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

[Tom Rodriguez]

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  
putback.

tom


>
> -- John