review(XS): 7145345: Code cache sweeper must cooperate with safepoints
Igor Veresov
igor.veresov at oracle.com
Tue Feb 14 17:40:14 PST 2012
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...
igor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120214/3de6507b/attachment.html
More information about the hotspot-compiler-dev
mailing list