Here is the original message from Tony:
Hi Leonid,
I hope you are well. Here's the list of the changes (I'm copying them
from the CR) and how you can test each:
* a GC Locker-induced GC will now do an evacuation pause, instead of a
Full GC : you can run a test that does GC Locker-induced GCs (I used
GCLockerTest from my GC test suite ; let me know if you'd like me to
tell you how to get a copy) - before, you'll see G1 doing Full GCs, now
it should do standard evacuation pauses (the correct behavior).
* I updated the verbosegc / PrintGCDetails code to only show
"(System.gc())" when a GC was really caused by a System.gc(), before
"(System.gc())" would also appear if the GC was GC Locker-induced:
again, that's easy to test: with your favorite GC locker test you should
not see System.gc()'s appearing (unless of course the GC is caused by
System.gc(); maybe run with +DisableExplicitGC to eliminate that
possibility)
* G1 now observes ExplicitGCInvokesConcurrent where because it didn't :
run any test that does explicit Full GCs (say _213_javac) with
+ExplicitGCInvokesConcurrent set to see what the difference in behavior is
* G1 now also observes GCLockerInvokesConcurrent : maybe run your
favorite GC Locker test with +GCLockerInvokesConcurrent to see what the
difference in behavior is
* And, IIRC, if +DisableExplicitGC was set, jmap induced GCs (with, say,
jmap -histo:live) would be ignored.
The above are the changes to G1's behavior. The rest of the changes were
basically fixed to support the above changes. Let me know if I can help
further.
Hi Leonid,
I hope you are well. Here's the list of the changes (I'm copying them
from the CR) and how you can test each:
* a GC Locker-induced GC will now do an evacuation pause, instead of a
Full GC : you can run a test that does GC Locker-induced GCs (I used
GCLockerTest from my GC test suite ; let me know if you'd like me to
tell you how to get a copy) - before, you'll see G1 doing Full GCs, now
it should do standard evacuation pauses (the correct behavior).
* I updated the verbosegc / PrintGCDetails code to only show
"(System.gc())" when a GC was really caused by a System.gc(), before
"(System.gc())" would also appear if the GC was GC Locker-induced:
again, that's easy to test: with your favorite GC locker test you should
not see System.gc()'s appearing (unless of course the GC is caused by
System.gc(); maybe run with +DisableExplicitGC to eliminate that
possibility)
* G1 now observes ExplicitGCInvokesConcurrent where because it didn't :
run any test that does explicit Full GCs (say _213_javac) with
+ExplicitGCInvokesConcurrent set to see what the difference in behavior is
* G1 now also observes GCLockerInvokesConcurrent : maybe run your
favorite GC Locker test with +GCLockerInvokesConcurrent to see what the
difference in behavior is
* And, IIRC, if +DisableExplicitGC was set, jmap induced GCs (with, say,
jmap -histo:live) would be ignored.
The above are the changes to G1's behavior. The rest of the changes were
basically fixed to support the above changes. Let me know if I can help
further.
- relates to
-
JDK-6944166 G1: explicit GCs are not always handled correctly
- Closed