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

[Joseph Provino]

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 
G1CollectedHeap::millis_since_last_gc().
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 
tests.

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

Could I get two reviews for this?

https://bugs.openjdk.java.net/browse/JDK-8164482

http://cr.openjdk.java.net/~jprovino/8164482/webrev.01

Thanks.

joe


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.org/pipermail/hotspot-gc-dev/attachments/20160915/b6d41c8e/attachment.htm>