RFR (S/M): 8012547: Reclamation of flushed methods can be slow
Nils Eliasson
nils.eliasson at oracle.com
Thu Apr 18 06:09:30 PDT 2013
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