Performance regression in java.util.zip.Deflater
linuxhippy at gmail.com
Thu Dec 20 23:20:28 UTC 2007
> Prior to 1.5.0_u7 the *Critical* function were used, but for the sake of
> 6206933, their use was replaced with data copying.
Thanks a lot for all the feedback, it really helps to understand the
reasons why the code is as it is. I also thought about the
DirectByteBuffers and I also did not like idea of having the data
twice (expecially when keeping in mind that some may compress hundreds
I still believe that a *Critical*-Solution still could be the best
solution - if the only drawback is that it can block other threads and
the JVM while running. Does a benchmark exist for this situation?
I still have some questions:
1.) Does GetByteArrayRegion also block the JVM/GC? (I assume it has to)
2.) Do the *Critical*-functions have other negative side-impacts
except blocking the GC.
3.) If many native threads try to call a *Critical*-function, although
the JVM would like to call a GC - does the JVM wait until no threads
hold a Critical Refrence - or will it block all threads that plan to
enter a Critical-Function, do its GC, and later resume?
Because if 1.) does block, 2.) no other side impacts, and 3.) is also
true I will try to benchmark and simulate a bit - I can't imagine that
it would block any more than GetByteArrayRegion.
Thanks a lot and sorry for beeing such a bullhead, lg Clemens
More information about the core-libs-dev