May 2018 - core-libs-dev

[PATCH] regex matcher opt: remove redundant StringBuilder
by Isaac Levy 18 Jul '18

18 Jul '18

(moving this to a separate discussion) --- a/src/java.base/share/classes/java/util/regex/Matcher.java +++ b/src/java.base/share/classes/java/util/regex/Matcher.java @@ -993,13 +993,11 @@ public Matcher appendReplacement(StringBuilder sb, String replacement) { // If no match, return error if (first < 0) throw new IllegalStateException("No match available"); - StringBuilder result = new StringBuilder(); - appendExpandedReplacement(replacement, result); // Append the intervening text sb.append(text, lastAppendPosition, first); // Append the match substitution + appendExpandedReplacement(replacement, sb); - sb.append(result); On Mon, Apr 23, 2018 at 5:05 PM Xueming Shen <xueming.shen(a)oracle.com> wrote: > > > I would assume in case of an exception thrown from appendExpandedReplacement() we don't > want "text" to be pushed into the "sb". > > -sherman Perhaps. Though the behavior under exception is undefined and this function is probably primarily used though the replaceAll API, which wouldn’t return the intermediate sb under the case of exception. My reading of the blame was the temp StringBuilder was an artifact of the api previously using StringBuffer externally. See http://hg.openjdk.java.net/jdk9/dev/jdk/rev/763c564451b3

2 6

Re: RFC: Experiment in accessing/managing persistent memory from Java
by Viswanathan, Sandhya 22 Jun '18

22 Jun '18

Hi Andrew/Jonathan, Thanks a lot for sharing this work. Copying hotspot-compiler-dev to get their feedback as well. Couple of thoughts/observations below: * Supporting ByteBuffer on persistent memory using existing FileChannel and MappedByteBuffer mechanism sounds like a very good idea. * Extending FileChannel.map to take additional parameter to indicate that the ByteBuffer is backed by persistent memory is a small API change. * Adding MappedByteBuffer.force(int from, int to) method on smaller range is very useful in addition to the force() on entire ByteBuffer. * The underlying force0_mapsync() could be implemented in terms of new unsafe APIs which in turn could be intrinsified. The advantage of this is that the unsafe APIs could then be used for other future persistent memory APIs in the JRE. Specifically the following two unsafe APIs would be useful: a) public native void flush(long address, long size); b) public native void storeFence(); storeFence() exists today but doesn't generate any instruction for x86. Wondering if we could have additional boolean parameter to force the sfence generation. * DEFAULT_CACHE_LINE_SIZE is 128 in src/hotspot/cpu/x86/globalDefinitions_x86.hpp whereas actual cache line on the hardware is 64 bytes. This could be the cause for some of performance that you saw with compiler intrinsic vs pure C native. Best Regards, Sandhya RFC: Experiment in accessing/managing persistent memory from Java Andrew Dinn adinn at redhat.com Mon May 21 09:47:46 UTC 2018 I have been helping one of my Red Hat colleagues, Jonathan Halliday, to investigate provision of a Java equivalent to Intel's libpmem suite of C libraries [1]. This approach avoids the significant cost of using the Intel libraries from Java via JNI (or, worse, as a virtual driver for a persistent memory device). Jonathan has modified the JVM/JDK to allow a MappedByteBuffer to be mapped over persistent memory, providing equivalent function to libpmem itself. On top of this he implemented a Java journaled log class providing equivalent functionality to one of the Intel client libs, libpmemlog, built over libpmem. The modified MappedByteBuffer can be configured to use either i) a registered native method or ii) a JIT intrinsic to perform the critical task of cache line writeback i.e. the persistence step (the intrinsic is my contribution). Jonathan's tests compare use of JNI, registered native and intrinsic with an equivalent C program to write a large swathe of records to a journaled log file stored in persistent memory. Performance is worse than C when relying on JNI and significantly better with JVM/JDK support. Indeed, as one might reasonably expect, use of the JIT intrinsic almost completely eliminates writeback costs. The journaled log code, jdk dev tree patch, build instructions, test code plus C equivalent and test results are all available from Jonathan's git repo [2]. For those who do not want to look at the actual code, the README file [3] provides background to use of persistent memory, an overview of the design, and summary details of the test process and results. [1] https://pmem.io/pmdk/ [2] https://github.com/jhalliday/pmem [3] http://github.com://jhalliday/pmem/README.md<http://github.com/jhalliday/pmem/README.md> n.b. Jonathan has experimented with using this same prototype to replace the journaled log used in the Red Hat Narayana transaction manager. It provides a significant improvement on the current disk file based log, both for throughput and latency (the code is not yet available as getting it to work involved some horrible hacking of the build to migrate up to jdk11). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander ________________________________

5 6

Promptly freeing the per-thread cached direct buffers when a thread exits
by Tony Printezis 22 Jun '18

22 Jun '18

Hi all, We recently hit another interesting issue with the NIO thread-local DirectByteBuffer cache. One of our services seems to create and drop threads at regular intervals. I assume this is due to a thread pool dynamically resizing itself. Let's say a thread starts, lives long enough for its Thread object to be promoted to the old gen (along with its cached direct buffer), then exits. This will result in its cached direct buffer(s) being unreachable in the old gen and will only be reclaimed after the next full GC / concurrent GC cycle. Interestingly, the service in question does concurrent GC cycles really infrequently (one every few days) as it has a really low promotion rate. This results in the JVM's total direct size constantly increasing (which is effectively a native buffer leak). Has anyone come across this issue before? There are a few obvious ways to mitigate this, e.g., cause a Full GC / concurrent GC cycle at regular intervals. However, the best solution IMHO is to explicitly free any direct buffers that are still in the cache when a thread exits. I'll be happy to implement this and test it internally at Twitter, if it's not on anyone else's radar. However, to do what I'm proposing I need some sort of thread exit hook. Unfortunately, there doesn't seem to be one. Would proposing to introduce thread exit hooks be reasonable? Or is everyone going to freak out? :-) The hooks can be either per-Thread or even per-ThreadLocal. And it's OK if the hooks can only be used within java.base. FWIW, I did a simple prototype of this (I call the hooks from Thread::exit) and it seems to work as expected. Any thoughts / feedback on this will be very appreciated. Thanks, Tony ————— Tony Printezis | @TonyPrintezis | tprintezis(a)twitter.com

7 23

RFR: JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit
by Tony Printezis 22 Jun '18

22 Jun '18

Hi all, Following the discussion on this a few weeks ago, here’s the first version of the change: http://cr.openjdk.java.net/~tonyp/8202788/webrev.0/ I think the consensus was that it’d be easier if the exit hooks were only available within java.base. Is it enough that I added the functionality to the jdk.internal.misc package? (And is jdk.internal.misc the best place for this?) I’ll also add a test for the new functionality. But let’s first come up with an approach that everyone is happy with. :-) One additional question: I put the new functionality conditional on a property (jdk.nio.freeBuffersAtThreadExit) and it’s off by default. Should I make it on by default? Or just not add the property all-together? Tony ————— Tony Printezis | @TonyPrintezis | tprintezis(a)twitter.com

5 50

[core-libs] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control
by David Holmes 21 Jun '18

21 Jun '18

This review is being spread across four groups: langtools, core-libs, hotspot and serviceability. This is the specific review thread for core-libs - webrev: http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.corelibs.v1/ See below for full details - including annotated full webrev guiding the review. The intent is to have JEP-181 targeted and integrated by the end of this month. Thanks, David ----- The nestmates project (JEP-181) introduces new classfile attributes to identify classes and interfaces in the same nest, so that the VM can perform access control based on those attributes and so allow direct private access between nestmates without requiring javac to generate synthetic accessor methods. These access control changes also extend to core reflection and the MethodHandle.Lookup contexts. Direct private calls between nestmates requires a more general calling context than is permitted by invokespecial, and so the JVMS is updated to allow, and javac updated to use, invokevirtual and invokeinterface for private class and interface method calls respectively. These changed semantics also extend to MethodHandle findXXX operations. At this time we are only concerned with static nest definitions, which map to a top-level class/interface as the nest-host and all its nested types as nest-members. Please see the JEP for further details. JEP: https://bugs.openjdk.java.net/browse/JDK-8046171 Bug: https://bugs.openjdk.java.net/browse/JDK-8010319 CSR: https://bugs.openjdk.java.net/browse/JDK-8197445 All of the specification changes have been previously been worked out by the Valhalla Project Expert Group, and the implementation reviewed by the various contributors and discussed on the valhalla-dev mailing list. Acknowledgments and contributions: Alex Buckley, Maurizio Cimadamore, Mandy Chung, Tobias Hartmann, Vladimir Ivanov, Karen Kinnear, Vladimir Kozlov, John Rose, Dan Smith, Serguei Spitsyn, Kumar Srinivasan Master webrev of all changes: http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.full.v1/ Annotated master webrev index: http://cr.openjdk.java.net/~dholmes/8010319-JEP181/jep181-webrev.html Performance: this is expected to be performance neutral in a general sense. Benchmarking and performance runs are about to start. Testing Discussion: ------------------ The testing for nestmates can be broken into four main groups: - New tests specifically related to nestmates and currently in the runtime/Nestmates directory - New tests to complement existing tests by adding in testcases not previously expressible. - For example java/lang/invoke/SpecialInterfaceCall.java tests use of invokespecial for private interface methods and performing receiver typechecks, so we add java/lang/invoke/PrivateInterfaceCall.java to do similar tests for invokeinterface. - New JVM TI tests to verify the spec changes related to nest attributes. - Existing tests significantly affected by the nestmates changes, primarily: - runtime/SelectionResolution In most cases the nestmate changes makes certain invocations that were illegal, legal (e.g. not requiring invokespecial to invoke private interface methods; allowing access to private members via reflection/Methodhandles that were previously not allowed). - Existing tests incidentally affected by the nestmate changes This includes tests of things utilising class redefinition/retransformation to alter nested types but which unintentionally alter nest relationships (which is not permitted). There are still a number of tests problem-listed with issues filed against them to have them adapted to work with nestmates. Some of these are intended to be addressed in the short-term, while some (such as the runtime/SelectionResolution test changes) may not eventuate. - https://bugs.openjdk.java.net/browse/JDK-8203033 - https://bugs.openjdk.java.net/browse/JDK-8199450 - https://bugs.openjdk.java.net/browse/JDK-8196855 - https://bugs.openjdk.java.net/browse/JDK-8194857 - https://bugs.openjdk.java.net/browse/JDK-8187655 There is also further test work still to be completed (the JNI and JDI invocation tests): - https://bugs.openjdk.java.net/browse/JDK-8191117 which will continue in parallel with the main RFR. Pre-integration Testing: - General: - Mach5: hs/jdk tier1,2 - Mach5: hs-nightly (tiers 1 -3) - Targetted - nashorn (for asm changes) - hotspot: runtime/* serviceability/* compiler/* vmTestbase/* - jdk: java/lang/invoke/* java/lang/reflect/* java/lang/instrument/* java/lang/Class/* java/lang/management/* - langtools: tools/javac tools/javap

11 69

Durations in existing JDK APIs
by Kurt Alfred Kluever 16 Jun '18

16 Jun '18

*Hi core-libs-dev and concurrency-interest,Recently, we've been closely studying date/time code inside of Google, and found a surprising number of places with time unit mismatches due to overuse of primitives to represent date/time concepts. And unlike "off-by-one" errors, these are often "off-by-1000x" or worse...yikes! For internal APIs, we're strongly encouraging folks to use the appropriate java.time types (i.e., Duration or Instant) because this greatly reduces the occurrence of these problems.There are several improvements in the JDK we'd like to propose: 1. Rename ALL existing unitless primitive method parameters to include their time unit. At Google, we have static analysis tools to detect unit mismatches that work based on method names, variable names, etc. However, when methods and method parameters are unitless, the only way to know what correct units are is to read and understand the javadocs (which our tools obviously can't do). Many IDEs also show method signatures with parameter names only. There are a handful of examples in the JDK that we'd like to update. For example, Object.wait(long timeout) would become Object.wait(long timeoutMillis) (or similar). An incomplete list of these APIs is included below [1].2. Add a java.time overload to some APIs that currently represent date/time concepts using primitives. While static analysis helps find errors, ideally people wouldn't have to decompose their Duration instances to call these APIs. Adding a Duration overload of each of these APIs would remove the need to decompose durations, and would encourage developers to plumb durations through more layers of their application. The old primitive-accepting APIs would be softly discouraged. Note that new default implementations will have to delegate to the existing overloads, and will have to choose between losing precision or capping large values at e.g. 292 years (for long nanos), but it is hard to imagine this being a serious problem in practice for any of them.1. Note: it's probably not worth adding Duration overloads to legacy APIs (e.g., java.util.Timer) or low-level APIs (e.g., java.lang.Object.wait()). Determining which APIs make the cut is certainly open to discussion.3. Add a java.time overload to most APIs that currently accept a <long, TimeUnit> pair. Prior to Java8, the recommended advice for accepting a logical duration was to use a <long, TimeUnit> pair, as most <https://docs.oracle.com/javase/9/docs/api/java/util/concurrent/locks/LockSu…> of java.util.concurrent currently does <https://docs.oracle.com/javase/9/docs/api/java/util/concurrent/class-use/Ti…>. Similarly, we've seen unit mismatch bugs with these APIs as well (e.g., future.get(timeout.toNanos(), MILLISECONDS)). Adding a Duration overload for each of these APIs would remove the need to decompose durations, and would encourage broader Duration adoption. The old APIs would be softly discouraged.1. Note: a few of the <long, TimeUnit> APIs are already overloaded, which would make this a 2x2 explosion of methods. Whether that sort of API explosion is acceptable is certainly open for discussion.2. Note: We've already started adding these overloads <https://github.com/google/guava/issues/2999> in Guava <https://github.com/google/guava/> and have plans to do so across the board. Caffeine <https://github.com/ben-manes/caffeine/> has also added <https://github.com/ben-manes/caffeine/issues/221> Duration overloads.4. Add APIs to convert between TimeUnit and Duration. As users transition to the new Duration-centric world, these APIs will come in handy. They will also be necessary for overload-implementers. We're proposing Duration.of(long, TimeUnit) and TimeUnit.convert(Duration).These recommendations, of course, should also apply to new APIs added in the future. Note that we are not expressing an opinion at this time on whether new APIs should or shouldn't also have a <long, TimeUnit> overload.Of course, even comprehensive adoption of Duration in a codebase will not eliminate every possible source of unit mismatch bugs. But it would confine them to only the places where Durations are created. This would reduce the risk in itself, but also makes it much easier for static analyses to detect any remaining bugs. It also lowers the cognitive burden faced by every developer interacting with logical durations.We realize that these are significant changes, so we'd love to hear your thoughts. We'd also be happy to work with Martin Buchholz to make these changes.Thanks,-Kurt Alfred Kluever(on behalf of the Java Core Libraries Team @ Google)Appendix[1] Unitless primitive parameters - Probably worth adding a Duration overload- java.lang.Thread.sleep(long millis)- java.lang.Thread.sleep(long millis, long nanos)- Note: this API is particularly weird since it accepts millis and nanos!- java.lang.Thread.join(long millis)- java.lang.Thread.join(long millis, long nanos)- Note: this API is particularly weird since it accepts millis and nanos!- java.nio.channel.Selector.select(long timeout)- Probably too low level to worry about adding a java.time overloads- java.lang.Object.wait(long timeout)- java.lang.Object.wait(long timeout, long nanos)- Note: this API is particularly weird since it accepts millis and nanos!- java.lang.ReferenceQueue.remove(long timeout)- java.util.concurrent.locks.LockSupport.parkUntil(long deadline)- Note: this parameter represents milliseconds since epoch (an Instant)- java.util.concurrent.locks.LockSupport.parkUntil(Object blocker, long deadline)- Note: this parameter represents milliseconds since epoch (an Instant)- java.util.concurrent.locks.LockSupport.parkNanos(long nanos)- java.util.concurrent.locks.LockSupport.parkNanos(Object blocker, long nanos)- java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject.awaitUntil(Date)- Note: this would be overloaded with an Instant- java.util.logging.LogRecord.setMillis(long millis)- "Legacy" APIs that are probably not worth adding a java.time overloads- java.util.Timer.schedule(TimerTask task, Date firstTime, long period)- java.util.Timer.schedule(TimerTask task, long delay)- java.util.Timer.schedule(TimerTask task, Date time)- java.util.Timer.schedule(TimerTask task, long delay, long period)- java.util.Timer.scheduleAtFixedRate(TimerTask task, Date firstTime, long period)- java.util.Timer.scheduleAtFixedRate(TimerTask task, long delay, long period)- java.sql.Connection.isValid(int timeout)- Note: this parameter is in seconds- java.sql.DriverManager.setLoginTimeout(int seconds)- Note: this parameter is in seconds- Networking APIs (perhaps not worth adding a Duration overload?)- java.net.InetAddress.isReachable(int timeout)- java.net.InetAddress.isReachable(NetworkInterface netif, int ttl, int timeout)- java.net.URLConnection.setConnectTimeout(int timeout)- java.net.URLConnection.setReadTimeout(int timeout)- java.net.Socket.setSoTimeout(int timeout)- java.net.Socket.connect(SocketAddress endpoint, int timeout)- java.net.ServerSocket.setSoTimeout(int timeout)- java.net.DatagramSocket.setSoTimeout(int timeout)*

6 18

RFR 7183985: Class.getAnnotation() throws an ArrayStoreException when the annotation class not present
by Liam Miller-Cushon 15 Jun '18

15 Jun '18

Hello, Please consider this fix for JDK-7183985. bug: https://bugs.openjdk.java.net/browse/JDK-7183985 webrev: http://cr.openjdk.java.net/~cushon/7183985/webrev.01/ I started a CSR for the change: https://bugs.openjdk.java.net/browse/JDK-8198584 We have been using the fix at Google for about two years, and there has been no compatibility impact. I found very few places ArrayStoreException was being explicitly handled, and none that were depending on the current behaviour of getAnnotation(). There was some previous discussion of the bug on core-libs-dev: * http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040590.html * http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/021798.ht… Thanks, Liam

6 13

[AIX] Fix codepage mappings in Java for IBM-943 and Big5
by Bhaktavatsal R Maram 14 Jun '18

14 Jun '18

Hi All, This issue is continuation to bug 8201540 (Extend the set of supported charsets in java.base on AIX) in which we have moved default charsets of most of the locales supported by Operating System to java.base module thus enabling OpenJDK on those locales for AIX platform. As part of that, charsets for locales Ja_JP (IBM-943) and Zh_TW (big5) also have been moved. However, corresponding charsets mapped in Java is not correct for them on AIX. Following are the details: 1. IBM-943 [1] for locale Ja_JP should be mapped to IBM-943C [2] Fundamental difference between IBM-943 and IBM-943C is that IBM-943C is ASCII compatible which means code points 'yen' and 'overline' of IBM-943 is replaced with 'backslash' and 'tilde' from ASCII character set. 2. Big5 for locale Zh_TW should be mapped to IBM-950 [3] I've attached simple test program to print the default charset along with fix for this issue. When run test program (PrintDefaultCharset) with IBM JDK 8 (on AIX) for locales Ja_JP & Zh_TW, following is output. -bash-4.4$ LANG=Ja_JP ~/JDKs/IBM/80/ON/sdk/jre/bin/java PrintDefaultCharset LANG = Ja_JP Default charset = x-IBM943C file.encoding = IBM-943C sun.jnu.encoding = IBM-943C -bash-4.4$ LANG=Zh_TW ~/JDKs/IBM/80/ON/sdk/jre/bin/java PrintDefaultCharset LANG = Zh_TW Default charset = x-IBM950 file.encoding = IBM-950 sun.jnu.encoding = IBM-950 Same test run with openJDK 11 gives following output -bash-4.4$ LANG=Ja_JP ~/jdk/bin/java PrintDefaultCharset LANG = Ja_JP Default charset = x-IBM943 file.encoding = IBM-943 sun.jnu.encoding = IBM-943 -bash-4.4$ LANG=Zh_TW ~/jdk/bin/java PrintDefaultCharset LANG = Zh_TW Default charset = Big5 file.encoding = big5 sun.jnu.encoding = big5 I will get webrev hosted in http://cr.openjdk.java.net for this change and send it for review once JIRA bug is created. [1] http://demo.icu-project.org/icu-bin/convexp?conv=ibm-943_P130-1999&s=JAVA [2] http://demo.icu-project.org/icu-bin/convexp?conv=ibm-943_P15A-2003&s=ALL [3] https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.nlsgd… Thanks, Bhaktavatsal Reddy

5 17

RFR: 8203357 Container Metrics
by Bob Vandette 12 Jun '18

12 Jun '18

Please review the following RFE which adds an internal API, along with jtreg tests that provide access to Docker container configuration data and metrics. In addition to the API which we hope to take advantage of in the future with Java Flight Recorder and a JMX Mbean, I’ve added an additional option to -XshowSettings:system than dumps out the container or host cgroup confguration information. See the sample output below: RFE: Container Metrics https://bugs.openjdk.java.net/browse/JDK-8203357 WEBREV: http://cr.openjdk.java.net/~bobv/8203357/webrev.00 This commit will also include a fix for the following bug. BUG: [TESTBUG] Test /runtime/containers/cgroup/PlainRead.java fails https://bugs.openjdk.java.net/browse/JDK-8203691 WEBREV: http://cr.openjdk.java.net/~bobv/8203357/webrev.00/test/hotspot/jtreg/runti… SAMPLE USAGE and OUTPUT: docker run —memory=256m --cpuset-cpus 4-7 -it ubuntu bash ./java -XshowSettings:system Operating System Metrics: Provider: cgroupv1 Effective CPU Count: 4 CPU Period: 100000 CPU Quota: -1 CPU Shares: -1 List of Processors, 4 total: 4 5 6 7 List of Effective Processors, 4 total: 4 5 6 7 List of Memory Nodes, 2 total: 0 1 List of Available Memory Nodes, 2 total: 0 1 CPUSet Memory Pressure Enabled: false Memory Limit: 256.00M Memory Soft Limit: Unlimited Memory & Swap Limit: 512.00M Kernel Memory Limit: Unlimited TCP Memory Limit: Unlimited Out Of Memory Killer Enabled: true TEST RESULTS: testing runtime container APIs Directory "JTwork" not found: creating Passed: runtime/containers/cgroup/PlainRead.java Passed: runtime/containers/docker/DockerBasicTest.java Passed: runtime/containers/docker/TestCPUAwareness.java Passed: runtime/containers/docker/TestCPUSets.java Passed: runtime/containers/docker/TestMemoryAwareness.java Passed: runtime/containers/docker/TestMisc.java Test results: passed: 6 Results written to /export/users/bobv/jdk11/build/jtreg/JTwork testing jdk.internal.platform APIs Passed: jdk/internal/platform/cgroup/TestCgroupMetrics.java Passed: jdk/internal/platform/docker/TestDockerCpuMetrics.java Passed: jdk/internal/platform/docker/TestDockerMemoryMetrics.java Passed: jdk/internal/platform/docker/TestSystemMetrics.java Test results: passed: 4 Results written to /export/users/bobv/jdk11/build/jtreg/JTwork testing -XshowSettings:system launcher option Passed: tools/launcher/Settings.java Test results: passed: 1 Bob.

7 20

[AIX] Add charset IBM-964 (default charset for zh_TW.IBM-eucTW) to stdcs
by Bhaktavatsal R Maram 12 Jun '18

12 Jun '18

Hi All, In bug 8201540 (Extend the set of supported charsets in java.base on AIX)[1] we moved default charsets that are available in OpenJDK to java.base module except to IBM964. Charset IBM964 is bit tricky. Its Encoder is extended from sun.nio.cs.ext.SimpleEUCEncoder. So, SimpleEUCEncoder also should be moved along with IBM964 to sun.nio.cs. However, there is another charset IBM33722 which should always in sun.nio.cs.ext whose encoder also extends SimpleEUCEncoder. Hence, the challenge is that sun.nio.cs.ext.IBM33722 should import SimpleEUCEncoder from either sun.nio.cs or sun.nio.cs.ext based on the location of IBM964. On AIX, following should be the package locations sun.nio.cs.IBM964 sun.nio.cs.SimpleEUCEncoder sun.nio.cs.ext.IBM33722 imports sun.nio.cs.SimpleEUCEncoder On Linux (and other platforms), following should be the package locations sun.nio.cs.ext.IBM964 sun.nio.cs.ext.SimpleEUCEncoder sun.nio.cs.ext.IBM33722 imports sun.nio.cs.ext.SimpleEUCEncoder To achieve this, I've changed all source files involved to templates. And, I also modified build tools to check if IBM964 is moved to stdcs or not and handled import statement of SimpleEUCEncoder in sun.nio.cs.ext.IBM33722 accordingly. Patch can be found here [2]. Please review. After jira bug is opened, I'll host it again with bug ID. With this change, java -version is successful on locale zh_TW.IBM-eucTW. -bash-4.4$ LANG=zh_TW.IBM-eucTW ~/openjdk/jdk11/build/aix-ppc64-normal-server-release/jdk/bin/java -version openjdk version "11-internal" 2018-09-25 OpenJDK Runtime Environment (build 11-internal+0-adhoc.bhamaram.jdk11) OpenJDK 64-Bit Server VM (build 11-internal+0-adhoc.bhamaram.jdk11, mixed mode) [1] https://bugs.openjdk.java.net/browse/JDK-8201540 [2] http://cr.openjdk.java.net/~aleonard/AIXIBM964/webrev.01/ Thanks, Bhaktavatsal Reddy

3 5