for review (M): 6863023: need non-perm oops in code cache for JSR 292
John.Rose at Sun.COM
Thu Aug 27 11:40:12 PDT 2009
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?
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
More information about the hotspot-gc-dev