jdk7 feature that might be good for ofbiz

[Adam Heath <do...@brainfood.com>]

==
Area: HotSpot
Synopsis: In JDK 7, interned strings are no longer allocated in the
permanent generation of the Java heap, but are instead allocated in
the main part of the Java heap (known as the young and old
generations), along with the other objects created by the application.
This change will result in more data residing in the main Java heap,
and less data in the permanent generation, and thus may require heap
sizes to be adjusted. Most applications will see only relatively small
differences in heap usage due to this change, but larger applications
that load many classes or make heavy use of the String.intern() method
will see more significant differences.
RFE: 6962931
==

A few years back, I modified ofbiz to intern strings read from
entitymodel and servicemodel files.  According to the above new
feature, those strings where in permgen.  Also, as ofbiz has used more
and more groovy files, there are more and more classes loaded.  That
also implies a much larger permgen.

Re: jdk7 feature that might be good for ofbiz

[Adrian Crum <ad...@sandglass-software.com>]

Thanks Adam.

-Adrian

On 8/3/2011 4:30 PM, Adam Heath wrote:
> ==
> Area: HotSpot
> Synopsis: In JDK 7, interned strings are no longer allocated in the
> permanent generation of the Java heap, but are instead allocated in
> the main part of the Java heap (known as the young and old
> generations), along with the other objects created by the application.
> This change will result in more data residing in the main Java heap,
> and less data in the permanent generation, and thus may require heap
> sizes to be adjusted. Most applications will see only relatively small
> differences in heap usage due to this change, but larger applications
> that load many classes or make heavy use of the String.intern() method
> will see more significant differences.
> RFE: 6962931
> ==
>
> A few years back, I modified ofbiz to intern strings read from
> entitymodel and servicemodel files.  According to the above new
> feature, those strings where in permgen.  Also, as ofbiz has used more
> and more groovy files, there are more and more classes loaded.  That
> also implies a much larger permgen.

Re: jdk7 feature that might be good for ofbiz

[Adrian Crum <ad...@sandglass-software.com>]

On 5/27/2012 1:09 PM, Jacques Le Roux wrote:
> From: "Adrian Crum" <ad...@sandglass-software.com>
>> FYI, in the Mini-language overhaul I interned the Element tag name 
>> Strings.
>
> Yes, that's really a good improvment! Things are much more clear now. 
> It's only in minilang though (I mean not in widgets actions yet), right?
>
>> Another thing to discuss is the proper use of Javolution and/or 
>> whether we still need it.
>
> Yes, I also wondered about that last week when willing to cast to a 
> TreeMap.
> The fact that it's a one man project and will maybe less and less 
> supported http://javolution.org/#HISTORY is not yet an issue but could be

No, the issue is whether or not we still need pooled objects for the 
express purpose of reducing garbage collection. The use of Javolution 
was warranted in JDK versions prior to 1.5, but not so much now (with 
improved multi-generation GC).

-Adrian

>
> Jacques
>
>> -Adrian
>>
>> On 5/27/2012 11:05 AM, Jacques Le Roux wrote:
>>> I think it's time to *think* about it (ie turn to jdk 7). I don't 
>>> mean to change things, simply think about them, prepare them...
>>>
>>> From: "Adam Heath" <do...@brainfood.com>
>>>> ==
>>>> Area: HotSpot
>>>> Synopsis: In JDK 7, interned strings are no longer allocated in the
>>>> permanent generation of the Java heap, but are instead allocated in
>>>> the main part of the Java heap (known as the young and old
>>>> generations), along with the other objects created by the application.
>>>> This change will result in more data residing in the main Java heap,
>>>> and less data in the permanent generation, and thus may require heap
>>>> sizes to be adjusted. Most applications will see only relatively small
>>>> differences in heap usage due to this change, but larger applications
>>>> that load many classes or make heavy use of the String.intern() method
>>>> will see more significant differences.
>>>> RFE: 6962931
>>>> ==
>>>>
>>>> A few years back, I modified ofbiz to intern strings read from
>>>> entitymodel and servicemodel files.  According to the above new
>>>> feature, those strings where in permgen.  Also, as ofbiz has used more
>>>> and more groovy files, there are more and more classes loaded.  That
>>>> also implies a much larger permgen. 

Re: Discussion: Using Javolution

[Adam Heath <do...@brainfood.com>]

On 05/30/2012 06:24 AM, Adrian Crum wrote:
> I am reposting this thread with a different subject to make sure
> everyone interested has a chance to comment.
> 
> To summarize (and to make sure we are all on the same page):
> 
> 1. Javolution was added to the project in the JDK 1.4 days. David
> Jones ran some performance tests that demonstrated a performance boost
> when using Javolution Fast* classes instead of java.util.* classes.
> 2. Javolution acheived this performance boost by eliminating some
> garbage collection. The Fast* classes use object pools - where objects
> are returned to the pool when they are unused instead of being garbage
> collected.
> 3. JDK 1.5 introduced an improved garbage collector that eliminated
> the long pauses caused by previous garbage collectors. Also, it
> introduced the java.util.concurrent package - which is functionally
> similar to Javolution's concurrency. When OFBiz switched to the JDK
> 1.5 requirement, the need for Javolution was eliminated - but it was
> kept in the project anyway.
> 4. No performance tests have been executed recently to see what kind
> of impact removing Javolution will have.
> 5. In the attached thread I recommend removing Javolution from object
> fields that are effectively static (either declared static or a field
> of an object that is cached indefinitely), because the pooled object
> is never returned to the pool - defeating the purpose of the library.
> 6. In the attached thread Adam suggests removing Javolution entirely.

7: In JDK 1.6, escape analysis is used to figure out that some objects
can be directly allocated on the stack, instead of the heap.  Using
pooled objects precludes this.

When using EntityCondition pooled objects, where the condition will
eventually be frozen and used as a key in a cache, it makes no sense
really to pool it at all.

When doing the actual query, escape analysis *might* detect that the
condition could be allocated on the stack(it'd have to look at several
deep method calls).

Re: Discussion: Using Javolution

[Scott Gray <sc...@hotwaxmedia.com>]

I do think it's definitely worthwhile trying this out.  Looking at the history of javolution on their main page[1], they don't appear to have made much in the way of changes for at least 2 years and possibly up to 5, meanwhile the JDK/JVM continues to progress.

I was expecting to check the site and see that it was time for us to upgrade the library before doing any comparisons but things seem pretty stagnant.

Regards
Scott

[1] http://javolution.org/

On 31/05/2012, at 6:33 PM, Adrian Crum wrote:

> That's the thing - measuring performance can be tricky. A while back I ran across some code that didn't use fixed-count loops, but instead ran the test code through a loop indefinitely until the loop execution time stabilized - then the stabilized time was used as the measurement. That approach seemed to make the most sense to me.
> 
> But I agree - before we remove it altogether we should run some performance tests.
> 
> -Adrian
> 
> On 5/31/2012 7:27 AM, Jacopo Cappellato wrote:
>> We could create a branch, convert the code there to remove javolution and then run some profiling on the two instances; we could define in advance (before starting the actual work) the tools and tests we will use to measure the performance.
>> Then people will run the same tests in their own boxes (different platforms, hardware) and we will have a decent amount of data to take a more informed decision.
>> Any idea for the tool? (JMeter etc...)
>> 
>> Jacopo
>> 
>> On May 31, 2012, at 7:37 AM, Adrian Crum wrote:
>> 
>>> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201006.mbox/%3C2640ABB5-65B1-4CB0-B360-2A97EAC2E652@me.com%3E
>>> 
>>> -Adrian
>>> 
>>> On 5/31/2012 2:08 AM, Scott Gray wrote:
>>>> Perhaps my memory is failing but haven't you raised this topic before?  What was the outcome back then?
>>>> 
>>>> I think if you're planning to rehash old topics then it's good to call out the previous discussions that have been had to give a full context.  While I'm not at all suggesting you are doing this, it is entirely possible for someone with an agenda to keep raising old topics as new ones until the desired response is received from the community, later on when someone complains you can just say "but I discussed it first!" even if the idea had been rejected in several previous discussions.  Again, I'm not suggesting you're doing this, just using it as an example of why it's important to disclose previous discussions when raising them anew.
>>>> 
>>>> Regards
>>>> Scott
>>>> 
>>>> On 30/05/2012, at 11:24 PM, Adrian Crum wrote:
>>>> 
>>>>> I am reposting this thread with a different subject to make sure everyone interested has a chance to comment.
>>>>> 
>>>>> To summarize (and to make sure we are all on the same page):
>>>>> 
>>>>> 1. Javolution was added to the project in the JDK 1.4 days. David Jones ran some performance tests that demonstrated a performance boost when using Javolution Fast* classes instead of java.util.* classes.
>>>>> 2. Javolution acheived this performance boost by eliminating some garbage collection. The Fast* classes use object pools - where objects are returned to the pool when they are unused instead of being garbage collected.
>>>>> 3. JDK 1.5 introduced an improved garbage collector that eliminated the long pauses caused by previous garbage collectors. Also, it introduced the java.util.concurrent package - which is functionally similar to Javolution's concurrency. When OFBiz switched to the JDK 1.5 requirement, the need for Javolution was eliminated - but it was kept in the project anyway.
>>>>> 4. No performance tests have been executed recently to see what kind of impact removing Javolution will have.
>>>>> 5. In the attached thread I recommend removing Javolution from object fields that are effectively static (either declared static or a field of an object that is cached indefinitely), because the pooled object is never returned to the pool - defeating the purpose of the library.
>>>>> 6. In the attached thread Adam suggests removing Javolution entirely.
>>>>> 
>>>>> -Adrian
>>>>> 
>>>>> 
>>>>> On 5/27/2012 9:56 PM, Adrian Crum wrote:
>>>>>> On 5/27/2012 5:56 PM, Adam Heath wrote:
>>>>>>> On 05/27/2012 07:09 AM, Jacques Le Roux wrote:
>>>>>>>> From: "Adrian Crum"<ad...@sandglass-software.com>
>>>>>>>>> FYI, in the Mini-language overhaul I interned the Element tag name
>>>>>>>>> Strings.
>>>>>>>> Yes, that's really a good improvment! Things are much more clear now.
>>>>>>>> It's only in minilang though (I mean not in widgets actions yet), right?
>>>>>>>> 
>>>>>>>>> Another thing to discuss is the proper use of Javolution and/or
>>>>>>>>> whether we still need it.
>>>>>>>> Yes, I also wondered about that last week when willing to cast to a
>>>>>>>> TreeMap.
>>>>>>>> The fact that it's a one man project and will maybe less and less
>>>>>>>> supported http://javolution.org/#HISTORY is not yet an issue but could be
>>>>>>> I personally see no need for javolution.  It's non-standard concurrency(java.util.concurrent).  It does it's own memory allocation, which prevents escape-analysis from working(allocating memory on the stack instead of the heap).
>>>>>>> 
>>>>>> In the Mini-language overhaul I removed Javolution classes from model fields - since the models could be kept in memory (cached) indefinitely (resulting in borrowed objects that are never returned to the pool). I kept Javolution in the script execution path - which is the proper use from my perspective. I know you ran into issues with FastMap previously, but I don't remember the details.
>>>>>> 
>>>>>> If there are no objections, I can remove Javolution from Mini-language entirely.
>>>>>> 
>>>>>> -Adrian
>>>>>> 

Re: Discussion: Using Javolution

[Adrian Crum <ad...@sandglass-software.com>]

That's the thing - measuring performance can be tricky. A while back I 
ran across some code that didn't use fixed-count loops, but instead ran 
the test code through a loop indefinitely until the loop execution time 
stabilized - then the stabilized time was used as the measurement. That 
approach seemed to make the most sense to me.

But I agree - before we remove it altogether we should run some 
performance tests.

-Adrian

On 5/31/2012 7:27 AM, Jacopo Cappellato wrote:
> We could create a branch, convert the code there to remove javolution and then run some profiling on the two instances; we could define in advance (before starting the actual work) the tools and tests we will use to measure the performance.
> Then people will run the same tests in their own boxes (different platforms, hardware) and we will have a decent amount of data to take a more informed decision.
> Any idea for the tool? (JMeter etc...)
>
> Jacopo
>
> On May 31, 2012, at 7:37 AM, Adrian Crum wrote:
>
>> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201006.mbox/%3C2640ABB5-65B1-4CB0-B360-2A97EAC2E652@me.com%3E
>>
>> -Adrian
>>
>> On 5/31/2012 2:08 AM, Scott Gray wrote:
>>> Perhaps my memory is failing but haven't you raised this topic before?  What was the outcome back then?
>>>
>>> I think if you're planning to rehash old topics then it's good to call out the previous discussions that have been had to give a full context.  While I'm not at all suggesting you are doing this, it is entirely possible for someone with an agenda to keep raising old topics as new ones until the desired response is received from the community, later on when someone complains you can just say "but I discussed it first!" even if the idea had been rejected in several previous discussions.  Again, I'm not suggesting you're doing this, just using it as an example of why it's important to disclose previous discussions when raising them anew.
>>>
>>> Regards
>>> Scott
>>>
>>> On 30/05/2012, at 11:24 PM, Adrian Crum wrote:
>>>
>>>> I am reposting this thread with a different subject to make sure everyone interested has a chance to comment.
>>>>
>>>> To summarize (and to make sure we are all on the same page):
>>>>
>>>> 1. Javolution was added to the project in the JDK 1.4 days. David Jones ran some performance tests that demonstrated a performance boost when using Javolution Fast* classes instead of java.util.* classes.
>>>> 2. Javolution acheived this performance boost by eliminating some garbage collection. The Fast* classes use object pools - where objects are returned to the pool when they are unused instead of being garbage collected.
>>>> 3. JDK 1.5 introduced an improved garbage collector that eliminated the long pauses caused by previous garbage collectors. Also, it introduced the java.util.concurrent package - which is functionally similar to Javolution's concurrency. When OFBiz switched to the JDK 1.5 requirement, the need for Javolution was eliminated - but it was kept in the project anyway.
>>>> 4. No performance tests have been executed recently to see what kind of impact removing Javolution will have.
>>>> 5. In the attached thread I recommend removing Javolution from object fields that are effectively static (either declared static or a field of an object that is cached indefinitely), because the pooled object is never returned to the pool - defeating the purpose of the library.
>>>> 6. In the attached thread Adam suggests removing Javolution entirely.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 5/27/2012 9:56 PM, Adrian Crum wrote:
>>>>> On 5/27/2012 5:56 PM, Adam Heath wrote:
>>>>>> On 05/27/2012 07:09 AM, Jacques Le Roux wrote:
>>>>>>> From: "Adrian Crum"<ad...@sandglass-software.com>
>>>>>>>> FYI, in the Mini-language overhaul I interned the Element tag name
>>>>>>>> Strings.
>>>>>>> Yes, that's really a good improvment! Things are much more clear now.
>>>>>>> It's only in minilang though (I mean not in widgets actions yet), right?
>>>>>>>
>>>>>>>> Another thing to discuss is the proper use of Javolution and/or
>>>>>>>> whether we still need it.
>>>>>>> Yes, I also wondered about that last week when willing to cast to a
>>>>>>> TreeMap.
>>>>>>> The fact that it's a one man project and will maybe less and less
>>>>>>> supported http://javolution.org/#HISTORY is not yet an issue but could be
>>>>>> I personally see no need for javolution.  It's non-standard concurrency(java.util.concurrent).  It does it's own memory allocation, which prevents escape-analysis from working(allocating memory on the stack instead of the heap).
>>>>>>
>>>>> In the Mini-language overhaul I removed Javolution classes from model fields - since the models could be kept in memory (cached) indefinitely (resulting in borrowed objects that are never returned to the pool). I kept Javolution in the script execution path - which is the proper use from my perspective. I know you ran into issues with FastMap previously, but I don't remember the details.
>>>>>
>>>>> If there are no objections, I can remove Javolution from Mini-language entirely.
>>>>>
>>>>> -Adrian
>>>>>

Re: Discussion: Using Javolution

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

We could create a branch, convert the code there to remove javolution and then run some profiling on the two instances; we could define in advance (before starting the actual work) the tools and tests we will use to measure the performance.
Then people will run the same tests in their own boxes (different platforms, hardware) and we will have a decent amount of data to take a more informed decision.
Any idea for the tool? (JMeter etc...)

Jacopo

On May 31, 2012, at 7:37 AM, Adrian Crum wrote:

> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201006.mbox/%3C2640ABB5-65B1-4CB0-B360-2A97EAC2E652@me.com%3E
> 
> -Adrian
> 
> On 5/31/2012 2:08 AM, Scott Gray wrote:
>> Perhaps my memory is failing but haven't you raised this topic before?  What was the outcome back then?
>> 
>> I think if you're planning to rehash old topics then it's good to call out the previous discussions that have been had to give a full context.  While I'm not at all suggesting you are doing this, it is entirely possible for someone with an agenda to keep raising old topics as new ones until the desired response is received from the community, later on when someone complains you can just say "but I discussed it first!" even if the idea had been rejected in several previous discussions.  Again, I'm not suggesting you're doing this, just using it as an example of why it's important to disclose previous discussions when raising them anew.
>> 
>> Regards
>> Scott
>> 
>> On 30/05/2012, at 11:24 PM, Adrian Crum wrote:
>> 
>>> I am reposting this thread with a different subject to make sure everyone interested has a chance to comment.
>>> 
>>> To summarize (and to make sure we are all on the same page):
>>> 
>>> 1. Javolution was added to the project in the JDK 1.4 days. David Jones ran some performance tests that demonstrated a performance boost when using Javolution Fast* classes instead of java.util.* classes.
>>> 2. Javolution acheived this performance boost by eliminating some garbage collection. The Fast* classes use object pools - where objects are returned to the pool when they are unused instead of being garbage collected.
>>> 3. JDK 1.5 introduced an improved garbage collector that eliminated the long pauses caused by previous garbage collectors. Also, it introduced the java.util.concurrent package - which is functionally similar to Javolution's concurrency. When OFBiz switched to the JDK 1.5 requirement, the need for Javolution was eliminated - but it was kept in the project anyway.
>>> 4. No performance tests have been executed recently to see what kind of impact removing Javolution will have.
>>> 5. In the attached thread I recommend removing Javolution from object fields that are effectively static (either declared static or a field of an object that is cached indefinitely), because the pooled object is never returned to the pool - defeating the purpose of the library.
>>> 6. In the attached thread Adam suggests removing Javolution entirely.
>>> 
>>> -Adrian
>>> 
>>> 
>>> On 5/27/2012 9:56 PM, Adrian Crum wrote:
>>>> On 5/27/2012 5:56 PM, Adam Heath wrote:
>>>>> On 05/27/2012 07:09 AM, Jacques Le Roux wrote:
>>>>>> From: "Adrian Crum"<ad...@sandglass-software.com>
>>>>>>> FYI, in the Mini-language overhaul I interned the Element tag name
>>>>>>> Strings.
>>>>>> Yes, that's really a good improvment! Things are much more clear now.
>>>>>> It's only in minilang though (I mean not in widgets actions yet), right?
>>>>>> 
>>>>>>> Another thing to discuss is the proper use of Javolution and/or
>>>>>>> whether we still need it.
>>>>>> Yes, I also wondered about that last week when willing to cast to a
>>>>>> TreeMap.
>>>>>> The fact that it's a one man project and will maybe less and less
>>>>>> supported http://javolution.org/#HISTORY is not yet an issue but could be
>>>>> I personally see no need for javolution.  It's non-standard concurrency(java.util.concurrent).  It does it's own memory allocation, which prevents escape-analysis from working(allocating memory on the stack instead of the heap).
>>>>> 
>>>> In the Mini-language overhaul I removed Javolution classes from model fields - since the models could be kept in memory (cached) indefinitely (resulting in borrowed objects that are never returned to the pool). I kept Javolution in the script execution path - which is the proper use from my perspective. I know you ran into issues with FastMap previously, but I don't remember the details.
>>>> 
>>>> If there are no objections, I can remove Javolution from Mini-language entirely.
>>>> 
>>>> -Adrian
>>>> 

Re: Discussion: Using Javolution

[Adrian Crum <ad...@sandglass-software.com>]

http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201006.mbox/%3C2640ABB5-65B1-4CB0-B360-2A97EAC2E652@me.com%3E

-Adrian

On 5/31/2012 2:08 AM, Scott Gray wrote:
> Perhaps my memory is failing but haven't you raised this topic before?  What was the outcome back then?
>
> I think if you're planning to rehash old topics then it's good to call out the previous discussions that have been had to give a full context.  While I'm not at all suggesting you are doing this, it is entirely possible for someone with an agenda to keep raising old topics as new ones until the desired response is received from the community, later on when someone complains you can just say "but I discussed it first!" even if the idea had been rejected in several previous discussions.  Again, I'm not suggesting you're doing this, just using it as an example of why it's important to disclose previous discussions when raising them anew.
>
> Regards
> Scott
>
> On 30/05/2012, at 11:24 PM, Adrian Crum wrote:
>
>> I am reposting this thread with a different subject to make sure everyone interested has a chance to comment.
>>
>> To summarize (and to make sure we are all on the same page):
>>
>> 1. Javolution was added to the project in the JDK 1.4 days. David Jones ran some performance tests that demonstrated a performance boost when using Javolution Fast* classes instead of java.util.* classes.
>> 2. Javolution acheived this performance boost by eliminating some garbage collection. The Fast* classes use object pools - where objects are returned to the pool when they are unused instead of being garbage collected.
>> 3. JDK 1.5 introduced an improved garbage collector that eliminated the long pauses caused by previous garbage collectors. Also, it introduced the java.util.concurrent package - which is functionally similar to Javolution's concurrency. When OFBiz switched to the JDK 1.5 requirement, the need for Javolution was eliminated - but it was kept in the project anyway.
>> 4. No performance tests have been executed recently to see what kind of impact removing Javolution will have.
>> 5. In the attached thread I recommend removing Javolution from object fields that are effectively static (either declared static or a field of an object that is cached indefinitely), because the pooled object is never returned to the pool - defeating the purpose of the library.
>> 6. In the attached thread Adam suggests removing Javolution entirely.
>>
>> -Adrian
>>
>>
>> On 5/27/2012 9:56 PM, Adrian Crum wrote:
>>> On 5/27/2012 5:56 PM, Adam Heath wrote:
>>>> On 05/27/2012 07:09 AM, Jacques Le Roux wrote:
>>>>> From: "Adrian Crum"<ad...@sandglass-software.com>
>>>>>> FYI, in the Mini-language overhaul I interned the Element tag name
>>>>>> Strings.
>>>>> Yes, that's really a good improvment! Things are much more clear now.
>>>>> It's only in minilang though (I mean not in widgets actions yet), right?
>>>>>
>>>>>> Another thing to discuss is the proper use of Javolution and/or
>>>>>> whether we still need it.
>>>>> Yes, I also wondered about that last week when willing to cast to a
>>>>> TreeMap.
>>>>> The fact that it's a one man project and will maybe less and less
>>>>> supported http://javolution.org/#HISTORY is not yet an issue but could be
>>>> I personally see no need for javolution.  It's non-standard concurrency(java.util.concurrent).  It does it's own memory allocation, which prevents escape-analysis from working(allocating memory on the stack instead of the heap).
>>>>
>>> In the Mini-language overhaul I removed Javolution classes from model fields - since the models could be kept in memory (cached) indefinitely (resulting in borrowed objects that are never returned to the pool). I kept Javolution in the script execution path - which is the proper use from my perspective. I know you ran into issues with FastMap previously, but I don't remember the details.
>>>
>>> If there are no objections, I can remove Javolution from Mini-language entirely.
>>>
>>> -Adrian
>>>

Re: Discussion: Using Javolution (was: jdk7 feature that might be good for ofbiz)

[Scott Gray <sc...@hotwaxmedia.com>]

Perhaps my memory is failing but haven't you raised this topic before?  What was the outcome back then?

I think if you're planning to rehash old topics then it's good to call out the previous discussions that have been had to give a full context.  While I'm not at all suggesting you are doing this, it is entirely possible for someone with an agenda to keep raising old topics as new ones until the desired response is received from the community, later on when someone complains you can just say "but I discussed it first!" even if the idea had been rejected in several previous discussions.  Again, I'm not suggesting you're doing this, just using it as an example of why it's important to disclose previous discussions when raising them anew.

Regards
Scott

On 30/05/2012, at 11:24 PM, Adrian Crum wrote:

> I am reposting this thread with a different subject to make sure everyone interested has a chance to comment.
> 
> To summarize (and to make sure we are all on the same page):
> 
> 1. Javolution was added to the project in the JDK 1.4 days. David Jones ran some performance tests that demonstrated a performance boost when using Javolution Fast* classes instead of java.util.* classes.
> 2. Javolution acheived this performance boost by eliminating some garbage collection. The Fast* classes use object pools - where objects are returned to the pool when they are unused instead of being garbage collected.
> 3. JDK 1.5 introduced an improved garbage collector that eliminated the long pauses caused by previous garbage collectors. Also, it introduced the java.util.concurrent package - which is functionally similar to Javolution's concurrency. When OFBiz switched to the JDK 1.5 requirement, the need for Javolution was eliminated - but it was kept in the project anyway.
> 4. No performance tests have been executed recently to see what kind of impact removing Javolution will have.
> 5. In the attached thread I recommend removing Javolution from object fields that are effectively static (either declared static or a field of an object that is cached indefinitely), because the pooled object is never returned to the pool - defeating the purpose of the library.
> 6. In the attached thread Adam suggests removing Javolution entirely.
> 
> -Adrian
> 
> 
> On 5/27/2012 9:56 PM, Adrian Crum wrote:
>> On 5/27/2012 5:56 PM, Adam Heath wrote:
>>> On 05/27/2012 07:09 AM, Jacques Le Roux wrote:
>>>> From: "Adrian Crum" <ad...@sandglass-software.com>
>>>>> FYI, in the Mini-language overhaul I interned the Element tag name
>>>>> Strings.
>>>> 
>>>> Yes, that's really a good improvment! Things are much more clear now.
>>>> It's only in minilang though (I mean not in widgets actions yet), right?
>>>> 
>>>>> Another thing to discuss is the proper use of Javolution and/or
>>>>> whether we still need it.
>>>> 
>>>> Yes, I also wondered about that last week when willing to cast to a
>>>> TreeMap.
>>>> The fact that it's a one man project and will maybe less and less
>>>> supported http://javolution.org/#HISTORY is not yet an issue but could be
>>> 
>>> I personally see no need for javolution.  It's non-standard concurrency(java.util.concurrent).  It does it's own memory allocation, which prevents escape-analysis from working(allocating memory on the stack instead of the heap).
>>> 
>> 
>> In the Mini-language overhaul I removed Javolution classes from model fields - since the models could be kept in memory (cached) indefinitely (resulting in borrowed objects that are never returned to the pool). I kept Javolution in the script execution path - which is the proper use from my perspective. I know you ran into issues with FastMap previously, but I don't remember the details.
>> 
>> If there are no objections, I can remove Javolution from Mini-language entirely.
>> 
>> -Adrian
>> 

Discussion: Using Javolution (was: jdk7 feature that might be good for ofbiz)

[Adrian Crum <ad...@sandglass-software.com>]

I am reposting this thread with a different subject to make sure 
everyone interested has a chance to comment.

To summarize (and to make sure we are all on the same page):

1. Javolution was added to the project in the JDK 1.4 days. David Jones 
ran some performance tests that demonstrated a performance boost when 
using Javolution Fast* classes instead of java.util.* classes.
2. Javolution acheived this performance boost by eliminating some 
garbage collection. The Fast* classes use object pools - where objects 
are returned to the pool when they are unused instead of being garbage 
collected.
3. JDK 1.5 introduced an improved garbage collector that eliminated the 
long pauses caused by previous garbage collectors. Also, it introduced 
the java.util.concurrent package - which is functionally similar to 
Javolution's concurrency. When OFBiz switched to the JDK 1.5 
requirement, the need for Javolution was eliminated - but it was kept in 
the project anyway.
4. No performance tests have been executed recently to see what kind of 
impact removing Javolution will have.
5. In the attached thread I recommend removing Javolution from object 
fields that are effectively static (either declared static or a field of 
an object that is cached indefinitely), because the pooled object is 
never returned to the pool - defeating the purpose of the library.
6. In the attached thread Adam suggests removing Javolution entirely.

-Adrian


On 5/27/2012 9:56 PM, Adrian Crum wrote:
> On 5/27/2012 5:56 PM, Adam Heath wrote:
>> On 05/27/2012 07:09 AM, Jacques Le Roux wrote:
>>> From: "Adrian Crum" <ad...@sandglass-software.com>
>>>> FYI, in the Mini-language overhaul I interned the Element tag name
>>>> Strings.
>>>
>>> Yes, that's really a good improvment! Things are much more clear now.
>>> It's only in minilang though (I mean not in widgets actions yet), 
>>> right?
>>>
>>>> Another thing to discuss is the proper use of Javolution and/or
>>>> whether we still need it.
>>>
>>> Yes, I also wondered about that last week when willing to cast to a
>>> TreeMap.
>>> The fact that it's a one man project and will maybe less and less
>>> supported http://javolution.org/#HISTORY is not yet an issue but 
>>> could be
>>
>> I personally see no need for javolution.  It's non-standard 
>> concurrency(java.util.concurrent).  It does it's own memory 
>> allocation, which prevents escape-analysis from working(allocating 
>> memory on the stack instead of the heap).
>>
>
> In the Mini-language overhaul I removed Javolution classes from model 
> fields - since the models could be kept in memory (cached) 
> indefinitely (resulting in borrowed objects that are never returned to 
> the pool). I kept Javolution in the script execution path - which is 
> the proper use from my perspective. I know you ran into issues with 
> FastMap previously, but I don't remember the details.
>
> If there are no objections, I can remove Javolution from Mini-language 
> entirely.
>
> -Adrian
>

Re: jdk7 feature that might be good for ofbiz

[Adrian Crum <ad...@sandglass-software.com>]

On 5/27/2012 5:56 PM, Adam Heath wrote:
> On 05/27/2012 07:09 AM, Jacques Le Roux wrote:
>> From: "Adrian Crum" <ad...@sandglass-software.com>
>>> FYI, in the Mini-language overhaul I interned the Element tag name
>>> Strings.
>>
>> Yes, that's really a good improvment! Things are much more clear now.
>> It's only in minilang though (I mean not in widgets actions yet), right?
>>
>>> Another thing to discuss is the proper use of Javolution and/or
>>> whether we still need it.
>>
>> Yes, I also wondered about that last week when willing to cast to a
>> TreeMap.
>> The fact that it's a one man project and will maybe less and less
>> supported http://javolution.org/#HISTORY is not yet an issue but 
>> could be
>
> I personally see no need for javolution.  It's non-standard 
> concurrency(java.util.concurrent).  It does it's own memory 
> allocation, which prevents escape-analysis from working(allocating 
> memory on the stack instead of the heap).
>

In the Mini-language overhaul I removed Javolution classes from model 
fields - since the models could be kept in memory (cached) indefinitely 
(resulting in borrowed objects that are never returned to the pool). I 
kept Javolution in the script execution path - which is the proper use 
from my perspective. I know you ran into issues with FastMap previously, 
but I don't remember the details.

If there are no objections, I can remove Javolution from Mini-language 
entirely.

-Adrian

Re: jdk7 feature that might be good for ofbiz

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

On May 27, 2012, at 6:56 PM, Adam Heath wrote:

> I personally see no need for javolution.  It's non-standard concurrency(java.util.concurrent).  It does it's own memory allocation, which prevents escape-analysis from working(allocating memory on the stack instead of the heap).

+1

Re: jdk7 feature that might be good for ofbiz

[Jacques Le Roux <ja...@les7arts.com>]

Removing Javolution could be part of a move to JDK 1.7

What do you think?

Jacques

From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
> This page may be useful:
>
> http://javolution.org/doc/benchmark.html
>
> Jacopo
>
> On May 27, 2012, at 6:56 PM, Adam Heath wrote:
>
>> On 05/27/2012 07:09 AM, Jacques Le Roux wrote:
>>> From: "Adrian Crum" <ad...@sandglass-software.com>
>>>> FYI, in the Mini-language overhaul I interned the Element tag name
>>>> Strings.
>>>
>>> Yes, that's really a good improvment! Things are much more clear now.
>>> It's only in minilang though (I mean not in widgets actions yet), right?
>>>
>>>> Another thing to discuss is the proper use of Javolution and/or
>>>> whether we still need it.
>>>
>>> Yes, I also wondered about that last week when willing to cast to a
>>> TreeMap.
>>> The fact that it's a one man project and will maybe less and less
>>> supported http://javolution.org/#HISTORY is not yet an issue but could be
>>
>> I personally see no need for javolution.  It's non-standard concurrency(java.util.concurrent).  It does it's own memory 
>> allocation, which prevents escape-analysis from working(allocating memory on the stack instead of the heap).
>>
>
> 

Re: jdk7 feature that might be good for ofbiz

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

This page may be useful:

http://javolution.org/doc/benchmark.html

Jacopo

On May 27, 2012, at 6:56 PM, Adam Heath wrote:

> On 05/27/2012 07:09 AM, Jacques Le Roux wrote:
>> From: "Adrian Crum" <ad...@sandglass-software.com>
>>> FYI, in the Mini-language overhaul I interned the Element tag name
>>> Strings.
>> 
>> Yes, that's really a good improvment! Things are much more clear now.
>> It's only in minilang though (I mean not in widgets actions yet), right?
>> 
>>> Another thing to discuss is the proper use of Javolution and/or
>>> whether we still need it.
>> 
>> Yes, I also wondered about that last week when willing to cast to a
>> TreeMap.
>> The fact that it's a one man project and will maybe less and less
>> supported http://javolution.org/#HISTORY is not yet an issue but could be
> 
> I personally see no need for javolution.  It's non-standard concurrency(java.util.concurrent).  It does it's own memory allocation, which prevents escape-analysis from working(allocating memory on the stack instead of the heap).
> 

Re: jdk7 feature that might be good for ofbiz

[Adam Heath <do...@brainfood.com>]

On 05/27/2012 07:09 AM, Jacques Le Roux wrote:
> From: "Adrian Crum" <ad...@sandglass-software.com>
>> FYI, in the Mini-language overhaul I interned the Element tag name
>> Strings.
>
> Yes, that's really a good improvment! Things are much more clear now.
> It's only in minilang though (I mean not in widgets actions yet), right?
>
>> Another thing to discuss is the proper use of Javolution and/or
>> whether we still need it.
>
> Yes, I also wondered about that last week when willing to cast to a
> TreeMap.
> The fact that it's a one man project and will maybe less and less
> supported http://javolution.org/#HISTORY is not yet an issue but could be

I personally see no need for javolution.  It's non-standard 
concurrency(java.util.concurrent).  It does it's own memory allocation, 
which prevents escape-analysis from working(allocating memory on the 
stack instead of the heap).

Re: jdk7 feature that might be good for ofbiz

[Jacques Le Roux <ja...@les7arts.com>]

From: "Adrian Crum" <ad...@sandglass-software.com>
> FYI, in the Mini-language overhaul I interned the Element tag name Strings.

Yes, that's really a good improvment! Things are much more clear now. It's only in minilang though (I mean not in widgets actions 
yet), right?

> Another thing to discuss is the proper use of Javolution and/or whether we still need it.

Yes, I also wondered about that last week when willing to cast to a TreeMap.
The fact that it's a one man project and will maybe less and less supported http://javolution.org/#HISTORY is not yet an issue but 
could be

Jacques

> -Adrian
>
> On 5/27/2012 11:05 AM, Jacques Le Roux wrote:
>> I think it's time to *think* about it (ie turn to jdk 7). I don't mean to change things, simply think about them, prepare them...
>>
>> From: "Adam Heath" <do...@brainfood.com>
>>> ==
>>> Area: HotSpot
>>> Synopsis: In JDK 7, interned strings are no longer allocated in the
>>> permanent generation of the Java heap, but are instead allocated in
>>> the main part of the Java heap (known as the young and old
>>> generations), along with the other objects created by the application.
>>> This change will result in more data residing in the main Java heap,
>>> and less data in the permanent generation, and thus may require heap
>>> sizes to be adjusted. Most applications will see only relatively small
>>> differences in heap usage due to this change, but larger applications
>>> that load many classes or make heavy use of the String.intern() method
>>> will see more significant differences.
>>> RFE: 6962931
>>> ==
>>>
>>> A few years back, I modified ofbiz to intern strings read from
>>> entitymodel and servicemodel files.  According to the above new
>>> feature, those strings where in permgen.  Also, as ofbiz has used more
>>> and more groovy files, there are more and more classes loaded.  That
>>> also implies a much larger permgen. 

Re: jdk7 feature that might be good for ofbiz

[Adrian Crum <ad...@sandglass-software.com>]

FYI, in the Mini-language overhaul I interned the Element tag name Strings.

Another thing to discuss is the proper use of Javolution and/or whether 
we still need it.

-Adrian

On 5/27/2012 11:05 AM, Jacques Le Roux wrote:
> I think it's time to *think* about it (ie turn to jdk 7). I don't mean 
> to change things, simply think about them, prepare them...
>
> From: "Adam Heath" <do...@brainfood.com>
>> ==
>> Area: HotSpot
>> Synopsis: In JDK 7, interned strings are no longer allocated in the
>> permanent generation of the Java heap, but are instead allocated in
>> the main part of the Java heap (known as the young and old
>> generations), along with the other objects created by the application.
>> This change will result in more data residing in the main Java heap,
>> and less data in the permanent generation, and thus may require heap
>> sizes to be adjusted. Most applications will see only relatively small
>> differences in heap usage due to this change, but larger applications
>> that load many classes or make heavy use of the String.intern() method
>> will see more significant differences.
>> RFE: 6962931
>> ==
>>
>> A few years back, I modified ofbiz to intern strings read from
>> entitymodel and servicemodel files.  According to the above new
>> feature, those strings where in permgen.  Also, as ofbiz has used more
>> and more groovy files, there are more and more classes loaded.  That
>> also implies a much larger permgen.

Re: jdk7 feature that might be good for ofbiz

[Jacques Le Roux <ja...@les7arts.com>]

I think it's time to *think* about it (ie turn to jdk 7). I don't mean to change things, simply think about them, prepare them...

From: "Adam Heath" <do...@brainfood.com>
> ==
> Area: HotSpot
> Synopsis: In JDK 7, interned strings are no longer allocated in the
> permanent generation of the Java heap, but are instead allocated in
> the main part of the Java heap (known as the young and old
> generations), along with the other objects created by the application.
> This change will result in more data residing in the main Java heap,
> and less data in the permanent generation, and thus may require heap
> sizes to be adjusted. Most applications will see only relatively small
> differences in heap usage due to this change, but larger applications
> that load many classes or make heavy use of the String.intern() method
> will see more significant differences.
> RFE: 6962931
> ==
> 
> A few years back, I modified ofbiz to intern strings read from
> entitymodel and servicemodel files.  According to the above new
> feature, those strings where in permgen.  Also, as ofbiz has used more
> and more groovy files, there are more and more classes loaded.  That
> also implies a much larger permgen.