RFR: 8219101: Stop using ICStubs for CompiledIC transitions to clean

Per Liden per.liden at oracle.com
Mon Feb 18 14:40:36 UTC 2019


On 02/18/2019 01:01 PM, Erik Österlund wrote:
> Hi,
> 
> When transitioning CompiledICs to clean, we sometimes need to use 
> transitional states (using JIT-compiled ICStubs).
> The trick is that today when we clean ICs, we atomically and logically 
> write NULL to the data section, and set the destination to some resolve 
> stub. In reality, the NULL gets translated to Universe::non_oop_word. 
> But the point is that in order to set both data and destination 
> atomically, we use an ICStub.
> 
> ...but we don't need to set them both.
> 
> When the inline cache is cleaned, the data part is no longer relevant, 
> and could really be set to any nonsense value, as long as subsequent 
> transitions away from that cleaned inline cache 
> (monomorphic/interpreted) uses a transitional state to do so.
> I suspect that at some point in time, when inline caches pointed at oops 
> in perm gen or something, it was crucial that the data part of the 
> inline cache made sense to the GC. This is not the case today, and we 
> can just ignore the value pretending it doesn't exist instead.
> 
> The benefit with deferring the use of transitional state to when someone 
> performs a subsequent transition away from clean (set_to_monomorphic), 
> is that all code paths where cleaning inline caches fail can be removed. 
> This in particular simplifies the sweeper and ZGC nmethod unloading 
> code, that needs to handle failures in inline cache cleaning due to 
> running out of ICStubs forcing us to trigger safepoints to refill IC 
> stubs. It should also reduce the overall number of safepoints due to 
> running out of ICStubs.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8219101
> 
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8219101/webrev.00/

Not a complete review, but the ZGC change looks awesome ;)

/Per

> 
> Testing: mach5 hs-tier1-5.
> 
> Thanks,
> /Erik


More information about the hotspot-dev mailing list