RFR: 8214338: Move IC stub refilling out of IC cache transitions
erik.osterlund at oracle.com
Tue Nov 27 21:29:34 UTC 2018
Thank you for reviewing this.
On 2018-11-27 19:07, dean.long at oracle.com wrote:
> Hi Erik. Can you explain why you removed the pre-allocated "next
> stub"? I guess it was no longer necessary? If so, then you should
> update the "always has sentinel" comment in is_empty.
Updated. Indeed, the sentinel no longer serves a purpose so I removed
it. Found some more traces of the sentinel that I removed in the last
> In your guarantee messages, some use "should not fail" and some use
> "should never fail". It's not a big deal but maybe they should be the
> You introduced a couple of infinite loops. Are we guaranteed to exit
> these loops eventually? Is there an upper bound on how many iterations
> are needed?
In my latest webrev I removed some unnecessary set_to_clean() where IC
caches are already is_clean(). With that in place, there should be
global progress guarantees and a single IC stub in the buffer should be
all you really "need". Although, you might want more. In fact, I'm
questioning if the 10K size buffer is big enough today, but I'll leave
that for another day.
> The rest looks good.
> On 11/27/18 5:00 AM, Erik Österlund wrote:
>> IC stub refilling currently requires a safepoint operation. When done
>> right at the point where an CompiledIC is about to get patched to a
>> transitional state using an IC stub, locks may already be held,
>> causing a bunch of locking issues - especially for concurrent class
>> unloading. Therefore, the IC stub refilling ought to be moved out so
>> that IC cache cleaning and transitioning may be done without any
>> safepoints, and the locks in the path ought to not perform safepoint
>> This is implemented by allowing IC transitions to fail when they
>> require IC stubs, and we run out of them. This propages back to a
>> higher level where IC stubs are refilled after having released the IC
More information about the hotspot-dev