RFR (S/M): 8012547: Reclamation of flushed methods can be slow
Vladimir Kozlov
vladimir.kozlov at oracle.com
Thu Apr 18 10:30:00 PDT 2013
Nils,
this looks good.
Thanks,
Vladimir
On 4/18/13 6:09 AM, Nils Eliasson wrote:
> Hi!
>
> I have another fix to the code cache sweeper and flushing that needs a
> review.
>
> The major change is to remove a check in scan_stacks that stops the
> sweeper when the cache is getting full. The normal mode is to sweep and
> record if any change has happened that require another sweep. This check
> stops the sweeper early causing some methods that are speculatively
> disconnected to stay so for an unnecessary long time sometimes causing
> unnecessary new flushes.
>
> Also some refactoring
> - remove state variable _do_sweep that was unnecessary. It marked if a
> sweep was active or not, but just a duplicate way of checking if any
> methods are being sweept (nmethodsweeper::current != NULL).
> - rename _rescan to _resweep. When _resweep is set there will be another
> sweep started when the current ends. That sweep will start with a scan,
> but it is not only a scan.
> - rename _advise_to_sweep to _flush_token. Is CASed by the first thread
> that wants to flush and reset by scan_stacks when the flush is finished
> and a proper time has passed.
>
> http://cr.openjdk.java.net/~neliasso/8012547/
> <http://cr.openjdk.java.net/%7Eneliasso/8012547/>
> https://jbs.oracle.com/bugs/browse/JDK-8012547
>
> Thanks,
> Nils E.
More information about the hotspot-compiler-dev
mailing list