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

Peter Levart peter.levart at gmail.com
Fri Mar 2 09:07:53 UTC 2018

Hi Sherman,

On 03/02/18 03:20, David Holmes wrote:
> Also this:
> 195         private Map<Integer,WeakReference<CoderResult>> 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 concurrent threads to result in NPE-s.

If you do replace it with a volatile, you should also load the field 
into local variable just once (although not strictly necessary for 


  193     private abstract static class Cache {
  197 *protected* abstract CoderResult create(int len);

the abstract method is protected, but the implementations:

  217         = new Cache() {
  218 *public* CoderResult create(int len) {
  219                     return new CoderResult(CR_MALFORMED, len);
  220                 }};

...are public.

Since you are dealing with private nested class, all create() methods 
could be package-private. Less words to write and read...

Regards, Peter

More information about the core-libs-dev mailing list