methodDataOops

[steve goldman]

(I've moved this to the OpenJDK list since it was only an accident I 
used the internal list for the original question...)

Y Srinivas Ramakrishna wrote:
> Unfortunately your comment about escape velocity is true.
>>From what i recall, MDO's should be treated as holding weak references,
> but currently are not. The exact details now elude me but this causes
> classes to be held longer in the heap than they need to, causing
> perm gen bloat. See 4957990 which has never risen sufficiently
> in our priority list. I think i still have a workspace where
> I made changes to let MDO's be traced weakly. I can't recall
> why, but this turned out to be quite convoluted. Anything to
> simplify that would be very nice, including perhaps even moving
> them out of the Java heap if it made tracing them weakly easier.
> 
> I'll try to reconstruct the history here as soon as i have attended
> to a couple of other urgent matters and then will post a more
> sensible note describing what made 4957990 more convoluted than
> we'd have wanted.

Chuck had told me about the weak reference issue which I wasn't aware 
of. Of course I realized that they contain oops and had to be traced but 
it seems like creating an MethodDataKlass to enable tracing rather than 
specialized C++ code like we have for other jvm structures seems like 
overkill.

I do see how it makes it simpler to just find the MDO's from the 
methodOop rather than by some more indirect means. I wasn't really 
planning on making any changes (at this point) but wondered if there was 
something that flat out forced this path since keeping jvm data that has 
no visibility to Java in the Java heap puts needless pressure on the 
heap and I wondered if I was missing something obvious.

> 
> -- ramki
> 
> ----- Original Message -----
> From: John Rose <John.Rose at Sun.COM>
> Date: Thursday, January 31, 2008 10:33 am
> Subject: Re: methodDataOops
> To: Steve.Goldman at Sun.COM
> 
> 
> 
>> It needs to contain oops, so it must be traced.
>>
>> That at least establishes an escape velocity required to exit the  
>> Java heap.
>>
>> -- John
>>
>>
>>
>> On Jan 30, 2008, at 11:57 AM, steve goldman wrote:
>>
>>> So here's a question I've meant to ask many times. Why is the  
>>> methodDataOop stored in the Java heap instead of C heap? It comes  
>>> up in my mind again because as I'm toying with compilation policy  
>>> changes and I'm looking at making a class to manage compilation  
>>> history which obviously similar to the MDO and could be subsumed  
>>> into it but it doesn't seem to deserve placement in the Java heap.
>>>
>>> -- 
>>> Steve
> 


-- 
Steve