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

[Eric Caspole]

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:

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