August 2018 - core-libs-dev

JEP 330 class loader getResourceAsStream
by seth lytle 27 Aug '18

27 Aug '18

JEP 330 (launch single-file source programs) uses a MemoryClassLoader. the compiled bytecode is stored in byte arrays in memory and is never written to file. currently, the bytecode is not exposed as resources and it would be advantageous to do so (enabling the use of eg ASM to modify the classes to implement continuations). this class loader has no resources other than the bytecode getResourceAsStream would be easy to implement. getResource would be significantly harder - a new url scheme and associated plumbing would be needed jonathon gibbons wrote on compiler-dev: > I would defer to ClassLoader experts as to whether it is reasonable > to provide getResourceAsStream but not getResource. > > It might be reasonable the jdk.compiler module to provide a URLStreamHandlerProvider for these URLs; > that would require some consideration. is it reasonable to expose a resource via getResourceAsStream that's not available via getResource ? the javadocs for getResource state "returns ... null if ... a URL could not be constructed to locate the resource". the javadocs for getResourceAsStream do not include such verbage, which appears to be precedent for such an arrangement

5 10

[12] Review Request: 8205537 Drop of sun.applet package
by Sergey Bylokhov 27 Aug '18

27 Aug '18

Hello. Please review the fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8205537 Webrev: http://cr.openjdk.java.net/~serb/8205537/webrev.00/ sun.applet is an internal package contained some code related to implementation of applets and appletviewer. Some of its classes were dropped already: JDK-8204454, JDK-8203308. Now there are only 3 classes, all related to the applet security and we can drop them as well. In the fix this package was removed, and the tests were updated to not use it. I am not sure how "ClassnameCharTest.java" is useful after applets removal, but since this test used subclass of the AppletClassLoader, I have copied some code from the removed class to the test. -- Best regards, Sergey.

2 2

RFR: 8209837: Avoid initializing ExpiringCache during bootstrap
by Claes Redestad 27 Aug '18

27 Aug '18

Hi, it's a tiny startup improvement to rearrange code so that the ExpiringCaches used in the FileSystem implementations aren't created if they aren't going to be used: Webrev: http://cr.openjdk.java.net/~redestad/8209837/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8209837 3 fewer classes loaded on bootstrap. Thanks! /Claes

5 6

(XS) java.logging Level.java minor cleanups
by Bernd Eckenfels 27 Aug '18

27 Aug '18

Hello, while investigating a Memory leak fix from IBM (IJ05380 is in 8.0.5.20 but not in 8u yet) I noticed that the (fixed) code registerWithClassLoader(Level) in the master queries a unused class name (pn) and it can use the method reference instead of Lambda. See patch below. There seems to be also a opportunity to use computeIfAbsent in a unrelated method add(Level), not sure if this is wanted, what do you think? index dbc27124d33..401c6dc73e0 100644 --- a/src/java.logging/share/classes/java/util/logging/Level.java +++ b/src/java.logging/share/classes/java/util/logging/Level.java @@ -610,10 +610,7 @@ public class Level implements java.io.Serializable { } private static void registerWithClassLoader(Level customLevel) { - PrivilegedAction<ClassLoader> pa = - () -> customLevel.getClass().getClassLoader(); - PrivilegedAction<String> pn = customLevel.getClass()::getName; - final String name = AccessController.doPrivileged(pn); + PrivilegedAction<ClassLoader> pa = customLevel.getClass()::getClassLoader; final ClassLoader cl = AccessController.doPrivileged(pa); CUSTOM_LEVEL_CLV.computeIfAbsent(cl, (c, v) -> new ArrayList<>()) .add(customLevel); @@ -624,19 +621,10 @@ public class Level implements java.io.Serializable { // the mirroredLevel object is always added to the list // before the custom Level instance KnownLevel o = new KnownLevel(l); - List<KnownLevel> list = nameToLevels.get(l.name); - if (list == null) { - list = new ArrayList<>(); - nameToLevels.put(l.name, list); - } - list.add(o); - - list = intToLevels.get(l.value); - if (list == null) { - list = new ArrayList<>(); - intToLevels.put(l.value, list); - } - list.add(o); + nameToLevels.computeIfAbsent(l.name, (k) -> new ArrayList<>()) + .add(o); + intToLevels.computeIfAbsent(l.value, (k) -> new ArrayList<>()) + .add(o); // keep the custom level reachable from its class loader // This will ensure that custom level values are not GC'ed I am happy if anyone can sponsor this change. BTW: I get a synthetic Accessor warning on l.name/value, is this what nestmates will resolve – is it worth adjusting the modifiers for those fields anyway? Gruss Bernd -- http://bernd.eckenfels.net

3 7

JVM Interpreter
by mr rupplin 26 Aug '18

26 Aug '18

I am presuming the JVM interpreter is defined/implemented in the the hotspot module since this is a JVM implementation. I cannot seem to find *any* instruction in it that gets called by a simple "./java -ea Class" call. We are stumped. For instance there are methods for local set and reference: void BytecodeInterpreter::set_stack_slot(intptr_t *tos, address value, int offset) { *((address *)&tos[Interpreter::expr_index_at(-offset)]) = value; } void BytecodeInterpreter::set_stack_object(intptr_t *tos, oop value, int offset) { *((oop *)&tos[Interpreter::expr_index_at(-offset)]) = value; } These (and similar in same file) are not being called at all during the JVM interpreter phase (simple java program as reference). My program creates an object and calls a test method with a single object as reference. What could be the hang up? No printf statement seems to work. Thanks. Max Rupplin Software Engineer

3 3

DatagramChannel performance issue
by Martin Thompson 25 Aug '18

25 Aug '18

We've been diagnosing a performance issue and isolated it to receiving on a datagram socket where we are seeing a significant step down in performance, and increase in allocation, when more than one source is sending. https://github.com/frohoff/jdk8u-jdk/blob/master/src/windows/native/sun/nio… When receiving from two or more sources we get InetAddress and InetSocketAddress objects allocated and they are set via multiple up calls from the JNI code into Java. A much more efficient implementation would be one that passes down two ByteBuffers. One to be filled in for the payload and one for the header. Allocation on a per packet receive is not a useful design for a network API. A read operation is not a valid alternative as we need the sender address. Regards, Martin...

1 0

Re: RFR: 8209937: Enhance java.io.Console - provide methods to query console width and height
by Xueming Shen 24 Aug '18

24 Aug '18

To the core-libs ... On 8/24/18, 9:56 AM, Xueming Shen wrote: > Hi Langer, > > I would suggest to add explicit wording to emphasize the "size" means > the rows > and columns in characters, not the pixels. > > It appears attractive to have a Console.Dimension to abstract the size > and make it > an "atomic" access but I'm not sure if it's really worth the cost to > have an extra > class merely for this purpose. getWidth/Height might be just good > enough for most > possible use scenario for Console class. Maybe we can add a getSize() > when we > have a better abstract/choice later, for example, "tuples/pair" ? :-) > > A little background, the design decision of the Console class back > then was to avoid > those platform dependent term curses related stuff, so those size, > cursor related > functionality were purposely removed from the final API and > implementation ... > > Thanks, > Sherman > > On 8/24/18, 6:41 AM, Peter Levart wrote: >> >> >> On 08/24/2018 03:18 PM, Langer, Christoph wrote: >>> Hi Rémi, Hi Peter, >>> >>> thanks for your quick answers. >>> >>> What you've suggested, Rémi, is perfectly right. I've updated my >>> webrev. The methods were copied from our old implementation (of a >>> different class) where they were provided as static. >>> >>> I will also think of using an optional. I'm furthermore wondering if >>> we should provide a method "dimensions()" returning an (optional) >>> java.io.Console.Dimension object that contains both height and width... >> >> Yes, a good idea. In AWT/Swing such methods are called getSize() or >> size(): >> >> /** >> * @deprecated As of JDK version 1.1, >> * replaced by <code>getSize()</code>. >> */ >> @Deprecated >> public Dimension size() { >> return new Dimension(width, height); >> } >> >> It seems that at some stage, methods like size() have been >> @Deprecated and replaced with getSize(). Now we're going back from >> getSize() to size() as the preferred name... >> >> I suggest you create a private native method that returns both >> dimensions (encoded in a jlong for example, with non-existence being >> -1L) and then do the conversion (to Optional<Console.Dimension>) in a >> public Java method. It would be much simpler than creating objects in >> native code... >> >> Regards, Peter >> >>> >>> Here is a new webrev: >>> http://cr.openjdk.java.net/~clanger/webrevs/8209937.1/ >>> >>> Best regards >>> Christoph >>> >>>> -----Original Message----- >>>> From: Peter Levart <peter.levart(a)gmail.com> >>>> Sent: Freitag, 24. August 2018 13:06 >>>> To: Remi Forax <forax(a)univ-mlv.fr>; Langer, Christoph >>>> <christoph.langer(a)sap.com> >>>> Cc: core-libs-dev <core-libs-dev(a)openjdk.java.net>; Baesken, Matthias >>>> <matthias.baesken(a)sap.com> >>>> Subject: Re: RFR: 8209937: Enhance java.io.Console - provide >>>> methods to >>>> query console width and height >>>> >>>> >>>> >>>> On 08/24/2018 12:09 PM, Remi Forax wrote: >>>>> Hi Christoph, >>>>> getWidth() and getHeight() should be instance methods and not static >>>> methods, providing the weight or the height if there is no console >>>> seems >>>> weird. >>>>> Also, they should be named width() and height() given the rest of the >>>> methods of java.io.Console doesn't use the "get" convention. >>>>> regards, >>>>> Rémi >>>> They could also return OptionalInt to force user to think about >>>> "not-available" situations. >>>> >>>> Regards, Peter >>>> >>>>> ----- Mail original ----- >>>>>> De: "Christoph Langer" <christoph.langer(a)sap.com> >>>>>> À: "core-libs-dev" <core-libs-dev(a)openjdk.java.net> >>>>>> Cc: "Baesken, Matthias" <matthias.baesken(a)sap.com> >>>>>> Envoyé: Vendredi 24 Août 2018 11:33:05 >>>>>> Objet: RFR: 8209937: Enhance java.io.Console - provide methods to >>>>>> query >>>> console width and height >>>>>> Hi, >>>>>> >>>>>> please review and give feedback for this augmentation of >>>>>> java.io.Console. >>>>>> >>>>>> We have users that have the need to query for Width and Height of >>>>>> the >>>> console >>>>>> device in Java. In our own JVM implementation we had given them this >>>> hook as a >>>>>> custom extension already quite some time ago. We think, however, >>>>>> that >>>> it is a >>>>>> worthwhile augmentation of java.io.Console. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8209937 >>>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209937.0/ >>>>>> >>>>>> I'll also open a CSR for this, but I'll wait for some feedback on >>>>>> our proposal >>>>>> first. >>>>>> >>>>>> Thanks & Best regards >>>>>> Christoph >> >

2 1

RFR - CSR JDK-8200435 - String::align, String::indent (after revisions)
by Jim Laskey 24 Aug '18

24 Aug '18

After further discussion, the API specs for these methods have been extensively reworked and the CSR moved back to Proposal stage. Please review https://bugs.openjdk.java.net/browse/JDK-8200435 Cheers, — Jim

1 0

Javac Compiler
by mr rupplin 24 Aug '18

24 Aug '18

com.sun.tools.javac.main.Main com.sun.tools.javac.main.Main compiler = new com.sun.tools.javac.main.Main("javac"); return compiler.compile(args).exitCode; I see this down in jdk.compiler. The com.sun.tools.javac.main folder doesn't exist.

3 2

Interpreter Function Handler
by mr rupplin 24 Aug '18

24 Aug '18

jdk9/hotspot/src/share/vm/interpreter/interpreterRuntime.cpp Where does Java handle pass by value? Where can I see that implementation? Great. Thank you.

1 0