Request review: 4360113: Evict nmethods when code cache gets full
eric.caspole at amd.com
Thu Jan 14 14:20:42 PST 2010
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
- 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.
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
> Eric Caspole wrote:
>> Hi Vladimir,
>> I updated the webrev using an enum for that parameter as we
>> discussed today.
>> 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/
>>> You need to specify .jar file you want to process, for example:
>>> 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".
More information about the hotspot-compiler-dev