August 2018 - core-libs-dev

Long chains created by direct Buffer::slice
by Florian Weimer 06 Aug '18

06 Aug '18

src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template contains this, unfortunately without further comments: | public $Type$Buffer slice() { | int pos = this.position(); | int lim = this.limit(); | assert (pos <= lim); | int rem = (pos <= lim ? lim - pos : 0); | int off = (pos << $LG_BYTES_PER_VALUE$); | assert (off >= 0); | return new Direct$Type$Buffer$RW$$BO$(this, -1, 0, rem, rem, off); | } ByteBuffer::duplicate and ByteBuffer::asReadOnlyBuffer have similar code. The constructor invoked: | // For duplicates and slices | // | Direct$Type$Buffer$RW$$BO$(DirectBuffer db, // package-private | int mark, int pos, int lim, int cap, | int off) | { | #if[rw] | super(mark, pos, lim, cap); | address = db.address() + off; | #if[byte] | cleaner = null; | #end[byte] | att = db; | #else[rw] | super(db, mark, pos, lim, cap, off); | this.isReadOnly = true; | #end[rw] | } The key part is the assignment to the att member. If I understand this correctly, it is needed to keep the backing object alive during the lifetime of this buffer. However, it causes the creation of a long chain of buffer objects. With -Xmx100m or so, the following test will OOM fairly quickly for this reason: | volatile ByteBuffer buffer; | … | buffer = ByteBuffer.allocateDirect(16384); | while (true) { | buffer = buffer.duplicate(); | } I wonder if it would be possible to change the setting of the att member to this instead: | if (db.att == null) { | att = db; | } else { | att = db.att; | } This would only keep the object alive which actually owns the backing storage, as if Buffer::slice had been invoked on it directly.

4 8

System.java Development Question
by mr rupplin 06 Aug '18

06 Aug '18

Hello. I'm not sure if there's a minor typo but I cannot find the error in it. Can you guys look? In System.c we have: JNIEXPORT void JNICALL Java_java_lang_System_setMemoryAllocationListener0(JNIEnv *env, jclass cla, jobject listener) { jfieldID fid = (*env)->GetStaticFieldID(env,cla,"memoryAllocationListener","Ljava/lang/memory/MemoryAllocationListener;"); if (fid == 0) return; (*env)->SetStaticObjectField(env,cla,fid,listener); } -- -- -- -- -- And in System.java we have: public static final MemoryAllocationListener memoryAllocationListener = null; ... public static void setMemoryAllocationListener(MemoryAllocationListener memoryAllocationListener) { checkMalloc(); setMemoryAllocationListener0(memoryAllocationListener); } ... //SecureJVM private private static native void setMemoryAllocationListener0(MemoryAllocationListener memoryAllocationListener); -- -- -- -- -- We get the following after running a trivial Java program: Exception in thread "main" java.lang.UnsatisfiedLinkError: java.lang.System.setMemoryAllocationListener0(Ljava/lang/memory/MemoryAllocationListener;)V at java.base/java.lang.System.setMemoryAllocationListener0(Native Method) at java.base/java.lang.System.setMemoryAllocationListener(System.java:261) at Hope.<init>(Hope.java:19) at Hope.main(Hope.java:11) -- -- Can we skip right to it? What is the issue here? Thanks. Max R.

4 8

[httpclient] HTTP2: Memory Leak with Proxy
by Albert Schimpf 06 Aug '18

06 Aug '18

Hi, I stumbled upon some strange behavior when using the new Java httpclient. The issue is very simple to reproduce. Send a GET request via a known bad proxy: HttpClient client = HttpClient.newBuilder() .proxy(ProxySelector.of(BAD_PROXY)) .build(); HttpRequest req = HttpRequest // target is not relevant .newBuilder(...) .GET() .build(); // body handler is not relevant HttpResponse.BodyHandler<?> t = HttpResponse.BodyHandler.asString(); // happens with both async and sync send client.sendAsync(req, t).get(30, TimeUnit.SECONDS); The result is that the heap size increases dramatically (to about 1.5GB) and resources are not released. CPU consumption increases by a constant factor, too. I have tried many variations of the above code, and the only thing which seems to work (i.e. heap size does not explode) is to set the HTTP version to 1.1. In my main application this leads to both memory and CPU starvation (4GB memory limit, 100% CPU usage). It usually uses only 5% CPU and 200MB memory at worst. I have attached a working example code with a bad proxy. I uploaded the generated garbage collection log and three heap dumps (before, during, and after the request) to dropbox: https://www.dropbox.com/s/ulqnmrmgr58rrul/debug.zip I tried the 10.0.0-openjdk and 10.0.1-zulu version. I can reproduce the issue 100% of times. Am I doing something wrong? Is this to be expected if one somehow happens to use a bad proxy? If this is to be expected, how can I protect my application against such behavior? Best, Albert

2 1

RFR: 8202794: Native Unix code should use readdir rather than readdir_r
by Pengfei Li 06 Aug '18

06 Aug '18

Hi Last month, Bernard proposed a patch to fix the OpenJDK build issue with recent versions of glibc. See http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/052991.html But this fix requires to be tested on all POSIX systems before getting integrated. As recently, more and more guys are complaining about the OpenJDK build failure issue, shall we just add the following workaround to upstream before Bernard's real fix eventually merged? diff --git a/src/java.base/unix/native/libjava/TimeZone_md.c b/src/java.base/unix/native/libjava/TimeZone_md.c index f0bb362afc..e156381acd 100644 --- a/src/java.base/unix/native/libjava/TimeZone_md.c +++ b/src/java.base/unix/native/libjava/TimeZone_md.c @@ -146,7 +146,7 @@ findZoneinfoFile(char *buf, size_t size, const char *dir) (void) closedir(dirp); return NULL; } - +#pragma GCC diagnostic ignored "-Wdeprecated-declarations" while (readdir64_r(dirp, entry, &dp) == 0 && dp != NULL) { /* * Skip '.' and '..' (and possibly other .* files) diff --git a/src/java.base/unix/native/libjava/UnixFileSystem_md.c b/src/java.base/unix/native/libjava/UnixFileSystem_md.c index 315aa92b64..5b9554dd47 100644 --- a/src/java.base/unix/native/libjava/UnixFileSystem_md.c +++ b/src/java.base/unix/native/libjava/UnixFileSystem_md.c @@ -339,6 +339,7 @@ Java_java_io_UnixFileSystem_list(JNIEnv *env, jobject this, if (rv == NULL) goto error; /* Scan the directory */ +#pragma GCC diagnostic ignored "-Wdeprecated-declarations" while ((readdir64_r(dir, ptr, &result) == 0) && (result != NULL)) { jstring name; if (!strcmp(ptr->d_name, ".") || !strcmp(ptr->d_name, "..")) diff --git a/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c b/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c index 53bb1c1009..72c38eb9a6 100644 --- a/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c +++ b/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c @@ -731,6 +731,7 @@ Java_sun_nio_fs_UnixNativeDispatcher_readdir(JNIEnv* env, jclass this, jlong val /* EINTR not listed as a possible error */ /* TDB: reentrant version probably not required here */ +#pragma GCC diagnostic ignored "-Wdeprecated-declarations" res = readdir64_r(dirp, ptr, &result); #ifdef _AIX diff --git a/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c b/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c index 1adeaf7bb5..080cf2a89b 100644 --- a/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c +++ b/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c @@ -80,6 +80,7 @@ static struct dirent* read_dir(DIR* dirp, struct dirent* entry) { return dbuf; #else /* __linux__ || _ALLBSD_SOURCE */ struct dirent* p; +#pragma GCC diagnostic ignored "-Wdeprecated-declarations" if (readdir_r(dirp, entry, &p) == 0) { return p; } else { -- Thanks, Pengfei

4 8

[NEW BUG] Fix "moduel" typo in ModuleInfo
by Christoph Dreis 05 Aug '18

05 Aug '18

Hi, I just noticed this trivial typo while looking through the module related code. I'd be happy if this patch is accepted. Cheers, Christoph === PATCH === diff --git a/src/java.base/share/classes/jdk/internal/module/ModuleInfo.java b/src/java.base/share/classes/jdk/internal/module/ModuleInfo.java --- a/src/java.base/share/classes/jdk/internal/module/ModuleInfo.java +++ b/src/java.base/share/classes/jdk/internal/module/ModuleInfo.java @@ -233,7 +233,7 @@ Set<String> allPackages = null; String mainClass = null; ModuleTarget moduleTarget = null; - ModuleHashes moduelHashes = null; + ModuleHashes moduleHashes = null; ModuleResolution moduleResolution = null; for (int i = 0; i < attributes_count ; i++) { @@ -267,7 +267,7 @@ case MODULE_HASHES : if (parseHashes) { - moduelHashes = readModuleHashesAttribute(in, cpool); + moduleHashes = readModuleHashesAttribute(in, cpool); } else { in.skipBytes(length); } @@ -331,7 +331,7 @@ ModuleDescriptor descriptor = builder.build(); return new Attributes(descriptor, moduleTarget, - moduelHashes, + moduleHashes, moduleResolution); }

2 1

JDK 12 RFR of JDK-8208782: Remove extra type in throws clause of SerialClob.writeObject
by Joseph D. Darcy 03 Aug '18

03 Aug '18

Hello, The fix for JDK-8208060, Additional corrections of serial-related declarations, overlooked an extra type in the throws clause of javax.sql.rowset.serial.SerialClob.writeObject. The extra type should be removed. Patch below. Thanks, -Joe --- old/src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialClob.java 2018-08-03 14:45:17.977105996 -0700 +++ new/src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialClob.java 2018-08-03 14:45:17.453105982 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -663,7 +663,7 @@ * to a stream. */ private void writeObject(ObjectOutputStream s) - throws IOException, ClassNotFoundException { + throws IOException { ObjectOutputStream.PutField fields = s.putFields(); fields.put("buf", buf);

2 1

RFR: 8207263: Store the Configuration for system modules into CDS archive
by Jiangli Zhou 03 Aug '18

03 Aug '18

Please review the following webrev that archives the system module boot layer Configuration (including all java objects reachable from the Configuration) in CDS archive. This is built on top of the earlier change for JDK-8202035 (https://bugs.openjdk.java.net/browse/JDK-8202035) which provides a framework for object sub-graph archiving. The boot layer Configuration is created in ModuleBootstrap.boot() (similar to the archived system ModuleDescriptor objects, etc) and is unchanged after construction. With archived boot layer Configuration, it allows runtime to bypass the work for creating the configuration. Currently, this is only supported when the initial module is unnamed module. Measurements indicate archiving the boot layer Configuration improves the startup time by 1% ~ 1.5% (on linux-x64) when running HelloWorld from -cp at runtime. Many thanks to Alan and Claes for discussions and contributions to this change! Webrev: http://cr.openjdk.java.net/~jiangli/8207263/webrev.00/ RFE: https://bugs.openjdk.java.net/browse/JDK-8207263 Tested with tier1 - tier5 tests via mach5. Thanks, Jiangli

2 1

Race condition when serializing SerializedRandomAccessList
by Krystal Mok 03 Aug '18

03 Aug '18

Hi core-libs, I'd like to report a bug on race condition while serializing SerializedRandomAccessList / deserializing SerializedList. This seems to be a long standing bug, we've hit it on JDK8 and the same code is still there in JDK11's core-lib. In SerializedRandomAccessList.writeReplace(): [1] private Object writeReplace() { return new SynchronizedList<>(list); } Here, it's creating a new "face" of the current SerializedRandomAccessList, but not passing down this.mutex into the newly created SynchronizedList. What we've seen go wrong was that one thread was still appending to the SerializedRandomAccessList, while another thread is trying to serialize it, a ConcurrentModificationException may be thrown on the underlying list. I've filed JDK-8208779 [2] to track this issue. Note: this issue was reported by my colleague Shixiong Zhu at Databricks. I'm just delegating the report to the core-libs list. One past occurrence of the same issue can be found in Apache Spark in [3]. Thanks, Kris [1]: http://hg.openjdk.java.net/jdk/jdk11/file/4322ef0c1684/src/java.base/share/… [2]: https://bugs.openjdk.java.net/browse/JDK-8208779 [3]: https://issues.apache.org/jira/browse/SPARK-17463?focusedCommentId=15787809…

1 0

RFR: JDK-8208634 : Add x-IBM-1129 charset
by Nasser Ebrahim 03 Aug '18

03 Aug '18

Hello, Java was not launching on many AIX supported locales as the default charsets for those locales were not included in the java.base and Java could not access jdk.charsets during boot up. Most of those locales were addressed through the Oracle bugs JDK-8201540 [1] and JDK-8202329 [2]. Still, few more are pending. In the remaining locales, two charsets (Vi_VN.IBM-1129 & ja_JP.IBM-eucJP) are missing in the jdk.charsets as well. In this enhancement, IBM-1129 charset is getting added to jdk.charsets on all platforms and to java.base on AIX platform. The webrev of the fix is available at http://cr.openjdk.java.net/~aleonard/IBM1129/webrev.00/ Kindly request you to review the webrev and provide your comments. [1] https://bugs.openjdk.java.net/browse/JDK-8201540 [2] https://bugs.openjdk.java.net/browse/JDK-8202329 Thank you, Nasser Ebrahim

1 0

Add x-IBM-1129 charset
by Nasser Ebrahim 03 Aug '18

03 Aug '18

Hello, With the following three bugs, all the default locale charsets except two (Vi_VN.IBM-1129 & ja_JP.IBM-eucJP) are fixed for AIX platform. - JDK-8201540: [AIX] Extend the set of supported charsets in java.base - JDK-8202329: Codepage mappings for IBM-943 and Big5 (aix) - http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053050.html : [AIX] Add charset IBM-964 (default charset for zh_TW.IBM-eucTW) to stdcs [bug not yet opened]. For those fixed charsets, the charsets were existing in the extended charsets (jdk.charsets) and they were not working with default locale charset as it did not exist in the standard charset (java.base). The charsets correspond to the two pending locale (Vi_VN.IBM-1129 & ja_JP.IBM-eucJP) does not exist in the jdk. They need to be added to the extended charsets before adding to stdcs on AIX platform. Here, am including the patch to fix the charset IBM-1129 for the locale Vi_VN.IBM-1129. We are working on the other missing charset (for ja_JP.IBM-eucJP) which will be contributed in some time. The webrev of the fix is available at http://cr.openjdk.java.net/~aleonard/IBM1129/webrev.00/ Kindly request you to open a bug and review the fix. Please let me know if you have any questions. Thank you, Nasser Ebrahim

3 4