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