March 2017 - core-libs-dev

[NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened
by Christoph Dreis 02 Mar '17

02 Mar '17

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();

5 19

[10] RFR: 8176041: Optimize handling of comment lines in Properties$LineReader.readLine
by Claes Redestad 02 Mar '17

02 Mar '17

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

5 7

RE: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar
by Baesken, Matthias 02 Mar '17

02 Mar '17

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(a)openjdk.java.net' <core-libs-dev(a)openjdk.java.net> Cc: Langer, Christoph <christoph.langer(a)sap.com>; Erik Joelsson (erik.joelsson(a)oracle.com) <erik.joelsson(a)oracle.com>; 'Michel Trudeau' <michel.trudeau(a)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(a)openjdk.java.net' <core-libs-dev(a)openjdk.java.net<mailto:core-libs-dev@openjdk.java.net>> Cc: Langer, Christoph <christoph.langer(a)sap.com<mailto:christoph.langer@sap.com>>; Erik Joelsson (erik.joelsson(a)oracle.com<mailto:erik.joelsson@oracle.com>) <erik.joelsson(a)oracle.com<mailto:erik.joelsson@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(a)openjdk.java.net<mailto:core-libs-dev@openjdk.java.net> Cc: Langer, Christoph <christoph.langer(a)sap.com<mailto:christoph.langer@sap.com>>; Erik Joelsson (erik.joelsson(a)oracle.com<mailto:erik.joelsson@oracle.com>) <erik.joelsson(a)oracle.com<mailto:erik.joelsson@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<https://javapartner.oracle.com/mproxy/repository/technology/java2/jdk9/jdk/…> . 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);

4 7

Forcing initialization of string concat INDY expressions
by David Holmes 01 Mar '17

01 Mar '17

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@ObjectMonitor@@QAEXPAVThread@@@Z+0x170 V [jvm.dll+0x862035] ObjectSynchronizer::slow_enter+0x1d5;; ?slow_enter@ObjectSynchronizer@@SAXVHandle@@PAVBasicLock@@PAVThread@@@Z+0x1d5 V [jvm.dll+0x85fe8f] ObjectSynchronizer::fast_enter+0xff;; ?fast_enter@ObjectSynchronizer@@SAXVHandle@@PAVBasicLock@@_NPAVThread@@@Z+0xff V [jvm.dll+0x2b5412] Runtime1::monitorenter+0x1e2;; ?monitorenter@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@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@9-internal (66 bytes) @ 0x0242ca20 [0x0242c9a0+0x00000080] J 255 c1 java.lang.invoke.MemberName.getMethodOrFieldType()Ljava/lang/invoke/MethodType; java.base@9-internal (72 bytes) @ 0x02445238 [0x02444f20+0x00000318] J 239 c1 java.lang.invoke.InvokerBytecodeGenerator.isStaticallyInvocable(Ljava/lang/invoke/MemberName;)Z java.base@9-internal (169 bytes) @ 0x0243dc28 [0x0243d820+0x00000408] j java.lang.invoke.InvokerBytecodeGenerator.addMethod()V+648 java.base@9-internal j java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes()[B+6 java.base@9-internal j java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(Ljava/lang/invoke/LambdaForm;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MemberName;+25 java.base@9-internal j java.lang.invoke.LambdaForm.compileToBytecode()V+69 java.base@9-internal j java.lang.invoke.LambdaForm.prepare()V+21 java.base@9-internal j java.lang.invoke.MethodHandle.<init>(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;)V+33 java.base@9-internal j java.lang.invoke.BoundMethodHandle.<init>(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;)V+3 java.base@9-internal j java.lang.invoke.BoundMethodHandle$Species_L9.<init>(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@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@9-internal j java.lang.invoke.MethodHandles.dropArguments0(Ljava/lang/invoke/MethodHandle;ILjava/util/List;)Ljava/lang/invoke/MethodHandle;+105 java.base@9-internal j java.lang.invoke.MethodHandles.dropArguments(Ljava/lang/invoke/MethodHandle;I[Ljava/lang/Class;)Ljava/lang/invoke/MethodHandle;+6 java.base@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@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@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@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@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@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@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@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@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@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@9-internal v ~StubRoutines::call_stub V [jvm.dll+0x526f80] JavaCalls::call_helper+0x390;; ?call_helper@JavaCalls@@CAXPAVJavaValue@@ABVmethodHandle@@PAVJavaCallArguments@@PAVThread@@@Z+0x390 V [jvm.dll+0x7777c5] os::os_exception_wrapper+0xb5;; ?os_exception_wrapper@os@@SAXP6AXPAVJavaValue@@ABVmethodHandle@@PAVJavaCallArguments@@PAVThread@@@Z0123@Z+0xb5 V [jvm.dll+0x526bdb] JavaCalls::call+0x5b;; ?call@JavaCalls@@SAXPAVJavaValue@@ABVmethodHandle@@PAVJavaCallArguments@@PAVThread@@@Z+0x5b V [jvm.dll+0x527349] JavaCalls::call_static+0xc9;; ?call_static@JavaCalls@@SAXPAVJavaValue@@VKlassHandle@@PAVSymbol@@2PAVJavaCallArguments@@PAVThread@@@Z+0xc9 V [jvm.dll+0x864617] SystemDictionary::find_dynamic_call_site_invoker+0x687;; ?find_dynamic_call_site_invoker@SystemDictionary@@SA?AVmethodHandle@@VKlassHandle@@VHandle@@PAVSymbol@@2PAV4@3PAVThread@@@Z+0x687 V [jvm.dll+0x65eb84] LinkResolver::resolve_dynamic_call+0x44;; ?resolve_dynamic_call@LinkResolver@@SAXAAVCallInfo@@VHandle@@PAVSymbol@@2VKlassHandle@@PAVThread@@@Z+0x44 V [jvm.dll+0x66014e] LinkResolver::resolve_invokedynamic+0x35e;; ?resolve_invokedynamic@LinkResolver@@CAXAAVCallInfo@@ABVconstantPoolHandle@@HPAVThread@@@Z+0x35e V [jvm.dll+0x65fd7e] LinkResolver::resolve_invoke+0x8e;; ?resolve_invoke@LinkResolver@@SAXAAVCallInfo@@VHandle@@ABVconstantPoolHandle@@HW4Code@Bytecodes@@PAVThread@@@Z+0x8e V [jvm.dll+0x51eb0b] InterpreterRuntime::resolve_invokedynamic+0x7b;; ?resolve_invokedynamic@InterpreterRuntime@@CAXPAVJavaThread@@@Z+0x7b V [jvm.dll+0x51dee4] InterpreterRuntime::resolve_from_cache+0xd4;; ?resolve_from_cache@InterpreterRuntime@@SAXPAVJavaThread@@W4Code@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@JavaCalls@@CAXPAVJavaValue@@ABVmethodHandle@@PAVJavaCallArguments@@PAVThread@@@Z+0x390 V [jvm.dll+0x7777c5] os::os_exception_wrapper+0xb5;; ?os_exception_wrapper@os@@SAXP6AXPAVJavaValue@@ABVmethodHandle@@PAVJavaCallArguments@@PAVThread@@@Z0123@Z+0xb5 V [jvm.dll+0x526bdb] JavaCalls::call+0x5b;; ?call@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@ObjectMonitor@@QAEX_J_NPAVThread@@@Z+0x3bd

3 3

10 RFR: 8150687: typedefs without type names
by Kim Barrett 01 Mar '17

01 Mar '17

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

3 3