RFR(XS): 8155570: serviceability/tmtools/jstat/GcTest02.java fails with parallel GC

[Leonid Mesnik]

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.mesnik at oracle.com
> To: serviceability-dev at openjdk.java.net
> Cc: hotspot-gc-dev at 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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20161005/c5a8c1b9/attachment.htm>