RFR (S/M): 8012547: Reclamation of flushed methods can be slow
Nils Eliasson
nils.eliasson at oracle.com
Wed Apr 24 07:16:25 PDT 2013
This is the correct webrev for the RFR I sent a moment ago:
http://cr.openjdk.java.net/~neliasso/8012547/webrev.04/
<http://cr.openjdk.java.net/%7Eneliasso/8012547/webrev.04/>
//Nils
On 2013-04-18 15:09, 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