RFR (XS) JDK-8164482,[REDO] G1 does not implement millis_since_last_gc which is needed by RMI GC

Joseph Provino joseph.provino at oracle.com
Thu Sep 15 17:16:51 UTC 2016

Creating a jtreg test is more complicated than expected because 
sun.rmi.transport.GC is not public.

Reflection could be used or millis_since_last_gc() could be made 
accessible through WhiteBox.

But Dima says the correct way is a test in GTest format for 
But this case requires an initialized VM, and for the time being our 
GTest mechanism doesn't support such cases, it supports only native unit 

So I'd like to file an RFE for a regression test and push the fix for 

Could I get two reviews for this?





On 9/8/2016 10:18 AM, Thomas Schatzl wrote:
> Hi Joe,
> On Thu, 2016-09-08 at 09:54 -0400, Joseph Provino wrote:
>> Latest Webrev:  http://cr.openjdk.java.net/~jprovino/8164482/webrev.0
>> 1
>> JDK-8164482 [REDO] G1 does not implement millis_since_last_gc which
>> is needed by RMI GC
>> Tests:  JPRT.  Also, I put in a log message for testing.  It calls
>> millis_since_last_gc() before each collection.  This will be removed
>> before pushing.  The messages printed show millis since last gc
>> always >= 0 and the warning message is never printed.
>> thanks.
>    I think this looks good. Could you also write a small test that calls
> sun.misc.GC.maxObjectInspectionAge() (or wherever it has been moved in
> jdk9, it should be in sun.rmi.transport now?) to verify that no gc
> returns 0 after a GC (and some artificial pause)?
> Using whitebox to issue full/young gcs directly should make that fairly
> easy.
> Thanks,
>    Thomas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20160915/b6d41c8e/attachment.htm>

More information about the hotspot-gc-dev mailing list