RFR: 8219101: Stop using ICStubs for CompiledIC transitions to clean
Erik Österlund
erik.osterlund at oracle.com
Mon Feb 25 14:28:08 UTC 2019
Hi,
Ping.
Thanks,
/Erik
On 2019-02-18 13:01, 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/
>
> Testing: mach5 hs-tier1-5.
>
> Thanks,
> /Erik
More information about the hotspot-dev
mailing list