OOM without a full GC with G1GC

[Roman Kennke]

Am 08.05.2017 um 09:51 schrieb Per Liden:
> Hi,
>
> On 2017-05-06 00:12, nezih yigitbasi wrote:
>> This JVM runs the Presto distributed SQL engine and some threads use
>> native codecs to read from compressed files (I see from our logs that
>> GZIP is being used). Is it possible that JNI threads delay the full GC
>> and the JVM hits the GCLockerRetryAllocationCount?
>
> Yes, heavy use of JNI GetPrimitiveArrayCritical (used by libzip) can
> cause allocation starvation and premature OOM, which might be what
> you're seeing here. Try set GCLockerRetryAllocationCount to a big
> number. That would at least help avoid the premature OOM.

You might want to give Shenandoah GC a try. Not only is it specifically
targeted at low pause times with large heaps, it also does not hold back
GC because of JNI critical regions..

https://wiki.openjdk.java.net/display/shenandoah/Main

Best regards, Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20170508/b96de93a/signature.asc>