<div dir="ltr">Hi Per,<div>I was also thinking about bumping up GCLockerRetryAllocationCount. But, the default value of this parameter is small (2), is that because having a large value for that can have other negative side effects? In other words, how safe is it to increase this number?<br><div><br></div><div>Thanks,</div><div><span style="font-size:12.8px">Nezih</span></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-05-08 2:49 GMT-07:00 Roman Kennke <span dir="ltr"><<a href="mailto:rkennke@redhat.com" target="_blank">rkennke@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Am 08.05.2017 um 09:51 schrieb Per Liden:<br>
> Hi,<br>
><br>
> On 2017-05-06 00:12, nezih yigitbasi wrote:<br>
>> This JVM runs the Presto distributed SQL engine and some threads use<br>
>> native codecs to read from compressed files (I see from our logs that<br>
>> GZIP is being used). Is it possible that JNI threads delay the full GC<br>
>> and the JVM hits the GCLockerRetryAllocationCount?<br>
><br>
> Yes, heavy use of JNI GetPrimitiveArrayCritical (used by libzip) can<br>
> cause allocation starvation and premature OOM, which might be what<br>
> you're seeing here. Try set GCLockerRetryAllocationCount to a big<br>
> number. That would at least help avoid the premature OOM.<br>
<br>
</span>You might want to give Shenandoah GC a try. Not only is it specifically<br>
targeted at low pause times with large heaps, it also does not hold back<br>
GC because of JNI critical regions..<br>
<br>
<a href="https://wiki.openjdk.java.net/display/shenandoah/Main" rel="noreferrer" target="_blank">https://wiki.openjdk.java.net/<wbr>display/shenandoah/Main</a><br>
<br>
Best regards, Roman<br>
<br>
</blockquote></div><br></div>