GetPrimitiveArrayCritical vs GetByteArrayRegion: 140x slow-down using -Xcheck:jni and java.util.zip.DeflaterOutputStream
thomas.schatzl at oracle.com
Thu Mar 15 08:25:48 UTC 2018
On Thu, 2018-03-15 at 01:00 +0000, Ian Rogers wrote:
> An old data point on how large a critical region should be comes from
> java.nio.Bits. In JDK 9 the code migrated into unsafe, but in JDK 8
> the copies within a critical region were bound at most copying 1MB:
> native/java/nio/Bits.c#l88 This is inconsistent with Deflater and
> ObjectOutputStream which both allow unlimited arrays and thereby
> critical region sizes.
> In JDK 9 the copies starve the garbage collector in nio Bits too as
> there is no 1MB limit to the copy sizes:
> which came from:
> Perhaps this is a regression not demonstrated due to the testing
> It doesn't seem unreasonable to have the loops for the copies occur
> in 1MB chunks but JDK-8149596 lost this and so I'm confused on what
> the HotSpot stand point is.
Please file a bug (seems to be a core-libs/java.nio regression?),
preferably with some kind of regression test. Also file enhancements (I
would guess) for the other cases allowing unlimited arrays.
Long TTSP is a performance bug as any other.
> In a way criticals are better than unsafe as they may
> pin the memory and not starve GC, which shenandoah does.
(Region based) Object pinning has its own share of problems:
- only (relatively) easily implemented in region based collectors
- may slow down pause a bit in presence of pinned regions/objects (for
non-concurrent copying collectors)
- excessive use of pinning may cause OOME and VM exit probably earlier
than the gc locker. GC locker seems to provide a more gradual
degradation. E.g. pinning regions typically makes these regions
unavailable for allocation.
I.e. you still should not use it for many, very long living objects.
Of course this somewhat depends on the sophistication of the
I think region based pinning would be a good addition to other
collectors than Shenandoah too. It has been on our minds for a long
time, but there are so many other more important issues :), so of
course we are eager to see contributions in this area. ;)
If you are interested on working on this, please ping us on hotspot-gc-
dev for implementation ideas to get you jump-started.
More information about the hotspot-dev