methodDataOops

[steve goldman]

John Rose wrote:
> On Jan 31, 2008, at 11:25 AM, steve goldman wrote:
> 
>> it seems like creating an MethodDataKlass to enable tracing rather 
>> than specialized C++ code like we have for other jvm structures seems 
>> like overkill.
> 
> Here's another reason to put them in the heap:  You want to garbage 
> collect one when its method goes away due to class unloading.

I was trying to say that this is something that is easier. Although it 
would seem by the evidence of the bug Ramki was talking about maybe not 
quite so simple as we'd like.

> 
> It seems to me that putting metadata in the heap isn't overkill, it's 
> just how we do things.

Well that would be an answer to my question and that answer would be 
more style and not it must be done that way. To some extent I think the 
style was dictated by the name. Thinking of it as MethodData makes it 
seems like metadat for methodOops and more naturally in the Java heap. 
Thinking of it as say ProfileData or ExecutionHistory and the direct 
connection seems more tenous especially when you think of this data 
being specialized per call site and not per method.

So here's a followup question. If this data were in the C heap does this 
make a difference as far as the CI and how the data would be accessed?

> 
> I'm obviously missing your point:  I don't know exactly what specialized 
> C++ code you're referring to (outside of the Oop/Klass pattern),
> unless it's things like what's in the SystemDictionary.  It seems to me 
> that the SystemDictionary pattern is complicated enough already.
> You have to walk it for GC roots, and then also manually clean up the 
> C++ structures when the GC frees something.
> Every time I read the class loader constraint code or symbol table stuff 
> or dependency indexer the manual allocations and deletions scare me.

It was probably too obvious, things like frames, JavaThreads, nmethods, 
etc. have to be taught to the GC outside the Oop/Klass pattern. They all 
have oops in them too but they don't have to be oops though they could 
and I guess in Monty they might be. As far as things going away when a 
class unloads it doesn't really seem a lot more different than how an 
nmethod goes away at the same time and doesn't seem particularly scary.

> 
> I think it's less buggy and complex to bite the bullet and describe 
> chunks of data to the GC (using Oop/Klass)
> and then let the GC manage the metadata graph.

I'm not convinced that in this case it actually was. IIRC there were a 
number of interpreter bugs caused by holding mdo's in registers across 
safepoints that would have been non-bugs had the MDO's been MD's.

In any case as I said I wasn't proposing change it was just something 
I've wondered about.


-- 
Steve