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
