review(XS): 7145345: Code cache sweeper must cooperate with safepoints

[Tom Rodriguez]

On Feb 14, 2012, at 5:40 PM, Igor Veresov wrote:

> 
> 
> On Tuesday, February 14, 2012 at 4:45 PM, Tom Rodriguez wrote:
>>> So, would the following solution seem reasonable to you:
>>> http://cr.openjdk.java.net/~iveresov/7145345/webrev.01/
>> 
>> Structurally that looks pretty reasonable. NmethodSweepFraction is an advertised flag so we'd have to silently ignore it instead of rejecting it. But for 7u4 it might be best to just increase the NmethodSweepFraction and add a safepoint check in the loop instead of introducing a new flag that will likely require some more tuning. 256 seems rather low and I'd be concerned about the sweeper getting too far behind since it has more work to do with tiered. With tiered we may need to reconsider how the sweeper does its work.
>> 
> You mean we should just statically set it to another value? Like, say 40?
> 
> The problem with the fraction is that it never guarantees the time we're going to starve compilation. Moreover this time changes as we add new methods to the code cache while sweeping is in progress. So I have no clue really what to set it to. I mean setting it statically seems wrong…

The whole scheme is pretty ad hoc but for the most part it has worked ok.  Maybe we should simply put an upper limit on the number of nmethods that we'll process in a sweep.  So the fraction keeps on spreading the work out but we also bound the wait.  If there are relatively few nmethods there's no point in doing them all in a single sweep.

tom

> 
> igor
>