[rules-users] rule infinitely loops, appears to be depending on naming on variable

Greg Barton greg_barton at yahoo.com
Fri Oct 5 23:16:03 EDT 2012


You could implement a custom bit set with internal loops that are apt to be unrolled by the jit.


________________________________
 From: Mark Proctor <mproctor at codehaus.org>
To: Rules Users List <rules-users at lists.jboss.org> 
Sent: Friday, October 5, 2012 7:17 PM
Subject: Re: [rules-users] rule infinitely loops, appears to be depending on naming on variable
 

There is a class called BitSet, which grows the number of bits.
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/BitSet.java

This uses an array of longs instead. But i'm really reluctant to use this, because it adds overhead to our currently very lightweight operation, it has to create a for loop:
public boolean intersects(BitSet set) {
for (int i = Math.min(wordsInUse, set.wordsInUse) - 1; i >= 0; i--) {
    if ((words[i] & set.words[i]) != 0) {
return true;
}
}
 return false;
}


But we can investigate and see if it adds any noticeable performance. In the meantime the kbuilder should probably throw an exception.

Mark

On 5 Oct 2012, at 21:44, Davide Sottara <dsotty at gmail.com> wrote:

At the moment, @propertyReactive uses a bit mask internally... and I believe
>that is limited to 64 bits, which corresponds to 64 fields, less than what
>you have. 
>I'm not 100% sure since I didn't check, but I have the feeling that it may
>explain what is going on here..
>You have something like 160 fields, which is 128+32.. adding or removing one
>might indeed make a difference!
>
>This may indeed be a (known?) bug or limitation of the current impl, Mario
>Fusco will be able to provide more insight..
>
>You can easily work around the problem, at least for now, by preventing the
>loop with updatedArBankruptcyChapterPopulated != "No"
>
>A side question would be: do you really need all those fields in the same
>class? Wouldn't it be more reasonable to split it them in multiple beans,
>rather than a single generic "Facts" class? I'm not familiar
>with the domain, but the properties seem very hetherogeneous...
>Also in terms of efficiency and memory consumption, would an average
>instance of yours have most of those fields populated?
>
>Best
>Davide
>
>
>
>--
>View this message in context: http://drools.46999.n3.nabble.com/rule-infinitely-loops-appears-to-be-depending-on-naming-on-variable-tp4020158p4020159.html
>Sent from the Drools: User forum mailing list archive at Nabble.com.
>_______________________________________________
>rules-users mailing list
>rules-users at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/rules-users
>

_______________________________________________
rules-users mailing list
rules-users at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20121005/763deb5e/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1x1.gif
Type: image/gif
Size: 43 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/rules-users/attachments/20121005/763deb5e/attachment.gif 


More information about the rules-users mailing list