Hi, I think there's a bit of confusion here and I agree this is caused by not exhaustive documentation (we are trying to improve it). The permgen threshold option is used for constraint jitting and that one works exactly in the same way regardless of the dialects. However when using the java dialect the permgen occupation grows not because of constraint jitting but because we have to generate java classes to implement the consequences. To cut it short permgen threshold and dialects are 2 orthogonal things, but it's true that keeping the threshold to 0 and using the mvel dialect is the best combination to reduce to the minimum the permgen occupation, because the first prevents the generation of java classes for constraints jitting while the second has the same effect for what regards consequences. Nevertheless there's a performance drawback in doing this because not allowing constraint jitting means that they will be always evaluated in interpreted mode, while for the same reason mvel consequences are a bit slower than java ones. For this reason my personal advice is to look for the best compromise between permgen occupation and performances for your specific use case. I hope this helps, Mario -- View this message in context: http://drools.46999.n3.nabble.com/Drools-Perm-gen-grows-constantly-tp4026... Sent from the Drools: User forum mailing list archive at Nabble.com.

Are you saying the permgen is leaking? That you update the rules, and no perigean space is reclaimed? There are some issues with the JVM, that I’ve seen before, which may be the problem. Such as the CMSClassUnloadingEnabled issue: http://java.dzone.com/articles/busting-permgen-myths I’d be interested to know if this is a pergmen leak, and if it continues on 6.x. If it does, maybe you could work with us to find out why it’s not being reclaimed? Mark On 18 Nov 2013, at 16:56, pmander <paul.s.mander(a)gmail.com&gt; wrote:

We had this issue where the permgen space was not reclaimed as CMS does not by default reclaim unless you use CMSClassUnloadingEnabled . After that we have not seen this though the permgen space keeps growing with addition of rules.The only thing we are afraid that if the permgen space requirement becomes same/greater than the threshold that CMS reclaims then what will happen?.We keep changing/increasing the permgen space but there is a limit to this at some point we can't allocate more proportion of memory for permgen space only ... Thanks & Regards, Adarsh SENIOR LEAD DEVELOPMENT SPECIALIST SCJP, SCWCD FINANCE TECHNOLOGY HSBC BANK PLC HBEU 8 Canada Square,Canary Wharf, London,E14 5HQ,United Kingdom ------------------------------------------------------ Phone +44 207914720 Mobile 07595530105 Email. adarsh.chaini(a)hsbcib.com ________________________________ From: Mark Proctor <mproctor(a)codehaus.org&gt; To: Rules Users List <rules-users(a)lists.jboss.org&gt; Date: 18/11/2013 17:12 Subject: Re: [rules-users] Drools Perm gen grows constantly Sent by: rules-users-bounces(a)lists.jboss.org Are you saying the permgen is leaking? That you update the rules, and no perigean space is reclaimed? There are some issues with the JVM, that I?ve seen before, which may be the problem. Such as the CMSClassUnloadingEnabled issue: http://java.dzone.com/articles/busting-permgen-myths I?d be interested to know if this is a pergmen leak, and if it continues on 6.x. If it does, maybe you could work with us to find out why it?s not being reclaimed? Mark On 18 Nov 2013, at 16:56, pmander <paul.s.mander(a)gmail.com&gt; wrote: rules. need. but up the http://drools.46999.n3.nabble.com/Drools-Perm-gen-grows-constantly-tp4026... _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ************************************************************ HSBC Bank plc may be solicited in the course of its placement efforts for a new issue, by investment clients of the firm for whom the Bank as a firm already provides other services. It may equally decide to allocate to its own proprietary book or with an associate of HSBC Group. This represents a potential conflict of interest. HSBC Bank plc has internal arrangements designed to ensure that the firm would give unbiased and full advice to the corporate finance client about the valuation and pricing of the offering as well as internal systems, controls and procedures to identify and manage conflicts of interest. HSBC Bank plc Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom Registered in England - Number 14259 Authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority ************************************************************ ----------------------------------------- SAVE PAPER - THINK BEFORE YOU PRINT! This transmission has been issued by a member of the HSBC Group "HSBC" for the information of the addressee only and should not be reproduced and/or distributed to any other person. Each page attached hereto must be read in conjunction with any disclaimer which forms part of it. Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. Its contents are based on information obtained from sources believed to be reliable but HSBC makes no representation and accepts no responsibility or liability as to its completeness or accuracy.