RE: [rules-dev] RE: [rules-users] Invokers and class gen

I believe it should make some difference in permgen to generate a single class. Some of the permgen data is generated on a per-class basis. It may not make enough of a difference though. Given that the mvel dialect is a valid workaround for the problem it probably isn't worth the effort. I can think of two alternatives to solve the problem (if the problem is worth solving). The first is to unload the classes generated for a given package when that package is reloaded. The permgen problems I've encountered have been when a rule package is replaced or many times in succession. Each time a class is generated during the package replacement its definition ends up in permgen. This would involve a custom class loader for the generated classes and the ability to remove all references to generated classes on demand. Probably mvel changes to make this work. The second alternative would be to provide a configuration option to approach the java dialiect like the mvel dialect and compile and execute on demand. This would likely be big drag on performance and not worth doing. I'll be in Dallas and if this project isn't worth working on I'd be happy to pick something else up that would get me deeper into the code, Joe More on permgen http://blogs.sun.com/jonthecollector/entry/presenting_the_permanent_gene ration From: rules-dev-bounces(a)lists.jboss.org [mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Mark Proctor Sent: Tuesday, October 14, 2008 9:11 AM To: Rules Dev List Subject: Re: [rules-dev] RE: [rules-users] Invokers and class gen Joe White wrote: I've spent a little time looking into allowing the invokers to be generated as methods in a single class rather than individual classes as is discussed below. Btw chatting to edson, he's not sure this will reduce perm gen size - what is the size differnce from one big class, and multiple small ones,on the perm gen. It's worth checking that this will make a difference, before doing it. It seems like a new set of mvel templates will need to be created to allow the java invokers to be generated as methods rather than individual classes. Then the Abstract Builder code will need to be updated to reference the correct template based on the user provided granularity level. For granularity, should there be any levels outside of: one class per package, one class per rule, and the current one class per invoker? If you can show that this is worth while doing, I'd look at making it configurable - although typically I imagine one per package. Am I on the right track? Thanks, Joe From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Mark Proctor Sent: Thursday, August 14, 2008 11:01 AM To: Rules Users List Cc: Rules Dev List Subject: Re: [rules-users] Max packages Joe White wrote: Mark, thank you very much for your help, it is greatly appreciated. "There are improvements we can make to generated code into a single class and use a switch statement to invoke the correct part, but we don't have time for that right now, so would need to come from the community." I would be interested in doing this work if someone can point me in the right direction on where to start. look for the *.mvel templates in drools-compiler you'll see how we generate the code. Then look at all the various java builders, like JavaConsequenceBuilder and you'll see how we construct it. compiled code is done in two places. We first generate an invoker class which implements the interface, like the Consequence interface and then we genernate the code to be executed which is called via the invoker. It needs to be two as the needed parameters for the java consequence to execute differer (different number of vars) so the invokers job is to match the needed interfaces and adapt/bridge to calling to the actual consequence/eval/predicate. We currently generate all the consequence/eval/predicate in a single class per rule, but we have a class per invoker. So we now need invoker apis, like Consequence, to take an int so it can use a switch statement to which allows multiple invocations to be generated into the same file. An idea solution will take a configuration on teh granularity that people want - to what we have now right up to putting everything into a single file for the entire package. I also would be interested in doing the work to allow drools to reference multiple levels of inner classes. This is done and fixed in 4.0.x and trunk - we just haven't released any binaries wit hteh fix. Our work would benefit from both pieces of functionality. I'll move this to the developer list, but would appreciate if somebody knowledgeable could show me where to get started on the code necessary to generate to a single class. I've cc'd this into the dev mailing list, so please when you reply do so to just that mailing list. Thanks, Joe From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Mark Proctor Sent: Wednesday, August 13, 2008 2:53 AM To: Rules Users List Subject: Re: [rules-users] Max packages Joe White wrote: Can someone help me understand the relationship between the number of Packages in a single RuleBase and PermGen memory consumption? I have a test that generates 200 rules and then adds those rules as different packages to a single rule base. PermGen consumption grows near linearly with the addition of Packages to the rule base and on a default PermGen setting the JVM runs out of PermGen after about 120 packages. It's not related to Packages, it's related to the number of rules and whether those rules have compiled java parts - like the consequence, eval etc - each one adds an additional class. Is every new Package and RuleBase backed by a set of generated Classes? Is there a way to get around the amount of class generation that is taking place? The test has been run against Drools 5. You can use MVEL, which has no class generation. There are improvements we can make to generated code into a single class and use a switch statement to invoke the correct part, but we don't have time for that right now, so would need to come from the community. Thank you for your help, Joe ________________________________ _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ________________________________ _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ________________________________ _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev