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:
http://cr.openjdk.java.net/~redestad/scratch/coderresult_cache.00
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
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
writes observed from concu
On 2/03/2018 12:09 PM, Xueming Shen wrote:
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
exa
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
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: http://cr.o
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.
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 final.
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
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
mechanism
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
11 matches
Mail list logo