for review (M): 6863023: need non-perm oops in code cache for JSR 292
Thomas.Rodriguez at Sun.COM
Thu Aug 27 12:00:22 PDT 2009
On Aug 27, 2009, at 11:40 AM, John Rose wrote:
> On Aug 27, 2009, at 9:24 AM, Tom Rodriguez wrote:
>> There's a bug in these changes that Christian just tripped across.
>> In drop_scavenge_root_nmethod the next == nm case doesn't does call
>> clear_on_scavenge_root_list or set the link to NULL. You should
>> move that case into the body of the loop so you don't have to
>> duplicate the code.
> Thanks; will fix.
> On Aug 27, 2009, at 9:32 AM, Tom Rodriguez wrote:
>> The scanning twice one is probably caused by an nmethod both being
>> on stack and containing scavengeable oops so it will get scanned
>> during stack walk and again when all the scavengeable nmethods are
>> scanned by marking in a minor collection. There needs to be some
>> marking so it can't get scanned twice.
> Yes. Double scanning may be the root of several other failures. I
> think I'll set a bit on the header of each on-stack nmethod in the
> gc_prologue, and clear it in the gc_epilogue. That way the
> distinction can be made explicit and clear through all GC phases.
> What do you think of that?
Hmm. Having to scan the stacks an extra time seems bad, particularly
since it's only needed during a scavenge because we're treating some
nmethods as strong roots. Can't you just mark the nmethods during the
stack walk and clear it during the gc_epilogue?
> Also, what do you think of setting ScavengeRootsInCode = 1 by
> default, so that the mechanism gets exercised right away, instead of
> waiting for EnableInvokeDynamic to be turned on by default? The
> choice is set SRIC=0 by default (as in webrev) for maximum
> stability, vs SRIC=1 to default in order to start exploring the GC
> bug tail (if any :-) right away. SRIC=1 means that if a static
> final variable contains a non-perm oop, it will still get folded
> into the code. This currently happens for a handful of methods that
> use names like java.nio.charset.CoderResult.UNDERFLOW.
I think we'd want to let it sit in hotspot-comp for a while after that
change to let nightlies shake out any issues. Running a bunch of
tests with it == 1 would probably shake out quite a few of them before
> -- John
More information about the hotspot-gc-dev