Joe
More on
permgen
http://blogs.sun.com/jonthecollector/entry/presenting_the_permanent_generation
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
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
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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev