RFR: 8003246: Add Supplier to ThreadLocal

[Vitaly Davidovich]

Understood - I'm just trying to make sure I don't have the wrong mental
model of this in my mind.  Taking pathology aside (e.g. code cache is full
when time to recompile, poor tiering interaction, etc), I'd expect the fast
inlined path to be restored assuming call site type profile (of the ones we
care about) doesn't change after other subclasses are loaded.  Would be
good if someone can correct that if it's inaccurate.  Apologies if this is
slightly hijacking the thread, but it's Remi's fault :).

Sent from my phone
On Dec 6, 2012 7:03 AM, "Doug Lea" <dl at cs.oswego.edu> wrote:

> On 12/06/12 06:56, Vitaly Davidovich wrote:
>
>> Doug,
>>
>> When you see the fast to slow ThreadLocal transition due to class loading
>> invalidating inlined get(), do you not then see it get restored back to
>> fast
>> mode since the receiver type in your call sites is still the monomorphic
>> ThreadLocal (and not the unrelated subclasses)? Just trying to understand
>> what
>> Rémi and you are saying.
>>
>>
> The possible outcomes are fairly non-deterministic, depending
> on hotspot's mood about recompiles, tiered-compile interactions,
> method size, Amddahl's law interactions, phase of moon, etc.
>
> (In j.u.c, we have learned that our users appreciate things
> being predictably fast enough rather than being
> unpredictably sometimes even faster but often slower.
> So when we see such cases, as with ThreadLocal, they get added
> to todo list.)
>
> -Doug
>
>
>
>
>