From kim.barrett at oracle.com Wed Mar 1 01:56:45 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 28 Feb 2017 20:56:45 -0500 Subject: 10 RFR: 8150687: typedefs without type names Message-ID: <33F5BF24-5892-4E14-962D-09CEF2F92FDB@oracle.com> Please review this small change, removing unnecessary uses of "typedef" that lead to warnings from Visual Studio 2015. CR: https://bugs.openjdk.java.net/browse/JDK-8150687 Webrev: http://cr.openjdk.java.net/~kbarrett/8150687/jdk.00/ Testing: jprt From david.holmes at oracle.com Wed Mar 1 02:05:54 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 Mar 2017 12:05:54 +1000 Subject: 10 RFR: 8150687: typedefs without type names In-Reply-To: <33F5BF24-5892-4E14-962D-09CEF2F92FDB@oracle.com> References: <33F5BF24-5892-4E14-962D-09CEF2F92FDB@oracle.com> Message-ID: <2e8caf41-32a2-c060-4a69-53cb89ab2fe8@oracle.com> Hi Kim, nio-dev should look at this - cc'd. But looks fine to me. :) David On 1/03/2017 11:56 AM, Kim Barrett wrote: > Please review this small change, removing unnecessary uses of "typedef" that lead to warnings from Visual Studio 2015. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8150687 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8150687/jdk.00/ > > Testing: > jprt > From brian.burkhalter at oracle.com Wed Mar 1 02:20:33 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 28 Feb 2017 18:20:33 -0800 Subject: 10 RFR: 8150687: typedefs without type names In-Reply-To: <2e8caf41-32a2-c060-4a69-53cb89ab2fe8@oracle.com> References: <33F5BF24-5892-4E14-962D-09CEF2F92FDB@oracle.com> <2e8caf41-32a2-c060-4a69-53cb89ab2fe8@oracle.com> Message-ID: <207B8FE0-0F63-40E2-AA8D-98266EFC45D4@oracle.com> +1 Brian On Feb 28, 2017, at 6:05 PM, David Holmes wrote: > Hi Kim, > > nio-dev should look at this - cc'd. > > But looks fine to me. :) > > David > > On 1/03/2017 11:56 AM, Kim Barrett wrote: >> Please review this small change, removing unnecessary uses of "typedef" that lead to warnings from Visual Studio 2015. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8150687 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8150687/jdk.00/ >> >> Testing: >> jprt >> From david.holmes at oracle.com Wed Mar 1 06:36:37 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 Mar 2017 16:36:37 +1000 Subject: Forcing initialization of string concat INDY expressions Message-ID: The INDY-fication of string concatenation has triggered a problem where a JVM TI agent's monitor-wait/ed callback hits an error path that uses string concat which triggers a mass of indy related initialization, which in turn hits monitor use in MethodType$ConcurrentWeakInternSet.get, which causes the VM monitor subsystem to be re-entered (and it is not reentrant!) so we crash. (log extract below - the amount of code to process this is truly scary!) I'm trying to workaround the problem by forcing some earlier string concat in the thread in which the callback will execute. From what I can see the test already does: log(Thread.currentThread() + "some text"); but the error code is doing: log("Agent '" + agentName + "' finished execution (finishedSuccessfully: " + finishedSuccessfully + ")"); where finishedSuccessfully is a boolean, and so we have a different form of makeConcatWithConstants call site. I assume I can cover the exact case above by replicating it? But can I generalize it to cover arbitrary string concat expressions that might arise on other error paths? And yes I realize this error code could hit monitor use in numerous other places, but so far this is the only case that we have seen trigger. (Though I can't reproduce it - even if I force the error path to be taken.) Thanks, David ----- V [jvm.dll+0x3ba688] report_vm_error+0x48;; ?report_vm_error@@YAXPBDH00ZZ+0x48 V [jvm.dll+0x7608f0] ObjectMonitor::enter+0x170;; ?enter at ObjectMonitor@@QAEXPAVThread@@@Z+0x170 V [jvm.dll+0x862035] ObjectSynchronizer::slow_enter+0x1d5;; ?slow_enter at ObjectSynchronizer@@SAXVHandle@@PAVBasicLock@@PAVThread@@@Z+0x1d5 V [jvm.dll+0x85fe8f] ObjectSynchronizer::fast_enter+0xff;; ?fast_enter at ObjectSynchronizer@@SAXVHandle@@PAVBasicLock@@_NPAVThread@@@Z+0xff V [jvm.dll+0x2b5412] Runtime1::monitorenter+0x1e2;; ?monitorenter at Runtime1@@CAXPAVJavaThread@@PAVoopDesc@@PAVBasicObjectLock@@@Z+0x1e2 v ~RuntimeStub::monitorenter_nofpu Runtime1 stub J 192 c1 java.lang.invoke.MethodType$ConcurrentWeakInternSet.get(Ljava/lang/Object;)Ljava/lang/Object; java.base at 9-internal (54 bytes) @ 0x0242d7da [0x0242d4c0+0x0000031a] J 190 c1 java.lang.invoke.MethodType.makeImpl(Ljava/lang/Class;[Ljava/lang/Class;Z)Ljava/lang/invoke/MethodType; java.base at 9-internal (66 bytes) @ 0x0242ca20 [0x0242c9a0+0x00000080] J 255 c1 java.lang.invoke.MemberName.getMethodOrFieldType()Ljava/lang/invoke/MethodType; java.base at 9-internal (72 bytes) @ 0x02445238 [0x02444f20+0x00000318] J 239 c1 java.lang.invoke.InvokerBytecodeGenerator.isStaticallyInvocable(Ljava/lang/invoke/MemberName;)Z java.base at 9-internal (169 bytes) @ 0x0243dc28 [0x0243d820+0x00000408] j java.lang.invoke.InvokerBytecodeGenerator.addMethod()V+648 java.base at 9-internal j java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes()[B+6 java.base at 9-internal j java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(Ljava/lang/invoke/LambdaForm;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MemberName;+25 java.base at 9-internal j java.lang.invoke.LambdaForm.compileToBytecode()V+69 java.base at 9-internal j java.lang.invoke.LambdaForm.prepare()V+21 java.base at 9-internal j java.lang.invoke.MethodHandle.(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;)V+33 java.base at 9-internal j java.lang.invoke.BoundMethodHandle.(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;)V+3 java.base at 9-internal j java.lang.invoke.BoundMethodHandle$Species_L9.(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)V+3 java.base at 9-internal j java.lang.invoke.BoundMethodHandle$Species_L9.copyWith(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;)Ljava/lang/invoke/BoundMethodHandle;+42 java.base at 9-internal j java.lang.invoke.MethodHandles.dropArguments0(Ljava/lang/invoke/MethodHandle;ILjava/util/List;)Ljava/lang/invoke/MethodHandle;+105 java.base at 9-internal j java.lang.invoke.MethodHandles.dropArguments(Ljava/lang/invoke/MethodHandle;I[Ljava/lang/Class;)Ljava/lang/invoke/MethodHandle;+6 java.base at 9-internal j java.lang.invoke.StringConcatFactory$MethodHandleInlineCopyStrategy.generate(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/StringConcatFactory$Recipe;)Ljava/lang/invoke/MethodHandle;+479 java.base at 9-internal j java.lang.invoke.StringConcatFactory.generate(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/StringConcatFactory$Recipe;)Ljava/lang/invoke/MethodHandle;+101 java.base at 9-internal j java.lang.invoke.StringConcatFactory.doStringConcat(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;ZLjava/lang/String;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;+507 java.base at 9-internal j java.lang.invoke.StringConcatFactory.makeConcatWithConstants(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;+71 java.base at 9-internal j java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+18 java.base at 9-internal j java.lang.invoke.LambdaForm$BMH.reinvoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+48 java.base at 9-internal j java.lang.invoke.Invokers$Holder.invoke_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+26 java.base at 9-internal j java.lang.invoke.CallSite.makeSite(Ljava/lang/invoke/MethodHandle;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/Object;Ljava/lang/Class;)Ljava/lang/invoke/CallSite;+134 java.base at 9-internal j java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(Ljava/lang/Class;Ljava/lang/invoke/MethodHandle;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/invoke/MemberName;+6 java.base at 9-internal j java.lang.invoke.MethodHandleNatives.linkCallSite(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/invoke/MemberName;+45 java.base at 9-internal v ~StubRoutines::call_stub V [jvm.dll+0x526f80] JavaCalls::call_helper+0x390;; ?call_helper at JavaCalls@@CAXPAVJavaValue@@ABVmethodHandle@@PAVJavaCallArguments@@PAVThread@@@Z+0x390 V [jvm.dll+0x7777c5] os::os_exception_wrapper+0xb5;; ?os_exception_wrapper at os@@SAXP6AXPAVJavaValue@@ABVmethodHandle@@PAVJavaCallArguments@@PAVThread@@@Z0123 at Z+0xb5 V [jvm.dll+0x526bdb] JavaCalls::call+0x5b;; ?call at JavaCalls@@SAXPAVJavaValue@@ABVmethodHandle@@PAVJavaCallArguments@@PAVThread@@@Z+0x5b V [jvm.dll+0x527349] JavaCalls::call_static+0xc9;; ?call_static at JavaCalls@@SAXPAVJavaValue@@VKlassHandle@@PAVSymbol@@2PAVJavaCallArguments@@PAVThread@@@Z+0xc9 V [jvm.dll+0x864617] SystemDictionary::find_dynamic_call_site_invoker+0x687;; ?find_dynamic_call_site_invoker at SystemDictionary@@SA?AVmethodHandle@@VKlassHandle@@VHandle@@PAVSymbol@@2PAV4 at 3PAVThread@@@Z+0x687 V [jvm.dll+0x65eb84] LinkResolver::resolve_dynamic_call+0x44;; ?resolve_dynamic_call at LinkResolver@@SAXAAVCallInfo@@VHandle@@PAVSymbol@@2VKlassHandle@@PAVThread@@@Z+0x44 V [jvm.dll+0x66014e] LinkResolver::resolve_invokedynamic+0x35e;; ?resolve_invokedynamic at LinkResolver@@CAXAAVCallInfo@@ABVconstantPoolHandle@@HPAVThread@@@Z+0x35e V [jvm.dll+0x65fd7e] LinkResolver::resolve_invoke+0x8e;; ?resolve_invoke at LinkResolver@@SAXAAVCallInfo@@VHandle@@ABVconstantPoolHandle@@HW4Code at Bytecodes@@PAVThread@@@Z+0x8e V [jvm.dll+0x51eb0b] InterpreterRuntime::resolve_invokedynamic+0x7b;; ?resolve_invokedynamic at InterpreterRuntime@@CAXPAVJavaThread@@@Z+0x7b V [jvm.dll+0x51dee4] InterpreterRuntime::resolve_from_cache+0xd4;; ?resolve_from_cache at InterpreterRuntime@@SAXPAVJavaThread@@W4Code at Bytecodes@@@Z+0xd4 j nsk.share.aod.TargetApplicationWaitingAgents.agentFinished(Ljava/lang/String;Z)V+131 v ~StubRoutines::call_stub V [jvm.dll+0x526f80] JavaCalls::call_helper+0x390;; ?call_helper at JavaCalls@@CAXPAVJavaValue@@ABVmethodHandle@@PAVJavaCallArguments@@PAVThread@@@Z+0x390 V [jvm.dll+0x7777c5] os::os_exception_wrapper+0xb5;; ?os_exception_wrapper at os@@SAXP6AXPAVJavaValue@@ABVmethodHandle@@PAVJavaCallArguments@@PAVThread@@@Z0123 at Z+0xb5 V [jvm.dll+0x526bdb] JavaCalls::call+0x5b;; ?call at JavaCalls@@SAXPAVJavaValue@@ABVmethodHandle@@PAVJavaCallArguments@@PAVThread@@@Z+0x5b V [jvm.dll+0x597f9a] jni_invoke_static+0x1ba;; ?jni_invoke_static@@YAXPAUJNIEnv_@@PAVJavaValue@@PAV_jobject@@W4JNICallType@@PAU_jmethodID@@PAVJNI_ArgumentPusher@@PAVThread@@@Z+0x1ba V [jvm.dll+0x57f125] jni_CallStaticVoidMethod+0x1f5;; _jni_CallStaticVoidMethod+0x1f5 C [attach037Agent00.dll+0x1167] V [jvm.dll+0x7621cd] ObjectMonitor::wait+0x3bd;; ?wait at ObjectMonitor@@QAEX_J_NPAVThread@@@Z+0x3bd From matthias.baesken at sap.com Wed Mar 1 09:23:53 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 1 Mar 2017 09:23:53 +0000 Subject: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar Message-ID: Ping ... Can I get a review please for the change ? Thanks, Matthias From: Baesken, Matthias Sent: Donnerstag, 23. Februar 2017 12:28 To: 'core-libs-dev at openjdk.java.net' Cc: Langer, Christoph ; Erik Joelsson (erik.joelsson at oracle.com) ; 'Michel Trudeau' Subject: RE: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar Here is the webrev for jdk9 : http://cr.openjdk.java.net/~mbaesken/webrevs/8175000/ ? And btw I really wonder - is jexec still needed in future jdk's like jdk10 ? Seems it is not used much . ? In case jexec will stay in the jdk I might add a test for the tool as well, if there is interest ( could not really find one that tests execution of a simple jar-file with jexec). Best regards, Matthias From: Baesken, Matthias Sent: Donnerstag, 23. Februar 2017 07:39 To: 'core-libs-dev at openjdk.java.net' > Cc: Langer, Christoph >; Erik Joelsson (erik.joelsson at oracle.com) > Subject: RE: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar Hello, probably I should add the info that the fix is needed in jdk9 as well , not only jdk10 . Without the fix jdk9/10 show this error when executing a small example jar : /myjdk9/images/jdk/lib/jexec /java_test/hellojar/helloworld.jar invalid file (bad magic number): Exec format error with the fix : jdk/lib/jexec /java_test/hellojar/helloworld.jar Hello world from a jar file And btw I really wonder - is jexec still needed in future jdk's like jdk10 ? Seems it is not used much . Best regards, Matthias From: Baesken, Matthias Sent: Mittwoch, 22. Februar 2017 18:16 To: core-libs-dev at openjdk.java.net Cc: Langer, Christoph >; Erik Joelsson (erik.joelsson at oracle.com) > Subject: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar Hello , when looking into the jexec build I noticed that execution of a simple helloworld.jar with jexec does not work any more. I did a little patch for this which adjusted the addition done with CR 8156478: 3 Buffer overrun defect groups in jexec.c . Could I have a review ( just a diff this time is provided because of infrastructure issues) for it ? Thanks, Matthias Bug : https://bugs.openjdk.java.net/browse/JDK-8175000 Diff for jdk10 : # HG changeset patch # User mbaesken # Date 1487782485 -3600 # Wed Feb 22 17:54:45 2017 +0100 # Node ID 93d55a711f3b1c3f282e6889c24d13f16d4a4548 # Parent 884872263accabd4ab68d005abd4e5393144aa4f 8175000: jexec fails to execute simple helloworld.jar diff --git a/src/java.base/unix/native/launcher/jexec.c b/src/java.base/unix/native/launcher/jexec.c --- a/src/java.base/unix/native/launcher/jexec.c +++ b/src/java.base/unix/native/launcher/jexec.c @@ -331,8 +331,9 @@ off_t end = start + xlen; if (end <= count) { - end -= 4; // make sure there are 4 bytes to read at start - while (start < end) { + // make sure there are 4 bytes to read at start + end -= 3; + while ((start < end) && (start < count-3)) { off_t xhid = SH(buf, start); off_t xdlen = SH(buf, start + 2); From shade at redhat.com Wed Mar 1 09:46:48 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 1 Mar 2017 10:46:48 +0100 Subject: Forcing initialization of string concat INDY expressions In-Reply-To: References: Message-ID: <01edff9a-3054-da5b-0663-4f7e01170cf2@redhat.com> Hi, On 03/01/2017 07:36 AM, David Holmes wrote: > The INDY-fication of string concatenation has triggered a problem where a JVM TI > agent's monitor-wait/ed callback hits an error path that uses string concat > which triggers a mass of indy related initialization, which in turn hits monitor > use in MethodType$ConcurrentWeakInternSet.get, which causes the VM monitor > subsystem to be re-entered (and it is not reentrant!) so we crash. (log extract > below - the amount of code to process this is truly scary!) Ouch. This is an unexpected circularity. It is unusual to see Java thread to do Java stuff when doing Object.wait. > I assume I can cover the exact case above by replicating it? But can I > generalize it to cover arbitrary string concat expressions that might arise on > other error paths? Yes, the StringConcatFactory code is deliberately lazy. If you want to link eagerly, you would need to match the concat shape exactly (number and type of arguments) -- probably by using the same concat code the test failed on. We can probably eagerly link some popular concat shapes early during system init, but that requires JDK changes. Looking at stack trace, it seems to be generic failure when adding new MethodType to the MethodType cache. This is not the first time that cache participates in circularities (I wonder if it *always* does). But I am puzzled how does this happen: ... V [jvm.dll+0x2b5412] Runtime1::monitorenter+0x1e2;; ?monitorenter at Runtime1@@CAXPAVJavaThread@@PAVoopDesc@@PAVBasicObjectLock@@@Z+0x1e2 v ~RuntimeStub::monitorenter_nofpu Runtime1 stub J 192 c1 java.lang.invoke.MethodType$ConcurrentWeakInternSet.get(Ljava/lang/Object;)Ljava/lang/Object; java.base at 9-internal (54 bytes) @ 0x0242d7da [0x0242d4c0+0x0000031a] ... It calls RuntimeStub::monitorenter_nofpu destructor? Why it ends up calling into monitorenter? There are no locks in j.l.i.MT$CWIS.get (I checked the bytecode too). If you want a nuclear option for your test, you may want to pass -XDstringConcat:inline to javac to disable indy string concat to bypass that circularity completely. Thanks, -Aleksey From thomas.stuefe at gmail.com Wed Mar 1 11:47:00 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 1 Mar 2017 12:47:00 +0100 Subject: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar In-Reply-To: References: Message-ID: Hi Matthias, the fix makes sense, this is very clearly a bug. I'd suggest a simpler fix though: end -= 4; // make sure there are 4 bytes to read at start - while (start < end) { + while (start <= end) { Note that the code has a diffent bug too, very unlikely but not impossible to hit: 321 ssize_t count = read(fd, buf, CHUNK_SIZE); 322 if (count >= MIN_SIZE) { We attempt to read CHUNK_SIZE bytes and require the read to have returned at least MIN_SIZE (something like 30ish bytes). If not, jexec fails. read may have been interrupted (EINTR) or may have returned less bytes than MIN_SIZE, so it should read in a loop til eof or CHUNK_SIZE bytes are read. Kind Regards, Thomas On Wed, Mar 1, 2017 at 10:23 AM, Baesken, Matthias wrote: > Ping ... > > Can I get a review please for the change ? > > > Thanks, Matthias > > From: Baesken, Matthias > Sent: Donnerstag, 23. Februar 2017 12:28 > To: 'core-libs-dev at openjdk.java.net' > Cc: Langer, Christoph ; Erik Joelsson ( > erik.joelsson at oracle.com) ; 'Michel Trudeau' < > michel.trudeau at oracle.com> > Subject: RE: RFR [XS] : 8175000 : jexec fails to execute simple > helloworld.jar > > Here is the webrev for jdk9 : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8175000/ > > > ? And btw I really wonder - is jexec still needed in future jdk's like > jdk10 ? Seems it is not used much . > > ? > > In case jexec will stay in the jdk I might add a test for the tool as > well, if there is interest ( could not really find one that tests > execution of a simple jar-file with jexec). > > Best regards, Matthias > > > From: Baesken, Matthias > Sent: Donnerstag, 23. Februar 2017 07:39 > To: 'core-libs-dev at openjdk.java.net' > > Cc: Langer, Christoph christoph.langer at sap.com>>; Erik Joelsson (erik.joelsson at oracle.com< > mailto:erik.joelsson at oracle.com>) erik.joelsson at oracle.com>> > Subject: RE: RFR [XS] : 8175000 : jexec fails to execute simple > helloworld.jar > > Hello, probably I should add the info that the fix is needed in jdk9 as > well , not only jdk10 . > > Without the fix jdk9/10 show this error when executing a small > example jar : > > /myjdk9/images/jdk/lib/jexec /java_test/hellojar/helloworld.jar > invalid file (bad magic number): Exec format error > > with the fix : > > jdk/lib/jexec /java_test/hellojar/helloworld.jar > Hello world from a jar file > > > And btw I really wonder - is jexec still needed in future jdk's like > jdk10 ? Seems it is not used much . > > Best regards, Matthias > > > From: Baesken, Matthias > Sent: Mittwoch, 22. Februar 2017 18:16 > To: core-libs-dev at openjdk.java.net > Cc: Langer, Christoph christoph.langer at sap.com>>; Erik Joelsson (erik.joelsson at oracle.com< > mailto:erik.joelsson at oracle.com>) erik.joelsson at oracle.com>> > Subject: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar > > Hello , when looking into the jexec build I noticed that execution of > a simple helloworld.jar with jexec does not work any more. > > I did a little patch for this which adjusted the addition done with CR > 8156478: 3 Buffer overrun defect groups in jexec.c oracle.com/mproxy/repository/technology/java2/jdk9/jdk/rev/4f96129b45ee> > . > > Could I have a review ( just a diff this time is provided because of > infrastructure issues) for it ? > > > Thanks, Matthias > > Bug : > https://bugs.openjdk.java.net/browse/JDK-8175000 > > > Diff for jdk10 : > > # HG changeset patch > # User mbaesken > # Date 1487782485 -3600 > # Wed Feb 22 17:54:45 2017 +0100 > # Node ID 93d55a711f3b1c3f282e6889c24d13f16d4a4548 > # Parent 884872263accabd4ab68d005abd4e5393144aa4f > 8175000: jexec fails to execute simple helloworld.jar > > diff --git a/src/java.base/unix/native/launcher/jexec.c > b/src/java.base/unix/native/launcher/jexec.c > --- a/src/java.base/unix/native/launcher/jexec.c > +++ b/src/java.base/unix/native/launcher/jexec.c > @@ -331,8 +331,9 @@ > off_t end = start + xlen; > > if (end <= count) { > - end -= 4; // make sure there are 4 bytes to read at > start > - while (start < end) { > + // make sure there are 4 bytes to read at start > + end -= 3; > + while ((start < end) && (start < count-3)) { > off_t xhid = SH(buf, start); > off_t xdlen = SH(buf, start + 2); > > From david.holmes at oracle.com Wed Mar 1 12:36:49 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 Mar 2017 22:36:49 +1000 Subject: Forcing initialization of string concat INDY expressions In-Reply-To: <01edff9a-3054-da5b-0663-4f7e01170cf2@redhat.com> References: <01edff9a-3054-da5b-0663-4f7e01170cf2@redhat.com> Message-ID: <8b35c43f-b21f-a8a8-bc2b-4657a9152823@oracle.com> Hi Aleksey, On 1/03/2017 7:46 PM, Aleksey Shipilev wrote: > Hi, > > On 03/01/2017 07:36 AM, David Holmes wrote: >> The INDY-fication of string concatenation has triggered a problem where a JVM TI >> agent's monitor-wait/ed callback hits an error path that uses string concat >> which triggers a mass of indy related initialization, which in turn hits monitor >> use in MethodType$ConcurrentWeakInternSet.get, which causes the VM monitor >> subsystem to be re-entered (and it is not reentrant!) so we crash. (log extract >> below - the amount of code to process this is truly scary!) > > Ouch. This is an unexpected circularity. It is unusual to see Java thread to do > Java stuff when doing Object.wait. That's the fatal flaw in JVM TI. It pretends you can invoke arbitrary Java code via an agent callback. You can invoke simple Java code - as most real callbacks do - but not arbitrary Java code. The VM is not reentrant in some subsystems - like monitors. >> I assume I can cover the exact case above by replicating it? But can I >> generalize it to cover arbitrary string concat expressions that might arise on >> other error paths? > > Yes, the StringConcatFactory code is deliberately lazy. If you want to link > eagerly, you would need to match the concat shape exactly (number and type of > arguments) -- probably by using the same concat code the test failed on. We can > probably eagerly link some popular concat shapes early during system init, but > that requires JDK changes. So I can cover the current failing case easily enough but can't generalize except by covering each case individually. > Looking at stack trace, it seems to be generic failure when adding new > MethodType to the MethodType cache. This is not the first time that cache > participates in circularities (I wonder if it *always* does). But I am puzzled > how does this happen: > > ... > V [jvm.dll+0x2b5412] Runtime1::monitorenter+0x1e2;; > ?monitorenter at Runtime1@@CAXPAVJavaThread@@PAVoopDesc@@PAVBasicObjectLock@@@Z+0x1e2 > v ~RuntimeStub::monitorenter_nofpu Runtime1 stub > J 192 c1 > java.lang.invoke.MethodType$ConcurrentWeakInternSet.get(Ljava/lang/Object;)Ljava/lang/Object; > java.base at 9-internal (54 bytes) @ 0x0242d7da [0x0242d4c0+0x0000031a] > ... > > It calls RuntimeStub::monitorenter_nofpu destructor? Why it ends up calling into > monitorenter? There are no locks in j.l.i.MT$CWIS.get (I checked the bytecode too). get() is compiled so I'm assuming it has inlined something from CHM that does the locking. > If you want a nuclear option for your test, you may want to pass > -XDstringConcat:inline to javac to disable indy string concat to bypass that > circularity completely. Hmmmm ... that is worth thinking about. Thanks, David > Thanks, > -Aleksey > From kim.barrett at oracle.com Wed Mar 1 14:42:53 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 1 Mar 2017 09:42:53 -0500 Subject: 10 RFR: 8150687: typedefs without type names In-Reply-To: <207B8FE0-0F63-40E2-AA8D-98266EFC45D4@oracle.com> References: <33F5BF24-5892-4E14-962D-09CEF2F92FDB@oracle.com> <2e8caf41-32a2-c060-4a69-53cb89ab2fe8@oracle.com> <207B8FE0-0F63-40E2-AA8D-98266EFC45D4@oracle.com> Message-ID: <7E74AAA9-9DD0-4555-96A6-908773C34BF1@oracle.com> > On Feb 28, 2017, at 9:20 PM, Brian Burkhalter wrote: > > +1 > > Brian > > On Feb 28, 2017, at 6:05 PM, David Holmes wrote: > >> Hi Kim, >> >> nio-dev should look at this - cc'd. >> >> But looks fine to me. :) >> >> David >> >> On 1/03/2017 11:56 AM, Kim Barrett wrote: >>> Please review this small change, removing unnecessary uses of "typedef" that lead to warnings from Visual Studio 2015. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8150687 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~kbarrett/8150687/jdk.00/ >>> >>> Testing: >>> jprt Thanks, David and Brian. From claes.redestad at oracle.com Wed Mar 1 15:34:17 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 1 Mar 2017 15:34:17 +0000 Subject: [10] RFR: 8176041: Optimize handling of comment lines in Properties$LineReader.readLine Message-ID: <102d6fc7-921e-4c39-ee9a-00ebfdd624ac@oracle.com> Hi, the properties line reader has some relevance to startup, e.g., when reading the java.security file, and as more documentation content has been added to this file it has been made apparent that the handling of comment lines is inefficient due to treating every character after a comment line marker ('#' or '!') as any other character (writes it to an internal buffer etc) when a fast-path consuming the rest of the line would do. Bug: https://bugs.openjdk.java.net/browse/JDK-8176041 Webrev: http://cr.openjdk.java.net/~redestad/8176041/jdk.01 This cuts off ~1ms from startup on apps that read the java.security property file, and while this is tailored to improve performance in interpreted code during startup there's also a reasonable speedup in JIT:ed code. (As this is actually resolving an extremely small regression in 9 due to the java.security file having grown, it's likely too late and minor to go into 9..) Thanks! /Claes From shade at redhat.com Wed Mar 1 15:40:58 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 1 Mar 2017 16:40:58 +0100 Subject: [10] RFR: 8176041: Optimize handling of comment lines in Properties$LineReader.readLine In-Reply-To: <102d6fc7-921e-4c39-ee9a-00ebfdd624ac@oracle.com> References: <102d6fc7-921e-4c39-ee9a-00ebfdd624ac@oracle.com> Message-ID: On 03/01/2017 04:34 PM, Claes Redestad wrote: > the properties line reader has some relevance to startup, e.g., > when reading the java.security file, and as more documentation > content has been added to this file it has been made apparent > that the handling of comment lines is inefficient due to treating > every character after a comment line marker ('#' or '!') as any > other character (writes it to an internal buffer etc) when a > fast-path consuming the rest of the line would do. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8176041 > Webrev: http://cr.openjdk.java.net/~redestad/8176041/jdk.01 The idea looks fine. I think you can go further and unswitch the loop, saving branch in a hot loop, and using byte comparisons (may require some work to do efficient byte-char comparisons): if (inStream != null) { while (inOff < inLimit) { byte b = inByteBuf[inOff++]; if (b == '\n' || b == '\r' || b == '\\') { break; } } } else { while (inOff < inLimit) { c = inCharBuf[inOff++]; if (c == '\n' || c == '\r' || c == '\\') { break; } } } Thanks, -Aleksey From matthias.baesken at sap.com Wed Mar 1 16:07:35 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 1 Mar 2017 16:07:35 +0000 Subject: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar In-Reply-To: References: Message-ID: <634120435d0d4814969a0c28c3b14f07@DEWDFE13DE14.global.corp.sap> Hi Thomas , thanks for looking into it . I suggest to handle the read issue in another bug because this one just deals with ?jexec fails to execute simple helloworld.jar? . ( there seem to be a few other read(?) calls in the jdk code base to consider as well ) Can we push the existing change ? Regards, Matthias From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: Mittwoch, 1. M?rz 2017 12:47 To: Baesken, Matthias Cc: core-libs-dev at openjdk.java.net; Simonis, Volker Subject: Re: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar Hi Matthias, the fix makes sense, this is very clearly a bug. I'd suggest a simpler fix though: end -= 4; // make sure there are 4 bytes to read at start - while (start < end) { + while (start <= end) { Note that the code has a diffent bug too, very unlikely but not impossible to hit: 321 ssize_t count = read(fd, buf, CHUNK_SIZE); 322 if (count >= MIN_SIZE) { We attempt to read CHUNK_SIZE bytes and require the read to have returned at least MIN_SIZE (something like 30ish bytes). If not, jexec fails. read may have been interrupted (EINTR) or may have returned less bytes than MIN_SIZE, so it should read in a loop til eof or CHUNK_SIZE bytes are read. Kind Regards, Thomas On Wed, Mar 1, 2017 at 10:23 AM, Baesken, Matthias > wrote: Ping ... Can I get a review please for the change ? Thanks, Matthias From: Baesken, Matthias Sent: Donnerstag, 23. Februar 2017 12:28 To: 'core-libs-dev at openjdk.java.net' > Cc: Langer, Christoph >; Erik Joelsson (erik.joelsson at oracle.com) >; 'Michel Trudeau' > Subject: RE: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar Here is the webrev for jdk9 : http://cr.openjdk.java.net/~mbaesken/webrevs/8175000/ ? And btw I really wonder - is jexec still needed in future jdk's like jdk10 ? Seems it is not used much . ? In case jexec will stay in the jdk I might add a test for the tool as well, if there is interest ( could not really find one that tests execution of a simple jar-file with jexec). Best regards, Matthias From: Baesken, Matthias Sent: Donnerstag, 23. Februar 2017 07:39 To: 'core-libs-dev at openjdk.java.net' >> Cc: Langer, Christoph >>; Erik Joelsson (erik.joelsson at oracle.com>) >> Subject: RE: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar Hello, probably I should add the info that the fix is needed in jdk9 as well , not only jdk10 . Without the fix jdk9/10 show this error when executing a small example jar : /myjdk9/images/jdk/lib/jexec /java_test/hellojar/helloworld.jar invalid file (bad magic number): Exec format error with the fix : jdk/lib/jexec /java_test/hellojar/helloworld.jar Hello world from a jar file And btw I really wonder - is jexec still needed in future jdk's like jdk10 ? Seems it is not used much . Best regards, Matthias From: Baesken, Matthias Sent: Mittwoch, 22. Februar 2017 18:16 To: core-libs-dev at openjdk.java.net> Cc: Langer, Christoph >>; Erik Joelsson (erik.joelsson at oracle.com>) >> Subject: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar Hello , when looking into the jexec build I noticed that execution of a simple helloworld.jar with jexec does not work any more. I did a little patch for this which adjusted the addition done with CR 8156478: 3 Buffer overrun defect groups in jexec.c . Could I have a review ( just a diff this time is provided because of infrastructure issues) for it ? Thanks, Matthias Bug : https://bugs.openjdk.java.net/browse/JDK-8175000 Diff for jdk10 : # HG changeset patch # User mbaesken # Date 1487782485 -3600 # Wed Feb 22 17:54:45 2017 +0100 # Node ID 93d55a711f3b1c3f282e6889c24d13f16d4a4548 # Parent 884872263accabd4ab68d005abd4e5393144aa4f 8175000: jexec fails to execute simple helloworld.jar diff --git a/src/java.base/unix/native/launcher/jexec.c b/src/java.base/unix/native/launcher/jexec.c --- a/src/java.base/unix/native/launcher/jexec.c +++ b/src/java.base/unix/native/launcher/jexec.c @@ -331,8 +331,9 @@ off_t end = start + xlen; if (end <= count) { - end -= 4; // make sure there are 4 bytes to read at start - while (start < end) { + // make sure there are 4 bytes to read at start + end -= 3; + while ((start < end) && (start < count-3)) { off_t xhid = SH(buf, start); off_t xdlen = SH(buf, start + 2); From claes.redestad at oracle.com Wed Mar 1 17:11:40 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 1 Mar 2017 17:11:40 +0000 Subject: [10] RFR: 8176041: Optimize handling of comment lines in Properties$LineReader.readLine In-Reply-To: References: <102d6fc7-921e-4c39-ee9a-00ebfdd624ac@oracle.com> Message-ID: <1e2dae22-8f07-61a9-4ad6-791cb95d627e@oracle.com> Hi Aleksey! On 03/01/2017 03:40 PM, Aleksey Shipilev wrote: > On 03/01/2017 04:34 PM, Claes Redestad wrote: >> the properties line reader has some relevance to startup, e.g., >> when reading the java.security file, and as more documentation >> content has been added to this file it has been made apparent >> that the handling of comment lines is inefficient due to treating >> every character after a comment line marker ('#' or '!') as any >> other character (writes it to an internal buffer etc) when a >> fast-path consuming the rest of the line would do. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8176041 >> Webrev: http://cr.openjdk.java.net/~redestad/8176041/jdk.01 > The idea looks fine. > > I think you can go further and unswitch the loop, saving branch in a hot loop, > and using byte comparisons (may require some work to do efficient byte-char > comparisons): > > if (inStream != null) { > while (inOff < inLimit) { > byte b = inByteBuf[inOff++]; > if (b == '\n' || b == '\r' || b == '\\') { > break; > } > } > } else { > while (inOff < inLimit) { > c = inCharBuf[inOff++]; > if (c == '\n' || c == '\r' || c == '\\') { > break; > } > } > } Sure, with a bit of fix-up this drops another 170k executed bytecodes to read in the java.security file (original: 1882k, now: 980k): http://cr.openjdk.java.net/~redestad/8176041/jdk.02/ It seems javac optimizes byte-char comparisons pretty well in this case since the chars we're comparing against are all in the 0-127 range, so I don't think there's much we can do: 256: getfield #7 // Field inByteBuf:[B 259: aload_0 260: dup 261: getfield #5 // Field inOff:I 264: dup_x1 265: iconst_1 266: iadd 267: putfield #5 // Field inOff:I 270: baload 271: istore 9 273: iload 9 275: bipush 10 <- '\n' 277: if_icmpeq 294 280: iload 9 282: bipush 13 <- '\r' 284: if_icmpeq 294 287: iload 9 289: bipush 92 <- '\\' Thanks! /Claes > > Thanks, > -Aleksey > From thomas.stuefe at gmail.com Wed Mar 1 17:14:47 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 1 Mar 2017 18:14:47 +0100 Subject: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar In-Reply-To: <634120435d0d4814969a0c28c3b14f07@DEWDFE13DE14.global.corp.sap> References: <634120435d0d4814969a0c28c3b14f07@DEWDFE13DE14.global.corp.sap> Message-ID: Hi Matthias, On Wed, Mar 1, 2017 at 5:07 PM, Baesken, Matthias wrote: > Hi Thomas , thanks for looking into it . > > > > I suggest to handle the read issue in another bug because this one just > deals with ?jexec fails to execute simple helloworld.jar? . > > > > ( there seem to be a few other read(?) calls in the jdk code base to > consider as well ) > > > > Can we push the existing change ? > > > Not a Reviewer, so it is not for me to decide. Someone from core libs should look at this. ...Thomas > Regards, Matthias > > > > > > *From:* Thomas St?fe [mailto:thomas.stuefe at gmail.com] > *Sent:* Mittwoch, 1. M?rz 2017 12:47 > *To:* Baesken, Matthias > *Cc:* core-libs-dev at openjdk.java.net; Simonis, Volker < > volker.simonis at sap.com> > *Subject:* Re: RFR [XS] : 8175000 : jexec fails to execute simple > helloworld.jar > > > > Hi Matthias, > > > > the fix makes sense, this is very clearly a bug. > > I'd suggest a simpler fix though: > > end -= 4; // make sure there are 4 bytes to read at > start > - while (start < end) { > + while (start <= end) { > > Note that the code has a diffent bug too, very unlikely but not impossible > to hit: > > 321 ssize_t count = read(fd, buf, CHUNK_SIZE); > 322 if (count >= MIN_SIZE) { > > We attempt to read CHUNK_SIZE bytes and require the read to have returned > at least MIN_SIZE (something like 30ish bytes). If not, jexec fails. > > read may have been interrupted (EINTR) or may have returned less bytes > than MIN_SIZE, so it should read in a loop til eof or CHUNK_SIZE bytes are > read. > > Kind Regards, Thomas > > > > > > On Wed, Mar 1, 2017 at 10:23 AM, Baesken, Matthias < > matthias.baesken at sap.com> wrote: > > Ping ... > > Can I get a review please for the change ? > > > Thanks, Matthias > > From: Baesken, Matthias > Sent: Donnerstag, 23. Februar 2017 12:28 > To: 'core-libs-dev at openjdk.java.net' > Cc: Langer, Christoph ; Erik Joelsson ( > erik.joelsson at oracle.com) ; 'Michel Trudeau' < > michel.trudeau at oracle.com> > Subject: RE: RFR [XS] : 8175000 : jexec fails to execute simple > helloworld.jar > > Here is the webrev for jdk9 : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8175000/ > > > ? And btw I really wonder - is jexec still needed in future jdk's like > jdk10 ? Seems it is not used much . > > ? > > In case jexec will stay in the jdk I might add a test for the tool as > well, if there is interest ( could not really find one that tests > execution of a simple jar-file with jexec). > > Best regards, Matthias > > > From: Baesken, Matthias > Sent: Donnerstag, 23. Februar 2017 07:39 > To: 'core-libs-dev at openjdk.java.net' > > > Cc: Langer, Christoph christoph.langer at sap.com>>; Erik Joelsson (erik.joelsson at oracle.com< > mailto:erik.joelsson at oracle.com>) erik.joelsson at oracle.com>> > Subject: RE: RFR [XS] : 8175000 : jexec fails to execute simple > helloworld.jar > > Hello, probably I should add the info that the fix is needed in jdk9 as > well , not only jdk10 . > > Without the fix jdk9/10 show this error when executing a small > example jar : > > /myjdk9/images/jdk/lib/jexec /java_test/hellojar/helloworld.jar > invalid file (bad magic number): Exec format error > > with the fix : > > jdk/lib/jexec /java_test/hellojar/helloworld.jar > Hello world from a jar file > > > And btw I really wonder - is jexec still needed in future jdk's like > jdk10 ? Seems it is not used much . > > Best regards, Matthias > > > From: Baesken, Matthias > Sent: Mittwoch, 22. Februar 2017 18:16 > To: core-libs-dev at openjdk.java.net > Cc: Langer, Christoph christoph.langer at sap.com>>; Erik Joelsson (erik.joelsson at oracle.com< > mailto:erik.joelsson at oracle.com>) erik.joelsson at oracle.com>> > Subject: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar > > Hello , when looking into the jexec build I noticed that execution of > a simple helloworld.jar with jexec does not work any more. > > I did a little patch for this which adjusted the addition done with CR > 8156478: 3 Buffer overrun defect groups in jexec.c oracle.com/mproxy/repository/technology/java2/jdk9/jdk/rev/4f96129b45ee> > . > > Could I have a review ( just a diff this time is provided because of > infrastructure issues) for it ? > > > Thanks, Matthias > > Bug : > https://bugs.openjdk.java.net/browse/JDK-8175000 > > > Diff for jdk10 : > > # HG changeset patch > # User mbaesken > # Date 1487782485 -3600 > # Wed Feb 22 17:54:45 2017 +0100 > # Node ID 93d55a711f3b1c3f282e6889c24d13f16d4a4548 > # Parent 884872263accabd4ab68d005abd4e5393144aa4f > 8175000: jexec fails to execute simple helloworld.jar > > diff --git a/src/java.base/unix/native/launcher/jexec.c > b/src/java.base/unix/native/launcher/jexec.c > --- a/src/java.base/unix/native/launcher/jexec.c > +++ b/src/java.base/unix/native/launcher/jexec.c > @@ -331,8 +331,9 @@ > off_t end = start + xlen; > > if (end <= count) { > - end -= 4; // make sure there are 4 bytes to read at > start > - while (start < end) { > + // make sure there are 4 bytes to read at start > + end -= 3; > + while ((start < end) && (start < count-3)) { > off_t xhid = SH(buf, start); > off_t xdlen = SH(buf, start + 2); > > > From shade at redhat.com Wed Mar 1 17:17:45 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 1 Mar 2017 18:17:45 +0100 Subject: [10] RFR: 8176041: Optimize handling of comment lines in Properties$LineReader.readLine In-Reply-To: <1e2dae22-8f07-61a9-4ad6-791cb95d627e@oracle.com> References: <102d6fc7-921e-4c39-ee9a-00ebfdd624ac@oracle.com> <1e2dae22-8f07-61a9-4ad6-791cb95d627e@oracle.com> Message-ID: <0acfb3e5-7198-47f8-8035-818348cef884@redhat.com> On 03/01/2017 06:11 PM, Claes Redestad wrote: > Sure, with a bit of fix-up this drops another 170k executed bytecodes > to read in the java.security file (original: 1882k, now: 980k): > > http://cr.openjdk.java.net/~redestad/8176041/jdk.02/ Ok, that's fine. This is slightly more idiomatic, you might want to change before pushing: c = (char)(b & 0xFF); Thanks, -Aleksey From xueming.shen at oracle.com Wed Mar 1 17:32:54 2017 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 1 Mar 2017 09:32:54 -0800 Subject: [10] RFR: 8176041: Optimize handling of comment lines in Properties$LineReader.readLine In-Reply-To: <1e2dae22-8f07-61a9-4ad6-791cb95d627e@oracle.com> References: <102d6fc7-921e-4c39-ee9a-00ebfdd624ac@oracle.com> <1e2dae22-8f07-61a9-4ad6-791cb95d627e@oracle.com> Message-ID: +1 On 3/1/17 9:11 AM, Claes Redestad wrote: > Hi Aleksey! > > On 03/01/2017 03:40 PM, Aleksey Shipilev wrote: >> On 03/01/2017 04:34 PM, Claes Redestad wrote: >>> the properties line reader has some relevance to startup, e.g., >>> when reading the java.security file, and as more documentation >>> content has been added to this file it has been made apparent >>> that the handling of comment lines is inefficient due to treating >>> every character after a comment line marker ('#' or '!') as any >>> other character (writes it to an internal buffer etc) when a >>> fast-path consuming the rest of the line would do. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8176041 >>> Webrev: http://cr.openjdk.java.net/~redestad/8176041/jdk.01 >> The idea looks fine. >> >> I think you can go further and unswitch the loop, saving branch in a >> hot loop, >> and using byte comparisons (may require some work to do efficient >> byte-char >> comparisons): >> >> if (inStream != null) { >> while (inOff < inLimit) { >> byte b = inByteBuf[inOff++]; >> if (b == '\n' || b == '\r' || b == '\\') { >> break; >> } >> } >> } else { >> while (inOff < inLimit) { >> c = inCharBuf[inOff++]; >> if (c == '\n' || c == '\r' || c == '\\') { >> break; >> } >> } >> } > > Sure, with a bit of fix-up this drops another 170k executed bytecodes > to read in the java.security file (original: 1882k, now: 980k): > > http://cr.openjdk.java.net/~redestad/8176041/jdk.02/ > > It seems javac optimizes byte-char comparisons pretty well in this > case since the chars we're comparing against are all in the 0-127 range, > so I don't think there's much we can do: > > 256: getfield #7 // Field inByteBuf:[B > 259: aload_0 > 260: dup > 261: getfield #5 // Field inOff:I > 264: dup_x1 > 265: iconst_1 > 266: iadd > 267: putfield #5 // Field inOff:I > 270: baload > 271: istore 9 > 273: iload 9 > 275: bipush 10 <- '\n' > 277: if_icmpeq 294 > 280: iload 9 > 282: bipush 13 <- '\r' > 284: if_icmpeq 294 > 287: iload 9 > 289: bipush 92 <- '\\' > > Thanks! > > /Claes > >> >> Thanks, >> -Aleksey >> > From henry.jen at oracle.com Wed Mar 1 17:42:01 2017 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 1 Mar 2017 09:42:01 -0800 Subject: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar In-Reply-To: References: Message-ID: > On Mar 1, 2017, at 3:47 AM, Thomas St?fe wrote: > > Hi Matthias, > > the fix makes sense, this is very clearly a bug. > > I'd suggest a simpler fix though: > > end -= 4; // make sure there are 4 bytes to read at > start > - while (start < end) { > + while (start <= end) { > +1. Cheers, Henry > Note that the code has a diffent bug too, very unlikely but not impossible > to hit: > > 321 ssize_t count = read(fd, buf, CHUNK_SIZE); > 322 if (count >= MIN_SIZE) { > > We attempt to read CHUNK_SIZE bytes and require the read to have returned > at least MIN_SIZE (something like 30ish bytes). If not, jexec fails. > > read may have been interrupted (EINTR) or may have returned less bytes than > MIN_SIZE, so it should read in a loop til eof or CHUNK_SIZE bytes are read. > > Kind Regards, Thomas > > > On Wed, Mar 1, 2017 at 10:23 AM, Baesken, Matthias > wrote: > >> Ping ... >> >> Can I get a review please for the change ? >> >> >> Thanks, Matthias >> >> From: Baesken, Matthias >> Sent: Donnerstag, 23. Februar 2017 12:28 >> To: 'core-libs-dev at openjdk.java.net' >> Cc: Langer, Christoph ; Erik Joelsson ( >> erik.joelsson at oracle.com) ; 'Michel Trudeau' < >> michel.trudeau at oracle.com> >> Subject: RE: RFR [XS] : 8175000 : jexec fails to execute simple >> helloworld.jar >> >> Here is the webrev for jdk9 : >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8175000/ >> >> >> ? And btw I really wonder - is jexec still needed in future jdk's like >> jdk10 ? Seems it is not used much . >> >> ? >> >> In case jexec will stay in the jdk I might add a test for the tool as >> well, if there is interest ( could not really find one that tests >> execution of a simple jar-file with jexec). >> >> Best regards, Matthias >> >> >> From: Baesken, Matthias >> Sent: Donnerstag, 23. Februar 2017 07:39 >> To: 'core-libs-dev at openjdk.java.net' > > >> Cc: Langer, Christoph > christoph.langer at sap.com>>; Erik Joelsson (erik.joelsson at oracle.com< >> mailto:erik.joelsson at oracle.com>) > erik.joelsson at oracle.com>> >> Subject: RE: RFR [XS] : 8175000 : jexec fails to execute simple >> helloworld.jar >> >> Hello, probably I should add the info that the fix is needed in jdk9 as >> well , not only jdk10 . >> >> Without the fix jdk9/10 show this error when executing a small >> example jar : >> >> /myjdk9/images/jdk/lib/jexec /java_test/hellojar/helloworld.jar >> invalid file (bad magic number): Exec format error >> >> with the fix : >> >> jdk/lib/jexec /java_test/hellojar/helloworld.jar >> Hello world from a jar file >> >> >> And btw I really wonder - is jexec still needed in future jdk's like >> jdk10 ? Seems it is not used much . >> >> Best regards, Matthias >> >> >> From: Baesken, Matthias >> Sent: Mittwoch, 22. Februar 2017 18:16 >> To: core-libs-dev at openjdk.java.net >> Cc: Langer, Christoph > christoph.langer at sap.com>>; Erik Joelsson (erik.joelsson at oracle.com< >> mailto:erik.joelsson at oracle.com>) > erik.joelsson at oracle.com>> >> Subject: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar >> >> Hello , when looking into the jexec build I noticed that execution of >> a simple helloworld.jar with jexec does not work any more. >> >> I did a little patch for this which adjusted the addition done with CR >> 8156478: 3 Buffer overrun defect groups in jexec.c> oracle.com/mproxy/repository/technology/java2/jdk9/jdk/rev/4f96129b45ee> >> . >> >> Could I have a review ( just a diff this time is provided because of >> infrastructure issues) for it ? >> >> >> Thanks, Matthias >> >> Bug : >> https://bugs.openjdk.java.net/browse/JDK-8175000 >> >> >> Diff for jdk10 : >> >> # HG changeset patch >> # User mbaesken >> # Date 1487782485 -3600 >> # Wed Feb 22 17:54:45 2017 +0100 >> # Node ID 93d55a711f3b1c3f282e6889c24d13f16d4a4548 >> # Parent 884872263accabd4ab68d005abd4e5393144aa4f >> 8175000: jexec fails to execute simple helloworld.jar >> >> diff --git a/src/java.base/unix/native/launcher/jexec.c >> b/src/java.base/unix/native/launcher/jexec.c >> --- a/src/java.base/unix/native/launcher/jexec.c >> +++ b/src/java.base/unix/native/launcher/jexec.c >> @@ -331,8 +331,9 @@ >> off_t end = start + xlen; >> >> if (end <= count) { >> - end -= 4; // make sure there are 4 bytes to read at >> start >> - while (start < end) { >> + // make sure there are 4 bytes to read at start >> + end -= 3; >> + while ((start < end) && (start < count-3)) { >> off_t xhid = SH(buf, start); >> off_t xdlen = SH(buf, start + 2); >> >> From kumar.x.srinivasan at oracle.com Wed Mar 1 17:51:00 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 01 Mar 2017 09:51:00 -0800 Subject: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar In-Reply-To: References: <634120435d0d4814969a0c28c3b14f07@DEWDFE13DE14.global.corp.sap> Message-ID: <58B70A04.4010807@oracle.com> Hi Baesken, Thanks for fixing this, BUT...... Has this been tested on other platforms, especially on both the Endian platforms. I think we should have a simplistic regression test for this in jdk/test/tools/launcher area, until we EOL this. Once we have that then we need to test this on all platforms. So I will write a test, and test this change, through our test and build system, please hold off until then. Thanks Kumar > Hi Matthias, > > On Wed, Mar 1, 2017 at 5:07 PM, Baesken, Matthias > > wrote: > > Hi Thomas , thanks for looking into it . > > I suggest to handle the read issue in another bug because this > one just deals with ?jexec fails to execute simple helloworld.jar? . > > ( there seem to be a few other read(?) calls in the jdk code > base to consider as well ) > > Can we push the existing change ? > > > Not a Reviewer, so it is not for me to decide. Someone from core libs > should look at this. > > ...Thomas > > Regards, Matthias > > *From:*Thomas St?fe [mailto:thomas.stuefe at gmail.com > ] > *Sent:* Mittwoch, 1. M?rz 2017 12:47 > *To:* Baesken, Matthias > > *Cc:* core-libs-dev at openjdk.java.net > ; Simonis, Volker > > > *Subject:* Re: RFR [XS] : 8175000 : jexec fails to execute simple > helloworld.jar > > Hi Matthias, > > the fix makes sense, this is very clearly a bug. > > I'd suggest a simpler fix though: > > end -= 4; // make sure there are 4 bytes to > read at start > - while (start < end) { > + while (start <= end) { > > Note that the code has a diffent bug too, very unlikely but not > impossible to hit: > > 321 ssize_t count = read(fd, buf, CHUNK_SIZE); > 322 if (count >= MIN_SIZE) { > > We attempt to read CHUNK_SIZE bytes and require the read to have > returned at least MIN_SIZE (something like 30ish bytes). If not, > jexec fails. > > read may have been interrupted (EINTR) or may have returned less > bytes than MIN_SIZE, so it should read in a loop til eof or > CHUNK_SIZE bytes are read. > > Kind Regards, Thomas > > On Wed, Mar 1, 2017 at 10:23 AM, Baesken, Matthias > > wrote: > > Ping ... > > Can I get a review please for the change ? > > > Thanks, Matthias > > From: Baesken, Matthias > Sent: Donnerstag, 23. Februar 2017 12:28 > To: 'core-libs-dev at openjdk.java.net > ' > > > Cc: Langer, Christoph >; Erik Joelsson > (erik.joelsson at oracle.com ) > >; > 'Michel Trudeau' > > Subject: RE: RFR [XS] : 8175000 : jexec fails to execute > simple helloworld.jar > > Here is the webrev for jdk9 : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8175000/ > > > > ? And btw I really wonder - is jexec still needed in future > jdk's like jdk10 ? Seems it is not used much . > > ? > > In case jexec will stay in the jdk I might add a test for > the tool as well, if there is interest ( could not really > find one that tests execution of a simple jar-file with jexec). > > Best regards, Matthias > > > From: Baesken, Matthias > Sent: Donnerstag, 23. Februar 2017 07:39 > To: 'core-libs-dev at openjdk.java.net > ' > >> > > Cc: Langer, Christoph >>; Erik Joelsson > (erik.joelsson at oracle.com > >) >> > Subject: RE: RFR [XS] : 8175000 : jexec fails to execute > simple helloworld.jar > > Hello, probably I should add the info that the fix is needed > in jdk9 as well , not only jdk10 . > > Without the fix jdk9/10 show this error when executing a > small example jar : > > /myjdk9/images/jdk/lib/jexec /java_test/hellojar/helloworld.jar > invalid file (bad magic number): Exec format error > > with the fix : > > jdk/lib/jexec /java_test/hellojar/helloworld.jar > Hello world from a jar file > > > And btw I really wonder - is jexec still needed in future > jdk's like jdk10 ? Seems it is not used much . > > Best regards, Matthias > > > From: Baesken, Matthias > Sent: Mittwoch, 22. Februar 2017 18:16 > To: core-libs-dev at openjdk.java.net > > > Cc: Langer, Christoph >>; Erik Joelsson > (erik.joelsson at oracle.com > >) >> > Subject: RFR [XS] : 8175000 : jexec fails to execute simple > helloworld.jar > > Hello , when looking into the jexec build I noticed that > execution of a simple helloworld.jar with jexec does not > work any more. > > I did a little patch for this which adjusted the addition done > with CR 8156478: 3 Buffer overrun defect groups in > jexec.c > > . > > Could I have a review ( just a diff this time is provided > because of infrastructure issues) for it ? > > > Thanks, Matthias > > Bug : > https://bugs.openjdk.java.net/browse/JDK-8175000 > > > > Diff for jdk10 : > > # HG changeset patch > # User mbaesken > # Date 1487782485 -3600 > # Wed Feb 22 17:54:45 2017 +0100 > # Node ID 93d55a711f3b1c3f282e6889c24d13f16d4a4548 > # Parent 884872263accabd4ab68d005abd4e5393144aa4f > 8175000: jexec fails to execute simple helloworld.jar > > diff --git a/src/java.base/unix/native/launcher/jexec.c > b/src/java.base/unix/native/launcher/jexec.c > --- a/src/java.base/unix/native/launcher/jexec.c > +++ b/src/java.base/unix/native/launcher/jexec.c > @@ -331,8 +331,9 @@ > off_t end = start + xlen; > > if (end <= count) { > - end -= 4; // make sure there are 4 bytes > to read at start > - while (start < end) { > + // make sure there are 4 bytes to read at > start > + end -= 3; > + while ((start < end) && (start < count-3)) { > off_t xhid = SH(buf, start); > off_t xdlen = SH(buf, start + 2); > > From forax at univ-mlv.fr Wed Mar 1 17:54:44 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 1 Mar 2017 18:54:44 +0100 (CET) Subject: Forcing initialization of string concat INDY expressions In-Reply-To: <8b35c43f-b21f-a8a8-bc2b-4657a9152823@oracle.com> References: <01edff9a-3054-da5b-0663-4f7e01170cf2@redhat.com> <8b35c43f-b21f-a8a8-bc2b-4657a9152823@oracle.com> Message-ID: <1561498070.1640638.1488390884041.JavaMail.zimbra@u-pem.fr> The worst thing here is that conceptually, for an invokedynamic, the implementation do not use the fact that MethodTypes are interned. Only a direct call to a method handle (with invokeExact/invoke) needs MethodTypes to be interned to speedup the test that verifies that the parameter types are compatible. One way to solve that is to not use the cache when creating a MethodType but only when invoking a method handle directly. A MethodHandle can have two fields, one storing the non-interned method type (which is final) and one storing the corresponding interned method type (which is @Stable) and computed it if the pointer check of an invokeExact check fail because mh.invokeExact(desc) if (mh.internedMethodType == desc.methodType) { // fastpath } if (mh.internedMethodType == null) { mh.internedMethodType = intern(mh.type); if (mh.internedMethodType == desc.methodType) { // fastpath } } ... R?mi ----- Mail original ----- > De: "David Holmes" > ?: "Aleksey Shipilev" , "core-libs-dev Libs" > Envoy?: Mercredi 1 Mars 2017 13:36:49 > Objet: Re: Forcing initialization of string concat INDY expressions > Hi Aleksey, > > On 1/03/2017 7:46 PM, Aleksey Shipilev wrote: >> Hi, >> >> On 03/01/2017 07:36 AM, David Holmes wrote: >>> The INDY-fication of string concatenation has triggered a problem where a JVM TI >>> agent's monitor-wait/ed callback hits an error path that uses string concat >>> which triggers a mass of indy related initialization, which in turn hits monitor >>> use in MethodType$ConcurrentWeakInternSet.get, which causes the VM monitor >>> subsystem to be re-entered (and it is not reentrant!) so we crash. (log extract >>> below - the amount of code to process this is truly scary!) >> >> Ouch. This is an unexpected circularity. It is unusual to see Java thread to do >> Java stuff when doing Object.wait. > > That's the fatal flaw in JVM TI. It pretends you can invoke arbitrary > Java code via an agent callback. You can invoke simple Java code - as > most real callbacks do - but not arbitrary Java code. The VM is not > reentrant in some subsystems - like monitors. > >>> I assume I can cover the exact case above by replicating it? But can I >>> generalize it to cover arbitrary string concat expressions that might arise on >>> other error paths? >> >> Yes, the StringConcatFactory code is deliberately lazy. If you want to link >> eagerly, you would need to match the concat shape exactly (number and type of >> arguments) -- probably by using the same concat code the test failed on. We can >> probably eagerly link some popular concat shapes early during system init, but >> that requires JDK changes. > > So I can cover the current failing case easily enough but can't > generalize except by covering each case individually. > >> Looking at stack trace, it seems to be generic failure when adding new >> MethodType to the MethodType cache. This is not the first time that cache >> participates in circularities (I wonder if it *always* does). But I am puzzled >> how does this happen: >> >> ... >> V [jvm.dll+0x2b5412] Runtime1::monitorenter+0x1e2;; >> ?monitorenter at Runtime1@@CAXPAVJavaThread@@PAVoopDesc@@PAVBasicObjectLock@@@Z+0x1e2 >> v ~RuntimeStub::monitorenter_nofpu Runtime1 stub >> J 192 c1 >> java.lang.invoke.MethodType$ConcurrentWeakInternSet.get(Ljava/lang/Object;)Ljava/lang/Object; >> java.base at 9-internal (54 bytes) @ 0x0242d7da [0x0242d4c0+0x0000031a] >> ... >> >> It calls RuntimeStub::monitorenter_nofpu destructor? Why it ends up calling into >> monitorenter? There are no locks in j.l.i.MT$CWIS.get (I checked the bytecode >> too). > > get() is compiled so I'm assuming it has inlined something from CHM that > does the locking. > >> If you want a nuclear option for your test, you may want to pass >> -XDstringConcat:inline to javac to disable indy string concat to bypass that >> circularity completely. > > Hmmmm ... that is worth thinking about. > > Thanks, > David > >> Thanks, >> -Aleksey From mpaluch at paluch.biz Wed Mar 1 21:14:04 2017 From: mpaluch at paluch.biz (mp911de) Date: Wed, 1 Mar 2017 14:14:04 -0700 (MST) Subject: Proposal: java.lang.reflect.Proxy and default methods In-Reply-To: <33B3EDCF-65C6-4991-A635-084B157A9D27@gmail.com> References: <4408a730-3f91-fe39-ef3f-b8ac00c1391c@gmail.com> <6F6ED6C5-9324-40F2-AE9A-E5BB15277733@oracle.com> <33B3EDCF-65C6-4991-A635-084B157A9D27@gmail.com> Message-ID: <1488402844432-300249.post@n7.nabble.com> Is there any progress on this issue? In the light of Java 9, the workaround with MethodHandles.lookup()/unreflectSpecial does not work anymore because MethodHandles is encapsulated and calling setAccessible(true) on the constructor fails. Resolving method handles inside the same module seems to work with public lookup, but as soon as a module defines an interface with default methods and this interface is called by a proxy handler that comes from a different module, it's no longer possible to resolve the MethodHandle. Is this the appropriate mailing list for this case? -- View this message in context: http://openjdk.5641.n7.nabble.com/Proposal-java-lang-reflect-Proxy-and-default-methods-tp273894p300249.html Sent from the OpenJDK Core Libraries mailing list archive at Nabble.com. From stevenschlansker at gmail.com Wed Mar 1 21:34:59 2017 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Wed, 1 Mar 2017 13:34:59 -0800 Subject: Proposal: java.lang.reflect.Proxy and default methods In-Reply-To: <1488402844432-300249.post@n7.nabble.com> References: <4408a730-3f91-fe39-ef3f-b8ac00c1391c@gmail.com> <6F6ED6C5-9324-40F2-AE9A-E5BB15277733@oracle.com> <33B3EDCF-65C6-4991-A635-084B157A9D27@gmail.com> <1488402844432-300249.post@n7.nabble.com> Message-ID: > On Mar 1, 2017, at 1:14 PM, mp911de wrote: > > Is there any progress on this issue? In the light of Java 9, the workaround > with > MethodHandles.lookup()/unreflectSpecial does not work anymore because > MethodHandles is encapsulated and calling setAccessible(true) on the > constructor fails. > > Resolving method handles inside the same module seems to work with public > lookup, > but as soon as a module defines an interface with default methods and this > interface is called by a proxy handler that comes from a different module, > it's > no longer possible to resolve the MethodHandle. > > Is this the appropriate mailing list for this case? This is still a sticking point for us too, our (moderately popular) library currently will not work in Java 9 because of this: https://github.com/jdbi/jdbi/issues/497 From christoph.dreis at freenet.de Wed Mar 1 21:34:48 2017 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Wed, 1 Mar 2017 22:34:48 +0100 Subject: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened Message-ID: <000001d292d3$a72bb560$f5832020$@freenet.de> Hey, I just noticed a small improvement for String.replace(CharSequence, CharSequence) in case the target sequence is not found. There is the possibility of an early-out in case there is nothing to replace. Yet there is a call to replacement.toString(); While this is usually not a problem in case of String parameters, a StringBuilder - or other more "dynamic" CharSequence.toString() implementations - will likely produce unnecessary allocations here. I think the JDK could prevent that with the given patch below. I would be very happy if this is sponsored for JDK 10. Cheers, Christoph ===== PATCH ====== diff --git a/src/java.base/share/classes/java/lang/String.java b/src/java.base/share/classes/java/lang/String.java --- a/src/java.base/share/classes/java/lang/String.java +++ b/src/java.base/share/classes/java/lang/String.java @@ -2177,11 +2177,11 @@ */ public String replace(CharSequence target, CharSequence replacement) { String tgtStr = target.toString(); - String replStr = replacement.toString(); int j = indexOf(tgtStr); if (j < 0) { return this; } + String replStr = replacement.toString(); int tgtLen = tgtStr.length(); int tgtLen1 = Math.max(tgtLen, 1); int thisLen = length(); From kumar.x.srinivasan at oracle.com Wed Mar 1 22:22:04 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 01 Mar 2017 14:22:04 -0800 Subject: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar In-Reply-To: References: <634120435d0d4814969a0c28c3b14f07@DEWDFE13DE14.global.corp.sap> Message-ID: <58B7498C.9050003@oracle.com> Hello Baesken, I have attached 8175000.patch to the bug report, it includes Thomas' suggested fix + a test. I have also tested it, you may want to post it to corelibs-dev. If posting a new webrev, please add the pipermail to the bug report, http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-March/046548.html If there are no further changes, I don't need to see it, and you can add me as a reviewer, and I don't need credit for the test. As for jexec, it appears that only Linux supports this, and I am uncertain who is using it in the Linux community. Perhaps we should try deprecate it in jdk10. Filed: https://bugs.openjdk.java.net/browse/JDK-8176066 Thanks Kumar On 3/1/2017 9:14 AM, Thomas St?fe wrote: > Hi Matthias, > > On Wed, Mar 1, 2017 at 5:07 PM, Baesken, Matthias > > wrote: > > Hi Thomas , thanks for looking into it . > > I suggest to handle the read issue in another bug because this > one just deals with ?jexec fails to execute simple helloworld.jar? . > > ( there seem to be a few other read(?) calls in the jdk code > base to consider as well ) > > Can we push the existing change ? > > > Not a Reviewer, so it is not for me to decide. Someone from core libs > should look at this. > > ...Thomas > > Regards, Matthias > > *From:*Thomas St?fe [mailto:thomas.stuefe at gmail.com > ] > *Sent:* Mittwoch, 1. M?rz 2017 12:47 > *To:* Baesken, Matthias > > *Cc:* core-libs-dev at openjdk.java.net > ; Simonis, Volker > > > *Subject:* Re: RFR [XS] : 8175000 : jexec fails to execute simple > helloworld.jar > > Hi Matthias, > > the fix makes sense, this is very clearly a bug. > > I'd suggest a simpler fix though: > > end -= 4; // make sure there are 4 bytes to > read at start > - while (start < end) { > + while (start <= end) { > > Note that the code has a diffent bug too, very unlikely but not > impossible to hit: > > 321 ssize_t count = read(fd, buf, CHUNK_SIZE); > 322 if (count >= MIN_SIZE) { > > We attempt to read CHUNK_SIZE bytes and require the read to have > returned at least MIN_SIZE (something like 30ish bytes). If not, > jexec fails. > > read may have been interrupted (EINTR) or may have returned less > bytes than MIN_SIZE, so it should read in a loop til eof or > CHUNK_SIZE bytes are read. > > Kind Regards, Thomas > > On Wed, Mar 1, 2017 at 10:23 AM, Baesken, Matthias > > wrote: > > Ping ... > > Can I get a review please for the change ? > > > Thanks, Matthias > > From: Baesken, Matthias > Sent: Donnerstag, 23. Februar 2017 12:28 > To: 'core-libs-dev at openjdk.java.net > ' > > > Cc: Langer, Christoph >; Erik Joelsson > (erik.joelsson at oracle.com ) > >; > 'Michel Trudeau' > > Subject: RE: RFR [XS] : 8175000 : jexec fails to execute > simple helloworld.jar > > Here is the webrev for jdk9 : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8175000/ > > > > ? And btw I really wonder - is jexec still needed in future > jdk's like jdk10 ? Seems it is not used much . > > ? > > In case jexec will stay in the jdk I might add a test for > the tool as well, if there is interest ( could not really > find one that tests execution of a simple jar-file with jexec). > > Best regards, Matthias > > > From: Baesken, Matthias > Sent: Donnerstag, 23. Februar 2017 07:39 > To: 'core-libs-dev at openjdk.java.net > ' > >> > > Cc: Langer, Christoph >>; Erik Joelsson > (erik.joelsson at oracle.com > >) >> > Subject: RE: RFR [XS] : 8175000 : jexec fails to execute > simple helloworld.jar > > Hello, probably I should add the info that the fix is needed > in jdk9 as well , not only jdk10 . > > Without the fix jdk9/10 show this error when executing a > small example jar : > > /myjdk9/images/jdk/lib/jexec /java_test/hellojar/helloworld.jar > invalid file (bad magic number): Exec format error > > with the fix : > > jdk/lib/jexec /java_test/hellojar/helloworld.jar > Hello world from a jar file > > > And btw I really wonder - is jexec still needed in future > jdk's like jdk10 ? Seems it is not used much . > > Best regards, Matthias > > > From: Baesken, Matthias > Sent: Mittwoch, 22. Februar 2017 18:16 > To: core-libs-dev at openjdk.java.net > > > Cc: Langer, Christoph >>; Erik Joelsson > (erik.joelsson at oracle.com > >) >> > Subject: RFR [XS] : 8175000 : jexec fails to execute simple > helloworld.jar > > Hello , when looking into the jexec build I noticed that > execution of a simple helloworld.jar with jexec does not > work any more. > > I did a little patch for this which adjusted the addition done > with CR 8156478: 3 Buffer overrun defect groups in > jexec.c > > . > > Could I have a review ( just a diff this time is provided > because of infrastructure issues) for it ? > > > Thanks, Matthias > > Bug : > https://bugs.openjdk.java.net/browse/JDK-8175000 > > > > Diff for jdk10 : > > # HG changeset patch > # User mbaesken > # Date 1487782485 -3600 > # Wed Feb 22 17:54:45 2017 +0100 > # Node ID 93d55a711f3b1c3f282e6889c24d13f16d4a4548 > # Parent 884872263accabd4ab68d005abd4e5393144aa4f > 8175000: jexec fails to execute simple helloworld.jar > > diff --git a/src/java.base/unix/native/launcher/jexec.c > b/src/java.base/unix/native/launcher/jexec.c > --- a/src/java.base/unix/native/launcher/jexec.c > +++ b/src/java.base/unix/native/launcher/jexec.c > @@ -331,8 +331,9 @@ > off_t end = start + xlen; > > if (end <= count) { > - end -= 4; // make sure there are 4 bytes > to read at start > - while (start < end) { > + // make sure there are 4 bytes to read at > start > + end -= 3; > + while ((start < end) && (start < count-3)) { > off_t xhid = SH(buf, start); > off_t xdlen = SH(buf, start + 2); > > From mandy.chung at oracle.com Wed Mar 1 23:14:03 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 1 Mar 2017 23:14:03 +0000 Subject: Proposal: java.lang.reflect.Proxy and default methods In-Reply-To: <1488402844432-300249.post@n7.nabble.com> References: <4408a730-3f91-fe39-ef3f-b8ac00c1391c@gmail.com> <6F6ED6C5-9324-40F2-AE9A-E5BB15277733@oracle.com> <33B3EDCF-65C6-4991-A635-084B157A9D27@gmail.com> <1488402844432-300249.post@n7.nabble.com> Message-ID: <07A3A2EF-3677-451B-AF36-0A15938AD92B@oracle.com> You can use MethodHandles.privateLookupIn (new in JDK 9) to replace Constructor hack to get a Lookup object with private access for the target class. Mandy > On Mar 1, 2017, at 9:14 PM, mp911de wrote: > > Is there any progress on this issue? In the light of Java 9, the workaround > with > MethodHandles.lookup()/unreflectSpecial does not work anymore because > MethodHandles is encapsulated and calling setAccessible(true) on the > constructor fails. > > Resolving method handles inside the same module seems to work with public > lookup, > but as soon as a module defines an interface with default methods and this > interface is called by a proxy handler that comes from a different module, > it's > no longer possible to resolve the MethodHandle. > > Is this the appropriate mailing list for this case? > > > > -- > View this message in context: http://openjdk.5641.n7.nabble.com/Proposal-java-lang-reflect-Proxy-and-default-methods-tp273894p300249.html > Sent from the OpenJDK Core Libraries mailing list archive at Nabble.com. From vitalyd at gmail.com Wed Mar 1 23:18:06 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 01 Mar 2017 23:18:06 +0000 Subject: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened In-Reply-To: <000001d292d3$a72bb560$f5832020$@freenet.de> References: <000001d292d3$a72bb560$f5832020$@freenet.de> Message-ID: Seems like a good idea. You probably want to null check 'replacement' before the bail out as the method is specified as throwing NPE in that case. On Wed, Mar 1, 2017 at 4:37 PM Christoph Dreis wrote: > Hey, > > I just noticed a small improvement for String.replace(CharSequence, > CharSequence) in case the target sequence is not found. > > There is the possibility of an early-out in case there is nothing to > replace. Yet there is a call to replacement.toString(); > While this is usually not a problem in case of String parameters, a > StringBuilder - or other more "dynamic" CharSequence.toString() > implementations - will likely produce unnecessary allocations here. > > I think the JDK could prevent that with the given patch below. > > I would be very happy if this is sponsored for JDK 10. > > Cheers, > Christoph > > ===== PATCH ====== > diff --git a/src/java.base/share/classes/java/lang/String.java > b/src/java.base/share/classes/java/lang/String.java > --- a/src/java.base/share/classes/java/lang/String.java > +++ b/src/java.base/share/classes/java/lang/String.java > @@ -2177,11 +2177,11 @@ > */ > public String replace(CharSequence target, CharSequence replacement) { > String tgtStr = target.toString(); > - String replStr = replacement.toString(); > int j = indexOf(tgtStr); > if (j < 0) { > return this; > } > + String replStr = replacement.toString(); > int tgtLen = tgtStr.length(); > int tgtLen1 = Math.max(tgtLen, 1); > int thisLen = length(); > > -- Sent from my phone From christoph.dreis at freenet.de Wed Mar 1 23:47:48 2017 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Thu, 2 Mar 2017 00:47:48 +0100 Subject: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened In-Reply-To: References: <000001d292d3$a72bb560$f5832020$@freenet.de> Message-ID: <000401d292e6$3b93efd0$b2bbcf70$@freenet.de> Hey Vitaly, > Seems like a good idea. You probably want to null check 'replacement' before the bail out as the method is specified as throwing NPE in that case. Thanks for your feedback. See the adjusted patch below. ===== PATCH ====== diff --git a/src/java.base/share/classes/java/lang/String.java b/src/java.base/share/classes/java/lang/String.java --- a/src/java.base/share/classes/java/lang/String.java +++ b/src/java.base/share/classes/java/lang/String.java @@ -2176,12 +2176,13 @@ * @since 1.5 */ public String replace(CharSequence target, CharSequence replacement) { + Objects.requireNonNull(replacement); String tgtStr = target.toString(); - String replStr = replacement.toString(); int j = indexOf(tgtStr); if (j < 0) { return this; } + String replStr = replacement.toString(); int tgtLen = tgtStr.length(); int tgtLen1 = Math.max(tgtLen, 1); int thisLen = length(); From jbluettduncan at gmail.com Wed Mar 1 23:55:50 2017 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Wed, 1 Mar 2017 23:55:50 +0000 Subject: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened In-Reply-To: <000401d292e6$3b93efd0$b2bbcf70$@freenet.de> References: <000001d292d3$a72bb560$f5832020$@freenet.de> <000401d292e6$3b93efd0$b2bbcf70$@freenet.de> Message-ID: Hi Christoph, I think it's worth adding a small comment to the end of `String tgtStr = target.toString();`, saying that the null check is implicit, in case people read the code in the future and get confused as to why only `replacement` is apparently null-checked. What do you think? Kind regards, Jonathan On 1 March 2017 at 23:47, Christoph Dreis wrote: > Hey Vitaly, > > > Seems like a good idea. You probably want to null check 'replacement' > before the bail out as the method is specified as throwing NPE in that case. > > Thanks for your feedback. See the adjusted patch below. > > ===== PATCH ====== > > diff --git a/src/java.base/share/classes/java/lang/String.java > b/src/java.base/share/classes/java/lang/String.java > --- a/src/java.base/share/classes/java/lang/String.java > +++ b/src/java.base/share/classes/java/lang/String.java > @@ -2176,12 +2176,13 @@ > * @since 1.5 > */ > public String replace(CharSequence target, CharSequence replacement) { > + Objects.requireNonNull(replacement); > String tgtStr = target.toString(); > - String replStr = replacement.toString(); > int j = indexOf(tgtStr); > if (j < 0) { > return this; > } > + String replStr = replacement.toString(); > int tgtLen = tgtStr.length(); > int tgtLen1 = Math.max(tgtLen, 1); > int thisLen = length(); > > From vitalyd at gmail.com Thu Mar 2 00:06:19 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 02 Mar 2017 00:06:19 +0000 Subject: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened In-Reply-To: <000401d292e6$3b93efd0$b2bbcf70$@freenet.de> References: <000001d292d3$a72bb560$f5832020$@freenet.de> <000401d292e6$3b93efd0$b2bbcf70$@freenet.de> Message-ID: As mentioned offline, I would move the null check right before "return this". On Wed, Mar 1, 2017 at 6:50 PM Christoph Dreis wrote: > Hey Vitaly, > > > Seems like a good idea. You probably want to null check 'replacement' > before the bail out as the method is specified as throwing NPE in that case. > > Thanks for your feedback. See the adjusted patch below. > > ===== PATCH ====== > > diff --git a/src/java.base/share/classes/java/lang/String.java > b/src/java.base/share/classes/java/lang/String.java > --- a/src/java.base/share/classes/java/lang/String.java > +++ b/src/java.base/share/classes/java/lang/String.java > @@ -2176,12 +2176,13 @@ > * @since 1.5 > */ > public String replace(CharSequence target, CharSequence replacement) { > + Objects.requireNonNull(replacement); > String tgtStr = target.toString(); > - String replStr = replacement.toString(); > int j = indexOf(tgtStr); > if (j < 0) { > return this; > } > + String replStr = replacement.toString(); > int tgtLen = tgtStr.length(); > int tgtLen1 = Math.max(tgtLen, 1); > int thisLen = length(); > > -- Sent from my phone From matthias.baesken at sap.com Thu Mar 2 06:33:08 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 2 Mar 2017 06:33:08 +0000 Subject: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar In-Reply-To: <58B7498C.9050003@oracle.com> References: <634120435d0d4814969a0c28c3b14f07@DEWDFE13DE14.global.corp.sap> <58B7498C.9050003@oracle.com> Message-ID: <0b2481528f1d4cb5951016ac773a5ded@DEWDFE13DE14.global.corp.sap> >If there are no further changes, I don't need to see it, and you >can add me as a reviewer, and I don't need credit for the test. Thanks Kumar for review and adding the test. >As for jexec, it appears that only Linux supports this, and I am >uncertain who is using it in the Linux community. >Perhaps we should try deprecate it in jdk10. >Filed: https://bugs.openjdk.java.net/browse/JDK-8176066 I agree that it makes sense to look into a deprecation of jexec for jdk10. Best regards, Matthias From: Kumar Srinivasan [mailto:kumar.x.srinivasan at oracle.com] Sent: Mittwoch, 1. M?rz 2017 23:22 To: Thomas St?fe Cc: Baesken, Matthias ; Michel Trudeau ; core-libs-dev at openjdk.java.net; Simonis, Volker Subject: Re: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar Hello Baesken, I have attached 8175000.patch to the bug report, it includes Thomas' suggested fix + a test. I have also tested it, you may want to post it to corelibs-dev. If posting a new webrev, please add the pipermail to the bug report, http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-March/046548.html If there are no further changes, I don't need to see it, and you can add me as a reviewer, and I don't need credit for the test. As for jexec, it appears that only Linux supports this, and I am uncertain who is using it in the Linux community. Perhaps we should try deprecate it in jdk10. Filed: https://bugs.openjdk.java.net/browse/JDK-8176066 Thanks Kumar On 3/1/2017 9:14 AM, Thomas St?fe wrote: Hi Matthias, On Wed, Mar 1, 2017 at 5:07 PM, Baesken, Matthias > wrote: Hi Thomas , thanks for looking into it . I suggest to handle the read issue in another bug because this one just deals with ?jexec fails to execute simple helloworld.jar? . ( there seem to be a few other read(?) calls in the jdk code base to consider as well ) Can we push the existing change ? Not a Reviewer, so it is not for me to decide. Someone from core libs should look at this. ...Thomas Regards, Matthias From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: Mittwoch, 1. M?rz 2017 12:47 To: Baesken, Matthias > Cc: core-libs-dev at openjdk.java.net; Simonis, Volker > Subject: Re: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar Hi Matthias, the fix makes sense, this is very clearly a bug. I'd suggest a simpler fix though: end -= 4; // make sure there are 4 bytes to read at start - while (start < end) { + while (start <= end) { Note that the code has a diffent bug too, very unlikely but not impossible to hit: 321 ssize_t count = read(fd, buf, CHUNK_SIZE); 322 if (count >= MIN_SIZE) { We attempt to read CHUNK_SIZE bytes and require the read to have returned at least MIN_SIZE (something like 30ish bytes). If not, jexec fails. read may have been interrupted (EINTR) or may have returned less bytes than MIN_SIZE, so it should read in a loop til eof or CHUNK_SIZE bytes are read. Kind Regards, Thomas On Wed, Mar 1, 2017 at 10:23 AM, Baesken, Matthias > wrote: Ping ... Can I get a review please for the change ? Thanks, Matthias From: Baesken, Matthias Sent: Donnerstag, 23. Februar 2017 12:28 To: 'core-libs-dev at openjdk.java.net' > Cc: Langer, Christoph >; Erik Joelsson (erik.joelsson at oracle.com) >; 'Michel Trudeau' > Subject: RE: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar Here is the webrev for jdk9 : http://cr.openjdk.java.net/~mbaesken/webrevs/8175000/ ? And btw I really wonder - is jexec still needed in future jdk's like jdk10 ? Seems it is not used much . ? In case jexec will stay in the jdk I might add a test for the tool as well, if there is interest ( could not really find one that tests execution of a simple jar-file with jexec). Best regards, Matthias From: Baesken, Matthias Sent: Donnerstag, 23. Februar 2017 07:39 To: 'core-libs-dev at openjdk.java.net' >> Cc: Langer, Christoph >>; Erik Joelsson (erik.joelsson at oracle.com>) >> Subject: RE: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar Hello, probably I should add the info that the fix is needed in jdk9 as well , not only jdk10 . Without the fix jdk9/10 show this error when executing a small example jar : /myjdk9/images/jdk/lib/jexec /java_test/hellojar/helloworld.jar invalid file (bad magic number): Exec format error with the fix : jdk/lib/jexec /java_test/hellojar/helloworld.jar Hello world from a jar file And btw I really wonder - is jexec still needed in future jdk's like jdk10 ? Seems it is not used much . Best regards, Matthias From: Baesken, Matthias Sent: Mittwoch, 22. Februar 2017 18:16 To: core-libs-dev at openjdk.java.net> Cc: Langer, Christoph >>; Erik Joelsson (erik.joelsson at oracle.com>) >> Subject: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar Hello , when looking into the jexec build I noticed that execution of a simple helloworld.jar with jexec does not work any more. I did a little patch for this which adjusted the addition done with CR 8156478: 3 Buffer overrun defect groups in jexec.c . Could I have a review ( just a diff this time is provided because of infrastructure issues) for it ? Thanks, Matthias Bug : https://bugs.openjdk.java.net/browse/JDK-8175000 Diff for jdk10 : # HG changeset patch # User mbaesken # Date 1487782485 -3600 # Wed Feb 22 17:54:45 2017 +0100 # Node ID 93d55a711f3b1c3f282e6889c24d13f16d4a4548 # Parent 884872263accabd4ab68d005abd4e5393144aa4f 8175000: jexec fails to execute simple helloworld.jar diff --git a/src/java.base/unix/native/launcher/jexec.c b/src/java.base/unix/native/launcher/jexec.c --- a/src/java.base/unix/native/launcher/jexec.c +++ b/src/java.base/unix/native/launcher/jexec.c @@ -331,8 +331,9 @@ off_t end = start + xlen; if (end <= count) { - end -= 4; // make sure there are 4 bytes to read at start - while (start < end) { + // make sure there are 4 bytes to read at start + end -= 3; + while ((start < end) && (start < count-3)) { off_t xhid = SH(buf, start); off_t xdlen = SH(buf, start + 2); From christoph.dreis at freenet.de Thu Mar 2 07:26:06 2017 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Thu, 2 Mar 2017 08:26:06 +0100 Subject: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened In-Reply-To: References: <000001d292d3$a72bb560$f5832020$@freenet.de> <000401d292e6$3b93efd0$b2bbcf70$@freenet.de> Message-ID: <001601d29326$41ccb220$c5661660$@freenet.de> Hey Vitaly and Jonathan, > As mentioned offline, I would move the null check right before "return this". @Vitaly: Thanks again. Adjusted. @Jonathan: Thanks. Thought about that as well, but I'd probably rather go with explaining the explicit nullcheck. See the adjusted patch below. What do you think? ===== PATCH ====== diff --git a/src/java.base/share/classes/java/lang/String.java b/src/java.base/share/classes/java/lang/String.java --- a/src/java.base/share/classes/java/lang/String.java +++ b/src/java.base/share/classes/java/lang/String.java @@ -2177,11 +2177,13 @@ */ public String replace(CharSequence target, CharSequence replacement) { String tgtStr = target.toString(); - String replStr = replacement.toString(); int j = indexOf(tgtStr); if (j < 0) { + // Explicit nullcheck of replacement to fulfill NPE contract in early out + Objects.requireNonNull(replacement); return this; } + String replStr = replacement.toString(); int tgtLen = tgtStr.length(); int tgtLen1 = Math.max(tgtLen, 1); int thisLen = length(); From Alan.Bateman at oracle.com Thu Mar 2 08:28:35 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 2 Mar 2017 08:28:35 +0000 Subject: Proposal: java.lang.reflect.Proxy and default methods In-Reply-To: <1488402844432-300249.post@n7.nabble.com> References: <4408a730-3f91-fe39-ef3f-b8ac00c1391c@gmail.com> <6F6ED6C5-9324-40F2-AE9A-E5BB15277733@oracle.com> <33B3EDCF-65C6-4991-A635-084B157A9D27@gmail.com> <1488402844432-300249.post@n7.nabble.com> Message-ID: <3af82dd3-a6bf-04d7-208f-b9857322d615@oracle.com> On 01/03/2017 21:14, mp911de wrote: > Is there any progress on this issue? In the light of Java 9, the workaround > with > MethodHandles.lookup()/unreflectSpecial does not work anymore because > MethodHandles is encapsulated and calling setAccessible(true) on the > constructor fails. > > Resolving method handles inside the same module seems to work with public > lookup, > but as soon as a module defines an interface with default methods and this > interface is called by a proxy handler that comes from a different module, > it's > no longer possible to resolve the MethodHandle. > > Is this the appropriate mailing list for this case? > I assume you are looking for the "Non-abstract methods in interfaces" section in JEP 274 [1]. See also John Rose's note to jigsaw-dev about using Lookup.findSpecial to access default methods in interfaces [2]. -Alan [1] http://openjdk.java.net/jeps/274 [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-January/010741.html From john.r.rose at oracle.com Thu Mar 2 11:28:21 2017 From: john.r.rose at oracle.com (John Rose) Date: Thu, 2 Mar 2017 11:28:21 +0000 Subject: [10] RFR: 8176041: Optimize handling of comment lines in Properties$LineReader.readLine In-Reply-To: <1e2dae22-8f07-61a9-4ad6-791cb95d627e@oracle.com> References: <102d6fc7-921e-4c39-ee9a-00ebfdd624ac@oracle.com> <1e2dae22-8f07-61a9-4ad6-791cb95d627e@oracle.com> Message-ID: On Mar 1, 2017, at 5:11 PM, Claes Redestad wrote: > > It seems javac optimizes byte-char comparisons pretty well This happened because of the JVM's bytecode ISA, which requires that javac must "erase" all integer subrange types (boolean, char, byte, short) internally to int, when emitting bytecode. So whether you say true, '\1', (byte)1, (short)1, or just 1, javac will emit an "iconst_1" instruction and push 32 bits on the stack. This tends to "smooth out" differences between types of 32 bits or less. This is especially surprising in the case of booleans, which are not convertible to ints at the source level. More JVM trivia: The only places in the bytecode ISA where subrange types are fully significant are (1) field get/set, (2) array element get/set, and (3) the type-checking of primitive arrays. The i2x/x2i conversions and xipush constants can be viewed as always operating on ints. Method descriptor types are "partially significant", in a way that has evolved over time and is too complicated to describe here. ? John From claes.redestad at oracle.com Thu Mar 2 11:35:12 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 2 Mar 2017 11:35:12 +0000 Subject: [9] RFR: 8176041: Optimize handling of comment lines in Properties$LineReader.readLine In-Reply-To: <0acfb3e5-7198-47f8-8035-818348cef884@redhat.com> References: <102d6fc7-921e-4c39-ee9a-00ebfdd624ac@oracle.com> <1e2dae22-8f07-61a9-4ad6-791cb95d627e@oracle.com> <0acfb3e5-7198-47f8-8035-818348cef884@redhat.com> Message-ID: <40b0267d-9314-f85f-5fdc-1b4b3dca331a@oracle.com> Hi, as this now significantly helps with one of our startup regression, and the change is very low risk, I've retargetted to 9. Any objections? /Claes On 03/01/2017 05:17 PM, Aleksey Shipilev wrote: > On 03/01/2017 06:11 PM, Claes Redestad wrote: >> Sure, with a bit of fix-up this drops another 170k executed bytecodes >> to read in the java.security file (original: 1882k, now: 980k): >> >> http://cr.openjdk.java.net/~redestad/8176041/jdk.02/ > Ok, that's fine. > > This is slightly more idiomatic, you might want to change before pushing: > c = (char)(b & 0xFF); > > Thanks, > -Aleksey > From Ulf.Zibis at CoSoCo.de Thu Mar 2 11:38:08 2017 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 2 Mar 2017 12:38:08 +0100 Subject: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened In-Reply-To: References: <000001d292d3$a72bb560$f5832020$@freenet.de> Message-ID: <10de9d22-6a32-dcac-838a-b88ac04e7b37@CoSoCo.de> Hi Vitaly, I don't see any contract to throw an NPE: https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replace-java.lang.CharSequence-java.lang.CharSequence- In any case, what's the reasonable of checking an argument, which is not used in that case? Am 02.03.2017 um 00:18 schrieb Vitaly Davidovich: > Seems like a good idea. You probably want to null check 'replacement' > before the bail out as the method is specified as throwing NPE in that case. From claes.redestad at oracle.com Thu Mar 2 11:44:36 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 2 Mar 2017 11:44:36 +0000 Subject: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened In-Reply-To: <10de9d22-6a32-dcac-838a-b88ac04e7b37@CoSoCo.de> References: <000001d292d3$a72bb560$f5832020$@freenet.de> <10de9d22-6a32-dcac-838a-b88ac04e7b37@CoSoCo.de> Message-ID: <8fd5647a-ffb8-48c5-b785-8d7aa4e67a4d@oracle.com> On 03/02/2017 11:38 AM, Ulf Zibis wrote: > Hi Vitaly, > > I don't see any contract to throw an NPE: > https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replace-java.lang.CharSequence-java.lang.CharSequence- > "Unless otherwise noted, passing anullargument to a constructor or method in this class will cause a|NullPointerException| to be thrown." /Claes From vitalyd at gmail.com Thu Mar 2 11:45:03 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 02 Mar 2017 11:45:03 +0000 Subject: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened In-Reply-To: <10de9d22-6a32-dcac-838a-b88ac04e7b37@CoSoCo.de> References: <000001d292d3$a72bb560$f5832020$@freenet.de> <10de9d22-6a32-dcac-838a-b88ac04e7b37@CoSoCo.de> Message-ID: On Thu, Mar 2, 2017 at 6:38 AM Ulf Zibis wrote: > Hi Vitaly, > > I don't see any contract to throw an NPE: > > https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replace-java.lang.CharSequence-java.lang.CharSequence- Hmm, I must've looked at java 7 docs, which do call out the NPE: http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#replace(java.lang.CharSequence,%20java.lang.CharSequence) Was this changed intentionally in 8? > > > > In any case, what's the reasonable of checking an argument, which is not > used in that case? My understanding is contracts like the above (let's assume it still called out the NPE in 8) are checked even if the argument isn't used in some cases. The other case where I believe this is done is when passing a Supplier to some method that uses it to obtain a default value - even if it's not needed, it's checked for null because most (all?) such methods stipulate that it cannot be null. > > > > Am 02.03.2017 um 00:18 schrieb Vitaly Davidovich: > > Seems like a good idea. You probably want to null check 'replacement' > > before the bail out as the method is specified as throwing NPE in that > case. > > -- Sent from my phone From christoph.dreis at freenet.de Thu Mar 2 11:45:09 2017 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Thu, 2 Mar 2017 12:45:09 +0100 Subject: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened In-Reply-To: <10de9d22-6a32-dcac-838a-b88ac04e7b37@CoSoCo.de> References: <000001d292d3$a72bb560$f5832020$@freenet.de> <10de9d22-6a32-dcac-838a-b88ac04e7b37@CoSoCo.de> Message-ID: <001701d2934a$728382d0$578a8870$@freenet.de> Hey Ulf, > Hi Vitaly, > > I don't see any contract to throw an NPE: > https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replace- > java.lang.CharSequence-java.lang.CharSequence- > > In any case, what's the reasonable of checking an argument, which is not > used in that case? > > > Am 02.03.2017 um 00:18 schrieb Vitaly Davidovich: > > Seems like a good idea. You probably want to null check 'replacement' > > before the bail out as the method is specified as throwing NPE in that case. It is stated in the class comment. "Unless otherwise noted, passing a null argument to a constructor or method in this class will cause a NullPointerException to be thrown." Cheers, Christoph From vitalyd at gmail.com Thu Mar 2 11:50:54 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 02 Mar 2017 11:50:54 +0000 Subject: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened In-Reply-To: <8fd5647a-ffb8-48c5-b785-8d7aa4e67a4d@oracle.com> References: <000001d292d3$a72bb560$f5832020$@freenet.de> <10de9d22-6a32-dcac-838a-b88ac04e7b37@CoSoCo.de> <8fd5647a-ffb8-48c5-b785-8d7aa4e67a4d@oracle.com> Message-ID: On Thu, Mar 2, 2017 at 6:45 AM Claes Redestad wrote: > On 03/02/2017 11:38 AM, Ulf Zibis wrote: > > Hi Vitaly, > > > > I don't see any contract to throw an NPE: > > > https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replace-java.lang.CharSequence-java.lang.CharSequence- > > > > "Unless otherwise noted, passing anullargument to a constructor or > method in this class will cause a|NullPointerException| > < > https://docs.oracle.com/javase/8/docs/api/java/lang/NullPointerException.html > >to > be thrown." > > /Claes > Ah, it was moved to class level docs in 8 - thanks Claes. As a side comment, I certainly understand the desire to not repeat yourself for each method's javadoc, but at the same time it's a bit less user friendly as most people don't read class level docs nearly as frequently as method level. -- Sent from my phone From paul.sandoz at oracle.com Thu Mar 2 11:55:59 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 2 Mar 2017 11:55:59 +0000 Subject: [9] RFR: 8176041: Optimize handling of comment lines in Properties$LineReader.readLine In-Reply-To: <40b0267d-9314-f85f-5fdc-1b4b3dca331a@oracle.com> References: <102d6fc7-921e-4c39-ee9a-00ebfdd624ac@oracle.com> <1e2dae22-8f07-61a9-4ad6-791cb95d627e@oracle.com> <0acfb3e5-7198-47f8-8035-818348cef884@redhat.com> <40b0267d-9314-f85f-5fdc-1b4b3dca331a@oracle.com> Message-ID: > On 2 Mar 2017, at 11:35, Claes Redestad wrote: > > Hi, > > as this now significantly helps with one of our startup regression, and > the change is very low risk, I've retargetted to 9. Any objections? > No objections, +1 for 9. Paul. From ramanand.patil at oracle.com Thu Mar 2 12:45:26 2017 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Thu, 2 Mar 2017 04:45:26 -0800 (PST) Subject: RFR: 8176044: (tz) Support tzdata2017a Message-ID: <5906baa2-ce3c-41e1-aad7-db9583988a6e@default> Hi all, Please review the latest TZDATA integration (tzdata2017a) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8176044 Webrev: http://cr.openjdk.java.net/~rpatil/8176044/webrev.00/ All the TimeZone related tests are passed after integration. Regards, Ramanand. From jbluettduncan at gmail.com Thu Mar 2 13:26:31 2017 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Thu, 2 Mar 2017 13:26:31 +0000 Subject: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened In-Reply-To: <001601d29326$41ccb220$c5661660$@freenet.de> References: <000001d292d3$a72bb560$f5832020$@freenet.de> <000401d292e6$3b93efd0$b2bbcf70$@freenet.de> <001601d29326$41ccb220$c5661660$@freenet.de> Message-ID: Hi Christoph and Vitaly, I am struggling to understand why the null-check for `replacement` has been moved within the `if (j < 0) { ... }` block. Could one of you explain to me the reasoning behind this change? I ask because, AFAICT, making it so that it only throws an NPE if `replacement` is null *and* `j < 0`, rather than throwing NPE at the very start of the method, seems to be going against the class-level doc which says, "Unless otherwise noted, passing a null argument to a constructor or method in this class will cause a NullPointerException to be thrown." Other than that, I am equally happy with `replacement` itself having an explicit-nullness-related comment instead of target having an implicit-nullness comment - it seems to deliver the same sort of message. :) Kind regards, Jonathan On 2 March 2017 at 07:26, Christoph Dreis wrote: > Hey Vitaly and Jonathan, > > > As mentioned offline, I would move the null check right before "return > this". > > @Vitaly: Thanks again. Adjusted. > @Jonathan: Thanks. Thought about that as well, but I'd probably rather go > with explaining the explicit nullcheck. > > See the adjusted patch below. What do you think? > > ===== PATCH ====== > diff --git a/src/java.base/share/classes/java/lang/String.java > b/src/java.base/share/classes/java/lang/String.java > --- a/src/java.base/share/classes/java/lang/String.java > +++ b/src/java.base/share/classes/java/lang/String.java > @@ -2177,11 +2177,13 @@ > */ > public String replace(CharSequence target, CharSequence replacement) { > String tgtStr = target.toString(); > - String replStr = replacement.toString(); > int j = indexOf(tgtStr); > if (j < 0) { > + // Explicit nullcheck of replacement to fulfill NPE contract > in early out > + Objects.requireNonNull(replacement); > return this; > } > + String replStr = replacement.toString(); > int tgtLen = tgtStr.length(); > int tgtLen1 = Math.max(tgtLen, 1); > int thisLen = length(); > > From Ulf.Zibis at CoSoCo.de Thu Mar 2 13:32:17 2017 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 2 Mar 2017 14:32:17 +0100 Subject: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened In-Reply-To: References: <000001d292d3$a72bb560$f5832020$@freenet.de> <10de9d22-6a32-dcac-838a-b88ac04e7b37@CoSoCo.de> Message-ID: HI, first sorry for missing the class wide definition. Am 02.03.2017 um 12:45 schrieb Vitaly Davidovich: > > On Thu, Mar 2, 2017 at 6:38 AM Ulf Zibis > wrote: > > In any case, what's the reasonable of checking an argument, which is not used in that case? > > My understanding is contracts like the above (let's assume it still called out the NPE in 8) are > checked even if the argument isn't used in some cases. The other case where I believe this is > done is when passing a Supplier to some method that uses it to obtain a default value - even if > it's not needed, it's checked for null because most (all?) such methods stipulate that it cannot > be null. On the other hand, the null check is a waste of performance and footprint (implicits performance cost too). I can't imagine, if any programmer would rely on such contract, instead of doing the check explicitly if of significance. I think, the original reasonable of the contract is to rule out any other exception type or undefined behaviour in case of relevance of the argument. So I would vote for stating the contract more precisely in that way. Also, if I remember correct, if a variable, here replStr, is only referenced later, the compiler can move the execution of here replacement.toString() to a later position, so it is not clear to me, if the original implementation ever fulfilled the contract. -Ulf From vitalyd at gmail.com Thu Mar 2 13:32:57 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 2 Mar 2017 08:32:57 -0500 Subject: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened In-Reply-To: References: <000001d292d3$a72bb560$f5832020$@freenet.de> <000401d292e6$3b93efd0$b2bbcf70$@freenet.de> <001601d29326$41ccb220$c5661660$@freenet.de> Message-ID: On Thu, Mar 2, 2017 at 8:26 AM, Jonathan Bluett-Duncan < jbluettduncan at gmail.com> wrote: > Hi Christoph and Vitaly, > > I am struggling to understand why the null-check for `replacement` has > been moved within the `if (j < 0) { ... }` block. Could one of you explain > to me the reasoning behind this change? > > I ask because, AFAICT, making it so that it only throws an NPE if > `replacement` is null *and* `j < 0`, rather than throwing NPE at the very > start of the method, seems to be going against the class-level doc which > says, "Unless otherwise noted, passing a null argument to a constructor or > method in this class will cause a NullPointerException to be thrown." > If there's no early bail out, there's an implicit null check when replacement.toString() is called; in fact, if a null is never seen (based on profile), there won't be any code generated for the null check (sigsegv handling will be used instead). If we add an explicit null check at the top of the method, I'm not confident that the JIT will eliminate it in cases where the method does not bail out early. It probably doesn't matter, really, but I don't see much harm in delaying the explicit null check until the last moment, so to speak. > > Other than that, I am equally happy with `replacement` itself having an > explicit-nullness-related comment instead of target having an > implicit-nullness comment - it seems to deliver the same sort of message. :) > > Kind regards, > Jonathan > > On 2 March 2017 at 07:26, Christoph Dreis > wrote: > >> Hey Vitaly and Jonathan, >> >> > As mentioned offline, I would move the null check right before "return >> this". >> >> @Vitaly: Thanks again. Adjusted. >> @Jonathan: Thanks. Thought about that as well, but I'd probably rather go >> with explaining the explicit nullcheck. >> >> See the adjusted patch below. What do you think? >> >> ===== PATCH ====== >> diff --git a/src/java.base/share/classes/java/lang/String.java >> b/src/java.base/share/classes/java/lang/String.java >> --- a/src/java.base/share/classes/java/lang/String.java >> +++ b/src/java.base/share/classes/java/lang/String.java >> @@ -2177,11 +2177,13 @@ >> */ >> public String replace(CharSequence target, CharSequence replacement) >> { >> String tgtStr = target.toString(); >> - String replStr = replacement.toString(); >> int j = indexOf(tgtStr); >> if (j < 0) { >> + // Explicit nullcheck of replacement to fulfill NPE contract >> in early out >> + Objects.requireNonNull(replacement); >> return this; >> } >> + String replStr = replacement.toString(); >> int tgtLen = tgtStr.length(); >> int tgtLen1 = Math.max(tgtLen, 1); >> int thisLen = length(); >> >> > From vitalyd at gmail.com Thu Mar 2 13:55:19 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 02 Mar 2017 13:55:19 +0000 Subject: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened In-Reply-To: References: <000001d292d3$a72bb560$f5832020$@freenet.de> <10de9d22-6a32-dcac-838a-b88ac04e7b37@CoSoCo.de> Message-ID: On Thu, Mar 2, 2017 at 8:32 AM Ulf Zibis wrote: > HI, > > first sorry for missing the class wide definition. > > Am 02.03.2017 um 12:45 schrieb Vitaly Davidovich: > > > > On Thu, Mar 2, 2017 at 6:38 AM Ulf Zibis Ulf.Zibis at cosoco.de>> wrote: > > > > In any case, what's the reasonable of checking an argument, which is > not used in that case? > > > > My understanding is contracts like the above (let's assume it still > called out the NPE in 8) are > > checked even if the argument isn't used in some cases. The other case > where I believe this is > > done is when passing a Supplier to some method that uses it to obtain a > default value - even if > > it's not needed, it's checked for null because most (all?) such methods > stipulate that it cannot > > be null. > On the other hand, the null check is a waste of performance and footprint > (implicits performance > cost too). Implicit null checks aren't always eliminated (e.g. calling an empty devirtualized method will still test the receiver for null) but generally don't cost anything. Explicit null checks can sometimes be folded into the implicit one by the optimizer, but not always. > > I can't imagine, if any programmer would rely on such contract, instead of > doing the check > explicitly if of significance. I think it's to have consistent behavior, irrespective of control flow. It can detect bugs early on. I agree callers can do their own checks, but this consistency is what I've noticed JDK to prefer. > > > I think, the original reasonable of the contract is to rule out any other > exception type or > undefined behaviour in case of relevance of the argument. So I would vote > for stating the contract > more precisely in that way. > > Also, if I remember correct, if a variable, here replStr, is only > referenced later, the compiler can > move the execution of here replacement.toString() to a later position, so > it is not clear to me, if > the original implementation ever fulfilled the contract. Compiler can only do that if it proves a bunch of things, such as no observable side effects as a result of sinking it down. If CharSequence.toString isn't devirtualized there, eg, it definitely cannot do it. I wouldn't bet on it. > > > -Ulf > > -- Sent from my phone From jbluettduncan at gmail.com Thu Mar 2 13:56:22 2017 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Thu, 2 Mar 2017 13:56:22 +0000 Subject: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened In-Reply-To: References: <000001d292d3$a72bb560$f5832020$@freenet.de> <000401d292e6$3b93efd0$b2bbcf70$@freenet.de> <001601d29326$41ccb220$c5661660$@freenet.de> Message-ID: Hi Vitaly, > If there's no early bail out, there's an implicit null check when > replacement.toString() is called... Oh apologies! I had missed in the code that NPE does get thrown if `replacement` is null, no matter if the `if (j < 0) { ... }` block is entered or not, because `replacement.toString()` gets called immediately after the if block, which of course executes an implicit null-check. In that case, the patch LGTM. :) Kind regards, Jonathan From christoph.dreis at freenet.de Thu Mar 2 15:44:58 2017 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Thu, 2 Mar 2017 16:44:58 +0100 Subject: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened In-Reply-To: References: <000001d292d3$a72bb560$f5832020$@freenet.de> <10de9d22-6a32-dcac-838a-b88ac04e7b37@CoSoCo.de> Message-ID: <002201d2936b$f3270490$d9750db0$@freenet.de> Hey Vitaly, Thanks for clearing the way. As all things seem to be clarified now, is there someone who is willing to sponsor the patch? Cheers, Christoph ====== PATCH ====== diff --git a/src/java.base/share/classes/java/lang/String.java b/src/java.base/share/classes/java/lang/String.jav --- a/src/java.base/share/classes/java/lang/String.java +++ b/src/java.base/share/classes/java/lang/String.java @@ -2177,11 +2177,13 @@ */ public String replace(CharSequence target, CharSequence replacement) { String tgtStr = target.toString(); - String replStr = replacement.toString(); int j = indexOf(tgtStr); if (j < 0) { + // Explicit nullcheck of replacement to fulfill NPE contract in early out + Objects.requireNonNull(replacement); return this; } + String replStr = replacement.toString(); int tgtLen = tgtStr.length(); int tgtLen1 = Math.max(tgtLen, 1); int thisLen = length(); From Ulf.Zibis at CoSoCo.de Thu Mar 2 16:42:07 2017 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 2 Mar 2017 17:42:07 +0100 Subject: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened In-Reply-To: References: <000001d292d3$a72bb560$f5832020$@freenet.de> <10de9d22-6a32-dcac-838a-b88ac04e7b37@CoSoCo.de> Message-ID: Am 02.03.2017 um 14:55 schrieb Vitaly Davidovich: > Implicit null checks ... generally don't cost anything. Any additional byte of code in CPU cache prevents other code from staying there. > > I can't imagine, if any programmer would rely on such contract, instead of doing the check > explicitly if of significance. > > I think it's to have consistent behavior, irrespective of control flow. It can detect bugs early on. Yes, serving bug detection almost always has some cost and should be pondered, but the issue of this patch is to increase performance. Here I suspect the real value of the bug detection help. > I think, the original reasonable of the contract is to rule out any other exception type or > undefined behaviour in case of relevance of the argument. So I would vote for stating the contract > more precisely in that way. > > Also, if I remember correct, if a variable, here replStr, is only referenced later, the > compiler can > move the execution of here replacement.toString() to a later position, so it is not clear to > me, if > the original implementation ever fulfilled the contract. > > Compiler can only do that if it proves a bunch of things, such as no observable side effects as a > result of sinking it down. If CharSequence.toString isn't devirtualized there, eg, it definitely > cannot do it. I wouldn't bet on it. For the original code in case of inlining, I guess, the optimizer would place the null check before the if block and the allocation of the replacement String after. For the new code, the optimizer can detect the duplicate null check inside and outside the if block, so can move it before the if block. So both java codes could result in the same machine code. IMHO the effective optimization should be proved by HS disassembler. There is also the possibility, that an allocation of an intermediate String object is never done, because the anyway involved StringBuilder perhaps can insert the replacement sequence without before instantiating a String object. -Ulf From vitalyd at gmail.com Thu Mar 2 17:16:04 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 2 Mar 2017 12:16:04 -0500 Subject: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened In-Reply-To: References: <000001d292d3$a72bb560$f5832020$@freenet.de> <10de9d22-6a32-dcac-838a-b88ac04e7b37@CoSoCo.de> Message-ID: On Thu, Mar 2, 2017 at 11:42 AM, Ulf Zibis wrote: > > Am 02.03.2017 um 14:55 schrieb Vitaly Davidovich: > >> Implicit null checks ... generally don't cost anything. >> > Any additional byte of code in CPU cache prevents other code from staying > there. When the optimization applies, there shouldn't be *any* instructions for the null check on the path - it's done via signal handling. > > > >> I can't imagine, if any programmer would rely on such contract, >> instead of doing the check >> explicitly if of significance. >> >> I think it's to have consistent behavior, irrespective of control flow. >> It can detect bugs early on. >> > Yes, serving bug detection almost always has some cost and should be > pondered, but the issue of this patch is to increase performance. Here I > suspect the real value of the bug detection help. Performance by way of removing an allocation. There's already code in that method that's much more expensive than a test against a register. So while I suggested to move the explicit null check into the if block, I don't think it'll really matter. But removing an allocation is always a good thing. > > > I think, the original reasonable of the contract is to rule out any >> other exception type or >> undefined behaviour in case of relevance of the argument. So I would >> vote for stating the contract >> more precisely in that way. >> >> Also, if I remember correct, if a variable, here replStr, is only >> referenced later, the >> compiler can >> move the execution of here replacement.toString() to a later >> position, so it is not clear to >> me, if >> the original implementation ever fulfilled the contract. >> >> Compiler can only do that if it proves a bunch of things, such as no >> observable side effects as a result of sinking it down. If >> CharSequence.toString isn't devirtualized there, eg, it definitely cannot >> do it. I wouldn't bet on it. >> > For the original code in case of inlining, I guess, the optimizer would > place the null check before the if block and the allocation of the > replacement String after. For the new code, the optimizer can detect the > duplicate null check inside and outside the if block, so can move it before > the if block. So both java codes could result in the same machine code. > IMHO the effective optimization should be proved by HS disassembler. > This is Sufficiently Smart Compiler territory. It's much better to hand-code this properly, particularly since nothing is lost in readability or maintainability in this case. > > There is also the possibility, that an allocation of an intermediate > String object is never done, because the anyway involved StringBuilder > perhaps can insert the replacement sequence without before instantiating a > String object. I know C2 can remove some intermediate string allocations, but I would be very impressed if it handled this particular method in the way you describe. > > > -Ulf > > From Ulf.Zibis at CoSoCo.de Thu Mar 2 17:30:34 2017 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 2 Mar 2017 18:30:34 +0100 Subject: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened In-Reply-To: References: <000001d292d3$a72bb560$f5832020$@freenet.de> <10de9d22-6a32-dcac-838a-b88ac04e7b37@CoSoCo.de> Message-ID: Am 02.03.2017 um 18:16 schrieb Vitaly Davidovich: > When the optimization applies, there shouldn't be *any* instructions for the null check on the > path - it's done via signal handling. Thanks for clarification. > This is Sufficiently Smart Compiler territory. It's much better to hand-code this properly, > particularly since nothing is lost in readability or maintainability in this case. Convinced! -Ulf From naoto.sato at oracle.com Thu Mar 2 18:51:04 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 2 Mar 2017 10:51:04 -0800 Subject: RFR: 8176044: (tz) Support tzdata2017a In-Reply-To: <5906baa2-ce3c-41e1-aad7-db9583988a6e@default> References: <5906baa2-ce3c-41e1-aad7-db9583988a6e@default> Message-ID: Looks fine. Thanks, Ramanand. Naoto On 3/2/17 4:45 AM, Ramanand Patil wrote: > Hi all, > Please review the latest TZDATA integration (tzdata2017a) to JDK9. > Bug: https://bugs.openjdk.java.net/browse/JDK-8176044 > Webrev: http://cr.openjdk.java.net/~rpatil/8176044/webrev.00/ > > All the TimeZone related tests are passed after integration. > > Regards, > Ramanand. > From xueming.shen at oracle.com Fri Mar 3 02:56:56 2017 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 02 Mar 2017 18:56:56 -0800 Subject: RFR JDK-8176029: Linebreak matcher is not equivalent to the pattern as stated in javadoc Message-ID: <58B8DB78.9080909@oracle.com> Hi, Please help review the change for JDK-8176029 issue: https://bugs.openjdk.java.net/browse/JDK-8176029 webrev: http://cr.openjdk.java.net/~sherman/8176029/webrev It appears the API doc for \R is correct, instead the implementation is buggy when dealing with sequence "\r\n" (u+000du+000a). The existing implementation fails to backtrack to match \r and then next.match() when the attempt \r\n + next.match() failed. As a simple obvious sample both following should return true. The existing implementation returns false for the second. "\r\n".match("\\R") "\r\n".match("\\R\\n") Thanks, Sherman From xueming.shen at oracle.com Fri Mar 3 02:59:01 2017 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 02 Mar 2017 18:59:01 -0800 Subject: RFR JDK-8176029: Linebreak matcher is not equivalent to the pattern as stated in javadoc In-Reply-To: <58B8DB78.9080909@oracle.com> References: <58B8DB78.9080909@oracle.com> Message-ID: <58B8DBF5.2090207@oracle.com> On 3/2/17, 6:56 PM, Xueming Shen wrote: > Hi, > > Please help review the change for JDK-8176029 > > issue: https://bugs.openjdk.java.net/browse/JDK-8176029 > webrev: http://cr.openjdk.java.net/~sherman/8176029/webrev > > It appears the API doc for \R is correct, instead the implementation > is buggy when > dealing with sequence "\r\n" (u+000du+000a). The existing > implementation fails to > backtrack to match \r and then next.match() when the attempt \r\n + > next.match() > failed. As a simple obvious sample both following should return true. > The existing > implementation returns false for the second. > > "\r\n".match("\\R") > "\r\n".match("\\R\\n") "\r\n".matches("\\R") "\r\n".matches("\\R\\n") > > Thanks, > Sherman From forax at univ-mlv.fr Fri Mar 3 06:58:29 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 3 Mar 2017 07:58:29 +0100 (CET) Subject: Proposal: java.lang.reflect.Proxy and default methods In-Reply-To: <3af82dd3-a6bf-04d7-208f-b9857322d615@oracle.com> References: <4408a730-3f91-fe39-ef3f-b8ac00c1391c@gmail.com> <6F6ED6C5-9324-40F2-AE9A-E5BB15277733@oracle.com> <33B3EDCF-65C6-4991-A635-084B157A9D27@gmail.com> <1488402844432-300249.post@n7.nabble.com> <3af82dd3-a6bf-04d7-208f-b9857322d615@oracle.com> Message-ID: <2012342487.2211499.1488524309930.JavaMail.zimbra@u-pem.fr> Alan, i think we should update the doc section of j.l.r.Proxy to add a sentence about default methods ? R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: "mp911de" , core-libs-dev at openjdk.java.net > Envoy?: Jeudi 2 Mars 2017 09:28:35 > Objet: Re: Proposal: java.lang.reflect.Proxy and default methods > On 01/03/2017 21:14, mp911de wrote: > >> Is there any progress on this issue? In the light of Java 9, the workaround >> with >> MethodHandles.lookup()/unreflectSpecial does not work anymore because >> MethodHandles is encapsulated and calling setAccessible(true) on the >> constructor fails. >> >> Resolving method handles inside the same module seems to work with public >> lookup, >> but as soon as a module defines an interface with default methods and this >> interface is called by a proxy handler that comes from a different module, >> it's >> no longer possible to resolve the MethodHandle. >> >> Is this the appropriate mailing list for this case? >> > I assume you are looking for the "Non-abstract methods in interfaces" > section in JEP 274 [1]. See also John Rose's note to jigsaw-dev about > using Lookup.findSpecial to access default methods in interfaces [2]. > > -Alan > > [1] http://openjdk.java.net/jeps/274 > [2] > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-January/010741.html From martinrb at google.com Fri Mar 3 19:43:54 2017 From: martinrb at google.com (Martin Buchholz) Date: Fri, 3 Mar 2017 11:43:54 -0800 Subject: RFR: jsr166 jdk? integration wave ? In-Reply-To: References: Message-ID: Changes except for ThreadPoolExecutor.java submitted. ThreadPoolExecutor doc change is deferred to jdk10. We have a new change, to SubmissionPublisher, which should probably make jdk9 because SubmissionPublisher is new to jdk9. https://bugs.openjdk.java.net/browse/JDK-8176155 On Fri, Feb 24, 2017 at 7:11 AM, Martin Buchholz wrote: > > > On Fri, Feb 24, 2017 at 2:59 AM, Chris Hegarty > wrote: > >> Martin, >> >> > On 22 Feb 2017, at 20:30, Martin Buchholz wrote: >> > >> > We half promised "no more jdk9 changes", but ... >> > >> > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166- >> jdk9-integration/ >> > >> > as usual, I think they should go into jdk9, but y'all probably tell me >> it's >> > too late (and that's OK; we can retarget for jdk10) >> >> Are there any spec changes, or all rewordings that do not affect spec >> (there?s quite a bit of noise in the webrevs )? >> > > There's only the "spec change" in ThreadPoolExecutor.java. I don't count > that as a "real" spec change, because the original intent is clear enough, > but you might disagree. > > From naoto.sato at oracle.com Fri Mar 3 21:19:38 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 3 Mar 2017 13:19:38 -0800 Subject: [9] RFR: 8174736: [JCP] [Mac]Cannot launch JCP on Mac os with language set to "Chinese, Simplified" while region is not China Message-ID: <551c1dea-da72-920d-f2fb-557657923734@oracle.com> Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8174736 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8174736/webrev.00/ This is a follow-on fix to 8174779 [1]. The previous fix addresses the issue for the default locale, and this one is to address the default format locale in order to handle locales with script codes on macOS. Naoto [1] https://bugs.openjdk.java.net/browse/JDK-8174779 From igor.ignatyev at oracle.com Sat Mar 4 06:38:57 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 3 Mar 2017 22:38:57 -0800 Subject: RFR(XXS) : 8176162 : com/sun/jndi/dns/Parser.java is not executed Message-ID: <86A1BAF2-B7CA-408D-BFDF-7F3F0806AB45@oracle.com> Hi all, Could you please review this tiny fix which adds '@run main? to jdk/test/com/sun/jndi/dns/Parser.java test? The test has only one compile action, as a result jtreg only compiles java file, but does not execute the test. Web rev: http://cr.openjdk.java.net/~iignatyev//8176162/webrev.00/index.html Bug: https://bugs.openjdk.java.net/browse/JDK-8176162 Testing: run the test locally and checked .jtr file Thanks, ? Igor From roger.riggs at oracle.com Sat Mar 4 10:49:46 2017 From: roger.riggs at oracle.com (Roger Riggs) Date: Sat, 4 Mar 2017 10:49:46 +0000 Subject: RFR(XXS) : 8176162 : com/sun/jndi/dns/Parser.java is not executed In-Reply-To: <86A1BAF2-B7CA-408D-BFDF-7F3F0806AB45@oracle.com> References: <86A1BAF2-B7CA-408D-BFDF-7F3F0806AB45@oracle.com> Message-ID: <48f01326-d3d0-31e0-e189-68ec60a4e7fc@oracle.com> Hi Igor, Looks fine, Roger On 3/4/17 6:38 AM, Igor Ignatyev wrote: > Hi all, > > Could you please review this tiny fix which adds '@run main? to jdk/test/com/sun/jndi/dns/Parser.java test? > The test has only one compile action, as a result jtreg only compiles java file, but does not execute the test. > > Web rev: http://cr.openjdk.java.net/~iignatyev//8176162/webrev.00/index.html > Bug: https://bugs.openjdk.java.net/browse/JDK-8176162 > Testing: run the test locally and checked .jtr file > > Thanks, > ? Igor From amy.lu at oracle.com Mon Mar 6 03:06:54 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 6 Mar 2017 11:06:54 +0800 Subject: JDK 9 RFR of JDK-8176185: java/util/TimeZone/UTCAliasTest.java is not run Message-ID: java/util/TimeZone/UTCAliasTest.java This is not a compile-only test, but due to the missed @run tag, test is not run. Please review the patch to add @run tag to the test. bug: https://bugs.openjdk.java.net/browse/JDK-8176185 Thanks, Amy --- old/test/java/util/TimeZone/UTCAliasTest.java 2017-03-06 11:01:33.000000000 +0800 +++ new/test/java/util/TimeZone/UTCAliasTest.java 2017-03-06 11:01:33.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2005, 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2017, 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 @@ -27,6 +27,7 @@ * @summary Make sure that "UTC" is an alias of "Etc/UTC" as defined in the tzdata backward. * @modules java.base/sun.util.calendar * @compile -XDignore.symbol.file UTCAliasTest.java + * @run main UTCAliasTest */ import java.util.*; From amy.lu at oracle.com Mon Mar 6 05:34:48 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 6 Mar 2017 13:34:48 +0800 Subject: JDK 9 RFR of JDK-8176182: 4 security tests are not run In-Reply-To: References: <6068a2b1-4398-6cfa-f4f5-ea4e8e73451d@oracle.com> Message-ID: <68177779-38cb-e36b-df36-281a0d2e1d27@oracle.com> Thank you Max for your review. I noticed this issue: (Thanks to Igor) JDK-8176162: com/sun/jndi/dns/Parser.java is not executed https://bugs.openjdk.java.net/browse/JDK-8176162 So checked other jdk tests, and found more similar issues. jtreg enhancement created with the hope to get help from test harness to avoid such issue in the future: CODETOOLS-7901909: Enforce @compile/ for compile-only test, make test results Error if test has @compile or @build but no @run tag https://bugs.openjdk.java.net/browse/CODETOOLS-7901909 Thanks, Amy On 3/6/17 11:52 AM, Weijun Wang wrote: > Hi Amy > > Change looks good. > > BTW, how did you notice this? > > Thanks > Max > > On 03/06/2017 10:48 AM, Amy Lu wrote: >> sun/security/ec/SignedObjectChain.java >> sun/security/mscapi/SignedObjectChain.java >> sun/security/rsa/SignedObjectChain.java >> sun/security/ssl/rsa/SignedObjectChain.java >> >> These tests are not compile-only tests, but due to the missed @run tag, >> tests are not run. >> >> Please review the patch to add @run tag to them. >> >> Note that with the added @run tag, test result show that >> sun/security/mscapi/SignedObjectChain.java fails. Problem list it for >> now. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8176182 >> webrev: http://cr.openjdk.java.net/~amlu/8176182/webrev.00/ >> >> Thanks, >> Amy >> >> --- old/test/ProblemList.txt 2017-03-06 10:43:29.000000000 +0800 >> +++ new/test/ProblemList.txt 2017-03-06 10:43:29.000000000 +0800 >> @@ -215,6 +215,8 @@ >> javax/net/ssl/DTLS/PacketLossRetransmission.java 8169086 macosx-x64 >> javax/net/ssl/DTLS/RespondToRetransmit.java 8169086 macosx-x64 >> >> +sun/security/mscapi/SignedObjectChain.java 8176183 windows-all >> + >> ############################################################################ >> >> >> # jdk_sound >> --- old/test/sun/security/ec/SignedObjectChain.java 2017-03-06 >> 10:43:30.000000000 +0800 >> +++ new/test/sun/security/ec/SignedObjectChain.java 2017-03-06 >> 10:43:30.000000000 +0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2015, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2015, 2017, 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 >> @@ -24,8 +24,9 @@ >> /* >> * @test >> * @bug 8050374 >> - * @compile ../../../java/security/SignedObject/Chain.java >> * @summary Verify a chain of signed objects >> + * @compile ../../../java/security/SignedObject/Chain.java >> + * @run main SignedObjectChain >> */ >> public class SignedObjectChain { >> >> --- old/test/sun/security/mscapi/SignedObjectChain.java 2017-03-06 >> 10:43:31.000000000 +0800 >> +++ new/test/sun/security/mscapi/SignedObjectChain.java 2017-03-06 >> 10:43:30.000000000 +0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2015, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2015, 2017, 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 >> @@ -24,9 +24,10 @@ >> /* >> * @test >> * @bug 8050374 >> + * @summary Verify a chain of signed objects >> * @compile ../../../java/security/SignedObject/Chain.java >> * @requires os.family == "windows" >> - * @summary Verify a chain of signed objects >> + * @run main SignedObjectChain >> */ >> public class SignedObjectChain { >> >> --- old/test/sun/security/rsa/SignedObjectChain.java 2017-03-06 >> 10:43:32.000000000 +0800 >> +++ new/test/sun/security/rsa/SignedObjectChain.java 2017-03-06 >> 10:43:31.000000000 +0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2015, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2015, 2017, 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 >> @@ -24,8 +24,9 @@ >> /* >> * @test >> * @bug 8050374 >> - * @compile ../../../java/security/SignedObject/Chain.java >> * @summary Verify a chain of signed objects >> + * @compile ../../../java/security/SignedObject/Chain.java >> + * @run main SignedObjectChain >> */ >> public class SignedObjectChain { >> >> --- old/test/sun/security/ssl/rsa/SignedObjectChain.java 2017-03-06 >> 10:43:32.000000000 +0800 >> +++ new/test/sun/security/ssl/rsa/SignedObjectChain.java 2017-03-06 >> 10:43:32.000000000 +0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2015, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2015, 2017, 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 >> @@ -24,8 +24,9 @@ >> /* >> * @test >> * @bug 8050374 >> - * @compile ../../../../java/security/SignedObject/Chain.java >> * @summary Verify a chain of signed objects >> + * @compile ../../../../java/security/SignedObject/Chain.java >> + * @run main SignedObjectChain >> */ >> public class SignedObjectChain { >> >> >> From amy.lu at oracle.com Mon Mar 6 06:17:22 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 6 Mar 2017 14:17:22 +0800 Subject: JDK 9 RFR of JDK-8176187: jdk/internal/misc/JavaLangAccess/NewUnsafeString.java is not run Message-ID: <763485bc-36f6-07e3-4da2-8d77b0e110f6@oracle.com> jdk/internal/misc/JavaLangAccess/NewUnsafeString.java This is not a compile-only test, but due to the missed @run tag, test is not run. Please review the patch to add @run tag to the test. Note this test starts failing since 9/b93 (JDK-8176188), test is problem listed in this patch. bug: https://bugs.openjdk.java.net/browse/JDK-8176187 webrev: http://cr.openjdk.java.net/~amlu/8176187/webrev.00/ Thanks, Amy --- old/test/ProblemList.txt 2017-03-06 14:12:35.000000000 +0800 +++ new/test/ProblemList.txt 2017-03-06 14:12:35.000000000 +0800 @@ -125,6 +125,8 @@ java/lang/StringCoding/CheckEncodings.sh 7008363 generic-all +jdk/internal/misc/JavaLangAccess/NewUnsafeString.java 8176188 generic-all + ############################################################################ # jdk_instrument --- old/test/jdk/internal/misc/JavaLangAccess/NewUnsafeString.java 2017-03-06 14:12:36.000000000 +0800 +++ new/test/jdk/internal/misc/JavaLangAccess/NewUnsafeString.java 2017-03-06 14:12:36.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2017, 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 @@ -32,6 +32,7 @@ * @summary Test JavaLangAccess.newUnsafeString * @modules java.base/jdk.internal.misc * @compile -XDignore.symbol.file NewUnsafeString.java + * @run main NewUnsafeString */ public class NewUnsafeString { From Alan.Bateman at oracle.com Mon Mar 6 07:47:49 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 6 Mar 2017 07:47:49 +0000 Subject: JDK 9 RFR of JDK-8176185: java/util/TimeZone/UTCAliasTest.java is not run In-Reply-To: References: Message-ID: <3a39cb42-4125-649e-c3f6-96bc4bd9080f@oracle.com> On 06/03/2017 03:06, Amy Lu wrote: > java/util/TimeZone/UTCAliasTest.java > > This is not a compile-only test, but due to the missed @run tag, test > is not run. > > Please review the patch to add @run tag to the test. Looks okay, alternatively then I assume dropping the @compile tag will work too. -Alan From Alan.Bateman at oracle.com Mon Mar 6 07:49:58 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 6 Mar 2017 07:49:58 +0000 Subject: JDK 9 RFR of JDK-8176187: jdk/internal/misc/JavaLangAccess/NewUnsafeString.java is not run In-Reply-To: <763485bc-36f6-07e3-4da2-8d77b0e110f6@oracle.com> References: <763485bc-36f6-07e3-4da2-8d77b0e110f6@oracle.com> Message-ID: On 06/03/2017 06:17, Amy Lu wrote: > jdk/internal/misc/JavaLangAccess/NewUnsafeString.java > > This is not a compile-only test, but due to the missed @run tag, test > is not run. > > Please review the patch to add @run tag to the test. > > Note this test starts failing since 9/b93 (JDK-8176188), test is > problem listed in this patch. Looks okay, I hope there aren't too many more of these. -Alan From amy.lu at oracle.com Mon Mar 6 08:16:07 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 6 Mar 2017 16:16:07 +0800 Subject: JDK 9 RFR of JDK-8176187: jdk/internal/misc/JavaLangAccess/NewUnsafeString.java is not run In-Reply-To: References: <763485bc-36f6-07e3-4da2-8d77b0e110f6@oracle.com> Message-ID: <4ae591d2-3507-c523-e708-ca63b7952e39@oracle.com> On 3/6/17 3:49 PM, Alan Bateman wrote: > Looks okay, I hope there aren't too many more of these. > > -Alan * @compile -XDignore.symbol.file UTCAliasTest.java + * @run main UTCAliasTest */ I noticed that -XDignore.symbol.file are still used in "9" test, thought they might be bulk changed with JDK-8133887. For now, I pushed with added @run tag. Thanks, Amy From chris.hegarty at oracle.com Mon Mar 6 13:10:00 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 6 Mar 2017 13:10:00 +0000 Subject: RFR: jsr166 jdk? integration wave ? In-Reply-To: References: Message-ID: On 03/03/17 19:43, Martin Buchholz wrote: > Changes except for ThreadPoolExecutor.java submitted. > > ThreadPoolExecutor doc change is deferred to jdk10. > > We have a new change, to SubmissionPublisher, which should probably make > jdk9 because SubmissionPublisher is new to jdk9. > > https://bugs.openjdk.java.net/browse/JDK-8176155 Agreed. The webrev for this looks ok for 9. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/SubmissionPublisher/ -Chris. From sander.mak at luminis.eu Mon Mar 6 15:46:06 2017 From: sander.mak at luminis.eu (Sander Mak) Date: Mon, 6 Mar 2017 15:46:06 +0000 Subject: ProcessHandle::onExit behavior Message-ID: <0A813A40-296C-4A79-86F3-EB8AA3A4CFFE@luminis.eu> I was trying to get an example to work with the new ProcessHandle API. My goal was to wait on another process (Spotify) to terminate before printing something to the console: ProcessHandle handle = ProcessHandle.allProcesses() .filter(h -> h.info().commandLine().map(cmd -> cmd.contains("Spotify")).orElse(false)) .findFirst() .orElseThrow(() -> new IllegalArgumentException("No matching handle found")); System.out.println(handle.info()); ProcessHandle completed = handle.onExit().get(); System.out.println(completed.isAlive()); However this code doesn't wait on `handle` to be terminated, as the JavaDoc of onExit led me to believe: "Calling onExit().get() waits for the process to terminate and returns the ProcessHandle.". What I expected: the get() call blocks until I terminate the Spotify process. Instead, it runs to completion and prints true for the `isAlive` call in the end. Am I missing something? Env: Java(TM) SE Runtime Environment (build 9-ea+157-jigsaw-nightly-h6122-20170221) on MacOS. Also, first time posting to this list, I hope this is the right avenue for these questions. Sander From lance.andersen at oracle.com Mon Mar 6 20:34:13 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 6 Mar 2017 15:34:13 -0500 Subject: RFR JDK-8176235: Minor updates to package.html Message-ID: <79501BA1-C3D1-4D14-9D93-DC16FC051B93@oracle.com> Hi all, This RFR is for minor updates to package.html for JDBC. For JDK 10, I will probably overhaul these files and possibly convert to package-info.java. But for now just keeping the updates minimal. Best Lance ?????????? ljanders-mac:classes ljanders$ hg diff java/sql/package.html javax/sql/package.html diff -r b35a2a941498 src/java.sql/share/classes/java/sql/package.html --- a/src/java.sql/share/classes/java/sql/package.html Fri Mar 03 22:00:27 2017 -0800 +++ b/src/java.sql/share/classes/java/sql/package.html Mon Mar 06 15:08:47 2017 -0500 @@ -2,7 +2,7 @@