RFR (S/M): 8012547: Reclamation of flushed methods can be slow

[Christian Thalinger]

Looks good.  One minor comment:

src/share/vm/runtime/sweeper.hpp:

   static void notify(nmethod* nm) {
     // Perform a full scan of the code cache from the beginning.  No
     // need to synchronize the setting of this flag since it only
     // changes to false at safepoint so we can never overwrite it with false.
-     _rescan = true;
+     _resweep = true;
   }

Could you change the comment to not only talk about a full scan but also the sweeping?

-- Chris

On Apr 18, 2013, at 6:09 AM, Nils Eliasson <nils.eliasson at oracle.com> 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.