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
correctness).
Also:
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