RFR: 8202184: Reduce time blocking the ClassSpecializer cache creating SpeciesData
claes.redestad at oracle.com
Wed Apr 25 08:11:32 UTC 2018
On 2018-04-24 21:01, Paul Sandoz wrote:
> This looks good.
> Took me a while to understand the interactions: you need to replace not update otherwise there is a race on isResolved (which currently queries multiple state, there is no singular guard here). We could push isResolved into the synchronized block and simplify but every findSpecies call may take a small hit (or there are potentially other ways looking more closely at how ClassSpecializer.Factory initializes state, i.e. a fenced static field write, but we go further down the rabbit hole)
Right, I've been down that hole unsuccessfully and came up with this
'play' (a much nicer word than 'hack'; thanks Peter!) as a means to
escape it. :-)
> I think this might fix some rare and intermittent recursive exceptions from ConcurrentHashMap cache we have been observing, where a collision occurs on keys for recursive updates (rather than for the same key).
I think so, too, but as I've not been able to reproduce any of these
rare intermittent issues locally I've no real evidence to that effect.
More information about the core-libs-dev