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

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:

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

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

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

Hi Sherman, On 03/02/18 03:20, David Holmes wrote: Also this: 195 private Map cache = null; should now be volatile. Either that, or you should load the 'cache' field only once per method call into a local variable unless you want reorderings of reads and

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

On 3/1/18, 4:35 PM, David Holmes wrote: When you replace synchronized code with concurrent data structures you introduce race conditions that are precluded in the synchronized code. These need to be examined carefully to ensure they are safe. For example, whenever you replace a HashMap with a

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

Hi Sherman, On 24/02/2018 11:26 AM, Xueming Shen wrote: Hi, Please help review the proposed change to remove the potential performance bottleneck in CoderResult caused by the "over" synchronization the cache mechanism. issue: https://bugs.openjdk.java.net/browse/JDK-8187653 webrev:

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

On 01/03/2018 20:10, Xueming Shen wrote: Right, they all should be final. webrev has been updated accordingly. Thanks, it looks okay now.

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

On 03/01/2018 12:00 PM, Alan Bateman wrote: On 01/03/2018 19:42, Roger Riggs wrote: Hi Sherman, Looks to be a good fix with predictable behavior and performance. +1, Roger I assume malformed4 and unmappable4 should be final, the XXXCache fields too. -Alan Right, they all should be

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

On 01/03/2018 19:42, Roger Riggs wrote: Hi Sherman, Looks to be a good fix with predictable behavior and performance. +1, Roger I assume malformed4 and unmappable4 should be final, the XXXCache fields too. -Alan

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

Hi Sherman, Looks to be a good fix with predictable behavior and performance. +1, Roger On 2/23/2018 8:26 PM, Xueming Shen wrote: Hi, Please help review the proposed change to remove the potential performance bottleneck in CoderResult caused by the "over" synchronization the cache

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

Hi, Please help review the proposed change to remove the potential performance bottleneck in CoderResult caused by the "over" synchronization the cache mechanism. issue: https://bugs.openjdk.java.net/browse/JDK-8187653 webrev: http://cr.openjdk.java.net/~sherman/8187653/webrev Notes: While the