Performance regression on jdk7u25 vs jdk7u40 due to EPollArrayWrapper.eventsLow

[Jungwoo Ha]

tradesoap is a benchmark in Dacapo Suite (http://dacapobench.org)
It is one of the popular public benchmark used in both industry and
academia.

What are the scenarios that EPollArrayWrapper has more than one instance?



On Thu, Jan 9, 2014 at 6:20 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:

> Having 122 instances of the epollarraywrapper seems odd - that's basically
> 122 selectors monitoring connections.  Typically you'd have just one
> selector and thus one epollarraywrapper.  I'm not familiar with tradesoap
> so don't know what it's doing internally.
>
> One could probably slim down epollarraywrapper a bit but I think the
> reason the eventsLow[] is pre allocated with a large value is probably
> because it's expected to just have one or a few of them in the process.
>
> Sent from my phone
> On Jan 9, 2014 7:44 PM, "Jungwoo Ha" <jwha at google.com> wrote:
>
>> Hi,
>>
>> I found a performance issues on DaCapo tradesoap benchmark.
>>
>> *Commandline*
>> $ java -XX:+UseConcMarkSweepGC -Xmx76m -jar dacapo-9.12-bach.jar
>> tradesoap -n 7
>>
>>   76MB is 2 times of minimum heap size requirement on tradesoap, i.e.,
>> tradesoap can run on 38MB but not less.
>>   Measure the last iteration (steady state performance)
>>
>> *Execution time on the last iteration*
>>   7u25: 17910ms
>>   7u40: 21263ms
>>
>> So I compared the GC behavior using -XX:+PrintGCDetails, and noticed that
>> 7u40 executed far more concurrent-mode-failure.
>>   7u25: 2 Full GC, 60 concurrent-mode-failure
>>   7u40: 9 Full GC, 70 concurrent-mode-failure
>> and this is the cause of slowdown.
>>
>> Looking at the GC log, I noticed that 7u40 uses more memory.
>> 7u25 : [Full GC .... (concurrent mode failure): 48145K->*42452K*(51904K),
>> 0.2212080 secs]
>> 7u40 : [Full GC .... (concurrent mode failure): 47923K->*44672K*(51904K),
>> 0.2138640 secs]
>>
>> After the Full GC, 7u40 has 2.2MB more live objects. This is always
>> repeatable.
>>
>> So I got the heapdump of live objects and found that the most noticeable
>> difference is the byte[] of *EPollArrayWrapper.eventsLow.*
>> I think this field is added on 7u40 and was occupying 122 instances * 32K
>> = 3.8MB.
>>
>> Here goes my question.
>> 1) How are the # of instances of this type expected grow on large heap
>> size?
>>     How does it correlate to the network usage or typical server
>> applications?
>> 2) Is there a way to reduce the memory?
>>
>> Thanks,
>> Jungwoo
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20140109/9355606b/attachment.html