[rules-dev] RE: [rules-users] Invokers and class gen
Mark Proctor
mproctor at codehaus.org
Tue Oct 14 13:09:09 EDT 2008
Joe White wrote:
>
> 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).
>
Another way is to stop generating the invoker and instead use cached
reflection to call the generated rule - this might be a good compromise,
as it'll reduce the generated code by half. Again ideally it would be
configurable.
>
>
>
> 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 sounds like a memory leak, when you redefine a class it should drop
the classloader and create a new one, leaving all the perm gen space
used for that classloader to be GC'd.
>
> 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,
>
Cool, see you then.
>
>
>
> Joe
>
>
>
>
>
>
>
>
>
> More on permgen
> http://blogs.sun.com/jonthecollector/entry/presenting_the_permanent_generation
>
>
>
>
>
>
>
> *From:* rules-dev-bounces at lists.jboss.org
> [mailto:rules-dev-bounces at 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 at lists.jboss.org
> <mailto:rules-users-bounces at lists.jboss.org>
> [mailto:rules-users-bounces at 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 at lists.jboss.org
> <mailto:rules-users-bounces at lists.jboss.org>
> [mailto:rules-users-bounces at 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 at lists.jboss.org <mailto:rules-users at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
>
>
>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
>
> ------------------------------------------------------------------------
>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20081014/6fcd5515/attachment.html
More information about the rules-dev
mailing list