for review (M): 6863023: need non-perm oops in code cache for JSR 292

[John Rose]

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  
java.nio.charset.CoderResult.UNDERFLOW.

-- John