RFR JDK-8187653: Lock in CoderResult.Cache becomes performance bottleneck

Claes Redestad claes.redestad at oracle.com
Fri Mar 2 22:52:59 UTC 2018

One less (benign) race - and possibly more efficient, too :-)

If we really worry about the startup costs here, we could make it so 
that the three Cache classes
themselves aren't loaded until someone actually has a need for them:



On 2018-03-02 21:02, Xueming Shen wrote:
> To follow Claes's suggestion to make the CoderResult.Cache.cache field 
> final and allocate early.
> issue: https://bugs.openjdk.java.net/browse/JDK-8198966
> webrev: http://cr.openjdk.java.net/~sherman/8198966/webrev/
> Thanks,
> -Sherman

More information about the core-libs-dev mailing list