Let me put following comment in eatMetaspaceAndHeap method:
@Override
public void eatMetaspaceAndHeap(float targetMemoryUsagePercent) {
+ // Metaspace should be filled before Java Heap to prevent unexpected
OOME
+ // in the Java Heap while filling Metaspace
+ eatenMetaspace = eatMetaspace(targetMemoryUsagePercent);
eatenMemory = eatHeapMemory(targetMemoryUsagePercent);
- eatenMetaspace = eatMetaspace(targetMemoryUsagePercent);
}
Leonid
On 05.10.2016 14:10, Alexander Kulyakhtin wrote:
Hi Leonid,
(not a reviewer) Maybe a comment explaining why the metaspace should
be eaten first could be useful?
Otherwise it might be not clear that the order of the methods is
important and the methods can be unintentionally swapped again?
Best regards,
Alexander
----- Original Message -----
From: leonid.mes...@oracle.com
To: serviceability-dev@openjdk.java.net
Cc: hotspot-gc-...@openjdk.java.net
Sent: Tuesday, October 4, 2016 11:26:33 AM GMT +03:00 Iraq
Subject: RFR(XS): 8155570: serviceability/tmtools/jstat/GcTest02.java
fails with parallel GC
Hi
Could you please review following fix:
Webrev: http://cr.openjdk.java.net/~lmesnik/8155570/webrev.00/
<http://cr.openjdk.java.net/%7Elmesnik/8155570/webrev.00/>
Bug: https://bugs.openjdk.java.net/browse/JDK-8155570
Test filled java heap up to 70% and then failed with OOME in the java
heap while filling metaspace. I updated test to fill metaspace first
and then to fill heap. Also I added more info about unexpected OOME.
I verified locally that OOME doesn't happen now on my local host with
all GC. Unfortunately I haven't run it yet in the lab because of infra
outage. Also test still might fail because of jcmd/jstat crash caused by
<https://bugs.openjdk.java.net/browse/JDK-8166364>
JDK-8166364 <https://bugs.openjdk.java.net/browse/JDK-8166364> fatal
error: acquiring lock DirtyCardQ_CBL_mon/16 out of order with lock
Module_lock/6 -- possible deadlock
Leonid