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