Performance regression in java.util.zip.Deflater

[Martin Buchholz]

Hi Clemens,

(Thank you very much for working on this problem)

Clemens Eisserer wrote:
> Hi again,
> 
>>Sun engineers have tried to get reasonable performance
>>without using JNI_Get*Critical, since that introduces other
>>serious performance problems.  It was my belief that any
>>pathological n^2 performance problems had been truly fixed.
> At least the code in JDK7u23 looks like (n^2)/2 or something like
> that, it copies every time the whole bytes which are left, including
> malloc/free.
> 
>>Sun engineers have tried to get reasonable performance
>>without using JNI_Get*Critical, since that introduces other
>>serious performance problems.
> Could please tell me when and why. As far as I understood the problem
> with the *Critical*-Functions is that they hinder the JVM in doing
> some operations (GC, ...) which limits scalability.
> 
> If this is the only reson, using them may not be that bad if the
> Get*ArrayRegion also has some GC-atomic behaviour. Copying 50mb data
> atomically also blocks the GC, doesn't it?

I'm not the expert on this, but I believe the GC may be completely
blocked from making progress while data is held "Critical"-ly,
while this is not true of the regular JNI functions.
If multiple threads are busy deflating furiously, the entire JVM
may be blocked from making progress.

> I am working on a fix which processes the data in "strides", therefor
> the lock is only held a short time. Is this really a bad idea, except
> for the additional JNI overhead?

Offhand, dividing the data into chunks sounds like a good idea.
But you're not likely to be able to persuade Sun to
reintroduce the use of JNI_Get*Critical, which has already
been removed at great cost.

Martin

> Thanks, lg Clemens