Hello, I see some strange scalability problem in an application which uses a few exernal Charsets which are provided by ServiceLoader. When I check the code for Charset.forName()/lookup() I can the 2-entry LRU cache for charsets, and if those caches do not find the charset, it will check standard, extended and loaded charsets.
The later function is here: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/42770c335bf7/src/java.base/share/classes/java/nio/charset/Charset.java#l341 And it uses ServiceLoader.load() on each lookup. This is unfortunate as it creates a new ServideLoader instance which in turn has its own (empty) service provider cache. So every time a extended charset is loaded (or an unknown charset is requested) it has to parse all the manifests. But what it is even worse, it also has to actually instantiate the found provider (again), so in some cases that provider can also not cache. Do I read the code correct? I think a quick fix would be to hold onto the ServiceLoader. Since it is initialized with the System classloader, there is no need to have a new one on each load. It migh also be worth considerung another 2-level LRU cache inside lookupViaProviders. I am not sure if a reload would be needed for that kind of system serviceloader? Here is a Java7 stacktrace, I think it has'nt changed much in Java9: java.lang.Thread.State: RUNNABLE at sun.misc.ASCIICaseInsensitiveComparator.isUpper(ASCIICaseInsensitiveComparator.java:89) at sun.misc.ASCIICaseInsensitiveComparator.toLower(ASCIICaseInsensitiveComparator.java:93) at sun.misc.ASCIICaseInsensitiveComparator.compare(ASCIICaseInsensitiveComparator.java:48) at sun.misc.ASCIICaseInsensitiveComparator.compare(ASCIICaseInsensitiveComparator.java:36) at java.util.TreeMap.put(TreeMap.java:545) at sun.nio.cs.AbstractCharsetProvider.put(AbstractCharsetProvider.java:84) at sun.nio.cs.AbstractCharsetProvider.charset(AbstractCharsetProvider.java:98) - locked <0x00002b0df808c1e0> (a sun.nio.cs.ext.ExtendedCharsets) at sun.nio.cs.ext.ExtendedCharsets.<init>(ExtendedCharsets.java:349) at sun.reflect.GeneratedConstructorAccessor398.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) >>at java.lang.Class.newInstance(Class.java:374) at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:373) at java.util.ServiceLoader$1.next(ServiceLoader.java:445) at java.nio.charset.Charset$1.getNext(Charset.java:357) at java.nio.charset.Charset$1.hasNext(Charset.java:370) at java.nio.charset.Charset$2.run(Charset.java:413) at java.nio.charset.Charset$2.run(Charset.java:411) at java.security.AccessController.doPrivileged(Native Method) >>at java.nio.charset.Charset.lookupViaProviders(Charset.java:410) at java.nio.charset.Charset.lookup2(Charset.java:487) at java.nio.charset.Charset.lookup(Charset.java:475) at java.nio.charset.Charset.isSupported(Charset.java:517) at sun.nio.cs.StreamDecoder.forInputStreamReader(StreamDecoder.java:68) at java.io.InputStreamReader.<init>(InputStreamReader.java:100) In the specific case it also looks like no thread local decoder was used, but I havent looked into that, yet. Gruss Bernd
