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