[9] RFR(S): 8136458: Remove "marked for reclamation" nmethod state

[Nils Eliasson]

Hi,

Was it the move to a dedicated sweeper thread that make this possible? 
When the compiler threads swept the code cache, it was done in parts, 
and then we had to keep the nmethods as marked-for-reclaation until a 
full sweep was completed. Am I right? Then this makes perfect sense.

Looks good,
Nils

On 2016-03-18 10:22, Tobias Hartmann wrote:
> Hi,
>
> please review the following patch.
>
> https://bugs.openjdk.java.net/browse/JDK-8136458
> http://cr.openjdk.java.net/~thartmann/8136458/webrev.00/
>
> The sweeper removes zombie nmethods only after they were "marked for reclamation" to ensure that there are no inline caches referencing the zombie nmethod. However, this is not required because if a zombie nmethod is encountered again by the sweeper, all ICs pointing to it were already cleaned in the previous sweeper cycle:
>
> alive -> not-entrant/unloaded (may be on the stack)
> cycle 1: not-entrant/unloaded -> zombie (may be referenced by ICs)
> cycle 2: zombie -> marked for reclamation
> cycle 3: marked for reclamation -> flush
>
> In each cycle, we clean all inline caches that point to not-entrant/unloaded/zombie nmethods. Therefore, we know already after sweeper cycle 2, that the zombie nmethod is not referenced by any ICs and we could flush it immediately.
>
> I removed the "marked for reclamation" state. The following testing revealed no problems:
> - JPRT
> - RBT with hotspot_all and -Xcomp/-Xmixed
> - 100 iterations of Nashorn + Octane with -XX:StartAggressiveSweepingAt=100/50 -XX:NmethodSweepActivity=500/100
>
> Thanks,
> Tobias