Performance regression on jdk7u25 vs jdk7u40 due to EPollArrayWrapper.eventsLow

[Vitaly Davidovich]

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/3ee7005e/attachment.html