for review (M): 6863023: need non-perm oops in code cache for JSR 292
John.Rose at Sun.COM
Sat Sep 12 10:16:07 UTC 2009
Here is an updated webrev. The operations of the GC relative to the
code cache are much more explicit now:
This one (a) is about to pass JPRT, (b) does pass unit tests like
GCBasher and GCOld in various stress modes, (c) does run various JRuby
+invokedynamic benchmarks successfully. I've been routinely testing
with all four GC modes.
I think it's ready to go back, as soon as a GC person verifies that my
GC-related refactorings are reasonable. The other parts of the code
are already reviewed.
P.S. The two stress modes I've mostly used are are
ScavengeRootsInCode=2 and ScavengeRootsInCode=2 with -Xcomp. These
modes tend to create a lot of nmethods with non-perm oops embedded.
The default I'm going to push is ScavengeRootsInCode=0. When
invokedynamic is turned on by default, the flag will change to
ScavengeRootsInCode=1, which means non-perm oops will be inserted into
code for invokedynamic, but not for user-written Java code.
More information about the hotspot-gc-dev