Request review: 4360113: Evict nmethods when code cache gets full

[Tom Rodriguez]

On Jan 14, 2010, at 2:20 PM, Eric Caspole wrote:

> OK, Tom could you comment if the 'manage the ptrs in an external list' is a philosophical point or you really want me to change it. I have been thinking about the pros and cons that occurred to me:

It's purely a space question.  On average there are 12 methods per loaded class so if you have 3000 classes loaded, which really isn't that many, then you have roughly 12 * 3000 * sizeof(void*) of effectively wasted space.  That's 140k in 32 bit or 280k in 64 bit.

tom

> 
> - moving the saved code pointers into an external managed list would keep methodOops same size as now
> - however the saved code field is already almost the last data member in methodOop so I dont think it will disturb access to any other hot data members in that oop, but it will slightly increase the overall perm gen footprint for methodOops. This doesn't seem so bad if we can get to a point where this feature is on by default, but it's not right now.
> 
> - as we discussed earlier, most of the code ptr manipulating code I added is not under the flag, it always does it to minimize the checks on those paths. If the list is maintained externally I would want to change the method ptr manipulating code to be under the flag, since the saved code lookup will take a little longer.
> - sweeper or somebody would need to manage the list of saved code ptrs, I haven't really thought about it yet.
> - methodOop unloading might need to clean up after itself in the list, have to think about this more
> 
> Let me know what you think.
> Thanks,
> Eric
> 
> 
> On Jan 13, 2010, at 4:58 PM, Vladimir Kozlov wrote:
> 
>> Looks good.
>> 
>> On meeting I talked about the next Tom's complain which is not reflected in your final code.
>> I don't know if Tom agree on this.
>> 
>> >>> One thing I don't really like is the new field in methodOop since it makes methodOops larger.  I'd like to avoid doing that if we could, particularly since the field is really only used in extreme cases.  Would it be possible to simply manage a list of these nmethods in the code cache instead?
>> >> Yes, I see what you mean, but I think that would make it all a little more complicated. Such a list would have to be managed on the sweeper side too.   I'll have to think about it more.
>> >
>> > I agree that it's a little more complicated because you have to manage the list but it will end up being localized more I think.
>> >
>> > tom
>> 
>> Thanks,
>> Vladimir
>> 
>> Eric Caspole wrote:
>>> Hi Vladimir,
>>> I updated the webrev using an enum for that parameter as we discussed today.
>>> http://cr.openjdk.java.net/~ecaspole/4360113/webrev.03/
>>> Eric
>>> On Jan 8, 2010, at 11:34 AM, Vladimir Kozlov wrote:
>>>> Eric Caspole wrote:
>>>>> Could you send me a cmd line for trying CompileTheWorld? I don't think I am doing it right, I tried:
>>>>> $ time /home/ecaspole/jdk1.6.0_16/bin/java -XX:+CompileTheWorld -XX:+PrintCompilation  -version
>>>>> VM option '+CompileTheWorld'
>>>>> VM option '+PrintCompilation'
>>>>> CompileTheWorld : Compiling all classes in /home/ecaspole/jdk1.6.0_16/jre/lib/resources.jar
>>>> 
>>>> You need to specify .jar file you want to process, for example:
>>>> 
>>>> -Xbootclasspath/p:/home/ecaspole/jdk1.6.0_16/jre/lib/rt.jar
>>>> 
>>>> And eith -version VM will exit, use -showversion.
>>>> 
>>>>>> Actually, I don't understand why it is need to be atomic.
>>>>>> It is always one direction change:
>>>>>> compiler broker change it to "false" and
>>>>>> only sweeper (at safepoint) change it to "true".
>>>>> What I was going for here is that when there are multiple compiler threads, probably more than one will hit the full condition more at less at once. I want to get the flag set and let me know if I actually set it. If I won to set it, I will run the cleaning op, otherwise I will go back and block and wait on the compile queue until the flag gets set back to true.
>>>> 
>>>> I see. I still want to use "1" instead of "true" for initialization
>>>> since in all places you use "1" or "0".
>>>> 
>>>> Vladimir
>>>> 
>> 
> 
>