Performance regression in

Dave Bristor David.Bristor at Sun.COM
Fri Dec 21 00:37:14 UTC 2007

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/ 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):
(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!


More information about the core-libs-dev mailing list