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

John Rose John.Rose at Sun.COM
Tue Sep 8 22:23:42 UTC 2009

Responses below...

-- John  (on my iPhone)

On Sep 8, 2009, at 12:19 PM, Y.S.Ramakrishna at Sun.COM wrote:

> 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.
>> (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?

It should be a small number compared to the number of scavenged  
objects. It is about one NM ref per live stack frame, and for many- 
threaded apps. there will be many repeat refs.

> 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?

Yes I think the number of queue events will be very small, rarely more  
than 1000.
>> (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.

Please look at my last JPRT job.  There were a lot of failures so I  
think I did something "obviously" wrong!

Thanks very much!

> later.
> -- ramki
>> -- John

More information about the hotspot-gc-dev mailing list