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

[Y.S.Ramakrishna at Sun.COM]

Hi John --

On 09/08/09 01:38, John Rose wrote:
> I have sufficient reviews for 6863023 as of webrev.03, but the GC 
> interactions are (sigh) more subtle than I anticipated, and I want to 
> get it right.
> 
> Here is a fresh layer of changes, required to ensure that strong-root 
> nmethods get scavenged exactly once.
>   http://cr.openjdk.java.net/~jrose/6863023/diff-02-to-03 (these 
> specific changes)

I looked at the above and the changes look fine to me. I had a question
about the # of active nmethods that get thus linked into your marked
list. Is this a fairly small number? Or fairly large?

If large, then perhaps an alternative implementation might be worth
considering where each worker thread maintains its own local list
(head) to which it links the just claimed nmethod rather than to the
single global list. This would reduce contention for a global head
and would avoid one CAS per nmethod  claimed.
Then, in the epilogue (which would have to be appropriately sited
in the per-worker marking code), the workers could run down their
local lists in parallel, thus avoiding a serial bottlebeck.
As I said, it depends on the expected volume of these active
nmethods. Perhaps they are sufficiently small (even as # active
threads in the application scales up) for this not to become
a scalability issue in the future?

>   http://cr.openjdk.java.net/~jrose/6863023/webrev.03 (full webrev)
> 
> These changes fix some double-tracing bugs, but they are not correct.  
> However, they are not right yet.  What I'm asking for now is (a) further 
> advice for structuring the nmethod-walking code correctly, and (b) help 
> spotting bugs.

Any hints on the kinds of bugs you may be seeing? My first overview of
the structure of yr changes looks fine, but i will do a second, more
careful, pass to see if i can spot any potential issues.

later.
-- ramki

> 
> -- John