Clemens Eisserer wrote:
Hi Dave,
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
of mbs).
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?
jdk/test/java/util/zip/FlaterTest.java can be used to compare different JVMs;
I'm sorry but I don't think we have a better test. See also the code in
6364346 and/or 6507183.
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.
I don't see a block in the ArrayRegion functions (a little surprisingly):
hotspot/src/share/vm/prims/jni.cpp
(Search for just "arrayregion"). Compare the array region function body with
the primitivearraycritical function body; the latter obviously interacts with 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?
I'm no expert here! See 6186200's discussion of GC & critical sections.
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
You're welcome, and thank you for your interest!
Dave
