February 2018 - core-libs-dev

JEP [DRAFT]: Container aware Java
by Bob Vandette 16 Feb '18

16 Feb '18

I’d like to re-propose the following JEP that will enhance the Java runtime to be more container aware. This will add an Internal Java API that will provide container specific statistics. Some of the initial goals of the previous JEP proposal has been integrated into JDK 10 under an RFE (JDK-8146115). This JEP is now focused on providing a Java API that exports Container runtime configuration and metrics. Since the scope of this JEP have changed, I’m re-submitting it for comment and endorsement. JEP Issue: https://bugs.openjdk.java.net/browse/JDK-8182070 Here’s a Text dump of the JEP contents for your convenience: Summary ------- Container aware Java runtime Goals ----- Provide an internal API that can be used to extract container specific configuration and runtime statistics. This JEP will only support Docker on Linux-x64 although the design should be flexible enough to allow support for other platforms and container technologies. The initial focus will be on Linux cgroups technology so that we will be able to easily support other container technologies running on Linux in addition to Docker. Non-Goals --------- It is not a goal of this JEP to support any platform other than Docker container technology running on Linux x64. Success Metrics --------------- Success will be measured by the improvement in information that will be available to tools which visualize resource usage of containers that are running Java processes. Motivation ---------- Container technology is becoming more and more prevalent in Cloud based applications. The Cloud Serverless application programming model motivates developers to split large monolithic applications into 100s of smaller pieces each running in thier own container. This move increases the importance of the observability of each running container process. Adding the proposed set of APIs will allow more details related to each container process to be made available to external tools thereby improving the observability. Description ----------- This enhancement will be made up of the following work items: A. Detecting if Java is running in a container. The Java runtime, as well as any tests that we might write for this feature, will need to be able to detect that the current Java process is running in a container. A new API will be made available for this purpose. B. Exposing container resource limits, configuration and runtime statistics. There are several configuration options and limits that can be imposed upon a running container. Not all of these are important to a running Java process. We clearly want to be able to detect how many CPUs have been allocated to our process along with the maximum amount of memory that the process has been allocated but there are other options that we might want to base runtime decisions on. In addition, since Container typically impose limits on system resources, they also provide the ability to easily access the amount of consumption of these resources. The goal is to provide this information in addition to the configuration data. I propose adding a new jdk.internal.Platform class that will allow access to this information. Here are some of the types of configuration and consumption statistics that would be made available: isContainerized Memory Limit Total Memory Limit Soft Memory Limit Max Memory Usage Current Memory Usage Maximum Kernel Memory CPU Shares CPU Period CPU Quota Number of CPUs CPU Sets CPU Set Memory Nodes CPU Usage CPU Usage Per CPU Block I/O Weight Block I/O Device Weight Device I/O Read Rate Device I/O Write Rate OOM Kill Enabled OOM Score Adjustment Memory Swappiness Shared Memory Size Alternatives ------------ There are a few existing tools available to extract some of the same container statistics. These tools could be used instead. The benefit of providing a core Java internal API is that this information can be expose by current Java serviceability tools such as JMX and JFR along side other JVM specific information. Testing ------- Docker/container specific tests should be added in order to validate the functionality being provided with this JEP. Risks and Assumptions --------------------- Docker is currently based on cgroups v1. Cgroups v2 is also available but is incomplete and not yet supported by Docker. It's possible that v2 could replace v1 in an incompatible way rendering this work unusable until it is upgraded. Other alternative container technologies based on hypervisors are being developed that could replace the use of cgroups for container isloation. Dependencies ----------- None at this time.

4 5

RFR 8196298 Add null Reader and Writer
by Patrick Reinhart 15 Feb '18

15 Feb '18

Hi, Here is my first shot of the actual implementation and tests: http://cr.openjdk.java.net/~reinhapa/reviews/8196298/webrev.00 Thanks for feedback -Patrick

5 8

RFR: JDK-8190187: C++ code calling JNI_CreateJavaVM can be killed by Java
by Adam Farley8 15 Feb '18

15 Feb '18

Hi All, -- Short version -- Could a committer please take the fix for JDK-8190187 (full code included in the bug) and: 1) Complete the CSR process for the new JNI Return code. 2) Commit the changes that contain (a) the new return code, and (b) the non-Hotspot code that handles the new code. Backporting would be appreciated, but is optional. Also optional: Commit the jdwp code that serves as an example for how this code should be used. CSR again, unfortunately. -- Long Version -- We have a bug in OpenJDK where if you pass an info-only option (like -agentlib:jdwp=help) in through the JNI interface, it can exit your code with RC 0. I think this is a bug because if you planned to do anything after starting a Java VM, you have to do it in an exit hook. If an info-only option is used, exit(0) should not happen. Instead, the user's code should be told the VM cannot be used. Bug Link: https://bugs.openjdk.java.net/browse/JDK-8190187 I have proposed the creation of a new JNI return code indicating a "silent exit", where the vm encountered no error, but that it is not in a fit state to be used. See the link for an implementation of this, along with a handy test. In short, if you agree that this is a problem, we need a champion to: 1) Complete the CSR process for the new JNI Return code. 2) Commit the changes that contain (a) the new return code, and (b) the non-Hotspot code that handles the new code. Optionally, if you want to commit the code containing an example of the fix, you will need to: 3) Commit the Hotspot code that channels the new return code. 4) Complete the CSR process for the jdwp behaviour change. 5) Commit the jdwp code. Note that all of this code has *already been written*. This should be an easy commit once the CSR is done with. Best Regards Adam Farley Best Regards Adam Farley Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

3 4

RFR(xs): 8193909: Obsolete(remove) Co-operative Memory Management (CMM)
by sangheon.kim 15 Feb '18

15 Feb '18

Hi all, Could I have some reviews for CMM removal? This is closed CR but some public codes also need small modifications. This CR is for removing stuff related to an Oracle JDK module/package. Changes are just removing CMM from lists or in a test to skip the testing logic. CR: https://bugs.openjdk.java.net/browse/JDK-8193909 Webrev: http://cr.openjdk.java.net/~sangheki/8193909/webrev.0 Testing: hs-tier1~5, jdk1~3, open/test/jdk:jdk_core Thanks, Sangheon

5 7

8193819: Error message when module does not have a ModuleMainClass attribute is confusing
by Alan Bateman 15 Feb '18

15 Feb '18

There's a typo in the launcher resource used for the error message when `java -m` fails because the module doesn't have a main class. The name of the attribute is "ModuleMainClass", not "MainClass". Trivial change. -Alan diff --git a/src/java.base/share/classes/sun/launcher/resources/launcher.properties b/src/java.base/share/classes/sun/launcher/resources/launcher.properties --- a/src/java.base/share/classes/sun/launcher/resources/launcher.properties +++ b/src/java.base/share/classes/sun/launcher/resources/launcher.properties @@ -220,7 +220,7 @@ Error: The JavaFX launchApplication method has the wrong signature, it\n\ must be declared static and return a value of type void java.launcher.module.error1=\ - module {0} does not have a MainClass attribute, use -m <module>/<main-class> + module {0} does not have a ModuleMainClass attribute, use -m <module>/<main-class> java.launcher.module.error2=\ Error: Could not find or load main class {0} in module {1} java.launcher.module.error3=\

2 1

Re: RFR: 8196959: NullPointerException in discovery003.java
by Jim Laskey 15 Feb '18

15 Feb '18

+1 > On Feb 14, 2018, at 1:24 AM, Srinivas Dama <srinivas.dama(a)oracle.com> wrote: > > Jim, > > May I have second review for this thread in core-libs-dev group. > > Regards, > Srinivas > > ----- Forwarded Message ----- > From: sundararajan.athijegannathan(a)oracle.com > To: srinivas.dama(a)oracle.com > Cc: core-libs-dev(a)openjdk.java.net > Sent: Monday, February 12, 2018 6:25:08 PM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi > Subject: Re: RFR: 8196959: NullPointerException in discovery003.java > > Looks good. > > -Sundar > > On 12/02/18, 5:31 PM, Srinivas Dama wrote: >> Hi, >> >> Please review http://cr.openjdk.java.net/~sdama/8196959/webrev.00/ >> for https://bugs.openjdk.java.net/browse/JDK-8196959 >> >> This is small modification of fix for https://bugs.openjdk.java.net/browse/JDK-8011697. >> Fix is to handle the corner case where the engineName is null. >> >> >> Regards, >> Srinivas

1 0

Thread.single_step field, anything using it?
by Alan Bateman 15 Feb '18

15 Feb '18

I've been going through the fields in java.lang.Thread and I'm wondering if this field can be removed: /* Whether or not to single_step this thread. */ private boolean single_step; This field was used in the original Classic VM (pre-OpenJDK history). It doesn't appear to be used in the HotSpot VM. Does anyone know of any reason to keep it? Are there other VMs using it by any chance? -Alan

3 3

RFR: JDK-8197988, mach5 T2 test javax/net/ssl/interop/ClientHelloChromeInterOp.java failed after JDK-8164278
by Xueming Shen 15 Feb '18

15 Feb '18

Hi, Please help review the change for JDK-819798 issue: https://bugs.openjdk.java.net/browse/JDK-8197988 webrev: http://cr.openjdk.java.net/~sherman/8197988/webrev The change for JDK-8164278 caused a decoding regression. A Tier2 test case, javax/net/ssl/interop/ClientHelloChromeInterOp.java, that uses mime-base64-decoder failed. The "condition" that triggers the decoding to go the fast path is incorrect in the code pushed for JDK-819798. The intent here is to only start/try the fast path when we are at the beginning of a 4-byte legal base64 unit. The correct/appropriate check is to see if shiftto == 18, which means the decoder is still at the beginning of 4-byte unit. ( bits == 0 is a false indicator, as bits might include decoded byte value of 0). The fix is a relatively easy/one line change. Thanks, Sherman

2 2

RFR: 8194154 patch for crash at File.getCanonicalPath()
by Wenqian Pei 14 Feb '18

14 Feb '18

Hi: Bug: https://bugs.openjdk.java.net/browse/JDK-8194154 We found that if user defines -Duser.dir like "/home/a/b/c/", jvm will crash at File.getCanonicalPath() in java process bootstrap (before invoking user's java code). The native implematation of canonicalize_md.c:collapsible(char *names) has problem in processing double '/', parameter 'names' need normalized before JNI_CALL. This patch normalize parameters before call canonicalize0() in this call path Patch and test are in mailbox attachments. Can I please have a review for this patch? Thanks Wenqian Pei

6 11

RFR JDK-8164278: java.util.Base64.EncOutputStream/DecInputStream is slower than corresponding version in javax.mail package
by Xueming Shen 14 Feb '18

14 Feb '18

Hi, Please help review the change for JDK-8164278. issue: https://bugs.openjdk.java.net/browse/JDK-8164278 webrev: http://cr.openjdk.java.net/~sherman/8164278/webrev jmh.src: http://cr.openjdk.java.net/~sherman/8164278/Base64BM.java jmh.result: http://cr.openjdk.java.net/~sherman/8164278/base64.bm Base64.Decoder.decode0: Adopted the "similar" optimization approach we took in Base64.Encoder.encode0() to add a "fast path" to decode a block of 4-byte units together (current implementation decodes one single byte per while/loop. The jmh benchmark result indicates a big speed boost (those decodeArray/Mime/Url results, from 30% to 2 times faster, depends on input size). Base64.Encoder.encode0() It appears encode0() was fully optimized in 1.8. Can't get it faster :-) Tried to use Unsafe.getLong/putLong instead of byte by byte access. But it appears the 8-byte "vectorization" does not bring us enough speed up, the performance is the same as the current one. See encode00() at http://cr.openjdk.java.net/~sherman/8164278/webrev.00 Base64.Encoder.wrap(OutputStream)/EncOutputStream.write(): If my memory serves me right, the current implementation was under the assumption that the underlying output stream probably is buffered (if invoker cares). It would be a redundant if EncOutputStream buffers bytes again. It appears this is a wrong assumption. It is much slower to write 4 bytes separately, compared to bundle them together in a byte[4] and write into underlying, even the underlying output stream is a ByteArrayOutputStream. Again, the proposed change is to add a fast path loop, as we do in encode0(), to decode/ write a block of 3-byte->4-byte unites. It appears this fast loop can help the compiler to optimize away some boundary checks, therefor is much faster. The jmh result Base64BM.encodeOS suggests the new implementation is almost 4 times faster and is almost the same as java.mail's stream encoder. Base64.Decoder.wrap(InputStream)/DecInputStream.read(): Same as the approach we take for decode0(), to add a fast path decode block of 4-byte unites together. The jmh result Base64BM.decodeOS (the name probably should be decodeIS, for InputStream, but anyway...) shows the proposed one is 4 times faster than the existing impl and double the java.mail (Base64BM.decodeOS_javamail) implementation. However, there is a side-effect of adding a buffering mechanism into DecInputStream. The current implementation read bytes from the underlying stream one by one, it never reads more bytes than it needs, which means it should/is supposed to just stop at the last byte that it needs to decode, when there is "=" present in the stream. With buffering, it's possible more bytes (after "=", which indicates "end of base64 stream") might be read/consumed in and buffered. A concern? if this is indeed a concern, the only alternative might be to add a separate method to support this "faster-buffered-decoder"? Thanks, Sherman

2 5