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