Performance regression on jdk7u25 vs jdk7u40 due to EPollArrayWrapper.eventsLow

[Jungwoo Ha]

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/8c584234/attachment.html