Performance regression in java.util.zip.Deflater

[Clemens Eisserer]

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?

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