From gnu.andrew at redhat.com Wed Jun 1 03:00:18 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 31 May 2016 23:00:18 -0400 (EDT) Subject: SIGILL crashes JVM on PPC64 LE In-Reply-To: <201605310131.u4V1T6HM033728@mx0a-001b2d01.pphosted.com> References: <5733B30D.6010201@linux.vnet.ibm.com> <201605310131.u4V1T6HM033728@mx0a-001b2d01.pphosted.com> Message-ID: <1733568059.1110524.1464750018575.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi Volker > > The following test case has been isolated by Hiroshi Horii and generates > the illegal instruction, crashing the JVM on PPC64 LE: > > UnalignedUnsafeAccess.java: > http://hastebin.com/raw/uqegukific > > $ javac UnalignedUnsafeAccess.java > $ java -Xcomp -Xbatch UnalignedUnsafeAccess > > The issue can be reproduced on OpenJDK 8 downstream, OpenJDK 8, and > OpenJDK 9 - hs_err logs: > > OpenJDK 9, tag 0be6f4f5d186 jdk-9+120: > http://hastebin.com/raw/ecuhukutur > > OpenJDK 8, tag 5aaa43d91c73 tip: > http://hastebin.com/raw/ipohoyafos > > OpenJDK 8 downstream: > > Ubuntu 16.04 LTS > build 1.8.0_91-8u91-b14-0ubuntu4~16.04.1-b14 > http://hastebin.com/raw/yetizebofo > > RHEL 7.2: > build 1.8.0_91-b14 > http://hastebin.com/raw/irequfawaw > > The crash happens when an illegal instruction - 0xea2f0013 - is executed. > > The backtrace shows: > > Stack: [0x00003fff56030000,0x00003fff56430000], sp=0x00003fff5642b8d0, free > space=4078k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native > code) > V [libjvm.so+0x162104] loadI2LNode::emit(CodeBuffer&, PhaseRegAlloc*) > const+0x194 > V [libjvm.so+0x8ece28] Compile::fill_buffer(CodeBuffer*, unsigned > int*)+0x4e8 > V [libjvm.so+0x368e08] Compile::Code_Gen()+0x3c8 > V [libjvm.so+0x369e04] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, > int, bool, bool, bool)+0xf64 > V [libjvm.so+0x271380] C2Compiler::compile_method(ciEnv*, ciMethod*, > int)+0x1f0 > V [libjvm.so+0x3785a4] > CompileBroker::invoke_compiler_on_method(CompileTask*)+0xd54 > V [libjvm.so+0x379dc8] CompileBroker::compiler_thread_loop()+0x488 > V [libjvm.so+0xa5de90] compiler_thread_entry(JavaThread*, Thread*)+0x20 > V [libjvm.so+0xa690c8] JavaThread::thread_main_inner()+0x178 > V [libjvm.so+0x8c8c10] java_start(Thread*)+0x170 > C [libpthread.so.0+0x833c] start_thread+0xfc > C [libc.so.6+0x12b014] clone+0xe4 > > loadI2LNode class is generated according to the following ADL code in > ppc.ad file: > > instruct loadI2L(iRegLdst dst, memory mem) %{ > match(Set dst (ConvI2L (LoadI mem))); > predicate(_kids[0]->_leaf->as_Load()->is_unordered()); > ins_cost(MEMORY_REF_COST); > > format %{ "LWA $dst, $mem \t// loadI2L" %} > size(4); > ins_encode %{ > // TODO: PPC port $archOpcode(ppc64Opcode_lwa); > int Idisp = $mem$$disp + frame_slots_bias($mem$$base, ra_); > __ lwa($dst$$Register, Idisp, $mem$$base$$Register); > %} > ins_pipe(pipe_class_memory); > %} > > So the generated illegal instruction comes from: > lwa 17,17,15 (DS-form: lwa RT, DS, RA) > > As DS field must always be 4-byte aligned (i.e. DS field is always > concatenated with 0b00), 17 as DS (middle 17 value) is illegal, > generating the illegal instruction in question: > > 11101010000000000000000000000010: LWA > 00000010001000000000000000000000: 17 > 00000000000000000000000000010001: 17 > 00000000000011110000000000000000: 15 > -------------------------------- > 11101010001011110000000000010011: 0xEA2F0013 => Illegal instruction > > The following change is proposed to fix the issue and deals with the > unaligned displacements: > > OpenJDK 9 webrev: > 81.de.7a9f.ip4.static.sl-reverse.com./illegal/9 > > OpenJDK 8 webrev: > 81.de.7a9f.ip4.static.sl-reverse.com./illegal/8 > > Could we open a JIRA ticket regarding this issue in order to include it > in the webrev? > Done: https://bugs.openjdk.java.net/browse/JDK-8158318 Reproduced on IcedTea 2.6.6 & OpenJDK 8u92: # JRE version: OpenJDK Runtime Environment (7.0_101) (build 1.7.0_101-mockbuild_2016_04_19_09_08-b00) # Java VM: OpenJDK 64-Bit Server VM (24.95-b01 compiled mode linux-ppc64 compressed oops) # Derivative: IcedTea 2.6.6pre01 # Distribution: Red Hat Enterprise Linux Server release 7.2 (Maipo), package rhel-2.6.6.2.el7-ppc64le u101-b00 # Problematic frame: # J 602 C2 UnalignedUnsafeAccess$NativeCell.path()Ljava/lang/String; (106 bytes) @ 0x00003fff88184430 [0x00003fff88184400+0x30] # JRE version: OpenJDK Runtime Environment (8.0_92-b14) (build 1.8.0_92-b14) # Java VM: OpenJDK 64-Bit Server VM (25.92-b14 compiled mode linux-ppc64 compressed oops) # Problematic frame: # J 485 C2 UnalignedUnsafeAccess$NativeCell.path()Ljava/lang/String; (106 bytes) @ 0x00003fff8015f030 [0x00003fff8015f000+0x30] -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From tobias.hartmann at oracle.com Wed Jun 1 05:39:28 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 1 Jun 2016 07:39:28 +0200 Subject: [9] RFR(S): 8156760: VM crashes if -XX:-ReduceInitialCardMarks is set In-Reply-To: <6d45938b-c7d9-6ea2-7821-4a6344de32f4@oracle.com> References: <5742CC7F.4050309@oracle.com> <5745C75C.80208@oracle.com> <574BEA7C.3040000@oracle.com> <1464692918.2464.20.camel@oracle.com> <574D7505.9090005@oracle.com> <6d45938b-c7d9-6ea2-7821-4a6344de32f4@oracle.com> Message-ID: <574E7510.2000606@oracle.com> Thanks, Vladimir! Best regards, Tobias On 31.05.2016 20:14, Vladimir Kozlov wrote: > Looks good to me. > > Thanks, > Vladimir > > On 5/31/16 4:27 AM, Tobias Hartmann wrote: >> Hi Thomas, >> >> On 31.05.2016 13:08, Thomas Schatzl wrote: >>> Hi Tobias, >>> >>> On Mon, 2016-05-30 at 09:23 +0200, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> all tests passed (link is attached to the bug). Is everyone fine with >>>> the latest webrev? >>>> http://cr.openjdk.java.net/~thartmann/8156760/webrev.02/ >>>> >>> >>> I would think it is good. I believe the necessary actions (card >>> marking) are taken with -XX:-ReduceInitialCardMarks from the comments, >>> in the places I would expect them. However my C2-fu is limited to >>> hacking together barriers, so I am honestly unable to verify that the >>> code in detail is correct. >> >> Thanks for looking at this again! >> >>> Somebody more knowledgable in C2 in general needs to look at this. >>> >>> If you have time, copyrights may need to be fixed up. I do not need a >>> re-review for that. >> >> Right, I updated the copyright dates in-place. >> >> Thanks, >> Tobias >> >>> >>> Thanks, >>> Thomas >>> From volker.simonis at gmail.com Wed Jun 1 06:37:21 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 1 Jun 2016 08:37:21 +0200 Subject: SIGILL crashes JVM on PPC64 LE In-Reply-To: <201605310131.u4V1TL5g037744@mx0a-001b2d01.pphosted.com> References: <5733B30D.6010201@linux.vnet.ibm.com> <201605310131.u4V1TL5g037744@mx0a-001b2d01.pphosted.com> Message-ID: Hi Gustavo, Hiroshi, thanks a lot for the great analysis and the nice stand-alone test case. This is indeed a problem, and it also occurs on ppc64 big-endian. I've opened "8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions" (https://bugs.openjdk.java.net/browse/JDK-8158260) for this issue. I'm currently looking at your proposed fix and will come back with a new webrev soon. Thanks a lot and best regards, Volker On Tue, May 31, 2016 at 3:31 AM, Gustavo Romero wrote: > Hi Volker > > The following test case has been isolated by Hiroshi Horii and generates > the illegal instruction, crashing the JVM on PPC64 LE: > > UnalignedUnsafeAccess.java: > http://hastebin.com/raw/uqegukific > > $ javac UnalignedUnsafeAccess.java > $ java -Xcomp -Xbatch UnalignedUnsafeAccess > > The issue can be reproduced on OpenJDK 8 downstream, OpenJDK 8, and > OpenJDK 9 - hs_err logs: > > OpenJDK 9, tag 0be6f4f5d186 jdk-9+120: > http://hastebin.com/raw/ecuhukutur > > OpenJDK 8, tag 5aaa43d91c73 tip: > http://hastebin.com/raw/ipohoyafos > > OpenJDK 8 downstream: > > Ubuntu 16.04 LTS > build 1.8.0_91-8u91-b14-0ubuntu4~16.04.1-b14 > http://hastebin.com/raw/yetizebofo > > RHEL 7.2: > build 1.8.0_91-b14 > http://hastebin.com/raw/irequfawaw > > The crash happens when an illegal instruction - 0xea2f0013 - is executed. > > The backtrace shows: > > Stack: [0x00003fff56030000,0x00003fff56430000], sp=0x00003fff5642b8d0, free space=4078k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x162104] loadI2LNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0x194 > V [libjvm.so+0x8ece28] Compile::fill_buffer(CodeBuffer*, unsigned int*)+0x4e8 > V [libjvm.so+0x368e08] Compile::Code_Gen()+0x3c8 > V [libjvm.so+0x369e04] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0xf64 > V [libjvm.so+0x271380] C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0x1f0 > V [libjvm.so+0x3785a4] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xd54 > V [libjvm.so+0x379dc8] CompileBroker::compiler_thread_loop()+0x488 > V [libjvm.so+0xa5de90] compiler_thread_entry(JavaThread*, Thread*)+0x20 > V [libjvm.so+0xa690c8] JavaThread::thread_main_inner()+0x178 > V [libjvm.so+0x8c8c10] java_start(Thread*)+0x170 > C [libpthread.so.0+0x833c] start_thread+0xfc > C [libc.so.6+0x12b014] clone+0xe4 > > loadI2LNode class is generated according to the following ADL code in > ppc.ad file: > > instruct loadI2L(iRegLdst dst, memory mem) %{ > match(Set dst (ConvI2L (LoadI mem))); > predicate(_kids[0]->_leaf->as_Load()->is_unordered()); > ins_cost(MEMORY_REF_COST); > > format %{ "LWA $dst, $mem \t// loadI2L" %} > size(4); > ins_encode %{ > // TODO: PPC port $archOpcode(ppc64Opcode_lwa); > int Idisp = $mem$$disp + frame_slots_bias($mem$$base, ra_); > __ lwa($dst$$Register, Idisp, $mem$$base$$Register); > %} > ins_pipe(pipe_class_memory); > %} > > So the generated illegal instruction comes from: > lwa 17,17,15 (DS-form: lwa RT, DS, RA) > > As DS field must always be 4-byte aligned (i.e. DS field is always > concatenated with 0b00), 17 as DS (middle 17 value) is illegal, > generating the illegal instruction in question: > > 11101010000000000000000000000010: LWA > 00000010001000000000000000000000: 17 > 00000000000000000000000000010001: 17 > 00000000000011110000000000000000: 15 > -------------------------------- > 11101010001011110000000000010011: 0xEA2F0013 => Illegal instruction > > The following change is proposed to fix the issue and deals with the > unaligned displacements: > > OpenJDK 9 webrev: > 81.de.7a9f.ip4.static.sl-reverse.com./illegal/9 > > OpenJDK 8 webrev: > 81.de.7a9f.ip4.static.sl-reverse.com./illegal/8 > > Could we open a JIRA ticket regarding this issue in order to include it > in the webrev? > > Thank you! > > Best regards, > Gustavo > > On 12-05-2016 09:39, Volker Simonis wrote: >> And I forgot to mention: I've checked and we don't emit vsel >> instructions in jdk8 on ppc. So it must be a coincidence that changing >> the endianess of the offending instruction yields a valid 'vsel' >> instruction. >> >> >> >> On Thu, May 12, 2016 at 2:26 PM, Volker Simonis >> wrote: >>> Hi Gustavo, >>> >>> thanks for the bug report. The hs_err file you provided indicates that >>> this crash happened with Ubuntu's openjdk 8 version. Can you still >>> reproduce this with the the newest jdk9 builds? >>> >>> Also, I can see from the hs_err file that the crash happened in the C2 >>> compiled method java.util.TimSort.countRunAndMakeAscending which >>> doesn't seem to be related to nio and unsafe. >>> >>> Ideally, you could post an easy test case to reproduce the problem. If >>> that's not possible, it would be helpful if you could post the output >>> of a failing run with >>> "-XX:CompileCommand=print,java.util.TimSort::countRunAndMakeAscending >>> -XX:CompileCommand=option,java.util.TimSort::countRunAndMakeAscending,PrintOptoAssembly". >>> In order to get the disassembly output for compiled methods you have >>> to build the hsdis library from hotspot/src/share/tools/hsdis (it has >>> a README with build instructions). >>> >>> Regards, >>> Volker >>> >>> >>> On Thu, May 12, 2016 at 12:32 AM, Gustavo Romero >>> wrote: >>>> Hi >>>> >>>> I'm getting a nasty SIGILL that crashes the JVM on PPC64 LE. >>>> >>>> hs_err log: >>>> http://hastebin.com/raw/fovagunaci >>>> >>>> The application employs methods from both java.nio.ByteBuffer and >>>> sun.misc.Unsafe classes in order to write and read from an allocated buffer. >>>> >>>> A interesting thing is that after debugging the instruction that caused the >>>> said SIGILL: >>>> >>>> 0x3fff902839a4: cmpwi cr6,r17,0 >>>> 0x3fff902839a8: beq cr6,0x3fff90283ae4 >>>> 0x3fff902839ac: .long 0xea2f0013 <============ illegal instruction >>>> 0x3fff902839b0: add r15,r15,r17 >>>> 0x3fff902839b4: add r14,r17,r14 >>>> >>>> I found that when its endianness is changed it turns out to be a valid >>>> instruction: vsel v24,v0,v5,v31 >>>> >>>> However, I'm still unable to determine if it's an application issue, something >>>> with JVM unsafe interface code, or something else. >>>> >>>> Any clue on how to narrow down this SIGILL? >>>> >>>> Thank you! >>>> >>>> Regards, >>>> Gustavo >>>> >> > From volker.simonis at gmail.com Wed Jun 1 06:42:36 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 1 Jun 2016 08:42:36 +0200 Subject: SIGILL crashes JVM on PPC64 LE In-Reply-To: <1733568059.1110524.1464750018575.JavaMail.zimbra@redhat.com> References: <5733B30D.6010201@linux.vnet.ibm.com> <201605310131.u4V1T6HM033728@mx0a-001b2d01.pphosted.com> <1733568059.1110524.1464750018575.JavaMail.zimbra@redhat.com> Message-ID: Hi Andrew, thanks for creating the bug, but I already created a bug for this issue yesterday and posted a mail about it. Unfortunately I've just realized that it was still pending in my outbox. I've therefor closed https://bugs.openjdk.java.net/browse/JDK-8158318 as duplicate of https://bugs.openjdk.java.net/browse/JDK-8158260 Regards, Volker On Wed, Jun 1, 2016 at 5:00 AM, Andrew Hughes wrote: > ----- Original Message ----- >> Hi Volker >> >> The following test case has been isolated by Hiroshi Horii and generates >> the illegal instruction, crashing the JVM on PPC64 LE: >> >> UnalignedUnsafeAccess.java: >> http://hastebin.com/raw/uqegukific >> >> $ javac UnalignedUnsafeAccess.java >> $ java -Xcomp -Xbatch UnalignedUnsafeAccess >> >> The issue can be reproduced on OpenJDK 8 downstream, OpenJDK 8, and >> OpenJDK 9 - hs_err logs: >> >> OpenJDK 9, tag 0be6f4f5d186 jdk-9+120: >> http://hastebin.com/raw/ecuhukutur >> >> OpenJDK 8, tag 5aaa43d91c73 tip: >> http://hastebin.com/raw/ipohoyafos >> >> OpenJDK 8 downstream: >> >> Ubuntu 16.04 LTS >> build 1.8.0_91-8u91-b14-0ubuntu4~16.04.1-b14 >> http://hastebin.com/raw/yetizebofo >> >> RHEL 7.2: >> build 1.8.0_91-b14 >> http://hastebin.com/raw/irequfawaw >> >> The crash happens when an illegal instruction - 0xea2f0013 - is executed. >> >> The backtrace shows: >> >> Stack: [0x00003fff56030000,0x00003fff56430000], sp=0x00003fff5642b8d0, free >> space=4078k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> V [libjvm.so+0x162104] loadI2LNode::emit(CodeBuffer&, PhaseRegAlloc*) >> const+0x194 >> V [libjvm.so+0x8ece28] Compile::fill_buffer(CodeBuffer*, unsigned >> int*)+0x4e8 >> V [libjvm.so+0x368e08] Compile::Code_Gen()+0x3c8 >> V [libjvm.so+0x369e04] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, >> int, bool, bool, bool)+0xf64 >> V [libjvm.so+0x271380] C2Compiler::compile_method(ciEnv*, ciMethod*, >> int)+0x1f0 >> V [libjvm.so+0x3785a4] >> CompileBroker::invoke_compiler_on_method(CompileTask*)+0xd54 >> V [libjvm.so+0x379dc8] CompileBroker::compiler_thread_loop()+0x488 >> V [libjvm.so+0xa5de90] compiler_thread_entry(JavaThread*, Thread*)+0x20 >> V [libjvm.so+0xa690c8] JavaThread::thread_main_inner()+0x178 >> V [libjvm.so+0x8c8c10] java_start(Thread*)+0x170 >> C [libpthread.so.0+0x833c] start_thread+0xfc >> C [libc.so.6+0x12b014] clone+0xe4 >> >> loadI2LNode class is generated according to the following ADL code in >> ppc.ad file: >> >> instruct loadI2L(iRegLdst dst, memory mem) %{ >> match(Set dst (ConvI2L (LoadI mem))); >> predicate(_kids[0]->_leaf->as_Load()->is_unordered()); >> ins_cost(MEMORY_REF_COST); >> >> format %{ "LWA $dst, $mem \t// loadI2L" %} >> size(4); >> ins_encode %{ >> // TODO: PPC port $archOpcode(ppc64Opcode_lwa); >> int Idisp = $mem$$disp + frame_slots_bias($mem$$base, ra_); >> __ lwa($dst$$Register, Idisp, $mem$$base$$Register); >> %} >> ins_pipe(pipe_class_memory); >> %} >> >> So the generated illegal instruction comes from: >> lwa 17,17,15 (DS-form: lwa RT, DS, RA) >> >> As DS field must always be 4-byte aligned (i.e. DS field is always >> concatenated with 0b00), 17 as DS (middle 17 value) is illegal, >> generating the illegal instruction in question: >> >> 11101010000000000000000000000010: LWA >> 00000010001000000000000000000000: 17 >> 00000000000000000000000000010001: 17 >> 00000000000011110000000000000000: 15 >> -------------------------------- >> 11101010001011110000000000010011: 0xEA2F0013 => Illegal instruction >> >> The following change is proposed to fix the issue and deals with the >> unaligned displacements: >> >> OpenJDK 9 webrev: >> 81.de.7a9f.ip4.static.sl-reverse.com./illegal/9 >> >> OpenJDK 8 webrev: >> 81.de.7a9f.ip4.static.sl-reverse.com./illegal/8 >> >> Could we open a JIRA ticket regarding this issue in order to include it >> in the webrev? >> > > Done: > > https://bugs.openjdk.java.net/browse/JDK-8158318 > > Reproduced on IcedTea 2.6.6 & OpenJDK 8u92: > > # JRE version: OpenJDK Runtime Environment (7.0_101) (build 1.7.0_101-mockbuild_2016_04_19_09_08-b00) > # Java VM: OpenJDK 64-Bit Server VM (24.95-b01 compiled mode linux-ppc64 compressed oops) > # Derivative: IcedTea 2.6.6pre01 > # Distribution: Red Hat Enterprise Linux Server release 7.2 (Maipo), package rhel-2.6.6.2.el7-ppc64le u101-b00 > # Problematic frame: > # J 602 C2 UnalignedUnsafeAccess$NativeCell.path()Ljava/lang/String; (106 bytes) @ 0x00003fff88184430 [0x00003fff88184400+0x30] > > # JRE version: OpenJDK Runtime Environment (8.0_92-b14) (build 1.8.0_92-b14) > # Java VM: OpenJDK 64-Bit Server VM (25.92-b14 compiled mode linux-ppc64 compressed oops) > # Problematic frame: > # J 485 C2 UnalignedUnsafeAccess$NativeCell.path()Ljava/lang/String; (106 bytes) @ 0x00003fff8015f030 [0x00003fff8015f000+0x30] > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > From HORII at jp.ibm.com Wed Jun 1 08:51:21 2016 From: HORII at jp.ibm.com (Hiroshi H Horii) Date: Wed, 1 Jun 2016 17:51:21 +0900 Subject: SIGILL crashes JVM on PPC64 LE In-Reply-To: References: <5733B30D.6010201@linux.vnet.ibm.com><201605310131.u4V1TL5g037744@mx0a-001b2d01.pphosted.com> Message-ID: <201606010852.u518mRmO030935@mx0a-001b2d01.pphosted.com> Hi Volker, Thank you for your reviewing our fix. To avoid a generation of illegal instructions when ldisp is not 4-alignment, I changed ppc.ad to generate always two instructions for each ld and lwa as follows. I mean, when ldisp is 4-alignment, nop() is generated redundantly. // Operand 'ds' requires 4-alignment. if (Idisp & 0x3) { __ addi($dst$$Register, $mem$$base$$Register, Idisp); __ ld($dst$$Register, 0, $dst$$Register); } else { __ ld($dst$$Register, Idisp, $mem$$base$$Register); __ nop(); } I'm not sure this fix is elegant or not. In my understanding, an argument of size(n) in ADL must be constant. Correct? If the number can be dynamic, we can avoid generating nop()... Also, we may be able to fix this bug in more higher level (such as IR generation). Regards, Hiroshi ----------------------- Hiroshi Horii, Ph.D. IBM Research - Tokyo Volker Simonis wrote on 06/01/2016 15:37:21: > From: Volker Simonis > To: Gustavo Romero > Cc: "ppc-aix-port-dev at openjdk.java.net" dev at openjdk.java.net>, "hotspot-dev at openjdk.java.net" dev at openjdk.java.net>, Breno Leitao , Hiroshi H > Horii/Japan/IBM at IBMJP > Date: 06/01/2016 15:38 > Subject: Re: SIGILL crashes JVM on PPC64 LE > > Hi Gustavo, Hiroshi, > > thanks a lot for the great analysis and the nice stand-alone test > case. This is indeed a problem, and it also occurs on ppc64 > big-endian. > > I've opened "8158260: PPC64: unaligned Unsafe.getInt can lead to the > generation of illegal instructions" > (https://bugs.openjdk.java.net/browse/JDK-8158260) for this issue. > > I'm currently looking at your proposed fix and will come back with a > new webrev soon. > > Thanks a lot and best regards, > Volker > > > On Tue, May 31, 2016 at 3:31 AM, Gustavo Romero > wrote: > > Hi Volker > > > > The following test case has been isolated by Hiroshi Horii and generates > > the illegal instruction, crashing the JVM on PPC64 LE: > > > > UnalignedUnsafeAccess.java: > > http://hastebin.com/raw/uqegukific > > > > $ javac UnalignedUnsafeAccess.java > > $ java -Xcomp -Xbatch UnalignedUnsafeAccess > > > > The issue can be reproduced on OpenJDK 8 downstream, OpenJDK 8, and > > OpenJDK 9 - hs_err logs: > > > > OpenJDK 9, tag 0be6f4f5d186 jdk-9+120: > > http://hastebin.com/raw/ecuhukutur > > > > OpenJDK 8, tag 5aaa43d91c73 tip: > > http://hastebin.com/raw/ipohoyafos > > > > OpenJDK 8 downstream: > > > > Ubuntu 16.04 LTS > > build 1.8.0_91-8u91-b14-0ubuntu4~16.04.1-b14 > > http://hastebin.com/raw/yetizebofo > > > > RHEL 7.2: > > build 1.8.0_91-b14 > > http://hastebin.com/raw/irequfawaw > > > > The crash happens when an illegal instruction - 0xea2f0013 - is executed. > > > > The backtrace shows: > > > > Stack: [0x00003fff56030000,0x00003fff56430000], > sp=0x00003fff5642b8d0, free space=4078k > > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > > V [libjvm.so+0x162104] loadI2LNode::emit(CodeBuffer&, > PhaseRegAlloc*) const+0x194 > > V [libjvm.so+0x8ece28] Compile::fill_buffer(CodeBuffer*, > unsigned int*)+0x4e8 > > V [libjvm.so+0x368e08] Compile::Code_Gen()+0x3c8 > > V [libjvm.so+0x369e04] Compile::Compile(ciEnv*, C2Compiler*, > ciMethod*, int, bool, bool, bool)+0xf64 > > V [libjvm.so+0x271380] C2Compiler::compile_method(ciEnv*, > ciMethod*, int)+0x1f0 > > V [libjvm.so+0x3785a4] CompileBroker::invoke_compiler_on_method > (CompileTask*)+0xd54 > > V [libjvm.so+0x379dc8] CompileBroker::compiler_thread_loop()+0x488 > > V [libjvm.so+0xa5de90] compiler_thread_entry(JavaThread*, Thread*)+0x20 > > V [libjvm.so+0xa690c8] JavaThread::thread_main_inner()+0x178 > > V [libjvm.so+0x8c8c10] java_start(Thread*)+0x170 > > C [libpthread.so.0+0x833c] start_thread+0xfc > > C [libc.so.6+0x12b014] clone+0xe4 > > > > loadI2LNode class is generated according to the following ADL code in > > ppc.ad file: > > > > instruct loadI2L(iRegLdst dst, memory mem) %{ > > match(Set dst (ConvI2L (LoadI mem))); > > predicate(_kids[0]->_leaf->as_Load()->is_unordered()); > > ins_cost(MEMORY_REF_COST); > > > > format %{ "LWA $dst, $mem \t// loadI2L" %} > > size(4); > > ins_encode %{ > > // TODO: PPC port $archOpcode(ppc64Opcode_lwa); > > int Idisp = $mem$$disp + frame_slots_bias($mem$$base, ra_); > > __ lwa($dst$$Register, Idisp, $mem$$base$$Register); > > %} > > ins_pipe(pipe_class_memory); > > %} > > > > So the generated illegal instruction comes from: > > lwa 17,17,15 (DS-form: lwa RT, DS, RA) > > > > As DS field must always be 4-byte aligned (i.e. DS field is always > > concatenated with 0b00), 17 as DS (middle 17 value) is illegal, > > generating the illegal instruction in question: > > > > 11101010000000000000000000000010: LWA > > 00000010001000000000000000000000: 17 > > 00000000000000000000000000010001: 17 > > 00000000000011110000000000000000: 15 > > -------------------------------- > > 11101010001011110000000000010011: 0xEA2F0013 => Illegal instruction > > > > The following change is proposed to fix the issue and deals with the > > unaligned displacements: > > > > OpenJDK 9 webrev: > > 81.de.7a9f.ip4.static.sl-reverse.com./illegal/9 > > > > OpenJDK 8 webrev: > > 81.de.7a9f.ip4.static.sl-reverse.com./illegal/8 > > > > Could we open a JIRA ticket regarding this issue in order to include it > > in the webrev? > > > > Thank you! > > > > Best regards, > > Gustavo > > > > On 12-05-2016 09:39, Volker Simonis wrote: > >> And I forgot to mention: I've checked and we don't emit vsel > >> instructions in jdk8 on ppc. So it must be a coincidence that changing > >> the endianess of the offending instruction yields a valid 'vsel' > >> instruction. > >> > >> > >> > >> On Thu, May 12, 2016 at 2:26 PM, Volker Simonis > >> wrote: > >>> Hi Gustavo, > >>> > >>> thanks for the bug report. The hs_err file you provided indicates that > >>> this crash happened with Ubuntu's openjdk 8 version. Can you still > >>> reproduce this with the the newest jdk9 builds? > >>> > >>> Also, I can see from the hs_err file that the crash happened in the C2 > >>> compiled method java.util.TimSort.countRunAndMakeAscending which > >>> doesn't seem to be related to nio and unsafe. > >>> > >>> Ideally, you could post an easy test case to reproduce the problem. If > >>> that's not possible, it would be helpful if you could post the output > >>> of a failing run with > >>> "-XX:CompileCommand=print,java.util.TimSort::countRunAndMakeAscending > >>> - > XX:CompileCommand=option,java.util.TimSort::countRunAndMakeAscending,PrintOptoAssembly". > >>> In order to get the disassembly output for compiled methods you have > >>> to build the hsdis library from hotspot/src/share/tools/hsdis (it has > >>> a README with build instructions). > >>> > >>> Regards, > >>> Volker > >>> > >>> > >>> On Thu, May 12, 2016 at 12:32 AM, Gustavo Romero > >>> wrote: > >>>> Hi > >>>> > >>>> I'm getting a nasty SIGILL that crashes the JVM on PPC64 LE. > >>>> > >>>> hs_err log: > >>>> http://hastebin.com/raw/fovagunaci > >>>> > >>>> The application employs methods from both java.nio.ByteBuffer and > >>>> sun.misc.Unsafe classes in order to write and read from an > allocated buffer. > >>>> > >>>> A interesting thing is that after debugging the instruction > that caused the > >>>> said SIGILL: > >>>> > >>>> 0x3fff902839a4: cmpwi cr6,r17,0 > >>>> 0x3fff902839a8: beq cr6,0x3fff90283ae4 > >>>> 0x3fff902839ac: .long 0xea2f0013 <============ illegal > instruction > >>>> 0x3fff902839b0: add r15,r15,r17 > >>>> 0x3fff902839b4: add r14,r17,r14 > >>>> > >>>> I found that when its endianness is changed it turns out to be a valid > >>>> instruction: vsel v24,v0,v5,v31 > >>>> > >>>> However, I'm still unable to determine if it's an application > issue, something > >>>> with JVM unsafe interface code, or something else. > >>>> > >>>> Any clue on how to narrow down this SIGILL? > >>>> > >>>> Thank you! > >>>> > >>>> Regards, > >>>> Gustavo > >>>> > >> > > > From goetz.lindenmaier at sap.com Wed Jun 1 14:13:34 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 1 Jun 2016 14:13:34 +0000 Subject: RFR(M): 8158232: PPC64: improve byte, int and long array copy stubs by using VSX instructions In-Reply-To: <201605311537.u4VFYV1Q029540@mx0a-001b2d01.pphosted.com> References: <201605311537.u4VFYV1Q029540@mx0a-001b2d01.pphosted.com> Message-ID: <4ef29ef8b7904b98952224ecb77e21f8@DEWDFE13DE09.global.corp.sap> Hi Michihiro, Thanks for contributing to the ppc port! I've been looking at your changes. Basically they look good. But I'm not convinced that this helps the average performance, as important lengths will regress. We once ananlyzed a benchmark, where we saw 400 million copies of short arrays which had an average length of 38!! elements. There were 200 byte array copies and 20 million long array copies. This should have changed as there are compact strings, now. I think we had suppressed the array copy stubs and modified PrintOptoStatistics to collect that data. As I understand we have the following loops now: Loop body sizes in elements before now sizes regressing byte 32,4,1 128,4,1 32-127 short 16,2,1 16,2,1 none int 8,1 32,1 8-31 long 4,1 16,4,1 none Especially with the byte arrays, which are used to store compact Strings, I would doubt that this helps an average application. For sizes 32-128 you first have a failing compare, and then step through a '4' loop instead of a '32' one. Further, why don't you use the new instructions in the smaller loops, too? Like in the long '4' version? I could not find a measurement showing the effect on jbb2015 or jvm2008. Did you measure these? Or you could modify your benchmarks for some small, odd numbers, as 23, 42, 99 ...? Should you also set the prefetching engine more aggressive as in the short copy loop? Best regards, Goetz. > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Michihiro Horie > Sent: Dienstag, 31. Mai 2016 17:37 > To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: RFR(M): 8158232: PPC64: improve byte, int and long array copy stubs > by using VSX instructions > > > Dear all, > > Could you please review the following webrev? > > http://cr.openjdk.java.net/~mdoerr/8158232_PPC_vsx_copy/webrev.00/ > > This change improves performance of disjoint arraycopy of byte, int, and > long by using VSX load/store instructions. > > Discussion started from: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016- > May/002483.html > > Performance improvement with micro benchmarks is shown in: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016- > May/002531.html > > Thank you very much, > > Best regards, > -- > Michihiro Horie, > IBM Research - Tokyo From aph at redhat.com Wed Jun 1 14:18:35 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 1 Jun 2016 15:18:35 +0100 Subject: RFR: 8158361: AArch64: Address calculation missed optimizations Message-ID: <574EEEBB.2080303@redhat.com> In calculations involving Unsafe addressing we're missing opportunities to combine instructions. We're seeing, for example: sbfiz x13, x13, #3, #32 add x15, x13, x10 instead of add x15, x10, w13, sxtw #3 This is due to a couple of missing patterns. http://cr.openjdk.java.net/~aph/8158361/ Andrew. From rwestrel at redhat.com Wed Jun 1 14:36:04 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 1 Jun 2016 16:36:04 +0200 Subject: RFR: 8158361: AArch64: Address calculation missed optimizations In-Reply-To: <574EEEBB.2080303@redhat.com> References: <574EEEBB.2080303@redhat.com> Message-ID: <574EF2D4.4080606@redhat.com> > http://cr.openjdk.java.net/~aph/8158361/ That looks good to me. Roland. From paul.sandoz at oracle.com Wed Jun 1 15:24:14 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 1 Jun 2016 17:24:14 +0200 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics Message-ID: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> (Please note this work is or will be covered with FC exception) Hi, Please review the VarHandles/Unsafe support for atomic ops on double/float fields/arrays. http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ These patches are based on those of for sub-word CAS https://bugs.openjdk.java.net/browse/JDK-8157726 http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/ http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/ And the two patches combined expand the support of fields/arrays. New float/double CAS methods are added to Unsafe that defer to int/long equivalents. Then the other atomic methods are built from weak CAS loops. No changes are required to HotSpot, but changes are required to the Unsafe tests in the hotspot repository. In general the changes to VHs and tests are minimal since it is triggered from changes to the generating scripts that now include float/double into the CAS category. There are some minor specification changes and a CCC has been initiated. JPRT tests results show no relevant failures for hotspot and core test sets. Thanks, Paul. From volker.simonis at gmail.com Wed Jun 1 17:06:31 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 1 Jun 2016 19:06:31 +0200 Subject: SIGILL crashes JVM on PPC64 LE In-Reply-To: <201606010852.u518mWRl027027@mx0a-001b2d01.pphosted.com> References: <5733B30D.6010201@linux.vnet.ibm.com> <201605310131.u4V1TL5g037744@mx0a-001b2d01.pphosted.com> <201606010852.u518mWRl027027@mx0a-001b2d01.pphosted.com> Message-ID: Hi Hiroshi, Gustavo, I'm currently trying to better understand the cause of the crash. When looking at the Cassandra sources [1] I can see that on ppc we should actually not call Unsafe.getInt() at all: UNALIGNED = arch.equals("i386") || arch.equals("x86") || arch.equals("amd64") || arch.equals("x86_64") || arch.equals("s390x"); public static int getInt(long address) { return UNALIGNED ? unsafe.getInt(address) : getIntByByte(address); } Is this behavior different in the version of Cassandra which you have used for your tests? I just want to make sure that the problem we reproduce with your stand-alone test case is the same like the one we are seeing in the initial Cassandra crash. Could you please provide the exact versions of Cassandra you have used and a description of the tests and the way you have executed them when you saw the initial error? Thanks a lot for your help, Volker [1] https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java On Wed, Jun 1, 2016 at 10:51 AM, Hiroshi H Horii wrote: > Hi Volker, > > Thank you for your reviewing our fix. > > To avoid a generation of illegal instructions when ldisp is not 4-alignment, > I changed ppc.ad to generate always two instructions for each ld and lwa as > follows. > I mean, when ldisp is 4-alignment, nop() is generated redundantly. > > // Operand 'ds' requires 4-alignment. > if (Idisp & 0x3) { > __ addi($dst$$Register, $mem$$base$$Register, Idisp); > __ ld($dst$$Register, 0, $dst$$Register); > } else { > __ ld($dst$$Register, Idisp, $mem$$base$$Register); > __ nop(); > } > > I'm not sure this fix is elegant or not. > > In my understanding, an argument of size(n) in ADL must be constant. > Correct? > If the number can be dynamic, we can avoid generating nop()... > Also, we may be able to fix this bug in more higher level (such as IR > generation). > > Regards, > Hiroshi > ----------------------- > Hiroshi Horii, Ph.D. > IBM Research - Tokyo > > > Volker Simonis wrote on 06/01/2016 15:37:21: > >> From: Volker Simonis >> To: Gustavo Romero >> Cc: "ppc-aix-port-dev at openjdk.java.net" > dev at openjdk.java.net>, "hotspot-dev at openjdk.java.net" > dev at openjdk.java.net>, Breno Leitao , Hiroshi H >> Horii/Japan/IBM at IBMJP >> Date: 06/01/2016 15:38 >> Subject: Re: SIGILL crashes JVM on PPC64 LE > >> >> Hi Gustavo, Hiroshi, >> >> thanks a lot for the great analysis and the nice stand-alone test >> case. This is indeed a problem, and it also occurs on ppc64 >> big-endian. >> >> I've opened "8158260: PPC64: unaligned Unsafe.getInt can lead to the >> generation of illegal instructions" >> (https://bugs.openjdk.java.net/browse/JDK-8158260) for this issue. >> >> I'm currently looking at your proposed fix and will come back with a >> new webrev soon. >> >> Thanks a lot and best regards, >> Volker >> >> >> On Tue, May 31, 2016 at 3:31 AM, Gustavo Romero >> wrote: >> > Hi Volker >> > >> > The following test case has been isolated by Hiroshi Horii and generates >> > the illegal instruction, crashing the JVM on PPC64 LE: >> > >> > UnalignedUnsafeAccess.java: >> > http://hastebin.com/raw/uqegukific >> > >> > $ javac UnalignedUnsafeAccess.java >> > $ java -Xcomp -Xbatch UnalignedUnsafeAccess >> > >> > The issue can be reproduced on OpenJDK 8 downstream, OpenJDK 8, and >> > OpenJDK 9 - hs_err logs: >> > >> > OpenJDK 9, tag 0be6f4f5d186 jdk-9+120: >> > http://hastebin.com/raw/ecuhukutur >> > >> > OpenJDK 8, tag 5aaa43d91c73 tip: >> > http://hastebin.com/raw/ipohoyafos >> > >> > OpenJDK 8 downstream: >> > >> > Ubuntu 16.04 LTS >> > build 1.8.0_91-8u91-b14-0ubuntu4~16.04.1-b14 >> > http://hastebin.com/raw/yetizebofo >> > >> > RHEL 7.2: >> > build 1.8.0_91-b14 >> > http://hastebin.com/raw/irequfawaw >> > >> > The crash happens when an illegal instruction - 0xea2f0013 - is >> > executed. >> > >> > The backtrace shows: >> > >> > Stack: [0x00003fff56030000,0x00003fff56430000], >> sp=0x00003fff5642b8d0, free space=4078k >> > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >> C=native code) >> > V [libjvm.so+0x162104] loadI2LNode::emit(CodeBuffer&, >> PhaseRegAlloc*) const+0x194 >> > V [libjvm.so+0x8ece28] Compile::fill_buffer(CodeBuffer*, >> unsigned int*)+0x4e8 >> > V [libjvm.so+0x368e08] Compile::Code_Gen()+0x3c8 >> > V [libjvm.so+0x369e04] Compile::Compile(ciEnv*, C2Compiler*, >> ciMethod*, int, bool, bool, bool)+0xf64 >> > V [libjvm.so+0x271380] C2Compiler::compile_method(ciEnv*, >> ciMethod*, int)+0x1f0 >> > V [libjvm.so+0x3785a4] CompileBroker::invoke_compiler_on_method >> (CompileTask*)+0xd54 >> > V [libjvm.so+0x379dc8] CompileBroker::compiler_thread_loop()+0x488 >> > V [libjvm.so+0xa5de90] compiler_thread_entry(JavaThread*, >> > Thread*)+0x20 >> > V [libjvm.so+0xa690c8] JavaThread::thread_main_inner()+0x178 >> > V [libjvm.so+0x8c8c10] java_start(Thread*)+0x170 >> > C [libpthread.so.0+0x833c] start_thread+0xfc >> > C [libc.so.6+0x12b014] clone+0xe4 >> > >> > loadI2LNode class is generated according to the following ADL code in >> > ppc.ad file: >> > >> > instruct loadI2L(iRegLdst dst, memory mem) %{ >> > match(Set dst (ConvI2L (LoadI mem))); >> > predicate(_kids[0]->_leaf->as_Load()->is_unordered()); >> > ins_cost(MEMORY_REF_COST); >> > >> > format %{ "LWA $dst, $mem \t// loadI2L" %} >> > size(4); >> > ins_encode %{ >> > // TODO: PPC port $archOpcode(ppc64Opcode_lwa); >> > int Idisp = $mem$$disp + frame_slots_bias($mem$$base, ra_); >> > __ lwa($dst$$Register, Idisp, $mem$$base$$Register); >> > %} >> > ins_pipe(pipe_class_memory); >> > %} >> > >> > So the generated illegal instruction comes from: >> > lwa 17,17,15 (DS-form: lwa RT, DS, RA) >> > >> > As DS field must always be 4-byte aligned (i.e. DS field is always >> > concatenated with 0b00), 17 as DS (middle 17 value) is illegal, >> > generating the illegal instruction in question: >> > >> > 11101010000000000000000000000010: LWA >> > 00000010001000000000000000000000: 17 >> > 00000000000000000000000000010001: 17 >> > 00000000000011110000000000000000: 15 >> > -------------------------------- >> > 11101010001011110000000000010011: 0xEA2F0013 => Illegal instruction >> > >> > The following change is proposed to fix the issue and deals with the >> > unaligned displacements: >> > >> > OpenJDK 9 webrev: >> > 81.de.7a9f.ip4.static.sl-reverse.com./illegal/9 >> > >> > OpenJDK 8 webrev: >> > 81.de.7a9f.ip4.static.sl-reverse.com./illegal/8 >> > >> > Could we open a JIRA ticket regarding this issue in order to include it >> > in the webrev? >> > >> > Thank you! >> > >> > Best regards, >> > Gustavo >> > >> > On 12-05-2016 09:39, Volker Simonis wrote: >> >> And I forgot to mention: I've checked and we don't emit vsel >> >> instructions in jdk8 on ppc. So it must be a coincidence that changing >> >> the endianess of the offending instruction yields a valid 'vsel' >> >> instruction. >> >> >> >> >> >> >> >> On Thu, May 12, 2016 at 2:26 PM, Volker Simonis >> >> wrote: >> >>> Hi Gustavo, >> >>> >> >>> thanks for the bug report. The hs_err file you provided indicates that >> >>> this crash happened with Ubuntu's openjdk 8 version. Can you still >> >>> reproduce this with the the newest jdk9 builds? >> >>> >> >>> Also, I can see from the hs_err file that the crash happened in the C2 >> >>> compiled method java.util.TimSort.countRunAndMakeAscending which >> >>> doesn't seem to be related to nio and unsafe. >> >>> >> >>> Ideally, you could post an easy test case to reproduce the problem. If >> >>> that's not possible, it would be helpful if you could post the output >> >>> of a failing run with >> >>> "-XX:CompileCommand=print,java.util.TimSort::countRunAndMakeAscending >> >>> - >> >> XX:CompileCommand=option,java.util.TimSort::countRunAndMakeAscending,PrintOptoAssembly". >> >>> In order to get the disassembly output for compiled methods you have >> >>> to build the hsdis library from hotspot/src/share/tools/hsdis (it has >> >>> a README with build instructions). >> >>> >> >>> Regards, >> >>> Volker >> >>> >> >>> >> >>> On Thu, May 12, 2016 at 12:32 AM, Gustavo Romero >> >>> wrote: >> >>>> Hi >> >>>> >> >>>> I'm getting a nasty SIGILL that crashes the JVM on PPC64 LE. >> >>>> >> >>>> hs_err log: >> >>>> http://hastebin.com/raw/fovagunaci >> >>>> >> >>>> The application employs methods from both java.nio.ByteBuffer and >> >>>> sun.misc.Unsafe classes in order to write and read from an >> allocated buffer. >> >>>> >> >>>> A interesting thing is that after debugging the instruction >> that caused the >> >>>> said SIGILL: >> >>>> >> >>>> 0x3fff902839a4: cmpwi cr6,r17,0 >> >>>> 0x3fff902839a8: beq cr6,0x3fff90283ae4 >> >>>> 0x3fff902839ac: .long 0xea2f0013 <============ illegal >> instruction >> >>>> 0x3fff902839b0: add r15,r15,r17 >> >>>> 0x3fff902839b4: add r14,r17,r14 >> >>>> >> >>>> I found that when its endianness is changed it turns out to be a >> >>>> valid >> >>>> instruction: vsel v24,v0,v5,v31 >> >>>> >> >>>> However, I'm still unable to determine if it's an application >> issue, something >> >>>> with JVM unsafe interface code, or something else. >> >>>> >> >>>> Any clue on how to narrow down this SIGILL? >> >>>> >> >>>> Thank you! >> >>>> >> >>>> Regards, >> >>>> Gustavo >> >>>> >> >> >> > >> > From aleksey.shipilev at oracle.com Wed Jun 1 17:55:42 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 1 Jun 2016 20:55:42 +0300 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> Message-ID: <574F219E.40109@oracle.com> On 06/01/2016 06:24 PM, Paul Sandoz wrote: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ These look good. Thanks, -Aleksey From gromero at linux.vnet.ibm.com Wed Jun 1 18:21:55 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 1 Jun 2016 15:21:55 -0300 Subject: SIGILL crashes JVM on PPC64 LE In-Reply-To: References: <5733B30D.6010201@linux.vnet.ibm.com> <201605310131.u4V1TL5g037744@mx0a-001b2d01.pphosted.com> <201606010852.u518mWRl027027@mx0a-001b2d01.pphosted.com> Message-ID: <201606011822.u51IENGF043033@mx0a-001b2d01.pphosted.com> Hi Volker You are right, Cassandra's upstream code does not contain arch.equals("ppc64le"). The following patch http://hastebin.com/raw/zusomadace was applied to this commit: http://cassci.datastax.com/job/trunk_utest/1344 This was the way I first reproduced the issue, maybe Hiroshi is using a more recent commit. As, except for VMX/Altivec instructions whose operands are assumed to be always aligned, PPC64 supports unaligned storage access, and as - I've been told - the patch solved all failing tests on z (which is LE, BTW), the change (adding ppc64le) was tried and the issue emerged. The initial error thus was seen on "ant test" suite. This is an example of failing test due to the illegal instruction (there are others): ant testsome -Dtest.name=org.apache.cassandra.db.NativeCellTest -Dtest.methods=testCells The following problematic snippet that uses MemoryUtil.getInt has been traced: https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/rows/NativeCell.java#L136-L137 This is from where the test case was thought (Hiroshi, please correct me if I'm wrong). Thanks a lot for your help! Gustavo On 01-06-2016 14:06, Volker Simonis wrote: > Hi Hiroshi, Gustavo, > > I'm currently trying to better understand the cause of the crash. > When looking at the Cassandra sources [1] I can see that on ppc we > should actually not call Unsafe.getInt() at all: > > UNALIGNED = arch.equals("i386") || arch.equals("x86") > || arch.equals("amd64") || arch.equals("x86_64") || arch.equals("s390x"); > > public static int getInt(long address) > { > return UNALIGNED ? unsafe.getInt(address) : getIntByByte(address); > } > > Is this behavior different in the version of Cassandra which you have > used for your tests? > > I just want to make sure that the problem we reproduce with your > stand-alone test case is the same like the one we are seeing in the > initial Cassandra crash. > > Could you please provide the exact versions of Cassandra you have used > and a description of the tests and the way you have executed them when > you saw the initial error? > > Thanks a lot for your help, > Volker > > [1] https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java > > On Wed, Jun 1, 2016 at 10:51 AM, Hiroshi H Horii wrote: >> Hi Volker, >> >> Thank you for your reviewing our fix. >> >> To avoid a generation of illegal instructions when ldisp is not 4-alignment, >> I changed ppc.ad to generate always two instructions for each ld and lwa as >> follows. >> I mean, when ldisp is 4-alignment, nop() is generated redundantly. >> >> // Operand 'ds' requires 4-alignment. >> if (Idisp & 0x3) { >> __ addi($dst$$Register, $mem$$base$$Register, Idisp); >> __ ld($dst$$Register, 0, $dst$$Register); >> } else { >> __ ld($dst$$Register, Idisp, $mem$$base$$Register); >> __ nop(); >> } >> >> I'm not sure this fix is elegant or not. >> >> In my understanding, an argument of size(n) in ADL must be constant. >> Correct? >> If the number can be dynamic, we can avoid generating nop()... >> Also, we may be able to fix this bug in more higher level (such as IR >> generation). >> >> Regards, >> Hiroshi >> ----------------------- >> Hiroshi Horii, Ph.D. >> IBM Research - Tokyo >> >> >> Volker Simonis wrote on 06/01/2016 15:37:21: >> >>> From: Volker Simonis >>> To: Gustavo Romero >>> Cc: "ppc-aix-port-dev at openjdk.java.net" >> dev at openjdk.java.net>, "hotspot-dev at openjdk.java.net" >> dev at openjdk.java.net>, Breno Leitao , Hiroshi H >>> Horii/Japan/IBM at IBMJP >>> Date: 06/01/2016 15:38 >>> Subject: Re: SIGILL crashes JVM on PPC64 LE >> >>> >>> Hi Gustavo, Hiroshi, >>> >>> thanks a lot for the great analysis and the nice stand-alone test >>> case. This is indeed a problem, and it also occurs on ppc64 >>> big-endian. >>> >>> I've opened "8158260: PPC64: unaligned Unsafe.getInt can lead to the >>> generation of illegal instructions" >>> (https://bugs.openjdk.java.net/browse/JDK-8158260) for this issue. >>> >>> I'm currently looking at your proposed fix and will come back with a >>> new webrev soon. >>> >>> Thanks a lot and best regards, >>> Volker >>> >>> >>> On Tue, May 31, 2016 at 3:31 AM, Gustavo Romero >>> wrote: >>>> Hi Volker >>>> >>>> The following test case has been isolated by Hiroshi Horii and generates >>>> the illegal instruction, crashing the JVM on PPC64 LE: >>>> >>>> UnalignedUnsafeAccess.java: >>>> http://hastebin.com/raw/uqegukific >>>> >>>> $ javac UnalignedUnsafeAccess.java >>>> $ java -Xcomp -Xbatch UnalignedUnsafeAccess >>>> >>>> The issue can be reproduced on OpenJDK 8 downstream, OpenJDK 8, and >>>> OpenJDK 9 - hs_err logs: >>>> >>>> OpenJDK 9, tag 0be6f4f5d186 jdk-9+120: >>>> http://hastebin.com/raw/ecuhukutur >>>> >>>> OpenJDK 8, tag 5aaa43d91c73 tip: >>>> http://hastebin.com/raw/ipohoyafos >>>> >>>> OpenJDK 8 downstream: >>>> >>>> Ubuntu 16.04 LTS >>>> build 1.8.0_91-8u91-b14-0ubuntu4~16.04.1-b14 >>>> http://hastebin.com/raw/yetizebofo >>>> >>>> RHEL 7.2: >>>> build 1.8.0_91-b14 >>>> http://hastebin.com/raw/irequfawaw >>>> >>>> The crash happens when an illegal instruction - 0xea2f0013 - is >>>> executed. >>>> >>>> The backtrace shows: >>>> >>>> Stack: [0x00003fff56030000,0x00003fff56430000], >>> sp=0x00003fff5642b8d0, free space=4078k >>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>> C=native code) >>>> V [libjvm.so+0x162104] loadI2LNode::emit(CodeBuffer&, >>> PhaseRegAlloc*) const+0x194 >>>> V [libjvm.so+0x8ece28] Compile::fill_buffer(CodeBuffer*, >>> unsigned int*)+0x4e8 >>>> V [libjvm.so+0x368e08] Compile::Code_Gen()+0x3c8 >>>> V [libjvm.so+0x369e04] Compile::Compile(ciEnv*, C2Compiler*, >>> ciMethod*, int, bool, bool, bool)+0xf64 >>>> V [libjvm.so+0x271380] C2Compiler::compile_method(ciEnv*, >>> ciMethod*, int)+0x1f0 >>>> V [libjvm.so+0x3785a4] CompileBroker::invoke_compiler_on_method >>> (CompileTask*)+0xd54 >>>> V [libjvm.so+0x379dc8] CompileBroker::compiler_thread_loop()+0x488 >>>> V [libjvm.so+0xa5de90] compiler_thread_entry(JavaThread*, >>>> Thread*)+0x20 >>>> V [libjvm.so+0xa690c8] JavaThread::thread_main_inner()+0x178 >>>> V [libjvm.so+0x8c8c10] java_start(Thread*)+0x170 >>>> C [libpthread.so.0+0x833c] start_thread+0xfc >>>> C [libc.so.6+0x12b014] clone+0xe4 >>>> >>>> loadI2LNode class is generated according to the following ADL code in >>>> ppc.ad file: >>>> >>>> instruct loadI2L(iRegLdst dst, memory mem) %{ >>>> match(Set dst (ConvI2L (LoadI mem))); >>>> predicate(_kids[0]->_leaf->as_Load()->is_unordered()); >>>> ins_cost(MEMORY_REF_COST); >>>> >>>> format %{ "LWA $dst, $mem \t// loadI2L" %} >>>> size(4); >>>> ins_encode %{ >>>> // TODO: PPC port $archOpcode(ppc64Opcode_lwa); >>>> int Idisp = $mem$$disp + frame_slots_bias($mem$$base, ra_); >>>> __ lwa($dst$$Register, Idisp, $mem$$base$$Register); >>>> %} >>>> ins_pipe(pipe_class_memory); >>>> %} >>>> >>>> So the generated illegal instruction comes from: >>>> lwa 17,17,15 (DS-form: lwa RT, DS, RA) >>>> >>>> As DS field must always be 4-byte aligned (i.e. DS field is always >>>> concatenated with 0b00), 17 as DS (middle 17 value) is illegal, >>>> generating the illegal instruction in question: >>>> >>>> 11101010000000000000000000000010: LWA >>>> 00000010001000000000000000000000: 17 >>>> 00000000000000000000000000010001: 17 >>>> 00000000000011110000000000000000: 15 >>>> -------------------------------- >>>> 11101010001011110000000000010011: 0xEA2F0013 => Illegal instruction >>>> >>>> The following change is proposed to fix the issue and deals with the >>>> unaligned displacements: >>>> >>>> OpenJDK 9 webrev: >>>> 81.de.7a9f.ip4.static.sl-reverse.com./illegal/9 >>>> >>>> OpenJDK 8 webrev: >>>> 81.de.7a9f.ip4.static.sl-reverse.com./illegal/8 >>>> >>>> Could we open a JIRA ticket regarding this issue in order to include it >>>> in the webrev? >>>> >>>> Thank you! >>>> >>>> Best regards, >>>> Gustavo >>>> >>>> On 12-05-2016 09:39, Volker Simonis wrote: >>>>> And I forgot to mention: I've checked and we don't emit vsel >>>>> instructions in jdk8 on ppc. So it must be a coincidence that changing >>>>> the endianess of the offending instruction yields a valid 'vsel' >>>>> instruction. >>>>> >>>>> >>>>> >>>>> On Thu, May 12, 2016 at 2:26 PM, Volker Simonis >>>>> wrote: >>>>>> Hi Gustavo, >>>>>> >>>>>> thanks for the bug report. The hs_err file you provided indicates that >>>>>> this crash happened with Ubuntu's openjdk 8 version. Can you still >>>>>> reproduce this with the the newest jdk9 builds? >>>>>> >>>>>> Also, I can see from the hs_err file that the crash happened in the C2 >>>>>> compiled method java.util.TimSort.countRunAndMakeAscending which >>>>>> doesn't seem to be related to nio and unsafe. >>>>>> >>>>>> Ideally, you could post an easy test case to reproduce the problem. If >>>>>> that's not possible, it would be helpful if you could post the output >>>>>> of a failing run with >>>>>> "-XX:CompileCommand=print,java.util.TimSort::countRunAndMakeAscending >>>>>> - >>> >>> XX:CompileCommand=option,java.util.TimSort::countRunAndMakeAscending,PrintOptoAssembly". >>>>>> In order to get the disassembly output for compiled methods you have >>>>>> to build the hsdis library from hotspot/src/share/tools/hsdis (it has >>>>>> a README with build instructions). >>>>>> >>>>>> Regards, >>>>>> Volker >>>>>> >>>>>> >>>>>> On Thu, May 12, 2016 at 12:32 AM, Gustavo Romero >>>>>> wrote: >>>>>>> Hi >>>>>>> >>>>>>> I'm getting a nasty SIGILL that crashes the JVM on PPC64 LE. >>>>>>> >>>>>>> hs_err log: >>>>>>> http://hastebin.com/raw/fovagunaci >>>>>>> >>>>>>> The application employs methods from both java.nio.ByteBuffer and >>>>>>> sun.misc.Unsafe classes in order to write and read from an >>> allocated buffer. >>>>>>> >>>>>>> A interesting thing is that after debugging the instruction >>> that caused the >>>>>>> said SIGILL: >>>>>>> >>>>>>> 0x3fff902839a4: cmpwi cr6,r17,0 >>>>>>> 0x3fff902839a8: beq cr6,0x3fff90283ae4 >>>>>>> 0x3fff902839ac: .long 0xea2f0013 <============ illegal >>> instruction >>>>>>> 0x3fff902839b0: add r15,r15,r17 >>>>>>> 0x3fff902839b4: add r14,r17,r14 >>>>>>> >>>>>>> I found that when its endianness is changed it turns out to be a >>>>>>> valid >>>>>>> instruction: vsel v24,v0,v5,v31 >>>>>>> >>>>>>> However, I'm still unable to determine if it's an application >>> issue, something >>>>>>> with JVM unsafe interface code, or something else. >>>>>>> >>>>>>> Any clue on how to narrow down this SIGILL? >>>>>>> >>>>>>> Thank you! >>>>>>> >>>>>>> Regards, >>>>>>> Gustavo >>>>>>> >>>>> >>>> >>> >> > From daniel.smith at oracle.com Wed Jun 1 21:58:34 2016 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 1 Jun 2016 15:58:34 -0600 Subject: General Registration -- 2016 JVM Language Summit Message-ID: GENERAL REGISTRATION -- JVM LANGUAGE SUMMIT, AUGUST 2016 General registration for the 2016 JVM Language Summit is now open. The event will be held at Oracle's Santa Clara campus on August 1-3, 2016. We've also decided to extend speaker registration, keeping it open for one more week, until June 8. If you or someone you know is interested in presenting, take advantage and submit an abstract ASAP! See http://jvmlangsummit.com for detailed speaker instructions. The JVM Language Summit is an open technical collaboration among language designers, compiler writers, tool builders, runtime engineers, and VM architects. We will share our experiences as creators of both the JVM and programming languages for the JVM. We also welcome non-JVM developers of similar technologies to attend or speak on their runtime, VM, or language of choice. Presentations will be recorded and made available to the public. This event is being organized by language and JVM engineers?no marketers involved! So bring your slide rules and be prepared for some seriously geeky discussions. Format The summit is held in a single classroom-style room to support direct communication between participants. About 100-120 attendees are expected. The schedule consists of a single track of traditional presentations (about 7 each day) interspersed with less-formal multitrack "workshop" discussion groups (2-3 each day) and, possibly, impromptu "lightning talks." Workshops will be less structured than in the past, favoring an open discussion format with only a small amount of prepared material. Thus, rather than collecting workshop abstracts from speakers, we're asking each registrant to suggest a few topics of interest. After choosing the most popular topics, we'll ask some registrants if they'd like to act as discussion leaders. To register: register.jvmlangsummit.com For further information: jvmlangsummit.com Questions: inquire2016 at jvmlangsummit.com From gromero at linux.vnet.ibm.com Wed Jun 1 22:12:01 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 1 Jun 2016 19:12:01 -0300 Subject: RFR(M): 8158232: PPC64: improve byte, int and long array copy stubs by using VSX instructions In-Reply-To: <201605311537.u4VFYV1Q029540@mx0a-001b2d01.pphosted.com> References: <201605311537.u4VFYV1Q029540@mx0a-001b2d01.pphosted.com> Message-ID: <201606012212.u51M6Mws005449@mx0a-001b2d01.pphosted.com> Hi Michihiro A few things that come to my mind that could help address the questions raised by Goetz: * I could not see, when implementing the short case, any gain by unrolling the tight loop; * I could see that setting an aggressive prefetch did help a lot; * I think that aligning the backbranch target at 16-byte at least is the right thing to do, since according to [1]: "Instructions read out of the I-cache are forwarded to the IBuffer as a staging area for group formation. The IBuffer is arranged as a register file where each row can hold up to four instructions (16-byte aligned from the I-cache)" And a nit: add space, add upper case 'C', fix typo in "byte", and add an ending dot on: //copy 16 elements (total 128 byte) a time Regards, Gustavo [1] POWER8 Processor User?s Manual for the Single-Chip Module, 10 March 2015, Version 1.11, p. 207, section 10.1.6. On 31-05-2016 12:36, Michihiro Horie wrote: > > Dear all, > > Could you please review the following webrev? > > http://cr.openjdk.java.net/~mdoerr/8158232_PPC_vsx_copy/webrev.00/ > > This change improves performance of disjoint arraycopy of byte, int, and > long by using VSX load/store instructions. > > Discussion started from: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-May/002483.html > > Performance improvement with micro benchmarks is shown in: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-May/002531.html > > Thank you very much, > > Best regards, > -- > Michihiro Horie, > IBM Research - Tokyo > From david.holmes at oracle.com Thu Jun 2 07:13:05 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Jun 2016 17:13:05 +1000 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> Message-ID: <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> On 2/06/2016 1:24 AM, Paul Sandoz wrote: > (Please note this work is or will be covered with FC exception) > > Hi, > > Please review the VarHandles/Unsafe support for atomic ops on double/float fields/arrays. I think this is misguided. If the user wants CAS for float/double they can do the conversion to int/long in a context where they know that conversion makes sense and where they can deal with NaNs appropriately. At a minimum the fact this deals with raw bit patterns not semantic values needs to be exposed somehow. ie the handling of NaN needs to be explicit. David ----- > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ > > These patches are based on those of for sub-word CAS > > https://bugs.openjdk.java.net/browse/JDK-8157726 > http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/ > http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/ > > And the two patches combined expand the support of fields/arrays. > > > New float/double CAS methods are added to Unsafe that defer to int/long equivalents. Then the other atomic methods are built from weak CAS loops. > > No changes are required to HotSpot, but changes are required to the Unsafe tests in the hotspot repository. > > In general the changes to VHs and tests are minimal since it is triggered from changes to the generating scripts that now include float/double into the CAS category. > > There are some minor specification changes and a CCC has been initiated. > > JPRT tests results show no relevant failures for hotspot and core test sets. > > Thanks, > Paul. > From paul.sandoz at oracle.com Thu Jun 2 08:34:00 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 2 Jun 2016 10:34:00 +0200 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> Message-ID: > On 2 Jun 2016, at 09:13, David Holmes wrote: > > On 2/06/2016 1:24 AM, Paul Sandoz wrote: >> (Please note this work is or will be covered with FC exception) >> >> Hi, >> >> Please review the VarHandles/Unsafe support for atomic ops on double/float fields/arrays. > > I think this is misguided. If the user wants CAS for float/double they can do the conversion to int/long in a context where they know that conversion makes sense and where they can deal with NaNs appropriately. > I would still like to support some clearly defined default behaviour if at all possible, since this is not easy to get right so we can add some value here. The user can use int/long if that behaviour is not suitable. > At a minimum the fact this deals with raw bit patterns not semantic values needs to be exposed somehow. ie the handling of NaN needs to be explicit. > Yes, it?s multiple NaN values that collapse to a single NaN value. It would be good if our resident floating point expert Mr. Joe Darcy could chime in this respect. On Float.intBitsToFloat: *

Note that this method may not be able to return a * {@code float} NaN with exactly same bit pattern as the * {@code int} argument. IEEE 754 distinguishes between two * kinds of NaNs, quiet NaNs and signaling NaNs. The * differences between the two kinds of NaN are generally not * visible in Java. Arithmetic operations on signaling NaNs turn * them into quiet NaNs with a different, but often similar, bit * pattern. However, on some processors merely copying a * signaling NaN also performs that conversion. In particular, * copying a signaling NaN to return it to the calling method may * perform this conversion. So {@code intBitsToFloat} may * not be able to return a {@code float} with a signaling NaN * bit pattern. Consequently, for some {@code int} values, * {@code floatToRawIntBits(intBitsToFloat(start))} may * not equal {@code start}. Moreover, which * particular bit patterns represent signaling NaNs is platform * dependent; although all NaN bit patterns, quiet or signaling, * must be in the NaN range identified above. I am concerned that the CAS loops could in some cases loop without termination: @ForceInline public final float getAndAddFloat(Object o, long offset, float delta) { float v; do { v = getFloatVolatile(o, offset); } while (!weakCompareAndSwapFloatVolatile(o, offset, v, v + delta)); return v; } I think this should be: @ForceInline public final float getAndAddFloat(Object o, long offset, float delta) { int expectedBits; float v; do { expectedBits = getIntVolatile(o, offset); v = Float.intBitsToFloat(bits); // May not preserve a NaN value with the same bit pattern as expectedBits } while (!weakCompareAndSwapIntVolatile(o, offset, expectedBits, Float.floatToRawIntBits(v + delta))); return v; } and likewise for the atomic get-and-set methods. Paul. > David > ----- > >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ >> >> These patches are based on those of for sub-word CAS >> >> https://bugs.openjdk.java.net/browse/JDK-8157726 >> http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/ >> http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/ >> >> And the two patches combined expand the support of fields/arrays. >> >> >> New float/double CAS methods are added to Unsafe that defer to int/long equivalents. Then the other atomic methods are built from weak CAS loops. >> >> No changes are required to HotSpot, but changes are required to the Unsafe tests in the hotspot repository. >> >> In general the changes to VHs and tests are minimal since it is triggered from changes to the generating scripts that now include float/double into the CAS category. >> >> There are some minor specification changes and a CCC has been initiated. >> >> JPRT tests results show no relevant failures for hotspot and core test sets. >> >> Thanks, >> Paul. >> From vladimir.x.ivanov at oracle.com Thu Jun 2 10:47:09 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 2 Jun 2016 13:47:09 +0300 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <574FFC92.6010606@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> Message-ID: <988f2271-0d7e-7a02-b301-c6237f123262@oracle.com> Zoltan, (broadening the audience to hotspot-dev@) I'd like to draw attention from Runtime group to this change. > OK, so I have implemented a generic fix that adds the checks required by > the JVMS. > > For bytecodes modifying final fields, the VM checks > - that the accessing method is (for static fields) > - that the accessing method is (for instance fields) > and thrown an IllegalAccessError if any of the checks fails. > > Here is the new webrev: > http://cr.openjdk.java.net/~zmajo/8157181/webrev.02/ Regarding tightening linkage checks, your fix doesn't take into account JVMS changes between 6 & 7 (expected behavior differs depending on class file version). Before JVMS-7, where putfield/putstatic linkage checks were tightened, it was allowed to change final fields from anywhere in the same class. putfield "Linking Exceptions": JVMS-6 [1]: "Otherwise, if the field is final, it must be declared in the current class. Otherwise, an IllegalAccessError is thrown." JVMS-7 [2]: "Otherwise, if the field is final, it must be declared in the current class, and the instruction must occur in an instance initialization method () of the current class. Otherwise, an IllegalAccessError is thrown." src/share/vm/interpreter/linkResolver.cpp: + (byte == Bytecodes::_putstatic && fd.is_static() && method_name != vmSymbols::class_initializer_name()) || + ((byte == Bytecodes::_putfield || byte == Bytecodes::_nofast_putfield) && !fd.is_static() && method_name != vmSymbols::object_initializer_name()) Also, as we found earlier, checking method name is not enough: bool Method::is_static_initializer() const { // For classfiles version 51 or greater, ensure that the clinit method is // static. Non-static methods with the name "" are not static // initializers. (older classfiles exempted for backward compatibility) return name() == vmSymbols::class_initializer_name() && has_valid_initializer_flags(); } - LinkInfo link_info(defc, name, type, KlassHandle(), /*check_access=*/false); + LinkInfo link_info(defc, name, type, KlassHandle(), NULL, /*check_access=*/false); Use Handle() instead of NULL. Also, I'd prefer to see LinkInfo::_current_method and new constructor added: LinkInfo(KlassHandle resolved_klass, Symbol* name, Symbol* signature, Handle current_method, bool check_access = true) : _current_klass can be derived from _current_method, since: // current_klass = sending method holder (i.e., class containing the method // containing the call being resolved) > I did the following testing: > - JPRT > - pre-PIT RBT run (in progress) > - the reproducer. > > The reproducer now behaves as expected (an IllegalAccessError is > thrown). Also, the pre-PIT RBT run has shown no new failures so far. > > But there is a problem with JPRT: A JCK test, putstatic01801m, fails. > > The reason for the failure is that the the test generates a method that > contains a putstatic to a static final field (i.e., the bytecodes > generated by the test do not conform to the JVMS). (Even the test > mentions that the Java source equivalent to the generated bytecodes is > compilable only if the "final" keyword is removed from the declaration > of the static field.) > > So (if we decide to push the current fix) the issue with the test needs > to be fixed first. Do you know how we could proceed with that? File a bug against JCK. Best regards, Vladimir Ivanov [1] https://docs.oracle.com/javase/specs/jvms/se6/html/Instructions2.doc11.html [2] https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.putfield [3] https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4.3.2 > > Thank you and best regards, > > > Zoltan > >> >> Best regards, >> Vladimir Ivanov >> >>> >>> I agree with you, alternatively we can propose a more generic fix (fix >>> the interpreter and the compilers as well). The fix would most likely >>> affect field resolution in LinkResolver::resolve_field() around here: >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>> >>> >>> >>> Changing resolve_field() to throw an IllegalAccessError for >>> inappropriate field access will propagate the exception to the >>> interpreter. Changing ciField::will_link() will most likely kill (some) >>> compilations (if, e.g., fields are linked through ciField::will_link()). >>> >>> I'd prefer to take the second option (changing field resolution), but >>> there might be some disadvantages related to option I might be >>> overseeing. >> >> >> >> >>> >>> Thank you! >>> >>> Best regards, >>> >>> >>> Zoltan >>> >>> >>>> >>>>> More details about the failure are here [3]. >>>>> >>>>> With the patch applied, the program always completes as it is expected >>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed (because we >>>>> always interpret methods non-conforming with the VM spec). >>>>> >>>>> Here is the updated webrev: >>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>> Bailing out the whole compilation in C2 is even less appropriate. It >>>> should generate an uncommon trap for such accesses instead (see >>>> Parse::do_field_access). >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] >>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>> >>>> >>> > From david.holmes at oracle.com Thu Jun 2 11:51:02 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Jun 2016 21:51:02 +1000 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <988f2271-0d7e-7a02-b301-c6237f123262@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <988f2271-0d7e-7a02-b301-c6237f123262@oracle.com> Message-ID: <93b3fe16-2bb0-3e77-9333-61989f33ff1c@oracle.com> On 2/06/2016 8:47 PM, Vladimir Ivanov wrote: > Zoltan, > > (broadening the audience to hotspot-dev@) > > I'd like to draw attention from Runtime group to this change. >> OK, so I have implemented a generic fix that adds the checks required by >> the JVMS. >> >> For bytecodes modifying final fields, the VM checks >> - that the accessing method is (for static fields) >> - that the accessing method is (for instance fields) >> and thrown an IllegalAccessError if any of the checks fails. >> >> Here is the new webrev: >> http://cr.openjdk.java.net/~zmajo/8157181/webrev.02/ > > Regarding tightening linkage checks, your fix doesn't take into account > JVMS changes between 6 & 7 (expected behavior differs depending on class > file version). The simplest, and common, approach to these kind of issues is to only apply the correction for the current class file version and keep the relaxed rules for all others. That provides the best compatibility story. Of course if security is a concern then that is a different matter - but such concerns can not be discussed here. David ----- > Before JVMS-7, where putfield/putstatic linkage checks were tightened, > it was allowed to change final fields from anywhere in the same class. > > putfield "Linking Exceptions": > > JVMS-6 [1]: > "Otherwise, if the field is final, it must be declared in the > current class. Otherwise, an IllegalAccessError is thrown." > > JVMS-7 [2]: > "Otherwise, if the field is final, it must be declared in the > current class, and the instruction must occur in an instance > initialization method () of the current class. Otherwise, an > IllegalAccessError is thrown." > > > src/share/vm/interpreter/linkResolver.cpp: > > + (byte == Bytecodes::_putstatic && fd.is_static() && > method_name != vmSymbols::class_initializer_name()) || > + ((byte == Bytecodes::_putfield || byte == > Bytecodes::_nofast_putfield) && !fd.is_static() && method_name != > vmSymbols::object_initializer_name()) > > > Also, as we found earlier, checking method name is not enough: > > bool Method::is_static_initializer() const { > // For classfiles version 51 or greater, ensure that the clinit method is > // static. Non-static methods with the name "" are not static > // initializers. (older classfiles exempted for backward compatibility) > return name() == vmSymbols::class_initializer_name() && > has_valid_initializer_flags(); > } > > > - LinkInfo link_info(defc, name, type, KlassHandle(), > /*check_access=*/false); > + LinkInfo link_info(defc, name, type, KlassHandle(), NULL, > /*check_access=*/false); > > Use Handle() instead of NULL. > > Also, I'd prefer to see LinkInfo::_current_method and new constructor > added: > > LinkInfo(KlassHandle resolved_klass, Symbol* name, Symbol* signature, > Handle current_method, bool check_access = true) : > > _current_klass can be derived from _current_method, since: > > // current_klass = sending method holder (i.e., class containing the > method > // containing the call being resolved) > >> I did the following testing: >> - JPRT >> - pre-PIT RBT run (in progress) >> - the reproducer. >> >> The reproducer now behaves as expected (an IllegalAccessError is >> thrown). Also, the pre-PIT RBT run has shown no new failures so far. >> >> But there is a problem with JPRT: A JCK test, putstatic01801m, fails. >> >> The reason for the failure is that the the test generates a method that >> contains a putstatic to a static final field (i.e., the bytecodes >> generated by the test do not conform to the JVMS). (Even the test >> mentions that the Java source equivalent to the generated bytecodes is >> compilable only if the "final" keyword is removed from the declaration >> of the static field.) >> >> So (if we decide to push the current fix) the issue with the test needs >> to be fixed first. Do you know how we could proceed with that? > File a bug against JCK. > > Best regards, > Vladimir Ivanov > > [1] > https://docs.oracle.com/javase/specs/jvms/se6/html/Instructions2.doc11.html > > [2] > https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.putfield > > > [3] > https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4.3.2 > >> >> Thank you and best regards, >> >> >> Zoltan >> >>> >>> Best regards, >>> Vladimir Ivanov >>> >>>> >>>> I agree with you, alternatively we can propose a more generic fix (fix >>>> the interpreter and the compilers as well). The fix would most likely >>>> affect field resolution in LinkResolver::resolve_field() around here: >>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>> >>>> >>>> >>>> >>>> Changing resolve_field() to throw an IllegalAccessError for >>>> inappropriate field access will propagate the exception to the >>>> interpreter. Changing ciField::will_link() will most likely kill (some) >>>> compilations (if, e.g., fields are linked through >>>> ciField::will_link()). >>>> >>>> I'd prefer to take the second option (changing field resolution), but >>>> there might be some disadvantages related to option I might be >>>> overseeing. >>> >>> >>> >>> >>>> >>>> Thank you! >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>>> >>>> >>>>> >>>>>> More details about the failure are here [3]. >>>>>> >>>>>> With the patch applied, the program always completes as it is >>>>>> expected >>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed (because we >>>>>> always interpret methods non-conforming with the VM spec). >>>>>> >>>>>> Here is the updated webrev: >>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>> Bailing out the whole compilation in C2 is even less appropriate. It >>>>> should generate an uncommon trap for such accesses instead (see >>>>> Parse::do_field_access). >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> [1] >>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>> >>>>> >>>>> >>>> >> From martinrb at google.com Thu Jun 2 12:41:35 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 2 Jun 2016 05:41:35 -0700 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: <575021C2.7070509@cs.oswego.edu> References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> <575021C2.7070509@cs.oswego.edu> Message-ID: You can find an AtomicDouble in jsr166 CVS http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/extra/AtomicDouble.java?view=markup and in guava https://github.com/google/guava/blob/master/guava/src/com/google/common/util/concurrent/AtomicDouble.java I'm still in favor of putting it in openjdk. On Thu, Jun 2, 2016 at 5:08 AM, Doug Lea

wrote: > On 06/02/2016 04:34 AM, Paul Sandoz wrote: >> >> >> I am concerned that the CAS loops could in some cases loop without >> termination: >> >> @ForceInline >> public final float getAndAddFloat(Object o, long offset, float delta) { >> float v; >> do { >> v = getFloatVolatile(o, offset); >> } while (!weakCompareAndSwapFloatVolatile(o, offset, v, v + delta)); >> return v; >> } >> > > Yes. This is why we did not introduce Atomic{Float, Double} in > java.util.concurrent.atomic, but instead tell people to > use intBitsToFloat etc if that's what they intend (see > http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/package-summary.html) > > People (apparently including you :-) argue that this is too pedantic > though. The standard way suggested in docs is almost always what > people want, so could be used, so long as it is carefully spelled > out so that when people do hit multiple NaN problems and the like, > at least they can find an explanation. > > > >> >> I think this should be: >> >> @ForceInline >> public final float getAndAddFloat(Object o, long offset, float delta) { >> int expectedBits; >> float v; >> do { >> expectedBits = getIntVolatile(o, offset); >> v = Float.intBitsToFloat(bits); // May not preserve a NaN value >> with the same bit pattern as expectedBits >> } while (!weakCompareAndSwapIntVolatile(o, offset, expectedBits, >> Float.floatToRawIntBits(v + delta))); >> return v; >> } >> > From vladimir.x.ivanov at oracle.com Thu Jun 2 12:55:38 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 2 Jun 2016 15:55:38 +0300 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> Message-ID: Paul, Leaving practicality aspect of float/double API aside... > I am concerned that the CAS loops could in some cases loop without termination: Can you elaborate? I don't see how it is possible with the proposed patch. Unless getFloatVolatile() or weakCompareAndSwapFloatVolatile() change the original value, it should not happen. And both functions preserve float value bits intact: + @ForceInline + public final boolean weakCompareAndSwapFloatVolatile(Object o, long offset, + float expected, + float x) { + return weakCompareAndSwapIntVolatile(o, offset, + Float.floatToRawIntBits(expected), + Float.floatToRawIntBits(x)); + } Float.floatToRawIntBits() makes it safe, but with Float.intBitsToFloat() used infinite looping can happen for NaNs. Best regards, Vladimir Ivanov > > @ForceInline > public final float getAndAddFloat(Object o, long offset, float delta) { > float v; > do { > v = getFloatVolatile(o, offset); > } while (!weakCompareAndSwapFloatVolatile(o, offset, v, v + delta)); > return v; > } > > > I think this should be: > > @ForceInline > public final float getAndAddFloat(Object o, long offset, float delta) { > int expectedBits; > float v; > do { > expectedBits = getIntVolatile(o, offset); > v = Float.intBitsToFloat(bits); // May not preserve a NaN value with the same bit pattern as expectedBits > } while (!weakCompareAndSwapIntVolatile(o, offset, expectedBits, Float.floatToRawIntBits(v + delta))); > return v; > } > > and likewise for the atomic get-and-set methods. > > Paul. > >> David >> ----- >> >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ >>> >>> These patches are based on those of for sub-word CAS >>> >>> https://bugs.openjdk.java.net/browse/JDK-8157726 >>> http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/ >>> http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/ >>> >>> And the two patches combined expand the support of fields/arrays. >>> >>> >>> New float/double CAS methods are added to Unsafe that defer to int/long equivalents. Then the other atomic methods are built from weak CAS loops. >>> >>> No changes are required to HotSpot, but changes are required to the Unsafe tests in the hotspot repository. >>> >>> In general the changes to VHs and tests are minimal since it is triggered from changes to the generating scripts that now include float/double into the CAS category. >>> >>> There are some minor specification changes and a CCC has been initiated. >>> >>> JPRT tests results show no relevant failures for hotspot and core test sets. >>> >>> Thanks, >>> Paul. >>> > From paul.sandoz at oracle.com Thu Jun 2 15:25:48 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 2 Jun 2016 17:25:48 +0200 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> Message-ID: <89EC54E9-2BC1-4994-BF72-99FC20F9729C@oracle.com> > On 2 Jun 2016, at 14:55, Vladimir Ivanov wrote: > > Paul, > > Leaving practicality aspect of float/double API aside... > >> I am concerned that the CAS loops could in some cases loop without termination: > > Can you elaborate? I don't see how it is possible with the proposed patch. > The key aspect is in the JavaDoc snippet in my previous email. > On Float.intBitsToFloat: > > *

Note that this method may not be able to return a > * {@code float} NaN with exactly same bit pattern as the > * {@code int} argument. IEEE 754 distinguishes between two > * kinds of NaNs, quiet NaNs and signaling NaNs. The > * differences between the two kinds of NaN are generally not > * visible in Java. Arithmetic operations on signaling NaNs turn > * them into quiet NaNs with a different, but often similar, bit > * pattern. However, on some processors merely copying a > * signaling NaN also performs that conversion. In particular, > * copying a signaling NaN to return it to the calling method may > * perform this conversion. So {@code intBitsToFloat} may > * not be able to return a {@code float} with a signaling NaN > * bit pattern. Consequently, for some {@code int} values, > * {@code floatToRawIntBits(intBitsToFloat(start))} may > * not equal {@code start}. Moreover, which > * particular bit patterns represent signaling NaNs is platform > * dependent; although all NaN bit patterns, quiet or signaling, > * must be in the NaN range identified above. > I dunno if it can happen on x86 [*], but from reading the above I presume it could theoretically happen on some other hardware (what exactly i do not know). Note that the loaded float value is passed to the weakCompareAndSwapFloatVolatile method as an argument. IIUC that might trigger the conversion from a signalling NaN to a quiet NaN, subtly changing the bits of the expected value that was loaded. Paul. [*] Here is a simple program to induce a different on x86 (at least on my machine). To induce that i am adding 0.0f to the float value. public class AllTheNaNs { public static void main(String[] args) { for (long bits = 0x7f800001; bits <= 0x7fffffff; bits++) { testBits((int) bits); } for (long bits = 0xff800001; bits <= 0xffffffff; bits++) { testBits((int) bits); } } static void testBits(int vbits) { float v = Float.intBitsToFloat(vbits); assert Float.isNaN(v); float vv = id(v); assert Float.isNaN(vv); int vvbits = Float.floatToRawIntBits(vv); if (vvbits != vbits) { System.out.println(Integer.toHexString(vbits) + " " + Integer.toHexString(vvbits) + " " + Float.valueOf(v).equals(Float.valueOf(vv)) + " " + Float.compare(v, vv)); } } static float id(float f) { return f + 0.0f; } } > Unless getFloatVolatile() or weakCompareAndSwapFloatVolatile() change the original value, it should not happen. And both functions preserve float value bits intact: > > + @ForceInline > + public final boolean weakCompareAndSwapFloatVolatile(Object o, long offset, > + float expected, > + float x) { > + return weakCompareAndSwapIntVolatile(o, offset, > + Float.floatToRawIntBits(expected), > + Float.floatToRawIntBits(x)); > + } > > Float.floatToRawIntBits() makes it safe, but with Float.intBitsToFloat() used infinite looping can happen for NaNs. > > Best regards, > Vladimir Ivanov > From paul.sandoz at oracle.com Thu Jun 2 15:29:58 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 2 Jun 2016 17:29:58 +0200 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> <575021C2.7070509@cs.oswego.edu> Message-ID: > On 2 Jun 2016, at 14:41, Martin Buchholz wrote: > > You can find an AtomicDouble in jsr166 CVS > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/extra/AtomicDouble.java?view=markup > and in guava > https://github.com/google/guava/blob/master/guava/src/com/google/common/util/concurrent/AtomicDouble.java > > I'm still in favor of putting it in openjdk. > Thanks, that is helpful. What pushed me over the edge in favour was the support for sub-word CAS. The float/double types are lonely and want to join the club as fully signed up members :-) I will produce another patch with fixes and better docs. Thanks, Paul. From max.ockner at oracle.com Thu Jun 2 15:33:26 2016 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 02 Jun 2016 11:33:26 -0400 Subject: RFR: 8157490: null stream->source() no longer causes error with -Xlog:class+load In-Reply-To: <574DF56D.8050503@oracle.com> References: <57473B6F.2010806@oracle.com> <57474AB1.6030407@oracle.com> <574DCC6D.1080208@oracle.com> <574DF56D.8050503@oracle.com> Message-ID: <575051C6.7050709@oracle.com> Thanks for your reviews. I will submit this now. Max On 5/31/2016 4:34 PM, Lois Foltan wrote: > Thanks Max for implementing the suggestion. Looks good. > Lois > > On 5/31/2016 1:39 PM, Max Ockner wrote: >> I like this suggestion and I have updated my fix with it. >> webrev: http://cr.openjdk.java.net/~mockner/8157490.02/ >> Thanks, >> Max >> >> On 5/26/2016 3:12 PM, Lois Foltan wrote: >>> >>> On 5/26/2016 2:07 PM, Max Ockner wrote: >>>> Hello, >>>> >>>> Please review this very small fix for class+load logging with modules. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8157490 >>>> Webrev: http://cr.openjdk.java.net/~mockner/8157490/ >>>> >>>> Summary: The JCK test >>>> vm/jni/DefineClass/dfcl001/dfcl00101m1/dfcl00101m1 hit a SIGSEGV in >>>> the logging section at the end of >>>> ClassFileParser::fill_instance_klass(). With the addition of >>>> modules, this logging section now uses >>>> >>>> strlen(stream->source()) >>>> >>>> to compute some of the module related parameters that it needs. >>>> This SIGSEGV originated from the above line being executed with a >>>> null stream source. >>> >>> Hi Max, >>> >>> I think you change is correct, but I would like to suggest changing >>> the code even further. Currently the code between line #5352-5360 >>> does a complicated check to see if the module's name is part of the >>> java runtime image file and only sets the local variable >>> "module_name" if it is. So, only module names that are defined >>> within the java runtime image file are printed out in the logging. >>> We should print out all modules' names, not just the ones in the >>> jimage file. So please try removing lines #5352-5360 and set the >>> local variable to: >>> >>> const char* module_name = (module_entry->name() == NULL) ? >>> UNNAMED_MODULE : module_entry->name()->as_C_string(); >>> >>> The local variable "module_entry" is already checked at line #5310 >>> to make sure it is set to a non-NULL value. >>> >>> Thanks, >>> Lois >>> >>>> >>>> Tested with vm/jni/DefineClass/dfcl001/dfcl00101m1/dfcl00101m1 >>>> >>>> Thanks, >>>> Max >>> >> > From martinrb at google.com Thu Jun 2 17:56:12 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 2 Jun 2016 10:56:12 -0700 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> <575021C2.7070509@cs.oswego.edu> Message-ID: I don't see any way that AtomicDouble could get into trouble with floating point weirdness. Users cannot provide arbitrary long bit patterns; they have to provide an actual java double. It encapsulates the existing advice of transforming double to long. I suppose someone could do atomicDouble.CAS(NaN, 1) and fail because we're storing a DIFFERENT NaN, but we have little sympathy. It's possible to collapse all the NaNs into the One True NaN on input, but I don't recommend it. On Thu, Jun 2, 2016 at 8:29 AM, Paul Sandoz wrote: > >> On 2 Jun 2016, at 14:41, Martin Buchholz wrote: >> >> You can find an AtomicDouble in jsr166 CVS >> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/extra/AtomicDouble.java?view=markup >> and in guava >> https://github.com/google/guava/blob/master/guava/src/com/google/common/util/concurrent/AtomicDouble.java >> >> I'm still in favor of putting it in openjdk. >> > > Thanks, that is helpful. > > What pushed me over the edge in favour was the support for sub-word CAS. The float/double types are lonely and want to join the club as fully signed up members :-) > > I will produce another patch with fixes and better docs. > > Thanks, > Paul. From vladimir.kozlov at oracle.com Thu Jun 2 19:04:16 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 2 Jun 2016 12:04:16 -0700 Subject: RFR(M): 8158232: PPC64: improve byte, int and long array copy stubs by using VSX instructions In-Reply-To: <15e6ab6155984dee9760170d731844b1@DEWDFE13DE09.global.corp.sap> References: <201605311537.u4VFYV1Q029540@mx0a-001b2d01.pphosted.com> <4ef29ef8b7904b98952224ecb77e21f8@DEWDFE13DE09.global.corp.sap> <201606020207.u5225ptS007620@mx0a-001b2d01.pphosted.com> <498493e344fd4d02beb049ff9dd9aba3@DEWDFE13DE09.global.corp.sap> <201606021507.u52F64ci025581@mx0a-001b2d01.pphosted.com> <15e6ab6155984dee9760170d731844b1@DEWDFE13DE09.global.corp.sap> Message-ID: <57508330.2050307@oracle.com> Please, hold on pushing this. We are after Feature complete date May 26: http://openjdk.java.net/projects/jdk9/ All RFE(enhancement) changes should be approved before push. Please, wait when approval process is finalized. Regards, Vladimir On 6/2/16 11:48 AM, Lindenmaier, Goetz wrote: > Ok, reviewed. > > Thanks for explanations, > > Goetz. > > *From:*Michihiro Horie [mailto:HORIE at jp.ibm.com] > *Sent:* Thursday, June 02, 2016 5:07 PM > *To:* Lindenmaier, Goetz > *Cc:* hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > *Subject:* RE: RFR(M): 8158232: PPC64: improve byte, int and long array copy stubs by using VSX instructions > > Hi Goetz, > >>You are saying you could not measure an effect? > We could not observe a big difference, but as you point out, jbb2013 looks a little difficult to get stable results. > >>There still might be a penalty because of the additional instructions >>as the prefetching for small arrays, or a lost opportunity because of >>not unrolling. >>It would be nice to have numbers on this, but I think the effect will >>be rather small so that I?m also fine with the current solution. >> >>How did you test the new solution? > I agree, a penalty might depend on the applications, but the effect will be rather small. I also tested the latest code by using micro benchmarks and jbb2013. > > Best regards, > -- > Michi-hiro > IBM Research - Tokyo > > Inactive hide details for "Lindenmaier, Goetz" ---2016/06/02 19:47:38---Hi Michihiro, thanks for the new webrev, and thanks Mar"Lindenmaier, Goetz" ---2016/06/02 19:47:38---Hi Michihiro, thanks for > the new webrev, and thanks Martin for uploading it. > > From: "Lindenmaier, Goetz" > > To: Michihiro Horie/Japan/IBM at IBMJP > Cc: "hotspot-dev at openjdk.java.net " >, "ppc-aix-port-dev at openjdk.java.net > " > > Date: 2016/06/02 19:47 > Subject: RE: RFR(M): 8158232: PPC64: improve byte, int and long array copy stubs by using VSX instructions > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > > > Hi Michihiro, > > thanks for the new webrev, and thanks Martin for uploading it. > >> but there was no special reason on the changes in loop body sizes > You are saying you could not measure an effect? With jbb2013 it?s hard > to get reproducible results, jvm2008 is more simple with that. But it > needs adaptions to run with Java 8 (or you skip the compiler benchmarks). > Also, there is now jbb2015 which is jbb2013 with some bugs fixed. > > The loop body sizes are now the same with and without vsx. > This alleviates my main concerns. > There still might be a penalty because of the additional instructions > as the prefetching for small arrays, or a lost opportunity because of > not unrolling. > It would be nice to have numbers on this, but I think the effect will > be rather small so that I?m also fine with the current solution. > > How did you test the new solution? > > Best regards, > Goetz. > > > *From:*Michihiro Horie [mailto:HORIE at jp.ibm.com] * > Sent:* Thursday, June 02, 2016 4:07 AM* > To:* Lindenmaier, Goetz >* > Cc:* hotspot-dev at openjdk.java.net ; ppc-aix-port-dev at openjdk.java.net * > Subject:* RE: RFR(M): 8158232: PPC64: improve byte, int and long array copy stubs by using VSX instructions > > Hi Goetz, > > Thank you very much for your comments, which is really helpful. > > I would fix my code to fit the loop body sizes in elements to the original ones. We did measurements by using SPECjbb2013, but there was no special reason on the changes in loop body sizes. They are > code after the trial and error with a few developers. > >>But I'm not convinced that this helps the average performance, as important >>lengths will regress. > : >>Especially with the byte arrays, which are used to store >>compact Strings, I would doubt that this helps an average >>application. For sizes 32-128 you first have a failing >>compare, and then step through a '4' loop instead of a '32' >>one. > Your point makes sense to me. > >>Should you also set the prefetching engine more aggressive as >>in the short copy loop? > I would use prefetching engine as in the short copy loop, thank you. > > Best regards, > -- > Michihiro Horie, > IBM Research - Tokyo > > Inactive hide details for "Lindenmaier, Goetz" ---2016/06/01 23:14:42---Hi Michihiro, Thanks for contributing to the ppc port!"Lindenmaier, Goetz" ---2016/06/01 23:14:42---Hi Michihiro, Thanks for > contributing to the ppc port! > > From: "Lindenmaier, Goetz" > > To: Michihiro Horie/Japan/IBM at IBMJP, "hotspot-dev at openjdk.java.net " >, > "ppc-aix-port-dev at openjdk.java.net " > > Date: 2016/06/01 23:14 > Subject: RE: RFR(M): 8158232: PPC64: improve byte, int and long array copy stubs by using VSX instructions > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > > > > Hi Michihiro, > > Thanks for contributing to the ppc port! > > I've been looking at your changes. Basically they look good. But I'm > not convinced that this helps the average performance, as important > lengths will regress. > > We once ananlyzed a benchmark, where we saw 400 million copies of > short arrays which had an average length of 38!! elements. There > were 200 byte array copies and 20 million long array copies. > This should have changed as there are compact strings, now. > I think we had suppressed the array copy stubs and modified > PrintOptoStatistics to collect that data. > > As I understand we have the following loops now: > > Loop body sizes in elements > before now sizes regressing > byte 32,4,1 128,4,1 32-127 > short 16,2,1 16,2,1 none > int 8,1 32,1 8-31 > long 4,1 16,4,1 none > > Especially with the byte arrays, which are used to store > compact Strings, I would doubt that this helps an average > application. For sizes 32-128 you first have a failing > compare, and then step through a '4' loop instead of a '32' > one. > > Further, why don't you use the new instructions in the smaller > loops, too? Like in the long '4' version? > > I could not find a measurement showing the effect on jbb2015 > or jvm2008. Did you measure these? > Or you could modify your benchmarks for some small, odd > numbers, as 23, 42, 99 ...? > > Should you also set the prefetching engine more aggressive as > in the short copy loop? > > Best regards, > Goetz. > >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >> Behalf Of Michihiro Horie >> Sent: Dienstag, 31. Mai 2016 17:37 >> To:hotspot-dev at openjdk.java.net ; ppc-aix-port-dev at openjdk.java.net >> Subject: RFR(M): 8158232: PPC64: improve byte, int and long array copy stubs >> by using VSX instructions >> >> >> Dear all, >> >> Could you please review the following webrev? >> >>http://cr.openjdk.java.net/~mdoerr/8158232_PPC_vsx_copy/webrev.00/ >> >> This change improves performance of disjoint arraycopy of byte, int, and >> long by using VSX load/store instructions. >> >> Discussion started from: >>http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016- _ > _> May/002483.html >> >> Performance improvement with micro benchmarks is shown in: >>http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016- _ > _> May/002531.html >> >> Thank you very much, >> >> Best regards, >> -- >> Michihiro Horie, >> IBM Research - Tokyo > From alexhenrie24 at gmail.com Thu Jun 2 19:44:23 2016 From: alexhenrie24 at gmail.com (Alex Henrie) Date: Thu, 02 Jun 2016 13:44:23 -0600 Subject: [PATCH resend] 8157758: Use (~0u) instead of (-1) when left-shifting Message-ID: # HG changeset patch # User ahenrie # Date 1464130244 21600 # Tue May 24 16:50:44 2016 -0600 # Node ID a6853f1a7065fbdef50bc71948f7712f81527734 # Parent 3844f305a6f7b9bcb39c1274ed41aaf5614d0968 8157758: Use (~0u) instead of (-1) when left-shifting diff --git a/src/share/vm/code/dependencies.hpp b/src/share/vm/code/dependencies.hpp --- a/src/share/vm/code/dependencies.hpp +++ b/src/share/vm/code/dependencies.hpp @@ -163,17 +163,17 @@ class Dependencies: public ResourceObj { call_site_target_value, TYPE_LIMIT }; enum { LG2_TYPE_LIMIT = 4, // assert(TYPE_LIMIT <= (1< References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> Message-ID: <57510383.4090506@oracle.com> How about only fixing C1 to take into account the store (or not constant fold in such case) because it was allowed before JVMS-7? And file a separate issue for JVMS-7 conformance. It looks like it may have huge impact on performance and we are already very late in JDK 9 development to make such changes in rush. Zoltan, what C2 does in such case? Tom, what Graal does in such case? The case is: https://bugs.openjdk.java.net/browse/JDK-8157181?focusedCommentId=13942824&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13942824 "While compiling bytecode @29, the C1 compiler assumes that the value of the _pyx0.self field has already been set in the class initializer method (as the class is initialized). The C1 compiler also assumes that the field will not change (as it is static final). Therefore, the C1 compiler omits reading the field _pyx0.self and passes the current value of the field ('null') to the org/python/core/Py.newCode() method called at bytecode @37. (The correct value would be 'this'.)" Thanks, Vladimir On 6/2/16 10:51 AM, Tom Rodriguez wrote: >>>> Therefore, in the current webrev, I've disabled folding of accesses to >>>> all non-stable fields. >>> Please do not do that, it will be a huge regression in term of perf at least for the language runtimes i maintain >>> (and i suppose for Nashorn, JRuby or Groovy), Here are the perf assertions i use routinely, >>> static final method handle is considered as constant, final fields (even not static) of VM anonymous class is considered as truly final. >>> >> >> I fully understand your concerns. And thank you for sharing your asserts! > > The folding within the compiler should be handled differently since the concerns are different and removing it will likely cause invokeynamic performance to collapse. The compiler is only folding > final instance fields that are part of a chain of constants, so the main concern is whether an object has been published before it?s been fully constructed or if someone is going to use reflection to > modify a final field after the object has been published. The trust_final_non_static_fields logic in ciField.cpp is calling out classes which we control that shouldn?t violate those rules and that > are important for performance. So I think it should be left as is. It really doesn?t relate to the issue at hand I think. > > Also you?ve removed folding of static final fields which would be a very bad thing to do. > > ciField has some caching logic for _known_to_link_with_get/set and if you are adding a ciMethod* argument you also need to cache the method that was checked last time as well. > > tom > >> >> Let's see what others think about how to go about this problem. So far the following options were explored >> - bail out compilation of non-compliant methods; >> - enforce JVMS conformance for all classes and keep constant folding enabled; >> - enforce JVMS conformance only for classes with _major_version >=52 and completely disable constant folding. >> >> I'm not sure which option is the best. Also, there might be other options as well. >> >> Thank you and best regards, >> >> >> Zoltan >> >> >> >>>> We could relax that criteria, e.g., by disabling folding only for those >>>> field that were declared in a class with _major_version < 52. But it >>>> would be great if you could give me some feedback before I look into >>>> that. Thank you very much in advance! >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.05/ >>>> >>>> Testing: JPRT in progress. >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>> R?mi >>> >>>>> Thank you and best regards, >>>>> >>>>> >>>>> Zoltan >>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>>> I agree with you, alternatively we can propose a more generic fix (fix >>>>>>> the interpreter and the compilers as well). The fix would most likely >>>>>>> affect field resolution in LinkResolver::resolve_field() around here: >>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>>>> inappropriate field access will propagate the exception to the >>>>>>> interpreter. Changing ciField::will_link() will most likely kill (some) >>>>>>> compilations (if, e.g., fields are linked through >>>>>>> ciField::will_link()). >>>>>>> >>>>>>> I'd prefer to take the second option (changing field resolution), but >>>>>>> there might be some disadvantages related to option I might be >>>>>>> overseeing. >>>>>> >>>>>> >>>>>> >>>>>>> Thank you! >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> >>>>>>> Zoltan >>>>>>> >>>>>>> >>>>>>>>> More details about the failure are here [3]. >>>>>>>>> >>>>>>>>> With the patch applied, the program always completes as it is >>>>>>>>> expected >>>>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed (because we >>>>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>>>> >>>>>>>>> Here is the updated webrev: >>>>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>>>> Bailing out the whole compilation in C2 is even less appropriate. It >>>>>>>> should generate an uncommon trap for such accesses instead (see >>>>>>>> Parse::do_field_access). >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>> [1] >>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 > From vladimir.x.ivanov at oracle.com Fri Jun 3 10:48:38 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 3 Jun 2016 13:48:38 +0300 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <57510383.4090506@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> Message-ID: On 6/3/16 7:11 AM, Vladimir Kozlov wrote: > How about only fixing C1 to take into account the store (or not constant > fold in such case) because it was allowed before JVMS-7? > > And file a separate issue for JVMS-7 conformance. It looks like it may > have huge impact on performance and we are already very late in JDK 9 > development to make such changes in rush. Yes, let's separate them (considering the difference in impact) and align the JVM behavior with the JVMS separately. For now, disabling constant folding of static/instance field loads in static/instance initializers should solve the immediate problem for well-behaved (according to JVMS) programs. Also, such change should not cause any performance regressions. Considering it is possible to update static final fields through Reflection API, I don't see JVMS conformance issue (ability to update final static fields outside of static initializer on bytecode level) as a problem of the same level for JIT-compilers. It can be fixed as part of aligning the JVM with JVMS (but still in JDK9). Best regards, Vladimir Ivanov > > Zoltan, what C2 does in such case? > Tom, what Graal does in such case? > > The case is: > > https://bugs.openjdk.java.net/browse/JDK-8157181?focusedCommentId=13942824&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13942824 > > > "While compiling bytecode @29, the C1 compiler assumes that the value of > the _pyx0.self field has already been set in the class initializer > method (as the class is initialized). The C1 compiler also > assumes that the field will not change (as it is static final). > Therefore, the C1 compiler omits reading the field _pyx0.self and passes > the current value of the field ('null') to the > org/python/core/Py.newCode() method called at bytecode @37. (The correct > value would be 'this'.)" > > Thanks, > Vladimir > > On 6/2/16 10:51 AM, Tom Rodriguez wrote: >>>>> Therefore, in the current webrev, I've disabled folding of accesses to >>>>> all non-stable fields. >>>> Please do not do that, it will be a huge regression in term of perf >>>> at least for the language runtimes i maintain >>>> (and i suppose for Nashorn, JRuby or Groovy), Here are the perf >>>> assertions i use routinely, >>>> static final method handle is considered as constant, final fields >>>> (even not static) of VM anonymous class is considered as truly final. >>>> >>> >>> I fully understand your concerns. And thank you for sharing your >>> asserts! >> >> The folding within the compiler should be handled differently since >> the concerns are different and removing it will likely cause >> invokeynamic performance to collapse. The compiler is only folding >> final instance fields that are part of a chain of constants, so the >> main concern is whether an object has been published before it?s been >> fully constructed or if someone is going to use reflection to >> modify a final field after the object has been published. The >> trust_final_non_static_fields logic in ciField.cpp is calling out >> classes which we control that shouldn?t violate those rules and that >> are important for performance. So I think it should be left as is. >> It really doesn?t relate to the issue at hand I think. >> >> Also you?ve removed folding of static final fields which would be a >> very bad thing to do. >> >> ciField has some caching logic for _known_to_link_with_get/set and if >> you are adding a ciMethod* argument you also need to cache the method >> that was checked last time as well. >> >> tom >> >>> >>> Let's see what others think about how to go about this problem. So >>> far the following options were explored >>> - bail out compilation of non-compliant methods; >>> - enforce JVMS conformance for all classes and keep constant folding >>> enabled; >>> - enforce JVMS conformance only for classes with _major_version >=52 >>> and completely disable constant folding. >>> >>> I'm not sure which option is the best. Also, there might be other >>> options as well. >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> >>> >>> >>>>> We could relax that criteria, e.g., by disabling folding only for >>>>> those >>>>> field that were declared in a class with _major_version < 52. But it >>>>> would be great if you could give me some feedback before I look into >>>>> that. Thank you very much in advance! >>>>> >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.05/ >>>>> >>>>> Testing: JPRT in progress. >>>>> >>>>> Best regards, >>>>> >>>>> >>>>> Zoltan >>>> R?mi >>>> >>>>>> Thank you and best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>>> I agree with you, alternatively we can propose a more generic >>>>>>>> fix (fix >>>>>>>> the interpreter and the compilers as well). The fix would most >>>>>>>> likely >>>>>>>> affect field resolution in LinkResolver::resolve_field() around >>>>>>>> here: >>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>>>>> inappropriate field access will propagate the exception to the >>>>>>>> interpreter. Changing ciField::will_link() will most likely kill >>>>>>>> (some) >>>>>>>> compilations (if, e.g., fields are linked through >>>>>>>> ciField::will_link()). >>>>>>>> >>>>>>>> I'd prefer to take the second option (changing field >>>>>>>> resolution), but >>>>>>>> there might be some disadvantages related to option I might be >>>>>>>> overseeing. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Thank you! >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> >>>>>>>> Zoltan >>>>>>>> >>>>>>>> >>>>>>>>>> More details about the failure are here [3]. >>>>>>>>>> >>>>>>>>>> With the patch applied, the program always completes as it is >>>>>>>>>> expected >>>>>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed >>>>>>>>>> (because we >>>>>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>>>>> >>>>>>>>>> Here is the updated webrev: >>>>>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>>>>> Bailing out the whole compilation in C2 is even less >>>>>>>>> appropriate. It >>>>>>>>> should generate an uncommon trap for such accesses instead (see >>>>>>>>> Parse::do_field_access). >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Vladimir Ivanov >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>>>>>> >> From vladimir.x.ivanov at oracle.com Fri Jun 3 10:59:11 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 3 Jun 2016 13:59:11 +0300 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> Message-ID: (forgot to add hotspot-compiler-dev@) Best regards, Vladimir Ivanov On 6/3/16 1:48 PM, Vladimir Ivanov wrote: > > > On 6/3/16 7:11 AM, Vladimir Kozlov wrote: >> How about only fixing C1 to take into account the store (or not constant >> fold in such case) because it was allowed before JVMS-7? >> >> And file a separate issue for JVMS-7 conformance. It looks like it may >> have huge impact on performance and we are already very late in JDK 9 >> development to make such changes in rush. > > Yes, let's separate them (considering the difference in impact) and > align the JVM behavior with the JVMS separately. > > For now, disabling constant folding of static/instance field loads in > static/instance initializers should solve the immediate problem for > well-behaved (according to JVMS) programs. Also, such change should not > cause any performance regressions. > > Considering it is possible to update static final fields through > Reflection API, I don't see JVMS conformance issue (ability to update > final static fields outside of static initializer on bytecode level) as > a problem of the same level for JIT-compilers. It can be fixed as part > of aligning the JVM with JVMS (but still in JDK9). > > Best regards, > Vladimir Ivanov > >> >> Zoltan, what C2 does in such case? >> Tom, what Graal does in such case? >> >> The case is: >> >> https://bugs.openjdk.java.net/browse/JDK-8157181?focusedCommentId=13942824&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13942824 >> >> >> >> "While compiling bytecode @29, the C1 compiler assumes that the value of >> the _pyx0.self field has already been set in the class initializer >> method (as the class is initialized). The C1 compiler also >> assumes that the field will not change (as it is static final). >> Therefore, the C1 compiler omits reading the field _pyx0.self and passes >> the current value of the field ('null') to the >> org/python/core/Py.newCode() method called at bytecode @37. (The correct >> value would be 'this'.)" >> >> Thanks, >> Vladimir >> >> On 6/2/16 10:51 AM, Tom Rodriguez wrote: >>>>>> Therefore, in the current webrev, I've disabled folding of >>>>>> accesses to >>>>>> all non-stable fields. >>>>> Please do not do that, it will be a huge regression in term of perf >>>>> at least for the language runtimes i maintain >>>>> (and i suppose for Nashorn, JRuby or Groovy), Here are the perf >>>>> assertions i use routinely, >>>>> static final method handle is considered as constant, final fields >>>>> (even not static) of VM anonymous class is considered as truly final. >>>>> >>>> >>>> I fully understand your concerns. And thank you for sharing your >>>> asserts! >>> >>> The folding within the compiler should be handled differently since >>> the concerns are different and removing it will likely cause >>> invokeynamic performance to collapse. The compiler is only folding >>> final instance fields that are part of a chain of constants, so the >>> main concern is whether an object has been published before it?s been >>> fully constructed or if someone is going to use reflection to >>> modify a final field after the object has been published. The >>> trust_final_non_static_fields logic in ciField.cpp is calling out >>> classes which we control that shouldn?t violate those rules and that >>> are important for performance. So I think it should be left as is. >>> It really doesn?t relate to the issue at hand I think. >>> >>> Also you?ve removed folding of static final fields which would be a >>> very bad thing to do. >>> >>> ciField has some caching logic for _known_to_link_with_get/set and if >>> you are adding a ciMethod* argument you also need to cache the method >>> that was checked last time as well. >>> >>> tom >>> >>>> >>>> Let's see what others think about how to go about this problem. So >>>> far the following options were explored >>>> - bail out compilation of non-compliant methods; >>>> - enforce JVMS conformance for all classes and keep constant folding >>>> enabled; >>>> - enforce JVMS conformance only for classes with _major_version >=52 >>>> and completely disable constant folding. >>>> >>>> I'm not sure which option is the best. Also, there might be other >>>> options as well. >>>> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> >>>> >>>> >>>>>> We could relax that criteria, e.g., by disabling folding only for >>>>>> those >>>>>> field that were declared in a class with _major_version < 52. But it >>>>>> would be great if you could give me some feedback before I look into >>>>>> that. Thank you very much in advance! >>>>>> >>>>>> Updated webrev: >>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.05/ >>>>>> >>>>>> Testing: JPRT in progress. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>> R?mi >>>>> >>>>>>> Thank you and best regards, >>>>>>> >>>>>>> >>>>>>> Zoltan >>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>>> I agree with you, alternatively we can propose a more generic >>>>>>>>> fix (fix >>>>>>>>> the interpreter and the compilers as well). The fix would most >>>>>>>>> likely >>>>>>>>> affect field resolution in LinkResolver::resolve_field() around >>>>>>>>> here: >>>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>>>>>> inappropriate field access will propagate the exception to the >>>>>>>>> interpreter. Changing ciField::will_link() will most likely kill >>>>>>>>> (some) >>>>>>>>> compilations (if, e.g., fields are linked through >>>>>>>>> ciField::will_link()). >>>>>>>>> >>>>>>>>> I'd prefer to take the second option (changing field >>>>>>>>> resolution), but >>>>>>>>> there might be some disadvantages related to option I might be >>>>>>>>> overseeing. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Thank you! >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> >>>>>>>>> Zoltan >>>>>>>>> >>>>>>>>> >>>>>>>>>>> More details about the failure are here [3]. >>>>>>>>>>> >>>>>>>>>>> With the patch applied, the program always completes as it is >>>>>>>>>>> expected >>>>>>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed >>>>>>>>>>> (because we >>>>>>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>>>>>> >>>>>>>>>>> Here is the updated webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>>>>>> Bailing out the whole compilation in C2 is even less >>>>>>>>>> appropriate. It >>>>>>>>>> should generate an uncommon trap for such accesses instead (see >>>>>>>>>> Parse::do_field_access). >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Vladimir Ivanov >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>>>>>>> >>>>>>>>>> >>> From jon.masamitsu at oracle.com Fri Jun 3 15:57:03 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 3 Jun 2016 08:57:03 -0700 Subject: RFR (S) JDK-8153578,Default NewRatio is ignored when UseConcMarkSweepGC is used as GC algorithm In-Reply-To: <5745D089.8090003@oracle.com> References: <5717C5A9.1060406@oracle.com> <5717D9ED.2070907@oracle.com> <571802CF.7010000@oracle.com> <5745D089.8090003@oracle.com> Message-ID: <3e090650-48ee-ecc8-470f-c67ed56f781c@oracle.com> Joe, The intention of this code is to ergonomically select a small young gen size to keep young GC pauses small. The value of default value of CMSYoungGenPerWorker was chosen such that 1 GC worker could collect that large a young gen in an "acceptable" pause time. "acceptable", of course, is in the eye of the beholder and is probably out of date but it allows the user to pick a value such that the young gen gets larger as the ability to collect the young gen in that "acceptable" pause time scales up with the number of GC workers. Bottom line is that this is not a bug. It is an unfortunate conflict between the default behavior of how the other GC's use NewRatio and how CMS uses NewRatio. I think there is a similiar conflict in G1. I'll add this to the CR. Jon On 5/25/2016 9:19 AM, Joseph Provino wrote: > This is a simple change from MIN2 to MAX2 suggested by Jesper. > The code now matches the comment and seems to fix the problem. > > Webrev: http://cr.openjdk.java.net/~jprovino/8153578/webrev.01 > > thanks. > > joe > > On 4/20/2016 6:29 PM, Jon Masamitsu wrote: >> >> >> On 04/20/2016 12:35 PM, Jesper Wilhelmsson wrote: >>> Hi Joe, >>> >>> If I understand the bug description correctly the problem is that >>> NewSize becomes too small. According to the bug the VM ignores the >>> NewRatio setting. >>> >>> Your change removes the setting of MaxNewSize in the case where >>> NewSize has the default value. It's not obvious to me how that is >>> related to the bug. >>> >>> There is an if statement enclosing the code you are changing. It has >>> a comment that I find interesting: >>> >>> 1755 // If either MaxNewSize or NewRatio is set on the command line, >>> 1756 // assume the user is trying to set the size of the young gen. >>> 1757 if (FLAG_IS_DEFAULT(MaxNewSize) && FLAG_IS_DEFAULT(NewRatio)) { >>> >>> The interesting part is that the comment says "MaxNewSize OR >>> NewRatio" but the code says "MaxNewSize AND NewRatio". This could be >>> a typo in the comment, or it could be related to your bug. >>> >>> I don't think the fix here is to ignore the calculated >>> preferred_max_new_size, but rather to figure out why it has the >>> wrong value. preferred_max_new_size is calculated a few lines up, >>> and it is based on NewRatio. The number of threads seems to be >>> involved as well. Should it be? Usually things based on the number >>> of threads tend to be wrong... >> >> The intent of this code was to control the young pause times by >> limiting the size of >> the young gen. The preferred size scaling with >> >> young_gen_per_worker * ParallelGCThreads >> >> was meant to take into account the fact you could have approximately the >> same pauses with larger heaps as the number of GC workers increases. >> I didn't add this code but I'm pretty sure it was added as a result of >> customer interaction. >> >> Jon >> >>> >>> 1748 MIN2(max_heap/(NewRatio+1), >>> ScaleForWordSize(young_gen_per_worker * ParallelGCThreads)); >>> >>> young_gen_per_worker is CMSYoungGenPerWorker which defaults to >>> things like 16M or 64M. ParallelGCThreads is usually just a handful, >>> 8 on my machine. Since we take the smallest number of this thread >>> based thing and the NewRatio calculation, I would guess the threads >>> will limit the MaxNewSize quite a lot. I wonder if this isn't the >>> bug you are looking for. It would make more sense to me if it was >>> MAX of the two instead of MIN. You should probably consult whoever >>> wrote this code. >>> >>> /Jesper >>> >>> >>> Den 20/4/16 kl. 20:08, skrev Joseph Provino: >>>> Please review this tiny change. It only affects ParNew. Are there >>>> any >>>> unintended consequences? >>>> >>>> Passes JPRT. >>>> >>>> CR: JDK-8153578 Default NewRatio is ignored when UseConcMarkSweepGC >>>> is used as >>>> GC algorithm >>>> >>>> Webrev: http://cr.openjdk.java.net/~jprovino/8153578/webrev.00 >>>> >>>> >> > From timo.kinnunen at gmail.com Thu Jun 2 18:19:50 2016 From: timo.kinnunen at gmail.com (timo.kinnunen at gmail.com) Date: Thu, 2 Jun 2016 20:19:50 +0200 Subject: RFR 8158039 VarHandle float/double field/array access shouldsupport CAS/set/add atomics In-Reply-To: <89EC54E9-2BC1-4994-BF72-99FC20F9729C@oracle.com> References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> <89EC54E9-2BC1-4994-BF72-99FC20F9729C@oracle.com> Message-ID: <575078c8.45271c0a.7e9a9.ffffebf5@mx.google.com> Hi, Regarding x86, I can induce an infinite loop in getAndAddFloat on my computer if I simulate getFloatVolatile with the following implementation: static float getFloatVolatile(Object o, long offset) { return -0.0f + Float.intBitsToFloat(((int[]) o)[(int) offset]); } Note the added sum with -0.0f. This simulates the case where storing or subsequently reading a local variable changes the NaN value. With this implementation the first (largest) NaN to hang is 0xffbfffff. Some other curiosities: Adding -0.0 leaves all non-NaN floats with identical raw bits, including the negative zero. This isn?t the case if positive zero is used. When positive zero was used every non-NaN except negative zero remained same. This method changes 8,388,606 of the NaNs and leaves 8,388,608 the same. -- Have a nice day, Timo Sent from Mail for Windows 10 From: Paul Sandoz Sent: Thursday, June 2, 2016 17:26 To: Vladimir Ivanov Cc: jdk9-dev; hotspot-dev developers Subject: Re: RFR 8158039 VarHandle float/double field/array access shouldsupport CAS/set/add atomics > On 2 Jun 2016, at 14:55, Vladimir Ivanov wrote: > > Paul, > > Leaving practicality aspect of float/double API aside... > >> I am concerned that the CAS loops could in some cases loop without termination: > > Can you elaborate? I don't see how it is possible with the proposed patch. > The key aspect is in the JavaDoc snippet in my previous email. > On Float.intBitsToFloat: > > *

Note that this method may not be able to return a > * {@code float} NaN with exactly same bit pattern as the > * {@code int} argument. IEEE 754 distinguishes between two > * kinds of NaNs, quiet NaNs and signaling NaNs. The > * differences between the two kinds of NaN are generally not > * visible in Java. Arithmetic operations on signaling NaNs turn > * them into quiet NaNs with a different, but often similar, bit > * pattern. However, on some processors merely copying a > * signaling NaN also performs that conversion. In particular, > * copying a signaling NaN to return it to the calling method may > * perform this conversion. So {@code intBitsToFloat} may > * not be able to return a {@code float} with a signaling NaN > * bit pattern. Consequently, for some {@code int} values, > * {@code floatToRawIntBits(intBitsToFloat(start))} may > * not equal {@code start}. Moreover, which > * particular bit patterns represent signaling NaNs is platform > * dependent; although all NaN bit patterns, quiet or signaling, > * must be in the NaN range identified above. > I dunno if it can happen on x86 [*], but from reading the above I presume it could theoretically happen on some other hardware (what exactly i do not know). Note that the loaded float value is passed to the weakCompareAndSwapFloatVolatile method as an argument. IIUC that might trigger the conversion from a signalling NaN to a quiet NaN, subtly changing the bits of the expected value that was loaded. Paul. [*] Here is a simple program to induce a different on x86 (at least on my machine). To induce that i am adding 0.0f to the float value. public class AllTheNaNs { public static void main(String[] args) { for (long bits = 0x7f800001; bits <= 0x7fffffff; bits++) { testBits((int) bits); } for (long bits = 0xff800001; bits <= 0xffffffff; bits++) { testBits((int) bits); } } static void testBits(int vbits) { float v = Float.intBitsToFloat(vbits); assert Float.isNaN(v); float vv = id(v); assert Float.isNaN(vv); int vvbits = Float.floatToRawIntBits(vv); if (vvbits != vbits) { System.out.println(Integer.toHexString(vbits) + " " + Integer.toHexString(vvbits) + " " + Float.valueOf(v).equals(Float.valueOf(vv)) + " " + Float.compare(v, vv)); } } static float id(float f) { return f + 0.0f; } } > Unless getFloatVolatile() or weakCompareAndSwapFloatVolatile() change the original value, it should not happen. And both functions preserve float value bits intact: > > + @ForceInline > + public final boolean weakCompareAndSwapFloatVolatile(Object o, long offset, > + float expected, > + float x) { > + return weakCompareAndSwapIntVolatile(o, offset, > + Float.floatToRawIntBits(expected), > + Float.floatToRawIntBits(x)); > + } > > Float.floatToRawIntBits() makes it safe, but with Float.intBitsToFloat() used infinite looping can happen for NaNs. > > Best regards, > Vladimir Ivanov > From volker.simonis at gmail.com Mon Jun 6 13:59:03 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 6 Jun 2016 15:59:03 +0200 Subject: RFR(XS): 8158763 : --disable-hotspot-gtest not working on Solaris Message-ID: Hi, I'd like to get the following tiny bug fix into jdk9-dev. What's the current procedure to get this change approved? http://cr.openjdk.java.net/~simonis/webrevs/2016/8158763/ https://bugs.openjdk.java.net/browse/JDK-8158763 On Solaris, the configure test for libstlport.so.1 isn't disabled by --disable-hotspot-gtest. So, if libstlport.so.1 isn't present, the build will break during configuration even if we set --disable-hotspot-gtest. The fix is trivial - just guard the test for libstlport.so.1 by "x$BUILD_GTEST" = "xtrue". The fix also adds an alternative location for libstlport.so.1 (from SS12u3) to keep the sources compilable with SS12u3. Thank you and best regards, Volker From haozhun.jin at gmail.com Mon Jun 6 16:58:40 2016 From: haozhun.jin at gmail.com (Haozhun Jin) Date: Mon, 6 Jun 2016 09:58:40 -0700 Subject: Deoptimization taking up most CPU cycles Message-ID: We are running a distributed system of about 30 hosts. We observe that a few (~10%) of the hosts become unbearably slow after running for ~3 weeks (10-50X slower compared to hosts the are healthy). Restart of LXC container where JVM runs in on the unhealthy hosts would cure them. (Our system is configured in a way that restarting JVM alone is impossible.) Our system generates byte code and load them on the fly. But we have caches that keep generated code around if code for the same work need to be generated again. We believe this is a JVM problem because we see that a significant amount of time is spent in VM deopt logic once the host becomes very slow. An excerpt of the perf result is at the end of this email. Since we see de-opt, we wondered if JVM is repeatedly optimizing and deoptimizing back and forth. We used `jstat -printcompilation ` to compare the number of compilations before and after we run a new piece of work. (We didn't generate new code for the work. Class comes from cache.) The number doens't change. If we slightly tweak the work to force a cache miss and generate new code, the compile count will increase. But its performance remains slow. (I made 10 tries. Each generate new classes. In one of them, 1 of the 4 unhealthy hosts finishes its work in reasonable time. But all 4 unhealthy hosts remain slow in the other 9 tries. For that particular work that triggered one of the hosts to finish in reasonable time, the same work will consistently be fast on that particular host.) We didn't turn on de-opt logging when we started JVM. But we were able to get them through GDB. Below is the 2nd, 3rd, 5th, 6th, and 7th argument of Events::log_deopt_message. $34746 = 0x7f7a7cc67bf0 "Uncommon trap: reason=%s action=%s pc=0x%016lx method=%s @ %d" $34747 = 0x7f7a7cc67905 "unstable_if" $34748 = 0x7f7a7cc4d0ba "none" $34749 = 0x7f7a14f422c0 "com_facebook_presto_$gen_PageProcessor_440742.filter(Lcom/facebook/presto/spi/ConnectorSession;Lcom/facebook/presto/spi/block/Block;Lcom/facebook/presto/spi/block/Block;Lcom/facebook/presto/spi/block/"... $34750 = 450 You can find the class referenced above at https://gist.github.com/haozhun/920b28932ef253b55f3f497e2d187286 along with its text representation. To summarize, at bci 450, the branch predicts ~5% one way, ~95% the rest. When one branch is taken, the same branch will most likely continue to be taken for the same branch for a while. My questions: * Is there anything else we could look at while the process is still running? (we have kept 3 of them around, for now) * Are there any options we can turn on next time we start the process that could help troubleshoot this when it happens again? * Is the behavior we?re seeing, namely, repeated uncommon traps for the same method for ?unstable if? with no apparent deoptimization/further re-compilations normal? * For my understanding, what does action ?none? mean for ?unstable if?? Java version: java version "1.8.0_72" Java(TM) SE Runtime Environment (build 1.8.0_72-b15) Java HotSpot(TM) 64-Bit Server VM (build 25.72-b15, mixed mode) Excerpt of JVM options: -server -Xmx120G -Xms120G -Xss2048k -XX:+PreserveFramePointer -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:G1MaxNewSizePercent=20 -XX:G1HeapRegionSize=32M -XX:+ExplicitGCInvokesConcurrent -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintReferenceGC -XX:+PrintGCCause -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+PrintClassHistogramAfterFullGC -XX:+PrintClassHistogramBeforeFullGC -XX:+PrintAdaptiveSizePolicy -XX:+PrintSafepointStatistics -XX:-OmitStackTraceInFastThrow -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -XX:-UseBiasedLocking -XX:ReservedCodeCacheSize=512m Excerpt of perf reuslt: Samples: 97K of event 'cycles', Event count (approx.): 45248264720 Overhead Command Shared Object Symbol + 4.99% swapper [kernel.kallsyms] [k] intel_idle - 4.40% presto-facebook libc-2.12.so [.] _IO_strn_overflow _IO_strn_overflow _IO_default_xsputn vfprintf _IO_vsnprintf Events::log_deopt_message Deoptimization::uncommon_trap_inner Deoptimization::uncommon_trap UncommonTrapBlob - 4.30% presto-facebook libc-2.12.so [.] vfprintf vfprintf - _IO_vsnprintf + 60.98% Events::log_deopt_message + 39.02% Events::log + 3.93% presto-facebook perf-994763.map [.] Interpreter - 3.55% presto-facebook libjvm.so [.] vframeArray::allocate vframeArray::allocate Deoptimization::fetch_unroll_info_helper UncommonTrapBlob - 3.40% presto-facebook libc-2.12.so [.] _IO_default_xsputn - _IO_default_xsputn - 93.51% vfprintf - _IO_vsnprintf + 83.39% Events::log_deopt_message + 16.61% Events::log + 6.49% _IO_padn - 3.25% presto-facebook libc-2.12.so [.] _int_malloc _int_malloc malloc - os::malloc + 41.90% Deoptimization::fetch_unroll_info_helper + 24.60% CHeapObj<(MemoryType)6>::operator new + 19.49% vframeArray::allocate + 14.01% CHeapObj<(MemoryType)7>::operator new - 2.85% presto-facebook libc-2.12.so [.] malloc malloc - os::malloc + 41.94% Deoptimization::fetch_unroll_info_helper + 21.75% vframeArray::allocate + 19.94% CHeapObj<(MemoryType)7>::operator new + 16.37% CHeapObj<(MemoryType)6>::operator new - 2.34% presto-facebook libc-2.12.so [.] malloc_consolidate malloc_consolidate _int_malloc malloc - os::malloc + 64.23% vframeArray::allocate + 35.77% Deoptimization::fetch_unroll_info_helper - 2.04% presto-facebook libjvm.so [.] resource_allocate_bytes - resource_allocate_bytes + 25.88% vframeArrayElement::fill_in + 20.02% StackValue::create_stack_value + 19.86% ScopeValue::read_from + 8.19% GenericGrowableArray::raw_allocate + 3.79% nmethod::scope_desc_at + 3.69% compiledVFrame::monitors + 3.55% OopMapSet::update_register_map + 3.30% ScopeDesc::decode_scope_values + 2.05% compiledVFrame::locals + 2.04% compiledVFrame::expressions + 1.87% vframe::new_vframe + 1.52% ScopeDesc::decode_body + 1.05% Symbol::as_C_string + 0.99% Deoptimization::fetch_unroll_info_helper + 0.73% Symbol::as_klass_external_name + 0.67% DataLayout::data_in - 1.70% presto-facebook libc-2.12.so [.] _int_free _int_free - Deoptimization::cleanup_deopt_info From haozhun.jin at gmail.com Sat Jun 4 00:08:42 2016 From: haozhun.jin at gmail.com (Haozhun Jin) Date: Fri, 3 Jun 2016 17:08:42 -0700 Subject: Deoptimization taking up most CPU cycles Message-ID: We are running a distributed system of about 30 hosts. We observe that a few (~10%) of the hosts become unbearably slow after running for ~3 weeks (10-50X slower compared to hosts the are healthy). Restart of LXC container where JVM runs in on the unhealthy hosts would cure them. (Our system is configured in a way that restarting JVM alone is impossible.) Our system generates byte code and load them on the fly. But we have caches that keep generated code around if code for the same work need to be generated again. We believe this is a JVM problem because we see that a significant amount of time is spent in VM deopt logic once the host becomes very slow. An excerpt of the perf result is at the end of this email. Since we see de-opt, we wondered if JVM is repeatedly optimizing and deoptimizing back and forth. We used `jstat -printcompilation ` to compare the number of compilations before and after we run a new piece of work. (We didn't generate new code for the work. Class comes from cache.) The number doens't change. If we slightly tweak the work to force a cache miss and generate new code, the compile count will increase. But its performance remains slow. (I made 10 tries. Each generate new classes. In one of them, 1 of the 4 unhealthy hosts finishes its work in reasonable time. But all 4 unhealthy hosts remain slow in the other 9 tries. For that particular work that triggered one of the hosts to finish in reasonable time, the same work will consistently be fast on that particular host.) We didn't turn on de-opt logging when we started JVM. But we were able to get them through GDB. Below is the 2nd, 3rd, 5th, 6th, and 7th argument of Events::log_deopt_message. $34746 = 0x7f7a7cc67bf0 "Uncommon trap: reason=%s action=%s pc=0x%016lx method=%s @ %d" $34747 = 0x7f7a7cc67905 "unstable_if" $34748 = 0x7f7a7cc4d0ba "none" $34749 = 0x7f7a14f422c0 "com_facebook_presto_$gen_PageProcessor_440742.filter(Lcom/facebook/presto/spi/ConnectorSession;Lcom/facebook/presto/spi/block/Block;Lcom/facebook/presto/spi/block/Block;Lcom/facebook/presto/spi/block/"... $34750 = 450 You can find the class referenced above at https://gist.github.com/haozhun/920b28932ef253b55f3f497e2d187286 along with its text representation. To summarize, at bci 450, the branch predicts ~5% one way, ~95% the rest. When one branch is taken, the same branch will most likely continue to be taken for the same branch for a while. My questions: * Is there anything else we could look at while the process is still running? (we have kept 3 of them around, for now) * Are there any options we can turn on next time we start the process that could help troubleshoot this when it happens again? * Is the behavior we?re seeing, namely, repeated uncommon traps for the same method for ?unstable if? with no apparent deoptimization/further re-compilations normal? * For my understanding, what does action ?none? mean for ?unstable if?? Java version: java version "1.8.0_72" Java(TM) SE Runtime Environment (build 1.8.0_72-b15) Java HotSpot(TM) 64-Bit Server VM (build 25.72-b15, mixed mode) Excerpt of JVM options: -server -Xmx120G -Xms120G -Xss2048k -XX:+PreserveFramePointer -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:G1MaxNewSizePercent=20 -XX:G1HeapRegionSize=32M -XX:+ExplicitGCInvokesConcurrent -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintReferenceGC -XX:+PrintGCCause -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+PrintClassHistogramAfterFullGC -XX:+PrintClassHistogramBeforeFullGC -XX:+PrintAdaptiveSizePolicy -XX:+PrintSafepointStatistics -XX:-OmitStackTraceInFastThrow -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -XX:-UseBiasedLocking -XX:ReservedCodeCacheSize=512m Excerpt of perf reuslt: Samples: 97K of event 'cycles', Event count (approx.): 45248264720 Overhead Command Shared Object Symbol + 4.99% swapper [kernel.kallsyms] [k] intel_idle - 4.40% presto-facebook libc-2.12.so [.] _IO_strn_overflow _IO_strn_overflow _IO_default_xsputn vfprintf _IO_vsnprintf Events::log_deopt_message Deoptimization::uncommon_trap_inner Deoptimization::uncommon_trap UncommonTrapBlob - 4.30% presto-facebook libc-2.12.so [.] vfprintf vfprintf - _IO_vsnprintf + 60.98% Events::log_deopt_message + 39.02% Events::log + 3.93% presto-facebook perf-994763.map [.] Interpreter - 3.55% presto-facebook libjvm.so [.] vframeArray::allocate vframeArray::allocate Deoptimization::fetch_unroll_info_helper UncommonTrapBlob - 3.40% presto-facebook libc-2.12.so [.] _IO_default_xsputn - _IO_default_xsputn - 93.51% vfprintf - _IO_vsnprintf + 83.39% Events::log_deopt_message + 16.61% Events::log + 6.49% _IO_padn - 3.25% presto-facebook libc-2.12.so [.] _int_malloc _int_malloc malloc - os::malloc + 41.90% Deoptimization::fetch_unroll_info_helper + 24.60% CHeapObj<(MemoryType)6>::operator new + 19.49% vframeArray::allocate + 14.01% CHeapObj<(MemoryType)7>::operator new - 2.85% presto-facebook libc-2.12.so [.] malloc malloc - os::malloc + 41.94% Deoptimization::fetch_unroll_info_helper + 21.75% vframeArray::allocate + 19.94% CHeapObj<(MemoryType)7>::operator new + 16.37% CHeapObj<(MemoryType)6>::operator new - 2.34% presto-facebook libc-2.12.so [.] malloc_consolidate malloc_consolidate _int_malloc malloc - os::malloc + 64.23% vframeArray::allocate + 35.77% Deoptimization::fetch_unroll_info_helper - 2.04% presto-facebook libjvm.so [.] resource_allocate_bytes - resource_allocate_bytes + 25.88% vframeArrayElement::fill_in + 20.02% StackValue::create_stack_value + 19.86% ScopeValue::read_from + 8.19% GenericGrowableArray::raw_allocate + 3.79% nmethod::scope_desc_at + 3.69% compiledVFrame::monitors + 3.55% OopMapSet::update_register_map + 3.30% ScopeDesc::decode_scope_values + 2.05% compiledVFrame::locals + 2.04% compiledVFrame::expressions + 1.87% vframe::new_vframe + 1.52% ScopeDesc::decode_body + 1.05% Symbol::as_C_string + 0.99% Deoptimization::fetch_unroll_info_helper + 0.73% Symbol::as_klass_external_name + 0.67% DataLayout::data_in - 1.70% presto-facebook libc-2.12.so [.] _int_free _int_free - Deoptimization::cleanup_deopt_info From aleksey.shipilev at oracle.com Mon Jun 6 17:34:55 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 6 Jun 2016 20:34:55 +0300 Subject: Deoptimization taking up most CPU cycles In-Reply-To: References: Message-ID: <5755B43F.1040400@oracle.com> On 06/06/2016 07:58 PM, Haozhun Jin wrote: > $34746 = 0x7f7a7cc67bf0 "Uncommon trap: reason=%s action=%s pc=0x%016lx > method=%s @ %d" > $34747 = 0x7f7a7cc67905 "unstable_if" > $34748 = 0x7f7a7cc4d0ba "none" > $34749 = 0x7f7a14f422c0 > "com_facebook_presto_$gen_PageProcessor_440742.filter(Lcom/facebook/presto/spi/ConnectorSession;Lcom/facebook/presto/spi/block/Block;Lcom/facebook/presto/spi/block/Block;Lcom/facebook/presto/spi/block/"... > $34750 = 450 Looking at HotSpot source code, action="None" seems to mean: enum DeoptAction { Action_none, // just interpret, do not invalidate nmethod ...which probably means you end up calling cold branch via trap to interpreter always, and die trashing compiled->trap->interpreter transitions. I see the we emit with Action_reinterpret for Reason_unstable_if: void Parse::adjust_map_after_if(...) { ... if (path_is_suitable_for_uncommon_trap(prob)) { repush_if_args(); uncommon_trap(Deoptimization::Reason_unstable_if, Deoptimization::Action_reinterpret, NULL, (is_fallthrough ? "taken always" : "taken never")); return; } ...but in the downcall: void GraphKit::uncommon_trap(...) { ... case Deoptimization::Action_reinterpret: // Temporary fix for 6529811 to allow virtual calls to be sure they // get the chance to go from mono->bi->mega if (!keep_exact_action && Deoptimization::trap_request_index(trap_request) < 0 && too_many_recompiles(reason)) { // This BCI is causing too many recompilations. if (C->log() != NULL) { C->log()->elem("observe that='trap_action_change' reason='%s' from='%s' to='none'", Deoptimization::trap_reason_name(reason), Deoptimization::trap_action_name(action)); } action = Deoptimization::Action_none; trap_request = Deoptimization::make_trap_request(reason, action); The comment leads to: https://bugs.openjdk.java.net/browse/JDK-6529811 ...which manifestation looks suspiciously like the issue you are describing. For one, I wonder why do we overwrite with Action_none, while safer alternative would be deoptimize hard on too many recompiles and run in interpreter with Action_make_not_compilable. > * Are there any options we can turn on next time we start the process that > could help troubleshoot this when it happens again? I would guess -XX:+LogCompilation -XX:LogFile=somewhere.log would be nice to have to better diagnose cases like these. But if you are under the uncommon_trap storm, that file can get rather large. Thanks, -Aleksey From cnewland at chrisnewland.com Mon Jun 6 20:35:15 2016 From: cnewland at chrisnewland.com (Chris Newland) Date: Mon, 6 Jun 2016 21:35:15 +0100 Subject: Deoptimization taking up most CPU cycles In-Reply-To: <5755B43F.1040400@oracle.com> References: <5755B43F.1040400@oracle.com> Message-ID: <88907e8d858d34758b42bb26abc9166e.squirrel@excalibur.xssl.net> fyi A very similar problem was reported on hotspot-compiler-dev this week: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-June/023278.html In response to that thread I've just pushed some code in JITWatch for visualising sweeps and the point at which compilation gets disabled [1]. Hope that's useful. Cheers, Chris [1] https://github.com/AdoptOpenJDK/jitwatch On Mon, June 6, 2016 18:34, Aleksey Shipilev wrote: > On 06/06/2016 07:58 PM, Haozhun Jin wrote: > >> $34746 = 0x7f7a7cc67bf0 "Uncommon trap: reason=%s action=%s pc=0x%016lx >> method=%s @ %d" $34747 = 0x7f7a7cc67905 "unstable_if" >> $34748 = 0x7f7a7cc4d0ba "none" >> $34749 = 0x7f7a14f422c0 >> "com_facebook_presto_$gen_PageProcessor_440742.filter(Lcom/facebook/pres >> to/spi/ConnectorSession;Lcom/facebook/presto/spi/block/Block;Lcom/faceb >> ook/presto/spi/block/Block;Lcom/facebook/presto/spi/block/"... $34750 = >> 450 >> > > Looking at HotSpot source code, action="None" seems to mean: > > > enum DeoptAction { Action_none, // just interpret, do not invalidate > nmethod > > ...which probably means you end up calling cold branch via trap to > interpreter always, and die trashing compiled->trap->interpreter > transitions. > > I see the we emit with Action_reinterpret for Reason_unstable_if: > > > void Parse::adjust_map_after_if(...) { ... > if (path_is_suitable_for_uncommon_trap(prob)) { repush_if_args(); > uncommon_trap(Deoptimization::Reason_unstable_if, > Deoptimization::Action_reinterpret, > NULL, > (is_fallthrough ? "taken always" : "taken never")); > return; } > > > ...but in the downcall: > > > void GraphKit::uncommon_trap(...) { ... > case Deoptimization::Action_reinterpret: // Temporary fix for 6529811 to > allow virtual calls to be sure they // get the chance to go from > mono->bi->mega if (!keep_exact_action && > Deoptimization::trap_request_index(trap_request) < 0 && > too_many_recompiles(reason)) { // This BCI is causing too many > recompilations. if (C->log() != NULL) { C->log()->elem("observe > that='trap_action_change' reason='%s' from='%s' to='none'", > Deoptimization::trap_reason_name(reason), > Deoptimization::trap_action_name(action)); > } > action = Deoptimization::Action_none; trap_request = > Deoptimization::make_trap_request(reason, action); > > > The comment leads to: > https://bugs.openjdk.java.net/browse/JDK-6529811 > > > ...which manifestation looks suspiciously like the issue you are > describing. For one, I wonder why do we overwrite with Action_none, while > safer alternative would be deoptimize hard on too many recompiles and run > in interpreter with Action_make_not_compilable. > > >> * Are there any options we can turn on next time we start the process >> that could help troubleshoot this when it happens again? > > I would guess -XX:+LogCompilation -XX:LogFile=somewhere.log would be > nice to have to better diagnose cases like these. But if you are under the > uncommon_trap storm, that file can get rather large. > > Thanks, > -Aleksey > > > From joe.darcy at oracle.com Tue Jun 7 00:47:18 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 06 Jun 2016 17:47:18 -0700 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> Message-ID: <57561996.4000501@oracle.com> Hello, Catching up on email, there are several different notions on floating-point equality one might want to use. [1] One notion is the built-in "==" operator on float and double. This has the wrinkle of not defining an equivalence relation because of NaN values (not reflexive) and signed zeros (distinguishable values compare as equal). When I write floating-point tests, I'll use a notion of equality close to Float.compare(x, y) == 0 which means all NaN values are treated as the same and Float.compare(NaN, NaN) == 0 is true. This also distinguishes the signed zeros from each other. So comparing based on the non-raw bitwise conversion can give resonable semantics, at the cost of not preserving any payload stored in the NaN significand. HTH, -Joe [1] "Notions of Floating-Point Equality ," https://blogs.oracle.com/darcy/entry/notions_of_floating_point_equality On 6/2/2016 1:34 AM, Paul Sandoz wrote: >> On 2 Jun 2016, at 09:13, David Holmes wrote: >> >> On 2/06/2016 1:24 AM, Paul Sandoz wrote: >>> (Please note this work is or will be covered with FC exception) >>> >>> Hi, >>> >>> Please review the VarHandles/Unsafe support for atomic ops on double/float fields/arrays. >> I think this is misguided. If the user wants CAS for float/double they can do the conversion to int/long in a context where they know that conversion makes sense and where they can deal with NaNs appropriately. >> > I would still like to support some clearly defined default behaviour if at all possible, since this is not easy to get right so we can add some value here. The user can use int/long if that behaviour is not suitable. > > >> At a minimum the fact this deals with raw bit patterns not semantic values needs to be exposed somehow. ie the handling of NaN needs to be explicit. >> > Yes, it?s multiple NaN values that collapse to a single NaN value. > > It would be good if our resident floating point expert Mr. Joe Darcy could chime in this respect. > > On Float.intBitsToFloat: > > *

Note that this method may not be able to return a > * {@code float} NaN with exactly same bit pattern as the > * {@code int} argument. IEEE 754 distinguishes between two > * kinds of NaNs, quiet NaNs and signaling NaNs. The > * differences between the two kinds of NaN are generally not > * visible in Java. Arithmetic operations on signaling NaNs turn > * them into quiet NaNs with a different, but often similar, bit > * pattern. However, on some processors merely copying a > * signaling NaN also performs that conversion. In particular, > * copying a signaling NaN to return it to the calling method may > * perform this conversion. So {@code intBitsToFloat} may > * not be able to return a {@code float} with a signaling NaN > * bit pattern. Consequently, for some {@code int} values, > * {@code floatToRawIntBits(intBitsToFloat(start))} may > * not equal {@code start}. Moreover, which > * particular bit patterns represent signaling NaNs is platform > * dependent; although all NaN bit patterns, quiet or signaling, > * must be in the NaN range identified above. > > > > I am concerned that the CAS loops could in some cases loop without termination: > > @ForceInline > public final float getAndAddFloat(Object o, long offset, float delta) { > float v; > do { > v = getFloatVolatile(o, offset); > } while (!weakCompareAndSwapFloatVolatile(o, offset, v, v + delta)); > return v; > } > > > I think this should be: > > @ForceInline > public final float getAndAddFloat(Object o, long offset, float delta) { > int expectedBits; > float v; > do { > expectedBits = getIntVolatile(o, offset); > v = Float.intBitsToFloat(bits); // May not preserve a NaN value with the same bit pattern as expectedBits > } while (!weakCompareAndSwapIntVolatile(o, offset, expectedBits, Float.floatToRawIntBits(v + delta))); > return v; > } > > and likewise for the atomic get-and-set methods. > > Paul. > >> David >> ----- >> >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ >>> >>> These patches are based on those of for sub-word CAS >>> >>> https://bugs.openjdk.java.net/browse/JDK-8157726 >>> http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/ >>> http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/ >>> >>> And the two patches combined expand the support of fields/arrays. >>> >>> >>> New float/double CAS methods are added to Unsafe that defer to int/long equivalents. Then the other atomic methods are built from weak CAS loops. >>> >>> No changes are required to HotSpot, but changes are required to the Unsafe tests in the hotspot repository. >>> >>> In general the changes to VHs and tests are minimal since it is triggered from changes to the generating scripts that now include float/double into the CAS category. >>> >>> There are some minor specification changes and a CCC has been initiated. >>> >>> JPRT tests results show no relevant failures for hotspot and core test sets. >>> >>> Thanks, >>> Paul. >>> From haozhun.jin at gmail.com Tue Jun 7 02:05:29 2016 From: haozhun.jin at gmail.com (Haozhun Jin) Date: Mon, 6 Jun 2016 19:05:29 -0700 Subject: Deoptimization taking up most CPU cycles In-Reply-To: <5755B43F.1040400@oracle.com> References: <5755B43F.1040400@oracle.com> Message-ID: Thank you, Aleksey. Thank you, Chris. On Mon, Jun 6, 2016 at 10:34 AM, Aleksey Shipilev < aleksey.shipilev at oracle.com> wrote: > void GraphKit::uncommon_trap(...) { > ... > case Deoptimization::Action_reinterpret: > // Temporary fix for 6529811 to allow virtual calls to be sure they > // get the chance to go from mono->bi->mega > if (!keep_exact_action && > Deoptimization::trap_request_index(trap_request) < 0 && > too_many_recompiles(reason)) { > // This BCI is causing too many recompilations. > if (C->log() != NULL) { > C->log()->elem("observe that='trap_action_change' reason='%s' > from='%s' to='none'", > Deoptimization::trap_reason_name(reason), > Deoptimization::trap_action_name(action)); > } > action = Deoptimization::Action_none; > trap_request = Deoptimization::make_trap_request(reason, action); > > The comment leads to: > https://bugs.openjdk.java.net/browse/JDK-6529811 > > ...which manifestation looks suspiciously like the issue you are > describing. For one, I wonder why do we overwrite with Action_none, > while safer alternative would be deoptimize hard on too many recompiles > and run in interpreter with Action_make_not_compilable. > I took a look at how `Compile::too_many_recompiles` is implemented after reading Alekshey's reply. But I'm new to hotspot source code. And I don't think I understood it. In `Compile::too_many_recompiles`, a comment reads "Too many recompiles globally, and we have seen this sort of trap. Use cumulative decompile_count, not just md->decompile_count". Does this mean there is a VM-wide global counter that will be eventually hit, and cause recompilation to stop VM-wide? This sounds unlikely to me. But I can't figure out what it actually means. I'm bringing this up because the degraded performance I observed is not specific to a class/method. I mentioned this in my previous email. But I should have emphasize it. The performance is as bad if I slightly alter the workload to force my program to generate a different class to execute the work. This newly-generated class implements the same interface, but has different class name. I assume this would be considered different methods by the compiler. However, the newly-generated class hits the unstable_if/action_none problem right away. For comparison, the same work runs perfectly fine on the healthy hosts. (4 out of 30 hosts were seeing this performance problem now. But the other 26 were fine.) If I restart JVM on one of the unhealthy hosts, the performance on the restarted JVM will be cured and become as fast as the healthy hosts. This suggests that there's some sort of global state that the JVM gets into that results in degraded performance for new classes/methods. Maybe I missed it, but the previous reply seems to only addressed the question of how one particular class/method got into a bad state. Having a global state that stop future methods from being optimized seems to be a different problem? From david.holmes at oracle.com Tue Jun 7 02:28:29 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 7 Jun 2016 12:28:29 +1000 Subject: RFR(XS): 8158763 : --disable-hotspot-gtest not working on Solaris In-Reply-To: References: Message-ID: Hi Volker, On 6/06/2016 11:59 PM, Volker Simonis wrote: > Hi, > > I'd like to get the following tiny bug fix into jdk9-dev. What's the > current procedure to get this change approved? No approvals needed for bug fixes until RDP1 later in the year. Only enhancements need approval post FC and that process has not yet been setup. > http://cr.openjdk.java.net/~simonis/webrevs/2016/8158763/ > https://bugs.openjdk.java.net/browse/JDK-8158763 > > On Solaris, the configure test for libstlport.so.1 isn't disabled by > --disable-hotspot-gtest. So, if libstlport.so.1 isn't present, the > build will break during configuration even if we set > --disable-hotspot-gtest. > > The fix is trivial - just guard the test for libstlport.so.1 by > "x$BUILD_GTEST" = "xtrue". > > The fix also adds an alternative location for libstlport.so.1 (from > SS12u3) to keep the sources compilable with SS12u3. This looks fine to me and I can sponsor it (need to regenerate closed generated-configure.sh). I'd also prefer to see this go into jdk9/hs if that is okay? Thanks, David ----- > > Thank you and best regards, > Volker > From volker.simonis at gmail.com Tue Jun 7 07:07:38 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 7 Jun 2016 09:07:38 +0200 Subject: RFR(XS): 8158763 : --disable-hotspot-gtest not working on Solaris In-Reply-To: References: Message-ID: On Tue, Jun 7, 2016 at 4:28 AM, David Holmes wrote: > Hi Volker, > > On 6/06/2016 11:59 PM, Volker Simonis wrote: >> >> Hi, >> >> I'd like to get the following tiny bug fix into jdk9-dev. What's the >> current procedure to get this change approved? > > > No approvals needed for bug fixes until RDP1 later in the year. Only > enhancements need approval post FC and that process has not yet been setup. > Ah, good to know. >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8158763/ >> https://bugs.openjdk.java.net/browse/JDK-8158763 >> >> On Solaris, the configure test for libstlport.so.1 isn't disabled by >> --disable-hotspot-gtest. So, if libstlport.so.1 isn't present, the >> build will break during configuration even if we set >> --disable-hotspot-gtest. >> >> The fix is trivial - just guard the test for libstlport.so.1 by >> "x$BUILD_GTEST" = "xtrue". >> >> The fix also adds an alternative location for libstlport.so.1 (from >> SS12u3) to keep the sources compilable with SS12u3. > > > This looks fine to me and I can sponsor it (need to regenerate closed > generated-configure.sh). I'd also prefer to see this go into jdk9/hs if that > is okay? > Thanks a lot David. Pushing it to jdk9/hs first is fine for me. Regards, Volker > Thanks, > David > ----- > > >> >> Thank you and best regards, >> Volker >> > From Leonid.Mesnik at oracle.com Tue Jun 7 09:03:35 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Tue, 7 Jun 2016 12:03:35 +0300 Subject: RFR(S): 8154209: Remove client VM from default JIB profile on windows-x86 and linux-x86 In-Reply-To: <2fdb4a87-54e6-5fce-8feb-f093cb3f24d2@oracle.com> References: <570FC852.10808@oracle.com> <57149250.10008@oracle.com> <5717F77D.6080308@oracle.com> <571871E6.5050306@oracle.com> <574747CB.8000103@oracle.com> <2fdb4a87-54e6-5fce-8feb-f093cb3f24d2@oracle.com> Message-ID: <57568DE7.8070002@oracle.com> Hi The testset hotspot is not affected by this change. It run c2 only on windows/linux-x86. I verified that default target and pit has same results and similar time as before my fix. Leonid On 27.05.2016 01:09, David Holmes wrote: > Hi Leonid, > > On 27/05/2016 5:00 AM, Leonid Mesnik wrote: >> Dear All >> >> Please find updated webrev for this fix here: >> http://cr.openjdk.java.net/~lmesnik/8154209/webrev.00/hotspot/ >> >> http://cr.openjdk.java.net/~lmesnik/8154209/webrev.00/root/ >> >> The client jvm is removed from linux-x86 and windows-x86 profiles. The >> linux-x86 currently includes minimal and server VM. The server VM is >> used by default. >> The test targets has been updated to test server for this profiles. > > The changes look to do what they intended. > > However I have a couple of concerns. > > In places we are now testing with C2 on 32-bit rather than C1 - do we > know how that might affect the test runs in terms of execution time > and resource usage? I don't want to see a swag of new OOM failures or > timeouts. > > I'm doubly concerned by the windows changes as we previously only > focussed on client for 32-bit, and now we only do server. > > Thanks, > David > >> Leonid >> >> On 21.04.2016 09:23, Leonid Mesnik wrote: >>> Mikael >>> >>> On 21.04.2016 00:41, Mikael Vidstedt wrote: >>>> >>>> Good catch. Updated webrevs here: >>>> >>>> top: >>>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02/webrev/common/conf/jib-profiles.js.udiff.html >>> >>> >>> >>> >>> >>> Couldn't be >>> >>> *"--with-jvm-variants=client,server"* >>> >>> just completely removed now as for all 64bit profiles? >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02/webrev/make/jprt.properties.sdiff.html >>> >>> >>> >>> >>> >>> 213 windows_i586_6.3-product-c1-TESTNAME, \ >>> >>> I see that you just remove C1 testing. Wouldn't be better to replace >>> it with c2? (Same for line 298) >>> >>> Leonid >>>> hotspot: >>>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02/hotspot/webrev/ >>>> >>>> >>>> >>>> Incremental webrevs (from webrev.01): >>>> >>>> top: >>>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02.incr/webrev/ >>>> >>>> >>>> hotspot: N/A (same as webrev.01) >>>> >>>> Cheers, >>>> Mikael >>>> >>>> On 4/18/2016 12:52 AM, Leonid Mesnik wrote: >>>>> Hi >>>>> >>>>> >>>>> Shouldn't be jprt targets in jprt.properties updates to stop using >>>>> client also? >>>>> >>>>> http://hg.openjdk.java.net/jdk9/hs/file/645c48292130/make/jprt.properties >>>>> >>>>> >>>>> >>>>> line 206 - 214 >>>>> # Test target list (no fastdebug & limited c2 testing) >>>>> my.test.target.set= \ >>>>> solaris_sparcv9_5.11-product-c2-TESTNAME, \ >>>>> solaris_x64_5.11-product-c2-TESTNAME, \ >>>>> linux_i586_3.8-product-{c1|c2}-TESTNAME, \ >>>>> linux_x64_3.8-product-c2-TESTNAME, \ >>>>> macosx_x64_10.9-product-c2-TESTNAME, \ >>>>> windows_i586_6.3-product-c1-TESTNAME, \ >>>>> windows_x64_6.3-product-c2-TESTNAME >>>>> >>>>> and >>>>> line 294-299 >>>>> # JCK test targets in test/Makefile (no windows) >>>>> my.test.target.set.jck= \ >>>>> solaris_sparcv9_5.11-product-c2-JCK7TESTRULE, \ >>>>> solaris_x64_5.11-product-c2-JCK7TESTRULE, \ >>>>> linux_i586_3.8-product-c1-JCK7TESTRULE, \ >>>>> linux_x64_3.8-product-c2-JCK7TESTRULE >>>>> >>>>> Leonid >>>>> >>>>> On 14.04.2016 19:41, Mikael Vidstedt wrote: >>>>>> >>>>>> Please review the following change which removes the "client" VM >>>>>> from the default JIB build profile on windows-x86 and linux-x86: >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154209 >>>>>> Webrev (top): >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.01/ >>>>>> Webrev (hotspot): >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.01/hotspot/webrev/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> When not including the client VM, the build system automatically >>>>>> creates a jvm.cfg which makes -client an alias for -server. At some >>>>>> point in the future we may choose to output a warning and/or refuse >>>>>> to start up if -client is specified, but at least for now silently >>>>>> falling back on the -server VM seems appropriate. >>>>>> >>>>>> The test/runtime/SharedArchiveFile/DefaultUseWithClient.java test >>>>>> assumes that CDS is always compiled in and enabled in the -client >>>>>> VM on windows-x86. Since -client will fall back on -server that is >>>>>> no longer true, so the test needs to be updated. I added an @ignore >>>>>> and filed the following issue to track fixing the test: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8154204 >>>>>> >>>>>> >>>>>> Testing: >>>>>> >>>>>> In addition to a standard JPRT push job, Christian Tornqvist helped >>>>>> me run the runtime nightly tests and apart from the above mentioned >>>>>> test all tests were successful. >>>>>> >>>>>> Cheers, >>>>>> Mikael >>>>>> >>>>> >>>> >>> >> From david.holmes at oracle.com Tue Jun 7 09:32:27 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 7 Jun 2016 19:32:27 +1000 Subject: RFR(S): 8154209: Remove client VM from default JIB profile on windows-x86 and linux-x86 In-Reply-To: <57568DE7.8070002@oracle.com> References: <570FC852.10808@oracle.com> <57149250.10008@oracle.com> <5717F77D.6080308@oracle.com> <571871E6.5050306@oracle.com> <574747CB.8000103@oracle.com> <2fdb4a87-54e6-5fce-8feb-f093cb3f24d2@oracle.com> <57568DE7.8070002@oracle.com> Message-ID: <595f3fa0-62d4-6447-84dc-021a169f4d11@oracle.com> On 7/06/2016 7:03 PM, Leonid Mesnik wrote: > Hi > > The testset hotspot is not affected by this change. It run c2 only on > windows/linux-x86. Right -sorry - I forgot we already ripped out client testing in 8153071. All good. Thanks, David > I verified that default target and pit has same results and similar time > as before my fix. > > Leonid > > On 27.05.2016 01:09, David Holmes wrote: >> Hi Leonid, >> >> On 27/05/2016 5:00 AM, Leonid Mesnik wrote: >>> Dear All >>> >>> Please find updated webrev for this fix here: >>> http://cr.openjdk.java.net/~lmesnik/8154209/webrev.00/hotspot/ >>> >>> http://cr.openjdk.java.net/~lmesnik/8154209/webrev.00/root/ >>> >>> The client jvm is removed from linux-x86 and windows-x86 profiles. The >>> linux-x86 currently includes minimal and server VM. The server VM is >>> used by default. >>> The test targets has been updated to test server for this profiles. >> >> The changes look to do what they intended. >> >> However I have a couple of concerns. >> >> In places we are now testing with C2 on 32-bit rather than C1 - do we >> know how that might affect the test runs in terms of execution time >> and resource usage? I don't want to see a swag of new OOM failures or >> timeouts. >> >> I'm doubly concerned by the windows changes as we previously only >> focussed on client for 32-bit, and now we only do server. >> >> Thanks, >> David >> >>> Leonid >>> >>> On 21.04.2016 09:23, Leonid Mesnik wrote: >>>> Mikael >>>> >>>> On 21.04.2016 00:41, Mikael Vidstedt wrote: >>>>> >>>>> Good catch. Updated webrevs here: >>>>> >>>>> top: >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02/webrev/common/conf/jib-profiles.js.udiff.html >>>> >>>> >>>> >>>> >>>> >>>> Couldn't be >>>> >>>> *"--with-jvm-variants=client,server"* >>>> >>>> just completely removed now as for all 64bit profiles? >>>> >>>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02/webrev/make/jprt.properties.sdiff.html >>>> >>>> >>>> >>>> >>>> >>>> 213 windows_i586_6.3-product-c1-TESTNAME, \ >>>> >>>> I see that you just remove C1 testing. Wouldn't be better to replace >>>> it with c2? (Same for line 298) >>>> >>>> Leonid >>>>> hotspot: >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02/hotspot/webrev/ >>>>> >>>>> >>>>> >>>>> Incremental webrevs (from webrev.01): >>>>> >>>>> top: >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02.incr/webrev/ >>>>> >>>>> >>>>> hotspot: N/A (same as webrev.01) >>>>> >>>>> Cheers, >>>>> Mikael >>>>> >>>>> On 4/18/2016 12:52 AM, Leonid Mesnik wrote: >>>>>> Hi >>>>>> >>>>>> >>>>>> Shouldn't be jprt targets in jprt.properties updates to stop using >>>>>> client also? >>>>>> >>>>>> http://hg.openjdk.java.net/jdk9/hs/file/645c48292130/make/jprt.properties >>>>>> >>>>>> >>>>>> >>>>>> line 206 - 214 >>>>>> # Test target list (no fastdebug & limited c2 testing) >>>>>> my.test.target.set= \ >>>>>> solaris_sparcv9_5.11-product-c2-TESTNAME, \ >>>>>> solaris_x64_5.11-product-c2-TESTNAME, \ >>>>>> linux_i586_3.8-product-{c1|c2}-TESTNAME, \ >>>>>> linux_x64_3.8-product-c2-TESTNAME, \ >>>>>> macosx_x64_10.9-product-c2-TESTNAME, \ >>>>>> windows_i586_6.3-product-c1-TESTNAME, \ >>>>>> windows_x64_6.3-product-c2-TESTNAME >>>>>> >>>>>> and >>>>>> line 294-299 >>>>>> # JCK test targets in test/Makefile (no windows) >>>>>> my.test.target.set.jck= \ >>>>>> solaris_sparcv9_5.11-product-c2-JCK7TESTRULE, \ >>>>>> solaris_x64_5.11-product-c2-JCK7TESTRULE, \ >>>>>> linux_i586_3.8-product-c1-JCK7TESTRULE, \ >>>>>> linux_x64_3.8-product-c2-JCK7TESTRULE >>>>>> >>>>>> Leonid >>>>>> >>>>>> On 14.04.2016 19:41, Mikael Vidstedt wrote: >>>>>>> >>>>>>> Please review the following change which removes the "client" VM >>>>>>> from the default JIB build profile on windows-x86 and linux-x86: >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154209 >>>>>>> Webrev (top): >>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.01/ >>>>>>> Webrev (hotspot): >>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.01/hotspot/webrev/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> When not including the client VM, the build system automatically >>>>>>> creates a jvm.cfg which makes -client an alias for -server. At some >>>>>>> point in the future we may choose to output a warning and/or refuse >>>>>>> to start up if -client is specified, but at least for now silently >>>>>>> falling back on the -server VM seems appropriate. >>>>>>> >>>>>>> The test/runtime/SharedArchiveFile/DefaultUseWithClient.java test >>>>>>> assumes that CDS is always compiled in and enabled in the -client >>>>>>> VM on windows-x86. Since -client will fall back on -server that is >>>>>>> no longer true, so the test needs to be updated. I added an @ignore >>>>>>> and filed the following issue to track fixing the test: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8154204 >>>>>>> >>>>>>> >>>>>>> Testing: >>>>>>> >>>>>>> In addition to a standard JPRT push job, Christian Tornqvist helped >>>>>>> me run the runtime nightly tests and apart from the above mentioned >>>>>>> test all tests were successful. >>>>>>> >>>>>>> Cheers, >>>>>>> Mikael >>>>>>> >>>>>> >>>>> >>>> >>> > From Leonid.Mesnik at oracle.com Tue Jun 7 09:45:38 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Tue, 7 Jun 2016 12:45:38 +0300 Subject: RFR(S): 8154209: Remove client VM from default JIB profile on windows-x86 and linux-x86 In-Reply-To: <595f3fa0-62d4-6447-84dc-021a169f4d11@oracle.com> References: <570FC852.10808@oracle.com> <57149250.10008@oracle.com> <5717F77D.6080308@oracle.com> <571871E6.5050306@oracle.com> <574747CB.8000103@oracle.com> <2fdb4a87-54e6-5fce-8feb-f093cb3f24d2@oracle.com> <57568DE7.8070002@oracle.com> <595f3fa0-62d4-6447-84dc-021a169f4d11@oracle.com> Message-ID: <575697C2.4020608@oracle.com> Thank you for review. Leonid On 07.06.2016 12:32, David Holmes wrote: > On 7/06/2016 7:03 PM, Leonid Mesnik wrote: >> Hi >> >> The testset hotspot is not affected by this change. It run c2 only on >> windows/linux-x86. > > Right -sorry - I forgot we already ripped out client testing in 8153071. > > All good. > > Thanks, > David > >> I verified that default target and pit has same results and similar time >> as before my fix. >> >> Leonid >> >> On 27.05.2016 01:09, David Holmes wrote: >>> Hi Leonid, >>> >>> On 27/05/2016 5:00 AM, Leonid Mesnik wrote: >>>> Dear All >>>> >>>> Please find updated webrev for this fix here: >>>> http://cr.openjdk.java.net/~lmesnik/8154209/webrev.00/hotspot/ >>>> >>>> http://cr.openjdk.java.net/~lmesnik/8154209/webrev.00/root/ >>>> >>>> The client jvm is removed from linux-x86 and windows-x86 profiles. The >>>> linux-x86 currently includes minimal and server VM. The server VM is >>>> used by default. >>>> The test targets has been updated to test server for this profiles. >>> >>> The changes look to do what they intended. >>> >>> However I have a couple of concerns. >>> >>> In places we are now testing with C2 on 32-bit rather than C1 - do we >>> know how that might affect the test runs in terms of execution time >>> and resource usage? I don't want to see a swag of new OOM failures or >>> timeouts. >>> >>> I'm doubly concerned by the windows changes as we previously only >>> focussed on client for 32-bit, and now we only do server. >>> >>> Thanks, >>> David >>> >>>> Leonid >>>> >>>> On 21.04.2016 09:23, Leonid Mesnik wrote: >>>>> Mikael >>>>> >>>>> On 21.04.2016 00:41, Mikael Vidstedt wrote: >>>>>> >>>>>> Good catch. Updated webrevs here: >>>>>> >>>>>> top: >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02/webrev/common/conf/jib-profiles.js.udiff.html >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Couldn't be >>>>> >>>>> *"--with-jvm-variants=client,server"* >>>>> >>>>> just completely removed now as for all 64bit profiles? >>>>> >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02/webrev/make/jprt.properties.sdiff.html >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 213 windows_i586_6.3-product-c1-TESTNAME, \ >>>>> >>>>> I see that you just remove C1 testing. Wouldn't be better to replace >>>>> it with c2? (Same for line 298) >>>>> >>>>> Leonid >>>>>> hotspot: >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02/hotspot/webrev/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Incremental webrevs (from webrev.01): >>>>>> >>>>>> top: >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02.incr/webrev/ >>>>>> >>>>>> >>>>>> >>>>>> hotspot: N/A (same as webrev.01) >>>>>> >>>>>> Cheers, >>>>>> Mikael >>>>>> >>>>>> On 4/18/2016 12:52 AM, Leonid Mesnik wrote: >>>>>>> Hi >>>>>>> >>>>>>> >>>>>>> Shouldn't be jprt targets in jprt.properties updates to stop using >>>>>>> client also? >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk9/hs/file/645c48292130/make/jprt.properties >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> line 206 - 214 >>>>>>> # Test target list (no fastdebug & limited c2 testing) >>>>>>> my.test.target.set= \ >>>>>>> solaris_sparcv9_5.11-product-c2-TESTNAME, \ >>>>>>> solaris_x64_5.11-product-c2-TESTNAME, \ >>>>>>> linux_i586_3.8-product-{c1|c2}-TESTNAME, \ >>>>>>> linux_x64_3.8-product-c2-TESTNAME, \ >>>>>>> macosx_x64_10.9-product-c2-TESTNAME, \ >>>>>>> windows_i586_6.3-product-c1-TESTNAME, \ >>>>>>> windows_x64_6.3-product-c2-TESTNAME >>>>>>> >>>>>>> and >>>>>>> line 294-299 >>>>>>> # JCK test targets in test/Makefile (no windows) >>>>>>> my.test.target.set.jck= \ >>>>>>> solaris_sparcv9_5.11-product-c2-JCK7TESTRULE, \ >>>>>>> solaris_x64_5.11-product-c2-JCK7TESTRULE, \ >>>>>>> linux_i586_3.8-product-c1-JCK7TESTRULE, \ >>>>>>> linux_x64_3.8-product-c2-JCK7TESTRULE >>>>>>> >>>>>>> Leonid >>>>>>> >>>>>>> On 14.04.2016 19:41, Mikael Vidstedt wrote: >>>>>>>> >>>>>>>> Please review the following change which removes the "client" VM >>>>>>>> from the default JIB build profile on windows-x86 and linux-x86: >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154209 >>>>>>>> Webrev (top): >>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.01/ >>>>>>>> Webrev (hotspot): >>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.01/hotspot/webrev/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> When not including the client VM, the build system automatically >>>>>>>> creates a jvm.cfg which makes -client an alias for -server. At >>>>>>>> some >>>>>>>> point in the future we may choose to output a warning and/or >>>>>>>> refuse >>>>>>>> to start up if -client is specified, but at least for now silently >>>>>>>> falling back on the -server VM seems appropriate. >>>>>>>> >>>>>>>> The test/runtime/SharedArchiveFile/DefaultUseWithClient.java test >>>>>>>> assumes that CDS is always compiled in and enabled in the -client >>>>>>>> VM on windows-x86. Since -client will fall back on -server that is >>>>>>>> no longer true, so the test needs to be updated. I added an >>>>>>>> @ignore >>>>>>>> and filed the following issue to track fixing the test: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8154204 >>>>>>>> >>>>>>>> >>>>>>>> Testing: >>>>>>>> >>>>>>>> In addition to a standard JPRT push job, Christian Tornqvist >>>>>>>> helped >>>>>>>> me run the runtime nightly tests and apart from the above >>>>>>>> mentioned >>>>>>>> test all tests were successful. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Mikael >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> From volker.simonis at gmail.com Tue Jun 7 16:14:07 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 7 Jun 2016 18:14:07 +0200 Subject: RFR(S): 8158938: AIX: some more new hotspot build fixes Message-ID: Hi, can I please have a review for the following two (top-level and hotspot) AIX-only changes: http://cr.openjdk.java.net/~simonis/webrevs/2016/8158938_top/ http://cr.openjdk.java.net/~simonis/webrevs/2016/8158938_hs/ https://bugs.openjdk.java.net/browse/JDK-8158938 Although the changes are AIX only, they require the recreation of generated_configure.sh in the top-level repo and touche a shared make file in the hotspot repo, so I need a sponsor for both of them. Ideally they should go into the same forest although they have no dependencies on each other. It's not important for me into which forest they will be pushed, as long as they eventually arrive in jdk9. The changes in some more detail: top-level repository: - fix AIX build to set -DDONT_USE_PRECOMPILED_HEADERS - don't build gtest on AIX by default - move optimization flags from JVM_CFLAGS to C_O_FLAG_HI* where they really belong to. hotspot repository: - build jvmtiEnterTrace.cpp on a lower optimization level to prevent excessive build times. Thank you and best regards, Volker From erik.joelsson at oracle.com Tue Jun 7 16:19:48 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 7 Jun 2016 18:19:48 +0200 Subject: RFR(S): 8158938: AIX: some more new hotspot build fixes In-Reply-To: References: Message-ID: <5756F424.6070000@oracle.com> Looks good to me. I will sponsor. /Erik On 2016-06-07 18:14, Volker Simonis wrote: > Hi, > > can I please have a review for the following two (top-level and > hotspot) AIX-only changes: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8158938_top/ > http://cr.openjdk.java.net/~simonis/webrevs/2016/8158938_hs/ > https://bugs.openjdk.java.net/browse/JDK-8158938 > > Although the changes are AIX only, they require the recreation of > generated_configure.sh in the top-level repo and touche a shared make > file in the hotspot repo, so I need a sponsor for both of them. > Ideally they should go into the same forest although they have no > dependencies on each other. It's not important for me into which > forest they will be pushed, as long as they eventually arrive in jdk9. > > The changes in some more detail: > > top-level repository: > - fix AIX build to set -DDONT_USE_PRECOMPILED_HEADERS > - don't build gtest on AIX by default > - move optimization flags from JVM_CFLAGS to C_O_FLAG_HI* where they > really belong to. > > hotspot repository: > - build jvmtiEnterTrace.cpp on a lower optimization level to prevent > excessive build times. > > Thank you and best regards, > Volker From volker.simonis at gmail.com Tue Jun 7 18:43:30 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 7 Jun 2016 20:43:30 +0200 Subject: RFR(S): 8158938: AIX: some more new hotspot build fixes In-Reply-To: <5756F424.6070000@oracle.com> References: <5756F424.6070000@oracle.com> Message-ID: Thanks a lot Erik. That was really fast! Regards, Volker On Tue, Jun 7, 2016 at 6:19 PM, Erik Joelsson wrote: > Looks good to me. I will sponsor. > > /Erik > > > On 2016-06-07 18:14, Volker Simonis wrote: >> >> Hi, >> >> can I please have a review for the following two (top-level and >> hotspot) AIX-only changes: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8158938_top/ >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8158938_hs/ >> https://bugs.openjdk.java.net/browse/JDK-8158938 >> >> Although the changes are AIX only, they require the recreation of >> generated_configure.sh in the top-level repo and touche a shared make >> file in the hotspot repo, so I need a sponsor for both of them. >> Ideally they should go into the same forest although they have no >> dependencies on each other. It's not important for me into which >> forest they will be pushed, as long as they eventually arrive in jdk9. >> >> The changes in some more detail: >> >> top-level repository: >> - fix AIX build to set -DDONT_USE_PRECOMPILED_HEADERS >> - don't build gtest on AIX by default >> - move optimization flags from JVM_CFLAGS to C_O_FLAG_HI* where they >> really belong to. >> >> hotspot repository: >> - build jvmtiEnterTrace.cpp on a lower optimization level to prevent >> excessive build times. >> >> Thank you and best regards, >> Volker > > From david.holmes at oracle.com Tue Jun 7 20:53:02 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 8 Jun 2016 06:53:02 +1000 Subject: RFR(S): 8158938: AIX: some more new hotspot build fixes In-Reply-To: <5756F424.6070000@oracle.com> References: <5756F424.6070000@oracle.com> Message-ID: <8c6ce565-693b-91c0-2f85-6e255cba0604@oracle.com> Looks good to me too! David On 8/06/2016 2:19 AM, Erik Joelsson wrote: > Looks good to me. I will sponsor. > > /Erik > > On 2016-06-07 18:14, Volker Simonis wrote: >> Hi, >> >> can I please have a review for the following two (top-level and >> hotspot) AIX-only changes: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8158938_top/ >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8158938_hs/ >> https://bugs.openjdk.java.net/browse/JDK-8158938 >> >> Although the changes are AIX only, they require the recreation of >> generated_configure.sh in the top-level repo and touche a shared make >> file in the hotspot repo, so I need a sponsor for both of them. >> Ideally they should go into the same forest although they have no >> dependencies on each other. It's not important for me into which >> forest they will be pushed, as long as they eventually arrive in jdk9. >> >> The changes in some more detail: >> >> top-level repository: >> - fix AIX build to set -DDONT_USE_PRECOMPILED_HEADERS >> - don't build gtest on AIX by default >> - move optimization flags from JVM_CFLAGS to C_O_FLAG_HI* where they >> really belong to. >> >> hotspot repository: >> - build jvmtiEnterTrace.cpp on a lower optimization level to prevent >> excessive build times. >> >> Thank you and best regards, >> Volker > From david.holmes at oracle.com Wed Jun 8 01:37:12 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 8 Jun 2016 11:37:12 +1000 Subject: RFR(XS): 8158763 : --disable-hotspot-gtest not working on Solaris In-Reply-To: References: Message-ID: <16d36f1f-943b-abbd-01b9-8a52f56660d6@oracle.com> Pushing to jdk9/hs under the "trivial - 1 Reviewer" rule David On 7/06/2016 5:07 PM, Volker Simonis wrote: > On Tue, Jun 7, 2016 at 4:28 AM, David Holmes wrote: >> Hi Volker, >> >> On 6/06/2016 11:59 PM, Volker Simonis wrote: >>> >>> Hi, >>> >>> I'd like to get the following tiny bug fix into jdk9-dev. What's the >>> current procedure to get this change approved? >> >> >> No approvals needed for bug fixes until RDP1 later in the year. Only >> enhancements need approval post FC and that process has not yet been setup. >> > > Ah, good to know. > >>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8158763/ >>> https://bugs.openjdk.java.net/browse/JDK-8158763 >>> >>> On Solaris, the configure test for libstlport.so.1 isn't disabled by >>> --disable-hotspot-gtest. So, if libstlport.so.1 isn't present, the >>> build will break during configuration even if we set >>> --disable-hotspot-gtest. >>> >>> The fix is trivial - just guard the test for libstlport.so.1 by >>> "x$BUILD_GTEST" = "xtrue". >>> >>> The fix also adds an alternative location for libstlport.so.1 (from >>> SS12u3) to keep the sources compilable with SS12u3. >> >> >> This looks fine to me and I can sponsor it (need to regenerate closed >> generated-configure.sh). I'd also prefer to see this go into jdk9/hs if that >> is okay? >> > > Thanks a lot David. Pushing it to jdk9/hs first is fine for me. > > Regards, > Volker > >> Thanks, >> David >> ----- >> >> >>> >>> Thank you and best regards, >>> Volker >>> >> From volker.simonis at gmail.com Wed Jun 8 07:24:00 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 8 Jun 2016 09:24:00 +0200 Subject: RFR(XS): 8158763 : --disable-hotspot-gtest not working on Solaris In-Reply-To: <16d36f1f-943b-abbd-01b9-8a52f56660d6@oracle.com> References: <16d36f1f-943b-abbd-01b9-8a52f56660d6@oracle.com> Message-ID: Thanks a lot David! Regards, Volker On Wed, Jun 8, 2016 at 3:37 AM, David Holmes wrote: > Pushing to jdk9/hs under the "trivial - 1 Reviewer" rule > > David > > > On 7/06/2016 5:07 PM, Volker Simonis wrote: >> >> On Tue, Jun 7, 2016 at 4:28 AM, David Holmes >> wrote: >>> >>> Hi Volker, >>> >>> On 6/06/2016 11:59 PM, Volker Simonis wrote: >>>> >>>> >>>> Hi, >>>> >>>> I'd like to get the following tiny bug fix into jdk9-dev. What's the >>>> current procedure to get this change approved? >>> >>> >>> >>> No approvals needed for bug fixes until RDP1 later in the year. Only >>> enhancements need approval post FC and that process has not yet been >>> setup. >>> >> >> Ah, good to know. >> >>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8158763/ >>>> https://bugs.openjdk.java.net/browse/JDK-8158763 >>>> >>>> On Solaris, the configure test for libstlport.so.1 isn't disabled by >>>> --disable-hotspot-gtest. So, if libstlport.so.1 isn't present, the >>>> build will break during configuration even if we set >>>> --disable-hotspot-gtest. >>>> >>>> The fix is trivial - just guard the test for libstlport.so.1 by >>>> "x$BUILD_GTEST" = "xtrue". >>>> >>>> The fix also adds an alternative location for libstlport.so.1 (from >>>> SS12u3) to keep the sources compilable with SS12u3. >>> >>> >>> >>> This looks fine to me and I can sponsor it (need to regenerate closed >>> generated-configure.sh). I'd also prefer to see this go into jdk9/hs if >>> that >>> is okay? >>> >> >> Thanks a lot David. Pushing it to jdk9/hs first is fine for me. >> >> Regards, >> Volker >> >>> Thanks, >>> David >>> ----- >>> >>> >>>> >>>> Thank you and best regards, >>>> Volker >>>> >>> > From michael.rasmussen at zeroturnaround.com Wed Jun 8 08:27:28 2016 From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen) Date: Wed, 8 Jun 2016 11:27:28 +0300 Subject: SignatureIterator::iterate_returntype with method params containing ')' Message-ID: Hi I was looking at src/share/vm/runtime/signature.cpp [1] and noticed that SignatureIterator::iterate_returntype simply reads until the first ')' it sees, which should be incorrect if any of the parameter types contains ')'. I constructed a small sample code [2], that uses ASM to generate classes, for which I get warnings or VerifyError presumably because of this, depending on how I name my class. I know it's uncommon for classes to have ')' in their names, but according to the JVMS it's legal and some libraries do generate such classes (for instance some versions of Weld). Best regards Michael Rasmussen ZeroTurnaround [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/tip/src/share/vm/runtime/signature.cpp#l222 [2] https://gist.github.com/anonymous/abbd5ed146b39f4ce3ba0b84b0edc8e6 From stefan.johansson at oracle.com Wed Jun 8 09:29:28 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 8 Jun 2016 11:29:28 +0200 Subject: RFR: 8146530: [testbug] some tests fail because the compiler is using Java heap memory Message-ID: <5757E578.3010509@oracle.com> Hi all, Please review this test fix for: https://bugs.openjdk.java.net/browse/JDK-8146530 Webrev: http://cr.openjdk.java.net/~sjohanss/8146530/hotspot.00/ Summary: This test seems to fail because of two things. Either because it is executed with +ExplicitGCInvokesConcurrent or that a Java compiler is used via JVMCI. The suggested fix is to use @requires to avoid running the test with these options. The reason ExplicitGCInvokesConcurrent fails the test is because the test is written to rely on calling System.gc() to have a clear view when starting the test, and if this call instead starts a concurrent cycle the test might fail. Using JVMCI causes the test to fail because it leads to unexpected amount of allocated data and there for the assumptions made by the test does not hold. Testing: Verified that the test is not executed when these options are given on the command-line. Thanks, Stefan From jesper.wilhelmsson at oracle.com Wed Jun 8 11:23:30 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 8 Jun 2016 13:23:30 +0200 Subject: RFR: 8146530: [testbug] some tests fail because the compiler is using Java heap memory In-Reply-To: <5757E578.3010509@oracle.com> References: <5757E578.3010509@oracle.com> Message-ID: Looks good! /Jesper Den 8/6/16 kl. 11:29, skrev Stefan Johansson: > Hi all, > > Please review this test fix for: > https://bugs.openjdk.java.net/browse/JDK-8146530 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8146530/hotspot.00/ > > Summary: > This test seems to fail because of two things. Either because it is executed > with +ExplicitGCInvokesConcurrent or that a Java compiler is used via JVMCI. The > suggested fix is to use @requires to avoid running the test with these options. > > The reason ExplicitGCInvokesConcurrent fails the test is because the test is > written to rely on calling System.gc() to have a clear view when starting the > test, and if this call instead starts a concurrent cycle the test might fail. > > Using JVMCI causes the test to fail because it leads to unexpected amount of > allocated data and there for the assumptions made by the test does not hold. > > Testing: > Verified that the test is not executed when these options are given on the > command-line. > > Thanks, > Stefan From erik.helin at oracle.com Wed Jun 8 11:59:44 2016 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 8 Jun 2016 13:59:44 +0200 Subject: RFR: 8157243: JMap heap test fail when used with external heap In-Reply-To: <573C83EB.5090804@oracle.com> References: <573C83EB.5090804@oracle.com> Message-ID: <20160608115944.GD26799@ehelin.jrpg.bea.com> On 2016-05-18, Stefan Johansson wrote: > Hi, > > Please review this small change for: > https://bugs.openjdk.java.net/browse/JDK-8157243 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8157243/hotspot.00/ Looks good, Reviewed. Thanks, Erik > Summary: > This change is needed to fix a failing test when a non-standard heap is > used. The change adds a way to declare such heaps. > > Since this was considered an enhancement rather then a bug-fix, I'm > currently waiting for approval to push this even though FC has passed. > > Testing: > * JPRT > * RBT > > Thanks, > Stefan > From stefan.johansson at oracle.com Wed Jun 8 12:01:28 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 8 Jun 2016 14:01:28 +0200 Subject: RFR: 8157243: JMap heap test fail when used with external heap In-Reply-To: <20160608115944.GD26799@ehelin.jrpg.bea.com> References: <573C83EB.5090804@oracle.com> <20160608115944.GD26799@ehelin.jrpg.bea.com> Message-ID: <57580918.7010300@oracle.com> Thanks Erik and Dmitry, Stefan On 2016-06-08 13:59, Erik Helin wrote: > On 2016-05-18, Stefan Johansson wrote: >> Hi, >> >> Please review this small change for: >> https://bugs.openjdk.java.net/browse/JDK-8157243 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8157243/hotspot.00/ > Looks good, Reviewed. > > Thanks, > Erik > >> Summary: >> This change is needed to fix a failing test when a non-standard heap is >> used. The change adds a way to declare such heaps. >> >> Since this was considered an enhancement rather then a bug-fix, I'm >> currently waiting for approval to push this even though FC has passed. >> >> Testing: >> * JPRT >> * RBT >> >> Thanks, >> Stefan >> From edward.nevill at gmail.com Wed Jun 8 13:28:50 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 08 Jun 2016 14:28:50 +0100 Subject: RFR: 8159052: aarch64: optimise unaligned copies in pd_disjoint_words and pd_conjoint_words Message-ID: <1465392530.28716.52.camel@mylittlepony.linaroharston> Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8159052/webrev JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8159052 Some partners HW has large unaligned access penalties. This webrev optimises unaligned copies in pd_disjoint_words and pd_conjoint_words. There is no performance degradation on other partners HW. The following JMH test was used to benchmark performance. http://cr.openjdk.java.net/~enevill/8159052/JMHSample_97_GCStress.java The following graphs show the performance of the above test on two partners HW, partner A which has a penalty for unaligned accesses and partner B which does not. The test was repeated for three different garbage collectors, G1GC, ParallelGC and CMS. The units are time, so lower is better. http://cr.openjdk.java.net/~enevill/8159052/gcstress_res.pdf I understand that this cannot be pushed to jdk 9 at the moment because jdk 9 is FC, however I would like to push this to the aarch64 port jdk8u repo so it has a save home to be migrated to jdk 9/jdk 9u/jdk 10 in the future. OK to push to jdk8u? Ed. From aph at redhat.com Wed Jun 8 13:31:54 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 8 Jun 2016 14:31:54 +0100 Subject: RFR: 8159052: aarch64: optimise unaligned copies in pd_disjoint_words and pd_conjoint_words In-Reply-To: <1465392530.28716.52.camel@mylittlepony.linaroharston> References: <1465392530.28716.52.camel@mylittlepony.linaroharston> Message-ID: <57581E4A.6070503@redhat.com> On 08/06/16 14:28, Edward Nevill wrote: > I understand that this cannot be pushed to jdk 9 at the moment because > jdk 9 is FC, however I would like to push this to the aarch64 port jdk8u > repo so it has a save home to be migrated to jdk 9/jdk 9u/jdk 10 in the > future. > > OK to push to jdk8u? OK. This is also OK for jdk9 once we figure out how to get approval. Andrew. From jon.masamitsu at oracle.com Wed Jun 8 15:47:44 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 8 Jun 2016 08:47:44 -0700 Subject: RFR: 8146530: [testbug] some tests fail because the compiler is using Java heap memory In-Reply-To: <5757E578.3010509@oracle.com> References: <5757E578.3010509@oracle.com> Message-ID: <57583E20.1010708@oracle.com> Looks good. Copyright needs updating. Jon On 06/08/2016 02:29 AM, Stefan Johansson wrote: > Hi all, > > Please review this test fix for: > https://bugs.openjdk.java.net/browse/JDK-8146530 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8146530/hotspot.00/ > > Summary: > This test seems to fail because of two things. Either because it is > executed with +ExplicitGCInvokesConcurrent or that a Java compiler is > used via JVMCI. The suggested fix is to use @requires to avoid running > the test with these options. > > The reason ExplicitGCInvokesConcurrent fails the test is because the > test is written to rely on calling System.gc() to have a clear view > when starting the test, and if this call instead starts a concurrent > cycle the test might fail. > > Using JVMCI causes the test to fail because it leads to unexpected > amount of allocated data and there for the assumptions made by the > test does not hold. > > Testing: > Verified that the test is not executed when these options are given on > the command-line. > > Thanks, > Stefan From vladimir.kozlov at oracle.com Wed Jun 8 16:10:16 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 8 Jun 2016 09:10:16 -0700 Subject: RFR: 8146530: [testbug] some tests fail because the compiler is using Java heap memory In-Reply-To: <5757E578.3010509@oracle.com> References: <5757E578.3010509@oracle.com> Message-ID: <29b45368-547d-9df3-31dc-0090f0629067@oracle.com> Only UseJVMCICompiler triggers usage of java compiler. EnableJVMCI is false only on embedded platforms as result you will not run the test at all if you check it. Please, remove this check. Thanks, Vladimir On 6/8/16 2:29 AM, Stefan Johansson wrote: > Hi all, > > Please review this test fix for: > https://bugs.openjdk.java.net/browse/JDK-8146530 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8146530/hotspot.00/ > > Summary: > This test seems to fail because of two things. Either because it is > executed with +ExplicitGCInvokesConcurrent or that a Java compiler is > used via JVMCI. The suggested fix is to use @requires to avoid running > the test with these options. > > The reason ExplicitGCInvokesConcurrent fails the test is because the > test is written to rely on calling System.gc() to have a clear view when > starting the test, and if this call instead starts a concurrent cycle > the test might fail. > > Using JVMCI causes the test to fail because it leads to unexpected > amount of allocated data and there for the assumptions made by the test > does not hold. > > Testing: > Verified that the test is not executed when these options are given on > the command-line. > > Thanks, > Stefan From zoltan.majo at oracle.com Wed Jun 8 17:52:17 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 8 Jun 2016 19:52:17 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <988f2271-0d7e-7a02-b301-c6237f123262@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <988f2271-0d7e-7a02-b301-c6237f123262@oracle.com> Message-ID: <57585B51.1020503@oracle.com> Hi Vladimir, thank you for the feedback. Please see comments inline. On 06/02/2016 12:47 PM, Vladimir Ivanov wrote: > Zoltan, > > (broadening the audience to hotspot-dev@) > > I'd like to draw attention from Runtime group to this change. >> OK, so I have implemented a generic fix that adds the checks required by >> the JVMS. >> >> For bytecodes modifying final fields, the VM checks >> - that the accessing method is (for static fields) >> - that the accessing method is (for instance fields) >> and thrown an IllegalAccessError if any of the checks fails. >> >> Here is the new webrev: >> http://cr.openjdk.java.net/~zmajo/8157181/webrev.02/ > > Regarding tightening linkage checks, your fix doesn't take into > account JVMS changes between 6 & 7 (expected behavior differs > depending on class file version). > > Before JVMS-7, where putfield/putstatic linkage checks were tightened, > it was allowed to change final fields from anywhere in the same class. > > putfield "Linking Exceptions": > > JVMS-6 [1]: > "Otherwise, if the field is final, it must be declared in the > current class. Otherwise, an IllegalAccessError is thrown." > > JVMS-7 [2]: > "Otherwise, if the field is final, it must be declared in the > current class, and the instruction must occur in an instance > initialization method () of the current class. Otherwise, an > IllegalAccessError is thrown." Thanks for drawing attention of the different specification for version 6. > > > src/share/vm/interpreter/linkResolver.cpp: > > + (byte == Bytecodes::_putstatic && fd.is_static() && > method_name != vmSymbols::class_initializer_name()) || > + ((byte == Bytecodes::_putfield || byte == > Bytecodes::_nofast_putfield) && !fd.is_static() && method_name != > vmSymbols::object_initializer_name()) > > > Also, as we found earlier, checking method name is not enough: > > bool Method::is_static_initializer() const { > // For classfiles version 51 or greater, ensure that the clinit > method is > // static. Non-static methods with the name "" are not static > // initializers. (older classfiles exempted for backward compatibility) > return name() == vmSymbols::class_initializer_name() && > has_valid_initializer_flags(); > } Right. I missed that issue, but have addressed it in the latest webrev (webrev.06). > > > - LinkInfo link_info(defc, name, type, KlassHandle(), > /*check_access=*/false); > + LinkInfo link_info(defc, name, type, KlassHandle(), NULL, > /*check_access=*/false); > > Use Handle() instead of NULL. It seems that methodHandle() works better for these cases, but... (see below) > > > Also, I'd prefer to see LinkInfo::_current_method and new constructor > added: > > LinkInfo(KlassHandle resolved_klass, Symbol* name, Symbol* signature, > Handle current_method, bool check_access = true) : > > _current_klass can be derived from _current_method, since: > > // current_klass = sending method holder (i.e., class containing > the method > // containing the call being resolved) ... I've added two new constructors. One of them derives _current_method from _current_klass, the other uses methodHandle() within the constructor. Please see the updated webrev (webrev.06) in the reply to Vladimir K. Best regards, Zoltan > >> I did the following testing: >> - JPRT >> - pre-PIT RBT run (in progress) >> - the reproducer. >> >> The reproducer now behaves as expected (an IllegalAccessError is >> thrown). Also, the pre-PIT RBT run has shown no new failures so far. >> >> But there is a problem with JPRT: A JCK test, putstatic01801m, fails. >> >> The reason for the failure is that the the test generates a method that >> contains a putstatic to a static final field (i.e., the bytecodes >> generated by the test do not conform to the JVMS). (Even the test >> mentions that the Java source equivalent to the generated bytecodes is >> compilable only if the "final" keyword is removed from the declaration >> of the static field.) >> >> So (if we decide to push the current fix) the issue with the test needs >> to be fixed first. Do you know how we could proceed with that? > File a bug against JCK. > > Best regards, > Vladimir Ivanov > > [1] > https://docs.oracle.com/javase/specs/jvms/se6/html/Instructions2.doc11.html > > [2] > https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.putfield > > [3] > https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4.3.2 > >> >> Thank you and best regards, >> >> >> Zoltan >> >>> >>> Best regards, >>> Vladimir Ivanov >>> >>>> >>>> I agree with you, alternatively we can propose a more generic fix (fix >>>> the interpreter and the compilers as well). The fix would most likely >>>> affect field resolution in LinkResolver::resolve_field() around here: >>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>> >>>> >>>> >>>> >>>> Changing resolve_field() to throw an IllegalAccessError for >>>> inappropriate field access will propagate the exception to the >>>> interpreter. Changing ciField::will_link() will most likely kill >>>> (some) >>>> compilations (if, e.g., fields are linked through >>>> ciField::will_link()). >>>> >>>> I'd prefer to take the second option (changing field resolution), but >>>> there might be some disadvantages related to option I might be >>>> overseeing. >>> >>> >>> >>> >>>> >>>> Thank you! >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>>> >>>> >>>>> >>>>>> More details about the failure are here [3]. >>>>>> >>>>>> With the patch applied, the program always completes as it is >>>>>> expected >>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed (because we >>>>>> always interpret methods non-conforming with the VM spec). >>>>>> >>>>>> Here is the updated webrev: >>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>> Bailing out the whole compilation in C2 is even less appropriate. It >>>>> should generate an uncommon trap for such accesses instead (see >>>>> Parse::do_field_access). >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> [1] >>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>> >>>>> >>>>> >>>> >> From zoltan.majo at oracle.com Wed Jun 8 17:52:54 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 8 Jun 2016 19:52:54 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <93b3fe16-2bb0-3e77-9333-61989f33ff1c@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <988f2271-0d7e-7a02-b301-c6237f123262@oracle.com> <93b3fe16-2bb0-3e77-9333-61989f33ff1c@oracle.com> Message-ID: <57585B76.5050809@oracle.com> Hi David, On 06/02/2016 01:51 PM, David Holmes wrote: > [...] > The simplest, and common, approach to these kind of issues is to only > apply the correction for the current class file version and keep the > relaxed rules for all others. That provides the best compatibility > story. Of course if security is a concern then that is a different > matter - but such concerns can not be discussed here. thank you for the suggestion! In the latest webrev (webrev.06), I enable the additional check for classfile version >= 51 (JAVA_7_VERSION). With that version, we're conforming with the specification. So far no problems have showed up with our test base. The new check can be disabled with the CheckFinalFieldModifications flag (you've suggested that in your JBS comment). We can also change the checked version to 52 (JAVA_8) or 53 (JAVA_9). Please see the updated webrev (webrev.06) in my reply to Vladimir K. Thank you! Best regards, Zoltan > > David > ----- > >> Before JVMS-7, where putfield/putstatic linkage checks were tightened, >> it was allowed to change final fields from anywhere in the same class. >> >> putfield "Linking Exceptions": >> >> JVMS-6 [1]: >> "Otherwise, if the field is final, it must be declared in the >> current class. Otherwise, an IllegalAccessError is thrown." >> >> JVMS-7 [2]: >> "Otherwise, if the field is final, it must be declared in the >> current class, and the instruction must occur in an instance >> initialization method () of the current class. Otherwise, an >> IllegalAccessError is thrown." >> >> >> src/share/vm/interpreter/linkResolver.cpp: >> >> + (byte == Bytecodes::_putstatic && fd.is_static() && >> method_name != vmSymbols::class_initializer_name()) || >> + ((byte == Bytecodes::_putfield || byte == >> Bytecodes::_nofast_putfield) && !fd.is_static() && method_name != >> vmSymbols::object_initializer_name()) >> >> >> Also, as we found earlier, checking method name is not enough: >> >> bool Method::is_static_initializer() const { >> // For classfiles version 51 or greater, ensure that the clinit >> method is >> // static. Non-static methods with the name "" are not static >> // initializers. (older classfiles exempted for backward >> compatibility) >> return name() == vmSymbols::class_initializer_name() && >> has_valid_initializer_flags(); >> } >> >> >> - LinkInfo link_info(defc, name, type, KlassHandle(), >> /*check_access=*/false); >> + LinkInfo link_info(defc, name, type, KlassHandle(), NULL, >> /*check_access=*/false); >> >> Use Handle() instead of NULL. >> >> Also, I'd prefer to see LinkInfo::_current_method and new constructor >> added: >> >> LinkInfo(KlassHandle resolved_klass, Symbol* name, Symbol* signature, >> Handle current_method, bool check_access = true) : >> >> _current_klass can be derived from _current_method, since: >> >> // current_klass = sending method holder (i.e., class containing the >> method >> // containing the call being resolved) >> >>> I did the following testing: >>> - JPRT >>> - pre-PIT RBT run (in progress) >>> - the reproducer. >>> >>> The reproducer now behaves as expected (an IllegalAccessError is >>> thrown). Also, the pre-PIT RBT run has shown no new failures so far. >>> >>> But there is a problem with JPRT: A JCK test, putstatic01801m, fails. >>> >>> The reason for the failure is that the the test generates a method that >>> contains a putstatic to a static final field (i.e., the bytecodes >>> generated by the test do not conform to the JVMS). (Even the test >>> mentions that the Java source equivalent to the generated bytecodes is >>> compilable only if the "final" keyword is removed from the declaration >>> of the static field.) >>> >>> So (if we decide to push the current fix) the issue with the test needs >>> to be fixed first. Do you know how we could proceed with that? >> File a bug against JCK. >> >> Best regards, >> Vladimir Ivanov >> >> [1] >> https://docs.oracle.com/javase/specs/jvms/se6/html/Instructions2.doc11.html >> >> >> [2] >> https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.putfield >> >> >> >> [3] >> https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4.3.2 >> >> >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>>> >>>>> I agree with you, alternatively we can propose a more generic fix >>>>> (fix >>>>> the interpreter and the compilers as well). The fix would most likely >>>>> affect field resolution in LinkResolver::resolve_field() around here: >>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>> inappropriate field access will propagate the exception to the >>>>> interpreter. Changing ciField::will_link() will most likely kill >>>>> (some) >>>>> compilations (if, e.g., fields are linked through >>>>> ciField::will_link()). >>>>> >>>>> I'd prefer to take the second option (changing field resolution), but >>>>> there might be some disadvantages related to option I might be >>>>> overseeing. >>>> >>>> >>>> >>>> >>>>> >>>>> Thank you! >>>>> >>>>> Best regards, >>>>> >>>>> >>>>> Zoltan >>>>> >>>>> >>>>>> >>>>>>> More details about the failure are here [3]. >>>>>>> >>>>>>> With the patch applied, the program always completes as it is >>>>>>> expected >>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed >>>>>>> (because we >>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>> >>>>>>> Here is the updated webrev: >>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>> Bailing out the whole compilation in C2 is even less appropriate. It >>>>>> should generate an uncommon trap for such accesses instead (see >>>>>> Parse::do_field_access). >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> [1] >>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>> From zoltan.majo at oracle.com Wed Jun 8 17:53:42 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 8 Jun 2016 19:53:42 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <2074215461.1970597.1464886502016.JavaMail.zimbra@u-pem.fr> References: <573C2DAD.1030903@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <2074215461.1970597.1464886502016.JavaMail.zimbra@u-pem.fr> Message-ID: <57585BA6.8000002@oracle.com> Hi R?mi, On 06/02/2016 06:55 PM, forax at univ-mlv.fr wrote: > [...] > I fully understand your concerns. And thank you for sharing your asserts! > > Let's see what others think about how to go about this problem. So far > the following options were explored > - bail out compilation of non-compliant methods; > - enforce JVMS conformance for all classes and keep constant folding > enabled; > - enforce JVMS conformance only for classes with _major_version >=52 and > completely disable constant folding. > > I'm not sure which option is the best. Also, there might be other > options as well. > what about bailing out compilation of non-compliant methods if major <= 52 or if a backward compat flag is set and enforcing the JVMS spec for major >= 53 ? In the latest webrev (webrev.06) compilation is not bailed out for non-compliant methods, only constant folding is disabled. The JVMS is enforced for version >= 51 (the exact version is subject to discussion). Please see the latest webrev (webrev.06) in my reply to Vladimir K. Thank you and best regards, Zolt?n >> Thank you and best regards, >> >> >> Zoltan > R?mi > >>>> We could relax that criteria, e.g., by disabling folding only for those >>>> field that were declared in a class with _major_version < 52. But it >>>> would be great if you could give me some feedback before I look into >>>> that. Thank you very much in advance! >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.05/ >>>> >>>> Testing: JPRT in progress. >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>> R?mi >>> >>>>> Thank you and best regards, >>>>> >>>>> >>>>> Zoltan >>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>>> I agree with you, alternatively we can propose a more generic fix (fix >>>>>>> the interpreter and the compilers as well). The fix would most likely >>>>>>> affect field resolution in LinkResolver::resolve_field() around here: >>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>>>> inappropriate field access will propagate the exception to the >>>>>>> interpreter. Changing ciField::will_link() will most likely kill (some) >>>>>>> compilations (if, e.g., fields are linked through >>>>>>> ciField::will_link()). >>>>>>> >>>>>>> I'd prefer to take the second option (changing field resolution), but >>>>>>> there might be some disadvantages related to option I might be >>>>>>> overseeing. >>>>>>> Thank you! >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> >>>>>>> Zoltan >>>>>>> >>>>>>> >>>>>>>>> More details about the failure are here [3]. >>>>>>>>> >>>>>>>>> With the patch applied, the program always completes as it is >>>>>>>>> expected >>>>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed (because we >>>>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>>>> >>>>>>>>> Here is the updated webrev: >>>>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>>>> Bailing out the whole compilation in C2 is even less appropriate. It >>>>>>>> should generate an uncommon trap for such accesses instead (see >>>>>>>> Parse::do_field_access). >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>> [1] >>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>>>>> >>>>>>>> From zoltan.majo at oracle.com Wed Jun 8 17:55:06 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 8 Jun 2016 19:55:06 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> Message-ID: <57585BFA.4040806@oracle.com> Hi Tom, thank you for your input and suggestions! Please see comments inline. On 06/02/2016 07:51 PM, Tom Rodriguez wrote: >>>> Therefore, in the current webrev, I've disabled folding of accesses to >>>> all non-stable fields. >>> Please do not do that, it will be a huge regression in term of perf >>> at least for the language runtimes i maintain >>> (and i suppose for Nashorn, JRuby or Groovy), Here are the perf >>> assertions i use routinely, >>> static final method handle is considered as constant, final fields >>> (even not static) of VM anonymous class is considered as truly final. >>> >> >> I fully understand your concerns. And thank you for sharing your asserts! > > The folding within the compiler should be handled differently since > the concerns are different and removing it will likely cause > invokeynamic performance to collapse. The compiler is only folding > final instance fields that are part of a chain of constants, so the > main concern is whether an object has been published before it?s been > fully constructed or if someone is going to use reflection to modify a > final field after the object has been published. > The trust_final_non_static_fields logic in ciField.cpp is calling out > classes which we control that shouldn?t violate those rules and that > are important for performance. So I think it should be left as is. > It really doesn?t relate to the issue at hand I think. Thank you for clarifying -- I agree and won't touch the folding of final instance fields. > > Also you?ve removed folding of static final fields which would be a > very bad thing to do. Yes, you're right. But I was curious of how much degradation does the removal of folding (most) static final fields cause. So, *as a side experiment*, I have changed the logic controlling folding of static final fields [1] from _is_constant = true; to _is_constant = is_stable_field || trust_final_non_static_fields(_holder); (that is similar to what we do for instance final fields). SPECjvm2008 is unaffected. For the Octane benchmarks we get <10% degradation in 66/70 different configurations, <20% degradation in the remaining cases. The experiment was done on the side and related changes are not included in the newest webrev (webrev.06). > > ciField has some caching logic for _known_to_link_with_get/set and if > you are adding a ciMethod* argument you also need to cache the method > that was checked last time as well. Thanks for pointing that out! I've addressed the caching of methods in the webrev.06 (URL in my reply to Vladimir K.) Best regards, Zoltan [1]: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/84ff58dfd5e0/src/share/vm/ci/ciField.cpp#l256 > > tom > >> >> Let's see what others think about how to go about this problem. So >> far the following options were explored >> - bail out compilation of non-compliant methods; >> - enforce JVMS conformance for all classes and keep constant folding >> enabled; >> - enforce JVMS conformance only for classes with _major_version >=52 >> and completely disable constant folding. >> >> I'm not sure which option is the best. Also, there might be other >> options as well. >> >> Thank you and best regards, >> >> >> Zoltan >> >> >> >>>> We could relax that criteria, e.g., by disabling folding only for those >>>> field that were declared in a class with _major_version < 52. But it >>>> would be great if you could give me some feedback before I look into >>>> that. Thank you very much in advance! >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.05/ >>>> >>>> >>>> Testing: JPRT in progress. >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>> R?mi >>> >>>>> Thank you and best regards, >>>>> >>>>> >>>>> Zoltan >>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>>> I agree with you, alternatively we can propose a more generic >>>>>>> fix (fix >>>>>>> the interpreter and the compilers as well). The fix would most >>>>>>> likely >>>>>>> affect field resolution in LinkResolver::resolve_field() around >>>>>>> here: >>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>>>> inappropriate field access will propagate the exception to the >>>>>>> interpreter. Changing ciField::will_link() will most likely kill >>>>>>> (some) >>>>>>> compilations (if, e.g., fields are linked through >>>>>>> ciField::will_link()). >>>>>>> >>>>>>> I'd prefer to take the second option (changing field >>>>>>> resolution), but >>>>>>> there might be some disadvantages related to option I might be >>>>>>> overseeing. >>>>>> >>>>>> >>>>>> >>>>>>> Thank you! >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> >>>>>>> Zoltan >>>>>>> >>>>>>> >>>>>>>>> More details about the failure are here [3]. >>>>>>>>> >>>>>>>>> With the patch applied, the program always completes as it is >>>>>>>>> expected >>>>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed >>>>>>>>> (because we >>>>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>>>> >>>>>>>>> Here is the updated webrev: >>>>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>>>>> >>>>>>>> Bailing out the whole compilation in C2 is even less >>>>>>>> appropriate. It >>>>>>>> should generate an uncommon trap for such accesses instead (see >>>>>>>> Parse::do_field_access). >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>> [1] >>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 > From zoltan.majo at oracle.com Wed Jun 8 18:00:10 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 8 Jun 2016 20:00:10 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <57510383.4090506@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> Message-ID: <57585D2A.3010906@oracle.com> Hi Vladimir, thank you for the feedback! On 06/03/2016 06:11 AM, Vladimir Kozlov wrote: > How about only fixing C1 to take into account the store (or not > constant fold in such case) because it was allowed before JVMS-7? before JVMS-7, any method of a class 'C' (not just the class initializer) is allowed to modify a *static* final field 'C::f' of that class. The same is true for *instance* final fields (any method, not only constructors, is allowed to modify them). So, to avoid problems similar to the current one, we would have to disable constant folding completely if JVMS-7 is not enforced by the VM. That is not a walkable path due to performance reasons. Fortunately, there are *very few* classes that "misbehave" the above way. (So far I've seen *only two* such classes, Jython and a single JCK test, although I've run all pre-PIT testing with -Xcomp and -Xmixed.) So, a solution would be to detect misbehaving fields and disable constant folding only for those fields. And that is what the latest webrev (webrev.06) does. To summarize, webrev.06 - *detects misbehaving fields in the verifier* for classes with version < JAVA_7_VERSION and *disables constant folding for those fields only*; - *enforces JVMS-7 conformance* for classes with version >= JAVA_7_VERSION and *leaves constant folding as it is* (no performance impact). As I mentioned to David Holmes, we can use JAVA_8_VERSION or JAVA_9_VERSION instead of JAVA_7_VERSION. I'm currently running pre-PIT RBT to see if there are any problems with our testbase. Performance runs are also in progress. Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8157181/webrev.06/ Testing: - JPRT; - local testing with reproducer (verified that interpreter/compiled code behave the same way); - pre-PIT RBT in progress. > > And file a separate issue for JVMS-7 conformance. It looks like it may > have huge impact on performance and we are already very late in JDK 9 > development to make such changes in rush. I agree that the two issues can be treated as unrelated. But, for now, I'd like to keep them together as by fixing them together we cover both the > JAVA_7_VERSION and the <= JAVA_7_VERSION case at the same time. The performance runs (in progress) show that the fix has no performance impact (because we disable constant folding in very rare cases). I'll report all numbers once they become available. > > Zoltan, what C2 does in such case? I can reproduce the problem only with -Xcomp. With -Xcomp, there is not enough profiling information available for C2 to compile the problematic bytecode. Thus, C2 deoptimizes before execution proceeds to that bytecode. But C2 folds final fields as well, therefore C2-compiled methods can also be negatively impacted if final fields chang after they have been initialized. Fortunately, with the current fix we have to disable folding only in very rare cases. Thank you! Best regards, Zoltan > Tom, what Graal does in such case? > > The case is: > > https://bugs.openjdk.java.net/browse/JDK-8157181?focusedCommentId=13942824&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13942824 > > > "While compiling bytecode @29, the C1 compiler assumes that the value > of the _pyx0.self field has already been set in the class initializer > method (as the class is initialized). The C1 compiler also > assumes that the field will not change (as it is static final). > Therefore, the C1 compiler omits reading the field _pyx0.self and > passes the current value of the field ('null') to the > org/python/core/Py.newCode() method called at bytecode @37. (The > correct value would be 'this'.)" > > Thanks, > Vladimir > > On 6/2/16 10:51 AM, Tom Rodriguez wrote: >>>>> Therefore, in the current webrev, I've disabled folding of >>>>> accesses to >>>>> all non-stable fields. >>>> Please do not do that, it will be a huge regression in term of perf >>>> at least for the language runtimes i maintain >>>> (and i suppose for Nashorn, JRuby or Groovy), Here are the perf >>>> assertions i use routinely, >>>> static final method handle is considered as constant, final fields >>>> (even not static) of VM anonymous class is considered as truly final. >>>> >>> >>> I fully understand your concerns. And thank you for sharing your >>> asserts! >> >> The folding within the compiler should be handled differently since >> the concerns are different and removing it will likely cause >> invokeynamic performance to collapse. The compiler is only folding >> final instance fields that are part of a chain of constants, so the >> main concern is whether an object has been published before it?s been >> fully constructed or if someone is going to use reflection to >> modify a final field after the object has been published. The >> trust_final_non_static_fields logic in ciField.cpp is calling out >> classes which we control that shouldn?t violate those rules and that >> are important for performance. So I think it should be left as is. >> It really doesn?t relate to the issue at hand I think. >> >> Also you?ve removed folding of static final fields which would be a >> very bad thing to do. >> >> ciField has some caching logic for _known_to_link_with_get/set and if >> you are adding a ciMethod* argument you also need to cache the method >> that was checked last time as well. >> >> tom >> >>> >>> Let's see what others think about how to go about this problem. So >>> far the following options were explored >>> - bail out compilation of non-compliant methods; >>> - enforce JVMS conformance for all classes and keep constant folding >>> enabled; >>> - enforce JVMS conformance only for classes with _major_version >=52 >>> and completely disable constant folding. >>> >>> I'm not sure which option is the best. Also, there might be other >>> options as well. >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> >>> >>> >>>>> We could relax that criteria, e.g., by disabling folding only for >>>>> those >>>>> field that were declared in a class with _major_version < 52. But it >>>>> would be great if you could give me some feedback before I look into >>>>> that. Thank you very much in advance! >>>>> >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.05/ >>>>> >>>>> Testing: JPRT in progress. >>>>> >>>>> Best regards, >>>>> >>>>> >>>>> Zoltan >>>> R?mi >>>> >>>>>> Thank you and best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>>> I agree with you, alternatively we can propose a more generic >>>>>>>> fix (fix >>>>>>>> the interpreter and the compilers as well). The fix would most >>>>>>>> likely >>>>>>>> affect field resolution in LinkResolver::resolve_field() around >>>>>>>> here: >>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>>>>> inappropriate field access will propagate the exception to the >>>>>>>> interpreter. Changing ciField::will_link() will most likely >>>>>>>> kill (some) >>>>>>>> compilations (if, e.g., fields are linked through >>>>>>>> ciField::will_link()). >>>>>>>> >>>>>>>> I'd prefer to take the second option (changing field >>>>>>>> resolution), but >>>>>>>> there might be some disadvantages related to option I might be >>>>>>>> overseeing. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Thank you! >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> >>>>>>>> Zoltan >>>>>>>> >>>>>>>> >>>>>>>>>> More details about the failure are here [3]. >>>>>>>>>> >>>>>>>>>> With the patch applied, the program always completes as it is >>>>>>>>>> expected >>>>>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed >>>>>>>>>> (because we >>>>>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>>>>> >>>>>>>>>> Here is the updated webrev: >>>>>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>>>>> Bailing out the whole compilation in C2 is even less >>>>>>>>> appropriate. It >>>>>>>>> should generate an uncommon trap for such accesses instead (see >>>>>>>>> Parse::do_field_access). >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Vladimir Ivanov >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>>>>>> >> From zoltan.majo at oracle.com Wed Jun 8 18:01:12 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 8 Jun 2016 20:01:12 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> Message-ID: <57585D68.7030108@oracle.com> Hi Vladimir, thank you for the feedback (both on the mailing list and in private)! On 06/03/2016 12:48 PM, Vladimir Ivanov wrote: > > > On 6/3/16 7:11 AM, Vladimir Kozlov wrote: >> How about only fixing C1 to take into account the store (or not constant >> fold in such case) because it was allowed before JVMS-7? >> >> And file a separate issue for JVMS-7 conformance. It looks like it may >> have huge impact on performance and we are already very late in JDK 9 >> development to make such changes in rush. > > Yes, let's separate them (considering the difference in impact) and > align the JVM behavior with the JVMS separately. As I mentioned to Vladimir K, I would like to keep the two issues together (at least for now). That way we have a fix that covers both cases > JAVA_7_VERSION and <= JAVA_7_VERSION at once. > > For now, disabling constant folding of static/instance field loads in > static/instance initializers should solve the immediate problem for > well-behaved (according to JVMS) programs. Also, such change should > not cause any performance regressions. > > Considering it is possible to update static final fields through > Reflection API, I don't see JVMS conformance issue (ability to update > final static fields outside of static initializer on bytecode level) > as a problem of the same level for JIT-compilers. It can be fixed as > part of aligning the JVM with JVMS (but still in JDK9). I hope I've addressed your comments in my replies to other people. Can you please let me know, if not? Thank you! Best regards, Zoltan > > Best regards, > Vladimir Ivanov > >> >> Zoltan, what C2 does in such case? >> Tom, what Graal does in such case? >> >> The case is: >> >> https://bugs.openjdk.java.net/browse/JDK-8157181?focusedCommentId=13942824&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13942824 >> >> >> >> "While compiling bytecode @29, the C1 compiler assumes that the value of >> the _pyx0.self field has already been set in the class initializer >> method (as the class is initialized). The C1 compiler also >> assumes that the field will not change (as it is static final). >> Therefore, the C1 compiler omits reading the field _pyx0.self and passes >> the current value of the field ('null') to the >> org/python/core/Py.newCode() method called at bytecode @37. (The correct >> value would be 'this'.)" >> >> Thanks, >> Vladimir >> >> On 6/2/16 10:51 AM, Tom Rodriguez wrote: >>>>>> Therefore, in the current webrev, I've disabled folding of >>>>>> accesses to >>>>>> all non-stable fields. >>>>> Please do not do that, it will be a huge regression in term of perf >>>>> at least for the language runtimes i maintain >>>>> (and i suppose for Nashorn, JRuby or Groovy), Here are the perf >>>>> assertions i use routinely, >>>>> static final method handle is considered as constant, final fields >>>>> (even not static) of VM anonymous class is considered as truly final. >>>>> >>>> >>>> I fully understand your concerns. And thank you for sharing your >>>> asserts! >>> >>> The folding within the compiler should be handled differently since >>> the concerns are different and removing it will likely cause >>> invokeynamic performance to collapse. The compiler is only folding >>> final instance fields that are part of a chain of constants, so the >>> main concern is whether an object has been published before it?s been >>> fully constructed or if someone is going to use reflection to >>> modify a final field after the object has been published. The >>> trust_final_non_static_fields logic in ciField.cpp is calling out >>> classes which we control that shouldn?t violate those rules and that >>> are important for performance. So I think it should be left as is. >>> It really doesn?t relate to the issue at hand I think. >>> >>> Also you?ve removed folding of static final fields which would be a >>> very bad thing to do. >>> >>> ciField has some caching logic for _known_to_link_with_get/set and if >>> you are adding a ciMethod* argument you also need to cache the method >>> that was checked last time as well. >>> >>> tom >>> >>>> >>>> Let's see what others think about how to go about this problem. So >>>> far the following options were explored >>>> - bail out compilation of non-compliant methods; >>>> - enforce JVMS conformance for all classes and keep constant folding >>>> enabled; >>>> - enforce JVMS conformance only for classes with _major_version >=52 >>>> and completely disable constant folding. >>>> >>>> I'm not sure which option is the best. Also, there might be other >>>> options as well. >>>> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> >>>> >>>> >>>>>> We could relax that criteria, e.g., by disabling folding only for >>>>>> those >>>>>> field that were declared in a class with _major_version < 52. But it >>>>>> would be great if you could give me some feedback before I look into >>>>>> that. Thank you very much in advance! >>>>>> >>>>>> Updated webrev: >>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.05/ >>>>>> >>>>>> Testing: JPRT in progress. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>> R?mi >>>>> >>>>>>> Thank you and best regards, >>>>>>> >>>>>>> >>>>>>> Zoltan >>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>>> I agree with you, alternatively we can propose a more generic >>>>>>>>> fix (fix >>>>>>>>> the interpreter and the compilers as well). The fix would most >>>>>>>>> likely >>>>>>>>> affect field resolution in LinkResolver::resolve_field() around >>>>>>>>> here: >>>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>>>>>> inappropriate field access will propagate the exception to the >>>>>>>>> interpreter. Changing ciField::will_link() will most likely kill >>>>>>>>> (some) >>>>>>>>> compilations (if, e.g., fields are linked through >>>>>>>>> ciField::will_link()). >>>>>>>>> >>>>>>>>> I'd prefer to take the second option (changing field >>>>>>>>> resolution), but >>>>>>>>> there might be some disadvantages related to option I might be >>>>>>>>> overseeing. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Thank you! >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> >>>>>>>>> Zoltan >>>>>>>>> >>>>>>>>> >>>>>>>>>>> More details about the failure are here [3]. >>>>>>>>>>> >>>>>>>>>>> With the patch applied, the program always completes as it is >>>>>>>>>>> expected >>>>>>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed >>>>>>>>>>> (because we >>>>>>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>>>>>> >>>>>>>>>>> Here is the updated webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>>>>>> Bailing out the whole compilation in C2 is even less >>>>>>>>>> appropriate. It >>>>>>>>>> should generate an uncommon trap for such accesses instead (see >>>>>>>>>> Parse::do_field_access). >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Vladimir Ivanov >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>>>>>>> >>>>>>>>>> >>> From stefan.johansson at oracle.com Thu Jun 9 08:21:37 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 9 Jun 2016 10:21:37 +0200 Subject: RFR: 8146530: [testbug] some tests fail because the compiler is using Java heap memory In-Reply-To: <29b45368-547d-9df3-31dc-0090f0629067@oracle.com> References: <5757E578.3010509@oracle.com> <29b45368-547d-9df3-31dc-0090f0629067@oracle.com> Message-ID: <57592711.6090400@oracle.com> Thanks Vladimir, Jon and Jesper, I'll remove that requires for EnableJVMCI and update copyrights before pushing. Stefan On 2016-06-08 18:10, Vladimir Kozlov wrote: > Only UseJVMCICompiler triggers usage of java compiler. > > EnableJVMCI is false only on embedded platforms as result you will not > run the test at all if you check it. Please, remove this check. > > Thanks, > Vladimir > > On 6/8/16 2:29 AM, Stefan Johansson wrote: >> Hi all, >> >> Please review this test fix for: >> https://bugs.openjdk.java.net/browse/JDK-8146530 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8146530/hotspot.00/ >> >> Summary: >> This test seems to fail because of two things. Either because it is >> executed with +ExplicitGCInvokesConcurrent or that a Java compiler is >> used via JVMCI. The suggested fix is to use @requires to avoid running >> the test with these options. >> >> The reason ExplicitGCInvokesConcurrent fails the test is because the >> test is written to rely on calling System.gc() to have a clear view when >> starting the test, and if this call instead starts a concurrent cycle >> the test might fail. >> >> Using JVMCI causes the test to fail because it leads to unexpected >> amount of allocated data and there for the assumptions made by the test >> does not hold. >> >> Testing: >> Verified that the test is not executed when these options are given on >> the command-line. >> >> Thanks, >> Stefan From vladimir.x.ivanov at oracle.com Thu Jun 9 11:28:23 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 9 Jun 2016 14:28:23 +0300 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <57585D2A.3010906@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> Message-ID: Zoltan, > To summarize, webrev.06 > - *detects misbehaving fields in the verifier* for classes with version > < JAVA_7_VERSION and *disables constant folding for those fields only*; > - *enforces JVMS-7 conformance* for classes with version >= > JAVA_7_VERSION and *leaves constant folding as it is* (no performance > impact). > > As I mentioned to David Holmes, we can use JAVA_8_VERSION or > JAVA_9_VERSION instead of JAVA_7_VERSION. Agree. > I'm currently running pre-PIT RBT to see if there are any problems with > our testbase. Performance runs are also in progress. > > Here is the updated webrev: > http://cr.openjdk.java.net/~zmajo/8157181/webrev.06/ I really like how it shapes out! Some comments follow: Unfortunately, it doesn't (and, moreover, can't) cover class redefinition: if a new version of a method contains final field update, all the generated code which embed previous value should be invalidated. The only way to handle such case now is to add nmethod dependencies when static final field loads are constant folded. Please, file a separate bug (P4) for that and let's decide how to proceed with it later. --- src/share/vm/classfile/verifier.cpp: + void Verifier::detect_invalid_final_field_accesses(instanceKlassHandle klass) { The name is misleading: such accesses are legal according to JVMS-6 (and earlier). Maybe something like detect_initialized_final_field_updates? Same for: + bool has_invalid_final_access() const { return access_flags().has_field_invalid_final_access(); } + void set_has_invalid_final_access(const bool value) { + JVM_ACC_FIELD_INVALID_FINAL_ACCESS = 0x00000100, --- Why do you care about _nofast_putfield? The bytecode hasn't been rewritten yet. + if (klass()->major_version() < 51 && !klass->is_rewritten()) { ... + if (opcode == Bytecodes::_putstatic || opcode == Bytecodes::_putfield || opcode == Bytecodes::_nofast_putfield) { --- Also, I don't think in its current shape it is part of verification, but instanceKlass linkage phase instead: bool InstanceKlass::link_class_impl( instanceKlassHandle this_k, bool throw_verifyerror, TRAPS) { ... if (!this_k->is_linked()) { if (!this_k->is_rewritten()) { { bool verify_ok = verify_code(this_k, throw_verifyerror, THREAD); if (!verify_ok) { return false; } } ... << HERE >> ... // also sets rewritten this_k->rewrite_class(CHECK_false); --- I don't see much benefit in tracking the problematic updates per-methods and not per-class. So, you could do the checks in ClassVerifier::verify_field_instructions [1] and mark the whole class (ClassVerifier::_klass) as containing problematic instructions. --- src/share/vm/interpreter/linkResolver.cpp: THROW(vmSymbols::java_lang_IllegalAccessError()); + THROW(vmSymbols::java_lang_IllegalAccessError()); Please, add an error message for diagnostic purposes. --- src/share/vm/ci/ciField.cpp: - if (_known_to_link_with_put == accessing_klass) { + if (_known_to_link_with_put_klass == accessing_klass && _known_to_link_with_put_method) { Don't you need to check _known_to_link_with_put_method with accessing_method? Why don't you use accessing_method instead of accessing_klass and migrate _known_to_link_with_put/get to ciMethod*? bool will_link(ciMethod* accessing_method, Bytecodes::Code bc); I looked at all will_link usages and accessing_method is always available. Otherwise, looks good! Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/84ff58dfd5e0/src/share/vm/classfile/verifier.cpp#l2226 From zoltan.majo at oracle.com Thu Jun 9 14:00:19 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 9 Jun 2016 16:00:19 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> Message-ID: <57597673.4070103@oracle.com> Hi Vladimir, thank you for the feedback! Please see comments inline. On 06/09/2016 01:28 PM, Vladimir Ivanov wrote: > Zoltan, > >> To summarize, webrev.06 >> - *detects misbehaving fields in the verifier* for classes with version >> < JAVA_7_VERSION and *disables constant folding for those fields only*; >> - *enforces JVMS-7 conformance* for classes with version >= >> JAVA_7_VERSION and *leaves constant folding as it is* (no performance >> impact). >> >> As I mentioned to David Holmes, we can use JAVA_8_VERSION or >> JAVA_9_VERSION instead of JAVA_7_VERSION. > > Agree. OK. > >> I'm currently running pre-PIT RBT to see if there are any problems with >> our testbase. Performance runs are also in progress. >> >> Here is the updated webrev: >> http://cr.openjdk.java.net/~zmajo/8157181/webrev.06/ > > I really like how it shapes out! Thank you, I'm glad to hear that! > > Some comments follow: > > Unfortunately, it doesn't (and, moreover, can't) cover class > redefinition: if a new version of a method contains final field > update, all the generated code which embed previous value should be > invalidated. > > The only way to handle such case now is to add nmethod dependencies > when static final field loads are constant folded. > > Please, file a separate bug (P4) for that and let's decide how to > proceed with it later. OK, I've filed JDK-8159150 [1]. > > --- > src/share/vm/classfile/verifier.cpp: > > + void > Verifier::detect_invalid_final_field_accesses(instanceKlassHandle > klass) { > > The name is misleading: such accesses are legal according to JVMS-6 > (and earlier). Maybe something like > detect_initialized_final_field_updates? > > Same for: > + bool has_invalid_final_access() const { return > access_flags().has_field_invalid_final_access(); } > + void set_has_invalid_final_access(const bool value) { > + JVM_ACC_FIELD_INVALID_FINAL_ACCESS = 0x00000100, > Yes, that name sounds better and I've updated the code accordingly. > > --- > Why do you care about _nofast_putfield? The bytecode hasn't been > rewritten yet. > > + if (klass()->major_version() < 51 && !klass->is_rewritten()) { > ... > + if (opcode == Bytecodes::_putstatic || opcode == > Bytecodes::_putfield || opcode == Bytecodes::_nofast_putfield) { That is a mistake, I've removed the condition related to _nofast_putfield. > > --- > Also, I don't think in its current shape it is part of verification, > but instanceKlass linkage phase instead: > > bool InstanceKlass::link_class_impl( > instanceKlassHandle this_k, bool throw_verifyerror, TRAPS) { > ... > if (!this_k->is_linked()) { > if (!this_k->is_rewritten()) { > { > bool verify_ok = verify_code(this_k, throw_verifyerror, > THREAD); > if (!verify_ok) { > return false; > } > } > ... > << HERE >> > ... > // also sets rewritten > this_k->rewrite_class(CHECK_false); I agree and have updated the code. > > --- > I don't see much benefit in tracking the problematic updates > per-methods and not per-class. So, you could do the checks in > ClassVerifier::verify_field_instructions [1] and mark the whole class > (ClassVerifier::_klass) as containing problematic instructions. The problematic updates are tracked *per-field* (and not *per-method* or * per-class*). Initially, I had a version that tracked problematic instructions on a per-class basis. With that version, once a problematic instruction was detected, the whole class was marked as containing problematic instructions. As a result, constant folding was disabled for accesses to *all* final fields of that class. Tracking problematic updates on a per-field basis seems to be less intrusive. That way we disable folding *only for fields to which problematic accesses are made* (and leave constant folding enabled for accesses to all other fields). So we can fold some accesses even for "misbehaving" classes. I hope that is fine. Regarding doing checks in verify_field_instructions() [2]: It turns out that we have two verifiers, one that is called for major_version >= STACKMAP_ATTRIBUTE_MAJOR_VERSION and a second one that is called for major_version < STACKMAP_ATTRIBUTE_MAJOR_VERSION. ClassVerifier::verify_field_instructions() is called only for class files >= STACKMAP_ATTRIBUTE_MAJOR_VERSION so we need to call detect_initialized_final_field_updates() after verification. But I think it is a good idea to move the check to the linkage phase (as you've suggested above). > > --- > src/share/vm/interpreter/linkResolver.cpp: > > THROW(vmSymbols::java_lang_IllegalAccessError()); > > + THROW(vmSymbols::java_lang_IllegalAccessError()); > > Please, add an error message for diagnostic purposes. OK, I did that. > > --- > src/share/vm/ci/ciField.cpp: > > - if (_known_to_link_with_put == accessing_klass) { > + if (_known_to_link_with_put_klass == accessing_klass && > _known_to_link_with_put_method) { > > Don't you need to check _known_to_link_with_put_method with > accessing_method? Sure I do. Thank you for catching that mistake. > > Why don't you use accessing_method instead of accessing_klass and > migrate _known_to_link_with_put/get to ciMethod*? > > bool will_link(ciMethod* accessing_method, Bytecodes::Code bc); > > I looked at all will_link usages and accessing_method is always > available. That is a good idea. I've removed the parameter accessing_klass and use only accessing_method. For put bytecodes, the VM caches the accessing method. For get bytecodes, it is sufficient to cache the accessing klass; we derive the accessing klass from the accessing _method. Please let me know if you think we should proceed differently. Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8157181/webrev.07/ JPRT is in progress. > > > Otherwise, looks good! Thanks a lot! Best regards, Zoltan [1] https://bugs.openjdk.java.net/browse/JDK-8159150 [2] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/84ff58dfd5e0/src/share/vm/classfile/verifier.cpp#l173 > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/84ff58dfd5e0/src/share/vm/classfile/verifier.cpp#l2226 From zoltan.majo at oracle.com Thu Jun 9 14:03:20 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 9 Jun 2016 16:03:20 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <57585D2A.3010906@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> Message-ID: <57597728.1030604@oracle.com> Hi, On 06/08/2016 08:00 PM, Zolt?n Maj? wrote: > [...] > I'm currently running pre-PIT RBT to see if there are any problems > with our testbase. Performance runs are also in progress. Just to report on the performance/correctness results: The change does not cause any performance regression; pre-PIT RBT completed successfully. Thank you! Best regards, Zoltan > > Here is the updated webrev: > http://cr.openjdk.java.net/~zmajo/8157181/webrev.06/ > > Testing: > - JPRT; > - local testing with reproducer (verified that interpreter/compiled > code behave the same way); > - pre-PIT RBT in progress. > > >> >> And file a separate issue for JVMS-7 conformance. It looks like it >> may have huge impact on performance and we are already very late in >> JDK 9 development to make such changes in rush. > > I agree that the two issues can be treated as unrelated. But, for now, > I'd like to keep them together as by fixing them together we cover > both the > JAVA_7_VERSION and the <= JAVA_7_VERSION case at the same > time. > > The performance runs (in progress) show that the fix has no > performance impact (because we disable constant folding in very rare > cases). I'll report all numbers once they become available. > >> >> Zoltan, what C2 does in such case? > > I can reproduce the problem only with -Xcomp. With -Xcomp, there is > not enough profiling information available for C2 to compile the > problematic bytecode. Thus, C2 deoptimizes before execution proceeds > to that bytecode. > > But C2 folds final fields as well, therefore C2-compiled methods can > also be negatively impacted if final fields chang after they have been > initialized. Fortunately, with the current fix we have to disable > folding only in very rare cases. > > Thank you! > > Best regards, > > > Zoltan > >> Tom, what Graal does in such case? >> >> The case is: >> >> https://bugs.openjdk.java.net/browse/JDK-8157181?focusedCommentId=13942824&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13942824 >> >> >> "While compiling bytecode @29, the C1 compiler assumes that the value >> of the _pyx0.self field has already been set in the class initializer >> method (as the class is initialized). The C1 compiler also >> assumes that the field will not change (as it is static final). >> Therefore, the C1 compiler omits reading the field _pyx0.self and >> passes the current value of the field ('null') to the >> org/python/core/Py.newCode() method called at bytecode @37. (The >> correct value would be 'this'.)" >> >> Thanks, >> Vladimir >> >> On 6/2/16 10:51 AM, Tom Rodriguez wrote: >>>>>> Therefore, in the current webrev, I've disabled folding of >>>>>> accesses to >>>>>> all non-stable fields. >>>>> Please do not do that, it will be a huge regression in term of >>>>> perf at least for the language runtimes i maintain >>>>> (and i suppose for Nashorn, JRuby or Groovy), Here are the perf >>>>> assertions i use routinely, >>>>> static final method handle is considered as constant, final fields >>>>> (even not static) of VM anonymous class is considered as truly final. >>>>> >>>> >>>> I fully understand your concerns. And thank you for sharing your >>>> asserts! >>> >>> The folding within the compiler should be handled differently since >>> the concerns are different and removing it will likely cause >>> invokeynamic performance to collapse. The compiler is only folding >>> final instance fields that are part of a chain of constants, so the >>> main concern is whether an object has been published before it?s >>> been fully constructed or if someone is going to use reflection to >>> modify a final field after the object has been published. The >>> trust_final_non_static_fields logic in ciField.cpp is calling out >>> classes which we control that shouldn?t violate those rules and that >>> are important for performance. So I think it should be left as is. >>> It really doesn?t relate to the issue at hand I think. >>> >>> Also you?ve removed folding of static final fields which would be a >>> very bad thing to do. >>> >>> ciField has some caching logic for _known_to_link_with_get/set and >>> if you are adding a ciMethod* argument you also need to cache the >>> method that was checked last time as well. >>> >>> tom >>> >>>> >>>> Let's see what others think about how to go about this problem. So >>>> far the following options were explored >>>> - bail out compilation of non-compliant methods; >>>> - enforce JVMS conformance for all classes and keep constant >>>> folding enabled; >>>> - enforce JVMS conformance only for classes with _major_version >>>> >=52 and completely disable constant folding. >>>> >>>> I'm not sure which option is the best. Also, there might be other >>>> options as well. >>>> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> >>>> >>>> >>>>>> We could relax that criteria, e.g., by disabling folding only for >>>>>> those >>>>>> field that were declared in a class with _major_version < 52. But it >>>>>> would be great if you could give me some feedback before I look into >>>>>> that. Thank you very much in advance! >>>>>> >>>>>> Updated webrev: >>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.05/ >>>>>> >>>>>> Testing: JPRT in progress. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>> R?mi >>>>> >>>>>>> Thank you and best regards, >>>>>>> >>>>>>> >>>>>>> Zoltan >>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>>> I agree with you, alternatively we can propose a more generic >>>>>>>>> fix (fix >>>>>>>>> the interpreter and the compilers as well). The fix would most >>>>>>>>> likely >>>>>>>>> affect field resolution in LinkResolver::resolve_field() >>>>>>>>> around here: >>>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>>>>>> inappropriate field access will propagate the exception to the >>>>>>>>> interpreter. Changing ciField::will_link() will most likely >>>>>>>>> kill (some) >>>>>>>>> compilations (if, e.g., fields are linked through >>>>>>>>> ciField::will_link()). >>>>>>>>> >>>>>>>>> I'd prefer to take the second option (changing field >>>>>>>>> resolution), but >>>>>>>>> there might be some disadvantages related to option I might be >>>>>>>>> overseeing. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Thank you! >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> >>>>>>>>> Zoltan >>>>>>>>> >>>>>>>>> >>>>>>>>>>> More details about the failure are here [3]. >>>>>>>>>>> >>>>>>>>>>> With the patch applied, the program always completes as it is >>>>>>>>>>> expected >>>>>>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed >>>>>>>>>>> (because we >>>>>>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>>>>>> >>>>>>>>>>> Here is the updated webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>>>>>> Bailing out the whole compilation in C2 is even less >>>>>>>>>> appropriate. It >>>>>>>>>> should generate an uncommon trap for such accesses instead (see >>>>>>>>>> Parse::do_field_access). >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Vladimir Ivanov >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>>>>>>> >>> > From chf at redhat.com Thu Jun 9 14:25:40 2016 From: chf at redhat.com (Christine Flood) Date: Thu, 9 Jun 2016 10:25:40 -0400 (EDT) Subject: Submitted JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector In-Reply-To: <20160525093308.GB23701@ehelin.jrpg.bea.com> References: <20160504075621.450403951eggemoggin.niobe.net> <729617618.2672396.1463148140398.JavaMail.zimbra@redhat.com> <20160516124402.GG32434@ehelin.jrpg.bea.com> <545560389.4790998.1464037461928.JavaMail.zimbra@redhat.com> <20160525093308.GB23701@ehelin.jrpg.bea.com> Message-ID: <1029478489.9095893.1465482340231.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Erik Helin" > To: "Christine Flood" > Cc: hotspot-dev at openjdk.java.net > Sent: Wednesday, May 25, 2016 5:33:08 AM > Subject: Re: Submitted JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector > ... > Ok, then I would like you to make sure that compiling the Shenandoah > code is controlled with a configure variable, similar to jvmci, shark, > dtrace, vm-structs, etc: > > sh configure --with-jvm-features=shenandoah > > There are some refactorings that we've done to make sharing code between G1 and Shenandoah easier. We'd like to put those back upstream as is. They make merges much simpler for us. We can isolate the Shenandoah specific barriers with a flag as you suggest but may we request that the flag be left on by default. This provides the option to turn Shenandoah off if there is an issue but provides us with more testing/exposure. Christine From max.ockner at oracle.com Thu Jun 9 18:05:02 2016 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 09 Jun 2016 14:05:02 -0400 Subject: RFR: 8038332: The trace event vm/class/load is not always being sent Message-ID: <5759AFCE.2080406@oracle.com> Hello, Please review this small fix which causes the vm/class/load event to be fired from JVM_DefineClass() and JVM_DefineClassWithSource(). Webrev: http://cr.openjdk.java.net/~mockner/8038332/ Bug: https://bugs.openjdk.java.net/browse/JDK-8038332 The vm/class/load event (EventClassLoad) was previously fired in 2 places: SystemDictionary::parse_stream SystemDictionary::resolve_instance_class_or_null parse_stream is the standard option for creating a klass from a stream, but JVM_DefineClass uses a different function: SystemDictionary::resolve_from_stream. This did not fire a vm/class/load event. Now it does fire the event. Sanity tested with jtreg runtime. Issue was reproduced and tested using the reproducer script attached to the bug Thanks, Max From jiangli.zhou at oracle.com Thu Jun 9 20:39:11 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 9 Jun 2016 13:39:11 -0700 Subject: RFR: 8038332: The trace event vm/class/load is not always being sent In-Reply-To: <5759AFCE.2080406@oracle.com> References: <5759AFCE.2080406@oracle.com> Message-ID: Hi Max, Looks ok. The only possible issue is more than one event might be sent in some of the call paths. But my quick search didn?t find any of such case. Thanks, Jiangli > On Jun 9, 2016, at 11:05 AM, Max Ockner wrote: > > Hello, > > Please review this small fix which causes the vm/class/load event to be fired from JVM_DefineClass() and JVM_DefineClassWithSource(). > > Webrev: http://cr.openjdk.java.net/~mockner/8038332/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8038332 > > The vm/class/load event (EventClassLoad) was previously fired in 2 places: > > SystemDictionary::parse_stream > SystemDictionary::resolve_instance_class_or_null > > parse_stream is the standard option for creating a klass from a stream, but JVM_DefineClass uses a different function: > > SystemDictionary::resolve_from_stream. > > This did not fire a vm/class/load event. Now it does fire the event. > > Sanity tested with jtreg runtime. Issue was reproduced and tested using the reproducer script attached to the bug > > Thanks, > Max From Leonid.Mesnik at oracle.com Thu Jun 9 21:34:27 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Fri, 10 Jun 2016 00:34:27 +0300 Subject: RFR: 8038332: The trace event vm/class/load is not always being sent In-Reply-To: <5759AFCE.2080406@oracle.com> References: <5759AFCE.2080406@oracle.com> Message-ID: <5759E0E3.7090803@oracle.com> Max Is it possible to develop regression test which parse jfr logs instead of using gdb for this bug? Leonid On 09.06.2016 21:05, Max Ockner wrote: > Hello, > > Please review this small fix which causes the vm/class/load event to > be fired from JVM_DefineClass() and JVM_DefineClassWithSource(). > > Webrev: http://cr.openjdk.java.net/~mockner/8038332/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8038332 > > The vm/class/load event (EventClassLoad) was previously fired in 2 > places: > > SystemDictionary::parse_stream > SystemDictionary::resolve_instance_class_or_null > > parse_stream is the standard option for creating a klass from a > stream, but JVM_DefineClass uses a different function: > > SystemDictionary::resolve_from_stream. > > This did not fire a vm/class/load event. Now it does fire the event. > > Sanity tested with jtreg runtime. Issue was reproduced and tested > using the reproducer script attached to the bug > > Thanks, > Max From david.holmes at oracle.com Fri Jun 10 00:59:44 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 Jun 2016 10:59:44 +1000 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <57585B76.5050809@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <988f2271-0d7e-7a02-b301-c6237f123262@oracle.com> <93b3fe16-2bb0-3e77-9333-61989f33ff1c@oracle.com> <57585B76.5050809@oracle.com> Message-ID: Hi Zoltan, On 9/06/2016 3:52 AM, Zolt?n Maj? wrote: > Hi David, > > > > On 06/02/2016 01:51 PM, David Holmes wrote: >> [...] >> The simplest, and common, approach to these kind of issues is to only >> apply the correction for the current class file version and keep the >> relaxed rules for all others. That provides the best compatibility >> story. Of course if security is a concern then that is a different >> matter - but such concerns can not be discussed here. > > thank you for the suggestion! > > In the latest webrev (webrev.06), I enable the additional check for > classfile version >= 51 (JAVA_7_VERSION). With that version, we're > conforming with the specification. So far no problems have showed up > with our test base. The new check can be disabled with the > CheckFinalFieldModifications flag (you've suggested that in your JBS > comment). > > We can also change the checked version to 52 (JAVA_8) or 53 (JAVA_9). I think this needs to go to CCC so that the compatibility issue can be examined. Normally, after long periods of non-conformance, we don't "back date" tighter checks - so my initial feeling is that this should only be enforced for Java 9 classfiles onwards. But that is not a decision for individual engineers to make. Thanks, David > Please see the updated webrev (webrev.06) in my reply to Vladimir K. > > Thank you! > > Best regards, > > > Zoltan > >> >> David >> ----- >> >>> Before JVMS-7, where putfield/putstatic linkage checks were tightened, >>> it was allowed to change final fields from anywhere in the same class. >>> >>> putfield "Linking Exceptions": >>> >>> JVMS-6 [1]: >>> "Otherwise, if the field is final, it must be declared in the >>> current class. Otherwise, an IllegalAccessError is thrown." >>> >>> JVMS-7 [2]: >>> "Otherwise, if the field is final, it must be declared in the >>> current class, and the instruction must occur in an instance >>> initialization method () of the current class. Otherwise, an >>> IllegalAccessError is thrown." >>> >>> >>> src/share/vm/interpreter/linkResolver.cpp: >>> >>> + (byte == Bytecodes::_putstatic && fd.is_static() && >>> method_name != vmSymbols::class_initializer_name()) || >>> + ((byte == Bytecodes::_putfield || byte == >>> Bytecodes::_nofast_putfield) && !fd.is_static() && method_name != >>> vmSymbols::object_initializer_name()) >>> >>> >>> Also, as we found earlier, checking method name is not enough: >>> >>> bool Method::is_static_initializer() const { >>> // For classfiles version 51 or greater, ensure that the clinit >>> method is >>> // static. Non-static methods with the name "" are not static >>> // initializers. (older classfiles exempted for backward >>> compatibility) >>> return name() == vmSymbols::class_initializer_name() && >>> has_valid_initializer_flags(); >>> } >>> >>> >>> - LinkInfo link_info(defc, name, type, KlassHandle(), >>> /*check_access=*/false); >>> + LinkInfo link_info(defc, name, type, KlassHandle(), NULL, >>> /*check_access=*/false); >>> >>> Use Handle() instead of NULL. >>> >>> Also, I'd prefer to see LinkInfo::_current_method and new constructor >>> added: >>> >>> LinkInfo(KlassHandle resolved_klass, Symbol* name, Symbol* signature, >>> Handle current_method, bool check_access = true) : >>> >>> _current_klass can be derived from _current_method, since: >>> >>> // current_klass = sending method holder (i.e., class containing the >>> method >>> // containing the call being resolved) >>> >>>> I did the following testing: >>>> - JPRT >>>> - pre-PIT RBT run (in progress) >>>> - the reproducer. >>>> >>>> The reproducer now behaves as expected (an IllegalAccessError is >>>> thrown). Also, the pre-PIT RBT run has shown no new failures so far. >>>> >>>> But there is a problem with JPRT: A JCK test, putstatic01801m, fails. >>>> >>>> The reason for the failure is that the the test generates a method that >>>> contains a putstatic to a static final field (i.e., the bytecodes >>>> generated by the test do not conform to the JVMS). (Even the test >>>> mentions that the Java source equivalent to the generated bytecodes is >>>> compilable only if the "final" keyword is removed from the declaration >>>> of the static field.) >>>> >>>> So (if we decide to push the current fix) the issue with the test needs >>>> to be fixed first. Do you know how we could proceed with that? >>> File a bug against JCK. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] >>> https://docs.oracle.com/javase/specs/jvms/se6/html/Instructions2.doc11.html >>> >>> >>> [2] >>> https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.putfield >>> >>> >>> >>> [3] >>> https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4.3.2 >>> >>> >>>> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>>> >>>>>> I agree with you, alternatively we can propose a more generic fix >>>>>> (fix >>>>>> the interpreter and the compilers as well). The fix would most likely >>>>>> affect field resolution in LinkResolver::resolve_field() around here: >>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>>> inappropriate field access will propagate the exception to the >>>>>> interpreter. Changing ciField::will_link() will most likely kill >>>>>> (some) >>>>>> compilations (if, e.g., fields are linked through >>>>>> ciField::will_link()). >>>>>> >>>>>> I'd prefer to take the second option (changing field resolution), but >>>>>> there might be some disadvantages related to option I might be >>>>>> overseeing. >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> Thank you! >>>>>> >>>>>> Best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>>> >>>>>> >>>>>>> >>>>>>>> More details about the failure are here [3]. >>>>>>>> >>>>>>>> With the patch applied, the program always completes as it is >>>>>>>> expected >>>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed >>>>>>>> (because we >>>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>>> >>>>>>>> Here is the updated webrev: >>>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>>> Bailing out the whole compilation in C2 is even less appropriate. It >>>>>>> should generate an uncommon trap for such accesses instead (see >>>>>>> Parse::do_field_access). >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>> [1] >>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> > From zoltan.majo at oracle.com Fri Jun 10 06:38:38 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 10 Jun 2016 08:38:38 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <988f2271-0d7e-7a02-b301-c6237f123262@oracle.com> <93b3fe16-2bb0-3e77-9333-61989f33ff1c@oracle.com> <57585B76.5050809@oracle.com> Message-ID: <575A606E.90906@oracle.com> Hi David, On 06/10/2016 02:59 AM, David Holmes wrote: > Hi Zoltan, > > On 9/06/2016 3:52 AM, Zolt?n Maj? wrote: >> Hi David, >> >> >> >> On 06/02/2016 01:51 PM, David Holmes wrote: >>> [...] >>> The simplest, and common, approach to these kind of issues is to only >>> apply the correction for the current class file version and keep the >>> relaxed rules for all others. That provides the best compatibility >>> story. Of course if security is a concern then that is a different >>> matter - but such concerns can not be discussed here. >> >> thank you for the suggestion! >> >> In the latest webrev (webrev.06), I enable the additional check for >> classfile version >= 51 (JAVA_7_VERSION). With that version, we're >> conforming with the specification. So far no problems have showed up >> with our test base. The new check can be disabled with the >> CheckFinalFieldModifications flag (you've suggested that in your JBS >> comment). >> >> We can also change the checked version to 52 (JAVA_8) or 53 (JAVA_9). > > I think this needs to go to CCC so that the compatibility issue can be > examined. Normally, after long periods of non-conformance, we don't > "back date" tighter checks - so my initial feeling is that this should > only be enforced for Java 9 classfiles onwards. But that is not a > decision for individual engineers to make. Thank you for the feedback! I have changed the checked version to JAVA_9 (as you initially suggested). Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8157181/webrev.08/ I hope we don't need CCC approval if we apply the correction for the current class version only. I can file a new bug to investigate if the checks can be tightened up to pre-JAVA_9 -- that could form the discussion with the CCC. Thank you! Best regards, Zoltan > > > Thanks, > David > >> Please see the updated webrev (webrev.06) in my reply to Vladimir K. >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >>> >>> David >>> ----- >>> >>>> Before JVMS-7, where putfield/putstatic linkage checks were tightened, >>>> it was allowed to change final fields from anywhere in the same class. >>>> >>>> putfield "Linking Exceptions": >>>> >>>> JVMS-6 [1]: >>>> "Otherwise, if the field is final, it must be declared in the >>>> current class. Otherwise, an IllegalAccessError is thrown." >>>> >>>> JVMS-7 [2]: >>>> "Otherwise, if the field is final, it must be declared in the >>>> current class, and the instruction must occur in an instance >>>> initialization method () of the current class. Otherwise, an >>>> IllegalAccessError is thrown." >>>> >>>> >>>> src/share/vm/interpreter/linkResolver.cpp: >>>> >>>> + (byte == Bytecodes::_putstatic && fd.is_static() && >>>> method_name != vmSymbols::class_initializer_name()) || >>>> + ((byte == Bytecodes::_putfield || byte == >>>> Bytecodes::_nofast_putfield) && !fd.is_static() && method_name != >>>> vmSymbols::object_initializer_name()) >>>> >>>> >>>> Also, as we found earlier, checking method name is not enough: >>>> >>>> bool Method::is_static_initializer() const { >>>> // For classfiles version 51 or greater, ensure that the clinit >>>> method is >>>> // static. Non-static methods with the name "" are not >>>> static >>>> // initializers. (older classfiles exempted for backward >>>> compatibility) >>>> return name() == vmSymbols::class_initializer_name() && >>>> has_valid_initializer_flags(); >>>> } >>>> >>>> >>>> - LinkInfo link_info(defc, name, type, KlassHandle(), >>>> /*check_access=*/false); >>>> + LinkInfo link_info(defc, name, type, KlassHandle(), NULL, >>>> /*check_access=*/false); >>>> >>>> Use Handle() instead of NULL. >>>> >>>> Also, I'd prefer to see LinkInfo::_current_method and new constructor >>>> added: >>>> >>>> LinkInfo(KlassHandle resolved_klass, Symbol* name, Symbol* >>>> signature, >>>> Handle current_method, bool check_access = true) : >>>> >>>> _current_klass can be derived from _current_method, since: >>>> >>>> // current_klass = sending method holder (i.e., class containing >>>> the >>>> method >>>> // containing the call being resolved) >>>> >>>>> I did the following testing: >>>>> - JPRT >>>>> - pre-PIT RBT run (in progress) >>>>> - the reproducer. >>>>> >>>>> The reproducer now behaves as expected (an IllegalAccessError is >>>>> thrown). Also, the pre-PIT RBT run has shown no new failures so far. >>>>> >>>>> But there is a problem with JPRT: A JCK test, putstatic01801m, fails. >>>>> >>>>> The reason for the failure is that the the test generates a method >>>>> that >>>>> contains a putstatic to a static final field (i.e., the bytecodes >>>>> generated by the test do not conform to the JVMS). (Even the test >>>>> mentions that the Java source equivalent to the generated >>>>> bytecodes is >>>>> compilable only if the "final" keyword is removed from the >>>>> declaration >>>>> of the static field.) >>>>> >>>>> So (if we decide to push the current fix) the issue with the test >>>>> needs >>>>> to be fixed first. Do you know how we could proceed with that? >>>> File a bug against JCK. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] >>>> https://docs.oracle.com/javase/specs/jvms/se6/html/Instructions2.doc11.html >>>> >>>> >>>> >>>> [2] >>>> https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.putfield >>>> >>>> >>>> >>>> >>>> [3] >>>> https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4.3.2 >>>> >>>> >>>> >>>>> >>>>> Thank you and best regards, >>>>> >>>>> >>>>> Zoltan >>>>> >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>>> >>>>>>> I agree with you, alternatively we can propose a more generic fix >>>>>>> (fix >>>>>>> the interpreter and the compilers as well). The fix would most >>>>>>> likely >>>>>>> affect field resolution in LinkResolver::resolve_field() around >>>>>>> here: >>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>>>> inappropriate field access will propagate the exception to the >>>>>>> interpreter. Changing ciField::will_link() will most likely kill >>>>>>> (some) >>>>>>> compilations (if, e.g., fields are linked through >>>>>>> ciField::will_link()). >>>>>>> >>>>>>> I'd prefer to take the second option (changing field >>>>>>> resolution), but >>>>>>> there might be some disadvantages related to option I might be >>>>>>> overseeing. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Thank you! >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> >>>>>>> Zoltan >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> More details about the failure are here [3]. >>>>>>>>> >>>>>>>>> With the patch applied, the program always completes as it is >>>>>>>>> expected >>>>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed >>>>>>>>> (because we >>>>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>>>> >>>>>>>>> Here is the updated webrev: >>>>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>>>> Bailing out the whole compilation in C2 is even less >>>>>>>> appropriate. It >>>>>>>> should generate an uncommon trap for such accesses instead (see >>>>>>>> Parse::do_field_access). >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>> [1] >>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >> From zoltan.majo at oracle.com Fri Jun 10 06:45:32 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 10 Jun 2016 08:45:32 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <575A606E.90906@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <988f2271-0d7e-7a02-b301-c6237f123262@oracle.com> <93b3fe16-2bb0-3e77-9333-61989f33ff1c@oracle.com> <57585B76.5050809@oracle.com> <575A606E.90906@oracle.com> Message-ID: <575A620C.706@oracle.com> P.S.: Correction of small typo: On 06/10/2016 08:38 AM, Zolt?n Maj? wrote: > [...] > I can file a new bug to investigate if the checks can be tightened up > to pre-JAVA_9 -- that could form *the base of* the discussion with the > CCC. From david.holmes at oracle.com Fri Jun 10 07:30:07 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 Jun 2016 17:30:07 +1000 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <575A606E.90906@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <988f2271-0d7e-7a02-b301-c6237f123262@oracle.com> <93b3fe16-2bb0-3e77-9333-61989f33ff1c@oracle.com> <57585B76.5050809@oracle.com> <575A606E.90906@oracle.com> Message-ID: <365a7891-abce-b2e9-4974-34307410341a@oracle.com> On 10/06/2016 4:38 PM, Zolt?n Maj? wrote: > Hi David, > > > On 06/10/2016 02:59 AM, David Holmes wrote: >> Hi Zoltan, >> >> On 9/06/2016 3:52 AM, Zolt?n Maj? wrote: >>> Hi David, >>> >>> >>> >>> On 06/02/2016 01:51 PM, David Holmes wrote: >>>> [...] >>>> The simplest, and common, approach to these kind of issues is to only >>>> apply the correction for the current class file version and keep the >>>> relaxed rules for all others. That provides the best compatibility >>>> story. Of course if security is a concern then that is a different >>>> matter - but such concerns can not be discussed here. >>> >>> thank you for the suggestion! >>> >>> In the latest webrev (webrev.06), I enable the additional check for >>> classfile version >= 51 (JAVA_7_VERSION). With that version, we're >>> conforming with the specification. So far no problems have showed up >>> with our test base. The new check can be disabled with the >>> CheckFinalFieldModifications flag (you've suggested that in your JBS >>> comment). >>> >>> We can also change the checked version to 52 (JAVA_8) or 53 (JAVA_9). >> >> I think this needs to go to CCC so that the compatibility issue can be >> examined. Normally, after long periods of non-conformance, we don't >> "back date" tighter checks - so my initial feeling is that this should >> only be enforced for Java 9 classfiles onwards. But that is not a >> decision for individual engineers to make. > > Thank you for the feedback! > > I have changed the checked version to JAVA_9 (as you initially > suggested). Here is the updated webrev: > > http://cr.openjdk.java.net/~zmajo/8157181/webrev.08/ > > I hope we don't need CCC approval if we apply the correction for the > current class version only. > > I can file a new bug to investigate if the checks can be tightened up to > pre-JAVA_9 -- that could form the discussion with the CCC. That sounds fine - thanks. Note I have not reviewed the actual code. Cheers, David > Thank you! > > Best regards, > > > Zoltan > >> >> >> Thanks, >> David >> >>> Please see the updated webrev (webrev.06) in my reply to Vladimir K. >>> >>> Thank you! >>> >>> Best regards, >>> >>> >>> Zoltan >>> >>>> >>>> David >>>> ----- >>>> >>>>> Before JVMS-7, where putfield/putstatic linkage checks were tightened, >>>>> it was allowed to change final fields from anywhere in the same class. >>>>> >>>>> putfield "Linking Exceptions": >>>>> >>>>> JVMS-6 [1]: >>>>> "Otherwise, if the field is final, it must be declared in the >>>>> current class. Otherwise, an IllegalAccessError is thrown." >>>>> >>>>> JVMS-7 [2]: >>>>> "Otherwise, if the field is final, it must be declared in the >>>>> current class, and the instruction must occur in an instance >>>>> initialization method () of the current class. Otherwise, an >>>>> IllegalAccessError is thrown." >>>>> >>>>> >>>>> src/share/vm/interpreter/linkResolver.cpp: >>>>> >>>>> + (byte == Bytecodes::_putstatic && fd.is_static() && >>>>> method_name != vmSymbols::class_initializer_name()) || >>>>> + ((byte == Bytecodes::_putfield || byte == >>>>> Bytecodes::_nofast_putfield) && !fd.is_static() && method_name != >>>>> vmSymbols::object_initializer_name()) >>>>> >>>>> >>>>> Also, as we found earlier, checking method name is not enough: >>>>> >>>>> bool Method::is_static_initializer() const { >>>>> // For classfiles version 51 or greater, ensure that the clinit >>>>> method is >>>>> // static. Non-static methods with the name "" are not >>>>> static >>>>> // initializers. (older classfiles exempted for backward >>>>> compatibility) >>>>> return name() == vmSymbols::class_initializer_name() && >>>>> has_valid_initializer_flags(); >>>>> } >>>>> >>>>> >>>>> - LinkInfo link_info(defc, name, type, KlassHandle(), >>>>> /*check_access=*/false); >>>>> + LinkInfo link_info(defc, name, type, KlassHandle(), NULL, >>>>> /*check_access=*/false); >>>>> >>>>> Use Handle() instead of NULL. >>>>> >>>>> Also, I'd prefer to see LinkInfo::_current_method and new constructor >>>>> added: >>>>> >>>>> LinkInfo(KlassHandle resolved_klass, Symbol* name, Symbol* >>>>> signature, >>>>> Handle current_method, bool check_access = true) : >>>>> >>>>> _current_klass can be derived from _current_method, since: >>>>> >>>>> // current_klass = sending method holder (i.e., class containing >>>>> the >>>>> method >>>>> // containing the call being resolved) >>>>> >>>>>> I did the following testing: >>>>>> - JPRT >>>>>> - pre-PIT RBT run (in progress) >>>>>> - the reproducer. >>>>>> >>>>>> The reproducer now behaves as expected (an IllegalAccessError is >>>>>> thrown). Also, the pre-PIT RBT run has shown no new failures so far. >>>>>> >>>>>> But there is a problem with JPRT: A JCK test, putstatic01801m, fails. >>>>>> >>>>>> The reason for the failure is that the the test generates a method >>>>>> that >>>>>> contains a putstatic to a static final field (i.e., the bytecodes >>>>>> generated by the test do not conform to the JVMS). (Even the test >>>>>> mentions that the Java source equivalent to the generated >>>>>> bytecodes is >>>>>> compilable only if the "final" keyword is removed from the >>>>>> declaration >>>>>> of the static field.) >>>>>> >>>>>> So (if we decide to push the current fix) the issue with the test >>>>>> needs >>>>>> to be fixed first. Do you know how we could proceed with that? >>>>> File a bug against JCK. >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> [1] >>>>> https://docs.oracle.com/javase/specs/jvms/se6/html/Instructions2.doc11.html >>>>> >>>>> >>>>> >>>>> [2] >>>>> https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.putfield >>>>> >>>>> >>>>> >>>>> >>>>> [3] >>>>> https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4.3.2 >>>>> >>>>> >>>>> >>>>>> >>>>>> Thank you and best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>>> >>>>>>>> I agree with you, alternatively we can propose a more generic fix >>>>>>>> (fix >>>>>>>> the interpreter and the compilers as well). The fix would most >>>>>>>> likely >>>>>>>> affect field resolution in LinkResolver::resolve_field() around >>>>>>>> here: >>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>>>>> inappropriate field access will propagate the exception to the >>>>>>>> interpreter. Changing ciField::will_link() will most likely kill >>>>>>>> (some) >>>>>>>> compilations (if, e.g., fields are linked through >>>>>>>> ciField::will_link()). >>>>>>>> >>>>>>>> I'd prefer to take the second option (changing field >>>>>>>> resolution), but >>>>>>>> there might be some disadvantages related to option I might be >>>>>>>> overseeing. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thank you! >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> >>>>>>>> Zoltan >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> More details about the failure are here [3]. >>>>>>>>>> >>>>>>>>>> With the patch applied, the program always completes as it is >>>>>>>>>> expected >>>>>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed >>>>>>>>>> (because we >>>>>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>>>>> >>>>>>>>>> Here is the updated webrev: >>>>>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>>>>> Bailing out the whole compilation in C2 is even less >>>>>>>>> appropriate. It >>>>>>>>> should generate an uncommon trap for such accesses instead (see >>>>>>>>> Parse::do_field_access). >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Vladimir Ivanov >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>> > From zoltan.majo at oracle.com Fri Jun 10 08:36:18 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 10 Jun 2016 10:36:18 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <365a7891-abce-b2e9-4974-34307410341a@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <988f2271-0d7e-7a02-b301-c6237f123262@oracle.com> <93b3fe16-2bb0-3e77-9333-61989f33ff1c@oracle.com> <57585B76.5050809@oracle.com> <575A606E.90906@oracle.com> <365a7891-abce-b2e9-4974-34307410341a@oracle.com> Message-ID: <575A7C02.30103@oracle.com> Hi David, On 06/10/2016 09:30 AM, David Holmes wrote: > > On 10/06/2016 4:38 PM, Zolt?n Maj? wrote: >> Hi David, >> >> >> On 06/10/2016 02:59 AM, David Holmes wrote: >>> Hi Zoltan, >>> >>> On 9/06/2016 3:52 AM, Zolt?n Maj? wrote: >>>> Hi David, >>>> >>>> >>>> >>>> On 06/02/2016 01:51 PM, David Holmes wrote: >>>>> [...] >>>>> The simplest, and common, approach to these kind of issues is to only >>>>> apply the correction for the current class file version and keep the >>>>> relaxed rules for all others. That provides the best compatibility >>>>> story. Of course if security is a concern then that is a different >>>>> matter - but such concerns can not be discussed here. >>>> >>>> thank you for the suggestion! >>>> >>>> In the latest webrev (webrev.06), I enable the additional check for >>>> classfile version >= 51 (JAVA_7_VERSION). With that version, we're >>>> conforming with the specification. So far no problems have showed up >>>> with our test base. The new check can be disabled with the >>>> CheckFinalFieldModifications flag (you've suggested that in your JBS >>>> comment). >>>> >>>> We can also change the checked version to 52 (JAVA_8) or 53 (JAVA_9). >>> >>> I think this needs to go to CCC so that the compatibility issue can be >>> examined. Normally, after long periods of non-conformance, we don't >>> "back date" tighter checks - so my initial feeling is that this should >>> only be enforced for Java 9 classfiles onwards. But that is not a >>> decision for individual engineers to make. >> >> Thank you for the feedback! >> >> I have changed the checked version to JAVA_9 (as you initially >> suggested). Here is the updated webrev: >> >> http://cr.openjdk.java.net/~zmajo/8157181/webrev.08/ >> >> I hope we don't need CCC approval if we apply the correction for the >> current class version only. >> >> I can file a new bug to investigate if the checks can be tightened up to >> pre-JAVA_9 -- that could form the discussion with the CCC. > > That sounds fine - thanks. Thank you! I've filed JDK-8159215 [1] for tightening up the checks for Java 7 and/or Java 8. > > Note I have not reviewed the actual code. I've noted that. Thank you for all the suggestions/feedback! Best regards, Zoltan [1] https://bugs.openjdk.java.net/browse/JDK-8159215 > > Cheers, > David > >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >>> >>> >>> Thanks, >>> David >>> >>>> Please see the updated webrev (webrev.06) in my reply to Vladimir K. >>>> >>>> Thank you! >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> Before JVMS-7, where putfield/putstatic linkage checks were >>>>>> tightened, >>>>>> it was allowed to change final fields from anywhere in the same >>>>>> class. >>>>>> >>>>>> putfield "Linking Exceptions": >>>>>> >>>>>> JVMS-6 [1]: >>>>>> "Otherwise, if the field is final, it must be declared in the >>>>>> current class. Otherwise, an IllegalAccessError is thrown." >>>>>> >>>>>> JVMS-7 [2]: >>>>>> "Otherwise, if the field is final, it must be declared in the >>>>>> current class, and the instruction must occur in an instance >>>>>> initialization method () of the current class. Otherwise, an >>>>>> IllegalAccessError is thrown." >>>>>> >>>>>> >>>>>> src/share/vm/interpreter/linkResolver.cpp: >>>>>> >>>>>> + (byte == Bytecodes::_putstatic && fd.is_static() && >>>>>> method_name != vmSymbols::class_initializer_name()) || >>>>>> + ((byte == Bytecodes::_putfield || byte == >>>>>> Bytecodes::_nofast_putfield) && !fd.is_static() && method_name != >>>>>> vmSymbols::object_initializer_name()) >>>>>> >>>>>> >>>>>> Also, as we found earlier, checking method name is not enough: >>>>>> >>>>>> bool Method::is_static_initializer() const { >>>>>> // For classfiles version 51 or greater, ensure that the clinit >>>>>> method is >>>>>> // static. Non-static methods with the name "" are not >>>>>> static >>>>>> // initializers. (older classfiles exempted for backward >>>>>> compatibility) >>>>>> return name() == vmSymbols::class_initializer_name() && >>>>>> has_valid_initializer_flags(); >>>>>> } >>>>>> >>>>>> >>>>>> - LinkInfo link_info(defc, name, type, KlassHandle(), >>>>>> /*check_access=*/false); >>>>>> + LinkInfo link_info(defc, name, type, KlassHandle(), NULL, >>>>>> /*check_access=*/false); >>>>>> >>>>>> Use Handle() instead of NULL. >>>>>> >>>>>> Also, I'd prefer to see LinkInfo::_current_method and new >>>>>> constructor >>>>>> added: >>>>>> >>>>>> LinkInfo(KlassHandle resolved_klass, Symbol* name, Symbol* >>>>>> signature, >>>>>> Handle current_method, bool check_access = true) : >>>>>> >>>>>> _current_klass can be derived from _current_method, since: >>>>>> >>>>>> // current_klass = sending method holder (i.e., class containing >>>>>> the >>>>>> method >>>>>> // containing the call being resolved) >>>>>> >>>>>>> I did the following testing: >>>>>>> - JPRT >>>>>>> - pre-PIT RBT run (in progress) >>>>>>> - the reproducer. >>>>>>> >>>>>>> The reproducer now behaves as expected (an IllegalAccessError is >>>>>>> thrown). Also, the pre-PIT RBT run has shown no new failures so >>>>>>> far. >>>>>>> >>>>>>> But there is a problem with JPRT: A JCK test, putstatic01801m, >>>>>>> fails. >>>>>>> >>>>>>> The reason for the failure is that the the test generates a method >>>>>>> that >>>>>>> contains a putstatic to a static final field (i.e., the bytecodes >>>>>>> generated by the test do not conform to the JVMS). (Even the test >>>>>>> mentions that the Java source equivalent to the generated >>>>>>> bytecodes is >>>>>>> compilable only if the "final" keyword is removed from the >>>>>>> declaration >>>>>>> of the static field.) >>>>>>> >>>>>>> So (if we decide to push the current fix) the issue with the test >>>>>>> needs >>>>>>> to be fixed first. Do you know how we could proceed with that? >>>>>> File a bug against JCK. >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> [1] >>>>>> https://docs.oracle.com/javase/specs/jvms/se6/html/Instructions2.doc11.html >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> [2] >>>>>> https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.putfield >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> [3] >>>>>> https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4.3.2 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Thank you and best regards, >>>>>>> >>>>>>> >>>>>>> Zoltan >>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>>> >>>>>>>>> I agree with you, alternatively we can propose a more generic fix >>>>>>>>> (fix >>>>>>>>> the interpreter and the compilers as well). The fix would most >>>>>>>>> likely >>>>>>>>> affect field resolution in LinkResolver::resolve_field() around >>>>>>>>> here: >>>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>>>>>> inappropriate field access will propagate the exception to the >>>>>>>>> interpreter. Changing ciField::will_link() will most likely kill >>>>>>>>> (some) >>>>>>>>> compilations (if, e.g., fields are linked through >>>>>>>>> ciField::will_link()). >>>>>>>>> >>>>>>>>> I'd prefer to take the second option (changing field >>>>>>>>> resolution), but >>>>>>>>> there might be some disadvantages related to option I might be >>>>>>>>> overseeing. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Thank you! >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> >>>>>>>>> Zoltan >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> More details about the failure are here [3]. >>>>>>>>>>> >>>>>>>>>>> With the patch applied, the program always completes as it is >>>>>>>>>>> expected >>>>>>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed >>>>>>>>>>> (because we >>>>>>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>>>>>> >>>>>>>>>>> Here is the updated webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>>>>>> Bailing out the whole compilation in C2 is even less >>>>>>>>>> appropriate. It >>>>>>>>>> should generate an uncommon trap for such accesses instead (see >>>>>>>>>> Parse::do_field_access). >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Vladimir Ivanov >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>> >> From vladimir.x.ivanov at oracle.com Fri Jun 10 12:56:53 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 10 Jun 2016 15:56:53 +0300 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <57597673.4070103@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> Message-ID: <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> http://cr.openjdk.java.net/~zmajo/8157181/webrev.08 I'm fine with enabling the checks only for 9 for now and handle 7 & 8 class files separately. >> src/share/vm/classfile/verifier.cpp: >> >> + void >> Verifier::detect_invalid_final_field_accesses(instanceKlassHandle >> klass) { >> >> The name is misleading: such accesses are legal according to JVMS-6 >> (and earlier). Maybe something like >> detect_initialized_final_field_updates? >> >> Same for: >> + bool has_invalid_final_access() const { return >> access_flags().has_field_invalid_final_access(); } >> + void set_has_invalid_final_access(const bool value) { >> + JVM_ACC_FIELD_INVALID_FINAL_ACCESS = 0x00000100, >> > > Yes, that name sounds better and I've updated the code accordingly. A leftover: src/share/vm/runtime/fieldDescriptor.hpp: + void set_has_invalid_final_access(const bool value) { >> --- >> I don't see much benefit in tracking the problematic updates >> per-methods and not per-class. So, you could do the checks in >> ClassVerifier::verify_field_instructions [1] and mark the whole class >> (ClassVerifier::_klass) as containing problematic instructions. > > The problematic updates are tracked *per-field* (and not *per-method* or > * per-class*). > > Initially, I had a version that tracked problematic instructions on a > per-class basis. With that version, once a problematic instruction was > detected, the whole class was marked as containing problematic > instructions. As a result, constant folding was disabled for accesses to > *all* final fields of that class. > > Tracking problematic updates on a per-field basis seems to be less > intrusive. That way we disable folding *only for fields to which > problematic accesses are made* (and leave constant folding enabled for > accesses to all other fields). So we can fold some accesses even for > "misbehaving" classes. I hope that is fine. > > Regarding doing checks in verify_field_instructions() [2]: It turns out > that we have two verifiers, one that is called for > > major_version >= STACKMAP_ATTRIBUTE_MAJOR_VERSION > > and a second one that is called for > > major_version < STACKMAP_ATTRIBUTE_MAJOR_VERSION. > > ClassVerifier::verify_field_instructions() is called only for class > files >= STACKMAP_ATTRIBUTE_MAJOR_VERSION so we need to call > detect_initialized_final_field_updates() after verification. > > But I think it is a good idea to move the check to the linkage phase (as > you've suggested above). While browsing the code, I got another idea: what about piggybacking on Rewriter pass (see Rewriter::scan_method)? It already sets some per-method properties (e.g., Method::has_monitor_bytecodes()). I'd like to avoid additional pass over the bytecode, because it can cause slow downs during class loading (just a precaution - I haven't measured the impact). >> --- >> src/share/vm/interpreter/linkResolver.cpp: >> >> THROW(vmSymbols::java_lang_IllegalAccessError()); >> >> + THROW(vmSymbols::java_lang_IllegalAccessError()); >> >> Please, add an error message for diagnostic purposes. > > OK, I did that. src/share/vm/interpreter/linkResolver.cpp: + if (is_put && fd.access_flags().is_final()) { + ResourceMark rm(THREAD); + char msg[200]; There's much more convenient way now - stringStream. It takes care of memory management in resource area for you and provides convenient utility functions: ResourceMark rm(THREAD); stringStream ss; ss.printf("...", ...); THROW_MSG(vmSymbols::java_lang_IllegalAccessError(), ss.as_string()); --- + if ((byte == Bytecodes::_putstatic && fd.is_static() && !m()->is_static_initializer()) || + ((byte == Bytecodes::_putfield || byte == Bytecodes::_nofast_putfield) && !fd.is_static() && !m->is_object_initializer())) { Maybe refactor it to make more readable? bool is_static_final_update = ...; bool is_instance_final_update = ...; if (is_static_final_update || is_instance_final_update) { ... Otherwise, looks good. Best regards, Vladimir Ivanov From zoltan.majo at oracle.com Fri Jun 10 14:50:40 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 10 Jun 2016 16:50:40 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> Message-ID: <575AD3C0.8040303@oracle.com> Hi Vladimir, thank you for the feedback! On 06/10/2016 02:56 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~zmajo/8157181/webrev.08 > > I'm fine with enabling the checks only for 9 for now and handle 7 & 8 > class files separately. OK, thanks! > >>> src/share/vm/classfile/verifier.cpp: >>> >>> + void >>> Verifier::detect_invalid_final_field_accesses(instanceKlassHandle >>> klass) { >>> >>> The name is misleading: such accesses are legal according to JVMS-6 >>> (and earlier). Maybe something like >>> detect_initialized_final_field_updates? >>> >>> Same for: >>> + bool has_invalid_final_access() const { return >>> access_flags().has_field_invalid_final_access(); } >>> + void set_has_invalid_final_access(const bool value) { >>> + JVM_ACC_FIELD_INVALID_FINAL_ACCESS = 0x00000100, >>> >> >> Yes, that name sounds better and I've updated the code accordingly. > > A leftover: > > src/share/vm/runtime/fieldDescriptor.hpp: > > + void set_has_invalid_final_access(const bool value) { Thanks for catching that, corrected. > >>> --- >>> I don't see much benefit in tracking the problematic updates >>> per-methods and not per-class. So, you could do the checks in >>> ClassVerifier::verify_field_instructions [1] and mark the whole class >>> (ClassVerifier::_klass) as containing problematic instructions. >> >> The problematic updates are tracked *per-field* (and not *per-method* or >> * per-class*). >> >> Initially, I had a version that tracked problematic instructions on a >> per-class basis. With that version, once a problematic instruction was >> detected, the whole class was marked as containing problematic >> instructions. As a result, constant folding was disabled for accesses to >> *all* final fields of that class. >> >> Tracking problematic updates on a per-field basis seems to be less >> intrusive. That way we disable folding *only for fields to which >> problematic accesses are made* (and leave constant folding enabled for >> accesses to all other fields). So we can fold some accesses even for >> "misbehaving" classes. I hope that is fine. >> >> Regarding doing checks in verify_field_instructions() [2]: It turns out >> that we have two verifiers, one that is called for >> >> major_version >= STACKMAP_ATTRIBUTE_MAJOR_VERSION >> >> and a second one that is called for >> >> major_version < STACKMAP_ATTRIBUTE_MAJOR_VERSION. >> >> ClassVerifier::verify_field_instructions() is called only for class >> files >= STACKMAP_ATTRIBUTE_MAJOR_VERSION so we need to call >> detect_initialized_final_field_updates() after verification. >> >> But I think it is a good idea to move the check to the linkage phase (as >> you've suggested above). > > While browsing the code, I got another idea: what about piggybacking > on Rewriter pass (see Rewriter::scan_method)? It already sets some > per-method properties (e.g., Method::has_monitor_bytecodes()). > > I'd like to avoid additional pass over the bytecode, because it can > cause slow downs during class loading (just a precaution - I haven't > measured the impact). I understand your concern and have moved the detection of initialized final field updates to Rewriter::scan_method(). > >>> --- >>> src/share/vm/interpreter/linkResolver.cpp: >>> >>> THROW(vmSymbols::java_lang_IllegalAccessError()); >>> >>> + THROW(vmSymbols::java_lang_IllegalAccessError()); >>> >>> Please, add an error message for diagnostic purposes. >> >> OK, I did that. > > src/share/vm/interpreter/linkResolver.cpp: > > + if (is_put && fd.access_flags().is_final()) { > + ResourceMark rm(THREAD); > + char msg[200]; > > There's much more convenient way now - stringStream. It takes care of > memory management in resource area for you and provides convenient > utility functions: > > ResourceMark rm(THREAD); > stringStream ss; > ss.printf("...", ...); > THROW_MSG(vmSymbols::java_lang_IllegalAccessError(), ss.as_string()); OK, I changed that part. > > --- > + if ((byte == Bytecodes::_putstatic && fd.is_static() && > !m()->is_static_initializer()) || > + ((byte == Bytecodes::_putfield || byte == > Bytecodes::_nofast_putfield) && !fd.is_static() && > !m->is_object_initializer())) { > > Maybe refactor it to make more readable? > > bool is_static_final_update = ...; > bool is_instance_final_update = ...; > if (is_static_final_update || is_instance_final_update) { OK, I did that. > ... > > Otherwise, looks good. Thank you! Please let me know if you spot anything with the newest changes. Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8157181/webrev.09/ JPRT is running. Best regards, Zoltan > > Best regards, > Vladimir Ivanov From coleen.phillimore at oracle.com Fri Jun 10 14:55:25 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 10 Jun 2016 10:55:25 -0400 Subject: RFR 8152271: MemberNameTable doesn't purge stale entries Message-ID: Summary: Intern MemberNames in table instead of allocating new entries For degenerate case, we were leaking native code in the member name table. Going with the suggested workaround, it was only a few more lines of code to intern MemberName and return the MemberName that was already in the table. This has been performance tested to show no regression and works really well for the degenerate test case, even though the real percentage of reused MemberName seems quite small. Tested with all runtime nightly tests, tests in jdk/test/java/lang/invoke. open webrev at http://cr.openjdk.java.net/~coleenp/8152271.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8152271 Thanks, Coleen From vladimir.x.ivanov at oracle.com Fri Jun 10 15:09:41 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 10 Jun 2016 18:09:41 +0300 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <575AD3C0.8040303@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> Message-ID: > Here is the updated webrev: > http://cr.openjdk.java.net/~zmajo/8157181/webrev.09/ Looks good. Last comment: src/share/vm/interpreter/rewriter.cpp: + if (!(method->is_native() || method->is_abstract() || method->is_overpass())) { Seems redundant. Native & abstract methods don't have body. Shouldn't happen for overpasses as well (AFAIK they don't contain putstatic/putfield instructions), but it's better to analyze them (just in case). Best regards, Vladimir Ivanov From zoltan.majo at oracle.com Fri Jun 10 15:20:56 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 10 Jun 2016 17:20:56 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> Message-ID: <575ADAD8.1030907@oracle.com> Hi Vladimir, On 06/10/2016 05:09 PM, Vladimir Ivanov wrote: >> Here is the updated webrev: >> http://cr.openjdk.java.net/~zmajo/8157181/webrev.09/ > > Looks good. thank you! > > Last comment: > > src/share/vm/interpreter/rewriter.cpp: > > + if (!(method->is_native() || method->is_abstract() || > method->is_overpass())) { > > Seems redundant. Native & abstract methods don't have body. > Shouldn't happen for overpasses as well (AFAIK they don't contain > putstatic/putfield instructions), but it's better to analyze them > (just in case). OK, I've removed that condition. Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8157181/webrev.10/ JPRT is in progress. Thank you and best regards, Zoltan > > Best regards, > Vladimir Ivanov From vladimir.x.ivanov at oracle.com Fri Jun 10 15:33:25 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 10 Jun 2016 18:33:25 +0300 Subject: RFR 8152271: MemberNameTable doesn't purge stale entries In-Reply-To: References: Message-ID: Coleen, src/share/vm/prims/methodHandles.cpp: @@ -975,7 +969,7 @@ - oop saved = MethodHandles::init_method_MemberName(result, info); + oop saved = MethodHandles::init_method_MemberName(result, info, /*intern*/false); Why do you disable interning in that case? Otherwise, looks good. Best regards, Vladimir Ivanov On 6/10/16 5:55 PM, Coleen Phillimore wrote: > Summary: Intern MemberNames in table instead of allocating new entries > > For degenerate case, we were leaking native code in the member name > table. Going with the suggested workaround, it was only a few more > lines of code to intern MemberName and return the MemberName that was > already in the table. > > This has been performance tested to show no regression and works really > well for the degenerate test case, even though the real percentage of > reused MemberName seems quite small. > > Tested with all runtime nightly tests, tests in jdk/test/java/lang/invoke. > > open webrev at http://cr.openjdk.java.net/~coleenp/8152271.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8152271 > > Thanks, > Coleen From zoltan.majo at oracle.com Fri Jun 10 15:53:17 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 10 Jun 2016 17:53:17 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <575ADAD8.1030907@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> Message-ID: <575AE26D.4010409@oracle.com> Hi Vladimir, On 06/10/2016 05:20 PM, Zolt?n Maj? wrote: > [...] > > Here is the updated webrev: > http://cr.openjdk.java.net/~zmajo/8157181/webrev.10/ > Please note an additional small change in rewriter.cpp: +if (!reverse) { // Check if any final field of the class given as parameter is modified // outside of initializer methods of the class. Fields that are modified ... +} It's sufficient to check fields during rewriting (i.e., we're coming from Rewriter::rewrite_bytecodes()). We do not need to do the checks if the class has already been rewritten but we're reversing changes due to some failure that appeared during rewriting (in that case scan_method() is called from Rewriter::restore_bytecodes()). Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/ JPRT is in progress. Thank you and best regards, Zoltan > JPRT is in progress. > > Thank you and best regards, > > > Zoltan > >> >> Best regards, >> Vladimir Ivanov > From vladimir.x.ivanov at oracle.com Fri Jun 10 16:05:21 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 10 Jun 2016 19:05:21 +0300 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <575AE26D.4010409@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> Message-ID: <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> > Please note an additional small change in rewriter.cpp: > > +if (!reverse) { > // Check if any final field of the class given as parameter is modified > // outside of initializer methods of the class. Fields that are modified > ... > +} > > It's sufficient to check fields during rewriting (i.e., we're coming > from Rewriter::rewrite_bytecodes()). We do not need to do the checks if > the class has already been rewritten but we're reversing changes due to > some failure that appeared during rewriting (in that case scan_method() > is called from Rewriter::restore_bytecodes()). Ok. > Here is the updated webrev: > http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/ Looks good. src/share/vm/runtime/globals.hpp + "for classfile version >= 51") s/51/53/ (no need to send new webrev). Best regards, Vladimir Ivanov From zoltan.majo at oracle.com Fri Jun 10 17:40:32 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 10 Jun 2016 19:40:32 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> Message-ID: <575AFB90.5060001@oracle.com> Hi Vladimir, On 06/10/2016 06:05 PM, Vladimir Ivanov wrote: > >> Please note an additional small change in rewriter.cpp: >> >> +if (!reverse) { >> // Check if any final field of the class given as parameter is modified >> // outside of initializer methods of the class. Fields that are modified >> ... >> +} >> >> It's sufficient to check fields during rewriting (i.e., we're coming >> from Rewriter::rewrite_bytecodes()). We do not need to do the checks if >> the class has already been rewritten but we're reversing changes due to >> some failure that appeared during rewriting (in that case scan_method() >> is called from Rewriter::restore_bytecodes()). > > Ok. > >> Here is the updated webrev: >> http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/ > > Looks good. > > src/share/vm/runtime/globals.hpp > > + "for classfile version >= 51") > > s/51/53/ (no need to send new webrev). OK, I've corrected the code in-situ (in webrev.11). I also have the JPRT results now, all tests pass. Thank you! Best regards, Zoltan > > Best regards, > Vladimir Ivanov From coleen.phillimore at oracle.com Fri Jun 10 18:27:43 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 10 Jun 2016 14:27:43 -0400 Subject: RFR 8158237: JVMTI hides critical debug information for memory leak tracing Message-ID: <792bc4db-b0a9-9eea-3401-a1df5be9f475@oracle.com> Summary: remove _backtrace as hidden field, since the original problem no longer exists The backtrace format is changed to be all java objects and no longer have jvm methodOops (pseudo Objects) which caused the crash. This change is being also tested by the customer. I ran full nightly tests on this. bug link https://bugs.openjdk.java.net/browse/JDK-8158237 open webrev at http://cr.openjdk.java.net/~coleenp/8158237.01/webrev open webrev at http://cr.openjdk.java.net/~coleenp/8158237.jdk.01/webrev Thanks, Coleen From coleen.phillimore at oracle.com Fri Jun 10 18:33:44 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 10 Jun 2016 14:33:44 -0400 Subject: RFR 8152271: MemberNameTable doesn't purge stale entries In-Reply-To: References: Message-ID: On 6/10/16 11:33 AM, Vladimir Ivanov wrote: > Coleen, > > src/share/vm/prims/methodHandles.cpp: > > @@ -975,7 +969,7 @@ > > - oop saved = MethodHandles::init_method_MemberName(result, info); > + oop saved = MethodHandles::init_method_MemberName(result, > info, /*intern*/false); > > Why do you disable interning in that case? I added a comment. This case was looping through methods and creating member names so shouldn't linear search the table. // Since this is going through the methods to create MemberNames, don't search // for matching methods already in the table (there won't be any) oop saved = MethodHandles::init_method_MemberName(result, info, /*intern*/false); > > Otherwise, looks good. Thanks! Coleen > > Best regards, > Vladimir Ivanov > > On 6/10/16 5:55 PM, Coleen Phillimore wrote: >> Summary: Intern MemberNames in table instead of allocating new entries >> >> For degenerate case, we were leaking native code in the member name >> table. Going with the suggested workaround, it was only a few more >> lines of code to intern MemberName and return the MemberName that was >> already in the table. >> >> This has been performance tested to show no regression and works really >> well for the degenerate test case, even though the real percentage of >> reused MemberName seems quite small. >> >> Tested with all runtime nightly tests, tests in >> jdk/test/java/lang/invoke. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8152271.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8152271 >> >> Thanks, >> Coleen From coleen.phillimore at oracle.com Fri Jun 10 19:43:32 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 10 Jun 2016 15:43:32 -0400 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <575AFB90.5060001@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> Message-ID: <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> Hi, I'm late to the thread, which is good because it's better that this check is done in the rewriter, than in InstanceKlass. But I'm fuzzy on why this wasn't checked in the verifier, and what the purpose of the has_initialized_final_update (which means a non method has updated a final field, which is a verify error, right? Also, have you run the JCK tests? Why have a global flag if it's an error? Thanks, Coleen On 6/10/16 1:40 PM, Zolt?n Maj? wrote: > Hi Vladimir, > > > On 06/10/2016 06:05 PM, Vladimir Ivanov wrote: >> >>> Please note an additional small change in rewriter.cpp: >>> >>> +if (!reverse) { >>> // Check if any final field of the class given as parameter is modified >>> // outside of initializer methods of the class. Fields that are >>> modified >>> ... >>> +} >>> >>> It's sufficient to check fields during rewriting (i.e., we're coming >>> from Rewriter::rewrite_bytecodes()). We do not need to do the checks if >>> the class has already been rewritten but we're reversing changes due to >>> some failure that appeared during rewriting (in that case scan_method() >>> is called from Rewriter::restore_bytecodes()). >> >> Ok. >> >>> Here is the updated webrev: >>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/ >> >> Looks good. >> >> src/share/vm/runtime/globals.hpp >> >> + "for classfile version >= 51") >> >> s/51/53/ (no need to send new webrev). > > OK, I've corrected the code in-situ (in webrev.11). I also have the > JPRT results now, all tests pass. > > Thank you! > > Best regards, > > > Zoltan > > > >> >> Best regards, >> Vladimir Ivanov > From serguei.spitsyn at oracle.com Fri Jun 10 20:09:53 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 10 Jun 2016 13:09:53 -0700 Subject: RFR 8152271: MemberNameTable doesn't purge stale entries In-Reply-To: References: Message-ID: <575B1E91.9010803@oracle.com> Hi Coleen, This looks nice. Thank you for taking care about it! Thanks, Serguei On 6/10/16 07:55, Coleen Phillimore wrote: > Summary: Intern MemberNames in table instead of allocating new entries > > For degenerate case, we were leaking native code in the member name > table. Going with the suggested workaround, it was only a few more > lines of code to intern MemberName and return the MemberName that was > already in the table. > > This has been performance tested to show no regression and works > really well for the degenerate test case, even though the real > percentage of reused MemberName seems quite small. > > Tested with all runtime nightly tests, tests in > jdk/test/java/lang/invoke. > > open webrev at http://cr.openjdk.java.net/~coleenp/8152271.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8152271 > > Thanks, > Coleen From coleen.phillimore at oracle.com Fri Jun 10 20:15:42 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 10 Jun 2016 16:15:42 -0400 Subject: RFR 8152271: MemberNameTable doesn't purge stale entries In-Reply-To: <575B1E91.9010803@oracle.com> References: <575B1E91.9010803@oracle.com> Message-ID: <4b96f5fc-2066-4036-ba6f-9a6e9de4b505@oracle.com> On 6/10/16 4:09 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > This looks nice. > Thank you for taking care about it! Thanks, Serguei! Coleen > > Thanks, > Serguei > > > On 6/10/16 07:55, Coleen Phillimore wrote: >> Summary: Intern MemberNames in table instead of allocating new entries >> >> For degenerate case, we were leaking native code in the member name >> table. Going with the suggested workaround, it was only a few more >> lines of code to intern MemberName and return the MemberName that was >> already in the table. >> >> This has been performance tested to show no regression and works >> really well for the degenerate test case, even though the real >> percentage of reused MemberName seems quite small. >> >> Tested with all runtime nightly tests, tests in >> jdk/test/java/lang/invoke. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8152271.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8152271 >> >> Thanks, >> Coleen > From serguei.spitsyn at oracle.com Fri Jun 10 20:37:37 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 10 Jun 2016 13:37:37 -0700 Subject: RFR 8158237: JVMTI hides critical debug information for memory leak tracing In-Reply-To: <792bc4db-b0a9-9eea-3401-a1df5be9f475@oracle.com> References: <792bc4db-b0a9-9eea-3401-a1df5be9f475@oracle.com> Message-ID: <575B2511.5080009@oracle.com> Coleen, It looks good. test/com/sun/jdi/BacktraceFieldTest.java: Nit: seems to be unneeded leftover: 71 // Thanks, Serguei On 6/10/16 11:27, Coleen Phillimore wrote: > Summary: remove _backtrace as hidden field, since the original problem > no longer exists The backtrace format is changed to be all java > objects and no longer have jvm methodOops (pseudo Objects) which > caused the crash. This change is being also tested by the customer. I > ran full nightly tests on this. bug link > https://bugs.openjdk.java.net/browse/JDK-8158237 open webrev at > http://cr.openjdk.java.net/~coleenp/8158237.01/webrev open webrev at > http://cr.openjdk.java.net/~coleenp/8158237.jdk.01/webrev Thanks, Coleen From coleen.phillimore at oracle.com Fri Jun 10 20:49:21 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 10 Jun 2016 16:49:21 -0400 Subject: RFR 8158237: JVMTI hides critical debug information for memory leak tracing In-Reply-To: <575B2511.5080009@oracle.com> References: <792bc4db-b0a9-9eea-3401-a1df5be9f475@oracle.com> <575B2511.5080009@oracle.com> Message-ID: On 6/10/16 4:37 PM, serguei.spitsyn at oracle.com wrote: > Coleen, > > It looks good. > > test/com/sun/jdi/BacktraceFieldTest.java: > > Nit: seems to be unneeded leftover: > 71 // Removed it. Thanks again, Serguei! Coleen > Thanks, Serguei On 6/10/16 11:27, Coleen Phillimore wrote: >> Summary: remove _backtrace as hidden field, since the original >> problem no longer exists The backtrace format is changed to be all >> java objects and no longer have jvm methodOops (pseudo Objects) which >> caused the crash. This change is being also tested by the customer. >> I ran full nightly tests on this. bug link >> https://bugs.openjdk.java.net/browse/JDK-8158237 open webrev at >> http://cr.openjdk.java.net/~coleenp/8158237.01/webrev open webrev at >> http://cr.openjdk.java.net/~coleenp/8158237.jdk.01/webrev Thanks, Coleen From jiangli.zhou at oracle.com Fri Jun 10 21:17:08 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 10 Jun 2016 14:17:08 -0700 Subject: RFR 8158237: JVMTI hides critical debug information for memory leak tracing In-Reply-To: References: <792bc4db-b0a9-9eea-3401-a1df5be9f475@oracle.com> <575B2511.5080009@oracle.com> Message-ID: <29FE364A-D60C-4EAF-9E13-FCED13006CA2@oracle.com> Looks good. Thanks, Jiangli > On Jun 10, 2016, at 1:49 PM, Coleen Phillimore wrote: > > > > On 6/10/16 4:37 PM, serguei.spitsyn at oracle.com wrote: >> Coleen, >> >> It looks good. >> >> test/com/sun/jdi/BacktraceFieldTest.java: >> >> Nit: seems to be unneeded leftover: >> 71 // > Removed it. Thanks again, Serguei! Coleen >> Thanks, Serguei On 6/10/16 11:27, Coleen Phillimore wrote: >>> Summary: remove _backtrace as hidden field, since the original problem no longer exists The backtrace format is changed to be all java objects and no longer have jvm methodOops (pseudo Objects) which caused the crash. This change is being also tested by the customer. I ran full nightly tests on this. bug link https://bugs.openjdk.java.net/browse/JDK-8158237 open webrev at http://cr.openjdk.java.net/~coleenp/8158237.01/webrev open webrev at http://cr.openjdk.java.net/~coleenp/8158237.jdk.01/webrev Thanks, Coleen From coleen.phillimore at oracle.com Fri Jun 10 21:24:51 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 10 Jun 2016 17:24:51 -0400 Subject: RFR 8158237: JVMTI hides critical debug information for memory leak tracing In-Reply-To: <29FE364A-D60C-4EAF-9E13-FCED13006CA2@oracle.com> References: <792bc4db-b0a9-9eea-3401-a1df5be9f475@oracle.com> <575B2511.5080009@oracle.com> <29FE364A-D60C-4EAF-9E13-FCED13006CA2@oracle.com> Message-ID: Thanks, Jiangli! Coleen On 6/10/16 5:17 PM, Jiangli Zhou wrote: > Looks good. > > Thanks, > Jiangli > >> On Jun 10, 2016, at 1:49 PM, Coleen Phillimore wrote: >> >> >> >> On 6/10/16 4:37 PM, serguei.spitsyn at oracle.com wrote: >>> Coleen, >>> >>> It looks good. >>> >>> test/com/sun/jdi/BacktraceFieldTest.java: >>> >>> Nit: seems to be unneeded leftover: >>> 71 // >> Removed it. Thanks again, Serguei! Coleen >>> Thanks, Serguei On 6/10/16 11:27, Coleen Phillimore wrote: >>>> Summary: remove _backtrace as hidden field, since the original problem no longer exists The backtrace format is changed to be all java objects and no longer have jvm methodOops (pseudo Objects) which caused the crash. This change is being also tested by the customer. I ran full nightly tests on this. bug link https://bugs.openjdk.java.net/browse/JDK-8158237 open webrev at http://cr.openjdk.java.net/~coleenp/8158237.01/webrev open webrev at http://cr.openjdk.java.net/~coleenp/8158237.jdk.01/webrev Thanks, Coleen From paul.sandoz at oracle.com Fri Jun 10 22:39:54 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 10 Jun 2016 15:39:54 -0700 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: <57561996.4000501@oracle.com> References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> <57561996.4000501@oracle.com> Message-ID: <951844EF-D517-4BF5-861A-81769EA1C306@oracle.com> Hi Joe, It?s my turn to catch up on email? > On 6 Jun 2016, at 17:47, Joseph D. Darcy wrote: > > Hello, > > Catching up on email, there are several different notions on floating-point equality one might want to use. [1] > > One notion is the built-in "==" operator on float and double. This has the wrinkle of not defining an equivalence relation because of NaN values (not reflexive) and signed zeros (distinguishable values compare as equal). > > When I write floating-point tests, I'll use a notion of equality close to > > Float.compare(x, y) == 0 > > which means all NaN values are treated as the same and Float.compare(NaN, NaN) == 0 is true. This also distinguishes the signed zeros from each other. > > So comparing based on the non-raw bitwise conversion can give resonable semantics, at the cost of not preserving any payload stored in the NaN significand. > And potentially a performance hit too [*]. Pedantically since (NaN == NaN) is false, one could argue that it should not possible to CAS with an expected NaN value and/or a witness NaN value. Such behaviour might be considered BaNaNas :-) (sorry). I don?t think we can or should enforce that, but we should strongly advise against it and mention the pitfalls, and i will need to specify that the atomic ops perform bit-wise equality with suitable ?as if? text. Paul. [*] For example, the double[] accepting Arrays.equals method used to compare each element as: 2762 for (int i=0; i HTH, > > -Joe > > [1] "Notions of Floating-Point Equality ," https://blogs.oracle.com/darcy/entry/notions_of_floating_point_equality > > On 6/2/2016 1:34 AM, Paul Sandoz wrote: >>> On 2 Jun 2016, at 09:13, David Holmes wrote: >>> >>> On 2/06/2016 1:24 AM, Paul Sandoz wrote: >>>> (Please note this work is or will be covered with FC exception) >>>> >>>> Hi, >>>> >>>> Please review the VarHandles/Unsafe support for atomic ops on double/float fields/arrays. >>> I think this is misguided. If the user wants CAS for float/double they can do the conversion to int/long in a context where they know that conversion makes sense and where they can deal with NaNs appropriately. >>> >> I would still like to support some clearly defined default behaviour if at all possible, since this is not easy to get right so we can add some value here. The user can use int/long if that behaviour is not suitable. >> >> >>> At a minimum the fact this deals with raw bit patterns not semantic values needs to be exposed somehow. ie the handling of NaN needs to be explicit. >>> >> Yes, it?s multiple NaN values that collapse to a single NaN value. >> >> It would be good if our resident floating point expert Mr. Joe Darcy could chime in this respect. >> >> On Float.intBitsToFloat: >> >> *

Note that this method may not be able to return a >> * {@code float} NaN with exactly same bit pattern as the >> * {@code int} argument. IEEE 754 distinguishes between two >> * kinds of NaNs, quiet NaNs and signaling NaNs. The >> * differences between the two kinds of NaN are generally not >> * visible in Java. Arithmetic operations on signaling NaNs turn >> * them into quiet NaNs with a different, but often similar, bit >> * pattern. However, on some processors merely copying a >> * signaling NaN also performs that conversion. In particular, >> * copying a signaling NaN to return it to the calling method may >> * perform this conversion. So {@code intBitsToFloat} may >> * not be able to return a {@code float} with a signaling NaN >> * bit pattern. Consequently, for some {@code int} values, >> * {@code floatToRawIntBits(intBitsToFloat(start))} may >> * not equal {@code start}. Moreover, which >> * particular bit patterns represent signaling NaNs is platform >> * dependent; although all NaN bit patterns, quiet or signaling, >> * must be in the NaN range identified above. >> >> >> >> I am concerned that the CAS loops could in some cases loop without termination: >> >> @ForceInline >> public final float getAndAddFloat(Object o, long offset, float delta) { >> float v; >> do { >> v = getFloatVolatile(o, offset); >> } while (!weakCompareAndSwapFloatVolatile(o, offset, v, v + delta)); >> return v; >> } >> >> >> I think this should be: >> >> @ForceInline >> public final float getAndAddFloat(Object o, long offset, float delta) { >> int expectedBits; >> float v; >> do { >> expectedBits = getIntVolatile(o, offset); >> v = Float.intBitsToFloat(bits); // May not preserve a NaN value with the same bit pattern as expectedBits >> } while (!weakCompareAndSwapIntVolatile(o, offset, expectedBits, Float.floatToRawIntBits(v + delta))); >> return v; >> } >> >> and likewise for the atomic get-and-set methods. >> >> Paul. >> >>> David >>> ----- >>> >>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ >>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ >>>> >>>> These patches are based on those of for sub-word CAS >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8157726 >>>> http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/ >>>> http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/ >>>> >>>> And the two patches combined expand the support of fields/arrays. >>>> >>>> >>>> New float/double CAS methods are added to Unsafe that defer to int/long equivalents. Then the other atomic methods are built from weak CAS loops. >>>> >>>> No changes are required to HotSpot, but changes are required to the Unsafe tests in the hotspot repository. >>>> >>>> In general the changes to VHs and tests are minimal since it is triggered from changes to the generating scripts that now include float/double into the CAS category. >>>> >>>> There are some minor specification changes and a CCC has been initiated. >>>> >>>> JPRT tests results show no relevant failures for hotspot and core test sets. >>>> >>>> Thanks, >>>> Paul. >>>> > From david.holmes at oracle.com Sat Jun 11 00:26:52 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 11 Jun 2016 10:26:52 +1000 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> Message-ID: <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> Hi Coleen, If I may ... On 11/06/2016 5:43 AM, Coleen Phillimore wrote: > > Hi, > > I'm late to the thread, which is good because it's better that this > check is done in the rewriter, than in InstanceKlass. > > But I'm fuzzy on why this wasn't checked in the verifier, and what the > purpose of the has_initialized_final_update (which means a non > method has updated a final field, which is a verify error, right? Can't comment on the verifier part. The check is only currently enforced for classfile versions for JDK9+ > Also, have you run the JCK tests? > > Why have a global flag if it's an error? We are enforcing a rule that has not been enforced before. To deal with compatibility issues we have provided, as is customary for non-security issues, a flag that allows the enforcement to be turned off, if it causes a problem. (Though that is more likely needed for JDK 7/8 compatibility than for 9). David > Thanks, > Coleen > > > > On 6/10/16 1:40 PM, Zolt?n Maj? wrote: >> Hi Vladimir, >> >> >> On 06/10/2016 06:05 PM, Vladimir Ivanov wrote: >>> >>>> Please note an additional small change in rewriter.cpp: >>>> >>>> +if (!reverse) { >>>> // Check if any final field of the class given as parameter is modified >>>> // outside of initializer methods of the class. Fields that are >>>> modified >>>> ... >>>> +} >>>> >>>> It's sufficient to check fields during rewriting (i.e., we're coming >>>> from Rewriter::rewrite_bytecodes()). We do not need to do the checks if >>>> the class has already been rewritten but we're reversing changes due to >>>> some failure that appeared during rewriting (in that case scan_method() >>>> is called from Rewriter::restore_bytecodes()). >>> >>> Ok. >>> >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/ >>> >>> Looks good. >>> >>> src/share/vm/runtime/globals.hpp >>> >>> + "for classfile version >= 51") >>> >>> s/51/53/ (no need to send new webrev). >> >> OK, I've corrected the code in-situ (in webrev.11). I also have the >> JPRT results now, all tests pass. >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >> >> >>> >>> Best regards, >>> Vladimir Ivanov >> > From zoltan.majo at oracle.com Sat Jun 11 10:13:12 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Sat, 11 Jun 2016 12:13:12 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> Message-ID: <575BE438.6010904@oracle.com> Hi Coleen, thank you for the feedback! On 06/10/2016 09:43 PM, Coleen Phillimore wrote: > > Hi, > > I'm late to the thread, which is good because it's better that this > check is done in the rewriter, than in InstanceKlass. I'm glad you are OK with that. > > But I'm fuzzy on why this wasn't checked in the verifier, and what the > purpose of the has_initialized_final_update (which means a non > method has updated a final field, which is a verify error, right? I think it is a linking exception that is supposed to be thrown during field resolution. Please see some details below (I use putfield as an example). For putfield "Linking Exceptions", the JVMS-6 [1] states: "During resolution of the symbolic reference to the field, any of the exceptions pertaining to field resolution documented in Section 5.4.3.2 can be thrown. [...] Otherwise, if the field is final, it must be declared in the current class. Otherwise, an IllegalAccessError is thrown." With JVMS-7 [2], the second sentence has changed the following way: "Otherwise, if the field is final, it must be declared in the current class, and the instruction must occur in an instance initialization method () of the current class. Otherwise, an IllegalAccessError is thrown." HotSpot currently enforces JVMS-6 (i.e.,that the final field accessed by the putfield must be declared in the current class). That condition is checked in LinkResolver::resolve_field() in linkResolver.cpp. The current patch proposes to check *also* that the instruction occurs in the method, as required by JVMS-7. I've added that check also to LinkResolver::resolve_field() (I had the feeling that the two checks belong together). The new check is, however, enforced only for class file versions >=JDK-9 (as David pointed out earlier). Regarding has_initialized_final_update: Some compiler optimizations assume that final fields are modified only in initializer methods. That assumption does always not hold (e.g., for class file versions > Also, have you run the JCK tests? Yes, I've run all all JCK tests executed in JPRT (the runThese8 target). I also did a complete pre-PIT RBT (with -Xmixed and -Xcomp) run. No failures have occurred. > > Why have a global flag if it's an error? David has pointed out the reasons in his reply. Thank you! Best regards, Zoltan [1] https://docs.oracle.com/javase/specs/jvms/se6/html/Instructions2.doc11.html [2] https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.putfield > > Thanks, > Coleen > > > > On 6/10/16 1:40 PM, Zolt?n Maj? wrote: >> Hi Vladimir, >> >> >> On 06/10/2016 06:05 PM, Vladimir Ivanov wrote: >>> >>>> Please note an additional small change in rewriter.cpp: >>>> >>>> +if (!reverse) { >>>> // Check if any final field of the class given as parameter is >>>> modified >>>> // outside of initializer methods of the class. Fields that are >>>> modified >>>> ... >>>> +} >>>> >>>> It's sufficient to check fields during rewriting (i.e., we're coming >>>> from Rewriter::rewrite_bytecodes()). We do not need to do the >>>> checks if >>>> the class has already been rewritten but we're reversing changes >>>> due to >>>> some failure that appeared during rewriting (in that case >>>> scan_method() >>>> is called from Rewriter::restore_bytecodes()). >>> >>> Ok. >>> >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/ >>> >>> Looks good. >>> >>> src/share/vm/runtime/globals.hpp >>> >>> + "for classfile version >= 51") >>> >>> s/51/53/ (no need to send new webrev). >> >> OK, I've corrected the code in-situ (in webrev.11). I also have the >> JPRT results now, all tests pass. >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >> >> >>> >>> Best regards, >>> Vladimir Ivanov >> > From zoltan.majo at oracle.com Sat Jun 11 10:13:56 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Sat, 11 Jun 2016 12:13:56 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> Message-ID: <575BE464.4030001@oracle.com> Hi David, On 06/11/2016 02:26 AM, David Holmes wrote: > > > Hi Coleen, > > If I may ... > > On 11/06/2016 5:43 AM, Coleen Phillimore wrote: >> >> Hi, >> >> I'm late to the thread, which is good because it's better that this >> check is done in the rewriter, than in InstanceKlass. >> >> But I'm fuzzy on why this wasn't checked in the verifier, and what the >> purpose of the has_initialized_final_update (which means a non >> method has updated a final field, which is a verify error, right? > > Can't comment on the verifier part. > > The check is only currently enforced for classfile versions for JDK9+ > >> Also, have you run the JCK tests? >> >> Why have a global flag if it's an error? > > We are enforcing a rule that has not been enforced before. To deal > with compatibility issues we have provided, as is customary for > non-security issues, a flag that allows the enforcement to be turned > off, if it causes a problem. (Though that is more likely needed for > JDK 7/8 compatibility than for 9). thank you for clarifying that! Best regards, Zoltan > > David > >> Thanks, >> Coleen >> >> >> >> On 6/10/16 1:40 PM, Zolt?n Maj? wrote: >>> Hi Vladimir, >>> >>> >>> On 06/10/2016 06:05 PM, Vladimir Ivanov wrote: >>>> >>>>> Please note an additional small change in rewriter.cpp: >>>>> >>>>> +if (!reverse) { >>>>> // Check if any final field of the class given as parameter is >>>>> modified >>>>> // outside of initializer methods of the class. Fields that are >>>>> modified >>>>> ... >>>>> +} >>>>> >>>>> It's sufficient to check fields during rewriting (i.e., we're coming >>>>> from Rewriter::rewrite_bytecodes()). We do not need to do the >>>>> checks if >>>>> the class has already been rewritten but we're reversing changes >>>>> due to >>>>> some failure that appeared during rewriting (in that case >>>>> scan_method() >>>>> is called from Rewriter::restore_bytecodes()). >>>> >>>> Ok. >>>> >>>>> Here is the updated webrev: >>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/ >>>> >>>> Looks good. >>>> >>>> src/share/vm/runtime/globals.hpp >>>> >>>> + "for classfile version >= 51") >>>> >>>> s/51/53/ (no need to send new webrev). >>> >>> OK, I've corrected the code in-situ (in webrev.11). I also have the >>> JPRT results now, all tests pass. >>> >>> Thank you! >>> >>> Best regards, >>> >>> >>> Zoltan >>> >>> >>> >>>> >>>> Best regards, >>>> Vladimir Ivanov >>> >> From david.holmes at oracle.com Sun Jun 12 23:42:08 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Jun 2016 09:42:08 +1000 Subject: RFR 8152271: MemberNameTable doesn't purge stale entries In-Reply-To: References: Message-ID: Hi Coleen, On 11/06/2016 12:55 AM, Coleen Phillimore wrote: > Summary: Intern MemberNames in table instead of allocating new entries > > For degenerate case, we were leaking native code in the member name > table. Going with the suggested workaround, it was only a few more > lines of code to intern MemberName and return the MemberName that was > already in the table. I guess I'm very surprised that these were not already being "cached" at some level (ie the Java level where all other reflection-like objects get cached)! I'm not familiar with the mechanics or j.l.invoke so was wondering where MemberName instances actually get created - because I'd like to understand how you get two distinct MemberName instances that compare equal in the first place? Otherwise changes seem fine - though perhaps MemberNameTable::add_member_name should assert the member_name is not already present, just to confirm those intern==false cases are working as intended. Thanks, David ----- > This has been performance tested to show no regression and works really > well for the degenerate test case, even though the real percentage of > reused MemberName seems quite small. > > Tested with all runtime nightly tests, tests in jdk/test/java/lang/invoke. > > open webrev at http://cr.openjdk.java.net/~coleenp/8152271.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8152271 > > Thanks, > Coleen From erik.helin at oracle.com Mon Jun 13 08:35:31 2016 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 13 Jun 2016 10:35:31 +0200 Subject: Submitted JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector In-Reply-To: <1029478489.9095893.1465482340231.JavaMail.zimbra@redhat.com> References: <20160504075621.450403951eggemoggin.niobe.net> <729617618.2672396.1463148140398.JavaMail.zimbra@redhat.com> <20160516124402.GG32434@ehelin.jrpg.bea.com> <545560389.4790998.1464037461928.JavaMail.zimbra@redhat.com> <20160525093308.GB23701@ehelin.jrpg.bea.com> <1029478489.9095893.1465482340231.JavaMail.zimbra@redhat.com> Message-ID: <20160613083531.GM26799@ehelin.jrpg.bea.com> On 2016-06-09, Christine Flood wrote: > > > ----- Original Message ----- > > From: "Erik Helin" > > To: "Christine Flood" > > Cc: hotspot-dev at openjdk.java.net > > Sent: Wednesday, May 25, 2016 5:33:08 AM > > Subject: Re: Submitted JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector > > ... > > Ok, then I would like you to make sure that compiling the Shenandoah > > code is controlled with a configure variable, similar to jvmci, shark, > > dtrace, vm-structs, etc: > > > > sh configure --with-jvm-features=shenandoah > > > > > > There are some refactorings that we've done to make sharing code between G1 and Shenandoah easier. > We'd like to put those back upstream as is. They make merges much simpler for us. Do you mean the patch that Roman sent to hotspot-gc-dev? I will look at the patch and give my feedback in that email thread. > We can isolate the Shenandoah specific barriers with a flag as you suggest but may we request that the > flag be left on by default. This provides the option to turn Shenandoah off if there is an > issue but provides us with more testing/exposure. Given that the barriers is a new and intrusive change, the configure flag will have to start out by being off by default. Once the code has gone through significant testing and there is support for all the OpenJDK platforms, then we can have a discussion again about having the configure flag being on by default. The stability of OpenJDK is very important, it is better to introduce new, intrusive changes gradually. Thanks, Erik > Christine From coleen.phillimore at oracle.com Mon Jun 13 12:23:43 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 13 Jun 2016 08:23:43 -0400 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <575BE438.6010904@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <575BE438.6010904@oracle.com> Message-ID: Hi Zoltan, On 6/11/16 6:13 AM, Zolt?n Maj? wrote: > Hi Coleen, > > > thank you for the feedback! > > On 06/10/2016 09:43 PM, Coleen Phillimore wrote: >> >> Hi, >> >> I'm late to the thread, which is good because it's better that this >> check is done in the rewriter, than in InstanceKlass. > > I'm glad you are OK with that. Yes, I think this is better. We only want one bytecode iteration during linking. At one point, we talked about not having the rewriter but that'll never happen. > >> >> But I'm fuzzy on why this wasn't checked in the verifier, and what >> the purpose of the has_initialized_final_update (which means a non >> method has updated a final field, which is a verify error, right? > > I think it is a linking exception that is supposed to be thrown during > field resolution. Please see some details below (I use putfield as an > example). > > For putfield "Linking Exceptions", the JVMS-6 [1] states: > > "During resolution of the symbolic reference to the field, any of the > exceptions pertaining to field resolution documented in Section > 5.4.3.2 can be thrown. > [...] > Otherwise, if the field is final, it must be declared in the current > class. Otherwise, an IllegalAccessError is thrown." > > With JVMS-7 [2], the second sentence has changed the following way: > > "Otherwise, if the field is final, it must be declared in the current > class, and the instruction must occur in an instance initialization > method () of the current class. Otherwise, an IllegalAccessError > is thrown." > > HotSpot currently enforces JVMS-6 (i.e.,that the final field accessed > by the putfield must be declared in the current class). That condition > is checked in LinkResolver::resolve_field() in linkResolver.cpp. Thank you for the clarification. It looks correct. > > The current patch proposes to check *also* that the instruction occurs > in the method, as required by JVMS-7. I've added that check > also to LinkResolver::resolve_field() (I had the feeling that the two > checks belong together). The new check is, however, enforced only for > class file versions >=JDK-9 (as David pointed out earlier). > > Regarding has_initialized_final_update: Some compiler optimizations > assume that final fields are modified only in initializer methods. > That assumption does always not hold (e.g., for class file versions > outside initializers; for such fields has_initialized_final_update() > returns true. > > The analysis to detect "invalid" updates to final fields must be > performed before any of a class's methods is compiled. So the analysis > is performed at class loading and initialization. Ok. I didn't understand how it affected the compilers but that's beyond the scope of my review anyway. > > The current patch proposes to do the analysis in the rewriter. That > way we don't introduce an extra iteration over all bytecodes that are > loaded (because we piggyback on the iteration performed by the > rewriter). So we reduce the risk of potential performance degradations. > >> >> Also, have you run the JCK tests? > > Yes, I've run all all JCK tests executed in JPRT (the runThese8 > target). I also did a complete pre-PIT RBT (with -Xmixed and -Xcomp) > run. No failures have occurred. > I'll send you a link to how to run the jck9 jck tests. They take a bit longer to run. They may run with the pre-PIT RBT though, so you might be ok. Please check that this is the case. >> >> Why have a global flag if it's an error? > > David has pointed out the reasons in his reply. > Ok. Makes sense. I wonder if I should have done that with https://bugs.openjdk.java.net/browse/JDK-8145148 Thanks, Coleen > Thank you! > > Best regards, > > > Zoltan > > [1] > https://docs.oracle.com/javase/specs/jvms/se6/html/Instructions2.doc11.html > > [2] > https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.putfield >> >> Thanks, >> Coleen >> >> >> >> On 6/10/16 1:40 PM, Zolt?n Maj? wrote: >>> Hi Vladimir, >>> >>> >>> On 06/10/2016 06:05 PM, Vladimir Ivanov wrote: >>>> >>>>> Please note an additional small change in rewriter.cpp: >>>>> >>>>> +if (!reverse) { >>>>> // Check if any final field of the class given as parameter is >>>>> modified >>>>> // outside of initializer methods of the class. Fields that are >>>>> modified >>>>> ... >>>>> +} >>>>> >>>>> It's sufficient to check fields during rewriting (i.e., we're coming >>>>> from Rewriter::rewrite_bytecodes()). We do not need to do the >>>>> checks if >>>>> the class has already been rewritten but we're reversing changes >>>>> due to >>>>> some failure that appeared during rewriting (in that case >>>>> scan_method() >>>>> is called from Rewriter::restore_bytecodes()). >>>> >>>> Ok. >>>> >>>>> Here is the updated webrev: >>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/ >>>> >>>> Looks good. >>>> >>>> src/share/vm/runtime/globals.hpp >>>> >>>> + "for classfile version >= 51") >>>> >>>> s/51/53/ (no need to send new webrev). >>> >>> OK, I've corrected the code in-situ (in webrev.11). I also have the >>> JPRT results now, all tests pass. >>> >>> Thank you! >>> >>> Best regards, >>> >>> >>> Zoltan >>> >>> >>> >>>> >>>> Best regards, >>>> Vladimir Ivanov >>> >> > From coleen.phillimore at oracle.com Mon Jun 13 12:24:45 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 13 Jun 2016 08:24:45 -0400 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <575BE464.4030001@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <575BE464.4030001@oracle.com> Message-ID: <4043b483-c940-beb5-3bd1-908b7cab024a@oracle.com> One more question. On 6/11/16 6:13 AM, Zolt?n Maj? wrote: > Hi David, > > > On 06/11/2016 02:26 AM, David Holmes wrote: >> >> >> Hi Coleen, >> >> If I may ... >> >> On 11/06/2016 5:43 AM, Coleen Phillimore wrote: >>> >>> Hi, >>> >>> I'm late to the thread, which is good because it's better that this >>> check is done in the rewriter, than in InstanceKlass. >>> >>> But I'm fuzzy on why this wasn't checked in the verifier, and what the >>> purpose of the has_initialized_final_update (which means a non >>> method has updated a final field, which is a verify error, right? >> >> Can't comment on the verifier part. >> >> The check is only currently enforced for classfile versions for JDK9+ >> >>> Also, have you run the JCK tests? >>> >>> Why have a global flag if it's an error? >> >> We are enforcing a rule that has not been enforced before. To deal >> with compatibility issues we have provided, as is customary for >> non-security issues, a flag that allows the enforcement to be turned >> off, if it causes a problem. (Though that is more likely needed for >> JDK 7/8 compatibility than for 9). > > thank you for clarifying that! Can we time-bomb this option, so we can remove it in 10? thanks, Coleen > > Best regards, > > > Zoltan > >> >> David >> >>> Thanks, >>> Coleen >>> >>> >>> >>> On 6/10/16 1:40 PM, Zolt?n Maj? wrote: >>>> Hi Vladimir, >>>> >>>> >>>> On 06/10/2016 06:05 PM, Vladimir Ivanov wrote: >>>>> >>>>>> Please note an additional small change in rewriter.cpp: >>>>>> >>>>>> +if (!reverse) { >>>>>> // Check if any final field of the class given as parameter is >>>>>> modified >>>>>> // outside of initializer methods of the class. Fields that are >>>>>> modified >>>>>> ... >>>>>> +} >>>>>> >>>>>> It's sufficient to check fields during rewriting (i.e., we're coming >>>>>> from Rewriter::rewrite_bytecodes()). We do not need to do the >>>>>> checks if >>>>>> the class has already been rewritten but we're reversing changes >>>>>> due to >>>>>> some failure that appeared during rewriting (in that case >>>>>> scan_method() >>>>>> is called from Rewriter::restore_bytecodes()). >>>>> >>>>> Ok. >>>>> >>>>>> Here is the updated webrev: >>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/ >>>>> >>>>> Looks good. >>>>> >>>>> src/share/vm/runtime/globals.hpp >>>>> >>>>> + "for classfile version >= 51") >>>>> >>>>> s/51/53/ (no need to send new webrev). >>>> >>>> OK, I've corrected the code in-situ (in webrev.11). I also have the >>>> JPRT results now, all tests pass. >>>> >>>> Thank you! >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>>> >>>> >>>> >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>> >>> > From alexhenrie24 at gmail.com Mon Jun 13 15:51:50 2016 From: alexhenrie24 at gmail.com (Alex Henrie) Date: Mon, 13 Jun 2016 09:51:50 -0600 Subject: [PATCH resend2] 8157758: Use (~0u) instead of (-1) when left-shifting Message-ID: # HG changeset patch # User ahenrie # Date 1464130244 21600 # Tue May 24 16:50:44 2016 -0600 # Node ID e3e2afa872c68a8fc7891fc25a9a11dab0704787 # Parent 3f4173a750ac10fa4c22ed3d0e3d8d43bab3020b 8157758: Use (~0u) instead of (-1) when left-shifting diff --git a/src/share/vm/code/dependencies.hpp b/src/share/vm/code/dependencies.hpp --- a/src/share/vm/code/dependencies.hpp +++ b/src/share/vm/code/dependencies.hpp @@ -163,17 +163,17 @@ class Dependencies: public ResourceObj { call_site_target_value, TYPE_LIMIT }; enum { LG2_TYPE_LIMIT = 4, // assert(TYPE_LIMIT <= (1< References: <5759AFCE.2080406@oracle.com> Message-ID: <575EF096.9020908@oracle.com> Jiangli, Thanks for looking. I didn't see anything that looked like it might produce duplicate events. However, I did see some additional places where it looks like no event is fire. Can anyone point me to the event specs? Thanks, Max On 6/9/2016 4:39 PM, Jiangli Zhou wrote: > Hi Max, > > Looks ok. The only possible issue is more than one event might be sent in some of the call paths. But my quick search didn?t find any of such case. > > Thanks, > Jiangli > >> On Jun 9, 2016, at 11:05 AM, Max Ockner wrote: >> >> Hello, >> >> Please review this small fix which causes the vm/class/load event to be fired from JVM_DefineClass() and JVM_DefineClassWithSource(). >> >> Webrev: http://cr.openjdk.java.net/~mockner/8038332/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8038332 >> >> The vm/class/load event (EventClassLoad) was previously fired in 2 places: >> >> SystemDictionary::parse_stream >> SystemDictionary::resolve_instance_class_or_null >> >> parse_stream is the standard option for creating a klass from a stream, but JVM_DefineClass uses a different function: >> >> SystemDictionary::resolve_from_stream. >> >> This did not fire a vm/class/load event. Now it does fire the event. >> >> Sanity tested with jtreg runtime. Issue was reproduced and tested using the reproducer script attached to the bug >> >> Thanks, >> Max From david.holmes at oracle.com Mon Jun 13 22:05:08 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Jun 2016 08:05:08 +1000 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <4043b483-c940-beb5-3bd1-908b7cab024a@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <575BE464.4030001@oracle.com> <4043b483-c940-beb5-3bd1-908b7cab024a@oracle.com> Message-ID: On 13/06/2016 10:24 PM, Coleen Phillimore wrote: > One more question. >>>> Why have a global flag if it's an error? >>> >>> We are enforcing a rule that has not been enforced before. To deal >>> with compatibility issues we have provided, as is customary for >>> non-security issues, a flag that allows the enforcement to be turned >>> off, if it causes a problem. (Though that is more likely needed for >>> JDK 7/8 compatibility than for 9). >> >> thank you for clarifying that! > > Can we time-bomb this option, so we can remove it in 10? I think it would have to follow a staged deprecation process: deprecate in 10 and remove in 11. To some extent it depends on whether the systems that currently produce this non-compliant bytecode can be modified in the JDK 9 and 10 timeframes so that the problem disappears. It may be this becomes a non-issue even before 9 GA ... David > thanks, > Coleen > >> >> Best regards, >> >> >> Zoltan >> >>> >>> David >>> >>>> Thanks, >>>> Coleen >>>> >>>> >>>> >>>> On 6/10/16 1:40 PM, Zolt?n Maj? wrote: >>>>> Hi Vladimir, >>>>> >>>>> >>>>> On 06/10/2016 06:05 PM, Vladimir Ivanov wrote: >>>>>> >>>>>>> Please note an additional small change in rewriter.cpp: >>>>>>> >>>>>>> +if (!reverse) { >>>>>>> // Check if any final field of the class given as parameter is >>>>>>> modified >>>>>>> // outside of initializer methods of the class. Fields that are >>>>>>> modified >>>>>>> ... >>>>>>> +} >>>>>>> >>>>>>> It's sufficient to check fields during rewriting (i.e., we're coming >>>>>>> from Rewriter::rewrite_bytecodes()). We do not need to do the >>>>>>> checks if >>>>>>> the class has already been rewritten but we're reversing changes >>>>>>> due to >>>>>>> some failure that appeared during rewriting (in that case >>>>>>> scan_method() >>>>>>> is called from Rewriter::restore_bytecodes()). >>>>>> >>>>>> Ok. >>>>>> >>>>>>> Here is the updated webrev: >>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/ >>>>>> >>>>>> Looks good. >>>>>> >>>>>> src/share/vm/runtime/globals.hpp >>>>>> >>>>>> + "for classfile version >= 51") >>>>>> >>>>>> s/51/53/ (no need to send new webrev). >>>>> >>>>> OK, I've corrected the code in-situ (in webrev.11). I also have the >>>>> JPRT results now, all tests pass. >>>>> >>>>> Thank you! >>>>> >>>>> Best regards, >>>>> >>>>> >>>>> Zoltan >>>>> >>>>> >>>>> >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>> >>>> >> > From david.holmes at oracle.com Mon Jun 13 22:40:35 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Jun 2016 08:40:35 +1000 Subject: RFR: 8038332: The trace event vm/class/load is not always being sent In-Reply-To: <575EF096.9020908@oracle.com> References: <5759AFCE.2080406@oracle.com> <575EF096.9020908@oracle.com> Message-ID: <95d4e379-2680-1e49-f972-831e4e1701ba@oracle.com> Hi Max, On 14/06/2016 3:42 AM, Max Ockner wrote: > Jiangli, > Thanks for looking. I didn't see anything that looked like it might > produce duplicate events. However, I did see some additional places > where it looks like no event is fire. > > Can anyone point me to the event specs? I'm not sure there is any spec for this. Even JFR doesn't seem to document individual events and when they are triggered. Your change does not look right however as you are posting the classload event regardless of the exception state. If you look at SystemDictionary::resolve_instance_class_or_null, it only posts after checking the load was successful: 892 if (HAS_PENDING_EXCEPTION || k.is_null()) { 893 return NULL; 894 } 895 896 post_class_load_event(class_load_start_time, k, class_loader); Similarly, SystemDictionary::parse_stream, has various CHECK macros that will cause a return on exception, prior to getting to the point of posting the load event. So you also need to add a check for a pending exception and that k is not null, I think, before posting the event. BTW I would have expected to see trace-events generated at approximately the same locations as the corresponding JVMTI events. That does not seem to be the case which seems very strange to me. The notion of "loading a class" seems to be spread across far too many functions to me. Thanks, David > Thanks, > Max > > On 6/9/2016 4:39 PM, Jiangli Zhou wrote: >> Hi Max, >> >> Looks ok. The only possible issue is more than one event might be sent >> in some of the call paths. But my quick search didn?t find any of such >> case. >> >> Thanks, >> Jiangli >> >>> On Jun 9, 2016, at 11:05 AM, Max Ockner wrote: >>> >>> Hello, >>> >>> Please review this small fix which causes the vm/class/load event to >>> be fired from JVM_DefineClass() and JVM_DefineClassWithSource(). >>> >>> Webrev: http://cr.openjdk.java.net/~mockner/8038332/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038332 >>> >>> The vm/class/load event (EventClassLoad) was previously fired in 2 >>> places: >>> >>> SystemDictionary::parse_stream >>> SystemDictionary::resolve_instance_class_or_null >>> >>> parse_stream is the standard option for creating a klass from a >>> stream, but JVM_DefineClass uses a different function: >>> >>> SystemDictionary::resolve_from_stream. >>> >>> This did not fire a vm/class/load event. Now it does fire the event. >>> >>> Sanity tested with jtreg runtime. Issue was reproduced and tested >>> using the reproducer script attached to the bug >>> >>> Thanks, >>> Max > From paul.sandoz at oracle.com Tue Jun 14 00:12:14 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 13 Jun 2016 17:12:14 -0700 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: <951844EF-D517-4BF5-861A-81769EA1C306@oracle.com> References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> <57561996.4000501@oracle.com> <951844EF-D517-4BF5-861A-81769EA1C306@oracle.com> Message-ID: Hi, Here is an updated webrev. http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ Changes - the Unsafe.getAndAdd for float/double operate in the bit-domain. - documentation added to the factory methods: 1221 *

1222 * If the field type is {@code float} or {@code double} then numeric 1223 * and atomic update access modes compare values using their bitwise 1224 * representation (see {@link Float#floatToRawIntBits} and 1225 * {@link Double#doubleToRawLongBits}, respectively). 1226 *

1227 * @apiNote 1228 * Bitwise comparison of {@code float} values or {@code double} values, 1229 * as performed by the numeric and atomic update access modes, differ 1230 * from the primitive {@code ==} operator and the {@link Float#equals} 1231 * and {@link Double#equals} methods, notably with respect to 1232 * {@code NaN}. There are many possible NaN values that are considered 1233 * to be {@code NaN} in Java, although no IEEE 754 floating-point 1234 * operation provided by Java can distinguish between them. As such 1235 * care should be taken when performing a compare and set or a compare 1236 * and exchange operation with NaN values since the operation may 1237 * unexpectedly fail. Failure can occur if the expected or witness 1238 * value is a NaN value and it is transformed (perhaps in a platform 1239 * specific manner) into another NaN value, and thus has a different 1240 * bitwise representation (see {@link Float#intBitsToFloat} or 1241 * Double#longBitsToDouble for more details). (I also updated the documentation on array/ByteBuffer view methods but did not bother with the api note) Paul. > On 10 Jun 2016, at 15:39, Paul Sandoz wrote: > > Hi Joe, > > It?s my turn to catch up on email? > > >> On 6 Jun 2016, at 17:47, Joseph D. Darcy wrote: >> >> Hello, >> >> Catching up on email, there are several different notions on floating-point equality one might want to use. [1] >> >> One notion is the built-in "==" operator on float and double. This has the wrinkle of not defining an equivalence relation because of NaN values (not reflexive) and signed zeros (distinguishable values compare as equal). >> >> When I write floating-point tests, I'll use a notion of equality close to >> >> Float.compare(x, y) == 0 >> >> which means all NaN values are treated as the same and Float.compare(NaN, NaN) == 0 is true. This also distinguishes the signed zeros from each other. >> >> So comparing based on the non-raw bitwise conversion can give resonable semantics, at the cost of not preserving any payload stored in the NaN significand. >> > > And potentially a performance hit too [*]. > > Pedantically since (NaN == NaN) is false, one could argue that it should not possible to CAS with an expected NaN value and/or a witness NaN value. Such behaviour might be considered BaNaNas :-) (sorry). I don?t think we can or should enforce that, but we should strongly advise against it and mention the pitfalls, and i will need to specify that the atomic ops perform bit-wise equality with suitable ?as if? text. > > Paul. > > [*] For example, the double[] accepting Arrays.equals method used to compare each element as: > > 2762 for (int i=0; i 2763 if (Double.doubleToLongBits(a[i])!=Double.doubleToLongBits(a2[i])) > 2764 return false; > > In the interim of my adding vectorized mismatch support i changed that to: > > 3057 for (int i=0; i 3058 double v1 = a[i], v2 = a2[i]; > 3059 if (Double.doubleToRawLongBits(v1) != Double.doubleToRawLongBits(v2)) > 3060 if (!Double.isNaN(v1) || !Double.isNaN(v2)) > 3061 return false; > 3062 } > > Which boosted the performance similar to that of comparing long[] (when no NaNs are present). > > >> HTH, >> >> -Joe >> >> [1] "Notions of Floating-Point Equality ," https://blogs.oracle.com/darcy/entry/notions_of_floating_point_equality >> >> On 6/2/2016 1:34 AM, Paul Sandoz wrote: >>>> On 2 Jun 2016, at 09:13, David Holmes wrote: >>>> >>>> On 2/06/2016 1:24 AM, Paul Sandoz wrote: >>>>> (Please note this work is or will be covered with FC exception) >>>>> >>>>> Hi, >>>>> >>>>> Please review the VarHandles/Unsafe support for atomic ops on double/float fields/arrays. >>>> I think this is misguided. If the user wants CAS for float/double they can do the conversion to int/long in a context where they know that conversion makes sense and where they can deal with NaNs appropriately. >>>> >>> I would still like to support some clearly defined default behaviour if at all possible, since this is not easy to get right so we can add some value here. The user can use int/long if that behaviour is not suitable. >>> >>> >>>> At a minimum the fact this deals with raw bit patterns not semantic values needs to be exposed somehow. ie the handling of NaN needs to be explicit. >>>> >>> Yes, it?s multiple NaN values that collapse to a single NaN value. >>> >>> It would be good if our resident floating point expert Mr. Joe Darcy could chime in this respect. >>> >>> On Float.intBitsToFloat: >>> >>> *

Note that this method may not be able to return a >>> * {@code float} NaN with exactly same bit pattern as the >>> * {@code int} argument. IEEE 754 distinguishes between two >>> * kinds of NaNs, quiet NaNs and signaling NaNs. The >>> * differences between the two kinds of NaN are generally not >>> * visible in Java. Arithmetic operations on signaling NaNs turn >>> * them into quiet NaNs with a different, but often similar, bit >>> * pattern. However, on some processors merely copying a >>> * signaling NaN also performs that conversion. In particular, >>> * copying a signaling NaN to return it to the calling method may >>> * perform this conversion. So {@code intBitsToFloat} may >>> * not be able to return a {@code float} with a signaling NaN >>> * bit pattern. Consequently, for some {@code int} values, >>> * {@code floatToRawIntBits(intBitsToFloat(start))} may >>> * not equal {@code start}. Moreover, which >>> * particular bit patterns represent signaling NaNs is platform >>> * dependent; although all NaN bit patterns, quiet or signaling, >>> * must be in the NaN range identified above. >>> >>> >>> >>> I am concerned that the CAS loops could in some cases loop without termination: >>> >>> @ForceInline >>> public final float getAndAddFloat(Object o, long offset, float delta) { >>> float v; >>> do { >>> v = getFloatVolatile(o, offset); >>> } while (!weakCompareAndSwapFloatVolatile(o, offset, v, v + delta)); >>> return v; >>> } >>> >>> >>> I think this should be: >>> >>> @ForceInline >>> public final float getAndAddFloat(Object o, long offset, float delta) { >>> int expectedBits; >>> float v; >>> do { >>> expectedBits = getIntVolatile(o, offset); >>> v = Float.intBitsToFloat(bits); // May not preserve a NaN value with the same bit pattern as expectedBits >>> } while (!weakCompareAndSwapIntVolatile(o, offset, expectedBits, Float.floatToRawIntBits(v + delta))); >>> return v; >>> } >>> >>> and likewise for the atomic get-and-set methods. >>> >>> Paul. >>> >>>> David >>>> ----- >>>> >>>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ >>>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ >>>>> >>>>> These patches are based on those of for sub-word CAS >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8157726 >>>>> http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/ >>>>> http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/ >>>>> >>>>> And the two patches combined expand the support of fields/arrays. >>>>> >>>>> >>>>> New float/double CAS methods are added to Unsafe that defer to int/long equivalents. Then the other atomic methods are built from weak CAS loops. >>>>> >>>>> No changes are required to HotSpot, but changes are required to the Unsafe tests in the hotspot repository. >>>>> >>>>> In general the changes to VHs and tests are minimal since it is triggered from changes to the generating scripts that now include float/double into the CAS category. >>>>> >>>>> There are some minor specification changes and a CCC has been initiated. >>>>> >>>>> JPRT tests results show no relevant failures for hotspot and core test sets. >>>>> >>>>> Thanks, >>>>> Paul. >>>>> >> > From joe.darcy at oracle.com Tue Jun 14 04:09:01 2016 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 13 Jun 2016 21:09:01 -0700 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> <57561996.4000501@oracle.com> <951844EF-D517-4BF5-861A-81769EA1C306@oracle.com> Message-ID: <8d668cf7-1f40-8310-117e-267cefe2ab5c@oracle.com> Hi Paul, I suggest also pointing out that a bitwise comparison distinguishes -0.0 from +0.0; they compare as == under the built-in operation. HTH, -Joe On 6/13/2016 5:12 PM, Paul Sandoz wrote: > Hi, > > Here is an updated webrev. > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ > > Changes > > - the Unsafe.getAndAdd for float/double operate in the bit-domain. > > - documentation added to the factory methods: > > 1221 *

> 1222 * If the field type is {@code float} or {@code double} then numeric > 1223 * and atomic update access modes compare values using their bitwise > 1224 * representation (see {@link Float#floatToRawIntBits} and > 1225 * {@link Double#doubleToRawLongBits}, respectively). > 1226 *

> 1227 * @apiNote > 1228 * Bitwise comparison of {@code float} values or {@code double} values, > 1229 * as performed by the numeric and atomic update access modes, differ > 1230 * from the primitive {@code ==} operator and the {@link Float#equals} > 1231 * and {@link Double#equals} methods, notably with respect to > 1232 * {@code NaN}. There are many possible NaN values that are considered > 1233 * to be {@code NaN} in Java, although no IEEE 754 floating-point > 1234 * operation provided by Java can distinguish between them. As such > 1235 * care should be taken when performing a compare and set or a compare > 1236 * and exchange operation with NaN values since the operation may > 1237 * unexpectedly fail. Failure can occur if the expected or witness > 1238 * value is a NaN value and it is transformed (perhaps in a platform > 1239 * specific manner) into another NaN value, and thus has a different > 1240 * bitwise representation (see {@link Float#intBitsToFloat} or > 1241 * Double#longBitsToDouble for more details). > > (I also updated the documentation on array/ByteBuffer view methods but did not bother with the api note) > > Paul. > >> On 10 Jun 2016, at 15:39, Paul Sandoz wrote: >> >> Hi Joe, >> >> It?s my turn to catch up on email? >> >> >>> On 6 Jun 2016, at 17:47, Joseph D. Darcy wrote: >>> >>> Hello, >>> >>> Catching up on email, there are several different notions on floating-point equality one might want to use. [1] >>> >>> One notion is the built-in "==" operator on float and double. This has the wrinkle of not defining an equivalence relation because of NaN values (not reflexive) and signed zeros (distinguishable values compare as equal). >>> >>> When I write floating-point tests, I'll use a notion of equality close to >>> >>> Float.compare(x, y) == 0 >>> >>> which means all NaN values are treated as the same and Float.compare(NaN, NaN) == 0 is true. This also distinguishes the signed zeros from each other. >>> >>> So comparing based on the non-raw bitwise conversion can give resonable semantics, at the cost of not preserving any payload stored in the NaN significand. >>> >> And potentially a performance hit too [*]. >> >> Pedantically since (NaN == NaN) is false, one could argue that it should not possible to CAS with an expected NaN value and/or a witness NaN value. Such behaviour might be considered BaNaNas :-) (sorry). I don?t think we can or should enforce that, but we should strongly advise against it and mention the pitfalls, and i will need to specify that the atomic ops perform bit-wise equality with suitable ?as if? text. >> >> Paul. >> >> [*] For example, the double[] accepting Arrays.equals method used to compare each element as: >> >> 2762 for (int i=0; i> 2763 if (Double.doubleToLongBits(a[i])!=Double.doubleToLongBits(a2[i])) >> 2764 return false; >> >> In the interim of my adding vectorized mismatch support i changed that to: >> >> 3057 for (int i=0; i> 3058 double v1 = a[i], v2 = a2[i]; >> 3059 if (Double.doubleToRawLongBits(v1) != Double.doubleToRawLongBits(v2)) >> 3060 if (!Double.isNaN(v1) || !Double.isNaN(v2)) >> 3061 return false; >> 3062 } >> >> Which boosted the performance similar to that of comparing long[] (when no NaNs are present). >> >> >>> HTH, >>> >>> -Joe >>> >>> [1] "Notions of Floating-Point Equality ," https://blogs.oracle.com/darcy/entry/notions_of_floating_point_equality >>> >>> On 6/2/2016 1:34 AM, Paul Sandoz wrote: >>>>> On 2 Jun 2016, at 09:13, David Holmes wrote: >>>>> >>>>> On 2/06/2016 1:24 AM, Paul Sandoz wrote: >>>>>> (Please note this work is or will be covered with FC exception) >>>>>> >>>>>> Hi, >>>>>> >>>>>> Please review the VarHandles/Unsafe support for atomic ops on double/float fields/arrays. >>>>> I think this is misguided. If the user wants CAS for float/double they can do the conversion to int/long in a context where they know that conversion makes sense and where they can deal with NaNs appropriately. >>>>> >>>> I would still like to support some clearly defined default behaviour if at all possible, since this is not easy to get right so we can add some value here. The user can use int/long if that behaviour is not suitable. >>>> >>>> >>>>> At a minimum the fact this deals with raw bit patterns not semantic values needs to be exposed somehow. ie the handling of NaN needs to be explicit. >>>>> >>>> Yes, it?s multiple NaN values that collapse to a single NaN value. >>>> >>>> It would be good if our resident floating point expert Mr. Joe Darcy could chime in this respect. >>>> >>>> On Float.intBitsToFloat: >>>> >>>> *

Note that this method may not be able to return a >>>> * {@code float} NaN with exactly same bit pattern as the >>>> * {@code int} argument. IEEE 754 distinguishes between two >>>> * kinds of NaNs, quiet NaNs and signaling NaNs. The >>>> * differences between the two kinds of NaN are generally not >>>> * visible in Java. Arithmetic operations on signaling NaNs turn >>>> * them into quiet NaNs with a different, but often similar, bit >>>> * pattern. However, on some processors merely copying a >>>> * signaling NaN also performs that conversion. In particular, >>>> * copying a signaling NaN to return it to the calling method may >>>> * perform this conversion. So {@code intBitsToFloat} may >>>> * not be able to return a {@code float} with a signaling NaN >>>> * bit pattern. Consequently, for some {@code int} values, >>>> * {@code floatToRawIntBits(intBitsToFloat(start))} may >>>> * not equal {@code start}. Moreover, which >>>> * particular bit patterns represent signaling NaNs is platform >>>> * dependent; although all NaN bit patterns, quiet or signaling, >>>> * must be in the NaN range identified above. >>>> >>>> >>>> >>>> I am concerned that the CAS loops could in some cases loop without termination: >>>> >>>> @ForceInline >>>> public final float getAndAddFloat(Object o, long offset, float delta) { >>>> float v; >>>> do { >>>> v = getFloatVolatile(o, offset); >>>> } while (!weakCompareAndSwapFloatVolatile(o, offset, v, v + delta)); >>>> return v; >>>> } >>>> >>>> >>>> I think this should be: >>>> >>>> @ForceInline >>>> public final float getAndAddFloat(Object o, long offset, float delta) { >>>> int expectedBits; >>>> float v; >>>> do { >>>> expectedBits = getIntVolatile(o, offset); >>>> v = Float.intBitsToFloat(bits); // May not preserve a NaN value with the same bit pattern as expectedBits >>>> } while (!weakCompareAndSwapIntVolatile(o, offset, expectedBits, Float.floatToRawIntBits(v + delta))); >>>> return v; >>>> } >>>> >>>> and likewise for the atomic get-and-set methods. >>>> >>>> Paul. >>>> >>>>> David >>>>> ----- >>>>> >>>>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ >>>>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ >>>>>> >>>>>> These patches are based on those of for sub-word CAS >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8157726 >>>>>> http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/ >>>>>> http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/ >>>>>> >>>>>> And the two patches combined expand the support of fields/arrays. >>>>>> >>>>>> >>>>>> New float/double CAS methods are added to Unsafe that defer to int/long equivalents. Then the other atomic methods are built from weak CAS loops. >>>>>> >>>>>> No changes are required to HotSpot, but changes are required to the Unsafe tests in the hotspot repository. >>>>>> >>>>>> In general the changes to VHs and tests are minimal since it is triggered from changes to the generating scripts that now include float/double into the CAS category. >>>>>> >>>>>> There are some minor specification changes and a CCC has been initiated. >>>>>> >>>>>> JPRT tests results show no relevant failures for hotspot and core test sets. >>>>>> >>>>>> Thanks, >>>>>> Paul. >>>>>> From aph at redhat.com Tue Jun 14 09:05:25 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 14 Jun 2016 10:05:25 +0100 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: <8d668cf7-1f40-8310-117e-267cefe2ab5c@oracle.com> References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> <57561996.4000501@oracle.com> <951844EF-D517-4BF5-861A-81769EA1C306@oracle.com> <8d668cf7-1f40-8310-117e-267cefe2ab5c@oracle.com> Message-ID: <575FC8D5.8050900@redhat.com> On 14/06/16 05:09, joe darcy wrote: > I suggest also pointing out that a bitwise comparison distinguishes -0.0 > from +0.0; they compare as == under the built-in operation. Indeed so, yes. This is particularly likely to bite people who have a zero created by, say, an algorithm which converges on zero with successive terms which alternate sign. Eww. Andrew. From erik.helin at oracle.com Tue Jun 14 09:27:54 2016 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 14 Jun 2016 11:27:54 +0200 Subject: RFR: 8159340: Add extension to CompileGtest.gmk Message-ID: <20160614092754.GP26799@ehelin.jrpg.bea.com> Hi all, this small patch adds an extension to CompileGtest.gmk. Bug: https://bugs.openjdk.java.net/browse/JDK-8159340 Webrev: http://cr.openjdk.java.net/~ehelin/8159340/00/ Testing: - JPRT Thanks, Erik From david.holmes at oracle.com Tue Jun 14 09:48:30 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Jun 2016 19:48:30 +1000 Subject: RFR: 8159340: Add extension to CompileGtest.gmk In-Reply-To: <20160614092754.GP26799@ehelin.jrpg.bea.com> References: <20160614092754.GP26799@ehelin.jrpg.bea.com> Message-ID: Looks good to me. Thanks, David On 14/06/2016 7:27 PM, Erik Helin wrote: > Hi all, > > this small patch adds an extension to CompileGtest.gmk. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8159340 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8159340/00/ > > Testing: > - JPRT > > Thanks, > Erik > From erik.helin at oracle.com Tue Jun 14 09:50:40 2016 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 14 Jun 2016 11:50:40 +0200 Subject: RFR: 8159364: Gtest unit tests does not support PCH Message-ID: <20160614095040.GS26799@ehelin.jrpg.bea.com> Hi all, this patch adds support for pre-compiled headers (PCH) to the gtest unit tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8159364 Webrev: http://cr.openjdk.java.net/~ehelin/8159364/00/ Testing: - JPRT Thanks, Erik From erik.helin at oracle.com Tue Jun 14 09:59:37 2016 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 14 Jun 2016 11:59:37 +0200 Subject: RFR: 8159365: assert is not defined for unit tests Message-ID: <20160614095937.GT26799@ehelin.jrpg.bea.com> Hi all, we have a small problem with the `assert` macro and the gtest unit tests. The issue is that unittest.hpp will include gtest/gtest.h and gtest/gtest.h includes assert.h which will define the assert macro. The problem is that hotspot has its own standards incompatible assert macro that takes two parameters. So if a test includes unittest.hpp, then the standard assert macro will be defined, not the hotspot one. The workaround is to undef assert and then re-define hotspot's assert macro. The re-definition must unfortunately be copied since debug.hpp might already have been included and a second include wouldn't work due to the header guards in debug.hpp. Bug: https://bugs.openjdk.java.net/browse/JDK-8159365 Webrev: http://cr.openjdk.java.net/~ehelin/8159365/00/ Testing: - JPRT Thanks, Erik From erik.helin at oracle.com Tue Jun 14 10:03:03 2016 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 14 Jun 2016 12:03:03 +0200 Subject: RFR: 8159366: Header guards missing for unittest.hpp Message-ID: <20160614100303.GU26799@ehelin.jrpg.bea.com> Hi all, this tiny patch adds header guards for test/native/unittest.hpp. Bug: https://bugs.openjdk.java.net/browse/JDK-8159366 Webrev: http://cr.openjdk.java.net/~ehelin/8159366/00/ Testing: - JPRT Thanks, Erik From jesper.wilhelmsson at oracle.com Tue Jun 14 10:46:25 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 14 Jun 2016 12:46:25 +0200 Subject: RFR: 8159340: Add extension to CompileGtest.gmk In-Reply-To: <20160614092754.GP26799@ehelin.jrpg.bea.com> References: <20160614092754.GP26799@ehelin.jrpg.bea.com> Message-ID: <645b02c3-1ae4-97b5-c93b-487dba3db2b1@oracle.com> Looks good! /Jesper Den 14/6/16 kl. 11:27, skrev Erik Helin: > Hi all, > > this small patch adds an extension to CompileGtest.gmk. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8159340 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8159340/00/ > > Testing: > - JPRT > > Thanks, > Erik > From jesper.wilhelmsson at oracle.com Tue Jun 14 10:46:35 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 14 Jun 2016 12:46:35 +0200 Subject: RFR: 8159364: Gtest unit tests does not support PCH In-Reply-To: <20160614095040.GS26799@ehelin.jrpg.bea.com> References: <20160614095040.GS26799@ehelin.jrpg.bea.com> Message-ID: <035d3d65-df9f-091c-b328-99849d377ce4@oracle.com> Looks good! /Jesper Den 14/6/16 kl. 11:50, skrev Erik Helin: > Hi all, > > this patch adds support for pre-compiled headers (PCH) to the gtest unit > tests. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8159364 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8159364/00/ > > Testing: > - JPRT > > Thanks, > Erik > From jesper.wilhelmsson at oracle.com Tue Jun 14 10:46:45 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 14 Jun 2016 12:46:45 +0200 Subject: RFR: 8159365: assert is not defined for unit tests In-Reply-To: <20160614095937.GT26799@ehelin.jrpg.bea.com> References: <20160614095937.GT26799@ehelin.jrpg.bea.com> Message-ID: <95e677d8-249a-c8b6-5210-b3247c948460@oracle.com> Looks good! /Jesper Den 14/6/16 kl. 11:59, skrev Erik Helin: > Hi all, > > we have a small problem with the `assert` macro and the gtest unit > tests. The issue is that unittest.hpp will include gtest/gtest.h and > gtest/gtest.h includes assert.h which will define the assert macro. > The problem is that hotspot has its own standards incompatible assert > macro that takes two parameters. So if a test includes unittest.hpp, > then the standard assert macro will be defined, not the hotspot one. > > The workaround is to undef assert and then re-define hotspot's assert > macro. The re-definition must unfortunately be copied since debug.hpp > might already have been included and a second include wouldn't work due > to the header guards in debug.hpp. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8159365 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8159365/00/ > > Testing: > - JPRT > > Thanks, > Erik > From jesper.wilhelmsson at oracle.com Tue Jun 14 10:46:54 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 14 Jun 2016 12:46:54 +0200 Subject: RFR: 8159366: Header guards missing for unittest.hpp In-Reply-To: <20160614100303.GU26799@ehelin.jrpg.bea.com> References: <20160614100303.GU26799@ehelin.jrpg.bea.com> Message-ID: <65b9b18a-5050-6b8b-6ac2-9de7d3bfe758@oracle.com> Looks good! /Jesper Den 14/6/16 kl. 12:03, skrev Erik Helin: > Hi all, > > this tiny patch adds header guards for test/native/unittest.hpp. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8159366 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8159366/00/ > > Testing: > - JPRT > > Thanks, > Erik > From erik.helin at oracle.com Tue Jun 14 10:58:57 2016 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 14 Jun 2016 12:58:57 +0200 Subject: RFR: 8159370: Add FlagGuard for easier modification of flags for unit tests Message-ID: <20160614105857.GV26799@ehelin.jrpg.bea.com> Hi all, this patch adds a small utility class that makes it easier for TEST_VM unit tests to safely modify flags. The class FlagGuard will store the value of the flag in its constructor and then restore the flag in its destructor. This is similar IntFlagSetting, UIntFlagSetting etc, but the FlagGuard differs in two aspects: - it does not set a new value - it is "untyped", you can use FlagGuard for flags with any type I have also added a macro, GUARD_FLAG, to make it more convenient to guard a flag. A test might now look like: TEST_VM(G1Policy, test_calc_max_old_cset_length) { GUARD_FLAG(MaxGCPauseMillis); GUARD_FLAG(ParallelGCThreads); MaxGCPauseMillis = 500; ParallelGCThreads = 10; ASSERT_EQ(10u, G1Policy::calc_max_old_cset_length()); MaxGCPauseMillis = 50; ParallelGCThreads = 1; ASSERT_EQ(2u, G1Policy::calc_max_old_cset_length()); // All guarded flags are restored here } Bug: https://bugs.openjdk.java.net/browse/JDK-8159370 Webrev: http://cr.openjdk.java.net/~ehelin/8159370/00/ Testing: - JPRT Thanks, Erik From george.triantafillou at oracle.com Tue Jun 14 11:59:15 2016 From: george.triantafillou at oracle.com (George Triantafillou) Date: Tue, 14 Jun 2016 07:59:15 -0400 Subject: RFR: 8159340: Add extension to CompileGtest.gmk In-Reply-To: References: <20160614092754.GP26799@ehelin.jrpg.bea.com> Message-ID: +1 -George On 6/14/2016 5:48 AM, David Holmes wrote: > Looks good to me. > > Thanks, > David > > On 14/06/2016 7:27 PM, Erik Helin wrote: >> Hi all, >> >> this small patch adds an extension to CompileGtest.gmk. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8159340 >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8159340/00/ >> >> Testing: >> - JPRT >> >> Thanks, >> Erik >> From george.triantafillou at oracle.com Tue Jun 14 12:04:37 2016 From: george.triantafillou at oracle.com (George Triantafillou) Date: Tue, 14 Jun 2016 08:04:37 -0400 Subject: RFR: 8159364: Gtest unit tests does not support PCH In-Reply-To: <20160614095040.GS26799@ehelin.jrpg.bea.com> References: <20160614095040.GS26799@ehelin.jrpg.bea.com> Message-ID: Erik, Looks good. -George On 6/14/2016 5:50 AM, Erik Helin wrote: > Hi all, > > this patch adds support for pre-compiled headers (PCH) to the gtest unit > tests. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8159364 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8159364/00/ > > Testing: > - JPRT > > Thanks, > Erik From vladimir.x.ivanov at oracle.com Tue Jun 14 12:17:10 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 14 Jun 2016 15:17:10 +0300 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> Message-ID: <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> >> Also, have you run the JCK tests? >> >> Why have a global flag if it's an error? > > We are enforcing a rule that has not been enforced before. To deal with > compatibility issues we have provided, as is customary for non-security > issues, a flag that allows the enforcement to be turned off, if it > causes a problem. (Though that is more likely needed for JDK 7/8 > compatibility than for 9). FTR I'd like to see the checks turned ON by default for 7/8 in 9 and the flag providing an escape hatch for compatibility purposes. It is motivated by the desire to limit possibilities of final field updates at runtime, so JIT-compilers have more freedom optimizing loads from final fields. It will be unfortunate if we effectively forbid final field updates outside of initializers starting only from 9 (class files >=53) and not 7 (cf >=51). The change requires a CCC request and will be investigated separately (JDK-8159215 [1]). If there are serious compatibility issues found during EA testing, we can turn the checks OFF by default. The flag is declared as diagnostic, so I don't think we need to go through deprecation process (as we do for product flags) and just remove it in the next(?) major release. Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8159215 From david.holmes at oracle.com Tue Jun 14 13:08:14 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Jun 2016 23:08:14 +1000 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> Message-ID: On 14/06/2016 10:17 PM, Vladimir Ivanov wrote: >>> Also, have you run the JCK tests? >>> >>> Why have a global flag if it's an error? >> >> We are enforcing a rule that has not been enforced before. To deal with >> compatibility issues we have provided, as is customary for non-security >> issues, a flag that allows the enforcement to be turned off, if it >> causes a problem. (Though that is more likely needed for JDK 7/8 >> compatibility than for 9). > > FTR I'd like to see the checks turned ON by default for 7/8 in 9 and the > flag providing an escape hatch for compatibility purposes. > > It is motivated by the desire to limit possibilities of final field > updates at runtime, so JIT-compilers have more freedom optimizing loads > from final fields. It will be unfortunate if we effectively forbid final > field updates outside of initializers starting only from 9 (class files >>=53) and not 7 (cf >=51). > > The change requires a CCC request and will be investigated separately > (JDK-8159215 [1]). Ok. JDK 7/8 code exists now and by changing the rules you may break code that was working. We can't expect that code to be fixed, but that is why we have to provide the flag to disable the check. The question is whether this will impact a large or small number of users, and whether it will impact things that can readily have the flag applied. > If there are serious compatibility issues found during EA testing, we > can turn the checks OFF by default. I doubt we will test very much that would expose this. As I understand it this only affects non-Java languages running on the JVM. (Though I supposed hand-assembled Java code could also have this.) > The flag is declared as diagnostic, so I don't think we need to go > through deprecation process (as we do for product flags) and just remove > it in the next(?) major release. I had not looked at the code and did not know the flag was marked diagnostic - that doesn't seem right to me. This isn't about diagnostics. The issue with removing the flag is when you can reasonably expect any existing "bad" code will be updated. I can't judge the scope/extent of the problem - it may be trivially small, or may not. Thanks, David > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8159215 From jesper.wilhelmsson at oracle.com Tue Jun 14 13:39:35 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 14 Jun 2016 15:39:35 +0200 Subject: RFR: 8159370: Add FlagGuard for easier modification of flags for unit tests In-Reply-To: <20160614105857.GV26799@ehelin.jrpg.bea.com> References: <20160614105857.GV26799@ehelin.jrpg.bea.com> Message-ID: Looks good! /Jesper Den 14/6/16 kl. 12:58, skrev Erik Helin: > Hi all, > > this patch adds a small utility class that makes it easier for TEST_VM > unit tests to safely modify flags. The class FlagGuard will store the > value of the flag in its constructor and then restore the flag in its > destructor. This is similar IntFlagSetting, UIntFlagSetting etc, but the > FlagGuard differs in two aspects: > - it does not set a new value > - it is "untyped", you can use FlagGuard for flags with any type > > I have also added a macro, GUARD_FLAG, to make it more convenient to > guard a flag. A test might now look like: > > TEST_VM(G1Policy, test_calc_max_old_cset_length) { > GUARD_FLAG(MaxGCPauseMillis); > GUARD_FLAG(ParallelGCThreads); > > MaxGCPauseMillis = 500; > ParallelGCThreads = 10; > ASSERT_EQ(10u, G1Policy::calc_max_old_cset_length()); > > MaxGCPauseMillis = 50; > ParallelGCThreads = 1; > ASSERT_EQ(2u, G1Policy::calc_max_old_cset_length()); > > // All guarded flags are restored here > } > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8159370 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8159370/00/ > > Testing: > - JPRT > > Thanks, > Erik > From vladimir.x.ivanov at oracle.com Tue Jun 14 14:17:00 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 14 Jun 2016 17:17:00 +0300 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: References: <573C2DAD.1030903@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> Message-ID: <711d840a-5df1-3dbd-0a2f-c0ee64834a57@oracle.com> >>>> Also, have you run the JCK tests? >>>> >>>> Why have a global flag if it's an error? >>> >>> We are enforcing a rule that has not been enforced before. To deal with >>> compatibility issues we have provided, as is customary for non-security >>> issues, a flag that allows the enforcement to be turned off, if it >>> causes a problem. (Though that is more likely needed for JDK 7/8 >>> compatibility than for 9). >> >> FTR I'd like to see the checks turned ON by default for 7/8 in 9 and the >> flag providing an escape hatch for compatibility purposes. >> >> It is motivated by the desire to limit possibilities of final field >> updates at runtime, so JIT-compilers have more freedom optimizing loads >> from final fields. It will be unfortunate if we effectively forbid final >> field updates outside of initializers starting only from 9 (class files >>> =53) and not 7 (cf >=51). >> >> The change requires a CCC request and will be investigated separately >> (JDK-8159215 [1]). > > Ok. JDK 7/8 code exists now and by changing the rules you may break code > that was working. We can't expect that code to be fixed, but that is why > we have to provide the flag to disable the check. The question is > whether this will impact a large or small number of users, and whether > it will impact things that can readily have the flag applied. Yes, impact is what should drive the decision. The plan is to have the checks (either ON or OFF by default) only in 9 (no backports to 7/8). If the checks are ON by default, users should handle any problems caused by them when migrating between major releases, which sounds reasonable (if impact is low). There will be a choice to fix the library/application or disable problematic checks (by setting the flag). >> If there are serious compatibility issues found during EA testing, we >> can turn the checks OFF by default. > > I doubt we will test very much that would expose this. As I understand > it this only affects non-Java languages running on the JVM. (Though I > supposed hand-assembled Java code could also have this.) There's Quality Outreach program [1] (conducted by Adoption Group) and many popular FOSS Java projects test OpenJDK 9 builds. So, the projects involved should notice if the change affects them. >> The flag is declared as diagnostic, so I don't think we need to go >> through deprecation process (as we do for product flags) and just remove >> it in the next(?) major release. > > I had not looked at the code and did not know the flag was marked > diagnostic - that doesn't seem right to me. This isn't about diagnostics. Good point. Maybe make it product and deprecate right from the beginning then? > The issue with removing the flag is when you can reasonably expect any > existing "bad" code will be updated. I can't judge the scope/extent of > the problem - it may be trivially small, or may not. Thinking about that more, I don't see much value in the flag if the checks are OFF for 7-8 (cf <53) by default. If we don't enable the checks in 9, I'm sure we will never change that. I don't see any value in providing opt-out option for 9 (cf >=53). The impact is limited: javac doesn't produce such code shape and bytecode generators require a change to produce cf =53. New code should adhere to JVMS in this particular case. So, if we decide that enabling the checks for 7-8 is too risky, we can remove the flag. Best regards, Vladimir Ivanov [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach From coleen.phillimore at oracle.com Tue Jun 14 14:34:17 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 14 Jun 2016 10:34:17 -0400 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <711d840a-5df1-3dbd-0a2f-c0ee64834a57@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> <711d840a-5df1-3dbd-0a2f-c0ee64834a57@oracle.com> Message-ID: <4b85c1f9-8e63-9546-6c65-8208c369cb89@oracle.com> On 6/14/16 10:17 AM, Vladimir Ivanov wrote: > >>>>> Also, have you run the JCK tests? >>>>> >>>>> Why have a global flag if it's an error? >>>> >>>> We are enforcing a rule that has not been enforced before. To deal >>>> with >>>> compatibility issues we have provided, as is customary for >>>> non-security >>>> issues, a flag that allows the enforcement to be turned off, if it >>>> causes a problem. (Though that is more likely needed for JDK 7/8 >>>> compatibility than for 9). >>> >>> FTR I'd like to see the checks turned ON by default for 7/8 in 9 and >>> the >>> flag providing an escape hatch for compatibility purposes. >>> >>> It is motivated by the desire to limit possibilities of final field >>> updates at runtime, so JIT-compilers have more freedom optimizing loads >>> from final fields. It will be unfortunate if we effectively forbid >>> final >>> field updates outside of initializers starting only from 9 (class files >>>> =53) and not 7 (cf >=51). >>> >>> The change requires a CCC request and will be investigated separately >>> (JDK-8159215 [1]). >> >> Ok. JDK 7/8 code exists now and by changing the rules you may break code >> that was working. We can't expect that code to be fixed, but that is why >> we have to provide the flag to disable the check. The question is >> whether this will impact a large or small number of users, and whether >> it will impact things that can readily have the flag applied. > > Yes, impact is what should drive the decision. > > The plan is to have the checks (either ON or OFF by default) only in 9 > (no backports to 7/8). > > If the checks are ON by default, users should handle any problems > caused by them when migrating between major releases, which sounds > reasonable (if impact is low). There will be a choice to fix the > library/application or disable problematic checks (by setting the flag). > >>> If there are serious compatibility issues found during EA testing, we >>> can turn the checks OFF by default. >> >> I doubt we will test very much that would expose this. As I understand >> it this only affects non-Java languages running on the JVM. (Though I >> supposed hand-assembled Java code could also have this.) > > There's Quality Outreach program [1] (conducted by Adoption Group) and > many popular FOSS Java projects test OpenJDK 9 builds. So, the > projects involved should notice if the change affects them. > >>> The flag is declared as diagnostic, so I don't think we need to go >>> through deprecation process (as we do for product flags) and just >>> remove >>> it in the next(?) major release. >> >> I had not looked at the code and did not know the flag was marked >> diagnostic - that doesn't seem right to me. This isn't about >> diagnostics. > > Good point. Maybe make it product and deprecate right from the > beginning then? > >> The issue with removing the flag is when you can reasonably expect any >> existing "bad" code will be updated. I can't judge the scope/extent of >> the problem - it may be trivially small, or may not. > > Thinking about that more, I don't see much value in the flag if the > checks are OFF for 7-8 (cf <53) by default. If we don't enable the > checks in 9, I'm sure we will never change that. > > I don't see any value in providing opt-out option for 9 (cf >=53). The > impact is limited: javac doesn't produce such code shape and bytecode > generators require a change to produce cf =53. New code should adhere > to JVMS in this particular case. > > So, if we decide that enabling the checks for 7-8 is too risky, we can > remove the flag. I would vote for pre-deprecating or removing the flag. We don't generally add flags for new spec enforcement unless we anticipate a lot of customers having problems with the new rule. Just make sure the error message is really good though, so that when people hit this new rule, they'll know what to fix. Coleen > > Best regards, > Vladimir Ivanov > > [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach From erik.joelsson at oracle.com Tue Jun 14 15:13:45 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 14 Jun 2016 08:13:45 -0700 Subject: RFR: 8159364: Gtest unit tests does not support PCH In-Reply-To: <20160614095040.GS26799@ehelin.jrpg.bea.com> References: <20160614095040.GS26799@ehelin.jrpg.bea.com> Message-ID: <57601F29.7060903@oracle.com> Do you really need to exclude gTestLauncher.cpp from precompiled? That file should be excluded from compilation already. Otherwise looks good. /Erik On 2016-06-14 02:50, Erik Helin wrote: > Hi all, > > this patch adds support for pre-compiled headers (PCH) to the gtest unit > tests. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8159364 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8159364/00/ > > Testing: > - JPRT > > Thanks, > Erik From coleen.phillimore at oracle.com Tue Jun 14 15:58:41 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 14 Jun 2016 11:58:41 -0400 Subject: RFR: 8159365: assert is not defined for unit tests In-Reply-To: <20160614095937.GT26799@ehelin.jrpg.bea.com> References: <20160614095937.GT26799@ehelin.jrpg.bea.com> Message-ID: Or you could just change all the hotspot non conforming asserts to vmassert. j.k. Looks good. Coleen On 6/14/16 5:59 AM, Erik Helin wrote: > Hi all, > > we have a small problem with the `assert` macro and the gtest unit > tests. The issue is that unittest.hpp will include gtest/gtest.h and > gtest/gtest.h includes assert.h which will define the assert macro. > The problem is that hotspot has its own standards incompatible assert > macro that takes two parameters. So if a test includes unittest.hpp, > then the standard assert macro will be defined, not the hotspot one. > > The workaround is to undef assert and then re-define hotspot's assert > macro. The re-definition must unfortunately be copied since debug.hpp > might already have been included and a second include wouldn't work due > to the header guards in debug.hpp. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8159365 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8159365/00/ > > Testing: > - JPRT > > Thanks, > Erik From volker.simonis at gmail.com Tue Jun 14 18:18:40 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Jun 2016 20:18:40 +0200 Subject: RFR(M): 8158232: PPC64: improve byte, int and long array copy stubs by using VSX instructions In-Reply-To: <57508330.2050307@oracle.com> References: <201605311537.u4VFYV1Q029540@mx0a-001b2d01.pphosted.com> <4ef29ef8b7904b98952224ecb77e21f8@DEWDFE13DE09.global.corp.sap> <201606020207.u5225ptS007620@mx0a-001b2d01.pphosted.com> <498493e344fd4d02beb049ff9dd9aba3@DEWDFE13DE09.global.corp.sap> <201606021507.u52F64ci025581@mx0a-001b2d01.pphosted.com> <15e6ab6155984dee9760170d731844b1@DEWDFE13DE09.global.corp.sap> <57508330.2050307@oracle.com> Message-ID: Hi Vladimir, are there any news regarding the approval process? I think this change is ppc only and shouldn't do any harm. Or maybe w should just change the issue from "Enhancement" to "(Performance) Bug" if that would simplify the procedure? Thank you and best regards, Volker On Thu, Jun 2, 2016 at 9:04 PM, Vladimir Kozlov wrote: > Please, hold on pushing this. We are after Feature complete date May 26: > > http://openjdk.java.net/projects/jdk9/ > > All RFE(enhancement) changes should be approved before push. > Please, wait when approval process is finalized. > > Regards, > Vladimir > > On 6/2/16 11:48 AM, Lindenmaier, Goetz wrote: >> >> Ok, reviewed. >> >> Thanks for explanations, >> >> Goetz. >> >> *From:*Michihiro Horie [mailto:HORIE at jp.ibm.com] >> *Sent:* Thursday, June 02, 2016 5:07 PM >> *To:* Lindenmaier, Goetz >> *Cc:* hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >> *Subject:* RE: RFR(M): 8158232: PPC64: improve byte, int and long array >> copy stubs by using VSX instructions >> >> Hi Goetz, >> >>> You are saying you could not measure an effect? >> >> We could not observe a big difference, but as you point out, jbb2013 looks >> a little difficult to get stable results. >> >>> There still might be a penalty because of the additional instructions >>> as the prefetching for small arrays, or a lost opportunity because of >>> not unrolling. >>> It would be nice to have numbers on this, but I think the effect will >>> be rather small so that I?m also fine with the current solution. >>> >>> How did you test the new solution? >> >> I agree, a penalty might depend on the applications, but the effect will >> be rather small. I also tested the latest code by using micro benchmarks and >> jbb2013. >> >> Best regards, >> -- >> Michi-hiro >> IBM Research - Tokyo >> >> Inactive hide details for "Lindenmaier, Goetz" ---2016/06/02 19:47:38---Hi >> Michihiro, thanks for the new webrev, and thanks Mar"Lindenmaier, Goetz" >> ---2016/06/02 19:47:38---Hi Michihiro, thanks for >> the new webrev, and thanks Martin for uploading it. >> >> From: "Lindenmaier, Goetz" > > >> To: Michihiro Horie/Japan/IBM at IBMJP >> Cc: "hotspot-dev at openjdk.java.net " >> >, >> "ppc-aix-port-dev at openjdk.java.net >> " >> > > >> Date: 2016/06/02 19:47 >> Subject: RE: RFR(M): 8158232: PPC64: improve byte, int and long array copy >> stubs by using VSX instructions >> >> >> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> >> >> >> >> Hi Michihiro, >> >> thanks for the new webrev, and thanks Martin for uploading it. >> >>> but there was no special reason on the changes in loop body sizes >> >> You are saying you could not measure an effect? With jbb2013 it?s hard >> to get reproducible results, jvm2008 is more simple with that. But it >> needs adaptions to run with Java 8 (or you skip the compiler benchmarks). >> Also, there is now jbb2015 which is jbb2013 with some bugs fixed. >> >> The loop body sizes are now the same with and without vsx. >> This alleviates my main concerns. >> There still might be a penalty because of the additional instructions >> as the prefetching for small arrays, or a lost opportunity because of >> not unrolling. >> It would be nice to have numbers on this, but I think the effect will >> be rather small so that I?m also fine with the current solution. >> >> How did you test the new solution? >> >> Best regards, >> Goetz. >> >> >> *From:*Michihiro Horie [mailto:HORIE at jp.ibm.com] * >> Sent:* Thursday, June 02, 2016 4:07 AM* >> To:* Lindenmaier, Goetz > >* >> Cc:* hotspot-dev at openjdk.java.net ; >> ppc-aix-port-dev at openjdk.java.net >> * >> Subject:* RE: RFR(M): 8158232: PPC64: improve byte, int and long array >> copy stubs by using VSX instructions >> >> Hi Goetz, >> >> Thank you very much for your comments, which is really helpful. >> >> I would fix my code to fit the loop body sizes in elements to the original >> ones. We did measurements by using SPECjbb2013, but there was no special >> reason on the changes in loop body sizes. They are >> code after the trial and error with a few developers. >> >>> But I'm not convinced that this helps the average performance, as >>> important >>> lengths will regress. >> >> : >>> >>> Especially with the byte arrays, which are used to store >>> compact Strings, I would doubt that this helps an average >>> application. For sizes 32-128 you first have a failing >>> compare, and then step through a '4' loop instead of a '32' >>> one. >> >> Your point makes sense to me. >> >>> Should you also set the prefetching engine more aggressive as >>> in the short copy loop? >> >> I would use prefetching engine as in the short copy loop, thank you. >> >> Best regards, >> -- >> Michihiro Horie, >> IBM Research - Tokyo >> >> Inactive hide details for "Lindenmaier, Goetz" ---2016/06/01 23:14:42---Hi >> Michihiro, Thanks for contributing to the ppc port!"Lindenmaier, Goetz" >> ---2016/06/01 23:14:42---Hi Michihiro, Thanks for >> contributing to the ppc port! >> >> From: "Lindenmaier, Goetz" > > >> To: Michihiro Horie/Japan/IBM at IBMJP, "hotspot-dev at openjdk.java.net >> " > >, >> "ppc-aix-port-dev at openjdk.java.net >> " >> > > >> Date: 2016/06/01 23:14 >> Subject: RE: RFR(M): 8158232: PPC64: improve byte, int and long array copy >> stubs by using VSX instructions >> >> >> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> >> >> >> >> >> >> Hi Michihiro, >> >> Thanks for contributing to the ppc port! >> >> I've been looking at your changes. Basically they look good. But I'm >> not convinced that this helps the average performance, as important >> lengths will regress. >> >> We once ananlyzed a benchmark, where we saw 400 million copies of >> short arrays which had an average length of 38!! elements. There >> were 200 byte array copies and 20 million long array copies. >> This should have changed as there are compact strings, now. >> I think we had suppressed the array copy stubs and modified >> PrintOptoStatistics to collect that data. >> >> As I understand we have the following loops now: >> >> Loop body sizes in elements >> before now sizes regressing >> byte 32,4,1 128,4,1 32-127 >> short 16,2,1 16,2,1 none >> int 8,1 32,1 8-31 >> long 4,1 16,4,1 none >> >> Especially with the byte arrays, which are used to store >> compact Strings, I would doubt that this helps an average >> application. For sizes 32-128 you first have a failing >> compare, and then step through a '4' loop instead of a '32' >> one. >> >> Further, why don't you use the new instructions in the smaller >> loops, too? Like in the long '4' version? >> >> I could not find a measurement showing the effect on jbb2015 >> or jvm2008. Did you measure these? >> Or you could modify your benchmarks for some small, odd >> numbers, as 23, 42, 99 ...? >> >> Should you also set the prefetching engine more aggressive as >> in the short copy loop? >> >> Best regards, >> Goetz. >> >>> -----Original Message----- >>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>> Behalf Of Michihiro Horie >>> Sent: Dienstag, 31. Mai 2016 17:37 >>> To:hotspot-dev at openjdk.java.net ; >>> ppc-aix-port-dev at openjdk.java.net >>> Subject: RFR(M): 8158232: PPC64: improve byte, int and long array copy >>> stubs >>> by using VSX instructions >>> >>> >>> Dear all, >>> >>> Could you please review the following webrev? >>> >>> http://cr.openjdk.java.net/~mdoerr/8158232_PPC_vsx_copy/webrev.00/ >>> >>> This change improves performance of disjoint arraycopy of byte, int, and >>> long by using VSX load/store instructions. >>> >>> Discussion started from: >>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016- >>> _ >> >> _> May/002483.html >> >>> >>> >>> Performance improvement with micro benchmarks is shown in: >>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016- >>> _ >> >> _> May/002531.html >> >>> >>> >>> Thank you very much, >>> >>> Best regards, >>> -- >>> Michihiro Horie, >>> IBM Research - Tokyo >> >> > From vladimir.kozlov at oracle.com Tue Jun 14 18:34:05 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Jun 2016 11:34:05 -0700 Subject: RFR(M): 8158232: PPC64: improve byte, int and long array copy stubs by using VSX instructions In-Reply-To: References: <201605311537.u4VFYV1Q029540@mx0a-001b2d01.pphosted.com> <4ef29ef8b7904b98952224ecb77e21f8@DEWDFE13DE09.global.corp.sap> <201606020207.u5225ptS007620@mx0a-001b2d01.pphosted.com> <498493e344fd4d02beb049ff9dd9aba3@DEWDFE13DE09.global.corp.sap> <201606021507.u52F64ci025581@mx0a-001b2d01.pphosted.com> <15e6ab6155984dee9760170d731844b1@DEWDFE13DE09.global.corp.sap> <57508330.2050307@oracle.com> Message-ID: <7a9115b9-5ec4-58ed-51ba-de940938fe85@oracle.com> Yes, there was mail sent by Mark about the process: http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004443.html " - If you own a JEP or a small enhancement that is not yet complete then you can request an FC extension as follows: Update the JBS issue to add a comment whose first line is "FC Extension Request". In that comment describe the remaining work to be done, the risk level, a brief justification, and your best estimate of the date by which the feature will be complete. Add the label "jdk9-fc-request" to the issue. " Regards, Vladimir On 6/14/16 11:18 AM, Volker Simonis wrote: > Hi Vladimir, > > are there any news regarding the approval process? > I think this change is ppc only and shouldn't do any harm. > Or maybe w should just change the issue from "Enhancement" to > "(Performance) Bug" if that would simplify the procedure? > > Thank you and best regards, > Volker > > > On Thu, Jun 2, 2016 at 9:04 PM, Vladimir Kozlov > wrote: >> Please, hold on pushing this. We are after Feature complete date May 26: >> >> http://openjdk.java.net/projects/jdk9/ >> >> All RFE(enhancement) changes should be approved before push. >> Please, wait when approval process is finalized. >> >> Regards, >> Vladimir >> >> On 6/2/16 11:48 AM, Lindenmaier, Goetz wrote: >>> >>> Ok, reviewed. >>> >>> Thanks for explanations, >>> >>> Goetz. >>> >>> *From:*Michihiro Horie [mailto:HORIE at jp.ibm.com] >>> *Sent:* Thursday, June 02, 2016 5:07 PM >>> *To:* Lindenmaier, Goetz >>> *Cc:* hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>> *Subject:* RE: RFR(M): 8158232: PPC64: improve byte, int and long array >>> copy stubs by using VSX instructions >>> >>> Hi Goetz, >>> >>>> You are saying you could not measure an effect? >>> >>> We could not observe a big difference, but as you point out, jbb2013 looks >>> a little difficult to get stable results. >>> >>>> There still might be a penalty because of the additional instructions >>>> as the prefetching for small arrays, or a lost opportunity because of >>>> not unrolling. >>>> It would be nice to have numbers on this, but I think the effect will >>>> be rather small so that I?m also fine with the current solution. >>>> >>>> How did you test the new solution? >>> >>> I agree, a penalty might depend on the applications, but the effect will >>> be rather small. I also tested the latest code by using micro benchmarks and >>> jbb2013. >>> >>> Best regards, >>> -- >>> Michi-hiro >>> IBM Research - Tokyo >>> >>> Inactive hide details for "Lindenmaier, Goetz" ---2016/06/02 19:47:38---Hi >>> Michihiro, thanks for the new webrev, and thanks Mar"Lindenmaier, Goetz" >>> ---2016/06/02 19:47:38---Hi Michihiro, thanks for >>> the new webrev, and thanks Martin for uploading it. >>> >>> From: "Lindenmaier, Goetz" >> > >>> To: Michihiro Horie/Japan/IBM at IBMJP >>> Cc: "hotspot-dev at openjdk.java.net " >>> >, >>> "ppc-aix-port-dev at openjdk.java.net >>> " >>> >> > >>> Date: 2016/06/02 19:47 >>> Subject: RE: RFR(M): 8158232: PPC64: improve byte, int and long array copy >>> stubs by using VSX instructions >>> >>> >>> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >>> >>> >>> >>> >>> Hi Michihiro, >>> >>> thanks for the new webrev, and thanks Martin for uploading it. >>> >>>> but there was no special reason on the changes in loop body sizes >>> >>> You are saying you could not measure an effect? With jbb2013 it?s hard >>> to get reproducible results, jvm2008 is more simple with that. But it >>> needs adaptions to run with Java 8 (or you skip the compiler benchmarks). >>> Also, there is now jbb2015 which is jbb2013 with some bugs fixed. >>> >>> The loop body sizes are now the same with and without vsx. >>> This alleviates my main concerns. >>> There still might be a penalty because of the additional instructions >>> as the prefetching for small arrays, or a lost opportunity because of >>> not unrolling. >>> It would be nice to have numbers on this, but I think the effect will >>> be rather small so that I?m also fine with the current solution. >>> >>> How did you test the new solution? >>> >>> Best regards, >>> Goetz. >>> >>> >>> *From:*Michihiro Horie [mailto:HORIE at jp.ibm.com] * >>> Sent:* Thursday, June 02, 2016 4:07 AM* >>> To:* Lindenmaier, Goetz >> >* >>> Cc:* hotspot-dev at openjdk.java.net ; >>> ppc-aix-port-dev at openjdk.java.net >>> * >>> Subject:* RE: RFR(M): 8158232: PPC64: improve byte, int and long array >>> copy stubs by using VSX instructions >>> >>> Hi Goetz, >>> >>> Thank you very much for your comments, which is really helpful. >>> >>> I would fix my code to fit the loop body sizes in elements to the original >>> ones. We did measurements by using SPECjbb2013, but there was no special >>> reason on the changes in loop body sizes. They are >>> code after the trial and error with a few developers. >>> >>>> But I'm not convinced that this helps the average performance, as >>>> important >>>> lengths will regress. >>> >>> : >>>> >>>> Especially with the byte arrays, which are used to store >>>> compact Strings, I would doubt that this helps an average >>>> application. For sizes 32-128 you first have a failing >>>> compare, and then step through a '4' loop instead of a '32' >>>> one. >>> >>> Your point makes sense to me. >>> >>>> Should you also set the prefetching engine more aggressive as >>>> in the short copy loop? >>> >>> I would use prefetching engine as in the short copy loop, thank you. >>> >>> Best regards, >>> -- >>> Michihiro Horie, >>> IBM Research - Tokyo >>> >>> Inactive hide details for "Lindenmaier, Goetz" ---2016/06/01 23:14:42---Hi >>> Michihiro, Thanks for contributing to the ppc port!"Lindenmaier, Goetz" >>> ---2016/06/01 23:14:42---Hi Michihiro, Thanks for >>> contributing to the ppc port! >>> >>> From: "Lindenmaier, Goetz" >> > >>> To: Michihiro Horie/Japan/IBM at IBMJP, "hotspot-dev at openjdk.java.net >>> " >> >, >>> "ppc-aix-port-dev at openjdk.java.net >>> " >>> >> > >>> Date: 2016/06/01 23:14 >>> Subject: RE: RFR(M): 8158232: PPC64: improve byte, int and long array copy >>> stubs by using VSX instructions >>> >>> >>> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >>> >>> >>> >>> >>> >>> >>> Hi Michihiro, >>> >>> Thanks for contributing to the ppc port! >>> >>> I've been looking at your changes. Basically they look good. But I'm >>> not convinced that this helps the average performance, as important >>> lengths will regress. >>> >>> We once ananlyzed a benchmark, where we saw 400 million copies of >>> short arrays which had an average length of 38!! elements. There >>> were 200 byte array copies and 20 million long array copies. >>> This should have changed as there are compact strings, now. >>> I think we had suppressed the array copy stubs and modified >>> PrintOptoStatistics to collect that data. >>> >>> As I understand we have the following loops now: >>> >>> Loop body sizes in elements >>> before now sizes regressing >>> byte 32,4,1 128,4,1 32-127 >>> short 16,2,1 16,2,1 none >>> int 8,1 32,1 8-31 >>> long 4,1 16,4,1 none >>> >>> Especially with the byte arrays, which are used to store >>> compact Strings, I would doubt that this helps an average >>> application. For sizes 32-128 you first have a failing >>> compare, and then step through a '4' loop instead of a '32' >>> one. >>> >>> Further, why don't you use the new instructions in the smaller >>> loops, too? Like in the long '4' version? >>> >>> I could not find a measurement showing the effect on jbb2015 >>> or jvm2008. Did you measure these? >>> Or you could modify your benchmarks for some small, odd >>> numbers, as 23, 42, 99 ...? >>> >>> Should you also set the prefetching engine more aggressive as >>> in the short copy loop? >>> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>> Behalf Of Michihiro Horie >>>> Sent: Dienstag, 31. Mai 2016 17:37 >>>> To:hotspot-dev at openjdk.java.net ; >>>> ppc-aix-port-dev at openjdk.java.net >>>> Subject: RFR(M): 8158232: PPC64: improve byte, int and long array copy >>>> stubs >>>> by using VSX instructions >>>> >>>> >>>> Dear all, >>>> >>>> Could you please review the following webrev? >>>> >>>> http://cr.openjdk.java.net/~mdoerr/8158232_PPC_vsx_copy/webrev.00/ >>>> >>>> This change improves performance of disjoint arraycopy of byte, int, and >>>> long by using VSX load/store instructions. >>>> >>>> Discussion started from: >>>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016- >>>> _ >>> >>> _> May/002483.html >>> >>>> >>>> >>>> Performance improvement with micro benchmarks is shown in: >>>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016- >>>> _ >>> >>> _> May/002531.html >>> >>>> >>>> >>>> Thank you very much, >>>> >>>> Best regards, >>>> -- >>>> Michihiro Horie, >>>> IBM Research - Tokyo >>> >>> >> From david.holmes at oracle.com Tue Jun 14 21:02:15 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Jun 2016 07:02:15 +1000 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <4b85c1f9-8e63-9546-6c65-8208c369cb89@oracle.com> References: <573C2DAD.1030903@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> <711d840a-5df1-3dbd-0a2f-c0ee64834a57@oracle.com> <4b85c1f9-8e63-9546-6c65-8208c369cb89@oracle.com> Message-ID: On 15/06/2016 12:34 AM, Coleen Phillimore wrote: > > > On 6/14/16 10:17 AM, Vladimir Ivanov wrote: >> >>>>>> Also, have you run the JCK tests? >>>>>> >>>>>> Why have a global flag if it's an error? >>>>> >>>>> We are enforcing a rule that has not been enforced before. To deal >>>>> with >>>>> compatibility issues we have provided, as is customary for >>>>> non-security >>>>> issues, a flag that allows the enforcement to be turned off, if it >>>>> causes a problem. (Though that is more likely needed for JDK 7/8 >>>>> compatibility than for 9). >>>> >>>> FTR I'd like to see the checks turned ON by default for 7/8 in 9 and >>>> the >>>> flag providing an escape hatch for compatibility purposes. >>>> >>>> It is motivated by the desire to limit possibilities of final field >>>> updates at runtime, so JIT-compilers have more freedom optimizing loads >>>> from final fields. It will be unfortunate if we effectively forbid >>>> final >>>> field updates outside of initializers starting only from 9 (class files >>>>> =53) and not 7 (cf >=51). >>>> >>>> The change requires a CCC request and will be investigated separately >>>> (JDK-8159215 [1]). >>> >>> Ok. JDK 7/8 code exists now and by changing the rules you may break code >>> that was working. We can't expect that code to be fixed, but that is why >>> we have to provide the flag to disable the check. The question is >>> whether this will impact a large or small number of users, and whether >>> it will impact things that can readily have the flag applied. >> >> Yes, impact is what should drive the decision. >> >> The plan is to have the checks (either ON or OFF by default) only in 9 >> (no backports to 7/8). >> >> If the checks are ON by default, users should handle any problems >> caused by them when migrating between major releases, which sounds >> reasonable (if impact is low). There will be a choice to fix the >> library/application or disable problematic checks (by setting the flag). >> >>>> If there are serious compatibility issues found during EA testing, we >>>> can turn the checks OFF by default. >>> >>> I doubt we will test very much that would expose this. As I understand >>> it this only affects non-Java languages running on the JVM. (Though I >>> supposed hand-assembled Java code could also have this.) >> >> There's Quality Outreach program [1] (conducted by Adoption Group) and >> many popular FOSS Java projects test OpenJDK 9 builds. So, the >> projects involved should notice if the change affects them. >> >>>> The flag is declared as diagnostic, so I don't think we need to go >>>> through deprecation process (as we do for product flags) and just >>>> remove >>>> it in the next(?) major release. >>> >>> I had not looked at the code and did not know the flag was marked >>> diagnostic - that doesn't seem right to me. This isn't about >>> diagnostics. >> >> Good point. Maybe make it product and deprecate right from the >> beginning then? >> >>> The issue with removing the flag is when you can reasonably expect any >>> existing "bad" code will be updated. I can't judge the scope/extent of >>> the problem - it may be trivially small, or may not. >> >> Thinking about that more, I don't see much value in the flag if the >> checks are OFF for 7-8 (cf <53) by default. If we don't enable the >> checks in 9, I'm sure we will never change that. >> >> I don't see any value in providing opt-out option for 9 (cf >=53). The >> impact is limited: javac doesn't produce such code shape and bytecode >> generators require a change to produce cf =53. New code should adhere >> to JVMS in this particular case. >> >> So, if we decide that enabling the checks for 7-8 is too risky, we can >> remove the flag. > > I would vote for pre-deprecating or removing the flag. We don't > generally add flags for new spec enforcement unless we anticipate a lot > of customers having problems with the new rule. Just make sure the > error message is really good though, so that when people hit this new > rule, they'll know what to fix. Okay. If this is restricted to 9 then we can drop the flag and require any "offenders" to become compliant if they plan to ship Java 9 version bytecode. David ----- > > Coleen >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach > From kim.barrett at oracle.com Tue Jun 14 22:14:40 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 14 Jun 2016 18:14:40 -0400 Subject: [PATCH resend2] 8157758: Use (~0u) instead of (-1) when left-shifting In-Reply-To: References: Message-ID: <740DB36B-CB51-46E9-A456-A546FD3F3836@oracle.com> > On Jun 13, 2016, at 11:51 AM, Alex Henrie wrote: > > # HG changeset patch > # User ahenrie > # Date 1464130244 21600 > # Tue May 24 16:50:44 2016 -0600 > # Node ID e3e2afa872c68a8fc7891fc25a9a11dab0704787 > # Parent 3f4173a750ac10fa4c22ed3d0e3d8d43bab3020b > 8157758: Use (~0u) instead of (-1) when left-shifting > > diff --git a/src/share/vm/code/dependencies.hpp b/src/share/vm/code/dependencies.hpp > --- a/src/share/vm/code/dependencies.hpp > +++ b/src/share/vm/code/dependencies.hpp > @@ -163,17 +163,17 @@ class Dependencies: public ResourceObj { > call_site_target_value, > > TYPE_LIMIT > }; > enum { > LG2_TYPE_LIMIT = 4, // assert(TYPE_LIMIT <= (1< > // handy categorizations of dependency types: > - all_types = ((1 << TYPE_LIMIT) - 1) & ((-1) << FIRST_TYPE), > + all_types = ((1 << TYPE_LIMIT) - 1) & ((~0u) << FIRST_TYPE), > > non_klass_types = (1 << call_site_target_value), > klass_types = all_types & ~non_klass_types, > > non_ctxk_types = (1 << evol_method) | (1 << call_site_target_value), > implicit_ctxk_types = 0, > explicit_ctxk_types = all_types & ~(non_ctxk_types | implicit_ctxk_types), > > diff --git a/src/share/vm/oops/cpCache.hpp b/src/share/vm/oops/cpCache.hpp > --- a/src/share/vm/oops/cpCache.hpp > +++ b/src/share/vm/oops/cpCache.hpp > @@ -188,17 +188,17 @@ class ConstantPoolCacheEntry VALUE_OBJ_C > is_final_shift = 22, // (f) is the field or method final? > is_volatile_shift = 21, // (v) is the field volatile? > is_vfinal_shift = 20, // (vf) did the call resolve to a final method? > // low order bits give field index (for FieldInfo) or method parameter size: > field_index_bits = 16, > field_index_mask = right_n_bits(field_index_bits), > parameter_size_bits = 8, // subset of field_index_mask, range is 0..255 > parameter_size_mask = right_n_bits(parameter_size_bits), > - option_bits_mask = ~(((-1) << tos_state_shift) | (field_index_mask | parameter_size_mask)) > + option_bits_mask = ~(((~0u) << tos_state_shift) | (field_index_mask | parameter_size_mask)) > }; > > // specific bit definitions for the indices field: > enum { > cp_index_bits = 2*BitsPerByte, > cp_index_mask = right_n_bits(cp_index_bits), > bytecode_1_shift = cp_index_bits, > bytecode_1_mask = right_n_bits(BitsPerByte), // == (u1)0xFF At first glance, the proposed changes seem obviously correct, since they replace left shifts of negative signed values, which is undefined behavior, with left shifts of unsigned values, which are fine. However, this patch may change the underlying type of the enum, affecting the types of all the enumerators. That could have widespread ripple effects that are hard to track and examine. Better would be to extract these problematic values out of their respective enums and instead declare them as static consts of an appropriate type. That they are presently enumerators isn't actually interesting. Probably many / all of the nearby enumerators would be better treated as static const declarations with appropriate types, but that's less urgent than eliminating the obvious undefined behavior. From kim.barrett at oracle.com Tue Jun 14 22:27:35 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 14 Jun 2016 18:27:35 -0400 Subject: RFR: 8159370: Add FlagGuard for easier modification of flags for unit tests In-Reply-To: <20160614105857.GV26799@ehelin.jrpg.bea.com> References: <20160614105857.GV26799@ehelin.jrpg.bea.com> Message-ID: <2C12A9D7-3E82-461B-B0BD-13B0A83276C2@oracle.com> > On Jun 14, 2016, at 6:58 AM, Erik Helin wrote: > > Hi all, > > this patch adds a small utility class that makes it easier for TEST_VM > unit tests to safely modify flags. The class FlagGuard will store the > value of the flag in its constructor and then restore the flag in its > destructor. This is similar IntFlagSetting, UIntFlagSetting etc, but the > FlagGuard differs in two aspects: > - it does not set a new value > - it is "untyped", you can use FlagGuard for flags with any type Is there a reason why this is being added to the unit test framework, rather than being a generalization of the existing [U]IntFlagSetting &etc and placed nearby? That?s where I would expect to find it. > I have also added a macro, GUARD_FLAG, to make it more convenient to > guard a flag. A test might now look like: > > TEST_VM(G1Policy, test_calc_max_old_cset_length) { > GUARD_FLAG(MaxGCPauseMillis); > GUARD_FLAG(ParallelGCThreads); > > MaxGCPauseMillis = 500; > ParallelGCThreads = 10; > ASSERT_EQ(10u, G1Policy::calc_max_old_cset_length()); > > MaxGCPauseMillis = 50; > ParallelGCThreads = 1; > ASSERT_EQ(2u, G1Policy::calc_max_old_cset_length()); > > // All guarded flags are restored here > } > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8159370 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8159370/00/ > > Testing: > - JPRT > > Thanks, > Erik From coleen.phillimore at oracle.com Tue Jun 14 22:41:52 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 14 Jun 2016 18:41:52 -0400 Subject: RFR 8152271: MemberNameTable doesn't purge stale entries In-Reply-To: References: Message-ID: On 6/12/16 7:42 PM, David Holmes wrote: > Hi Coleen, > > On 11/06/2016 12:55 AM, Coleen Phillimore wrote: >> Summary: Intern MemberNames in table instead of allocating new entries >> >> For degenerate case, we were leaking native code in the member name >> table. Going with the suggested workaround, it was only a few more >> lines of code to intern MemberName and return the MemberName that was >> already in the table. > > I guess I'm very surprised that these were not already being "cached" > at some level (ie the Java level where all other reflection-like > objects get cached)! I'm not familiar with the mechanics or j.l.invoke > so was wondering where MemberName instances actually get created - > because I'd like to understand how you get two distinct MemberName > instances that compare equal in the first place? Hi David, The MemberNames were not being cached. There was a change to attempt to cache them in the jdk https://bugs.openjdk.java.net/browse/JDK-8013267 but it was a much bigger change and we still need access to MemberName in the jvm because we have to replace the Method* in them with redefinition. MemberNames get created mostly when you create a MethodHandle. The MemberName is the jvm representation of the member of the class. It's not simply a Method* because it contains flags based on how it's resolved at linktime. In the test case provided, MethodHandle mh = lookup.findSpecial(Leak.class, "callMe", mt, Leak.class); this looks up the same method and creates the same MemberName over and over. > > Otherwise changes seem fine - though perhaps > MemberNameTable::add_member_name should assert the member_name is not > already present, just to confirm those intern==false cases are working > as intended. I want to keep add_member_name simple and not go through the list even under ASSERT. It's okay if some member_name are already present, and for the case with JVM_Clone, we want an additional MemberName in the table (and that uses add_member_name()). Thanks for looking at the code. Coleen > > Thanks, > David > ----- > >> This has been performance tested to show no regression and works really >> well for the degenerate test case, even though the real percentage of >> reused MemberName seems quite small. >> >> Tested with all runtime nightly tests, tests in >> jdk/test/java/lang/invoke. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8152271.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8152271 >> >> Thanks, >> Coleen From volker.simonis at gmail.com Wed Jun 15 08:49:09 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Jun 2016 10:49:09 +0200 Subject: RFR(M): 8158232: PPC64: improve byte, int and long array copy stubs by using VSX instructions In-Reply-To: <7a9115b9-5ec4-58ed-51ba-de940938fe85@oracle.com> References: <201605311537.u4VFYV1Q029540@mx0a-001b2d01.pphosted.com> <4ef29ef8b7904b98952224ecb77e21f8@DEWDFE13DE09.global.corp.sap> <201606020207.u5225ptS007620@mx0a-001b2d01.pphosted.com> <498493e344fd4d02beb049ff9dd9aba3@DEWDFE13DE09.global.corp.sap> <201606021507.u52F64ci025581@mx0a-001b2d01.pphosted.com> <15e6ab6155984dee9760170d731844b1@DEWDFE13DE09.global.corp.sap> <57508330.2050307@oracle.com> <7a9115b9-5ec4-58ed-51ba-de940938fe85@oracle.com> Message-ID: Thanks Vladimir. I've updated the issue in JBS accordingly. Regards, Volker On Tue, Jun 14, 2016 at 8:34 PM, Vladimir Kozlov wrote: > Yes, there was mail sent by Mark about the process: > > http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004443.html > > " - If you own a JEP or a small enhancement that is not yet complete then > you can request an FC extension as follows: Update the JBS issue to > add a comment whose first line is "FC Extension Request". In that > comment describe the remaining work to be done, the risk level, a > brief justification, and your best estimate of the date by which the > feature will be complete. Add the label "jdk9-fc-request" to the > issue. > " > > Regards, > Vladimir > > > On 6/14/16 11:18 AM, Volker Simonis wrote: >> >> Hi Vladimir, >> >> are there any news regarding the approval process? >> I think this change is ppc only and shouldn't do any harm. >> Or maybe w should just change the issue from "Enhancement" to >> "(Performance) Bug" if that would simplify the procedure? >> >> Thank you and best regards, >> Volker >> >> >> On Thu, Jun 2, 2016 at 9:04 PM, Vladimir Kozlov >> wrote: >>> >>> Please, hold on pushing this. We are after Feature complete date May 26: >>> >>> http://openjdk.java.net/projects/jdk9/ >>> >>> All RFE(enhancement) changes should be approved before push. >>> Please, wait when approval process is finalized. >>> >>> Regards, >>> Vladimir >>> >>> On 6/2/16 11:48 AM, Lindenmaier, Goetz wrote: >>>> >>>> >>>> Ok, reviewed. >>>> >>>> Thanks for explanations, >>>> >>>> Goetz. >>>> >>>> *From:*Michihiro Horie [mailto:HORIE at jp.ibm.com] >>>> *Sent:* Thursday, June 02, 2016 5:07 PM >>>> *To:* Lindenmaier, Goetz >>>> *Cc:* hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>> *Subject:* RE: RFR(M): 8158232: PPC64: improve byte, int and long array >>>> copy stubs by using VSX instructions >>>> >>>> Hi Goetz, >>>> >>>>> You are saying you could not measure an effect? >>>> >>>> >>>> We could not observe a big difference, but as you point out, jbb2013 >>>> looks >>>> a little difficult to get stable results. >>>> >>>>> There still might be a penalty because of the additional instructions >>>>> as the prefetching for small arrays, or a lost opportunity because of >>>>> not unrolling. >>>>> It would be nice to have numbers on this, but I think the effect will >>>>> be rather small so that I?m also fine with the current solution. >>>>> >>>>> How did you test the new solution? >>>> >>>> >>>> I agree, a penalty might depend on the applications, but the effect will >>>> be rather small. I also tested the latest code by using micro benchmarks >>>> and >>>> jbb2013. >>>> >>>> Best regards, >>>> -- >>>> Michi-hiro >>>> IBM Research - Tokyo >>>> >>>> Inactive hide details for "Lindenmaier, Goetz" ---2016/06/02 >>>> 19:47:38---Hi >>>> Michihiro, thanks for the new webrev, and thanks Mar"Lindenmaier, Goetz" >>>> ---2016/06/02 19:47:38---Hi Michihiro, thanks for >>>> the new webrev, and thanks Martin for uploading it. >>>> >>>> From: "Lindenmaier, Goetz" >>> > >>>> To: Michihiro Horie/Japan/IBM at IBMJP >>>> Cc: "hotspot-dev at openjdk.java.net " >>>> >, >>>> "ppc-aix-port-dev at openjdk.java.net >>>> " >>>> >>> > >>>> Date: 2016/06/02 19:47 >>>> Subject: RE: RFR(M): 8158232: PPC64: improve byte, int and long array >>>> copy >>>> stubs by using VSX instructions >>>> >>>> >>>> >>>> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >>>> >>>> >>>> >>>> >>>> Hi Michihiro, >>>> >>>> thanks for the new webrev, and thanks Martin for uploading it. >>>> >>>>> but there was no special reason on the changes in loop body sizes >>>> >>>> >>>> You are saying you could not measure an effect? With jbb2013 it?s hard >>>> to get reproducible results, jvm2008 is more simple with that. But it >>>> needs adaptions to run with Java 8 (or you skip the compiler >>>> benchmarks). >>>> Also, there is now jbb2015 which is jbb2013 with some bugs fixed. >>>> >>>> The loop body sizes are now the same with and without vsx. >>>> This alleviates my main concerns. >>>> There still might be a penalty because of the additional instructions >>>> as the prefetching for small arrays, or a lost opportunity because of >>>> not unrolling. >>>> It would be nice to have numbers on this, but I think the effect will >>>> be rather small so that I?m also fine with the current solution. >>>> >>>> How did you test the new solution? >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> *From:*Michihiro Horie [mailto:HORIE at jp.ibm.com] * >>>> Sent:* Thursday, June 02, 2016 4:07 AM* >>>> To:* Lindenmaier, Goetz >>> >* >>>> Cc:* hotspot-dev at openjdk.java.net ; >>>> ppc-aix-port-dev at openjdk.java.net >>>> * >>>> Subject:* RE: RFR(M): 8158232: PPC64: improve byte, int and long array >>>> copy stubs by using VSX instructions >>>> >>>> Hi Goetz, >>>> >>>> Thank you very much for your comments, which is really helpful. >>>> >>>> I would fix my code to fit the loop body sizes in elements to the >>>> original >>>> ones. We did measurements by using SPECjbb2013, but there was no special >>>> reason on the changes in loop body sizes. They are >>>> code after the trial and error with a few developers. >>>> >>>>> But I'm not convinced that this helps the average performance, as >>>>> important >>>>> lengths will regress. >>>> >>>> >>>> : >>>>> >>>>> >>>>> Especially with the byte arrays, which are used to store >>>>> compact Strings, I would doubt that this helps an average >>>>> application. For sizes 32-128 you first have a failing >>>>> compare, and then step through a '4' loop instead of a '32' >>>>> one. >>>> >>>> >>>> Your point makes sense to me. >>>> >>>>> Should you also set the prefetching engine more aggressive as >>>>> in the short copy loop? >>>> >>>> >>>> I would use prefetching engine as in the short copy loop, thank you. >>>> >>>> Best regards, >>>> -- >>>> Michihiro Horie, >>>> IBM Research - Tokyo >>>> >>>> Inactive hide details for "Lindenmaier, Goetz" ---2016/06/01 >>>> 23:14:42---Hi >>>> Michihiro, Thanks for contributing to the ppc port!"Lindenmaier, Goetz" >>>> ---2016/06/01 23:14:42---Hi Michihiro, Thanks for >>>> contributing to the ppc port! >>>> >>>> From: "Lindenmaier, Goetz" >>> > >>>> To: Michihiro Horie/Japan/IBM at IBMJP, "hotspot-dev at openjdk.java.net >>>> " >>> >, >>>> "ppc-aix-port-dev at openjdk.java.net >>>> " >>>> >>> > >>>> Date: 2016/06/01 23:14 >>>> Subject: RE: RFR(M): 8158232: PPC64: improve byte, int and long array >>>> copy >>>> stubs by using VSX instructions >>>> >>>> >>>> >>>> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >>>> >>>> >>>> >>>> >>>> >>>> >>>> Hi Michihiro, >>>> >>>> Thanks for contributing to the ppc port! >>>> >>>> I've been looking at your changes. Basically they look good. But I'm >>>> not convinced that this helps the average performance, as important >>>> lengths will regress. >>>> >>>> We once ananlyzed a benchmark, where we saw 400 million copies of >>>> short arrays which had an average length of 38!! elements. There >>>> were 200 byte array copies and 20 million long array copies. >>>> This should have changed as there are compact strings, now. >>>> I think we had suppressed the array copy stubs and modified >>>> PrintOptoStatistics to collect that data. >>>> >>>> As I understand we have the following loops now: >>>> >>>> Loop body sizes in elements >>>> before now sizes regressing >>>> byte 32,4,1 128,4,1 32-127 >>>> short 16,2,1 16,2,1 none >>>> int 8,1 32,1 8-31 >>>> long 4,1 16,4,1 none >>>> >>>> Especially with the byte arrays, which are used to store >>>> compact Strings, I would doubt that this helps an average >>>> application. For sizes 32-128 you first have a failing >>>> compare, and then step through a '4' loop instead of a '32' >>>> one. >>>> >>>> Further, why don't you use the new instructions in the smaller >>>> loops, too? Like in the long '4' version? >>>> >>>> I could not find a measurement showing the effect on jbb2015 >>>> or jvm2008. Did you measure these? >>>> Or you could modify your benchmarks for some small, odd >>>> numbers, as 23, 42, 99 ...? >>>> >>>> Should you also set the prefetching engine more aggressive as >>>> in the short copy loop? >>>> >>>> Best regards, >>>> Goetz. >>>> >>>>> -----Original Message----- >>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>>> Behalf Of Michihiro Horie >>>>> Sent: Dienstag, 31. Mai 2016 17:37 >>>>> To:hotspot-dev at openjdk.java.net ; >>>>> ppc-aix-port-dev at openjdk.java.net >>>>> >>>>> Subject: RFR(M): 8158232: PPC64: improve byte, int and long array copy >>>>> stubs >>>>> by using VSX instructions >>>>> >>>>> >>>>> Dear all, >>>>> >>>>> Could you please review the following webrev? >>>>> >>>>> http://cr.openjdk.java.net/~mdoerr/8158232_PPC_vsx_copy/webrev.00/ >>>>> >>>>> This change improves performance of disjoint arraycopy of byte, int, >>>>> and >>>>> long by using VSX load/store instructions. >>>>> >>>>> Discussion started from: >>>>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016- >>>>> >>>>> _ >>>> >>>> >>>> _> May/002483.html >>>> >>>> >>>>> >>>>> >>>>> >>>>> Performance improvement with micro benchmarks is shown in: >>>>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016- >>>>> >>>>> _ >>>> >>>> >>>> _> May/002531.html >>>> >>>> >>>>> >>>>> >>>>> >>>>> Thank you very much, >>>>> >>>>> Best regards, >>>>> -- >>>>> Michihiro Horie, >>>>> IBM Research - Tokyo >>>> >>>> >>>> >>> > From vladimir.x.ivanov at oracle.com Wed Jun 15 11:06:34 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 15 Jun 2016 14:06:34 +0300 Subject: RFR 8152271: MemberNameTable doesn't purge stale entries In-Reply-To: References: Message-ID: <5c01ccec-391e-0950-cdba-652ef76b6711@oracle.com> Coleen, Latest version looks good. Thanks for adding clarifying comment in the code. >>> Summary: Intern MemberNames in table instead of allocating new entries >>> >>> For degenerate case, we were leaking native code in the member name >>> table. Going with the suggested workaround, it was only a few more >>> lines of code to intern MemberName and return the MemberName that was >>> already in the table. >> >> I guess I'm very surprised that these were not already being "cached" >> at some level (ie the Java level where all other reflection-like >> objects get cached)! I'm not familiar with the mechanics or j.l.invoke >> so was wondering where MemberName instances actually get created - >> because I'd like to understand how you get two distinct MemberName >> instances that compare equal in the first place? > > Hi David, > > The MemberNames were not being cached. There was a change to attempt to > cache them in the jdk https://bugs.openjdk.java.net/browse/JDK-8013267 > but it was a much bigger change and we still need access to MemberName > in the jvm because we have to replace the Method* in them with > redefinition. > > MemberNames get created mostly when you create a MethodHandle. The > MemberName is the jvm representation of the member of the class. It's > not simply a Method* because it contains flags based on how it's > resolved at linktime. > > In the test case provided, > MethodHandle mh = lookup.findSpecial(Leak.class, "callMe", mt, > Leak.class); > > this looks up the same method and creates the same MemberName over and > over. j.l.i.MemberName implements Cloneable and MN cloning is pervasively used during DirectMethodHandle construction (see MN.resolve() and other MN instance methods). Best regards, Vladimir Ivanov >> >> Otherwise changes seem fine - though perhaps >> MemberNameTable::add_member_name should assert the member_name is not >> already present, just to confirm those intern==false cases are working >> as intended. > > I want to keep add_member_name simple and not go through the list even > under ASSERT. It's okay if some member_name are already present, and > for the case with JVM_Clone, we want an additional MemberName in the > table (and that uses add_member_name()). > > Thanks for looking at the code. > Coleen > >> >> Thanks, >> David >> ----- >> >>> This has been performance tested to show no regression and works really >>> well for the degenerate test case, even though the real percentage of >>> reused MemberName seems quite small. >>> >>> Tested with all runtime nightly tests, tests in >>> jdk/test/java/lang/invoke. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8152271.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8152271 >>> >>> Thanks, >>> Coleen > From zoltan.majo at oracle.com Wed Jun 15 12:00:33 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 15 Jun 2016 14:00:33 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <575BE438.6010904@oracle.com> Message-ID: <57614361.3020102@oracle.com> Hi Coleen, thank you for the feedback! Please see some detailed answers inline. On 06/13/2016 02:23 PM, Coleen Phillimore wrote: > > Hi Zoltan, > > On 6/11/16 6:13 AM, Zolt?n Maj? wrote: >> Hi Coleen, >> >> >> thank you for the feedback! >> >> On 06/10/2016 09:43 PM, Coleen Phillimore wrote: >>> >>> Hi, >>> >>> I'm late to the thread, which is good because it's better that this >>> check is done in the rewriter, than in InstanceKlass. >> >> I'm glad you are OK with that. > > Yes, I think this is better. We only want one bytecode iteration > during linking. At one point, we talked about not having the rewriter > but that'll never happen. >> >>> >>> But I'm fuzzy on why this wasn't checked in the verifier, and what >>> the purpose of the has_initialized_final_update (which means a non >>> method has updated a final field, which is a verify error, >>> right? >> >> I think it is a linking exception that is supposed to be thrown >> during field resolution. Please see some details below (I use >> putfield as an example). >> >> For putfield "Linking Exceptions", the JVMS-6 [1] states: >> >> "During resolution of the symbolic reference to the field, any of the >> exceptions pertaining to field resolution documented in Section >> 5.4.3.2 can be thrown. >> [...] >> Otherwise, if the field is final, it must be declared in the current >> class. Otherwise, an IllegalAccessError is thrown." >> >> With JVMS-7 [2], the second sentence has changed the following way: >> >> "Otherwise, if the field is final, it must be declared in the current >> class, and the instruction must occur in an instance initialization >> method () of the current class. Otherwise, an >> IllegalAccessError is thrown." >> >> HotSpot currently enforces JVMS-6 (i.e.,that the final field accessed >> by the putfield must be declared in the current class). That >> condition is checked in LinkResolver::resolve_field() in >> linkResolver.cpp. > > Thank you for the clarification. It looks correct. Thank you! >> >> The current patch proposes to check *also* that the instruction >> occurs in the method, as required by JVMS-7. I've added that >> check also to LinkResolver::resolve_field() (I had the feeling that >> the two checks belong together). The new check is, however, enforced >> only for class file versions >=JDK-9 (as David pointed out earlier). >> >> Regarding has_initialized_final_update: Some compiler optimizations >> assume that final fields are modified only in initializer methods. >> That assumption does always not hold (e.g., for class file versions >> > updated outside initializers; for such fields >> has_initialized_final_update() returns true. >> >> The analysis to detect "invalid" updates to final fields must be >> performed before any of a class's methods is compiled. So the >> analysis is performed at class loading and initialization. > > Ok. I didn't understand how it affected the compilers but that's > beyond the scope of my review anyway. > >> >> The current patch proposes to do the analysis in the rewriter. That >> way we don't introduce an extra iteration over all bytecodes that are >> loaded (because we piggyback on the iteration performed by the >> rewriter). So we reduce the risk of potential performance degradations. >> >>> >>> Also, have you run the JCK tests? >> >> Yes, I've run all all JCK tests executed in JPRT (the runThese8 >> target). I also did a complete pre-PIT RBT (with -Xmixed and -Xcomp) >> run. No failures have occurred. >> > > I'll send you a link to how to run the jck9 jck tests. They take a > bit longer to run. They may run with the pre-PIT RBT though, so you > might be ok. Please check that this is the case. Thank you for sending me the instructions! To be an the safe side, I've run all JCK tests (the way you've suggested), all pass. I've attached to the bug description a file containing the test output and some details on the setup I used to run the tests. > >>> >>> Why have a global flag if it's an error? >> >> David has pointed out the reasons in his reply. >> > > Ok. Makes sense. I wonder if I should have done that with > https://bugs.openjdk.java.net/browse/JDK-8145148 I'm not sure. For the current bug, it seems that we've have agreed to not have a global flag after all. For JDK-8145148, we would probably would have to think of the possible (customer) impact of the introduced changes by and decide then if such a flag is necessary. Also, the fix for JDK-8145148 was not backported to earlier releases, so maybe it's fine to have stricter checks introduced with a new major release. Thank you! Best regards, Zoltan > > > Thanks, > Coleen >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >> [1] >> https://docs.oracle.com/javase/specs/jvms/se6/html/Instructions2.doc11.html >> >> [2] >> https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.putfield >>> >>> Thanks, >>> Coleen >>> >>> >>> >>> On 6/10/16 1:40 PM, Zolt?n Maj? wrote: >>>> Hi Vladimir, >>>> >>>> >>>> On 06/10/2016 06:05 PM, Vladimir Ivanov wrote: >>>>> >>>>>> Please note an additional small change in rewriter.cpp: >>>>>> >>>>>> +if (!reverse) { >>>>>> // Check if any final field of the class given as parameter is >>>>>> modified >>>>>> // outside of initializer methods of the class. Fields that are >>>>>> modified >>>>>> ... >>>>>> +} >>>>>> >>>>>> It's sufficient to check fields during rewriting (i.e., we're coming >>>>>> from Rewriter::rewrite_bytecodes()). We do not need to do the >>>>>> checks if >>>>>> the class has already been rewritten but we're reversing changes >>>>>> due to >>>>>> some failure that appeared during rewriting (in that case >>>>>> scan_method() >>>>>> is called from Rewriter::restore_bytecodes()). >>>>> >>>>> Ok. >>>>> >>>>>> Here is the updated webrev: >>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/ >>>>> >>>>> Looks good. >>>>> >>>>> src/share/vm/runtime/globals.hpp >>>>> >>>>> + "for classfile version >= 51") >>>>> >>>>> s/51/53/ (no need to send new webrev). >>>> >>>> OK, I've corrected the code in-situ (in webrev.11). I also have the >>>> JPRT results now, all tests pass. >>>> >>>> Thank you! >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>>> >>>> >>>> >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>> >>> >> > From zoltan.majo at oracle.com Wed Jun 15 12:03:34 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 15 Jun 2016 14:03:34 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <4b85c1f9-8e63-9546-6c65-8208c369cb89@oracle.com> References: <573C2DAD.1030903@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> <711d840a-5df1-3dbd-0a2f-c0ee64834a57@oracle.com> <4b85c1f9-8e63-9546-6c65-8208c369cb89@oracle.com> Message-ID: <57614416.2090804@oracle.com> Hi Coleen, On 06/14/2016 04:34 PM, Coleen Phillimore wrote: > [...] > > I would vote for pre-deprecating or removing the flag. We don't > generally add flags for new spec enforcement unless we anticipate a > lot of customers having problems with the new rule. OK. > Just make sure the error message is really good though, so that when > people hit this new rule, they'll know what to fix. The change I propose tries to make the error message a bit more informative, please see the changes to linkResolver.cpp in the webrev: http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/src/share/vm/interpreter/linkResolver.cpp.sdiff.html I hope that is good enough. Thank you and best regards, Zoltan > > Coleen >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach > From coleen.phillimore at oracle.com Wed Jun 15 12:03:49 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 15 Jun 2016 08:03:49 -0400 Subject: RFR 8152271: MemberNameTable doesn't purge stale entries In-Reply-To: <5c01ccec-391e-0950-cdba-652ef76b6711@oracle.com> References: <5c01ccec-391e-0950-cdba-652ef76b6711@oracle.com> Message-ID: <8fa77b50-6260-96e3-d202-f058ad1ac4d2@oracle.com> On 6/15/16 7:06 AM, Vladimir Ivanov wrote: > Coleen, > > Latest version looks good. Thanks for adding clarifying comment in the > code. > >>>> Summary: Intern MemberNames in table instead of allocating new entries >>>> >>>> For degenerate case, we were leaking native code in the member name >>>> table. Going with the suggested workaround, it was only a few more >>>> lines of code to intern MemberName and return the MemberName that was >>>> already in the table. >>> >>> I guess I'm very surprised that these were not already being "cached" >>> at some level (ie the Java level where all other reflection-like >>> objects get cached)! I'm not familiar with the mechanics or j.l.invoke >>> so was wondering where MemberName instances actually get created - >>> because I'd like to understand how you get two distinct MemberName >>> instances that compare equal in the first place? >> >> Hi David, >> >> The MemberNames were not being cached. There was a change to attempt to >> cache them in the jdk https://bugs.openjdk.java.net/browse/JDK-8013267 >> but it was a much bigger change and we still need access to MemberName >> in the jvm because we have to replace the Method* in them with >> redefinition. >> >> MemberNames get created mostly when you create a MethodHandle. The >> MemberName is the jvm representation of the member of the class. It's >> not simply a Method* because it contains flags based on how it's >> resolved at linktime. >> >> In the test case provided, >> MethodHandle mh = lookup.findSpecial(Leak.class, "callMe", mt, >> Leak.class); >> >> this looks up the same method and creates the same MemberName over and >> over. > > j.l.i.MemberName implements Cloneable and MN cloning is pervasively > used during DirectMethodHandle construction (see MN.resolve() and > other MN instance methods). So there'd still be a leak but just not a simple one. Are there plans to not use cloning? That should be a separate issue, though. The VM would now reuse MemberName with this change. Thanks, Coleen > > Best regards, > Vladimir Ivanov > >>> >>> Otherwise changes seem fine - though perhaps >>> MemberNameTable::add_member_name should assert the member_name is not >>> already present, just to confirm those intern==false cases are working >>> as intended. >> >> I want to keep add_member_name simple and not go through the list even >> under ASSERT. It's okay if some member_name are already present, and >> for the case with JVM_Clone, we want an additional MemberName in the >> table (and that uses add_member_name()). >> >> Thanks for looking at the code. >> Coleen >> >>> >>> Thanks, >>> David >>> ----- >>> >>>> This has been performance tested to show no regression and works >>>> really >>>> well for the degenerate test case, even though the real percentage of >>>> reused MemberName seems quite small. >>>> >>>> Tested with all runtime nightly tests, tests in >>>> jdk/test/java/lang/invoke. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8152271.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8152271 >>>> >>>> Thanks, >>>> Coleen >> From zoltan.majo at oracle.com Wed Jun 15 12:07:21 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 15 Jun 2016 14:07:21 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: References: <573C2DAD.1030903@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> <711d840a-5df1-3dbd-0a2f-c0ee64834a57@oracle.com> <4b85c1f9-8e63-9546-6c65-8208c369cb89@oracle.com> Message-ID: <576144F9.9040508@oracle.com> Hi David, On 06/14/2016 11:02 PM, David Holmes wrote: > [...] >> I would vote for pre-deprecating or removing the flag. We don't >> generally add flags for new spec enforcement unless we anticipate a lot >> of customers having problems with the new rule. Just make sure the >> error message is really good though, so that when people hit this new >> rule, they'll know what to fix. > > Okay. If this is restricted to 9 then we can drop the flag and require > any "offenders" to become compliant if they plan to ship Java 9 > version bytecode. OK, I've removed the flag. Here is the newest webrev: http://cr.openjdk.java.net/~zmajo/8157181/webrev.12/ Thank you! Best regards, Zoltan > > David > ----- > >> >> Coleen >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach >> From coleen.phillimore at oracle.com Wed Jun 15 12:07:54 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 15 Jun 2016 08:07:54 -0400 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <57614416.2090804@oracle.com> References: <573C2DAD.1030903@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> <711d840a-5df1-3dbd-0a2f-c0ee64834a57@oracle.com> <4b85c1f9-8e63-9546-6c65-8208c369cb89@oracle.com> <57614416.2090804@oracle.com> Message-ID: <6fcf4965-af17-5fa3-409d-52a0b2e25b59@oracle.com> On 6/15/16 8:03 AM, Zolt?n Maj? wrote: > Hi Coleen, > > > On 06/14/2016 04:34 PM, Coleen Phillimore wrote: >> [...] >> >> I would vote for pre-deprecating or removing the flag. We don't >> generally add flags for new spec enforcement unless we anticipate a >> lot of customers having problems with the new rule. > > OK. > >> Just make sure the error message is really good though, so that when >> people hit this new rule, they'll know what to fix. > > The change I propose tries to make the error message a bit more > informative, please see the changes to linkResolver.cpp in the webrev: > > http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/src/share/vm/interpreter/linkResolver.cpp.sdiff.html > > > I hope that is good enough. These messages and this change looks good (looked at cdiff because sdiffs don't look right). Thanks, Coleen > > Thank you and best regards, > > > Zoltan > >> >> Coleen >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach >> > From coleen.phillimore at oracle.com Wed Jun 15 12:09:17 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 15 Jun 2016 08:09:17 -0400 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <576144F9.9040508@oracle.com> References: <573C2DAD.1030903@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> <711d840a-5df1-3dbd-0a2f-c0ee64834a57@oracle.com> <4b85c1f9-8e63-9546-6c65-8208c369cb89@oracle.com> <576144F9.9040508@oracle.com> Message-ID: <6e31c4dd-fa63-18df-ce30-e81980408a3e@oracle.com> Okay with this one ... Thank you for making this significant change. Coleen On 6/15/16 8:07 AM, Zolt?n Maj? wrote: > Hi David, > > > On 06/14/2016 11:02 PM, David Holmes wrote: >> [...] >>> I would vote for pre-deprecating or removing the flag. We don't >>> generally add flags for new spec enforcement unless we anticipate a lot >>> of customers having problems with the new rule. Just make sure the >>> error message is really good though, so that when people hit this new >>> rule, they'll know what to fix. >> >> Okay. If this is restricted to 9 then we can drop the flag and >> require any "offenders" to become compliant if they plan to ship Java >> 9 version bytecode. > > OK, I've removed the flag. Here is the newest webrev: > http://cr.openjdk.java.net/~zmajo/8157181/webrev.12/ > > Thank you! > > Best regards, > > > Zoltan > >> >> David >> ----- >> >>> >>> Coleen >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach >>> > From zoltan.majo at oracle.com Wed Jun 15 12:17:58 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 15 Jun 2016 14:17:58 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <6fcf4965-af17-5fa3-409d-52a0b2e25b59@oracle.com> References: <573C2DAD.1030903@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> <711d840a-5df1-3dbd-0a2f-c0ee64834a57@oracle.com> <4b85c1f9-8e63-9546-6c65-8208c369cb89@oracle.com> <57614416.2090804@oracle.com> <6fcf4965-af17-5fa3-409d-52a0b2e25b59@oracle.com> Message-ID: <57614776.30403@oracle.com> Hi Coleen, On 06/15/2016 02:07 PM, Coleen Phillimore wrote: > > > > On 6/15/16 8:03 AM, Zolt?n Maj? wrote: >> Hi Coleen, >> >> >> On 06/14/2016 04:34 PM, Coleen Phillimore wrote: >>> [...] >>> >>> I would vote for pre-deprecating or removing the flag. We don't >>> generally add flags for new spec enforcement unless we anticipate a >>> lot of customers having problems with the new rule. >> >> OK. >> >>> Just make sure the error message is really good though, so that when >>> people hit this new rule, they'll know what to fix. >> >> The change I propose tries to make the error message a bit more >> informative, please see the changes to linkResolver.cpp in the webrev: >> >> http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/src/share/vm/interpreter/linkResolver.cpp.sdiff.html >> >> >> I hope that is good enough. > > These messages and this change looks good Thank you! > (looked at cdiff because sdiffs don't look right). Sorry, I should have sent you the cdiffs... Best regards, Zoltan > > Thanks, > Coleen >> >> Thank you and best regards, >> >> >> Zoltan >> >>> >>> Coleen >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach >>> >> > From zoltan.majo at oracle.com Wed Jun 15 12:18:45 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 15 Jun 2016 14:18:45 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <6e31c4dd-fa63-18df-ce30-e81980408a3e@oracle.com> References: <573C2DAD.1030903@oracle.com> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> <711d840a-5df1-3dbd-0a2f-c0ee64834a57@oracle.com> <4b85c1f9-8e63-9546-6c65-8208c369cb89@oracle.com> <576144F9.9040508@oracle.com> <6e31c4dd-fa63-18df-ce30-e81980408a3e@oracle.com> Message-ID: <576147A5.5050807@oracle.com> Hi Coleen, On 06/15/2016 02:09 PM, Coleen Phillimore wrote: > > Okay with this one ... Thank you for making this significant change. thank you for the review! Best regards, Zoltan > Coleen > > > On 6/15/16 8:07 AM, Zolt?n Maj? wrote: >> Hi David, >> >> >> On 06/14/2016 11:02 PM, David Holmes wrote: >>> [...] >>>> I would vote for pre-deprecating or removing the flag. We don't >>>> generally add flags for new spec enforcement unless we anticipate a >>>> lot >>>> of customers having problems with the new rule. Just make sure the >>>> error message is really good though, so that when people hit this new >>>> rule, they'll know what to fix. >>> >>> Okay. If this is restricted to 9 then we can drop the flag and >>> require any "offenders" to become compliant if they plan to ship >>> Java 9 version bytecode. >> >> OK, I've removed the flag. Here is the newest webrev: >> http://cr.openjdk.java.net/~zmajo/8157181/webrev.12/ >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >>> >>> David >>> ----- >>> >>>> >>>> Coleen >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach >>>> >> > From zoltan.majo at oracle.com Wed Jun 15 12:22:05 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 15 Jun 2016 14:22:05 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <576144F9.9040508@oracle.com> References: <573C2DAD.1030903@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> <711d840a-5df1-3dbd-0a2f-c0ee64834a57@oracle.com> <4b85c1f9-8e63-9546-6c65-8208c369cb89@oracle.com> <576144F9.9040508@oracle.com> Message-ID: <5761486D.4080403@oracle.com> Thanks to everyone for the reviews/feedback/suggestions! For the record: I'll push the latest version (webrev.12) later today. Best regards, Zoltan On 06/15/2016 02:07 PM, Zolt?n Maj? wrote: > Hi David, > > > On 06/14/2016 11:02 PM, David Holmes wrote: >> [...] >>> I would vote for pre-deprecating or removing the flag. We don't >>> generally add flags for new spec enforcement unless we anticipate a lot >>> of customers having problems with the new rule. Just make sure the >>> error message is really good though, so that when people hit this new >>> rule, they'll know what to fix. >> >> Okay. If this is restricted to 9 then we can drop the flag and >> require any "offenders" to become compliant if they plan to ship Java >> 9 version bytecode. > > OK, I've removed the flag. Here is the newest webrev: > http://cr.openjdk.java.net/~zmajo/8157181/webrev.12/ > > Thank you! > > Best regards, > > > Zoltan > >> >> David >> ----- >> >>> >>> Coleen >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach >>> > From vladimir.x.ivanov at oracle.com Wed Jun 15 12:22:31 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 15 Jun 2016 15:22:31 +0300 Subject: RFR 8152271: MemberNameTable doesn't purge stale entries In-Reply-To: <8fa77b50-6260-96e3-d202-f058ad1ac4d2@oracle.com> References: <5c01ccec-391e-0950-cdba-652ef76b6711@oracle.com> <8fa77b50-6260-96e3-d202-f058ad1ac4d2@oracle.com> Message-ID: <4b95b8f3-a434-085f-fada-90dd528970f4@oracle.com> On 6/15/16 3:03 PM, Coleen Phillimore wrote: > > > On 6/15/16 7:06 AM, Vladimir Ivanov wrote: >> Coleen, >> >> Latest version looks good. Thanks for adding clarifying comment in the >> code. >> >>>>> Summary: Intern MemberNames in table instead of allocating new entries >>>>> >>>>> For degenerate case, we were leaking native code in the member name >>>>> table. Going with the suggested workaround, it was only a few more >>>>> lines of code to intern MemberName and return the MemberName that was >>>>> already in the table. >>>> >>>> I guess I'm very surprised that these were not already being "cached" >>>> at some level (ie the Java level where all other reflection-like >>>> objects get cached)! I'm not familiar with the mechanics or j.l.invoke >>>> so was wondering where MemberName instances actually get created - >>>> because I'd like to understand how you get two distinct MemberName >>>> instances that compare equal in the first place? >>> >>> Hi David, >>> >>> The MemberNames were not being cached. There was a change to attempt to >>> cache them in the jdk https://bugs.openjdk.java.net/browse/JDK-8013267 >>> but it was a much bigger change and we still need access to MemberName >>> in the jvm because we have to replace the Method* in them with >>> redefinition. >>> >>> MemberNames get created mostly when you create a MethodHandle. The >>> MemberName is the jvm representation of the member of the class. It's >>> not simply a Method* because it contains flags based on how it's >>> resolved at linktime. >>> >>> In the test case provided, >>> MethodHandle mh = lookup.findSpecial(Leak.class, "callMe", mt, >>> Leak.class); >>> >>> this looks up the same method and creates the same MemberName over and >>> over. >> >> j.l.i.MemberName implements Cloneable and MN cloning is pervasively >> used during DirectMethodHandle construction (see MN.resolve() and >> other MN instance methods). > > So there'd still be a leak but just not a simple one. Are there plans > to not use cloning? That should be a separate issue, though. The VM > would now reuse MemberName with this change. No, I'm not aware of any plans to get rid of MN cloning. The following code takes care of cloned MN instance: --- old/src/share/vm/prims/jvm.cpp 2016-06-09 17:19:13.896240434 -0400 +++ new/src/share/vm/prims/jvm.cpp 2016-06-09 17:19:13.454960882 -0400 @@ -695,7 +695,7 @@ // This can safepoint and redefine method, so need both new_obj and method // in a handle, for two different reasons. new_obj can move, method can be // deleted if nothing is using it on the stack. - m->method_holder()->add_member_name(new_obj()); + m->method_holder()->add_member_name(new_obj(), false); } } The cloned instance is usually adjusted (changes in MN.flags) right away, so it becomes non-equal to the original one. It allows to bypass repeated resolution. When you talk about a leak, do you mean the situation when there's already a duplicate of adjusted MN registered ? If it causes a leak, we can do a call into the JVM to intern adjusted MN instance, e.g: jdk/src/java.base/share/classes/java/lang/invoke/MemberName.java: private MemberName changeReferenceKind(byte refKind, byte oldKind) { assert(getReferenceKind() == oldKind); assert(MethodHandleNatives.refKindIsValid(refKind)); flags += (((int)refKind - oldKind) << MN_REFERENCE_KIND_SHIFT); return MethodHandleNatives.intern(this); // returns interned MN instance } Best regards, Vladimir Ivanov > > Thanks, > Coleen > >> >> Best regards, >> Vladimir Ivanov >> >>>> >>>> Otherwise changes seem fine - though perhaps >>>> MemberNameTable::add_member_name should assert the member_name is not >>>> already present, just to confirm those intern==false cases are working >>>> as intended. >>> >>> I want to keep add_member_name simple and not go through the list even >>> under ASSERT. It's okay if some member_name are already present, and >>> for the case with JVM_Clone, we want an additional MemberName in the >>> table (and that uses add_member_name()). >>> >>> Thanks for looking at the code. >>> Coleen >>> >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> This has been performance tested to show no regression and works >>>>> really >>>>> well for the degenerate test case, even though the real percentage of >>>>> reused MemberName seems quite small. >>>>> >>>>> Tested with all runtime nightly tests, tests in >>>>> jdk/test/java/lang/invoke. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8152271.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8152271 >>>>> >>>>> Thanks, >>>>> Coleen >>> > From david.holmes at oracle.com Wed Jun 15 12:57:57 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Jun 2016 22:57:57 +1000 Subject: JDK 9 is not (yet) Feature Complete -- how will we get there? In-Reply-To: <20160610072437.975638333eggemoggin.niobe.net> References: <20160610072437.975638333eggemoggin.niobe.net> Message-ID: Please read the following thoroughly. After requesting approval you must wait until approval is granted before pushing anything. As the approval process itself is still not confirmed, do not expect any approvals until after the process has been confirmed. Thanks, David On 11/06/2016 12:24 AM, mark.reinhold at oracle.com wrote: > The JDK 9 schedule [1] lists a date for the Feature Complete milestone > of 2016/5/26, about two weeks ago. There's been some concern that this > means that the JDK 9 (and hence Java SE 9) feature set is somehow frozen, > but that's not the case. > > The milestones listed in the JDK 9 schedule are condition-driven rather > than date-driven, as noted along with the milestone definitions [2]. We > try our best to reach the goal of each milestone by its scheduled date. > If we miss a date then we don't just blindly constrain further work so as > to fit the date, we instead manage the remaining changes relevant to the > milestone so as to reach its goal in a reasonable time frame without > putting the final GA date at undue risk. When we finally do reach the > goal then we declare the milestone on that date. > > The goal of the Feature Complete milestone is to get all of the planned > features, i.e., JEPs, and smaller enhancements integrated into the JDK 9 > master forest, together with their unit tests. As of today most JEPs > targeted to JDK 9 have been completed [3]. Fifteen JEPs remain, and a > number of small enhancements are listed as intended for JDK 9 but are > still either open or in progress. > > To manage the remaining JEPs and small enhancements so that we can reach > the Feature Complete state in a timely fashion I hereby propose the > following process: > > - If you own a JEP or a small enhancement that is not yet complete then > you can request an FC extension as follows: Update the JBS issue to > add a comment whose first line is "FC Extension Request". In that > comment describe the remaining work to be done, the risk level, a > brief justification, and your best estimate of the date by which the > feature will be complete. Add the label "jdk9-fc-request" to the > issue. > > - The Area Leads, relevant Group Leads, and I will review such requests > on a regular basis, at least weekly if not more often. One of us > will take one of the following actions: > > - Approve the request by adding the label "jdk9-fc-yes". > > - Reject the request by adding the label "jdk9-fc-no", along > with a comment describing the reason for this action. > > - Request more information by adding the label "jdk9-fc-nmi" > ("nmi" = "needs more information"), along with a comment > describing what information is requested. > > - If you're asked to provide more information for an FC extension > request then please do so in a new comment in the issue, and then > remove the "jdk9-fc-nmi" label so that we see that it's ready for > re-review. > > - If your request is approved then update the issue's due date to the > expected completion date. > > - If you own a JEP that's targeted to JDK 9, but won't make it, then > please propose to drop it [4]; this will move the JEP back to the > Candidate state unless there are strong objections. If you own a > small enhancement whose fix version is 9, but won't make it, then > please clear the fix-version field. > > If a JEP has been granted an FC extension then enhancement issues that > block the JEP's issue are automatically considered to have FC extensions. > > If a JEP has not yet been targeted to JDK 9 then you can still propose to > target it to the release, but going forward the bar for accepting new > features will be increasingly high. > > For the record, the Area Leads are Mikael Vidstedt (VM) and Brian Goetz > (Language and Libraries). The relevant Group Leads are as follows, per > the Census [5]: > > Artem Ananiev - AWT > Alan Bateman - Core Libraries > Tim Bell - Build > Daniel D. Daugherty - Serviceability > Jonathan Gibbons - Compiler > Vladimir Kozlov - HotSpot > Michael McMahon - Networking > Sean Mullan - Security > Masayoshi Okutsu - Internationalization > Pavel Porvatov - Swing > Phil Race - 2D Graphics & Sound > Dalibor Topic - Porters > > JDK 9 Committers are invited to comment on this process proposal. If no > serious objections are raised in one week's time, by 15:00 UTC on 17 June > 2016, then this is the process that we'll use. > > In anticipation that we will use this process, more or less, I encourage > owners of not-yet-complete JEPs and small enhancements to go ahead and > request extensions as described above, if desired, so that we can move > quickly once the process is in place. > > - Mark > > > [1] http://openjdk.java.net/projects/jdk9/ > [2] http://openjdk.java.net/projects/jdk8/milestones#definitions > [3] http://j.mp/jdk9-features-jbs > [4] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html#Proposed-to-Drop > [5] http://openjdk.java.net/census > From coleen.phillimore at oracle.com Wed Jun 15 13:31:24 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 15 Jun 2016 09:31:24 -0400 Subject: RFR 8152271: MemberNameTable doesn't purge stale entries In-Reply-To: <4b95b8f3-a434-085f-fada-90dd528970f4@oracle.com> References: <5c01ccec-391e-0950-cdba-652ef76b6711@oracle.com> <8fa77b50-6260-96e3-d202-f058ad1ac4d2@oracle.com> <4b95b8f3-a434-085f-fada-90dd528970f4@oracle.com> Message-ID: <3c94c9ff-2c8a-58d6-073e-abefb240ab03@oracle.com> Hi Vladimir, On 6/15/16 8:22 AM, Vladimir Ivanov wrote: > > > On 6/15/16 3:03 PM, Coleen Phillimore wrote: >> >> >> On 6/15/16 7:06 AM, Vladimir Ivanov wrote: >>> Coleen, >>> >>> Latest version looks good. Thanks for adding clarifying comment in the >>> code. >>> >>>>>> Summary: Intern MemberNames in table instead of allocating new >>>>>> entries >>>>>> >>>>>> For degenerate case, we were leaking native code in the member name >>>>>> table. Going with the suggested workaround, it was only a few more >>>>>> lines of code to intern MemberName and return the MemberName that >>>>>> was >>>>>> already in the table. >>>>> >>>>> I guess I'm very surprised that these were not already being "cached" >>>>> at some level (ie the Java level where all other reflection-like >>>>> objects get cached)! I'm not familiar with the mechanics or >>>>> j.l.invoke >>>>> so was wondering where MemberName instances actually get created - >>>>> because I'd like to understand how you get two distinct MemberName >>>>> instances that compare equal in the first place? >>>> >>>> Hi David, >>>> >>>> The MemberNames were not being cached. There was a change to >>>> attempt to >>>> cache them in the jdk https://bugs.openjdk.java.net/browse/JDK-8013267 >>>> but it was a much bigger change and we still need access to MemberName >>>> in the jvm because we have to replace the Method* in them with >>>> redefinition. >>>> >>>> MemberNames get created mostly when you create a MethodHandle. The >>>> MemberName is the jvm representation of the member of the class. It's >>>> not simply a Method* because it contains flags based on how it's >>>> resolved at linktime. >>>> >>>> In the test case provided, >>>> MethodHandle mh = lookup.findSpecial(Leak.class, "callMe", mt, >>>> Leak.class); >>>> >>>> this looks up the same method and creates the same MemberName over and >>>> over. >>> >>> j.l.i.MemberName implements Cloneable and MN cloning is pervasively >>> used during DirectMethodHandle construction (see MN.resolve() and >>> other MN instance methods). >> >> So there'd still be a leak but just not a simple one. Are there plans >> to not use cloning? That should be a separate issue, though. The VM >> would now reuse MemberName with this change. > > No, I'm not aware of any plans to get rid of MN cloning. > > The following code takes care of cloned MN instance: > > --- old/src/share/vm/prims/jvm.cpp 2016-06-09 17:19:13.896240434 -0400 > +++ new/src/share/vm/prims/jvm.cpp 2016-06-09 17:19:13.454960882 -0400 > @@ -695,7 +695,7 @@ > // This can safepoint and redefine method, so need both new_obj > and method > // in a handle, for two different reasons. new_obj can move, > method can be > // deleted if nothing is using it on the stack. > - m->method_holder()->add_member_name(new_obj()); > + m->method_holder()->add_member_name(new_obj(), false); > } > } > > The cloned instance is usually adjusted (changes in MN.flags) right > away, so it becomes non-equal to the original one. It allows to bypass > repeated resolution. Ah, I see. > > When you talk about a leak, do you mean the situation when there's > already a duplicate of adjusted MN registered ? I was but I didn't realize what the cloning was for. > > If it causes a leak, we can do a call into the JVM to intern adjusted > MN instance, e.g: > > jdk/src/java.base/share/classes/java/lang/invoke/MemberName.java: > > private MemberName changeReferenceKind(byte refKind, byte oldKind) { > assert(getReferenceKind() == oldKind); > assert(MethodHandleNatives.refKindIsValid(refKind)); > flags += (((int)refKind - oldKind) << MN_REFERENCE_KIND_SHIFT); > return MethodHandleNatives.intern(this); // returns interned MN > instance > } Yes, this could be added if there's a problem observed. This should be considered in the context of https://bugs.openjdk.java.net/browse/JDK-8013267 for later. I'll add it to the bug. Thanks, Coleen > > Best regards, > Vladimir Ivanov > >> >> Thanks, >> Coleen >> >>> >>> Best regards, >>> Vladimir Ivanov >>> >>>>> >>>>> Otherwise changes seem fine - though perhaps >>>>> MemberNameTable::add_member_name should assert the member_name is not >>>>> already present, just to confirm those intern==false cases are >>>>> working >>>>> as intended. >>>> >>>> I want to keep add_member_name simple and not go through the list even >>>> under ASSERT. It's okay if some member_name are already present, and >>>> for the case with JVM_Clone, we want an additional MemberName in the >>>> table (and that uses add_member_name()). >>>> >>>> Thanks for looking at the code. >>>> Coleen >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> This has been performance tested to show no regression and works >>>>>> really >>>>>> well for the degenerate test case, even though the real >>>>>> percentage of >>>>>> reused MemberName seems quite small. >>>>>> >>>>>> Tested with all runtime nightly tests, tests in >>>>>> jdk/test/java/lang/invoke. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8152271.01/webrev >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8152271 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>> >> From kim.barrett at oracle.com Wed Jun 15 18:48:00 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 15 Jun 2016 14:48:00 -0400 Subject: [PATCH resend2] 8157758: Use (~0u) instead of (-1) when left-shifting In-Reply-To: <740DB36B-CB51-46E9-A456-A546FD3F3836@oracle.com> References: <740DB36B-CB51-46E9-A456-A546FD3F3836@oracle.com> Message-ID: <855E9FFA-4BD7-4329-806E-A1BFE5665AD2@oracle.com> > On Jun 14, 2016, at 6:14 PM, Kim Barrett wrote: > >> On Jun 13, 2016, at 11:51 AM, Alex Henrie wrote: >> >> # HG changeset patch >> # User ahenrie >> # Date 1464130244 21600 >> # Tue May 24 16:50:44 2016 -0600 >> # Node ID e3e2afa872c68a8fc7891fc25a9a11dab0704787 >> # Parent 3f4173a750ac10fa4c22ed3d0e3d8d43bab3020b >> 8157758: Use (~0u) instead of (-1) when left-shifting >> >> diff --git a/src/share/vm/code/dependencies.hpp b/src/share/vm/code/dependencies.hpp >> --- a/src/share/vm/code/dependencies.hpp >> +++ b/src/share/vm/code/dependencies.hpp >> @@ -163,17 +163,17 @@ class Dependencies: public ResourceObj { >> call_site_target_value, >> >> TYPE_LIMIT >> }; >> enum { >> LG2_TYPE_LIMIT = 4, // assert(TYPE_LIMIT <= (1<> >> // handy categorizations of dependency types: >> - all_types = ((1 << TYPE_LIMIT) - 1) & ((-1) << FIRST_TYPE), >> + all_types = ((1 << TYPE_LIMIT) - 1) & ((~0u) << FIRST_TYPE), >> >> non_klass_types = (1 << call_site_target_value), >> klass_types = all_types & ~non_klass_types, >> >> non_ctxk_types = (1 << evol_method) | (1 << call_site_target_value), >> implicit_ctxk_types = 0, >> explicit_ctxk_types = all_types & ~(non_ctxk_types | implicit_ctxk_types), >> >> diff --git a/src/share/vm/oops/cpCache.hpp b/src/share/vm/oops/cpCache.hpp >> --- a/src/share/vm/oops/cpCache.hpp >> +++ b/src/share/vm/oops/cpCache.hpp >> @@ -188,17 +188,17 @@ class ConstantPoolCacheEntry VALUE_OBJ_C >> is_final_shift = 22, // (f) is the field or method final? >> is_volatile_shift = 21, // (v) is the field volatile? >> is_vfinal_shift = 20, // (vf) did the call resolve to a final method? >> // low order bits give field index (for FieldInfo) or method parameter size: >> field_index_bits = 16, >> field_index_mask = right_n_bits(field_index_bits), >> parameter_size_bits = 8, // subset of field_index_mask, range is 0..255 >> parameter_size_mask = right_n_bits(parameter_size_bits), >> - option_bits_mask = ~(((-1) << tos_state_shift) | (field_index_mask | parameter_size_mask)) >> + option_bits_mask = ~(((~0u) << tos_state_shift) | (field_index_mask | parameter_size_mask)) >> }; >> >> // specific bit definitions for the indices field: >> enum { >> cp_index_bits = 2*BitsPerByte, >> cp_index_mask = right_n_bits(cp_index_bits), >> bytecode_1_shift = cp_index_bits, >> bytecode_1_mask = right_n_bits(BitsPerByte), // == (u1)0xFF > > At first glance, the proposed changes seem obviously correct, since > they replace left shifts of negative signed values, which is undefined > behavior, with left shifts of unsigned values, which are fine. > > However, this patch may change the underlying type of the enum, > affecting the types of all the enumerators. That could have > widespread ripple effects that are hard to track and examine. > > Better would be to extract these problematic values out of their > respective enums and instead declare them as static consts of an > appropriate type. That they are presently enumerators isn't actually > interesting. > > Probably many / all of the nearby enumerators would be better treated > as static const declarations with appropriate types, but that's less > urgent than eliminating the obvious undefined behavior. After examining the specific values involved, I don't think a change of the underlying type for the enums in question is likely after all. And my suggestion of moving the affected values out of the enum has a similar opportunity to change the underlying type of the enum. I still think it would be better in the long term to eliminate the enums in favor of constants with specified types (or make the underlying type explicit using C++11 syntax, but we don't have that option yet), but that isn't needed right now. So I've changed my mind about this patch. Looks good. From paul.sandoz at oracle.com Thu Jun 16 03:54:40 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 15 Jun 2016 20:54:40 -0700 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: <575FC8D5.8050900@redhat.com> References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> <57561996.4000501@oracle.com> <951844EF-D517-4BF5-861A-81769EA1C306@oracle.com> <8d668cf7-1f40-8310-117e-267cefe2ab5c@oracle.com> <575FC8D5.8050900@redhat.com> Message-ID: Hi Joe, Andrew, > On 14 Jun 2016, at 02:05, Andrew Haley wrote: > > On 14/06/16 05:09, joe darcy wrote: >> I suggest also pointing out that a bitwise comparison distinguishes -0.0 >> from +0.0; they compare as == under the built-in operation. > > Indeed so, yes. This is particularly likely to bite people who have > a zero created by, say, an algorithm which converges on zero with > successive terms which alternate sign. Eww. > In a previously unpublished incarnation i did talk about -0.0/+0.0, then i dropped it... Here is an updated revision of the note: 1226 * @apiNote 1227 * Bitwise comparison of {@code float} values or {@code double} values, 1228 * as performed by the numeric and atomic update access modes, differ 1229 * from the primitive {@code ==} operator and the {@link Float#equals} 1230 * and {@link Double#equals} methods, specifically with respect to 1231 * comparing NaN values or comparing {@code -0.0} with {@code +0.0}. 1232 * Care should be taken when performing a compare and set or a compare 1233 * and exchange operation with such values since the operation may 1234 * unexpectedly fail. 1235 * There are many possible NaN values that are considered to be 1236 * {@code NaN} in Java, although no IEEE 754 floating-point operation 1237 * provided by Java can distinguish between them. Operation failure can 1238 * occur if the expected or witness value is a NaN value and it is 1239 * transformed (perhaps in a platform specific manner) into another NaN 1240 * value, and thus has a different bitwise representation (see 1241 * {@link Float#intBitsToFloat} or {@link Double#longBitsToDouble} for more 1242 * details). 1243 * The values {@code -0.0} and {@code +0.0} have different bitwise 1244 * representations but are considered equal when using the primitive 1245 * {@code ==} operator. Operation failure can occur if, for example, a 1246 * numeric algorithm computes an expected value to be say {@code -0.0} 1247 * and previously computed the witness value to be say {@code +0.0}. Paul. From volker.simonis at gmail.com Thu Jun 16 14:54:11 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 16 Jun 2016 16:54:11 +0200 Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation on ppc64 and sparc Message-ID: Hi, can I please have a review and sponsor for the following small change which fixes -XX:-UseOnStackReplacement to work together with -XX:+TieredCompilation: http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620/ https://bugs.openjdk.java.net/browse/JDK-8159620 This is a long standing bug on SPARC and as the ppc64 template interpreter was initially forked from the SPARC implementation, it also manifests there. The problem is that in the case of tiered compilation the interpreter unconditionally calls InterpreterRuntime::frequency_counter_overflow if the back edge counter overflows. This triggers an OSR compilation, even if OSR was switched off with -XX:-UseOnStackReplacement. The fix is simple - just don't call InterpreterRuntime::frequency_counter_overflow if OSR has been switched off. Thank you and best regards, Volker From vladimir.kozlov at oracle.com Fri Jun 17 01:57:11 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Jun 2016 18:57:11 -0700 Subject: CFV: New hotspot Group Member: Zoltan Majo Message-ID: <576358F7.7050409@oracle.com> I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to Membership in the hotspot Group. Zoltan is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He has been working on Hotspot since 2014 and contributed more than 60 changes. Votes are due by 18:00, Thu, June 30, 2016 PDT. Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list For Lazy Consensus voting instructions, see [2]. Vladimir Kozlov [1] http://openjdk.java.net/census#hotspot [2] http://openjdk.java.net/groups/#member-vote From vladimir.kozlov at oracle.com Fri Jun 17 02:08:05 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Jun 2016 19:08:05 -0700 Subject: CFV: New hotspot Group Member: Tobias Hartmann Message-ID: <57635B85.4070700@oracle.com> I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to Membership in the hotspot Group. Tobias is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He has been working on Hotspot since 2013 (he worked on segmented codecache before joining Oracle) and contributed more than 130 changes. Votes are due by 18:00, Thu, June 30, 2016 PDT. Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list For Lazy Consensus voting instructions, see [2]. Vladimir Kozlov [1] http://openjdk.java.net/census#hotspot [2] http://openjdk.java.net/groups/#member-vote From coleen.phillimore at oracle.com Fri Jun 17 02:34:17 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 16 Jun 2016 22:34:17 -0400 Subject: CFV: New hotspot Group Member: Zoltan Majo In-Reply-To: <576358F7.7050409@oracle.com> References: <576358F7.7050409@oracle.com> Message-ID: <4eade878-b68b-d061-b22d-772baaa4ac41@oracle.com> Vote: yes On 6/16/16 9:57 PM, Vladimir Kozlov wrote: > I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to Membership > in the hotspot Group. > > Zoltan is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He > has been working on Hotspot since 2014 and contributed more than 60 > changes. > > Votes are due by 18:00, Thu, June 30, 2016 PDT. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote From coleen.phillimore at oracle.com Fri Jun 17 02:34:36 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 16 Jun 2016 22:34:36 -0400 Subject: CFV: New hotspot Group Member: Tobias Hartmann In-Reply-To: <57635B85.4070700@oracle.com> References: <57635B85.4070700@oracle.com> Message-ID: <2ea30eba-a757-7e35-fa90-ec5f7ef31616@oracle.com> Vote: yes On 6/16/16 10:08 PM, Vladimir Kozlov wrote: > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to > Membership in the hotspot Group. > > Tobias is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He > has been working on Hotspot since 2013 (he worked on segmented > codecache before joining Oracle) and contributed more than 130 changes. > > Votes are due by 18:00, Thu, June 30, 2016 PDT. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote From john.r.rose at oracle.com Fri Jun 17 03:42:11 2016 From: john.r.rose at oracle.com (John Rose) Date: Thu, 16 Jun 2016 20:42:11 -0700 Subject: CFV: New hotspot Group Member: Tobias Hartmann In-Reply-To: <57635B85.4070700@oracle.com> References: <57635B85.4070700@oracle.com> Message-ID: Vote: yes On Jun 16, 2016, at 7:08 PM, Vladimir Kozlov wrote: > > Tobias Hartmann From john.r.rose at oracle.com Fri Jun 17 03:42:21 2016 From: john.r.rose at oracle.com (John Rose) Date: Thu, 16 Jun 2016 20:42:21 -0700 Subject: CFV: New hotspot Group Member: Zoltan Majo In-Reply-To: <576358F7.7050409@oracle.com> References: <576358F7.7050409@oracle.com> Message-ID: <0CA88E0E-AD02-4550-A2E2-90AF9866BCA5@oracle.com> Vote: yes From david.holmes at oracle.com Fri Jun 17 03:56:53 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Jun 2016 13:56:53 +1000 Subject: CFV: New hotspot Group Member: Zoltan Majo In-Reply-To: <576358F7.7050409@oracle.com> References: <576358F7.7050409@oracle.com> Message-ID: <70f110f2-b35e-4821-71b6-a68f71b8744b@oracle.com> Vote: yes David On 17/06/2016 11:57 AM, Vladimir Kozlov wrote: > I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to Membership > in the hotspot Group. > > Zoltan is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He > has been working on Hotspot since 2014 and contributed more than 60 > changes. > > Votes are due by 18:00, Thu, June 30, 2016 PDT. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote From david.holmes at oracle.com Fri Jun 17 03:57:11 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Jun 2016 13:57:11 +1000 Subject: CFV: New hotspot Group Member: Tobias Hartmann In-Reply-To: <57635B85.4070700@oracle.com> References: <57635B85.4070700@oracle.com> Message-ID: <5b2fd237-e189-cab0-a414-d9f3efba7d0b@oracle.com> Vote: yes David On 17/06/2016 12:08 PM, Vladimir Kozlov wrote: > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to > Membership in the hotspot Group. > > Tobias is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He > has been working on Hotspot since 2013 (he worked on segmented codecache > before joining Oracle) and contributed more than 130 changes. > > Votes are due by 18:00, Thu, June 30, 2016 PDT. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote From daniel.daugherty at oracle.com Fri Jun 17 04:17:40 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 16 Jun 2016 22:17:40 -0600 Subject: CFV: New hotspot Group Member: Zoltan Majo In-Reply-To: <576358F7.7050409@oracle.com> References: <576358F7.7050409@oracle.com> Message-ID: <7634bbc4-fc46-0e96-5aa6-a3d9c69b0246@oracle.com> Vote: yes Dan On 6/16/16 7:57 PM, Vladimir Kozlov wrote: > I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to Membership > in the hotspot Group. > > Zoltan is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He > has been working on Hotspot since 2014 and contributed more than 60 > changes. > > Votes are due by 18:00, Thu, June 30, 2016 PDT. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > From daniel.daugherty at oracle.com Fri Jun 17 04:18:04 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 16 Jun 2016 22:18:04 -0600 Subject: CFV: New hotspot Group Member: Tobias Hartmann In-Reply-To: <57635B85.4070700@oracle.com> References: <57635B85.4070700@oracle.com> Message-ID: <924f360b-8ccb-9099-2115-44404be2dbcc@oracle.com> Vote: yes Dan On 6/16/16 8:08 PM, Vladimir Kozlov wrote: > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to > Membership in the hotspot Group. > > Tobias is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He > has been working on Hotspot since 2013 (he worked on segmented > codecache before joining Oracle) and contributed more than 130 changes. > > Votes are due by 18:00, Thu, June 30, 2016 PDT. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > From vladimir.kozlov at oracle.com Fri Jun 17 05:29:25 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Jun 2016 22:29:25 -0700 Subject: CFV: New hotspot Group Member: Zoltan Majo In-Reply-To: <576358F7.7050409@oracle.com> References: <576358F7.7050409@oracle.com> Message-ID: Vote: yes On 6/16/16 6:57 PM, Vladimir Kozlov wrote: > I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to Membership in the hotspot Group. > > Zoltan is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He has been working on Hotspot since 2014 and > contributed more than 60 changes. > > Votes are due by 18:00, Thu, June 30, 2016 PDT. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote From vladimir.kozlov at oracle.com Fri Jun 17 05:29:40 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Jun 2016 22:29:40 -0700 Subject: CFV: New hotspot Group Member: Tobias Hartmann In-Reply-To: <57635B85.4070700@oracle.com> References: <57635B85.4070700@oracle.com> Message-ID: <81d5d128-0606-5e5b-3d13-ed7557caabf3@oracle.com> Vote: yes On 6/16/16 7:08 PM, Vladimir Kozlov wrote: > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to Membership in the hotspot Group. > > Tobias is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He has been working on Hotspot since 2013 (he worked > on segmented codecache before joining Oracle) and contributed more than 130 changes. > > Votes are due by 18:00, Thu, June 30, 2016 PDT. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote From jesper.wilhelmsson at oracle.com Fri Jun 17 05:30:00 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 17 Jun 2016 07:30:00 +0200 Subject: CFV: New hotspot Group Member: Tobias Hartmann In-Reply-To: <57635B85.4070700@oracle.com> References: <57635B85.4070700@oracle.com> Message-ID: <61ce61a4-70b1-278e-52bd-f158644231d7@oracle.com> Vote: yes /Jesper Den 17/6/16 kl. 04:08, skrev Vladimir Kozlov: > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to Membership > in the hotspot Group. > > Tobias is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He has been > working on Hotspot since 2013 (he worked on segmented codecache before joining > Oracle) and contributed more than 130 changes. > > Votes are due by 18:00, Thu, June 30, 2016 PDT. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote From jesper.wilhelmsson at oracle.com Fri Jun 17 05:31:07 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 17 Jun 2016 07:31:07 +0200 Subject: CFV: New hotspot Group Member: Zoltan Majo In-Reply-To: <576358F7.7050409@oracle.com> References: <576358F7.7050409@oracle.com> Message-ID: <1fb1b113-f5fd-6fd4-b69f-5da2dba22505@oracle.com> Vote: yes /Jesper Den 17/6/16 kl. 03:57, skrev Vladimir Kozlov: > I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to Membership in the > hotspot Group. > > Zoltan is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He has been > working on Hotspot since 2014 and contributed more than 60 changes. > > Votes are due by 18:00, Thu, June 30, 2016 PDT. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote From stefan.karlsson at oracle.com Fri Jun 17 06:43:02 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 17 Jun 2016 08:43:02 +0200 Subject: CFV: New hotspot Group Member: Tobias Hartmann In-Reply-To: <57635B85.4070700@oracle.com> References: <57635B85.4070700@oracle.com> Message-ID: <57639BF6.2050007@oracle.com> Vote: yes StefanK On 2016-06-17 04:08, Vladimir Kozlov wrote: > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to > Membership in the hotspot Group. > > Tobias is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He > has been working on Hotspot since 2013 (he worked on segmented > codecache before joining Oracle) and contributed more than 130 changes. > > Votes are due by 18:00, Thu, June 30, 2016 PDT. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote From stefan.karlsson at oracle.com Fri Jun 17 06:43:30 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 17 Jun 2016 08:43:30 +0200 Subject: CFV: New hotspot Group Member: Zoltan Majo In-Reply-To: <576358F7.7050409@oracle.com> References: <576358F7.7050409@oracle.com> Message-ID: <57639C12.1090600@oracle.com> Vote: yes StefanK On 2016-06-17 03:57, Vladimir Kozlov wrote: > I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to Membership > in the hotspot Group. > > Zoltan is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He > has been working on Hotspot since 2014 and contributed more than 60 > changes. > > Votes are due by 18:00, Thu, June 30, 2016 PDT. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote From goetz.lindenmaier at sap.com Fri Jun 17 07:07:42 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 17 Jun 2016 07:07:42 +0000 Subject: New hotspot Group Member: Zoltan Majo In-Reply-To: <576358F7.7050409@oracle.com> References: <576358F7.7050409@oracle.com> Message-ID: <1fefb33d66054551a3e5077ae0679bdf@DEWDFE13DE09.global.corp.sap> Vote: yes Best regards, Goetz. > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Vladimir Kozlov > Sent: Freitag, 17. Juni 2016 03:57 > To: hotspot-dev at openjdk.java.net > Subject: CFV: New hotspot Group Member: Zoltan Majo > > I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to Membership > in the hotspot Group. > > Zoltan is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He has > been working on Hotspot since 2014 and contributed more than 60 changes. > > Votes are due by 18:00, Thu, June 30, 2016 PDT. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote From goetz.lindenmaier at sap.com Fri Jun 17 07:07:58 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 17 Jun 2016 07:07:58 +0000 Subject: New hotspot Group Member: Tobias Hartmann In-Reply-To: <57635B85.4070700@oracle.com> References: <57635B85.4070700@oracle.com> Message-ID: Vote: yes Best regards, Goetz. > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Vladimir Kozlov > Sent: Freitag, 17. Juni 2016 04:08 > To: hotspot-dev at openjdk.java.net > Subject: CFV: New hotspot Group Member: Tobias Hartmann > > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to > Membership in the hotspot Group. > > Tobias is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He has > been working on Hotspot since 2013 (he worked on segmented codecache > before joining Oracle) and contributed more than 130 > changes. > > Votes are due by 18:00, Thu, June 30, 2016 PDT. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote From volker.simonis at gmail.com Fri Jun 17 07:19:15 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Jun 2016 09:19:15 +0200 Subject: CFV: New hotspot Group Member: Zoltan Majo In-Reply-To: <576358F7.7050409@oracle.com> References: <576358F7.7050409@oracle.com> Message-ID: Vote: yes On Fri, Jun 17, 2016 at 3:57 AM, Vladimir Kozlov wrote: > I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to Membership in > the hotspot Group. > > Zoltan is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He has > been working on Hotspot since 2014 and contributed more than 60 changes. > > Votes are due by 18:00, Thu, June 30, 2016 PDT. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote From goetz.lindenmaier at sap.com Fri Jun 17 09:08:16 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 17 Jun 2016 09:08:16 +0000 Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation on ppc64 and sparc In-Reply-To: References: Message-ID: Hi Volker, thanks for doing this fix, I also have run into this issue before ... Looks good. Small nit: usually } else { are on one line. Best regards, Goetz. > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Volker Simonis > Sent: Donnerstag, 16. Juni 2016 16:54 > To: HotSpot Open Source Developers > Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work > together with -XX:+TieredCompilation on ppc64 and sparc > > Hi, > > can I please have a review and sponsor for the following small change > which fixes -XX:-UseOnStackReplacement to work together with > -XX:+TieredCompilation: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620/ > https://bugs.openjdk.java.net/browse/JDK-8159620 > > This is a long standing bug on SPARC and as the ppc64 template > interpreter was initially forked from the SPARC implementation, it > also manifests there. The problem is that in the case of tiered > compilation the interpreter unconditionally calls > InterpreterRuntime::frequency_counter_overflow if the back edge > counter overflows. This triggers an OSR compilation, even if OSR was > switched off with -XX:-UseOnStackReplacement. > > The fix is simple - just don't call > InterpreterRuntime::frequency_counter_overflow if OSR has been > switched off. > > Thank you and best regards, > Volker From volker.simonis at gmail.com Fri Jun 17 09:22:44 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Jun 2016 11:22:44 +0200 Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation on ppc64 and sparc In-Reply-To: References: Message-ID: Hi Goetz, thanks for the review. You're right, I've fixed the "else": http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v1/ Regards, Volker On Fri, Jun 17, 2016 at 11:08 AM, Lindenmaier, Goetz wrote: > Hi Volker, > > thanks for doing this fix, I also have run into this issue before ... > Looks good. > > Small nit: usually > } > else { > are on one line. > > Best regards, > Goetz. > >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >> Behalf Of Volker Simonis >> Sent: Donnerstag, 16. Juni 2016 16:54 >> To: HotSpot Open Source Developers >> Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work >> together with -XX:+TieredCompilation on ppc64 and sparc >> >> Hi, >> >> can I please have a review and sponsor for the following small change >> which fixes -XX:-UseOnStackReplacement to work together with >> -XX:+TieredCompilation: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620/ >> https://bugs.openjdk.java.net/browse/JDK-8159620 >> >> This is a long standing bug on SPARC and as the ppc64 template >> interpreter was initially forked from the SPARC implementation, it >> also manifests there. The problem is that in the case of tiered >> compilation the interpreter unconditionally calls >> InterpreterRuntime::frequency_counter_overflow if the back edge >> counter overflows. This triggers an OSR compilation, even if OSR was >> switched off with -XX:-UseOnStackReplacement. >> >> The fix is simple - just don't call >> InterpreterRuntime::frequency_counter_overflow if OSR has been >> switched off. >> >> Thank you and best regards, >> Volker From igor.ignatyev at oracle.com Fri Jun 17 09:48:55 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 17 Jun 2016 12:48:55 +0300 Subject: CFV: New hotspot Group Member: Tobias Hartmann In-Reply-To: <57635B85.4070700@oracle.com> References: <57635B85.4070700@oracle.com> Message-ID: <6E9EC0EF-867A-4BE8-B2DE-8D368D9B1B28@oracle.com> Vote: yes ? Igor > On Jun 17, 2016, at 5:08 AM, Vladimir Kozlov wrote: > > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to Membership in the hotspot Group. From igor.ignatyev at oracle.com Fri Jun 17 09:49:56 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 17 Jun 2016 12:49:56 +0300 Subject: CFV: New hotspot Group Member: Zoltan Majo In-Reply-To: <576358F7.7050409@oracle.com> References: <576358F7.7050409@oracle.com> Message-ID: Vote: yes ? Igor > On Jun 17, 2016, at 4:57 AM, Vladimir Kozlov wrote: > > I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to Membership in the hotspot Group. From vladimir.x.ivanov at oracle.com Fri Jun 17 11:13:20 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 17 Jun 2016 14:13:20 +0300 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> <57561996.4000501@oracle.com> <951844EF-D517-4BF5-861A-81769EA1C306@oracle.com> Message-ID: Looks good. Best regards, Vladimir Ivanov On 6/14/16 3:12 AM, Paul Sandoz wrote: > Hi, > > Here is an updated webrev. > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ > > Changes > > - the Unsafe.getAndAdd for float/double operate in the bit-domain. > > - documentation added to the factory methods: > > 1221 *

> 1222 * If the field type is {@code float} or {@code double} then numeric > 1223 * and atomic update access modes compare values using their bitwise > 1224 * representation (see {@link Float#floatToRawIntBits} and > 1225 * {@link Double#doubleToRawLongBits}, respectively). > 1226 *

> 1227 * @apiNote > 1228 * Bitwise comparison of {@code float} values or {@code double} values, > 1229 * as performed by the numeric and atomic update access modes, differ > 1230 * from the primitive {@code ==} operator and the {@link Float#equals} > 1231 * and {@link Double#equals} methods, notably with respect to > 1232 * {@code NaN}. There are many possible NaN values that are considered > 1233 * to be {@code NaN} in Java, although no IEEE 754 floating-point > 1234 * operation provided by Java can distinguish between them. As such > 1235 * care should be taken when performing a compare and set or a compare > 1236 * and exchange operation with NaN values since the operation may > 1237 * unexpectedly fail. Failure can occur if the expected or witness > 1238 * value is a NaN value and it is transformed (perhaps in a platform > 1239 * specific manner) into another NaN value, and thus has a different > 1240 * bitwise representation (see {@link Float#intBitsToFloat} or > 1241 * Double#longBitsToDouble for more details). > > (I also updated the documentation on array/ByteBuffer view methods but did not bother with the api note) > > Paul. > >> On 10 Jun 2016, at 15:39, Paul Sandoz wrote: >> >> Hi Joe, >> >> It?s my turn to catch up on email? >> >> >>> On 6 Jun 2016, at 17:47, Joseph D. Darcy wrote: >>> >>> Hello, >>> >>> Catching up on email, there are several different notions on floating-point equality one might want to use. [1] >>> >>> One notion is the built-in "==" operator on float and double. This has the wrinkle of not defining an equivalence relation because of NaN values (not reflexive) and signed zeros (distinguishable values compare as equal). >>> >>> When I write floating-point tests, I'll use a notion of equality close to >>> >>> Float.compare(x, y) == 0 >>> >>> which means all NaN values are treated as the same and Float.compare(NaN, NaN) == 0 is true. This also distinguishes the signed zeros from each other. >>> >>> So comparing based on the non-raw bitwise conversion can give resonable semantics, at the cost of not preserving any payload stored in the NaN significand. >>> >> >> And potentially a performance hit too [*]. >> >> Pedantically since (NaN == NaN) is false, one could argue that it should not possible to CAS with an expected NaN value and/or a witness NaN value. Such behaviour might be considered BaNaNas :-) (sorry). I don?t think we can or should enforce that, but we should strongly advise against it and mention the pitfalls, and i will need to specify that the atomic ops perform bit-wise equality with suitable ?as if? text. >> >> Paul. >> >> [*] For example, the double[] accepting Arrays.equals method used to compare each element as: >> >> 2762 for (int i=0; i> 2763 if (Double.doubleToLongBits(a[i])!=Double.doubleToLongBits(a2[i])) >> 2764 return false; >> >> In the interim of my adding vectorized mismatch support i changed that to: >> >> 3057 for (int i=0; i> 3058 double v1 = a[i], v2 = a2[i]; >> 3059 if (Double.doubleToRawLongBits(v1) != Double.doubleToRawLongBits(v2)) >> 3060 if (!Double.isNaN(v1) || !Double.isNaN(v2)) >> 3061 return false; >> 3062 } >> >> Which boosted the performance similar to that of comparing long[] (when no NaNs are present). >> >> >>> HTH, >>> >>> -Joe >>> >>> [1] "Notions of Floating-Point Equality ," https://blogs.oracle.com/darcy/entry/notions_of_floating_point_equality >>> >>> On 6/2/2016 1:34 AM, Paul Sandoz wrote: >>>>> On 2 Jun 2016, at 09:13, David Holmes wrote: >>>>> >>>>> On 2/06/2016 1:24 AM, Paul Sandoz wrote: >>>>>> (Please note this work is or will be covered with FC exception) >>>>>> >>>>>> Hi, >>>>>> >>>>>> Please review the VarHandles/Unsafe support for atomic ops on double/float fields/arrays. >>>>> I think this is misguided. If the user wants CAS for float/double they can do the conversion to int/long in a context where they know that conversion makes sense and where they can deal with NaNs appropriately. >>>>> >>>> I would still like to support some clearly defined default behaviour if at all possible, since this is not easy to get right so we can add some value here. The user can use int/long if that behaviour is not suitable. >>>> >>>> >>>>> At a minimum the fact this deals with raw bit patterns not semantic values needs to be exposed somehow. ie the handling of NaN needs to be explicit. >>>>> >>>> Yes, it?s multiple NaN values that collapse to a single NaN value. >>>> >>>> It would be good if our resident floating point expert Mr. Joe Darcy could chime in this respect. >>>> >>>> On Float.intBitsToFloat: >>>> >>>> *

Note that this method may not be able to return a >>>> * {@code float} NaN with exactly same bit pattern as the >>>> * {@code int} argument. IEEE 754 distinguishes between two >>>> * kinds of NaNs, quiet NaNs and signaling NaNs. The >>>> * differences between the two kinds of NaN are generally not >>>> * visible in Java. Arithmetic operations on signaling NaNs turn >>>> * them into quiet NaNs with a different, but often similar, bit >>>> * pattern. However, on some processors merely copying a >>>> * signaling NaN also performs that conversion. In particular, >>>> * copying a signaling NaN to return it to the calling method may >>>> * perform this conversion. So {@code intBitsToFloat} may >>>> * not be able to return a {@code float} with a signaling NaN >>>> * bit pattern. Consequently, for some {@code int} values, >>>> * {@code floatToRawIntBits(intBitsToFloat(start))} may >>>> * not equal {@code start}. Moreover, which >>>> * particular bit patterns represent signaling NaNs is platform >>>> * dependent; although all NaN bit patterns, quiet or signaling, >>>> * must be in the NaN range identified above. >>>> >>>> >>>> >>>> I am concerned that the CAS loops could in some cases loop without termination: >>>> >>>> @ForceInline >>>> public final float getAndAddFloat(Object o, long offset, float delta) { >>>> float v; >>>> do { >>>> v = getFloatVolatile(o, offset); >>>> } while (!weakCompareAndSwapFloatVolatile(o, offset, v, v + delta)); >>>> return v; >>>> } >>>> >>>> >>>> I think this should be: >>>> >>>> @ForceInline >>>> public final float getAndAddFloat(Object o, long offset, float delta) { >>>> int expectedBits; >>>> float v; >>>> do { >>>> expectedBits = getIntVolatile(o, offset); >>>> v = Float.intBitsToFloat(bits); // May not preserve a NaN value with the same bit pattern as expectedBits >>>> } while (!weakCompareAndSwapIntVolatile(o, offset, expectedBits, Float.floatToRawIntBits(v + delta))); >>>> return v; >>>> } >>>> >>>> and likewise for the atomic get-and-set methods. >>>> >>>> Paul. >>>> >>>>> David >>>>> ----- >>>>> >>>>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ >>>>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ >>>>>> >>>>>> These patches are based on those of for sub-word CAS >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8157726 >>>>>> http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/ >>>>>> http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/ >>>>>> >>>>>> And the two patches combined expand the support of fields/arrays. >>>>>> >>>>>> >>>>>> New float/double CAS methods are added to Unsafe that defer to int/long equivalents. Then the other atomic methods are built from weak CAS loops. >>>>>> >>>>>> No changes are required to HotSpot, but changes are required to the Unsafe tests in the hotspot repository. >>>>>> >>>>>> In general the changes to VHs and tests are minimal since it is triggered from changes to the generating scripts that now include float/double into the CAS category. >>>>>> >>>>>> There are some minor specification changes and a CCC has been initiated. >>>>>> >>>>>> JPRT tests results show no relevant failures for hotspot and core test sets. >>>>>> >>>>>> Thanks, >>>>>> Paul. >>>>>> >>> >> > From BLebeda at luxoft.com Fri Jun 17 12:42:55 2016 From: BLebeda at luxoft.com (Lebeda, Borys) Date: Fri, 17 Jun 2016 12:42:55 +0000 Subject: Exception on using hotspot compiler Message-ID: <6AE91074EA3C3E49BD0F843608814648BB3520CB@oro-mbox-02.luxoft.com> Hello everyone, We are running a tomcat 6 on server with Java 8 on ARM device: root at phyFLEX-i:~ uname -a Linux phyFLEX-i.MX6 3.0.43-tpcom_run2-PD13.2.4 #1 SMP PREEMPT Fri Jun 10 11:55:37 CEST 2016 armv7l GNU/Linux root at phyFLEX-i:/usr/tomcat/lib /usr/java/ejre1.8.0_65/bin/java -cp catalina.jar org.apache.catalina.util.ServerInfo Server version: Apache Tomcat/6.0.36 Server built: Oct 16 2012 09:59:09 Server number: 6.0.36.0 OS Name: Linux OS Version: 3.0.43-tpcom_run2-PD13.2.4 Architecture: arm JVM Version: 1.8.0_65-b17 JVM Vendor: Oracle Corporation root at phyFLEX-i:~ /usr/java/ejre1.8.0_65/bin/java -version java version "1.8.0_65" Java(TM) SE Embedded Runtime Environment (build 1.8.0_65-b17, headless) Java HotSpot(TM) Embedded Client VM (build 25.65-b01, mixed mode) During work of the application there are bunch of error constantly appear in the dmesg log: unhandled page fault and undefined instructions. Yet the application on tomcat works correctly. With _JAVA_OPTIONS -Xint there is no exception at all. With _JAVA_OPTIONS -Xcomp there are even more of them With _JAVA_OPTIONS -Xcomp -Xbatch returns the same result as -XComp Here is the sample of undefined instructions: [ 1929.280395] Code: e590c004 e15c0008 0a000000 eaf2da0f (e7f000f0) [ 1929.299220] java (2566): undefined instruction: pc=2b7504c0 [ 1929.304821] Code: e590c004 e15c0008 0a000000 eaf2adef (e7f000f0) [ 1929.328355] java (2566): undefined instruction: pc=2b7504c0 [ 1929.334510] Code: e590c004 e15c0008 0a000000 eaf2adef (e7f000f0) [ 1929.342659] java (2566): undefined instruction: pc=2b7412c0 [ 1929.348784] Code: e590c004 e15c0008 0a000000 eaf2ea6f (e7f000f0) [ 1929.355993] java (2566): undefined instruction: pc=2b7412c0 [ 1929.362188] Code: e590c004 e15c0008 0a000000 eaf2ea6f (e7f000f0) [ 1929.375402] java (2566): undefined instruction: pc=2b7412c0 [ 1929.381460] Code: e590c004 e15c0008 0a000000 eaf2ea6f (e7f000f0) [ 1929.388276] java (2566): undefined instruction: pc=2b7412c0 [ 1929.393876] Code: e590c004 e15c0008 0a000000 eaf2ea6f (e7f000f0) Here is the sample fot he unhandled page fault: [ 161.903357] java: unhandled page fault (11) at 0x00000004, code 0x017 [ 161.903378] pgd = 9b010000 [ 161.906101] [00000004] *pgd=2aeae831, *pte=00000000, *ppte=00000000 [ 161.912523] [ 161.914028] Pid: 1945, comm: java [ 161.918798] CPU: 0 Not tainted (3.0.43-tpcom_run2-PD13.2.4 #1) [ 161.925000] PC is at 0x2b401a28 [ 161.928203] LR is at 0x2b3f39b4 [ 161.931363] pc : [<2b401a28>] lr : [<2b3f39b4>] psr: 40000010 [ 161.931369] sp : 2b385074 ip : 2b2b6e6c fp : 2b385098 [ 161.942921] r10: 00017800 r9 : 32bf46d8 r8 : 2b3850a0 [ 161.948208] r7 : 32bf46b3 r6 : 2b2b9058 r5 : 32bf5988 r4 : 00000000 [ 161.954753] r3 : 70000001 r2 : 00000000 r1 : 00000007 r0 : 00000000 [ 161.961343] Flags: nZcv IRQs on FIQs on Mode USER_32 ISA ARM Segment user [ 161.968629] Control: 10c53c7d Table: 2b01004a DAC: 00000015 [ 161.974415] [<80356cb8>] (show_regs+0x0/0x50) from [<80362538>] (__do_user_fault+0x9c/0xa8) [ 161.982860] r4:9b0607c0 r3:8004d4e8 [ 161.989245] [<8036249c>] (__do_user_fault+0x0/0xa8) from [<80362774>] (do_page_fault+0x230/0x3a8) [ 161.998181] r7:00000004 r6:9b0607c0 r5:9a7289c0 r4:9b083fb0 [ 162.003964] [<80362544>] (do_page_fault+0x0/0x3a8) from [<8034f4b8>] (do_DataAbort+0x3c/0x248) [ 162.012656] [<8034f47c>] (do_DataAbort+0x0/0x248) from [<80355a08>] (ret_from_exception+0x0/0x40) [ 162.021591] Exception stack(0x9b083fb0 to 0x9b083ff8) [ 162.026662] 3fa0: 00000000 00000007 00000000 70000001 [ 162.034909] 3fc0: 00000000 32bf5988 2b2b9058 32bf46b3 2b3850a0 32bf46d8 00017800 2b385098 [ 162.043288] 3fe0: 2b2b6e6c 2b385074 2b3f39b4 2b401a28 40000010 ffffffff There are less exceptions when tomcat is run without application. There is no exception if I am running Hello World application (which mean System.out should not get the blame. Is it possible to set up some runtime globals http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/cf1faa9100dd/src/share/vm/runtime/globals.hpp to avoid or mitigate such crashes? How can the instruction that leads to exception on hotspot be retrieved? Kind regards, Borys Lebeda Luxoft Ukraine ________________________________ This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you. From ChrisPhi at LGonQn.Org Fri Jun 17 14:05:13 2016 From: ChrisPhi at LGonQn.Org (Chris Phillips @ T O) Date: Fri, 17 Jun 2016 10:05:13 -0400 Subject: CFV: New hotspot Group Member: Zoltan Majo In-Reply-To: <576358F7.7050409@oracle.com> References: <576358F7.7050409@oracle.com> Message-ID: <57640399.2060700@LGonQn.Org> Vote: yes Chris From ChrisPhi at LGonQn.Org Fri Jun 17 14:06:23 2016 From: ChrisPhi at LGonQn.Org (Chris Phillips @ T O) Date: Fri, 17 Jun 2016 10:06:23 -0400 Subject: CFV: New hotspot Group Member: Tobias Hartmann In-Reply-To: <57635B85.4070700@oracle.com> References: <57635B85.4070700@oracle.com> Message-ID: <576403DF.1040409@LGonQn.Org> Vote: yes Chris From erik.helin at oracle.com Fri Jun 17 15:31:22 2016 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 17 Jun 2016 17:31:22 +0200 Subject: RFR: 8159370: Add FlagGuard for easier modification of flags for unit tests In-Reply-To: <2C12A9D7-3E82-461B-B0BD-13B0A83276C2@oracle.com> References: <20160614105857.GV26799@ehelin.jrpg.bea.com> <2C12A9D7-3E82-461B-B0BD-13B0A83276C2@oracle.com> Message-ID: <20160617153121.GB22330@ehelin.jrpg.bea.com> On 2016-06-14, Kim Barrett wrote: > > On Jun 14, 2016, at 6:58 AM, Erik Helin wrote: > > > > Hi all, > > > > this patch adds a small utility class that makes it easier for TEST_VM > > unit tests to safely modify flags. The class FlagGuard will store the > > value of the flag in its constructor and then restore the flag in its > > destructor. This is similar IntFlagSetting, UIntFlagSetting etc, but the > > FlagGuard differs in two aspects: > > - it does not set a new value > > - it is "untyped", you can use FlagGuard for flags with any type > > Is there a reason why this is being added to the unit test framework, > rather than being a generalization of the existing [U]IntFlagSetting > &etc and placed nearby? That?s where I would expect to find it. So my reasoning was that the FlagGuard was pretty slow, since it used Flag::find_flag, so I didn't want to encourage anyone to use it in production. Me and Per hacked together a new implementation of FlagGuard, which uses templates and memcpy instead of Flag::find_flag: http://cr.openjdk.java.net/~ehelin/8159370/00/ What do you think? I also moved FlagGuard to runtime/globals.hpp and added some tests. I don't want to update [U]IntFlagSetting since they also take a new value as parameter, FlagGuard just restores the value at the end of the scope. Thanks, Erik > > I have also added a macro, GUARD_FLAG, to make it more convenient to > > guard a flag. A test might now look like: > > > > TEST_VM(G1Policy, test_calc_max_old_cset_length) { > > GUARD_FLAG(MaxGCPauseMillis); > > GUARD_FLAG(ParallelGCThreads); > > > > MaxGCPauseMillis = 500; > > ParallelGCThreads = 10; > > ASSERT_EQ(10u, G1Policy::calc_max_old_cset_length()); > > > > MaxGCPauseMillis = 50; > > ParallelGCThreads = 1; > > ASSERT_EQ(2u, G1Policy::calc_max_old_cset_length()); > > > > // All guarded flags are restored here > > } > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8159370 > > > > Webrev: > > http://cr.openjdk.java.net/~ehelin/8159370/00/ > > > > Testing: > > - JPRT > > > > Thanks, > > Erik > > From vladimir.kozlov at oracle.com Fri Jun 17 20:53:37 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Jun 2016 13:53:37 -0700 Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation on ppc64 and sparc In-Reply-To: References: Message-ID: <27dde86d-f7b3-3093-e500-cd3c9156811f@oracle.com> Looks good. Thanks, Vladimir On 6/17/16 2:22 AM, Volker Simonis wrote: > Hi Goetz, > > thanks for the review. > You're right, I've fixed the "else": > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v1/ > > Regards, > Volker > > On Fri, Jun 17, 2016 at 11:08 AM, Lindenmaier, Goetz > wrote: >> Hi Volker, >> >> thanks for doing this fix, I also have run into this issue before ... >> Looks good. >> >> Small nit: usually >> } >> else { >> are on one line. >> >> Best regards, >> Goetz. >> >>> -----Original Message----- >>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>> Behalf Of Volker Simonis >>> Sent: Donnerstag, 16. Juni 2016 16:54 >>> To: HotSpot Open Source Developers >>> Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work >>> together with -XX:+TieredCompilation on ppc64 and sparc >>> >>> Hi, >>> >>> can I please have a review and sponsor for the following small change >>> which fixes -XX:-UseOnStackReplacement to work together with >>> -XX:+TieredCompilation: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620/ >>> https://bugs.openjdk.java.net/browse/JDK-8159620 >>> >>> This is a long standing bug on SPARC and as the ppc64 template >>> interpreter was initially forked from the SPARC implementation, it >>> also manifests there. The problem is that in the case of tiered >>> compilation the interpreter unconditionally calls >>> InterpreterRuntime::frequency_counter_overflow if the back edge >>> counter overflows. This triggers an OSR compilation, even if OSR was >>> switched off with -XX:-UseOnStackReplacement. >>> >>> The fix is simple - just don't call >>> InterpreterRuntime::frequency_counter_overflow if OSR has been >>> switched off. >>> >>> Thank you and best regards, >>> Volker From kim.barrett at oracle.com Fri Jun 17 21:37:54 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 17 Jun 2016 17:37:54 -0400 Subject: RFR: 8159370: Add FlagGuard for easier modification of flags for unit tests In-Reply-To: <20160617153121.GB22330@ehelin.jrpg.bea.com> References: <20160614105857.GV26799@ehelin.jrpg.bea.com> <2C12A9D7-3E82-461B-B0BD-13B0A83276C2@oracle.com> <20160617153121.GB22330@ehelin.jrpg.bea.com> Message-ID: > On Jun 17, 2016, at 11:31 AM, Erik Helin wrote: > > On 2016-06-14, Kim Barrett wrote: >>> On Jun 14, 2016, at 6:58 AM, Erik Helin wrote: >>> >>> Hi all, >>> >>> this patch adds a small utility class that makes it easier for TEST_VM >>> unit tests to safely modify flags. The class FlagGuard will store the >>> value of the flag in its constructor and then restore the flag in its >>> destructor. This is similar IntFlagSetting, UIntFlagSetting etc, but the >>> FlagGuard differs in two aspects: >>> - it does not set a new value >>> - it is "untyped", you can use FlagGuard for flags with any type >> >> Is there a reason why this is being added to the unit test framework, >> rather than being a generalization of the existing [U]IntFlagSetting >> &etc and placed nearby? That?s where I would expect to find it. > > So my reasoning was that the FlagGuard was pretty slow, since it used > Flag::find_flag, so I didn't want to encourage anyone to use it in > production. Me and Per hacked together a new implementation of > FlagGuard, which uses templates and memcpy instead of Flag::find_flag: > > http://cr.openjdk.java.net/~ehelin/8159370/00/ That's the old URL; the correct URL ends in /01/ > What do you think? I also moved FlagGuard to runtime/globals.hpp and > added some tests. I don't want to update [U]IntFlagSetting since > they also take a new value as parameter, FlagGuard just restores the > value at the end of the scope. ------------------------------------------------------------------------------ For reference, the technique used here is based on C++2003 3.9/2. The basic idea seems sound, though I have quibbles about details. I'm fine with this interface and leaving [U]IntFlagSetting alone. Given that we have a fixed set of types to deal with, I suspect there is some tag dispatching / sizeof trick that could eliminate the memcpy and use the actual option type, but it hardly seems worth the trouble. There are much cleaner solutions with C++11... ------------------------------------------------------------------------------ src/share/vm/runtime/globals.hpp 469 uint8_t _value[SIZE]; Element type should be char or unsigned char. uint8_t is not necessarily either of those, though it likely is on any platform we support. ------------------------------------------------------------------------------ src/share/vm/runtime/globals.hpp 475 void* operator new(size_t size) throw() { 476 return 0; 477 } 478 479 void* operator new [](size_t size) throw() { 480 return 0; 481 } Leave off the definitions, further ensuring they can't be used, and not being misleading about them. ------------------------------------------------------------------------------ src/share/vm/runtime/globals.hpp 470 const uintptr_t _addr; 484 FlagGuard(uintptr_t flag_addr) : _addr(flag_addr) { 493 #define FLAG_GUARD(f) FlagGuard f ## _guard((uintptr_t) &f) Why the address conversion to uintptr_t? Why not just use const void*, and eliminate lots of casts... ------------------------------------------------------------------------------ src/share/vm/runtime/globals.hpp 485 memcpy((void*) _value, (const void*) _addr, SIZE); 489 memcpy((void*) _addr, (const void*) _value, SIZE); Unnecessary casts of _value. ------------------------------------------------------------------------------ test/native/runtime/test_globals.cpp This file only contains tests for FlagGuard. I don't know what conventions we're adopting for native tests, and what restrictions the build system might be imposing on us. It seems to me though that this might be better called test_FlagGuard, and other native tests of facilities in globals.hpp would be in other file(s). ------------------------------------------------------------------------------ test/native/runtime/test_globals.cpp I think each test should also contain a check that the flag is of the expected type, e.g. at the beginning something like ASSERT(Flag::find_flag("AlwaysActAsServerClassMachine")->is_bool()); Otherwise, a change in the type of an option could accidently result in an untested case here. ------------------------------------------------------------------------------ test/native/runtime/test_globals.cpp The code here is extreme boilerplate. Consider a macro to reduce that? ------------------------------------------------------------------------------ test/native/runtime/test_globals.cpp 102 const char* original_value = PerfDataSaveFile; For consistency, I think that should be ccstr rather than const char*. ------------------------------------------------------------------------------ From david.holmes at oracle.com Mon Jun 20 03:58:06 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 20 Jun 2016 13:58:06 +1000 Subject: Exception on using hotspot compiler In-Reply-To: <6AE91074EA3C3E49BD0F843608814648BB3520CB@oro-mbox-02.luxoft.com> References: <6AE91074EA3C3E49BD0F843608814648BB3520CB@oro-mbox-02.luxoft.com> Message-ID: Hi, This is an issue with the Oracle SE Embedded JRE for ARM , which is not part of OpenJDK and so can not be discussed on these mailing lists. That said, if the JVM was hitting an illegal instruction then there should be a hs_err_pidXXX.log file created and potentially a core dump. Regards, David On 17/06/2016 10:42 PM, Lebeda, Borys wrote: > Hello everyone, > > We are running a tomcat 6 on server with Java 8 on ARM device: > > root at phyFLEX-i:~ uname -a > Linux phyFLEX-i.MX6 3.0.43-tpcom_run2-PD13.2.4 #1 SMP PREEMPT Fri Jun 10 11:55:37 CEST 2016 armv7l GNU/Linux > > root at phyFLEX-i:/usr/tomcat/lib /usr/java/ejre1.8.0_65/bin/java -cp catalina.jar org.apache.catalina.util.ServerInfo > Server version: Apache Tomcat/6.0.36 > Server built: Oct 16 2012 09:59:09 > Server number: 6.0.36.0 > OS Name: Linux > OS Version: 3.0.43-tpcom_run2-PD13.2.4 > Architecture: arm > JVM Version: 1.8.0_65-b17 > JVM Vendor: Oracle Corporation > > root at phyFLEX-i:~ /usr/java/ejre1.8.0_65/bin/java -version > java version "1.8.0_65" > Java(TM) SE Embedded Runtime Environment (build 1.8.0_65-b17, headless) > Java HotSpot(TM) Embedded Client VM (build 25.65-b01, mixed mode) > > During work of the application there are bunch of error constantly appear in the dmesg log: unhandled page fault and undefined instructions. Yet the application on tomcat works correctly. > > With _JAVA_OPTIONS -Xint there is no exception at all. > With _JAVA_OPTIONS -Xcomp there are even more of them > With _JAVA_OPTIONS -Xcomp -Xbatch returns the same result as -XComp > > Here is the sample of undefined instructions: > [ 1929.280395] Code: e590c004 e15c0008 0a000000 eaf2da0f (e7f000f0) > [ 1929.299220] java (2566): undefined instruction: pc=2b7504c0 > [ 1929.304821] Code: e590c004 e15c0008 0a000000 eaf2adef (e7f000f0) > [ 1929.328355] java (2566): undefined instruction: pc=2b7504c0 > [ 1929.334510] Code: e590c004 e15c0008 0a000000 eaf2adef (e7f000f0) > [ 1929.342659] java (2566): undefined instruction: pc=2b7412c0 > [ 1929.348784] Code: e590c004 e15c0008 0a000000 eaf2ea6f (e7f000f0) > [ 1929.355993] java (2566): undefined instruction: pc=2b7412c0 > [ 1929.362188] Code: e590c004 e15c0008 0a000000 eaf2ea6f (e7f000f0) > [ 1929.375402] java (2566): undefined instruction: pc=2b7412c0 > [ 1929.381460] Code: e590c004 e15c0008 0a000000 eaf2ea6f (e7f000f0) > [ 1929.388276] java (2566): undefined instruction: pc=2b7412c0 > [ 1929.393876] Code: e590c004 e15c0008 0a000000 eaf2ea6f (e7f000f0) > > Here is the sample fot he unhandled page fault: > [ 161.903357] java: unhandled page fault (11) at 0x00000004, code 0x017 > [ 161.903378] pgd = 9b010000 > [ 161.906101] [00000004] *pgd=2aeae831, *pte=00000000, *ppte=00000000 > [ 161.912523] > [ 161.914028] Pid: 1945, comm: java > [ 161.918798] CPU: 0 Not tainted (3.0.43-tpcom_run2-PD13.2.4 #1) > [ 161.925000] PC is at 0x2b401a28 > [ 161.928203] LR is at 0x2b3f39b4 > [ 161.931363] pc : [<2b401a28>] lr : [<2b3f39b4>] psr: 40000010 > [ 161.931369] sp : 2b385074 ip : 2b2b6e6c fp : 2b385098 > [ 161.942921] r10: 00017800 r9 : 32bf46d8 r8 : 2b3850a0 > [ 161.948208] r7 : 32bf46b3 r6 : 2b2b9058 r5 : 32bf5988 r4 : 00000000 > [ 161.954753] r3 : 70000001 r2 : 00000000 r1 : 00000007 r0 : 00000000 > [ 161.961343] Flags: nZcv IRQs on FIQs on Mode USER_32 ISA ARM Segment user > [ 161.968629] Control: 10c53c7d Table: 2b01004a DAC: 00000015 > [ 161.974415] [<80356cb8>] (show_regs+0x0/0x50) from [<80362538>] (__do_user_fault+0x9c/0xa8) > [ 161.982860] r4:9b0607c0 r3:8004d4e8 > [ 161.989245] [<8036249c>] (__do_user_fault+0x0/0xa8) from [<80362774>] (do_page_fault+0x230/0x3a8) > [ 161.998181] r7:00000004 r6:9b0607c0 r5:9a7289c0 r4:9b083fb0 > [ 162.003964] [<80362544>] (do_page_fault+0x0/0x3a8) from [<8034f4b8>] (do_DataAbort+0x3c/0x248) > [ 162.012656] [<8034f47c>] (do_DataAbort+0x0/0x248) from [<80355a08>] (ret_from_exception+0x0/0x40) > [ 162.021591] Exception stack(0x9b083fb0 to 0x9b083ff8) > [ 162.026662] 3fa0: 00000000 00000007 00000000 70000001 > [ 162.034909] 3fc0: 00000000 32bf5988 2b2b9058 32bf46b3 2b3850a0 32bf46d8 00017800 2b385098 > [ 162.043288] 3fe0: 2b2b6e6c 2b385074 2b3f39b4 2b401a28 40000010 ffffffff > > There are less exceptions when tomcat is run without application. > > There is no exception if I am running Hello World application (which mean System.out should not get the blame. > > Is it possible to set up some runtime globals http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/cf1faa9100dd/src/share/vm/runtime/globals.hpp to avoid or mitigate such crashes? > > How can the instruction that leads to exception on hotspot be retrieved? > > > > Kind regards, > Borys Lebeda > Luxoft Ukraine > > > ________________________________ > > This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you. > From volker.simonis at gmail.com Mon Jun 20 08:16:32 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 20 Jun 2016 10:16:32 +0200 Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation on ppc64 and sparc In-Reply-To: <27dde86d-f7b3-3093-e500-cd3c9156811f@oracle.com> References: <27dde86d-f7b3-3093-e500-cd3c9156811f@oracle.com> Message-ID: Thanks Vladimir! .. I still need a sponsor :( Regards, Volker On Fri, Jun 17, 2016 at 10:53 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > > On 6/17/16 2:22 AM, Volker Simonis wrote: >> >> Hi Goetz, >> >> thanks for the review. >> You're right, I've fixed the "else": >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v1/ >> >> Regards, >> Volker >> >> On Fri, Jun 17, 2016 at 11:08 AM, Lindenmaier, Goetz >> wrote: >>> >>> Hi Volker, >>> >>> thanks for doing this fix, I also have run into this issue before ... >>> Looks good. >>> >>> Small nit: usually >>> } >>> else { >>> are on one line. >>> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>> Behalf Of Volker Simonis >>>> Sent: Donnerstag, 16. Juni 2016 16:54 >>>> To: HotSpot Open Source Developers >>>> Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work >>>> together with -XX:+TieredCompilation on ppc64 and sparc >>>> >>>> Hi, >>>> >>>> can I please have a review and sponsor for the following small change >>>> which fixes -XX:-UseOnStackReplacement to work together with >>>> -XX:+TieredCompilation: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620/ >>>> https://bugs.openjdk.java.net/browse/JDK-8159620 >>>> >>>> This is a long standing bug on SPARC and as the ppc64 template >>>> interpreter was initially forked from the SPARC implementation, it >>>> also manifests there. The problem is that in the case of tiered >>>> compilation the interpreter unconditionally calls >>>> InterpreterRuntime::frequency_counter_overflow if the back edge >>>> counter overflows. This triggers an OSR compilation, even if OSR was >>>> switched off with -XX:-UseOnStackReplacement. >>>> >>>> The fix is simple - just don't call >>>> InterpreterRuntime::frequency_counter_overflow if OSR has been >>>> switched off. >>>> >>>> Thank you and best regards, >>>> Volker From tobias.hartmann at oracle.com Mon Jun 20 08:46:32 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 20 Jun 2016 10:46:32 +0200 Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation on ppc64 and sparc In-Reply-To: References: <27dde86d-f7b3-3093-e500-cd3c9156811f@oracle.com> Message-ID: <5767AD68.8090500@oracle.com> Hi Volker, you fix looks good to me! I can do the sponsoring, please just send me a changeset. Best regards, Tobias On 20.06.2016 10:16, Volker Simonis wrote: > Thanks Vladimir! > > .. I still need a sponsor :( > > Regards, > Volker > > > On Fri, Jun 17, 2016 at 10:53 PM, Vladimir Kozlov > wrote: >> Looks good. >> >> Thanks, >> Vladimir >> >> >> On 6/17/16 2:22 AM, Volker Simonis wrote: >>> >>> Hi Goetz, >>> >>> thanks for the review. >>> You're right, I've fixed the "else": >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v1/ >>> >>> Regards, >>> Volker >>> >>> On Fri, Jun 17, 2016 at 11:08 AM, Lindenmaier, Goetz >>> wrote: >>>> >>>> Hi Volker, >>>> >>>> thanks for doing this fix, I also have run into this issue before ... >>>> Looks good. >>>> >>>> Small nit: usually >>>> } >>>> else { >>>> are on one line. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>>> -----Original Message----- >>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>>> Behalf Of Volker Simonis >>>>> Sent: Donnerstag, 16. Juni 2016 16:54 >>>>> To: HotSpot Open Source Developers >>>>> Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work >>>>> together with -XX:+TieredCompilation on ppc64 and sparc >>>>> >>>>> Hi, >>>>> >>>>> can I please have a review and sponsor for the following small change >>>>> which fixes -XX:-UseOnStackReplacement to work together with >>>>> -XX:+TieredCompilation: >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8159620 >>>>> >>>>> This is a long standing bug on SPARC and as the ppc64 template >>>>> interpreter was initially forked from the SPARC implementation, it >>>>> also manifests there. The problem is that in the case of tiered >>>>> compilation the interpreter unconditionally calls >>>>> InterpreterRuntime::frequency_counter_overflow if the back edge >>>>> counter overflows. This triggers an OSR compilation, even if OSR was >>>>> switched off with -XX:-UseOnStackReplacement. >>>>> >>>>> The fix is simple - just don't call >>>>> InterpreterRuntime::frequency_counter_overflow if OSR has been >>>>> switched off. >>>>> >>>>> Thank you and best regards, >>>>> Volker From volker.simonis at gmail.com Mon Jun 20 08:52:50 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 20 Jun 2016 10:52:50 +0200 Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation on ppc64 and sparc In-Reply-To: <5767AD68.8090500@oracle.com> References: <27dde86d-f7b3-3093-e500-cd3c9156811f@oracle.com> <5767AD68.8090500@oracle.com> Message-ID: Hi Tobias, thanks for sponsoring! I've uploaded a new webrev with you and Vladimir as reviewers: http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v2/ You can find the changeset there: http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v2/hotspot.changeset Thanks, Volker On Mon, Jun 20, 2016 at 10:46 AM, Tobias Hartmann wrote: > Hi Volker, > > you fix looks good to me! I can do the sponsoring, please just send me a changeset. > > Best regards, > Tobias > > On 20.06.2016 10:16, Volker Simonis wrote: >> Thanks Vladimir! >> >> .. I still need a sponsor :( >> >> Regards, >> Volker >> >> >> On Fri, Jun 17, 2016 at 10:53 PM, Vladimir Kozlov >> wrote: >>> Looks good. >>> >>> Thanks, >>> Vladimir >>> >>> >>> On 6/17/16 2:22 AM, Volker Simonis wrote: >>>> >>>> Hi Goetz, >>>> >>>> thanks for the review. >>>> You're right, I've fixed the "else": >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v1/ >>>> >>>> Regards, >>>> Volker >>>> >>>> On Fri, Jun 17, 2016 at 11:08 AM, Lindenmaier, Goetz >>>> wrote: >>>>> >>>>> Hi Volker, >>>>> >>>>> thanks for doing this fix, I also have run into this issue before ... >>>>> Looks good. >>>>> >>>>> Small nit: usually >>>>> } >>>>> else { >>>>> are on one line. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>>> -----Original Message----- >>>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>>>> Behalf Of Volker Simonis >>>>>> Sent: Donnerstag, 16. Juni 2016 16:54 >>>>>> To: HotSpot Open Source Developers >>>>>> Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work >>>>>> together with -XX:+TieredCompilation on ppc64 and sparc >>>>>> >>>>>> Hi, >>>>>> >>>>>> can I please have a review and sponsor for the following small change >>>>>> which fixes -XX:-UseOnStackReplacement to work together with >>>>>> -XX:+TieredCompilation: >>>>>> >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8159620 >>>>>> >>>>>> This is a long standing bug on SPARC and as the ppc64 template >>>>>> interpreter was initially forked from the SPARC implementation, it >>>>>> also manifests there. The problem is that in the case of tiered >>>>>> compilation the interpreter unconditionally calls >>>>>> InterpreterRuntime::frequency_counter_overflow if the back edge >>>>>> counter overflows. This triggers an OSR compilation, even if OSR was >>>>>> switched off with -XX:-UseOnStackReplacement. >>>>>> >>>>>> The fix is simple - just don't call >>>>>> InterpreterRuntime::frequency_counter_overflow if OSR has been >>>>>> switched off. >>>>>> >>>>>> Thank you and best regards, >>>>>> Volker From tobias.hartmann at oracle.com Mon Jun 20 08:59:36 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 20 Jun 2016 10:59:36 +0200 Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation on ppc64 and sparc In-Reply-To: References: <27dde86d-f7b3-3093-e500-cd3c9156811f@oracle.com> <5767AD68.8090500@oracle.com> Message-ID: <5767B078.8030102@oracle.com> Hi Volker, On 20.06.2016 10:52, Volker Simonis wrote: > Hi Tobias, > > thanks for sponsoring! I've uploaded a new webrev with you and > Vladimir as reviewers: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v2/ > > You can find the changeset there: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v2/hotspot.changeset Thanks, I just noticed that the test has 26 * @bug 9999999 You can fix this in-place. I'll then run the required pre-integration testing (~24h) and push your change afterwards. Best regards, Tobias > > Thanks, > Volker > > > On Mon, Jun 20, 2016 at 10:46 AM, Tobias Hartmann > wrote: >> Hi Volker, >> >> you fix looks good to me! I can do the sponsoring, please just send me a changeset. >> >> Best regards, >> Tobias >> >> On 20.06.2016 10:16, Volker Simonis wrote: >>> Thanks Vladimir! >>> >>> .. I still need a sponsor :( >>> >>> Regards, >>> Volker >>> >>> >>> On Fri, Jun 17, 2016 at 10:53 PM, Vladimir Kozlov >>> wrote: >>>> Looks good. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>>> On 6/17/16 2:22 AM, Volker Simonis wrote: >>>>> >>>>> Hi Goetz, >>>>> >>>>> thanks for the review. >>>>> You're right, I've fixed the "else": >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v1/ >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> On Fri, Jun 17, 2016 at 11:08 AM, Lindenmaier, Goetz >>>>> wrote: >>>>>> >>>>>> Hi Volker, >>>>>> >>>>>> thanks for doing this fix, I also have run into this issue before ... >>>>>> Looks good. >>>>>> >>>>>> Small nit: usually >>>>>> } >>>>>> else { >>>>>> are on one line. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>>>>> Behalf Of Volker Simonis >>>>>>> Sent: Donnerstag, 16. Juni 2016 16:54 >>>>>>> To: HotSpot Open Source Developers >>>>>>> Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work >>>>>>> together with -XX:+TieredCompilation on ppc64 and sparc >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> can I please have a review and sponsor for the following small change >>>>>>> which fixes -XX:-UseOnStackReplacement to work together with >>>>>>> -XX:+TieredCompilation: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620/ >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8159620 >>>>>>> >>>>>>> This is a long standing bug on SPARC and as the ppc64 template >>>>>>> interpreter was initially forked from the SPARC implementation, it >>>>>>> also manifests there. The problem is that in the case of tiered >>>>>>> compilation the interpreter unconditionally calls >>>>>>> InterpreterRuntime::frequency_counter_overflow if the back edge >>>>>>> counter overflows. This triggers an OSR compilation, even if OSR was >>>>>>> switched off with -XX:-UseOnStackReplacement. >>>>>>> >>>>>>> The fix is simple - just don't call >>>>>>> InterpreterRuntime::frequency_counter_overflow if OSR has been >>>>>>> switched off. >>>>>>> >>>>>>> Thank you and best regards, >>>>>>> Volker From erik.helin at oracle.com Mon Jun 20 09:35:35 2016 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 20 Jun 2016 11:35:35 +0200 Subject: RFR: 8159364: Gtest unit tests does not support PCH In-Reply-To: <57601F29.7060903@oracle.com> References: <20160614095040.GS26799@ehelin.jrpg.bea.com> <57601F29.7060903@oracle.com> Message-ID: <20160620093535.GA11430@ehelin.jrpg.bea.com> On 2016-06-14, Erik Joelsson wrote: > Do you really need to exclude gTestLauncher.cpp from precompiled? That file > should be excluded from compilation already. No, you are right, I don't need to re-exclude gTestLauncher.cpp (verified by running JPRT). I will remove gTestLauncher.cpp from PRECOMPILED_HEADER_EXCLUDE before I push. > Otherwise looks good. Thanks, Erik > /Erik > > On 2016-06-14 02:50, Erik Helin wrote: > >Hi all, > > > >this patch adds support for pre-compiled headers (PCH) to the gtest unit > >tests. > > > >Bug: > >https://bugs.openjdk.java.net/browse/JDK-8159364 > > > >Webrev: > >http://cr.openjdk.java.net/~ehelin/8159364/00/ > > > >Testing: > >- JPRT > > > >Thanks, > >Erik > From joe.darcy at oracle.com Mon Jun 20 14:58:39 2016 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 20 Jun 2016 07:58:39 -0700 Subject: RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics In-Reply-To: References: <23FAF71F-F8B9-4AD6-9BF3-896795540788@oracle.com> <6ed640e8-f581-e81d-3e77-ef47405f9618@oracle.com> <57561996.4000501@oracle.com> <951844EF-D517-4BF5-861A-81769EA1C306@oracle.com> <8d668cf7-1f40-8310-117e-267cefe2ab5c@oracle.com> <575FC8D5.8050900@redhat.com> Message-ID: New spec sounds fine; thanks Paul, -Joe On 6/15/2016 8:54 PM, Paul Sandoz wrote: > Hi Joe, Andrew, > >> On 14 Jun 2016, at 02:05, Andrew Haley wrote: >> >> On 14/06/16 05:09, joe darcy wrote: >>> I suggest also pointing out that a bitwise comparison distinguishes -0.0 >>> from +0.0; they compare as == under the built-in operation. >> Indeed so, yes. This is particularly likely to bite people who have >> a zero created by, say, an algorithm which converges on zero with >> successive terms which alternate sign. Eww. >> > In a previously unpublished incarnation i did talk about -0.0/+0.0, then i dropped it... > > Here is an updated revision of the note: > > 1226 * @apiNote > 1227 * Bitwise comparison of {@code float} values or {@code double} values, > 1228 * as performed by the numeric and atomic update access modes, differ > 1229 * from the primitive {@code ==} operator and the {@link Float#equals} > 1230 * and {@link Double#equals} methods, specifically with respect to > 1231 * comparing NaN values or comparing {@code -0.0} with {@code +0.0}. > 1232 * Care should be taken when performing a compare and set or a compare > 1233 * and exchange operation with such values since the operation may > 1234 * unexpectedly fail. > 1235 * There are many possible NaN values that are considered to be > 1236 * {@code NaN} in Java, although no IEEE 754 floating-point operation > 1237 * provided by Java can distinguish between them. Operation failure can > 1238 * occur if the expected or witness value is a NaN value and it is > 1239 * transformed (perhaps in a platform specific manner) into another NaN > 1240 * value, and thus has a different bitwise representation (see > 1241 * {@link Float#intBitsToFloat} or {@link Double#longBitsToDouble} for more > 1242 * details). > 1243 * The values {@code -0.0} and {@code +0.0} have different bitwise > 1244 * representations but are considered equal when using the primitive > 1245 * {@code ==} operator. Operation failure can occur if, for example, a > 1246 * numeric algorithm computes an expected value to be say {@code -0.0} > 1247 * and previously computed the witness value to be say {@code +0.0}. > > Paul. From max.ockner at oracle.com Mon Jun 20 19:08:03 2016 From: max.ockner at oracle.com (Max Ockner) Date: Mon, 20 Jun 2016 15:08:03 -0400 Subject: RFR: 8038332: The trace event vm/class/load is not always being sent In-Reply-To: <95d4e379-2680-1e49-f972-831e4e1701ba@oracle.com> References: <5759AFCE.2080406@oracle.com> <575EF096.9020908@oracle.com> <95d4e379-2680-1e49-f972-831e4e1701ba@oracle.com> Message-ID: <57683F13.5070900@oracle.com> David, New webrev: http://cr.openjdk.java.net/~mockner/8038332.02/src/share/vm/classfile/systemDictionary.cpp.cdiff.html I have added the check you suggested before triggering the event: if (HAS_PENDING_EXCEPTION || k.is_null()) { return NULL; } Thanks, Max On 6/13/2016 6:40 PM, David Holmes wrote: > Hi Max, > > On 14/06/2016 3:42 AM, Max Ockner wrote: >> Jiangli, >> Thanks for looking. I didn't see anything that looked like it might >> produce duplicate events. However, I did see some additional places >> where it looks like no event is fire. >> >> Can anyone point me to the event specs? > > I'm not sure there is any spec for this. Even JFR doesn't seem to > document individual events and when they are triggered. > > Your change does not look right however as you are posting the > classload event regardless of the exception state. If you look at > SystemDictionary::resolve_instance_class_or_null, it only posts after > checking the load was successful: > > 892 if (HAS_PENDING_EXCEPTION || k.is_null()) { > 893 return NULL; > 894 } > 895 > 896 post_class_load_event(class_load_start_time, k, class_loader); > > Similarly, SystemDictionary::parse_stream, has various CHECK macros > that will cause a return on exception, prior to getting to the point > of posting the load event. So you also need to add a check for a > pending exception and that k is not null, I think, before posting the > event. > I have added this check. > BTW I would have expected to see trace-events generated at > approximately the same locations as the corresponding JVMTI events. > That does not seem to be the case which seems very strange to me. The > notion of "loading a class" seems to be spread across far too many > functions to me. > > Thanks, > David > >> Thanks, >> Max >> >> On 6/9/2016 4:39 PM, Jiangli Zhou wrote: >>> Hi Max, >>> >>> Looks ok. The only possible issue is more than one event might be sent >>> in some of the call paths. But my quick search didn?t find any of such >>> case. >>> >>> Thanks, >>> Jiangli >>> >>>> On Jun 9, 2016, at 11:05 AM, Max Ockner wrote: >>>> >>>> Hello, >>>> >>>> Please review this small fix which causes the vm/class/load event to >>>> be fired from JVM_DefineClass() and JVM_DefineClassWithSource(). >>>> >>>> Webrev: http://cr.openjdk.java.net/~mockner/8038332/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038332 >>>> >>>> The vm/class/load event (EventClassLoad) was previously fired in 2 >>>> places: >>>> >>>> SystemDictionary::parse_stream >>>> SystemDictionary::resolve_instance_class_or_null >>>> >>>> parse_stream is the standard option for creating a klass from a >>>> stream, but JVM_DefineClass uses a different function: >>>> >>>> SystemDictionary::resolve_from_stream. >>>> >>>> This did not fire a vm/class/load event. Now it does fire the event. >>>> >>>> Sanity tested with jtreg runtime. Issue was reproduced and tested >>>> using the reproducer script attached to the bug >>>> >>>> Thanks, >>>> Max >> From david.holmes at oracle.com Tue Jun 21 00:02:41 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Jun 2016 10:02:41 +1000 Subject: RFR: 8038332: The trace event vm/class/load is not always being sent In-Reply-To: <57683F13.5070900@oracle.com> References: <5759AFCE.2080406@oracle.com> <575EF096.9020908@oracle.com> <95d4e379-2680-1e49-f972-831e4e1701ba@oracle.com> <57683F13.5070900@oracle.com> Message-ID: <1a071acf-de4b-e9c3-8f2e-c87ee637902e@oracle.com> Hi Max, On 21/06/2016 5:08 AM, Max Ockner wrote: > David, > > New webrev: > http://cr.openjdk.java.net/~mockner/8038332.02/src/share/vm/classfile/systemDictionary.cpp.cdiff.html > > I have added the check you suggested before triggering the event: > > if (HAS_PENDING_EXCEPTION || k.is_null()) { > return NULL; > } Seems okay. I assume when an exception is pending that k() yields NULL anyway. Thanks, David ----- > Thanks, > Max > > On 6/13/2016 6:40 PM, David Holmes wrote: >> Hi Max, >> >> On 14/06/2016 3:42 AM, Max Ockner wrote: >>> Jiangli, >>> Thanks for looking. I didn't see anything that looked like it might >>> produce duplicate events. However, I did see some additional places >>> where it looks like no event is fire. >>> >>> Can anyone point me to the event specs? >> >> I'm not sure there is any spec for this. Even JFR doesn't seem to >> document individual events and when they are triggered. >> >> Your change does not look right however as you are posting the >> classload event regardless of the exception state. If you look at >> SystemDictionary::resolve_instance_class_or_null, it only posts after >> checking the load was successful: >> >> 892 if (HAS_PENDING_EXCEPTION || k.is_null()) { >> 893 return NULL; >> 894 } >> 895 >> 896 post_class_load_event(class_load_start_time, k, class_loader); >> >> Similarly, SystemDictionary::parse_stream, has various CHECK macros >> that will cause a return on exception, prior to getting to the point >> of posting the load event. So you also need to add a check for a >> pending exception and that k is not null, I think, before posting the >> event. >> > I have added this check. >> BTW I would have expected to see trace-events generated at >> approximately the same locations as the corresponding JVMTI events. >> That does not seem to be the case which seems very strange to me. The >> notion of "loading a class" seems to be spread across far too many >> functions to me. >> >> Thanks, >> David >> >>> Thanks, >>> Max >>> >>> On 6/9/2016 4:39 PM, Jiangli Zhou wrote: >>>> Hi Max, >>>> >>>> Looks ok. The only possible issue is more than one event might be sent >>>> in some of the call paths. But my quick search didn?t find any of such >>>> case. >>>> >>>> Thanks, >>>> Jiangli >>>> >>>>> On Jun 9, 2016, at 11:05 AM, Max Ockner wrote: >>>>> >>>>> Hello, >>>>> >>>>> Please review this small fix which causes the vm/class/load event to >>>>> be fired from JVM_DefineClass() and JVM_DefineClassWithSource(). >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~mockner/8038332/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038332 >>>>> >>>>> The vm/class/load event (EventClassLoad) was previously fired in 2 >>>>> places: >>>>> >>>>> SystemDictionary::parse_stream >>>>> SystemDictionary::resolve_instance_class_or_null >>>>> >>>>> parse_stream is the standard option for creating a klass from a >>>>> stream, but JVM_DefineClass uses a different function: >>>>> >>>>> SystemDictionary::resolve_from_stream. >>>>> >>>>> This did not fire a vm/class/load event. Now it does fire the event. >>>>> >>>>> Sanity tested with jtreg runtime. Issue was reproduced and tested >>>>> using the reproducer script attached to the bug >>>>> >>>>> Thanks, >>>>> Max >>> > From cthalinger at twitter.com Tue Jun 21 00:20:04 2016 From: cthalinger at twitter.com (Christian Thalinger) Date: Mon, 20 Jun 2016 17:20:04 -0700 Subject: CFV: New hotspot Group Member: Zoltan Majo In-Reply-To: <576358F7.7050409@oracle.com> References: <576358F7.7050409@oracle.com> Message-ID: <8C4A0F54-412E-47E8-AE86-A8B955858EFA@twitter.com> Vote: yes > On Jun 16, 2016, at 6:57 PM, Vladimir Kozlov wrote: > > I hereby nominate Zoltan Majo (OpenJDK user name: zmajo) to Membership in the hotspot Group. > > Zoltan is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He has been working on Hotspot since 2014 and contributed more than 60 changes. > > Votes are due by 18:00, Thu, June 30, 2016 PDT. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote From cthalinger at twitter.com Tue Jun 21 00:20:18 2016 From: cthalinger at twitter.com (Christian Thalinger) Date: Mon, 20 Jun 2016 17:20:18 -0700 Subject: CFV: New hotspot Group Member: Tobias Hartmann In-Reply-To: <57635B85.4070700@oracle.com> References: <57635B85.4070700@oracle.com> Message-ID: <76E84ECA-0BED-4A93-9E84-B751927D2871@twitter.com> Vote: yes > On Jun 16, 2016, at 7:08 PM, Vladimir Kozlov wrote: > > I hereby nominate Tobias Hartmann (OpenJDK user name: thartmann) to Membership in the hotspot Group. > > Tobias is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He has been working on Hotspot since 2013 (he worked on segmented codecache before joining Oracle) and contributed more than 130 changes. > > Votes are due by 18:00, Thu, June 30, 2016 PDT. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote From volker.simonis at gmail.com Tue Jun 21 07:37:08 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 21 Jun 2016 09:37:08 +0200 Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation on ppc64 and sparc In-Reply-To: <5767B078.8030102@oracle.com> References: <27dde86d-f7b3-3093-e500-cd3c9156811f@oracle.com> <5767AD68.8090500@oracle.com> <5767B078.8030102@oracle.com> Message-ID: On Mon, Jun 20, 2016 at 10:59 AM, Tobias Hartmann wrote: > Hi Volker, > > On 20.06.2016 10:52, Volker Simonis wrote: >> Hi Tobias, >> >> thanks for sponsoring! I've uploaded a new webrev with you and >> Vladimir as reviewers: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v2/ >> >> You can find the changeset there: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v2/hotspot.changeset > > Thanks, I just noticed that the test has > > 26 * @bug 9999999 > > You can fix this in-place. I'll then run the required pre-integration testing (~24h) and push your change afterwards. > Hi Tobias, good catch and sorry, I somehow missed your mail yesterday. You can find the new changeset here: http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v3/hotspot.changeset Thank you and best regards, Volker > Best regards, > Tobias > >> >> Thanks, >> Volker >> >> >> On Mon, Jun 20, 2016 at 10:46 AM, Tobias Hartmann >> wrote: >>> Hi Volker, >>> >>> you fix looks good to me! I can do the sponsoring, please just send me a changeset. >>> >>> Best regards, >>> Tobias >>> >>> On 20.06.2016 10:16, Volker Simonis wrote: >>>> Thanks Vladimir! >>>> >>>> .. I still need a sponsor :( >>>> >>>> Regards, >>>> Volker >>>> >>>> >>>> On Fri, Jun 17, 2016 at 10:53 PM, Vladimir Kozlov >>>> wrote: >>>>> Looks good. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> >>>>> On 6/17/16 2:22 AM, Volker Simonis wrote: >>>>>> >>>>>> Hi Goetz, >>>>>> >>>>>> thanks for the review. >>>>>> You're right, I've fixed the "else": >>>>>> >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v1/ >>>>>> >>>>>> Regards, >>>>>> Volker >>>>>> >>>>>> On Fri, Jun 17, 2016 at 11:08 AM, Lindenmaier, Goetz >>>>>> wrote: >>>>>>> >>>>>>> Hi Volker, >>>>>>> >>>>>>> thanks for doing this fix, I also have run into this issue before ... >>>>>>> Looks good. >>>>>>> >>>>>>> Small nit: usually >>>>>>> } >>>>>>> else { >>>>>>> are on one line. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>>>>>> Behalf Of Volker Simonis >>>>>>>> Sent: Donnerstag, 16. Juni 2016 16:54 >>>>>>>> To: HotSpot Open Source Developers >>>>>>>> Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work >>>>>>>> together with -XX:+TieredCompilation on ppc64 and sparc >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> can I please have a review and sponsor for the following small change >>>>>>>> which fixes -XX:-UseOnStackReplacement to work together with >>>>>>>> -XX:+TieredCompilation: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620/ >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8159620 >>>>>>>> >>>>>>>> This is a long standing bug on SPARC and as the ppc64 template >>>>>>>> interpreter was initially forked from the SPARC implementation, it >>>>>>>> also manifests there. The problem is that in the case of tiered >>>>>>>> compilation the interpreter unconditionally calls >>>>>>>> InterpreterRuntime::frequency_counter_overflow if the back edge >>>>>>>> counter overflows. This triggers an OSR compilation, even if OSR was >>>>>>>> switched off with -XX:-UseOnStackReplacement. >>>>>>>> >>>>>>>> The fix is simple - just don't call >>>>>>>> InterpreterRuntime::frequency_counter_overflow if OSR has been >>>>>>>> switched off. >>>>>>>> >>>>>>>> Thank you and best regards, >>>>>>>> Volker From tobias.hartmann at oracle.com Tue Jun 21 08:44:41 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 21 Jun 2016 10:44:41 +0200 Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation on ppc64 and sparc In-Reply-To: References: <27dde86d-f7b3-3093-e500-cd3c9156811f@oracle.com> <5767AD68.8090500@oracle.com> <5767B078.8030102@oracle.com> Message-ID: <5768FE79.2060301@oracle.com> Hi Volker, On 21.06.2016 09:37, Volker Simonis wrote: > On Mon, Jun 20, 2016 at 10:59 AM, Tobias Hartmann > wrote: >> Hi Volker, >> >> On 20.06.2016 10:52, Volker Simonis wrote: >>> Hi Tobias, >>> >>> thanks for sponsoring! I've uploaded a new webrev with you and >>> Vladimir as reviewers: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v2/ >>> >>> You can find the changeset there: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v2/hotspot.changeset >> >> Thanks, I just noticed that the test has >> >> 26 * @bug 9999999 >> >> You can fix this in-place. I'll then run the required pre-integration testing (~24h) and push your change afterwards. >> > > Hi Tobias, > > good catch and sorry, I somehow missed your mail yesterday. > > You can find the new changeset here: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v3/hotspot.changeset Thank you! I just looked at the test results and unfortunately DisableOSRTest fails on all platforms (including SPARC) if -Xcomp is set: ----------System.err:(13/1215)---------- java.lang.RuntimeException: "public static void DisableOSRTest.main(java.lang.String[]) throws java.lang.Exception" shouldn't be OSR compiled if running with -XX:-UseOnStackReplacement! at DisableOSRTest.main(DisableOSRTest.java:59) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base/Method.java:531) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.lang.Thread.run(java.base/Thread.java:843) There are several OSR compilations in the log: 12916 4242 % b 4 DisableOSRTest::main @ 19 (61 bytes) Best regards, Tobias > > Thank you and best regards, > Volker > > >> Best regards, >> Tobias >> >>> >>> Thanks, >>> Volker >>> >>> >>> On Mon, Jun 20, 2016 at 10:46 AM, Tobias Hartmann >>> wrote: >>>> Hi Volker, >>>> >>>> you fix looks good to me! I can do the sponsoring, please just send me a changeset. >>>> >>>> Best regards, >>>> Tobias >>>> >>>> On 20.06.2016 10:16, Volker Simonis wrote: >>>>> Thanks Vladimir! >>>>> >>>>> .. I still need a sponsor :( >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> >>>>> On Fri, Jun 17, 2016 at 10:53 PM, Vladimir Kozlov >>>>> wrote: >>>>>> Looks good. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> >>>>>> On 6/17/16 2:22 AM, Volker Simonis wrote: >>>>>>> >>>>>>> Hi Goetz, >>>>>>> >>>>>>> thanks for the review. >>>>>>> You're right, I've fixed the "else": >>>>>>> >>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v1/ >>>>>>> >>>>>>> Regards, >>>>>>> Volker >>>>>>> >>>>>>> On Fri, Jun 17, 2016 at 11:08 AM, Lindenmaier, Goetz >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Volker, >>>>>>>> >>>>>>>> thanks for doing this fix, I also have run into this issue before ... >>>>>>>> Looks good. >>>>>>>> >>>>>>>> Small nit: usually >>>>>>>> } >>>>>>>> else { >>>>>>>> are on one line. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>>>>>>> Behalf Of Volker Simonis >>>>>>>>> Sent: Donnerstag, 16. Juni 2016 16:54 >>>>>>>>> To: HotSpot Open Source Developers >>>>>>>>> Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work >>>>>>>>> together with -XX:+TieredCompilation on ppc64 and sparc >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> can I please have a review and sponsor for the following small change >>>>>>>>> which fixes -XX:-UseOnStackReplacement to work together with >>>>>>>>> -XX:+TieredCompilation: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620/ >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8159620 >>>>>>>>> >>>>>>>>> This is a long standing bug on SPARC and as the ppc64 template >>>>>>>>> interpreter was initially forked from the SPARC implementation, it >>>>>>>>> also manifests there. The problem is that in the case of tiered >>>>>>>>> compilation the interpreter unconditionally calls >>>>>>>>> InterpreterRuntime::frequency_counter_overflow if the back edge >>>>>>>>> counter overflows. This triggers an OSR compilation, even if OSR was >>>>>>>>> switched off with -XX:-UseOnStackReplacement. >>>>>>>>> >>>>>>>>> The fix is simple - just don't call >>>>>>>>> InterpreterRuntime::frequency_counter_overflow if OSR has been >>>>>>>>> switched off. >>>>>>>>> >>>>>>>>> Thank you and best regards, >>>>>>>>> Volker From shafi.s.ahmad at oracle.com Tue Jun 21 09:21:20 2016 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Tue, 21 Jun 2016 02:21:20 -0700 (PDT) Subject: [8u] RFR for JDK-8156836: Test test/compiler/jsr292/VMAnonymousClasses.java fails with JTREG 4.2 b02 Message-ID: <7a3e12e9-3e79-4730-8547-857a84c96b4b@default> Hi, Please review the code change for "JDK-8156836: Test test/compiler/jsr292/VMAnonymousClasses.java fails with JTREG 4.2 b02" to jdk8u. Summary: Test case failed with Parse Exception: '[-Xbatch]: vm option(s) found, need to specify /othervm' as '/othervm' is not specified in the annotation section. Current modification add this at appropriate place. Jdk8 bug: https://bugs.openjdk.java.net/browse/JDK-8156836 Webrev link: http://cr.openjdk.java.net/~shshahma/8156836/webrev.00/ Testing: As the change is in the test case so I run only this test case. Regards, Shafi From serguei.spitsyn at oracle.com Tue Jun 21 09:54:03 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Jun 2016 02:54:03 -0700 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName Message-ID: <57690EBB.2010007@oracle.com> Please, review the Jigsaw fix for the enhancement: https://bugs.openjdk.java.net/browse/JDK-8159145 The Hotspot webrev: http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ The Jdk webrev: http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ Summary: JVM TI agents that instrument code in named modules need the Module at class load time. One way to do this is by introducing a new ClassFileLoadHook that takes an additional parameter but this approach is disruptive. The alternative option is a JVM TI function that maps a classloader + package name to a module. We were initially not confident with this approach so we introduced it as JVM function JVM_GetModuleByPackageName. Based on experience to date then this approach seems okay and so this function needs to be promoted to a JVMTI function. This fix is to introduce new JVMTI function GetModuleByPackageName. It includes new jtreg test with native JVMTI agent. A CCC is fast-tracked and getting an approval is in progress. Testing: Run newly developed jtreg test. Thanks, Serguei From adinn at redhat.com Tue Jun 21 10:19:42 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 21 Jun 2016 11:19:42 +0100 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <57690EBB.2010007@oracle.com> References: <57690EBB.2010007@oracle.com> Message-ID: <576914BE.1030309@redhat.com> On 21/06/16 10:54, serguei.spitsyn at oracle.com wrote: > > Please, review the Jigsaw fix for the enhancement: > https://bugs.openjdk.java.net/browse/JDK-8159145 > > > The Hotspot webrev: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ > > > The Jdk webrev: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ I don't seem to be able to access those webrevs: Server not found Firefox can't find the server at javaweb.sfbay.sun.com. . . . regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Alan.Bateman at oracle.com Tue Jun 21 10:23:47 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 Jun 2016 11:23:47 +0100 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <57690EBB.2010007@oracle.com> References: <57690EBB.2010007@oracle.com> Message-ID: <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> On 21/06/2016 10:54, serguei.spitsyn at oracle.com wrote: > > Please, review the Jigsaw fix for the enhancement: > https://bugs.openjdk.java.net/browse/JDK-8159145 > > > The Hotspot webrev: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ > > The Jdk webrev: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ > Serguei - can you put the patches on cr.openjdk.java.net? -Alan From serguei.spitsyn at oracle.com Tue Jun 21 10:48:39 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Jun 2016 03:48:39 -0700 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> References: <57690EBB.2010007@oracle.com> <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> Message-ID: <57691B87.20104@oracle.com> On 6/21/16 03:23, Alan Bateman wrote: > > > > On 21/06/2016 10:54, serguei.spitsyn at oracle.com wrote: >> >> Please, review the Jigsaw fix for the enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8159145 >> >> >> The Hotspot webrev: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ >> >> The Jdk webrev: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >> > Serguei - can you put the patches on cr.openjdk.java.net? Sorry. My initial plan was to write an nsk.jvmti test and review it on a confidential mailing list. It is why I put the webrevs on the non-public server. Forgot to switch the server when the test was converted into the jtreg format. The public webrevs are: Hotspot: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ Jdk: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ Thanks, Serguei > > -Alan From serguei.spitsyn at oracle.com Tue Jun 21 10:49:55 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Jun 2016 03:49:55 -0700 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576914BE.1030309@redhat.com> References: <57690EBB.2010007@oracle.com> <576914BE.1030309@redhat.com> Message-ID: <57691BD3.2000406@oracle.com> Hi Andrew, Please, find the public webrevs in my reply to Alan. Thanks, Serguei On 6/21/16 03:19, Andrew Dinn wrote: > On 21/06/16 10:54, serguei.spitsyn at oracle.com wrote: >> Please, review the Jigsaw fix for the enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8159145 >> >> >> The Hotspot webrev: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ >> >> >> The Jdk webrev: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ > I don't seem to be able to access those webrevs: > > > Server not found > > Firefox can't find the server at javaweb.sfbay.sun.com. > . . . > > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Alan.Bateman at oracle.com Tue Jun 21 11:56:01 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 Jun 2016 12:56:01 +0100 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <57691B87.20104@oracle.com> References: <57690EBB.2010007@oracle.com> <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> <57691B87.20104@oracle.com> Message-ID: On 21/06/2016 11:48, serguei.spitsyn at oracle.com wrote: > > Sorry. > My initial plan was to write an nsk.jvmti test and review it on a > confidential mailing list. > It is why I put the webrevs on the non-public server. > Forgot to switch the server when the test was converted into the jtreg > format. > > The public webrevs are: > > Hotspot: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ > > Jdk: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ > The spec generally looks good, just two small points: 1. "java.lang.ClassLoader" would be better than "java/lang/ClassLoader" when describing the class_loader parameter. 2. For the package name then it might be clearer to say that the package name is in internal form and then include the example of "java/lang" in parenthesis. One comment on the test is that it looks like check_system_loader doesn't test any packages that are defined to a module. check_bootstrap_loader does have tests for named modules for the null loader case. Just wondering if we need more here. You might have spotted this already but the header comment on the tests needs to be the GPL header. -Alan From christian.tornqvist at oracle.com Tue Jun 21 11:56:29 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 21 Jun 2016 07:56:29 -0400 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <57691B87.20104@oracle.com> References: <57690EBB.2010007@oracle.com> <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> <57691B87.20104@oracle.com> Message-ID: Hi Serguei, I?ve only looked at the test code so far, here are some comments: * You?re not allowed to call System.exit in a jtreg test. If something fails, you need to throw an exception. * Instead of a run() method you could simply collapse all this into the main method like this: assertEQ(check(), 0); * Would it make sense to throw exceptions with useful error messages from the JNI code instead of returning failed status codes? Our error matching system would work a lot better with unique error messages. Thanks, Christian From: serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] Sent: Tuesday, June 21, 2016 6:49 AM To: Alan Bateman ; serviceability-dev at openjdk.java.net; Christian T?rnqvist ; Alexander Kulyakhtin ; hotspot-dev at openjdk.java.net Developers Subject: Re: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName On 6/21/16 03:23, Alan Bateman wrote: On 21/06/2016 10:54, serguei.spitsyn at oracle.com wrote: Please, review the Jigsaw fix for the enhancement: https://bugs.openjdk.java.net/browse/JDK-8159145 The Hotspot webrev: http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ The Jdk webrev: http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ Serguei - can you put the patches on cr.openjdk.java.net? Sorry. My initial plan was to write an nsk.jvmti test and review it on a confidential mailing list. It is why I put the webrevs on the non-public server. Forgot to switch the server when the test was converted into the jtreg format. The public webrevs are: Hotspot: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ Jdk: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ Thanks, Serguei -Alan From erik.helin at oracle.com Tue Jun 21 14:27:28 2016 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 21 Jun 2016 16:27:28 +0200 Subject: RFR: 8159370: Add FlagGuard for easier modification of flags for unit tests In-Reply-To: References: <20160614105857.GV26799@ehelin.jrpg.bea.com> <2C12A9D7-3E82-461B-B0BD-13B0A83276C2@oracle.com> <20160617153121.GB22330@ehelin.jrpg.bea.com> Message-ID: <20160621142728.GB20451@ehelin.jrpg.bea.com> On 2016-06-17, Kim Barrett wrote: > > On Jun 17, 2016, at 11:31 AM, Erik Helin wrote: > > > > On 2016-06-14, Kim Barrett wrote: > >>> On Jun 14, 2016, at 6:58 AM, Erik Helin wrote: > >>> > >>> Hi all, > >>> > >>> this patch adds a small utility class that makes it easier for TEST_VM > >>> unit tests to safely modify flags. The class FlagGuard will store the > >>> value of the flag in its constructor and then restore the flag in its > >>> destructor. This is similar IntFlagSetting, UIntFlagSetting etc, but the > >>> FlagGuard differs in two aspects: > >>> - it does not set a new value > >>> - it is "untyped", you can use FlagGuard for flags with any type > >> > >> Is there a reason why this is being added to the unit test framework, > >> rather than being a generalization of the existing [U]IntFlagSetting > >> &etc and placed nearby? That?s where I would expect to find it. > > > > So my reasoning was that the FlagGuard was pretty slow, since it used > > Flag::find_flag, so I didn't want to encourage anyone to use it in > > production. Me and Per hacked together a new implementation of > > FlagGuard, which uses templates and memcpy instead of Flag::find_flag: > > > > http://cr.openjdk.java.net/~ehelin/8159370/00/ > > That's the old URL; the correct URL ends in /01/ Thanks for correcting the URL. New patches are located at: - incremental: http://cr.openjdk.java.net/~ehelin/8159370/01-02/ - full: http://cr.openjdk.java.net/~ehelin/8159370/02/ (tested in JRPT) Please see my comments inline. > > What do you think? I also moved FlagGuard to runtime/globals.hpp and > > added some tests. I don't want to update [U]IntFlagSetting since > > they also take a new value as parameter, FlagGuard just restores the > > value at the end of the scope. > > ------------------------------------------------------------------------------ > For reference, the technique used here is based on C++2003 3.9/2. > > The basic idea seems sound, though I have quibbles about details. > > I'm fine with this interface and leaving [U]IntFlagSetting alone. Thanks! > Given that we have a fixed set of types to deal with, I suspect there > is some tag dispatching / sizeof trick that could eliminate the memcpy > and use the actual option type, but it hardly seems worth the trouble. > > There are much cleaner solutions with C++11... > > ------------------------------------------------------------------------------ > src/share/vm/runtime/globals.hpp > 469 uint8_t _value[SIZE]; > > Element type should be char or unsigned char. uint8_t is not > necessarily either of those, though it likely is on any platform we > support. Ok, I changed _value to be unsigned char. > ------------------------------------------------------------------------------ > src/share/vm/runtime/globals.hpp > 475 void* operator new(size_t size) throw() { > 476 return 0; > 477 } > 478 > 479 void* operator new [](size_t size) throw() { > 480 return 0; > 481 } > > Leave off the definitions, further ensuring they can't be used, and > not being misleading about them. Agree, fixed. > ------------------------------------------------------------------------------ > src/share/vm/runtime/globals.hpp > 470 const uintptr_t _addr; > 484 FlagGuard(uintptr_t flag_addr) : _addr(flag_addr) { > 493 #define FLAG_GUARD(f) FlagGuard f ## _guard((uintptr_t) &f) > > Why the address conversion to uintptr_t? Why not just use const void*, > and eliminate lots of casts... Agree, changed to void*. > ------------------------------------------------------------------------------ > src/share/vm/runtime/globals.hpp > 485 memcpy((void*) _value, (const void*) _addr, SIZE); > 489 memcpy((void*) _addr, (const void*) _value, SIZE); > > Unnecessary casts of _value. Fixed. > ------------------------------------------------------------------------------ > test/native/runtime/test_globals.cpp > > This file only contains tests for FlagGuard. I don't know what > conventions we're adopting for native tests, and what restrictions the > build system might be imposing on us. It seems to me though that this > might be better called test_FlagGuard, and other native tests of > facilities in globals.hpp would be in other file(s). I would like to start by using one test_ file per source file until we have more experience with the unit tests. If we then find that it is better to use multiple test_ files for one source files, then I'll be happy to move the FlagGuard tests into its own file. > ------------------------------------------------------------------------------ > test/native/runtime/test_globals.cpp > > I think each test should also contain a check that the flag is of the > expected type, e.g. at the beginning something like > > ASSERT(Flag::find_flag("AlwaysActAsServerClassMachine")->is_bool()); > > Otherwise, a change in the type of an option could accidently result > in an untested case here. Agree, fixed. > ------------------------------------------------------------------------------ > test/native/runtime/test_globals.cpp > > The code here is extreme boilerplate. Consider a macro to reduce > that? Yep, agree. What do you think of the macro? > ------------------------------------------------------------------------------ > test/native/runtime/test_globals.cpp > 102 const char* original_value = PerfDataSaveFile; > > For consistency, I think that should be ccstr rather than const char*. Agree, fixed. Thanks, Erik From serguei.spitsyn at oracle.com Tue Jun 21 14:58:48 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Jun 2016 07:58:48 -0700 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: References: <57690EBB.2010007@oracle.com> <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> <57691B87.20104@oracle.com> Message-ID: <57695628.4000200@oracle.com> Hi Christian, Thank you for looking at it! On 6/21/16 04:56, Christian Tornqvist wrote: > > Hi Serguei, > > I?ve only looked at the test code so far, here are some comments: > > * You?re not allowed to call System.exit in a jtreg test. If something > fails, you need to throw an exception. > Ok, an exception is Ok with me. > * Instead of a run() method you could simply collapse all this into > the main method like this: > > assertEQ(check(), 0); > Will check if this works for me. > * Would it make sense to throw exceptions with useful error messages > from the JNI code instead of returning failed status codes? Our error > matching system would work a lot better with unique error messages. > Will check if this works well in this case. The unique error messages are already printed in the native code. Thanks, Serguei > Thanks, > > Christian > > *From:*serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] > *Sent:* Tuesday, June 21, 2016 6:49 AM > *To:* Alan Bateman ; > serviceability-dev at openjdk.java.net; Christian T?rnqvist > ; Alexander Kulyakhtin > ; hotspot-dev at openjdk.java.net > Developers > *Subject:* Re: Jigsaw Enhancement RFR: 8159145 Add JVMTI function > GetModuleByPackageName > > On 6/21/16 03:23, Alan Bateman wrote: > > On 21/06/2016 10:54, serguei.spitsyn at oracle.com > wrote: > > > Please, review the Jigsaw fix for the enhancement: > https://bugs.openjdk.java.net/browse/JDK-8159145 > > > The Hotspot webrev: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ > > The Jdk webrev: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ > > Serguei - can you put the patches on cr.openjdk.java.net? > > > Sorry. > My initial plan was to write an nsk.jvmti test and review it on a > confidential mailing list. > It is why I put the webrevs on the non-public server. > Forgot to switch the server when the test was converted into the jtreg > format. > > The public webrevs are: > > Hotspot: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ > > > Jdk: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ > > > > Thanks, > Serguei > > > > > -Alan > From serguei.spitsyn at oracle.com Tue Jun 21 14:59:58 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Jun 2016 07:59:58 -0700 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: References: <57690EBB.2010007@oracle.com> <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> <57691B87.20104@oracle.com> Message-ID: <5769566E.6080609@oracle.com> Hi Alan, Thank you for the review! I'll implement all your suggestions. Thanks, Serguei On 6/21/16 04:56, Alan Bateman wrote: > > > On 21/06/2016 11:48, serguei.spitsyn at oracle.com wrote: >> >> Sorry. >> My initial plan was to write an nsk.jvmti test and review it on a >> confidential mailing list. >> It is why I put the webrevs on the non-public server. >> Forgot to switch the server when the test was converted into the >> jtreg format. >> >> The public webrevs are: >> >> Hotspot: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ >> >> >> Jdk: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >> >> > > The spec generally looks good, just two small points: > > 1. "java.lang.ClassLoader" would be better than > "java/lang/ClassLoader" when describing the class_loader parameter. > > 2. For the package name then it might be clearer to say that the > package name is in internal form and then include the example of > "java/lang" in parenthesis. > > One comment on the test is that it looks like check_system_loader > doesn't test any packages that are defined to a module. > check_bootstrap_loader does have tests for named modules for the null > loader case. Just wondering if we need more here. > > You might have spotted this already but the header comment on the > tests needs to be the GPL header. > > -Alan From harold.seigel at oracle.com Tue Jun 21 16:42:26 2016 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 21 Jun 2016 12:42:26 -0400 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <57690EBB.2010007@oracle.com> References: <57690EBB.2010007@oracle.com> Message-ID: <2566893c-09ba-f31a-4495-7d315872e79a@oracle.com> Hi Serguei, The hotspot changes look good. Thanks, Harold On 6/21/2016 5:54 AM, serguei.spitsyn at oracle.com wrote: > > Please, review the Jigsaw fix for the enhancement: > https://bugs.openjdk.java.net/browse/JDK-8159145 > > > The Hotspot webrev: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ > > > The Jdk webrev: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ > > > > Summary: > > JVM TI agents that instrument code in named modules need the Module at > class load time. > > One way to do this is by introducing a new ClassFileLoadHook that > takes an additional parameter but this approach is disruptive. > The alternative option is a JVM TI function that maps a classloader > + package name to a module. > We were initially not confident with this approach so we introduced > it as JVM function JVM_GetModuleByPackageName. > Based on experience to date then this approach seems okay and so > this function needs to be promoted to a JVMTI function. > > This fix is to introduce new JVMTI function GetModuleByPackageName. > It includes new jtreg test with native JVMTI agent. > > A CCC is fast-tracked and getting an approval is in progress. > > Testing: > Run newly developed jtreg test. > > Thanks, > Serguei From kim.barrett at oracle.com Tue Jun 21 16:54:31 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 21 Jun 2016 12:54:31 -0400 Subject: RFR: 8159370: Add FlagGuard for easier modification of flags for unit tests In-Reply-To: <20160621142728.GB20451@ehelin.jrpg.bea.com> References: <20160614105857.GV26799@ehelin.jrpg.bea.com> <2C12A9D7-3E82-461B-B0BD-13B0A83276C2@oracle.com> <20160617153121.GB22330@ehelin.jrpg.bea.com> <20160621142728.GB20451@ehelin.jrpg.bea.com> Message-ID: > On Jun 21, 2016, at 10:27 AM, Erik Helin wrote: > > On 2016-06-17, Kim Barrett wrote: > Thanks for correcting the URL. New patches are located at: > - incremental: http://cr.openjdk.java.net/~ehelin/8159370/01-02/ > - full: http://cr.openjdk.java.net/~ehelin/8159370/02/ Looks good. >> test/native/runtime/test_globals.cpp >> >> This file only contains tests for FlagGuard. I don't know what >> conventions we're adopting for native tests, and what restrictions the >> build system might be imposing on us. It seems to me though that this >> might be better called test_FlagGuard, and other native tests of >> facilities in globals.hpp would be in other file(s). > > I would like to start by using one test_ file per source file until we > have more experience with the unit tests. If we then find that it is > better to use multiple test_ files for one source files, then I'll be > happy to move the FlagGuard tests into its own file. OK. >> test/native/runtime/test_globals.cpp >> >> The code here is extreme boilerplate. Consider a macro to reduce >> that? > > Yep, agree. What do you think of the macro? I think I would have included the TEST_VM(?) in the macro expansion, but I?m OK with it as is too, since I can come up with arguments for preferring the separation. In particular, if a test fails, making the failing test easier to find (without needing to understand a macro) by reported name has some benefit. From christian.tornqvist at oracle.com Tue Jun 21 17:06:17 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 21 Jun 2016 13:06:17 -0400 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <57695628.4000200@oracle.com> References: <57690EBB.2010007@oracle.com> <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> <57691B87.20104@oracle.com> <57695628.4000200@oracle.com> Message-ID: Hi Serguei, >Will check if this works well in this case. >The unique error messages are already printed in the native code. Yes, they?re printed on stdout/stderr but the test will fail with a ?Test failed? exception and our failure matching system wouldn?t be able to tell why it failed. It?d be a lot nicer if it?d just throw an exception when one of the checks in the native code failed. Thanks, Christian From: serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] Sent: Tuesday, June 21, 2016 10:59 AM To: Christian Tornqvist ; 'Alan Bateman' ; serviceability-dev at openjdk.java.net; 'Alexander Kulyakhtin' ; hotspot-dev at openjdk.java.net Subject: Re: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName Hi Christian, Thank you for looking at it! On 6/21/16 04:56, Christian Tornqvist wrote: Hi Serguei, I?ve only looked at the test code so far, here are some comments: * You?re not allowed to call System.exit in a jtreg test. If something fails, you need to throw an exception. Ok, an exception is Ok with me. * Instead of a run() method you could simply collapse all this into the main method like this: assertEQ(check(), 0); Will check if this works for me. * Would it make sense to throw exceptions with useful error messages from the JNI code instead of returning failed status codes? Our error matching system would work a lot better with unique error messages. Will check if this works well in this case. The unique error messages are already printed in the native code. Thanks, Serguei Thanks, Christian From: serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] Sent: Tuesday, June 21, 2016 6:49 AM To: Alan Bateman ; serviceability-dev at openjdk.java.net ; Christian T?rnqvist ; Alexander Kulyakhtin ; hotspot-dev at openjdk.java.net Developers Subject: Re: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName On 6/21/16 03:23, Alan Bateman wrote: On 21/06/2016 10:54, serguei.spitsyn at oracle.com wrote: Please, review the Jigsaw fix for the enhancement: https://bugs.openjdk.java.net/browse/JDK-8159145 The Hotspot webrev: http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ The Jdk webrev: http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ Serguei - can you put the patches on cr.openjdk.java.net? Sorry. My initial plan was to write an nsk.jvmti test and review it on a confidential mailing list. It is why I put the webrevs on the non-public server. Forgot to switch the server when the test was converted into the jtreg format. The public webrevs are: Hotspot: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ Jdk: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ Thanks, Serguei -Alan From adinn at redhat.com Tue Jun 21 17:44:14 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 21 Jun 2016 18:44:14 +0100 Subject: RFR: 8160006 Fix AArch64 after changes made by 8151661 Message-ID: <57697CEE.6060100@redhat.com> The Fix: Please review the following webrev against hs-comp head which provides a patch to fix the AArch64 ad file after it is broken by JDK-8151661. http://cr.openjdk.java.net/~adinn/8160006/webrev.00/ n.b. The webrev also includes the changes for 8151661 (which has not yet been posted to hs-comp). Testing: Eyeballing of the code generated during a run of HelloWorld (-XX:-TieredCompilation -XX:+PrintOptoAssembly) shows it is generating cbxx and tbxx instructions as expected. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From lois.foltan at oracle.com Tue Jun 21 17:59:05 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 21 Jun 2016 13:59:05 -0400 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined Message-ID: <57698069.80902@oracle.com> Hello, Please review the following fix: Webrev: http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262/webrev/ Bug: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined https://bugs.openjdk.java.net/browse/JDK-8159262 Summary: In ClassLoaderDataGraph::do_unloading(), the decision to walk each ClassLoader's PackageEntry exports and ModuleEntry's reads list was occurring too soon, before the aliveness of all class loaders was determined. The walk has been moved to immediately after and only alive ClassLoader's PackageEntry and ModuleEntry lists are walked. The other piece to this fix is that the lists themselves were being unnecessarily walked if only modules on any given list were either: 1. defined to the same class loader as either the package being exported or the module that a read edge was being established from. Thus both modules in this equation have the same life cycle. 2. or defined to one of the three builtin class loaders (boot, application or platform) which never die Test: - java/io, java/lang/, java/util, all Hotspot jtreg tests, JCK vm & lang - full hotspot nightly RBT run in progress From vladimir.kozlov at oracle.com Tue Jun 21 18:00:45 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Jun 2016 11:00:45 -0700 Subject: RFR: 8160006 Fix AArch64 after changes made by 8151661 In-Reply-To: <57697CEE.6060100@redhat.com> References: <57697CEE.6060100@redhat.com> Message-ID: <0b22ba64-c167-62d3-e3e0-676761dc0020@oracle.com> Thank you, Andrew Changes looks good. I will sponsor them since they touch shared code. Thanks, Vladimir PS: After that I will close 8151661. On 6/21/16 10:44 AM, Andrew Dinn wrote: > The Fix: > > Please review the following webrev against hs-comp head which provides a > patch to fix the AArch64 ad file after it is broken by JDK-8151661. > > http://cr.openjdk.java.net/~adinn/8160006/webrev.00/ > > n.b. The webrev also includes the changes for 8151661 (which has not yet > been posted to hs-comp). > > Testing: > > Eyeballing of the code generated during a run of HelloWorld > (-XX:-TieredCompilation -XX:+PrintOptoAssembly) shows it is generating > cbxx and tbxx instructions as expected. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From adinn at redhat.com Tue Jun 21 18:55:06 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 21 Jun 2016 19:55:06 +0100 Subject: RFR: 8160006 Fix AArch64 after changes made by 8151661 In-Reply-To: <0b22ba64-c167-62d3-e3e0-676761dc0020@oracle.com> References: <57697CEE.6060100@redhat.com> <0b22ba64-c167-62d3-e3e0-676761dc0020@oracle.com> Message-ID: <57698D8A.9010307@redhat.com> On 21/06/16 19:00, Vladimir Kozlov wrote: > Thank you, Andrew > > Changes looks good. I will sponsor them since they touch shared code. Thank you for the review Vladimir. I am hoping Andrew will also review asap so both changes an go in together. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From jesper.wilhelmsson at oracle.com Tue Jun 21 19:09:50 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 21 Jun 2016 21:09:50 +0200 Subject: RFR: 8048093 - Explicitly setting := vs = in the -XX:+PrintFlagsFinal output Message-ID: Hi, Please review this change to make -XX:+PrintFlagsFinal distinguish between flags changed on the command line and flags changed by the ergonomics. To enable us to remember if a flag was set on the command line or not after having been changed by the ergonomics I use another bit in the Flag struct. The actual symbols printed by PrintFlagsFinal are chosen somewhat arbitrary and I'm open to suggestions (bike sheding) about how to visualize this the best. The old decorations are: ' =' - Default value (no decoration) ':=' - Value was changed, either by command line or ergonomics or other The new decorations are: ' =' - Default value (no decoration) ':=' - Set on the command line '?=' - Changed by the ergonomics '!=' - Set on the command line AND changed by the ergonomics '-=' - Any other origin, like changed by management API or taken from a config file My reasoning behind selecting these characters are that ':=' looks like a solid assignment and will therefore represent the command line. You never know what you get from the ergonomics, so '?=' seems appropriate. '!=' because you'd want to know that the ergonomics changed a value you had set on the command line. Another option could be to use a colon ':=' for the command line, and a comma ',=' for the ergonomics. That would naturally give us the semi-colon ';=' for something set on the command line and changed by the ergonomics. I didn't go with this because the colon and semi-colon can be hard to distinguish from each other. As mentioned above there are other origins, the enum contains eight values. There is no mention of the other types in the bug and there are no is_...() for the other types in globals.cpp, so they didn't seem as important. If the general opinion is that these other origins are as important, or we might as well..., I'd suggest that we use letters as decorations. Let me know if you have an opinion. Bug: https://bugs.openjdk.java.net/browse/JDK-8048093 Webrev: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.00/ Thanks, /Jesper From vladimir.kozlov at oracle.com Tue Jun 21 20:08:23 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Jun 2016 13:08:23 -0700 Subject: [8u] RFR for JDK-8156836: Test test/compiler/jsr292/VMAnonymousClasses.java fails with JTREG 4.2 b02 In-Reply-To: <7a3e12e9-3e79-4730-8547-857a84c96b4b@default> References: <7a3e12e9-3e79-4730-8547-857a84c96b4b@default> Message-ID: Good. Thanks, Vladimir On 6/21/16 2:21 AM, Shafi Ahmad wrote: > Hi, > > Please review the code change for "JDK-8156836: Test test/compiler/jsr292/VMAnonymousClasses.java fails with JTREG 4.2 b02" to jdk8u. > > Summary: > Test case failed with Parse Exception: '[-Xbatch]: vm option(s) found, need to specify /othervm' as '/othervm' is not specified in the annotation section. > Current modification add this at appropriate place. > > Jdk8 bug: https://bugs.openjdk.java.net/browse/JDK-8156836 > Webrev link: http://cr.openjdk.java.net/~shshahma/8156836/webrev.00/ > > Testing: As the change is in the test case so I run only this test case. > > Regards, > Shafi > From dmitry.fazunenko at oracle.com Tue Jun 21 20:08:27 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Tue, 21 Jun 2016 23:08:27 +0300 Subject: RFR: 8048093 - Explicitly setting := vs = in the -XX:+PrintFlagsFinal output In-Reply-To: References: Message-ID: <123080d3-f364-9597-b385-91a211ce0e88@oracle.com> Hi Jesper, New decorations look very attractive! But this change misses a regression test. Would either develop it or submit a CR to develop it later. Thanks, Dima On 21.06.2016 22:09, Jesper Wilhelmsson wrote: > Hi, > > Please review this change to make -XX:+PrintFlagsFinal distinguish > between flags changed on the command line and flags changed by the > ergonomics. > > To enable us to remember if a flag was set on the command line or not > after having been changed by the ergonomics I use another bit in the > Flag struct. > > The actual symbols printed by PrintFlagsFinal are chosen somewhat > arbitrary and I'm open to suggestions (bike sheding) about how to > visualize this the best. > > The old decorations are: > > ' =' - Default value (no decoration) > ':=' - Value was changed, either by command line or ergonomics or other > > The new decorations are: > > ' =' - Default value (no decoration) > ':=' - Set on the command line > '?=' - Changed by the ergonomics > '!=' - Set on the command line AND changed by the ergonomics > '-=' - Any other origin, like changed by management API or taken from > a config file > > My reasoning behind selecting these characters are that ':=' looks > like a solid assignment and will therefore represent the command line. > You never know what you get from the ergonomics, so '?=' seems > appropriate. '!=' because you'd want to know that the ergonomics > changed a value you had set on the command line. > > Another option could be to use a colon ':=' for the command line, and > a comma ',=' for the ergonomics. That would naturally give us the > semi-colon ';=' for something set on the command line and changed by > the ergonomics. I didn't go with this because the colon and semi-colon > can be hard to distinguish from each other. > > As mentioned above there are other origins, the enum contains eight > values. There is no mention of the other types in the bug and there > are no is_...() for the other types in globals.cpp, so they didn't > seem as important. If the general opinion is that these other origins > are as important, or we might as well..., I'd suggest that we use > letters as decorations. Let me know if you have an opinion. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8048093 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.00/ > > Thanks, > /Jesper From vladimir.kozlov at oracle.com Tue Jun 21 20:15:13 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Jun 2016 13:15:13 -0700 Subject: RFR: 8048093 - Explicitly setting := vs = in the -XX:+PrintFlagsFinal output In-Reply-To: References: Message-ID: Nobody will remember the meaning of such marking. You should use normal words. The output already have flag's type as, for example, "{C2 product}". You can add an other word there to indicate type of initialization: default|command|ergo. Thanks, Vladimir On 6/21/16 12:09 PM, Jesper Wilhelmsson wrote: > Hi, > > Please review this change to make -XX:+PrintFlagsFinal distinguish between flags changed on the command line and flags > changed by the ergonomics. > > To enable us to remember if a flag was set on the command line or not after having been changed by the ergonomics I use > another bit in the Flag struct. > > The actual symbols printed by PrintFlagsFinal are chosen somewhat arbitrary and I'm open to suggestions (bike sheding) > about how to visualize this the best. > > The old decorations are: > > ' =' - Default value (no decoration) > ':=' - Value was changed, either by command line or ergonomics or other > > The new decorations are: > > ' =' - Default value (no decoration) > ':=' - Set on the command line > '?=' - Changed by the ergonomics > '!=' - Set on the command line AND changed by the ergonomics > '-=' - Any other origin, like changed by management API or taken from a config file > > My reasoning behind selecting these characters are that ':=' looks like a solid assignment and will therefore represent > the command line. You never know what you get from the ergonomics, so '?=' seems appropriate. '!=' because you'd want to > know that the ergonomics changed a value you had set on the command line. > > Another option could be to use a colon ':=' for the command line, and a comma ',=' for the ergonomics. That would > naturally give us the semi-colon ';=' for something set on the command line and changed by the ergonomics. I didn't go > with this because the colon and semi-colon can be hard to distinguish from each other. > > As mentioned above there are other origins, the enum contains eight values. There is no mention of the other types in > the bug and there are no is_...() for the other types in globals.cpp, so they didn't seem as important. If the general > opinion is that these other origins are as important, or we might as well..., I'd suggest that we use letters as > decorations. Let me know if you have an opinion. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8048093 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.00/ > > Thanks, > /Jesper From jesper.wilhelmsson at oracle.com Tue Jun 21 20:16:53 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 21 Jun 2016 22:16:53 +0200 Subject: RFR: 8048093 - Explicitly setting := vs = in the -XX:+PrintFlagsFinal output In-Reply-To: <123080d3-f364-9597-b385-91a211ce0e88@oracle.com> References: <123080d3-f364-9597-b385-91a211ce0e88@oracle.com> Message-ID: <02619a0c-9443-fb64-cb7f-c715b53342f0@oracle.com> Den 21/6/16 kl. 22:08, skrev Dmitry Fazunenko: > Hi Jesper, > > New decorations look very attractive! > But this change misses a regression test. Would either develop it or submit a CR > to develop it later. Yes, a regression test should be added. Thanks, /Jesper > > Thanks, > Dima > > > On 21.06.2016 22:09, Jesper Wilhelmsson wrote: >> Hi, >> >> Please review this change to make -XX:+PrintFlagsFinal distinguish between >> flags changed on the command line and flags changed by the ergonomics. >> >> To enable us to remember if a flag was set on the command line or not after >> having been changed by the ergonomics I use another bit in the Flag struct. >> >> The actual symbols printed by PrintFlagsFinal are chosen somewhat arbitrary >> and I'm open to suggestions (bike sheding) about how to visualize this the best. >> >> The old decorations are: >> >> ' =' - Default value (no decoration) >> ':=' - Value was changed, either by command line or ergonomics or other >> >> The new decorations are: >> >> ' =' - Default value (no decoration) >> ':=' - Set on the command line >> '?=' - Changed by the ergonomics >> '!=' - Set on the command line AND changed by the ergonomics >> '-=' - Any other origin, like changed by management API or taken from a config >> file >> >> My reasoning behind selecting these characters are that ':=' looks like a >> solid assignment and will therefore represent the command line. You never know >> what you get from the ergonomics, so '?=' seems appropriate. '!=' because >> you'd want to know that the ergonomics changed a value you had set on the >> command line. >> >> Another option could be to use a colon ':=' for the command line, and a comma >> ',=' for the ergonomics. That would naturally give us the semi-colon ';=' for >> something set on the command line and changed by the ergonomics. I didn't go >> with this because the colon and semi-colon can be hard to distinguish from >> each other. >> >> As mentioned above there are other origins, the enum contains eight values. >> There is no mention of the other types in the bug and there are no is_...() >> for the other types in globals.cpp, so they didn't seem as important. If the >> general opinion is that these other origins are as important, or we might as >> well..., I'd suggest that we use letters as decorations. Let me know if you >> have an opinion. >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8048093 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.00/ >> >> Thanks, >> /Jesper > From vladimir.kozlov at oracle.com Tue Jun 21 20:31:47 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Jun 2016 13:31:47 -0700 Subject: JDK debug builds on OSX copying dSYM In-Reply-To: References: Message-ID: Thank you, Radek This should be reviewed in 'build' mailing list. Thanks, Vladimir -------- Forwarded Message -------- Subject: JDK debug builds on OSX copying dSYM Date: Mon, 20 Jun 2016 21:01:48 +0000 From: Rados?aw Smogura To: hotspot-compiler-dev at openjdk.java.net Hello, Recently I tried to compile JDK9 on OS X, I've found two issues related to installing debug symbols, which on OSX are package-folders. 1. Install-file macro doesn't remove dSYM folder, as used rm -f, instead of rm -rf 2. There was additional parenthesis in Dist.gmk which caused dSYM not to be copied. The overview of changes is attached. Kind regards, Radek Smogura From rsmogura at outlook.com Tue Jun 21 21:33:44 2016 From: rsmogura at outlook.com (=?utf-8?B?UmFkb3PFgmF3IFNtb2d1cmE=?=) Date: Tue, 21 Jun 2016 21:33:44 +0000 Subject: JDK debug builds on OSX copying dSYM In-Reply-To: References: Message-ID: <1030E294-0E3B-4D1D-BA23-357E94A8CF9C@outlook.com> Hi Vladimir, I?m so sorry, I haven?t checked for such list and thank you for forwarding :) Bets regards, Radek > On 21 Jun 2016, at 22:31, Vladimir Kozlov wrote: > > Thank you, Radek > > This should be reviewed in 'build' mailing list. > > Thanks, > Vladimir > > -------- Forwarded Message -------- > Subject: JDK debug builds on OSX copying dSYM > Date: Mon, 20 Jun 2016 21:01:48 +0000 > From: Rados?aw Smogura > To: hotspot-compiler-dev at openjdk.java.net > > Hello, > > Recently I tried to compile JDK9 on OS X, I've found two issues related to installing debug symbols, which on OSX are package-folders. > > 1. Install-file macro doesn't remove dSYM folder, as used rm -f, instead of rm -rf > 2. There was additional parenthesis in Dist.gmk which caused dSYM not to be copied. > > The overview of changes is attached. > > Kind regards, > Radek Smogura > > From serguei.spitsyn at oracle.com Wed Jun 22 00:28:24 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Jun 2016 17:28:24 -0700 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <2566893c-09ba-f31a-4495-7d315872e79a@oracle.com> References: <57690EBB.2010007@oracle.com> <2566893c-09ba-f31a-4495-7d315872e79a@oracle.com> Message-ID: <5769DBA8.7090003@oracle.com> Hi Harold, Thank you for the review! Serguei On 6/21/16 09:42, harold seigel wrote: > Hi Serguei, > > The hotspot changes look good. > > > Thanks, Harold > > > On 6/21/2016 5:54 AM, serguei.spitsyn at oracle.com wrote: >> >> Please, review the Jigsaw fix for the enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8159145 >> >> >> The Hotspot webrev: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ >> >> >> The Jdk webrev: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >> >> >> >> Summary: >> >> JVM TI agents that instrument code in named modules need the Module >> at class load time. >> >> One way to do this is by introducing a new ClassFileLoadHook that >> takes an additional parameter but this approach is disruptive. >> The alternative option is a JVM TI function that maps a classloader >> + package name to a module. >> We were initially not confident with this approach so we introduced >> it as JVM function JVM_GetModuleByPackageName. >> Based on experience to date then this approach seems okay and so >> this function needs to be promoted to a JVMTI function. >> >> This fix is to introduce new JVMTI function GetModuleByPackageName. >> It includes new jtreg test with native JVMTI agent. >> >> A CCC is fast-tracked and getting an approval is in progress. >> >> Testing: >> Run newly developed jtreg test. >> >> Thanks, >> Serguei > From david.holmes at oracle.com Wed Jun 22 00:51:39 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jun 2016 10:51:39 +1000 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <57698069.80902@oracle.com> References: <57698069.80902@oracle.com> Message-ID: <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> Hi Lois, Initial question: what is the platform classloader versus the application classloader? Thanks, David On 22/06/2016 3:59 AM, Lois Foltan wrote: > Hello, > > Please review the following fix: > > Webrev: > http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262/webrev/ > > Bug: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only > When Neccessary And Wait Until ClassLoader's Aliveness Determined > https://bugs.openjdk.java.net/browse/JDK-8159262 > > Summary: > In ClassLoaderDataGraph::do_unloading(), the decision to walk each > ClassLoader's PackageEntry exports and ModuleEntry's reads list was > occurring too soon, before the aliveness of all class loaders was > determined. The walk has been moved to immediately after and only alive > ClassLoader's PackageEntry and ModuleEntry lists are walked. > > The other piece to this fix is that the lists themselves were being > unnecessarily walked if only modules on any given list were either: > 1. defined to the same class loader as either the package being > exported or the module that a read edge was being > established from. Thus both modules in this equation have the > same life cycle. > 2. or defined to one of the three builtin class loaders (boot, > application or platform) which never die > > Test: > - java/io, java/lang/, java/util, all Hotspot jtreg tests, JCK vm & lang > - full hotspot nightly RBT run in progress From erik.joelsson at oracle.com Wed Jun 22 01:18:21 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 21 Jun 2016 18:18:21 -0700 Subject: JDK debug builds on OSX copying dSYM In-Reply-To: <1030E294-0E3B-4D1D-BA23-357E94A8CF9C@outlook.com> References: <1030E294-0E3B-4D1D-BA23-357E94A8CF9C@outlook.com> Message-ID: <5769E75D.2040107@oracle.com> The parentheses is definitely a bug, but I don't see why we need recursive delete by default. In what situation is the *.dSYM dir not being deleted? I did notice that things got weird in NativeCompilation.gmk which I fixed like this: diff -r 1db1ada70b16 make/common/NativeCompilation.gmk --- a/make/common/NativeCompilation.gmk +++ b/make/common/NativeCompilation.gmk @@ -833,7 +833,8 @@ # The dependency on TARGET is needed on windows for debuginfo files # to be rebuilt properly. $$($1_OUTPUT_DIR)/% : $$($1_OBJECT_DIR)/% $$($1_TARGET) - # Use cp -r since on macosx, the dSYM is a directory + # Use -r since on macosx, the dSYM is a directory + $(RM) -r $$@ $(CP) -r $$< $$@ endif /Erik On 2016-06-21 14:33, Rados?aw Smogura wrote: > Hi Vladimir, > > I?m so sorry, I haven?t checked for such list and thank you for forwarding :) > > Bets regards, > Radek >> On 21 Jun 2016, at 22:31, Vladimir Kozlov wrote: >> >> Thank you, Radek >> >> This should be reviewed in 'build' mailing list. >> >> Thanks, >> Vladimir >> >> -------- Forwarded Message -------- >> Subject: JDK debug builds on OSX copying dSYM >> Date: Mon, 20 Jun 2016 21:01:48 +0000 >> From: Rados?aw Smogura >> To: hotspot-compiler-dev at openjdk.java.net >> >> Hello, >> >> Recently I tried to compile JDK9 on OS X, I've found two issues related to installing debug symbols, which on OSX are package-folders. >> >> 1. Install-file macro doesn't remove dSYM folder, as used rm -f, instead of rm -rf >> 2. There was additional parenthesis in Dist.gmk which caused dSYM not to be copied. >> >> The overview of changes is attached. >> >> Kind regards, >> Radek Smogura >> >> From serguei.spitsyn at oracle.com Wed Jun 22 01:31:39 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Jun 2016 18:31:39 -0700 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <57698069.80902@oracle.com> References: <57698069.80902@oracle.com> Message-ID: <5769EA7B.9050207@oracle.com> Lois, It looks good. Thanks, Serguei On 6/21/16 10:59, Lois Foltan wrote: > Hello, > > Please review the following fix: > > Webrev: > http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262/webrev/ > > Bug: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only > When Neccessary And Wait Until ClassLoader's Aliveness Determined > https://bugs.openjdk.java.net/browse/JDK-8159262 > > Summary: > In ClassLoaderDataGraph::do_unloading(), the decision to walk each > ClassLoader's PackageEntry exports and ModuleEntry's reads list was > occurring too soon, before the aliveness of all class loaders was > determined. The walk has been moved to immediately after and only > alive ClassLoader's PackageEntry and ModuleEntry lists are walked. > > The other piece to this fix is that the lists themselves were being > unnecessarily walked if only modules on any given list were either: > 1. defined to the same class loader as either the package being > exported or the module that a read edge was being > established from. Thus both modules in this equation have the > same life cycle. > 2. or defined to one of the three builtin class loaders (boot, > application or platform) which never die > > Test: > - java/io, java/lang/, java/util, all Hotspot jtreg tests, JCK vm & lang > - full hotspot nightly RBT run in progress From mandy.chung at oracle.com Wed Jun 22 03:33:39 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 21 Jun 2016 20:33:39 -0700 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> Message-ID: <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> Platform class loader [1] is previously known as the extension class loader. We have deprivileged several Java SE modules to be defined by the platform class loader instead of the boot loader. They are not granted with all permissions by default. The class spec of ClassLoader has a section [2] to describe the built-in class loaders. Mandy [1] http://download.java.net/java/jdk9/docs/api/java/lang/ClassLoader.html#getPlatformClassLoader-- [2] http://download.java.net/java/jdk9/docs/api/java/lang/ClassLoader.html#builtinLoaders > On Jun 21, 2016, at 5:51 PM, David Holmes wrote: > > Hi Lois, > > Initial question: what is the platform classloader versus the application classloader? > > Thanks, > David > > On 22/06/2016 3:59 AM, Lois Foltan wrote: >> Hello, >> >> Please review the following fix: >> >> Webrev: >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262/webrev/ >> >> Bug: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only >> When Neccessary And Wait Until ClassLoader's Aliveness Determined >> https://bugs.openjdk.java.net/browse/JDK-8159262 >> >> Summary: >> In ClassLoaderDataGraph::do_unloading(), the decision to walk each >> ClassLoader's PackageEntry exports and ModuleEntry's reads list was >> occurring too soon, before the aliveness of all class loaders was >> determined. The walk has been moved to immediately after and only alive >> ClassLoader's PackageEntry and ModuleEntry lists are walked. >> >> The other piece to this fix is that the lists themselves were being >> unnecessarily walked if only modules on any given list were either: >> 1. defined to the same class loader as either the package being >> exported or the module that a read edge was being >> established from. Thus both modules in this equation have the >> same life cycle. >> 2. or defined to one of the three builtin class loaders (boot, >> application or platform) which never die >> >> Test: >> - java/io, java/lang/, java/util, all Hotspot jtreg tests, JCK vm & lang >> - full hotspot nightly RBT run in progress From david.holmes at oracle.com Wed Jun 22 03:43:43 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jun 2016 13:43:43 +1000 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> Message-ID: <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> On 22/06/2016 1:33 PM, Mandy Chung wrote: > Platform class loader [1] is previously known as the extension class loader. We have deprivileged several Java SE modules to be defined by the platform class loader instead of the boot loader. They are not granted with all permissions by default. The class spec of ClassLoader has a section [2] to describe the built-in class loaders. Thanks Mandy. I was surprised to see the addition of code to query if the application classloader as we have always had such code: SystemDictionary::java_system_loader() So AFAICS this addition is not needed: 178 // Returns true if the passed class loader is the application class loader. 179 bool SystemDictionary::is_application_class_loader(Handle class_loader) { 180 if (class_loader.is_null()) { 181 return false; 182 } 183 return (class_loader->klass() == SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass()); 184 } But for that matter why do we have SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass and SystemDictionary::java_system_loader ? They are, or should be, the same thing. David > Mandy > [1] http://download.java.net/java/jdk9/docs/api/java/lang/ClassLoader.html#getPlatformClassLoader-- > [2] http://download.java.net/java/jdk9/docs/api/java/lang/ClassLoader.html#builtinLoaders > >> On Jun 21, 2016, at 5:51 PM, David Holmes wrote: >> >> Hi Lois, >> >> Initial question: what is the platform classloader versus the application classloader? >> >> Thanks, >> David >> >> On 22/06/2016 3:59 AM, Lois Foltan wrote: >>> Hello, >>> >>> Please review the following fix: >>> >>> Webrev: >>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262/webrev/ >>> >>> Bug: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only >>> When Neccessary And Wait Until ClassLoader's Aliveness Determined >>> https://bugs.openjdk.java.net/browse/JDK-8159262 >>> >>> Summary: >>> In ClassLoaderDataGraph::do_unloading(), the decision to walk each >>> ClassLoader's PackageEntry exports and ModuleEntry's reads list was >>> occurring too soon, before the aliveness of all class loaders was >>> determined. The walk has been moved to immediately after and only alive >>> ClassLoader's PackageEntry and ModuleEntry lists are walked. >>> >>> The other piece to this fix is that the lists themselves were being >>> unnecessarily walked if only modules on any given list were either: >>> 1. defined to the same class loader as either the package being >>> exported or the module that a read edge was being >>> established from. Thus both modules in this equation have the >>> same life cycle. >>> 2. or defined to one of the three builtin class loaders (boot, >>> application or platform) which never die >>> >>> Test: >>> - java/io, java/lang/, java/util, all Hotspot jtreg tests, JCK vm & lang >>> - full hotspot nightly RBT run in progress > From mandy.chung at oracle.com Wed Jun 22 04:21:54 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 21 Jun 2016 21:21:54 -0700 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> Message-ID: <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> > On Jun 21, 2016, at 8:43 PM, David Holmes wrote: > > On 22/06/2016 1:33 PM, Mandy Chung wrote: >> Platform class loader [1] is previously known as the extension class loader. We have deprivileged several Java SE modules to be defined by the platform class loader instead of the boot loader. They are not granted with all permissions by default. The class spec of ClassLoader has a section [2] to describe the built-in class loaders. > > Thanks Mandy. I was surprised to see the addition of code to query if the application classloader as we have always had such code: > > SystemDictionary::java_system_loader() > > So AFAICS this addition is not needed: > > 178 // Returns true if the passed class loader is the application class loader. > 179 bool SystemDictionary::is_application_class_loader(Handle class_loader) { > 180 if (class_loader.is_null()) { > 181 return false; > 182 } > 183 return (class_loader->klass() == SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass()); > 184 } > This might be better to rename it to is_builtin_application_loader? > But for that matter why do we have SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass and SystemDictionary::java_system_loader ? They are, or should be, the same thing. > In almost all cases except when -Djava.system.class.loader is set to a custom class loader: java_system_loader may be a custom system class loader which is not an instance of jdk_internal_loader_ClassLoaders_AppClassLoader_klass. Mandy From david.holmes at oracle.com Wed Jun 22 05:15:52 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jun 2016 15:15:52 +1000 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> Message-ID: <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> On 22/06/2016 2:21 PM, Mandy Chung wrote: > >> On Jun 21, 2016, at 8:43 PM, David Holmes wrote: >> >> On 22/06/2016 1:33 PM, Mandy Chung wrote: >>> Platform class loader [1] is previously known as the extension class loader. We have deprivileged several Java SE modules to be defined by the platform class loader instead of the boot loader. They are not granted with all permissions by default. The class spec of ClassLoader has a section [2] to describe the built-in class loaders. >> >> Thanks Mandy. I was surprised to see the addition of code to query if the application classloader as we have always had such code: >> >> SystemDictionary::java_system_loader() >> >> So AFAICS this addition is not needed: >> >> 178 // Returns true if the passed class loader is the application class loader. >> 179 bool SystemDictionary::is_application_class_loader(Handle class_loader) { >> 180 if (class_loader.is_null()) { >> 181 return false; >> 182 } >> 183 return (class_loader->klass() == SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass()); >> 184 } >> > > This might be better to rename it to is_builtin_application_loader? Maybe ... >> But for that matter why do we have SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass and SystemDictionary::java_system_loader ? They are, or should be, the same thing. >> > > In almost all cases except when -Djava.system.class.loader is set to a custom class loader: > > java_system_loader may be a custom system class loader which is not an instance of jdk_internal_loader_ClassLoaders_AppClassLoader_klass. ... so we're not really asking if it is the system/application loader but if it is a particular type of classloader that is fulfilling that role? Which then begs the question as to what we are doing that depends on a specific type of classloader and what we do if not dealing with such a type ?? Thanks, David > Mandy > From shafi.s.ahmad at oracle.com Wed Jun 22 05:28:02 2016 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Tue, 21 Jun 2016 22:28:02 -0700 (PDT) Subject: [8u] RFR for JDK-8156836: Test test/compiler/jsr292/VMAnonymousClasses.java fails with JTREG 4.2 b02 In-Reply-To: References: <7a3e12e9-3e79-4730-8547-857a84c96b4b@default> Message-ID: <7e8a852f-bf5a-425b-87d7-2be9326504b1@default> Thanks Vladimir. I need a second reviewer. Regards, Shafi > -----Original Message----- > From: Vladimir Kozlov > Sent: Wednesday, June 22, 2016 1:38 AM > To: Shafi Ahmad; hotspot-dev at openjdk.java.net > Subject: Re: [8u] RFR for JDK-8156836: Test > test/compiler/jsr292/VMAnonymousClasses.java fails with JTREG 4.2 b02 > > Good. > > Thanks, > Vladimir > > On 6/21/16 2:21 AM, Shafi Ahmad wrote: > > Hi, > > > > Please review the code change for "JDK-8156836: Test > test/compiler/jsr292/VMAnonymousClasses.java fails with JTREG 4.2 b02" to > jdk8u. > > > > Summary: > > Test case failed with Parse Exception: '[-Xbatch]: vm option(s) found, need > to specify /othervm' as '/othervm' is not specified in the annotation section. > > Current modification add this at appropriate place. > > > > Jdk8 bug: https://bugs.openjdk.java.net/browse/JDK-8156836 > > Webrev link: http://cr.openjdk.java.net/~shshahma/8156836/webrev.00/ > > > > Testing: As the change is in the test case so I run only this test case. > > > > Regards, > > Shafi > > From serguei.spitsyn at oracle.com Wed Jun 22 06:39:57 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Jun 2016 23:39:57 -0700 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: References: <57690EBB.2010007@oracle.com> <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> <57691B87.20104@oracle.com> <57695628.4000200@oracle.com> Message-ID: <576A32BD.4040709@oracle.com> Hi Christian, I understand that. Will do my best to achieve this. There are some corner cases however. Thanks, Serguei On 6/21/16 10:06, Christian Tornqvist wrote: > > Hi Serguei, > > >Will check if this works well in this case. > > >The unique error messages are already printed in the native code. > > Yes, they?re printed on stdout/stderr but the test will fail with a > ?Test failed? exception and our failure matching system wouldn?t be > able to tell why it failed. It?d be a lot nicer if it?d just throw an > exception when one of the checks in the native code failed. > > Thanks, > > Christian > > *From:*serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] > *Sent:* Tuesday, June 21, 2016 10:59 AM > *To:* Christian Tornqvist ; 'Alan > Bateman' ; > serviceability-dev at openjdk.java.net; 'Alexander Kulyakhtin' > ; hotspot-dev at openjdk.java.net > *Subject:* Re: Jigsaw Enhancement RFR: 8159145 Add JVMTI function > GetModuleByPackageName > > Hi Christian, > > Thank you for looking at it! > > > On 6/21/16 04:56, Christian Tornqvist wrote: > > Hi Serguei, > > I?ve only looked at the test code so far, here are some comments: > > * You?re not allowed to call System.exit in a jtreg test. If > something fails, you need to throw an exception. > > > Ok, an exception is Ok with me. > > > * Instead of a run() method you could simply collapse all this > into the main method like this: > > assertEQ(check(), 0); > > > Will check if this works for me. > > > > > > * Would it make sense to throw exceptions with useful error > messages from the JNI code instead of returning failed status > codes? Our error matching system would work a lot better with > unique error messages. > > > Will check if this works well in this case. > The unique error messages are already printed in the native code. > > Thanks, > Serguei > > > Thanks, > > Christian > > *From:*serguei.spitsyn at oracle.com > > [mailto:serguei.spitsyn at oracle.com] > *Sent:* Tuesday, June 21, 2016 6:49 AM > *To:* Alan Bateman > ; > serviceability-dev at openjdk.java.net > ; Christian T?rnqvist > > ; Alexander Kulyakhtin > > ; > hotspot-dev at openjdk.java.net > Developers > > *Subject:* Re: Jigsaw Enhancement RFR: 8159145 Add JVMTI function > GetModuleByPackageName > > On 6/21/16 03:23, Alan Bateman wrote: > > On 21/06/2016 10:54, serguei.spitsyn at oracle.com > wrote: > > > Please, review the Jigsaw fix for the enhancement: > https://bugs.openjdk.java.net/browse/JDK-8159145 > > > The Hotspot webrev: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ > > The Jdk webrev: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ > > Serguei - can you put the patches on cr.openjdk.java.net? > > > Sorry. > My initial plan was to write an nsk.jvmti test and review it on a > confidential mailing list. > It is why I put the webrevs on the non-public server. > Forgot to switch the server when the test was converted into the > jtreg format. > > The public webrevs are: > > Hotspot: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ > > > Jdk: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ > > > > Thanks, > Serguei > > > > > > -Alan > From aph at redhat.com Wed Jun 22 08:29:34 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 22 Jun 2016 09:29:34 +0100 Subject: [aarch64-port-dev ] RFR: 8160006 Fix AArch64 after changes made by 8151661 In-Reply-To: <57697CEE.6060100@redhat.com> References: <57697CEE.6060100@redhat.com> Message-ID: <576A4C6E.5010401@redhat.com> On 21/06/16 18:44, Andrew Dinn wrote: > Please review the following webrev against hs-comp head which provides a > patch to fix the AArch64 ad file after it is broken by JDK-8151661. > > http://cr.openjdk.java.net/~adinn/8160006/webrev.00/ > > n.b. The webrev also includes the changes for 8151661 (which has not yet > been posted to hs-comp). That looks like a considerable improvement. Andrew. From Alan.Bateman at oracle.com Wed Jun 22 08:44:03 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Jun 2016 09:44:03 +0100 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <57691B87.20104@oracle.com> References: <57690EBB.2010007@oracle.com> <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> <57691B87.20104@oracle.com> Message-ID: <89068a44-f213-e75b-1984-90e649ef58bf@oracle.com> Serguei, One other question - are you going to drop the (temporary) JVM_* function and update the JPLISAgent as part of this or are you leaving that to a follow-on issue? -Alan From serguei.spitsyn at oracle.com Wed Jun 22 09:00:29 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jun 2016 02:00:29 -0700 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <89068a44-f213-e75b-1984-90e649ef58bf@oracle.com> References: <57690EBB.2010007@oracle.com> <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> <57691B87.20104@oracle.com> <89068a44-f213-e75b-1984-90e649ef58bf@oracle.com> Message-ID: <576A53AD.2090209@oracle.com> Alan, Now I prefer to separate both changes. My plan was to separate dropping the JVM_* function as we discussed previously. The JPLISAgent can be updated as a part of adding back the transform method class loader argument as the change is pretty trivial. But I can make this change as a part of this fix if you think it is more appropriate. Thanks, Serguei On 6/22/16 01:44, Alan Bateman wrote: > Serguei, > > One other question - are you going to drop the (temporary) JVM_* > function and update the JPLISAgent as part of this or are you leaving > that to a follow-on issue? > > -Alan From Alan.Bateman at oracle.com Wed Jun 22 09:02:11 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Jun 2016 10:02:11 +0100 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576A53AD.2090209@oracle.com> References: <57690EBB.2010007@oracle.com> <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> <57691B87.20104@oracle.com> <89068a44-f213-e75b-1984-90e649ef58bf@oracle.com> <576A53AD.2090209@oracle.com> Message-ID: <92df23e5-2256-01f9-3585-9f5ed364706c@oracle.com> On 22/06/2016 10:00, serguei.spitsyn at oracle.com wrote: > Alan, > > Now I prefer to separate both changes. > My plan was to separate dropping the JVM_* function as we discussed > previously. > The JPLISAgent can be updated as a part of adding back the transform > method > class loader argument as the change is pretty trivial. > But I can make this change as a part of this fix if you think it is > more appropriate. > Two steps is okay with me, I just want to make sure that this part is covered. -Alan From serguei.spitsyn at oracle.com Wed Jun 22 09:09:23 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jun 2016 02:09:23 -0700 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <92df23e5-2256-01f9-3585-9f5ed364706c@oracle.com> References: <57690EBB.2010007@oracle.com> <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> <57691B87.20104@oracle.com> <89068a44-f213-e75b-1984-90e649ef58bf@oracle.com> <576A53AD.2090209@oracle.com> <92df23e5-2256-01f9-3585-9f5ed364706c@oracle.com> Message-ID: <576A55C3.4060305@oracle.com> On 6/22/16 02:02, Alan Bateman wrote: > > > On 22/06/2016 10:00, serguei.spitsyn at oracle.com wrote: >> Alan, >> >> Now I prefer to separate both changes. >> My plan was to separate dropping the JVM_* function as we discussed >> previously. >> The JPLISAgent can be updated as a part of adding back the transform >> method >> class loader argument as the change is pretty trivial. >> But I can make this change as a part of this fix if you think it is >> more appropriate. >> > Two steps is okay with me, I just want to make sure that this part is > covered. Yes, I keep it in mind. Thanks! Serguei > > -Alan From adinn at redhat.com Wed Jun 22 09:29:54 2016 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 22 Jun 2016 10:29:54 +0100 Subject: [aarch64-port-dev ] RFR: 8160006 Fix AArch64 after changes made by 8151661 In-Reply-To: <576A4C6E.5010401@redhat.com> References: <57697CEE.6060100@redhat.com> <576A4C6E.5010401@redhat.com> Message-ID: <576A5A92.5090904@redhat.com> On 22/06/16 09:29, Andrew Haley wrote: > On 21/06/16 18:44, Andrew Dinn wrote: >> Please review the following webrev against hs-comp head which provides a >> patch to fix the AArch64 ad file after it is broken by JDK-8151661. >> >> http://cr.openjdk.java.net/~adinn/8160006/webrev.00/ >> >> n.b. The webrev also includes the changes for 8151661 (which has not yet >> been posted to hs-comp). > > That looks like a considerable improvement. Thanks for the review. It seems Vladimir has already pushed the change so I'm glad you approve :-) regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From volker.simonis at gmail.com Wed Jun 22 09:35:29 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 22 Jun 2016 11:35:29 +0200 Subject: [8u] request for approval: "8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions" Message-ID: Hi, could you please approve the backport of the following ppc64-only fixe to jdk8u-dev: 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions Bug: https://bugs.openjdk.java.net/browse/JDK-8158260 Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260/ Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-June/023347.html URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5f3687f2143c The original change has a JTreg test which uses the new jdk.internal.misc.Unsafe class and some of its features like Unsafe.unalignedAccess() which are not available in jdk8 so I propose to exclude the test from the downport. Without the test the change only touches a ppc64 specific file and applies cleanly to jdk8u-dev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260_8u As this backport is now truly "ppc64-only", can I push it directly to jdk8u-dev/hotspot or do I still need a sponsor? Thank you and best regards, Volker From serguei.spitsyn at oracle.com Wed Jun 22 11:07:53 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jun 2016 04:07:53 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <57690EBB.2010007@oracle.com> References: <57690EBB.2010007@oracle.com> Message-ID: <576A7189.6040809@oracle.com> Here are new hotspot webrev where I've fixed the comments from Alan and Christian. Hotspot: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.2 The Jdk webrev is the same: http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ Thanks, Serguei On 6/21/16 02:54, serguei.spitsyn at oracle.com wrote: > > Please, review the Jigsaw fix for the enhancement: > https://bugs.openjdk.java.net/browse/JDK-8159145 > > > The Hotspot webrev: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ > > The Jdk webrev: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ > > > Summary: > > JVM TI agents that instrument code in named modules need the Module at > class load time. > > One way to do this is by introducing a new ClassFileLoadHook that > takes an additional parameter but this approach is disruptive. > The alternative option is a JVM TI function that maps a classloader > + package name to a module. > We were initially not confident with this approach so we introduced > it as JVM function JVM_GetModuleByPackageName. > Based on experience to date then this approach seems okay and so > this function needs to be promoted to a JVMTI function. > > This fix is to introduce new JVMTI function GetModuleByPackageName. > It includes new jtreg test with native JVMTI agent. > > A CCC is fast-tracked and getting an approval is in progress. > > Testing: > Run newly developed jtreg test. > > Thanks, > Serguei From lois.foltan at oracle.com Wed Jun 22 11:10:08 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 22 Jun 2016 07:10:08 -0400 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> Message-ID: <576A7210.3000402@oracle.com> On 6/22/2016 1:15 AM, David Holmes wrote: > On 22/06/2016 2:21 PM, Mandy Chung wrote: >> >>> On Jun 21, 2016, at 8:43 PM, David Holmes >>> wrote: >>> >>> On 22/06/2016 1:33 PM, Mandy Chung wrote: >>>> Platform class loader [1] is previously known as the extension >>>> class loader. We have deprivileged several Java SE modules to be >>>> defined by the platform class loader instead of the boot loader. >>>> They are not granted with all permissions by default. The class >>>> spec of ClassLoader has a section [2] to describe the built-in >>>> class loaders. >>> >>> Thanks Mandy. I was surprised to see the addition of code to query >>> if the application classloader as we have always had such code: >>> >>> SystemDictionary::java_system_loader() >>> >>> So AFAICS this addition is not needed: >>> >>> 178 // Returns true if the passed class loader is the application >>> class loader. >>> 179 bool SystemDictionary::is_application_class_loader(Handle >>> class_loader) { >>> 180 if (class_loader.is_null()) { >>> 181 return false; >>> 182 } >>> 183 return (class_loader->klass() == >>> SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass()); >>> 184 } >>> >> >> This might be better to rename it to is_builtin_application_loader? > > Maybe ... First, thank you Mandy and David for reviewing. I actually like the suggestion of renaming this method to is_builtin_application_loader with added comments in SystemDictionary::is_builtin_application_class_loader as to why exactly the check is against SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass and not _java_system_loader. > >>> But for that matter why do we have >>> SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass >>> and SystemDictionary::java_system_loader ? They are, or should be, >>> the same thing. >>> >> >> In almost all cases except when -Djava.system.class.loader is set to >> a custom class loader: >> >> java_system_loader may be a custom system class loader which is not >> an instance of jdk_internal_loader_ClassLoaders_AppClassLoader_klass. > > ... so we're not really asking if it is the system/application loader > but if it is a particular type of classloader that is fulfilling that > role? > > Which then begs the question as to what we are doing that depends on a > specific type of classloader and what we do if not dealing with such a > type ?? For this RFR's that differentiation is important. If someone defines their own system/application loader, I suspect then that they have control over its life cycle. The fact that it will not die during the application's life can not be assumed. Thus any modules defined to that custom system/application loader may indeed die and need to get purged from packages' export or modules' reads lists. Thanks, Lois > > Thanks, > David > >> Mandy >> From lois.foltan at oracle.com Wed Jun 22 11:10:55 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 22 Jun 2016 07:10:55 -0400 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <5769EA7B.9050207@oracle.com> References: <57698069.80902@oracle.com> <5769EA7B.9050207@oracle.com> Message-ID: <576A723F.8080608@oracle.com> Thanks Serguei for the review! Lois On 6/21/2016 9:31 PM, serguei.spitsyn at oracle.com wrote: > Lois, > > It looks good. > > Thanks, > Serguei > > > On 6/21/16 10:59, Lois Foltan wrote: >> Hello, >> >> Please review the following fix: >> >> Webrev: >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262/webrev/ >> >> Bug: Walking PackageEntry Export and ModuleEntry Reads Must Occur >> Only When Neccessary And Wait Until ClassLoader's Aliveness Determined >> https://bugs.openjdk.java.net/browse/JDK-8159262 >> >> Summary: >> In ClassLoaderDataGraph::do_unloading(), the decision to walk each >> ClassLoader's PackageEntry exports and ModuleEntry's reads list was >> occurring too soon, before the aliveness of all class loaders was >> determined. The walk has been moved to immediately after and only >> alive ClassLoader's PackageEntry and ModuleEntry lists are walked. >> >> The other piece to this fix is that the lists themselves were being >> unnecessarily walked if only modules on any given list were either: >> 1. defined to the same class loader as either the package being >> exported or the module that a read edge was being >> established from. Thus both modules in this equation have >> the same life cycle. >> 2. or defined to one of the three builtin class loaders (boot, >> application or platform) which never die >> >> Test: >> - java/io, java/lang/, java/util, all Hotspot jtreg tests, JCK vm & lang >> - full hotspot nightly RBT run in progress > From david.holmes at oracle.com Wed Jun 22 12:51:46 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jun 2016 22:51:46 +1000 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <576A7210.3000402@oracle.com> References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> Message-ID: On 22/06/2016 9:10 PM, Lois Foltan wrote: > > On 6/22/2016 1:15 AM, David Holmes wrote: >> On 22/06/2016 2:21 PM, Mandy Chung wrote: >>> >>>> On Jun 21, 2016, at 8:43 PM, David Holmes >>>> wrote: >>>> >>>> On 22/06/2016 1:33 PM, Mandy Chung wrote: >>>>> Platform class loader [1] is previously known as the extension >>>>> class loader. We have deprivileged several Java SE modules to be >>>>> defined by the platform class loader instead of the boot loader. >>>>> They are not granted with all permissions by default. The class >>>>> spec of ClassLoader has a section [2] to describe the built-in >>>>> class loaders. >>>> >>>> Thanks Mandy. I was surprised to see the addition of code to query >>>> if the application classloader as we have always had such code: >>>> >>>> SystemDictionary::java_system_loader() >>>> >>>> So AFAICS this addition is not needed: >>>> >>>> 178 // Returns true if the passed class loader is the application >>>> class loader. >>>> 179 bool SystemDictionary::is_application_class_loader(Handle >>>> class_loader) { >>>> 180 if (class_loader.is_null()) { >>>> 181 return false; >>>> 182 } >>>> 183 return (class_loader->klass() == >>>> SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass()); >>>> >>>> 184 } >>>> >>> >>> This might be better to rename it to is_builtin_application_loader? >> >> Maybe ... > > First, thank you Mandy and David for reviewing. I actually like the > suggestion of renaming this method to is_builtin_application_loader with > added comments in SystemDictionary::is_builtin_application_class_loader > as to why exactly the check is against > SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass > and not _java_system_loader. > >> >>>> But for that matter why do we have >>>> SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass >>>> and SystemDictionary::java_system_loader ? They are, or should be, >>>> the same thing. >>>> >>> >>> In almost all cases except when -Djava.system.class.loader is set to >>> a custom class loader: >>> >>> java_system_loader may be a custom system class loader which is not >>> an instance of jdk_internal_loader_ClassLoaders_AppClassLoader_klass. >> >> ... so we're not really asking if it is the system/application loader >> but if it is a particular type of classloader that is fulfilling that >> role? >> >> Which then begs the question as to what we are doing that depends on a >> specific type of classloader and what we do if not dealing with such a >> type ?? > > For this RFR's that differentiation is important. If someone defines > their own system/application loader, I suspect then that they have > control over its life cycle. The fact that it will not die during the > application's life can not be assumed. Thus any modules defined to that > custom system/application loader may indeed die and need to get purged > from packages' export or modules' reads lists. How do you envisage any system classloader "dying" ?? David > Thanks, > Lois > >> >> Thanks, >> David >> >>> Mandy >>> > From Alan.Bateman at oracle.com Wed Jun 22 12:56:23 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Jun 2016 13:56:23 +0100 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> Message-ID: <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> On 22/06/2016 13:51, David Holmes wrote: > > How do you envisage any system classloader "dying" ?? The system class loader (be it the built-in application class loader or a custom system class loader configured via -Djava.system.class.loader) will/can never be GC'ed. ClassLoader.getSystemClassLoader() always returns a reference to it (for example). -Alan From serguei.spitsyn at oracle.com Wed Jun 22 13:05:17 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jun 2016 06:05:17 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576A7189.6040809@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> Message-ID: <576A8D0D.3090907@oracle.com> I've updated the libGetModuleByPkgTest.c in place in the webrev #2 with minor improvements. Sorry, if it spoiled your work. Thanks, Serguei On 6/22/16 04:07, serguei.spitsyn at oracle.com wrote: > Here are new hotspot webrev where I've fixed the comments from Alan > and Christian. > > Hotspot: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.2 > > > The Jdk webrev is the same: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ > > > Thanks, > Serguei > > > On 6/21/16 02:54, serguei.spitsyn at oracle.com wrote: >> >> Please, review the Jigsaw fix for the enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8159145 >> >> >> The Hotspot webrev: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ >> >> The Jdk webrev: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >> >> >> Summary: >> >> JVM TI agents that instrument code in named modules need the Module >> at class load time. >> >> One way to do this is by introducing a new ClassFileLoadHook that >> takes an additional parameter but this approach is disruptive. >> The alternative option is a JVM TI function that maps a classloader >> + package name to a module. >> We were initially not confident with this approach so we introduced >> it as JVM function JVM_GetModuleByPackageName. >> Based on experience to date then this approach seems okay and so >> this function needs to be promoted to a JVMTI function. >> >> This fix is to introduce new JVMTI function GetModuleByPackageName. >> It includes new jtreg test with native JVMTI agent. >> >> A CCC is fast-tracked and getting an approval is in progress. >> >> Testing: >> Run newly developed jtreg test. >> >> Thanks, >> Serguei > From volker.simonis at gmail.com Wed Jun 22 14:29:47 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 22 Jun 2016 16:29:47 +0200 Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation on ppc64 and sparc In-Reply-To: <5768FE79.2060301@oracle.com> References: <27dde86d-f7b3-3093-e500-cd3c9156811f@oracle.com> <5767AD68.8090500@oracle.com> <5767B078.8030102@oracle.com> <5768FE79.2060301@oracle.com> Message-ID: On Tue, Jun 21, 2016 at 10:44 AM, Tobias Hartmann wrote: > Hi Volker, > > On 21.06.2016 09:37, Volker Simonis wrote: >> On Mon, Jun 20, 2016 at 10:59 AM, Tobias Hartmann >> wrote: >>> Hi Volker, >>> >>> On 20.06.2016 10:52, Volker Simonis wrote: >>>> Hi Tobias, >>>> >>>> thanks for sponsoring! I've uploaded a new webrev with you and >>>> Vladimir as reviewers: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v2/ >>>> >>>> You can find the changeset there: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v2/hotspot.changeset >>> >>> Thanks, I just noticed that the test has >>> >>> 26 * @bug 9999999 >>> >>> You can fix this in-place. I'll then run the required pre-integration testing (~24h) and push your change afterwards. >>> >> >> Hi Tobias, >> >> good catch and sorry, I somehow missed your mail yesterday. >> >> You can find the new changeset here: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v3/hotspot.changeset > > Thank you! > > I just looked at the test results and unfortunately DisableOSRTest fails on all platforms (including SPARC) if -Xcomp is set: > > ----------System.err:(13/1215)---------- > java.lang.RuntimeException: "public static void DisableOSRTest.main(java.lang.String[]) throws java.lang.Exception" shouldn't be OSR compiled if running with -XX:-UseOnStackReplacement! > at DisableOSRTest.main(DisableOSRTest.java:59) > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base/Native Method) > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base/NativeMethodAccessorImpl.java:62) > at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base/DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(java.base/Method.java:531) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) > at java.lang.Thread.run(java.base/Thread.java:843) > > There are several OSR compilations in the log: > > 12916 4242 % b 4 DisableOSRTest::main @ 19 (61 bytes) > Hi Tobias, you're right! Thanks for finding this new problem:) I initially only fixed OSR from interpreted code. But C1 compiled code can also trigger an OSR request (and -Xcomp triggers a C1 compilation of main before it is invoked for the first time). Switching this off with the help of -XX:-UseOnStackReplacement never worked, but it was actually easy to fix. Please find the new change here: http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v4/ I think it would good if somebody (maybe the initial reviewers) could review the new C1 changes to prevent OSR in C1-compiled code. Thank you and best regards, Volker > Best regards, > Tobias > >> >> Thank you and best regards, >> Volker >> >> >>> Best regards, >>> Tobias >>> >>>> >>>> Thanks, >>>> Volker >>>> >>>> >>>> On Mon, Jun 20, 2016 at 10:46 AM, Tobias Hartmann >>>> wrote: >>>>> Hi Volker, >>>>> >>>>> you fix looks good to me! I can do the sponsoring, please just send me a changeset. >>>>> >>>>> Best regards, >>>>> Tobias >>>>> >>>>> On 20.06.2016 10:16, Volker Simonis wrote: >>>>>> Thanks Vladimir! >>>>>> >>>>>> .. I still need a sponsor :( >>>>>> >>>>>> Regards, >>>>>> Volker >>>>>> >>>>>> >>>>>> On Fri, Jun 17, 2016 at 10:53 PM, Vladimir Kozlov >>>>>> wrote: >>>>>>> Looks good. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> >>>>>>> On 6/17/16 2:22 AM, Volker Simonis wrote: >>>>>>>> >>>>>>>> Hi Goetz, >>>>>>>> >>>>>>>> thanks for the review. >>>>>>>> You're right, I've fixed the "else": >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v1/ >>>>>>>> >>>>>>>> Regards, >>>>>>>> Volker >>>>>>>> >>>>>>>> On Fri, Jun 17, 2016 at 11:08 AM, Lindenmaier, Goetz >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Volker, >>>>>>>>> >>>>>>>>> thanks for doing this fix, I also have run into this issue before ... >>>>>>>>> Looks good. >>>>>>>>> >>>>>>>>> Small nit: usually >>>>>>>>> } >>>>>>>>> else { >>>>>>>>> are on one line. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>>>>>>>> Behalf Of Volker Simonis >>>>>>>>>> Sent: Donnerstag, 16. Juni 2016 16:54 >>>>>>>>>> To: HotSpot Open Source Developers >>>>>>>>>> Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work >>>>>>>>>> together with -XX:+TieredCompilation on ppc64 and sparc >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> can I please have a review and sponsor for the following small change >>>>>>>>>> which fixes -XX:-UseOnStackReplacement to work together with >>>>>>>>>> -XX:+TieredCompilation: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620/ >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8159620 >>>>>>>>>> >>>>>>>>>> This is a long standing bug on SPARC and as the ppc64 template >>>>>>>>>> interpreter was initially forked from the SPARC implementation, it >>>>>>>>>> also manifests there. The problem is that in the case of tiered >>>>>>>>>> compilation the interpreter unconditionally calls >>>>>>>>>> InterpreterRuntime::frequency_counter_overflow if the back edge >>>>>>>>>> counter overflows. This triggers an OSR compilation, even if OSR was >>>>>>>>>> switched off with -XX:-UseOnStackReplacement. >>>>>>>>>> >>>>>>>>>> The fix is simple - just don't call >>>>>>>>>> InterpreterRuntime::frequency_counter_overflow if OSR has been >>>>>>>>>> switched off. >>>>>>>>>> >>>>>>>>>> Thank you and best regards, >>>>>>>>>> Volker From volker.simonis at gmail.com Wed Jun 22 14:34:23 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 22 Jun 2016 16:34:23 +0200 Subject: [8u] request for approval: "8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions" In-Reply-To: <20160622140754.GD3299@vimes> References: <20160622140754.GD3299@vimes> Message-ID: On Wed, Jun 22, 2016 at 4:07 PM, Rob McKenna wrote: > Approved assuming the HS folks are ok with the test situation. > Thanks Rob! Yes, let's wait for another HS review. > I'm not sure I get the sponsor question. If you are an approved committer to jdk8u-dev (which you appear to be) you can push, otherwise you would need a sponsor. As all hotspot changes have to go trough JPRT external committers are not allowed to directly push to HS repos - expect for changes which only touch platforms which aren't built and tested by Oracle anyway (e.g. ppc64 and aarch64). My initial change contained a shared test so I needed a sponsor whereas the downport only touches a ppc64 file. Regards, Volker > > -Rob > > On 22/06/16 11:35, Volker Simonis wrote: >> Hi, >> >> could you please approve the backport of the following ppc64-only fixe >> to jdk8u-dev: >> >> 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of >> illegal instructions >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8158260 >> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260/ >> Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-June/023347.html >> URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5f3687f2143c >> >> The original change has a JTreg test which uses the new >> jdk.internal.misc.Unsafe class and some of its features like >> Unsafe.unalignedAccess() which are not available in jdk8 so I propose >> to exclude the test from the downport. >> >> Without the test the change only touches a ppc64 specific file and >> applies cleanly to jdk8u-dev: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260_8u >> >> As this backport is now truly "ppc64-only", can I push it directly to >> jdk8u-dev/hotspot or do I still need a sponsor? >> >> Thank you and best regards, >> Volker From rob.mckenna at oracle.com Wed Jun 22 14:07:54 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 22 Jun 2016 15:07:54 +0100 Subject: [8u] request for approval: "8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions" In-Reply-To: References: Message-ID: <20160622140754.GD3299@vimes> Approved assuming the HS folks are ok with the test situation. I'm not sure I get the sponsor question. If you are an approved committer to jdk8u-dev (which you appear to be) you can push, otherwise you would need a sponsor. -Rob On 22/06/16 11:35, Volker Simonis wrote: > Hi, > > could you please approve the backport of the following ppc64-only fixe > to jdk8u-dev: > > 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of > illegal instructions > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158260 > Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260/ > Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-June/023347.html > URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5f3687f2143c > > The original change has a JTreg test which uses the new > jdk.internal.misc.Unsafe class and some of its features like > Unsafe.unalignedAccess() which are not available in jdk8 so I propose > to exclude the test from the downport. > > Without the test the change only touches a ppc64 specific file and > applies cleanly to jdk8u-dev: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260_8u > > As this backport is now truly "ppc64-only", can I push it directly to > jdk8u-dev/hotspot or do I still need a sponsor? > > Thank you and best regards, > Volker From lois.foltan at oracle.com Wed Jun 22 14:51:21 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 22 Jun 2016 10:51:21 -0400 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> Message-ID: <576AA5E9.9040408@oracle.com> On 6/22/2016 8:56 AM, Alan Bateman wrote: > > > On 22/06/2016 13:51, David Holmes wrote: >> >> How do you envisage any system classloader "dying" ?? > The system class loader (be it the built-in application class loader > or a custom system class loader configured via > -Djava.system.class.loader) will/can never be GC'ed. > ClassLoader.getSystemClassLoader() always returns a reference to it > (for example). Ahh, ok, I was being overly cautious, so no opportunity to reset the system class loader dynamically at all? SystemDictionary::_java_class_loader is not initialized until after the module system initialization is complete. Due to this I have updated my webrev to check for either the built-in application class loader or a custom system class loader and have renamed the method to is_system_class_loader(). http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/ Thanks, Lois From rob.mckenna at oracle.com Wed Jun 22 15:42:19 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 22 Jun 2016 16:42:19 +0100 Subject: [8u] request for approval: "8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions" In-Reply-To: References: <20160622140754.GD3299@vimes> Message-ID: <20160622154219.GH3299@vimes> On 22/06/16 04:34, Volker Simonis wrote: > On Wed, Jun 22, 2016 at 4:07 PM, Rob McKenna wrote: > > Approved assuming the HS folks are ok with the test situation. > > > > Thanks Rob! > Yes, let's wait for another HS review. > > > I'm not sure I get the sponsor question. If you are an approved committer to jdk8u-dev (which you appear to be) you can push, otherwise you would need a sponsor. > > As all hotspot changes have to go trough JPRT external committers are JDK9 only :) -Rob > not allowed to directly push to HS repos - expect for changes which > only touch platforms which aren't built and tested by Oracle anyway > (e.g. ppc64 and aarch64). My initial change contained a shared test so > I needed a sponsor whereas the downport only touches a ppc64 file. > > Regards, > Volker > > > > > -Rob > > > > On 22/06/16 11:35, Volker Simonis wrote: > >> Hi, > >> > >> could you please approve the backport of the following ppc64-only fixe > >> to jdk8u-dev: > >> > >> 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of > >> illegal instructions > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8158260 > >> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260/ > >> Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-June/023347.html > >> URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5f3687f2143c > >> > >> The original change has a JTreg test which uses the new > >> jdk.internal.misc.Unsafe class and some of its features like > >> Unsafe.unalignedAccess() which are not available in jdk8 so I propose > >> to exclude the test from the downport. > >> > >> Without the test the change only touches a ppc64 specific file and > >> applies cleanly to jdk8u-dev: > >> > >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260_8u > >> > >> As this backport is now truly "ppc64-only", can I push it directly to > >> jdk8u-dev/hotspot or do I still need a sponsor? > >> > >> Thank you and best regards, > >> Volker From daniel.daugherty at oracle.com Wed Jun 22 16:11:28 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 22 Jun 2016 10:11:28 -0600 Subject: RFR: 8048093 - Explicitly setting := vs = in the -XX:+PrintFlagsFinal output In-Reply-To: References: Message-ID: <6499cfc2-ab6c-727b-589a-5726fcc267ed@oracle.com> Would it be useful to distinguish which "bucket" the VM option came from? We have the "-XX:Flags=" option , the JAVA_TOOL_OPTIONS env var, the _JAVA_OPTIONS env var, the JNI invocation cmd line (from the launcher), and the new "-XX:VMOptionsFile=" option. With this dizzying array of sources for VM options, it might be useful to have a way to report which bucket provided the "last one wins" value... Sorry if this would muddy the waters too much... Dan On 6/21/16 1:09 PM, Jesper Wilhelmsson wrote: > Hi, > > Please review this change to make -XX:+PrintFlagsFinal distinguish > between flags changed on the command line and flags changed by the > ergonomics. > > To enable us to remember if a flag was set on the command line or not > after having been changed by the ergonomics I use another bit in the > Flag struct. > > The actual symbols printed by PrintFlagsFinal are chosen somewhat > arbitrary and I'm open to suggestions (bike sheding) about how to > visualize this the best. > > The old decorations are: > > ' =' - Default value (no decoration) > ':=' - Value was changed, either by command line or ergonomics or other > > The new decorations are: > > ' =' - Default value (no decoration) > ':=' - Set on the command line > '?=' - Changed by the ergonomics > '!=' - Set on the command line AND changed by the ergonomics > '-=' - Any other origin, like changed by management API or taken from > a config file > > My reasoning behind selecting these characters are that ':=' looks > like a solid assignment and will therefore represent the command line. > You never know what you get from the ergonomics, so '?=' seems > appropriate. '!=' because you'd want to know that the ergonomics > changed a value you had set on the command line. > > Another option could be to use a colon ':=' for the command line, and > a comma ',=' for the ergonomics. That would naturally give us the > semi-colon ';=' for something set on the command line and changed by > the ergonomics. I didn't go with this because the colon and semi-colon > can be hard to distinguish from each other. > > As mentioned above there are other origins, the enum contains eight > values. There is no mention of the other types in the bug and there > are no is_...() for the other types in globals.cpp, so they didn't > seem as important. If the general opinion is that these other origins > are as important, or we might as well..., I'd suggest that we use > letters as decorations. Let me know if you have an opinion. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8048093 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.00/ > > Thanks, > /Jesper From volker.simonis at gmail.com Wed Jun 22 16:21:36 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 22 Jun 2016 18:21:36 +0200 Subject: [8u] request for approval: "8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions" In-Reply-To: <20160622154219.GH3299@vimes> References: <20160622140754.GD3299@vimes> <20160622154219.GH3299@vimes> Message-ID: On Wed, Jun 22, 2016 at 5:42 PM, Rob McKenna wrote: > On 22/06/16 04:34, Volker Simonis wrote: >> On Wed, Jun 22, 2016 at 4:07 PM, Rob McKenna wrote: >> > Approved assuming the HS folks are ok with the test situation. >> > >> >> Thanks Rob! >> Yes, let's wait for another HS review. >> >> > I'm not sure I get the sponsor question. If you are an approved committer to jdk8u-dev (which you appear to be) you can push, otherwise you would need a sponsor. >> >> As all hotspot changes have to go trough JPRT external committers are > > JDK9 only :) > Thanks! Good to know :) > -Rob > >> not allowed to directly push to HS repos - expect for changes which >> only touch platforms which aren't built and tested by Oracle anyway >> (e.g. ppc64 and aarch64). My initial change contained a shared test so >> I needed a sponsor whereas the downport only touches a ppc64 file. >> >> Regards, >> Volker >> >> > >> > -Rob >> > >> > On 22/06/16 11:35, Volker Simonis wrote: >> >> Hi, >> >> >> >> could you please approve the backport of the following ppc64-only fixe >> >> to jdk8u-dev: >> >> >> >> 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of >> >> illegal instructions >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8158260 >> >> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260/ >> >> Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-June/023347.html >> >> URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5f3687f2143c >> >> >> >> The original change has a JTreg test which uses the new >> >> jdk.internal.misc.Unsafe class and some of its features like >> >> Unsafe.unalignedAccess() which are not available in jdk8 so I propose >> >> to exclude the test from the downport. >> >> >> >> Without the test the change only touches a ppc64 specific file and >> >> applies cleanly to jdk8u-dev: >> >> >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260_8u >> >> >> >> As this backport is now truly "ppc64-only", can I push it directly to >> >> jdk8u-dev/hotspot or do I still need a sponsor? >> >> >> >> Thank you and best regards, >> >> Volker From coleen.phillimore at oracle.com Wed Jun 22 16:31:49 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 22 Jun 2016 12:31:49 -0400 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <576AA5E9.9040408@oracle.com> References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> Message-ID: <84b40e40-347d-bb53-7662-9745f894eaa8@oracle.com> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/src/share/vm/classfile/classLoaderData.cpp.udiff.html The new function, is_system_class_loader_data are never used. It looks like the function was subsumed by is_builtin_class_loader_data() which is fine. The only other use of is_platform_class_loader_data is here: Should this really be is_builtin_class_loader_data ? The subtleties of the distinctions are lost on me. // Privileged code can use all annotations. Other code silently drops some. const bool privileged = loader_data->is_the_null_class_loader_data() || loader_data->is_platform_class_loader_data() || loader_data->is_anonymous(); You might want to add for is_builtin_class_loader_data() a comment that says that these are grouped together because they are the class loaders that are not freed by GC. http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/src/share/vm/classfile/systemDictionary.cpp.udiff.html Isn't is_system_class_loader The same as +bool SystemDictionary::is_system_class_loader(Handle class_loader) { + return (is_platform_class_loader(class_loader) || + class_loader() == _java_system_loader); +} + ? And a comment should say why checking against _java_system_loader is done - ie that it is a custom system class loader configured -Djava.system.class.loader. http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/src/share/vm/classfile/classLoaderData.cpp.udiff.html Then is_builtin_class_loader_data should really be: +// Returns true if this class loader data is one of the 3 builtin +// (boot, application/system or platform) class loaders. +bool ClassLoaderData::is_builtin_class_loader_data() const { + Handle classLoaderHandle = class_loader(); + return (is_the_null_class_loader_data() || + SystemDictionary::is_system_class_loader(classLoaderHandle)); +} ie. doesn't need to check the platform class loader and add to my confusion. And I guess builtin_class_loader should really be named something like, is_permanent_class_loader_data. Or something like that because that's really the distinction. http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/test/runtime/modules/ModuleStress/src/jdk.test/test/MainGC.java.html the callback() function isn't used. Otherwise, everything looks great. Coleen On 6/22/16 10:51 AM, Lois Foltan wrote: > > On 6/22/2016 8:56 AM, Alan Bateman wrote: >> >> >> On 22/06/2016 13:51, David Holmes wrote: >>> >>> How do you envisage any system classloader "dying" ?? >> The system class loader (be it the built-in application class loader >> or a custom system class loader configured via >> -Djava.system.class.loader) will/can never be GC'ed. >> ClassLoader.getSystemClassLoader() always returns a reference to it >> (for example). > Ahh, ok, I was being overly cautious, so no opportunity to reset the > system class loader dynamically at all? > SystemDictionary::_java_class_loader is not initialized until after > the module system initialization is complete. Due to this I have > updated my webrev to check for either the built-in application class > loader or a custom system class loader and have renamed the method to > is_system_class_loader(). > > http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/ > > Thanks, > Lois > From lois.foltan at oracle.com Wed Jun 22 17:03:40 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 22 Jun 2016 13:03:40 -0400 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <84b40e40-347d-bb53-7662-9745f894eaa8@oracle.com> References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <84b40e40-347d-bb53-7662-9745f894eaa8@oracle.com> Message-ID: <576AC4EC.6070406@oracle.com> On 6/22/2016 12:31 PM, Coleen Phillimore wrote: > > http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/src/share/vm/classfile/classLoaderData.cpp.udiff.html > > > The new function, is_system_class_loader_data are never used. It > looks like the function was subsumed by is_builtin_class_loader_data() > which is fine. > The only other use of is_platform_class_loader_data is here: Should > this really be is_builtin_class_loader_data ? The subtleties of the > distinctions are lost on me. > > // Privileged code can use all annotations. Other code silently > drops some. > const bool privileged = loader_data->is_the_null_class_loader_data() || > loader_data->is_platform_class_loader_data() || > loader_data->is_anonymous(); Hi Coleen, Thanks for reviewing! That use of is_platform_class_loader_data() is in AnnotationCollector::annotation_index() which is outside the scope of this RFR so I am hesitant to change it now. > > > You might want to add for is_builtin_class_loader_data() a comment > that says that these are grouped together because they are the class > loaders that are not freed by GC. Good idea, will do. > > http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/src/share/vm/classfile/systemDictionary.cpp.udiff.html > > > Isn't is_system_class_loader The same as > > +bool SystemDictionary::is_system_class_loader(Handle class_loader) { > + return (is_platform_class_loader(class_loader) || > + class_loader() == _java_system_loader); > +} > + No, the platform class loader is distinct from the application/system class loader. And before SystemDictionary::_java_system_loader is initialized during bootstrapping, modules are defined to the built-in application class loader. Thus is_system_class_loader must check for either: + return (class_loader->klass() == SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass() || + class_loader() == _java_system_loader); +} I think the confusion might be coming from the word "system", when one states "system class loaders" does that terminology imply either the application class loader or the platform class loader? It doesn't, see http://download.java.net/java/jdk9/docs/api/java/lang/ClassLoader.html#getPlatformClassLoader, snipit follows: The Java run-time has the following built-in class loaders: * Bootstrap class loader. It is the virtual machine's built-in class loader, typically represented as|null|, and does not have a parent. * Platform class loader . All/platform classes/are visible to the platform class loader that can be used as the parent of a|ClassLoader|instance. Platform classes include Java SE platform APIs, their implementation classes and JDK-specific run-time classes that are defined by the platform class loader or its ancestors. * System class loader . It is also known as/application class loader/and is distinct from the platform class loader. The system class loader is typically used to define classes on the application class path, module path, and JDK-specific tools. The platform class loader is a parent or an ancestor of the system class loader that all platform classes are visible to it. > > ? And a comment should say why checking against _java_system_loader > is done - ie that it is a custom system class loader configured > -Djava.system.class.loader. Good idea, will do. > > http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/src/share/vm/classfile/classLoaderData.cpp.udiff.html > > > Then is_builtin_class_loader_data should really be: > > +// Returns true if this class loader data is one of the 3 builtin > +// (boot, application/system or platform) class loaders. > +bool ClassLoaderData::is_builtin_class_loader_data() const { > + Handle classLoaderHandle = class_loader(); > + return (is_the_null_class_loader_data() || > + SystemDictionary::is_system_class_loader(classLoaderHandle)); > +} > > ie. doesn't need to check the platform class loader and add to my > confusion. See explanation above why a call to is_system_class_loader and is_platform_class_loader must both be made. > > And I guess builtin_class_loader should really be named something > like, is_permanent_class_loader_data. Or something like that because > that's really the distinction. Again, see snipit above. They are "built-in" class loaders according to the documentation. > > http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/test/runtime/modules/ModuleStress/src/jdk.test/test/MainGC.java.html > > > the callback() function isn't used. Ah yes, the invocation here should be test.MainGC.callback(). I will fix. jdk.translet/translet/Main.java: test.Main.callback(); > > Otherwise, everything looks great. Thanks! Lois > > Coleen > > > On 6/22/16 10:51 AM, Lois Foltan wrote: >> >> On 6/22/2016 8:56 AM, Alan Bateman wrote: >>> >>> >>> On 22/06/2016 13:51, David Holmes wrote: >>>> >>>> How do you envisage any system classloader "dying" ?? >>> The system class loader (be it the built-in application class loader >>> or a custom system class loader configured via >>> -Djava.system.class.loader) will/can never be GC'ed. >>> ClassLoader.getSystemClassLoader() always returns a reference to it >>> (for example). >> Ahh, ok, I was being overly cautious, so no opportunity to reset the >> system class loader dynamically at all? >> SystemDictionary::_java_class_loader is not initialized until after >> the module system initialization is complete. Due to this I have >> updated my webrev to check for either the built-in application class >> loader or a custom system class loader and have renamed the method to >> is_system_class_loader(). >> >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/ >> >> Thanks, >> Lois >> > From stanislav.lukyanov at oracle.com Wed Jun 22 17:09:19 2016 From: stanislav.lukyanov at oracle.com (stanislav lukyanov) Date: Wed, 22 Jun 2016 20:09:19 +0300 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576A8D0D.3090907@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> Message-ID: Hi Serguei, What is the expected behavior when passed string is not a valid package name (e.g. contains illegal characters)? I think I'd expect JVMTI_ERROR_ILLEGAL_ARGUMENT to be returned in that case. Now it looks like the method will return unnamed module not only for an empty string but for any string that is not a known package name. If it's correct, I think the empty string case shouldn't be described explicitly. Thanks, Stas On 22.06.2016 16:05, serguei.spitsyn at oracle.com wrote: > I've updated the libGetModuleByPkgTest.c in place in the webrev #2 > with minor improvements. > Sorry, if it spoiled your work. > > Thanks, > Serguei > > > On 6/22/16 04:07, serguei.spitsyn at oracle.com wrote: >> Here are new hotspot webrev where I've fixed the comments from Alan >> and Christian. >> >> Hotspot: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.2 >> >> >> >> The Jdk webrev is the same: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >> >> >> >> Thanks, >> Serguei >> >> >> On 6/21/16 02:54, serguei.spitsyn at oracle.com wrote: >>> >>> Please, review the Jigsaw fix for the enhancement: >>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>> >>> >>> The Hotspot webrev: >>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ >>> >>> >>> The Jdk webrev: >>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>> >>> >>> >>> Summary: >>> >>> JVM TI agents that instrument code in named modules need the Module >>> at class load time. >>> >>> One way to do this is by introducing a new ClassFileLoadHook that >>> takes an additional parameter but this approach is disruptive. >>> The alternative option is a JVM TI function that maps a >>> classloader + package name to a module. >>> We were initially not confident with this approach so we >>> introduced it as JVM function JVM_GetModuleByPackageName. >>> Based on experience to date then this approach seems okay and so >>> this function needs to be promoted to a JVMTI function. >>> >>> This fix is to introduce new JVMTI function GetModuleByPackageName. >>> It includes new jtreg test with native JVMTI agent. >>> >>> A CCC is fast-tracked and getting an approval is in progress. >>> >>> Testing: >>> Run newly developed jtreg test. >>> >>> Thanks, >>> Serguei >> > From jiangli.zhou at oracle.com Wed Jun 22 17:29:09 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 22 Jun 2016 10:29:09 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576A7189.6040809@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> Message-ID: <8175258F-38C7-4D54-8FCF-73C9C17D2D61@oracle.com> Hi Serguei, The comment in the following assert is outdated. There is no get_module_from_pkg. Should it be changed to get_module_by_package_name()? 804 assert(ModuleEntryTable::javabase_defined(), 805 "Attempt to call get_module_from_pkg before java.base is defined"); It?s not part of your change, I just happen to notice it. In the same get_module_by_package_name(), both the ?if? and ?else? cases have return statement. The ?return NULL? at line 825 seems will never reached and not needed. Thanks, Jiangli > On Jun 22, 2016, at 4:07 AM, serguei.spitsyn at oracle.com wrote: > > Here are new hotspot webrev where I've fixed the comments from Alan and Christian. > > Hotspot: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.2 > > > The Jdk webrev is the same: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ > > > Thanks, > Serguei > > > On 6/21/16 02:54, serguei.spitsyn at oracle.com wrote: >> >> Please, review the Jigsaw fix for the enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8159145 >> >> >> The Hotspot webrev: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ >> >> The Jdk webrev: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >> >> >> Summary: >> >> JVM TI agents that instrument code in named modules need the Module at class load time. >> >> One way to do this is by introducing a new ClassFileLoadHook that takes an additional parameter but this approach is disruptive. >> The alternative option is a JVM TI function that maps a classloader + package name to a module. >> We were initially not confident with this approach so we introduced it as JVM function JVM_GetModuleByPackageName. >> Based on experience to date then this approach seems okay and so this function needs to be promoted to a JVMTI function. >> >> This fix is to introduce new JVMTI function GetModuleByPackageName. >> It includes new jtreg test with native JVMTI agent. >> >> A CCC is fast-tracked and getting an approval is in progress. >> >> Testing: >> Run newly developed jtreg test. >> >> Thanks, >> Serguei > From Alan.Bateman at oracle.com Wed Jun 22 17:45:36 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Jun 2016 18:45:36 +0100 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> Message-ID: <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> On 22/06/2016 18:09, stanislav lukyanov wrote: > Hi Serguei, > > What is the expected behavior when passed string is not a valid > package name (e.g. contains illegal characters)? > I think I'd expect JVMTI_ERROR_ILLEGAL_ARGUMENT to be returned in that > case. > > Now it looks like the method will return unnamed module not only for > an empty string > but for any string that is not a known package name. > If it's correct, I think the empty string case shouldn't be described > explicitly. The empty string is the unnamed module case and so the function should always return the unamed module. You question on whether this function checks for invalid identifiers is a good question as that is currently not specified. -Alan From jiangli.zhou at oracle.com Wed Jun 22 17:53:34 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 22 Jun 2016 10:53:34 -0700 Subject: RFR: 8038332: The trace event vm/class/load is not always being sent In-Reply-To: <57683F13.5070900@oracle.com> References: <5759AFCE.2080406@oracle.com> <575EF096.9020908@oracle.com> <95d4e379-2680-1e49-f972-831e4e1701ba@oracle.com> <57683F13.5070900@oracle.com> Message-ID: <642636BA-2185-482E-B022-A57002568FAA@oracle.com> Hi Max, I see there is already an ?if (!HAS_PENDING_EXCEPTION)? check at line 1170 before the debug_only code. Maybe you cloud place the post_class_load_event() in there so it only post the event when there is no pending exception. That way you don?t need to change the existing logic and add the additional checks. Thanks, Jiangli > On Jun 20, 2016, at 12:08 PM, Max Ockner wrote: > > David, > > New webrev: http://cr.openjdk.java.net/~mockner/8038332.02/src/share/vm/classfile/systemDictionary.cpp.cdiff.html > I have added the check you suggested before triggering the event: > > if (HAS_PENDING_EXCEPTION || k.is_null()) { > return NULL; > } > > Thanks, > Max > > On 6/13/2016 6:40 PM, David Holmes wrote: >> Hi Max, >> >> On 14/06/2016 3:42 AM, Max Ockner wrote: >>> Jiangli, >>> Thanks for looking. I didn't see anything that looked like it might >>> produce duplicate events. However, I did see some additional places >>> where it looks like no event is fire. >>> >>> Can anyone point me to the event specs? >> >> I'm not sure there is any spec for this. Even JFR doesn't seem to document individual events and when they are triggered. >> >> Your change does not look right however as you are posting the classload event regardless of the exception state. If you look at SystemDictionary::resolve_instance_class_or_null, it only posts after checking the load was successful: >> >> 892 if (HAS_PENDING_EXCEPTION || k.is_null()) { >> 893 return NULL; >> 894 } >> 895 >> 896 post_class_load_event(class_load_start_time, k, class_loader); >> >> Similarly, SystemDictionary::parse_stream, has various CHECK macros that will cause a return on exception, prior to getting to the point of posting the load event. So you also need to add a check for a pending exception and that k is not null, I think, before posting the event. >> > I have added this check. >> BTW I would have expected to see trace-events generated at approximately the same locations as the corresponding JVMTI events. That does not seem to be the case which seems very strange to me. The notion of "loading a class" seems to be spread across far too many functions to me. >> >> Thanks, >> David >> >>> Thanks, >>> Max >>> >>> On 6/9/2016 4:39 PM, Jiangli Zhou wrote: >>>> Hi Max, >>>> >>>> Looks ok. The only possible issue is more than one event might be sent >>>> in some of the call paths. But my quick search didn?t find any of such >>>> case. >>>> >>>> Thanks, >>>> Jiangli >>>> >>>>> On Jun 9, 2016, at 11:05 AM, Max Ockner wrote: >>>>> >>>>> Hello, >>>>> >>>>> Please review this small fix which causes the vm/class/load event to >>>>> be fired from JVM_DefineClass() and JVM_DefineClassWithSource(). >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~mockner/8038332/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038332 >>>>> >>>>> The vm/class/load event (EventClassLoad) was previously fired in 2 >>>>> places: >>>>> >>>>> SystemDictionary::parse_stream >>>>> SystemDictionary::resolve_instance_class_or_null >>>>> >>>>> parse_stream is the standard option for creating a klass from a >>>>> stream, but JVM_DefineClass uses a different function: >>>>> >>>>> SystemDictionary::resolve_from_stream. >>>>> >>>>> This did not fire a vm/class/load event. Now it does fire the event. >>>>> >>>>> Sanity tested with jtreg runtime. Issue was reproduced and tested >>>>> using the reproducer script attached to the bug >>>>> >>>>> Thanks, >>>>> Max >>> > From dmitry.fazunenko at oracle.com Wed Jun 22 18:06:56 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Wed, 22 Jun 2016 21:06:56 +0300 Subject: RFR: 8160088: update hotspot tests depending on GC to use @requires vm.gc.X Message-ID: <5594dba8-f008-2fae-d293-d9a2e3f6913a@oracle.com> Hello, I'm looking for Reviewers for relatively simple fix which affects 59 tests. https://bugs.openjdk.java.net/browse/JDK-8160088 http://cr.openjdk.java.net/~dfazunen/8160088/webrev.00/ The fix allows to skip execution of tests requiring a specific GC in case of the required GC is not supported by VM. Old variant: @requires vm.gc == null | vm.gc == "G1" A test will be executed if no GC is specified externally or -XX:+UseG1GC flag is given. This test will be executed even if VM doesn't support G1 and fail. New variant: @requires vm.gc.G1 This test will not be executed if VM doesn't support G1. Testing: 1) starting jtreg with various collectors with "-c" option to verify correctness of test descriptions. Number of selected tests before and after change is the same: -XX:+UseG1GC: 1,456 -XX:+UseSerialGC: 1,366 -XX:+UseParallelGC: 1,369 -XX:+UseConcMarkSweepGC: 1,368 Default: 1,483; error 2) RBT (in progress) 3) Diff is analyzed manually (only necessary lines are affected): #> hg diff |grep "^- " |sort -u - * @requires (vm.gc == "G1" | vm.gc == "null") - * @requires (vm.gc=="G1" | vm.gc=="null") - * @requires vm.gc == "G1" | vm.gc == "null" - * @requires vm.gc=="ConcMarkSweep" | vm.gc == "null" - * @requires vm.gc=="ConcMarkSweep" | vm.gc=="null" - * @requires vm.gc=="G1" | vm.gc =="null" - * @requires vm.gc=="G1" | vm.gc=="null" - * @requires vm.gc=="Parallel" | vm.gc=="null" - * @requires vm.gc=="Serial" | vm.gc=="null" - * @requires vm.gc=="null" | vm.gc=="G1" - * Copyright (c) 2013, 2014, Oracle and/or its affiliates. All rights reserved. - * Copyright (c) 2013, 2015, Oracle and/or its affiliates. All rights reserved. - * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All rights reserved. - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. #> hg diff |grep "^+ " |sort -u + * @requires vm.gc.ConcMarkSweep + * @requires vm.gc.G1 + * @requires vm.gc.Parallel + * @requires vm.gc.Serial + * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2014, 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights reserved. Thanks, Dima From serguei.spitsyn at oracle.com Wed Jun 22 18:11:31 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jun 2016 11:11:31 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> Message-ID: <576AD4D3.9030002@oracle.com> On 6/22/16 10:45, Alan Bateman wrote: > > > On 22/06/2016 18:09, stanislav lukyanov wrote: >> Hi Serguei, >> >> What is the expected behavior when passed string is not a valid >> package name (e.g. contains illegal characters)? >> I think I'd expect JVMTI_ERROR_ILLEGAL_ARGUMENT to be returned in >> that case. >> >> Now it looks like the method will return unnamed module not only for >> an empty string >> but for any string that is not a known package name. >> If it's correct, I think the empty string case shouldn't be described >> explicitly. > The empty string is the unnamed module case and so the function should > always return the unamed module. > > You question on whether this function checks for invalid identifiers > is a good question as that is currently not specified. I'd suggest to specify this function does not check for invalid characters (or identifiers). Please, let me know if you have objections. Thanks, Serguei > > -Alan From aph at redhat.com Wed Jun 22 18:22:32 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 22 Jun 2016 19:22:32 +0100 Subject: RFD: C2 bug: 8157306 random infrequent null pointer exceptions in javac Message-ID: <576AD768.3070005@redhat.com> This bogus NullPointerException happens because nodes are cloned from a block into its successors by PhaseCFG::call_catch_cleanup. When the clone is performed we don't do an anti-dependence check, so scheduling is free to move a store even above a load which has an anti-dependence. The questionable code in call_catch_cleanup is here: // Clone along all Catch output paths. Clone area between the 'beg' and // 'end' indices. for( uint i = 0; i < block->_num_succs; i++ ) { Block *sb = block->_succs[i]; // Clone the entire area; ignoring the edge fixup for now. for( uint j = end; j > beg; j-- ) { // It is safe here to clone a node with anti_dependence // since clones dominate on each path. Node *clone = block->get_node(j-1)->clone(); sb->insert_node(clone, 1); map_node_to_block(clone, sb); } } There is a fairly simple fix which passes smoke tests: aph at arm64:~/jdk8u/hotspot$ hg revert src/share/vm/opto/lcm.cpp aph at arm64:~/jdk8u/hotspot$ hg diff src/share/vm/opto/lcm.cpp diff --git a/src/share/vm/opto/lcm.cpp b/src/share/vm/opto/lcm.cpp --- a/src/share/vm/opto/lcm.cpp +++ b/src/share/vm/opto/lcm.cpp @@ -1090,11 +1090,12 @@ Block *sb = block->_succs[i]; // Clone the entire area; ignoring the edge fixup for now. for( uint j = end; j > beg; j-- ) { - // It is safe here to clone a node with anti_dependence - // since clones dominate on each path. Node *clone = block->get_node(j-1)->clone(); sb->insert_node(clone, 1); map_node_to_block(clone, sb); + if (clone->needs_anti_dependence_check()) { + insert_anti_dependences(sb, clone); + } } } And this changes the code we generate accordingly, Bad on the left, Good on the right: mov x11, xzr ldr x13, [sp,#32] ldr x13, [sp,#32] ldr w10, [x13,#12] lsr x12, x13, #9 mov x11, xzr str w11, [x13,#12] lsr x12, x13, #9 adrp x14, word_map_base str w11, [x13,#12] ldr w10, [x13,#12] adrp x14, word_map_base ldr w11, [sp,#16] ldr w11, [sp,#16] strb wzr, [x14,x12,lsl #0] strb wzr, [x14,x12,lsl #0] The critical loads and stores are from [x13,#12], and the load must come before the store. The really baffling thing for me, of course, is why this hasn't been seen before. It looks obviously wrong but it's very old code in C2. Could it be that this bug has been causing occasional faults for years but no-one has tracked it down because it's so hard to reproduce? Just to confirm this for a non-AArch64 target, I added an assertion in PhaseCFG::call_catch_cleanup to check that precedence edges were correct, and on x86-64 I got: # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/gcm.cpp:748 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/aph/hs-comp/hotspot/src/share/vm/opto/gcm.cpp:748), pid=14847, tid=14854 # assert(store->find_edge(load) != -1) failed: missing precedence edge # # JRE version: OpenJDK Runtime Environment (9.0) (slowdebug build 9-internal+0-2016-06-22-183041.aph.hs-comp) # Java VM: OpenJDK 64-Bit Server VM (slowdebug 9-internal+0-2016-06-22-183041.aph.hs-comp, mixed mode, tiered, compressed oops, serial gc, linux-amd64) # Core dump will be written. Default location: /home/aph/hs-comp/make/core.14847 # # An error report file with more information is saved as: # /home/aph/hs-comp/make/hs_err_pid14847.log So: IMO this is a real bug, not just on AArch64, but on x86 as well. It may or may not actually result in bad code being generated; that depends on the scheduling. Andrew. From serguei.spitsyn at oracle.com Wed Jun 22 18:26:02 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jun 2016 11:26:02 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> Message-ID: <576AD83A.5070402@oracle.com> Hi Stanislav, Thank you for looking at this update and the comments! On 6/22/16 10:09, stanislav lukyanov wrote: > Hi Serguei, > > What is the expected behavior when passed string is not a valid > package name (e.g. contains illegal characters)? > I think I'd expect JVMTI_ERROR_ILLEGAL_ARGUMENT to be returned in that > case. I initially was thinking the same but currently have a doubt it is really needed. Let's find out if we can reach a consensus here. > > Now it looks like the method will return unnamed module not only for > an empty string > but for any string that is not a known package name. Yes, this is correct. We are not able to recognize non-existing package names and always return the unnamed package. I'm still not sure we want to explicitly specify it. > If it's correct, I think the empty string case shouldn't be described > explicitly. I agree, it can confuse the users. I still prefer to explicitly specify it. The question is if we want to explicitly specify that we always return the unnamed package for non-existing packages. Thanks, Serguei > > Thanks, > Stas > > On 22.06.2016 16:05, serguei.spitsyn at oracle.com wrote: >> I've updated the libGetModuleByPkgTest.c in place in the webrev #2 >> with minor improvements. >> Sorry, if it spoiled your work. >> >> Thanks, >> Serguei >> >> >> On 6/22/16 04:07, serguei.spitsyn at oracle.com wrote: >>> Here are new hotspot webrev where I've fixed the comments from Alan >>> and Christian. >>> >>> Hotspot: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.2 >>> >>> >>> >>> The Jdk webrev is the same: >>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>> >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 6/21/16 02:54, serguei.spitsyn at oracle.com wrote: >>>> >>>> Please, review the Jigsaw fix for the enhancement: >>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>> >>>> >>>> The Hotspot webrev: >>>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ >>>> >>>> >>>> The Jdk webrev: >>>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>> >>>> >>>> >>>> Summary: >>>> >>>> JVM TI agents that instrument code in named modules need the Module >>>> at class load time. >>>> >>>> One way to do this is by introducing a new ClassFileLoadHook that >>>> takes an additional parameter but this approach is disruptive. >>>> The alternative option is a JVM TI function that maps a >>>> classloader + package name to a module. >>>> We were initially not confident with this approach so we >>>> introduced it as JVM function JVM_GetModuleByPackageName. >>>> Based on experience to date then this approach seems okay and so >>>> this function needs to be promoted to a JVMTI function. >>>> >>>> This fix is to introduce new JVMTI function GetModuleByPackageName. >>>> It includes new jtreg test with native JVMTI agent. >>>> >>>> A CCC is fast-tracked and getting an approval is in progress. >>>> >>>> Testing: >>>> Run newly developed jtreg test. >>>> >>>> Thanks, >>>> Serguei >>> >> > From serguei.spitsyn at oracle.com Wed Jun 22 18:36:24 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jun 2016 11:36:24 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576AD4D3.9030002@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> Message-ID: <576ADAA8.8000902@oracle.com> On 6/22/16 11:11, serguei.spitsyn at oracle.com wrote: > On 6/22/16 10:45, Alan Bateman wrote: >> >> >> On 22/06/2016 18:09, stanislav lukyanov wrote: >>> Hi Serguei, >>> >>> What is the expected behavior when passed string is not a valid >>> package name (e.g. contains illegal characters)? >>> I think I'd expect JVMTI_ERROR_ILLEGAL_ARGUMENT to be returned in >>> that case. >>> >>> Now it looks like the method will return unnamed module not only for >>> an empty string >>> but for any string that is not a known package name. >>> If it's correct, I think the empty string case shouldn't be >>> described explicitly. >> The empty string is the unnamed module case and so the function >> should always return the unamed module. >> >> You question on whether this function checks for invalid identifiers >> is a good question as that is currently not specified. > > I'd suggest to specify this function does not check for invalid > characters (or identifiers). > Please, let me know if you have objections. Alan, please, let me know if you support the Stanislav's suggestion. I can go ahead and implement returning the JVMTI_ERROR_ILLEGAL_ARGUMENT for invalid package names. Thanks, Serguei > > Thanks, > Serguei > > >> >> -Alan > From coleen.phillimore at oracle.com Wed Jun 22 18:50:28 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 22 Jun 2016 14:50:28 -0400 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <576AC4EC.6070406@oracle.com> References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <84b40e40-347d-bb53-7662-9745f894eaa8@oracle.com> <576AC4EC.6070406@oracle.com> Message-ID: <38aa1a47-8524-dbcd-e940-343bb54b2d1e@oracle.com> On 6/22/16 1:03 PM, Lois Foltan wrote: > > On 6/22/2016 12:31 PM, Coleen Phillimore wrote: >> >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/src/share/vm/classfile/classLoaderData.cpp.udiff.html >> >> >> The new function, is_system_class_loader_data are never used. It >> looks like the function was subsumed by >> is_builtin_class_loader_data() which is fine. >> The only other use of is_platform_class_loader_data is here: Should >> this really be is_builtin_class_loader_data ? The subtleties of the >> distinctions are lost on me. >> >> // Privileged code can use all annotations. Other code silently >> drops some. >> const bool privileged = >> loader_data->is_the_null_class_loader_data() || >> loader_data->is_platform_class_loader_data() || >> loader_data->is_anonymous(); > > Hi Coleen, > Thanks for reviewing! That use of is_platform_class_loader_data() is > in AnnotationCollector::annotation_index() which is outside the scope > of this RFR so I am hesitant to change it now. > >> >> >> You might want to add for is_builtin_class_loader_data() a comment >> that says that these are grouped together because they are the class >> loaders that are not freed by GC. > Good idea, will do. Thanks. this would be good. > >> >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/src/share/vm/classfile/systemDictionary.cpp.udiff.html >> >> >> Isn't is_system_class_loader The same as >> >> +bool SystemDictionary::is_system_class_loader(Handle class_loader) { >> + return (is_platform_class_loader(class_loader) || >> + class_loader() == _java_system_loader); >> +} >> + > No, the platform class loader is distinct from the application/system > class loader. And before SystemDictionary::_java_system_loader is > initialized during bootstrapping, modules are defined to the built-in > application class loader. Thus is_system_class_loader must check for > either: > + return (class_loader->klass() == > SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass() > || > + class_loader() == _java_system_loader); > +} Ok, I matched these two things when looking at the functions, when they are different. + return (class_loader->klass() == SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass() || and return (class_loader->klass() == SystemDictionary::jdk_internal_loader_ClassLoaders_PlatformClassLoader_klass()); > > I think the confusion might be coming from the word "system", when one > states "system class loaders" does that terminology imply either the > application class loader or the platform class loader? It doesn't, see > http://download.java.net/java/jdk9/docs/api/java/lang/ClassLoader.html#getPlatformClassLoader, > snipit follows: > > The Java run-time has the following built-in class loaders: > > * Bootstrap class loader. It is the virtual machine's built-in class > loader, typically represented as|null|, and does not have a parent. > * Platform class loader > . > All/platform classes/are visible to the platform class loader that > can be used as the parent of a|ClassLoader|instance. Platform > classes include Java SE platform APIs, their implementation > classes and JDK-specific run-time classes that are defined by the > platform class loader or its ancestors. > * System class loader > . > It is also known as/application class loader/and is distinct from > the platform class loader. The system class loader is typically > used to define classes on the application class path, module path, > and JDK-specific tools. The platform class loader is a parent or > an ancestor of the system class loader that all platform classes > are visible to it. > >> >> ? And a comment should say why checking against _java_system_loader >> is done - ie that it is a custom system class loader configured >> -Djava.system.class.loader. > Good idea, will do. Thanks. > >> >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/src/share/vm/classfile/classLoaderData.cpp.udiff.html >> >> >> Then is_builtin_class_loader_data should really be: >> >> +// Returns true if this class loader data is one of the 3 builtin >> +// (boot, application/system or platform) class loaders. >> +bool ClassLoaderData::is_builtin_class_loader_data() const { >> + Handle classLoaderHandle = class_loader(); >> + return (is_the_null_class_loader_data() || >> + SystemDictionary::is_system_class_loader(classLoaderHandle)); >> +} >> >> ie. doesn't need to check the platform class loader and add to my >> confusion. > See explanation above why a call to is_system_class_loader and > is_platform_class_loader must both be made. > >> >> And I guess builtin_class_loader should really be named something >> like, is_permanent_class_loader_data. Or something like that >> because that's really the distinction. > Again, see snipit above. They are "built-in" class loaders according > to the documentation. Thanks for the snippet. I didn't like my renaming anyway. Thank you for adding the comments. Coleen > >> >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/test/runtime/modules/ModuleStress/src/jdk.test/test/MainGC.java.html >> >> >> the callback() function isn't used. > > Ah yes, the invocation here should be test.MainGC.callback(). I will fix. > jdk.translet/translet/Main.java: test.Main.callback(); > >> >> Otherwise, everything looks great. > > Thanks! > Lois > >> >> Coleen >> >> >> On 6/22/16 10:51 AM, Lois Foltan wrote: >>> >>> On 6/22/2016 8:56 AM, Alan Bateman wrote: >>>> >>>> >>>> On 22/06/2016 13:51, David Holmes wrote: >>>>> >>>>> How do you envisage any system classloader "dying" ?? >>>> The system class loader (be it the built-in application class >>>> loader or a custom system class loader configured via >>>> -Djava.system.class.loader) will/can never be GC'ed. >>>> ClassLoader.getSystemClassLoader() always returns a reference to it >>>> (for example). >>> Ahh, ok, I was being overly cautious, so no opportunity to reset the >>> system class loader dynamically at all? >>> SystemDictionary::_java_class_loader is not initialized until after >>> the module system initialization is complete. Due to this I have >>> updated my webrev to check for either the built-in application class >>> loader or a custom system class loader and have renamed the method >>> to is_system_class_loader(). >>> >>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/ >>> >>> Thanks, >>> Lois >>> >> > From Alan.Bateman at oracle.com Wed Jun 22 19:01:42 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Jun 2016 20:01:42 +0100 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576ADAA8.8000902@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> Message-ID: <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> On 22/06/2016 19:36, serguei.spitsyn at oracle.com wrote: > > Alan, please, let me know if you support the Stanislav's suggestion. > I can go ahead and implement returning the > JVMTI_ERROR_ILLEGAL_ARGUMENT for invalid package names. No objection from me. It would be good to first check the existing spec and also the JNI spec to see if there any similar cases (so that the update and new function is consistent). Off-hand, I can't think of any functions that require the same check. -Alan From serguei.spitsyn at oracle.com Wed Jun 22 19:07:45 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jun 2016 12:07:45 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> Message-ID: <576AE201.5030702@oracle.com> On 6/22/16 12:01, Alan Bateman wrote: > On 22/06/2016 19:36, serguei.spitsyn at oracle.com wrote: > >> >> Alan, please, let me know if you support the Stanislav's suggestion. >> I can go ahead and implement returning the >> JVMTI_ERROR_ILLEGAL_ARGUMENT for invalid package names. > No objection from me. Ok, thanks! > It would be good to first check the existing spec and also the JNI > spec to see if there any similar cases (so that the update and new > function is consistent). Will do. > Off-hand, I can't think of any functions that require the same check. Agreed. Thanks, Serguei > > -Alan From vladimir.kozlov at oracle.com Wed Jun 22 19:08:50 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jun 2016 12:08:50 -0700 Subject: [8u] request for approval: "8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions" In-Reply-To: References: Message-ID: Changes looks good. I agree with exclusion of test. Since it is only ppc64 changes you can push it yourself. Note, we do run Hotspot changes through JPRT to push into 8u-dev. Thanks, Vladimir On 6/22/16 2:35 AM, Volker Simonis wrote: > Hi, > > could you please approve the backport of the following ppc64-only fixe > to jdk8u-dev: > > 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of > illegal instructions > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158260 > Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260/ > Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-June/023347.html > URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5f3687f2143c > > The original change has a JTreg test which uses the new > jdk.internal.misc.Unsafe class and some of its features like > Unsafe.unalignedAccess() which are not available in jdk8 so I propose > to exclude the test from the downport. > > Without the test the change only touches a ppc64 specific file and > applies cleanly to jdk8u-dev: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260_8u > > As this backport is now truly "ppc64-only", can I push it directly to > jdk8u-dev/hotspot or do I still need a sponsor? > > Thank you and best regards, > Volker > From coleen.phillimore at oracle.com Wed Jun 22 19:13:16 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 22 Jun 2016 15:13:16 -0400 Subject: RFR: 8038332: The trace event vm/class/load is not always being sent In-Reply-To: <642636BA-2185-482E-B022-A57002568FAA@oracle.com> References: <5759AFCE.2080406@oracle.com> <575EF096.9020908@oracle.com> <95d4e379-2680-1e49-f972-831e4e1701ba@oracle.com> <57683F13.5070900@oracle.com> <642636BA-2185-482E-B022-A57002568FAA@oracle.com> Message-ID: <23a73321-9ad4-c49f-ba9d-841b0754e21c@oracle.com> Hi, Can I suggest actually fixing this code? Please? Instead of returning THREAD in all the calls in parse_stream(), they should have CHECK_NULL. Then all the if (!HAS_PENDING_EXCEPTION) conditionals can be removed and the logic fixed. The only reason to have THREAD as the last parameter is if there's cleanup that needs to be done in the case of an exception, which is rare and I verified not the case in this function. After this code put a return NULL; Exceptions::_throw_msg(THREAD_AND_LOCATION, vmSymbols::java_lang_SecurityException(), message); // add return NULL; } Otherwise, the code to add the event looks good. Thanks, Coleen On 6/22/16 1:53 PM, Jiangli Zhou wrote: > Hi Max, > > I see there is already an ?if (!HAS_PENDING_EXCEPTION)? check at line 1170 before the debug_only code. Maybe you cloud place the post_class_load_event() in there so it only post the event when there is no pending exception. That way you don?t need to change the existing logic and add the additional checks. > > Thanks, > Jiangli > >> On Jun 20, 2016, at 12:08 PM, Max Ockner wrote: >> >> David, >> >> New webrev: http://cr.openjdk.java.net/~mockner/8038332.02/src/share/vm/classfile/systemDictionary.cpp.cdiff.html >> I have added the check you suggested before triggering the event: >> >> if (HAS_PENDING_EXCEPTION || k.is_null()) { >> return NULL; >> } >> >> Thanks, >> Max >> >> On 6/13/2016 6:40 PM, David Holmes wrote: >>> Hi Max, >>> >>> On 14/06/2016 3:42 AM, Max Ockner wrote: >>>> Jiangli, >>>> Thanks for looking. I didn't see anything that looked like it might >>>> produce duplicate events. However, I did see some additional places >>>> where it looks like no event is fire. >>>> >>>> Can anyone point me to the event specs? >>> I'm not sure there is any spec for this. Even JFR doesn't seem to document individual events and when they are triggered. >>> >>> Your change does not look right however as you are posting the classload event regardless of the exception state. If you look at SystemDictionary::resolve_instance_class_or_null, it only posts after checking the load was successful: >>> >>> 892 if (HAS_PENDING_EXCEPTION || k.is_null()) { >>> 893 return NULL; >>> 894 } >>> 895 >>> 896 post_class_load_event(class_load_start_time, k, class_loader); >>> >>> Similarly, SystemDictionary::parse_stream, has various CHECK macros that will cause a return on exception, prior to getting to the point of posting the load event. So you also need to add a check for a pending exception and that k is not null, I think, before posting the event. >>> >> I have added this check. >>> BTW I would have expected to see trace-events generated at approximately the same locations as the corresponding JVMTI events. That does not seem to be the case which seems very strange to me. The notion of "loading a class" seems to be spread across far too many functions to me. >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Max >>>> >>>> On 6/9/2016 4:39 PM, Jiangli Zhou wrote: >>>>> Hi Max, >>>>> >>>>> Looks ok. The only possible issue is more than one event might be sent >>>>> in some of the call paths. But my quick search didn?t find any of such >>>>> case. >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>>> On Jun 9, 2016, at 11:05 AM, Max Ockner wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Please review this small fix which causes the vm/class/load event to >>>>>> be fired from JVM_DefineClass() and JVM_DefineClassWithSource(). >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8038332/ >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038332 >>>>>> >>>>>> The vm/class/load event (EventClassLoad) was previously fired in 2 >>>>>> places: >>>>>> >>>>>> SystemDictionary::parse_stream >>>>>> SystemDictionary::resolve_instance_class_or_null >>>>>> >>>>>> parse_stream is the standard option for creating a klass from a >>>>>> stream, but JVM_DefineClass uses a different function: >>>>>> >>>>>> SystemDictionary::resolve_from_stream. >>>>>> >>>>>> This did not fire a vm/class/load event. Now it does fire the event. >>>>>> >>>>>> Sanity tested with jtreg runtime. Issue was reproduced and tested >>>>>> using the reproducer script attached to the bug >>>>>> >>>>>> Thanks, >>>>>> Max From alexhenrie24 at gmail.com Wed Jun 22 19:15:11 2016 From: alexhenrie24 at gmail.com (Alex Henrie) Date: Wed, 22 Jun 2016 13:15:11 -0600 Subject: [PATCH resend2] 8157758: Use (~0u) instead of (-1) when left-shifting In-Reply-To: <855E9FFA-4BD7-4329-806E-A1BFE5665AD2@oracle.com> References: <740DB36B-CB51-46E9-A456-A546FD3F3836@oracle.com> <855E9FFA-4BD7-4329-806E-A1BFE5665AD2@oracle.com> Message-ID: 2016-06-15 12:48 GMT-06:00 Kim Barrett : > So I've changed my mind about this patch. Looks good. If you approve of the patch, would you please commit it? -Alex From coleen.phillimore at oracle.com Wed Jun 22 19:33:38 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 22 Jun 2016 15:33:38 -0400 Subject: RFR: 8048093 - Explicitly setting := vs = in the -XX:+PrintFlagsFinal output In-Reply-To: References: Message-ID: <838ed626-566c-963c-9b9b-2fb76e0820cf@oracle.com> I agree with Vladimir. There's no way I'm going to remember that a colon mean that the value was changed. Coleen On 6/21/16 4:15 PM, Vladimir Kozlov wrote: > Nobody will remember the meaning of such marking. You should use > normal words. > The output already have flag's type as, for example, "{C2 product}". > You can add an other word there to indicate type of initialization: > default|command|ergo. > > Thanks, > Vladimir > > On 6/21/16 12:09 PM, Jesper Wilhelmsson wrote: >> Hi, >> >> Please review this change to make -XX:+PrintFlagsFinal distinguish >> between flags changed on the command line and flags >> changed by the ergonomics. >> >> To enable us to remember if a flag was set on the command line or not >> after having been changed by the ergonomics I use >> another bit in the Flag struct. >> >> The actual symbols printed by PrintFlagsFinal are chosen somewhat >> arbitrary and I'm open to suggestions (bike sheding) >> about how to visualize this the best. >> >> The old decorations are: >> >> ' =' - Default value (no decoration) >> ':=' - Value was changed, either by command line or ergonomics or other >> >> The new decorations are: >> >> ' =' - Default value (no decoration) >> ':=' - Set on the command line >> '?=' - Changed by the ergonomics >> '!=' - Set on the command line AND changed by the ergonomics >> '-=' - Any other origin, like changed by management API or taken from >> a config file >> >> My reasoning behind selecting these characters are that ':=' looks >> like a solid assignment and will therefore represent >> the command line. You never know what you get from the ergonomics, so >> '?=' seems appropriate. '!=' because you'd want to >> know that the ergonomics changed a value you had set on the command >> line. >> >> Another option could be to use a colon ':=' for the command line, and >> a comma ',=' for the ergonomics. That would >> naturally give us the semi-colon ';=' for something set on the >> command line and changed by the ergonomics. I didn't go >> with this because the colon and semi-colon can be hard to distinguish >> from each other. >> >> As mentioned above there are other origins, the enum contains eight >> values. There is no mention of the other types in >> the bug and there are no is_...() for the other types in globals.cpp, >> so they didn't seem as important. If the general >> opinion is that these other origins are as important, or we might as >> well..., I'd suggest that we use letters as >> decorations. Let me know if you have an opinion. >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8048093 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.00/ >> >> Thanks, >> /Jesper From jiangli.zhou at oracle.com Wed Jun 22 19:53:44 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 22 Jun 2016 12:53:44 -0700 Subject: RFR: 8038332: The trace event vm/class/load is not always being sent In-Reply-To: <23a73321-9ad4-c49f-ba9d-841b0754e21c@oracle.com> References: <5759AFCE.2080406@oracle.com> <575EF096.9020908@oracle.com> <95d4e379-2680-1e49-f972-831e4e1701ba@oracle.com> <57683F13.5070900@oracle.com> <642636BA-2185-482E-B022-A57002568FAA@oracle.com> <23a73321-9ad4-c49f-ba9d-841b0754e21c@oracle.com> Message-ID: <5E728FAD-52EB-4944-B054-3D8185766731@oracle.com> That?s good suggestion. Thanks, Jiangli > On Jun 22, 2016, at 12:13 PM, Coleen Phillimore wrote: > > > Hi, > > Can I suggest actually fixing this code? Please? > > Instead of returning THREAD in all the calls in parse_stream(), they should have CHECK_NULL. Then all the if (!HAS_PENDING_EXCEPTION) conditionals can be removed and the logic fixed. > > The only reason to have THREAD as the last parameter is if there's cleanup that needs to be done in the case of an exception, which is rare and I verified not the case in this function. > > After this code put a return NULL; > > Exceptions::_throw_msg(THREAD_AND_LOCATION, > vmSymbols::java_lang_SecurityException(), message); > // add return NULL; > } > > Otherwise, the code to add the event looks good. > > Thanks, > Coleen > > > On 6/22/16 1:53 PM, Jiangli Zhou wrote: >> Hi Max, >> >> I see there is already an ?if (!HAS_PENDING_EXCEPTION)? check at line 1170 before the debug_only code. Maybe you cloud place the post_class_load_event() in there so it only post the event when there is no pending exception. That way you don?t need to change the existing logic and add the additional checks. >> >> Thanks, >> Jiangli >> >>> On Jun 20, 2016, at 12:08 PM, Max Ockner wrote: >>> >>> David, >>> >>> New webrev: http://cr.openjdk.java.net/~mockner/8038332.02/src/share/vm/classfile/systemDictionary.cpp.cdiff.html >>> I have added the check you suggested before triggering the event: >>> >>> if (HAS_PENDING_EXCEPTION || k.is_null()) { >>> return NULL; >>> } >>> >>> Thanks, >>> Max >>> >>> On 6/13/2016 6:40 PM, David Holmes wrote: >>>> Hi Max, >>>> >>>> On 14/06/2016 3:42 AM, Max Ockner wrote: >>>>> Jiangli, >>>>> Thanks for looking. I didn't see anything that looked like it might >>>>> produce duplicate events. However, I did see some additional places >>>>> where it looks like no event is fire. >>>>> >>>>> Can anyone point me to the event specs? >>>> I'm not sure there is any spec for this. Even JFR doesn't seem to document individual events and when they are triggered. >>>> >>>> Your change does not look right however as you are posting the classload event regardless of the exception state. If you look at SystemDictionary::resolve_instance_class_or_null, it only posts after checking the load was successful: >>>> >>>> 892 if (HAS_PENDING_EXCEPTION || k.is_null()) { >>>> 893 return NULL; >>>> 894 } >>>> 895 >>>> 896 post_class_load_event(class_load_start_time, k, class_loader); >>>> >>>> Similarly, SystemDictionary::parse_stream, has various CHECK macros that will cause a return on exception, prior to getting to the point of posting the load event. So you also need to add a check for a pending exception and that k is not null, I think, before posting the event. >>>> >>> I have added this check. >>>> BTW I would have expected to see trace-events generated at approximately the same locations as the corresponding JVMTI events. That does not seem to be the case which seems very strange to me. The notion of "loading a class" seems to be spread across far too many functions to me. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> On 6/9/2016 4:39 PM, Jiangli Zhou wrote: >>>>>> Hi Max, >>>>>> >>>>>> Looks ok. The only possible issue is more than one event might be sent >>>>>> in some of the call paths. But my quick search didn?t find any of such >>>>>> case. >>>>>> >>>>>> Thanks, >>>>>> Jiangli >>>>>> >>>>>>> On Jun 9, 2016, at 11:05 AM, Max Ockner wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Please review this small fix which causes the vm/class/load event to >>>>>>> be fired from JVM_DefineClass() and JVM_DefineClassWithSource(). >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8038332/ >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038332 >>>>>>> >>>>>>> The vm/class/load event (EventClassLoad) was previously fired in 2 >>>>>>> places: >>>>>>> >>>>>>> SystemDictionary::parse_stream >>>>>>> SystemDictionary::resolve_instance_class_or_null >>>>>>> >>>>>>> parse_stream is the standard option for creating a klass from a >>>>>>> stream, but JVM_DefineClass uses a different function: >>>>>>> >>>>>>> SystemDictionary::resolve_from_stream. >>>>>>> >>>>>>> This did not fire a vm/class/load event. Now it does fire the event. >>>>>>> >>>>>>> Sanity tested with jtreg runtime. Issue was reproduced and tested >>>>>>> using the reproducer script attached to the bug >>>>>>> >>>>>>> Thanks, >>>>>>> Max > From serguei.spitsyn at oracle.com Wed Jun 22 20:17:05 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jun 2016 13:17:05 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <8175258F-38C7-4D54-8FCF-73C9C17D2D61@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <8175258F-38C7-4D54-8FCF-73C9C17D2D61@oracle.com> Message-ID: <576AF241.7080908@oracle.com> Hi Jiangli, Fixed both places - nice catch! Would you like I list you as a reviewer? Thanks, Serguei On 6/22/16 10:29, Jiangli Zhou wrote: > Hi Serguei, > > The comment in the following assert is outdated. There is no > get_module_from_pkg. Should it be changed to get_module_by_package_name()? > > 804 assert(ModuleEntryTable::javabase_defined(), > 805 "Attempt to call get_module_from_pkg before java.base is defined"); > > It?s not part of your change, I just happen to notice it. In the same > get_module_by_package_name(), both the ?if? and ?else? cases have > return statement. The ?return NULL? at line 825 seems will never > reached and not needed. > > Thanks, > Jiangli > >> On Jun 22, 2016, at 4:07 AM, serguei.spitsyn at oracle.com >> wrote: >> >> Here are new hotspot webrev where I've fixed the comments from Alan >> and Christian. >> >> Hotspot: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.2 >> >> >> >> The Jdk webrev is the same: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >> >> >> Thanks, >> Serguei >> >> >> On 6/21/16 02:54, serguei.spitsyn at oracle.com wrote: >>> >>> Please, review the Jigsaw fix for the enhancement: >>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>> >>> >>> The Hotspot webrev: >>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ >>> >>> The Jdk webrev: >>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>> >>> >>> Summary: >>> >>> JVM TI agents that instrument code in named modules need the Module >>> at class load time. >>> >>> One way to do this is by introducing a new ClassFileLoadHook that >>> takes an additional parameter but this approach is disruptive. >>> The alternative option is a JVM TI function that maps a classloader >>> + package name to a module. >>> We were initially not confident with this approach so we introduced >>> it as JVM function JVM_GetModuleByPackageName. >>> Based on experience to date then this approach seems okay and so >>> this function needs to be promoted to a JVMTI function. >>> >>> This fix is to introduce new JVMTI function GetModuleByPackageName. >>> It includes new jtreg test with native JVMTI agent. >>> >>> A CCC is fast-tracked and getting an approval is in progress. >>> >>> Testing: >>> Run newly developed jtreg test. >>> >>> Thanks, >>> Serguei >> > From jiangli.zhou at oracle.com Wed Jun 22 20:54:41 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 22 Jun 2016 13:54:41 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576AF241.7080908@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <8175258F-38C7-4D54-8FCF-73C9C17D2D61@oracle.com> <576AF241.7080908@oracle.com> Message-ID: Hi Serguei, > On Jun 22, 2016, at 1:17 PM, serguei.spitsyn at oracle.com wrote: > > Hi Jiangli, > > Fixed both places - nice catch! > Would you like I list you as a reviewer? No worry, if you already committed/pushed your changes. Thanks, Jiangli > > Thanks, > Serguei > > > On 6/22/16 10:29, Jiangli Zhou wrote: >> Hi Serguei, >> >> The comment in the following assert is outdated. There is no get_module_from_pkg. Should it be changed to get_module_by_package_name()? >> >> 804 assert(ModuleEntryTable::javabase_defined(), >> 805 "Attempt to call get_module_from_pkg before java.base is defined"); >> >> It?s not part of your change, I just happen to notice it. In the same get_module_by_package_name(), both the ?if? and ?else? cases have return statement. The ?return NULL? at line 825 seems will never reached and not needed. >> >> Thanks, >> Jiangli >> >>> On Jun 22, 2016, at 4:07 AM, serguei.spitsyn at oracle.com wrote: >>> >>> Here are new hotspot webrev where I've fixed the comments from Alan and Christian. >>> >>> Hotspot: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.2 >>> >>> >>> The Jdk webrev is the same: >>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 6/21/16 02:54, serguei.spitsyn at oracle.com wrote: >>>> >>>> Please, review the Jigsaw fix for the enhancement: >>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>> >>>> >>>> The Hotspot webrev: >>>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ >>>> >>>> The Jdk webrev: >>>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>> >>>> >>>> Summary: >>>> >>>> JVM TI agents that instrument code in named modules need the Module at class load time. >>>> >>>> One way to do this is by introducing a new ClassFileLoadHook that takes an additional parameter but this approach is disruptive. >>>> The alternative option is a JVM TI function that maps a classloader + package name to a module. >>>> We were initially not confident with this approach so we introduced it as JVM function JVM_GetModuleByPackageName. >>>> Based on experience to date then this approach seems okay and so this function needs to be promoted to a JVMTI function. >>>> >>>> This fix is to introduce new JVMTI function GetModuleByPackageName. >>>> It includes new jtreg test with native JVMTI agent. >>>> >>>> A CCC is fast-tracked and getting an approval is in progress. >>>> >>>> Testing: >>>> Run newly developed jtreg test. >>>> >>>> Thanks, >>>> Serguei >>> >> > From kim.barrett at oracle.com Wed Jun 22 20:56:07 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 22 Jun 2016 16:56:07 -0400 Subject: [PATCH resend2] 8157758: Use (~0u) instead of (-1) when left-shifting In-Reply-To: References: <740DB36B-CB51-46E9-A456-A546FD3F3836@oracle.com> <855E9FFA-4BD7-4329-806E-A1BFE5665AD2@oracle.com> Message-ID: <6A986EED-1557-4483-AB94-A89AFDBFD130@oracle.com> > On Jun 22, 2016, at 3:15 PM, Alex Henrie wrote: > > 2016-06-15 12:48 GMT-06:00 Kim Barrett : >> So I've changed my mind about this patch. Looks good. > > If you approve of the patch, would you please commit it? > > -Alex Hotspot changes generally require at least two reviewers, and at least one must be a ?Reviewer?. I only see one so far (me, also a Reviewer). I?ll poke a couple people about being a second. The change process is described here: http://openjdk.java.net/guide/changePlanning.html The requirement for a second reviewer is a Hotspot extension to that process. Are you covered by an Oracle Contributor Agreement, either individually or through an employer? I can sponsor it once there?s a second review. From serguei.spitsyn at oracle.com Wed Jun 22 21:02:40 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jun 2016 14:02:40 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <8175258F-38C7-4D54-8FCF-73C9C17D2D61@oracle.com> <576AF241.7080908@oracle.com> Message-ID: <576AFCF0.9050201@oracle.com> On 6/22/16 13:54, Jiangli Zhou wrote: > Hi Serguei, > >> On Jun 22, 2016, at 1:17 PM, serguei.spitsyn at oracle.com >> wrote: >> >> Hi Jiangli, >> >> Fixed both places - nice catch! >> Would you like I list you as a reviewer? > > No worry, if you already committed/pushed your changes. I've not committed/pushed yet. Thanks, Serguei > > Thanks, > Jiangli > >> >> Thanks, >> Serguei >> >> >> On 6/22/16 10:29, Jiangli Zhou wrote: >>> Hi Serguei, >>> >>> The comment in the following assert is outdated. There is no >>> get_module_from_pkg. Should it be changed to >>> get_module_by_package_name()? >>> >>> 804 assert(ModuleEntryTable::javabase_defined(), >>> 805 "Attempt to call get_module_from_pkg before java.base is defined"); >>> >>> It?s not part of your change, I just happen to notice it. In the >>> same get_module_by_package_name(), both the ?if? and ?else? cases >>> have return statement. The ?return NULL? at line 825 seems will >>> never reached and not needed. >>> >>> Thanks, >>> Jiangli >>> >>>> On Jun 22, 2016, at 4:07 AM, serguei.spitsyn at oracle.com wrote: >>>> >>>> Here are new hotspot webrev where I've fixed the comments from Alan >>>> and Christian. >>>> >>>> Hotspot: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.2 >>>> >>>> >>>> >>>> The Jdk webrev is the same: >>>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 6/21/16 02:54, serguei.spitsyn at oracle.com wrote: >>>>> >>>>> Please, review the Jigsaw fix for the enhancement: >>>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>>> >>>>> >>>>> The Hotspot webrev: >>>>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ >>>>> >>>>> The Jdk webrev: >>>>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>>> >>>>> >>>>> Summary: >>>>> >>>>> JVM TI agents that instrument code in named modules need the >>>>> Module at class load time. >>>>> >>>>> One way to do this is by introducing a new ClassFileLoadHook that >>>>> takes an additional parameter but this approach is disruptive. >>>>> The alternative option is a JVM TI function that maps a >>>>> classloader + package name to a module. >>>>> We were initially not confident with this approach so we >>>>> introduced it as JVM function JVM_GetModuleByPackageName. >>>>> Based on experience to date then this approach seems okay and so >>>>> this function needs to be promoted to a JVMTI function. >>>>> >>>>> This fix is to introduce new JVMTI function GetModuleByPackageName. >>>>> It includes new jtreg test with native JVMTI agent. >>>>> >>>>> A CCC is fast-tracked and getting an approval is in progress. >>>>> >>>>> Testing: >>>>> Run newly developed jtreg test. >>>>> >>>>> Thanks, >>>>> Serguei >>>> >>> >> > From ioi.lam at oracle.com Wed Jun 22 21:02:54 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 22 Jun 2016 14:02:54 -0700 Subject: RFR: 8038332: The trace event vm/class/load is not always being sent In-Reply-To: <23a73321-9ad4-c49f-ba9d-841b0754e21c@oracle.com> References: <5759AFCE.2080406@oracle.com> <575EF096.9020908@oracle.com> <95d4e379-2680-1e49-f972-831e4e1701ba@oracle.com> <57683F13.5070900@oracle.com> <642636BA-2185-482E-B022-A57002568FAA@oracle.com> <23a73321-9ad4-c49f-ba9d-841b0754e21c@oracle.com> Message-ID: <576AFCFE.3010504@oracle.com> Instead of using Exceptions::_throw_msg directly, I think it's better to use the macro THROW_MSG_NULL(vmSymbols::java_lang_SecurityException(), message); It will do the "return NULL" for you, so there's no danger of forgetting doing it. Thanks - Ioi On 6/22/16 12:13 PM, Coleen Phillimore wrote: > > Hi, > > Can I suggest actually fixing this code? Please? > > Instead of returning THREAD in all the calls in parse_stream(), they > should have CHECK_NULL. Then all the if (!HAS_PENDING_EXCEPTION) > conditionals can be removed and the logic fixed. > > The only reason to have THREAD as the last parameter is if there's > cleanup that needs to be done in the case of an exception, which is > rare and I verified not the case in this function. > > After this code put a return NULL; > > Exceptions::_throw_msg(THREAD_AND_LOCATION, > vmSymbols::java_lang_SecurityException(), message); > // add return NULL; > } > > Otherwise, the code to add the event looks good. > > Thanks, > Coleen > > > On 6/22/16 1:53 PM, Jiangli Zhou wrote: >> Hi Max, >> >> I see there is already an ?if (!HAS_PENDING_EXCEPTION)? check at line >> 1170 before the debug_only code. Maybe you cloud place the >> post_class_load_event() in there so it only post the event when there >> is no pending exception. That way you don?t need to change the >> existing logic and add the additional checks. >> >> Thanks, >> Jiangli >> >>> On Jun 20, 2016, at 12:08 PM, Max Ockner wrote: >>> >>> David, >>> >>> New webrev: >>> http://cr.openjdk.java.net/~mockner/8038332.02/src/share/vm/classfile/systemDictionary.cpp.cdiff.html >>> I have added the check you suggested before triggering the event: >>> >>> if (HAS_PENDING_EXCEPTION || k.is_null()) { >>> return NULL; >>> } >>> >>> Thanks, >>> Max >>> >>> On 6/13/2016 6:40 PM, David Holmes wrote: >>>> Hi Max, >>>> >>>> On 14/06/2016 3:42 AM, Max Ockner wrote: >>>>> Jiangli, >>>>> Thanks for looking. I didn't see anything that looked like it might >>>>> produce duplicate events. However, I did see some additional places >>>>> where it looks like no event is fire. >>>>> >>>>> Can anyone point me to the event specs? >>>> I'm not sure there is any spec for this. Even JFR doesn't seem to >>>> document individual events and when they are triggered. >>>> >>>> Your change does not look right however as you are posting the >>>> classload event regardless of the exception state. If you look at >>>> SystemDictionary::resolve_instance_class_or_null, it only posts >>>> after checking the load was successful: >>>> >>>> 892 if (HAS_PENDING_EXCEPTION || k.is_null()) { >>>> 893 return NULL; >>>> 894 } >>>> 895 >>>> 896 post_class_load_event(class_load_start_time, k, class_loader); >>>> >>>> Similarly, SystemDictionary::parse_stream, has various CHECK macros >>>> that will cause a return on exception, prior to getting to the >>>> point of posting the load event. So you also need to add a check >>>> for a pending exception and that k is not null, I think, before >>>> posting the event. >>>> >>> I have added this check. >>>> BTW I would have expected to see trace-events generated at >>>> approximately the same locations as the corresponding JVMTI events. >>>> That does not seem to be the case which seems very strange to me. >>>> The notion of "loading a class" seems to be spread across far too >>>> many functions to me. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> On 6/9/2016 4:39 PM, Jiangli Zhou wrote: >>>>>> Hi Max, >>>>>> >>>>>> Looks ok. The only possible issue is more than one event might be >>>>>> sent >>>>>> in some of the call paths. But my quick search didn?t find any of >>>>>> such >>>>>> case. >>>>>> >>>>>> Thanks, >>>>>> Jiangli >>>>>> >>>>>>> On Jun 9, 2016, at 11:05 AM, Max Ockner >>>>>>> wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Please review this small fix which causes the vm/class/load >>>>>>> event to >>>>>>> be fired from JVM_DefineClass() and JVM_DefineClassWithSource(). >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8038332/ >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038332 >>>>>>> >>>>>>> The vm/class/load event (EventClassLoad) was previously fired in 2 >>>>>>> places: >>>>>>> >>>>>>> SystemDictionary::parse_stream >>>>>>> SystemDictionary::resolve_instance_class_or_null >>>>>>> >>>>>>> parse_stream is the standard option for creating a klass from a >>>>>>> stream, but JVM_DefineClass uses a different function: >>>>>>> >>>>>>> SystemDictionary::resolve_from_stream. >>>>>>> >>>>>>> This did not fire a vm/class/load event. Now it does fire the >>>>>>> event. >>>>>>> >>>>>>> Sanity tested with jtreg runtime. Issue was reproduced and tested >>>>>>> using the reproducer script attached to the bug >>>>>>> >>>>>>> Thanks, >>>>>>> Max > From alexhenrie24 at gmail.com Wed Jun 22 21:12:23 2016 From: alexhenrie24 at gmail.com (Alex Henrie) Date: Wed, 22 Jun 2016 15:12:23 -0600 Subject: [PATCH resend2] 8157758: Use (~0u) instead of (-1) when left-shifting In-Reply-To: <6A986EED-1557-4483-AB94-A89AFDBFD130@oracle.com> References: <740DB36B-CB51-46E9-A456-A546FD3F3836@oracle.com> <855E9FFA-4BD7-4329-806E-A1BFE5665AD2@oracle.com> <6A986EED-1557-4483-AB94-A89AFDBFD130@oracle.com> Message-ID: 2016-06-22 14:56 GMT-06:00 Kim Barrett : >> On Jun 22, 2016, at 3:15 PM, Alex Henrie wrote: >> >> 2016-06-15 12:48 GMT-06:00 Kim Barrett : >>> So I've changed my mind about this patch. Looks good. >> >> If you approve of the patch, would you please commit it? >> >> -Alex > > Hotspot changes generally require at least two reviewers, and at least one must be a ?Reviewer?. > I only see one so far (me, also a Reviewer). I?ll poke a couple people about being a second. > > The change process is described here: http://openjdk.java.net/guide/changePlanning.html > The requirement for a second reviewer is a Hotspot extension to that process. > Are you covered by an Oracle Contributor Agreement, either individually or through an employer? > > I can sponsor it once there?s a second review. Yes, I have signed the OCA. Is there anything that I can do to help find a second reviewer? -Alex From vladimir.kozlov at oracle.com Wed Jun 22 21:13:40 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jun 2016 14:13:40 -0700 Subject: RFD: C2 bug: 8157306 random infrequent null pointer exceptions in javac In-Reply-To: <576AD768.3070005@redhat.com> References: <576AD768.3070005@redhat.com> Message-ID: <50693eff-01c3-9791-ca4d-b979ad0deb91@oracle.com> Thank you, Andrew, for finding the cause of this problem. Your fix looks good to me. Can you also add changes for the assert you mentioned - I think it is useful. And, please, prepare webrev. May be scheduling changes in LCM (JDK-8134802) cause this happen more frequently. Before the cloning was done at the beginning of block dominating stores in the block and original scheduling did not move it. Also rarity could be because splitting through call projections are rare and you also need to have a store in the cloned block. Thanks, Vladimir On 6/22/16 11:22 AM, Andrew Haley wrote: > This bogus NullPointerException happens because nodes are cloned from > a block into its successors by PhaseCFG::call_catch_cleanup. When the > clone is performed we don't do an anti-dependence check, so scheduling > is free to move a store even above a load which has an anti-dependence. > > The questionable code in call_catch_cleanup is here: > > // Clone along all Catch output paths. Clone area between the 'beg' and > // 'end' indices. > for( uint i = 0; i < block->_num_succs; i++ ) { > Block *sb = block->_succs[i]; > // Clone the entire area; ignoring the edge fixup for now. > for( uint j = end; j > beg; j-- ) { > // It is safe here to clone a node with anti_dependence > // since clones dominate on each path. > Node *clone = block->get_node(j-1)->clone(); > sb->insert_node(clone, 1); > map_node_to_block(clone, sb); > } > } > > There is a fairly simple fix which passes smoke tests: > > aph at arm64:~/jdk8u/hotspot$ hg revert src/share/vm/opto/lcm.cpp > aph at arm64:~/jdk8u/hotspot$ hg diff src/share/vm/opto/lcm.cpp > diff --git a/src/share/vm/opto/lcm.cpp b/src/share/vm/opto/lcm.cpp > --- a/src/share/vm/opto/lcm.cpp > +++ b/src/share/vm/opto/lcm.cpp > @@ -1090,11 +1090,12 @@ > Block *sb = block->_succs[i]; > // Clone the entire area; ignoring the edge fixup for now. > for( uint j = end; j > beg; j-- ) { > - // It is safe here to clone a node with anti_dependence > - // since clones dominate on each path. > Node *clone = block->get_node(j-1)->clone(); > sb->insert_node(clone, 1); > map_node_to_block(clone, sb); > + if (clone->needs_anti_dependence_check()) { > + insert_anti_dependences(sb, clone); > + } > } > } > > And this changes the code we generate accordingly, Bad on the left, > Good on the right: > > mov x11, xzr ldr x13, [sp,#32] > ldr x13, [sp,#32] ldr w10, [x13,#12] > lsr x12, x13, #9 mov x11, xzr > str w11, [x13,#12] lsr x12, x13, #9 > adrp x14, word_map_base str w11, [x13,#12] > ldr w10, [x13,#12] adrp x14, word_map_base > ldr w11, [sp,#16] ldr w11, [sp,#16] > strb wzr, [x14,x12,lsl #0] strb wzr, [x14,x12,lsl #0] > > The critical loads and stores are from [x13,#12], and the load must > come before the store. > > The really baffling thing for me, of course, is why this hasn't been > seen before. It looks obviously wrong but it's very old code in C2. > Could it be that this bug has been causing occasional faults for years > but no-one has tracked it down because it's so hard to reproduce? > > Just to confirm this for a non-AArch64 target, I added an assertion in > PhaseCFG::call_catch_cleanup to check that precedence edges were > correct, and on x86-64 I got: > > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/gcm.cpp:748 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/aph/hs-comp/hotspot/src/share/vm/opto/gcm.cpp:748), pid=14847, tid=14854 > # assert(store->find_edge(load) != -1) failed: missing precedence edge > # > # JRE version: OpenJDK Runtime Environment (9.0) (slowdebug build 9-internal+0-2016-06-22-183041.aph.hs-comp) > # Java VM: OpenJDK 64-Bit Server VM (slowdebug 9-internal+0-2016-06-22-183041.aph.hs-comp, mixed mode, tiered, compressed oops, serial gc, linux-amd64) > # Core dump will be written. Default location: /home/aph/hs-comp/make/core.14847 > # > # An error report file with more information is saved as: > # /home/aph/hs-comp/make/hs_err_pid14847.log > > So: IMO this is a real bug, not just on AArch64, but on x86 as well. > It may or may not actually result in bad code being generated; that > depends on the scheduling. > > Andrew. > From david.holmes at oracle.com Wed Jun 22 22:31:50 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jun 2016 08:31:50 +1000 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> Message-ID: On 23/06/2016 5:01 AM, Alan Bateman wrote: > On 22/06/2016 19:36, serguei.spitsyn at oracle.com wrote: > >> >> Alan, please, let me know if you support the Stanislav's suggestion. >> I can go ahead and implement returning the >> JVMTI_ERROR_ILLEGAL_ARGUMENT for invalid package names. > No objection from me. It would be good to first check the existing spec > and also the JNI spec to see if there any similar cases (so that the > update and new function is consistent). Off-hand, I can't think of any > functions that require the same check. Taking GetLocalVariableTable as an example there is no validation that names are legal, so there should not be a check in this case either. Thanks, David ----- > -Alan From serguei.spitsyn at oracle.com Wed Jun 22 23:20:49 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jun 2016 16:20:49 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> Message-ID: <576B1D51.10403@oracle.com> On 6/22/16 15:31, David Holmes wrote: > On 23/06/2016 5:01 AM, Alan Bateman wrote: >> On 22/06/2016 19:36, serguei.spitsyn at oracle.com wrote: >> >>> >>> Alan, please, let me know if you support the Stanislav's suggestion. >>> I can go ahead and implement returning the >>> JVMTI_ERROR_ILLEGAL_ARGUMENT for invalid package names. >> No objection from me. It would be good to first check the existing spec >> and also the JNI spec to see if there any similar cases (so that the >> update and new function is consistent). Off-hand, I can't think of any >> functions that require the same check. > > Taking GetLocalVariableTable as an example there is no validation that > names are legal, so there should not be a check in this case either. David, I agree with it. Thank you for pointing to this JVMTI example. I did not find in the JNI where the names are checked to be legal. We are going to open a can of worms with this kind of check as there can be many corner cases to cover. Thanks, Serguei > > Thanks, > David > ----- > >> -Alan From david.holmes at oracle.com Wed Jun 22 23:40:49 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jun 2016 09:40:49 +1000 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576B1D51.10403@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> Message-ID: <4d85bb7c-0f8a-c05d-782f-fd7e7499d652@oracle.com> On 23/06/2016 9:20 AM, serguei.spitsyn at oracle.com wrote: > On 6/22/16 15:31, David Holmes wrote: >> On 23/06/2016 5:01 AM, Alan Bateman wrote: >>> On 22/06/2016 19:36, serguei.spitsyn at oracle.com wrote: >>> >>>> >>>> Alan, please, let me know if you support the Stanislav's suggestion. >>>> I can go ahead and implement returning the >>>> JVMTI_ERROR_ILLEGAL_ARGUMENT for invalid package names. >>> No objection from me. It would be good to first check the existing spec >>> and also the JNI spec to see if there any similar cases (so that the >>> update and new function is consistent). Off-hand, I can't think of any >>> functions that require the same check. >> >> Taking GetLocalVariableTable as an example there is no validation that >> names are legal, so there should not be a check in this case either. > > David, > > I agree with it. > Thank you for pointing to this JVMTI example. > I did not find in the JNI where the names are checked to be legal. > We are going to open a can of worms with this kind of check as there can > be many corner cases to cover. Right - JVM TI and JNI both do minimal argument checking/validation. You may want to specify an error for the NULL case - or else treat it as the empty string (which would need documenting). Cheers, David > Thanks, > Serguei > > >> >> Thanks, >> David >> ----- >> >>> -Alan > From david.holmes at oracle.com Wed Jun 22 23:54:20 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jun 2016 09:54:20 +1000 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <576AC4EC.6070406@oracle.com> References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <84b40e40-347d-bb53-7662-9745f894eaa8@oracle.com> <576AC4EC.6070406@oracle.com> Message-ID: Hi Lois, I'm still unclear here - are you saying that during module initialization there is an "application class loader" used that is different to what may eventually be defined as the "system class loader"? I thought all module initialization was done by the boot loader. ?? I'm still not understanding why we have to care about / know about the actual type of the class loader ie jdk_internal_loader_ClassLoaders_AppClassLoader_klass() ?? Thanks, David On 23/06/2016 3:03 AM, Lois Foltan wrote: > > On 6/22/2016 12:31 PM, Coleen Phillimore wrote: >> >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/src/share/vm/classfile/classLoaderData.cpp.udiff.html >> >> >> The new function, is_system_class_loader_data are never used. It >> looks like the function was subsumed by is_builtin_class_loader_data() >> which is fine. >> The only other use of is_platform_class_loader_data is here: Should >> this really be is_builtin_class_loader_data ? The subtleties of the >> distinctions are lost on me. >> >> // Privileged code can use all annotations. Other code silently >> drops some. >> const bool privileged = loader_data->is_the_null_class_loader_data() || >> loader_data->is_platform_class_loader_data() || >> loader_data->is_anonymous(); > > Hi Coleen, > Thanks for reviewing! That use of is_platform_class_loader_data() is in > AnnotationCollector::annotation_index() which is outside the scope of > this RFR so I am hesitant to change it now. > >> >> >> You might want to add for is_builtin_class_loader_data() a comment >> that says that these are grouped together because they are the class >> loaders that are not freed by GC. > Good idea, will do. > >> >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/src/share/vm/classfile/systemDictionary.cpp.udiff.html >> >> >> Isn't is_system_class_loader The same as >> >> +bool SystemDictionary::is_system_class_loader(Handle class_loader) { >> + return (is_platform_class_loader(class_loader) || >> + class_loader() == _java_system_loader); >> +} >> + > No, the platform class loader is distinct from the application/system > class loader. And before SystemDictionary::_java_system_loader is > initialized during bootstrapping, modules are defined to the built-in > application class loader. Thus is_system_class_loader must check for > either: > > + return (class_loader->klass() == > SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass() || > > + class_loader() == _java_system_loader); > +} > > > I think the confusion might be coming from the word "system", when one > states "system class loaders" does that terminology imply either the > application class loader or the platform class loader? It doesn't, see > http://download.java.net/java/jdk9/docs/api/java/lang/ClassLoader.html#getPlatformClassLoader, > snipit follows: > > The Java run-time has the following built-in class loaders: > > * Bootstrap class loader. It is the virtual machine's built-in class > loader, typically represented as|null|, and does not have a parent. > * Platform class loader > > . > > All/platform classes/are visible to the platform class loader that > can be used as the parent of a|ClassLoader|instance. Platform > classes include Java SE platform APIs, their implementation classes > and JDK-specific run-time classes that are defined by the platform > class loader or its ancestors. > * System class loader > > . > > It is also known as/application class loader/and is distinct from > the platform class loader. The system class loader is typically used > to define classes on the application class path, module path, and > JDK-specific tools. The platform class loader is a parent or an > ancestor of the system class loader that all platform classes are > visible to it. > >> >> ? And a comment should say why checking against _java_system_loader >> is done - ie that it is a custom system class loader configured >> -Djava.system.class.loader. > Good idea, will do. > >> >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/src/share/vm/classfile/classLoaderData.cpp.udiff.html >> >> >> Then is_builtin_class_loader_data should really be: >> >> +// Returns true if this class loader data is one of the 3 builtin >> +// (boot, application/system or platform) class loaders. >> +bool ClassLoaderData::is_builtin_class_loader_data() const { >> + Handle classLoaderHandle = class_loader(); >> + return (is_the_null_class_loader_data() || >> + SystemDictionary::is_system_class_loader(classLoaderHandle)); >> +} >> >> ie. doesn't need to check the platform class loader and add to my >> confusion. > See explanation above why a call to is_system_class_loader and > is_platform_class_loader must both be made. > >> >> And I guess builtin_class_loader should really be named something >> like, is_permanent_class_loader_data. Or something like that because >> that's really the distinction. > Again, see snipit above. They are "built-in" class loaders according to > the documentation. > >> >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/test/runtime/modules/ModuleStress/src/jdk.test/test/MainGC.java.html >> >> >> the callback() function isn't used. > > Ah yes, the invocation here should be test.MainGC.callback(). I will fix. > jdk.translet/translet/Main.java: test.Main.callback(); > >> >> Otherwise, everything looks great. > > Thanks! > Lois > >> >> Coleen >> >> >> On 6/22/16 10:51 AM, Lois Foltan wrote: >>> >>> On 6/22/2016 8:56 AM, Alan Bateman wrote: >>>> >>>> >>>> On 22/06/2016 13:51, David Holmes wrote: >>>>> >>>>> How do you envisage any system classloader "dying" ?? >>>> The system class loader (be it the built-in application class loader >>>> or a custom system class loader configured via >>>> -Djava.system.class.loader) will/can never be GC'ed. >>>> ClassLoader.getSystemClassLoader() always returns a reference to it >>>> (for example). >>> Ahh, ok, I was being overly cautious, so no opportunity to reset the >>> system class loader dynamically at all? >>> SystemDictionary::_java_class_loader is not initialized until after >>> the module system initialization is complete. Due to this I have >>> updated my webrev to check for either the built-in application class >>> loader or a custom system class loader and have renamed the method to >>> is_system_class_loader(). >>> >>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/ >>> >>> Thanks, >>> Lois >>> >> > From serguei.spitsyn at oracle.com Thu Jun 23 00:02:33 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jun 2016 17:02:33 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <4d85bb7c-0f8a-c05d-782f-fd7e7499d652@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <4d85bb7c-0f8a-c05d-782f-fd7e7499d652@oracle.com> Message-ID: <576B2719.7020104@oracle.com> On 6/22/16 16:40, David Holmes wrote: > On 23/06/2016 9:20 AM, serguei.spitsyn at oracle.com wrote: >> On 6/22/16 15:31, David Holmes wrote: >>> On 23/06/2016 5:01 AM, Alan Bateman wrote: >>>> On 22/06/2016 19:36, serguei.spitsyn at oracle.com wrote: >>>> >>>>> >>>>> Alan, please, let me know if you support the Stanislav's suggestion. >>>>> I can go ahead and implement returning the >>>>> JVMTI_ERROR_ILLEGAL_ARGUMENT for invalid package names. >>>> No objection from me. It would be good to first check the existing >>>> spec >>>> and also the JNI spec to see if there any similar cases (so that the >>>> update and new function is consistent). Off-hand, I can't think of any >>>> functions that require the same check. >>> >>> Taking GetLocalVariableTable as an example there is no validation that >>> names are legal, so there should not be a check in this case either. >> >> David, >> >> I agree with it. >> Thank you for pointing to this JVMTI example. >> I did not find in the JNI where the names are checked to be legal. >> We are going to open a can of worms with this kind of check as there can >> be many corner cases to cover. > > Right - JVM TI and JNI both do minimal argument checking/validation. > > You may want to specify an error for the NULL case - or else treat it > as the empty string (which would need documenting). It is already there. It is a part of the universal-error : http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#universal-error Thanks, Serguei > > Cheers, > David > >> Thanks, >> Serguei >> >> >>> >>> Thanks, >>> David >>> ----- >>> >>>> -Alan >> From david.holmes at oracle.com Thu Jun 23 00:17:09 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jun 2016 10:17:09 +1000 Subject: RFR: 8160088: update hotspot tests depending on GC to use @requires vm.gc.X In-Reply-To: <5594dba8-f008-2fae-d293-d9a2e3f6913a@oracle.com> References: <5594dba8-f008-2fae-d293-d9a2e3f6913a@oracle.com> Message-ID: <684b0ef2-14f2-ed3a-63ef-a65c748e2471@oracle.com> Hi Dmitry, On 23/06/2016 4:06 AM, Dmitry Fazunenko wrote: > Hello, > > I'm looking for Reviewers for relatively simple fix which affects 59 tests. > https://bugs.openjdk.java.net/browse/JDK-8160088 > http://cr.openjdk.java.net/~dfazunen/8160088/webrev.00/ > > The fix allows to skip execution of tests requiring a specific GC in > case of the required GC is not supported by VM. > Old variant: > @requires vm.gc == null | vm.gc == "G1" > A test will be executed if no GC is specified externally or > -XX:+UseG1GC flag is given. > This test will be executed even if VM doesn't support G1 and fail. > New variant: > @requires vm.gc.G1 > This test will not be executed if VM doesn't support G1. That doesn't seem sufficient. What you want is that if the test requires G1 then it also supports G1, so it seems to me the correct formulation is: @requires (vm.gc == null | // null -> default -> g1 (usually) vm.gc == G1 ) & vm.gc.G1 Aside: how does jtreg determine which GC's are supported? Thanks, David > Testing: > 1) starting jtreg with various collectors with "-c" option to verify > correctness of test descriptions. > Number of selected tests before and after change is the same: > -XX:+UseG1GC: 1,456 > -XX:+UseSerialGC: 1,366 > -XX:+UseParallelGC: 1,369 > -XX:+UseConcMarkSweepGC: 1,368 > Default: 1,483; error > > 2) RBT (in progress) > > 3) Diff is analyzed manually (only necessary lines are affected): > #> hg diff |grep "^- " |sort -u > - * @requires (vm.gc == "G1" | vm.gc == "null") > - * @requires (vm.gc=="G1" | vm.gc=="null") > - * @requires vm.gc == "G1" | vm.gc == "null" > - * @requires vm.gc=="ConcMarkSweep" | vm.gc == "null" > - * @requires vm.gc=="ConcMarkSweep" | vm.gc=="null" > - * @requires vm.gc=="G1" | vm.gc =="null" > - * @requires vm.gc=="G1" | vm.gc=="null" > - * @requires vm.gc=="Parallel" | vm.gc=="null" > - * @requires vm.gc=="Serial" | vm.gc=="null" > - * @requires vm.gc=="null" | vm.gc=="G1" > - * Copyright (c) 2013, 2014, Oracle and/or its affiliates. All rights > reserved. > - * Copyright (c) 2013, 2015, Oracle and/or its affiliates. All rights > reserved. > - * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All rights > reserved. > - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. > #> hg diff |grep "^+ " |sort -u > + * @requires vm.gc.ConcMarkSweep > + * @requires vm.gc.G1 > + * @requires vm.gc.Parallel > + * @requires vm.gc.Serial > + * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2014, 2016, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights > reserved. > > Thanks, > Dima From coleen.phillimore at oracle.com Thu Jun 23 02:53:39 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 22 Jun 2016 22:53:39 -0400 Subject: RFR: 8038332: The trace event vm/class/load is not always being sent In-Reply-To: <576AFCFE.3010504@oracle.com> References: <5759AFCE.2080406@oracle.com> <575EF096.9020908@oracle.com> <95d4e379-2680-1e49-f972-831e4e1701ba@oracle.com> <57683F13.5070900@oracle.com> <642636BA-2185-482E-B022-A57002568FAA@oracle.com> <23a73321-9ad4-c49f-ba9d-841b0754e21c@oracle.com> <576AFCFE.3010504@oracle.com> Message-ID: <32997529-3e7c-53b0-bd84-d4519d1b2419@oracle.com> On 6/22/16 5:02 PM, Ioi Lam wrote: > Instead of using Exceptions::_throw_msg directly, I think it's better > to use the macro > > THROW_MSG_NULL(vmSymbols::java_lang_SecurityException(), message); > > It will do the "return NULL" for you, so there's no danger of > forgetting doing it. Agree. Coleen > > Thanks > - Ioi > > On 6/22/16 12:13 PM, Coleen Phillimore wrote: >> >> Hi, >> >> Can I suggest actually fixing this code? Please? >> >> Instead of returning THREAD in all the calls in parse_stream(), they >> should have CHECK_NULL. Then all the if (!HAS_PENDING_EXCEPTION) >> conditionals can be removed and the logic fixed. >> >> The only reason to have THREAD as the last parameter is if there's >> cleanup that needs to be done in the case of an exception, which is >> rare and I verified not the case in this function. >> >> After this code put a return NULL; >> >> Exceptions::_throw_msg(THREAD_AND_LOCATION, >> vmSymbols::java_lang_SecurityException(), message); >> // add return NULL; >> } >> >> Otherwise, the code to add the event looks good. >> >> Thanks, >> Coleen >> >> >> On 6/22/16 1:53 PM, Jiangli Zhou wrote: >>> Hi Max, >>> >>> I see there is already an ?if (!HAS_PENDING_EXCEPTION)? check at >>> line 1170 before the debug_only code. Maybe you cloud place the >>> post_class_load_event() in there so it only post the event when >>> there is no pending exception. That way you don?t need to change the >>> existing logic and add the additional checks. >>> >>> Thanks, >>> Jiangli >>> >>>> On Jun 20, 2016, at 12:08 PM, Max Ockner >>>> wrote: >>>> >>>> David, >>>> >>>> New webrev: >>>> http://cr.openjdk.java.net/~mockner/8038332.02/src/share/vm/classfile/systemDictionary.cpp.cdiff.html >>>> I have added the check you suggested before triggering the event: >>>> >>>> if (HAS_PENDING_EXCEPTION || k.is_null()) { >>>> return NULL; >>>> } >>>> >>>> Thanks, >>>> Max >>>> >>>> On 6/13/2016 6:40 PM, David Holmes wrote: >>>>> Hi Max, >>>>> >>>>> On 14/06/2016 3:42 AM, Max Ockner wrote: >>>>>> Jiangli, >>>>>> Thanks for looking. I didn't see anything that looked like it might >>>>>> produce duplicate events. However, I did see some additional places >>>>>> where it looks like no event is fire. >>>>>> >>>>>> Can anyone point me to the event specs? >>>>> I'm not sure there is any spec for this. Even JFR doesn't seem to >>>>> document individual events and when they are triggered. >>>>> >>>>> Your change does not look right however as you are posting the >>>>> classload event regardless of the exception state. If you look at >>>>> SystemDictionary::resolve_instance_class_or_null, it only posts >>>>> after checking the load was successful: >>>>> >>>>> 892 if (HAS_PENDING_EXCEPTION || k.is_null()) { >>>>> 893 return NULL; >>>>> 894 } >>>>> 895 >>>>> 896 post_class_load_event(class_load_start_time, k, class_loader); >>>>> >>>>> Similarly, SystemDictionary::parse_stream, has various CHECK >>>>> macros that will cause a return on exception, prior to getting to >>>>> the point of posting the load event. So you also need to add a >>>>> check for a pending exception and that k is not null, I think, >>>>> before posting the event. >>>>> >>>> I have added this check. >>>>> BTW I would have expected to see trace-events generated at >>>>> approximately the same locations as the corresponding JVMTI >>>>> events. That does not seem to be the case which seems very strange >>>>> to me. The notion of "loading a class" seems to be spread across >>>>> far too many functions to me. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> On 6/9/2016 4:39 PM, Jiangli Zhou wrote: >>>>>>> Hi Max, >>>>>>> >>>>>>> Looks ok. The only possible issue is more than one event might >>>>>>> be sent >>>>>>> in some of the call paths. But my quick search didn?t find any >>>>>>> of such >>>>>>> case. >>>>>>> >>>>>>> Thanks, >>>>>>> Jiangli >>>>>>> >>>>>>>> On Jun 9, 2016, at 11:05 AM, Max Ockner >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review this small fix which causes the vm/class/load >>>>>>>> event to >>>>>>>> be fired from JVM_DefineClass() and JVM_DefineClassWithSource(). >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8038332/ >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038332 >>>>>>>> >>>>>>>> The vm/class/load event (EventClassLoad) was previously fired >>>>>>>> in 2 >>>>>>>> places: >>>>>>>> >>>>>>>> SystemDictionary::parse_stream >>>>>>>> SystemDictionary::resolve_instance_class_or_null >>>>>>>> >>>>>>>> parse_stream is the standard option for creating a klass from a >>>>>>>> stream, but JVM_DefineClass uses a different function: >>>>>>>> >>>>>>>> SystemDictionary::resolve_from_stream. >>>>>>>> >>>>>>>> This did not fire a vm/class/load event. Now it does fire the >>>>>>>> event. >>>>>>>> >>>>>>>> Sanity tested with jtreg runtime. Issue was reproduced and tested >>>>>>>> using the reproducer script attached to the bug >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >> > From tobias.hartmann at oracle.com Thu Jun 23 06:39:23 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 23 Jun 2016 08:39:23 +0200 Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation on ppc64 and sparc In-Reply-To: References: <27dde86d-f7b3-3093-e500-cd3c9156811f@oracle.com> <5767AD68.8090500@oracle.com> <5767B078.8030102@oracle.com> <5768FE79.2060301@oracle.com> Message-ID: <576B841B.6050408@oracle.com> Hi Volker, On 22.06.2016 16:29, Volker Simonis wrote: > On Tue, Jun 21, 2016 at 10:44 AM, Tobias Hartmann > wrote: >> Hi Volker, >> >> On 21.06.2016 09:37, Volker Simonis wrote: >>> On Mon, Jun 20, 2016 at 10:59 AM, Tobias Hartmann >>> wrote: >>>> Hi Volker, >>>> >>>> On 20.06.2016 10:52, Volker Simonis wrote: >>>>> Hi Tobias, >>>>> >>>>> thanks for sponsoring! I've uploaded a new webrev with you and >>>>> Vladimir as reviewers: >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v2/ >>>>> >>>>> You can find the changeset there: >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v2/hotspot.changeset >>>> >>>> Thanks, I just noticed that the test has >>>> >>>> 26 * @bug 9999999 >>>> >>>> You can fix this in-place. I'll then run the required pre-integration testing (~24h) and push your change afterwards. >>>> >>> >>> Hi Tobias, >>> >>> good catch and sorry, I somehow missed your mail yesterday. >>> >>> You can find the new changeset here: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v3/hotspot.changeset >> >> Thank you! >> >> I just looked at the test results and unfortunately DisableOSRTest fails on all platforms (including SPARC) if -Xcomp is set: >> >> ----------System.err:(13/1215)---------- >> java.lang.RuntimeException: "public static void DisableOSRTest.main(java.lang.String[]) throws java.lang.Exception" shouldn't be OSR compiled if running with -XX:-UseOnStackReplacement! >> at DisableOSRTest.main(DisableOSRTest.java:59) >> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base/Native Method) >> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base/NativeMethodAccessorImpl.java:62) >> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base/DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(java.base/Method.java:531) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) >> at java.lang.Thread.run(java.base/Thread.java:843) >> >> There are several OSR compilations in the log: >> >> 12916 4242 % b 4 DisableOSRTest::main @ 19 (61 bytes) >> > > Hi Tobias, > > you're right! Thanks for finding this new problem:) > > I initially only fixed OSR from interpreted code. But C1 compiled code > can also trigger an OSR request (and -Xcomp triggers a C1 compilation > of main before it is invoked for the first time). Switching this off > with the help of -XX:-UseOnStackReplacement never worked, but it was > actually easy to fix. Please find the new change here: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v4/ Your C1 fix looks correct to me. It's good to have this fixed! > I think it would good if somebody (maybe the initial reviewers) could > review the new C1 changes to prevent OSR in C1-compiled code. Yes, I'll wait with pushing until Goetz and/or Vladimir had a look. Best regards, Tobias > > Thank you and best regards, > Volker > > >> Best regards, >> Tobias >> >>> >>> Thank you and best regards, >>> Volker >>> >>> >>>> Best regards, >>>> Tobias >>>> >>>>> >>>>> Thanks, >>>>> Volker >>>>> >>>>> >>>>> On Mon, Jun 20, 2016 at 10:46 AM, Tobias Hartmann >>>>> wrote: >>>>>> Hi Volker, >>>>>> >>>>>> you fix looks good to me! I can do the sponsoring, please just send me a changeset. >>>>>> >>>>>> Best regards, >>>>>> Tobias >>>>>> >>>>>> On 20.06.2016 10:16, Volker Simonis wrote: >>>>>>> Thanks Vladimir! >>>>>>> >>>>>>> .. I still need a sponsor :( >>>>>>> >>>>>>> Regards, >>>>>>> Volker >>>>>>> >>>>>>> >>>>>>> On Fri, Jun 17, 2016 at 10:53 PM, Vladimir Kozlov >>>>>>> wrote: >>>>>>>> Looks good. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> >>>>>>>> On 6/17/16 2:22 AM, Volker Simonis wrote: >>>>>>>>> >>>>>>>>> Hi Goetz, >>>>>>>>> >>>>>>>>> thanks for the review. >>>>>>>>> You're right, I've fixed the "else": >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v1/ >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Volker >>>>>>>>> >>>>>>>>> On Fri, Jun 17, 2016 at 11:08 AM, Lindenmaier, Goetz >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi Volker, >>>>>>>>>> >>>>>>>>>> thanks for doing this fix, I also have run into this issue before ... >>>>>>>>>> Looks good. >>>>>>>>>> >>>>>>>>>> Small nit: usually >>>>>>>>>> } >>>>>>>>>> else { >>>>>>>>>> are on one line. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>>>>>>>>> Behalf Of Volker Simonis >>>>>>>>>>> Sent: Donnerstag, 16. Juni 2016 16:54 >>>>>>>>>>> To: HotSpot Open Source Developers >>>>>>>>>>> Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work >>>>>>>>>>> together with -XX:+TieredCompilation on ppc64 and sparc >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> can I please have a review and sponsor for the following small change >>>>>>>>>>> which fixes -XX:-UseOnStackReplacement to work together with >>>>>>>>>>> -XX:+TieredCompilation: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620/ >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8159620 >>>>>>>>>>> >>>>>>>>>>> This is a long standing bug on SPARC and as the ppc64 template >>>>>>>>>>> interpreter was initially forked from the SPARC implementation, it >>>>>>>>>>> also manifests there. The problem is that in the case of tiered >>>>>>>>>>> compilation the interpreter unconditionally calls >>>>>>>>>>> InterpreterRuntime::frequency_counter_overflow if the back edge >>>>>>>>>>> counter overflows. This triggers an OSR compilation, even if OSR was >>>>>>>>>>> switched off with -XX:-UseOnStackReplacement. >>>>>>>>>>> >>>>>>>>>>> The fix is simple - just don't call >>>>>>>>>>> InterpreterRuntime::frequency_counter_overflow if OSR has been >>>>>>>>>>> switched off. >>>>>>>>>>> >>>>>>>>>>> Thank you and best regards, >>>>>>>>>>> Volker From Alan.Bateman at oracle.com Thu Jun 23 07:51:36 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 Jun 2016 08:51:36 +0100 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576B1D51.10403@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> Message-ID: <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: > : > > I agree with it. > Thank you for pointing to this JVMTI example. > I did not find in the JNI where the names are checked to be legal. > We are going to open a can of worms with this kind of check as there > can be many corner cases to cover. The primary use-case for this function is from within the CLFH callback so have it return the unnamed module when calling with garage is probably okay, it just needs to be specified. Will you update the webrev to reflect where we've got to this in this discussion? -Alan From david.holmes at oracle.com Thu Jun 23 07:57:25 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jun 2016 17:57:25 +1000 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> Message-ID: <4f9176cf-9ec1-12ac-132a-2baf14091248@oracle.com> On 23/06/2016 5:51 PM, Alan Bateman wrote: > > > On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >> : >> >> I agree with it. >> Thank you for pointing to this JVMTI example. >> I did not find in the JNI where the names are checked to be legal. >> We are going to open a can of worms with this kind of check as there >> can be many corner cases to cover. > The primary use-case for this function is from within the CLFH callback > so have it return the unnamed module when calling with garage is > probably okay, it just needs to be specified. It already is specified :) If the name is garbage then it is, by definition, not a package that is associated with any module hence the else clause kicks in and the unnamed module is returned. David ----- > Will you update the webrev to reflect where we've got to this in this > discussion? > > -Alan From Alan.Bateman at oracle.com Thu Jun 23 08:02:45 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 Jun 2016 09:02:45 +0100 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <4f9176cf-9ec1-12ac-132a-2baf14091248@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <4f9176cf-9ec1-12ac-132a-2baf14091248@oracle.com> Message-ID: <4ddba382-f852-19f2-3b98-1096bea5d3dc@oracle.com> On 23/06/2016 08:57, David Holmes wrote: > > It already is specified :) If the name is garbage then it is, by > definition, not a package that is associated with any module hence the > else clause kicks in and the unnamed module is returned. Sure but there are are other changes the wording in this thread and I think it would be good to see the final changes to jvmti.xml. -Alan From serguei.spitsyn at oracle.com Thu Jun 23 08:04:13 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Jun 2016 01:04:13 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> Message-ID: <576B97FD.1080303@oracle.com> On 6/23/16 00:51, Alan Bateman wrote: > > > On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >> : >> >> I agree with it. >> Thank you for pointing to this JVMTI example. >> I did not find in the JNI where the names are checked to be legal. >> We are going to open a can of worms with this kind of check as there >> can be many corner cases to cover. > The primary use-case for this function is from within the CLFH > callback so have it return the unnamed module when calling with garage > is probably okay, it just needs to be specified. > > Will you update the webrev to reflect where we've got to this in this > discussion? I need to undo my fix for additional check. My up-to-date understanding is that we have to explicitly specify two points: - the function returns the unnamed module if the package does not exist - the function does not check the package names for validness and always returns the unnamed module for illegal package names It is better to specify these points explicitly to avoid possible confusion. Thanks, Serguei > > -Alan From Alan.Bateman at oracle.com Thu Jun 23 08:32:21 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 Jun 2016 09:32:21 +0100 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <84b40e40-347d-bb53-7662-9745f894eaa8@oracle.com> <576AC4EC.6070406@oracle.com> Message-ID: On 23/06/2016 00:54, David Holmes wrote: > Hi Lois, > > I'm still unclear here - are you saying that during module > initialization there is an "application class loader" used that is > different to what may eventually be defined as the "system class > loader"? I thought all module initialization was done by the boot > loader. ?? Startup has changed significantly in JDK 9. The comments on call_initPhase in thread.cpp have all the details. During module system initialization (init phase 2) then the only code that executes is in java.base, it's not possible to load code in any other module, not even code in the unnamed module of the boot loader. Module system initialization will initialize the built-in class loaders, including the application class loader. The platform or application class loaders won't load any classes in this phase of course but they will be initialized (with the modules that they might later load classes from). If there is a custom system class loader configured then it will be loaded in init phase 3 and so after the module system is initialized. -Alan From volker.simonis at gmail.com Thu Jun 23 08:41:23 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 23 Jun 2016 10:41:23 +0200 Subject: [8u] request for approval: "8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions" In-Reply-To: References: Message-ID: Thanks Vladimir! Regards, Volker On Wed, Jun 22, 2016 at 9:08 PM, Vladimir Kozlov wrote: > Changes looks good. I agree with exclusion of test. > > Since it is only ppc64 changes you can push it yourself. > > Note, we do run Hotspot changes through JPRT to push into 8u-dev. > > Thanks, > Vladimir > > > On 6/22/16 2:35 AM, Volker Simonis wrote: >> >> Hi, >> >> could you please approve the backport of the following ppc64-only fixe >> to jdk8u-dev: >> >> 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of >> illegal instructions >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8158260 >> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260/ >> Review: >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-June/023347.html >> URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5f3687f2143c >> >> The original change has a JTreg test which uses the new >> jdk.internal.misc.Unsafe class and some of its features like >> Unsafe.unalignedAccess() which are not available in jdk8 so I propose >> to exclude the test from the downport. >> >> Without the test the change only touches a ppc64 specific file and >> applies cleanly to jdk8u-dev: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260_8u >> >> As this backport is now truly "ppc64-only", can I push it directly to >> jdk8u-dev/hotspot or do I still need a sponsor? >> >> Thank you and best regards, >> Volker >> > From serguei.spitsyn at oracle.com Thu Jun 23 08:41:37 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Jun 2016 01:41:37 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <4ddba382-f852-19f2-3b98-1096bea5d3dc@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <4f9176cf-9ec1-12ac-132a-2baf14091248@oracle.com> <4ddba382-f852-19f2-3b98-1096bea5d3dc@oracle.com> Message-ID: <576BA0C1.2090301@oracle.com> Updated the webrev in place: Hotspot: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.2 Please, let me know about your opinion. Do I have to update the CCC as well? Thanks, Serguei On 6/23/16 01:02, Alan Bateman wrote: > > > On 23/06/2016 08:57, David Holmes wrote: >> >> It already is specified :) If the name is garbage then it is, by >> definition, not a package that is associated with any module hence >> the else clause kicks in and the unnamed module is returned. > Sure but there are are other changes the wording in this thread and I > think it would be good to see the final changes to jvmti.xml. > > -Alan From dmitry.fazunenko at oracle.com Thu Jun 23 08:52:01 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Thu, 23 Jun 2016 11:52:01 +0300 Subject: RFR: 8160088: update hotspot tests depending on GC to use @requires vm.gc.X In-Reply-To: <684b0ef2-14f2-ed3a-63ef-a65c748e2471@oracle.com> References: <5594dba8-f008-2fae-d293-d9a2e3f6913a@oracle.com> <684b0ef2-14f2-ed3a-63ef-a65c748e2471@oracle.com> Message-ID: <5b2a01d0-df0d-3826-65f5-a1c48f573e37@oracle.com> Hi David, thanks for looking! On 23.06.2016 3:17, David Holmes wrote: > Hi Dmitry, > > On 23/06/2016 4:06 AM, Dmitry Fazunenko wrote: >> Hello, >> >> I'm looking for Reviewers for relatively simple fix which affects 59 >> tests. >> https://bugs.openjdk.java.net/browse/JDK-8160088 >> http://cr.openjdk.java.net/~dfazunen/8160088/webrev.00/ >> >> The fix allows to skip execution of tests requiring a specific GC in >> case of the required GC is not supported by VM. >> Old variant: >> @requires vm.gc == null | vm.gc == "G1" >> A test will be executed if no GC is specified externally or >> -XX:+UseG1GC flag is given. >> This test will be executed even if VM doesn't support G1 and fail. >> New variant: >> @requires vm.gc.G1 >> This test will not be executed if VM doesn't support G1. > > That doesn't seem sufficient. What you want is that if the test > requires G1 then it also supports G1, so it seems to me the correct > formulation is: > > @requires (vm.gc == null | // null -> default -> g1 (usually) > vm.gc == G1 ) & > vm.gc.G1 No, vm.gc.G1 is an alias to: (vm.gc == null | vm.gc == g1) & vm.gc.supportsG1. > > Aside: how does jtreg determine which GC's are supported? Sorry for not providing the full history here: CODETOOLS-7901583: jtreg should provide extensible mechanism for @requires properties - change to jtreg that allows a Test Suite to introduce its own @requires props JDK-8152432: Implement setting jtreg @requires properties vm.flavor, vm.bits, vm.compMode - implementation that mechanism in hotspot JDK-8154096: Extend WhiteBox API with methods which retrieve from VM information about available GC - fix which allows to know if a GC is supported JDK-8151283: Implement setting jtreg @requires property vm.isG1Supported. - introduction vm.gc.G1, vm.gc.Serial, vm.gc.Parallel and vm.gc.ConcMarkSweep JDK-8160088 (this one): update hotspot tests depending on GC to use @requires vm.gc.X - culmination: update tests to use new functionality Thanks, Dima > > Thanks, > David > >> Testing: >> 1) starting jtreg with various collectors with "-c" option to verify >> correctness of test descriptions. >> Number of selected tests before and after change is the same: >> -XX:+UseG1GC: 1,456 >> -XX:+UseSerialGC: 1,366 >> -XX:+UseParallelGC: 1,369 >> -XX:+UseConcMarkSweepGC: 1,368 >> Default: 1,483; error >> >> 2) RBT (in progress) >> >> 3) Diff is analyzed manually (only necessary lines are affected): >> #> hg diff |grep "^- " |sort -u >> - * @requires (vm.gc == "G1" | vm.gc == "null") >> - * @requires (vm.gc=="G1" | vm.gc=="null") >> - * @requires vm.gc == "G1" | vm.gc == "null" >> - * @requires vm.gc=="ConcMarkSweep" | vm.gc == "null" >> - * @requires vm.gc=="ConcMarkSweep" | vm.gc=="null" >> - * @requires vm.gc=="G1" | vm.gc =="null" >> - * @requires vm.gc=="G1" | vm.gc=="null" >> - * @requires vm.gc=="Parallel" | vm.gc=="null" >> - * @requires vm.gc=="Serial" | vm.gc=="null" >> - * @requires vm.gc=="null" | vm.gc=="G1" >> - * Copyright (c) 2013, 2014, Oracle and/or its affiliates. All rights >> reserved. >> - * Copyright (c) 2013, 2015, Oracle and/or its affiliates. All rights >> reserved. >> - * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All rights >> reserved. >> - * Copyright (c) 2015, Oracle and/or its affiliates. All rights >> reserved. >> #> hg diff |grep "^+ " |sort -u >> + * @requires vm.gc.ConcMarkSweep >> + * @requires vm.gc.G1 >> + * @requires vm.gc.Parallel >> + * @requires vm.gc.Serial >> + * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2014, 2016, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights >> reserved. >> >> Thanks, >> Dima From adinn at redhat.com Thu Jun 23 08:52:57 2016 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 23 Jun 2016 09:52:57 +0100 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576BA0C1.2090301@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <4f9176cf-9ec1-12ac-132a-2baf14091248@oracle.com> <4ddba382-f852-19f2-3b98-1096bea5d3dc@oracle.com> <576BA0C1.2090301@oracle.com> Message-ID: <576BA369.4080305@redhat.com> On 23/06/16 09:41, serguei.spitsyn at oracle.com wrote: > Updated the webrev in place: > > Hotspot: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.2 Just as an aside, I think it's actually a bad idea to update in place. Much better to just add new webrevs. Why? Well, the mail lists provide an audit of the review process for a given change. Webrevs are the data on which those reviews are based. So, removing them (by overwriting) makes it harder to understand why a specific choice was made. This may not matter most of the time but when a fix gets revoked thanks, say, to a regression of some sort it's important to be able to go back and re-read that audit trail. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From goetz.lindenmaier at sap.com Thu Jun 23 09:07:10 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 23 Jun 2016 09:07:10 +0000 Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation on ppc64 and sparc In-Reply-To: References: <27dde86d-f7b3-3093-e500-cd3c9156811f@oracle.com> <5767AD68.8090500@oracle.com> <5767B078.8030102@oracle.com> <5768FE79.2060301@oracle.com> Message-ID: Hi Volker, Good there was a test to bring up this additional fix! Looks good. Best regards, Goetz. > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Volker Simonis > Sent: Mittwoch, 22. Juni 2016 16:30 > To: Tobias Hartmann > Cc: Vladimir Kozlov ; HotSpot Open Source > Developers > Subject: Re: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work > together with -XX:+TieredCompilation on ppc64 and sparc > > On Tue, Jun 21, 2016 at 10:44 AM, Tobias Hartmann > wrote: > > Hi Volker, > > > > On 21.06.2016 09:37, Volker Simonis wrote: > >> On Mon, Jun 20, 2016 at 10:59 AM, Tobias Hartmann > >> wrote: > >>> Hi Volker, > >>> > >>> On 20.06.2016 10:52, Volker Simonis wrote: > >>>> Hi Tobias, > >>>> > >>>> thanks for sponsoring! I've uploaded a new webrev with you and > >>>> Vladimir as reviewers: > >>>> > >>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v2/ > >>>> > >>>> You can find the changeset there: > >>>> > >>>> > http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v2/hotspot.cha > ngeset > >>> > >>> Thanks, I just noticed that the test has > >>> > >>> 26 * @bug 9999999 > >>> > >>> You can fix this in-place. I'll then run the required pre-integration testing > (~24h) and push your change afterwards. > >>> > >> > >> Hi Tobias, > >> > >> good catch and sorry, I somehow missed your mail yesterday. > >> > >> You can find the new changeset here: > >> > >> > http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v3/hotspot.cha > ngeset > > > > Thank you! > > > > I just looked at the test results and unfortunately DisableOSRTest fails on all > platforms (including SPARC) if -Xcomp is set: > > > > ----------System.err:(13/1215)---------- > > java.lang.RuntimeException: "public static void > DisableOSRTest.main(java.lang.String[]) throws java.lang.Exception" > shouldn't be OSR compiled if running with -XX:-UseOnStackReplacement! > > at DisableOSRTest.main(DisableOSRTest.java:59) > > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base/Native > Method) > > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base/NativeMet > hodAccessorImpl.java:62) > > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base/Delega > tingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(java.base/Method.java:531) > > at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapp > er.java:110) > > at java.lang.Thread.run(java.base/Thread.java:843) > > > > There are several OSR compilations in the log: > > > > 12916 4242 % b 4 DisableOSRTest::main @ 19 (61 bytes) > > > > Hi Tobias, > > you're right! Thanks for finding this new problem:) > > I initially only fixed OSR from interpreted code. But C1 compiled code > can also trigger an OSR request (and -Xcomp triggers a C1 compilation > of main before it is invoked for the first time). Switching this off > with the help of -XX:-UseOnStackReplacement never worked, but it was > actually easy to fix. Please find the new change here: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v4/ > > I think it would good if somebody (maybe the initial reviewers) could > review the new C1 changes to prevent OSR in C1-compiled code. > > Thank you and best regards, > Volker > > > > Best regards, > > Tobias > > > >> > >> Thank you and best regards, > >> Volker > >> > >> > >>> Best regards, > >>> Tobias > >>> > >>>> > >>>> Thanks, > >>>> Volker > >>>> > >>>> > >>>> On Mon, Jun 20, 2016 at 10:46 AM, Tobias Hartmann > >>>> wrote: > >>>>> Hi Volker, > >>>>> > >>>>> you fix looks good to me! I can do the sponsoring, please just send me > a changeset. > >>>>> > >>>>> Best regards, > >>>>> Tobias > >>>>> > >>>>> On 20.06.2016 10:16, Volker Simonis wrote: > >>>>>> Thanks Vladimir! > >>>>>> > >>>>>> .. I still need a sponsor :( > >>>>>> > >>>>>> Regards, > >>>>>> Volker > >>>>>> > >>>>>> > >>>>>> On Fri, Jun 17, 2016 at 10:53 PM, Vladimir Kozlov > >>>>>> wrote: > >>>>>>> Looks good. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Vladimir > >>>>>>> > >>>>>>> > >>>>>>> On 6/17/16 2:22 AM, Volker Simonis wrote: > >>>>>>>> > >>>>>>>> Hi Goetz, > >>>>>>>> > >>>>>>>> thanks for the review. > >>>>>>>> You're right, I've fixed the "else": > >>>>>>>> > >>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v1/ > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> Volker > >>>>>>>> > >>>>>>>> On Fri, Jun 17, 2016 at 11:08 AM, Lindenmaier, Goetz > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> Hi Volker, > >>>>>>>>> > >>>>>>>>> thanks for doing this fix, I also have run into this issue before ... > >>>>>>>>> Looks good. > >>>>>>>>> > >>>>>>>>> Small nit: usually > >>>>>>>>> } > >>>>>>>>> else { > >>>>>>>>> are on one line. > >>>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> Goetz. > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: hotspot-dev [mailto:hotspot-dev- > bounces at openjdk.java.net] On > >>>>>>>>>> Behalf Of Volker Simonis > >>>>>>>>>> Sent: Donnerstag, 16. Juni 2016 16:54 > >>>>>>>>>> To: HotSpot Open Source Developers dev at openjdk.java.net> > >>>>>>>>>> Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does > not work > >>>>>>>>>> together with -XX:+TieredCompilation on ppc64 and sparc > >>>>>>>>>> > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> can I please have a review and sponsor for the following small > change > >>>>>>>>>> which fixes -XX:-UseOnStackReplacement to work together > with > >>>>>>>>>> -XX:+TieredCompilation: > >>>>>>>>>> > >>>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620/ > >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8159620 > >>>>>>>>>> > >>>>>>>>>> This is a long standing bug on SPARC and as the ppc64 template > >>>>>>>>>> interpreter was initially forked from the SPARC > implementation, it > >>>>>>>>>> also manifests there. The problem is that in the case of tiered > >>>>>>>>>> compilation the interpreter unconditionally calls > >>>>>>>>>> InterpreterRuntime::frequency_counter_overflow if the back > edge > >>>>>>>>>> counter overflows. This triggers an OSR compilation, even if > OSR was > >>>>>>>>>> switched off with -XX:-UseOnStackReplacement. > >>>>>>>>>> > >>>>>>>>>> The fix is simple - just don't call > >>>>>>>>>> InterpreterRuntime::frequency_counter_overflow if OSR has > been > >>>>>>>>>> switched off. > >>>>>>>>>> > >>>>>>>>>> Thank you and best regards, > >>>>>>>>>> Volker From serguei.spitsyn at oracle.com Thu Jun 23 09:08:08 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Jun 2016 02:08:08 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576BA369.4080305@redhat.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <4f9176cf-9ec1-12ac-132a-2baf14091248@oracle.com> <4ddba382-f852-19f2-3b98-1096bea5d3dc@oracle.com> <576BA0C1.2090301@oracle.com> <576BA369.4080305@redhat.com> Message-ID: <576BA6F8.8040808@oracle.com> Hi Andrew, You should not try to convince me that updating webrev in place is a generally bad idea. I have the same opinion. :) Just did not want to generate another round for a pretty small change. Sorry. Thanks, Serguei On 6/23/16 01:52, Andrew Dinn wrote: > On 23/06/16 09:41, serguei.spitsyn at oracle.com wrote: >> Updated the webrev in place: >> >> Hotspot: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.2 > Just as an aside, I think it's actually a bad idea to update in place. > Much better to just add new webrevs. > > Why? Well, the mail lists provide an audit of the review process for a > given change. Webrevs are the data on which those reviews are based. So, > removing them (by overwriting) makes it harder to understand why a > specific choice was made. This may not matter most of the time but when > a fix gets revoked thanks, say, to a regression of some sort it's > important to be able to go back and re-read that audit trail. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From david.holmes at oracle.com Thu Jun 23 10:51:27 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jun 2016 20:51:27 +1000 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576B97FD.1080303@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <576B97FD.1080303@oracle.com> Message-ID: <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> On 23/06/2016 6:04 PM, serguei.spitsyn at oracle.com wrote: > On 6/23/16 00:51, Alan Bateman wrote: >> >> >> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >>> : >>> >>> I agree with it. >>> Thank you for pointing to this JVMTI example. >>> I did not find in the JNI where the names are checked to be legal. >>> We are going to open a can of worms with this kind of check as there >>> can be many corner cases to cover. >> The primary use-case for this function is from within the CLFH >> callback so have it return the unnamed module when calling with garage >> is probably okay, it just needs to be specified. >> >> Will you update the webrev to reflect where we've got to this in this >> discussion? > > I need to undo my fix for additional check. > My up-to-date understanding is that we have to explicitly specify two > points: > - the function returns the unnamed module if the package does not exist > - the function does not check the package names for validness and > always returns the unnamed module for illegal package names > > It is better to specify these points explicitly to avoid possible > confusion. I don't agree - nothing else refers to invalid "names" in JVM TI. I don't see any need to call this out here. If the name supplied is not a legal package name then it will not match - end of story. Cheers, David > Thanks, > Serguei > > > >> >> -Alan > From david.holmes at oracle.com Thu Jun 23 10:55:40 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jun 2016 20:55:40 +1000 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <84b40e40-347d-bb53-7662-9745f894eaa8@oracle.com> <576AC4EC.6070406@oracle.com> Message-ID: <6bdb6f82-517d-e686-4034-dc8f5ae6e9bd@oracle.com> On 23/06/2016 6:32 PM, Alan Bateman wrote: > On 23/06/2016 00:54, David Holmes wrote: > >> Hi Lois, >> >> I'm still unclear here - are you saying that during module >> initialization there is an "application class loader" used that is >> different to what may eventually be defined as the "system class >> loader"? I thought all module initialization was done by the boot >> loader. ?? > Startup has changed significantly in JDK 9. The comments on > call_initPhase in thread.cpp have all the details. > > During module system initialization (init phase 2) then the only code > that executes is in java.base, it's not possible to load code in any > other module, not even code in the unnamed module of the boot loader. > Module system initialization will initialize the built-in class loaders, > including the application class loader. The platform or application > class loaders won't load any classes in this phase of course but they > will be initialized (with the modules that they might later load classes > from). > > If there is a custom system class loader configured then it will be > loaded in init phase 3 and so after the module system is initialized. So then there are two "system" class loaders ??? I have not seen that spelt out anywhere. David > -Alan From Alan.Bateman at oracle.com Thu Jun 23 10:59:01 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 Jun 2016 11:59:01 +0100 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <6bdb6f82-517d-e686-4034-dc8f5ae6e9bd@oracle.com> References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <84b40e40-347d-bb53-7662-9745f894eaa8@oracle.com> <576AC4EC.6070406@oracle.com> <6bdb6f82-517d-e686-4034-dc8f5ae6e9bd@oracle.com> Message-ID: <6e921b20-2fa7-b60d-c310-857180f358dd@oracle.com> On 23/06/2016 11:55, David Holmes wrote: > > So then there are two "system" class loaders ??? I have not seen that > spelt out anywhere. No, just one system class loader. It will almost always == application class loader. In rare cases then the system class loader will user supplied and configured via the java.system.class.loader property. This is all documented/specific in java.lang.ClassLoader. -Alan From david.holmes at oracle.com Thu Jun 23 11:00:22 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jun 2016 21:00:22 +1000 Subject: RFR: 8160088: update hotspot tests depending on GC to use @requires vm.gc.X In-Reply-To: <5b2a01d0-df0d-3826-65f5-a1c48f573e37@oracle.com> References: <5594dba8-f008-2fae-d293-d9a2e3f6913a@oracle.com> <684b0ef2-14f2-ed3a-63ef-a65c748e2471@oracle.com> <5b2a01d0-df0d-3826-65f5-a1c48f573e37@oracle.com> Message-ID: <931a448e-0e87-59b0-2657-073ac1e34fb2@oracle.com> Hi Dmitry, On 23/06/2016 6:52 PM, Dmitry Fazunenko wrote: > Hi David, > > thanks for looking! > > On 23.06.2016 3:17, David Holmes wrote: >> Hi Dmitry, >> >> On 23/06/2016 4:06 AM, Dmitry Fazunenko wrote: >>> Hello, >>> >>> I'm looking for Reviewers for relatively simple fix which affects 59 >>> tests. >>> https://bugs.openjdk.java.net/browse/JDK-8160088 >>> http://cr.openjdk.java.net/~dfazunen/8160088/webrev.00/ >>> >>> The fix allows to skip execution of tests requiring a specific GC in >>> case of the required GC is not supported by VM. >>> Old variant: >>> @requires vm.gc == null | vm.gc == "G1" >>> A test will be executed if no GC is specified externally or >>> -XX:+UseG1GC flag is given. >>> This test will be executed even if VM doesn't support G1 and fail. >>> New variant: >>> @requires vm.gc.G1 >>> This test will not be executed if VM doesn't support G1. >> >> That doesn't seem sufficient. What you want is that if the test >> requires G1 then it also supports G1, so it seems to me the correct >> formulation is: >> >> @requires (vm.gc == null | // null -> default -> g1 (usually) >> vm.gc == G1 ) & >> vm.gc.G1 > > No, vm.gc.G1 is an alias to: (vm.gc == null | vm.gc == g1) & > vm.gc.supportsG1. Wow - on the one hand that is a compact/succinct syntax. On the other hand - no one will recognize what it actually means! I think I have missed a discussed I would like to have given input on! >> >> Aside: how does jtreg determine which GC's are supported? > Sorry for not providing the full history here: > > CODETOOLS-7901583: jtreg should provide extensible mechanism for > @requires properties > - change to jtreg that allows a Test Suite to introduce its own > @requires props > > JDK-8152432: Implement setting jtreg @requires properties vm.flavor, > vm.bits, vm.compMode > - implementation that mechanism in hotspot > > JDK-8154096: Extend WhiteBox API with methods which retrieve from VM > information about available GC > - fix which allows to know if a GC is supported > > JDK-8151283: Implement setting jtreg @requires property vm.isG1Supported. > - introduction vm.gc.G1, vm.gc.Serial, vm.gc.Parallel and > vm.gc.ConcMarkSweep > > JDK-8160088 (this one): update hotspot tests depending on GC to use > @requires vm.gc.X > - culmination: update tests to use new functionality Wow I have missed out on a lot it seem! :( What version of jtreg supports this level of customized @requires? Someone has already encountered the following error: Error. Parse Exception: Syntax error in @requires expression: invalid name: XXX for a new @requires XXX clause. Thanks, David > Thanks, > Dima > >> >> Thanks, >> David >> >>> Testing: >>> 1) starting jtreg with various collectors with "-c" option to verify >>> correctness of test descriptions. >>> Number of selected tests before and after change is the same: >>> -XX:+UseG1GC: 1,456 >>> -XX:+UseSerialGC: 1,366 >>> -XX:+UseParallelGC: 1,369 >>> -XX:+UseConcMarkSweepGC: 1,368 >>> Default: 1,483; error >>> >>> 2) RBT (in progress) >>> >>> 3) Diff is analyzed manually (only necessary lines are affected): >>> #> hg diff |grep "^- " |sort -u >>> - * @requires (vm.gc == "G1" | vm.gc == "null") >>> - * @requires (vm.gc=="G1" | vm.gc=="null") >>> - * @requires vm.gc == "G1" | vm.gc == "null" >>> - * @requires vm.gc=="ConcMarkSweep" | vm.gc == "null" >>> - * @requires vm.gc=="ConcMarkSweep" | vm.gc=="null" >>> - * @requires vm.gc=="G1" | vm.gc =="null" >>> - * @requires vm.gc=="G1" | vm.gc=="null" >>> - * @requires vm.gc=="Parallel" | vm.gc=="null" >>> - * @requires vm.gc=="Serial" | vm.gc=="null" >>> - * @requires vm.gc=="null" | vm.gc=="G1" >>> - * Copyright (c) 2013, 2014, Oracle and/or its affiliates. All rights >>> reserved. >>> - * Copyright (c) 2013, 2015, Oracle and/or its affiliates. All rights >>> reserved. >>> - * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All rights >>> reserved. >>> - * Copyright (c) 2015, Oracle and/or its affiliates. All rights >>> reserved. >>> #> hg diff |grep "^+ " |sort -u >>> + * @requires vm.gc.ConcMarkSweep >>> + * @requires vm.gc.G1 >>> + * @requires vm.gc.Parallel >>> + * @requires vm.gc.Serial >>> + * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All rights >>> reserved. >>> + * Copyright (c) 2014, 2016, Oracle and/or its affiliates. All rights >>> reserved. >>> + * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights >>> reserved. >>> >>> Thanks, >>> Dima > From david.holmes at oracle.com Thu Jun 23 11:05:34 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jun 2016 21:05:34 +1000 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <6e921b20-2fa7-b60d-c310-857180f358dd@oracle.com> References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <84b40e40-347d-bb53-7662-9745f894eaa8@oracle.com> <576AC4EC.6070406@oracle.com> <6bdb6f82-517d-e686-4034-dc8f5ae6e9bd@oracle.com> <6e921b20-2fa7-b60d-c310-857180f358dd@oracle.com> Message-ID: <16738fb0-7a98-5a3a-979e-dd162a19541f@oracle.com> On 23/06/2016 8:59 PM, Alan Bateman wrote: > On 23/06/2016 11:55, David Holmes wrote: > >> >> So then there are two "system" class loaders ??? I have not seen that >> spelt out anywhere. > No, just one system class loader. It will almost always == application > class loader. In rare cases then the system class loader will user > supplied and configured via the java.system.class.loader property. This > is all documented/specific in java.lang.ClassLoader. You said: "Module system initialization will initialize the built-in class loaders, including the application class loader. The platform or application class loaders won't load any classes in this phase of course but they will be initialized (with the modules that they might later load classes from). " What does that last part mean: "with the modules they might later load classes from"? How have modules become bound to a classloader that may not even get instantiated? If that class loader is never instantiated then why do we need a runtime test that checks for the type of the actual system class loader? Sorry if I'm being dense here but this is not really making sense to me. I really don't know why we need to know whether the system classloader is the default one or not? Thanks, David > -Alan From serguei.spitsyn at oracle.com Thu Jun 23 11:08:33 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Jun 2016 04:08:33 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <576B97FD.1080303@oracle.com> <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> Message-ID: <576BC331.8000400@oracle.com> On 6/23/16 03:51, David Holmes wrote: > On 23/06/2016 6:04 PM, serguei.spitsyn at oracle.com wrote: >> On 6/23/16 00:51, Alan Bateman wrote: >>> >>> >>> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >>>> : >>>> >>>> I agree with it. >>>> Thank you for pointing to this JVMTI example. >>>> I did not find in the JNI where the names are checked to be legal. >>>> We are going to open a can of worms with this kind of check as there >>>> can be many corner cases to cover. >>> The primary use-case for this function is from within the CLFH >>> callback so have it return the unnamed module when calling with garage >>> is probably okay, it just needs to be specified. >>> >>> Will you update the webrev to reflect where we've got to this in this >>> discussion? >> >> I need to undo my fix for additional check. >> My up-to-date understanding is that we have to explicitly specify two >> points: >> - the function returns the unnamed module if the package does not >> exist >> - the function does not check the package names for validness and >> always returns the unnamed module for illegal package names >> >> It is better to specify these points explicitly to avoid possible >> confusion. > > I don't agree - nothing else refers to invalid "names" in JVM TI. I > don't see any need to call this out here. If the name supplied is not > a legal package name then it will not match - end of story. David, It was the original approach that is in the CCC. You were the one who got confused here, and it convinced me that this needs to be more clear. All these changes are because you started the discussion. :) It was useful anyway. Are you against both clarifications or just the last one? I'm Ok to return it back as it is in the CCC. It will save time on the CCC approval. This is the last addition to the spec: + The unnamed module is returned if the specified package does not exist. + The function does not check if the specified package name is illegal. Thanks, Serguei > > Cheers, > David > > >> Thanks, >> Serguei >> >> >> >>> >>> -Alan >> From Alan.Bateman at oracle.com Thu Jun 23 11:25:38 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 Jun 2016 12:25:38 +0100 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <16738fb0-7a98-5a3a-979e-dd162a19541f@oracle.com> References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <84b40e40-347d-bb53-7662-9745f894eaa8@oracle.com> <576AC4EC.6070406@oracle.com> <6bdb6f82-517d-e686-4034-dc8f5ae6e9bd@oracle.com> <6e921b20-2fa7-b60d-c310-857180f358dd@oracle.com> <16738fb0-7a98-5a3a-979e-dd162a19541f@oracle.com> Message-ID: On 23/06/2016 12:05, David Holmes wrote: > > You said: > > "Module system initialization will initialize the built-in class > loaders, including the application class loader. The platform or > application class loaders won't load any classes in this phase of > course but they will be initialized (with the modules that they might > later load classes from). " > > What does that last part mean: "with the modules they might later load > classes from"? How have modules become bound to a classloader that may > not even get instantiated? If that class loader is never instantiated > then why do we need a runtime test that checks for the type of the > actual system class loader? The graph of modules that are defined to the runtime during startup are we call the "boot layer". They are statically mapped to the built-in class loaders where built-in means the boot, platform or application class loaders. There may be a custom system class loader that comes into existence later during the startup but it's just not interesting to the discussion here (except to know that it might be different to the application class loader in some niche configuration). -Alan From david.holmes at oracle.com Thu Jun 23 11:27:10 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jun 2016 21:27:10 +1000 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576BC331.8000400@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <576B97FD.1080303@oracle.com> <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> <576BC331.8000400@oracle.com> Message-ID: <32634325-b80f-81fe-674e-74ba5daa41fb@oracle.com> On 23/06/2016 9:08 PM, serguei.spitsyn at oracle.com wrote: > On 6/23/16 03:51, David Holmes wrote: >> On 23/06/2016 6:04 PM, serguei.spitsyn at oracle.com wrote: >>> On 6/23/16 00:51, Alan Bateman wrote: >>>> >>>> >>>> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >>>>> : >>>>> >>>>> I agree with it. >>>>> Thank you for pointing to this JVMTI example. >>>>> I did not find in the JNI where the names are checked to be legal. >>>>> We are going to open a can of worms with this kind of check as there >>>>> can be many corner cases to cover. >>>> The primary use-case for this function is from within the CLFH >>>> callback so have it return the unnamed module when calling with garage >>>> is probably okay, it just needs to be specified. >>>> >>>> Will you update the webrev to reflect where we've got to this in this >>>> discussion? >>> >>> I need to undo my fix for additional check. >>> My up-to-date understanding is that we have to explicitly specify two >>> points: >>> - the function returns the unnamed module if the package does not >>> exist >>> - the function does not check the package names for validness and >>> always returns the unnamed module for illegal package names >>> >>> It is better to specify these points explicitly to avoid possible >>> confusion. >> >> I don't agree - nothing else refers to invalid "names" in JVM TI. I >> don't see any need to call this out here. If the name supplied is not >> a legal package name then it will not match - end of story. > > David, > > It was the original approach that is in the CCC. > You were the one who got confused here, and it convinced me that this > needs to be more clear. > All these changes are because you started the discussion. :) > It was useful anyway. I never said anything about illegal package names. > Are you against both clarifications or just the last one? > I'm Ok to return it back as it is in the CCC. > It will save time on the CCC approval. > > This is the last addition to the spec: > > + The unnamed module is returned if the specified package does not exist. The notion of "package does not exist" is ill-defined. This case is already covered by the primary specification. > + The function does not check if the specified package name is illegal. This does not need to be stated as it is not stated anywhere else for anything else that may have legal and illegal forms. Thanks, David > > > Thanks, > Serguei > > > > >> >> Cheers, >> David >> >> >>> Thanks, >>> Serguei >>> >>> >>> >>>> >>>> -Alan >>> > From serguei.spitsyn at oracle.com Thu Jun 23 11:33:49 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Jun 2016 04:33:49 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <32634325-b80f-81fe-674e-74ba5daa41fb@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <576B97FD.1080303@oracle.com> <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> <576BC331.8000400@oracle.com> <32634325-b80f-81fe-674e-74ba5daa41fb@oracle.com> Message-ID: <576BC91D.9050204@oracle.com> On 6/23/16 04:27, David Holmes wrote: > On 23/06/2016 9:08 PM, serguei.spitsyn at oracle.com wrote: >> On 6/23/16 03:51, David Holmes wrote: >>> On 23/06/2016 6:04 PM, serguei.spitsyn at oracle.com wrote: >>>> On 6/23/16 00:51, Alan Bateman wrote: >>>>> >>>>> >>>>> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >>>>>> : >>>>>> >>>>>> I agree with it. >>>>>> Thank you for pointing to this JVMTI example. >>>>>> I did not find in the JNI where the names are checked to be legal. >>>>>> We are going to open a can of worms with this kind of check as there >>>>>> can be many corner cases to cover. >>>>> The primary use-case for this function is from within the CLFH >>>>> callback so have it return the unnamed module when calling with >>>>> garage >>>>> is probably okay, it just needs to be specified. >>>>> >>>>> Will you update the webrev to reflect where we've got to this in this >>>>> discussion? >>>> >>>> I need to undo my fix for additional check. >>>> My up-to-date understanding is that we have to explicitly specify two >>>> points: >>>> - the function returns the unnamed module if the package does not >>>> exist >>>> - the function does not check the package names for validness and >>>> always returns the unnamed module for illegal package names >>>> >>>> It is better to specify these points explicitly to avoid possible >>>> confusion. >>> >>> I don't agree - nothing else refers to invalid "names" in JVM TI. I >>> don't see any need to call this out here. If the name supplied is not >>> a legal package name then it will not match - end of story. >> >> David, >> >> It was the original approach that is in the CCC. >> You were the one who got confused here, and it convinced me that this >> needs to be more clear. >> All these changes are because you started the discussion. :) >> It was useful anyway. > > I never said anything about illegal package names. True. This is my (probably, wrong) attempt to make it more clear. > >> Are you against both clarifications or just the last one? >> I'm Ok to return it back as it is in the CCC. >> It will save time on the CCC approval. >> >> This is the last addition to the spec: >> >> + The unnamed module is returned if the specified package does not >> exist. > > The notion of "package does not exist" is ill-defined. This case is > already covered by the primary specification. > >> + The function does not check if the specified package name is illegal. > > This does not need to be stated as it is not stated anywhere else for > anything else that may have legal and illegal forms. Good. This is a relevant fragment from current version of CCC: + + Return the java.lang.reflect.Module object for a module + defined to a class loader that contains a given package. + The module is returned via module_ptr. +

+ If a named module is defined to the class loader and it + contains the package then that named module is returned, + otherwise the unnamed module of the class loader is returned. + If the package name is the empty string then this function + always returns the unnamed module for the class loader. +

Does it looks Ok? Thanks, Serguei > > Thanks, > David > >> >> >> Thanks, >> Serguei >> >> >> >> >>> >>> Cheers, >>> David >>> >>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>>> >>>>> -Alan >>>> >> From david.holmes at oracle.com Thu Jun 23 11:37:38 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jun 2016 21:37:38 +1000 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <84b40e40-347d-bb53-7662-9745f894eaa8@oracle.com> <576AC4EC.6070406@oracle.com> <6bdb6f82-517d-e686-4034-dc8f5ae6e9bd@oracle.com> <6e921b20-2fa7-b60d-c310-857180f358dd@oracle.com> <16738fb0-7a98-5a3a-979e-dd162a19541f@oracle.com> Message-ID: On 23/06/2016 9:25 PM, Alan Bateman wrote: > > > On 23/06/2016 12:05, David Holmes wrote: >> >> You said: >> >> "Module system initialization will initialize the built-in class >> loaders, including the application class loader. The platform or >> application class loaders won't load any classes in this phase of >> course but they will be initialized (with the modules that they might >> later load classes from). " >> >> What does that last part mean: "with the modules they might later load >> classes from"? How have modules become bound to a classloader that may >> not even get instantiated? If that class loader is never instantiated >> then why do we need a runtime test that checks for the type of the >> actual system class loader? > The graph of modules that are defined to the runtime during startup are > we call the "boot layer". They are statically mapped to the built-in > class loaders where built-in means the boot, platform or application > class loaders. There may be a custom system class loader that comes into > existence later during the startup but it's just not interesting to the > discussion here (except to know that it might be different to the > application class loader in some niche configuration). But you skipped the key part - why do we care about the built-in loaders. In this code: +// If the module's loader, that a read edge is being established to, is +// not the same loader as this module's and is not one of the 3 builtin +// class loaders, then this module's reads list must be walked at GC +// safepoint. Modules have the same life cycle as their defining class +// loaders and should be removed if dead. +void ModuleEntry::set_read_walk_required(ClassLoaderData* m_loader_data) { + assert_locked_or_safepoint(Module_lock); + if (!_must_walk_reads && + loader_data() != m_loader_data && + !m_loader_data->is_builtin_class_loader_data()) { + _must_walk_reads = true; + if (log_is_enabled(Trace, modules)) { + ResourceMark rm; + log_trace(modules)("ModuleEntry::set_read_walk_required(): module %s reads list must be walked", + (name() != NULL) ? name()->as_C_string() : UNNAMED_MODULE); + } + } +} what is "is_builtin_class_loader_data" really asking? Is it just that this is a loader whose lifetime is matched to that of the VM? If so then it is asking the wrong question with respect to the system loader. If not, then what is it about the built-in system loader type that makes it different to some custom system loader? Thanks, David (PS. Really calling it a night now :) ) > -Alan From david.holmes at oracle.com Thu Jun 23 11:40:31 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jun 2016 21:40:31 +1000 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576BC91D.9050204@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <576B97FD.1080303@oracle.com> <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> <576BC331.8000400@oracle.com> <32634325-b80f-81fe-674e-74ba5daa41fb@oracle.com> <576BC91D.9050204@oracle.com> Message-ID: <95819fd5-e582-3474-a138-7dd3d8761f5e@oracle.com> On 23/06/2016 9:33 PM, serguei.spitsyn at oracle.com wrote: > On 6/23/16 04:27, David Holmes wrote: >> On 23/06/2016 9:08 PM, serguei.spitsyn at oracle.com wrote: >>> On 6/23/16 03:51, David Holmes wrote: >>>> On 23/06/2016 6:04 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 6/23/16 00:51, Alan Bateman wrote: >>>>>> >>>>>> >>>>>> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >>>>>>> : >>>>>>> >>>>>>> I agree with it. >>>>>>> Thank you for pointing to this JVMTI example. >>>>>>> I did not find in the JNI where the names are checked to be legal. >>>>>>> We are going to open a can of worms with this kind of check as there >>>>>>> can be many corner cases to cover. >>>>>> The primary use-case for this function is from within the CLFH >>>>>> callback so have it return the unnamed module when calling with >>>>>> garage >>>>>> is probably okay, it just needs to be specified. >>>>>> >>>>>> Will you update the webrev to reflect where we've got to this in this >>>>>> discussion? >>>>> >>>>> I need to undo my fix for additional check. >>>>> My up-to-date understanding is that we have to explicitly specify two >>>>> points: >>>>> - the function returns the unnamed module if the package does not >>>>> exist >>>>> - the function does not check the package names for validness and >>>>> always returns the unnamed module for illegal package names >>>>> >>>>> It is better to specify these points explicitly to avoid possible >>>>> confusion. >>>> >>>> I don't agree - nothing else refers to invalid "names" in JVM TI. I >>>> don't see any need to call this out here. If the name supplied is not >>>> a legal package name then it will not match - end of story. >>> >>> David, >>> >>> It was the original approach that is in the CCC. >>> You were the one who got confused here, and it convinced me that this >>> needs to be more clear. >>> All these changes are because you started the discussion. :) >>> It was useful anyway. >> >> I never said anything about illegal package names. > > True. > This is my (probably, wrong) attempt to make it more clear. > >> >>> Are you against both clarifications or just the last one? >>> I'm Ok to return it back as it is in the CCC. >>> It will save time on the CCC approval. >>> >>> This is the last addition to the spec: >>> >>> + The unnamed module is returned if the specified package does not >>> exist. >> >> The notion of "package does not exist" is ill-defined. This case is >> already covered by the primary specification. >> >>> + The function does not check if the specified package name is illegal. >> >> This does not need to be stated as it is not stated anywhere else for >> anything else that may have legal and illegal forms. > > Good. > This is a relevant fragment from current version of CCC: > > + > + Return the java.lang.reflect.Module object for a > module > + defined to a class loader that contains a given package. > + The module is returned via module_ptr. > +

> + If a named module is defined to the class loader and it > + contains the package then that named module is returned, > + otherwise the unnamed module of the class loader is returned. > + If the package name is the empty string then this function > + always returns the unnamed module for the class loader. > +

As Stanislav said explicitly mentioning the empty string is not really necessary - but I don't see it as harmful. > Does it looks Ok? Yes - as good now as it was in the CCC discussion :) Cheers, David > > Thanks, > Serguei > >> >> Thanks, >> David >> >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> >>>> >>>> Cheers, >>>> David >>>> >>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>>> >>>>>> -Alan >>>>> >>> > From serguei.spitsyn at oracle.com Thu Jun 23 12:00:46 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Jun 2016 05:00:46 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <95819fd5-e582-3474-a138-7dd3d8761f5e@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <576B97FD.1080303@oracle.com> <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> <576BC331.8000400@oracle.com> <32634325-b80f-81fe-674e-74ba5daa41fb@oracle.com> <576BC91D.9050204@oracle.com> <95819fd5-e582-3474-a138-7dd3d8761f5e@oracle.com> Message-ID: <576BCF6E.9030000@oracle.com> On 6/23/16 04:40, David Holmes wrote: > > > On 23/06/2016 9:33 PM, serguei.spitsyn at oracle.com wrote: >> On 6/23/16 04:27, David Holmes wrote: >>> On 23/06/2016 9:08 PM, serguei.spitsyn at oracle.com wrote: >>>> On 6/23/16 03:51, David Holmes wrote: >>>>> On 23/06/2016 6:04 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 6/23/16 00:51, Alan Bateman wrote: >>>>>>> >>>>>>> >>>>>>> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >>>>>>>> : >>>>>>>> >>>>>>>> I agree with it. >>>>>>>> Thank you for pointing to this JVMTI example. >>>>>>>> I did not find in the JNI where the names are checked to be legal. >>>>>>>> We are going to open a can of worms with this kind of check as >>>>>>>> there >>>>>>>> can be many corner cases to cover. >>>>>>> The primary use-case for this function is from within the CLFH >>>>>>> callback so have it return the unnamed module when calling with >>>>>>> garage >>>>>>> is probably okay, it just needs to be specified. >>>>>>> >>>>>>> Will you update the webrev to reflect where we've got to this in >>>>>>> this >>>>>>> discussion? >>>>>> >>>>>> I need to undo my fix for additional check. >>>>>> My up-to-date understanding is that we have to explicitly specify >>>>>> two >>>>>> points: >>>>>> - the function returns the unnamed module if the package does not >>>>>> exist >>>>>> - the function does not check the package names for validness and >>>>>> always returns the unnamed module for illegal package names >>>>>> >>>>>> It is better to specify these points explicitly to avoid possible >>>>>> confusion. >>>>> >>>>> I don't agree - nothing else refers to invalid "names" in JVM TI. I >>>>> don't see any need to call this out here. If the name supplied is not >>>>> a legal package name then it will not match - end of story. >>>> >>>> David, >>>> >>>> It was the original approach that is in the CCC. >>>> You were the one who got confused here, and it convinced me that this >>>> needs to be more clear. >>>> All these changes are because you started the discussion. :) >>>> It was useful anyway. >>> >>> I never said anything about illegal package names. >> >> True. >> This is my (probably, wrong) attempt to make it more clear. >> >>> >>>> Are you against both clarifications or just the last one? >>>> I'm Ok to return it back as it is in the CCC. >>>> It will save time on the CCC approval. >>>> >>>> This is the last addition to the spec: >>>> >>>> + The unnamed module is returned if the specified package does not >>>> exist. >>> >>> The notion of "package does not exist" is ill-defined. This case is >>> already covered by the primary specification. >>> >>>> + The function does not check if the specified package name is >>>> illegal. >>> >>> This does not need to be stated as it is not stated anywhere else for >>> anything else that may have legal and illegal forms. >> >> Good. >> This is a relevant fragment from current version of CCC: >> >> + >> + Return the java.lang.reflect.Module object for a >> module >> + defined to a class loader that contains a given package. >> + The module is returned via module_ptr. >> +

>> + If a named module is defined to the class loader and it >> + contains the package then that named module is returned, >> + otherwise the unnamed module of the class loader is returned. >> + If the package name is the empty string then this function >> + always returns the unnamed module for the class loader. >> +

> > As Stanislav said explicitly mentioning the empty string is not really > necessary - but I don't see it as harmful. Me too. Stanislav did not insist on this matter. > >> Does it looks Ok? > > Yes - as good now as it was in the CCC discussion :) Great! I'm also waiting for a feedback from Alan. Thanks! Serguei > > Cheers, > David > From dmitry.fazunenko at oracle.com Thu Jun 23 12:52:12 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Thu, 23 Jun 2016 15:52:12 +0300 Subject: RFR: 8160088: update hotspot tests depending on GC to use @requires vm.gc.X In-Reply-To: <931a448e-0e87-59b0-2657-073ac1e34fb2@oracle.com> References: <5594dba8-f008-2fae-d293-d9a2e3f6913a@oracle.com> <684b0ef2-14f2-ed3a-63ef-a65c748e2471@oracle.com> <5b2a01d0-df0d-3826-65f5-a1c48f573e37@oracle.com> <931a448e-0e87-59b0-2657-073ac1e34fb2@oracle.com> Message-ID: David, On 23.06.2016 14:00, David Holmes wrote: > Hi Dmitry, > > On 23/06/2016 6:52 PM, Dmitry Fazunenko wrote: >> Hi David, >> >> thanks for looking! >> >> On 23.06.2016 3:17, David Holmes wrote: >>> Hi Dmitry, >>> >>> On 23/06/2016 4:06 AM, Dmitry Fazunenko wrote: >>>> Hello, >>>> >>>> I'm looking for Reviewers for relatively simple fix which affects 59 >>>> tests. >>>> https://bugs.openjdk.java.net/browse/JDK-8160088 >>>> http://cr.openjdk.java.net/~dfazunen/8160088/webrev.00/ >>>> >>>> The fix allows to skip execution of tests requiring a specific GC in >>>> case of the required GC is not supported by VM. >>>> Old variant: >>>> @requires vm.gc == null | vm.gc == "G1" >>>> A test will be executed if no GC is specified externally or >>>> -XX:+UseG1GC flag is given. >>>> This test will be executed even if VM doesn't support G1 and >>>> fail. >>>> New variant: >>>> @requires vm.gc.G1 >>>> This test will not be executed if VM doesn't support G1. >>> >>> That doesn't seem sufficient. What you want is that if the test >>> requires G1 then it also supports G1, so it seems to me the correct >>> formulation is: >>> >>> @requires (vm.gc == null | // null -> default -> g1 (usually) >>> vm.gc == G1 ) & >>> vm.gc.G1 >> >> No, vm.gc.G1 is an alias to: (vm.gc == null | vm.gc == g1) & >> vm.gc.supportsG1. > > Wow - on the one hand that is a compact/succinct syntax. On the other > hand - no one will recognize what it actually means! I think I have > missed a discussed I would like to have given input on! It was discussed on hotspot-gc-dev alias as part of '8151283' review: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-June/018352.html Originally it was proposed names like: vm.gc.G1.acceptable but after input from GC dev, vm.gc.G1 was selected. Documentation how the properties are set what that mean is available in the class source (jtreg plugin): /test/jtreg-ext/requires/VMProps.java > >>> >>> Aside: how does jtreg determine which GC's are supported? >> Sorry for not providing the full history here: >> >> CODETOOLS-7901583: jtreg should provide extensible mechanism for >> @requires properties >> - change to jtreg that allows a Test Suite to introduce its own >> @requires props >> >> JDK-8152432: Implement setting jtreg @requires properties vm.flavor, >> vm.bits, vm.compMode >> - implementation that mechanism in hotspot >> >> JDK-8154096: Extend WhiteBox API with methods which retrieve from VM >> information about available GC >> - fix which allows to know if a GC is supported >> >> JDK-8151283: Implement setting jtreg @requires property >> vm.isG1Supported. >> - introduction vm.gc.G1, vm.gc.Serial, vm.gc.Parallel and >> vm.gc.ConcMarkSweep >> >> JDK-8160088 (this one): update hotspot tests depending on GC to use >> @requires vm.gc.X >> - culmination: update tests to use new functionality > > Wow I have missed out on a lot it seem! :( > > What version of jtreg supports this level of customized @requires? > Someone has already encountered the following error: > > Error. Parse Exception: Syntax error in @requires expression: invalid > name: XXX > > for a new @requires XXX clause. It was implemented in the final build of jtreg4.1 and of course it's available in jtreg4.2 Quiting jtreg/doc/jtreg/tag-spec.html: |requires.extraPropDefns | This option is used to provide source files for classes that will be used at the beginning of each test suite run, to determine additional characteristics of the system for use with the |@requires| tag. Each class must implement |java.util.concurrent.Callable>|. When invoked, the |call()| method should return properties that can be referenced in an expression in a |@requires| tag. /Note:/ the names of the new properties that may be returned by calling these classes must also be declared in a |requires.properties| entry. If this option is specified, the following additional options may also be specified: * |requires.extraPropDefns.libs | ? source files for classes that will be put on the classpath when the primary classes are run. * |requires.extraPropDefns.bootlibs | ? source files for classes that will be put on the bootclasspath when the primary classes are run. * |requires.extraPropDefns.javacOpts | ? options that will be passed to javac when the source files are compiled. * |requires.extraPropDefns.vmOpts | ? options that will be passed to VM when the classes are executed. In this family of options, if a source file is enclosed in square brackets, no error message will be given if the file is not available. The following properties may appear in either TEST.ROOT or any TEST.properties file: The reason, why @requires XXX is not recognized by jtreg - XXX is not registered in TEST.ROOT. See: hotspot/test/TEST.ROOT for example on how to register new props. For the time being recently introduced requires properties are available only in the hotspot repository. To introduce them in jdk - a few lines from hotspot/test/TEST.ROOT should be placed in jdk/test/TEST.ROOT We haven't done this yet, because we are considering a possibility to move VM specific tests from jdk into hotspot repo. Thanks, Dima > > Thanks, > David > >> Thanks, >> Dima >> >>> >>> Thanks, >>> David >>> >>>> Testing: >>>> 1) starting jtreg with various collectors with "-c" option to verify >>>> correctness of test descriptions. >>>> Number of selected tests before and after change is the same: >>>> -XX:+UseG1GC: 1,456 >>>> -XX:+UseSerialGC: 1,366 >>>> -XX:+UseParallelGC: 1,369 >>>> -XX:+UseConcMarkSweepGC: 1,368 >>>> Default: 1,483; error >>>> >>>> 2) RBT (in progress) >>>> >>>> 3) Diff is analyzed manually (only necessary lines are affected): >>>> #> hg diff |grep "^- " |sort -u >>>> - * @requires (vm.gc == "G1" | vm.gc == "null") >>>> - * @requires (vm.gc=="G1" | vm.gc=="null") >>>> - * @requires vm.gc == "G1" | vm.gc == "null" >>>> - * @requires vm.gc=="ConcMarkSweep" | vm.gc == "null" >>>> - * @requires vm.gc=="ConcMarkSweep" | vm.gc=="null" >>>> - * @requires vm.gc=="G1" | vm.gc =="null" >>>> - * @requires vm.gc=="G1" | vm.gc=="null" >>>> - * @requires vm.gc=="Parallel" | vm.gc=="null" >>>> - * @requires vm.gc=="Serial" | vm.gc=="null" >>>> - * @requires vm.gc=="null" | vm.gc=="G1" >>>> - * Copyright (c) 2013, 2014, Oracle and/or its affiliates. All rights >>>> reserved. >>>> - * Copyright (c) 2013, 2015, Oracle and/or its affiliates. All rights >>>> reserved. >>>> - * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All rights >>>> reserved. >>>> - * Copyright (c) 2015, Oracle and/or its affiliates. All rights >>>> reserved. >>>> #> hg diff |grep "^+ " |sort -u >>>> + * @requires vm.gc.ConcMarkSweep >>>> + * @requires vm.gc.G1 >>>> + * @requires vm.gc.Parallel >>>> + * @requires vm.gc.Serial >>>> + * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All rights >>>> reserved. >>>> + * Copyright (c) 2014, 2016, Oracle and/or its affiliates. All rights >>>> reserved. >>>> + * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights >>>> reserved. >>>> >>>> Thanks, >>>> Dima >> From stanislav.lukyanov at oracle.com Thu Jun 23 13:02:57 2016 From: stanislav.lukyanov at oracle.com (stanislav lukyanov) Date: Thu, 23 Jun 2016 16:02:57 +0300 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <95819fd5-e582-3474-a138-7dd3d8761f5e@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <576B97FD.1080303@oracle.com> <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> <576BC331.8000400@oracle.com> <32634325-b80f-81fe-674e-74ba5daa41fb@oracle.com> <576BC91D.9050204@oracle.com> <95819fd5-e582-3474-a138-7dd3d8761f5e@oracle.com> Message-ID: There were different points in the discussion I didn't have a chance to comment in time, so I'll just summarize everything here not to break the thread flow with answers to older messages. First of all, I'm perfectly fine with either approach (adding name validation or not) as long as the behavior is clearly documented. I think it should be specified that unnamed module will be returned even if there cannot ever be a package with that name. It is not a complicated case to specify, but it brings much more clarity. Formally, now the function is specified to work with "package names" and the behavior on a string that is clearly not a "package name" is unspecified. The empty string case may or may not be specified. It may be considered another corner case, different from both "legal" and "illegal" package names, but I personally think that the behavior is clear anyway. I don't think the argument that JVMTI doesn't validate names is correct. GetLocalVariableTable doesn't look like a good example here, since it just reads data that's already in the VM anyway, but in case of GetModuleByPackageName it is about validation of input parameters. Other APIs that take identifiers like, for example, JNI FindClass or GetMethodID don't specify name checks explicitly, but throw ClassNotFoundError/NoSuchMethodError illegal names. It looks like GetModuleByPackageName is the first JNI/JVMTI function to succeed when an ill-formed identifier is passed, so it deserves to be documented. On CCC update: AFAIU CCC needs to have final version of the proposed specification, so yes, it needs to be updated to with the test that will be actually pushed to the workspace. Thanks, Stas On 23.06.2016 14:40, David Holmes wrote: > > > On 23/06/2016 9:33 PM, serguei.spitsyn at oracle.com wrote: >> On 6/23/16 04:27, David Holmes wrote: >>> On 23/06/2016 9:08 PM, serguei.spitsyn at oracle.com wrote: >>>> On 6/23/16 03:51, David Holmes wrote: >>>>> On 23/06/2016 6:04 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 6/23/16 00:51, Alan Bateman wrote: >>>>>>> >>>>>>> >>>>>>> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >>>>>>>> : >>>>>>>> >>>>>>>> I agree with it. >>>>>>>> Thank you for pointing to this JVMTI example. >>>>>>>> I did not find in the JNI where the names are checked to be legal. >>>>>>>> We are going to open a can of worms with this kind of check as >>>>>>>> there >>>>>>>> can be many corner cases to cover. >>>>>>> The primary use-case for this function is from within the CLFH >>>>>>> callback so have it return the unnamed module when calling with >>>>>>> garage >>>>>>> is probably okay, it just needs to be specified. >>>>>>> >>>>>>> Will you update the webrev to reflect where we've got to this in >>>>>>> this >>>>>>> discussion? >>>>>> >>>>>> I need to undo my fix for additional check. >>>>>> My up-to-date understanding is that we have to explicitly specify >>>>>> two >>>>>> points: >>>>>> - the function returns the unnamed module if the package does not >>>>>> exist >>>>>> - the function does not check the package names for validness and >>>>>> always returns the unnamed module for illegal package names >>>>>> >>>>>> It is better to specify these points explicitly to avoid possible >>>>>> confusion. >>>>> >>>>> I don't agree - nothing else refers to invalid "names" in JVM TI. I >>>>> don't see any need to call this out here. If the name supplied is not >>>>> a legal package name then it will not match - end of story. >>>> >>>> David, >>>> >>>> It was the original approach that is in the CCC. >>>> You were the one who got confused here, and it convinced me that this >>>> needs to be more clear. >>>> All these changes are because you started the discussion. :) >>>> It was useful anyway. >>> >>> I never said anything about illegal package names. >> >> True. >> This is my (probably, wrong) attempt to make it more clear. >> >>> >>>> Are you against both clarifications or just the last one? >>>> I'm Ok to return it back as it is in the CCC. >>>> It will save time on the CCC approval. >>>> >>>> This is the last addition to the spec: >>>> >>>> + The unnamed module is returned if the specified package does not >>>> exist. >>> >>> The notion of "package does not exist" is ill-defined. This case is >>> already covered by the primary specification. >>> >>>> + The function does not check if the specified package name is >>>> illegal. >>> >>> This does not need to be stated as it is not stated anywhere else for >>> anything else that may have legal and illegal forms. >> >> Good. >> This is a relevant fragment from current version of CCC: >> >> + >> + Return the java.lang.reflect.Module object for a >> module >> + defined to a class loader that contains a given package. >> + The module is returned via module_ptr. >> +

>> + If a named module is defined to the class loader and it >> + contains the package then that named module is returned, >> + otherwise the unnamed module of the class loader is returned. >> + If the package name is the empty string then this function >> + always returns the unnamed module for the class loader. >> +

> > As Stanislav said explicitly mentioning the empty string is not really > necessary - but I don't see it as harmful. > >> Does it looks Ok? > > Yes - as good now as it was in the CCC discussion :) > > Cheers, > David > >> >> Thanks, >> Serguei >> >>> >>> Thanks, >>> David >>> >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> -Alan >>>>>> >>>> >> From lois.foltan at oracle.com Thu Jun 23 13:53:15 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 23 Jun 2016 09:53:15 -0400 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <84b40e40-347d-bb53-7662-9745f894eaa8@oracle.com> <576AC4EC.6070406@oracle.com> <6bdb6f82-517d-e686-4034-dc8f5ae6e9bd@oracle.com> <6e921b20-2fa7-b60d-c310-857180f358dd@oracle.com> <16738fb0-7a98-5a3a-979e-dd162a19541f@oracle.com> Message-ID: <576BE9CB.5080109@oracle.com> On 6/23/2016 7:37 AM, David Holmes wrote: > On 23/06/2016 9:25 PM, Alan Bateman wrote: >> >> >> On 23/06/2016 12:05, David Holmes wrote: >>> >>> You said: >>> >>> "Module system initialization will initialize the built-in class >>> loaders, including the application class loader. The platform or >>> application class loaders won't load any classes in this phase of >>> course but they will be initialized (with the modules that they might >>> later load classes from). " >>> >>> What does that last part mean: "with the modules they might later load >>> classes from"? How have modules become bound to a classloader that may >>> not even get instantiated? If that class loader is never instantiated >>> then why do we need a runtime test that checks for the type of the >>> actual system class loader? >> The graph of modules that are defined to the runtime during startup are >> we call the "boot layer". They are statically mapped to the built-in >> class loaders where built-in means the boot, platform or application >> class loaders. There may be a custom system class loader that comes into >> existence later during the startup but it's just not interesting to the >> discussion here (except to know that it might be different to the >> application class loader in some niche configuration). > > But you skipped the key part - why do we care about the built-in > loaders. In this code: > > +// If the module's loader, that a read edge is being established to, is > +// not the same loader as this module's and is not one of the 3 builtin > +// class loaders, then this module's reads list must be walked at GC > +// safepoint. Modules have the same life cycle as their defining class > +// loaders and should be removed if dead. > +void ModuleEntry::set_read_walk_required(ClassLoaderData* > m_loader_data) { > + assert_locked_or_safepoint(Module_lock); > + if (!_must_walk_reads && > + loader_data() != m_loader_data && > + !m_loader_data->is_builtin_class_loader_data()) { > + _must_walk_reads = true; > + if (log_is_enabled(Trace, modules)) { > + ResourceMark rm; > + log_trace(modules)("ModuleEntry::set_read_walk_required(): > module %s reads list must be walked", > + (name() != NULL) ? name()->as_C_string() : > UNNAMED_MODULE); > + } > + } > +} > > what is "is_builtin_class_loader_data" really asking? Is it just that > this is a loader whose lifetime is matched to that of the VM? If so > then it is asking the wrong question with respect to the system > loader. If not, then what is it about the built-in system loader type > that makes it different to some custom system loader? Hi David, The 3 built-in loaders will never be GC'ed, neither will a custom system classloader if there is one configured. Thus the JVM can make reliable assumptions based on modules defined to those 3 loaders. So if for example, a module's reads list only has established read edges to modules that are defined to any of the 3 built-in loaders, the JVM can rely on the fact that these loaders will never die and thus their modules will never die. So at a GC safepoint, that module's reads list will not have to be walked looking for dead modules that should be removed. Lois > > Thanks, > David > > (PS. Really calling it a night now :) ) > >> -Alan From mail at smogura.eu Wed Jun 22 13:43:54 2016 From: mail at smogura.eu (=?utf-8?B?UmFkb3PFgmF3IFNtb2d1cmE=?=) Date: Wed, 22 Jun 2016 13:43:54 +0000 Subject: JDK debug builds on OSX copying dSYM In-Reply-To: <5769E75D.2040107@oracle.com> References: <1030E294-0E3B-4D1D-BA23-357E94A8CF9C@outlook.com> <5769E75D.2040107@oracle.com> Message-ID: Hi Erik, Thank you for checking this. I?m a bit confused about NativeCompilation.gmk. Originally, first patch was related to basics.m4 in common tree - # Always force rm. - RM="$RM -f" + # Always force rm and make it recursive + RM="$RM -rf? In any way, today I have rechecked things again on JDK9, but without above change (I?ve left only parenthesis fix) and I haven't reproduced error that dSYM could not be removed as it is folder. Best regards, Radek > On 22 Jun 2016, at 03:18, Erik Joelsson wrote: > > The parentheses is definitely a bug, but I don't see why we need recursive delete by default. In what situation is the *.dSYM dir not being deleted? > > I did notice that things got weird in NativeCompilation.gmk which I fixed like this: > > diff -r 1db1ada70b16 make/common/NativeCompilation.gmk > --- a/make/common/NativeCompilation.gmk > +++ b/make/common/NativeCompilation.gmk > @@ -833,7 +833,8 @@ > # The dependency on TARGET is needed on windows for debuginfo files > # to be rebuilt properly. > $$($1_OUTPUT_DIR)/% : $$($1_OBJECT_DIR)/% $$($1_TARGET) > - # Use cp -r since on macosx, the dSYM is a directory > + # Use -r since on macosx, the dSYM is a directory > + $(RM) -r $$@ > $(CP) -r $$< $$@ > endif > > /Erik > > On 2016-06-21 14:33, Rados?aw Smogura wrote: >> Hi Vladimir, >> >> I?m so sorry, I haven?t checked for such list and thank you for forwarding :) >> >> Bets regards, >> Radek >>> On 21 Jun 2016, at 22:31, Vladimir Kozlov wrote: >>> >>> Thank you, Radek >>> >>> This should be reviewed in 'build' mailing list. >>> >>> Thanks, >>> Vladimir >>> >>> -------- Forwarded Message -------- >>> Subject: JDK debug builds on OSX copying dSYM >>> Date: Mon, 20 Jun 2016 21:01:48 +0000 >>> From: Rados?aw Smogura >>> To: hotspot-compiler-dev at openjdk.java.net >>> >>> Hello, >>> >>> Recently I tried to compile JDK9 on OS X, I've found two issues related to installing debug symbols, which on OSX are package-folders. >>> >>> 1. Install-file macro doesn't remove dSYM folder, as used rm -f, instead of rm -rf >>> 2. There was additional parenthesis in Dist.gmk which caused dSYM not to be copied. >>> >>> The overview of changes is attached. >>> >>> Kind regards, >>> Radek Smogura >>> >>> > From jesper.wilhelmsson at oracle.com Thu Jun 23 15:04:24 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 23 Jun 2016 17:04:24 +0200 Subject: RFR: 8048093 - Explicitly setting := vs = in the -XX:+PrintFlagsFinal output In-Reply-To: <838ed626-566c-963c-9b9b-2fb76e0820cf@oracle.com> References: <838ed626-566c-963c-9b9b-2fb76e0820cf@oracle.com> Message-ID: <1eeb5ef3-06bc-072a-070b-b3732cf5332b@oracle.com> Den 22/6/16 kl. 21:33, skrev Coleen Phillimore: > > I agree with Vladimir. There's no way I'm going to remember that a colon mean > that the value was changed. The colon is what we have today to indicate that a value was changed :) I made a different solution in which I explicitly print the origin with words. To make it look better I changed the printing routine somewhat. The origin is currently at the end of the line. This version will also print other origins like config file, environment, and management as suggested by Dan. New webrev: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.01/ Examples of -XX:+PrintFlagsFinal with and without the change: This is the new version: ccstr AbortVMOnExceptionMessage = {diagnostic} {default} uintx AdaptiveSizeDecrementScaleFactor = 4 {product} {default} intx AliasLevel = 3 {C2 product} {default} intx CMSAbortablePrecleanWaitMillis = 100 {manageable} {default} bool CMSClassUnloadingEnabled = false {product} {command line} intx ConditionalMoveLimit = 3 {C2 pd product} {default} size_t InitialHeapSize = 134217728 {product} {ergonomic} size_t MaxMetaspaceSize = 18446744073709547520 {product} {default} size_t NewSize = 1966080 {product} {command line, ergonomic} ccstrlist OnError = {product} {default} intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = -1 {develop} {default} bool UseAdaptiveGenerationSizePolicyAtMajorCollection = true {product} {default} bool UseCISCSpill = true {C2 pd develop} {default} bool UseCLMUL = true {ARCH product} {default} bool UseCompressedOops = true {lp64_product} {ergonomic} bool UseConcMarkSweepGC = true {product} {command line} This is the old (current) version: ccstr AbortVMOnExceptionMessage = {diagnostic} uintx AdaptiveSizeDecrementScaleFactor = 4 {product} intx AliasLevel = 3 {C2 product} intx CMSAbortablePrecleanWaitMillis = 100 {manageable} bool CMSClassUnloadingEnabled := false {product} intx ConditionalMoveLimit = 3 {C2 pd product} size_t InitialHeapSize := 134217728 {product} size_t MaxMetaspaceSize = 18446744073709547520 {product} size_t NewSize := 1966080 {product} ccstrlist OnError = {product} intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = -1 {develop} bool UseAdaptiveGenerationSizePolicyAtMajorCollection = true {product} bool UseCISCSpill = true {C2 pd develop} bool UseCompressedOops := true {lp64_product} bool UseConcMarkSweepGC := true {product} /Jesper > Coleen > > > On 6/21/16 4:15 PM, Vladimir Kozlov wrote: >> Nobody will remember the meaning of such marking. You should use normal words. >> The output already have flag's type as, for example, "{C2 product}". You can >> add an other word there to indicate type of initialization: >> default|command|ergo. >> >> Thanks, >> Vladimir >> >> On 6/21/16 12:09 PM, Jesper Wilhelmsson wrote: >>> Hi, >>> >>> Please review this change to make -XX:+PrintFlagsFinal distinguish between >>> flags changed on the command line and flags >>> changed by the ergonomics. >>> >>> To enable us to remember if a flag was set on the command line or not after >>> having been changed by the ergonomics I use >>> another bit in the Flag struct. >>> >>> The actual symbols printed by PrintFlagsFinal are chosen somewhat arbitrary >>> and I'm open to suggestions (bike sheding) >>> about how to visualize this the best. >>> >>> The old decorations are: >>> >>> ' =' - Default value (no decoration) >>> ':=' - Value was changed, either by command line or ergonomics or other >>> >>> The new decorations are: >>> >>> ' =' - Default value (no decoration) >>> ':=' - Set on the command line >>> '?=' - Changed by the ergonomics >>> '!=' - Set on the command line AND changed by the ergonomics >>> '-=' - Any other origin, like changed by management API or taken from a >>> config file >>> >>> My reasoning behind selecting these characters are that ':=' looks like a >>> solid assignment and will therefore represent >>> the command line. You never know what you get from the ergonomics, so '?=' >>> seems appropriate. '!=' because you'd want to >>> know that the ergonomics changed a value you had set on the command line. >>> >>> Another option could be to use a colon ':=' for the command line, and a >>> comma ',=' for the ergonomics. That would >>> naturally give us the semi-colon ';=' for something set on the command line >>> and changed by the ergonomics. I didn't go >>> with this because the colon and semi-colon can be hard to distinguish from >>> each other. >>> >>> As mentioned above there are other origins, the enum contains eight values. >>> There is no mention of the other types in >>> the bug and there are no is_...() for the other types in globals.cpp, so >>> they didn't seem as important. If the general >>> opinion is that these other origins are as important, or we might as >>> well..., I'd suggest that we use letters as >>> decorations. Let me know if you have an opinion. >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048093 >>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.00/ >>> >>> Thanks, >>> /Jesper > From aph at redhat.com Thu Jun 23 16:18:30 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Jun 2016 17:18:30 +0100 Subject: RFD: C2 bug: 8157306 random infrequent null pointer exceptions in javac In-Reply-To: <50693eff-01c3-9791-ca4d-b979ad0deb91@oracle.com> References: <576AD768.3070005@redhat.com> <50693eff-01c3-9791-ca4d-b979ad0deb91@oracle.com> Message-ID: <576C0BD6.4000106@redhat.com> On 22/06/16 22:13, Vladimir Kozlov wrote: > Thank you, Andrew, for finding the cause of this problem. > Your fix looks good to me. Can you also add changes for the assert you mentioned - I think it is useful. > And, please, prepare webrev. http://cr.openjdk.java.net/~aph/8157306.1/ There is no point putting an assert in call_catch_cleanup() immediately after we insert the precedence edges. I think it is best to put the assert in verify_cfg(), where it makes the most sense. I had to make verify_anti_dependences() const in order to call it from verify_cfg(). I hope this is OK. Thanks, Andrew. From aph at redhat.com Thu Jun 23 16:33:46 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Jun 2016 17:33:46 +0100 Subject: RFR: 8160189: Fix for 8159335 breaks AArch64 Message-ID: <576C0F6A.5050806@redhat.com> http://cr.openjdk.java.net/~aph/8160189/ Thanks, Andrew. From coleen.phillimore at oracle.com Thu Jun 23 16:47:54 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 23 Jun 2016 12:47:54 -0400 Subject: RFR: 8160189: Fix for 8159335 breaks AArch64 In-Reply-To: <576C0F6A.5050806@redhat.com> References: <576C0F6A.5050806@redhat.com> Message-ID: <312d1a6c-9bf3-29b9-49e2-e8f270b9a4b3@oracle.com> Looks good. Sorry for the breakage. Coleen On 6/23/16 12:33 PM, Andrew Haley wrote: > http://cr.openjdk.java.net/~aph/8160189/ > > Thanks, > > Andrew. From kim.barrett at oracle.com Thu Jun 23 17:07:57 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 23 Jun 2016 13:07:57 -0400 Subject: RFR: 8160189: Fix for 8159335 breaks AArch64 In-Reply-To: <576C0F6A.5050806@redhat.com> References: <576C0F6A.5050806@redhat.com> Message-ID: <7175EE7C-1722-48A5-8AA1-8895443A7628@oracle.com> > On Jun 23, 2016, at 12:33 PM, Andrew Haley wrote: > > http://cr.openjdk.java.net/~aph/8160189/ > > Thanks, > > Andrew. Looks good. From aph at redhat.com Thu Jun 23 17:10:09 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Jun 2016 18:10:09 +0100 Subject: RFR: 8160189: Fix for 8159335 breaks AArch64 In-Reply-To: <312d1a6c-9bf3-29b9-49e2-e8f270b9a4b3@oracle.com> References: <576C0F6A.5050806@redhat.com> <312d1a6c-9bf3-29b9-49e2-e8f270b9a4b3@oracle.com> Message-ID: <576C17F1.7010107@redhat.com> On 23/06/16 17:47, Coleen Phillimore wrote: > Looks good. Sorry for the breakage. No problem at all. Thanks, Andrew. From vladimir.kozlov at oracle.com Thu Jun 23 17:57:10 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Jun 2016 10:57:10 -0700 Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation on ppc64 and sparc In-Reply-To: References: <27dde86d-f7b3-3093-e500-cd3c9156811f@oracle.com> <5767AD68.8090500@oracle.com> <5767B078.8030102@oracle.com> <5768FE79.2060301@oracle.com> Message-ID: <78048e75-621e-c8fe-b9fd-ee1a5842aa8d@oracle.com> Reviewed. PPC changes looks fine. SPARC changes are good - I was worried about annulling in branch in increment_mask_and_jump() but it is fine since it is false. C1 - new check is correct. Test is fine. Thanks, Vladimir On 6/22/16 7:29 AM, Volker Simonis wrote: > On Tue, Jun 21, 2016 at 10:44 AM, Tobias Hartmann > wrote: >> Hi Volker, >> >> On 21.06.2016 09:37, Volker Simonis wrote: >>> On Mon, Jun 20, 2016 at 10:59 AM, Tobias Hartmann >>> wrote: >>>> Hi Volker, >>>> >>>> On 20.06.2016 10:52, Volker Simonis wrote: >>>>> Hi Tobias, >>>>> >>>>> thanks for sponsoring! I've uploaded a new webrev with you and >>>>> Vladimir as reviewers: >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v2/ >>>>> >>>>> You can find the changeset there: >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v2/hotspot.changeset >>>> >>>> Thanks, I just noticed that the test has >>>> >>>> 26 * @bug 9999999 >>>> >>>> You can fix this in-place. I'll then run the required pre-integration testing (~24h) and push your change afterwards. >>>> >>> >>> Hi Tobias, >>> >>> good catch and sorry, I somehow missed your mail yesterday. >>> >>> You can find the new changeset here: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v3/hotspot.changeset >> >> Thank you! >> >> I just looked at the test results and unfortunately DisableOSRTest fails on all platforms (including SPARC) if -Xcomp is set: >> >> ----------System.err:(13/1215)---------- >> java.lang.RuntimeException: "public static void DisableOSRTest.main(java.lang.String[]) throws java.lang.Exception" shouldn't be OSR compiled if running with -XX:-UseOnStackReplacement! >> at DisableOSRTest.main(DisableOSRTest.java:59) >> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base/Native Method) >> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base/NativeMethodAccessorImpl.java:62) >> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base/DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(java.base/Method.java:531) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) >> at java.lang.Thread.run(java.base/Thread.java:843) >> >> There are several OSR compilations in the log: >> >> 12916 4242 % b 4 DisableOSRTest::main @ 19 (61 bytes) >> > > Hi Tobias, > > you're right! Thanks for finding this new problem:) > > I initially only fixed OSR from interpreted code. But C1 compiled code > can also trigger an OSR request (and -Xcomp triggers a C1 compilation > of main before it is invoked for the first time). Switching this off > with the help of -XX:-UseOnStackReplacement never worked, but it was > actually easy to fix. Please find the new change here: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v4/ > > I think it would good if somebody (maybe the initial reviewers) could > review the new C1 changes to prevent OSR in C1-compiled code. > > Thank you and best regards, > Volker > > >> Best regards, >> Tobias >> >>> >>> Thank you and best regards, >>> Volker >>> >>> >>>> Best regards, >>>> Tobias >>>> >>>>> >>>>> Thanks, >>>>> Volker >>>>> >>>>> >>>>> On Mon, Jun 20, 2016 at 10:46 AM, Tobias Hartmann >>>>> wrote: >>>>>> Hi Volker, >>>>>> >>>>>> you fix looks good to me! I can do the sponsoring, please just send me a changeset. >>>>>> >>>>>> Best regards, >>>>>> Tobias >>>>>> >>>>>> On 20.06.2016 10:16, Volker Simonis wrote: >>>>>>> Thanks Vladimir! >>>>>>> >>>>>>> .. I still need a sponsor :( >>>>>>> >>>>>>> Regards, >>>>>>> Volker >>>>>>> >>>>>>> >>>>>>> On Fri, Jun 17, 2016 at 10:53 PM, Vladimir Kozlov >>>>>>> wrote: >>>>>>>> Looks good. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> >>>>>>>> On 6/17/16 2:22 AM, Volker Simonis wrote: >>>>>>>>> >>>>>>>>> Hi Goetz, >>>>>>>>> >>>>>>>>> thanks for the review. >>>>>>>>> You're right, I've fixed the "else": >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v1/ >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Volker >>>>>>>>> >>>>>>>>> On Fri, Jun 17, 2016 at 11:08 AM, Lindenmaier, Goetz >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi Volker, >>>>>>>>>> >>>>>>>>>> thanks for doing this fix, I also have run into this issue before ... >>>>>>>>>> Looks good. >>>>>>>>>> >>>>>>>>>> Small nit: usually >>>>>>>>>> } >>>>>>>>>> else { >>>>>>>>>> are on one line. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>>>>>>>>> Behalf Of Volker Simonis >>>>>>>>>>> Sent: Donnerstag, 16. Juni 2016 16:54 >>>>>>>>>>> To: HotSpot Open Source Developers >>>>>>>>>>> Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work >>>>>>>>>>> together with -XX:+TieredCompilation on ppc64 and sparc >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> can I please have a review and sponsor for the following small change >>>>>>>>>>> which fixes -XX:-UseOnStackReplacement to work together with >>>>>>>>>>> -XX:+TieredCompilation: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620/ >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8159620 >>>>>>>>>>> >>>>>>>>>>> This is a long standing bug on SPARC and as the ppc64 template >>>>>>>>>>> interpreter was initially forked from the SPARC implementation, it >>>>>>>>>>> also manifests there. The problem is that in the case of tiered >>>>>>>>>>> compilation the interpreter unconditionally calls >>>>>>>>>>> InterpreterRuntime::frequency_counter_overflow if the back edge >>>>>>>>>>> counter overflows. This triggers an OSR compilation, even if OSR was >>>>>>>>>>> switched off with -XX:-UseOnStackReplacement. >>>>>>>>>>> >>>>>>>>>>> The fix is simple - just don't call >>>>>>>>>>> InterpreterRuntime::frequency_counter_overflow if OSR has been >>>>>>>>>>> switched off. >>>>>>>>>>> >>>>>>>>>>> Thank you and best regards, >>>>>>>>>>> Volker From max.ockner at oracle.com Thu Jun 23 18:03:56 2016 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 23 Jun 2016 14:03:56 -0400 Subject: RFR: 8038332: The trace event vm/class/load is not always being sent In-Reply-To: <23a73321-9ad4-c49f-ba9d-841b0754e21c@oracle.com> References: <5759AFCE.2080406@oracle.com> <575EF096.9020908@oracle.com> <95d4e379-2680-1e49-f972-831e4e1701ba@oracle.com> <57683F13.5070900@oracle.com> <642636BA-2185-482E-B022-A57002568FAA@oracle.com> <23a73321-9ad4-c49f-ba9d-841b0754e21c@oracle.com> Message-ID: <576C248C.9070009@oracle.com> Replies inline. Thanks, Max On 6/22/2016 3:13 PM, Coleen Phillimore wrote: > > Hi, > > Can I suggest actually fixing this code? Please? > Sure! > Instead of returning THREAD in all the calls in parse_stream(), they > should have CHECK_NULL. Then all the if (!HAS_PENDING_EXCEPTION) > conditionals can be removed and the logic fixed. > This has been changed for each occurrence of THREAD except for in MutexLocker and ResourceMark. > The only reason to have THREAD as the last parameter is if there's > cleanup that needs to be done in the case of an exception, which is > rare and I verified not the case in this function. > > After this code put a return NULL; > > Exceptions::_throw_msg(THREAD_AND_LOCATION, > vmSymbols::java_lang_SecurityException(), message); > // add return NULL; > } > I have followed Ioi's suggestion here to use THROW_MSG_NULL(vmSymbols::java_lang_SecurityException(), message); > Otherwise, the code to add the event looks good. > > Thanks, > Coleen > > > On 6/22/16 1:53 PM, Jiangli Zhou wrote: >> Hi Max, >> >> I see there is already an ?if (!HAS_PENDING_EXCEPTION)? check at line >> 1170 before the debug_only code. Maybe you cloud place the >> post_class_load_event() in there so it only post the event when there >> is no pending exception. That way you don?t need to change the >> existing logic and add the additional checks. >> >> Thanks, >> Jiangli >> >>> On Jun 20, 2016, at 12:08 PM, Max Ockner wrote: >>> >>> David, >>> >>> New webrev: >>> http://cr.openjdk.java.net/~mockner/8038332.02/src/share/vm/classfile/systemDictionary.cpp.cdiff.html >>> I have added the check you suggested before triggering the event: >>> >>> if (HAS_PENDING_EXCEPTION || k.is_null()) { >>> return NULL; >>> } >>> >>> Thanks, >>> Max >>> >>> On 6/13/2016 6:40 PM, David Holmes wrote: >>>> Hi Max, >>>> >>>> On 14/06/2016 3:42 AM, Max Ockner wrote: >>>>> Jiangli, >>>>> Thanks for looking. I didn't see anything that looked like it might >>>>> produce duplicate events. However, I did see some additional places >>>>> where it looks like no event is fire. >>>>> >>>>> Can anyone point me to the event specs? >>>> I'm not sure there is any spec for this. Even JFR doesn't seem to >>>> document individual events and when they are triggered. >>>> >>>> Your change does not look right however as you are posting the >>>> classload event regardless of the exception state. If you look at >>>> SystemDictionary::resolve_instance_class_or_null, it only posts >>>> after checking the load was successful: >>>> >>>> 892 if (HAS_PENDING_EXCEPTION || k.is_null()) { >>>> 893 return NULL; >>>> 894 } >>>> 895 >>>> 896 post_class_load_event(class_load_start_time, k, class_loader); >>>> >>>> Similarly, SystemDictionary::parse_stream, has various CHECK macros >>>> that will cause a return on exception, prior to getting to the >>>> point of posting the load event. So you also need to add a check >>>> for a pending exception and that k is not null, I think, before >>>> posting the event. >>>> >>> I have added this check. >>>> BTW I would have expected to see trace-events generated at >>>> approximately the same locations as the corresponding JVMTI events. >>>> That does not seem to be the case which seems very strange to me. >>>> The notion of "loading a class" seems to be spread across far too >>>> many functions to me. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> On 6/9/2016 4:39 PM, Jiangli Zhou wrote: >>>>>> Hi Max, >>>>>> >>>>>> Looks ok. The only possible issue is more than one event might be >>>>>> sent >>>>>> in some of the call paths. But my quick search didn?t find any of >>>>>> such >>>>>> case. >>>>>> >>>>>> Thanks, >>>>>> Jiangli >>>>>> >>>>>>> On Jun 9, 2016, at 11:05 AM, Max Ockner >>>>>>> wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Please review this small fix which causes the vm/class/load >>>>>>> event to >>>>>>> be fired from JVM_DefineClass() and JVM_DefineClassWithSource(). >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8038332/ >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038332 >>>>>>> >>>>>>> The vm/class/load event (EventClassLoad) was previously fired in 2 >>>>>>> places: >>>>>>> >>>>>>> SystemDictionary::parse_stream >>>>>>> SystemDictionary::resolve_instance_class_or_null >>>>>>> >>>>>>> parse_stream is the standard option for creating a klass from a >>>>>>> stream, but JVM_DefineClass uses a different function: >>>>>>> >>>>>>> SystemDictionary::resolve_from_stream. >>>>>>> >>>>>>> This did not fire a vm/class/load event. Now it does fire the >>>>>>> event. >>>>>>> >>>>>>> Sanity tested with jtreg runtime. Issue was reproduced and tested >>>>>>> using the reproducer script attached to the bug >>>>>>> >>>>>>> Thanks, >>>>>>> Max > From max.ockner at oracle.com Thu Jun 23 18:05:39 2016 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 23 Jun 2016 14:05:39 -0400 Subject: RFR: 8038332: The trace event vm/class/load is not always being sent In-Reply-To: <642636BA-2185-482E-B022-A57002568FAA@oracle.com> References: <5759AFCE.2080406@oracle.com> <575EF096.9020908@oracle.com> <95d4e379-2680-1e49-f972-831e4e1701ba@oracle.com> <57683F13.5070900@oracle.com> <642636BA-2185-482E-B022-A57002568FAA@oracle.com> Message-ID: <576C24F3.2040301@oracle.com> Jiangli, I have followed the suggestions from Ioi and Coleen to factor out all occurences of HAS_PENDING_EXCEPTION. Thanks, Max On 6/22/2016 1:53 PM, Jiangli Zhou wrote: > Hi Max, > > I see there is already an ?if (!HAS_PENDING_EXCEPTION)? check at line 1170 before the debug_only code. Maybe you cloud place the post_class_load_event() in there so it only post the event when there is no pending exception. That way you don?t need to change the existing logic and add the additional checks. > > Thanks, > Jiangli > >> On Jun 20, 2016, at 12:08 PM, Max Ockner wrote: >> >> David, >> >> New webrev: http://cr.openjdk.java.net/~mockner/8038332.02/src/share/vm/classfile/systemDictionary.cpp.cdiff.html >> I have added the check you suggested before triggering the event: >> >> if (HAS_PENDING_EXCEPTION || k.is_null()) { >> return NULL; >> } >> >> Thanks, >> Max >> >> On 6/13/2016 6:40 PM, David Holmes wrote: >>> Hi Max, >>> >>> On 14/06/2016 3:42 AM, Max Ockner wrote: >>>> Jiangli, >>>> Thanks for looking. I didn't see anything that looked like it might >>>> produce duplicate events. However, I did see some additional places >>>> where it looks like no event is fire. >>>> >>>> Can anyone point me to the event specs? >>> I'm not sure there is any spec for this. Even JFR doesn't seem to document individual events and when they are triggered. >>> >>> Your change does not look right however as you are posting the classload event regardless of the exception state. If you look at SystemDictionary::resolve_instance_class_or_null, it only posts after checking the load was successful: >>> >>> 892 if (HAS_PENDING_EXCEPTION || k.is_null()) { >>> 893 return NULL; >>> 894 } >>> 895 >>> 896 post_class_load_event(class_load_start_time, k, class_loader); >>> >>> Similarly, SystemDictionary::parse_stream, has various CHECK macros that will cause a return on exception, prior to getting to the point of posting the load event. So you also need to add a check for a pending exception and that k is not null, I think, before posting the event. >>> >> I have added this check. >>> BTW I would have expected to see trace-events generated at approximately the same locations as the corresponding JVMTI events. That does not seem to be the case which seems very strange to me. The notion of "loading a class" seems to be spread across far too many functions to me. >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Max >>>> >>>> On 6/9/2016 4:39 PM, Jiangli Zhou wrote: >>>>> Hi Max, >>>>> >>>>> Looks ok. The only possible issue is more than one event might be sent >>>>> in some of the call paths. But my quick search didn?t find any of such >>>>> case. >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>>> On Jun 9, 2016, at 11:05 AM, Max Ockner wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Please review this small fix which causes the vm/class/load event to >>>>>> be fired from JVM_DefineClass() and JVM_DefineClassWithSource(). >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8038332/ >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038332 >>>>>> >>>>>> The vm/class/load event (EventClassLoad) was previously fired in 2 >>>>>> places: >>>>>> >>>>>> SystemDictionary::parse_stream >>>>>> SystemDictionary::resolve_instance_class_or_null >>>>>> >>>>>> parse_stream is the standard option for creating a klass from a >>>>>> stream, but JVM_DefineClass uses a different function: >>>>>> >>>>>> SystemDictionary::resolve_from_stream. >>>>>> >>>>>> This did not fire a vm/class/load event. Now it does fire the event. >>>>>> >>>>>> Sanity tested with jtreg runtime. Issue was reproduced and tested >>>>>> using the reproducer script attached to the bug >>>>>> >>>>>> Thanks, >>>>>> Max From jiangli.zhou at oracle.com Thu Jun 23 18:08:50 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 23 Jun 2016 11:08:50 -0700 Subject: RFR: 8038332: The trace event vm/class/load is not always being sent In-Reply-To: <576C24F3.2040301@oracle.com> References: <5759AFCE.2080406@oracle.com> <575EF096.9020908@oracle.com> <95d4e379-2680-1e49-f972-831e4e1701ba@oracle.com> <57683F13.5070900@oracle.com> <642636BA-2185-482E-B022-A57002568FAA@oracle.com> <576C24F3.2040301@oracle.com> Message-ID: <01204BC2-D366-4BF7-9F12-89283AAA5A89@oracle.com> Thanks, Max. Do you have a new webrev? Thanks, Jiangli > On Jun 23, 2016, at 11:05 AM, Max Ockner wrote: > > Jiangli, > I have followed the suggestions from Ioi and Coleen to factor out all occurences of HAS_PENDING_EXCEPTION. > Thanks, > Max > > On 6/22/2016 1:53 PM, Jiangli Zhou wrote: >> Hi Max, >> >> I see there is already an ?if (!HAS_PENDING_EXCEPTION)? check at line 1170 before the debug_only code. Maybe you cloud place the post_class_load_event() in there so it only post the event when there is no pending exception. That way you don?t need to change the existing logic and add the additional checks. >> >> Thanks, >> Jiangli >> >>> On Jun 20, 2016, at 12:08 PM, Max Ockner wrote: >>> >>> David, >>> >>> New webrev: http://cr.openjdk.java.net/~mockner/8038332.02/src/share/vm/classfile/systemDictionary.cpp.cdiff.html >>> I have added the check you suggested before triggering the event: >>> >>> if (HAS_PENDING_EXCEPTION || k.is_null()) { >>> return NULL; >>> } >>> >>> Thanks, >>> Max >>> >>> On 6/13/2016 6:40 PM, David Holmes wrote: >>>> Hi Max, >>>> >>>> On 14/06/2016 3:42 AM, Max Ockner wrote: >>>>> Jiangli, >>>>> Thanks for looking. I didn't see anything that looked like it might >>>>> produce duplicate events. However, I did see some additional places >>>>> where it looks like no event is fire. >>>>> >>>>> Can anyone point me to the event specs? >>>> I'm not sure there is any spec for this. Even JFR doesn't seem to document individual events and when they are triggered. >>>> >>>> Your change does not look right however as you are posting the classload event regardless of the exception state. If you look at SystemDictionary::resolve_instance_class_or_null, it only posts after checking the load was successful: >>>> >>>> 892 if (HAS_PENDING_EXCEPTION || k.is_null()) { >>>> 893 return NULL; >>>> 894 } >>>> 895 >>>> 896 post_class_load_event(class_load_start_time, k, class_loader); >>>> >>>> Similarly, SystemDictionary::parse_stream, has various CHECK macros that will cause a return on exception, prior to getting to the point of posting the load event. So you also need to add a check for a pending exception and that k is not null, I think, before posting the event. >>>> >>> I have added this check. >>>> BTW I would have expected to see trace-events generated at approximately the same locations as the corresponding JVMTI events. That does not seem to be the case which seems very strange to me. The notion of "loading a class" seems to be spread across far too many functions to me. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> On 6/9/2016 4:39 PM, Jiangli Zhou wrote: >>>>>> Hi Max, >>>>>> >>>>>> Looks ok. The only possible issue is more than one event might be sent >>>>>> in some of the call paths. But my quick search didn?t find any of such >>>>>> case. >>>>>> >>>>>> Thanks, >>>>>> Jiangli >>>>>> >>>>>>> On Jun 9, 2016, at 11:05 AM, Max Ockner wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Please review this small fix which causes the vm/class/load event to >>>>>>> be fired from JVM_DefineClass() and JVM_DefineClassWithSource(). >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8038332/ >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038332 >>>>>>> >>>>>>> The vm/class/load event (EventClassLoad) was previously fired in 2 >>>>>>> places: >>>>>>> >>>>>>> SystemDictionary::parse_stream >>>>>>> SystemDictionary::resolve_instance_class_or_null >>>>>>> >>>>>>> parse_stream is the standard option for creating a klass from a >>>>>>> stream, but JVM_DefineClass uses a different function: >>>>>>> >>>>>>> SystemDictionary::resolve_from_stream. >>>>>>> >>>>>>> This did not fire a vm/class/load event. Now it does fire the event. >>>>>>> >>>>>>> Sanity tested with jtreg runtime. Issue was reproduced and tested >>>>>>> using the reproducer script attached to the bug >>>>>>> >>>>>>> Thanks, >>>>>>> Max > From vladimir.kozlov at oracle.com Thu Jun 23 18:22:56 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Jun 2016 11:22:56 -0700 Subject: RFR: 8048093 - Explicitly setting := vs = in the -XX:+PrintFlagsFinal output In-Reply-To: <1eeb5ef3-06bc-072a-070b-b3732cf5332b@oracle.com> References: <838ed626-566c-963c-9b9b-2fb76e0820cf@oracle.com> <1eeb5ef3-06bc-072a-070b-b3732cf5332b@oracle.com> Message-ID: why you skipped 19?: ORIG_COMMAND_LINE = 1 << 20, Otherwise looks good. Thanks, Vladimir On 6/23/16 8:04 AM, Jesper Wilhelmsson wrote: > Den 22/6/16 kl. 21:33, skrev Coleen Phillimore: > >> >> I agree with Vladimir. There's no way I'm going to remember that a colon mean that the value was changed. > The colon is what we have today to indicate that a value was changed :) > > I made a different solution in which I explicitly print the origin with words. To make it look better I changed the > printing routine somewhat. The origin is currently at the end of the line. > This version will also print other origins like config file, environment, and management as suggested by Dan. > > New webrev: > http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.01/ > > Examples of -XX:+PrintFlagsFinal with and without the change: > > This is the new version: > > ccstr AbortVMOnExceptionMessage = {diagnostic} {default} > uintx AdaptiveSizeDecrementScaleFactor = 4 {product} {default} > intx AliasLevel = 3 {C2 product} {default} > intx CMSAbortablePrecleanWaitMillis = 100 {manageable} {default} > bool CMSClassUnloadingEnabled = false {product} {command line} > intx ConditionalMoveLimit = 3 {C2 pd product} {default} > size_t InitialHeapSize = 134217728 {product} {ergonomic} > size_t MaxMetaspaceSize = 18446744073709547520 {product} {default} > size_t NewSize = 1966080 {product} {command line, > ergonomic} > ccstrlist OnError = {product} {default} > intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = -1 {develop} {default} > bool UseAdaptiveGenerationSizePolicyAtMajorCollection = true {product} {default} > bool UseCISCSpill = true {C2 pd develop} {default} > bool UseCLMUL = true {ARCH product} {default} > bool UseCompressedOops = true {lp64_product} {ergonomic} > bool UseConcMarkSweepGC = true {product} {command line} > > This is the old (current) version: > > ccstr AbortVMOnExceptionMessage = {diagnostic} > uintx AdaptiveSizeDecrementScaleFactor = 4 {product} > intx AliasLevel = 3 {C2 product} > intx CMSAbortablePrecleanWaitMillis = 100 {manageable} > bool CMSClassUnloadingEnabled := false {product} > intx ConditionalMoveLimit = 3 {C2 pd product} > size_t InitialHeapSize := 134217728 {product} > size_t MaxMetaspaceSize = 18446744073709547520 {product} > size_t NewSize := 1966080 {product} > ccstrlist OnError = {product} > intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = -1 {develop} > bool UseAdaptiveGenerationSizePolicyAtMajorCollection = true {product} > bool UseCISCSpill = true {C2 pd develop} > bool UseCompressedOops := true {lp64_product} > bool UseConcMarkSweepGC := true {product} > > /Jesper > >> Coleen >> >> >> On 6/21/16 4:15 PM, Vladimir Kozlov wrote: >>> Nobody will remember the meaning of such marking. You should use normal words. >>> The output already have flag's type as, for example, "{C2 product}". You can add an other word there to indicate type >>> of initialization: default|command|ergo. >>> >>> Thanks, >>> Vladimir >>> >>> On 6/21/16 12:09 PM, Jesper Wilhelmsson wrote: >>>> Hi, >>>> >>>> Please review this change to make -XX:+PrintFlagsFinal distinguish between flags changed on the command line and flags >>>> changed by the ergonomics. >>>> >>>> To enable us to remember if a flag was set on the command line or not after having been changed by the ergonomics I use >>>> another bit in the Flag struct. >>>> >>>> The actual symbols printed by PrintFlagsFinal are chosen somewhat arbitrary and I'm open to suggestions (bike sheding) >>>> about how to visualize this the best. >>>> >>>> The old decorations are: >>>> >>>> ' =' - Default value (no decoration) >>>> ':=' - Value was changed, either by command line or ergonomics or other >>>> >>>> The new decorations are: >>>> >>>> ' =' - Default value (no decoration) >>>> ':=' - Set on the command line >>>> '?=' - Changed by the ergonomics >>>> '!=' - Set on the command line AND changed by the ergonomics >>>> '-=' - Any other origin, like changed by management API or taken from a config file >>>> >>>> My reasoning behind selecting these characters are that ':=' looks like a solid assignment and will therefore represent >>>> the command line. You never know what you get from the ergonomics, so '?=' seems appropriate. '!=' because you'd >>>> want to >>>> know that the ergonomics changed a value you had set on the command line. >>>> >>>> Another option could be to use a colon ':=' for the command line, and a comma ',=' for the ergonomics. That would >>>> naturally give us the semi-colon ';=' for something set on the command line and changed by the ergonomics. I didn't go >>>> with this because the colon and semi-colon can be hard to distinguish from each other. >>>> >>>> As mentioned above there are other origins, the enum contains eight values. There is no mention of the other types in >>>> the bug and there are no is_...() for the other types in globals.cpp, so they didn't seem as important. If the general >>>> opinion is that these other origins are as important, or we might as well..., I'd suggest that we use letters as >>>> decorations. Let me know if you have an opinion. >>>> >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048093 >>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.00/ >>>> >>>> Thanks, >>>> /Jesper >> > From max.ockner at oracle.com Thu Jun 23 18:28:43 2016 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 23 Jun 2016 14:28:43 -0400 Subject: RFR: 8038332: The trace event vm/class/load is not always being sent In-Reply-To: <32997529-3e7c-53b0-bd84-d4519d1b2419@oracle.com> References: <5759AFCE.2080406@oracle.com> <575EF096.9020908@oracle.com> <95d4e379-2680-1e49-f972-831e4e1701ba@oracle.com> <57683F13.5070900@oracle.com> <642636BA-2185-482E-B022-A57002568FAA@oracle.com> <23a73321-9ad4-c49f-ba9d-841b0754e21c@oracle.com> <576AFCFE.3010504@oracle.com> <32997529-3e7c-53b0-bd84-d4519d1b2419@oracle.com> Message-ID: <576C2A5B.3020003@oracle.com> Hello again! New webrev: http://cr.openjdk.java.net/~mockner/8038332.03/ Thanks, Max On 6/22/2016 10:53 PM, Coleen Phillimore wrote: > > > On 6/22/16 5:02 PM, Ioi Lam wrote: >> Instead of using Exceptions::_throw_msg directly, I think it's better >> to use the macro >> >> THROW_MSG_NULL(vmSymbols::java_lang_SecurityException(), message); >> >> It will do the "return NULL" for you, so there's no danger of >> forgetting doing it. > Done. > Agree. > Coleen >> >> Thanks >> - Ioi >> >> On 6/22/16 12:13 PM, Coleen Phillimore wrote: >>> >>> Hi, >>> >>> Can I suggest actually fixing this code? Please? >>> >>> Instead of returning THREAD in all the calls in parse_stream(), they >>> should have CHECK_NULL. Then all the if (!HAS_PENDING_EXCEPTION) >>> conditionals can be removed and the logic fixed. >>> >>> The only reason to have THREAD as the last parameter is if there's >>> cleanup that needs to be done in the case of an exception, which is >>> rare and I verified not the case in this function. >>> >>> After this code put a return NULL; >>> >>> Exceptions::_throw_msg(THREAD_AND_LOCATION, >>> vmSymbols::java_lang_SecurityException(), message); >>> // add return NULL; >>> } >>> >>> Otherwise, the code to add the event looks good. >>> >>> Thanks, >>> Coleen >>> >>> >>> On 6/22/16 1:53 PM, Jiangli Zhou wrote: >>>> Hi Max, >>>> >>>> I see there is already an ?if (!HAS_PENDING_EXCEPTION)? check at >>>> line 1170 before the debug_only code. Maybe you cloud place the >>>> post_class_load_event() in there so it only post the event when >>>> there is no pending exception. That way you don?t need to change >>>> the existing logic and add the additional checks. >>>> >>>> Thanks, >>>> Jiangli >>>> >>>>> On Jun 20, 2016, at 12:08 PM, Max Ockner >>>>> wrote: >>>>> >>>>> David, >>>>> >>>>> New webrev: >>>>> http://cr.openjdk.java.net/~mockner/8038332.02/src/share/vm/classfile/systemDictionary.cpp.cdiff.html >>>>> I have added the check you suggested before triggering the event: >>>>> >>>>> if (HAS_PENDING_EXCEPTION || k.is_null()) { >>>>> return NULL; >>>>> } >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> On 6/13/2016 6:40 PM, David Holmes wrote: >>>>>> Hi Max, >>>>>> >>>>>> On 14/06/2016 3:42 AM, Max Ockner wrote: >>>>>>> Jiangli, >>>>>>> Thanks for looking. I didn't see anything that looked like it >>>>>>> might >>>>>>> produce duplicate events. However, I did see some additional places >>>>>>> where it looks like no event is fire. >>>>>>> >>>>>>> Can anyone point me to the event specs? >>>>>> I'm not sure there is any spec for this. Even JFR doesn't seem to >>>>>> document individual events and when they are triggered. >>>>>> >>>>>> Your change does not look right however as you are posting the >>>>>> classload event regardless of the exception state. If you look at >>>>>> SystemDictionary::resolve_instance_class_or_null, it only posts >>>>>> after checking the load was successful: >>>>>> >>>>>> 892 if (HAS_PENDING_EXCEPTION || k.is_null()) { >>>>>> 893 return NULL; >>>>>> 894 } >>>>>> 895 >>>>>> 896 post_class_load_event(class_load_start_time, k, class_loader); >>>>>> >>>>>> Similarly, SystemDictionary::parse_stream, has various CHECK >>>>>> macros that will cause a return on exception, prior to getting to >>>>>> the point of posting the load event. So you also need to add a >>>>>> check for a pending exception and that k is not null, I think, >>>>>> before posting the event. >>>>>> >>>>> I have added this check. >>>>>> BTW I would have expected to see trace-events generated at >>>>>> approximately the same locations as the corresponding JVMTI >>>>>> events. That does not seem to be the case which seems very >>>>>> strange to me. The notion of "loading a class" seems to be spread >>>>>> across far too many functions to me. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>> >>>>>>> On 6/9/2016 4:39 PM, Jiangli Zhou wrote: >>>>>>>> Hi Max, >>>>>>>> >>>>>>>> Looks ok. The only possible issue is more than one event might >>>>>>>> be sent >>>>>>>> in some of the call paths. But my quick search didn?t find any >>>>>>>> of such >>>>>>>> case. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jiangli >>>>>>>> >>>>>>>>> On Jun 9, 2016, at 11:05 AM, Max Ockner >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Please review this small fix which causes the vm/class/load >>>>>>>>> event to >>>>>>>>> be fired from JVM_DefineClass() and JVM_DefineClassWithSource(). >>>>>>>>> >>>>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8038332/ >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038332 >>>>>>>>> >>>>>>>>> The vm/class/load event (EventClassLoad) was previously fired >>>>>>>>> in 2 >>>>>>>>> places: >>>>>>>>> >>>>>>>>> SystemDictionary::parse_stream >>>>>>>>> SystemDictionary::resolve_instance_class_or_null >>>>>>>>> >>>>>>>>> parse_stream is the standard option for creating a klass from a >>>>>>>>> stream, but JVM_DefineClass uses a different function: >>>>>>>>> >>>>>>>>> SystemDictionary::resolve_from_stream. >>>>>>>>> >>>>>>>>> This did not fire a vm/class/load event. Now it does fire the >>>>>>>>> event. >>>>>>>>> >>>>>>>>> Sanity tested with jtreg runtime. Issue was reproduced and tested >>>>>>>>> using the reproducer script attached to the bug >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Max >>> >> > From jesper.wilhelmsson at oracle.com Thu Jun 23 18:54:39 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 23 Jun 2016 20:54:39 +0200 Subject: RFR: 8048093 - Explicitly setting := vs = in the -XX:+PrintFlagsFinal output In-Reply-To: References: <838ed626-566c-963c-9b9b-2fb76e0820cf@oracle.com> <1eeb5ef3-06bc-072a-070b-b3732cf5332b@oracle.com> Message-ID: Den 23/6/16 kl. 20:22, skrev Vladimir Kozlov: > why you skipped 19?: > > ORIG_COMMAND_LINE = 1 << 20, No good reason really, just leaving some space since ORIG_COMMAND_LINE is not a kind. I can change it to 19 if you think that's better. > > Otherwise looks good. Thanks for reviewing! /Jesper > > Thanks, > Vladimir > > On 6/23/16 8:04 AM, Jesper Wilhelmsson wrote: >> Den 22/6/16 kl. 21:33, skrev Coleen Phillimore: >> >>> >>> I agree with Vladimir. There's no way I'm going to remember that a colon >>> mean that the value was changed. >> The colon is what we have today to indicate that a value was changed :) >> >> I made a different solution in which I explicitly print the origin with words. >> To make it look better I changed the >> printing routine somewhat. The origin is currently at the end of the line. >> This version will also print other origins like config file, environment, and >> management as suggested by Dan. >> >> New webrev: >> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.01/ >> >> Examples of -XX:+PrintFlagsFinal with and without the change: >> >> This is the new version: >> >> ccstr AbortVMOnExceptionMessage = >> {diagnostic} {default} >> uintx AdaptiveSizeDecrementScaleFactor = >> 4 {product} {default} >> intx AliasLevel = >> 3 {C2 product} {default} >> intx CMSAbortablePrecleanWaitMillis = >> 100 {manageable} {default} >> bool CMSClassUnloadingEnabled = >> false {product} {command line} >> intx ConditionalMoveLimit = >> 3 {C2 pd product} {default} >> size_t InitialHeapSize = >> 134217728 {product} {ergonomic} >> size_t MaxMetaspaceSize = >> 18446744073709547520 {product} {default} >> size_t NewSize = >> 1966080 {product} {command line, >> ergonomic} >> ccstrlist OnError = {product} {default} >> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >> -1 {develop} {default} >> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >> true {product} {default} >> bool UseCISCSpill = >> true {C2 pd develop} {default} >> bool UseCLMUL = >> true {ARCH product} {default} >> bool UseCompressedOops = >> true {lp64_product} {ergonomic} >> bool UseConcMarkSweepGC = >> true {product} {command line} >> >> This is the old (current) version: >> >> ccstr AbortVMOnExceptionMessage = >> {diagnostic} >> uintx AdaptiveSizeDecrementScaleFactor = >> 4 {product} >> intx AliasLevel = >> 3 {C2 product} >> intx CMSAbortablePrecleanWaitMillis = >> 100 {manageable} >> bool CMSClassUnloadingEnabled := >> false {product} >> intx ConditionalMoveLimit = >> 3 {C2 pd product} >> size_t InitialHeapSize := >> 134217728 {product} >> size_t MaxMetaspaceSize = >> 18446744073709547520 {product} >> size_t NewSize := >> 1966080 {product} >> ccstrlist OnError = {product} >> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >> -1 {develop} >> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >> true {product} >> bool UseCISCSpill = >> true {C2 pd develop} >> bool UseCompressedOops := >> true {lp64_product} >> bool UseConcMarkSweepGC := >> true {product} >> >> /Jesper >> >>> Coleen >>> >>> >>> On 6/21/16 4:15 PM, Vladimir Kozlov wrote: >>>> Nobody will remember the meaning of such marking. You should use normal words. >>>> The output already have flag's type as, for example, "{C2 product}". You can >>>> add an other word there to indicate type >>>> of initialization: default|command|ergo. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 6/21/16 12:09 PM, Jesper Wilhelmsson wrote: >>>>> Hi, >>>>> >>>>> Please review this change to make -XX:+PrintFlagsFinal distinguish between >>>>> flags changed on the command line and flags >>>>> changed by the ergonomics. >>>>> >>>>> To enable us to remember if a flag was set on the command line or not after >>>>> having been changed by the ergonomics I use >>>>> another bit in the Flag struct. >>>>> >>>>> The actual symbols printed by PrintFlagsFinal are chosen somewhat arbitrary >>>>> and I'm open to suggestions (bike sheding) >>>>> about how to visualize this the best. >>>>> >>>>> The old decorations are: >>>>> >>>>> ' =' - Default value (no decoration) >>>>> ':=' - Value was changed, either by command line or ergonomics or other >>>>> >>>>> The new decorations are: >>>>> >>>>> ' =' - Default value (no decoration) >>>>> ':=' - Set on the command line >>>>> '?=' - Changed by the ergonomics >>>>> '!=' - Set on the command line AND changed by the ergonomics >>>>> '-=' - Any other origin, like changed by management API or taken from a >>>>> config file >>>>> >>>>> My reasoning behind selecting these characters are that ':=' looks like a >>>>> solid assignment and will therefore represent >>>>> the command line. You never know what you get from the ergonomics, so '?=' >>>>> seems appropriate. '!=' because you'd >>>>> want to >>>>> know that the ergonomics changed a value you had set on the command line. >>>>> >>>>> Another option could be to use a colon ':=' for the command line, and a >>>>> comma ',=' for the ergonomics. That would >>>>> naturally give us the semi-colon ';=' for something set on the command line >>>>> and changed by the ergonomics. I didn't go >>>>> with this because the colon and semi-colon can be hard to distinguish from >>>>> each other. >>>>> >>>>> As mentioned above there are other origins, the enum contains eight values. >>>>> There is no mention of the other types in >>>>> the bug and there are no is_...() for the other types in globals.cpp, so >>>>> they didn't seem as important. If the general >>>>> opinion is that these other origins are as important, or we might as >>>>> well..., I'd suggest that we use letters as >>>>> decorations. Let me know if you have an opinion. >>>>> >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048093 >>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.00/ >>>>> >>>>> Thanks, >>>>> /Jesper >>> >> From coleen.phillimore at oracle.com Thu Jun 23 19:32:41 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 23 Jun 2016 15:32:41 -0400 Subject: RFR: 8038332: The trace event vm/class/load is not always being sent In-Reply-To: <576C2A5B.3020003@oracle.com> References: <5759AFCE.2080406@oracle.com> <575EF096.9020908@oracle.com> <95d4e379-2680-1e49-f972-831e4e1701ba@oracle.com> <57683F13.5070900@oracle.com> <642636BA-2185-482E-B022-A57002568FAA@oracle.com> <23a73321-9ad4-c49f-ba9d-841b0754e21c@oracle.com> <576AFCFE.3010504@oracle.com> <32997529-3e7c-53b0-bd84-d4519d1b2419@oracle.com> <576C2A5B.3020003@oracle.com> Message-ID: <3e2b9015-af5b-dace-395f-026fe89b6645@oracle.com> This looks so much better. Thanks! Coleen On 6/23/16 2:28 PM, Max Ockner wrote: > Hello again! > > New webrev: http://cr.openjdk.java.net/~mockner/8038332.03/ > > Thanks, > Max > > > On 6/22/2016 10:53 PM, Coleen Phillimore wrote: >> >> >> On 6/22/16 5:02 PM, Ioi Lam wrote: >>> Instead of using Exceptions::_throw_msg directly, I think it's >>> better to use the macro >>> >>> THROW_MSG_NULL(vmSymbols::java_lang_SecurityException(), message); >>> >>> It will do the "return NULL" for you, so there's no danger of >>> forgetting doing it. >> > Done. > >> Agree. >> Coleen >>> >>> Thanks >>> - Ioi >>> >>> On 6/22/16 12:13 PM, Coleen Phillimore wrote: >>>> >>>> Hi, >>>> >>>> Can I suggest actually fixing this code? Please? >>>> >>>> Instead of returning THREAD in all the calls in parse_stream(), >>>> they should have CHECK_NULL. Then all the if >>>> (!HAS_PENDING_EXCEPTION) conditionals can be removed and the logic >>>> fixed. >>>> >>>> The only reason to have THREAD as the last parameter is if there's >>>> cleanup that needs to be done in the case of an exception, which is >>>> rare and I verified not the case in this function. >>>> >>>> After this code put a return NULL; >>>> >>>> Exceptions::_throw_msg(THREAD_AND_LOCATION, >>>> vmSymbols::java_lang_SecurityException(), message); >>>> // add return NULL; >>>> } >>>> >>>> Otherwise, the code to add the event looks good. >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>>> On 6/22/16 1:53 PM, Jiangli Zhou wrote: >>>>> Hi Max, >>>>> >>>>> I see there is already an ?if (!HAS_PENDING_EXCEPTION)? check at >>>>> line 1170 before the debug_only code. Maybe you cloud place the >>>>> post_class_load_event() in there so it only post the event when >>>>> there is no pending exception. That way you don?t need to change >>>>> the existing logic and add the additional checks. >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>>> On Jun 20, 2016, at 12:08 PM, Max Ockner >>>>>> wrote: >>>>>> >>>>>> David, >>>>>> >>>>>> New webrev: >>>>>> http://cr.openjdk.java.net/~mockner/8038332.02/src/share/vm/classfile/systemDictionary.cpp.cdiff.html >>>>>> I have added the check you suggested before triggering the event: >>>>>> >>>>>> if (HAS_PENDING_EXCEPTION || k.is_null()) { >>>>>> return NULL; >>>>>> } >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> On 6/13/2016 6:40 PM, David Holmes wrote: >>>>>>> Hi Max, >>>>>>> >>>>>>> On 14/06/2016 3:42 AM, Max Ockner wrote: >>>>>>>> Jiangli, >>>>>>>> Thanks for looking. I didn't see anything that looked like it >>>>>>>> might >>>>>>>> produce duplicate events. However, I did see some additional >>>>>>>> places >>>>>>>> where it looks like no event is fire. >>>>>>>> >>>>>>>> Can anyone point me to the event specs? >>>>>>> I'm not sure there is any spec for this. Even JFR doesn't seem >>>>>>> to document individual events and when they are triggered. >>>>>>> >>>>>>> Your change does not look right however as you are posting the >>>>>>> classload event regardless of the exception state. If you look >>>>>>> at SystemDictionary::resolve_instance_class_or_null, it only >>>>>>> posts after checking the load was successful: >>>>>>> >>>>>>> 892 if (HAS_PENDING_EXCEPTION || k.is_null()) { >>>>>>> 893 return NULL; >>>>>>> 894 } >>>>>>> 895 >>>>>>> 896 post_class_load_event(class_load_start_time, k, >>>>>>> class_loader); >>>>>>> >>>>>>> Similarly, SystemDictionary::parse_stream, has various CHECK >>>>>>> macros that will cause a return on exception, prior to getting >>>>>>> to the point of posting the load event. So you also need to add >>>>>>> a check for a pending exception and that k is not null, I think, >>>>>>> before posting the event. >>>>>>> >>>>>> I have added this check. >>>>>>> BTW I would have expected to see trace-events generated at >>>>>>> approximately the same locations as the corresponding JVMTI >>>>>>> events. That does not seem to be the case which seems very >>>>>>> strange to me. The notion of "loading a class" seems to be >>>>>>> spread across far too many functions to me. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>>>>> >>>>>>>> On 6/9/2016 4:39 PM, Jiangli Zhou wrote: >>>>>>>>> Hi Max, >>>>>>>>> >>>>>>>>> Looks ok. The only possible issue is more than one event might >>>>>>>>> be sent >>>>>>>>> in some of the call paths. But my quick search didn?t find any >>>>>>>>> of such >>>>>>>>> case. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Jiangli >>>>>>>>> >>>>>>>>>> On Jun 9, 2016, at 11:05 AM, Max Ockner >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Please review this small fix which causes the vm/class/load >>>>>>>>>> event to >>>>>>>>>> be fired from JVM_DefineClass() and JVM_DefineClassWithSource(). >>>>>>>>>> >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8038332/ >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038332 >>>>>>>>>> >>>>>>>>>> The vm/class/load event (EventClassLoad) was previously >>>>>>>>>> fired in 2 >>>>>>>>>> places: >>>>>>>>>> >>>>>>>>>> SystemDictionary::parse_stream >>>>>>>>>> SystemDictionary::resolve_instance_class_or_null >>>>>>>>>> >>>>>>>>>> parse_stream is the standard option for creating a klass from a >>>>>>>>>> stream, but JVM_DefineClass uses a different function: >>>>>>>>>> >>>>>>>>>> SystemDictionary::resolve_from_stream. >>>>>>>>>> >>>>>>>>>> This did not fire a vm/class/load event. Now it does fire the >>>>>>>>>> event. >>>>>>>>>> >>>>>>>>>> Sanity tested with jtreg runtime. Issue was reproduced and >>>>>>>>>> tested >>>>>>>>>> using the reproducer script attached to the bug >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Max >>>> >>> >> > From max.ockner at oracle.com Thu Jun 23 19:34:20 2016 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 23 Jun 2016 15:34:20 -0400 Subject: [PATCH resend2] 8157758: Use (~0u) instead of (-1) when left-shifting In-Reply-To: References: <740DB36B-CB51-46E9-A456-A546FD3F3836@oracle.com> <855E9FFA-4BD7-4329-806E-A1BFE5665AD2@oracle.com> <6A986EED-1557-4483-AB94-A89AFDBFD130@oracle.com> Message-ID: <576C39BC.8040905@oracle.com> Alex, This change looks good to me. Thanks, Max On 6/22/2016 5:12 PM, Alex Henrie wrote: > 2016-06-22 14:56 GMT-06:00 Kim Barrett : >>> On Jun 22, 2016, at 3:15 PM, Alex Henrie wrote: >>> >>> 2016-06-15 12:48 GMT-06:00 Kim Barrett : >>>> So I've changed my mind about this patch. Looks good. >>> If you approve of the patch, would you please commit it? >>> >>> -Alex >> Hotspot changes generally require at least two reviewers, and at least one must be a ?Reviewer?. >> I only see one so far (me, also a Reviewer). I?ll poke a couple people about being a second. >> >> The change process is described here: http://openjdk.java.net/guide/changePlanning.html >> The requirement for a second reviewer is a Hotspot extension to that process. >> Are you covered by an Oracle Contributor Agreement, either individually or through an employer? >> >> I can sponsor it once there?s a second review. > Yes, I have signed the OCA. Is there anything that I can do to help > find a second reviewer? > > -Alex From jiangli.zhou at oracle.com Thu Jun 23 20:48:27 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 23 Jun 2016 13:48:27 -0700 Subject: RFR: 8038332: The trace event vm/class/load is not always being sent In-Reply-To: <3e2b9015-af5b-dace-395f-026fe89b6645@oracle.com> References: <5759AFCE.2080406@oracle.com> <575EF096.9020908@oracle.com> <95d4e379-2680-1e49-f972-831e4e1701ba@oracle.com> <57683F13.5070900@oracle.com> <642636BA-2185-482E-B022-A57002568FAA@oracle.com> <23a73321-9ad4-c49f-ba9d-841b0754e21c@oracle.com> <576AFCFE.3010504@oracle.com> <32997529-3e7c-53b0-bd84-d4519d1b2419@oracle.com> <576C2A5B.3020003@oracle.com> <3e2b9015-af5b-dace-395f-026fe89b6645@oracle.com> Message-ID: <43E00971-56BA-40F2-96D4-3D87EC1B7FC0@oracle.com> +1 Thanks, Jiangli > On Jun 23, 2016, at 12:32 PM, Coleen Phillimore wrote: > > > This looks so much better. > Thanks! > Coleen > > On 6/23/16 2:28 PM, Max Ockner wrote: >> Hello again! >> >> New webrev: http://cr.openjdk.java.net/~mockner/8038332.03/ >> >> Thanks, >> Max >> >> >> On 6/22/2016 10:53 PM, Coleen Phillimore wrote: >>> >>> >>> On 6/22/16 5:02 PM, Ioi Lam wrote: >>>> Instead of using Exceptions::_throw_msg directly, I think it's better to use the macro >>>> >>>> THROW_MSG_NULL(vmSymbols::java_lang_SecurityException(), message); >>>> >>>> It will do the "return NULL" for you, so there's no danger of forgetting doing it. >>> >> Done. >> >>> Agree. >>> Coleen >>>> >>>> Thanks >>>> - Ioi >>>> >>>> On 6/22/16 12:13 PM, Coleen Phillimore wrote: >>>>> >>>>> Hi, >>>>> >>>>> Can I suggest actually fixing this code? Please? >>>>> >>>>> Instead of returning THREAD in all the calls in parse_stream(), they should have CHECK_NULL. Then all the if (!HAS_PENDING_EXCEPTION) conditionals can be removed and the logic fixed. >>>>> >>>>> The only reason to have THREAD as the last parameter is if there's cleanup that needs to be done in the case of an exception, which is rare and I verified not the case in this function. >>>>> >>>>> After this code put a return NULL; >>>>> >>>>> Exceptions::_throw_msg(THREAD_AND_LOCATION, >>>>> vmSymbols::java_lang_SecurityException(), message); >>>>> // add return NULL; >>>>> } >>>>> >>>>> Otherwise, the code to add the event looks good. >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>>>> On 6/22/16 1:53 PM, Jiangli Zhou wrote: >>>>>> Hi Max, >>>>>> >>>>>> I see there is already an ?if (!HAS_PENDING_EXCEPTION)? check at line 1170 before the debug_only code. Maybe you cloud place the post_class_load_event() in there so it only post the event when there is no pending exception. That way you don?t need to change the existing logic and add the additional checks. >>>>>> >>>>>> Thanks, >>>>>> Jiangli >>>>>> >>>>>>> On Jun 20, 2016, at 12:08 PM, Max Ockner wrote: >>>>>>> >>>>>>> David, >>>>>>> >>>>>>> New webrev: http://cr.openjdk.java.net/~mockner/8038332.02/src/share/vm/classfile/systemDictionary.cpp.cdiff.html >>>>>>> I have added the check you suggested before triggering the event: >>>>>>> >>>>>>> if (HAS_PENDING_EXCEPTION || k.is_null()) { >>>>>>> return NULL; >>>>>>> } >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>> >>>>>>> On 6/13/2016 6:40 PM, David Holmes wrote: >>>>>>>> Hi Max, >>>>>>>> >>>>>>>> On 14/06/2016 3:42 AM, Max Ockner wrote: >>>>>>>>> Jiangli, >>>>>>>>> Thanks for looking. I didn't see anything that looked like it might >>>>>>>>> produce duplicate events. However, I did see some additional places >>>>>>>>> where it looks like no event is fire. >>>>>>>>> >>>>>>>>> Can anyone point me to the event specs? >>>>>>>> I'm not sure there is any spec for this. Even JFR doesn't seem to document individual events and when they are triggered. >>>>>>>> >>>>>>>> Your change does not look right however as you are posting the classload event regardless of the exception state. If you look at SystemDictionary::resolve_instance_class_or_null, it only posts after checking the load was successful: >>>>>>>> >>>>>>>> 892 if (HAS_PENDING_EXCEPTION || k.is_null()) { >>>>>>>> 893 return NULL; >>>>>>>> 894 } >>>>>>>> 895 >>>>>>>> 896 post_class_load_event(class_load_start_time, k, class_loader); >>>>>>>> >>>>>>>> Similarly, SystemDictionary::parse_stream, has various CHECK macros that will cause a return on exception, prior to getting to the point of posting the load event. So you also need to add a check for a pending exception and that k is not null, I think, before posting the event. >>>>>>>> >>>>>>> I have added this check. >>>>>>>> BTW I would have expected to see trace-events generated at approximately the same locations as the corresponding JVMTI events. That does not seem to be the case which seems very strange to me. The notion of "loading a class" seems to be spread across far too many functions to me. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Max >>>>>>>>> >>>>>>>>> On 6/9/2016 4:39 PM, Jiangli Zhou wrote: >>>>>>>>>> Hi Max, >>>>>>>>>> >>>>>>>>>> Looks ok. The only possible issue is more than one event might be sent >>>>>>>>>> in some of the call paths. But my quick search didn?t find any of such >>>>>>>>>> case. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Jiangli >>>>>>>>>> >>>>>>>>>>> On Jun 9, 2016, at 11:05 AM, Max Ockner wrote: >>>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Please review this small fix which causes the vm/class/load event to >>>>>>>>>>> be fired from JVM_DefineClass() and JVM_DefineClassWithSource(). >>>>>>>>>>> >>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8038332/ >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038332 >>>>>>>>>>> >>>>>>>>>>> The vm/class/load event (EventClassLoad) was previously fired in 2 >>>>>>>>>>> places: >>>>>>>>>>> >>>>>>>>>>> SystemDictionary::parse_stream >>>>>>>>>>> SystemDictionary::resolve_instance_class_or_null >>>>>>>>>>> >>>>>>>>>>> parse_stream is the standard option for creating a klass from a >>>>>>>>>>> stream, but JVM_DefineClass uses a different function: >>>>>>>>>>> >>>>>>>>>>> SystemDictionary::resolve_from_stream. >>>>>>>>>>> >>>>>>>>>>> This did not fire a vm/class/load event. Now it does fire the event. >>>>>>>>>>> >>>>>>>>>>> Sanity tested with jtreg runtime. Issue was reproduced and tested >>>>>>>>>>> using the reproducer script attached to the bug >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Max >>>>> >>>> >>> >> > From david.holmes at oracle.com Thu Jun 23 21:02:09 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Jun 2016 07:02:09 +1000 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <576BE9CB.5080109@oracle.com> References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <84b40e40-347d-bb53-7662-9745f894eaa8@oracle.com> <576AC4EC.6070406@oracle.com> <6bdb6f82-517d-e686-4034-dc8f5ae6e9bd@oracle.com> <6e921b20-2fa7-b60d-c310-857180f358dd@oracle.com> <16738fb0-7a98-5a3a-979e-dd162a19541f@oracle.com> <576BE9CB.5080109@oracle.com> Message-ID: <334bf1c4-8628-b350-a3d2-5ebf717d0538@oracle.com> On 23/06/2016 11:53 PM, Lois Foltan wrote: > > On 6/23/2016 7:37 AM, David Holmes wrote: >> On 23/06/2016 9:25 PM, Alan Bateman wrote: >>> >>> >>> On 23/06/2016 12:05, David Holmes wrote: >>>> >>>> You said: >>>> >>>> "Module system initialization will initialize the built-in class >>>> loaders, including the application class loader. The platform or >>>> application class loaders won't load any classes in this phase of >>>> course but they will be initialized (with the modules that they might >>>> later load classes from). " >>>> >>>> What does that last part mean: "with the modules they might later load >>>> classes from"? How have modules become bound to a classloader that may >>>> not even get instantiated? If that class loader is never instantiated >>>> then why do we need a runtime test that checks for the type of the >>>> actual system class loader? >>> The graph of modules that are defined to the runtime during startup are >>> we call the "boot layer". They are statically mapped to the built-in >>> class loaders where built-in means the boot, platform or application >>> class loaders. There may be a custom system class loader that comes into >>> existence later during the startup but it's just not interesting to the >>> discussion here (except to know that it might be different to the >>> application class loader in some niche configuration). >> >> But you skipped the key part - why do we care about the built-in >> loaders. In this code: >> >> +// If the module's loader, that a read edge is being established to, is >> +// not the same loader as this module's and is not one of the 3 builtin >> +// class loaders, then this module's reads list must be walked at GC >> +// safepoint. Modules have the same life cycle as their defining class >> +// loaders and should be removed if dead. >> +void ModuleEntry::set_read_walk_required(ClassLoaderData* >> m_loader_data) { >> + assert_locked_or_safepoint(Module_lock); >> + if (!_must_walk_reads && >> + loader_data() != m_loader_data && >> + !m_loader_data->is_builtin_class_loader_data()) { >> + _must_walk_reads = true; >> + if (log_is_enabled(Trace, modules)) { >> + ResourceMark rm; >> + log_trace(modules)("ModuleEntry::set_read_walk_required(): >> module %s reads list must be walked", >> + (name() != NULL) ? name()->as_C_string() : >> UNNAMED_MODULE); >> + } >> + } >> +} >> >> what is "is_builtin_class_loader_data" really asking? Is it just that >> this is a loader whose lifetime is matched to that of the VM? If so >> then it is asking the wrong question with respect to the system >> loader. If not, then what is it about the built-in system loader type >> that makes it different to some custom system loader? > > Hi David, > > The 3 built-in loaders will never be GC'ed, neither will a custom system > classloader if there is one configured. Thus the JVM can make reliable > assumptions based on modules defined to those 3 loaders. So if for > example, a module's reads list only has established read edges to > modules that are defined to any of the 3 built-in loaders, the JVM can > rely on the fact that these loaders will never die and thus their > modules will never die. So at a GC safepoint, that module's reads list > will not have to be walked looking for dead modules that should be removed. My apologies to Alan and you as I didn't read this code you updated properly +bool SystemDictionary::is_system_class_loader(Handle class_loader) { + if (class_loader.is_null()) { + return false; + } + return (class_loader->klass() == SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass() || + class_loader() == _java_system_loader); +} Though I'm still unclear why it needs to have this form rather than just a check for: class_loader() == _java_system_loader Even if _java_system_loader may not be initialized if this is called very early during the init phase (seems unlikely but possible), then all that will happen is we do an unnecessary walk of the reads list. That seems better than having to do the klass check each time this is called. Thanks, David > Lois > >> >> Thanks, >> David >> >> (PS. Really calling it a night now :) ) >> >>> -Alan > From david.holmes at oracle.com Thu Jun 23 21:37:56 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Jun 2016 07:37:56 +1000 Subject: RFR: 8038332: The trace event vm/class/load is not always being sent In-Reply-To: <3e2b9015-af5b-dace-395f-026fe89b6645@oracle.com> References: <5759AFCE.2080406@oracle.com> <575EF096.9020908@oracle.com> <95d4e379-2680-1e49-f972-831e4e1701ba@oracle.com> <57683F13.5070900@oracle.com> <642636BA-2185-482E-B022-A57002568FAA@oracle.com> <23a73321-9ad4-c49f-ba9d-841b0754e21c@oracle.com> <576AFCFE.3010504@oracle.com> <32997529-3e7c-53b0-bd84-d4519d1b2419@oracle.com> <576C2A5B.3020003@oracle.com> <3e2b9015-af5b-dace-395f-026fe89b6645@oracle.com> Message-ID: <4ba09865-4af1-201d-c5b0-56a5d822fa56@oracle.com> Agreed! Good to use consistent code style in these related functions. Thanks, David On 24/06/2016 5:32 AM, Coleen Phillimore wrote: > > This looks so much better. > Thanks! > Coleen > > On 6/23/16 2:28 PM, Max Ockner wrote: >> Hello again! >> >> New webrev: http://cr.openjdk.java.net/~mockner/8038332.03/ >> >> Thanks, >> Max >> >> >> On 6/22/2016 10:53 PM, Coleen Phillimore wrote: >>> >>> >>> On 6/22/16 5:02 PM, Ioi Lam wrote: >>>> Instead of using Exceptions::_throw_msg directly, I think it's >>>> better to use the macro >>>> >>>> THROW_MSG_NULL(vmSymbols::java_lang_SecurityException(), message); >>>> >>>> It will do the "return NULL" for you, so there's no danger of >>>> forgetting doing it. >>> >> Done. >> >>> Agree. >>> Coleen >>>> >>>> Thanks >>>> - Ioi >>>> >>>> On 6/22/16 12:13 PM, Coleen Phillimore wrote: >>>>> >>>>> Hi, >>>>> >>>>> Can I suggest actually fixing this code? Please? >>>>> >>>>> Instead of returning THREAD in all the calls in parse_stream(), >>>>> they should have CHECK_NULL. Then all the if >>>>> (!HAS_PENDING_EXCEPTION) conditionals can be removed and the logic >>>>> fixed. >>>>> >>>>> The only reason to have THREAD as the last parameter is if there's >>>>> cleanup that needs to be done in the case of an exception, which is >>>>> rare and I verified not the case in this function. >>>>> >>>>> After this code put a return NULL; >>>>> >>>>> Exceptions::_throw_msg(THREAD_AND_LOCATION, >>>>> vmSymbols::java_lang_SecurityException(), message); >>>>> // add return NULL; >>>>> } >>>>> >>>>> Otherwise, the code to add the event looks good. >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>>>> On 6/22/16 1:53 PM, Jiangli Zhou wrote: >>>>>> Hi Max, >>>>>> >>>>>> I see there is already an ?if (!HAS_PENDING_EXCEPTION)? check at >>>>>> line 1170 before the debug_only code. Maybe you cloud place the >>>>>> post_class_load_event() in there so it only post the event when >>>>>> there is no pending exception. That way you don?t need to change >>>>>> the existing logic and add the additional checks. >>>>>> >>>>>> Thanks, >>>>>> Jiangli >>>>>> >>>>>>> On Jun 20, 2016, at 12:08 PM, Max Ockner >>>>>>> wrote: >>>>>>> >>>>>>> David, >>>>>>> >>>>>>> New webrev: >>>>>>> http://cr.openjdk.java.net/~mockner/8038332.02/src/share/vm/classfile/systemDictionary.cpp.cdiff.html >>>>>>> >>>>>>> I have added the check you suggested before triggering the event: >>>>>>> >>>>>>> if (HAS_PENDING_EXCEPTION || k.is_null()) { >>>>>>> return NULL; >>>>>>> } >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>> >>>>>>> On 6/13/2016 6:40 PM, David Holmes wrote: >>>>>>>> Hi Max, >>>>>>>> >>>>>>>> On 14/06/2016 3:42 AM, Max Ockner wrote: >>>>>>>>> Jiangli, >>>>>>>>> Thanks for looking. I didn't see anything that looked like it >>>>>>>>> might >>>>>>>>> produce duplicate events. However, I did see some additional >>>>>>>>> places >>>>>>>>> where it looks like no event is fire. >>>>>>>>> >>>>>>>>> Can anyone point me to the event specs? >>>>>>>> I'm not sure there is any spec for this. Even JFR doesn't seem >>>>>>>> to document individual events and when they are triggered. >>>>>>>> >>>>>>>> Your change does not look right however as you are posting the >>>>>>>> classload event regardless of the exception state. If you look >>>>>>>> at SystemDictionary::resolve_instance_class_or_null, it only >>>>>>>> posts after checking the load was successful: >>>>>>>> >>>>>>>> 892 if (HAS_PENDING_EXCEPTION || k.is_null()) { >>>>>>>> 893 return NULL; >>>>>>>> 894 } >>>>>>>> 895 >>>>>>>> 896 post_class_load_event(class_load_start_time, k, >>>>>>>> class_loader); >>>>>>>> >>>>>>>> Similarly, SystemDictionary::parse_stream, has various CHECK >>>>>>>> macros that will cause a return on exception, prior to getting >>>>>>>> to the point of posting the load event. So you also need to add >>>>>>>> a check for a pending exception and that k is not null, I think, >>>>>>>> before posting the event. >>>>>>>> >>>>>>> I have added this check. >>>>>>>> BTW I would have expected to see trace-events generated at >>>>>>>> approximately the same locations as the corresponding JVMTI >>>>>>>> events. That does not seem to be the case which seems very >>>>>>>> strange to me. The notion of "loading a class" seems to be >>>>>>>> spread across far too many functions to me. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Max >>>>>>>>> >>>>>>>>> On 6/9/2016 4:39 PM, Jiangli Zhou wrote: >>>>>>>>>> Hi Max, >>>>>>>>>> >>>>>>>>>> Looks ok. The only possible issue is more than one event might >>>>>>>>>> be sent >>>>>>>>>> in some of the call paths. But my quick search didn?t find any >>>>>>>>>> of such >>>>>>>>>> case. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Jiangli >>>>>>>>>> >>>>>>>>>>> On Jun 9, 2016, at 11:05 AM, Max Ockner >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Please review this small fix which causes the vm/class/load >>>>>>>>>>> event to >>>>>>>>>>> be fired from JVM_DefineClass() and JVM_DefineClassWithSource(). >>>>>>>>>>> >>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8038332/ >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038332 >>>>>>>>>>> >>>>>>>>>>> The vm/class/load event (EventClassLoad) was previously >>>>>>>>>>> fired in 2 >>>>>>>>>>> places: >>>>>>>>>>> >>>>>>>>>>> SystemDictionary::parse_stream >>>>>>>>>>> SystemDictionary::resolve_instance_class_or_null >>>>>>>>>>> >>>>>>>>>>> parse_stream is the standard option for creating a klass from a >>>>>>>>>>> stream, but JVM_DefineClass uses a different function: >>>>>>>>>>> >>>>>>>>>>> SystemDictionary::resolve_from_stream. >>>>>>>>>>> >>>>>>>>>>> This did not fire a vm/class/load event. Now it does fire the >>>>>>>>>>> event. >>>>>>>>>>> >>>>>>>>>>> Sanity tested with jtreg runtime. Issue was reproduced and >>>>>>>>>>> tested >>>>>>>>>>> using the reproducer script attached to the bug >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Max >>>>> >>>> >>> >> > From david.holmes at oracle.com Thu Jun 23 22:14:45 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Jun 2016 08:14:45 +1000 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <576B97FD.1080303@oracle.com> <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> <576BC331.8000400@oracle.com> <32634325-b80f-81fe-674e-74ba5daa41fb@oracle.com> <576BC91D.9050204@oracle.com> <95819fd5-e582-3474-a138-7dd3d8761f5e@oracle.com> Message-ID: <2c0bd870-25a7-7fca-36bc-6386a12902d9@oracle.com> On 23/06/2016 11:02 PM, stanislav lukyanov wrote: > There were different points in the discussion I didn't have a chance to > comment in time, > so I'll just summarize everything here not to break the thread flow with > answers to older messages. > > First of all, I'm perfectly fine with either approach (adding name > validation or not) > as long as the behavior is clearly documented. > > I think it should be specified that unnamed module will be returned even > if there cannot ever be a package > with that name. It is not a complicated case to specify, but it brings > much more clarity. > Formally, now the function is specified to work with "package names" and > the behavior on a string that is clearly not a "package name" is > unspecified. I think it is completely specified. Something that can not be a valid package name can obviously not have a module associated with it and so the unnamed-module is always returned. > The empty string case may or may not be specified. It may be considered > another corner case, different from both > "legal" and "illegal" package names, but I personally think that the > behavior is clear anyway. > > I don't think the argument that JVMTI doesn't validate names is correct. > GetLocalVariableTable doesn't look like a good example here, since > it just reads data that's already in the VM anyway, > but in case of GetModuleByPackageName it is about validation of input > parameters. > Other APIs that take identifiers like, for example, JNI FindClass or > GetMethodID > don't specify name checks explicitly, but throw > ClassNotFoundError/NoSuchMethodError illegal names. > It looks like GetModuleByPackageName is the first JNI/JVMTI function to > succeed when an ill-formed identifier is passed, > so it deserves to be documented. I disagree with all of that. GetLocalVariableTable, ClassFileLoadHook, DynamicCodeGenerated, GetThreadInfo, to name a few, all take "names" encoded as UTF-8 modified strings. None of them validate that the "name" is legal for the entity being named - JVM TI simply does not do that kind of argument validation. The JNI functions also do not do argument validation. The JNI spec is clear "The JNI does not check for programming errors such as passing in NULL pointers or illegal argument types". It is up to the programmer to ensure they pass valid arguments. FindClass is specified to simply throw: NoClassDefFoundError: if no definition for a requested class or interface can be found. It is the internal VM code, that has to deal with bytecode from arbitrary sources, that performs the more detailed checking of the name. GetModuleByPackageName is slightly unusual in that it really never fails. As I discussed in the CCC review it could have made a distinction between packages that would be loaded by the loader and packages that would not, and throw an exception (which in turn may have been able to discern that the name was invalid). But that is not the case - if you don't pass the name of a package that is known to the loader then you get back the unnamed-module. It doesn't matter whether the package name is legal-but-unknown, or illegal - it is just unknown. David ------ > On CCC update: AFAIU CCC needs to have final version of the proposed > specification, so yes, > it needs to be updated to with the test that will be actually pushed to > the workspace. > > Thanks, > Stas > > On 23.06.2016 14:40, David Holmes wrote: >> >> >> On 23/06/2016 9:33 PM, serguei.spitsyn at oracle.com wrote: >>> On 6/23/16 04:27, David Holmes wrote: >>>> On 23/06/2016 9:08 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 6/23/16 03:51, David Holmes wrote: >>>>>> On 23/06/2016 6:04 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> On 6/23/16 00:51, Alan Bateman wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >>>>>>>>> : >>>>>>>>> >>>>>>>>> I agree with it. >>>>>>>>> Thank you for pointing to this JVMTI example. >>>>>>>>> I did not find in the JNI where the names are checked to be legal. >>>>>>>>> We are going to open a can of worms with this kind of check as >>>>>>>>> there >>>>>>>>> can be many corner cases to cover. >>>>>>>> The primary use-case for this function is from within the CLFH >>>>>>>> callback so have it return the unnamed module when calling with >>>>>>>> garage >>>>>>>> is probably okay, it just needs to be specified. >>>>>>>> >>>>>>>> Will you update the webrev to reflect where we've got to this in >>>>>>>> this >>>>>>>> discussion? >>>>>>> >>>>>>> I need to undo my fix for additional check. >>>>>>> My up-to-date understanding is that we have to explicitly specify >>>>>>> two >>>>>>> points: >>>>>>> - the function returns the unnamed module if the package does not >>>>>>> exist >>>>>>> - the function does not check the package names for validness and >>>>>>> always returns the unnamed module for illegal package names >>>>>>> >>>>>>> It is better to specify these points explicitly to avoid possible >>>>>>> confusion. >>>>>> >>>>>> I don't agree - nothing else refers to invalid "names" in JVM TI. I >>>>>> don't see any need to call this out here. If the name supplied is not >>>>>> a legal package name then it will not match - end of story. >>>>> >>>>> David, >>>>> >>>>> It was the original approach that is in the CCC. >>>>> You were the one who got confused here, and it convinced me that this >>>>> needs to be more clear. >>>>> All these changes are because you started the discussion. :) >>>>> It was useful anyway. >>>> >>>> I never said anything about illegal package names. >>> >>> True. >>> This is my (probably, wrong) attempt to make it more clear. >>> >>>> >>>>> Are you against both clarifications or just the last one? >>>>> I'm Ok to return it back as it is in the CCC. >>>>> It will save time on the CCC approval. >>>>> >>>>> This is the last addition to the spec: >>>>> >>>>> + The unnamed module is returned if the specified package does not >>>>> exist. >>>> >>>> The notion of "package does not exist" is ill-defined. This case is >>>> already covered by the primary specification. >>>> >>>>> + The function does not check if the specified package name is >>>>> illegal. >>>> >>>> This does not need to be stated as it is not stated anywhere else for >>>> anything else that may have legal and illegal forms. >>> >>> Good. >>> This is a relevant fragment from current version of CCC: >>> >>> + >>> + Return the java.lang.reflect.Module object for a >>> module >>> + defined to a class loader that contains a given package. >>> + The module is returned via module_ptr. >>> +

>>> + If a named module is defined to the class loader and it >>> + contains the package then that named module is returned, >>> + otherwise the unnamed module of the class loader is returned. >>> + If the package name is the empty string then this function >>> + always returns the unnamed module for the class loader. >>> +

>> >> As Stanislav said explicitly mentioning the empty string is not really >> necessary - but I don't see it as harmful. >> >>> Does it looks Ok? >> >> Yes - as good now as it was in the CCC discussion :) >> >> Cheers, >> David >> >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> -Alan >>>>>>> >>>>> >>> > From serguei.spitsyn at oracle.com Thu Jun 23 23:07:54 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Jun 2016 16:07:54 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <2c0bd870-25a7-7fca-36bc-6386a12902d9@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <576B97FD.1080303@oracle.com> <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> <576BC331.8000400@oracle.com> <32634325-b80f-81fe-674e-74ba5daa41fb@oracle.com> <576BC91D.9050204@oracle.com> <95819fd5-e582-3474-a138-7dd3d8761f5e@oracle.com> <2c0bd870-25a7-7fca-36bc-6386a12902d9@oracle.com> Message-ID: <576C6BCA.6090100@oracle.com> On 6/23/16 15:14, David Holmes wrote: > On 23/06/2016 11:02 PM, stanislav lukyanov wrote: >> There were different points in the discussion I didn't have a chance to >> comment in time, >> so I'll just summarize everything here not to break the thread flow with >> answers to older messages. Thank you for taking these steps. It is very helpful. >> >> First of all, I'm perfectly fine with either approach (adding name >> validation or not) >> as long as the behavior is clearly documented. Good. >> >> I think it should be specified that unnamed module will be returned even >> if there cannot ever be a package >> with that name. It is not a complicated case to specify, but it brings >> much more clarity. >> Formally, now the function is specified to work with "package names" and >> the behavior on a string that is clearly not a "package name" is >> unspecified. > > I think it is completely specified. Something that can not be a valid > package name can obviously not have a module associated with it and so > the unnamed-module is always returned. I tend to agree with David here. It is good that you guys having this discussion here as it is a way to reach a consensus. > >> The empty string case may or may not be specified. It may be considered >> another corner case, different from both >> "legal" and "illegal" package names, but I personally think that the >> behavior is clear anyway. Ok. >> >> I don't think the argument that JVMTI doesn't validate names is correct. >> GetLocalVariableTable doesn't look like a good example here, since >> it just reads data that's already in the VM anyway, >> but in case of GetModuleByPackageName it is about validation of input >> parameters. Agreed here. >> Other APIs that take identifiers like, for example, JNI FindClass or >> GetMethodID >> don't specify name checks explicitly, but throw >> ClassNotFoundError/NoSuchMethodError illegal names. The JNI does not do any check for illegal names. If the name is illegal then the target is not found. It is why the ClassNotFoundError/NoSuchMethodError is thrown. It perfectly matches the current GetModuleByPackageName specification approach. >> It looks like GetModuleByPackageName is the first JNI/JVMTI function to >> succeed when an ill-formed identifier is passed, >> so it deserves to be documented. > > I disagree with all of that. GetLocalVariableTable, ClassFileLoadHook, > DynamicCodeGenerated, GetThreadInfo, to name a few, all take "names" > encoded as UTF-8 modified strings. None of them validate that the > "name" is legal for the entity being named - JVM TI simply does not do > that kind of argument validation. Right. > > The JNI functions also do not do argument validation. The JNI spec is > clear "The JNI does not check for programming errors such as passing > in NULL pointers or illegal argument types". It is up to the > programmer to ensure they pass valid arguments. FindClass is specified > to simply throw: > > NoClassDefFoundError: if no definition for a requested class or > interface can be found. > > It is the internal VM code, that has to deal with bytecode from > arbitrary sources, that performs the more detailed checking of the name. Right. > > GetModuleByPackageName is slightly unusual in that it really never > fails. As I discussed in the CCC review it could have made a > distinction between packages that would be loaded by the loader and > packages that would not, and throw an exception (which in turn may > have been able to discern that the name was invalid). But that is not > the case - if you don't pass the name of a package that is known to > the loader then you get back the unnamed-module. It doesn't matter > whether the package name is legal-but-unknown, or illegal - it is just > unknown. I tend to agree with David here. But interested to know what objections to this can be. Thanks, Serguei > > David > ------ > >> On CCC update: AFAIU CCC needs to have final version of the proposed >> specification, so yes, >> it needs to be updated to with the test that will be actually pushed to >> the workspace. >> >> Thanks, >> Stas >> >> On 23.06.2016 14:40, David Holmes wrote: >>> >>> >>> On 23/06/2016 9:33 PM, serguei.spitsyn at oracle.com wrote: >>>> On 6/23/16 04:27, David Holmes wrote: >>>>> On 23/06/2016 9:08 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 6/23/16 03:51, David Holmes wrote: >>>>>>> On 23/06/2016 6:04 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> On 6/23/16 00:51, Alan Bateman wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> : >>>>>>>>>> >>>>>>>>>> I agree with it. >>>>>>>>>> Thank you for pointing to this JVMTI example. >>>>>>>>>> I did not find in the JNI where the names are checked to be >>>>>>>>>> legal. >>>>>>>>>> We are going to open a can of worms with this kind of check as >>>>>>>>>> there >>>>>>>>>> can be many corner cases to cover. >>>>>>>>> The primary use-case for this function is from within the CLFH >>>>>>>>> callback so have it return the unnamed module when calling with >>>>>>>>> garage >>>>>>>>> is probably okay, it just needs to be specified. >>>>>>>>> >>>>>>>>> Will you update the webrev to reflect where we've got to this in >>>>>>>>> this >>>>>>>>> discussion? >>>>>>>> >>>>>>>> I need to undo my fix for additional check. >>>>>>>> My up-to-date understanding is that we have to explicitly specify >>>>>>>> two >>>>>>>> points: >>>>>>>> - the function returns the unnamed module if the package does >>>>>>>> not >>>>>>>> exist >>>>>>>> - the function does not check the package names for validness >>>>>>>> and >>>>>>>> always returns the unnamed module for illegal package names >>>>>>>> >>>>>>>> It is better to specify these points explicitly to avoid possible >>>>>>>> confusion. >>>>>>> >>>>>>> I don't agree - nothing else refers to invalid "names" in JVM TI. I >>>>>>> don't see any need to call this out here. If the name supplied >>>>>>> is not >>>>>>> a legal package name then it will not match - end of story. >>>>>> >>>>>> David, >>>>>> >>>>>> It was the original approach that is in the CCC. >>>>>> You were the one who got confused here, and it convinced me that >>>>>> this >>>>>> needs to be more clear. >>>>>> All these changes are because you started the discussion. :) >>>>>> It was useful anyway. >>>>> >>>>> I never said anything about illegal package names. >>>> >>>> True. >>>> This is my (probably, wrong) attempt to make it more clear. >>>> >>>>> >>>>>> Are you against both clarifications or just the last one? >>>>>> I'm Ok to return it back as it is in the CCC. >>>>>> It will save time on the CCC approval. >>>>>> >>>>>> This is the last addition to the spec: >>>>>> >>>>>> + The unnamed module is returned if the specified package does not >>>>>> exist. >>>>> >>>>> The notion of "package does not exist" is ill-defined. This case is >>>>> already covered by the primary specification. >>>>> >>>>>> + The function does not check if the specified package name is >>>>>> illegal. >>>>> >>>>> This does not need to be stated as it is not stated anywhere else for >>>>> anything else that may have legal and illegal forms. >>>> >>>> Good. >>>> This is a relevant fragment from current version of CCC: >>>> >>>> + >>>> + Return the java.lang.reflect.Module object for a >>>> module >>>> + defined to a class loader that contains a given package. >>>> + The module is returned via module_ptr. >>>> +

>>>> + If a named module is defined to the class loader and it >>>> + contains the package then that named module is returned, >>>> + otherwise the unnamed module of the class loader is returned. >>>> + If the package name is the empty string then this function >>>> + always returns the unnamed module for the class loader. >>>> +

>>> >>> As Stanislav said explicitly mentioning the empty string is not really >>> necessary - but I don't see it as harmful. >>> >>>> Does it looks Ok? >>> >>> Yes - as good now as it was in the CCC discussion :) >>> >>> Cheers, >>> David >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> -Alan >>>>>>>> >>>>>> >>>> >> From david.holmes at oracle.com Fri Jun 24 06:48:43 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Jun 2016 16:48:43 +1000 Subject: RFR: 8160088: update hotspot tests depending on GC to use @requires vm.gc.X In-Reply-To: References: <5594dba8-f008-2fae-d293-d9a2e3f6913a@oracle.com> <684b0ef2-14f2-ed3a-63ef-a65c748e2471@oracle.com> <5b2a01d0-df0d-3826-65f5-a1c48f573e37@oracle.com> <931a448e-0e87-59b0-2657-073ac1e34fb2@oracle.com> Message-ID: Thanks for the info Dima! I may have missed it but I think this new @requires functionality needs some broader advertising. :) I'm still not 100% sure what something like vm.gc.G1 means though. Looking at this comment: /** * For all existing GC sets vm.gc.X property. * Example vm.gc.G1=true means: * VM supports G1 * User either set G1 explicitely (-XX:+UseG1GC) or did not set any GC I think it would have been more accurate to add "and the selected GC is G1" - right? That is what the logic seems to do (though I'm not sure why it checks both current and currentSetByErgo ??) Anyway for this set of test changes everything seems fine. Thanks, David On 23/06/2016 10:52 PM, Dmitry Fazunenko wrote: > David, > > On 23.06.2016 14:00, David Holmes wrote: >> Hi Dmitry, >> >> On 23/06/2016 6:52 PM, Dmitry Fazunenko wrote: >>> Hi David, >>> >>> thanks for looking! >>> >>> On 23.06.2016 3:17, David Holmes wrote: >>>> Hi Dmitry, >>>> >>>> On 23/06/2016 4:06 AM, Dmitry Fazunenko wrote: >>>>> Hello, >>>>> >>>>> I'm looking for Reviewers for relatively simple fix which affects 59 >>>>> tests. >>>>> https://bugs.openjdk.java.net/browse/JDK-8160088 >>>>> http://cr.openjdk.java.net/~dfazunen/8160088/webrev.00/ >>>>> >>>>> The fix allows to skip execution of tests requiring a specific GC in >>>>> case of the required GC is not supported by VM. >>>>> Old variant: >>>>> @requires vm.gc == null | vm.gc == "G1" >>>>> A test will be executed if no GC is specified externally or >>>>> -XX:+UseG1GC flag is given. >>>>> This test will be executed even if VM doesn't support G1 and >>>>> fail. >>>>> New variant: >>>>> @requires vm.gc.G1 >>>>> This test will not be executed if VM doesn't support G1. >>>> >>>> That doesn't seem sufficient. What you want is that if the test >>>> requires G1 then it also supports G1, so it seems to me the correct >>>> formulation is: >>>> >>>> @requires (vm.gc == null | // null -> default -> g1 (usually) >>>> vm.gc == G1 ) & >>>> vm.gc.G1 >>> >>> No, vm.gc.G1 is an alias to: (vm.gc == null | vm.gc == g1) & >>> vm.gc.supportsG1. >> >> Wow - on the one hand that is a compact/succinct syntax. On the other >> hand - no one will recognize what it actually means! I think I have >> missed a discussed I would like to have given input on! > > It was discussed on hotspot-gc-dev alias as part of '8151283' review: > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-June/018352.html > > Originally it was proposed names like: vm.gc.G1.acceptable > but after input from GC dev, vm.gc.G1 was selected. > Documentation how the properties are set what that mean is available in > the class source (jtreg plugin): > /test/jtreg-ext/requires/VMProps.java > > >> >>>> >>>> Aside: how does jtreg determine which GC's are supported? >>> Sorry for not providing the full history here: >>> >>> CODETOOLS-7901583: jtreg should provide extensible mechanism for >>> @requires properties >>> - change to jtreg that allows a Test Suite to introduce its own >>> @requires props >>> >>> JDK-8152432: Implement setting jtreg @requires properties vm.flavor, >>> vm.bits, vm.compMode >>> - implementation that mechanism in hotspot >>> >>> JDK-8154096: Extend WhiteBox API with methods which retrieve from VM >>> information about available GC >>> - fix which allows to know if a GC is supported >>> >>> JDK-8151283: Implement setting jtreg @requires property >>> vm.isG1Supported. >>> - introduction vm.gc.G1, vm.gc.Serial, vm.gc.Parallel and >>> vm.gc.ConcMarkSweep >>> >>> JDK-8160088 (this one): update hotspot tests depending on GC to use >>> @requires vm.gc.X >>> - culmination: update tests to use new functionality >> >> Wow I have missed out on a lot it seem! :( >> >> What version of jtreg supports this level of customized @requires? >> Someone has already encountered the following error: >> >> Error. Parse Exception: Syntax error in @requires expression: invalid >> name: XXX >> >> for a new @requires XXX clause. > > It was implemented in the final build of jtreg4.1 and of course it's > available in jtreg4.2 > Quiting jtreg/doc/jtreg/tag-spec.html: > > |requires.extraPropDefns | > > This option is used to provide source files for classes that will be > used at the beginning of each test suite run, to determine > additional characteristics of the system for use with the > |@requires| tag. Each class must implement > |java.util.concurrent.Callable>|. When > invoked, the |call()| method should return properties that can be > referenced in an expression in a |@requires| tag. /Note:/ the names > of the new properties that may be returned by calling these classes > must also be declared in a |requires.properties| entry. > > If this option is specified, the following additional options may > also be specified: > > * |requires.extraPropDefns.libs | ? source files for > classes that will be put on the classpath when the primary > classes are run. > * |requires.extraPropDefns.bootlibs | ? source files > for classes that will be put on the bootclasspath when the > primary classes are run. > * |requires.extraPropDefns.javacOpts | ? options that > will be passed to javac when the source files are compiled. > * |requires.extraPropDefns.vmOpts | ? options that will > be passed to VM when the classes are executed. > > In this family of options, if a source file is enclosed in square > brackets, no error message will be given if the file is not available. > > The following properties may appear in either TEST.ROOT or any > TEST.properties file: > > The reason, why @requires XXX is not recognized by jtreg - XXX is not > registered in TEST.ROOT. > See: hotspot/test/TEST.ROOT for example on how to register new props. > > For the time being recently introduced requires properties are available > only in the hotspot repository. > To introduce them in jdk - a few lines from hotspot/test/TEST.ROOT > should be placed in jdk/test/TEST.ROOT > We haven't done this yet, because we are considering a possibility to > move VM specific tests from jdk into hotspot repo. > > Thanks, > Dima > > >> >> Thanks, >> David >> >>> Thanks, >>> Dima >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> Testing: >>>>> 1) starting jtreg with various collectors with "-c" option to verify >>>>> correctness of test descriptions. >>>>> Number of selected tests before and after change is the same: >>>>> -XX:+UseG1GC: 1,456 >>>>> -XX:+UseSerialGC: 1,366 >>>>> -XX:+UseParallelGC: 1,369 >>>>> -XX:+UseConcMarkSweepGC: 1,368 >>>>> Default: 1,483; error >>>>> >>>>> 2) RBT (in progress) >>>>> >>>>> 3) Diff is analyzed manually (only necessary lines are affected): >>>>> #> hg diff |grep "^- " |sort -u >>>>> - * @requires (vm.gc == "G1" | vm.gc == "null") >>>>> - * @requires (vm.gc=="G1" | vm.gc=="null") >>>>> - * @requires vm.gc == "G1" | vm.gc == "null" >>>>> - * @requires vm.gc=="ConcMarkSweep" | vm.gc == "null" >>>>> - * @requires vm.gc=="ConcMarkSweep" | vm.gc=="null" >>>>> - * @requires vm.gc=="G1" | vm.gc =="null" >>>>> - * @requires vm.gc=="G1" | vm.gc=="null" >>>>> - * @requires vm.gc=="Parallel" | vm.gc=="null" >>>>> - * @requires vm.gc=="Serial" | vm.gc=="null" >>>>> - * @requires vm.gc=="null" | vm.gc=="G1" >>>>> - * Copyright (c) 2013, 2014, Oracle and/or its affiliates. All rights >>>>> reserved. >>>>> - * Copyright (c) 2013, 2015, Oracle and/or its affiliates. All rights >>>>> reserved. >>>>> - * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All rights >>>>> reserved. >>>>> - * Copyright (c) 2015, Oracle and/or its affiliates. All rights >>>>> reserved. >>>>> #> hg diff |grep "^+ " |sort -u >>>>> + * @requires vm.gc.ConcMarkSweep >>>>> + * @requires vm.gc.G1 >>>>> + * @requires vm.gc.Parallel >>>>> + * @requires vm.gc.Serial >>>>> + * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All rights >>>>> reserved. >>>>> + * Copyright (c) 2014, 2016, Oracle and/or its affiliates. All rights >>>>> reserved. >>>>> + * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights >>>>> reserved. >>>>> >>>>> Thanks, >>>>> Dima >>> > From dmitry.fazunenko at oracle.com Fri Jun 24 08:54:36 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Fri, 24 Jun 2016 11:54:36 +0300 Subject: RFR: 8160088: update hotspot tests depending on GC to use @requires vm.gc.X In-Reply-To: References: <5594dba8-f008-2fae-d293-d9a2e3f6913a@oracle.com> <684b0ef2-14f2-ed3a-63ef-a65c748e2471@oracle.com> <5b2a01d0-df0d-3826-65f5-a1c48f573e37@oracle.com> <931a448e-0e87-59b0-2657-073ac1e34fb2@oracle.com> Message-ID: Hi David, On 24.06.2016 9:48, David Holmes wrote: > Thanks for the info Dima! I may have missed it but I think this new > @requires functionality needs some broader advertising. :) That functionality was introduced on this alias as well: http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-April/022443.html But I agree, "Implement setting jtreg @requires properties vm.flavor, vm.bits, vm.compMode" doesn't attract much attention. If I were from sales, I would write: "Braking news: jtreg introduces smart keywords" :) > > I'm still not 100% sure what something like vm.gc.G1 means though. > Looking at this comment: > > /** > * For all existing GC sets vm.gc.X property. > * Example vm.gc.G1=true means: > * VM supports G1 > * User either set G1 explicitely (-XX:+UseG1GC) or did not set any GC > > I think it would have been more accurate to add "and the selected GC > is G1" - right? No. vm.gc.G1 means: The test needs to set G1 GC via -XX:+UseG1GC It requires: 1) vm supports G1 (minimal VM doesn't) 2) User didn't say: -XX:+UseSerialGC ,-XX:+UseParallelGC -XX:+UseCMSGC (otherwise it will be a flag conflict) Note: User may say: -XX:+UseG1GC > That is what the logic seems to do (though I'm not sure why it checks > both current and currentSetByErgo ??) There is a class of machines where ergonomics selects Serial GC if no other GC is specified explicitly. For such machines currentGC might be "Serial" but setting G1 is still possible. currentSetByErgo == false means: no other collector but currently selected is available for setting via -XX:UseXGC. I know that the current description is hard to understand, but I didn't come up with a better wording. > > Anyway for this set of test changes everything seems fine. Thanks a lot! -- Dima > > Thanks, > David > > On 23/06/2016 10:52 PM, Dmitry Fazunenko wrote: >> David, >> >> On 23.06.2016 14:00, David Holmes wrote: >>> Hi Dmitry, >>> >>> On 23/06/2016 6:52 PM, Dmitry Fazunenko wrote: >>>> Hi David, >>>> >>>> thanks for looking! >>>> >>>> On 23.06.2016 3:17, David Holmes wrote: >>>>> Hi Dmitry, >>>>> >>>>> On 23/06/2016 4:06 AM, Dmitry Fazunenko wrote: >>>>>> Hello, >>>>>> >>>>>> I'm looking for Reviewers for relatively simple fix which affects 59 >>>>>> tests. >>>>>> https://bugs.openjdk.java.net/browse/JDK-8160088 >>>>>> http://cr.openjdk.java.net/~dfazunen/8160088/webrev.00/ >>>>>> >>>>>> The fix allows to skip execution of tests requiring a specific GC in >>>>>> case of the required GC is not supported by VM. >>>>>> Old variant: >>>>>> @requires vm.gc == null | vm.gc == "G1" >>>>>> A test will be executed if no GC is specified externally or >>>>>> -XX:+UseG1GC flag is given. >>>>>> This test will be executed even if VM doesn't support G1 and >>>>>> fail. >>>>>> New variant: >>>>>> @requires vm.gc.G1 >>>>>> This test will not be executed if VM doesn't support G1. >>>>> >>>>> That doesn't seem sufficient. What you want is that if the test >>>>> requires G1 then it also supports G1, so it seems to me the correct >>>>> formulation is: >>>>> >>>>> @requires (vm.gc == null | // null -> default -> g1 (usually) >>>>> vm.gc == G1 ) & >>>>> vm.gc.G1 >>>> >>>> No, vm.gc.G1 is an alias to: (vm.gc == null | vm.gc == g1) & >>>> vm.gc.supportsG1. >>> >>> Wow - on the one hand that is a compact/succinct syntax. On the other >>> hand - no one will recognize what it actually means! I think I have >>> missed a discussed I would like to have given input on! >> >> It was discussed on hotspot-gc-dev alias as part of '8151283' review: >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-June/018352.html >> >> >> Originally it was proposed names like: vm.gc.G1.acceptable >> but after input from GC dev, vm.gc.G1 was selected. >> Documentation how the properties are set what that mean is available in >> the class source (jtreg plugin): >> /test/jtreg-ext/requires/VMProps.java >> >> >>> >>>>> >>>>> Aside: how does jtreg determine which GC's are supported? >>>> Sorry for not providing the full history here: >>>> >>>> CODETOOLS-7901583: jtreg should provide extensible mechanism for >>>> @requires properties >>>> - change to jtreg that allows a Test Suite to introduce its own >>>> @requires props >>>> >>>> JDK-8152432: Implement setting jtreg @requires properties vm.flavor, >>>> vm.bits, vm.compMode >>>> - implementation that mechanism in hotspot >>>> >>>> JDK-8154096: Extend WhiteBox API with methods which retrieve from VM >>>> information about available GC >>>> - fix which allows to know if a GC is supported >>>> >>>> JDK-8151283: Implement setting jtreg @requires property >>>> vm.isG1Supported. >>>> - introduction vm.gc.G1, vm.gc.Serial, vm.gc.Parallel and >>>> vm.gc.ConcMarkSweep >>>> >>>> JDK-8160088 (this one): update hotspot tests depending on GC to use >>>> @requires vm.gc.X >>>> - culmination: update tests to use new functionality >>> >>> Wow I have missed out on a lot it seem! :( >>> >>> What version of jtreg supports this level of customized @requires? >>> Someone has already encountered the following error: >>> >>> Error. Parse Exception: Syntax error in @requires expression: invalid >>> name: XXX >>> >>> for a new @requires XXX clause. >> >> It was implemented in the final build of jtreg4.1 and of course it's >> available in jtreg4.2 >> Quiting jtreg/doc/jtreg/tag-spec.html: >> >> |requires.extraPropDefns | >> >> This option is used to provide source files for classes that will be >> used at the beginning of each test suite run, to determine >> additional characteristics of the system for use with the >> |@requires| tag. Each class must implement >> |java.util.concurrent.Callable>|. When >> invoked, the |call()| method should return properties that can be >> referenced in an expression in a |@requires| tag. /Note:/ the names >> of the new properties that may be returned by calling these classes >> must also be declared in a |requires.properties| entry. >> >> If this option is specified, the following additional options may >> also be specified: >> >> * |requires.extraPropDefns.libs | ? source files for >> classes that will be put on the classpath when the primary >> classes are run. >> * |requires.extraPropDefns.bootlibs | ? source files >> for classes that will be put on the bootclasspath when the >> primary classes are run. >> * |requires.extraPropDefns.javacOpts | ? options that >> will be passed to javac when the source files are compiled. >> * |requires.extraPropDefns.vmOpts | ? options that will >> be passed to VM when the classes are executed. >> >> In this family of options, if a source file is enclosed in square >> brackets, no error message will be given if the file is not >> available. >> >> The following properties may appear in either TEST.ROOT or any >> TEST.properties file: >> >> The reason, why @requires XXX is not recognized by jtreg - XXX is not >> registered in TEST.ROOT. >> See: hotspot/test/TEST.ROOT for example on how to register new props. >> >> For the time being recently introduced requires properties are available >> only in the hotspot repository. >> To introduce them in jdk - a few lines from hotspot/test/TEST.ROOT >> should be placed in jdk/test/TEST.ROOT >> We haven't done this yet, because we are considering a possibility to >> move VM specific tests from jdk into hotspot repo. >> >> Thanks, >> Dima >> >> >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Dima >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Testing: >>>>>> 1) starting jtreg with various collectors with "-c" option to verify >>>>>> correctness of test descriptions. >>>>>> Number of selected tests before and after change is the same: >>>>>> -XX:+UseG1GC: 1,456 >>>>>> -XX:+UseSerialGC: 1,366 >>>>>> -XX:+UseParallelGC: 1,369 >>>>>> -XX:+UseConcMarkSweepGC: 1,368 >>>>>> Default: 1,483; error >>>>>> >>>>>> 2) RBT (in progress) >>>>>> >>>>>> 3) Diff is analyzed manually (only necessary lines are affected): >>>>>> #> hg diff |grep "^- " |sort -u >>>>>> - * @requires (vm.gc == "G1" | vm.gc == "null") >>>>>> - * @requires (vm.gc=="G1" | vm.gc=="null") >>>>>> - * @requires vm.gc == "G1" | vm.gc == "null" >>>>>> - * @requires vm.gc=="ConcMarkSweep" | vm.gc == "null" >>>>>> - * @requires vm.gc=="ConcMarkSweep" | vm.gc=="null" >>>>>> - * @requires vm.gc=="G1" | vm.gc =="null" >>>>>> - * @requires vm.gc=="G1" | vm.gc=="null" >>>>>> - * @requires vm.gc=="Parallel" | vm.gc=="null" >>>>>> - * @requires vm.gc=="Serial" | vm.gc=="null" >>>>>> - * @requires vm.gc=="null" | vm.gc=="G1" >>>>>> - * Copyright (c) 2013, 2014, Oracle and/or its affiliates. All >>>>>> rights >>>>>> reserved. >>>>>> - * Copyright (c) 2013, 2015, Oracle and/or its affiliates. All >>>>>> rights >>>>>> reserved. >>>>>> - * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All >>>>>> rights >>>>>> reserved. >>>>>> - * Copyright (c) 2015, Oracle and/or its affiliates. All rights >>>>>> reserved. >>>>>> #> hg diff |grep "^+ " |sort -u >>>>>> + * @requires vm.gc.ConcMarkSweep >>>>>> + * @requires vm.gc.G1 >>>>>> + * @requires vm.gc.Parallel >>>>>> + * @requires vm.gc.Serial >>>>>> + * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All >>>>>> rights >>>>>> reserved. >>>>>> + * Copyright (c) 2014, 2016, Oracle and/or its affiliates. All >>>>>> rights >>>>>> reserved. >>>>>> + * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All >>>>>> rights >>>>>> reserved. >>>>>> >>>>>> Thanks, >>>>>> Dima >>>> >> From volker.simonis at gmail.com Fri Jun 24 09:17:10 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 24 Jun 2016 11:17:10 +0200 Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation on ppc64 and sparc In-Reply-To: <78048e75-621e-c8fe-b9fd-ee1a5842aa8d@oracle.com> References: <27dde86d-f7b3-3093-e500-cd3c9156811f@oracle.com> <5767AD68.8090500@oracle.com> <5767B078.8030102@oracle.com> <5768FE79.2060301@oracle.com> <78048e75-621e-c8fe-b9fd-ee1a5842aa8d@oracle.com> Message-ID: Thanks Vladimir. Best regards, Volker On Thu, Jun 23, 2016 at 7:57 PM, Vladimir Kozlov wrote: > Reviewed. > > PPC changes looks fine. > SPARC changes are good - I was worried about annulling in branch in > increment_mask_and_jump() but it is fine since it is false. > C1 - new check is correct. > > Test is fine. > > Thanks, > Vladimir > > > On 6/22/16 7:29 AM, Volker Simonis wrote: >> >> On Tue, Jun 21, 2016 at 10:44 AM, Tobias Hartmann >> wrote: >>> >>> Hi Volker, >>> >>> On 21.06.2016 09:37, Volker Simonis wrote: >>>> >>>> On Mon, Jun 20, 2016 at 10:59 AM, Tobias Hartmann >>>> wrote: >>>>> >>>>> Hi Volker, >>>>> >>>>> On 20.06.2016 10:52, Volker Simonis wrote: >>>>>> >>>>>> Hi Tobias, >>>>>> >>>>>> thanks for sponsoring! I've uploaded a new webrev with you and >>>>>> Vladimir as reviewers: >>>>>> >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v2/ >>>>>> >>>>>> You can find the changeset there: >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v2/hotspot.changeset >>>>> >>>>> >>>>> Thanks, I just noticed that the test has >>>>> >>>>> 26 * @bug 9999999 >>>>> >>>>> You can fix this in-place. I'll then run the required pre-integration >>>>> testing (~24h) and push your change afterwards. >>>>> >>>> >>>> Hi Tobias, >>>> >>>> good catch and sorry, I somehow missed your mail yesterday. >>>> >>>> You can find the new changeset here: >>>> >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v3/hotspot.changeset >>> >>> >>> Thank you! >>> >>> I just looked at the test results and unfortunately DisableOSRTest fails >>> on all platforms (including SPARC) if -Xcomp is set: >>> >>> ----------System.err:(13/1215)---------- >>> java.lang.RuntimeException: "public static void >>> DisableOSRTest.main(java.lang.String[]) throws java.lang.Exception" >>> shouldn't be OSR compiled if running with -XX:-UseOnStackReplacement! >>> at DisableOSRTest.main(DisableOSRTest.java:59) >>> at >>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base/Native >>> Method) >>> at >>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base/NativeMethodAccessorImpl.java:62) >>> at >>> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base/DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(java.base/Method.java:531) >>> at >>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) >>> at java.lang.Thread.run(java.base/Thread.java:843) >>> >>> There are several OSR compilations in the log: >>> >>> 12916 4242 % b 4 DisableOSRTest::main @ 19 (61 bytes) >>> >> >> Hi Tobias, >> >> you're right! Thanks for finding this new problem:) >> >> I initially only fixed OSR from interpreted code. But C1 compiled code >> can also trigger an OSR request (and -Xcomp triggers a C1 compilation >> of main before it is invoked for the first time). Switching this off >> with the help of -XX:-UseOnStackReplacement never worked, but it was >> actually easy to fix. Please find the new change here: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v4/ >> >> I think it would good if somebody (maybe the initial reviewers) could >> review the new C1 changes to prevent OSR in C1-compiled code. >> >> Thank you and best regards, >> Volker >> >> >>> Best regards, >>> Tobias >>> >>>> >>>> Thank you and best regards, >>>> Volker >>>> >>>> >>>>> Best regards, >>>>> Tobias >>>>> >>>>>> >>>>>> Thanks, >>>>>> Volker >>>>>> >>>>>> >>>>>> On Mon, Jun 20, 2016 at 10:46 AM, Tobias Hartmann >>>>>> wrote: >>>>>>> >>>>>>> Hi Volker, >>>>>>> >>>>>>> you fix looks good to me! I can do the sponsoring, please just send >>>>>>> me a changeset. >>>>>>> >>>>>>> Best regards, >>>>>>> Tobias >>>>>>> >>>>>>> On 20.06.2016 10:16, Volker Simonis wrote: >>>>>>>> >>>>>>>> Thanks Vladimir! >>>>>>>> >>>>>>>> .. I still need a sponsor :( >>>>>>>> >>>>>>>> Regards, >>>>>>>> Volker >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jun 17, 2016 at 10:53 PM, Vladimir Kozlov >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Looks good. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> >>>>>>>>> On 6/17/16 2:22 AM, Volker Simonis wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Goetz, >>>>>>>>>> >>>>>>>>>> thanks for the review. >>>>>>>>>> You're right, I've fixed the "else": >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v1/ >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Volker >>>>>>>>>> >>>>>>>>>> On Fri, Jun 17, 2016 at 11:08 AM, Lindenmaier, Goetz >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi Volker, >>>>>>>>>>> >>>>>>>>>>> thanks for doing this fix, I also have run into this issue before >>>>>>>>>>> ... >>>>>>>>>>> Looks good. >>>>>>>>>>> >>>>>>>>>>> Small nit: usually >>>>>>>>>>> } >>>>>>>>>>> else { >>>>>>>>>>> are on one line. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] >>>>>>>>>>>> On >>>>>>>>>>>> Behalf Of Volker Simonis >>>>>>>>>>>> Sent: Donnerstag, 16. Juni 2016 16:54 >>>>>>>>>>>> To: HotSpot Open Source Developers >>>>>>>>>>>> >>>>>>>>>>>> Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not >>>>>>>>>>>> work >>>>>>>>>>>> together with -XX:+TieredCompilation on ppc64 and sparc >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> can I please have a review and sponsor for the following small >>>>>>>>>>>> change >>>>>>>>>>>> which fixes -XX:-UseOnStackReplacement to work together with >>>>>>>>>>>> -XX:+TieredCompilation: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620/ >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8159620 >>>>>>>>>>>> >>>>>>>>>>>> This is a long standing bug on SPARC and as the ppc64 template >>>>>>>>>>>> interpreter was initially forked from the SPARC implementation, >>>>>>>>>>>> it >>>>>>>>>>>> also manifests there. The problem is that in the case of tiered >>>>>>>>>>>> compilation the interpreter unconditionally calls >>>>>>>>>>>> InterpreterRuntime::frequency_counter_overflow if the back edge >>>>>>>>>>>> counter overflows. This triggers an OSR compilation, even if OSR >>>>>>>>>>>> was >>>>>>>>>>>> switched off with -XX:-UseOnStackReplacement. >>>>>>>>>>>> >>>>>>>>>>>> The fix is simple - just don't call >>>>>>>>>>>> InterpreterRuntime::frequency_counter_overflow if OSR has been >>>>>>>>>>>> switched off. >>>>>>>>>>>> >>>>>>>>>>>> Thank you and best regards, >>>>>>>>>>>> Volker From david.holmes at oracle.com Fri Jun 24 09:20:30 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Jun 2016 02:20:30 -0700 (PDT) Subject: RFR: 8160088: update hotspot tests depending on GC to use @requires vm.gc.X In-Reply-To: References: <5594dba8-f008-2fae-d293-d9a2e3f6913a@oracle.com> <684b0ef2-14f2-ed3a-63ef-a65c748e2471@oracle.com> <5b2a01d0-df0d-3826-65f5-a1c48f573e37@oracle.com> <931a448e-0e87-59b0-2657-073ac1e34fb2@oracle.com> Message-ID: Hi Dima, This is diverging somewhat but ... :) On 24/06/2016 6:54 PM, Dmitry Fazunenko wrote: > Hi David, > > On 24.06.2016 9:48, David Holmes wrote: >> Thanks for the info Dima! I may have missed it but I think this new >> @requires functionality needs some broader advertising. :) > > That functionality was introduced on this alias as well: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-April/022443.html > But I agree, "Implement setting jtreg @requires properties vm.flavor, > vm.bits, vm.compMode" doesn't > attract much attention. > If I were from sales, I would write: "Braking news: jtreg introduces > smart keywords" :) > >> >> I'm still not 100% sure what something like vm.gc.G1 means though. >> Looking at this comment: >> >> /** >> * For all existing GC sets vm.gc.X property. >> * Example vm.gc.G1=true means: >> * VM supports G1 >> * User either set G1 explicitely (-XX:+UseG1GC) or did not set any GC >> >> I think it would have been more accurate to add "and the selected GC >> is G1" - right? > > No. vm.gc.G1 means: > The test needs to set G1 GC via -XX:+UseG1GC > It requires: > 1) vm supports G1 (minimal VM doesn't) > 2) User didn't say: -XX:+UseSerialGC ,-XX:+UseParallelGC -XX:+UseCMSGC > (otherwise it will be a flag conflict) > Note: User may say: -XX:+UseG1GC > >> That is what the logic seems to do (though I'm not sure why it checks >> both current and currentSetByErgo ??) > > There is a class of machines where ergonomics selects Serial GC if no > other GC is specified explicitly. > For such machines currentGC might be "Serial" but setting G1 is still > possible. > currentSetByErgo == false means: no other collector but currently > selected is available for setting via -XX:UseXGC. I'm more confused than I thought I was then. :( Let's pretend that default GC selection is random. If vm.gc == null we are letting the VM choose the GC by whatever means. If the test requires G1 then we need to know that currentGC() == G1 - if it is something else then we can't run this test. It doesn't seem to matter how the currentGC was selected as long as it is G1 - so I don't see why we need to query if the currentGC was selected by ergo ?? Cheers, David > I know that the current description is hard to understand, but I didn't > come up with a better wording. > >> >> Anyway for this set of test changes everything seems fine. > > Thanks a lot! > > -- Dima > >> >> Thanks, >> David >> >> On 23/06/2016 10:52 PM, Dmitry Fazunenko wrote: >>> David, >>> >>> On 23.06.2016 14:00, David Holmes wrote: >>>> Hi Dmitry, >>>> >>>> On 23/06/2016 6:52 PM, Dmitry Fazunenko wrote: >>>>> Hi David, >>>>> >>>>> thanks for looking! >>>>> >>>>> On 23.06.2016 3:17, David Holmes wrote: >>>>>> Hi Dmitry, >>>>>> >>>>>> On 23/06/2016 4:06 AM, Dmitry Fazunenko wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I'm looking for Reviewers for relatively simple fix which affects 59 >>>>>>> tests. >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8160088 >>>>>>> http://cr.openjdk.java.net/~dfazunen/8160088/webrev.00/ >>>>>>> >>>>>>> The fix allows to skip execution of tests requiring a specific GC in >>>>>>> case of the required GC is not supported by VM. >>>>>>> Old variant: >>>>>>> @requires vm.gc == null | vm.gc == "G1" >>>>>>> A test will be executed if no GC is specified externally or >>>>>>> -XX:+UseG1GC flag is given. >>>>>>> This test will be executed even if VM doesn't support G1 and >>>>>>> fail. >>>>>>> New variant: >>>>>>> @requires vm.gc.G1 >>>>>>> This test will not be executed if VM doesn't support G1. >>>>>> >>>>>> That doesn't seem sufficient. What you want is that if the test >>>>>> requires G1 then it also supports G1, so it seems to me the correct >>>>>> formulation is: >>>>>> >>>>>> @requires (vm.gc == null | // null -> default -> g1 (usually) >>>>>> vm.gc == G1 ) & >>>>>> vm.gc.G1 >>>>> >>>>> No, vm.gc.G1 is an alias to: (vm.gc == null | vm.gc == g1) & >>>>> vm.gc.supportsG1. >>>> >>>> Wow - on the one hand that is a compact/succinct syntax. On the other >>>> hand - no one will recognize what it actually means! I think I have >>>> missed a discussed I would like to have given input on! >>> >>> It was discussed on hotspot-gc-dev alias as part of '8151283' review: >>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-June/018352.html >>> >>> >>> Originally it was proposed names like: vm.gc.G1.acceptable >>> but after input from GC dev, vm.gc.G1 was selected. >>> Documentation how the properties are set what that mean is available in >>> the class source (jtreg plugin): >>> /test/jtreg-ext/requires/VMProps.java >>> >>> >>>> >>>>>> >>>>>> Aside: how does jtreg determine which GC's are supported? >>>>> Sorry for not providing the full history here: >>>>> >>>>> CODETOOLS-7901583: jtreg should provide extensible mechanism for >>>>> @requires properties >>>>> - change to jtreg that allows a Test Suite to introduce its own >>>>> @requires props >>>>> >>>>> JDK-8152432: Implement setting jtreg @requires properties vm.flavor, >>>>> vm.bits, vm.compMode >>>>> - implementation that mechanism in hotspot >>>>> >>>>> JDK-8154096: Extend WhiteBox API with methods which retrieve from VM >>>>> information about available GC >>>>> - fix which allows to know if a GC is supported >>>>> >>>>> JDK-8151283: Implement setting jtreg @requires property >>>>> vm.isG1Supported. >>>>> - introduction vm.gc.G1, vm.gc.Serial, vm.gc.Parallel and >>>>> vm.gc.ConcMarkSweep >>>>> >>>>> JDK-8160088 (this one): update hotspot tests depending on GC to use >>>>> @requires vm.gc.X >>>>> - culmination: update tests to use new functionality >>>> >>>> Wow I have missed out on a lot it seem! :( >>>> >>>> What version of jtreg supports this level of customized @requires? >>>> Someone has already encountered the following error: >>>> >>>> Error. Parse Exception: Syntax error in @requires expression: invalid >>>> name: XXX >>>> >>>> for a new @requires XXX clause. >>> >>> It was implemented in the final build of jtreg4.1 and of course it's >>> available in jtreg4.2 >>> Quiting jtreg/doc/jtreg/tag-spec.html: >>> >>> |requires.extraPropDefns | >>> >>> This option is used to provide source files for classes that will be >>> used at the beginning of each test suite run, to determine >>> additional characteristics of the system for use with the >>> |@requires| tag. Each class must implement >>> |java.util.concurrent.Callable>|. When >>> invoked, the |call()| method should return properties that can be >>> referenced in an expression in a |@requires| tag. /Note:/ the names >>> of the new properties that may be returned by calling these classes >>> must also be declared in a |requires.properties| entry. >>> >>> If this option is specified, the following additional options may >>> also be specified: >>> >>> * |requires.extraPropDefns.libs | ? source files for >>> classes that will be put on the classpath when the primary >>> classes are run. >>> * |requires.extraPropDefns.bootlibs | ? source files >>> for classes that will be put on the bootclasspath when the >>> primary classes are run. >>> * |requires.extraPropDefns.javacOpts | ? options that >>> will be passed to javac when the source files are compiled. >>> * |requires.extraPropDefns.vmOpts | ? options that will >>> be passed to VM when the classes are executed. >>> >>> In this family of options, if a source file is enclosed in square >>> brackets, no error message will be given if the file is not >>> available. >>> >>> The following properties may appear in either TEST.ROOT or any >>> TEST.properties file: >>> >>> The reason, why @requires XXX is not recognized by jtreg - XXX is not >>> registered in TEST.ROOT. >>> See: hotspot/test/TEST.ROOT for example on how to register new props. >>> >>> For the time being recently introduced requires properties are available >>> only in the hotspot repository. >>> To introduce them in jdk - a few lines from hotspot/test/TEST.ROOT >>> should be placed in jdk/test/TEST.ROOT >>> We haven't done this yet, because we are considering a possibility to >>> move VM specific tests from jdk into hotspot repo. >>> >>> Thanks, >>> Dima >>> >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Dima >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Testing: >>>>>>> 1) starting jtreg with various collectors with "-c" option to verify >>>>>>> correctness of test descriptions. >>>>>>> Number of selected tests before and after change is the same: >>>>>>> -XX:+UseG1GC: 1,456 >>>>>>> -XX:+UseSerialGC: 1,366 >>>>>>> -XX:+UseParallelGC: 1,369 >>>>>>> -XX:+UseConcMarkSweepGC: 1,368 >>>>>>> Default: 1,483; error >>>>>>> >>>>>>> 2) RBT (in progress) >>>>>>> >>>>>>> 3) Diff is analyzed manually (only necessary lines are affected): >>>>>>> #> hg diff |grep "^- " |sort -u >>>>>>> - * @requires (vm.gc == "G1" | vm.gc == "null") >>>>>>> - * @requires (vm.gc=="G1" | vm.gc=="null") >>>>>>> - * @requires vm.gc == "G1" | vm.gc == "null" >>>>>>> - * @requires vm.gc=="ConcMarkSweep" | vm.gc == "null" >>>>>>> - * @requires vm.gc=="ConcMarkSweep" | vm.gc=="null" >>>>>>> - * @requires vm.gc=="G1" | vm.gc =="null" >>>>>>> - * @requires vm.gc=="G1" | vm.gc=="null" >>>>>>> - * @requires vm.gc=="Parallel" | vm.gc=="null" >>>>>>> - * @requires vm.gc=="Serial" | vm.gc=="null" >>>>>>> - * @requires vm.gc=="null" | vm.gc=="G1" >>>>>>> - * Copyright (c) 2013, 2014, Oracle and/or its affiliates. All >>>>>>> rights >>>>>>> reserved. >>>>>>> - * Copyright (c) 2013, 2015, Oracle and/or its affiliates. All >>>>>>> rights >>>>>>> reserved. >>>>>>> - * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All >>>>>>> rights >>>>>>> reserved. >>>>>>> - * Copyright (c) 2015, Oracle and/or its affiliates. All rights >>>>>>> reserved. >>>>>>> #> hg diff |grep "^+ " |sort -u >>>>>>> + * @requires vm.gc.ConcMarkSweep >>>>>>> + * @requires vm.gc.G1 >>>>>>> + * @requires vm.gc.Parallel >>>>>>> + * @requires vm.gc.Serial >>>>>>> + * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All >>>>>>> rights >>>>>>> reserved. >>>>>>> + * Copyright (c) 2014, 2016, Oracle and/or its affiliates. All >>>>>>> rights >>>>>>> reserved. >>>>>>> + * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All >>>>>>> rights >>>>>>> reserved. >>>>>>> >>>>>>> Thanks, >>>>>>> Dima >>>>> >>> > From dmitry.fazunenko at oracle.com Fri Jun 24 09:52:44 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Fri, 24 Jun 2016 12:52:44 +0300 Subject: RFR: 8160088: update hotspot tests depending on GC to use @requires vm.gc.X In-Reply-To: References: <5594dba8-f008-2fae-d293-d9a2e3f6913a@oracle.com> <684b0ef2-14f2-ed3a-63ef-a65c748e2471@oracle.com> <5b2a01d0-df0d-3826-65f5-a1c48f573e37@oracle.com> <931a448e-0e87-59b0-2657-073ac1e34fb2@oracle.com> Message-ID: <5f381dd6-4eb2-5cee-36a6-1f4eccf67fbd@oracle.com> David, On 24.06.2016 12:20, David Holmes wrote: > Hi Dima, > > This is diverging somewhat but ... :) > > On 24/06/2016 6:54 PM, Dmitry Fazunenko wrote: >> Hi David, >> >> On 24.06.2016 9:48, David Holmes wrote: >>> Thanks for the info Dima! I may have missed it but I think this new >>> @requires functionality needs some broader advertising. :) >> >> That functionality was introduced on this alias as well: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-April/022443.html >> >> But I agree, "Implement setting jtreg @requires properties vm.flavor, >> vm.bits, vm.compMode" doesn't >> attract much attention. >> If I were from sales, I would write: "Braking news: jtreg introduces >> smart keywords" :) >> >>> >>> I'm still not 100% sure what something like vm.gc.G1 means though. >>> Looking at this comment: >>> >>> /** >>> * For all existing GC sets vm.gc.X property. >>> * Example vm.gc.G1=true means: >>> * VM supports G1 >>> * User either set G1 explicitely (-XX:+UseG1GC) or did not set >>> any GC >>> >>> I think it would have been more accurate to add "and the selected GC >>> is G1" - right? >> >> No. vm.gc.G1 means: >> The test needs to set G1 GC via -XX:+UseG1GC >> It requires: >> 1) vm supports G1 (minimal VM doesn't) >> 2) User didn't say: -XX:+UseSerialGC ,-XX:+UseParallelGC -XX:+UseCMSGC >> (otherwise it will be a flag conflict) >> Note: User may say: -XX:+UseG1GC >> >>> That is what the logic seems to do (though I'm not sure why it checks >>> both current and currentSetByErgo ??) >> >> There is a class of machines where ergonomics selects Serial GC if no >> other GC is specified explicitly. >> For such machines currentGC might be "Serial" but setting G1 is still >> possible. >> currentSetByErgo == false means: no other collector but currently >> selected is available for setting via -XX:UseXGC. > > I'm more confused than I thought I was then. :( > > Let's pretend that default GC selection is random. If vm.gc == null we > are letting the VM choose the GC by whatever means. If the test > requires G1 then we need to know that currentGC() == G1 - if it is > something else then we can't run this test. It doesn't seem to matter > how the currentGC was selected as long as it is G1 - so I don't see > why we need to query if the currentGC was selected by ergo ?? Okay :) 'vm.gc' is set by jtreg by parsing VM flags (jtreg is not aware of any VM specific) isSelectedByErgo is an implementation detail hidden from test developer. I used it to avoid parsing VM flags and set vm.gc.X properly. If I develop a test for G1 I'm going to specify -XX:+UseG1GC and I want it has an effect. Previously I used: @requires vm.gc == null | vm.gc == "G1" It protected from cases when jtreg was started with vmoptins:"-XX:+UseSerialGC", but didn't work if G1 wasn't supported: tests started and failed. Now if I need such test I still need to specify -XX:+UseG1GC and to protect it from running in non applicable configurations I use: @requires vm.gc.G1 So, developers should not care about how the current GC was selected. We don't write tests that require a particular GC is by default, so current GC for the VM under test is not exposed in the @requires properties. All GC specific tests set GC explicitly. vm.gc.X is set to false, when it's not possible. Thanks, Dima > > Cheers, > David > >> I know that the current description is hard to understand, but I didn't >> come up with a better wording. >> >>> >>> Anyway for this set of test changes everything seems fine. >> >> Thanks a lot! >> >> -- Dima >> >>> >>> Thanks, >>> David >>> >>> On 23/06/2016 10:52 PM, Dmitry Fazunenko wrote: >>>> David, >>>> >>>> On 23.06.2016 14:00, David Holmes wrote: >>>>> Hi Dmitry, >>>>> >>>>> On 23/06/2016 6:52 PM, Dmitry Fazunenko wrote: >>>>>> Hi David, >>>>>> >>>>>> thanks for looking! >>>>>> >>>>>> On 23.06.2016 3:17, David Holmes wrote: >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> On 23/06/2016 4:06 AM, Dmitry Fazunenko wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> I'm looking for Reviewers for relatively simple fix which >>>>>>>> affects 59 >>>>>>>> tests. >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8160088 >>>>>>>> http://cr.openjdk.java.net/~dfazunen/8160088/webrev.00/ >>>>>>>> >>>>>>>> The fix allows to skip execution of tests requiring a specific >>>>>>>> GC in >>>>>>>> case of the required GC is not supported by VM. >>>>>>>> Old variant: >>>>>>>> @requires vm.gc == null | vm.gc == "G1" >>>>>>>> A test will be executed if no GC is specified externally or >>>>>>>> -XX:+UseG1GC flag is given. >>>>>>>> This test will be executed even if VM doesn't support G1 and >>>>>>>> fail. >>>>>>>> New variant: >>>>>>>> @requires vm.gc.G1 >>>>>>>> This test will not be executed if VM doesn't support G1. >>>>>>> >>>>>>> That doesn't seem sufficient. What you want is that if the test >>>>>>> requires G1 then it also supports G1, so it seems to me the correct >>>>>>> formulation is: >>>>>>> >>>>>>> @requires (vm.gc == null | // null -> default -> g1 (usually) >>>>>>> vm.gc == G1 ) & >>>>>>> vm.gc.G1 >>>>>> >>>>>> No, vm.gc.G1 is an alias to: (vm.gc == null | vm.gc == g1) & >>>>>> vm.gc.supportsG1. >>>>> >>>>> Wow - on the one hand that is a compact/succinct syntax. On the other >>>>> hand - no one will recognize what it actually means! I think I have >>>>> missed a discussed I would like to have given input on! >>>> >>>> It was discussed on hotspot-gc-dev alias as part of '8151283' review: >>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-June/018352.html >>>> >>>> >>>> >>>> Originally it was proposed names like: vm.gc.G1.acceptable >>>> but after input from GC dev, vm.gc.G1 was selected. >>>> Documentation how the properties are set what that mean is >>>> available in >>>> the class source (jtreg plugin): >>>> /test/jtreg-ext/requires/VMProps.java >>>> >>>> >>>>> >>>>>>> >>>>>>> Aside: how does jtreg determine which GC's are supported? >>>>>> Sorry for not providing the full history here: >>>>>> >>>>>> CODETOOLS-7901583: jtreg should provide extensible mechanism for >>>>>> @requires properties >>>>>> - change to jtreg that allows a Test Suite to introduce its own >>>>>> @requires props >>>>>> >>>>>> JDK-8152432: Implement setting jtreg @requires properties vm.flavor, >>>>>> vm.bits, vm.compMode >>>>>> - implementation that mechanism in hotspot >>>>>> >>>>>> JDK-8154096: Extend WhiteBox API with methods which retrieve from VM >>>>>> information about available GC >>>>>> - fix which allows to know if a GC is supported >>>>>> >>>>>> JDK-8151283: Implement setting jtreg @requires property >>>>>> vm.isG1Supported. >>>>>> - introduction vm.gc.G1, vm.gc.Serial, vm.gc.Parallel and >>>>>> vm.gc.ConcMarkSweep >>>>>> >>>>>> JDK-8160088 (this one): update hotspot tests depending on GC to use >>>>>> @requires vm.gc.X >>>>>> - culmination: update tests to use new functionality >>>>> >>>>> Wow I have missed out on a lot it seem! :( >>>>> >>>>> What version of jtreg supports this level of customized @requires? >>>>> Someone has already encountered the following error: >>>>> >>>>> Error. Parse Exception: Syntax error in @requires expression: invalid >>>>> name: XXX >>>>> >>>>> for a new @requires XXX clause. >>>> >>>> It was implemented in the final build of jtreg4.1 and of course it's >>>> available in jtreg4.2 >>>> Quiting jtreg/doc/jtreg/tag-spec.html: >>>> >>>> |requires.extraPropDefns | >>>> >>>> This option is used to provide source files for classes that >>>> will be >>>> used at the beginning of each test suite run, to determine >>>> additional characteristics of the system for use with the >>>> |@requires| tag. Each class must implement >>>> |java.util.concurrent.Callable>|. When >>>> invoked, the |call()| method should return properties that can be >>>> referenced in an expression in a |@requires| tag. /Note:/ the >>>> names >>>> of the new properties that may be returned by calling these >>>> classes >>>> must also be declared in a |requires.properties| entry. >>>> >>>> If this option is specified, the following additional options may >>>> also be specified: >>>> >>>> * |requires.extraPropDefns.libs | ? source >>>> files for >>>> classes that will be put on the classpath when the primary >>>> classes are run. >>>> * |requires.extraPropDefns.bootlibs | ? source >>>> files >>>> for classes that will be put on the bootclasspath when the >>>> primary classes are run. >>>> * |requires.extraPropDefns.javacOpts | ? options that >>>> will be passed to javac when the source files are compiled. >>>> * |requires.extraPropDefns.vmOpts | ? options that will >>>> be passed to VM when the classes are executed. >>>> >>>> In this family of options, if a source file is enclosed in square >>>> brackets, no error message will be given if the file is not >>>> available. >>>> >>>> The following properties may appear in either TEST.ROOT or any >>>> TEST.properties file: >>>> >>>> The reason, why @requires XXX is not recognized by jtreg - XXX is not >>>> registered in TEST.ROOT. >>>> See: hotspot/test/TEST.ROOT for example on how to register new props. >>>> >>>> For the time being recently introduced requires properties are >>>> available >>>> only in the hotspot repository. >>>> To introduce them in jdk - a few lines from hotspot/test/TEST.ROOT >>>> should be placed in jdk/test/TEST.ROOT >>>> We haven't done this yet, because we are considering a possibility to >>>> move VM specific tests from jdk into hotspot repo. >>>> >>>> Thanks, >>>> Dima >>>> >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks, >>>>>> Dima >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Testing: >>>>>>>> 1) starting jtreg with various collectors with "-c" option to >>>>>>>> verify >>>>>>>> correctness of test descriptions. >>>>>>>> Number of selected tests before and after change is the same: >>>>>>>> -XX:+UseG1GC: 1,456 >>>>>>>> -XX:+UseSerialGC: 1,366 >>>>>>>> -XX:+UseParallelGC: 1,369 >>>>>>>> -XX:+UseConcMarkSweepGC: 1,368 >>>>>>>> Default: 1,483; error >>>>>>>> >>>>>>>> 2) RBT (in progress) >>>>>>>> >>>>>>>> 3) Diff is analyzed manually (only necessary lines are affected): >>>>>>>> #> hg diff |grep "^- " |sort -u >>>>>>>> - * @requires (vm.gc == "G1" | vm.gc == "null") >>>>>>>> - * @requires (vm.gc=="G1" | vm.gc=="null") >>>>>>>> - * @requires vm.gc == "G1" | vm.gc == "null" >>>>>>>> - * @requires vm.gc=="ConcMarkSweep" | vm.gc == "null" >>>>>>>> - * @requires vm.gc=="ConcMarkSweep" | vm.gc=="null" >>>>>>>> - * @requires vm.gc=="G1" | vm.gc =="null" >>>>>>>> - * @requires vm.gc=="G1" | vm.gc=="null" >>>>>>>> - * @requires vm.gc=="Parallel" | vm.gc=="null" >>>>>>>> - * @requires vm.gc=="Serial" | vm.gc=="null" >>>>>>>> - * @requires vm.gc=="null" | vm.gc=="G1" >>>>>>>> - * Copyright (c) 2013, 2014, Oracle and/or its affiliates. All >>>>>>>> rights >>>>>>>> reserved. >>>>>>>> - * Copyright (c) 2013, 2015, Oracle and/or its affiliates. All >>>>>>>> rights >>>>>>>> reserved. >>>>>>>> - * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All >>>>>>>> rights >>>>>>>> reserved. >>>>>>>> - * Copyright (c) 2015, Oracle and/or its affiliates. All rights >>>>>>>> reserved. >>>>>>>> #> hg diff |grep "^+ " |sort -u >>>>>>>> + * @requires vm.gc.ConcMarkSweep >>>>>>>> + * @requires vm.gc.G1 >>>>>>>> + * @requires vm.gc.Parallel >>>>>>>> + * @requires vm.gc.Serial >>>>>>>> + * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All >>>>>>>> rights >>>>>>>> reserved. >>>>>>>> + * Copyright (c) 2014, 2016, Oracle and/or its affiliates. All >>>>>>>> rights >>>>>>>> reserved. >>>>>>>> + * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All >>>>>>>> rights >>>>>>>> reserved. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dima >>>>>> >>>> >> From stanislav.lukyanov at oracle.com Fri Jun 24 12:10:33 2016 From: stanislav.lukyanov at oracle.com (stanislav lukyanov) Date: Fri, 24 Jun 2016 15:10:33 +0300 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576C6BCA.6090100@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <576B97FD.1080303@oracle.com> <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> <576BC331.8000400@oracle.com> <32634325-b80f-81fe-674e-74ba5daa41fb@oracle.com> <576BC91D.9050204@oracle.com> <95819fd5-e582-3474-a138-7dd3d8761f5e@oracle.com> <2c0bd870-25a7-7fca-36bc-6386a12902d9@oracle.com> <576C6BCA.6090100@oracle.com> Message-ID: <66d5e398-c221-82a7-2347-823f1f90e9fa@oracle.com> On 24.06.2016 2:07, serguei.spitsyn at oracle.com wrote: > On 6/23/16 15:14, David Holmes wrote: >> On 23/06/2016 11:02 PM, stanislav lukyanov wrote: >>> >>> I think it should be specified that unnamed module will be returned >>> even >>> if there cannot ever be a package >>> with that name. It is not a complicated case to specify, but it brings >>> much more clarity. >>> Formally, now the function is specified to work with "package names" >>> and >>> the behavior on a string that is clearly not a "package name" is >>> unspecified. >> >> I think it is completely specified. Something that can not be a valid >> package name can obviously not have a module associated with it and >> so the unnamed-module is always returned. > > I tend to agree with David here. > It is good that you guys having this discussion here as it is a way to > reach a consensus. > >>> Other APIs that take identifiers like, for example, JNI FindClass or >>> GetMethodID >>> don't specify name checks explicitly, but throw >>> ClassNotFoundError/NoSuchMethodError illegal names. > > The JNI does not do any check for illegal names. > If the name is illegal then the target is not found. > It is why the ClassNotFoundError/NoSuchMethodError is thrown. > It perfectly matches the current GetModuleByPackageName specification > approach. Yes, sure, there are no special checks. What I meant is that the functions do not succeed with illegal names, and because of that don't need such checks, but that's different with the GetModuleByPackageName since it does succeed. >>> It looks like GetModuleByPackageName is the first JNI/JVMTI function to >>> succeed when an ill-formed identifier is passed, >>> so it deserves to be documented. >> >> I disagree with all of that. GetLocalVariableTable, >> ClassFileLoadHook, DynamicCodeGenerated, GetThreadInfo, to name a >> few, all take "names" encoded as UTF-8 modified strings. None of them >> validate that the "name" is legal for the entity being named - JVM TI >> simply does not do that kind of argument validation. > > Right. All these functions don't take the names as input from user. GetLocalVariableTable and GetThreadInfo return the names, not accept them. ClassFileLoadHook and DynamicCodeGenerated are called by JVM, not user. So I see these cases as completely different. >> >> The JNI functions also do not do argument validation. The JNI spec is >> clear "The JNI does not check for programming errors such as passing >> in NULL pointers or illegal argument types". It is up to the >> programmer to ensure they pass valid arguments. FindClass is >> specified to simply throw: >> >> NoClassDefFoundError: if no definition for a requested class or >> interface can be found. >> >> It is the internal VM code, that has to deal with bytecode from >> arbitrary sources, that performs the more detailed checking of the name. > As I've said above, FindClass sure don't specify (and, probably, perform) validation, but it is important that it will always fail with an illegal argument (even if it's with NoClassDefFoundError and not something like IllegalArgumentException) >> >> GetModuleByPackageName is slightly unusual in that it really never >> fails. As I discussed in the CCC review it could have made a >> distinction between packages that would be loaded by the loader and >> packages that would not, and throw an exception (which in turn may >> have been able to discern that the name was invalid). But that is not >> the case - if you don't pass the name of a package that is known to >> the loader then you get back the unnamed-module. It doesn't matter >> whether the package name is legal-but-unknown, or illegal - it is >> just unknown. > > I tend to agree with David here. > But interested to know what objections to this can be. > My concern is that the spec doesn't give straightforward answers to how the function may be called ("Can I pass an arbitrary string, will it just return unnamed module, will I break something?") and, more importantly, implemented ("Can I only care about valid names, can I implement it in a way that doesn't consider illegal characters?"). I feel that could be clarified, but If that's just me still and you still feel that it is clear already then I think it's OK to go with the original version. BTW if the spec doesn't give special treatment to illegal names then the empty string clause should go away - if "otherwise..." clause is good enough to stand for "\t\n!@#$%^&*", it is definitely good enough to stand for "". Thanks, Stas > > Thanks, > Serguei > >> >> David >> ------ >> >>> On CCC update: AFAIU CCC needs to have final version of the proposed >>> specification, so yes, >>> it needs to be updated to with the test that will be actually pushed to >>> the workspace. >>> >>> Thanks, >>> Stas >>> >>> On 23.06.2016 14:40, David Holmes wrote: >>>> >>>> >>>> On 23/06/2016 9:33 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 6/23/16 04:27, David Holmes wrote: >>>>>> On 23/06/2016 9:08 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> On 6/23/16 03:51, David Holmes wrote: >>>>>>>> On 23/06/2016 6:04 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> On 6/23/16 00:51, Alan Bateman wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> : >>>>>>>>>>> >>>>>>>>>>> I agree with it. >>>>>>>>>>> Thank you for pointing to this JVMTI example. >>>>>>>>>>> I did not find in the JNI where the names are checked to be >>>>>>>>>>> legal. >>>>>>>>>>> We are going to open a can of worms with this kind of check as >>>>>>>>>>> there >>>>>>>>>>> can be many corner cases to cover. >>>>>>>>>> The primary use-case for this function is from within the CLFH >>>>>>>>>> callback so have it return the unnamed module when calling with >>>>>>>>>> garage >>>>>>>>>> is probably okay, it just needs to be specified. >>>>>>>>>> >>>>>>>>>> Will you update the webrev to reflect where we've got to this in >>>>>>>>>> this >>>>>>>>>> discussion? >>>>>>>>> >>>>>>>>> I need to undo my fix for additional check. >>>>>>>>> My up-to-date understanding is that we have to explicitly specify >>>>>>>>> two >>>>>>>>> points: >>>>>>>>> - the function returns the unnamed module if the package >>>>>>>>> does not >>>>>>>>> exist >>>>>>>>> - the function does not check the package names for >>>>>>>>> validness and >>>>>>>>> always returns the unnamed module for illegal package names >>>>>>>>> >>>>>>>>> It is better to specify these points explicitly to avoid possible >>>>>>>>> confusion. >>>>>>>> >>>>>>>> I don't agree - nothing else refers to invalid "names" in JVM >>>>>>>> TI. I >>>>>>>> don't see any need to call this out here. If the name supplied >>>>>>>> is not >>>>>>>> a legal package name then it will not match - end of story. >>>>>>> >>>>>>> David, >>>>>>> >>>>>>> It was the original approach that is in the CCC. >>>>>>> You were the one who got confused here, and it convinced me that >>>>>>> this >>>>>>> needs to be more clear. >>>>>>> All these changes are because you started the discussion. :) >>>>>>> It was useful anyway. >>>>>> >>>>>> I never said anything about illegal package names. >>>>> >>>>> True. >>>>> This is my (probably, wrong) attempt to make it more clear. >>>>> >>>>>> >>>>>>> Are you against both clarifications or just the last one? >>>>>>> I'm Ok to return it back as it is in the CCC. >>>>>>> It will save time on the CCC approval. >>>>>>> >>>>>>> This is the last addition to the spec: >>>>>>> >>>>>>> + The unnamed module is returned if the specified package does not >>>>>>> exist. >>>>>> >>>>>> The notion of "package does not exist" is ill-defined. This case is >>>>>> already covered by the primary specification. >>>>>> >>>>>>> + The function does not check if the specified package name is >>>>>>> illegal. >>>>>> >>>>>> This does not need to be stated as it is not stated anywhere else >>>>>> for >>>>>> anything else that may have legal and illegal forms. >>>>> >>>>> Good. >>>>> This is a relevant fragment from current version of CCC: >>>>> >>>>> + >>>>> + Return the java.lang.reflect.Module object >>>>> for a >>>>> module >>>>> + defined to a class loader that contains a given package. >>>>> + The module is returned via module_ptr. >>>>> +

>>>>> + If a named module is defined to the class loader and it >>>>> + contains the package then that named module is returned, >>>>> + otherwise the unnamed module of the class loader is >>>>> returned. >>>>> + If the package name is the empty string then this function >>>>> + always returns the unnamed module for the class loader. >>>>> +

>>>> >>>> As Stanislav said explicitly mentioning the empty string is not really >>>> necessary - but I don't see it as harmful. >>>> >>>>> Does it looks Ok? >>>> >>>> Yes - as good now as it was in the CCC discussion :) >>>> >>>> Cheers, >>>> David >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Cheers, >>>>>>>> David >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Alan >>>>>>>>> >>>>>>> >>>>> >>> > From david.holmes at oracle.com Fri Jun 24 12:53:32 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Jun 2016 22:53:32 +1000 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <66d5e398-c221-82a7-2347-823f1f90e9fa@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <576B97FD.1080303@oracle.com> <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> <576BC331.8000400@oracle.com> <32634325-b80f-81fe-674e-74ba5daa41fb@oracle.com> <576BC91D.9050204@oracle.com> <95819fd5-e582-3474-a138-7dd3d8761f5e@oracle.com> <2c0bd870-25a7-7fca-36bc-6386a12902d9@oracle.com> <576C6BCA.6090100@oracle.com> <66d5e398-c221-82a7-2347-823f1f90e9fa@oracle.com> Message-ID: <549ba7cc-d53a-8782-db6b-054c6252c438@oracle.com> On 24/06/2016 10:10 PM, stanislav lukyanov wrote: > > On 24.06.2016 2:07, serguei.spitsyn at oracle.com wrote: >> On 6/23/16 15:14, David Holmes wrote: >>> On 23/06/2016 11:02 PM, stanislav lukyanov wrote: >>>> >>>> I think it should be specified that unnamed module will be returned >>>> even >>>> if there cannot ever be a package >>>> with that name. It is not a complicated case to specify, but it brings >>>> much more clarity. >>>> Formally, now the function is specified to work with "package names" >>>> and >>>> the behavior on a string that is clearly not a "package name" is >>>> unspecified. >>> >>> I think it is completely specified. Something that can not be a valid >>> package name can obviously not have a module associated with it and >>> so the unnamed-module is always returned. >> >> I tend to agree with David here. >> It is good that you guys having this discussion here as it is a way to >> reach a consensus. >> >>>> Other APIs that take identifiers like, for example, JNI FindClass or >>>> GetMethodID >>>> don't specify name checks explicitly, but throw >>>> ClassNotFoundError/NoSuchMethodError illegal names. >> >> The JNI does not do any check for illegal names. >> If the name is illegal then the target is not found. >> It is why the ClassNotFoundError/NoSuchMethodError is thrown. >> It perfectly matches the current GetModuleByPackageName specification >> approach. > Yes, sure, there are no special checks. > What I meant is that the functions do not succeed with illegal names, > and because of that don't need such checks, but that's different with the > GetModuleByPackageName since it does succeed. It is a matter of perspective. This function simply says "if you give me a package known to this classloader I will give you its module; in all other cases I will give you the unnamed module". >>>> It looks like GetModuleByPackageName is the first JNI/JVMTI function to >>>> succeed when an ill-formed identifier is passed, >>>> so it deserves to be documented. >>> >>> I disagree with all of that. GetLocalVariableTable, >>> ClassFileLoadHook, DynamicCodeGenerated, GetThreadInfo, to name a >>> few, all take "names" encoded as UTF-8 modified strings. None of them >>> validate that the "name" is legal for the entity being named - JVM TI >>> simply does not do that kind of argument validation. >> >> Right. > All these functions don't take the names as input from user. > GetLocalVariableTable and GetThreadInfo return the names, not accept them. > ClassFileLoadHook and DynamicCodeGenerated are called by JVM, not user. > So I see these cases as completely different. Sorry yes you are right these functions fill in structs with the name. I misread that. So there are really no JVM TI functions that take in a name. >>> >>> The JNI functions also do not do argument validation. The JNI spec is >>> clear "The JNI does not check for programming errors such as passing >>> in NULL pointers or illegal argument types". It is up to the >>> programmer to ensure they pass valid arguments. FindClass is >>> specified to simply throw: >>> >>> NoClassDefFoundError: if no definition for a requested class or >>> interface can be found. >>> >>> It is the internal VM code, that has to deal with bytecode from >>> arbitrary sources, that performs the more detailed checking of the name. >> > As I've said above, FindClass sure don't specify (and, probably, > perform) validation, but it is important that it will always fail with > an illegal argument > (even if it's with NoClassDefFoundError and not something like > IllegalArgumentException) Sure but that is just the way it operates. Look at it this way, FindClass could have been specified to operate as follows: - returns the class of the given (valid) name; else - throws NoClassDefFoundError for an unknown (but valid) class; else - throws IllegalArgumentException if the name could not be a class name but it isn't. An invalid name is a class not found - the fact the exception says "by the way that was not a valid class name" is just an incidental effect of the internal implementation. >>> >>> GetModuleByPackageName is slightly unusual in that it really never >>> fails. As I discussed in the CCC review it could have made a >>> distinction between packages that would be loaded by the loader and >>> packages that would not, and throw an exception (which in turn may >>> have been able to discern that the name was invalid). But that is not >>> the case - if you don't pass the name of a package that is known to >>> the loader then you get back the unnamed-module. It doesn't matter >>> whether the package name is legal-but-unknown, or illegal - it is >>> just unknown. >> >> I tend to agree with David here. >> But interested to know what objections to this can be. >> > My concern is that the spec doesn't give straightforward answers > to how the function may be called > ("Can I pass an arbitrary string, will it just return unnamed module, > will I break something?") > and, more importantly, implemented > ("Can I only care about valid names, can I implement it in a way that > doesn't consider illegal characters?"). > I feel that could be clarified, but If that's just me still and you > still feel that > it is clear already then I think it's OK to go with the original version. > > BTW if the spec doesn't give special treatment to illegal names > then the empty string clause should go away - if "otherwise..." clause > is good enough > to stand for "\t\n!@#$%^&*", it is definitely good enough to stand for "". I agree the "" case is already covered. David ----- > Thanks, > Stas >> >> Thanks, >> Serguei >> >>> >>> David >>> ------ >>> >>>> On CCC update: AFAIU CCC needs to have final version of the proposed >>>> specification, so yes, >>>> it needs to be updated to with the test that will be actually pushed to >>>> the workspace. >>>> >>>> Thanks, >>>> Stas >>>> >>>> On 23.06.2016 14:40, David Holmes wrote: >>>>> >>>>> >>>>> On 23/06/2016 9:33 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 6/23/16 04:27, David Holmes wrote: >>>>>>> On 23/06/2016 9:08 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> On 6/23/16 03:51, David Holmes wrote: >>>>>>>>> On 23/06/2016 6:04 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> On 6/23/16 00:51, Alan Bateman wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>> : >>>>>>>>>>>> >>>>>>>>>>>> I agree with it. >>>>>>>>>>>> Thank you for pointing to this JVMTI example. >>>>>>>>>>>> I did not find in the JNI where the names are checked to be >>>>>>>>>>>> legal. >>>>>>>>>>>> We are going to open a can of worms with this kind of check as >>>>>>>>>>>> there >>>>>>>>>>>> can be many corner cases to cover. >>>>>>>>>>> The primary use-case for this function is from within the CLFH >>>>>>>>>>> callback so have it return the unnamed module when calling with >>>>>>>>>>> garage >>>>>>>>>>> is probably okay, it just needs to be specified. >>>>>>>>>>> >>>>>>>>>>> Will you update the webrev to reflect where we've got to this in >>>>>>>>>>> this >>>>>>>>>>> discussion? >>>>>>>>>> >>>>>>>>>> I need to undo my fix for additional check. >>>>>>>>>> My up-to-date understanding is that we have to explicitly specify >>>>>>>>>> two >>>>>>>>>> points: >>>>>>>>>> - the function returns the unnamed module if the package >>>>>>>>>> does not >>>>>>>>>> exist >>>>>>>>>> - the function does not check the package names for >>>>>>>>>> validness and >>>>>>>>>> always returns the unnamed module for illegal package names >>>>>>>>>> >>>>>>>>>> It is better to specify these points explicitly to avoid possible >>>>>>>>>> confusion. >>>>>>>>> >>>>>>>>> I don't agree - nothing else refers to invalid "names" in JVM >>>>>>>>> TI. I >>>>>>>>> don't see any need to call this out here. If the name supplied >>>>>>>>> is not >>>>>>>>> a legal package name then it will not match - end of story. >>>>>>>> >>>>>>>> David, >>>>>>>> >>>>>>>> It was the original approach that is in the CCC. >>>>>>>> You were the one who got confused here, and it convinced me that >>>>>>>> this >>>>>>>> needs to be more clear. >>>>>>>> All these changes are because you started the discussion. :) >>>>>>>> It was useful anyway. >>>>>>> >>>>>>> I never said anything about illegal package names. >>>>>> >>>>>> True. >>>>>> This is my (probably, wrong) attempt to make it more clear. >>>>>> >>>>>>> >>>>>>>> Are you against both clarifications or just the last one? >>>>>>>> I'm Ok to return it back as it is in the CCC. >>>>>>>> It will save time on the CCC approval. >>>>>>>> >>>>>>>> This is the last addition to the spec: >>>>>>>> >>>>>>>> + The unnamed module is returned if the specified package does not >>>>>>>> exist. >>>>>>> >>>>>>> The notion of "package does not exist" is ill-defined. This case is >>>>>>> already covered by the primary specification. >>>>>>> >>>>>>>> + The function does not check if the specified package name is >>>>>>>> illegal. >>>>>>> >>>>>>> This does not need to be stated as it is not stated anywhere else >>>>>>> for >>>>>>> anything else that may have legal and illegal forms. >>>>>> >>>>>> Good. >>>>>> This is a relevant fragment from current version of CCC: >>>>>> >>>>>> + >>>>>> + Return the java.lang.reflect.Module object >>>>>> for a >>>>>> module >>>>>> + defined to a class loader that contains a given package. >>>>>> + The module is returned via module_ptr. >>>>>> +

>>>>>> + If a named module is defined to the class loader and it >>>>>> + contains the package then that named module is returned, >>>>>> + otherwise the unnamed module of the class loader is >>>>>> returned. >>>>>> + If the package name is the empty string then this function >>>>>> + always returns the unnamed module for the class loader. >>>>>> +

>>>>> >>>>> As Stanislav said explicitly mentioning the empty string is not really >>>>> necessary - but I don't see it as harmful. >>>>> >>>>>> Does it looks Ok? >>>>> >>>>> Yes - as good now as it was in the CCC discussion :) >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> David >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -Alan >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> > From serguei.spitsyn at oracle.com Fri Jun 24 13:43:12 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 24 Jun 2016 06:43:12 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <549ba7cc-d53a-8782-db6b-054c6252c438@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <576B97FD.1080303@oracle.com> <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> <576BC331.8000400@oracle.com> <32634325-b80f-81fe-674e-74ba5daa41fb@oracle.com> <576BC91D.9050204@oracle.com> <95819fd5-e582-3474-a138-7dd3d8761f5e@oracle.com> <2c0bd870-25a7-7fca-36bc-6386a12902d9@oracle.com> <576C6BCA.6090100@oracle.com> <66d5e398-c221-82a7-2347-823f1f90e9fa@oracle.com> <549ba7cc-d53a-8782-db6b-054c6252c438@oracle.com> Message-ID: <576D38F0.5060403@oracle.com> Stanislav and David, Thank you for this interesting discussion! It seems, there are good points from both sides. Alan suggested to replace the GetModuleByPackageName with the GetNamedModule. The GetNamedModule should return NULL in all cases where the unnamed module was returned by the GetModuleByPackageName. It looks like this approach simplified the spec and will allow us to reach a consensus. You can find new spec in the updated CCC. I will work on the round #3 webrev and then send it for review. (Sorry that I mentioned CCC in the open but it is very inconvenient to separate it in this email thread) Please, let me know about your concerns. Thanks, Serguei On 6/24/16 05:53, David Holmes wrote: > On 24/06/2016 10:10 PM, stanislav lukyanov wrote: >> >> On 24.06.2016 2:07, serguei.spitsyn at oracle.com wrote: >>> On 6/23/16 15:14, David Holmes wrote: >>>> On 23/06/2016 11:02 PM, stanislav lukyanov wrote: >>>>> >>>>> I think it should be specified that unnamed module will be returned >>>>> even >>>>> if there cannot ever be a package >>>>> with that name. It is not a complicated case to specify, but it >>>>> brings >>>>> much more clarity. >>>>> Formally, now the function is specified to work with "package names" >>>>> and >>>>> the behavior on a string that is clearly not a "package name" is >>>>> unspecified. >>>> >>>> I think it is completely specified. Something that can not be a valid >>>> package name can obviously not have a module associated with it and >>>> so the unnamed-module is always returned. >>> >>> I tend to agree with David here. >>> It is good that you guys having this discussion here as it is a way to >>> reach a consensus. >>> >>>>> Other APIs that take identifiers like, for example, JNI FindClass or >>>>> GetMethodID >>>>> don't specify name checks explicitly, but throw >>>>> ClassNotFoundError/NoSuchMethodError illegal names. >>> >>> The JNI does not do any check for illegal names. >>> If the name is illegal then the target is not found. >>> It is why the ClassNotFoundError/NoSuchMethodError is thrown. >>> It perfectly matches the current GetModuleByPackageName specification >>> approach. >> Yes, sure, there are no special checks. >> What I meant is that the functions do not succeed with illegal names, >> and because of that don't need such checks, but that's different with >> the >> GetModuleByPackageName since it does succeed. > > It is a matter of perspective. This function simply says "if you give > me a package known to this classloader I will give you its module; in > all other cases I will give you the unnamed module". > >>>>> It looks like GetModuleByPackageName is the first JNI/JVMTI >>>>> function to >>>>> succeed when an ill-formed identifier is passed, >>>>> so it deserves to be documented. >>>> >>>> I disagree with all of that. GetLocalVariableTable, >>>> ClassFileLoadHook, DynamicCodeGenerated, GetThreadInfo, to name a >>>> few, all take "names" encoded as UTF-8 modified strings. None of them >>>> validate that the "name" is legal for the entity being named - JVM TI >>>> simply does not do that kind of argument validation. >>> >>> Right. >> All these functions don't take the names as input from user. >> GetLocalVariableTable and GetThreadInfo return the names, not accept >> them. >> ClassFileLoadHook and DynamicCodeGenerated are called by JVM, not user. >> So I see these cases as completely different. > > Sorry yes you are right these functions fill in structs with the name. > I misread that. > > So there are really no JVM TI functions that take in a name. > >>>> >>>> The JNI functions also do not do argument validation. The JNI spec is >>>> clear "The JNI does not check for programming errors such as passing >>>> in NULL pointers or illegal argument types". It is up to the >>>> programmer to ensure they pass valid arguments. FindClass is >>>> specified to simply throw: >>>> >>>> NoClassDefFoundError: if no definition for a requested class or >>>> interface can be found. >>>> >>>> It is the internal VM code, that has to deal with bytecode from >>>> arbitrary sources, that performs the more detailed checking of the >>>> name. >>> >> As I've said above, FindClass sure don't specify (and, probably, >> perform) validation, but it is important that it will always fail with >> an illegal argument >> (even if it's with NoClassDefFoundError and not something like >> IllegalArgumentException) > > Sure but that is just the way it operates. Look at it this way, > FindClass could have been specified to operate as follows: > - returns the class of the given (valid) name; else > - throws NoClassDefFoundError for an unknown (but valid) class; else > - throws IllegalArgumentException if the name could not be a class name > > but it isn't. An invalid name is a class not found - the fact the > exception says "by the way that was not a valid class name" is just an > incidental effect of the internal implementation. > >>>> >>>> GetModuleByPackageName is slightly unusual in that it really never >>>> fails. As I discussed in the CCC review it could have made a >>>> distinction between packages that would be loaded by the loader and >>>> packages that would not, and throw an exception (which in turn may >>>> have been able to discern that the name was invalid). But that is not >>>> the case - if you don't pass the name of a package that is known to >>>> the loader then you get back the unnamed-module. It doesn't matter >>>> whether the package name is legal-but-unknown, or illegal - it is >>>> just unknown. >>> >>> I tend to agree with David here. >>> But interested to know what objections to this can be. >>> >> My concern is that the spec doesn't give straightforward answers >> to how the function may be called >> ("Can I pass an arbitrary string, will it just return unnamed module, >> will I break something?") >> and, more importantly, implemented >> ("Can I only care about valid names, can I implement it in a way that >> doesn't consider illegal characters?"). >> I feel that could be clarified, but If that's just me still and you >> still feel that >> it is clear already then I think it's OK to go with the original >> version. >> >> BTW if the spec doesn't give special treatment to illegal names >> then the empty string clause should go away - if "otherwise..." clause >> is good enough >> to stand for "\t\n!@#$%^&*", it is definitely good enough to stand >> for "". > > I agree the "" case is already covered. > > David > ----- > >> Thanks, >> Stas >>> >>> Thanks, >>> Serguei >>> >>>> >>>> David >>>> ------ >>>> >>>>> On CCC update: AFAIU CCC needs to have final version of the proposed >>>>> specification, so yes, >>>>> it needs to be updated to with the test that will be actually >>>>> pushed to >>>>> the workspace. >>>>> >>>>> Thanks, >>>>> Stas >>>>> >>>>> On 23.06.2016 14:40, David Holmes wrote: >>>>>> >>>>>> >>>>>> On 23/06/2016 9:33 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> On 6/23/16 04:27, David Holmes wrote: >>>>>>>> On 23/06/2016 9:08 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> On 6/23/16 03:51, David Holmes wrote: >>>>>>>>>> On 23/06/2016 6:04 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> On 6/23/16 00:51, Alan Bateman wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>> : >>>>>>>>>>>>> >>>>>>>>>>>>> I agree with it. >>>>>>>>>>>>> Thank you for pointing to this JVMTI example. >>>>>>>>>>>>> I did not find in the JNI where the names are checked to be >>>>>>>>>>>>> legal. >>>>>>>>>>>>> We are going to open a can of worms with this kind of >>>>>>>>>>>>> check as >>>>>>>>>>>>> there >>>>>>>>>>>>> can be many corner cases to cover. >>>>>>>>>>>> The primary use-case for this function is from within the CLFH >>>>>>>>>>>> callback so have it return the unnamed module when calling >>>>>>>>>>>> with >>>>>>>>>>>> garage >>>>>>>>>>>> is probably okay, it just needs to be specified. >>>>>>>>>>>> >>>>>>>>>>>> Will you update the webrev to reflect where we've got to >>>>>>>>>>>> this in >>>>>>>>>>>> this >>>>>>>>>>>> discussion? >>>>>>>>>>> >>>>>>>>>>> I need to undo my fix for additional check. >>>>>>>>>>> My up-to-date understanding is that we have to explicitly >>>>>>>>>>> specify >>>>>>>>>>> two >>>>>>>>>>> points: >>>>>>>>>>> - the function returns the unnamed module if the package >>>>>>>>>>> does not >>>>>>>>>>> exist >>>>>>>>>>> - the function does not check the package names for >>>>>>>>>>> validness and >>>>>>>>>>> always returns the unnamed module for illegal package names >>>>>>>>>>> >>>>>>>>>>> It is better to specify these points explicitly to avoid >>>>>>>>>>> possible >>>>>>>>>>> confusion. >>>>>>>>>> >>>>>>>>>> I don't agree - nothing else refers to invalid "names" in JVM >>>>>>>>>> TI. I >>>>>>>>>> don't see any need to call this out here. If the name supplied >>>>>>>>>> is not >>>>>>>>>> a legal package name then it will not match - end of story. >>>>>>>>> >>>>>>>>> David, >>>>>>>>> >>>>>>>>> It was the original approach that is in the CCC. >>>>>>>>> You were the one who got confused here, and it convinced me that >>>>>>>>> this >>>>>>>>> needs to be more clear. >>>>>>>>> All these changes are because you started the discussion. :) >>>>>>>>> It was useful anyway. >>>>>>>> >>>>>>>> I never said anything about illegal package names. >>>>>>> >>>>>>> True. >>>>>>> This is my (probably, wrong) attempt to make it more clear. >>>>>>> >>>>>>>> >>>>>>>>> Are you against both clarifications or just the last one? >>>>>>>>> I'm Ok to return it back as it is in the CCC. >>>>>>>>> It will save time on the CCC approval. >>>>>>>>> >>>>>>>>> This is the last addition to the spec: >>>>>>>>> >>>>>>>>> + The unnamed module is returned if the specified package does >>>>>>>>> not >>>>>>>>> exist. >>>>>>>> >>>>>>>> The notion of "package does not exist" is ill-defined. This >>>>>>>> case is >>>>>>>> already covered by the primary specification. >>>>>>>> >>>>>>>>> + The function does not check if the specified package name is >>>>>>>>> illegal. >>>>>>>> >>>>>>>> This does not need to be stated as it is not stated anywhere else >>>>>>>> for >>>>>>>> anything else that may have legal and illegal forms. >>>>>>> >>>>>>> Good. >>>>>>> This is a relevant fragment from current version of CCC: >>>>>>> >>>>>>> + >>>>>>> + Return the java.lang.reflect.Module object >>>>>>> for a >>>>>>> module >>>>>>> + defined to a class loader that contains a given package. >>>>>>> + The module is returned via module_ptr. >>>>>>> +

>>>>>>> + If a named module is defined to the class loader and it >>>>>>> + contains the package then that named module is returned, >>>>>>> + otherwise the unnamed module of the class loader is >>>>>>> returned. >>>>>>> + If the package name is the empty string then this function >>>>>>> + always returns the unnamed module for the class loader. >>>>>>> +

>>>>>> >>>>>> As Stanislav said explicitly mentioning the empty string is not >>>>>> really >>>>>> necessary - but I don't see it as harmful. >>>>>> >>>>>>> Does it looks Ok? >>>>>> >>>>>> Yes - as good now as it was in the CCC discussion :) >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -Alan >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >> From michail.chernov at oracle.com Fri Jun 24 15:04:17 2016 From: michail.chernov at oracle.com (Michail Chernov) Date: Fri, 24 Jun 2016 18:04:17 +0300 Subject: RFR: 8160088: update hotspot tests depending on GC to use @requires vm.gc.X In-Reply-To: <5594dba8-f008-2fae-d293-d9a2e3f6913a@oracle.com> References: <5594dba8-f008-2fae-d293-d9a2e3f6913a@oracle.com> Message-ID: <576D4BF1.20407@oracle.com> Hi Dmitry, Thanks a lot for fixing this! Looks good to me. Thanks, Michail On 06/22/2016 09:06 PM, Dmitry Fazunenko wrote: > Hello, > > I'm looking for Reviewers for relatively simple fix which affects 59 > tests. > https://bugs.openjdk.java.net/browse/JDK-8160088 > http://cr.openjdk.java.net/~dfazunen/8160088/webrev.00/ > > The fix allows to skip execution of tests requiring a specific GC in > case of the required GC is not supported by VM. > Old variant: > @requires vm.gc == null | vm.gc == "G1" > A test will be executed if no GC is specified externally or > -XX:+UseG1GC flag is given. > This test will be executed even if VM doesn't support G1 and fail. > New variant: > @requires vm.gc.G1 > This test will not be executed if VM doesn't support G1. > > Testing: > 1) starting jtreg with various collectors with "-c" option to verify > correctness of test descriptions. > Number of selected tests before and after change is the same: > -XX:+UseG1GC: 1,456 > -XX:+UseSerialGC: 1,366 > -XX:+UseParallelGC: 1,369 > -XX:+UseConcMarkSweepGC: 1,368 > Default: 1,483; error > > 2) RBT (in progress) > > 3) Diff is analyzed manually (only necessary lines are affected): > #> hg diff |grep "^- " |sort -u > - * @requires (vm.gc == "G1" | vm.gc == "null") > - * @requires (vm.gc=="G1" | vm.gc=="null") > - * @requires vm.gc == "G1" | vm.gc == "null" > - * @requires vm.gc=="ConcMarkSweep" | vm.gc == "null" > - * @requires vm.gc=="ConcMarkSweep" | vm.gc=="null" > - * @requires vm.gc=="G1" | vm.gc =="null" > - * @requires vm.gc=="G1" | vm.gc=="null" > - * @requires vm.gc=="Parallel" | vm.gc=="null" > - * @requires vm.gc=="Serial" | vm.gc=="null" > - * @requires vm.gc=="null" | vm.gc=="G1" > - * Copyright (c) 2013, 2014, Oracle and/or its affiliates. All rights > reserved. > - * Copyright (c) 2013, 2015, Oracle and/or its affiliates. All rights > reserved. > - * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All rights > reserved. > - * Copyright (c) 2015, Oracle and/or its affiliates. All rights > reserved. > #> hg diff |grep "^+ " |sort -u > + * @requires vm.gc.ConcMarkSweep > + * @requires vm.gc.G1 > + * @requires vm.gc.Parallel > + * @requires vm.gc.Serial > + * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2014, 2016, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights > reserved. > > Thanks, > Dima From michail.chernov at oracle.com Fri Jun 24 15:26:41 2016 From: michail.chernov at oracle.com (Michail Chernov) Date: Fri, 24 Jun 2016 18:26:41 +0300 Subject: RFR: 8160088: update hotspot tests depending on GC to use @requires vm.gc.X In-Reply-To: <576D4BF1.20407@oracle.com> References: <5594dba8-f008-2fae-d293-d9a2e3f6913a@oracle.com> <576D4BF1.20407@oracle.com> Message-ID: <576D5131.2060601@oracle.com> Copyrights for some tests were not updated ( for example - test/runtime/SharedArchiveFile/SharedStringsRunAuto.java) , please update it before pushing. I don`t need additional review for it. Thanks, Michail. On 06/24/2016 06:04 PM, Michail Chernov wrote: > Hi Dmitry, > > Thanks a lot for fixing this! Looks good to me. > > Thanks, > Michail > > > > On 06/22/2016 09:06 PM, Dmitry Fazunenko wrote: >> Hello, >> >> I'm looking for Reviewers for relatively simple fix which affects 59 >> tests. >> https://bugs.openjdk.java.net/browse/JDK-8160088 >> http://cr.openjdk.java.net/~dfazunen/8160088/webrev.00/ >> >> The fix allows to skip execution of tests requiring a specific GC in >> case of the required GC is not supported by VM. >> Old variant: >> @requires vm.gc == null | vm.gc == "G1" >> A test will be executed if no GC is specified externally or >> -XX:+UseG1GC flag is given. >> This test will be executed even if VM doesn't support G1 and fail. >> New variant: >> @requires vm.gc.G1 >> This test will not be executed if VM doesn't support G1. >> >> Testing: >> 1) starting jtreg with various collectors with "-c" option to verify >> correctness of test descriptions. >> Number of selected tests before and after change is the same: >> -XX:+UseG1GC: 1,456 >> -XX:+UseSerialGC: 1,366 >> -XX:+UseParallelGC: 1,369 >> -XX:+UseConcMarkSweepGC: 1,368 >> Default: 1,483; error >> >> 2) RBT (in progress) >> >> 3) Diff is analyzed manually (only necessary lines are affected): >> #> hg diff |grep "^- " |sort -u >> - * @requires (vm.gc == "G1" | vm.gc == "null") >> - * @requires (vm.gc=="G1" | vm.gc=="null") >> - * @requires vm.gc == "G1" | vm.gc == "null" >> - * @requires vm.gc=="ConcMarkSweep" | vm.gc == "null" >> - * @requires vm.gc=="ConcMarkSweep" | vm.gc=="null" >> - * @requires vm.gc=="G1" | vm.gc =="null" >> - * @requires vm.gc=="G1" | vm.gc=="null" >> - * @requires vm.gc=="Parallel" | vm.gc=="null" >> - * @requires vm.gc=="Serial" | vm.gc=="null" >> - * @requires vm.gc=="null" | vm.gc=="G1" >> - * Copyright (c) 2013, 2014, Oracle and/or its affiliates. All >> rights reserved. >> - * Copyright (c) 2013, 2015, Oracle and/or its affiliates. All >> rights reserved. >> - * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All >> rights reserved. >> - * Copyright (c) 2015, Oracle and/or its affiliates. All rights >> reserved. >> #> hg diff |grep "^+ " |sort -u >> + * @requires vm.gc.ConcMarkSweep >> + * @requires vm.gc.G1 >> + * @requires vm.gc.Parallel >> + * @requires vm.gc.Serial >> + * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 2014, 2016, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All >> rights reserved. >> >> Thanks, >> Dima > From igor.ignatyev at oracle.com Fri Jun 24 15:39:12 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 24 Jun 2016 18:39:12 +0300 Subject: RFR: 8160088: update hotspot tests depending on GC to use @requires vm.gc.X In-Reply-To: <5594dba8-f008-2fae-d293-d9a2e3f6913a@oracle.com> References: <5594dba8-f008-2fae-d293-d9a2e3f6913a@oracle.com> Message-ID: <99DEC565-D2E7-4585-94E9-1005E781D3EB@oracle.com> > On Jun 22, 2016, at 9:06 PM, Dmitry Fazunenko wrote: > > Hello, > > I'm looking for Reviewers for relatively simple fix which affects 59 tests. > https://bugs.openjdk.java.net/browse/JDK-8160088 > http://cr.openjdk.java.net/~dfazunen/8160088/webrev.00/ Looks good to me. Thanks, ? Igor From dmitry.fazunenko at oracle.com Fri Jun 24 15:48:36 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Fri, 24 Jun 2016 18:48:36 +0300 Subject: RFR: 8160088: update hotspot tests depending on GC to use @requires vm.gc.X In-Reply-To: <576D5131.2060601@oracle.com> References: <5594dba8-f008-2fae-d293-d9a2e3f6913a@oracle.com> <576D4BF1.20407@oracle.com> <576D5131.2060601@oracle.com> Message-ID: <15862275-8b9d-b0e5-0ab6-736e276a996c@oracle.com> Michail, On 24.06.2016 18:26, Michail Chernov wrote: > Copyrights for some tests were not updated ( for example - > test/runtime/SharedArchiveFile/SharedStringsRunAuto.java) , please > update it before pushing. I don`t need additional review for it. Thanks for catching this. I've checked, this is the only one file which misses copyrights. -- Dima > > Thanks, > Michail. > > On 06/24/2016 06:04 PM, Michail Chernov wrote: >> Hi Dmitry, >> >> Thanks a lot for fixing this! Looks good to me. >> >> Thanks, >> Michail >> >> >> >> On 06/22/2016 09:06 PM, Dmitry Fazunenko wrote: >>> Hello, >>> >>> I'm looking for Reviewers for relatively simple fix which affects 59 >>> tests. >>> https://bugs.openjdk.java.net/browse/JDK-8160088 >>> http://cr.openjdk.java.net/~dfazunen/8160088/webrev.00/ >>> >>> The fix allows to skip execution of tests requiring a specific GC in >>> case of the required GC is not supported by VM. >>> Old variant: >>> @requires vm.gc == null | vm.gc == "G1" >>> A test will be executed if no GC is specified externally or >>> -XX:+UseG1GC flag is given. >>> This test will be executed even if VM doesn't support G1 and fail. >>> New variant: >>> @requires vm.gc.G1 >>> This test will not be executed if VM doesn't support G1. >>> >>> Testing: >>> 1) starting jtreg with various collectors with "-c" option to >>> verify correctness of test descriptions. >>> Number of selected tests before and after change is the same: >>> -XX:+UseG1GC: 1,456 >>> -XX:+UseSerialGC: 1,366 >>> -XX:+UseParallelGC: 1,369 >>> -XX:+UseConcMarkSweepGC: 1,368 >>> Default: 1,483; error >>> >>> 2) RBT (in progress) >>> >>> 3) Diff is analyzed manually (only necessary lines are affected): >>> #> hg diff |grep "^- " |sort -u >>> - * @requires (vm.gc == "G1" | vm.gc == "null") >>> - * @requires (vm.gc=="G1" | vm.gc=="null") >>> - * @requires vm.gc == "G1" | vm.gc == "null" >>> - * @requires vm.gc=="ConcMarkSweep" | vm.gc == "null" >>> - * @requires vm.gc=="ConcMarkSweep" | vm.gc=="null" >>> - * @requires vm.gc=="G1" | vm.gc =="null" >>> - * @requires vm.gc=="G1" | vm.gc=="null" >>> - * @requires vm.gc=="Parallel" | vm.gc=="null" >>> - * @requires vm.gc=="Serial" | vm.gc=="null" >>> - * @requires vm.gc=="null" | vm.gc=="G1" >>> - * Copyright (c) 2013, 2014, Oracle and/or its affiliates. All >>> rights reserved. >>> - * Copyright (c) 2013, 2015, Oracle and/or its affiliates. All >>> rights reserved. >>> - * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All >>> rights reserved. >>> - * Copyright (c) 2015, Oracle and/or its affiliates. All rights >>> reserved. >>> #> hg diff |grep "^+ " |sort -u >>> + * @requires vm.gc.ConcMarkSweep >>> + * @requires vm.gc.G1 >>> + * @requires vm.gc.Parallel >>> + * @requires vm.gc.Serial >>> + * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All >>> rights reserved. >>> + * Copyright (c) 2014, 2016, Oracle and/or its affiliates. All >>> rights reserved. >>> + * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All >>> rights reserved. >>> >>> Thanks, >>> Dima >> > From dmitry.fazunenko at oracle.com Fri Jun 24 15:49:05 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Fri, 24 Jun 2016 18:49:05 +0300 Subject: RFR: 8160088: update hotspot tests depending on GC to use @requires vm.gc.X In-Reply-To: <99DEC565-D2E7-4585-94E9-1005E781D3EB@oracle.com> References: <5594dba8-f008-2fae-d293-d9a2e3f6913a@oracle.com> <99DEC565-D2E7-4585-94E9-1005E781D3EB@oracle.com> Message-ID: Thanks, Igor! -- Dima On 24.06.2016 18:39, Igor Ignatyev wrote: >> On Jun 22, 2016, at 9:06 PM, Dmitry Fazunenko wrote: >> >> Hello, >> >> I'm looking for Reviewers for relatively simple fix which affects 59 tests. >> https://bugs.openjdk.java.net/browse/JDK-8160088 >> http://cr.openjdk.java.net/~dfazunen/8160088/webrev.00/ > Looks good to me. > > Thanks, > ? Igor From lois.foltan at oracle.com Fri Jun 24 17:37:34 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 24 Jun 2016 13:37:34 -0400 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <334bf1c4-8628-b350-a3d2-5ebf717d0538@oracle.com> References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <84b40e40-347d-bb53-7662-9745f894eaa8@oracle.com> <576AC4EC.6070406@oracle.com> <6bdb6f82-517d-e686-4034-dc8f5ae6e9bd@oracle.com> <6e921b20-2fa7-b60d-c310-857180f358dd@oracle.com> <16738fb0-7a98-5a3a-979e-dd162a19541f@oracle.com> <576BE9CB.5080109@oracle.com> <334bf1c4-8628-b350-a3d2-5ebf717d0538@oracle.com> Message-ID: <576D6FDE.3040301@oracle.com> On 6/23/2016 5:02 PM, David Holmes wrote: > On 23/06/2016 11:53 PM, Lois Foltan wrote: >> >> On 6/23/2016 7:37 AM, David Holmes wrote: >>> On 23/06/2016 9:25 PM, Alan Bateman wrote: >>>> >>>> >>>> On 23/06/2016 12:05, David Holmes wrote: >>>>> >>>>> You said: >>>>> >>>>> "Module system initialization will initialize the built-in class >>>>> loaders, including the application class loader. The platform or >>>>> application class loaders won't load any classes in this phase of >>>>> course but they will be initialized (with the modules that they might >>>>> later load classes from). " >>>>> >>>>> What does that last part mean: "with the modules they might later >>>>> load >>>>> classes from"? How have modules become bound to a classloader that >>>>> may >>>>> not even get instantiated? If that class loader is never instantiated >>>>> then why do we need a runtime test that checks for the type of the >>>>> actual system class loader? >>>> The graph of modules that are defined to the runtime during startup >>>> are >>>> we call the "boot layer". They are statically mapped to the built-in >>>> class loaders where built-in means the boot, platform or application >>>> class loaders. There may be a custom system class loader that comes >>>> into >>>> existence later during the startup but it's just not interesting to >>>> the >>>> discussion here (except to know that it might be different to the >>>> application class loader in some niche configuration). >>> >>> But you skipped the key part - why do we care about the built-in >>> loaders. In this code: >>> >>> +// If the module's loader, that a read edge is being established >>> to, is >>> +// not the same loader as this module's and is not one of the 3 >>> builtin >>> +// class loaders, then this module's reads list must be walked at GC >>> +// safepoint. Modules have the same life cycle as their defining class >>> +// loaders and should be removed if dead. >>> +void ModuleEntry::set_read_walk_required(ClassLoaderData* >>> m_loader_data) { >>> + assert_locked_or_safepoint(Module_lock); >>> + if (!_must_walk_reads && >>> + loader_data() != m_loader_data && >>> + !m_loader_data->is_builtin_class_loader_data()) { >>> + _must_walk_reads = true; >>> + if (log_is_enabled(Trace, modules)) { >>> + ResourceMark rm; >>> + log_trace(modules)("ModuleEntry::set_read_walk_required(): >>> module %s reads list must be walked", >>> + (name() != NULL) ? name()->as_C_string() : >>> UNNAMED_MODULE); >>> + } >>> + } >>> +} >>> >>> what is "is_builtin_class_loader_data" really asking? Is it just that >>> this is a loader whose lifetime is matched to that of the VM? If so >>> then it is asking the wrong question with respect to the system >>> loader. If not, then what is it about the built-in system loader type >>> that makes it different to some custom system loader? >> >> Hi David, >> >> The 3 built-in loaders will never be GC'ed, neither will a custom system >> classloader if there is one configured. Thus the JVM can make reliable >> assumptions based on modules defined to those 3 loaders. So if for >> example, a module's reads list only has established read edges to >> modules that are defined to any of the 3 built-in loaders, the JVM can >> rely on the fact that these loaders will never die and thus their >> modules will never die. So at a GC safepoint, that module's reads list >> will not have to be walked looking for dead modules that should be >> removed. > > My apologies to Alan and you as I didn't read this code you > updated properly No worries! > > +bool SystemDictionary::is_system_class_loader(Handle class_loader) { > + if (class_loader.is_null()) { > + return false; > + } > + return (class_loader->klass() == > SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass() > || > + class_loader() == _java_system_loader); > +} > > > > Though I'm still unclear why it needs to have this form rather than > just a check for: > > class_loader() == _java_system_loader > > Even if _java_system_loader may not be initialized if this is called > very early during the init phase (seems unlikely but possible), then > all that will happen is we do an unnecessary walk of the reads list. > That seems better than having to do the klass check each time this is > called. But it is called very and often in module initialization since the module graph (set of root modules and the transitive closure of their dependencies with respect to the set of observable modules), is communicated to the JVM during init phase 2. For example, a simple "java -version" defines several modules, establishes read edges between modules and numerous qualified exports. More specific details can be obtained via -Xlog:modules=debug. Thanks, Lois > > Thanks, > David > >> Lois >> >>> >>> Thanks, >>> David >>> >>> (PS. Really calling it a night now :) ) >>> >>>> -Alan >> From kim.barrett at oracle.com Fri Jun 24 20:09:27 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 24 Jun 2016 16:09:27 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java Message-ID: Please review this change which moves the Reference pending list and locking from the java.lang.ref.Reference class into the VM. This includes elimination of the ReferencePendingListLocker mechanism in the VM. This fixes various fragility issues arising from having the management of this list split between Java and the VM (GC). This change addresses JDK-8156500 by eliminating the possibility of suspension while holding the lock. Because the locking is now done in the VM, we have full control over where suspension may occur. This change retains the existing interface between the reference processor and the nio.Bits package, e.g. Reference.tryHandlePending has the same signature and behavior; this change just pushes the pending list manipulation down into the VM. There are open bugs reports, enhancement requests, and discussions related to that interface; see below. This change does not attempt to address them. This change additionally addresses or renders moot https://bugs.openjdk.java.net/browse/JDK-8055232 (ref) Exceptions while processing Reference pending list and https://bugs.openjdk.java.net/browse/JDK-7103238 Ensure pending list lock is held on behalf of GC before enqueuing references on to the pending list It is also relevant for followup discussion of https://bugs.openjdk.java.net/browse/JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails immediately and https://bugs.openjdk.java.net/browse/JDK-8149925 We don't need jdk.internal.ref.Cleaner any more - part 1 and has implications for: https://bugs.openjdk.java.net/browse/JDK-8066859 java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died In addition to the obviously relevant changes, there are a couple of changes whose presence here might seem surprising and require further explanation. - Removal of a stale comment in create_vm, noticed because it was near some code being removed as part of this change. The comment was rendered obsolete by JDK-8028275. - Moved initialization of exception classes earlier in initialize_java_lang_classes. The previous order only worked by accident, at least for OOME. During the bulk of the library initialization, OOME may be thrown, perhaps due to poorly chosen command line options. That attempts to use one of the pre-allocated OOME objects, and tries to fill in its stack trace. If the Throwable class is not yet initialized, this leads to a failed assert in the VM because Throwable.UNASSIGNED_STACK still has a null value. This initialization order issue was being masked by the old pending list implementation; the initialization of Reference ensured InterruptedException was initialized (thereby initializing its Throwable base class), and the initialization of Reference just happened to occur early enough that Throwable was initialized by the time it was needed when running certain tests. The forced initialization of InterruptedException is no longer needed by Reference, but removal of it triggered test failures (and could trigger corresponding product failures) because of this ordering issue. CR: https://bugs.openjdk.java.net/browse/JDK-8156500 Webrev: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.00/ http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.00/ Testing: RBT ad hoc nightly runtime & gc tests. With the proposed patch for JDK-8153711 applied, locally ran nearly 35K iterations of the OomDebugTest that is part of that patch, with no failures / deadlocks. Without this change it would typically only take on the order of 100 iterations to hit a deadlock failure. Locally ran direct byte buffer allocation test: jdk/test/java/nio/Buffer/DirectBufferAllocTest.java This change reported 3% faster allocation times, and 1/2 the standard deviation for allocation times. Locally ran failing test from JDK-8022321 and JDK-8066859 a few thousand times. jdk/test/java/lang/ref/OOMEInReferenceHandler.java No errors, but failures were noted as hard to reproduce. From david.holmes at oracle.com Fri Jun 24 21:51:47 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 25 Jun 2016 07:51:47 +1000 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <576D6FDE.3040301@oracle.com> References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <84b40e40-347d-bb53-7662-9745f894eaa8@oracle.com> <576AC4EC.6070406@oracle.com> <6bdb6f82-517d-e686-4034-dc8f5ae6e9bd@oracle.com> <6e921b20-2fa7-b60d-c310-857180f358dd@oracle.com> <16738fb0-7a98-5a3a-979e-dd162a19541f@oracle.com> <576BE9CB.5080109@oracle.com> <334bf1c4-8628-b350-a3d2-5ebf717d0538@oracle.com> <576D6FDE.3040301@oracle.com> Message-ID: On 25/06/2016 3:37 AM, Lois Foltan wrote: > > On 6/23/2016 5:02 PM, David Holmes wrote: >> On 23/06/2016 11:53 PM, Lois Foltan wrote: >>> >>> On 6/23/2016 7:37 AM, David Holmes wrote: >>>> On 23/06/2016 9:25 PM, Alan Bateman wrote: >>>>> >>>>> >>>>> On 23/06/2016 12:05, David Holmes wrote: >>>>>> >>>>>> You said: >>>>>> >>>>>> "Module system initialization will initialize the built-in class >>>>>> loaders, including the application class loader. The platform or >>>>>> application class loaders won't load any classes in this phase of >>>>>> course but they will be initialized (with the modules that they might >>>>>> later load classes from). " >>>>>> >>>>>> What does that last part mean: "with the modules they might later >>>>>> load >>>>>> classes from"? How have modules become bound to a classloader that >>>>>> may >>>>>> not even get instantiated? If that class loader is never instantiated >>>>>> then why do we need a runtime test that checks for the type of the >>>>>> actual system class loader? >>>>> The graph of modules that are defined to the runtime during startup >>>>> are >>>>> we call the "boot layer". They are statically mapped to the built-in >>>>> class loaders where built-in means the boot, platform or application >>>>> class loaders. There may be a custom system class loader that comes >>>>> into >>>>> existence later during the startup but it's just not interesting to >>>>> the >>>>> discussion here (except to know that it might be different to the >>>>> application class loader in some niche configuration). >>>> >>>> But you skipped the key part - why do we care about the built-in >>>> loaders. In this code: >>>> >>>> +// If the module's loader, that a read edge is being established >>>> to, is >>>> +// not the same loader as this module's and is not one of the 3 >>>> builtin >>>> +// class loaders, then this module's reads list must be walked at GC >>>> +// safepoint. Modules have the same life cycle as their defining class >>>> +// loaders and should be removed if dead. >>>> +void ModuleEntry::set_read_walk_required(ClassLoaderData* >>>> m_loader_data) { >>>> + assert_locked_or_safepoint(Module_lock); >>>> + if (!_must_walk_reads && >>>> + loader_data() != m_loader_data && >>>> + !m_loader_data->is_builtin_class_loader_data()) { >>>> + _must_walk_reads = true; >>>> + if (log_is_enabled(Trace, modules)) { >>>> + ResourceMark rm; >>>> + log_trace(modules)("ModuleEntry::set_read_walk_required(): >>>> module %s reads list must be walked", >>>> + (name() != NULL) ? name()->as_C_string() : >>>> UNNAMED_MODULE); >>>> + } >>>> + } >>>> +} >>>> >>>> what is "is_builtin_class_loader_data" really asking? Is it just that >>>> this is a loader whose lifetime is matched to that of the VM? If so >>>> then it is asking the wrong question with respect to the system >>>> loader. If not, then what is it about the built-in system loader type >>>> that makes it different to some custom system loader? >>> >>> Hi David, >>> >>> The 3 built-in loaders will never be GC'ed, neither will a custom system >>> classloader if there is one configured. Thus the JVM can make reliable >>> assumptions based on modules defined to those 3 loaders. So if for >>> example, a module's reads list only has established read edges to >>> modules that are defined to any of the 3 built-in loaders, the JVM can >>> rely on the fact that these loaders will never die and thus their >>> modules will never die. So at a GC safepoint, that module's reads list >>> will not have to be walked looking for dead modules that should be >>> removed. >> >> My apologies to Alan and you as I didn't read this code you >> updated properly > > No worries! > >> >> +bool SystemDictionary::is_system_class_loader(Handle class_loader) { >> + if (class_loader.is_null()) { >> + return false; >> + } >> + return (class_loader->klass() == >> SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass() >> || >> + class_loader() == _java_system_loader); >> +} >> >> >> >> Though I'm still unclear why it needs to have this form rather than >> just a check for: >> >> class_loader() == _java_system_loader >> >> Even if _java_system_loader may not be initialized if this is called >> very early during the init phase (seems unlikely but possible), then >> all that will happen is we do an unnecessary walk of the reads list. >> That seems better than having to do the klass check each time this is >> called. > > But it is called very and often in module initialization since the > module graph (set of root modules and the transitive closure of their > dependencies with respect to the set of observable modules), is > communicated to the JVM during init phase 2. For example, a simple > "java -version" defines several modules, establishes read edges between > modules and numerous qualified exports. More specific details can be > obtained via -Xlog:modules=debug. You previously indicated this was needed to avoid walking the read edges during a GC safepoint. There should not be many (if any) GC's during VM initialization. ?? David > > Thanks, > Lois > >> >> Thanks, >> David >> >>> Lois >>> >>>> >>>> Thanks, >>>> David >>>> >>>> (PS. Really calling it a night now :) ) >>>> >>>>> -Alan >>> > From lois.foltan at oracle.com Fri Jun 24 22:04:37 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 24 Jun 2016 18:04:37 -0400 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: References: <57698069.80902@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <84b40e40-347d-bb53-7662-9745f894eaa8@oracle.com> <576AC4EC.6070406@oracle.com> <6bdb6f82-517d-e686-4034-dc8f5ae6e9bd@oracle.com> <6e921b20-2fa7-b60d-c310-857180f358dd@oracle.com> <16738fb0-7a98-5a3a-979e-dd162a19541f@oracle.com> <576BE9CB.5080109@oracle.com> <334bf1c4-8628-b350-a3d2-5ebf717d0538@oracle.com> <576D6FDE.3040301@oracle.com> Message-ID: <576DAE75.30608@oracle.com> On 6/24/2016 5:51 PM, David Holmes wrote: > > > On 25/06/2016 3:37 AM, Lois Foltan wrote: >> >> On 6/23/2016 5:02 PM, David Holmes wrote: >>> On 23/06/2016 11:53 PM, Lois Foltan wrote: >>>> >>>> On 6/23/2016 7:37 AM, David Holmes wrote: >>>>> On 23/06/2016 9:25 PM, Alan Bateman wrote: >>>>>> >>>>>> >>>>>> On 23/06/2016 12:05, David Holmes wrote: >>>>>>> >>>>>>> You said: >>>>>>> >>>>>>> "Module system initialization will initialize the built-in class >>>>>>> loaders, including the application class loader. The platform or >>>>>>> application class loaders won't load any classes in this phase of >>>>>>> course but they will be initialized (with the modules that they >>>>>>> might >>>>>>> later load classes from). " >>>>>>> >>>>>>> What does that last part mean: "with the modules they might later >>>>>>> load >>>>>>> classes from"? How have modules become bound to a classloader that >>>>>>> may >>>>>>> not even get instantiated? If that class loader is never >>>>>>> instantiated >>>>>>> then why do we need a runtime test that checks for the type of the >>>>>>> actual system class loader? >>>>>> The graph of modules that are defined to the runtime during startup >>>>>> are >>>>>> we call the "boot layer". They are statically mapped to the built-in >>>>>> class loaders where built-in means the boot, platform or application >>>>>> class loaders. There may be a custom system class loader that comes >>>>>> into >>>>>> existence later during the startup but it's just not interesting to >>>>>> the >>>>>> discussion here (except to know that it might be different to the >>>>>> application class loader in some niche configuration). >>>>> >>>>> But you skipped the key part - why do we care about the built-in >>>>> loaders. In this code: >>>>> >>>>> +// If the module's loader, that a read edge is being established >>>>> to, is >>>>> +// not the same loader as this module's and is not one of the 3 >>>>> builtin >>>>> +// class loaders, then this module's reads list must be walked at GC >>>>> +// safepoint. Modules have the same life cycle as their defining >>>>> class >>>>> +// loaders and should be removed if dead. >>>>> +void ModuleEntry::set_read_walk_required(ClassLoaderData* >>>>> m_loader_data) { >>>>> + assert_locked_or_safepoint(Module_lock); >>>>> + if (!_must_walk_reads && >>>>> + loader_data() != m_loader_data && >>>>> + !m_loader_data->is_builtin_class_loader_data()) { >>>>> + _must_walk_reads = true; >>>>> + if (log_is_enabled(Trace, modules)) { >>>>> + ResourceMark rm; >>>>> + log_trace(modules)("ModuleEntry::set_read_walk_required(): >>>>> module %s reads list must be walked", >>>>> + (name() != NULL) ? name()->as_C_string() : >>>>> UNNAMED_MODULE); >>>>> + } >>>>> + } >>>>> +} >>>>> >>>>> what is "is_builtin_class_loader_data" really asking? Is it just that >>>>> this is a loader whose lifetime is matched to that of the VM? If so >>>>> then it is asking the wrong question with respect to the system >>>>> loader. If not, then what is it about the built-in system loader type >>>>> that makes it different to some custom system loader? >>>> >>>> Hi David, >>>> >>>> The 3 built-in loaders will never be GC'ed, neither will a custom >>>> system >>>> classloader if there is one configured. Thus the JVM can make >>>> reliable >>>> assumptions based on modules defined to those 3 loaders. So if for >>>> example, a module's reads list only has established read edges to >>>> modules that are defined to any of the 3 built-in loaders, the JVM can >>>> rely on the fact that these loaders will never die and thus their >>>> modules will never die. So at a GC safepoint, that module's reads >>>> list >>>> will not have to be walked looking for dead modules that should be >>>> removed. >>> >>> My apologies to Alan and you as I didn't read this code you >>> updated properly >> >> No worries! >> >>> >>> +bool SystemDictionary::is_system_class_loader(Handle class_loader) { >>> + if (class_loader.is_null()) { >>> + return false; >>> + } >>> + return (class_loader->klass() == >>> SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass() >>> >>> || >>> + class_loader() == _java_system_loader); >>> +} >>> >>> >>> >>> Though I'm still unclear why it needs to have this form rather than >>> just a check for: >>> >>> class_loader() == _java_system_loader >>> >>> Even if _java_system_loader may not be initialized if this is called >>> very early during the init phase (seems unlikely but possible), then >>> all that will happen is we do an unnecessary walk of the reads list. >>> That seems better than having to do the klass check each time this is >>> called. >> >> But it is called very and often in module initialization since the >> module graph (set of root modules and the transitive closure of their >> dependencies with respect to the set of observable modules), is >> communicated to the JVM during init phase 2. For example, a simple >> "java -version" defines several modules, establishes read edges between >> modules and numerous qualified exports. More specific details can be >> obtained via -Xlog:modules=debug. > > You previously indicated this was needed to avoid walking the read > edges during a GC safepoint. There should not be many (if any) GC's > during VM initialization. ?? Correct, there should not be many GC's during VM initialization. However, the module graph is intact for the life of the application in order for the JVM to correctly adhere to the new module rules with regards to type accessibility/access checking. And it can be added to dynamically. So it subject to being walked during any GC post VM initialization. > > David > >> >> Thanks, >> Lois >> >>> >>> Thanks, >>> David >>> >>>> Lois >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> (PS. Really calling it a night now :) ) >>>>> >>>>>> -Alan >>>> >> From vladimir.kozlov at oracle.com Fri Jun 24 22:37:05 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Jun 2016 15:37:05 -0700 Subject: RFD: C2 bug: 8157306 random infrequent null pointer exceptions in javac In-Reply-To: <576C0BD6.4000106@redhat.com> References: <576AD768.3070005@redhat.com> <50693eff-01c3-9791-ca4d-b979ad0deb91@oracle.com> <576C0BD6.4000106@redhat.com> Message-ID: <576DB611.4030408@oracle.com> Looks good. I submitted testing and will push if testing pass. Thanks, Vladimir On 6/23/16 9:18 AM, Andrew Haley wrote: > On 22/06/16 22:13, Vladimir Kozlov wrote: >> Thank you, Andrew, for finding the cause of this problem. >> Your fix looks good to me. Can you also add changes for the assert you mentioned - I think it is useful. >> And, please, prepare webrev. > > http://cr.openjdk.java.net/~aph/8157306.1/ > > There is no point putting an assert in call_catch_cleanup() > immediately after we insert the precedence edges. I think it is best > to put the assert in verify_cfg(), where it makes the most sense. I > had to make verify_anti_dependences() const in order to call it from > verify_cfg(). I hope this is OK. > > Thanks, > > Andrew. > From vladimir.kozlov at oracle.com Sat Jun 25 03:04:45 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Jun 2016 20:04:45 -0700 Subject: RFD: C2 bug: 8157306 random infrequent null pointer exceptions in javac In-Reply-To: <576DB611.4030408@oracle.com> References: <576AD768.3070005@redhat.com> <50693eff-01c3-9791-ca4d-b979ad0deb91@oracle.com> <576C0BD6.4000106@redhat.com> <576DB611.4030408@oracle.com> Message-ID: <576DF4CD.502@oracle.com> The assert you added is "good" :) It found several problems but I am not sure if they are real or we can't call insert_anti_dependences() there. # Internal Error (/opt/jprt/T/P1/223700.vkozlov/s/hotspot/src/share/vm/opto/gcm.cpp:417), pid=5717, tid=5738 # assert(early->dominates(LCA)) failed: early is high enough # Internal Error (/opt/jprt/T/P1/223700.vkozlov/s/hotspot/src/share/vm/opto/gcm.cpp:748), pid=6805, tid=6814 # assert(store->find_edge(load) != -1) failed: missing precedence edge V [libjvm.so+0x6b700c] report_vm_error(char const*, int, char const*, char const*, ...)+0xe0 V [libjvm.so+0x863710] PhaseCFG::insert_anti_dependences(Block*, Node*, bool)+0x1634 V [libjvm.so+0x37e074] PhaseCFG::verify() const+0x424 V [libjvm.so+0x630734] Compile::Code_Gen()+0x2cc V [libjvm.so+0x633ccc] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0xe2c hotspot/test/gc/g1/humongousObjects/TestHumongousClassLoader.java hotspot/test/gc/g1/plab/TestPLABEvacuationFailure.java hotspot/test/runtime/Metaspace/FragmentMetaspace.java and others. May be needed run with -Xcomp to trigger failures. Thanks, Vladimir On 6/24/16 3:37 PM, Vladimir Kozlov wrote: > Looks good. I submitted testing and will push if testing pass. > > Thanks, > Vladimir > > On 6/23/16 9:18 AM, Andrew Haley wrote: >> On 22/06/16 22:13, Vladimir Kozlov wrote: >>> Thank you, Andrew, for finding the cause of this problem. >>> Your fix looks good to me. Can you also add changes for the assert you mentioned - I think it is useful. >>> And, please, prepare webrev. >> >> http://cr.openjdk.java.net/~aph/8157306.1/ >> >> There is no point putting an assert in call_catch_cleanup() >> immediately after we insert the precedence edges. I think it is best >> to put the assert in verify_cfg(), where it makes the most sense. I >> had to make verify_anti_dependences() const in order to call it from >> verify_cfg(). I hope this is OK. >> >> Thanks, >> >> Andrew. >> From david.holmes at oracle.com Sat Jun 25 03:03:07 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 25 Jun 2016 13:03:07 +1000 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <576DAE75.30608@oracle.com> References: <57698069.80902@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <84b40e40-347d-bb53-7662-9745f894eaa8@oracle.com> <576AC4EC.6070406@oracle.com> <6bdb6f82-517d-e686-4034-dc8f5ae6e9bd@oracle.com> <6e921b20-2fa7-b60d-c310-857180f358dd@oracle.com> <16738fb0-7a98-5a3a-979e-dd162a19541f@oracle.com> <576BE9CB.5080109@oracle.com> <334bf1c4-8628-b350-a3d2-5ebf717d0538@oracle.com> <576D6FDE.3040301@oracle.com> <576DAE75.30608@oracle.com> Message-ID: On 25/06/2016 8:04 AM, Lois Foltan wrote: > > On 6/24/2016 5:51 PM, David Holmes wrote: >> >> >> On 25/06/2016 3:37 AM, Lois Foltan wrote: >>> >>> On 6/23/2016 5:02 PM, David Holmes wrote: >>>> On 23/06/2016 11:53 PM, Lois Foltan wrote: >>>>> >>>>> On 6/23/2016 7:37 AM, David Holmes wrote: >>>>>> On 23/06/2016 9:25 PM, Alan Bateman wrote: >>>>>>> >>>>>>> >>>>>>> On 23/06/2016 12:05, David Holmes wrote: >>>>>>>> >>>>>>>> You said: >>>>>>>> >>>>>>>> "Module system initialization will initialize the built-in class >>>>>>>> loaders, including the application class loader. The platform or >>>>>>>> application class loaders won't load any classes in this phase of >>>>>>>> course but they will be initialized (with the modules that they >>>>>>>> might >>>>>>>> later load classes from). " >>>>>>>> >>>>>>>> What does that last part mean: "with the modules they might later >>>>>>>> load >>>>>>>> classes from"? How have modules become bound to a classloader that >>>>>>>> may >>>>>>>> not even get instantiated? If that class loader is never >>>>>>>> instantiated >>>>>>>> then why do we need a runtime test that checks for the type of the >>>>>>>> actual system class loader? >>>>>>> The graph of modules that are defined to the runtime during startup >>>>>>> are >>>>>>> we call the "boot layer". They are statically mapped to the built-in >>>>>>> class loaders where built-in means the boot, platform or application >>>>>>> class loaders. There may be a custom system class loader that comes >>>>>>> into >>>>>>> existence later during the startup but it's just not interesting to >>>>>>> the >>>>>>> discussion here (except to know that it might be different to the >>>>>>> application class loader in some niche configuration). >>>>>> >>>>>> But you skipped the key part - why do we care about the built-in >>>>>> loaders. In this code: >>>>>> >>>>>> +// If the module's loader, that a read edge is being established >>>>>> to, is >>>>>> +// not the same loader as this module's and is not one of the 3 >>>>>> builtin >>>>>> +// class loaders, then this module's reads list must be walked at GC >>>>>> +// safepoint. Modules have the same life cycle as their defining >>>>>> class >>>>>> +// loaders and should be removed if dead. >>>>>> +void ModuleEntry::set_read_walk_required(ClassLoaderData* >>>>>> m_loader_data) { >>>>>> + assert_locked_or_safepoint(Module_lock); >>>>>> + if (!_must_walk_reads && >>>>>> + loader_data() != m_loader_data && >>>>>> + !m_loader_data->is_builtin_class_loader_data()) { >>>>>> + _must_walk_reads = true; >>>>>> + if (log_is_enabled(Trace, modules)) { >>>>>> + ResourceMark rm; >>>>>> + log_trace(modules)("ModuleEntry::set_read_walk_required(): >>>>>> module %s reads list must be walked", >>>>>> + (name() != NULL) ? name()->as_C_string() : >>>>>> UNNAMED_MODULE); >>>>>> + } >>>>>> + } >>>>>> +} >>>>>> >>>>>> what is "is_builtin_class_loader_data" really asking? Is it just that >>>>>> this is a loader whose lifetime is matched to that of the VM? If so >>>>>> then it is asking the wrong question with respect to the system >>>>>> loader. If not, then what is it about the built-in system loader type >>>>>> that makes it different to some custom system loader? >>>>> >>>>> Hi David, >>>>> >>>>> The 3 built-in loaders will never be GC'ed, neither will a custom >>>>> system >>>>> classloader if there is one configured. Thus the JVM can make >>>>> reliable >>>>> assumptions based on modules defined to those 3 loaders. So if for >>>>> example, a module's reads list only has established read edges to >>>>> modules that are defined to any of the 3 built-in loaders, the JVM can >>>>> rely on the fact that these loaders will never die and thus their >>>>> modules will never die. So at a GC safepoint, that module's reads >>>>> list >>>>> will not have to be walked looking for dead modules that should be >>>>> removed. >>>> >>>> My apologies to Alan and you as I didn't read this code you >>>> updated properly >>> >>> No worries! >>> >>>> >>>> +bool SystemDictionary::is_system_class_loader(Handle class_loader) { >>>> + if (class_loader.is_null()) { >>>> + return false; >>>> + } >>>> + return (class_loader->klass() == >>>> SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass() >>>> >>>> || >>>> + class_loader() == _java_system_loader); >>>> +} >>>> >>>> >>>> >>>> Though I'm still unclear why it needs to have this form rather than >>>> just a check for: >>>> >>>> class_loader() == _java_system_loader >>>> >>>> Even if _java_system_loader may not be initialized if this is called >>>> very early during the init phase (seems unlikely but possible), then >>>> all that will happen is we do an unnecessary walk of the reads list. >>>> That seems better than having to do the klass check each time this is >>>> called. >>> >>> But it is called very and often in module initialization since the >>> module graph (set of root modules and the transitive closure of their >>> dependencies with respect to the set of observable modules), is >>> communicated to the JVM during init phase 2. For example, a simple >>> "java -version" defines several modules, establishes read edges between >>> modules and numerous qualified exports. More specific details can be >>> obtained via -Xlog:modules=debug. >> >> You previously indicated this was needed to avoid walking the read >> edges during a GC safepoint. There should not be many (if any) GC's >> during VM initialization. ?? > > Correct, there should not be many GC's during VM initialization. > However, the module graph is intact for the life of the application in > order for the JVM to correctly adhere to the new module rules with > regards to type accessibility/access checking. And it can be added to > dynamically. So it subject to being walked during any GC post VM > initialization. Okay, but that still leaves me wondering why we can't just check: class_loader() == _java_system_loader as the check for: class_loader->klass() == SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass() seems to be an unnecessary optimization only useful during initialization ?? David >> >> David >> >>> >>> Thanks, >>> Lois >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> Lois >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> (PS. Really calling it a night now :) ) >>>>>> >>>>>>> -Alan >>>>> >>> > From aph at redhat.com Sat Jun 25 09:50:44 2016 From: aph at redhat.com (Andrew Haley) Date: Sat, 25 Jun 2016 10:50:44 +0100 Subject: RFD: C2 bug: 8157306 random infrequent null pointer exceptions in javac In-Reply-To: <576DF4CD.502@oracle.com> References: <576AD768.3070005@redhat.com> <50693eff-01c3-9791-ca4d-b979ad0deb91@oracle.com> <576C0BD6.4000106@redhat.com> <576DB611.4030408@oracle.com> <576DF4CD.502@oracle.com> Message-ID: <576E53F4.90508@redhat.com> On 25/06/16 04:04, Vladimir Kozlov wrote: > The assert you added is "good" :) > > It found several problems but I am not sure if they are real or we > can't call insert_anti_dependences() there. I expected as much, It seemed too unlikely that there was only one place anti-dependencies had been forgotten. If you want me to dig into some failures, just ask. Andrew. From lois.foltan at oracle.com Sat Jun 25 09:57:59 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Sat, 25 Jun 2016 05:57:59 -0400 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: References: <57698069.80902@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <84b40e40-347d-bb53-7662-9745f894eaa8@oracle.com> <576AC4EC.6070406@oracle.com> <6bdb6f82-517d-e686-4034-dc8f5ae6e9bd@oracle.com> <6e921b20-2fa7-b60d-c310-857180f358dd@oracle.com> <16738fb0-7a98-5a3a-979e-dd162a19541f@oracle.com> <576BE9CB.5080109@oracle.com> <334bf1c4-8628-b350-a3d2-5ebf717d0538@oracle.com> <576D6FDE.3040301@oracle.com> <576DAE75.30608@oracle.com> Message-ID: <576E55A7.8080008@oracle.com> On 6/24/2016 11:03 PM, David Holmes wrote: > On 25/06/2016 8:04 AM, Lois Foltan wrote: >> >> On 6/24/2016 5:51 PM, David Holmes wrote: >>> >>> >>> On 25/06/2016 3:37 AM, Lois Foltan wrote: >>>> >>>> On 6/23/2016 5:02 PM, David Holmes wrote: >>>>> On 23/06/2016 11:53 PM, Lois Foltan wrote: >>>>>> >>>>>> On 6/23/2016 7:37 AM, David Holmes wrote: >>>>>>> On 23/06/2016 9:25 PM, Alan Bateman wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 23/06/2016 12:05, David Holmes wrote: >>>>>>>>> >>>>>>>>> You said: >>>>>>>>> >>>>>>>>> "Module system initialization will initialize the built-in class >>>>>>>>> loaders, including the application class loader. The platform or >>>>>>>>> application class loaders won't load any classes in this phase of >>>>>>>>> course but they will be initialized (with the modules that they >>>>>>>>> might >>>>>>>>> later load classes from). " >>>>>>>>> >>>>>>>>> What does that last part mean: "with the modules they might later >>>>>>>>> load >>>>>>>>> classes from"? How have modules become bound to a classloader >>>>>>>>> that >>>>>>>>> may >>>>>>>>> not even get instantiated? If that class loader is never >>>>>>>>> instantiated >>>>>>>>> then why do we need a runtime test that checks for the type of >>>>>>>>> the >>>>>>>>> actual system class loader? >>>>>>>> The graph of modules that are defined to the runtime during >>>>>>>> startup >>>>>>>> are >>>>>>>> we call the "boot layer". They are statically mapped to the >>>>>>>> built-in >>>>>>>> class loaders where built-in means the boot, platform or >>>>>>>> application >>>>>>>> class loaders. There may be a custom system class loader that >>>>>>>> comes >>>>>>>> into >>>>>>>> existence later during the startup but it's just not >>>>>>>> interesting to >>>>>>>> the >>>>>>>> discussion here (except to know that it might be different to the >>>>>>>> application class loader in some niche configuration). >>>>>>> >>>>>>> But you skipped the key part - why do we care about the built-in >>>>>>> loaders. In this code: >>>>>>> >>>>>>> +// If the module's loader, that a read edge is being established >>>>>>> to, is >>>>>>> +// not the same loader as this module's and is not one of the 3 >>>>>>> builtin >>>>>>> +// class loaders, then this module's reads list must be walked >>>>>>> at GC >>>>>>> +// safepoint. Modules have the same life cycle as their defining >>>>>>> class >>>>>>> +// loaders and should be removed if dead. >>>>>>> +void ModuleEntry::set_read_walk_required(ClassLoaderData* >>>>>>> m_loader_data) { >>>>>>> + assert_locked_or_safepoint(Module_lock); >>>>>>> + if (!_must_walk_reads && >>>>>>> + loader_data() != m_loader_data && >>>>>>> + !m_loader_data->is_builtin_class_loader_data()) { >>>>>>> + _must_walk_reads = true; >>>>>>> + if (log_is_enabled(Trace, modules)) { >>>>>>> + ResourceMark rm; >>>>>>> + log_trace(modules)("ModuleEntry::set_read_walk_required(): >>>>>>> module %s reads list must be walked", >>>>>>> + (name() != NULL) ? >>>>>>> name()->as_C_string() : >>>>>>> UNNAMED_MODULE); >>>>>>> + } >>>>>>> + } >>>>>>> +} >>>>>>> >>>>>>> what is "is_builtin_class_loader_data" really asking? Is it just >>>>>>> that >>>>>>> this is a loader whose lifetime is matched to that of the VM? If so >>>>>>> then it is asking the wrong question with respect to the system >>>>>>> loader. If not, then what is it about the built-in system loader >>>>>>> type >>>>>>> that makes it different to some custom system loader? >>>>>> >>>>>> Hi David, >>>>>> >>>>>> The 3 built-in loaders will never be GC'ed, neither will a custom >>>>>> system >>>>>> classloader if there is one configured. Thus the JVM can make >>>>>> reliable >>>>>> assumptions based on modules defined to those 3 loaders. So if for >>>>>> example, a module's reads list only has established read edges to >>>>>> modules that are defined to any of the 3 built-in loaders, the >>>>>> JVM can >>>>>> rely on the fact that these loaders will never die and thus their >>>>>> modules will never die. So at a GC safepoint, that module's reads >>>>>> list >>>>>> will not have to be walked looking for dead modules that should be >>>>>> removed. >>>>> >>>>> My apologies to Alan and you as I didn't read this code you >>>>> updated properly >>>> >>>> No worries! >>>> >>>>> >>>>> +bool SystemDictionary::is_system_class_loader(Handle class_loader) { >>>>> + if (class_loader.is_null()) { >>>>> + return false; >>>>> + } >>>>> + return (class_loader->klass() == >>>>> SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass() >>>>> >>>>> >>>>> || >>>>> + class_loader() == _java_system_loader); >>>>> +} >>>>> >>>>> >>>>> >>>>> Though I'm still unclear why it needs to have this form rather than >>>>> just a check for: >>>>> >>>>> class_loader() == _java_system_loader >>>>> >>>>> Even if _java_system_loader may not be initialized if this is called >>>>> very early during the init phase (seems unlikely but possible), then >>>>> all that will happen is we do an unnecessary walk of the reads list. >>>>> That seems better than having to do the klass check each time this is >>>>> called. >>>> >>>> But it is called very and often in module initialization since the >>>> module graph (set of root modules and the transitive closure of their >>>> dependencies with respect to the set of observable modules), is >>>> communicated to the JVM during init phase 2. For example, a simple >>>> "java -version" defines several modules, establishes read edges >>>> between >>>> modules and numerous qualified exports. More specific details can be >>>> obtained via -Xlog:modules=debug. >>> >>> You previously indicated this was needed to avoid walking the read >>> edges during a GC safepoint. There should not be many (if any) GC's >>> during VM initialization. ?? >> >> Correct, there should not be many GC's during VM initialization. >> However, the module graph is intact for the life of the application in >> order for the JVM to correctly adhere to the new module rules with >> regards to type accessibility/access checking. And it can be added to >> dynamically. So it subject to being walked during any GC post VM >> initialization. > > Okay, but that still leaves me wondering why we can't just check: > > class_loader() == _java_system_loader > > as the check for: > > class_loader->klass() == > SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass() > > seems to be an unnecessary optimization only useful during > initialization ?? The modules defined, the read edges and the exported packages established during module system initialization (init phase 2) are the ones who can most benefit by this optimization since they are largely the system modules defined to the 3 builtin loaders! During module system initialization, for example, the module jdk.jconsole is defined to the builtin application class loader and establishes several read edges some of which are the following: [0.332s][debug][modules] add_reads_module(): Adding read from module jdk.jconsole to module java.logging [0.332s][debug][modules] add_reads_module(): Adding read from module jdk.jconsole to module java.datatransfer [0.332s][debug][modules] add_reads_module(): Adding read from module jdk.jconsole to module jdk.attach [0.332s][debug][modules] add_reads_module(): Adding read from module jdk.jconsole to module java.xml [0.332s][debug][modules] add_reads_module(): Adding read from module jdk.jconsole to module java.rmi [0.332s][debug][modules] add_reads_module(): Adding read from module jdk.jconsole to module jdk.jvmstat [0.332s][debug][modules] add_reads_module(): Adding read from module jdk.jconsole to module java.desktop [0.332s][debug][modules] add_reads_module(): Adding read from module jdk.jconsole to module java.base [0.332s][debug][modules] add_reads_module(): Adding read from module jdk.jconsole to module java.management [0.332s][debug][modules] add_reads_module(): Adding read from module jdk.jconsole to module jdk.management All the modules it establishes read edges to are modules that are defined to the 3 builtin loaders. It would be beneficial to never have to walk the jdk.jconsole's ModuleEntry reads list looking for dead modules that should be removed because in most scenarios there aren't going to be any. > > David > >>> >>> David >>> >>>> >>>> Thanks, >>>> Lois >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Lois >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> (PS. Really calling it a night now :) ) >>>>>>> >>>>>>>> -Alan >>>>>> >>>> >> From yasuenag at gmail.com Sat Jun 25 13:57:00 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 25 Jun 2016 22:57:00 +0900 Subject: JDK 9 build with GCC 6.1.1 Message-ID: Hi all, This review request relates to [1]. I've tried to build OpenJDK 9 at Fedora 24 x64. Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. I fixed build error and several issues (VM crash and internal error) as below: http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ Does someone work for it? If no one works for it, I will file it to JBS and will send review request. For jdk repos, I've sent review request [2]. Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html [2] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007081.html From yasuenag at gmail.com Sun Jun 26 15:09:18 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 27 Jun 2016 00:09:18 +0900 Subject: JDK 9 build with GCC 6.1.1 In-Reply-To: References: Message-ID: <29abf149-0dc7-c137-6a57-30fc66ed5906@gmail.com> Hi all, I've uploaded compile error and hs_err reports to Gist. Could you check them? https://gist.github.com/YaSuenag/812ed755117309ceb3e275e7c96dbebd Yasumasa On 2016/06/25 22:57, Yasumasa Suenaga wrote: > Hi all, > > This review request relates to [1]. > > I've tried to build OpenJDK 9 at Fedora 24 x64. > Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. > > I fixed build error and several issues (VM crash and internal error) as below: > > http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ > > Does someone work for it? > If no one works for it, I will file it to JBS and will send review request. > > For jdk repos, I've sent review request [2]. > > > Thanks, > > Yasumasa > > > [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html > [2] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007081.html > From david.holmes at oracle.com Sun Jun 26 23:25:38 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Jun 2016 09:25:38 +1000 Subject: JDK 9 build with GCC 6.1.1 In-Reply-To: <29abf149-0dc7-c137-6a57-30fc66ed5906@gmail.com> References: <29abf149-0dc7-c137-6a57-30fc66ed5906@gmail.com> Message-ID: <9b6ee147-b24a-5f6f-9b1a-e18decb39b15@oracle.com> Hi Yasumasa, Can you just file a bug for this please. It is important to make sure things continue to work with the older official compilers. Not sure how the crash relates to the gcc 6.6.1 compilation issues. Thanks, David On 27/06/2016 1:09 AM, Yasumasa Suenaga wrote: > Hi all, > > I've uploaded compile error and hs_err reports to Gist. > Could you check them? > > https://gist.github.com/YaSuenag/812ed755117309ceb3e275e7c96dbebd > > > Yasumasa > > > On 2016/06/25 22:57, Yasumasa Suenaga wrote: >> Hi all, >> >> This review request relates to [1]. >> >> I've tried to build OpenJDK 9 at Fedora 24 x64. >> Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. >> >> I fixed build error and several issues (VM crash and internal error) >> as below: >> >> http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ >> >> Does someone work for it? >> If no one works for it, I will file it to JBS and will send review >> request. >> >> For jdk repos, I've sent review request [2]. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html >> [2] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007081.html >> From david.holmes at oracle.com Sun Jun 26 23:32:16 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Jun 2016 09:32:16 +1000 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <576E55A7.8080008@oracle.com> References: <57698069.80902@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <84b40e40-347d-bb53-7662-9745f894eaa8@oracle.com> <576AC4EC.6070406@oracle.com> <6bdb6f82-517d-e686-4034-dc8f5ae6e9bd@oracle.com> <6e921b20-2fa7-b60d-c310-857180f358dd@oracle.com> <16738fb0-7a98-5a3a-979e-dd162a19541f@oracle.com> <576BE9CB.5080109@oracle.com> <334bf1c4-8628-b350-a3d2-5ebf717d0538@oracle.com> <576D6FDE.3040301@oracle.com> <576DAE75.30608@oracle.com> <576E55A7.8080008@oracle.com> Message-ID: <12be53ba-c330-2eeb-56de-03f6c9751f29@oracle.com> On 25/06/2016 7:57 PM, Lois Foltan wrote: > > On 6/24/2016 11:03 PM, David Holmes wrote: >> On 25/06/2016 8:04 AM, Lois Foltan wrote: >>> >>> On 6/24/2016 5:51 PM, David Holmes wrote: >>>> >>>> >>>> On 25/06/2016 3:37 AM, Lois Foltan wrote: >>>>> >>>>> On 6/23/2016 5:02 PM, David Holmes wrote: >>>>>> On 23/06/2016 11:53 PM, Lois Foltan wrote: >>>>>>> >>>>>>> On 6/23/2016 7:37 AM, David Holmes wrote: >>>>>>>> On 23/06/2016 9:25 PM, Alan Bateman wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 23/06/2016 12:05, David Holmes wrote: >>>>>>>>>> >>>>>>>>>> You said: >>>>>>>>>> >>>>>>>>>> "Module system initialization will initialize the built-in class >>>>>>>>>> loaders, including the application class loader. The platform or >>>>>>>>>> application class loaders won't load any classes in this phase of >>>>>>>>>> course but they will be initialized (with the modules that they >>>>>>>>>> might >>>>>>>>>> later load classes from). " >>>>>>>>>> >>>>>>>>>> What does that last part mean: "with the modules they might later >>>>>>>>>> load >>>>>>>>>> classes from"? How have modules become bound to a classloader >>>>>>>>>> that >>>>>>>>>> may >>>>>>>>>> not even get instantiated? If that class loader is never >>>>>>>>>> instantiated >>>>>>>>>> then why do we need a runtime test that checks for the type of >>>>>>>>>> the >>>>>>>>>> actual system class loader? >>>>>>>>> The graph of modules that are defined to the runtime during >>>>>>>>> startup >>>>>>>>> are >>>>>>>>> we call the "boot layer". They are statically mapped to the >>>>>>>>> built-in >>>>>>>>> class loaders where built-in means the boot, platform or >>>>>>>>> application >>>>>>>>> class loaders. There may be a custom system class loader that >>>>>>>>> comes >>>>>>>>> into >>>>>>>>> existence later during the startup but it's just not >>>>>>>>> interesting to >>>>>>>>> the >>>>>>>>> discussion here (except to know that it might be different to the >>>>>>>>> application class loader in some niche configuration). >>>>>>>> >>>>>>>> But you skipped the key part - why do we care about the built-in >>>>>>>> loaders. In this code: >>>>>>>> >>>>>>>> +// If the module's loader, that a read edge is being established >>>>>>>> to, is >>>>>>>> +// not the same loader as this module's and is not one of the 3 >>>>>>>> builtin >>>>>>>> +// class loaders, then this module's reads list must be walked >>>>>>>> at GC >>>>>>>> +// safepoint. Modules have the same life cycle as their defining >>>>>>>> class >>>>>>>> +// loaders and should be removed if dead. >>>>>>>> +void ModuleEntry::set_read_walk_required(ClassLoaderData* >>>>>>>> m_loader_data) { >>>>>>>> + assert_locked_or_safepoint(Module_lock); >>>>>>>> + if (!_must_walk_reads && >>>>>>>> + loader_data() != m_loader_data && >>>>>>>> + !m_loader_data->is_builtin_class_loader_data()) { >>>>>>>> + _must_walk_reads = true; >>>>>>>> + if (log_is_enabled(Trace, modules)) { >>>>>>>> + ResourceMark rm; >>>>>>>> + log_trace(modules)("ModuleEntry::set_read_walk_required(): >>>>>>>> module %s reads list must be walked", >>>>>>>> + (name() != NULL) ? >>>>>>>> name()->as_C_string() : >>>>>>>> UNNAMED_MODULE); >>>>>>>> + } >>>>>>>> + } >>>>>>>> +} >>>>>>>> >>>>>>>> what is "is_builtin_class_loader_data" really asking? Is it just >>>>>>>> that >>>>>>>> this is a loader whose lifetime is matched to that of the VM? If so >>>>>>>> then it is asking the wrong question with respect to the system >>>>>>>> loader. If not, then what is it about the built-in system loader >>>>>>>> type >>>>>>>> that makes it different to some custom system loader? >>>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>> The 3 built-in loaders will never be GC'ed, neither will a custom >>>>>>> system >>>>>>> classloader if there is one configured. Thus the JVM can make >>>>>>> reliable >>>>>>> assumptions based on modules defined to those 3 loaders. So if for >>>>>>> example, a module's reads list only has established read edges to >>>>>>> modules that are defined to any of the 3 built-in loaders, the >>>>>>> JVM can >>>>>>> rely on the fact that these loaders will never die and thus their >>>>>>> modules will never die. So at a GC safepoint, that module's reads >>>>>>> list >>>>>>> will not have to be walked looking for dead modules that should be >>>>>>> removed. >>>>>> >>>>>> My apologies to Alan and you as I didn't read this code you >>>>>> updated properly >>>>> >>>>> No worries! >>>>> >>>>>> >>>>>> +bool SystemDictionary::is_system_class_loader(Handle class_loader) { >>>>>> + if (class_loader.is_null()) { >>>>>> + return false; >>>>>> + } >>>>>> + return (class_loader->klass() == >>>>>> SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass() >>>>>> >>>>>> >>>>>> || >>>>>> + class_loader() == _java_system_loader); >>>>>> +} >>>>>> >>>>>> >>>>>> >>>>>> Though I'm still unclear why it needs to have this form rather than >>>>>> just a check for: >>>>>> >>>>>> class_loader() == _java_system_loader >>>>>> >>>>>> Even if _java_system_loader may not be initialized if this is called >>>>>> very early during the init phase (seems unlikely but possible), then >>>>>> all that will happen is we do an unnecessary walk of the reads list. >>>>>> That seems better than having to do the klass check each time this is >>>>>> called. >>>>> >>>>> But it is called very and often in module initialization since the >>>>> module graph (set of root modules and the transitive closure of their >>>>> dependencies with respect to the set of observable modules), is >>>>> communicated to the JVM during init phase 2. For example, a simple >>>>> "java -version" defines several modules, establishes read edges >>>>> between >>>>> modules and numerous qualified exports. More specific details can be >>>>> obtained via -Xlog:modules=debug. >>>> >>>> You previously indicated this was needed to avoid walking the read >>>> edges during a GC safepoint. There should not be many (if any) GC's >>>> during VM initialization. ?? >>> >>> Correct, there should not be many GC's during VM initialization. >>> However, the module graph is intact for the life of the application in >>> order for the JVM to correctly adhere to the new module rules with >>> regards to type accessibility/access checking. And it can be added to >>> dynamically. So it subject to being walked during any GC post VM >>> initialization. >> >> Okay, but that still leaves me wondering why we can't just check: >> >> class_loader() == _java_system_loader >> >> as the check for: >> >> class_loader->klass() == >> SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass() >> >> seems to be an unnecessary optimization only useful during >> initialization ?? > > The modules defined, the read edges and the exported packages > established during module system initialization (init phase 2) are the > ones who can most benefit by this optimization since they are largely > the system modules defined to the 3 builtin loaders! Yes _but_ the optimization is only used if we hit a GC safepoint, which you already agreed was very unlikely during the initialization phase. David ----- During module > system initialization, for example, the module jdk.jconsole is defined > to the builtin application class loader and establishes several read > edges some of which are the following: > > [0.332s][debug][modules] add_reads_module(): Adding read from module > jdk.jconsole to module java.logging > [0.332s][debug][modules] add_reads_module(): Adding read from module > jdk.jconsole to module java.datatransfer > [0.332s][debug][modules] add_reads_module(): Adding read from module > jdk.jconsole to module jdk.attach > [0.332s][debug][modules] add_reads_module(): Adding read from module > jdk.jconsole to module java.xml > [0.332s][debug][modules] add_reads_module(): Adding read from module > jdk.jconsole to module java.rmi > [0.332s][debug][modules] add_reads_module(): Adding read from module > jdk.jconsole to module jdk.jvmstat > [0.332s][debug][modules] add_reads_module(): Adding read from module > jdk.jconsole to module java.desktop > [0.332s][debug][modules] add_reads_module(): Adding read from module > jdk.jconsole to module java.base > [0.332s][debug][modules] add_reads_module(): Adding read from module > jdk.jconsole to module java.management > [0.332s][debug][modules] add_reads_module(): Adding read from module > jdk.jconsole to module jdk.management > > All the modules it establishes read edges to are modules that are > defined to the 3 builtin loaders. It would be beneficial to never have > to walk the jdk.jconsole's ModuleEntry reads list looking for dead > modules that should be removed because in most scenarios there aren't > going to be any. > >> >> David >> >>>> >>>> David >>>> >>>>> >>>>> Thanks, >>>>> Lois >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Lois >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> (PS. Really calling it a night now :) ) >>>>>>>> >>>>>>>>> -Alan >>>>>>> >>>>> >>> > From david.holmes at oracle.com Sun Jun 26 23:50:16 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Jun 2016 09:50:16 +1000 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: Message-ID: <5c124582-a862-892d-d391-7da1299edf66@oracle.com> Hi Kim, On 25/06/2016 6:09 AM, Kim Barrett wrote: > Please review this change which moves the Reference pending list and > locking from the java.lang.ref.Reference class into the VM. This > includes elimination of the ReferencePendingListLocker mechanism in > the VM. This fixes various fragility issues arising from having the > management of this list split between Java and the VM (GC). This seems a particular example of a more general problem. If the target VM can be "suspended" (does that mean it is taken to a safepoint or ???) and an execution request is then sent, there must be numerous potential things that can fail because a "suspended" thread holds a resource needed by the execution request? David ----- > This change addresses JDK-8156500 by eliminating the possibility of > suspension while holding the lock. Because the locking is now done in > the VM, we have full control over where suspension may occur. > > This change retains the existing interface between the reference > processor and the nio.Bits package, e.g. Reference.tryHandlePending > has the same signature and behavior; this change just pushes the > pending list manipulation down into the VM. There are open bugs > reports, enhancement requests, and discussions related to that > interface; see below. This change does not attempt to address them. > > This change additionally addresses or renders moot > https://bugs.openjdk.java.net/browse/JDK-8055232 > (ref) Exceptions while processing Reference pending list > > and > https://bugs.openjdk.java.net/browse/JDK-7103238 > Ensure pending list lock is held on behalf of GC before enqueuing references on to the pending list > > It is also relevant for followup discussion of > https://bugs.openjdk.java.net/browse/JDK-8022321 > java/lang/ref/OOMEInReferenceHandler.java fails immediately > > and > https://bugs.openjdk.java.net/browse/JDK-8149925 > We don't need jdk.internal.ref.Cleaner any more - part 1 > > and has implications for: > https://bugs.openjdk.java.net/browse/JDK-8066859 > java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died > > In addition to the obviously relevant changes, there are a couple of > changes whose presence here might seem surprising and require further > explanation. > > - Removal of a stale comment in create_vm, noticed because it was near > some code being removed as part of this change. The comment was > rendered obsolete by JDK-8028275. > > - Moved initialization of exception classes earlier in > initialize_java_lang_classes. The previous order only worked by > accident, at least for OOME. During the bulk of the library > initialization, OOME may be thrown, perhaps due to poorly chosen > command line options. That attempts to use one of the pre-allocated > OOME objects, and tries to fill in its stack trace. If the Throwable > class is not yet initialized, this leads to a failed assert in the VM > because Throwable.UNASSIGNED_STACK still has a null value. This > initialization order issue was being masked by the old pending list > implementation; the initialization of Reference ensured > InterruptedException was initialized (thereby initializing its > Throwable base class), and the initialization of Reference just > happened to occur early enough that Throwable was initialized by the > time it was needed when running certain tests. The forced > initialization of InterruptedException is no longer needed by > Reference, but removal of it triggered test failures (and could > trigger corresponding product failures) because of this ordering > issue. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8156500 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8156500/jdk.00/ > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.00/ > > Testing: > RBT ad hoc nightly runtime & gc tests. > > With the proposed patch for JDK-8153711 applied, locally ran nearly > 35K iterations of the OomDebugTest that is part of that patch, with no > failures / deadlocks. Without this change it would typically only take > on the order of 100 iterations to hit a deadlock failure. > > Locally ran direct byte buffer allocation test: > jdk/test/java/nio/Buffer/DirectBufferAllocTest.java > This change reported 3% faster allocation times, and 1/2 the standard > deviation for allocation times. > > Locally ran failing test from JDK-8022321 and JDK-8066859 a few > thousand times. > jdk/test/java/lang/ref/OOMEInReferenceHandler.java > No errors, but failures were noted as hard to reproduce. > From david.holmes at oracle.com Mon Jun 27 00:17:51 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Jun 2016 10:17:51 +1000 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: Message-ID: One more follow up before I actually review the code ... On 25/06/2016 6:09 AM, Kim Barrett wrote: > Please review this change which moves the Reference pending list and > locking from the java.lang.ref.Reference class into the VM. This > includes elimination of the ReferencePendingListLocker mechanism in > the VM. This fixes various fragility issues arising from having the > management of this list split between Java and the VM (GC). > > This change addresses JDK-8156500 by eliminating the possibility of > suspension while holding the lock. Because the locking is now done in > the VM, we have full control over where suspension may occur. > > This change retains the existing interface between the reference > processor and the nio.Bits package, e.g. Reference.tryHandlePending > has the same signature and behavior; this change just pushes the > pending list manipulation down into the VM. There are open bugs > reports, enhancement requests, and discussions related to that > interface; see below. This change does not attempt to address them. > > This change additionally addresses or renders moot > https://bugs.openjdk.java.net/browse/JDK-8055232 > (ref) Exceptions while processing Reference pending list > > and > https://bugs.openjdk.java.net/browse/JDK-7103238 > Ensure pending list lock is held on behalf of GC before enqueuing references on to the pending list > > It is also relevant for followup discussion of > https://bugs.openjdk.java.net/browse/JDK-8022321 > java/lang/ref/OOMEInReferenceHandler.java fails immediately > > and > https://bugs.openjdk.java.net/browse/JDK-8149925 > We don't need jdk.internal.ref.Cleaner any more - part 1 > > and has implications for: > https://bugs.openjdk.java.net/browse/JDK-8066859 > java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died > > In addition to the obviously relevant changes, there are a couple of > changes whose presence here might seem surprising and require further > explanation. > > - Removal of a stale comment in create_vm, noticed because it was near > some code being removed as part of this change. The comment was > rendered obsolete by JDK-8028275. > > - Moved initialization of exception classes earlier in > initialize_java_lang_classes. The previous order only worked by > accident, at least for OOME. During the bulk of the library > initialization, OOME may be thrown, perhaps due to poorly chosen > command line options. That attempts to use one of the pre-allocated > OOME objects, and tries to fill in its stack trace. If the Throwable > class is not yet initialized, this leads to a failed assert in the VM > because Throwable.UNASSIGNED_STACK still has a null value. This > initialization order issue was being masked by the old pending list > implementation; the initialization of Reference ensured > InterruptedException was initialized (thereby initializing its > Throwable base class), and the initialization of Reference just > happened to occur early enough that Throwable was initialized by the > time it was needed when running certain tests. The forced > initialization of InterruptedException is no longer needed by > Reference, but removal of it triggered test failures (and could > trigger corresponding product failures) because of this ordering > issue. This is surprising because prior to forcing the load of InterruptedException we did not see any initialization issues with OOME throwing that I am aware of. To me this seems to be a bug in Universe::gen_out_of_memory_error() as it is not checking to see if the necessary classes have been initialized - else it should return a pre-generated OOME with no backtrace. Any change to the VM initialization sequence has to be examined very carefully because there are always non obvious consequences to making changes. David ----- > CR: > https://bugs.openjdk.java.net/browse/JDK-8156500 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8156500/jdk.00/ > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.00/ > > Testing: > RBT ad hoc nightly runtime & gc tests. > > With the proposed patch for JDK-8153711 applied, locally ran nearly > 35K iterations of the OomDebugTest that is part of that patch, with no > failures / deadlocks. Without this change it would typically only take > on the order of 100 iterations to hit a deadlock failure. > > Locally ran direct byte buffer allocation test: > jdk/test/java/nio/Buffer/DirectBufferAllocTest.java > This change reported 3% faster allocation times, and 1/2 the standard > deviation for allocation times. > > Locally ran failing test from JDK-8022321 and JDK-8066859 a few > thousand times. > jdk/test/java/lang/ref/OOMEInReferenceHandler.java > No errors, but failures were noted as hard to reproduce. > From kim.barrett at oracle.com Mon Jun 27 03:40:40 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 26 Jun 2016 23:40:40 -0400 Subject: JDK 9 build with GCC 6.1.1 In-Reply-To: References: Message-ID: <39AC3517-8619-4E92-BB48-BB98ACA71349@oracle.com> > On Jun 25, 2016, at 9:57 AM, Yasumasa Suenaga wrote: > > Hi all, > > This review request relates to [1]. > > I've tried to build OpenJDK 9 at Fedora 24 x64. > Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. > > I fixed build error and several issues (VM crash and internal error) as below: > > http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ I've only done a quick skim of the proposed hotspot changes, not a proper review. Just in general, I'd rather review changes in chunks that were logically related, which many of these aren't. (Needed to build and run with some new compiler doesn't make them related for review purposes.) And please provide some context. Reviewers shouldn't have to guess what problem is being solved by a given change. Some of these still seem mysterious to me, even with the link to build failures and crash dumps. Some specific issues: A couple of these were recently addressed by JDK-8157758. Some of these are C++11 or later changes tripping up a code base written for C++98/03. A few months ago a change was made to explicitly use -std=gnu++98 for exactly this reason (see JDK-8151841), but that seems to have gotten lost in the transition to the new build system (see JDK-8156980). I would prefer that got fixed and these kinds of issues be deferred to a future modernization project, where some of them might involve something more principled than adding some workaround casts, for example. (We've been doing string/identifier whitespace separation for a while, though; I'd be fine with those, other than being post-FC.) Some of these appear to be just plain bug fixes, and I wonder why the code is working now? For example, the change at src/share/vm/classfile/classLoaderData.cpp:145 seems suspicious. Some of these are just cleanups, like src/share/vm/oops/oop.inline.hpp:542, but it's post-FC. > Does someone work for it? > If no one works for it, I will file it to JBS and will send review request. Certainly there should be CRs filed for these; the enhancements so they don't get lost, and the crashes because they probably indicate real bugs. > For jdk repos, I've sent review request [2]. > > > Thanks, > > Yasumasa > > > [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html > [2] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007081.html From yasuenag at gmail.com Mon Jun 27 03:57:25 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 27 Jun 2016 12:57:25 +0900 Subject: JDK-8160310: HotSpot cannot be built with GCC 6 In-Reply-To: <39AC3517-8619-4E92-BB48-BB98ACA71349@oracle.com> References: <39AC3517-8619-4E92-BB48-BB98ACA71349@oracle.com> Message-ID: <43d7a53e-ec53-f940-8e99-be1874fbc3d7@gmail.com> Hi David, Kim, I've filed this as JDK-8160310, and uploaded new webrev for discussion. (Not review request) http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot.01/ > Some of these appear to be just plain bug fixes, and I wonder why the > code is working now? For example, the change at > src/share/vm/classfile/classLoaderData.cpp:145 seems suspicious. I analyzed this crash with GDB, and this fix works fine. Please see hs_err log on JIRA. > Some of these are just cleanups, like > src/share/vm/oops/oop.inline.hpp:542, but it's post-FC. I understood. But I do not understand well why this cheange works fine. So I want to discuss about it. (I uploaded hs_err log to JIRA.) Thanks, Yasumasa On 2016/06/27 12:40, Kim Barrett wrote: >> On Jun 25, 2016, at 9:57 AM, Yasumasa Suenaga wrote: >> >> Hi all, >> >> This review request relates to [1]. >> >> I've tried to build OpenJDK 9 at Fedora 24 x64. >> Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. >> >> I fixed build error and several issues (VM crash and internal error) as below: >> >> http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ > > I've only done a quick skim of the proposed hotspot changes, not a > proper review. Just in general, I'd rather review changes in chunks > that were logically related, which many of these aren't. (Needed to > build and run with some new compiler doesn't make them related for > review purposes.) And please provide some context. Reviewers > shouldn't have to guess what problem is being solved by a given > change. Some of these still seem mysterious to me, even with the link > to build failures and crash dumps. > > Some specific issues: > > A couple of these were recently addressed by JDK-8157758. > > Some of these are C++11 or later changes tripping up a code base > written for C++98/03. A few months ago a change was made to > explicitly use -std=gnu++98 for exactly this reason (see JDK-8151841), > but that seems to have gotten lost in the transition to the new build > system (see JDK-8156980). I would prefer that got fixed and these > kinds of issues be deferred to a future modernization project, where > some of them might involve something more principled than adding some > workaround casts, for example. (We've been doing string/identifier > whitespace separation for a while, though; I'd be fine with those, > other than being post-FC.) > > Some of these appear to be just plain bug fixes, and I wonder why the > code is working now? For example, the change at > src/share/vm/classfile/classLoaderData.cpp:145 seems suspicious. > > Some of these are just cleanups, like > src/share/vm/oops/oop.inline.hpp:542, but it's post-FC. > >> Does someone work for it? >> If no one works for it, I will file it to JBS and will send review request. > > Certainly there should be CRs filed for these; the enhancements so > they don't get lost, and the crashes because they probably indicate > real bugs. > >> For jdk repos, I've sent review request [2]. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html >> [2] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007081.html > > From david.holmes at oracle.com Mon Jun 27 04:08:56 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Jun 2016 14:08:56 +1000 Subject: JDK-8160310: HotSpot cannot be built with GCC 6 In-Reply-To: <43d7a53e-ec53-f940-8e99-be1874fbc3d7@gmail.com> References: <39AC3517-8619-4E92-BB48-BB98ACA71349@oracle.com> <43d7a53e-ec53-f940-8e99-be1874fbc3d7@gmail.com> Message-ID: <929cfe33-d9de-cc0b-3090-e896dc59efbf@oracle.com> On 27/06/2016 1:57 PM, Yasumasa Suenaga wrote: > Hi David, Kim, > > I've filed this as JDK-8160310, and uploaded new webrev for discussion. > (Not review request) > > http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot.01/ > > >> Some of these appear to be just plain bug fixes, and I wonder why the >> code is working now? For example, the change at >> src/share/vm/classfile/classLoaderData.cpp:145 seems suspicious. > > I analyzed this crash with GDB, and this fix works fine. Yes but it has nothing to do with gcc 6. AFAICS a very early GC during module initialization would trigger this bug. I'd be very surprised if any of the crashes are directly attributable to using gcc 6. But these need to be broken up into individual problems. I don't mind if the actual compilation warnings/errors are handled as a group. Thanks, David ----- > Please see hs_err log on JIRA. > > >> Some of these are just cleanups, like >> src/share/vm/oops/oop.inline.hpp:542, but it's post-FC. > > I understood. > But I do not understand well why this cheange works fine. > So I want to discuss about it. > (I uploaded hs_err log to JIRA.) > > > Thanks, > > Yasumasa > > > On 2016/06/27 12:40, Kim Barrett wrote: >>> On Jun 25, 2016, at 9:57 AM, Yasumasa Suenaga >>> wrote: >>> >>> Hi all, >>> >>> This review request relates to [1]. >>> >>> I've tried to build OpenJDK 9 at Fedora 24 x64. >>> Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. >>> >>> I fixed build error and several issues (VM crash and internal error) >>> as below: >>> >>> http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ >> >> I've only done a quick skim of the proposed hotspot changes, not a >> proper review. Just in general, I'd rather review changes in chunks >> that were logically related, which many of these aren't. (Needed to >> build and run with some new compiler doesn't make them related for >> review purposes.) And please provide some context. Reviewers >> shouldn't have to guess what problem is being solved by a given >> change. Some of these still seem mysterious to me, even with the link >> to build failures and crash dumps. >> >> Some specific issues: >> >> A couple of these were recently addressed by JDK-8157758. >> >> Some of these are C++11 or later changes tripping up a code base >> written for C++98/03. A few months ago a change was made to >> explicitly use -std=gnu++98 for exactly this reason (see JDK-8151841), >> but that seems to have gotten lost in the transition to the new build >> system (see JDK-8156980). I would prefer that got fixed and these >> kinds of issues be deferred to a future modernization project, where >> some of them might involve something more principled than adding some >> workaround casts, for example. (We've been doing string/identifier >> whitespace separation for a while, though; I'd be fine with those, >> other than being post-FC.) >> >> Some of these appear to be just plain bug fixes, and I wonder why the >> code is working now? For example, the change at >> src/share/vm/classfile/classLoaderData.cpp:145 seems suspicious. >> >> Some of these are just cleanups, like >> src/share/vm/oops/oop.inline.hpp:542, but it's post-FC. >> >>> Does someone work for it? >>> If no one works for it, I will file it to JBS and will send review >>> request. >> >> Certainly there should be CRs filed for these; the enhancements so >> they don't get lost, and the crashes because they probably indicate >> real bugs. >> >>> For jdk repos, I've sent review request [2]. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html >>> [2] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007081.html >> >> From david.holmes at oracle.com Mon Jun 27 04:31:14 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Jun 2016 14:31:14 +1000 Subject: JDK-8160310: HotSpot cannot be built with GCC 6 In-Reply-To: <929cfe33-d9de-cc0b-3090-e896dc59efbf@oracle.com> References: <39AC3517-8619-4E92-BB48-BB98ACA71349@oracle.com> <43d7a53e-ec53-f940-8e99-be1874fbc3d7@gmail.com> <929cfe33-d9de-cc0b-3090-e896dc59efbf@oracle.com> Message-ID: <10a8bea0-5be5-f06f-fbc6-89d73c1ff490@oracle.com> On 27/06/2016 2:08 PM, David Holmes wrote: > On 27/06/2016 1:57 PM, Yasumasa Suenaga wrote: >> Hi David, Kim, >> >> I've filed this as JDK-8160310, and uploaded new webrev for discussion. >> (Not review request) >> >> http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot.01/ >> >> >>> Some of these appear to be just plain bug fixes, and I wonder why the >>> code is working now? For example, the change at >>> src/share/vm/classfile/classLoaderData.cpp:145 seems suspicious. >> >> I analyzed this crash with GDB, and this fix works fine. > > Yes but it has nothing to do with gcc 6. AFAICS a very early GC during > module initialization would trigger this bug. > > I'd be very surprised if any of the crashes are directly attributable to > using gcc 6. But these need to be broken up into individual problems. I > don't mind if the actual compilation warnings/errors are handled as a > group. Actually I take that last part back. I think this can be grouped in a clearer way eg the missing spaces around "PTR_FORMAT" (how did they creep back in??). And some of the changes have me puzzled over original intentions ie src/share/vm/c1/c1_Instruction.hpp. And some just have me puzzled eg src/share/vm/code/relocInfo.hpp. That said making this work with gcc 6 now is not really a high priority. I, for one, have more pressing concerns to deal with. David ----- > Thanks, > David > ----- > >> Please see hs_err log on JIRA. >> >> >>> Some of these are just cleanups, like >>> src/share/vm/oops/oop.inline.hpp:542, but it's post-FC. >> >> I understood. >> But I do not understand well why this cheange works fine. >> So I want to discuss about it. >> (I uploaded hs_err log to JIRA.) >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/06/27 12:40, Kim Barrett wrote: >>>> On Jun 25, 2016, at 9:57 AM, Yasumasa Suenaga >>>> wrote: >>>> >>>> Hi all, >>>> >>>> This review request relates to [1]. >>>> >>>> I've tried to build OpenJDK 9 at Fedora 24 x64. >>>> Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. >>>> >>>> I fixed build error and several issues (VM crash and internal error) >>>> as below: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ >>> >>> I've only done a quick skim of the proposed hotspot changes, not a >>> proper review. Just in general, I'd rather review changes in chunks >>> that were logically related, which many of these aren't. (Needed to >>> build and run with some new compiler doesn't make them related for >>> review purposes.) And please provide some context. Reviewers >>> shouldn't have to guess what problem is being solved by a given >>> change. Some of these still seem mysterious to me, even with the link >>> to build failures and crash dumps. >>> >>> Some specific issues: >>> >>> A couple of these were recently addressed by JDK-8157758. >>> >>> Some of these are C++11 or later changes tripping up a code base >>> written for C++98/03. A few months ago a change was made to >>> explicitly use -std=gnu++98 for exactly this reason (see JDK-8151841), >>> but that seems to have gotten lost in the transition to the new build >>> system (see JDK-8156980). I would prefer that got fixed and these >>> kinds of issues be deferred to a future modernization project, where >>> some of them might involve something more principled than adding some >>> workaround casts, for example. (We've been doing string/identifier >>> whitespace separation for a while, though; I'd be fine with those, >>> other than being post-FC.) >>> >>> Some of these appear to be just plain bug fixes, and I wonder why the >>> code is working now? For example, the change at >>> src/share/vm/classfile/classLoaderData.cpp:145 seems suspicious. >>> >>> Some of these are just cleanups, like >>> src/share/vm/oops/oop.inline.hpp:542, but it's post-FC. >>> >>>> Does someone work for it? >>>> If no one works for it, I will file it to JBS and will send review >>>> request. >>> >>> Certainly there should be CRs filed for these; the enhancements so >>> they don't get lost, and the crashes because they probably indicate >>> real bugs. >>> >>>> For jdk repos, I've sent review request [2]. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html >>>> [2] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007081.html >>> >>> From aph at redhat.com Mon Jun 27 07:40:56 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 27 Jun 2016 08:40:56 +0100 Subject: JDK 9 build with GCC 6.1.1 In-Reply-To: <9b6ee147-b24a-5f6f-9b1a-e18decb39b15@oracle.com> References: <29abf149-0dc7-c137-6a57-30fc66ed5906@gmail.com> <9b6ee147-b24a-5f6f-9b1a-e18decb39b15@oracle.com> Message-ID: <5770D888.6080501@redhat.com> On 27/06/16 00:25, David Holmes wrote: > Not sure how the crash relates to the gcc 6.6.1 compilation issues. Maybe it's related to -fno-delete-null-pointer-checks and HotSpot's habit of dereferencing null pointers. I made a start on some of these issues but ran out of time and enthusiasm. It'd be great to have a campaign to get rid of HotSpot's undefined behaviour. Andrew. From yasuenag at gmail.com Mon Jun 27 10:25:06 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 27 Jun 2016 19:25:06 +0900 Subject: JDK-8160310: HotSpot cannot be built with GCC 6 In-Reply-To: <929cfe33-d9de-cc0b-3090-e896dc59efbf@oracle.com> References: <39AC3517-8619-4E92-BB48-BB98ACA71349@oracle.com> <43d7a53e-ec53-f940-8e99-be1874fbc3d7@gmail.com> <929cfe33-d9de-cc0b-3090-e896dc59efbf@oracle.com> Message-ID: <4ba4ad31-9abe-ef39-18e0-3288ef1008d5@gmail.com> > But these need to be broken up into individual problems. I don't mind if the actual compilation warnings/errors are handled as a group. I think we can create several subtasks for this as below: Group 1: narrowing conversion - altHashing.cpp - os_linux.cpp - type.cpp Group 2: uninitialized value (including assertion failure) - assembler_x86.cpp - interp_masm_x86.cpp - relocInfo.hpp - c1_Instruction.hpp Group 3: invalid suffix on literal - moduleEntry.cpp - packageEntry.cpp - preservedMarks.cpp Group 4: unnescessary assertion - node.cpp Group 5: potential for SEGV - classLoaderData.cpp Group 6: refactoring for GCC 6 - oop.inline.hpp Is it okay? If so, I will create them as subtask of JDK-8160310 and send review request if possible. Thanks, Yasumasa On 2016/06/27 13:08, David Holmes wrote: > On 27/06/2016 1:57 PM, Yasumasa Suenaga wrote: >> Hi David, Kim, >> >> I've filed this as JDK-8160310, and uploaded new webrev for discussion. >> (Not review request) >> >> http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot.01/ >> >> >>> Some of these appear to be just plain bug fixes, and I wonder why the >>> code is working now? For example, the change at >>> src/share/vm/classfile/classLoaderData.cpp:145 seems suspicious. >> >> I analyzed this crash with GDB, and this fix works fine. > > Yes but it has nothing to do with gcc 6. AFAICS a very early GC during module initialization would trigger this bug. > > I'd be very surprised if any of the crashes are directly attributable to using gcc 6. But these need to be broken up into individual problems. I don't mind if the actual compilation warnings/errors are handled as a group. > > Thanks, > David > ----- > >> Please see hs_err log on JIRA. >> >> >>> Some of these are just cleanups, like >>> src/share/vm/oops/oop.inline.hpp:542, but it's post-FC. >> >> I understood. >> But I do not understand well why this cheange works fine. >> So I want to discuss about it. >> (I uploaded hs_err log to JIRA.) >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/06/27 12:40, Kim Barrett wrote: >>>> On Jun 25, 2016, at 9:57 AM, Yasumasa Suenaga >>>> wrote: >>>> >>>> Hi all, >>>> >>>> This review request relates to [1]. >>>> >>>> I've tried to build OpenJDK 9 at Fedora 24 x64. >>>> Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. >>>> >>>> I fixed build error and several issues (VM crash and internal error) >>>> as below: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ >>> >>> I've only done a quick skim of the proposed hotspot changes, not a >>> proper review. Just in general, I'd rather review changes in chunks >>> that were logically related, which many of these aren't. (Needed to >>> build and run with some new compiler doesn't make them related for >>> review purposes.) And please provide some context. Reviewers >>> shouldn't have to guess what problem is being solved by a given >>> change. Some of these still seem mysterious to me, even with the link >>> to build failures and crash dumps. >>> >>> Some specific issues: >>> >>> A couple of these were recently addressed by JDK-8157758. >>> >>> Some of these are C++11 or later changes tripping up a code base >>> written for C++98/03. A few months ago a change was made to >>> explicitly use -std=gnu++98 for exactly this reason (see JDK-8151841), >>> but that seems to have gotten lost in the transition to the new build >>> system (see JDK-8156980). I would prefer that got fixed and these >>> kinds of issues be deferred to a future modernization project, where >>> some of them might involve something more principled than adding some >>> workaround casts, for example. (We've been doing string/identifier >>> whitespace separation for a while, though; I'd be fine with those, >>> other than being post-FC.) >>> >>> Some of these appear to be just plain bug fixes, and I wonder why the >>> code is working now? For example, the change at >>> src/share/vm/classfile/classLoaderData.cpp:145 seems suspicious. >>> >>> Some of these are just cleanups, like >>> src/share/vm/oops/oop.inline.hpp:542, but it's post-FC. >>> >>>> Does someone work for it? >>>> If no one works for it, I will file it to JBS and will send review >>>> request. >>> >>> Certainly there should be CRs filed for these; the enhancements so >>> they don't get lost, and the crashes because they probably indicate >>> real bugs. >>> >>>> For jdk repos, I've sent review request [2]. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html >>>> [2] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007081.html >>> >>> From lois.foltan at oracle.com Mon Jun 27 11:03:37 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 27 Jun 2016 07:03:37 -0400 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <12be53ba-c330-2eeb-56de-03f6c9751f29@oracle.com> References: <57698069.80902@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <84b40e40-347d-bb53-7662-9745f894eaa8@oracle.com> <576AC4EC.6070406@oracle.com> <6bdb6f82-517d-e686-4034-dc8f5ae6e9bd@oracle.com> <6e921b20-2fa7-b60d-c310-857180f358dd@oracle.com> <16738fb0-7a98-5a3a-979e-dd162a19541f@oracle.com> <576BE9CB.5080109@oracle.com> <334bf1c4-8628-b350-a3d2-5ebf717d0538@oracle.com> <576D6FDE.3040301@oracle.com> <576DAE75.30608@oracle.com> <576E55A7.8080008@oracle.com> <12be53ba-c330-2eeb-56de-03f6c9751f29@ora! cle.com> Message-ID: <57710809.4060906@oracle.com> On 6/26/2016 7:32 PM, David Holmes wrote: > On 25/06/2016 7:57 PM, Lois Foltan wrote: >> >> On 6/24/2016 11:03 PM, David Holmes wrote: >>> On 25/06/2016 8:04 AM, Lois Foltan wrote: >>>> >>>> On 6/24/2016 5:51 PM, David Holmes wrote: >>>>> >>>>> >>>>> On 25/06/2016 3:37 AM, Lois Foltan wrote: >>>>>> >>>>>> On 6/23/2016 5:02 PM, David Holmes wrote: >>>>>>> On 23/06/2016 11:53 PM, Lois Foltan wrote: >>>>>>>> >>>>>>>> On 6/23/2016 7:37 AM, David Holmes wrote: >>>>>>>>> On 23/06/2016 9:25 PM, Alan Bateman wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 23/06/2016 12:05, David Holmes wrote: >>>>>>>>>>> >>>>>>>>>>> You said: >>>>>>>>>>> >>>>>>>>>>> "Module system initialization will initialize the built-in >>>>>>>>>>> class >>>>>>>>>>> loaders, including the application class loader. The >>>>>>>>>>> platform or >>>>>>>>>>> application class loaders won't load any classes in this >>>>>>>>>>> phase of >>>>>>>>>>> course but they will be initialized (with the modules that they >>>>>>>>>>> might >>>>>>>>>>> later load classes from). " >>>>>>>>>>> >>>>>>>>>>> What does that last part mean: "with the modules they might >>>>>>>>>>> later >>>>>>>>>>> load >>>>>>>>>>> classes from"? How have modules become bound to a classloader >>>>>>>>>>> that >>>>>>>>>>> may >>>>>>>>>>> not even get instantiated? If that class loader is never >>>>>>>>>>> instantiated >>>>>>>>>>> then why do we need a runtime test that checks for the type of >>>>>>>>>>> the >>>>>>>>>>> actual system class loader? >>>>>>>>>> The graph of modules that are defined to the runtime during >>>>>>>>>> startup >>>>>>>>>> are >>>>>>>>>> we call the "boot layer". They are statically mapped to the >>>>>>>>>> built-in >>>>>>>>>> class loaders where built-in means the boot, platform or >>>>>>>>>> application >>>>>>>>>> class loaders. There may be a custom system class loader that >>>>>>>>>> comes >>>>>>>>>> into >>>>>>>>>> existence later during the startup but it's just not >>>>>>>>>> interesting to >>>>>>>>>> the >>>>>>>>>> discussion here (except to know that it might be different to >>>>>>>>>> the >>>>>>>>>> application class loader in some niche configuration). >>>>>>>>> >>>>>>>>> But you skipped the key part - why do we care about the built-in >>>>>>>>> loaders. In this code: >>>>>>>>> >>>>>>>>> +// If the module's loader, that a read edge is being established >>>>>>>>> to, is >>>>>>>>> +// not the same loader as this module's and is not one of the 3 >>>>>>>>> builtin >>>>>>>>> +// class loaders, then this module's reads list must be walked >>>>>>>>> at GC >>>>>>>>> +// safepoint. Modules have the same life cycle as their defining >>>>>>>>> class >>>>>>>>> +// loaders and should be removed if dead. >>>>>>>>> +void ModuleEntry::set_read_walk_required(ClassLoaderData* >>>>>>>>> m_loader_data) { >>>>>>>>> + assert_locked_or_safepoint(Module_lock); >>>>>>>>> + if (!_must_walk_reads && >>>>>>>>> + loader_data() != m_loader_data && >>>>>>>>> + !m_loader_data->is_builtin_class_loader_data()) { >>>>>>>>> + _must_walk_reads = true; >>>>>>>>> + if (log_is_enabled(Trace, modules)) { >>>>>>>>> + ResourceMark rm; >>>>>>>>> + log_trace(modules)("ModuleEntry::set_read_walk_required(): >>>>>>>>> module %s reads list must be walked", >>>>>>>>> + (name() != NULL) ? >>>>>>>>> name()->as_C_string() : >>>>>>>>> UNNAMED_MODULE); >>>>>>>>> + } >>>>>>>>> + } >>>>>>>>> +} >>>>>>>>> >>>>>>>>> what is "is_builtin_class_loader_data" really asking? Is it just >>>>>>>>> that >>>>>>>>> this is a loader whose lifetime is matched to that of the VM? >>>>>>>>> If so >>>>>>>>> then it is asking the wrong question with respect to the system >>>>>>>>> loader. If not, then what is it about the built-in system loader >>>>>>>>> type >>>>>>>>> that makes it different to some custom system loader? >>>>>>>> >>>>>>>> Hi David, >>>>>>>> >>>>>>>> The 3 built-in loaders will never be GC'ed, neither will a custom >>>>>>>> system >>>>>>>> classloader if there is one configured. Thus the JVM can make >>>>>>>> reliable >>>>>>>> assumptions based on modules defined to those 3 loaders. So if >>>>>>>> for >>>>>>>> example, a module's reads list only has established read edges to >>>>>>>> modules that are defined to any of the 3 built-in loaders, the >>>>>>>> JVM can >>>>>>>> rely on the fact that these loaders will never die and thus their >>>>>>>> modules will never die. So at a GC safepoint, that module's reads >>>>>>>> list >>>>>>>> will not have to be walked looking for dead modules that should be >>>>>>>> removed. >>>>>>> >>>>>>> My apologies to Alan and you as I didn't read this >>>>>>> code you >>>>>>> updated properly >>>>>> >>>>>> No worries! >>>>>> >>>>>>> >>>>>>> +bool SystemDictionary::is_system_class_loader(Handle >>>>>>> class_loader) { >>>>>>> + if (class_loader.is_null()) { >>>>>>> + return false; >>>>>>> + } >>>>>>> + return (class_loader->klass() == >>>>>>> SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass() >>>>>>> >>>>>>> >>>>>>> >>>>>>> || >>>>>>> + class_loader() == _java_system_loader); >>>>>>> +} >>>>>>> >>>>>>> >>>>>>> >>>>>>> Though I'm still unclear why it needs to have this form rather than >>>>>>> just a check for: >>>>>>> >>>>>>> class_loader() == _java_system_loader >>>>>>> >>>>>>> Even if _java_system_loader may not be initialized if this is >>>>>>> called >>>>>>> very early during the init phase (seems unlikely but possible), >>>>>>> then >>>>>>> all that will happen is we do an unnecessary walk of the reads >>>>>>> list. >>>>>>> That seems better than having to do the klass check each time >>>>>>> this is >>>>>>> called. >>>>>> >>>>>> But it is called very and often in module initialization since the >>>>>> module graph (set of root modules and the transitive closure of >>>>>> their >>>>>> dependencies with respect to the set of observable modules), is >>>>>> communicated to the JVM during init phase 2. For example, a simple >>>>>> "java -version" defines several modules, establishes read edges >>>>>> between >>>>>> modules and numerous qualified exports. More specific details >>>>>> can be >>>>>> obtained via -Xlog:modules=debug. >>>>> >>>>> You previously indicated this was needed to avoid walking the read >>>>> edges during a GC safepoint. There should not be many (if any) GC's >>>>> during VM initialization. ?? >>>> >>>> Correct, there should not be many GC's during VM initialization. >>>> However, the module graph is intact for the life of the application in >>>> order for the JVM to correctly adhere to the new module rules with >>>> regards to type accessibility/access checking. And it can be added to >>>> dynamically. So it subject to being walked during any GC post VM >>>> initialization. >>> >>> Okay, but that still leaves me wondering why we can't just check: >>> >>> class_loader() == _java_system_loader >>> >>> as the check for: >>> >>> class_loader->klass() == >>> SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass() >>> >>> >>> seems to be an unnecessary optimization only useful during >>> initialization ?? >> >> The modules defined, the read edges and the exported packages >> established during module system initialization (init phase 2) are the >> ones who can most benefit by this optimization since they are largely >> the system modules defined to the 3 builtin loaders! > > Yes _but_ the optimization is only used if we hit a GC safepoint, > which you already agreed was very unlikely during the initialization > phase. But these moduleEntry(s) stay alive for the life of the application so are subject to being walked whenever there is a GC safepoint, not just during initialization. Lois > > David > ----- > > > During module >> system initialization, for example, the module jdk.jconsole is defined >> to the builtin application class loader and establishes several read >> edges some of which are the following: >> >> [0.332s][debug][modules] add_reads_module(): Adding read from module >> jdk.jconsole to module java.logging >> [0.332s][debug][modules] add_reads_module(): Adding read from module >> jdk.jconsole to module java.datatransfer >> [0.332s][debug][modules] add_reads_module(): Adding read from module >> jdk.jconsole to module jdk.attach >> [0.332s][debug][modules] add_reads_module(): Adding read from module >> jdk.jconsole to module java.xml >> [0.332s][debug][modules] add_reads_module(): Adding read from module >> jdk.jconsole to module java.rmi >> [0.332s][debug][modules] add_reads_module(): Adding read from module >> jdk.jconsole to module jdk.jvmstat >> [0.332s][debug][modules] add_reads_module(): Adding read from module >> jdk.jconsole to module java.desktop >> [0.332s][debug][modules] add_reads_module(): Adding read from module >> jdk.jconsole to module java.base >> [0.332s][debug][modules] add_reads_module(): Adding read from module >> jdk.jconsole to module java.management >> [0.332s][debug][modules] add_reads_module(): Adding read from module >> jdk.jconsole to module jdk.management >> >> All the modules it establishes read edges to are modules that are >> defined to the 3 builtin loaders. It would be beneficial to never have >> to walk the jdk.jconsole's ModuleEntry reads list looking for dead >> modules that should be removed because in most scenarios there aren't >> going to be any. >> >>> >>> David >>> >>>>> >>>>> David >>>>> >>>>>> >>>>>> Thanks, >>>>>> Lois >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Lois >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> (PS. Really calling it a night now :) ) >>>>>>>>> >>>>>>>>>> -Alan >>>>>>>> >>>>>> >>>> >> From david.holmes at oracle.com Mon Jun 27 11:32:05 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Jun 2016 21:32:05 +1000 Subject: JDK 9 build with GCC 6.1.1 In-Reply-To: <5770D888.6080501@redhat.com> References: <29abf149-0dc7-c137-6a57-30fc66ed5906@gmail.com> <9b6ee147-b24a-5f6f-9b1a-e18decb39b15@oracle.com> <5770D888.6080501@redhat.com> Message-ID: <80abfc4e-59c5-40d0-1e1f-a6d76aea992d@oracle.com> On 27/06/2016 5:40 PM, Andrew Haley wrote: > On 27/06/16 00:25, David Holmes wrote: >> Not sure how the crash relates to the gcc 6.6.1 compilation issues. > > Maybe it's related to -fno-delete-null-pointer-checks and HotSpot's > habit of dereferencing null pointers. I made a start on some of these > issues but ran out of time and enthusiasm. It'd be great to have a > campaign to get rid of HotSpot's undefined behaviour. I wasn't aware that we have any reliance on gcc doing any kind of "null pointer check" ?? David > Andrew. > From david.holmes at oracle.com Mon Jun 27 11:35:33 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Jun 2016 21:35:33 +1000 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <57710809.4060906@oracle.com> References: <57698069.80902@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <84b40e40-347d-bb53-7662-9745f894eaa8@oracle.com> <576AC4EC.6070406@oracle.com> <6bdb6f82-517d-e686-4034-dc8f5ae6e9bd@oracle.com> <6e921b20-2fa7-b60d-c310-857180f358dd@oracle.com> <16738fb0-7a98-5a3a-979e-dd162a19541f@oracle.com> <576BE9CB.5080109@oracle.com> <334bf1c4-8628-b350-a3d2-5ebf717d0538@oracle.com> <576D6FDE.3040301@oracle.com> <576DAE75.30608@oracle.com> <576E55A7.8080008@oracle.com> <12be53ba-c330-2eeb-56de-03f6c9751f29@oracle.com> <57710809.4060906@oracle.com> Message-ID: <39eba9f4-0df3-203b-e1bf-367146696b9d@oracle.com> On 27/06/2016 9:03 PM, Lois Foltan wrote: > > On 6/26/2016 7:32 PM, David Holmes wrote: >> On 25/06/2016 7:57 PM, Lois Foltan wrote: >>> >>> On 6/24/2016 11:03 PM, David Holmes wrote: >>>> On 25/06/2016 8:04 AM, Lois Foltan wrote: >>>>> >>>>> On 6/24/2016 5:51 PM, David Holmes wrote: >>>>>> >>>>>> >>>>>> On 25/06/2016 3:37 AM, Lois Foltan wrote: >>>>>>> >>>>>>> On 6/23/2016 5:02 PM, David Holmes wrote: >>>>>>>> On 23/06/2016 11:53 PM, Lois Foltan wrote: >>>>>>>>> >>>>>>>>> On 6/23/2016 7:37 AM, David Holmes wrote: >>>>>>>>>> On 23/06/2016 9:25 PM, Alan Bateman wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 23/06/2016 12:05, David Holmes wrote: >>>>>>>>>>>> >>>>>>>>>>>> You said: >>>>>>>>>>>> >>>>>>>>>>>> "Module system initialization will initialize the built-in >>>>>>>>>>>> class >>>>>>>>>>>> loaders, including the application class loader. The >>>>>>>>>>>> platform or >>>>>>>>>>>> application class loaders won't load any classes in this >>>>>>>>>>>> phase of >>>>>>>>>>>> course but they will be initialized (with the modules that they >>>>>>>>>>>> might >>>>>>>>>>>> later load classes from). " >>>>>>>>>>>> >>>>>>>>>>>> What does that last part mean: "with the modules they might >>>>>>>>>>>> later >>>>>>>>>>>> load >>>>>>>>>>>> classes from"? How have modules become bound to a classloader >>>>>>>>>>>> that >>>>>>>>>>>> may >>>>>>>>>>>> not even get instantiated? If that class loader is never >>>>>>>>>>>> instantiated >>>>>>>>>>>> then why do we need a runtime test that checks for the type of >>>>>>>>>>>> the >>>>>>>>>>>> actual system class loader? >>>>>>>>>>> The graph of modules that are defined to the runtime during >>>>>>>>>>> startup >>>>>>>>>>> are >>>>>>>>>>> we call the "boot layer". They are statically mapped to the >>>>>>>>>>> built-in >>>>>>>>>>> class loaders where built-in means the boot, platform or >>>>>>>>>>> application >>>>>>>>>>> class loaders. There may be a custom system class loader that >>>>>>>>>>> comes >>>>>>>>>>> into >>>>>>>>>>> existence later during the startup but it's just not >>>>>>>>>>> interesting to >>>>>>>>>>> the >>>>>>>>>>> discussion here (except to know that it might be different to >>>>>>>>>>> the >>>>>>>>>>> application class loader in some niche configuration). >>>>>>>>>> >>>>>>>>>> But you skipped the key part - why do we care about the built-in >>>>>>>>>> loaders. In this code: >>>>>>>>>> >>>>>>>>>> +// If the module's loader, that a read edge is being established >>>>>>>>>> to, is >>>>>>>>>> +// not the same loader as this module's and is not one of the 3 >>>>>>>>>> builtin >>>>>>>>>> +// class loaders, then this module's reads list must be walked >>>>>>>>>> at GC >>>>>>>>>> +// safepoint. Modules have the same life cycle as their defining >>>>>>>>>> class >>>>>>>>>> +// loaders and should be removed if dead. >>>>>>>>>> +void ModuleEntry::set_read_walk_required(ClassLoaderData* >>>>>>>>>> m_loader_data) { >>>>>>>>>> + assert_locked_or_safepoint(Module_lock); >>>>>>>>>> + if (!_must_walk_reads && >>>>>>>>>> + loader_data() != m_loader_data && >>>>>>>>>> + !m_loader_data->is_builtin_class_loader_data()) { >>>>>>>>>> + _must_walk_reads = true; >>>>>>>>>> + if (log_is_enabled(Trace, modules)) { >>>>>>>>>> + ResourceMark rm; >>>>>>>>>> + log_trace(modules)("ModuleEntry::set_read_walk_required(): >>>>>>>>>> module %s reads list must be walked", >>>>>>>>>> + (name() != NULL) ? >>>>>>>>>> name()->as_C_string() : >>>>>>>>>> UNNAMED_MODULE); >>>>>>>>>> + } >>>>>>>>>> + } >>>>>>>>>> +} >>>>>>>>>> >>>>>>>>>> what is "is_builtin_class_loader_data" really asking? Is it just >>>>>>>>>> that >>>>>>>>>> this is a loader whose lifetime is matched to that of the VM? >>>>>>>>>> If so >>>>>>>>>> then it is asking the wrong question with respect to the system >>>>>>>>>> loader. If not, then what is it about the built-in system loader >>>>>>>>>> type >>>>>>>>>> that makes it different to some custom system loader? >>>>>>>>> >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> The 3 built-in loaders will never be GC'ed, neither will a custom >>>>>>>>> system >>>>>>>>> classloader if there is one configured. Thus the JVM can make >>>>>>>>> reliable >>>>>>>>> assumptions based on modules defined to those 3 loaders. So if >>>>>>>>> for >>>>>>>>> example, a module's reads list only has established read edges to >>>>>>>>> modules that are defined to any of the 3 built-in loaders, the >>>>>>>>> JVM can >>>>>>>>> rely on the fact that these loaders will never die and thus their >>>>>>>>> modules will never die. So at a GC safepoint, that module's reads >>>>>>>>> list >>>>>>>>> will not have to be walked looking for dead modules that should be >>>>>>>>> removed. >>>>>>>> >>>>>>>> My apologies to Alan and you as I didn't read this >>>>>>>> code you >>>>>>>> updated properly >>>>>>> >>>>>>> No worries! >>>>>>> >>>>>>>> >>>>>>>> +bool SystemDictionary::is_system_class_loader(Handle >>>>>>>> class_loader) { >>>>>>>> + if (class_loader.is_null()) { >>>>>>>> + return false; >>>>>>>> + } >>>>>>>> + return (class_loader->klass() == >>>>>>>> SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass() >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> || >>>>>>>> + class_loader() == _java_system_loader); >>>>>>>> +} >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Though I'm still unclear why it needs to have this form rather than >>>>>>>> just a check for: >>>>>>>> >>>>>>>> class_loader() == _java_system_loader >>>>>>>> >>>>>>>> Even if _java_system_loader may not be initialized if this is >>>>>>>> called >>>>>>>> very early during the init phase (seems unlikely but possible), >>>>>>>> then >>>>>>>> all that will happen is we do an unnecessary walk of the reads >>>>>>>> list. >>>>>>>> That seems better than having to do the klass check each time >>>>>>>> this is >>>>>>>> called. >>>>>>> >>>>>>> But it is called very and often in module initialization since the >>>>>>> module graph (set of root modules and the transitive closure of >>>>>>> their >>>>>>> dependencies with respect to the set of observable modules), is >>>>>>> communicated to the JVM during init phase 2. For example, a simple >>>>>>> "java -version" defines several modules, establishes read edges >>>>>>> between >>>>>>> modules and numerous qualified exports. More specific details >>>>>>> can be >>>>>>> obtained via -Xlog:modules=debug. >>>>>> >>>>>> You previously indicated this was needed to avoid walking the read >>>>>> edges during a GC safepoint. There should not be many (if any) GC's >>>>>> during VM initialization. ?? >>>>> >>>>> Correct, there should not be many GC's during VM initialization. >>>>> However, the module graph is intact for the life of the application in >>>>> order for the JVM to correctly adhere to the new module rules with >>>>> regards to type accessibility/access checking. And it can be added to >>>>> dynamically. So it subject to being walked during any GC post VM >>>>> initialization. >>>> >>>> Okay, but that still leaves me wondering why we can't just check: >>>> >>>> class_loader() == _java_system_loader >>>> >>>> as the check for: >>>> >>>> class_loader->klass() == >>>> SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass() >>>> >>>> >>>> seems to be an unnecessary optimization only useful during >>>> initialization ?? >>> >>> The modules defined, the read edges and the exported packages >>> established during module system initialization (init phase 2) are the >>> ones who can most benefit by this optimization since they are largely >>> the system modules defined to the 3 builtin loaders! >> >> Yes _but_ the optimization is only used if we hit a GC safepoint, >> which you already agreed was very unlikely during the initialization >> phase. > > But these moduleEntry(s) stay alive for the life of the application so > are subject to being walked whenever there is a GC safepoint, not just > during initialization. Ah so I think I misunderstood. I assumed this test was used during GC to decide whether to walk the read edges of a module. It seems you are using it to "tag" a module with whether the reads edges need to be walked - is that right? Thanks, David > Lois > >> >> David >> ----- >> >> >> During module >>> system initialization, for example, the module jdk.jconsole is defined >>> to the builtin application class loader and establishes several read >>> edges some of which are the following: >>> >>> [0.332s][debug][modules] add_reads_module(): Adding read from module >>> jdk.jconsole to module java.logging >>> [0.332s][debug][modules] add_reads_module(): Adding read from module >>> jdk.jconsole to module java.datatransfer >>> [0.332s][debug][modules] add_reads_module(): Adding read from module >>> jdk.jconsole to module jdk.attach >>> [0.332s][debug][modules] add_reads_module(): Adding read from module >>> jdk.jconsole to module java.xml >>> [0.332s][debug][modules] add_reads_module(): Adding read from module >>> jdk.jconsole to module java.rmi >>> [0.332s][debug][modules] add_reads_module(): Adding read from module >>> jdk.jconsole to module jdk.jvmstat >>> [0.332s][debug][modules] add_reads_module(): Adding read from module >>> jdk.jconsole to module java.desktop >>> [0.332s][debug][modules] add_reads_module(): Adding read from module >>> jdk.jconsole to module java.base >>> [0.332s][debug][modules] add_reads_module(): Adding read from module >>> jdk.jconsole to module java.management >>> [0.332s][debug][modules] add_reads_module(): Adding read from module >>> jdk.jconsole to module jdk.management >>> >>> All the modules it establishes read edges to are modules that are >>> defined to the 3 builtin loaders. It would be beneficial to never have >>> to walk the jdk.jconsole's ModuleEntry reads list looking for dead >>> modules that should be removed because in most scenarios there aren't >>> going to be any. >>> >>>> >>>> David >>>> >>>>>> >>>>>> David >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Lois >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Lois >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> (PS. Really calling it a night now :) ) >>>>>>>>>> >>>>>>>>>>> -Alan >>>>>>>>> >>>>>>> >>>>> >>> > From lois.foltan at oracle.com Mon Jun 27 11:36:18 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 27 Jun 2016 07:36:18 -0400 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <39eba9f4-0df3-203b-e1bf-367146696b9d@oracle.com> References: <57698069.80902@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <84b40e40-347d-bb53-7662-9745f894eaa8@oracle.com> <576AC4EC.6070406@oracle.com> <6bdb6f82-517d-e686-4034-dc8f5ae6e9bd@oracle.com> <6e921b20-2fa7-b60d-c310-857180f358dd@oracle.com> <16738fb0-7a98-5a3a-979e-dd162a19541f@oracle.com> <576BE9CB.5080109@oracle.com> <334bf1c4-8628-b350-a3d2-5ebf717d0538@oracle.com> <576D6FDE.3040301@oracle.com> <576DAE75.30608@oracle.com> <576E55A7.8080008@oracle.com> <12be53ba-c330-2eeb-56de-03f6c9751f29@oracle.com> <57710809.4060906@oracle.com> <39eba9f4-0df3-203b-e1bf-367146696b9d@ora! cle.com> Message-ID: <57710FB2.8000208@oracle.com> On 6/27/2016 7:35 AM, David Holmes wrote: > > > On 27/06/2016 9:03 PM, Lois Foltan wrote: >> >> On 6/26/2016 7:32 PM, David Holmes wrote: >>> On 25/06/2016 7:57 PM, Lois Foltan wrote: >>>> >>>> On 6/24/2016 11:03 PM, David Holmes wrote: >>>>> On 25/06/2016 8:04 AM, Lois Foltan wrote: >>>>>> >>>>>> On 6/24/2016 5:51 PM, David Holmes wrote: >>>>>>> >>>>>>> >>>>>>> On 25/06/2016 3:37 AM, Lois Foltan wrote: >>>>>>>> >>>>>>>> On 6/23/2016 5:02 PM, David Holmes wrote: >>>>>>>>> On 23/06/2016 11:53 PM, Lois Foltan wrote: >>>>>>>>>> >>>>>>>>>> On 6/23/2016 7:37 AM, David Holmes wrote: >>>>>>>>>>> On 23/06/2016 9:25 PM, Alan Bateman wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 23/06/2016 12:05, David Holmes wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> You said: >>>>>>>>>>>>> >>>>>>>>>>>>> "Module system initialization will initialize the built-in >>>>>>>>>>>>> class >>>>>>>>>>>>> loaders, including the application class loader. The >>>>>>>>>>>>> platform or >>>>>>>>>>>>> application class loaders won't load any classes in this >>>>>>>>>>>>> phase of >>>>>>>>>>>>> course but they will be initialized (with the modules that >>>>>>>>>>>>> they >>>>>>>>>>>>> might >>>>>>>>>>>>> later load classes from). " >>>>>>>>>>>>> >>>>>>>>>>>>> What does that last part mean: "with the modules they might >>>>>>>>>>>>> later >>>>>>>>>>>>> load >>>>>>>>>>>>> classes from"? How have modules become bound to a classloader >>>>>>>>>>>>> that >>>>>>>>>>>>> may >>>>>>>>>>>>> not even get instantiated? If that class loader is never >>>>>>>>>>>>> instantiated >>>>>>>>>>>>> then why do we need a runtime test that checks for the >>>>>>>>>>>>> type of >>>>>>>>>>>>> the >>>>>>>>>>>>> actual system class loader? >>>>>>>>>>>> The graph of modules that are defined to the runtime during >>>>>>>>>>>> startup >>>>>>>>>>>> are >>>>>>>>>>>> we call the "boot layer". They are statically mapped to the >>>>>>>>>>>> built-in >>>>>>>>>>>> class loaders where built-in means the boot, platform or >>>>>>>>>>>> application >>>>>>>>>>>> class loaders. There may be a custom system class loader that >>>>>>>>>>>> comes >>>>>>>>>>>> into >>>>>>>>>>>> existence later during the startup but it's just not >>>>>>>>>>>> interesting to >>>>>>>>>>>> the >>>>>>>>>>>> discussion here (except to know that it might be different to >>>>>>>>>>>> the >>>>>>>>>>>> application class loader in some niche configuration). >>>>>>>>>>> >>>>>>>>>>> But you skipped the key part - why do we care about the >>>>>>>>>>> built-in >>>>>>>>>>> loaders. In this code: >>>>>>>>>>> >>>>>>>>>>> +// If the module's loader, that a read edge is being >>>>>>>>>>> established >>>>>>>>>>> to, is >>>>>>>>>>> +// not the same loader as this module's and is not one of >>>>>>>>>>> the 3 >>>>>>>>>>> builtin >>>>>>>>>>> +// class loaders, then this module's reads list must be walked >>>>>>>>>>> at GC >>>>>>>>>>> +// safepoint. Modules have the same life cycle as their >>>>>>>>>>> defining >>>>>>>>>>> class >>>>>>>>>>> +// loaders and should be removed if dead. >>>>>>>>>>> +void ModuleEntry::set_read_walk_required(ClassLoaderData* >>>>>>>>>>> m_loader_data) { >>>>>>>>>>> + assert_locked_or_safepoint(Module_lock); >>>>>>>>>>> + if (!_must_walk_reads && >>>>>>>>>>> + loader_data() != m_loader_data && >>>>>>>>>>> + !m_loader_data->is_builtin_class_loader_data()) { >>>>>>>>>>> + _must_walk_reads = true; >>>>>>>>>>> + if (log_is_enabled(Trace, modules)) { >>>>>>>>>>> + ResourceMark rm; >>>>>>>>>>> + log_trace(modules)("ModuleEntry::set_read_walk_required(): >>>>>>>>>>> module %s reads list must be walked", >>>>>>>>>>> + (name() != NULL) ? >>>>>>>>>>> name()->as_C_string() : >>>>>>>>>>> UNNAMED_MODULE); >>>>>>>>>>> + } >>>>>>>>>>> + } >>>>>>>>>>> +} >>>>>>>>>>> >>>>>>>>>>> what is "is_builtin_class_loader_data" really asking? Is it >>>>>>>>>>> just >>>>>>>>>>> that >>>>>>>>>>> this is a loader whose lifetime is matched to that of the VM? >>>>>>>>>>> If so >>>>>>>>>>> then it is asking the wrong question with respect to the system >>>>>>>>>>> loader. If not, then what is it about the built-in system >>>>>>>>>>> loader >>>>>>>>>>> type >>>>>>>>>>> that makes it different to some custom system loader? >>>>>>>>>> >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> The 3 built-in loaders will never be GC'ed, neither will a >>>>>>>>>> custom >>>>>>>>>> system >>>>>>>>>> classloader if there is one configured. Thus the JVM can make >>>>>>>>>> reliable >>>>>>>>>> assumptions based on modules defined to those 3 loaders. So if >>>>>>>>>> for >>>>>>>>>> example, a module's reads list only has established read >>>>>>>>>> edges to >>>>>>>>>> modules that are defined to any of the 3 built-in loaders, the >>>>>>>>>> JVM can >>>>>>>>>> rely on the fact that these loaders will never die and thus >>>>>>>>>> their >>>>>>>>>> modules will never die. So at a GC safepoint, that module's >>>>>>>>>> reads >>>>>>>>>> list >>>>>>>>>> will not have to be walked looking for dead modules that >>>>>>>>>> should be >>>>>>>>>> removed. >>>>>>>>> >>>>>>>>> My apologies to Alan and you as I didn't read this >>>>>>>>> code you >>>>>>>>> updated properly >>>>>>>> >>>>>>>> No worries! >>>>>>>> >>>>>>>>> >>>>>>>>> +bool SystemDictionary::is_system_class_loader(Handle >>>>>>>>> class_loader) { >>>>>>>>> + if (class_loader.is_null()) { >>>>>>>>> + return false; >>>>>>>>> + } >>>>>>>>> + return (class_loader->klass() == >>>>>>>>> SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass() >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> || >>>>>>>>> + class_loader() == _java_system_loader); >>>>>>>>> +} >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Though I'm still unclear why it needs to have this form rather >>>>>>>>> than >>>>>>>>> just a check for: >>>>>>>>> >>>>>>>>> class_loader() == _java_system_loader >>>>>>>>> >>>>>>>>> Even if _java_system_loader may not be initialized if this is >>>>>>>>> called >>>>>>>>> very early during the init phase (seems unlikely but possible), >>>>>>>>> then >>>>>>>>> all that will happen is we do an unnecessary walk of the reads >>>>>>>>> list. >>>>>>>>> That seems better than having to do the klass check each time >>>>>>>>> this is >>>>>>>>> called. >>>>>>>> >>>>>>>> But it is called very and often in module initialization since the >>>>>>>> module graph (set of root modules and the transitive closure of >>>>>>>> their >>>>>>>> dependencies with respect to the set of observable modules), is >>>>>>>> communicated to the JVM during init phase 2. For example, a >>>>>>>> simple >>>>>>>> "java -version" defines several modules, establishes read edges >>>>>>>> between >>>>>>>> modules and numerous qualified exports. More specific details >>>>>>>> can be >>>>>>>> obtained via -Xlog:modules=debug. >>>>>>> >>>>>>> You previously indicated this was needed to avoid walking the read >>>>>>> edges during a GC safepoint. There should not be many (if any) GC's >>>>>>> during VM initialization. ?? >>>>>> >>>>>> Correct, there should not be many GC's during VM initialization. >>>>>> However, the module graph is intact for the life of the >>>>>> application in >>>>>> order for the JVM to correctly adhere to the new module rules with >>>>>> regards to type accessibility/access checking. And it can be >>>>>> added to >>>>>> dynamically. So it subject to being walked during any GC post VM >>>>>> initialization. >>>>> >>>>> Okay, but that still leaves me wondering why we can't just check: >>>>> >>>>> class_loader() == _java_system_loader >>>>> >>>>> as the check for: >>>>> >>>>> class_loader->klass() == >>>>> SystemDictionary::jdk_internal_loader_ClassLoaders_AppClassLoader_klass() >>>>> >>>>> >>>>> >>>>> seems to be an unnecessary optimization only useful during >>>>> initialization ?? >>>> >>>> The modules defined, the read edges and the exported packages >>>> established during module system initialization (init phase 2) are the >>>> ones who can most benefit by this optimization since they are largely >>>> the system modules defined to the 3 builtin loaders! >>> >>> Yes _but_ the optimization is only used if we hit a GC safepoint, >>> which you already agreed was very unlikely during the initialization >>> phase. >> >> But these moduleEntry(s) stay alive for the life of the application so >> are subject to being walked whenever there is a GC safepoint, not just >> during initialization. > > Ah so I think I misunderstood. I assumed this test was used during GC > to decide whether to walk the read edges of a module. It seems you are > using it to "tag" a module with whether the reads edges need to be > walked - is that right? Yes! > > Thanks, > David > > >> Lois >> >>> >>> David >>> ----- >>> >>> >>> During module >>>> system initialization, for example, the module jdk.jconsole is defined >>>> to the builtin application class loader and establishes several read >>>> edges some of which are the following: >>>> >>>> [0.332s][debug][modules] add_reads_module(): Adding read from module >>>> jdk.jconsole to module java.logging >>>> [0.332s][debug][modules] add_reads_module(): Adding read from module >>>> jdk.jconsole to module java.datatransfer >>>> [0.332s][debug][modules] add_reads_module(): Adding read from module >>>> jdk.jconsole to module jdk.attach >>>> [0.332s][debug][modules] add_reads_module(): Adding read from module >>>> jdk.jconsole to module java.xml >>>> [0.332s][debug][modules] add_reads_module(): Adding read from module >>>> jdk.jconsole to module java.rmi >>>> [0.332s][debug][modules] add_reads_module(): Adding read from module >>>> jdk.jconsole to module jdk.jvmstat >>>> [0.332s][debug][modules] add_reads_module(): Adding read from module >>>> jdk.jconsole to module java.desktop >>>> [0.332s][debug][modules] add_reads_module(): Adding read from module >>>> jdk.jconsole to module java.base >>>> [0.332s][debug][modules] add_reads_module(): Adding read from module >>>> jdk.jconsole to module java.management >>>> [0.332s][debug][modules] add_reads_module(): Adding read from module >>>> jdk.jconsole to module jdk.management >>>> >>>> All the modules it establishes read edges to are modules that are >>>> defined to the 3 builtin loaders. It would be beneficial to never >>>> have >>>> to walk the jdk.jconsole's ModuleEntry reads list looking for dead >>>> modules that should be removed because in most scenarios there aren't >>>> going to be any. >>>> >>>>> >>>>> David >>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Lois >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Lois >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> (PS. Really calling it a night now :) ) >>>>>>>>>>> >>>>>>>>>>>> -Alan >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> From david.holmes at oracle.com Mon Jun 27 11:36:44 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Jun 2016 21:36:44 +1000 Subject: JDK-8160310: HotSpot cannot be built with GCC 6 In-Reply-To: <4ba4ad31-9abe-ef39-18e0-3288ef1008d5@gmail.com> References: <39AC3517-8619-4E92-BB48-BB98ACA71349@oracle.com> <43d7a53e-ec53-f940-8e99-be1874fbc3d7@gmail.com> <929cfe33-d9de-cc0b-3090-e896dc59efbf@oracle.com> <4ba4ad31-9abe-ef39-18e0-3288ef1008d5@gmail.com> Message-ID: On 27/06/2016 8:25 PM, Yasumasa Suenaga wrote: >> But these need to be broken up into individual problems. I don't mind >> if the actual compilation warnings/errors are handled as a group. > > I think we can create several subtasks for this as below: Seems reasonable. > Group 1: narrowing conversion > - altHashing.cpp > - os_linux.cpp > - type.cpp > > Group 2: uninitialized value (including assertion failure) > - assembler_x86.cpp > - interp_masm_x86.cpp > - relocInfo.hpp > - c1_Instruction.hpp > > Group 3: invalid suffix on literal > - moduleEntry.cpp > - packageEntry.cpp > - preservedMarks.cpp > > Group 4: unnescessary assertion > - node.cpp > > Group 5: potential for SEGV > - classLoaderData.cpp Would like to know how gcc 6 relates to this one. > Group 6: refactoring for GCC 6 > - oop.inline.hpp > > > Is it okay? > If so, I will create them as subtask of JDK-8160310 and send > review request if possible. I'm okay with that. Thanks, David > > Thanks, > > Yasumasa > > > On 2016/06/27 13:08, David Holmes wrote: >> On 27/06/2016 1:57 PM, Yasumasa Suenaga wrote: >>> Hi David, Kim, >>> >>> I've filed this as JDK-8160310, and uploaded new webrev for discussion. >>> (Not review request) >>> >>> http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot.01/ >>> >>> >>>> Some of these appear to be just plain bug fixes, and I wonder why the >>>> code is working now? For example, the change at >>>> src/share/vm/classfile/classLoaderData.cpp:145 seems suspicious. >>> >>> I analyzed this crash with GDB, and this fix works fine. >> >> Yes but it has nothing to do with gcc 6. AFAICS a very early GC during >> module initialization would trigger this bug. >> >> I'd be very surprised if any of the crashes are directly attributable >> to using gcc 6. But these need to be broken up into individual >> problems. I don't mind if the actual compilation warnings/errors are >> handled as a group. >> >> Thanks, >> David >> ----- >> >>> Please see hs_err log on JIRA. >>> >>> >>>> Some of these are just cleanups, like >>>> src/share/vm/oops/oop.inline.hpp:542, but it's post-FC. >>> >>> I understood. >>> But I do not understand well why this cheange works fine. >>> So I want to discuss about it. >>> (I uploaded hs_err log to JIRA.) >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/06/27 12:40, Kim Barrett wrote: >>>>> On Jun 25, 2016, at 9:57 AM, Yasumasa Suenaga >>>>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> This review request relates to [1]. >>>>> >>>>> I've tried to build OpenJDK 9 at Fedora 24 x64. >>>>> Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. >>>>> >>>>> I fixed build error and several issues (VM crash and internal error) >>>>> as below: >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ >>>> >>>> I've only done a quick skim of the proposed hotspot changes, not a >>>> proper review. Just in general, I'd rather review changes in chunks >>>> that were logically related, which many of these aren't. (Needed to >>>> build and run with some new compiler doesn't make them related for >>>> review purposes.) And please provide some context. Reviewers >>>> shouldn't have to guess what problem is being solved by a given >>>> change. Some of these still seem mysterious to me, even with the link >>>> to build failures and crash dumps. >>>> >>>> Some specific issues: >>>> >>>> A couple of these were recently addressed by JDK-8157758. >>>> >>>> Some of these are C++11 or later changes tripping up a code base >>>> written for C++98/03. A few months ago a change was made to >>>> explicitly use -std=gnu++98 for exactly this reason (see JDK-8151841), >>>> but that seems to have gotten lost in the transition to the new build >>>> system (see JDK-8156980). I would prefer that got fixed and these >>>> kinds of issues be deferred to a future modernization project, where >>>> some of them might involve something more principled than adding some >>>> workaround casts, for example. (We've been doing string/identifier >>>> whitespace separation for a while, though; I'd be fine with those, >>>> other than being post-FC.) >>>> >>>> Some of these appear to be just plain bug fixes, and I wonder why the >>>> code is working now? For example, the change at >>>> src/share/vm/classfile/classLoaderData.cpp:145 seems suspicious. >>>> >>>> Some of these are just cleanups, like >>>> src/share/vm/oops/oop.inline.hpp:542, but it's post-FC. >>>> >>>>> Does someone work for it? >>>>> If no one works for it, I will file it to JBS and will send review >>>>> request. >>>> >>>> Certainly there should be CRs filed for these; the enhancements so >>>> they don't get lost, and the crashes because they probably indicate >>>> real bugs. >>>> >>>>> For jdk repos, I've sent review request [2]. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] >>>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html >>>>> [2] >>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007081.html >>>> >>>> From aph at redhat.com Mon Jun 27 11:45:58 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 27 Jun 2016 12:45:58 +0100 Subject: JDK 9 build with GCC 6.1.1 In-Reply-To: <80abfc4e-59c5-40d0-1e1f-a6d76aea992d@oracle.com> References: <29abf149-0dc7-c137-6a57-30fc66ed5906@gmail.com> <9b6ee147-b24a-5f6f-9b1a-e18decb39b15@oracle.com> <5770D888.6080501@redhat.com> <80abfc4e-59c5-40d0-1e1f-a6d76aea992d@oracle.com> Message-ID: <577111F6.7000905@redhat.com> On 27/06/16 12:32, David Holmes wrote: > I wasn't aware that we have any reliance on gcc doing any kind of "null > pointer check" ?? Ah, right, I assumed you'd seen this before. If GCC sees something like a->foo(); if (a) { b(); } it will turn it into a->foo(); b(); This surprises some people, but is quite legal. Andrew. From coleen.phillimore at oracle.com Mon Jun 27 13:01:39 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 27 Jun 2016 09:01:39 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: Message-ID: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.00/src/share/vm/memory/universe.cpp.udiff.html Do you need load_aquires and store_releases on set_reference_pending_list and has_reference_pending_list ? Or rather, why do you need an atomic operation in swap_pending_list if the Heap_lock is held? Aha, you answered the question in the header file. http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.00/src/share/vm/oops/method.cpp.udiff.html I think this particular special case hack could have been taken out by permgen elimination, but I was too nervous about it! http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.00/src/share/vm/prims/jvm.cpp.udiff.html Can you change the boolean "wait" to "should_wait" ? http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.00/src/share/vm/runtime/thread.cpp.udiff.html This change in initialization order makes sense to me. We really need to preallocate OOM before initializing the system libraries. Since Throwable() doesn't check a property now, this is safe. I don't think this wasn't safe a few months ago. Throwable constructor should do as little as possible. Thank you for removing the stale comment. Is the test that you're going to add from the other bug fix? ie. OomDebugTest.java (can that have a @bug 8156500 entry in it? So many special cases removed! This is so nice. http://cr.openjdk.java.net/~kbarrett/8156500/jdk.00/src/java.base/share/classes/java/lang/ref/Reference.java.udiff.html Can you add to the popReferencePendingLIst comment that the pending list is managed by the GC, ie. gc enqueues and dequeues references to process? Or something like that? I'm glad you went with the simpler implementation of only popping one reference. I think it can be enhanced in the future to get the whole list but it's late in the release to change the behavior and you might come up with something even better in the next release. I've learned so much about reference processing with this change. Thank you for making it make more sense. This is a really good change. Coleen On 6/24/16 4:09 PM, Kim Barrett wrote: > Please review this change which moves the Reference pending list and > locking from the java.lang.ref.Reference class into the VM. This > includes elimination of the ReferencePendingListLocker mechanism in > the VM. This fixes various fragility issues arising from having the > management of this list split between Java and the VM (GC). > > This change addresses JDK-8156500 by eliminating the possibility of > suspension while holding the lock. Because the locking is now done in > the VM, we have full control over where suspension may occur. > > This change retains the existing interface between the reference > processor and the nio.Bits package, e.g. Reference.tryHandlePending > has the same signature and behavior; this change just pushes the > pending list manipulation down into the VM. There are open bugs > reports, enhancement requests, and discussions related to that > interface; see below. This change does not attempt to address them. > > This change additionally addresses or renders moot > https://bugs.openjdk.java.net/browse/JDK-8055232 > (ref) Exceptions while processing Reference pending list > > and > https://bugs.openjdk.java.net/browse/JDK-7103238 > Ensure pending list lock is held on behalf of GC before enqueuing references on to the pending list > > It is also relevant for followup discussion of > https://bugs.openjdk.java.net/browse/JDK-8022321 > java/lang/ref/OOMEInReferenceHandler.java fails immediately > > and > https://bugs.openjdk.java.net/browse/JDK-8149925 > We don't need jdk.internal.ref.Cleaner any more - part 1 > > and has implications for: > https://bugs.openjdk.java.net/browse/JDK-8066859 > java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died > > In addition to the obviously relevant changes, there are a couple of > changes whose presence here might seem surprising and require further > explanation. > > - Removal of a stale comment in create_vm, noticed because it was near > some code being removed as part of this change. The comment was > rendered obsolete by JDK-8028275. > > - Moved initialization of exception classes earlier in > initialize_java_lang_classes. The previous order only worked by > accident, at least for OOME. During the bulk of the library > initialization, OOME may be thrown, perhaps due to poorly chosen > command line options. That attempts to use one of the pre-allocated > OOME objects, and tries to fill in its stack trace. If the Throwable > class is not yet initialized, this leads to a failed assert in the VM > because Throwable.UNASSIGNED_STACK still has a null value. This > initialization order issue was being masked by the old pending list > implementation; the initialization of Reference ensured > InterruptedException was initialized (thereby initializing its > Throwable base class), and the initialization of Reference just > happened to occur early enough that Throwable was initialized by the > time it was needed when running certain tests. The forced > initialization of InterruptedException is no longer needed by > Reference, but removal of it triggered test failures (and could > trigger corresponding product failures) because of this ordering > issue. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8156500 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8156500/jdk.00/ > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.00/ > > Testing: > RBT ad hoc nightly runtime & gc tests. > > With the proposed patch for JDK-8153711 applied, locally ran nearly > 35K iterations of the OomDebugTest that is part of that patch, with no > failures / deadlocks. Without this change it would typically only take > on the order of 100 iterations to hit a deadlock failure. > > Locally ran direct byte buffer allocation test: > jdk/test/java/nio/Buffer/DirectBufferAllocTest.java > This change reported 3% faster allocation times, and 1/2 the standard > deviation for allocation times. > > Locally ran failing test from JDK-8022321 and JDK-8066859 a few > thousand times. > jdk/test/java/lang/ref/OOMEInReferenceHandler.java > No errors, but failures were noted as hard to reproduce. > From yasuenag at gmail.com Mon Jun 27 13:41:19 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 27 Jun 2016 22:41:19 +0900 Subject: JDK-8160310: HotSpot cannot be built with GCC 6 In-Reply-To: References: <39AC3517-8619-4E92-BB48-BB98ACA71349@oracle.com> <43d7a53e-ec53-f940-8e99-be1874fbc3d7@gmail.com> <929cfe33-d9de-cc0b-3090-e896dc59efbf@oracle.com> <4ba4ad31-9abe-ef39-18e0-3288ef1008d5@gmail.com> Message-ID: Hi David, I added subtasks to JDK-8160310. >> Group 5: potential for SEGV >> - classLoaderData.cpp > > Would like to know how gcc 6 relates to this one. I'm not sure this crash relates to GCC 6, but I think NULL check should be added at this point. Thanks, Yasumasa On 2016/06/27 20:36, David Holmes wrote: > On 27/06/2016 8:25 PM, Yasumasa Suenaga wrote: >>> But these need to be broken up into individual problems. I don't mind >>> if the actual compilation warnings/errors are handled as a group. >> >> I think we can create several subtasks for this as below: > > Seems reasonable. > >> Group 1: narrowing conversion >> - altHashing.cpp >> - os_linux.cpp >> - type.cpp >> >> Group 2: uninitialized value (including assertion failure) >> - assembler_x86.cpp >> - interp_masm_x86.cpp >> - relocInfo.hpp >> - c1_Instruction.hpp >> >> Group 3: invalid suffix on literal >> - moduleEntry.cpp >> - packageEntry.cpp >> - preservedMarks.cpp >> >> Group 4: unnescessary assertion >> - node.cpp >> >> Group 5: potential for SEGV >> - classLoaderData.cpp > > Would like to know how gcc 6 relates to this one. > >> Group 6: refactoring for GCC 6 >> - oop.inline.hpp >> >> >> Is it okay? >> If so, I will create them as subtask of JDK-8160310 and send >> review request if possible. > > I'm okay with that. > > Thanks, > David > >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/06/27 13:08, David Holmes wrote: >>> On 27/06/2016 1:57 PM, Yasumasa Suenaga wrote: >>>> Hi David, Kim, >>>> >>>> I've filed this as JDK-8160310, and uploaded new webrev for discussion. >>>> (Not review request) >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot.01/ >>>> >>>> >>>>> Some of these appear to be just plain bug fixes, and I wonder why the >>>>> code is working now? For example, the change at >>>>> src/share/vm/classfile/classLoaderData.cpp:145 seems suspicious. >>>> >>>> I analyzed this crash with GDB, and this fix works fine. >>> >>> Yes but it has nothing to do with gcc 6. AFAICS a very early GC during >>> module initialization would trigger this bug. >>> >>> I'd be very surprised if any of the crashes are directly attributable >>> to using gcc 6. But these need to be broken up into individual >>> problems. I don't mind if the actual compilation warnings/errors are >>> handled as a group. >>> >>> Thanks, >>> David >>> ----- >>> >>>> Please see hs_err log on JIRA. >>>> >>>> >>>>> Some of these are just cleanups, like >>>>> src/share/vm/oops/oop.inline.hpp:542, but it's post-FC. >>>> >>>> I understood. >>>> But I do not understand well why this cheange works fine. >>>> So I want to discuss about it. >>>> (I uploaded hs_err log to JIRA.) >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/06/27 12:40, Kim Barrett wrote: >>>>>> On Jun 25, 2016, at 9:57 AM, Yasumasa Suenaga >>>>>> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> This review request relates to [1]. >>>>>> >>>>>> I've tried to build OpenJDK 9 at Fedora 24 x64. >>>>>> Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. >>>>>> >>>>>> I fixed build error and several issues (VM crash and internal error) >>>>>> as below: >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ >>>>> >>>>> I've only done a quick skim of the proposed hotspot changes, not a >>>>> proper review. Just in general, I'd rather review changes in chunks >>>>> that were logically related, which many of these aren't. (Needed to >>>>> build and run with some new compiler doesn't make them related for >>>>> review purposes.) And please provide some context. Reviewers >>>>> shouldn't have to guess what problem is being solved by a given >>>>> change. Some of these still seem mysterious to me, even with the link >>>>> to build failures and crash dumps. >>>>> >>>>> Some specific issues: >>>>> >>>>> A couple of these were recently addressed by JDK-8157758. >>>>> >>>>> Some of these are C++11 or later changes tripping up a code base >>>>> written for C++98/03. A few months ago a change was made to >>>>> explicitly use -std=gnu++98 for exactly this reason (see JDK-8151841), >>>>> but that seems to have gotten lost in the transition to the new build >>>>> system (see JDK-8156980). I would prefer that got fixed and these >>>>> kinds of issues be deferred to a future modernization project, where >>>>> some of them might involve something more principled than adding some >>>>> workaround casts, for example. (We've been doing string/identifier >>>>> whitespace separation for a while, though; I'd be fine with those, >>>>> other than being post-FC.) >>>>> >>>>> Some of these appear to be just plain bug fixes, and I wonder why the >>>>> code is working now? For example, the change at >>>>> src/share/vm/classfile/classLoaderData.cpp:145 seems suspicious. >>>>> >>>>> Some of these are just cleanups, like >>>>> src/share/vm/oops/oop.inline.hpp:542, but it's post-FC. >>>>> >>>>>> Does someone work for it? >>>>>> If no one works for it, I will file it to JBS and will send review >>>>>> request. >>>>> >>>>> Certainly there should be CRs filed for these; the enhancements so >>>>> they don't get lost, and the crashes because they probably indicate >>>>> real bugs. >>>>> >>>>>> For jdk repos, I've sent review request [2]. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> [1] >>>>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html >>>>>> [2] >>>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007081.html >>>>> >>>>> From yasuenag at gmail.com Mon Jun 27 14:26:45 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 27 Jun 2016 23:26:45 +0900 Subject: RFR: JDK-8160353: narrowing conversion error is occurred with GCC 6 Message-ID: Hi all, This review request relates to JDK-8160310: HotSpot cannot be built with GCC 6 . I encountered narrowing conversion error when I compiled OpenJDK 9 with GCC 6 on Fedora 24 x64. I think these error should be fixed. I uploaded webrev. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8160353/webrev.00/ I'm jdk 9 committer, but I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa From yasuenag at gmail.com Mon Jun 27 14:29:04 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 27 Jun 2016 23:29:04 +0900 Subject: RFR: JDK-8160354: uninitialized value warning and VM crash are occurred with GCC 6 Message-ID: Hi all, This review request relates to JDK-8160310: HotSpot cannot be built with GCC 6 . I encountered 2 compiler warnings and 2 VM crashes when I compiled OpenJDK 9 with GCC 6 on Fedora 24 x64. I think these error should be fixed. I uploaded webrev. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8160354/webrev.00/ I'm jdk 9 committer, but I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa From yasuenag at gmail.com Mon Jun 27 14:30:59 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 27 Jun 2016 23:30:59 +0900 Subject: RFR: JDK-8160356: invalid suffix on literal warning is occurred with GCC 6 Message-ID: <96c1c5d9-403c-bdcf-4574-848a50b7521a@gmail.com> Hi all, This review request relates to JDK-8160310: HotSpot cannot be built with GCC 6 . I encountered invalid suffix on literal when I compiled OpenJDK 9 with GCC 6 on Fedora 24 x64. I think these error should be fixed. I uploaded webrev. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8160356/webrev.00/ I'm jdk 9 committer, but I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa From yasuenag at gmail.com Mon Jun 27 14:35:21 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 27 Jun 2016 23:35:21 +0900 Subject: JDK-8160357: assert(_in == (Node**)this) failed: Must not pass arg count to 'new' Message-ID: Hi all, This review request relates to JDK-8160310: HotSpot cannot be built with GCC 6 . I encountered VM crash when I compiled OpenJDK 9 with GCC 6 on Fedora 24 x64. jmod tool was crashed by assertion. This binary is fastdebug which is built by GCC 6. I guess this assertion can be removed as below because _in is set to NULL and does not seems to be initialized. http://cr.openjdk.java.net/~ysuenaga/JDK-8160356/webrev.00/ However, I'm not sure whether this fix is correct. Please discuss about it. Thanks, Yasumasa From yasuenag at gmail.com Mon Jun 27 14:38:08 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 27 Jun 2016 23:38:08 +0900 Subject: RFR: JDK-8160361: SEGV occurred at JNIHandleBlock::oops_do(OopClosure*) Message-ID: <6c0d9332-a49e-9cd4-7813-5bad8d873bbc@gmail.com> Hi all, This review request relates to JDK-8160310: HotSpot cannot be built with GCC 6 . I encountered VM crash when I compiled OpenJDK 9 with GCC 6 on Fedora 24 x64. This crash was occurred in fastdebug JVM which was built by GCC 6. I'm not sure this crash relates to GCC 6, but I think NULL check should be added at this point. I uploaded webrev. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8160361/webrev.00/ I'm jdk 9 committer, but I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa From yasuenag at gmail.com Mon Jun 27 14:41:03 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 27 Jun 2016 23:41:03 +0900 Subject: JDK-8160363: assert(discovered->is_oop_or_null()) failed: Expected an oop or NULL for discovered field at 0x0000000000000000 Message-ID: <450ea729-cc3f-9e83-0d83-07e7a6a5ce4c@gmail.com> Hi all, This review request relates to JDK-8160310: HotSpot cannot be built with GCC 6 . I encountered VM crash when I compiled OpenJDK 9 with GCC 6 on Fedora 24 x64. Address of pointer was expected (0x0), however is_oop_or_null() did not work. I do not understand why current code did not work, however it works fine as below: http://cr.openjdk.java.net/~ysuenaga/JDK-8160363/webrev.00/ Please discuss about it. Thanks, Yasumasa From dmitry.samersoff at oracle.com Mon Jun 27 14:49:53 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 27 Jun 2016 17:49:53 +0300 Subject: JDK-8160357: assert(_in == (Node**)this) failed: Must not pass arg count to 'new' In-Reply-To: References: Message-ID: <0f7f885a-f573-3583-b6b7-5b85f3a12887@oracle.com> Yasumasa, I see only space changes in a webrev below. Did I miss something? -Dmitry On 2016-06-27 17:35, Yasumasa Suenaga wrote: > Hi all, > > This review request relates to JDK-8160310: HotSpot cannot be built with > GCC 6 . > > I encountered VM crash when I compiled OpenJDK 9 with GCC 6 > on Fedora 24 x64. > > jmod tool was crashed by assertion. > This binary is fastdebug which is built by GCC 6. > > I guess this assertion can be removed as below because _in is set to > NULL and > does not seems to be initialized. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8160356/webrev.00/ > > > However, I'm not sure whether this fix is correct. > Please discuss about it. > > > Thanks, > > Yasumasa > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yasuenag at gmail.com Mon Jun 27 14:57:26 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 27 Jun 2016 23:57:26 +0900 Subject: JDK-8160357: assert(_in == (Node**)this) failed: Must not pass arg count to 'new' In-Reply-To: <0f7f885a-f573-3583-b6b7-5b85f3a12887@oracle.com> References: <0f7f885a-f573-3583-b6b7-5b85f3a12887@oracle.com> Message-ID: <75da501b-a025-d3bd-388f-d56cfe3dad99@gmail.com> > I see only space changes in a webrev below. Sorry, I wrote incorrect URL. Please see as below: http://cr.openjdk.java.net/~ysuenaga/JDK-8160357/webrev.00/ Yasumasa On 2016/06/27 23:49, Dmitry Samersoff wrote: > Yasumasa, > > I see only space changes in a webrev below. > > Did I miss something? > > -Dmitry > > On 2016-06-27 17:35, Yasumasa Suenaga wrote: >> Hi all, >> >> This review request relates to JDK-8160310: HotSpot cannot be built with >> GCC 6 . >> >> I encountered VM crash when I compiled OpenJDK 9 with GCC 6 >> on Fedora 24 x64. >> >> jmod tool was crashed by assertion. >> This binary is fastdebug which is built by GCC 6. >> >> I guess this assertion can be removed as below because _in is set to >> NULL and >> does not seems to be initialized. >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8160356/webrev.00/ >> >> >> However, I'm not sure whether this fix is correct. >> Please discuss about it. >> >> >> Thanks, >> >> Yasumasa >> >> > > From dmitry.samersoff at oracle.com Mon Jun 27 15:01:55 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 27 Jun 2016 18:01:55 +0300 Subject: RFR: JDK-8160361: SEGV occurred at JNIHandleBlock::oops_do(OopClosure*) In-Reply-To: <6c0d9332-a49e-9cd4-7813-5bad8d873bbc@gmail.com> References: <6c0d9332-a49e-9cd4-7813-5bad8d873bbc@gmail.com> Message-ID: Yasumasa, Looks good for me. I'll sponsor the push. -Dmitry On 2016-06-27 17:38, Yasumasa Suenaga wrote: > Hi all, > > This review request relates to JDK-8160310: HotSpot cannot be built with > GCC 6 . > > I encountered VM crash when I compiled OpenJDK 9 with GCC 6 > on Fedora 24 x64. > > This crash was occurred in fastdebug JVM which was built by GCC 6. > I'm not sure this crash relates to GCC 6, but I think NULL check should > be added > at this point. > > I uploaded webrev. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8160361/webrev.00/ > > > I'm jdk 9 committer, but I cannot access JPRT. > So I need a sponsor. > > > Thanks, > > Yasumasa > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yasuenag at gmail.com Mon Jun 27 15:05:33 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 28 Jun 2016 00:05:33 +0900 Subject: RFR: JDK-8160361: SEGV occurred at JNIHandleBlock::oops_do(OopClosure*) In-Reply-To: References: <6c0d9332-a49e-9cd4-7813-5bad8d873bbc@gmail.com> Message-ID: <587f9474-9df1-0f0a-5dbd-88a2ea9df3e9@gmail.com> Hi Dmitry, Thank you for reviewing! I'm waiting second reviewer. Yasumasa On 2016/06/28 0:01, Dmitry Samersoff wrote: > Yasumasa, > > Looks good for me. I'll sponsor the push. > > -Dmitry > > On 2016-06-27 17:38, Yasumasa Suenaga wrote: >> Hi all, >> >> This review request relates to JDK-8160310: HotSpot cannot be built with >> GCC 6 . >> >> I encountered VM crash when I compiled OpenJDK 9 with GCC 6 >> on Fedora 24 x64. >> >> This crash was occurred in fastdebug JVM which was built by GCC 6. >> I'm not sure this crash relates to GCC 6, but I think NULL check should >> be added >> at this point. >> >> I uploaded webrev. >> Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8160361/webrev.00/ >> >> >> I'm jdk 9 committer, but I cannot access JPRT. >> So I need a sponsor. >> >> >> Thanks, >> >> Yasumasa >> >> > > From dmitry.samersoff at oracle.com Mon Jun 27 15:07:58 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 27 Jun 2016 18:07:58 +0300 Subject: JDK-8160363: assert(discovered->is_oop_or_null()) failed: Expected an oop or NULL for discovered field at 0x0000000000000000 In-Reply-To: <450ea729-cc3f-9e83-0d83-07e7a6a5ce4c@gmail.com> References: <450ea729-cc3f-9e83-0d83-07e7a6a5ce4c@gmail.com> Message-ID: <82c67779-f9a0-d81b-c914-38df0ebebe76@oracle.com> Yasumasa, Statements below return this == NULL ? true : is_oop(ignore_mark_word); and return (this == NULL) || is_oop(ignore_mark_word); looks equivalent for me. -Dmitry On 2016-06-27 17:41, Yasumasa Suenaga wrote: > Hi all, > > This review request relates to JDK-8160310: HotSpot cannot be built with > GCC 6 . > > I encountered VM crash when I compiled OpenJDK 9 with GCC 6 > on Fedora 24 x64. > > Address of pointer was expected (0x0), however is_oop_or_null() did not > work. > I do not understand why current code did not work, however it works fine > as below: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8160363/webrev.00/ > > > Please discuss about it. > > > Thanks, > > Yasumasa > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yasuenag at gmail.com Mon Jun 27 15:17:31 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 28 Jun 2016 00:17:31 +0900 Subject: JDK-8160363: assert(discovered->is_oop_or_null()) failed: Expected an oop or NULL for discovered field at 0x0000000000000000 In-Reply-To: <82c67779-f9a0-d81b-c914-38df0ebebe76@oracle.com> References: <450ea729-cc3f-9e83-0d83-07e7a6a5ce4c@gmail.com> <82c67779-f9a0-d81b-c914-38df0ebebe76@oracle.com> Message-ID: 2016/06/28 0:08 "Dmitry Samersoff" : > > Yasumasa, > > Statements below > > return this == NULL ? true : is_oop(ignore_mark_word); > > and > > return (this == NULL) || is_oop(ignore_mark_word); > > looks equivalent for me. Me too. But return this == NULL ? true : is_oop(ignore_mark_word); does not work... Yasumasa > -Dmitry > > On 2016-06-27 17:41, Yasumasa Suenaga wrote: > > Hi all, > > > > This review request relates to JDK-8160310: HotSpot cannot be built with > > GCC 6 . > > > > I encountered VM crash when I compiled OpenJDK 9 with GCC 6 > > on Fedora 24 x64. > > > > Address of pointer was expected (0x0), however is_oop_or_null() did not > > work. > > I do not understand why current code did not work, however it works fine > > as below: > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8160363/webrev.00/ > > > > > > Please discuss about it. > > > > > > Thanks, > > > > Yasumasa > > > > > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From thomas.schatzl at oracle.com Mon Jun 27 15:17:42 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 27 Jun 2016 17:17:42 +0200 Subject: RFR: JDK-8160361: SEGV occurred at JNIHandleBlock::oops_do(OopClosure*) In-Reply-To: <6c0d9332-a49e-9cd4-7813-5bad8d873bbc@gmail.com> References: <6c0d9332-a49e-9cd4-7813-5bad8d873bbc@gmail.com> Message-ID: <1467040662.2352.52.camel@oracle.com> Hi, On Mon, 2016-06-27 at 23:38 +0900, Yasumasa Suenaga wrote: > Hi all, > > This review request relates to JDK-8160310: HotSpot cannot be built > with GCC 6 . > > I encountered VM crash when I compiled OpenJDK 9 with GCC 6 > on Fedora 24 x64. > > This crash was occurred in fastdebug JVM which was built by GCC 6. > I'm not sure this crash relates to GCC 6, but I think NULL check > should be added > at this point. > > I uploaded webrev. > Could you review it? > > ???http://cr.openjdk.java.net/~ysuenaga/JDK-8160361/webrev.00/ > > > I'm jdk 9 committer, but I cannot access JPRT. > So I need a sponsor. ? looks good to me. Not sure why it did not crash earlier, as the _handles member has always been allowed to be NULL (from what I understand). Thanks, ? Thomas From dmitry.samersoff at oracle.com Mon Jun 27 15:22:05 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 27 Jun 2016 18:22:05 +0300 Subject: JDK-8160363: assert(discovered->is_oop_or_null()) failed: Expected an oop or NULL for discovered field at 0x0000000000000000 In-Reply-To: References: <450ea729-cc3f-9e83-0d83-07e7a6a5ce4c@gmail.com> <82c67779-f9a0-d81b-c914-38df0ebebe76@oracle.com> Message-ID: <0973b749-642e-21bf-e91c-31c2117028ad@oracle.com> Yasumasa, Do you have a reproducer? Could you try to compile this unit with gcc -Wa,-adhln and see what compiler actually generates. -Dmitry On 2016-06-27 18:17, Yasumasa Suenaga wrote: > 2016/06/28 0:08 "Dmitry Samersoff" : >> >> Yasumasa, >> >> Statements below >> >> return this == NULL ? true : is_oop(ignore_mark_word); >> >> and >> >> return (this == NULL) || is_oop(ignore_mark_word); >> >> looks equivalent for me. > > Me too. > But return this == NULL ? true : is_oop(ignore_mark_word); does not work... > > Yasumasa > >> -Dmitry >> >> On 2016-06-27 17:41, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> This review request relates to JDK-8160310: HotSpot cannot be built with >>> GCC 6 . >>> >>> I encountered VM crash when I compiled OpenJDK 9 with GCC 6 >>> on Fedora 24 x64. >>> >>> Address of pointer was expected (0x0), however is_oop_or_null() did not >>> work. >>> I do not understand why current code did not work, however it works fine >>> as below: >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8160363/webrev.00/ >>> >>> >>> Please discuss about it. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yasuenag at gmail.com Mon Jun 27 15:25:16 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 28 Jun 2016 00:25:16 +0900 Subject: RFR: JDK-8160361: SEGV occurred at JNIHandleBlock::oops_do(OopClosure*) In-Reply-To: <1467040662.2352.52.camel@oracle.com> References: <6c0d9332-a49e-9cd4-7813-5bad8d873bbc@gmail.com> <1467040662.2352.52.camel@oracle.com> Message-ID: <8425c906-adad-d2c8-d16f-a48410346e89@gmail.com> Thanks Thomas! Yasumasa On 2016/06/28 0:17, Thomas Schatzl wrote: > Hi, > > On Mon, 2016-06-27 at 23:38 +0900, Yasumasa Suenaga wrote: >> Hi all, >> >> This review request relates to JDK-8160310: HotSpot cannot be built >> with GCC 6 . >> >> I encountered VM crash when I compiled OpenJDK 9 with GCC 6 >> on Fedora 24 x64. >> >> This crash was occurred in fastdebug JVM which was built by GCC 6. >> I'm not sure this crash relates to GCC 6, but I think NULL check >> should be added >> at this point. >> >> I uploaded webrev. >> Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8160361/webrev.00/ >> >> >> I'm jdk 9 committer, but I cannot access JPRT. >> So I need a sponsor. > > looks good to me. Not sure why it did not crash earlier, as the > _handles member has always been allowed to be NULL (from what I > understand). > > Thanks, > Thomas > From yasuenag at gmail.com Mon Jun 27 15:27:42 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 28 Jun 2016 00:27:42 +0900 Subject: JDK-8160363: assert(discovered->is_oop_or_null()) failed: Expected an oop or NULL for discovered field at 0x0000000000000000 In-Reply-To: <0973b749-642e-21bf-e91c-31c2117028ad@oracle.com> References: <450ea729-cc3f-9e83-0d83-07e7a6a5ce4c@gmail.com> <82c67779-f9a0-d81b-c914-38df0ebebe76@oracle.com> <0973b749-642e-21bf-e91c-31c2117028ad@oracle.com> Message-ID: <8b560735-b353-494e-fb48-5b7e0c941499@gmail.com> Hi Dmitry, You can reproduce this crash when building OpenJDK 9 on Fedora 24 x64. The crash always occurs on jmod process. Yasumasa On 2016/06/28 0:22, Dmitry Samersoff wrote: > Yasumasa, > > Do you have a reproducer? > > Could you try to compile this unit with > > gcc -Wa,-adhln > > and see what compiler actually generates. > > -Dmitry > > > > On 2016-06-27 18:17, Yasumasa Suenaga wrote: >> 2016/06/28 0:08 "Dmitry Samersoff" : >>> >>> Yasumasa, >>> >>> Statements below >>> >>> return this == NULL ? true : is_oop(ignore_mark_word); >>> >>> and >>> >>> return (this == NULL) || is_oop(ignore_mark_word); >>> >>> looks equivalent for me. >> >> Me too. >> But return this == NULL ? true : is_oop(ignore_mark_word); does not work... >> >> Yasumasa >> >>> -Dmitry >>> >>> On 2016-06-27 17:41, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> This review request relates to JDK-8160310: HotSpot cannot be built with >>>> GCC 6 . >>>> >>>> I encountered VM crash when I compiled OpenJDK 9 with GCC 6 >>>> on Fedora 24 x64. >>>> >>>> Address of pointer was expected (0x0), however is_oop_or_null() did not >>>> work. >>>> I do not understand why current code did not work, however it works fine >>>> as below: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8160363/webrev.00/ >>>> >>>> >>>> Please discuss about it. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>> >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. > > From zgu at redhat.com Mon Jun 27 16:03:14 2016 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 27 Jun 2016 12:03:14 -0400 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <576AA5E9.9040408@oracle.com> References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> Message-ID: <57714E42.7000406@redhat.com> Hi Lois, I have a question: classLoaderData.cpp # 1004 - 1013 If there is no class loader unloaded, (for example, _unloading == NULL), do you still need to execute this purge loop? Thanks, -Zhengyu On 06/22/2016 10:51 AM, Lois Foltan wrote: > > On 6/22/2016 8:56 AM, Alan Bateman wrote: >> >> >> On 22/06/2016 13:51, David Holmes wrote: >>> >>> How do you envisage any system classloader "dying" ?? >> The system class loader (be it the built-in application class loader >> or a custom system class loader configured via >> -Djava.system.class.loader) will/can never be GC'ed. >> ClassLoader.getSystemClassLoader() always returns a reference to it >> (for example). > Ahh, ok, I was being overly cautious, so no opportunity to reset the > system class loader dynamically at all? > SystemDictionary::_java_class_loader is not initialized until after > the module system initialization is complete. Due to this I have > updated my webrev to check for either the built-in application class > loader or a custom system class loader and have renamed the method to > is_system_class_loader(). > > http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/ > > Thanks, > Lois > From coleen.phillimore at oracle.com Mon Jun 27 17:00:51 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 27 Jun 2016 13:00:51 -0400 Subject: RFR: JDK-8160361: SEGV occurred at JNIHandleBlock::oops_do(OopClosure*) In-Reply-To: <6c0d9332-a49e-9cd4-7813-5bad8d873bbc@gmail.com> References: <6c0d9332-a49e-9cd4-7813-5bad8d873bbc@gmail.com> Message-ID: <5c01a838-2d65-0c08-d165-9539f37adc30@oracle.com> This looks good, thank you for fixing it. Thank you Dmitry for sponsoring it. Coleen On 6/27/16 10:38 AM, Yasumasa Suenaga wrote: > Hi all, > > This review request relates to JDK-8160310: HotSpot cannot be built > with GCC 6 . > > I encountered VM crash when I compiled OpenJDK 9 with GCC 6 > on Fedora 24 x64. > > This crash was occurred in fastdebug JVM which was built by GCC 6. > I'm not sure this crash relates to GCC 6, but I think NULL check > should be added > at this point. > > I uploaded webrev. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8160361/webrev.00/ > > > I'm jdk 9 committer, but I cannot access JPRT. > So I need a sponsor. > > > Thanks, > > Yasumasa > > From coleen.phillimore at oracle.com Mon Jun 27 17:02:28 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 27 Jun 2016 13:02:28 -0400 Subject: RFR: JDK-8160361: SEGV occurred at JNIHandleBlock::oops_do(OopClosure*) In-Reply-To: <8425c906-adad-d2c8-d16f-a48410346e89@gmail.com> References: <6c0d9332-a49e-9cd4-7813-5bad8d873bbc@gmail.com> <1467040662.2352.52.camel@oracle.com> <8425c906-adad-d2c8-d16f-a48410346e89@gmail.com> Message-ID: <7dbb8429-a4ca-a8f5-416f-3a02d9e4fbcc@oracle.com> On 6/27/16 11:25 AM, Yasumasa Suenaga wrote: > Thanks Thomas! > > Yasumasa > > On 2016/06/28 0:17, Thomas Schatzl wrote: >> Hi, >> >> On Mon, 2016-06-27 at 23:38 +0900, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> This review request relates to JDK-8160310: HotSpot cannot be built >>> with GCC 6 . >>> >>> I encountered VM crash when I compiled OpenJDK 9 with GCC 6 >>> on Fedora 24 x64. >>> >>> This crash was occurred in fastdebug JVM which was built by GCC 6. >>> I'm not sure this crash relates to GCC 6, but I think NULL check >>> should be added >>> at this point. >>> >>> I uploaded webrev. >>> Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8160361/webrev.00/ >>> >>> >>> I'm jdk 9 committer, but I cannot access JPRT. >>> So I need a sponsor. >> >> looks good to me. Not sure why it did not crash earlier, as the >> _handles member has always been allowed to be NULL (from what I >> understand). I was wondering this too. If there are no resolved_references, and now modules, it should be null. Maybe with modules, that's less likely? Coleen >> >> Thanks, >> Thomas >> From kim.barrett at oracle.com Mon Jun 27 17:23:57 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Jun 2016 13:23:57 -0400 Subject: JDK-8160310: HotSpot cannot be built with GCC 6 In-Reply-To: References: <39AC3517-8619-4E92-BB48-BB98ACA71349@oracle.com> <43d7a53e-ec53-f940-8e99-be1874fbc3d7@gmail.com> <929cfe33-d9de-cc0b-3090-e896dc59efbf@oracle.com> <4ba4ad31-9abe-ef39-18e0-3288ef1008d5@gmail.com> Message-ID: > On Jun 27, 2016, at 7:36 AM, David Holmes wrote: > > On 27/06/2016 8:25 PM, Yasumasa Suenaga wrote: >>> But these need to be broken up into individual problems. I don't mind >>> if the actual compilation warnings/errors are handled as a group. >> >> I think we can create several subtasks for this as below: > > Seems reasonable. > >> Group 1: narrowing conversion >> - altHashing.cpp >> - os_linux.cpp >> - type.cpp >> >> Group 2: uninitialized value (including assertion failure) >> - assembler_x86.cpp >> - interp_masm_x86.cpp >> - relocInfo.hpp >> - c1_Instruction.hpp >> >> Group 3: invalid suffix on literal >> - moduleEntry.cpp >> - packageEntry.cpp >> - preservedMarks.cpp >> >> Group 4: unnescessary assertion >> - node.cpp >> >> Group 5: potential for SEGV >> - classLoaderData.cpp > > Would like to know how gcc 6 relates to this one. > >> Group 6: refactoring for GCC 6 >> - oop.inline.hpp >> >> >> Is it okay? >> If so, I will create them as subtask of JDK-8160310 and send >> review request if possible. > > I'm okay with that. For the record, me too. That?s the kind of chunking I was asking for. > Thanks, > David From kim.barrett at oracle.com Mon Jun 27 17:34:15 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Jun 2016 13:34:15 -0400 Subject: JDK-8160310: HotSpot cannot be built with GCC 6 In-Reply-To: <10a8bea0-5be5-f06f-fbc6-89d73c1ff490@oracle.com> References: <39AC3517-8619-4E92-BB48-BB98ACA71349@oracle.com> <43d7a53e-ec53-f940-8e99-be1874fbc3d7@gmail.com> <929cfe33-d9de-cc0b-3090-e896dc59efbf@oracle.com> <10a8bea0-5be5-f06f-fbc6-89d73c1ff490@oracle.com> Message-ID: > On Jun 27, 2016, at 12:31 AM, David Holmes wrote: > the missing spaces around "PTR_FORMAT" (how did they creep back in??). We don?t have any mechanical check for it, and it?s easy to miss in a review. I looked into using gcc?s -Wliteral-suffix to catch these, but it seemed that option was being ignored when not in C++11 or later mode. From kim.barrett at oracle.com Mon Jun 27 18:12:14 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Jun 2016 14:12:14 -0400 Subject: RFR: JDK-8160353: narrowing conversion error is occurred with GCC 6 In-Reply-To: References: Message-ID: > On Jun 27, 2016, at 10:26 AM, Yasumasa Suenaga wrote: > > Hi all, > > This review request relates to JDK-8160310: HotSpot cannot be built with GCC 6 . > > I encountered narrowing conversion error when I compiled OpenJDK 9 with GCC 6 > on Fedora 24 x64. > I think these error should be fixed. > > I uploaded webrev. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8160353/webrev.00/ The warnings being encountered here are all a result of attempting to build a code base written for C++98 with a C++11 (or later) compiler. C++11 made an incompatible change to aggregate initialization, forbidding implicit narrowing conversions. A few months ago a change was made to explicitly use -std=gnu++98 for exactly this reason (see JDK-8151841), but that seems to have gotten lost in the transition to the new build system (see JDK-8156980). I would prefer that compiler configuration issue got fixed and these kinds of issues be deferred to a future modernization project. From kim.barrett at oracle.com Mon Jun 27 18:24:31 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Jun 2016 14:24:31 -0400 Subject: RFR: JDK-8160361: SEGV occurred at JNIHandleBlock::oops_do(OopClosure*) In-Reply-To: <7dbb8429-a4ca-a8f5-416f-3a02d9e4fbcc@oracle.com> References: <6c0d9332-a49e-9cd4-7813-5bad8d873bbc@gmail.com> <1467040662.2352.52.camel@oracle.com> <8425c906-adad-d2c8-d16f-a48410346e89@gmail.com> <7dbb8429-a4ca-a8f5-416f-3a02d9e4fbcc@oracle.com> Message-ID: <6E29EB26-1E0C-47FA-B82C-982CC9E6E37D@oracle.com> > On Jun 27, 2016, at 1:02 PM, Coleen Phillimore wrote: > > > > On 6/27/16 11:25 AM, Yasumasa Suenaga wrote: >> Thanks Thomas! >> >> Yasumasa >> >> On 2016/06/28 0:17, Thomas Schatzl wrote: >>> Hi, >>> >>> On Mon, 2016-06-27 at 23:38 +0900, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> This review request relates to JDK-8160310: HotSpot cannot be built >>>> with GCC 6 . >>>> >>>> I encountered VM crash when I compiled OpenJDK 9 with GCC 6 >>>> on Fedora 24 x64. >>>> >>>> This crash was occurred in fastdebug JVM which was built by GCC 6. >>>> I'm not sure this crash relates to GCC 6, but I think NULL check >>>> should be added >>>> at this point. >>>> >>>> I uploaded webrev. >>>> Could you review it? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8160361/webrev.00/ >>>> >>>> >>>> I'm jdk 9 committer, but I cannot access JPRT. >>>> So I need a sponsor. >>> >>> looks good to me. Not sure why it did not crash earlier, as the >>> _handles member has always been allowed to be NULL (from what I >>> understand). > > I was wondering this too. If there are no resolved_references, and now modules, it should be null. Maybe with modules, that's less likely? Me too. The suggested change seems correct, but I?m concerned there?s something we're missing. How did the existing code ever work, and what changed so that the reported error occurred? > Coleen > >>> >>> Thanks, >>> Thomas From kim.barrett at oracle.com Mon Jun 27 18:58:40 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Jun 2016 14:58:40 -0400 Subject: JDK-8160357: assert(_in == (Node**)this) failed: Must not pass arg count to 'new' In-Reply-To: <75da501b-a025-d3bd-388f-d56cfe3dad99@gmail.com> References: <0f7f885a-f573-3583-b6b7-5b85f3a12887@oracle.com> <75da501b-a025-d3bd-388f-d56cfe3dad99@gmail.com> Message-ID: > On Jun 27, 2016, at 10:57 AM, Yasumasa Suenaga wrote: > >> I see only space changes in a webrev below. > > Sorry, I wrote incorrect URL. > Please see as below: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8160357/webrev.00/ The change consists of: src/share/vm/opto/node.cpp remove: 329 assert( _in == (Node**)this, "Must not pass arg count to 'new'" ); This assertion is being tripped because gcc6 is removing the relevant assignment from Node::operator new: inline void* operator new(size_t x) throw() { Compile* C = Compile::current(); Node* n = (Node*)C->node_arena()->Amalloc_D(x); #ifdef ASSERT n->_in = (Node**)n; // magic cookie for assertion check #endif return (void*)n; } That assignment of n->_in is, in this context, undefined behavior. This was reported by Andrew Hughes back in March 2016. http://mail.openjdk.java.net/pipermail/build-dev/2016-March/016767.html This particular problem was suppose to have been worked around by https://bugs.openjdk.java.net/browse/JDK-8151841 which added -fno-lifetime-dse when building with gcc 6 or later. Maybe that got lost in the switch to the new build system? Hm, https://bugs.openjdk.java.net/browse/JDK-8157358 might be relevant. From kim.barrett at oracle.com Mon Jun 27 19:20:26 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Jun 2016 15:20:26 -0400 Subject: JDK-8160357: assert(_in == (Node**)this) failed: Must not pass arg count to 'new' In-Reply-To: References: <0f7f885a-f573-3583-b6b7-5b85f3a12887@oracle.com> <75da501b-a025-d3bd-388f-d56cfe3dad99@gmail.com> Message-ID: <838F90DD-3CA6-4E88-ADD9-84C1F8B52C12@oracle.com> > On Jun 27, 2016, at 2:58 PM, Kim Barrett wrote: > inline void* operator new(size_t x) throw() { > Compile* C = Compile::current(); > Node* n = (Node*)C->node_arena()->Amalloc_D(x); > #ifdef ASSERT > n->_in = (Node**)n; // magic cookie for assertion check > #endif > return (void*)n; > } > > That assignment of n->_in is, in this context, undefined behavior. > This was reported by Andrew Hughes back in March 2016. > http://mail.openjdk.java.net/pipermail/build-dev/2016-March/016767.html I thought there was a bug report for this undefined behavior, but I haven?t been able to find it. From karen.kinnear at oracle.com Mon Jun 27 19:46:38 2016 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 27 Jun 2016 15:46:38 -0400 Subject: RFR: 8038332: The trace event vm/class/load is not always being sent In-Reply-To: <4ba09865-4af1-201d-c5b0-56a5d822fa56@oracle.com> References: <5759AFCE.2080406@oracle.com> <575EF096.9020908@oracle.com> <95d4e379-2680-1e49-f972-831e4e1701ba@oracle.com> <57683F13.5070900@oracle.com> <642636BA-2185-482E-B022-A57002568FAA@oracle.com> <23a73321-9ad4-c49f-ba9d-841b0754e21c@oracle.com> <576AFCFE.3010504@oracle.com> <32997529-3e7c-53b0-bd84-d4519d1b2419@oracle.com> <576C2A5B.3020003@oracle.com> <3e2b9015-af5b-dace-395f-026fe89b6645@oracle.com> <4ba09865-4af1-201d-c5b0-56a5d822fa56@oracle.com> Message-ID: <4A995A5C-C11E-4277-81A0-AB48876A5B12@oracle.com> I asked Max to double check if we are getting two JFR events for code that uses resolve_instance_class_or_null and then calls resolve_from_stream when called by the class loader as part of JVM_DefineClass, which I believe is the common case for loading classes. I thought it made sense to record this where we post the jvmti load class event - and then remembered why Calvin and I didn?t do that to start with - with jvmti you would get a load class event for the defining loader and another one for the initiating loader, i.e. two events, each with a single class loader. Erik wanted to get a single event that contained both loaders, which is why we put this in resolve_instance_class_or_null. So today, this records vm class resolution. But that does miss the direct callers of loadClass (JVM_DefineClass), JNI_DefineClass and UnsafeDefineClass. I am still trying to figure out a clean and not to slow way to determine if we are already in resolve_instance_class_or_null. We do have a placeholder table entry, but it has a lookup by name/initiating class loader, and at JVM_DefineClass time we don?t know the initiating loader. Creative solutions welcome - my guess is we may have cases in which we print twice, even with creative filtering, but I would prefer to not have that be the common case. thanks, Karen > On Jun 23, 2016, at 5:37 PM, David Holmes wrote: > > Agreed! Good to use consistent code style in these related functions. > > Thanks, > David > > On 24/06/2016 5:32 AM, Coleen Phillimore wrote: >> >> This looks so much better. >> Thanks! >> Coleen >> >> On 6/23/16 2:28 PM, Max Ockner wrote: >>> Hello again! >>> >>> New webrev: http://cr.openjdk.java.net/~mockner/8038332.03/ >>> >>> Thanks, >>> Max >>> >>> >>> On 6/22/2016 10:53 PM, Coleen Phillimore wrote: >>>> >>>> >>>> On 6/22/16 5:02 PM, Ioi Lam wrote: >>>>> Instead of using Exceptions::_throw_msg directly, I think it's >>>>> better to use the macro >>>>> >>>>> THROW_MSG_NULL(vmSymbols::java_lang_SecurityException(), message); >>>>> >>>>> It will do the "return NULL" for you, so there's no danger of >>>>> forgetting doing it. >>>> >>> Done. >>> >>>> Agree. >>>> Coleen >>>>> >>>>> Thanks >>>>> - Ioi >>>>> >>>>> On 6/22/16 12:13 PM, Coleen Phillimore wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Can I suggest actually fixing this code? Please? >>>>>> >>>>>> Instead of returning THREAD in all the calls in parse_stream(), >>>>>> they should have CHECK_NULL. Then all the if >>>>>> (!HAS_PENDING_EXCEPTION) conditionals can be removed and the logic >>>>>> fixed. >>>>>> >>>>>> The only reason to have THREAD as the last parameter is if there's >>>>>> cleanup that needs to be done in the case of an exception, which is >>>>>> rare and I verified not the case in this function. >>>>>> >>>>>> After this code put a return NULL; >>>>>> >>>>>> Exceptions::_throw_msg(THREAD_AND_LOCATION, >>>>>> vmSymbols::java_lang_SecurityException(), message); >>>>>> // add return NULL; >>>>>> } >>>>>> >>>>>> Otherwise, the code to add the event looks good. >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> >>>>>> On 6/22/16 1:53 PM, Jiangli Zhou wrote: >>>>>>> Hi Max, >>>>>>> >>>>>>> I see there is already an ?if (!HAS_PENDING_EXCEPTION)? check at >>>>>>> line 1170 before the debug_only code. Maybe you cloud place the >>>>>>> post_class_load_event() in there so it only post the event when >>>>>>> there is no pending exception. That way you don?t need to change >>>>>>> the existing logic and add the additional checks. >>>>>>> >>>>>>> Thanks, >>>>>>> Jiangli >>>>>>> >>>>>>>> On Jun 20, 2016, at 12:08 PM, Max Ockner >>>>>>>> wrote: >>>>>>>> >>>>>>>> David, >>>>>>>> >>>>>>>> New webrev: >>>>>>>> http://cr.openjdk.java.net/~mockner/8038332.02/src/share/vm/classfile/systemDictionary.cpp.cdiff.html >>>>>>>> >>>>>>>> I have added the check you suggested before triggering the event: >>>>>>>> >>>>>>>> if (HAS_PENDING_EXCEPTION || k.is_null()) { >>>>>>>> return NULL; >>>>>>>> } >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>>>>> >>>>>>>> On 6/13/2016 6:40 PM, David Holmes wrote: >>>>>>>>> Hi Max, >>>>>>>>> >>>>>>>>> On 14/06/2016 3:42 AM, Max Ockner wrote: >>>>>>>>>> Jiangli, >>>>>>>>>> Thanks for looking. I didn't see anything that looked like it >>>>>>>>>> might >>>>>>>>>> produce duplicate events. However, I did see some additional >>>>>>>>>> places >>>>>>>>>> where it looks like no event is fire. >>>>>>>>>> >>>>>>>>>> Can anyone point me to the event specs? >>>>>>>>> I'm not sure there is any spec for this. Even JFR doesn't seem >>>>>>>>> to document individual events and when they are triggered. >>>>>>>>> >>>>>>>>> Your change does not look right however as you are posting the >>>>>>>>> classload event regardless of the exception state. If you look >>>>>>>>> at SystemDictionary::resolve_instance_class_or_null, it only >>>>>>>>> posts after checking the load was successful: >>>>>>>>> >>>>>>>>> 892 if (HAS_PENDING_EXCEPTION || k.is_null()) { >>>>>>>>> 893 return NULL; >>>>>>>>> 894 } >>>>>>>>> 895 >>>>>>>>> 896 post_class_load_event(class_load_start_time, k, >>>>>>>>> class_loader); >>>>>>>>> >>>>>>>>> Similarly, SystemDictionary::parse_stream, has various CHECK >>>>>>>>> macros that will cause a return on exception, prior to getting >>>>>>>>> to the point of posting the load event. So you also need to add >>>>>>>>> a check for a pending exception and that k is not null, I think, >>>>>>>>> before posting the event. >>>>>>>>> >>>>>>>> I have added this check. >>>>>>>>> BTW I would have expected to see trace-events generated at >>>>>>>>> approximately the same locations as the corresponding JVMTI >>>>>>>>> events. That does not seem to be the case which seems very >>>>>>>>> strange to me. The notion of "loading a class" seems to be >>>>>>>>> spread across far too many functions to me. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Max >>>>>>>>>> >>>>>>>>>> On 6/9/2016 4:39 PM, Jiangli Zhou wrote: >>>>>>>>>>> Hi Max, >>>>>>>>>>> >>>>>>>>>>> Looks ok. The only possible issue is more than one event might >>>>>>>>>>> be sent >>>>>>>>>>> in some of the call paths. But my quick search didn?t find any >>>>>>>>>>> of such >>>>>>>>>>> case. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Jiangli >>>>>>>>>>> >>>>>>>>>>>> On Jun 9, 2016, at 11:05 AM, Max Ockner >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> Please review this small fix which causes the vm/class/load >>>>>>>>>>>> event to >>>>>>>>>>>> be fired from JVM_DefineClass() and JVM_DefineClassWithSource(). >>>>>>>>>>>> >>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8038332/ >>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038332 >>>>>>>>>>>> >>>>>>>>>>>> The vm/class/load event (EventClassLoad) was previously >>>>>>>>>>>> fired in 2 >>>>>>>>>>>> places: >>>>>>>>>>>> >>>>>>>>>>>> SystemDictionary::parse_stream >>>>>>>>>>>> SystemDictionary::resolve_instance_class_or_null >>>>>>>>>>>> >>>>>>>>>>>> parse_stream is the standard option for creating a klass from a >>>>>>>>>>>> stream, but JVM_DefineClass uses a different function: >>>>>>>>>>>> >>>>>>>>>>>> SystemDictionary::resolve_from_stream. >>>>>>>>>>>> >>>>>>>>>>>> This did not fire a vm/class/load event. Now it does fire the >>>>>>>>>>>> event. >>>>>>>>>>>> >>>>>>>>>>>> Sanity tested with jtreg runtime. Issue was reproduced and >>>>>>>>>>>> tested >>>>>>>>>>>> using the reproducer script attached to the bug >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Max >>>>>> >>>>> >>>> >>> >> From kim.barrett at oracle.com Mon Jun 27 20:24:43 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Jun 2016 16:24:43 -0400 Subject: JDK-8160363: assert(discovered->is_oop_or_null()) failed: Expected an oop or NULL for discovered field at 0x0000000000000000 In-Reply-To: <450ea729-cc3f-9e83-0d83-07e7a6a5ce4c@gmail.com> References: <450ea729-cc3f-9e83-0d83-07e7a6a5ce4c@gmail.com> Message-ID: <9E3C98EC-BB9F-47AF-88C6-50FB07CB6D51@oracle.com> > On Jun 27, 2016, at 10:41 AM, Yasumasa Suenaga wrote: > > Hi all, > > This review request relates to JDK-8160310: HotSpot cannot be built with GCC 6 . > > I encountered VM crash when I compiled OpenJDK 9 with GCC 6 > on Fedora 24 x64. > > Address of pointer was expected (0x0), however is_oop_or_null() did not work. > I do not understand why current code did not work, however it works fine as below: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8160363/webrev.00/ The change consists of: src/share/vm/oops/oop.inline.hpp 542 return this == NULL ? true : is_oop(ignore_mark_word); replaced by 542 return (this == NULL) || is_oop(ignore_mark_word); The expression "this == NULL" can be assumed to be false, since invocation of the member function on a null pointer is undefined behavior. I have no idea why the code change affects behavior. I would expect in either case that this would be treated as just calling is_oop. Indeed, the whole concept of is_oop_or_null seems broken. I filed: https://bugs.openjdk.java.net/browse/JDK-8160399 I suspect this problem is also arising due to the missing build system changes for gcc 6 from Andrew Hughes that I mentioned in the discussion of JDK-8160357. I suspect a missing -fno-delete-null-pointer-checks is the problem here. From kim.barrett at oracle.com Mon Jun 27 20:29:46 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Jun 2016 16:29:46 -0400 Subject: JDK 9 build with GCC 6.1.1 In-Reply-To: <5770D888.6080501@redhat.com> References: <29abf149-0dc7-c137-6a57-30fc66ed5906@gmail.com> <9b6ee147-b24a-5f6f-9b1a-e18decb39b15@oracle.com> <5770D888.6080501@redhat.com> Message-ID: > On Jun 27, 2016, at 3:40 AM, Andrew Haley wrote: > > On 27/06/16 00:25, David Holmes wrote: >> Not sure how the crash relates to the gcc 6.6.1 compilation issues. > > Maybe it's related to -fno-delete-null-pointer-checks and HotSpot's > habit of dereferencing null pointers. I made a start on some of these > issues but ran out of time and enthusiasm. It'd be great to have a > campaign to get rid of HotSpot's undefined behaviour. > > Andrew. I think some of these may be a result of the new build system seeming to have broken or lost some of the changes from Andrew Hughes: http://mail.openjdk.java.net/pipermail/build-dev/2016-March/016767.html https://bugs.openjdk.java.net/browse/JDK-8151841 This might be relevant: https://bugs.openjdk.java.net/browse/JDK-8157358 From david.holmes at oracle.com Mon Jun 27 20:43:19 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Jun 2016 06:43:19 +1000 Subject: JDK 9 build with GCC 6.1.1 In-Reply-To: <577111F6.7000905@redhat.com> References: <29abf149-0dc7-c137-6a57-30fc66ed5906@gmail.com> <9b6ee147-b24a-5f6f-9b1a-e18decb39b15@oracle.com> <5770D888.6080501@redhat.com> <80abfc4e-59c5-40d0-1e1f-a6d76aea992d@oracle.com> <577111F6.7000905@redhat.com> Message-ID: On 27/06/2016 9:45 PM, Andrew Haley wrote: > On 27/06/16 12:32, David Holmes wrote: >> I wasn't aware that we have any reliance on gcc doing any kind of "null >> pointer check" ?? > > Ah, right, I assumed you'd seen this before. > > If GCC sees something like > > a->foo(); > if (a) { > b(); > } > > it will turn it into > > a->foo(); > b(); > > This surprises some people, but is quite legal. Okay. So I know I was initially surprised we have code that can do: a->foo(); when a is NULL, but that is because it is actually compiled as: foo(a); IIRC foo() has a "if (this != NULL)" check internally. I'm kind of surprised that the compiler itself seems to think a->foo() implies a is not NULL. I also hope it either is extremely smart about this or else very conservative. Would want it to make a mess of this: if (init(&a) != NULL) { a->foo(); } else { log(...); } if (a) a->bar(); Cheers, David > Andrew. > > From lois.foltan at oracle.com Mon Jun 27 20:50:31 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 27 Jun 2016 16:50:31 -0400 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <57714E42.7000406@redhat.com> References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <57714E42.7000406@redhat.com> Message-ID: <57719197.5030305@oracle.com> On 6/27/2016 12:03 PM, Zhengyu Gu wrote: > Hi Lois, > > I have a question: > > classLoaderData.cpp # 1004 - 1013 > > If there is no class loader unloaded, (for example, _unloading == > NULL), do you still need to execute this purge loop? Hi Zhengyu, Thank you for the review. I have addressed your concern by moving the purge loop into the following conditional that only executes "if (seen_dead_loader)", nice catch. This updated webrev also contains an improvement to the test ModuleStress.java to include a module defined to a custom system class loader, specified via -Djava.system.class.loader. http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.2/webrev/ Thanks, Lois > > Thanks, > > -Zhengyu > > On 06/22/2016 10:51 AM, Lois Foltan wrote: >> >> On 6/22/2016 8:56 AM, Alan Bateman wrote: >>> >>> >>> On 22/06/2016 13:51, David Holmes wrote: >>>> >>>> How do you envisage any system classloader "dying" ?? >>> The system class loader (be it the built-in application class loader >>> or a custom system class loader configured via >>> -Djava.system.class.loader) will/can never be GC'ed. >>> ClassLoader.getSystemClassLoader() always returns a reference to it >>> (for example). >> Ahh, ok, I was being overly cautious, so no opportunity to reset the >> system class loader dynamically at all? >> SystemDictionary::_java_class_loader is not initialized until after >> the module system initialization is complete. Due to this I have >> updated my webrev to check for either the built-in application class >> loader or a custom system class loader and have renamed the method to >> is_system_class_loader(). >> >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/ >> >> Thanks, >> Lois >> > From coleen.phillimore at oracle.com Mon Jun 27 21:41:27 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 27 Jun 2016 17:41:27 -0400 Subject: RFR: JDK-8160361: SEGV occurred at JNIHandleBlock::oops_do(OopClosure*) In-Reply-To: <6E29EB26-1E0C-47FA-B82C-982CC9E6E37D@oracle.com> References: <6c0d9332-a49e-9cd4-7813-5bad8d873bbc@gmail.com> <1467040662.2352.52.camel@oracle.com> <8425c906-adad-d2c8-d16f-a48410346e89@gmail.com> <7dbb8429-a4ca-a8f5-416f-3a02d9e4fbcc@oracle.com> <6E29EB26-1E0C-47FA-B82C-982CC9E6E37D@oracle.com> Message-ID: On 6/27/16 2:24 PM, Kim Barrett wrote: >> On Jun 27, 2016, at 1:02 PM, Coleen Phillimore wrote: >> >> >> >> On 6/27/16 11:25 AM, Yasumasa Suenaga wrote: >>> Thanks Thomas! >>> >>> Yasumasa >>> >>> On 2016/06/28 0:17, Thomas Schatzl wrote: >>>> Hi, >>>> >>>> On Mon, 2016-06-27 at 23:38 +0900, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> This review request relates to JDK-8160310: HotSpot cannot be built >>>>> with GCC 6 . >>>>> >>>>> I encountered VM crash when I compiled OpenJDK 9 with GCC 6 >>>>> on Fedora 24 x64. >>>>> >>>>> This crash was occurred in fastdebug JVM which was built by GCC 6. >>>>> I'm not sure this crash relates to GCC 6, but I think NULL check >>>>> should be added >>>>> at this point. >>>>> >>>>> I uploaded webrev. >>>>> Could you review it? >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8160361/webrev.00/ >>>>> >>>>> >>>>> I'm jdk 9 committer, but I cannot access JPRT. >>>>> So I need a sponsor. >>>> looks good to me. Not sure why it did not crash earlier, as the >>>> _handles member has always been allowed to be NULL (from what I >>>> understand). >> I was wondering this too. If there are no resolved_references, and now modules, it should be null. Maybe with modules, that's less likely? > Me too. The suggested change seems correct, but I?m concerned there?s > something we're missing. How did the existing code ever work, and what > changed so that the reported error occurred? It's the code in JNIHandleBlock::oops_do that's called for this, and NULL just quick exits. Add this code: 145 if (_handles == NULL) { 146 tty->print_cr("NULL"); 147 } 148 _handles->oops_do(f); break at 146 then trace: 146 tty->print_cr("NULL"); (gdb) n NULL 148 _handles->oops_do(f); (gdb) s JNIHandleBlock::oops_do (this=0x0, f=0x7fff28000ed8) at /home/cphillim/hg.local/jdk9.redef029/hotspot/src/share/vm/runtime/jniHandles.cpp:350 350 void JNIHandleBlock::oops_do(OopClosure* f) { (gdb) 351 JNIHandleBlock* current_chain = this; (gdb) 354 while (current_chain != NULL) { (gdb) 375 } The change is still an improvement, but now the question is why does it crash with GCC 6. thanks, Coleen > >> Coleen >> >>>> Thanks, >>>> Thomas > From kim.barrett at oracle.com Mon Jun 27 21:49:53 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Jun 2016 17:49:53 -0400 Subject: RFR: JDK-8160361: SEGV occurred at JNIHandleBlock::oops_do(OopClosure*) In-Reply-To: References: <6c0d9332-a49e-9cd4-7813-5bad8d873bbc@gmail.com> <1467040662.2352.52.camel@oracle.com> <8425c906-adad-d2c8-d16f-a48410346e89@gmail.com> <7dbb8429-a4ca-a8f5-416f-3a02d9e4fbcc@oracle.com> <6E29EB26-1E0C-47FA-B82C-982CC9E6E37D@oracle.com> Message-ID: <4F780641-39EF-4DEC-8A38-69934089B9E6@oracle.com> > On Jun 27, 2016, at 5:41 PM, Coleen Phillimore wrote: > 350 void JNIHandleBlock::oops_do(OopClosure* f) { > (gdb) > 351 JNIHandleBlock* current_chain = this; > (gdb) > 354 while (current_chain != NULL) { > (gdb) > 375 } > > > The change is still an improvement, but now the question is why does it crash with GCC 6. ?this? cannot be NULL, as to get there would require invoking undefined behavior. So the test can be elided on the first iteration? Thanks for tracking that down. Another one that I think would have been suppressed by the missing gcc6 options. So I think Yasumasa?s fix is good. > > thanks, > Coleen > >> >>> Coleen >>> >>>>> Thanks, >>>>> Thomas From kim.barrett at oracle.com Mon Jun 27 22:12:23 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Jun 2016 18:12:23 -0400 Subject: RFR: JDK-8160354: uninitialized value warning and VM crash are occurred with GCC 6 In-Reply-To: References: Message-ID: > On Jun 27, 2016, at 10:29 AM, Yasumasa Suenaga wrote: > > Hi all, > > This review request relates to JDK-8160310: HotSpot cannot be built with GCC 6 . > > I encountered 2 compiler warnings and 2 VM crashes when I compiled OpenJDK 9 with > GCC 6 on Fedora 24 x64. > I think these error should be fixed. > > I uploaded webrev. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8160354/webrev.00/ ------------------------------------------------------------------------------ src/share/vm/c1/c1_Instruction.hpp The problems here are similar to those JDK-8160357, e.g. casting uninitialized memory to a pointer to class type and treating it as such, without having first called the constructor. That's undefined behavior. The workaround is to use -fno-lifetime-dse when building with gcc 6. The code to do that seems to have been broken though. ------------------------------------------------------------------------------ src/cpu/x86/vm/assembler_x86.cpp 191 RelocationHolder rspec = (disp_reloc == relocInfo::none) 192 ? RelocationHolder::none 193 : rspec = Relocation::spec_simple(disp_reloc); I have no idea what is being attempted by this change, but I really doubt this is correct. The precedence of ?: is higher than the precedence of =. I think I see what might be going wrong with the original code. RelocationHolder has a _relocbuf member, which is really just storage for a Relocation object. The constructors for RelocationHolder are both problematic, but the no-arg constructor is the one at fault here. RelocationHolder::RelocationHolder() { new(*this) Relocation(); } This is constructing a different object over the current, which is undefined behavior, so gcc 6 is perhaps eliding it, leading to the failure. What this should actually be doing is using the start of the _relocbuf member as the placement new location. I suspect this is another case that would have been suppressed by the missing gcc6-specific build options. For the record, the other constructor is RelocationHolder::RelocationHolder(Relocation* r) { // wordwise copy from r (ok if it copies garbage after r) for (int i = 0; i < _relocbuf_size; i++) { _relocbuf[i] = ((void**)r)[i]; } } and that comment is just wrong, since the actual object could have been allocated close to the end of accessible memory, with a read beyond its real end potentially resulting in some kind of memory fault. I filed a bug for the RelocationHolder constructors: https://bugs.openjdk.java.net/browse/JDK-8160404 ------------------------------------------------------------------------------ src/share/vm/code/relocInfo.hpp 495 void* _relocbuf[ _relocbuf_size ] = {0}; I'm not sure why this might be needed, but I don't think this is valid C++98 code. I think this is actually using a C++14 feature. From kim.barrett at oracle.com Mon Jun 27 22:19:05 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Jun 2016 18:19:05 -0400 Subject: JDK 9 build with GCC 6.1.1 In-Reply-To: References: <29abf149-0dc7-c137-6a57-30fc66ed5906@gmail.com> <9b6ee147-b24a-5f6f-9b1a-e18decb39b15@oracle.com> <5770D888.6080501@redhat.com> <80abfc4e-59c5-40d0-1e1f-a6d76aea992d@oracle.com> <577111F6.7000905@redhat.com> Message-ID: <273DD208-175C-47EB-ABEF-98161849F0A9@oracle.com> > On Jun 27, 2016, at 4:43 PM, David Holmes wrote: > > On 27/06/2016 9:45 PM, Andrew Haley wrote: >> On 27/06/16 12:32, David Holmes wrote: >>> I wasn't aware that we have any reliance on gcc doing any kind of "null >>> pointer check" ?? >> >> Ah, right, I assumed you'd seen this before. >> >> If GCC sees something like >> >> a->foo(); >> if (a) { >> b(); >> } >> >> it will turn it into >> >> a->foo(); >> b(); >> >> This surprises some people, but is quite legal. > > Okay. So I know I was initially surprised we have code that can do: > > a->foo(); > > when a is NULL, but that is because it is actually compiled as: > > foo(a); > > IIRC foo() has a "if (this != NULL)" check internally. > > I'm kind of surprised that the compiler itself seems to think a->foo() implies a is not NULL. a->foo() is defined to be equivalent to (*a).foo(). Dereferencing a null pointer is undefined behavior... > > I also hope it either is extremely smart about this or else very conservative. Would want it to make a mess of this: > > if (init(&a) != NULL) { > a->foo(); > } > else { > log(...); > } > if (a) > a->bar(); > > Cheers, > David > >> Andrew. From kim.barrett at oracle.com Mon Jun 27 22:59:23 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Jun 2016 18:59:23 -0400 Subject: RFR: JDK-8160356: invalid suffix on literal warning is occurred with GCC 6 In-Reply-To: <96c1c5d9-403c-bdcf-4574-848a50b7521a@gmail.com> References: <96c1c5d9-403c-bdcf-4574-848a50b7521a@gmail.com> Message-ID: <6859BC03-4DAF-492F-AD5B-372819139A7A@oracle.com> > On Jun 27, 2016, at 10:30 AM, Yasumasa Suenaga wrote: > > Hi all, > > This review request relates to JDK-8160310: HotSpot cannot be built with GCC 6 . > > I encountered invalid suffix on literal when I compiled OpenJDK 9 with GCC 6 > on Fedora 24 x64. > I think these error should be fixed. > > I uploaded webrev. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8160356/webrev.00/ > > > I'm jdk 9 committer, but I cannot access JPRT. > So I need a sponsor. This looks good. However, I think this is an enhancement, as it wouldn?t be a problem if https://bugs.openjdk.java.net/browse/JDK-8156980 were fixed, so subject to a post-FC exemption or deferral to JDK 10. From kim.barrett at oracle.com Mon Jun 27 23:37:59 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Jun 2016 19:37:59 -0400 Subject: JDK 9 build with GCC 6.1.1 In-Reply-To: References: Message-ID: <57F3A28D-6FFD-45D6-B85C-1B5638CE29F4@oracle.com> > On Jun 25, 2016, at 9:57 AM, Yasumasa Suenaga wrote: > > Hi all, > > This review request relates to [1]. > > I've tried to build OpenJDK 9 at Fedora 24 x64. > Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. > > I fixed build error and several issues (VM crash and internal error) as below: > > http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ > > Does someone work for it? > If no one works for it, I will file it to JBS and will send review request. > > For jdk repos, I've sent review request [2]. > > > Thanks, > > Yasumasa > > > [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html > [2] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007081.html Having gone through these, I think all of them are arising due to build system problems, where we seem to have lost the compiler configuration to use explicit selection of the language standard and some additional options. For now I think we should fix the build system problems, and file additional bugs or update existing ones as needed to fix the root causes of the problems encountered. I think many of the proposed changes do not address the root causes, and should not be made. See my comments for the specific bugs. I'm not on the mailing list where the jdk RFR was submitted. I took a look at them though, and ------------------------------------------------------------------------------ make/lib/Awt2dLibraries.gmk 407 # Avoid warning for GCC 6 408 ifeq ($(TOOLCHAIN_TYPE), gcc) 409 LCMS_CFLAGS += -Wno-misleading-indentation 410 endif 926 # Avoid warning for GCC 6 927 ifeq ($(TOOLCHAIN_TYPE), gcc) 928 BUILD_LIBSPLASHSCREEN_jdhuff.c_CFLAGS += -Wno-shift-negative-value 929 BUILD_LIBSPLASHSCREEN_jdphuff.c_CFLAGS += -Wno-shift-negative-value 930 endif The -Wmisleading-indentation and -Wshift-negative-value options are new in gcc 6. gcc has for some time (starting with gcc 4.4) silently ignored unrecognized -Wno-XXX options. But some folks (like SAP) are still using older versions. So these will need to be conditionalized on the gcc version. ------------------------------------------------------------------------------ src/java.desktop/share/native/libfontmanager/layout/SunLayoutEngine.cpp 154 if (min < 0) min = 0; 155 if (max < min) max = min; /* defensive coding */ [splitting the line] Seems like this would be suppressed by -Wno-misleading-indentation, especially since the reported warning is for that. Why change both the code and the build configuration? ------------------------------------------------------------------------------ The changes in AlphaMath.c and splashscreen_jpeg.c look ok. From kim.barrett at oracle.com Tue Jun 28 00:10:10 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Jun 2016 20:10:10 -0400 Subject: RFR: JDK-8160354: uninitialized value warning and VM crash are occurred with GCC 6 In-Reply-To: References: Message-ID: <71663C28-C6C3-4B88-840D-35B07815828A@oracle.com> > On Jun 27, 2016, at 6:12 PM, Kim Barrett wrote: >> On Jun 27, 2016, at 10:29 AM, Yasumasa Suenaga wrote: >> >> Hi all, >> >> This review request relates to JDK-8160310: HotSpot cannot be built with GCC 6 . >> >> I encountered 2 compiler warnings and 2 VM crashes when I compiled OpenJDK 9 with >> GCC 6 on Fedora 24 x64. >> I think these error should be fixed. >> >> I uploaded webrev. >> Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8160354/webrev.00/ > > src/cpu/x86/vm/assembler_x86.cpp > 191 RelocationHolder rspec = (disp_reloc == relocInfo::none) > 192 ? RelocationHolder::none > 193 : rspec = Relocation::spec_simple(disp_reloc); > > I have no idea what is being attempted by this change, but I really > doubt this is correct. The precedence of ?: is higher than the > precedence of =. > > I think I see what might be going wrong with the original code. > > RelocationHolder has a _relocbuf member, which is really just storage > for a Relocation object. The constructors for RelocationHolder are > both problematic, but the no-arg constructor is the one at fault here. > > RelocationHolder::RelocationHolder() { > new(*this) Relocation(); > } > > This is constructing a different object over the current, which is > undefined behavior, so gcc 6 is perhaps eliding it, leading to the > failure. What this should actually be doing is using the start of the > _relocbuf member as the placement new location. No, that analysis is wrong. That isn't a placement new, it's new with another argument to the allocator, specifically this holder. I suspect the initialization of _relocbuf below might be related. > src/share/vm/code/relocInfo.hpp > 495 void* _relocbuf[ _relocbuf_size ] = {0}; > > I'm not sure why this might be needed, but I don't think this is valid > C++98 code. I think this is actually using a C++14 feature. From kim.barrett at oracle.com Tue Jun 28 01:21:12 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Jun 2016 21:21:12 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: Message-ID: <3C59F291-8A55-46A7-9ACC-DECCD1322484@oracle.com> > On Jun 27, 2016, at 9:01 AM, Coleen Phillimore wrote: > > > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.00/src/share/vm/memory/universe.cpp.udiff.html > > Do you need load_aquires and store_releases on set_reference_pending_list and has_reference_pending_list ? > > Or rather, why do you need an atomic operation in swap_pending_list if the Heap_lock is held? > > Aha, you answered the question in the header file. Yes, you found it. > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.00/src/share/vm/prims/jvm.cpp.udiff.html > > Can you change the boolean "wait" to "should_wait? ? Sure. Will be in the next webrev, if one is needed. > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.00/src/share/vm/runtime/thread.cpp.udiff.html > > This change in initialization order makes sense to me. We really need to preallocate OOM before initializing the system libraries. Since Throwable() doesn't check a property now, this is safe. I don't think this wasn't safe a few months ago. Throwable constructor should do as little as possible. I want to follow up on David?s question and try to figure out why the old order worked before we ensured InterruptedException was initialized by Reference. > Is the test that you're going to add from the other bug fix? ie. OomDebugTest.java (can that have a @bug 8156500 entry in it? OomDebugTest.java was borrowed from the proposed changes for JDK-8153711. I'm not including it with this change, because it requires something like the other changes for that bug, but when I ran tests with those changes I saw failures in other tests that were related to those changes. So that test is not yet ripe for pushing. > So many special cases removed! This is so nice. > > http://cr.openjdk.java.net/~kbarrett/8156500/jdk.00/src/java.base/share/classes/java/lang/ref/Reference.java.udiff.html > > Can you add to the popReferencePendingLIst comment that the pending list is managed by the GC, ie. gc enqueues and dequeues references to process? Or something like that? Sure. Added The GC adds references to the list, and notifies waiting threads when references are added. Will be in the next webrev, if one is needed. > > This is a really good change. Thanks for reviewing. From daniel.daugherty at oracle.com Tue Jun 28 01:34:15 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 27 Jun 2016 19:34:15 -0600 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: Message-ID: <10fd2944-4f2e-d2d1-d8d1-42752b687625@oracle.com> > Webrev: > http://cr.openjdk.java.net/~kbarrett/8156500/jdk.00/ make/mapfiles/libjava/mapfile-vers No comments. src/java.base/share/classes/java/lang/ref/Reference.java Much cleaner (pun might have been intended :-)). src/java.base/share/native/include/jvm.h No comments. src/java.base/share/native/libjava/Reference.c No comments. > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.00/ make/symbols/symbols-unix No comments. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java No comments. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/soql/sa.js No comments. src/share/vm/ci/ciReplay.cpp No comments. src/share/vm/classfile/javaClasses.cpp No comments. src/share/vm/classfile/javaClasses.hpp No comments. src/share/vm/compiler/compileBroker.cpp No comments. src/share/vm/gc/cms/concurrentMarkSweepThread.cpp So no more Surrogate Locker Thread (SLT)? Sound good to me. src/share/vm/gc/cms/vmCMSOperations.cpp No comments. src/share/vm/gc/cms/vmCMSOperations.hpp No comments. src/share/vm/gc/g1/concurrentMarkThread.cpp No comments. src/share/vm/gc/g1/g1CollectedHeap.hpp No comments. src/share/vm/gc/g1/vm_operations_g1.cpp No comments. src/share/vm/gc/g1/vm_operations_g1.hpp No comments. src/share/vm/gc/shared/collectedHeap.hpp No comments. src/share/vm/gc/shared/genCollectedHeap.hpp No comments. src/share/vm/gc/shared/referenceProcessor.cpp No comments. src/share/vm/gc/shared/referenceProcessor.hpp No comments. src/share/vm/gc/shared/vmGCOperations.cpp L103: Heap_lock->unlock(); You did not add a conditional "Heap_lock->notify_all()" before the Heap_lock->unlock() like you've done in other places. Since you deleted a release_and_notify_pending_list_lock() call, I would think you need the: if (Universe::has_reference_pending_list()) { Heap_lock->notify_all(); } src/share/vm/gc/shared/vmGCOperations.hpp No comments. src/share/vm/memory/universe.cpp No comments. src/share/vm/memory/universe.hpp No comments. src/share/vm/oops/method.cpp No comments. src/share/vm/prims/jvm.cpp No comments. src/share/vm/prims/jvm.h No comments. src/share/vm/runtime/thread.cpp So this change moves call_initPhase1() after the initialize_class() calls and that just sets off alarm bells in my head. Yes, you have a really big comment below explaining this. Still worries me! src/share/vm/runtime/vmStructs.cpp No comments. src/share/vm/gc/shared/referencePendingListLocker.cpp src/share/vm/gc/shared/referencePendingListLocker.hpp Both files are deleted and don't need review. Other than the possible missing notify_all() in vmGCOperations.cpp, this all looks great. Dan On 6/24/16 2:09 PM, Kim Barrett wrote: > Please review this change which moves the Reference pending list and > locking from the java.lang.ref.Reference class into the VM. This > includes elimination of the ReferencePendingListLocker mechanism in > the VM. This fixes various fragility issues arising from having the > management of this list split between Java and the VM (GC). > > This change addresses JDK-8156500 by eliminating the possibility of > suspension while holding the lock. Because the locking is now done in > the VM, we have full control over where suspension may occur. > > This change retains the existing interface between the reference > processor and the nio.Bits package, e.g. Reference.tryHandlePending > has the same signature and behavior; this change just pushes the > pending list manipulation down into the VM. There are open bugs > reports, enhancement requests, and discussions related to that > interface; see below. This change does not attempt to address them. > > This change additionally addresses or renders moot > https://bugs.openjdk.java.net/browse/JDK-8055232 > (ref) Exceptions while processing Reference pending list > > and > https://bugs.openjdk.java.net/browse/JDK-7103238 > Ensure pending list lock is held on behalf of GC before enqueuing references on to the pending list > > It is also relevant for followup discussion of > https://bugs.openjdk.java.net/browse/JDK-8022321 > java/lang/ref/OOMEInReferenceHandler.java fails immediately > > and > https://bugs.openjdk.java.net/browse/JDK-8149925 > We don't need jdk.internal.ref.Cleaner any more - part 1 > > and has implications for: > https://bugs.openjdk.java.net/browse/JDK-8066859 > java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died > > In addition to the obviously relevant changes, there are a couple of > changes whose presence here might seem surprising and require further > explanation. > > - Removal of a stale comment in create_vm, noticed because it was near > some code being removed as part of this change. The comment was > rendered obsolete by JDK-8028275. > > - Moved initialization of exception classes earlier in > initialize_java_lang_classes. The previous order only worked by > accident, at least for OOME. During the bulk of the library > initialization, OOME may be thrown, perhaps due to poorly chosen > command line options. That attempts to use one of the pre-allocated > OOME objects, and tries to fill in its stack trace. If the Throwable > class is not yet initialized, this leads to a failed assert in the VM > because Throwable.UNASSIGNED_STACK still has a null value. This > initialization order issue was being masked by the old pending list > implementation; the initialization of Reference ensured > InterruptedException was initialized (thereby initializing its > Throwable base class), and the initialization of Reference just > happened to occur early enough that Throwable was initialized by the > time it was needed when running certain tests. The forced > initialization of InterruptedException is no longer needed by > Reference, but removal of it triggered test failures (and could > trigger corresponding product failures) because of this ordering > issue. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8156500 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8156500/jdk.00/ > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.00/ > > Testing: > RBT ad hoc nightly runtime & gc tests. > > With the proposed patch for JDK-8153711 applied, locally ran nearly > 35K iterations of the OomDebugTest that is part of that patch, with no > failures / deadlocks. Without this change it would typically only take > on the order of 100 iterations to hit a deadlock failure. > > Locally ran direct byte buffer allocation test: > jdk/test/java/nio/Buffer/DirectBufferAllocTest.java > This change reported 3% faster allocation times, and 1/2 the standard > deviation for allocation times. > > Locally ran failing test from JDK-8022321 and JDK-8066859 a few > thousand times. > jdk/test/java/lang/ref/OOMEInReferenceHandler.java > No errors, but failures were noted as hard to reproduce. > From yasuenag at gmail.com Tue Jun 28 03:36:16 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 28 Jun 2016 12:36:16 +0900 Subject: RFR: JDK-8160353: narrowing conversion error is occurred with GCC 6 In-Reply-To: References: Message-ID: <7c5f113d-b5ae-2e49-ee7b-fb9a19227585@gmail.com> Hi Kim, > I would prefer that compiler configuration issue got fixed and these kinds of issues be deferred to a future modernization project. IMHO, src/os/linux/vm/os_linux.cpp should be fixed at least because elf_class and endianess is defined as unsigned char. In other point, I confirmed that we can avoid -std=gnu++98 as below: ----------- diff -r ba08710f3b6c make/lib/CompileJvm.gmk --- a/make/lib/CompileJvm.gmk Mon Jun 27 09:35:18 2016 +0200 +++ b/make/lib/CompileJvm.gmk Tue Jun 28 12:10:09 2016 +0900 @@ -187,6 +187,11 @@ JVM_OPTIMIZATION ?= HIGHEST_JVM +JVM_CXXFLAGS := $(JVM_CFLAGS) +ifeq ($(TOOLCHAIN_TYPE), gcc) + JVM_CXXFLAGS += -std=gnu++98 -fno-delete-null-pointer-checks -fno-lifetime-dse +endif + ################################################################################ # Now set up the actual compilation of the main hotspot native library @@ -202,6 +207,7 @@ CFLAGS := $(JVM_CFLAGS), \ CFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ CXXFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \ + CXXFLAGS := $(JVM_CXXFLAGS), \ vm_version.cpp_CXXFLAGS := $(CFLAGS_VM_VERSION), \ DISABLED_WARNINGS_clang := delete-non-virtual-dtor dynamic-class-memaccess \ empty-body format logical-op-parentheses parentheses \ ----------- Can I send this change as review request of JDK-8156980? Thanks, Yasumasa On 2016/06/28 3:12, Kim Barrett wrote: >> On Jun 27, 2016, at 10:26 AM, Yasumasa Suenaga wrote: >> >> Hi all, >> >> This review request relates to JDK-8160310: HotSpot cannot be built with GCC 6 . >> >> I encountered narrowing conversion error when I compiled OpenJDK 9 with GCC 6 >> on Fedora 24 x64. >> I think these error should be fixed. >> >> I uploaded webrev. >> Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8160353/webrev.00/ > > The warnings being encountered here are all a result of attempting to build a code base written for C++98 with a C++11 (or later) compiler. C++11 made an incompatible change to aggregate initialization, forbidding implicit narrowing conversions. A few months ago a change was made to explicitly use -std=gnu++98 for exactly this reason (see JDK-8151841), but that seems to have gotten lost in the transition to the new build system (see JDK-8156980). > > I would prefer that compiler configuration issue got fixed and these kinds of issues be deferred to a future modernization project. > From yasuenag at gmail.com Tue Jun 28 03:38:33 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 28 Jun 2016 12:38:33 +0900 Subject: JDK-8160357: assert(_in == (Node**)this) failed: Must not pass arg count to 'new' In-Reply-To: <838F90DD-3CA6-4E88-ADD9-84C1F8B52C12@oracle.com> References: <0f7f885a-f573-3583-b6b7-5b85f3a12887@oracle.com> <75da501b-a025-d3bd-388f-d56cfe3dad99@gmail.com> <838F90DD-3CA6-4E88-ADD9-84C1F8B52C12@oracle.com> Message-ID: Hi Kim, I can avoid this error with makefile fix in [1]. If [1] is merged, I want to stop to work for this issue. Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-June/023696.html On 2016/06/28 4:20, Kim Barrett wrote: >> On Jun 27, 2016, at 2:58 PM, Kim Barrett wrote: >> inline void* operator new(size_t x) throw() { >> Compile* C = Compile::current(); >> Node* n = (Node*)C->node_arena()->Amalloc_D(x); >> #ifdef ASSERT >> n->_in = (Node**)n; // magic cookie for assertion check >> #endif >> return (void*)n; >> } >> >> That assignment of n->_in is, in this context, undefined behavior. >> This was reported by Andrew Hughes back in March 2016. >> http://mail.openjdk.java.net/pipermail/build-dev/2016-March/016767.html > > I thought there was a bug report for this undefined behavior, but I haven?t been able to find it. > From yasuenag at gmail.com Tue Jun 28 03:39:35 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 28 Jun 2016 12:39:35 +0900 Subject: JDK-8160363: assert(discovered->is_oop_or_null()) failed: Expected an oop or NULL for discovered field at 0x0000000000000000 In-Reply-To: <9E3C98EC-BB9F-47AF-88C6-50FB07CB6D51@oracle.com> References: <450ea729-cc3f-9e83-0d83-07e7a6a5ce4c@gmail.com> <9E3C98EC-BB9F-47AF-88C6-50FB07CB6D51@oracle.com> Message-ID: <8e20163a-2b42-5580-2a13-e9ad83833338@gmail.com> Hi Kim, I can avoid this error with makefile fix in [1]. If [1] is merged, I want to stop to work for this issue. Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-June/023696.html On 2016/06/28 5:24, Kim Barrett wrote: >> On Jun 27, 2016, at 10:41 AM, Yasumasa Suenaga wrote: >> >> Hi all, >> >> This review request relates to JDK-8160310: HotSpot cannot be built with GCC 6 . >> >> I encountered VM crash when I compiled OpenJDK 9 with GCC 6 >> on Fedora 24 x64. >> >> Address of pointer was expected (0x0), however is_oop_or_null() did not work. >> I do not understand why current code did not work, however it works fine as below: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8160363/webrev.00/ > > The change consists of: > src/share/vm/oops/oop.inline.hpp > 542 return this == NULL ? true : is_oop(ignore_mark_word); > replaced by > 542 return (this == NULL) || is_oop(ignore_mark_word); > > The expression "this == NULL" can be assumed to be false, since > invocation of the member function on a null pointer is undefined > behavior. > > I have no idea why the code change affects behavior. I would expect > in either case that this would be treated as just calling is_oop. > Indeed, the whole concept of is_oop_or_null seems broken. I filed: > https://bugs.openjdk.java.net/browse/JDK-8160399 > > I suspect this problem is also arising due to the missing build system > changes for gcc 6 from Andrew Hughes that I mentioned in the > discussion of JDK-8160357. I suspect a missing > -fno-delete-null-pointer-checks is the problem here. > From yasuenag at gmail.com Tue Jun 28 03:43:33 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 28 Jun 2016 12:43:33 +0900 Subject: RFR: JDK-8160354: uninitialized value warning and VM crash are occurred with GCC 6 In-Reply-To: References: Message-ID: Hi Kim, On 2016/06/28 7:12, Kim Barrett wrote: >> On Jun 27, 2016, at 10:29 AM, Yasumasa Suenaga wrote: >> >> Hi all, >> >> This review request relates to JDK-8160310: HotSpot cannot be built with GCC 6 . >> >> I encountered 2 compiler warnings and 2 VM crashes when I compiled OpenJDK 9 with >> GCC 6 on Fedora 24 x64. >> I think these error should be fixed. >> >> I uploaded webrev. >> Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8160354/webrev.00/ > > ------------------------------------------------------------------------------ > src/share/vm/c1/c1_Instruction.hpp > > The problems here are similar to those JDK-8160357, e.g. casting > uninitialized memory to a pointer to class type and treating it as > such, without having first called the constructor. That's undefined > behavior. > > The workaround is to use -fno-lifetime-dse when building with gcc 6. > The code to do that seems to have been broken though. I can avoid this error with makefile fix in [1]. > ------------------------------------------------------------------------------ > src/cpu/x86/vm/assembler_x86.cpp > 191 RelocationHolder rspec = (disp_reloc == relocInfo::none) > 192 ? RelocationHolder::none > 193 : rspec = Relocation::spec_simple(disp_reloc); > > I have no idea what is being attempted by this change, but I really > doubt this is correct. The precedence of ?: is higher than the > precedence of =. Sorry, I will fix. > I think I see what might be going wrong with the original code. > > RelocationHolder has a _relocbuf member, which is really just storage > for a Relocation object. The constructors for RelocationHolder are > both problematic, but the no-arg constructor is the one at fault here. > > RelocationHolder::RelocationHolder() { > new(*this) Relocation(); > } > > This is constructing a different object over the current, which is > undefined behavior, so gcc 6 is perhaps eliding it, leading to the > failure. What this should actually be doing is using the start of the > _relocbuf member as the placement new location. > > I suspect this is another case that would have been suppressed by the > missing gcc6-specific build options. > > For the record, the other constructor is > > RelocationHolder::RelocationHolder(Relocation* r) { > // wordwise copy from r (ok if it copies garbage after r) > for (int i = 0; i < _relocbuf_size; i++) { > _relocbuf[i] = ((void**)r)[i]; > } > } > > and that comment is just wrong, since the actual object could have > been allocated close to the end of accessible memory, with a read > beyond its real end potentially resulting in some kind of memory > fault. > > I filed a bug for the RelocationHolder constructors: > https://bugs.openjdk.java.net/browse/JDK-8160404 > > ------------------------------------------------------------------------------ > src/share/vm/code/relocInfo.hpp > 495 void* _relocbuf[ _relocbuf_size ] = {0}; > > I'm not sure why this might be needed, but I don't think this is valid > C++98 code. I think this is actually using a C++14 feature. I fixed as below. It works fine. ---------- diff -r ba08710f3b6c src/share/vm/code/relocInfo.hpp --- a/src/share/vm/code/relocInfo.hpp Mon Jun 27 09:35:18 2016 +0200 +++ b/src/share/vm/code/relocInfo.hpp Tue Jun 28 12:10:09 2016 +0900 @@ -850,7 +850,7 @@ // certain inlines must be deferred until class Relocation is defined: -inline RelocationHolder::RelocationHolder() { +inline RelocationHolder::RelocationHolder() : _relocbuf() { // initialize the vtbl, just to keep things type-safe new(*this) Relocation(); } ---------- Should I start to work for it after [1] ? Or should I work for assembler_x86.cpp and relocInfo.hpp ? Yasumasa [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-June/023696.html From yasuenag at gmail.com Tue Jun 28 03:45:10 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 28 Jun 2016 12:45:10 +0900 Subject: RFR: JDK-8160356: invalid suffix on literal warning is occurred with GCC 6 In-Reply-To: <6859BC03-4DAF-492F-AD5B-372819139A7A@oracle.com> References: <96c1c5d9-403c-bdcf-4574-848a50b7521a@gmail.com> <6859BC03-4DAF-492F-AD5B-372819139A7A@oracle.com> Message-ID: Hi Kim, > However, I think this is an enhancement, as it wouldn?t be a problem if > https://bugs.openjdk.java.net/browse/JDK-8156980 > were fixed, so subject to a post-FC exemption or deferral to JDK 10. I want to add FC extention label to this issue. Can I add it now? Thanks, Yasumasa On 2016/06/28 7:59, Kim Barrett wrote: >> On Jun 27, 2016, at 10:30 AM, Yasumasa Suenaga wrote: >> >> Hi all, >> >> This review request relates to JDK-8160310: HotSpot cannot be built with GCC 6 . >> >> I encountered invalid suffix on literal when I compiled OpenJDK 9 with GCC 6 >> on Fedora 24 x64. >> I think these error should be fixed. >> >> I uploaded webrev. >> Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8160356/webrev.00/ >> >> >> I'm jdk 9 committer, but I cannot access JPRT. >> So I need a sponsor. > > This looks good. > > However, I think this is an enhancement, as it wouldn?t be a problem if > https://bugs.openjdk.java.net/browse/JDK-8156980 > were fixed, so subject to a post-FC exemption or deferral to JDK 10. > From yasuenag at gmail.com Tue Jun 28 03:50:33 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 28 Jun 2016 12:50:33 +0900 Subject: JDK 9 build with GCC 6.1.1 In-Reply-To: <57F3A28D-6FFD-45D6-B85C-1B5638CE29F4@oracle.com> References: <57F3A28D-6FFD-45D6-B85C-1B5638CE29F4@oracle.com> Message-ID: Hi Kim, The newest changes for jdk repos is [1]. Erik points we should use DISABLED_WARNINGS_gcc to handle unknown warning tags. [2] [1] is implemented with it. This change is already reviewed by 2d folks. So I want to merge it ASAP. Do you have any objection? Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007090.html [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004499.html On 2016/06/28 8:37, Kim Barrett wrote: >> On Jun 25, 2016, at 9:57 AM, Yasumasa Suenaga wrote: >> >> Hi all, >> >> This review request relates to [1]. >> >> I've tried to build OpenJDK 9 at Fedora 24 x64. >> Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. >> >> I fixed build error and several issues (VM crash and internal error) as below: >> >> http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ >> >> Does someone work for it? >> If no one works for it, I will file it to JBS and will send review request. >> >> For jdk repos, I've sent review request [2]. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html >> [2] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007081.html > > Having gone through these, I think all of them are arising due to > build system problems, where we seem to have lost the compiler > configuration to use explicit selection of the language standard and > some additional options. > > For now I think we should fix the build system problems, and file > additional bugs or update existing ones as needed to fix the root > causes of the problems encountered. I think many of the proposed > changes do not address the root causes, and should not be made. See > my comments for the specific bugs. > > I'm not on the mailing list where the jdk RFR was submitted. I took a > look at them though, and > > ------------------------------------------------------------------------------ > make/lib/Awt2dLibraries.gmk > 407 # Avoid warning for GCC 6 > 408 ifeq ($(TOOLCHAIN_TYPE), gcc) > 409 LCMS_CFLAGS += -Wno-misleading-indentation > 410 endif > > 926 # Avoid warning for GCC 6 > 927 ifeq ($(TOOLCHAIN_TYPE), gcc) > 928 BUILD_LIBSPLASHSCREEN_jdhuff.c_CFLAGS += -Wno-shift-negative-value > 929 BUILD_LIBSPLASHSCREEN_jdphuff.c_CFLAGS += -Wno-shift-negative-value > 930 endif > > The -Wmisleading-indentation and -Wshift-negative-value options are > new in gcc 6. gcc has for some time (starting with gcc 4.4) silently > ignored unrecognized -Wno-XXX options. But some folks (like SAP) are > still using older versions. So these will need to be conditionalized > on the gcc version. > > ------------------------------------------------------------------------------ > src/java.desktop/share/native/libfontmanager/layout/SunLayoutEngine.cpp > 154 if (min < 0) min = 0; > 155 if (max < min) max = min; /* defensive coding */ > > [splitting the line] > > Seems like this would be suppressed by -Wno-misleading-indentation, > especially since the reported warning is for that. Why change both > the code and the build configuration? > > ------------------------------------------------------------------------------ > > The changes in AlphaMath.c and splashscreen_jpeg.c look ok. > From david.holmes at oracle.com Tue Jun 28 04:04:20 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Jun 2016 14:04:20 +1000 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: Message-ID: Hi Kim, I like all the removal of the pending-list-locker related code, but can't really comment on the details of how it was replaced and interacts with all the GC code. The interface to the Reference class is fine, it is the GC code that pushes into the reference queue that I can't really comment on. I have a couple of queries following up from Coleen's and Dan's reviews. First, the synchronization of the pending-reference-list leaves me somewhat perplexed. As Coleen noted you require the heap_lock to be held but also use an Atomic::xchg. You have a comment: + // owns the lock. Swap is used by parallel non-concurrent reference + // processing threads, where some higher level controller owns + // Heap_lock, so requires the lock is locked, but not necessarily by + // the current thread. Can you clarify the higher-level protocol that is at play there. Asserting that "someone" owns a lock seems only marginally useful if you can't be sure who that owner is, or when they might release it. Some more direct detecting of being within this higher-level protocol would be better, if it is possible to detect. --- As previously mentioned the change to the initialization order is a concern to me - there are always unexpected consequences of making such changes, no matter how straight-forward they seem at the time. Pre-initialization of exception classes is not really essential as the attempt to throw any of them from Java code will force initialization anyway - it's only for exceptions created and thrown from the VM code that direct initialization is needed. The problematic case is OOME because throwing the OOME may trigger a secondary OOME during that class initialization etc. Hence we try to deal with that by pre-allocating instances that do not have stacktraces etc, so they can be thrown safely. Hence my earlier comment that I think the real bug in your situation is that gen_out_of_memory_error() is not considering how far into the VM init sequence we are, and that it should be returning the pre-allocated instance with no backtrace. --- A query on the JDK side: src/java.base/share/classes/java/lang/ref/Reference.java private static native Reference popReferencePendingList(boolean wait); I'm intrigued by the use of the lower-bounded wildcard using Object. As Object has no super-types this looks very strange and should be equivalent to the more common upper-bounded wildcard using Object ie Reference or more concisely Reference. I see this construct exists in the current code for the ReferenceQueue, but I am quite intrigued as to why? (Someone getting ready for Any-types? :) ) Thanks, David ----- On 25/06/2016 6:09 AM, Kim Barrett wrote: > Please review this change which moves the Reference pending list and > locking from the java.lang.ref.Reference class into the VM. This > includes elimination of the ReferencePendingListLocker mechanism in > the VM. This fixes various fragility issues arising from having the > management of this list split between Java and the VM (GC). > > This change addresses JDK-8156500 by eliminating the possibility of > suspension while holding the lock. Because the locking is now done in > the VM, we have full control over where suspension may occur. > > This change retains the existing interface between the reference > processor and the nio.Bits package, e.g. Reference.tryHandlePending > has the same signature and behavior; this change just pushes the > pending list manipulation down into the VM. There are open bugs > reports, enhancement requests, and discussions related to that > interface; see below. This change does not attempt to address them. > > This change additionally addresses or renders moot > https://bugs.openjdk.java.net/browse/JDK-8055232 > (ref) Exceptions while processing Reference pending list > > and > https://bugs.openjdk.java.net/browse/JDK-7103238 > Ensure pending list lock is held on behalf of GC before enqueuing references on to the pending list > > It is also relevant for followup discussion of > https://bugs.openjdk.java.net/browse/JDK-8022321 > java/lang/ref/OOMEInReferenceHandler.java fails immediately > > and > https://bugs.openjdk.java.net/browse/JDK-8149925 > We don't need jdk.internal.ref.Cleaner any more - part 1 > > and has implications for: > https://bugs.openjdk.java.net/browse/JDK-8066859 > java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died > > In addition to the obviously relevant changes, there are a couple of > changes whose presence here might seem surprising and require further > explanation. > > - Removal of a stale comment in create_vm, noticed because it was near > some code being removed as part of this change. The comment was > rendered obsolete by JDK-8028275. > > - Moved initialization of exception classes earlier in > initialize_java_lang_classes. The previous order only worked by > accident, at least for OOME. During the bulk of the library > initialization, OOME may be thrown, perhaps due to poorly chosen > command line options. That attempts to use one of the pre-allocated > OOME objects, and tries to fill in its stack trace. If the Throwable > class is not yet initialized, this leads to a failed assert in the VM > because Throwable.UNASSIGNED_STACK still has a null value. This > initialization order issue was being masked by the old pending list > implementation; the initialization of Reference ensured > InterruptedException was initialized (thereby initializing its > Throwable base class), and the initialization of Reference just > happened to occur early enough that Throwable was initialized by the > time it was needed when running certain tests. The forced > initialization of InterruptedException is no longer needed by > Reference, but removal of it triggered test failures (and could > trigger corresponding product failures) because of this ordering > issue. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8156500 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8156500/jdk.00/ > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.00/ > > Testing: > RBT ad hoc nightly runtime & gc tests. > > With the proposed patch for JDK-8153711 applied, locally ran nearly > 35K iterations of the OomDebugTest that is part of that patch, with no > failures / deadlocks. Without this change it would typically only take > on the order of 100 iterations to hit a deadlock failure. > > Locally ran direct byte buffer allocation test: > jdk/test/java/nio/Buffer/DirectBufferAllocTest.java > This change reported 3% faster allocation times, and 1/2 the standard > deviation for allocation times. > > Locally ran failing test from JDK-8022321 and JDK-8066859 a few > thousand times. > jdk/test/java/lang/ref/OOMEInReferenceHandler.java > No errors, but failures were noted as hard to reproduce. > From serguei.spitsyn at oracle.com Tue Jun 28 04:08:20 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Jun 2016 21:08:20 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule Message-ID: <5771F834.2020504@oracle.com> Please, review the Jigsaw fix for the enhancement: https://bugs.openjdk.java.net/browse/JDK-8159145 The Hotspot webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ The Jdk webrev is the same: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ Summary: This is the review round #3. Alan suggested to replace the function GetModuleByPackageName with the GetNamedModule. New function will return NULL if the package is not in a module defined to the class loader. It simplifies the API and makes it easier to specify. JVM TI agents that instrument code in named modules need the Module at class load time. One question that came from the function semantics change. I had to implement the Modules::get_named_module() from scratch independently of the existing Modules::get_module_by_package_name() and Modules::get_module(). The issue is that the Modules::get_module() can return the unnamed module whereas the JVMTI helper Modules::get_named_module() should return NULL instead of the unnamed module. Please, let me know if it is Ok or if you have better ideas how to share the code. This is the Summary from review round #1: One way to do this is by introducing a new ClassFileLoadHook that takes an additional parameter but this approach is disruptive. The alternative option is a JVM TI function that maps a classloader + package name to a module. We were initially not confident with this approach so we introduced it as JVM function JVM_GetModuleByPackageName. Based on experience to date then this approach seems okay and so this function needs to be promoted to a JVMTI function. It includes new jtreg test with native JVMTI agent. Testing: Run newly developed jtreg test. Thanks, Serguei From serguei.spitsyn at oracle.com Tue Jun 28 04:20:41 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Jun 2016 21:20:41 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <5771F834.2020504@oracle.com> References: <5771F834.2020504@oracle.com> Message-ID: <5771FB19.20009@oracle.com> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: > Please, review the Jigsaw fix for the enhancement: > https://bugs.openjdk.java.net/browse/JDK-8159145 > > > The Hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ > > > The Jdk webrev is the same: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ Sorry, the Jdk webrev changed as well: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ Thanks, Serguei > > > Summary: > > This is the review round #3. > Alan suggested to replace the function GetModuleByPackageName with > the GetNamedModule. > New function will return NULL if the package is not in a module > defined to the class loader. > It simplifies the API and makes it easier to specify. > JVM TI agents that instrument code in named modules need the Module at > class load time. > > One question that came from the function semantics change. > I had to implement the Modules::get_named_module() from scratch > independently of the existing > Modules::get_module_by_package_name() and Modules::get_module(). > The issue is that the Modules::get_module() can return the unnamed > module whereas the > JVMTI helper Modules::get_named_module() should return NULL instead > of the unnamed module. > Please, let me know if it is Ok or if you have better ideas how to > share the code. > > This is the Summary from review round #1: > > One way to do this is by introducing a new ClassFileLoadHook that > takes an additional parameter but this approach is disruptive. > The alternative option is a JVM TI function that maps a classloader > + package name to a module. > We were initially not confident with this approach so we introduced > it as JVM function JVM_GetModuleByPackageName. > Based on experience to date then this approach seems okay and so > this function needs to be promoted to a JVMTI function. > > It includes new jtreg test with native JVMTI agent. > > > Testing: > Run newly developed jtreg test. > > Thanks, > Serguei From david.holmes at oracle.com Tue Jun 28 04:26:19 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Jun 2016 14:26:19 +1000 Subject: RFR: 8160088: update hotspot tests depending on GC to use @requires vm.gc.X In-Reply-To: <5f381dd6-4eb2-5cee-36a6-1f4eccf67fbd@oracle.com> References: <5594dba8-f008-2fae-d293-d9a2e3f6913a@oracle.com> <684b0ef2-14f2-ed3a-63ef-a65c748e2471@oracle.com> <5b2a01d0-df0d-3826-65f5-a1c48f573e37@oracle.com> <931a448e-0e87-59b0-2657-073ac1e34fb2@oracle.com> <5f381dd6-4eb2-5cee-36a6-1f4eccf67fbd@oracle.com> Message-ID: <11a35b3b-530d-96db-295f-ba6e09a48df2@oracle.com> On 24/06/2016 7:52 PM, Dmitry Fazunenko wrote: > David, > > On 24.06.2016 12:20, David Holmes wrote: >> Hi Dima, >> >> This is diverging somewhat but ... :) >> >> On 24/06/2016 6:54 PM, Dmitry Fazunenko wrote: >>> Hi David, >>> >>> On 24.06.2016 9:48, David Holmes wrote: >>>> Thanks for the info Dima! I may have missed it but I think this new >>>> @requires functionality needs some broader advertising. :) >>> >>> That functionality was introduced on this alias as well: >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-April/022443.html >>> >>> But I agree, "Implement setting jtreg @requires properties vm.flavor, >>> vm.bits, vm.compMode" doesn't >>> attract much attention. >>> If I were from sales, I would write: "Braking news: jtreg introduces >>> smart keywords" :) >>> >>>> >>>> I'm still not 100% sure what something like vm.gc.G1 means though. >>>> Looking at this comment: >>>> >>>> /** >>>> * For all existing GC sets vm.gc.X property. >>>> * Example vm.gc.G1=true means: >>>> * VM supports G1 >>>> * User either set G1 explicitely (-XX:+UseG1GC) or did not set >>>> any GC >>>> >>>> I think it would have been more accurate to add "and the selected GC >>>> is G1" - right? >>> >>> No. vm.gc.G1 means: >>> The test needs to set G1 GC via -XX:+UseG1GC >>> It requires: >>> 1) vm supports G1 (minimal VM doesn't) >>> 2) User didn't say: -XX:+UseSerialGC ,-XX:+UseParallelGC -XX:+UseCMSGC >>> (otherwise it will be a flag conflict) >>> Note: User may say: -XX:+UseG1GC >>> >>>> That is what the logic seems to do (though I'm not sure why it checks >>>> both current and currentSetByErgo ??) >>> >>> There is a class of machines where ergonomics selects Serial GC if no >>> other GC is specified explicitly. >>> For such machines currentGC might be "Serial" but setting G1 is still >>> possible. >>> currentSetByErgo == false means: no other collector but currently >>> selected is available for setting via -XX:UseXGC. >> >> I'm more confused than I thought I was then. :( >> >> Let's pretend that default GC selection is random. If vm.gc == null we >> are letting the VM choose the GC by whatever means. If the test >> requires G1 then we need to know that currentGC() == G1 - if it is >> something else then we can't run this test. It doesn't seem to matter >> how the currentGC was selected as long as it is G1 - so I don't see >> why we need to query if the currentGC was selected by ergo ?? > > Okay :) > 'vm.gc' is set by jtreg by parsing VM flags (jtreg is not aware of any > VM specific) > isSelectedByErgo is an implementation detail hidden from test developer. > I used it to avoid parsing VM flags and set vm.gc.X properly. > > If I develop a test for G1 I'm going to specify -XX:+UseG1GC and I want > it has an effect. Right - of course. Thanks for clarifying. David ----- > Previously I used: > @requires vm.gc == null | vm.gc == "G1" > It protected from cases when jtreg was started with > vmoptins:"-XX:+UseSerialGC", but > didn't work if G1 wasn't supported: tests started and failed. > > Now if I need such test I still need to specify -XX:+UseG1GC and to > protect it from > running in non applicable configurations I use: > @requires vm.gc.G1 > > So, developers should not care about how the current GC was selected. > > We don't write tests that require a particular GC is by default, so > current GC for the VM under test is not exposed in the @requires > properties. > All GC specific tests set GC explicitly. vm.gc.X is set to false, when > it's not possible. > > Thanks, > Dima > >> >> Cheers, >> David >> >>> I know that the current description is hard to understand, but I didn't >>> come up with a better wording. >>> >>>> >>>> Anyway for this set of test changes everything seems fine. >>> >>> Thanks a lot! >>> >>> -- Dima >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 23/06/2016 10:52 PM, Dmitry Fazunenko wrote: >>>>> David, >>>>> >>>>> On 23.06.2016 14:00, David Holmes wrote: >>>>>> Hi Dmitry, >>>>>> >>>>>> On 23/06/2016 6:52 PM, Dmitry Fazunenko wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> thanks for looking! >>>>>>> >>>>>>> On 23.06.2016 3:17, David Holmes wrote: >>>>>>>> Hi Dmitry, >>>>>>>> >>>>>>>> On 23/06/2016 4:06 AM, Dmitry Fazunenko wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I'm looking for Reviewers for relatively simple fix which >>>>>>>>> affects 59 >>>>>>>>> tests. >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8160088 >>>>>>>>> http://cr.openjdk.java.net/~dfazunen/8160088/webrev.00/ >>>>>>>>> >>>>>>>>> The fix allows to skip execution of tests requiring a specific >>>>>>>>> GC in >>>>>>>>> case of the required GC is not supported by VM. >>>>>>>>> Old variant: >>>>>>>>> @requires vm.gc == null | vm.gc == "G1" >>>>>>>>> A test will be executed if no GC is specified externally or >>>>>>>>> -XX:+UseG1GC flag is given. >>>>>>>>> This test will be executed even if VM doesn't support G1 and >>>>>>>>> fail. >>>>>>>>> New variant: >>>>>>>>> @requires vm.gc.G1 >>>>>>>>> This test will not be executed if VM doesn't support G1. >>>>>>>> >>>>>>>> That doesn't seem sufficient. What you want is that if the test >>>>>>>> requires G1 then it also supports G1, so it seems to me the correct >>>>>>>> formulation is: >>>>>>>> >>>>>>>> @requires (vm.gc == null | // null -> default -> g1 (usually) >>>>>>>> vm.gc == G1 ) & >>>>>>>> vm.gc.G1 >>>>>>> >>>>>>> No, vm.gc.G1 is an alias to: (vm.gc == null | vm.gc == g1) & >>>>>>> vm.gc.supportsG1. >>>>>> >>>>>> Wow - on the one hand that is a compact/succinct syntax. On the other >>>>>> hand - no one will recognize what it actually means! I think I have >>>>>> missed a discussed I would like to have given input on! >>>>> >>>>> It was discussed on hotspot-gc-dev alias as part of '8151283' review: >>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-June/018352.html >>>>> >>>>> >>>>> >>>>> Originally it was proposed names like: vm.gc.G1.acceptable >>>>> but after input from GC dev, vm.gc.G1 was selected. >>>>> Documentation how the properties are set what that mean is >>>>> available in >>>>> the class source (jtreg plugin): >>>>> /test/jtreg-ext/requires/VMProps.java >>>>> >>>>> >>>>>> >>>>>>>> >>>>>>>> Aside: how does jtreg determine which GC's are supported? >>>>>>> Sorry for not providing the full history here: >>>>>>> >>>>>>> CODETOOLS-7901583: jtreg should provide extensible mechanism for >>>>>>> @requires properties >>>>>>> - change to jtreg that allows a Test Suite to introduce its own >>>>>>> @requires props >>>>>>> >>>>>>> JDK-8152432: Implement setting jtreg @requires properties vm.flavor, >>>>>>> vm.bits, vm.compMode >>>>>>> - implementation that mechanism in hotspot >>>>>>> >>>>>>> JDK-8154096: Extend WhiteBox API with methods which retrieve from VM >>>>>>> information about available GC >>>>>>> - fix which allows to know if a GC is supported >>>>>>> >>>>>>> JDK-8151283: Implement setting jtreg @requires property >>>>>>> vm.isG1Supported. >>>>>>> - introduction vm.gc.G1, vm.gc.Serial, vm.gc.Parallel and >>>>>>> vm.gc.ConcMarkSweep >>>>>>> >>>>>>> JDK-8160088 (this one): update hotspot tests depending on GC to use >>>>>>> @requires vm.gc.X >>>>>>> - culmination: update tests to use new functionality >>>>>> >>>>>> Wow I have missed out on a lot it seem! :( >>>>>> >>>>>> What version of jtreg supports this level of customized @requires? >>>>>> Someone has already encountered the following error: >>>>>> >>>>>> Error. Parse Exception: Syntax error in @requires expression: invalid >>>>>> name: XXX >>>>>> >>>>>> for a new @requires XXX clause. >>>>> >>>>> It was implemented in the final build of jtreg4.1 and of course it's >>>>> available in jtreg4.2 >>>>> Quiting jtreg/doc/jtreg/tag-spec.html: >>>>> >>>>> |requires.extraPropDefns | >>>>> >>>>> This option is used to provide source files for classes that >>>>> will be >>>>> used at the beginning of each test suite run, to determine >>>>> additional characteristics of the system for use with the >>>>> |@requires| tag. Each class must implement >>>>> |java.util.concurrent.Callable>|. When >>>>> invoked, the |call()| method should return properties that can be >>>>> referenced in an expression in a |@requires| tag. /Note:/ the >>>>> names >>>>> of the new properties that may be returned by calling these >>>>> classes >>>>> must also be declared in a |requires.properties| entry. >>>>> >>>>> If this option is specified, the following additional options may >>>>> also be specified: >>>>> >>>>> * |requires.extraPropDefns.libs | ? source >>>>> files for >>>>> classes that will be put on the classpath when the primary >>>>> classes are run. >>>>> * |requires.extraPropDefns.bootlibs | ? source >>>>> files >>>>> for classes that will be put on the bootclasspath when the >>>>> primary classes are run. >>>>> * |requires.extraPropDefns.javacOpts | ? options that >>>>> will be passed to javac when the source files are compiled. >>>>> * |requires.extraPropDefns.vmOpts | ? options that will >>>>> be passed to VM when the classes are executed. >>>>> >>>>> In this family of options, if a source file is enclosed in square >>>>> brackets, no error message will be given if the file is not >>>>> available. >>>>> >>>>> The following properties may appear in either TEST.ROOT or any >>>>> TEST.properties file: >>>>> >>>>> The reason, why @requires XXX is not recognized by jtreg - XXX is not >>>>> registered in TEST.ROOT. >>>>> See: hotspot/test/TEST.ROOT for example on how to register new props. >>>>> >>>>> For the time being recently introduced requires properties are >>>>> available >>>>> only in the hotspot repository. >>>>> To introduce them in jdk - a few lines from hotspot/test/TEST.ROOT >>>>> should be placed in jdk/test/TEST.ROOT >>>>> We haven't done this yet, because we are considering a possibility to >>>>> move VM specific tests from jdk into hotspot repo. >>>>> >>>>> Thanks, >>>>> Dima >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> Dima >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Testing: >>>>>>>>> 1) starting jtreg with various collectors with "-c" option to >>>>>>>>> verify >>>>>>>>> correctness of test descriptions. >>>>>>>>> Number of selected tests before and after change is the same: >>>>>>>>> -XX:+UseG1GC: 1,456 >>>>>>>>> -XX:+UseSerialGC: 1,366 >>>>>>>>> -XX:+UseParallelGC: 1,369 >>>>>>>>> -XX:+UseConcMarkSweepGC: 1,368 >>>>>>>>> Default: 1,483; error >>>>>>>>> >>>>>>>>> 2) RBT (in progress) >>>>>>>>> >>>>>>>>> 3) Diff is analyzed manually (only necessary lines are affected): >>>>>>>>> #> hg diff |grep "^- " |sort -u >>>>>>>>> - * @requires (vm.gc == "G1" | vm.gc == "null") >>>>>>>>> - * @requires (vm.gc=="G1" | vm.gc=="null") >>>>>>>>> - * @requires vm.gc == "G1" | vm.gc == "null" >>>>>>>>> - * @requires vm.gc=="ConcMarkSweep" | vm.gc == "null" >>>>>>>>> - * @requires vm.gc=="ConcMarkSweep" | vm.gc=="null" >>>>>>>>> - * @requires vm.gc=="G1" | vm.gc =="null" >>>>>>>>> - * @requires vm.gc=="G1" | vm.gc=="null" >>>>>>>>> - * @requires vm.gc=="Parallel" | vm.gc=="null" >>>>>>>>> - * @requires vm.gc=="Serial" | vm.gc=="null" >>>>>>>>> - * @requires vm.gc=="null" | vm.gc=="G1" >>>>>>>>> - * Copyright (c) 2013, 2014, Oracle and/or its affiliates. All >>>>>>>>> rights >>>>>>>>> reserved. >>>>>>>>> - * Copyright (c) 2013, 2015, Oracle and/or its affiliates. All >>>>>>>>> rights >>>>>>>>> reserved. >>>>>>>>> - * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All >>>>>>>>> rights >>>>>>>>> reserved. >>>>>>>>> - * Copyright (c) 2015, Oracle and/or its affiliates. All rights >>>>>>>>> reserved. >>>>>>>>> #> hg diff |grep "^+ " |sort -u >>>>>>>>> + * @requires vm.gc.ConcMarkSweep >>>>>>>>> + * @requires vm.gc.G1 >>>>>>>>> + * @requires vm.gc.Parallel >>>>>>>>> + * @requires vm.gc.Serial >>>>>>>>> + * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All >>>>>>>>> rights >>>>>>>>> reserved. >>>>>>>>> + * Copyright (c) 2014, 2016, Oracle and/or its affiliates. All >>>>>>>>> rights >>>>>>>>> reserved. >>>>>>>>> + * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All >>>>>>>>> rights >>>>>>>>> reserved. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dima >>>>>>> >>>>> >>> > From david.holmes at oracle.com Tue Jun 28 05:06:03 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Jun 2016 15:06:03 +1000 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <5771FB19.20009@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> Message-ID: <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> Hi Serguei, Overall this looks a lot clearer/simpler. On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: > On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >> Please, review the Jigsaw fix for the enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8159145 >> >> >> The Hotspot webrev: >> >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ Are there intended to be other callers of Module::get_named_module? If not it seems odd to go to all the trouble of throwing exceptions, just to have the caller clear them and return an error code. Or you could move all that argument checking code into the JVMTI function directly - if called internally you would just assert that arguments are as expected. src/share/vm/prims/jvmti.xml + otherwise the NULL is returned. Delete "the". Otherwise all looks good to me. >> >> >> The Jdk webrev is the same: >> >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ > > Sorry, the Jdk webrev changed as well: > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ Looks fine. Thanks, David > > Thanks, > Serguei > > >> >> >> Summary: >> >> This is the review round #3. >> Alan suggested to replace the function GetModuleByPackageName with >> the GetNamedModule. >> New function will return NULL if the package is not in a module >> defined to the class loader. >> It simplifies the API and makes it easier to specify. >> JVM TI agents that instrument code in named modules need the Module >> at class load time. >> >> One question that came from the function semantics change. >> I had to implement the Modules::get_named_module() from scratch >> independently of the existing >> Modules::get_module_by_package_name() and Modules::get_module(). >> The issue is that the Modules::get_module() can return the unnamed >> module whereas the >> JVMTI helper Modules::get_named_module() should return NULL instead >> of the unnamed module. >> Please, let me know if it is Ok or if you have better ideas how to >> share the code. >> >> This is the Summary from review round #1: >> >> One way to do this is by introducing a new ClassFileLoadHook that >> takes an additional parameter but this approach is disruptive. >> The alternative option is a JVM TI function that maps a classloader >> + package name to a module. >> We were initially not confident with this approach so we introduced >> it as JVM function JVM_GetModuleByPackageName. >> Based on experience to date then this approach seems okay and so >> this function needs to be promoted to a JVMTI function. >> >> It includes new jtreg test with native JVMTI agent. >> >> >> Testing: >> Run newly developed jtreg test. >> >> Thanks, >> Serguei > From aph at redhat.com Tue Jun 28 07:58:40 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 Jun 2016 08:58:40 +0100 Subject: JDK 9 build with GCC 6.1.1 In-Reply-To: References: <29abf149-0dc7-c137-6a57-30fc66ed5906@gmail.com> <9b6ee147-b24a-5f6f-9b1a-e18decb39b15@oracle.com> <5770D888.6080501@redhat.com> <80abfc4e-59c5-40d0-1e1f-a6d76aea992d@oracle.com> <577111F6.7000905@redhat.com> Message-ID: <57722E30.6010407@redhat.com> On 27/06/16 21:43, David Holmes wrote: > > Okay. So I know I was initially surprised we have code that can do: > > a->foo(); > > when a is NULL, but that is because it is actually compiled as: > > foo(a); Yes, it is. > IIRC foo() has a "if (this != NULL)" check internally. It doesn't, unless you write it in the body of foo(). > I'm kind of surprised that the compiler itself seems to think a->foo() > implies a is not NULL. That's what the standard says, and it's what GCC does. > I also hope it either is extremely smart about this or else very > conservative. Would want it to make a mess of this: > > if (init(&a) != NULL) { > a->foo(); > } > else { > log(...); > } > if (a) > a->bar(); This isn't enough to prove that a is non-null, so GCC won't eliminate the test. Andrew. From per.liden at oracle.com Tue Jun 28 08:19:46 2016 From: per.liden at oracle.com (Per Liden) Date: Tue, 28 Jun 2016 10:19:46 +0200 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: Message-ID: <57723322.4050107@oracle.com> Hi David, On 2016-06-28 06:04, David Holmes wrote: > Hi Kim, > > I like all the removal of the pending-list-locker related code, but > can't really comment on the details of how it was replaced and interacts > with all the GC code. The interface to the Reference class is fine, it > is the GC code that pushes into the reference queue that I can't really > comment on. > > I have a couple of queries following up from Coleen's and Dan's reviews. > > First, the synchronization of the pending-reference-list leaves me > somewhat perplexed. As Coleen noted you require the heap_lock to be held > but also use an Atomic::xchg. You have a comment: > > + // owns the lock. Swap is used by parallel non-concurrent reference > + // processing threads, where some higher level controller owns > + // Heap_lock, so requires the lock is locked, but not necessarily by > + // the current thread. > > Can you clarify the higher-level protocol that is at play there. > Asserting that "someone" owns a lock seems only marginally useful if you > can't be sure who that owner is, or when they might release it. Some > more direct detecting of being within this higher-level protocol would > be better, if it is possible to detect. The Heap_lock protects the pending list from access from the Reference Handler thread (or any other non-GC thread). During a GC, we grab the Heap_lock so that the GC then "owns" the list and is free to modify it. However, the GC itself potentially has many GC worker threads doing reference enqueuing. The atomic swap is there to allow concurrent insertion (prepending) into the list by these GC worker threads. So, each GC worker concurrently calls into ReferenceProcessor::enqueue_discovered_reflist(), with it's own/local list of references to enqueue onto the global pending list. Hope that clarifies things. cheers, Per > > --- > > As previously mentioned the change to the initialization order is a > concern to me - there are always unexpected consequences of making such > changes, no matter how straight-forward they seem at the time. > Pre-initialization of exception classes is not really essential as the > attempt to throw any of them from Java code will force initialization > anyway - it's only for exceptions created and thrown from the VM code > that direct initialization is needed. The problematic case is OOME > because throwing the OOME may trigger a secondary OOME during that class > initialization etc. Hence we try to deal with that by pre-allocating > instances that do not have stacktraces etc, so they can be thrown > safely. Hence my earlier comment that I think the real bug in your > situation is that gen_out_of_memory_error() is not considering how far > into the VM init sequence we are, and that it should be returning the > pre-allocated instance with no backtrace. > > --- > > A query on the JDK side: > > src/java.base/share/classes/java/lang/ref/Reference.java > > private static native Reference > popReferencePendingList(boolean wait); > > I'm intrigued by the use of the lower-bounded wildcard using Object. As > Object has no super-types this looks very strange and should be > equivalent to the more common upper-bounded wildcard using Object ie > Reference or more concisely Reference. I see this > construct exists in the current code for the ReferenceQueue, but I am > quite intrigued as to why? (Someone getting ready for Any-types? :) ) > > Thanks, > David > ----- > > On 25/06/2016 6:09 AM, Kim Barrett wrote: >> Please review this change which moves the Reference pending list and >> locking from the java.lang.ref.Reference class into the VM. This >> includes elimination of the ReferencePendingListLocker mechanism in >> the VM. This fixes various fragility issues arising from having the >> management of this list split between Java and the VM (GC). >> >> This change addresses JDK-8156500 by eliminating the possibility of >> suspension while holding the lock. Because the locking is now done in >> the VM, we have full control over where suspension may occur. >> >> This change retains the existing interface between the reference >> processor and the nio.Bits package, e.g. Reference.tryHandlePending >> has the same signature and behavior; this change just pushes the >> pending list manipulation down into the VM. There are open bugs >> reports, enhancement requests, and discussions related to that >> interface; see below. This change does not attempt to address them. >> >> This change additionally addresses or renders moot >> https://bugs.openjdk.java.net/browse/JDK-8055232 >> (ref) Exceptions while processing Reference pending list >> >> and >> https://bugs.openjdk.java.net/browse/JDK-7103238 >> Ensure pending list lock is held on behalf of GC before enqueuing >> references on to the pending list >> >> It is also relevant for followup discussion of >> https://bugs.openjdk.java.net/browse/JDK-8022321 >> java/lang/ref/OOMEInReferenceHandler.java fails immediately >> >> and >> https://bugs.openjdk.java.net/browse/JDK-8149925 >> We don't need jdk.internal.ref.Cleaner any more - part 1 >> >> and has implications for: >> https://bugs.openjdk.java.net/browse/JDK-8066859 >> java/lang/ref/OOMEInReferenceHandler.java failed with >> java.lang.Exception: Reference Handler thread died >> >> In addition to the obviously relevant changes, there are a couple of >> changes whose presence here might seem surprising and require further >> explanation. >> >> - Removal of a stale comment in create_vm, noticed because it was near >> some code being removed as part of this change. The comment was >> rendered obsolete by JDK-8028275. >> >> - Moved initialization of exception classes earlier in >> initialize_java_lang_classes. The previous order only worked by >> accident, at least for OOME. During the bulk of the library >> initialization, OOME may be thrown, perhaps due to poorly chosen >> command line options. That attempts to use one of the pre-allocated >> OOME objects, and tries to fill in its stack trace. If the Throwable >> class is not yet initialized, this leads to a failed assert in the VM >> because Throwable.UNASSIGNED_STACK still has a null value. This >> initialization order issue was being masked by the old pending list >> implementation; the initialization of Reference ensured >> InterruptedException was initialized (thereby initializing its >> Throwable base class), and the initialization of Reference just >> happened to occur early enough that Throwable was initialized by the >> time it was needed when running certain tests. The forced >> initialization of InterruptedException is no longer needed by >> Reference, but removal of it triggered test failures (and could >> trigger corresponding product failures) because of this ordering >> issue. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8156500 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8156500/jdk.00/ >> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.00/ >> >> Testing: >> RBT ad hoc nightly runtime & gc tests. >> >> With the proposed patch for JDK-8153711 applied, locally ran nearly >> 35K iterations of the OomDebugTest that is part of that patch, with no >> failures / deadlocks. Without this change it would typically only take >> on the order of 100 iterations to hit a deadlock failure. >> >> Locally ran direct byte buffer allocation test: >> jdk/test/java/nio/Buffer/DirectBufferAllocTest.java >> This change reported 3% faster allocation times, and 1/2 the standard >> deviation for allocation times. >> >> Locally ran failing test from JDK-8022321 and JDK-8066859 a few >> thousand times. >> jdk/test/java/lang/ref/OOMEInReferenceHandler.java >> No errors, but failures were noted as hard to reproduce. >> From per.liden at oracle.com Tue Jun 28 08:26:20 2016 From: per.liden at oracle.com (Per Liden) Date: Tue, 28 Jun 2016 10:26:20 +0200 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <10fd2944-4f2e-d2d1-d8d1-42752b687625@oracle.com> References: <10fd2944-4f2e-d2d1-d8d1-42752b687625@oracle.com> Message-ID: <577234AC.4040605@oracle.com> Hi Dan, On 2016-06-28 03:34, Daniel D. Daugherty wrote: [...] > > src/share/vm/gc/shared/vmGCOperations.cpp > L103: Heap_lock->unlock(); > You did not add a conditional "Heap_lock->notify_all()" before > the Heap_lock->unlock() like you've done in other places. > Since you deleted a release_and_notify_pending_list_lock() > call, I would think you need the: > > if (Universe::has_reference_pending_list()) { > Heap_lock->notify_all(); > } This path is only taken if the GC was skipped and never ran. In this case, we know we didn't discover and enqueued any new references on the pending list, hence no need to notify any waiting thread (the Reference Handler thread in this case). cheers, Per From serguei.spitsyn at oracle.com Tue Jun 28 08:54:47 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 01:54:47 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> Message-ID: <57723B57.2010605@oracle.com> Hi David, Thank you for the comments! I agree with you. Updated Hotspot webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.4/ Thanks, Serguei On 6/27/16 22:06, David Holmes wrote: > Hi Serguei, > > Overall this looks a lot clearer/simpler. > > On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: >> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>> Please, review the Jigsaw fix for the enhancement: >>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>> >>> >>> The Hotspot webrev: >>> >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>> > > Are there intended to be other callers of Module::get_named_module? If > not it seems odd to go to all the trouble of throwing exceptions, just > to have the caller clear them and return an error code. Or you could > move all that argument checking code into the JVMTI function directly > - if called internally you would just assert that arguments are as > expected. > > > src/share/vm/prims/jvmti.xml > > + otherwise the NULL is returned. > > Delete "the". > > Otherwise all looks good to me. > >>> >>> >>> The Jdk webrev is the same: >>> >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>> >> >> Sorry, the Jdk webrev changed as well: >> >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >> > > Looks fine. > > Thanks, > David > >> >> Thanks, >> Serguei >> >> >>> >>> >>> Summary: >>> >>> This is the review round #3. >>> Alan suggested to replace the function GetModuleByPackageName with >>> the GetNamedModule. >>> New function will return NULL if the package is not in a module >>> defined to the class loader. >>> It simplifies the API and makes it easier to specify. >>> JVM TI agents that instrument code in named modules need the Module >>> at class load time. >>> >>> One question that came from the function semantics change. >>> I had to implement the Modules::get_named_module() from scratch >>> independently of the existing >>> Modules::get_module_by_package_name() and Modules::get_module(). >>> The issue is that the Modules::get_module() can return the unnamed >>> module whereas the >>> JVMTI helper Modules::get_named_module() should return NULL instead >>> of the unnamed module. >>> Please, let me know if it is Ok or if you have better ideas how to >>> share the code. >>> >>> This is the Summary from review round #1: >>> >>> One way to do this is by introducing a new ClassFileLoadHook that >>> takes an additional parameter but this approach is disruptive. >>> The alternative option is a JVM TI function that maps a classloader >>> + package name to a module. >>> We were initially not confident with this approach so we introduced >>> it as JVM function JVM_GetModuleByPackageName. >>> Based on experience to date then this approach seems okay and so >>> this function needs to be promoted to a JVMTI function. >>> >>> It includes new jtreg test with native JVMTI agent. >>> >>> >>> Testing: >>> Run newly developed jtreg test. >>> >>> Thanks, >>> Serguei >> From per.liden at oracle.com Tue Jun 28 09:33:50 2016 From: per.liden at oracle.com (Per Liden) Date: Tue, 28 Jun 2016 11:33:50 +0200 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: Message-ID: <5772447E.9020900@oracle.com> Hi Kim, On 2016-06-24 22:09, Kim Barrett wrote: > Please review this change which moves the Reference pending list and > locking from the java.lang.ref.Reference class into the VM. This > includes elimination of the ReferencePendingListLocker mechanism in > the VM. This fixes various fragility issues arising from having the > management of this list split between Java and the VM (GC). > > This change addresses JDK-8156500 by eliminating the possibility of > suspension while holding the lock. Because the locking is now done in > the VM, we have full control over where suspension may occur. > > This change retains the existing interface between the reference > processor and the nio.Bits package, e.g. Reference.tryHandlePending > has the same signature and behavior; this change just pushes the > pending list manipulation down into the VM. There are open bugs > reports, enhancement requests, and discussions related to that > interface; see below. This change does not attempt to address them. > > This change additionally addresses or renders moot > https://bugs.openjdk.java.net/browse/JDK-8055232 > (ref) Exceptions while processing Reference pending list > > and > https://bugs.openjdk.java.net/browse/JDK-7103238 > Ensure pending list lock is held on behalf of GC before enqueuing references on to the pending list > > It is also relevant for followup discussion of > https://bugs.openjdk.java.net/browse/JDK-8022321 > java/lang/ref/OOMEInReferenceHandler.java fails immediately > > and > https://bugs.openjdk.java.net/browse/JDK-8149925 > We don't need jdk.internal.ref.Cleaner any more - part 1 > > and has implications for: > https://bugs.openjdk.java.net/browse/JDK-8066859 > java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died > > In addition to the obviously relevant changes, there are a couple of > changes whose presence here might seem surprising and require further > explanation. > > - Removal of a stale comment in create_vm, noticed because it was near > some code being removed as part of this change. The comment was > rendered obsolete by JDK-8028275. > > - Moved initialization of exception classes earlier in > initialize_java_lang_classes. The previous order only worked by > accident, at least for OOME. During the bulk of the library > initialization, OOME may be thrown, perhaps due to poorly chosen > command line options. That attempts to use one of the pre-allocated > OOME objects, and tries to fill in its stack trace. If the Throwable > class is not yet initialized, this leads to a failed assert in the VM > because Throwable.UNASSIGNED_STACK still has a null value. This > initialization order issue was being masked by the old pending list > implementation; the initialization of Reference ensured > InterruptedException was initialized (thereby initializing its > Throwable base class), and the initialization of Reference just > happened to occur early enough that Throwable was initialized by the > time it was needed when running certain tests. The forced > initialization of InterruptedException is no longer needed by > Reference, but removal of it triggered test failures (and could > trigger corresponding product failures) because of this ordering > issue. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8156500 Patch looks good. The only thing I don't feel qualified to review is the initialization order change in thread.cpp, so I'll let others comments on that. I like the pop-one-reference-at-a-time semantics, which simplifies things a lot and keeps the interface nice and clean. I was previously afraid that it might cause a noticeable performance degradation compared to lifting the whole list into Java in one go, but your testing seem to prove that's not the case. cheers, Per > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8156500/jdk.00/ > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.00/ > > Testing: > RBT ad hoc nightly runtime & gc tests. > > With the proposed patch for JDK-8153711 applied, locally ran nearly > 35K iterations of the OomDebugTest that is part of that patch, with no > failures / deadlocks. Without this change it would typically only take > on the order of 100 iterations to hit a deadlock failure. > > Locally ran direct byte buffer allocation test: > jdk/test/java/nio/Buffer/DirectBufferAllocTest.java > This change reported 3% faster allocation times, and 1/2 the standard > deviation for allocation times. > > Locally ran failing test from JDK-8022321 and JDK-8066859 a few > thousand times. > jdk/test/java/lang/ref/OOMEInReferenceHandler.java > No errors, but failures were noted as hard to reproduce. > From zgu at redhat.com Tue Jun 28 13:28:48 2016 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 28 Jun 2016 09:28:48 -0400 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <57719197.5030305@oracle.com> References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <57714E42.7000406@redhat.com> <57719197.5030305@oracle.com> Message-ID: <57727B90.8030203@redhat.com> Thanks for the changes. PackageEntry::delete_qualified_exports() has nothing to do with class unloading, should it be handled in earlier loop? or it may get lost. -Zhengyu On 06/27/2016 04:50 PM, Lois Foltan wrote: > > On 6/27/2016 12:03 PM, Zhengyu Gu wrote: >> Hi Lois, >> >> I have a question: >> >> classLoaderData.cpp # 1004 - 1013 >> >> If there is no class loader unloaded, (for example, _unloading == >> NULL), do you still need to execute this purge loop? > Hi Zhengyu, > > Thank you for the review. I have addressed your concern by moving the > purge loop into the following conditional that only executes "if > (seen_dead_loader)", nice catch. This updated webrev also contains an > improvement to the test ModuleStress.java to include a module defined > to a custom system class loader, specified via > -Djava.system.class.loader. > > http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.2/webrev/ > > Thanks, > Lois > >> >> Thanks, >> >> -Zhengyu >> >> On 06/22/2016 10:51 AM, Lois Foltan wrote: >>> >>> On 6/22/2016 8:56 AM, Alan Bateman wrote: >>>> >>>> >>>> On 22/06/2016 13:51, David Holmes wrote: >>>>> >>>>> How do you envisage any system classloader "dying" ?? >>>> The system class loader (be it the built-in application class >>>> loader or a custom system class loader configured via >>>> -Djava.system.class.loader) will/can never be GC'ed. >>>> ClassLoader.getSystemClassLoader() always returns a reference to it >>>> (for example). >>> Ahh, ok, I was being overly cautious, so no opportunity to reset the >>> system class loader dynamically at all? >>> SystemDictionary::_java_class_loader is not initialized until after >>> the module system initialization is complete. Due to this I have >>> updated my webrev to check for either the built-in application class >>> loader or a custom system class loader and have renamed the method >>> to is_system_class_loader(). >>> >>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/ >>> >>> Thanks, >>> Lois >>> >> > From lois.foltan at oracle.com Tue Jun 28 14:11:27 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 28 Jun 2016 10:11:27 -0400 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <57727B90.8030203@redhat.com> References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <57714E42.7000406@redhat.com> <57719197.5030305@oracle.com> <57727B90.8030203@redhat.com> Message-ID: <5772858F.5080507@oracle.com> On 6/28/2016 9:28 AM, Zhengyu Gu wrote: > Thanks for the changes. > > PackageEntry::delete_qualified_exports() has nothing to do with class > unloading, should it be handled in earlier loop? or it may get lost. Hi Zhengyu, PackageEntry::delete_qualified_exports() have everything to do with class unloading and is a direct consequence of a loader dying. When a class loader dies, its ModuleEntryTable and PackageEntryTable are deleted, see ClassLoaderData's destructor. In particular when a PackageEntryTable is deleted, each destructor is called for every package entry within that table which in return involves calling PackageEntry::delete_qualified_exports() if necessary. That section of code has no bearing on this webrev and the changes in ClassLoaderDataGraph::do_unloading. Thanks, Lois > > -Zhengyu > > On 06/27/2016 04:50 PM, Lois Foltan wrote: >> >> On 6/27/2016 12:03 PM, Zhengyu Gu wrote: >>> Hi Lois, >>> >>> I have a question: >>> >>> classLoaderData.cpp # 1004 - 1013 >>> >>> If there is no class loader unloaded, (for example, _unloading == >>> NULL), do you still need to execute this purge loop? >> Hi Zhengyu, >> >> Thank you for the review. I have addressed your concern by moving >> the purge loop into the following conditional that only executes "if >> (seen_dead_loader)", nice catch. This updated webrev also contains >> an improvement to the test ModuleStress.java to include a module >> defined to a custom system class loader, specified via >> -Djava.system.class.loader. >> >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.2/webrev/ >> >> Thanks, >> Lois >> >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> On 06/22/2016 10:51 AM, Lois Foltan wrote: >>>> >>>> On 6/22/2016 8:56 AM, Alan Bateman wrote: >>>>> >>>>> >>>>> On 22/06/2016 13:51, David Holmes wrote: >>>>>> >>>>>> How do you envisage any system classloader "dying" ?? >>>>> The system class loader (be it the built-in application class >>>>> loader or a custom system class loader configured via >>>>> -Djava.system.class.loader) will/can never be GC'ed. >>>>> ClassLoader.getSystemClassLoader() always returns a reference to >>>>> it (for example). >>>> Ahh, ok, I was being overly cautious, so no opportunity to reset >>>> the system class loader dynamically at all? >>>> SystemDictionary::_java_class_loader is not initialized until after >>>> the module system initialization is complete. Due to this I have >>>> updated my webrev to check for either the built-in application >>>> class loader or a custom system class loader and have renamed the >>>> method to is_system_class_loader(). >>>> >>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/ >>>> >>>> Thanks, >>>> Lois >>>> >>> >> > From harold.seigel at oracle.com Tue Jun 28 14:32:39 2016 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 28 Jun 2016 10:32:39 -0400 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <57723B57.2010605@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> Message-ID: <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> Hi Serguei, Looks good. 1. In modules.cpp, the first assert in get_named_module() has the wrong function name: 825 assert(ModuleEntryTable::javabase_defined(), 826 "Attempt to call *get_module_by_package_name* before java.base is defined"); 2. Also, is a check needed to ensure that package_str is not null? 3. Is the ResourceMark(THREAD) needed at line 824? Thanks, Harold On 6/28/2016 4:54 AM, serguei.spitsyn at oracle.com wrote: > Hi David, > > Thank you for the comments! > I agree with you. > > Updated Hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.4/ > > > > Thanks, > Serguei > > > > On 6/27/16 22:06, David Holmes wrote: >> Hi Serguei, >> >> Overall this looks a lot clearer/simpler. >> >> On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: >>> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>>> Please, review the Jigsaw fix for the enhancement: >>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>> >>>> >>>> The Hotspot webrev: >>>> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>>> >> >> Are there intended to be other callers of Module::get_named_module? >> If not it seems odd to go to all the trouble of throwing exceptions, >> just to have the caller clear them and return an error code. Or you >> could move all that argument checking code into the JVMTI function >> directly - if called internally you would just assert that arguments >> are as expected. >> >> >> src/share/vm/prims/jvmti.xml >> >> + otherwise the NULL is returned. >> >> Delete "the". >> >> Otherwise all looks good to me. >> >>>> >>>> >>>> The Jdk webrev is the same: >>>> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>> >>> >>> Sorry, the Jdk webrev changed as well: >>> >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >>> >> >> Looks fine. >> >> Thanks, >> David >> >>> >>> Thanks, >>> Serguei >>> >>> >>>> >>>> >>>> Summary: >>>> >>>> This is the review round #3. >>>> Alan suggested to replace the function GetModuleByPackageName with >>>> the GetNamedModule. >>>> New function will return NULL if the package is not in a module >>>> defined to the class loader. >>>> It simplifies the API and makes it easier to specify. >>>> JVM TI agents that instrument code in named modules need the Module >>>> at class load time. >>>> >>>> One question that came from the function semantics change. >>>> I had to implement the Modules::get_named_module() from scratch >>>> independently of the existing >>>> Modules::get_module_by_package_name() and Modules::get_module(). >>>> The issue is that the Modules::get_module() can return the unnamed >>>> module whereas the >>>> JVMTI helper Modules::get_named_module() should return NULL instead >>>> of the unnamed module. >>>> Please, let me know if it is Ok or if you have better ideas how to >>>> share the code. >>>> >>>> This is the Summary from review round #1: >>>> >>>> One way to do this is by introducing a new ClassFileLoadHook that >>>> takes an additional parameter but this approach is disruptive. >>>> The alternative option is a JVM TI function that maps a classloader >>>> + package name to a module. >>>> We were initially not confident with this approach so we introduced >>>> it as JVM function JVM_GetModuleByPackageName. >>>> Based on experience to date then this approach seems okay and so >>>> this function needs to be promoted to a JVMTI function. >>>> >>>> It includes new jtreg test with native JVMTI agent. >>>> >>>> >>>> Testing: >>>> Run newly developed jtreg test. >>>> >>>> Thanks, >>>> Serguei >>> > From aph at redhat.com Tue Jun 28 14:55:35 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 Jun 2016 15:55:35 +0100 Subject: RFD: C2 bug: 8157306 random infrequent null pointer exceptions in javac In-Reply-To: <576DF4CD.502@oracle.com> References: <576AD768.3070005@redhat.com> <50693eff-01c3-9791-ca4d-b979ad0deb91@oracle.com> <576C0BD6.4000106@redhat.com> <576DB611.4030408@oracle.com> <576DF4CD.502@oracle.com> Message-ID: <57728FE7.6080102@redhat.com> On 25/06/16 04:04, Vladimir Kozlov wrote: > The assert you added is "good" :) > > It found several problems but I am not sure if they are real or we > can't call insert_anti_dependences() there. I'm afraid that I have been completely unable to replicate any of these failures with my patch applied to a linux-x86_64-normal-server-fastdebug build on . I'll do a complete jtreg run to see if anything interesting happens. Andrew. From serguei.spitsyn at oracle.com Tue Jun 28 14:59:39 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 07:59:39 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> Message-ID: <577290DB.5010902@oracle.com> Hi Harold, On 6/28/16 07:32, harold seigel wrote: > > Hi Serguei, > > Looks good. > Thank you for reviewing! > 1. In modules.cpp, the first assert in get_named_module() has the > wrong function name: > > 825 assert(ModuleEntryTable::javabase_defined(), > 826 "Attempt to call *get_module_by_package_name* before java.base is > defined"); Nice catch. Will fix. > > 2. Also, is a check needed to ensure that package_str is not null? The only caller the JVMTI function does this check for both loader and package_str. Maybe worth to add an assert? > > 3. Is the ResourceMark(THREAD) needed at line 824? Does the SymbolTable::new_symbol() needs it? The caller has its own ResourceMark as well. Do you recommend to get rid of it? Thanks, Serguei > > Thanks, Harold > > On 6/28/2016 4:54 AM, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> Thank you for the comments! >> I agree with you. >> >> Updated Hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.4/ >> >> >> >> Thanks, >> Serguei >> >> >> >> On 6/27/16 22:06, David Holmes wrote: >>> Hi Serguei, >>> >>> Overall this looks a lot clearer/simpler. >>> >>> On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: >>>> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the Jigsaw fix for the enhancement: >>>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>>> >>>>> >>>>> The Hotspot webrev: >>>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>>>> >>> >>> Are there intended to be other callers of Module::get_named_module? >>> If not it seems odd to go to all the trouble of throwing exceptions, >>> just to have the caller clear them and return an error code. Or you >>> could move all that argument checking code into the JVMTI function >>> directly - if called internally you would just assert that arguments >>> are as expected. >>> >>> >>> src/share/vm/prims/jvmti.xml >>> >>> + otherwise the NULL is returned. >>> >>> Delete "the". >>> >>> Otherwise all looks good to me. >>> >>>>> >>>>> >>>>> The Jdk webrev is the same: >>>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>>> >>>> >>>> Sorry, the Jdk webrev changed as well: >>>> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >>>> >>> >>> Looks fine. >>> >>> Thanks, >>> David >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> >>>>> >>>>> Summary: >>>>> >>>>> This is the review round #3. >>>>> Alan suggested to replace the function GetModuleByPackageName with >>>>> the GetNamedModule. >>>>> New function will return NULL if the package is not in a module >>>>> defined to the class loader. >>>>> It simplifies the API and makes it easier to specify. >>>>> JVM TI agents that instrument code in named modules need the Module >>>>> at class load time. >>>>> >>>>> One question that came from the function semantics change. >>>>> I had to implement the Modules::get_named_module() from scratch >>>>> independently of the existing >>>>> Modules::get_module_by_package_name() and Modules::get_module(). >>>>> The issue is that the Modules::get_module() can return the unnamed >>>>> module whereas the >>>>> JVMTI helper Modules::get_named_module() should return NULL instead >>>>> of the unnamed module. >>>>> Please, let me know if it is Ok or if you have better ideas how to >>>>> share the code. >>>>> >>>>> This is the Summary from review round #1: >>>>> >>>>> One way to do this is by introducing a new ClassFileLoadHook that >>>>> takes an additional parameter but this approach is disruptive. >>>>> The alternative option is a JVM TI function that maps a classloader >>>>> + package name to a module. >>>>> We were initially not confident with this approach so we introduced >>>>> it as JVM function JVM_GetModuleByPackageName. >>>>> Based on experience to date then this approach seems okay and so >>>>> this function needs to be promoted to a JVMTI function. >>>>> >>>>> It includes new jtreg test with native JVMTI agent. >>>>> >>>>> >>>>> Testing: >>>>> Run newly developed jtreg test. >>>>> >>>>> Thanks, >>>>> Serguei >>>> >> > From zgu at redhat.com Tue Jun 28 15:07:15 2016 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 28 Jun 2016 11:07:15 -0400 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <5772858F.5080507@oracle.com> References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <57714E42.7000406@redhat.com> <57719197.5030305@oracle.com> <57727B90.8030203@redhat.com> <5772858F.5080507@oracle.com> Message-ID: <577292A3.9090508@redhat.com> Hi Lois, The comments in PackageEntry::delete_qualified_exports() suggests that it is related to a transition from qualified exports to unqualified. It seems to me that, when overriding package's exports from qualified to unqualified, ex. via JVM_AddModuleExportsToAll(), delete_qualified_exports() should be called. I don't see it has anything to do with class unloading. Thanks, -Zhengyu On 06/28/2016 10:11 AM, Lois Foltan wrote: > > On 6/28/2016 9:28 AM, Zhengyu Gu wrote: >> Thanks for the changes. >> >> PackageEntry::delete_qualified_exports() has nothing to do with class >> unloading, should it be handled in earlier loop? or it may get lost. > > Hi Zhengyu, > > PackageEntry::delete_qualified_exports() have everything to do with > class unloading and is a direct consequence of a loader dying. When a > class loader dies, its ModuleEntryTable and PackageEntryTable are > deleted, see ClassLoaderData's destructor. In particular when a > PackageEntryTable is deleted, each destructor is called for every > package entry within that table which in return involves calling > PackageEntry::delete_qualified_exports() if necessary. That section > of code has no bearing on this webrev and the changes in > ClassLoaderDataGraph::do_unloading. > > Thanks, > Lois > >> >> -Zhengyu >> >> On 06/27/2016 04:50 PM, Lois Foltan wrote: >>> >>> On 6/27/2016 12:03 PM, Zhengyu Gu wrote: >>>> Hi Lois, >>>> >>>> I have a question: >>>> >>>> classLoaderData.cpp # 1004 - 1013 >>>> >>>> If there is no class loader unloaded, (for example, _unloading == >>>> NULL), do you still need to execute this purge loop? >>> Hi Zhengyu, >>> >>> Thank you for the review. I have addressed your concern by moving >>> the purge loop into the following conditional that only executes "if >>> (seen_dead_loader)", nice catch. This updated webrev also contains >>> an improvement to the test ModuleStress.java to include a module >>> defined to a custom system class loader, specified via >>> -Djava.system.class.loader. >>> >>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.2/webrev/ >>> >>> Thanks, >>> Lois >>> >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> >>>> On 06/22/2016 10:51 AM, Lois Foltan wrote: >>>>> >>>>> On 6/22/2016 8:56 AM, Alan Bateman wrote: >>>>>> >>>>>> >>>>>> On 22/06/2016 13:51, David Holmes wrote: >>>>>>> >>>>>>> How do you envisage any system classloader "dying" ?? >>>>>> The system class loader (be it the built-in application class >>>>>> loader or a custom system class loader configured via >>>>>> -Djava.system.class.loader) will/can never be GC'ed. >>>>>> ClassLoader.getSystemClassLoader() always returns a reference to >>>>>> it (for example). >>>>> Ahh, ok, I was being overly cautious, so no opportunity to reset >>>>> the system class loader dynamically at all? >>>>> SystemDictionary::_java_class_loader is not initialized until >>>>> after the module system initialization is complete. Due to this I >>>>> have updated my webrev to check for either the built-in >>>>> application class loader or a custom system class loader and have >>>>> renamed the method to is_system_class_loader(). >>>>> >>>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/ >>>>> >>>>> Thanks, >>>>> Lois >>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Tue Jun 28 16:37:31 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 09:37:31 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> Message-ID: <5772A7CB.6070007@oracle.com> Hi Harold, Thank you again for the comments! This is the updated webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.5/ Thanks, Serguei On 6/28/16 07:32, harold seigel wrote: > > Hi Serguei, > > Looks good. > > 1. In modules.cpp, the first assert in get_named_module() has the > wrong function name: > > 825 assert(ModuleEntryTable::javabase_defined(), > 826 "Attempt to call *get_module_by_package_name* before java.base is > defined"); > > 2. Also, is a check needed to ensure that package_str is not null? > > 3. Is the ResourceMark(THREAD) needed at line 824? > > Thanks, Harold > > On 6/28/2016 4:54 AM, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> Thank you for the comments! >> I agree with you. >> >> Updated Hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.4/ >> >> >> >> Thanks, >> Serguei >> >> >> >> On 6/27/16 22:06, David Holmes wrote: >>> Hi Serguei, >>> >>> Overall this looks a lot clearer/simpler. >>> >>> On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: >>>> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the Jigsaw fix for the enhancement: >>>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>>> >>>>> >>>>> The Hotspot webrev: >>>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>>>> >>> >>> Are there intended to be other callers of Module::get_named_module? >>> If not it seems odd to go to all the trouble of throwing exceptions, >>> just to have the caller clear them and return an error code. Or you >>> could move all that argument checking code into the JVMTI function >>> directly - if called internally you would just assert that arguments >>> are as expected. >>> >>> >>> src/share/vm/prims/jvmti.xml >>> >>> + otherwise the NULL is returned. >>> >>> Delete "the". >>> >>> Otherwise all looks good to me. >>> >>>>> >>>>> >>>>> The Jdk webrev is the same: >>>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>>> >>>> >>>> Sorry, the Jdk webrev changed as well: >>>> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >>>> >>> >>> Looks fine. >>> >>> Thanks, >>> David >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> >>>>> >>>>> Summary: >>>>> >>>>> This is the review round #3. >>>>> Alan suggested to replace the function GetModuleByPackageName with >>>>> the GetNamedModule. >>>>> New function will return NULL if the package is not in a module >>>>> defined to the class loader. >>>>> It simplifies the API and makes it easier to specify. >>>>> JVM TI agents that instrument code in named modules need the Module >>>>> at class load time. >>>>> >>>>> One question that came from the function semantics change. >>>>> I had to implement the Modules::get_named_module() from scratch >>>>> independently of the existing >>>>> Modules::get_module_by_package_name() and Modules::get_module(). >>>>> The issue is that the Modules::get_module() can return the unnamed >>>>> module whereas the >>>>> JVMTI helper Modules::get_named_module() should return NULL instead >>>>> of the unnamed module. >>>>> Please, let me know if it is Ok or if you have better ideas how to >>>>> share the code. >>>>> >>>>> This is the Summary from review round #1: >>>>> >>>>> One way to do this is by introducing a new ClassFileLoadHook that >>>>> takes an additional parameter but this approach is disruptive. >>>>> The alternative option is a JVM TI function that maps a classloader >>>>> + package name to a module. >>>>> We were initially not confident with this approach so we introduced >>>>> it as JVM function JVM_GetModuleByPackageName. >>>>> Based on experience to date then this approach seems okay and so >>>>> this function needs to be promoted to a JVMTI function. >>>>> >>>>> It includes new jtreg test with native JVMTI agent. >>>>> >>>>> >>>>> Testing: >>>>> Run newly developed jtreg test. >>>>> >>>>> Thanks, >>>>> Serguei >>>> >> > From vladimir.kozlov at oracle.com Tue Jun 28 16:46:38 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Jun 2016 09:46:38 -0700 Subject: RFR: JDK-8160356: invalid suffix on literal warning is occurred with GCC 6 In-Reply-To: References: <96c1c5d9-403c-bdcf-4574-848a50b7521a@gmail.com> <6859BC03-4DAF-492F-AD5B-372819139A7A@oracle.com> Message-ID: Lets not complicate the process. Currently it is the bug (compilation warnings with gcc6) and there is reviewed fix (very simple). Lets push it and be done. Thanks, Vladimir On 6/27/16 8:45 PM, Yasumasa Suenaga wrote: > Hi Kim, > >> However, I think this is an enhancement, as it wouldn?t be a problem if >> https://bugs.openjdk.java.net/browse/JDK-8156980 >> were fixed, so subject to a post-FC exemption or deferral to JDK 10. > > I want to add FC extention label to this issue. > Can I add it now? > > > Thanks, > > Yasumasa > > > On 2016/06/28 7:59, Kim Barrett wrote: >>> On Jun 27, 2016, at 10:30 AM, Yasumasa Suenaga >>> wrote: >>> >>> Hi all, >>> >>> This review request relates to JDK-8160310: HotSpot cannot be built >>> with GCC 6 . >>> >>> I encountered invalid suffix on literal when I compiled OpenJDK 9 >>> with GCC 6 >>> on Fedora 24 x64. >>> I think these error should be fixed. >>> >>> I uploaded webrev. >>> Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8160356/webrev.00/ >>> >>> >>> I'm jdk 9 committer, but I cannot access JPRT. >>> So I need a sponsor. >> >> This looks good. >> >> However, I think this is an enhancement, as it wouldn?t be a problem if >> https://bugs.openjdk.java.net/browse/JDK-8156980 >> were fixed, so subject to a post-FC exemption or deferral to JDK 10. >> From daniel.daugherty at oracle.com Tue Jun 28 17:24:25 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 28 Jun 2016 11:24:25 -0600 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <5771FB19.20009@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> Message-ID: <2bf0d051-1fa9-3bbd-2d52-d9b117d366c6@oracle.com> On 6/27/16 10:20 PM, serguei.spitsyn at oracle.com wrote: > On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >> Please, review the Jigsaw fix for the enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8159145 >> >> >> The Hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >> >> >> >> The Jdk webrev is the same: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >> > > Sorry, the Jdk webrev changed as well: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ > ' src/java.base/share/native/include/jvmti.h No comments. Thumbs up on the 'jdk' repo change. Dan > > > Thanks, > Serguei > > >> >> >> Summary: >> >> This is the review round #3. >> Alan suggested to replace the function GetModuleByPackageName with >> the GetNamedModule. >> New function will return NULL if the package is not in a module >> defined to the class loader. >> It simplifies the API and makes it easier to specify. >> JVM TI agents that instrument code in named modules need the Module >> at class load time. >> >> One question that came from the function semantics change. >> I had to implement the Modules::get_named_module() from scratch >> independently of the existing >> Modules::get_module_by_package_name() and Modules::get_module(). >> The issue is that the Modules::get_module() can return the unnamed >> module whereas the >> JVMTI helper Modules::get_named_module() should return NULL instead >> of the unnamed module. >> Please, let me know if it is Ok or if you have better ideas how to >> share the code. >> >> This is the Summary from review round #1: >> >> One way to do this is by introducing a new ClassFileLoadHook that >> takes an additional parameter but this approach is disruptive. >> The alternative option is a JVM TI function that maps a classloader >> + package name to a module. >> We were initially not confident with this approach so we introduced >> it as JVM function JVM_GetModuleByPackageName. >> Based on experience to date then this approach seems okay and so >> this function needs to be promoted to a JVMTI function. >> >> It includes new jtreg test with native JVMTI agent. >> >> >> Testing: >> Run newly developed jtreg test. >> >> Thanks, >> Serguei > From philip.race at oracle.com Tue Jun 28 17:38:38 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 28 Jun 2016 10:38:38 -0700 Subject: [OpenJDK 2D-Dev] JDK 9 build with GCC 6.1.1 In-Reply-To: References: <57F3A28D-6FFD-45D6-B85C-1B5638CE29F4@oracle.com> Message-ID: <5772B61E.7060606@oracle.com> On 06/27/2016 08:50 PM, Yasumasa Suenaga wrote: > Hi Kim, > > The newest changes for jdk repos is [1]. > Erik points we should use DISABLED_WARNINGS_gcc to handle unknown > warning tags. [2] > [1] is implemented with it. > > This change is already reviewed by 2d folks. > So I want to merge it ASAP. > > Do you have any objection? > > > Thanks, > > Yasumasa > > > [1] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007090.html > [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004499.html > > > On 2016/06/28 8:37, Kim Barrett wrote: >>> On Jun 25, 2016, at 9:57 AM, Yasumasa Suenaga >>> wrote: >>> >>> Hi all, >>> >>> This review request relates to [1]. >>> >>> I've tried to build OpenJDK 9 at Fedora 24 x64. >>> Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. >>> >>> I fixed build error and several issues (VM crash and internal error) >>> as below: >>> >>> http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ >>> >>> Does someone work for it? >>> If no one works for it, I will file it to JBS and will send review >>> request. >>> >>> For jdk repos, I've sent review request [2]. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html >>> [2] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007081.html >> >> Having gone through these, I think all of them are arising due to >> build system problems, where we seem to have lost the compiler >> configuration to use explicit selection of the language standard and >> some additional options. Do tell more about what this means. Where would this previously have been seen ? Different versions of Visual Studio / CLANG / GCC all emit different warnings and it is not always monotonically increasing with compiler version, and I can imagine someone might want to have different sets of flags in general depending on compiler version in use, but I have not seen a pattern of this being applied to the warnings on any of the platforms. in the makefile here there is just one special case of this .. 474 # Suppress gcc warnings like "variable might be clobbered by 'longjmp' 475 # or 'vfork'": this warning indicates that some variable is placed to 476 # a register by optimized compiler and it's value might be lost on longjmp(). 477 # Recommended way to avoid such warning is to declare the variable as 478 # volatile to prevent the optimization. However, this approach does not 479 # work because we have to declare all variables as volatile in result. 480 #ifndef CROSS_COMPILE_ARCH 481 # CC_43_OR_NEWER := \ 482 # $(shell $(EXPR) $(CC_MAJORVER) \> 4 \| \ 483 # \( $(CC_MAJORVER) = 4 \& $(CC_MINORVER) \>= 3 \) ) 484 # ifeq ($(CC_43_OR_NEWER), 1) 485 # BUILD_LIBJAVAJPEG_CFLAGS_linux += -Wno-clobbered 486 # endif 487 #endif >> >> For now I think we should fix the build system problems, and file >> additional bugs or update existing ones as needed to fix the root >> causes of the problems encountered. I think many of the proposed >> changes do not address the root causes, and should not be made. See >> my comments for the specific bugs. >> >> I'm not on the mailing list where the jdk RFR was submitted. I took a >> look at them though, and >> >> ------------------------------------------------------------------------------ >> >> make/lib/Awt2dLibraries.gmk >> 407 # Avoid warning for GCC 6 >> 408 ifeq ($(TOOLCHAIN_TYPE), gcc) >> 409 LCMS_CFLAGS += -Wno-misleading-indentation >> 410 endif >> >> 926 # Avoid warning for GCC 6 >> 927 ifeq ($(TOOLCHAIN_TYPE), gcc) >> 928 BUILD_LIBSPLASHSCREEN_jdhuff.c_CFLAGS += >> -Wno-shift-negative-value >> 929 BUILD_LIBSPLASHSCREEN_jdphuff.c_CFLAGS += >> -Wno-shift-negative-value >> 930 endif >> >> The -Wmisleading-indentation and -Wshift-negative-value options are >> new in gcc 6. gcc has for some time (starting with gcc 4.4) silently >> ignored unrecognized -Wno-XXX options. But some folks (like SAP) are >> still using older versions. So these will need to be conditionalized >> on the gcc version. >> >> ------------------------------------------------------------------------------ >> >> src/java.desktop/share/native/libfontmanager/layout/SunLayoutEngine.cpp >> 154 if (min < 0) min = 0; >> 155 if (max < min) max = min; /* defensive coding */ >> >> [splitting the line] >> >> Seems like this would be suppressed by -Wno-misleading-indentation, >> especially since the reported warning is for that. Why change both >> the code and the build configuration? Was that something seen in the original fix ? It is not in the version I reviewed. The current version of the fix does not update the makefile to add this .. except for LCMS - which is a different library. -phil. >> >> ------------------------------------------------------------------------------ >> >> >> The changes in AlphaMath.c and splashscreen_jpeg.c look ok. >> From kim.barrett at oracle.com Tue Jun 28 17:45:31 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 28 Jun 2016 13:45:31 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <5772447E.9020900@oracle.com> References: <5772447E.9020900@oracle.com> Message-ID: <6C2DABC1-AB1D-4CF1-BB40-22107A37D122@oracle.com> > On Jun 28, 2016, at 5:33 AM, Per Liden wrote: > Patch looks good. The only thing I don't feel qualified to review is the initialization order change in thread.cpp, so I'll let others comments on that. Thanks. I?ll be following up on that area. > I like the pop-one-reference-at-a-time semantics, which simplifies things a lot and keeps the interface nice and clean. I was previously afraid that it might cause a noticeable performance degradation compared to lifting the whole list into Java in one go, but your testing seem to prove that's not the case. I was concerned about that too, and had tried a different approach that also still supported the existing "some callers wait and others don?t" API, but it was a bit messy. Coleen convinced me to try this (since it was easy) and do the measurement, and it worked out well. From harold.seigel at oracle.com Tue Jun 28 17:45:53 2016 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 28 Jun 2016 13:45:53 -0400 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <5772A7CB.6070007@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> Message-ID: Hi Serguei, It looks good! Thanks, Harold On 6/28/2016 12:37 PM, serguei.spitsyn at oracle.com wrote: > Hi Harold, > > Thank you again for the comments! > This is the updated webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.5/ > > Thanks, > Serguei > > > On 6/28/16 07:32, harold seigel wrote: >> >> Hi Serguei, >> >> Looks good. >> >> 1. In modules.cpp, the first assert in get_named_module() has the >> wrong function name: >> >> 825 assert(ModuleEntryTable::javabase_defined(), >> 826 "Attempt to call *get_module_by_package_name* before java.base is >> defined"); >> >> 2. Also, is a check needed to ensure that package_str is not null? >> >> 3. Is the ResourceMark(THREAD) needed at line 824? >> >> Thanks, Harold >> >> On 6/28/2016 4:54 AM, serguei.spitsyn at oracle.com wrote: >>> Hi David, >>> >>> Thank you for the comments! >>> I agree with you. >>> >>> Updated Hotspot webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.4/ >>> >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 6/27/16 22:06, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> Overall this looks a lot clearer/simpler. >>>> >>>> On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review the Jigsaw fix for the enhancement: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>>>> >>>>>> >>>>>> The Hotspot webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>>>>> >>>> >>>> Are there intended to be other callers of Module::get_named_module? >>>> If not it seems odd to go to all the trouble of throwing >>>> exceptions, just to have the caller clear them and return an error >>>> code. Or you could move all that argument checking code into the >>>> JVMTI function directly - if called internally you would just >>>> assert that arguments are as expected. >>>> >>>> >>>> src/share/vm/prims/jvmti.xml >>>> >>>> + otherwise the NULL is returned. >>>> >>>> Delete "the". >>>> >>>> Otherwise all looks good to me. >>>> >>>>>> >>>>>> >>>>>> The Jdk webrev is the same: >>>>>> >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>>>> >>>>> >>>>> Sorry, the Jdk webrev changed as well: >>>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >>>>> >>>> >>>> Looks fine. >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>>> >>>>>> >>>>>> Summary: >>>>>> >>>>>> This is the review round #3. >>>>>> Alan suggested to replace the function GetModuleByPackageName with >>>>>> the GetNamedModule. >>>>>> New function will return NULL if the package is not in a module >>>>>> defined to the class loader. >>>>>> It simplifies the API and makes it easier to specify. >>>>>> JVM TI agents that instrument code in named modules need the >>>>>> Module >>>>>> at class load time. >>>>>> >>>>>> One question that came from the function semantics change. >>>>>> I had to implement the Modules::get_named_module() from scratch >>>>>> independently of the existing >>>>>> Modules::get_module_by_package_name() and Modules::get_module(). >>>>>> The issue is that the Modules::get_module() can return the unnamed >>>>>> module whereas the >>>>>> JVMTI helper Modules::get_named_module() should return NULL >>>>>> instead >>>>>> of the unnamed module. >>>>>> Please, let me know if it is Ok or if you have better ideas how to >>>>>> share the code. >>>>>> >>>>>> This is the Summary from review round #1: >>>>>> >>>>>> One way to do this is by introducing a new ClassFileLoadHook that >>>>>> takes an additional parameter but this approach is disruptive. >>>>>> The alternative option is a JVM TI function that maps a >>>>>> classloader >>>>>> + package name to a module. >>>>>> We were initially not confident with this approach so we >>>>>> introduced >>>>>> it as JVM function JVM_GetModuleByPackageName. >>>>>> Based on experience to date then this approach seems okay and so >>>>>> this function needs to be promoted to a JVMTI function. >>>>>> >>>>>> It includes new jtreg test with native JVMTI agent. >>>>>> >>>>>> >>>>>> Testing: >>>>>> Run newly developed jtreg test. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>> >>> >> > From lois.foltan at oracle.com Tue Jun 28 17:52:05 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 28 Jun 2016 13:52:05 -0400 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <577292A3.9090508@redhat.com> References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <57714E42.7000406@redhat.com> <57719197.5030305@oracle.com> <57727B90.8030203@redhat.com> <5772858F.5080507@oracle.com> <577292A3.9090508@redhat.com> Message-ID: <5772B945.2040509@oracle.com> On 6/28/2016 11:07 AM, Zhengyu Gu wrote: > Hi Lois, > > The comments in PackageEntry::delete_qualified_exports() suggests that > it is related to a transition from qualified exports to unqualified. That is correct. A package can transition from being qualifiedly exported, to unqualifiedly exported. Its exported scope is widened. A package can not transition from being unqualifiedly exported to all modules to being specifically qualified to one or more modules. > > It seems to me that, when overriding package's exports from qualified > to unqualified, ex. via JVM_AddModuleExportsToAll(), > delete_qualified_exports() > should be called. I don't see it has anything to do with class unloading. We chose not to delete the qualified exports at that point but to delay that until the next GC safepoint. When a package does transition from being qualifiedly exported to unqualifiedly exported, its qualified exports list is moved to the _exported_pending_delete field which is then deleted later, via a call to PackageEntry::delete_qualified_exports(). That deletion of the _exported_pending_delete list does occur either during the purge walk or if the class loader that the package is defined to dies. Thanks, Lois > > Thanks, > > -Zhengyu > > > > On 06/28/2016 10:11 AM, Lois Foltan wrote: >> >> On 6/28/2016 9:28 AM, Zhengyu Gu wrote: >>> Thanks for the changes. >>> >>> PackageEntry::delete_qualified_exports() has nothing to do with >>> class unloading, should it be handled in earlier loop? or it may get >>> lost. >> >> Hi Zhengyu, >> >> PackageEntry::delete_qualified_exports() have everything to do with >> class unloading and is a direct consequence of a loader dying. When >> a class loader dies, its ModuleEntryTable and PackageEntryTable are >> deleted, see ClassLoaderData's destructor. In particular when a >> PackageEntryTable is deleted, each destructor is called for every >> package entry within that table which in return involves calling >> PackageEntry::delete_qualified_exports() if necessary. That section >> of code has no bearing on this webrev and the changes in >> ClassLoaderDataGraph::do_unloading. >> >> Thanks, >> Lois >> >>> >>> -Zhengyu >>> >>> On 06/27/2016 04:50 PM, Lois Foltan wrote: >>>> >>>> On 6/27/2016 12:03 PM, Zhengyu Gu wrote: >>>>> Hi Lois, >>>>> >>>>> I have a question: >>>>> >>>>> classLoaderData.cpp # 1004 - 1013 >>>>> >>>>> If there is no class loader unloaded, (for example, _unloading == >>>>> NULL), do you still need to execute this purge loop? >>>> Hi Zhengyu, >>>> >>>> Thank you for the review. I have addressed your concern by moving >>>> the purge loop into the following conditional that only executes >>>> "if (seen_dead_loader)", nice catch. This updated webrev also >>>> contains an improvement to the test ModuleStress.java to include a >>>> module defined to a custom system class loader, specified via >>>> -Djava.system.class.loader. >>>> >>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.2/webrev/ >>>> >>>> Thanks, >>>> Lois >>>> >>>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>>> >>>>> On 06/22/2016 10:51 AM, Lois Foltan wrote: >>>>>> >>>>>> On 6/22/2016 8:56 AM, Alan Bateman wrote: >>>>>>> >>>>>>> >>>>>>> On 22/06/2016 13:51, David Holmes wrote: >>>>>>>> >>>>>>>> How do you envisage any system classloader "dying" ?? >>>>>>> The system class loader (be it the built-in application class >>>>>>> loader or a custom system class loader configured via >>>>>>> -Djava.system.class.loader) will/can never be GC'ed. >>>>>>> ClassLoader.getSystemClassLoader() always returns a reference to >>>>>>> it (for example). >>>>>> Ahh, ok, I was being overly cautious, so no opportunity to reset >>>>>> the system class loader dynamically at all? >>>>>> SystemDictionary::_java_class_loader is not initialized until >>>>>> after the module system initialization is complete. Due to this I >>>>>> have updated my webrev to check for either the built-in >>>>>> application class loader or a custom system class loader and have >>>>>> renamed the method to is_system_class_loader(). >>>>>> >>>>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/ >>>>>> >>>>>> Thanks, >>>>>> Lois >>>>>> >>>>> >>>> >>> >> > From zgu at redhat.com Tue Jun 28 17:56:59 2016 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 28 Jun 2016 13:56:59 -0400 Subject: RFR (M): JDK-8159262: Walking PackageEntry Export and ModuleEntry Reads Must Occur Only When Neccessary And Wait Until ClassLoader's Aliveness Determined In-Reply-To: <5772B945.2040509@oracle.com> References: <57698069.80902@oracle.com> <1ecd880b-d5e0-42f6-64ce-0ec988aa5bc3@oracle.com> <4C657BEF-0623-4383-BCC5-26AA8159D10D@oracle.com> <7bdc8fec-5789-91d6-5d22-9a1bffac651a@oracle.com> <5A0B347B-FD2B-4D6D-BF1C-392146178CFB@oracle.com> <45e19eba-a728-dc5e-91df-6d25e4c2b0e0@oracle.com> <576A7210.3000402@oracle.com> <31a6057f-df05-d9ba-613d-4208dbd81a46@oracle.com> <576AA5E9.9040408@oracle.com> <57714E42.7000406@redhat.com> <57719197.5030305@oracle.com> <57727B90.8030203@redhat.com> <5772858F.5080507@oracle.com> <577292A3.9090508@redhat.com> <5772B945.2040509@oracle.com> Message-ID: <5772BA6B.4010307@redhat.com> On 06/28/2016 01:52 PM, Lois Foltan wrote: > > On 6/28/2016 11:07 AM, Zhengyu Gu wrote: >> Hi Lois, >> >> The comments in PackageEntry::delete_qualified_exports() suggests >> that it is related to a transition from qualified exports to >> unqualified. > > That is correct. A package can transition from being qualifiedly > exported, to unqualifiedly exported. Its exported scope is widened. A > package can not transition from being unqualifiedly exported to all > modules to being specifically qualified to one or more modules. > >> >> It seems to me that, when overriding package's exports from qualified >> to unqualified, ex. via JVM_AddModuleExportsToAll(), >> delete_qualified_exports() >> should be called. I don't see it has anything to do with class >> unloading. > > We chose not to delete the qualified exports at that point but to > delay that until the next GC safepoint. When a package does > transition from being qualifiedly exported to unqualifiedly exported, > its qualified exports list is moved to the _exported_pending_delete > field which is then deleted later, via a call to > PackageEntry::delete_qualified_exports(). That deletion of the > _exported_pending_delete list does occur either during the purge walk > or if the class loader that the package is defined to dies. I see. Thanks for the explanation. -Zhengyu > > Thanks, > Lois > >> >> Thanks, >> >> -Zhengyu >> >> >> >> On 06/28/2016 10:11 AM, Lois Foltan wrote: >>> >>> On 6/28/2016 9:28 AM, Zhengyu Gu wrote: >>>> Thanks for the changes. >>>> >>>> PackageEntry::delete_qualified_exports() has nothing to do with >>>> class unloading, should it be handled in earlier loop? or it may >>>> get lost. >>> >>> Hi Zhengyu, >>> >>> PackageEntry::delete_qualified_exports() have everything to do with >>> class unloading and is a direct consequence of a loader dying. When >>> a class loader dies, its ModuleEntryTable and PackageEntryTable are >>> deleted, see ClassLoaderData's destructor. In particular when a >>> PackageEntryTable is deleted, each destructor is called for every >>> package entry within that table which in return involves calling >>> PackageEntry::delete_qualified_exports() if necessary. That >>> section of code has no bearing on this webrev and the changes in >>> ClassLoaderDataGraph::do_unloading. >>> >>> Thanks, >>> Lois >>> >>>> >>>> -Zhengyu >>>> >>>> On 06/27/2016 04:50 PM, Lois Foltan wrote: >>>>> >>>>> On 6/27/2016 12:03 PM, Zhengyu Gu wrote: >>>>>> Hi Lois, >>>>>> >>>>>> I have a question: >>>>>> >>>>>> classLoaderData.cpp # 1004 - 1013 >>>>>> >>>>>> If there is no class loader unloaded, (for example, _unloading == >>>>>> NULL), do you still need to execute this purge loop? >>>>> Hi Zhengyu, >>>>> >>>>> Thank you for the review. I have addressed your concern by moving >>>>> the purge loop into the following conditional that only executes >>>>> "if (seen_dead_loader)", nice catch. This updated webrev also >>>>> contains an improvement to the test ModuleStress.java to include a >>>>> module defined to a custom system class loader, specified via >>>>> -Djava.system.class.loader. >>>>> >>>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.2/webrev/ >>>>> >>>>> Thanks, >>>>> Lois >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Zhengyu >>>>>> >>>>>> On 06/22/2016 10:51 AM, Lois Foltan wrote: >>>>>>> >>>>>>> On 6/22/2016 8:56 AM, Alan Bateman wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 22/06/2016 13:51, David Holmes wrote: >>>>>>>>> >>>>>>>>> How do you envisage any system classloader "dying" ?? >>>>>>>> The system class loader (be it the built-in application class >>>>>>>> loader or a custom system class loader configured via >>>>>>>> -Djava.system.class.loader) will/can never be GC'ed. >>>>>>>> ClassLoader.getSystemClassLoader() always returns a reference >>>>>>>> to it (for example). >>>>>>> Ahh, ok, I was being overly cautious, so no opportunity to reset >>>>>>> the system class loader dynamically at all? >>>>>>> SystemDictionary::_java_class_loader is not initialized until >>>>>>> after the module system initialization is complete. Due to this >>>>>>> I have updated my webrev to check for either the built-in >>>>>>> application class loader or a custom system class loader and >>>>>>> have renamed the method to is_system_class_loader(). >>>>>>> >>>>>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8159262.1/webrev/ >>>>>>> >>>>>>> Thanks, >>>>>>> Lois >>>>>>> >>>>>> >>>>> >>>> >>> >> > From kim.barrett at oracle.com Tue Jun 28 18:18:00 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 28 Jun 2016 14:18:00 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: Message-ID: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> > On Jun 28, 2016, at 12:04 AM, David Holmes wrote: > > Hi Kim, > > I like all the removal of the pending-list-locker related code, but can't really comment on the details of how it was replaced and interacts with all the GC code. The interface to the Reference class is fine, it is the GC code that pushes into the reference queue that I can't really comment on. Thanks David. > I have a couple of queries following up from Coleen's and Dan's reviews. > > First, the synchronization of the pending-reference-list leaves me somewhat perplexed. As Coleen noted you require the heap_lock to be held but also use an Atomic::xchg. You have a comment: > > + // owns the lock. Swap is used by parallel non-concurrent reference > + // processing threads, where some higher level controller owns > + // Heap_lock, so requires the lock is locked, but not necessarily by > + // the current thread. > > Can you clarify the higher-level protocol that is at play there. Asserting that "someone" owns a lock seems only marginally useful if you can't be sure who that owner is, or when they might release it. Some more direct detecting of being within this higher-level protocol would be better, if it is possible to detect. Was Per?s explanation sufficient? > As previously mentioned the change to the initialization order is a concern to me - there are always unexpected consequences of making such changes, no matter how straight-forward they seem at the time. Pre-initialization of exception classes is not really essential as the attempt to throw any of them from Java code will force initialization anyway - it's only for exceptions created and thrown from the VM code that direct initialization is needed. The problematic case is OOME because throwing the OOME may trigger a secondary OOME during that class initialization etc. Hence we try to deal with that by pre-allocating instances that do not have stacktraces etc, so they can be thrown safely. Hence my earlier comment that I think the real bug in your situation is that gen_out_of_memory_error() is not considering how far into the VM init sequence we are, and that it should be returning the pre-allocated instance with no backtrace. I'm also wondering why the existing order must have worked before the pre-initialization of InterruptedException by Reference, but now doesn't when we take that out. I'll see if I can figure out what's going on there. It might be some bug was introduced but was being masked by the Reference initialization. > --- > > A query on the JDK side: > > src/java.base/share/classes/java/lang/ref/Reference.java > > private static native Reference popReferencePendingList(boolean wait); > > I'm intrigued by the use of the lower-bounded wildcard using Object. As Object has no super-types this looks very strange and should be equivalent to the more common upper-bounded wildcard using Object ie Reference or more concisely Reference. I see this construct exists in the current code for the ReferenceQueue, but I am quite intrigued as to why? (Someone getting ready for Any-types? :) ) I botched that. I meant to have a real Java programmer (which I don't qualify as) look at that part of the change before sending it out for review, but seem to have forgotten to do so. And lulled into a false sense of security, since neither the compiler nor the runtime complained, unlike the reams of template instantiation error output or segfaults at runtime that I'd expect with C++... From daniel.daugherty at oracle.com Tue Jun 28 18:19:51 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 28 Jun 2016 12:19:51 -0600 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <5772A7CB.6070007@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> Message-ID: <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> On 6/28/16 10:37 AM, serguei.spitsyn at oracle.com wrote: > Hi Harold, > > Thank you again for the comments! > This is the updated webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.5/ > make/test/JtregNative.gmk No comments. src/share/vm/classfile/modules.hpp No comments. src/share/vm/classfile/modules.cpp L826: assert(h_loader.is_null() || java_lang_ClassLoader::is_subclass(h_loader->klass()), L827: "Class loader is not a subclass of java.lang.ClassLoader"); nit: indent on L827 is off by 1 space I'll have to check the upper layers of this API, but if an agent can pass a bad 'class_loader' parameter and get this assert() to fire, then that's not good. Hopefully a bad 'class_loader' parameter is caught at a higher layer. Update: Yes, passing a non-NULL jobject as the class_loader parameter when the jobject does not refer to a "class loader" is caught at the upper layer. L828: assert(package_str != NULL, "the package_str should not be NULL"); Same concern about the package_str parameter. Update: Yes, the generated JVM/TI glue code should catch a NULL package_name/package_str at the upper layers. src/share/vm/prims/jvmti.xml L6550: L6551: L6552: L6553: On return, points to a java.lang.reflect.Module object. L6554: L6555: The above wording doesn't allow for module_ptr to be NULL which is a mismatch with the description. L2518: function can be used to map class loader and package name to a module. Typo: 'map class loader and package name' -> 'map a class loader and a package name' src/share/vm/prims/jvmtiEnv.cpp L204: // class_loader - NULL is a valid value, must be pre-checked L205: // package_name - pre-checked for NULL L206: // module_ptr - pre-checked for NULL The jvmti.xml file doesn't mark package_name or module_ptr with so both of those should be checked by the generated glue code. class_loader is marked with so a NULL class_loader will get to here: L217: jobject module = Modules::get_named_module(h_loader, package_name, THREAD); and it looks like all the code paths in get_named_module() properly account for both NULL and non-NULL h_loader. Cool. test/serviceability/jvmti/GetNamedModule/MyPackage/GetNamedModuleTest.java L42: System.err.println("java.library.path:" nit: a space between the ':' and '"' would make the output more readable test/serviceability/jvmti/GetNamedModule/libGetNamedModuleTest.c L81: res = JNI_ENV_PTR(jvm)->GetEnv(JNI_ENV_ARG(jvm, (void **) &jvmti), L82: JVMTI_VERSION_1_1); I was expecting this test to ask for the JVM/TI version that includes support for GetAllModules() and GetNamesModule(). Looks like that is version 9.0.0 or newer aka JVMTI_VERSION_9. L360: if (module != NULL || mod_name !=NULL) { bit: space after '!=' and before NULL Has someone checked the generated glue code for completeness and proper checks? Dan > > Thanks, > Serguei > > > On 6/28/16 07:32, harold seigel wrote: >> >> Hi Serguei, >> >> Looks good. >> >> 1. In modules.cpp, the first assert in get_named_module() has the >> wrong function name: >> >> 825 assert(ModuleEntryTable::javabase_defined(), >> 826 "Attempt to call *get_module_by_package_name* before java.base is >> defined"); >> >> 2. Also, is a check needed to ensure that package_str is not null? >> >> 3. Is the ResourceMark(THREAD) needed at line 824? >> >> Thanks, Harold >> >> On 6/28/2016 4:54 AM, serguei.spitsyn at oracle.com wrote: >>> Hi David, >>> >>> Thank you for the comments! >>> I agree with you. >>> >>> Updated Hotspot webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.4/ >>> >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 6/27/16 22:06, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> Overall this looks a lot clearer/simpler. >>>> >>>> On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review the Jigsaw fix for the enhancement: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>>>> >>>>>> >>>>>> The Hotspot webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>>>>> >>>> >>>> Are there intended to be other callers of Module::get_named_module? >>>> If not it seems odd to go to all the trouble of throwing >>>> exceptions, just to have the caller clear them and return an error >>>> code. Or you could move all that argument checking code into the >>>> JVMTI function directly - if called internally you would just >>>> assert that arguments are as expected. >>>> >>>> >>>> src/share/vm/prims/jvmti.xml >>>> >>>> + otherwise the NULL is returned. >>>> >>>> Delete "the". >>>> >>>> Otherwise all looks good to me. >>>> >>>>>> >>>>>> >>>>>> The Jdk webrev is the same: >>>>>> >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>>>> >>>>> >>>>> Sorry, the Jdk webrev changed as well: >>>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >>>>> >>>> >>>> Looks fine. >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>>> >>>>>> >>>>>> Summary: >>>>>> >>>>>> This is the review round #3. >>>>>> Alan suggested to replace the function GetModuleByPackageName with >>>>>> the GetNamedModule. >>>>>> New function will return NULL if the package is not in a module >>>>>> defined to the class loader. >>>>>> It simplifies the API and makes it easier to specify. >>>>>> JVM TI agents that instrument code in named modules need the >>>>>> Module >>>>>> at class load time. >>>>>> >>>>>> One question that came from the function semantics change. >>>>>> I had to implement the Modules::get_named_module() from scratch >>>>>> independently of the existing >>>>>> Modules::get_module_by_package_name() and Modules::get_module(). >>>>>> The issue is that the Modules::get_module() can return the unnamed >>>>>> module whereas the >>>>>> JVMTI helper Modules::get_named_module() should return NULL >>>>>> instead >>>>>> of the unnamed module. >>>>>> Please, let me know if it is Ok or if you have better ideas how to >>>>>> share the code. >>>>>> >>>>>> This is the Summary from review round #1: >>>>>> >>>>>> One way to do this is by introducing a new ClassFileLoadHook that >>>>>> takes an additional parameter but this approach is disruptive. >>>>>> The alternative option is a JVM TI function that maps a >>>>>> classloader >>>>>> + package name to a module. >>>>>> We were initially not confident with this approach so we >>>>>> introduced >>>>>> it as JVM function JVM_GetModuleByPackageName. >>>>>> Based on experience to date then this approach seems okay and so >>>>>> this function needs to be promoted to a JVMTI function. >>>>>> >>>>>> It includes new jtreg test with native JVMTI agent. >>>>>> >>>>>> >>>>>> Testing: >>>>>> Run newly developed jtreg test. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>> >>> >> > From kim.barrett at oracle.com Tue Jun 28 18:21:19 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 28 Jun 2016 14:21:19 -0400 Subject: RFR: JDK-8160356: invalid suffix on literal warning is occurred with GCC 6 In-Reply-To: References: <96c1c5d9-403c-bdcf-4574-848a50b7521a@gmail.com> <6859BC03-4DAF-492F-AD5B-372819139A7A@oracle.com> Message-ID: > On Jun 28, 2016, at 12:46 PM, Vladimir Kozlov wrote: > > Lets not complicate the process. Currently it is the bug (compilation warnings with gcc6) and there is reviewed fix (very simple). Lets push it and be done. > > Thanks, > Vladimir Vladimir - since you are ok with that, then I am too. Yasumasa - I can sponsor this change. From coleen.phillimore at oracle.com Tue Jun 28 19:17:01 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 28 Jun 2016 15:17:01 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> Message-ID: <3bd01eb9-e396-c104-e7e5-239ea86e0304@oracle.com> On 6/28/16 2:18 PM, Kim Barrett wrote: >> On Jun 28, 2016, at 12:04 AM, David Holmes wrote: >> >> Hi Kim, >> >> I like all the removal of the pending-list-locker related code, but can't really comment on the details of how it was replaced and interacts with all the GC code. The interface to the Reference class is fine, it is the GC code that pushes into the reference queue that I can't really comment on. > Thanks David. > >> I have a couple of queries following up from Coleen's and Dan's reviews. >> >> First, the synchronization of the pending-reference-list leaves me somewhat perplexed. As Coleen noted you require the heap_lock to be held but also use an Atomic::xchg. You have a comment: >> >> + // owns the lock. Swap is used by parallel non-concurrent reference >> + // processing threads, where some higher level controller owns >> + // Heap_lock, so requires the lock is locked, but not necessarily by >> + // the current thread. >> >> Can you clarify the higher-level protocol that is at play there. Asserting that "someone" owns a lock seems only marginally useful if you can't be sure who that owner is, or when they might release it. Some more direct detecting of being within this higher-level protocol would be better, if it is possible to detect. > Was Per?s explanation sufficient? > >> As previously mentioned the change to the initialization order is a concern to me - there are always unexpected consequences of making such changes, no matter how straight-forward they seem at the time. Pre-initialization of exception classes is not really essential as the attempt to throw any of them from Java code will force initialization anyway - it's only for exceptions created and thrown from the VM code that direct initialization is needed. The problematic case is OOME because throwing the OOME may trigger a secondary OOME during that class initialization etc. Hence we try to deal with that by pre-allocating instances that do not have stacktraces etc, so they can be thrown safely. Hence my earlier comment that I think the real bug in your situation is that gen_out_of_memory_error() is not considering how far into the VM init sequence we are, and that it should be returning the pre-allocated instance with no backtrace. > I'm also wondering why the existing order must have worked before the > pre-initialization of InterruptedException by Reference, but now > doesn't when we take that out. I'll see if I can figure out what's > going on there. It might be some bug was introduced but was being > masked by the Reference initialization. Regarding the initialization order. It would be interesting to know what bug you hit, because it looks like this call_initPhase1() function was added for modules to break up java.lang.System initialization. It was probably added in this place because it initialized class Property, and java/lang/Throwable. used to query a property. This was taken out so it is safe to move the new initPhase1() initialization later. Exceptions, especially OOM should be initialized very early, especially since OOM has preallocated stack traces. It wouldn't surprise me if it needed to be moved further up someday. All this depends on future JDK changes though. Again, I think this looks fine. I believe your testing would have found if there was anything wrong with this. Coleen > >> --- >> >> A query on the JDK side: >> >> src/java.base/share/classes/java/lang/ref/Reference.java >> >> private static native Reference popReferencePendingList(boolean wait); >> >> I'm intrigued by the use of the lower-bounded wildcard using Object. As Object has no super-types this looks very strange and should be equivalent to the more common upper-bounded wildcard using Object ie Reference or more concisely Reference. I see this construct exists in the current code for the ReferenceQueue, but I am quite intrigued as to why? (Someone getting ready for Any-types? :) ) > I botched that. I meant to have a real Java programmer (which I don't > qualify as) look at that part of the change before sending it out for > review, but seem to have forgotten to do so. And lulled into a false > sense of security, since neither the compiler nor the runtime > complained, unlike the reams of template instantiation error output or > segfaults at runtime that I'd expect with C++... > From serguei.spitsyn at oracle.com Tue Jun 28 19:33:46 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 12:33:46 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> Message-ID: <5772D11A.4010809@oracle.com> Thanks, Harold! Serguei On 6/28/16 10:45, harold seigel wrote: > > Hi Serguei, > > It looks good! > > Thanks, Harold > > > On 6/28/2016 12:37 PM, serguei.spitsyn at oracle.com wrote: >> Hi Harold, >> >> Thank you again for the comments! >> This is the updated webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.5/ >> >> Thanks, >> Serguei >> >> >> On 6/28/16 07:32, harold seigel wrote: >>> >>> Hi Serguei, >>> >>> Looks good. >>> >>> 1. In modules.cpp, the first assert in get_named_module() has the >>> wrong function name: >>> >>> 825 assert(ModuleEntryTable::javabase_defined(), >>> 826 "Attempt to call *get_module_by_package_name* before java.base >>> is defined"); >>> >>> 2. Also, is a check needed to ensure that package_str is not null? >>> >>> 3. Is the ResourceMark(THREAD) needed at line 824? >>> >>> Thanks, Harold >>> >>> On 6/28/2016 4:54 AM, serguei.spitsyn at oracle.com wrote: >>>> Hi David, >>>> >>>> Thank you for the comments! >>>> I agree with you. >>>> >>>> Updated Hotspot webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.4/ >>>> >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> On 6/27/16 22:06, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> Overall this looks a lot clearer/simpler. >>>>> >>>>> On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, review the Jigsaw fix for the enhancement: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>>>>> >>>>>>> >>>>>>> The Hotspot webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>>>>>> >>>>> >>>>> Are there intended to be other callers of >>>>> Module::get_named_module? If not it seems odd to go to all the >>>>> trouble of throwing exceptions, just to have the caller clear them >>>>> and return an error code. Or you could move all that argument >>>>> checking code into the JVMTI function directly - if called >>>>> internally you would just assert that arguments are as expected. >>>>> >>>>> >>>>> src/share/vm/prims/jvmti.xml >>>>> >>>>> + otherwise the NULL is returned. >>>>> >>>>> Delete "the". >>>>> >>>>> Otherwise all looks good to me. >>>>> >>>>>>> >>>>>>> >>>>>>> The Jdk webrev is the same: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>>>>> >>>>>> >>>>>> Sorry, the Jdk webrev changed as well: >>>>>> >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >>>>>> >>>>> >>>>> Looks fine. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> >>>>>>> This is the review round #3. >>>>>>> Alan suggested to replace the function GetModuleByPackageName >>>>>>> with >>>>>>> the GetNamedModule. >>>>>>> New function will return NULL if the package is not in a module >>>>>>> defined to the class loader. >>>>>>> It simplifies the API and makes it easier to specify. >>>>>>> JVM TI agents that instrument code in named modules need the >>>>>>> Module >>>>>>> at class load time. >>>>>>> >>>>>>> One question that came from the function semantics change. >>>>>>> I had to implement the Modules::get_named_module() from scratch >>>>>>> independently of the existing >>>>>>> Modules::get_module_by_package_name() and Modules::get_module(). >>>>>>> The issue is that the Modules::get_module() can return the >>>>>>> unnamed >>>>>>> module whereas the >>>>>>> JVMTI helper Modules::get_named_module() should return NULL >>>>>>> instead >>>>>>> of the unnamed module. >>>>>>> Please, let me know if it is Ok or if you have better ideas >>>>>>> how to >>>>>>> share the code. >>>>>>> >>>>>>> This is the Summary from review round #1: >>>>>>> >>>>>>> One way to do this is by introducing a new ClassFileLoadHook that >>>>>>> takes an additional parameter but this approach is disruptive. >>>>>>> The alternative option is a JVM TI function that maps a >>>>>>> classloader >>>>>>> + package name to a module. >>>>>>> We were initially not confident with this approach so we >>>>>>> introduced >>>>>>> it as JVM function JVM_GetModuleByPackageName. >>>>>>> Based on experience to date then this approach seems okay and so >>>>>>> this function needs to be promoted to a JVMTI function. >>>>>>> >>>>>>> It includes new jtreg test with native JVMTI agent. >>>>>>> >>>>>>> >>>>>>> Testing: >>>>>>> Run newly developed jtreg test. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Tue Jun 28 19:34:56 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 12:34:56 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <2bf0d051-1fa9-3bbd-2d52-d9b117d366c6@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <2bf0d051-1fa9-3bbd-2d52-d9b117d366c6@oracle.com> Message-ID: <5772D160.9000002@oracle.com> On 6/28/16 10:24, Daniel D. Daugherty wrote: > On 6/27/16 10:20 PM, serguei.spitsyn at oracle.com wrote: >> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>> Please, review the Jigsaw fix for the enhancement: >>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>> >>> >>> The Hotspot webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>> >>> >>> >>> The Jdk webrev is the same: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>> >> >> Sorry, the Jdk webrev changed as well: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >> ' > > src/java.base/share/native/include/jvmti.h > No comments. > > Thumbs up on the 'jdk' repo change. Thanks, Dan! Serguei > > Dan > > > > >> >> >> Thanks, >> Serguei >> >> >>> >>> >>> Summary: >>> >>> This is the review round #3. >>> Alan suggested to replace the function GetModuleByPackageName with >>> the GetNamedModule. >>> New function will return NULL if the package is not in a module >>> defined to the class loader. >>> It simplifies the API and makes it easier to specify. >>> JVM TI agents that instrument code in named modules need the Module >>> at class load time. >>> >>> One question that came from the function semantics change. >>> I had to implement the Modules::get_named_module() from scratch >>> independently of the existing >>> Modules::get_module_by_package_name() and Modules::get_module(). >>> The issue is that the Modules::get_module() can return the unnamed >>> module whereas the >>> JVMTI helper Modules::get_named_module() should return NULL >>> instead of the unnamed module. >>> Please, let me know if it is Ok or if you have better ideas how to >>> share the code. >>> >>> This is the Summary from review round #1: >>> >>> One way to do this is by introducing a new ClassFileLoadHook that >>> takes an additional parameter but this approach is disruptive. >>> The alternative option is a JVM TI function that maps a >>> classloader + package name to a module. >>> We were initially not confident with this approach so we >>> introduced it as JVM function JVM_GetModuleByPackageName. >>> Based on experience to date then this approach seems okay and so >>> this function needs to be promoted to a JVMTI function. >>> >>> It includes new jtreg test with native JVMTI agent. >>> >>> >>> Testing: >>> Run newly developed jtreg test. >>> >>> Thanks, >>> Serguei >> > From serguei.spitsyn at oracle.com Tue Jun 28 20:11:42 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 13:11:42 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> Message-ID: <5772D9FE.5030804@oracle.com> On 6/28/16 11:19, Daniel D. Daugherty wrote: > On 6/28/16 10:37 AM, serguei.spitsyn at oracle.com wrote: >> Hi Harold, >> >> Thank you again for the comments! >> This is the updated webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.5/ >> > > make/test/JtregNative.gmk > No comments. > > src/share/vm/classfile/modules.hpp > No comments. > > src/share/vm/classfile/modules.cpp > L826: assert(h_loader.is_null() || > java_lang_ClassLoader::is_subclass(h_loader->klass()), > L827: "Class loader is not a subclass of > java.lang.ClassLoader"); > nit: indent on L827 is off by 1 space Thanks, will fix. > > I'll have to check the upper layers of this API, but if an > agent can pass a bad 'class_loader' parameter and get this > assert() to fire, then that's not good. Hopefully a bad > 'class_loader' parameter is caught at a higher layer. Not sure, what do you mean. Do you mean the generated JVMTI upper layer or the JvmtiEnv::GetNamedModule? Probably, the generated code. > > Update: Yes, passing a non-NULL jobject as the class_loader > parameter > when the jobject does not refer to a "class loader" is caught > at the upper layer. The upper layer does not check that it is a class loader, just for non-NULL. I think, it is good to have an assert here to double-checks the pre-conditions as other caller can be added later. But I'm Ok to get rid of it if you suggest. > > L828: assert(package_str != NULL, "the package_str should not be > NULL"); > Same concern about the package_str parameter. > > Update: Yes, the generated JVM/TI glue code should catch a > NULL package_name/package_str at the upper layers. Yes, but this assert is intentional as above. > > > src/share/vm/prims/jvmti.xml > L6550: > L6551: > L6552: > L6553: On return, points to a > java.lang.reflect.Module object. > L6554: > L6555: > > The above wording doesn't allow for module_ptr to be NULL which > is a mismatch with the description. I disagree (or maybe I got it incorrectly). Pointing to NULL and be NULL is different. It is not allowed for the module_ptr to be NULL but Ok to pint to NULL on return. > > L2518: function can be used to map class loader and package > name to a module. > Typo: 'map class loader and package name' > -> 'map a class loader and a package name' Good catch, thanks! Will fix. > > > src/share/vm/prims/jvmtiEnv.cpp > L204: // class_loader - NULL is a valid value, must be pre-checked > L205: // package_name - pre-checked for NULL > L206: // module_ptr - pre-checked for NULL > The jvmti.xml file doesn't mark package_name or module_ptr > with so both of those should be checked by the > generated glue code. > > class_loader is marked with so a NULL class_loader > will get to here: > > L217: jobject module = Modules::get_named_module(h_loader, > package_name, THREAD); > > and it looks like all the code paths in get_named_module() > properly account for both NULL and non-NULL h_loader. Cool. Good. Thank you for checking. > > test/serviceability/jvmti/GetNamedModule/MyPackage/GetNamedModuleTest.java > > L42: System.err.println("java.library.path:" > nit: a space between the ':' and '"' would make the > output more readable Thanks, will fix. > > test/serviceability/jvmti/GetNamedModule/libGetNamedModuleTest.c > L81: res = JNI_ENV_PTR(jvm)->GetEnv(JNI_ENV_ARG(jvm, (void **) > &jvmti), > L82: JVMTI_VERSION_1_1); > I was expecting this test to ask for the JVM/TI version that > includes support for GetAllModules() and GetNamesModule(). > Looks like that is version 9.0.0 or newer aka JVMTI_VERSION_9. You are right. Will fix. > > L360: if (module != NULL || mod_name !=NULL) { > bit: space after '!=' and before NULL Thanks, will fix. > > Has someone checked the generated glue code for completeness and > proper checks? I checked it some time ago. But will double-check it. Thank you for the review and detailed comments! Serguei > > Dan > > >> >> Thanks, >> Serguei >> >> >> On 6/28/16 07:32, harold seigel wrote: >>> >>> Hi Serguei, >>> >>> Looks good. >>> >>> 1. In modules.cpp, the first assert in get_named_module() has the >>> wrong function name: >>> >>> 825 assert(ModuleEntryTable::javabase_defined(), >>> 826 "Attempt to call *get_module_by_package_name* before java.base >>> is defined"); >>> >>> 2. Also, is a check needed to ensure that package_str is not null? >>> >>> 3. Is the ResourceMark(THREAD) needed at line 824? >>> >>> Thanks, Harold >>> >>> On 6/28/2016 4:54 AM, serguei.spitsyn at oracle.com wrote: >>>> Hi David, >>>> >>>> Thank you for the comments! >>>> I agree with you. >>>> >>>> Updated Hotspot webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.4/ >>>> >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> On 6/27/16 22:06, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> Overall this looks a lot clearer/simpler. >>>>> >>>>> On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, review the Jigsaw fix for the enhancement: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>>>>> >>>>>>> >>>>>>> The Hotspot webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>>>>>> >>>>> >>>>> Are there intended to be other callers of >>>>> Module::get_named_module? If not it seems odd to go to all the >>>>> trouble of throwing exceptions, just to have the caller clear them >>>>> and return an error code. Or you could move all that argument >>>>> checking code into the JVMTI function directly - if called >>>>> internally you would just assert that arguments are as expected. >>>>> >>>>> >>>>> src/share/vm/prims/jvmti.xml >>>>> >>>>> + otherwise the NULL is returned. >>>>> >>>>> Delete "the". >>>>> >>>>> Otherwise all looks good to me. >>>>> >>>>>>> >>>>>>> >>>>>>> The Jdk webrev is the same: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>>>>> >>>>>> >>>>>> Sorry, the Jdk webrev changed as well: >>>>>> >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >>>>>> >>>>> >>>>> Looks fine. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> >>>>>>> This is the review round #3. >>>>>>> Alan suggested to replace the function GetModuleByPackageName >>>>>>> with >>>>>>> the GetNamedModule. >>>>>>> New function will return NULL if the package is not in a module >>>>>>> defined to the class loader. >>>>>>> It simplifies the API and makes it easier to specify. >>>>>>> JVM TI agents that instrument code in named modules need the >>>>>>> Module >>>>>>> at class load time. >>>>>>> >>>>>>> One question that came from the function semantics change. >>>>>>> I had to implement the Modules::get_named_module() from scratch >>>>>>> independently of the existing >>>>>>> Modules::get_module_by_package_name() and Modules::get_module(). >>>>>>> The issue is that the Modules::get_module() can return the >>>>>>> unnamed >>>>>>> module whereas the >>>>>>> JVMTI helper Modules::get_named_module() should return NULL >>>>>>> instead >>>>>>> of the unnamed module. >>>>>>> Please, let me know if it is Ok or if you have better ideas >>>>>>> how to >>>>>>> share the code. >>>>>>> >>>>>>> This is the Summary from review round #1: >>>>>>> >>>>>>> One way to do this is by introducing a new ClassFileLoadHook that >>>>>>> takes an additional parameter but this approach is disruptive. >>>>>>> The alternative option is a JVM TI function that maps a >>>>>>> classloader >>>>>>> + package name to a module. >>>>>>> We were initially not confident with this approach so we >>>>>>> introduced >>>>>>> it as JVM function JVM_GetModuleByPackageName. >>>>>>> Based on experience to date then this approach seems okay and so >>>>>>> this function needs to be promoted to a JVMTI function. >>>>>>> >>>>>>> It includes new jtreg test with native JVMTI agent. >>>>>>> >>>>>>> >>>>>>> Testing: >>>>>>> Run newly developed jtreg test. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Tue Jun 28 20:37:10 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 13:37:10 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <5772D9FE.5030804@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> Message-ID: <5772DFF6.7040907@oracle.com> On 6/28/16 13:11, serguei.spitsyn at oracle.com wrote: > On 6/28/16 11:19, Daniel D. Daugherty wrote: >> On 6/28/16 10:37 AM, serguei.spitsyn at oracle.com wrote: >>> Hi Harold, >>> >>> Thank you again for the comments! >>> This is the updated webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.5/ >>> >> . . . >> Update: Yes, passing a non-NULL jobject as the class_loader >> parameter >> when the jobject does not refer to a "class loader" is >> caught >> at the upper layer. > > The upper layer does not check that it is a class loader, just for > non-NULL. Sorry, I mistyped the above. The upper layer does not check for the NULL which is correct as it is allowed. Thanks, Serguei > I think, it is good to have an assert here to double-checks the > pre-conditions as other caller can be added later. > But I'm Ok to get rid of it if you suggest. > From serguei.spitsyn at oracle.com Tue Jun 28 20:42:24 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 13:42:24 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> Message-ID: <5772E130.40109@oracle.com> Dan, The updated webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.6/ > Has someone checked the generated glue code for completeness and proper checks? This is the generated upper layer function in the jvmtiEnter.cpp: 3185 static jvmtiError JNICALL 3186 jvmti_GetNamedModule(jvmtiEnv* env, 3187 jobject class_loader, 3188 const char* package_name, 3189 jobject* module_ptr) { 3190 3191 #if !INCLUDE_JVMTI 3192 return JVMTI_ERROR_NOT_AVAILABLE; 3193 #else 3194 if(!JvmtiEnv::is_vm_live()) { 3195 return JVMTI_ERROR_WRONG_PHASE; 3196 } 3197 Thread* this_thread = Thread::current_or_null(); 3198 if (this_thread == NULL || !this_thread->is_Java_thread()) { 3199 return JVMTI_ERROR_UNATTACHED_THREAD; 3200 } 3201 JavaThread* current_thread = (JavaThread*)this_thread; 3202 ThreadInVMfromNative __tiv(current_thread); 3203 VM_ENTRY_BASE(jvmtiError, jvmti_GetNamedModule , current_thread) 3204 debug_only(VMNativeEntryWrapper __vew;) 3205 CautiouslyPreserveExceptionMark __em(this_thread); 3206 JvmtiEnv* jvmti_env = JvmtiEnv::JvmtiEnv_from_jvmti_env(env); 3207 if (!jvmti_env->is_valid()) { 3208 return JVMTI_ERROR_INVALID_ENVIRONMENT; 3209 } 3210 jvmtiError err; 3211 if (package_name == NULL) { 3212 return JVMTI_ERROR_NULL_POINTER; 3213 } 3214 if (module_ptr == NULL) { 3215 return JVMTI_ERROR_NULL_POINTER; 3216 } 3217 err = jvmti_env->GetNamedModule(class_loader, package_name, module_ptr); 3218 return err; 3219 #endif // INCLUDE_JVMTI 3220 } I do not see any problems in the above. Thanks, Serguei On 6/28/16 11:19, Daniel D. Daugherty wrote: > On 6/28/16 10:37 AM, serguei.spitsyn at oracle.com wrote: >> Hi Harold, >> >> Thank you again for the comments! >> This is the updated webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.5/ >> > > make/test/JtregNative.gmk > No comments. > > src/share/vm/classfile/modules.hpp > No comments. > > src/share/vm/classfile/modules.cpp > L826: assert(h_loader.is_null() || > java_lang_ClassLoader::is_subclass(h_loader->klass()), > L827: "Class loader is not a subclass of > java.lang.ClassLoader"); > nit: indent on L827 is off by 1 space > > I'll have to check the upper layers of this API, but if an > agent can pass a bad 'class_loader' parameter and get this > assert() to fire, then that's not good. Hopefully a bad > 'class_loader' parameter is caught at a higher layer. > > Update: Yes, passing a non-NULL jobject as the class_loader > parameter > when the jobject does not refer to a "class loader" is caught > at the upper layer. > > L828: assert(package_str != NULL, "the package_str should not be > NULL"); > Same concern about the package_str parameter. > > Update: Yes, the generated JVM/TI glue code should catch a > NULL package_name/package_str at the upper layers. > > > src/share/vm/prims/jvmti.xml > L6550: > L6551: > L6552: > L6553: On return, points to a > java.lang.reflect.Module object. > L6554: > L6555: > > The above wording doesn't allow for module_ptr to be NULL which > is a mismatch with the description. > > L2518: function can be used to map class loader and package > name to a module. > Typo: 'map class loader and package name' > -> 'map a class loader and a package name' > > > src/share/vm/prims/jvmtiEnv.cpp > L204: // class_loader - NULL is a valid value, must be pre-checked > L205: // package_name - pre-checked for NULL > L206: // module_ptr - pre-checked for NULL > The jvmti.xml file doesn't mark package_name or module_ptr > with so both of those should be checked by the > generated glue code. > > class_loader is marked with so a NULL class_loader > will get to here: > > L217: jobject module = Modules::get_named_module(h_loader, > package_name, THREAD); > > and it looks like all the code paths in get_named_module() > properly account for both NULL and non-NULL h_loader. Cool. > > test/serviceability/jvmti/GetNamedModule/MyPackage/GetNamedModuleTest.java > > L42: System.err.println("java.library.path:" > nit: a space between the ':' and '"' would make the > output more readable > > test/serviceability/jvmti/GetNamedModule/libGetNamedModuleTest.c > L81: res = JNI_ENV_PTR(jvm)->GetEnv(JNI_ENV_ARG(jvm, (void **) > &jvmti), > L82: JVMTI_VERSION_1_1); > I was expecting this test to ask for the JVM/TI version that > includes support for GetAllModules() and GetNamesModule(). > Looks like that is version 9.0.0 or newer aka JVMTI_VERSION_9. > > L360: if (module != NULL || mod_name !=NULL) { > bit: space after '!=' and before NULL > > Has someone checked the generated glue code for completeness and > proper checks? > > Dan > > >> >> Thanks, >> Serguei >> >> >> On 6/28/16 07:32, harold seigel wrote: >>> >>> Hi Serguei, >>> >>> Looks good. >>> >>> 1. In modules.cpp, the first assert in get_named_module() has the >>> wrong function name: >>> >>> 825 assert(ModuleEntryTable::javabase_defined(), >>> 826 "Attempt to call *get_module_by_package_name* before java.base >>> is defined"); >>> >>> 2. Also, is a check needed to ensure that package_str is not null? >>> >>> 3. Is the ResourceMark(THREAD) needed at line 824? >>> >>> Thanks, Harold >>> >>> On 6/28/2016 4:54 AM, serguei.spitsyn at oracle.com wrote: >>>> Hi David, >>>> >>>> Thank you for the comments! >>>> I agree with you. >>>> >>>> Updated Hotspot webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.4/ >>>> >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> On 6/27/16 22:06, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> Overall this looks a lot clearer/simpler. >>>>> >>>>> On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, review the Jigsaw fix for the enhancement: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>>>>> >>>>>>> >>>>>>> The Hotspot webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>>>>>> >>>>> >>>>> Are there intended to be other callers of >>>>> Module::get_named_module? If not it seems odd to go to all the >>>>> trouble of throwing exceptions, just to have the caller clear them >>>>> and return an error code. Or you could move all that argument >>>>> checking code into the JVMTI function directly - if called >>>>> internally you would just assert that arguments are as expected. >>>>> >>>>> >>>>> src/share/vm/prims/jvmti.xml >>>>> >>>>> + otherwise the NULL is returned. >>>>> >>>>> Delete "the". >>>>> >>>>> Otherwise all looks good to me. >>>>> >>>>>>> >>>>>>> >>>>>>> The Jdk webrev is the same: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>>>>> >>>>>> >>>>>> Sorry, the Jdk webrev changed as well: >>>>>> >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >>>>>> >>>>> >>>>> Looks fine. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> >>>>>>> This is the review round #3. >>>>>>> Alan suggested to replace the function GetModuleByPackageName >>>>>>> with >>>>>>> the GetNamedModule. >>>>>>> New function will return NULL if the package is not in a module >>>>>>> defined to the class loader. >>>>>>> It simplifies the API and makes it easier to specify. >>>>>>> JVM TI agents that instrument code in named modules need the >>>>>>> Module >>>>>>> at class load time. >>>>>>> >>>>>>> One question that came from the function semantics change. >>>>>>> I had to implement the Modules::get_named_module() from scratch >>>>>>> independently of the existing >>>>>>> Modules::get_module_by_package_name() and Modules::get_module(). >>>>>>> The issue is that the Modules::get_module() can return the >>>>>>> unnamed >>>>>>> module whereas the >>>>>>> JVMTI helper Modules::get_named_module() should return NULL >>>>>>> instead >>>>>>> of the unnamed module. >>>>>>> Please, let me know if it is Ok or if you have better ideas >>>>>>> how to >>>>>>> share the code. >>>>>>> >>>>>>> This is the Summary from review round #1: >>>>>>> >>>>>>> One way to do this is by introducing a new ClassFileLoadHook that >>>>>>> takes an additional parameter but this approach is disruptive. >>>>>>> The alternative option is a JVM TI function that maps a >>>>>>> classloader >>>>>>> + package name to a module. >>>>>>> We were initially not confident with this approach so we >>>>>>> introduced >>>>>>> it as JVM function JVM_GetModuleByPackageName. >>>>>>> Based on experience to date then this approach seems okay and so >>>>>>> this function needs to be promoted to a JVMTI function. >>>>>>> >>>>>>> It includes new jtreg test with native JVMTI agent. >>>>>>> >>>>>>> >>>>>>> Testing: >>>>>>> Run newly developed jtreg test. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>> >>>> >>> >> > From daniel.daugherty at oracle.com Tue Jun 28 21:02:20 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 28 Jun 2016 15:02:20 -0600 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <5772D9FE.5030804@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> Message-ID: <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> On 6/28/16 2:11 PM, serguei.spitsyn at oracle.com wrote: > On 6/28/16 11:19, Daniel D. Daugherty wrote: > >> >> I'll have to check the upper layers of this API, but if an >> agent can pass a bad 'class_loader' parameter and get this >> assert() to fire, then that's not good. Hopefully a bad >> 'class_loader' parameter is caught at a higher layer. > > Not sure, what do you mean. > Do you mean the generated JVMTI upper layer or the > JvmtiEnv::GetNamedModule? > Probably, the generated code. I did mean the generated layer. > >> >> Update: Yes, passing a non-NULL jobject as the class_loader >> parameter >> when the jobject does not refer to a "class loader" is >> caught >> at the upper layer. > > The upper layer does not check that it is a class loader, just for > non-NULL. > I think, it is good to have an assert here to double-checks the > pre-conditions as other caller can be added later. > But I'm Ok to get rid of it if you suggest. Please keep the asserts. Basically I was mumbling to myself to make sure that the asserts could not be reached by user code and the "Update:" was to indicate that I did do. > >> >> src/share/vm/prims/jvmti.xml >> L6550: >> L6551: >> L6552: >> L6553: On return, points to a >> java.lang.reflect.Module object. >> L6554: >> L6555: >> >> The above wording doesn't allow for module_ptr to be NULL which >> is a mismatch with the description. > > I disagree (or maybe I got it incorrectly). > Pointing to NULL and be NULL is different. > It is not allowed for the module_ptr to be NULL but Ok to pint to NULL > on return. I think the description needs to be: On return, points to a java.lang.reflect.Module object or points to a NULL. Dan From serguei.spitsyn at oracle.com Tue Jun 28 21:09:51 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 14:09:51 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> Message-ID: <5772E79F.3040504@oracle.com> On 6/28/16 14:02, Daniel D. Daugherty wrote: > On 6/28/16 2:11 PM, serguei.spitsyn at oracle.com wrote: >> On 6/28/16 11:19, Daniel D. Daugherty wrote: >> >>> >>> I'll have to check the upper layers of this API, but if an >>> agent can pass a bad 'class_loader' parameter and get this >>> assert() to fire, then that's not good. Hopefully a bad >>> 'class_loader' parameter is caught at a higher layer. >> >> Not sure, what do you mean. >> Do you mean the generated JVMTI upper layer or the >> JvmtiEnv::GetNamedModule? >> Probably, the generated code. > > I did mean the generated layer. Ok, thanks. > > >> >>> >>> Update: Yes, passing a non-NULL jobject as the class_loader >>> parameter >>> when the jobject does not refer to a "class loader" is >>> caught >>> at the upper layer. >> >> The upper layer does not check that it is a class loader, just for >> non-NULL. >> I think, it is good to have an assert here to double-checks the >> pre-conditions as other caller can be added later. >> But I'm Ok to get rid of it if you suggest. > > Please keep the asserts. Basically I was mumbling to myself to > make sure that the asserts could not be reached by user code > and the "Update:" was to indicate that I did do. Ok, thanks. > > >> >>> >>> src/share/vm/prims/jvmti.xml >>> L6550: >>> L6551: >>> L6552: >>> L6553: On return, points to a >>> java.lang.reflect.Module object. >>> L6554: >>> L6555: >>> >>> The above wording doesn't allow for module_ptr to be NULL which >>> is a mismatch with the description. >> >> I disagree (or maybe I got it incorrectly). >> Pointing to NULL and be NULL is different. >> It is not allowed for the module_ptr to be NULL but Ok to pint to >> NULL on return. > > I think the description needs to be: > > On return, points to a java.lang.reflect.Module object > or points to a NULL. Agreed, fixed. Thanks, Serguei > > > Dan From kim.barrett at oracle.com Tue Jun 28 22:43:22 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 28 Jun 2016 18:43:22 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> Message-ID: <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> Updated webrevs: Full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.01/ http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.01/ Incremental: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.01.inc/ http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.01.inc/ Still investigating the initialization order for core exceptions. From kim.barrett at oracle.com Tue Jun 28 22:46:48 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 28 Jun 2016 18:46:48 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <10fd2944-4f2e-d2d1-d8d1-42752b687625@oracle.com> References: <10fd2944-4f2e-d2d1-d8d1-42752b687625@oracle.com> Message-ID: <5CA1A01A-C087-483B-B8DD-9306453B76B1@oracle.com> > On Jun 27, 2016, at 9:34 PM, Daniel D. Daugherty wrote: > Other than the possible missing notify_all() in vmGCOperations.cpp, > this all looks great. Thanks Dan. From david.holmes at oracle.com Tue Jun 28 23:23:14 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Jun 2016 09:23:14 +1000 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> Message-ID: <3f6719ad-95a3-12eb-572a-8c171306fc8d@oracle.com> On 29/06/2016 8:43 AM, Kim Barrett wrote: > Updated webrevs: > > Full: > http://cr.openjdk.java.net/~kbarrett/8156500/jdk.01/ > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.01/ > > Incremental: > http://cr.openjdk.java.net/~kbarrett/8156500/jdk.01.inc/ Did Reference not work? Just curious. I used to be a qualified Java programmer back in the Java 5 era, but wildcards were always a bit iffy :) > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.01.inc/ > > Still investigating the initialization order for core exceptions. I suspect it is as Coleen indicated that the module changes introduced the new failure path that you hit. I did a quick check of the initialization order in an old b50: 33 Initializing 'java/lang/Throwable' (0x0000001780002990) ... 46 Initializing 'java/lang/Exception'(no method) (0x0000001780003158) 47 Initializing 'java/lang/InterruptedException'(no method) (0x00000017800178a8) Compare that with a current build: 60 Initializing 'java/lang/ref/Reference$ReferenceHandler' (0x000000080001e3f0) 61 Initializing 'java/lang/Throwable' (0x00000008000029f8) 62 Initializing 'java/lang/Exception'(no method) (0x00000008000031a8) 63 Initializing 'java/lang/InterruptedException'(no method) (0x000000080001e6e0) 64 Initializing 'java/lang/ref/PhantomReference'(no method) (0x0000000800006440) Initialization of Throwable is much, much later (large parts of java.lang and java.util are now initialized first!) and is obviously a direct consequence of preinitializing InterruptedException. So I would say that the module change did break this and that initialization of Throwable (only) should be restored to a much higher place in the initialization sequence. Thanks, David From david.holmes at oracle.com Wed Jun 29 01:44:49 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Jun 2016 11:44:49 +1000 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <5772E79F.3040504@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> <5772E79F.3040504@oracle.com> Message-ID: On 29/06/2016 7:09 AM, serguei.spitsyn at oracle.com wrote: > On 6/28/16 14:02, Daniel D. Daugherty wrote: >> On 6/28/16 2:11 PM, serguei.spitsyn at oracle.com wrote: >>> On 6/28/16 11:19, Daniel D. Daugherty wrote: >>> >>>> >>>> I'll have to check the upper layers of this API, but if an >>>> agent can pass a bad 'class_loader' parameter and get this >>>> assert() to fire, then that's not good. Hopefully a bad >>>> 'class_loader' parameter is caught at a higher layer. >>> >>> Not sure, what do you mean. >>> Do you mean the generated JVMTI upper layer or the >>> JvmtiEnv::GetNamedModule? >>> Probably, the generated code. >> >> I did mean the generated layer. > > Ok, thanks. > >> >> >>> >>>> >>>> Update: Yes, passing a non-NULL jobject as the class_loader >>>> parameter >>>> when the jobject does not refer to a "class loader" is >>>> caught >>>> at the upper layer. >>> >>> The upper layer does not check that it is a class loader, just for >>> non-NULL. >>> I think, it is good to have an assert here to double-checks the >>> pre-conditions as other caller can be added later. >>> But I'm Ok to get rid of it if you suggest. >> >> Please keep the asserts. Basically I was mumbling to myself to >> make sure that the asserts could not be reached by user code >> and the "Update:" was to indicate that I did do. > > Ok, thanks. > > >> >> >>> >>>> >>>> src/share/vm/prims/jvmti.xml >>>> L6550: >>>> L6551: >>>> L6552: >>>> L6553: On return, points to a >>>> java.lang.reflect.Module object. >>>> L6554: >>>> L6555: >>>> >>>> The above wording doesn't allow for module_ptr to be NULL which >>>> is a mismatch with the description. >>> >>> I disagree (or maybe I got it incorrectly). >>> Pointing to NULL and be NULL is different. >>> It is not allowed for the module_ptr to be NULL but Ok to pint to >>> NULL on return. >> >> I think the description needs to be: >> >> On return, points to a java.lang.reflect.Module object >> or points to a NULL. > > Agreed, fixed. Disagree. You would say that a pointer is NULL, not that it points to a NULL. David > > Thanks, > Serguei > > >> >> >> Dan > From serguei.spitsyn at oracle.com Wed Jun 29 02:09:35 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 19:09:35 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> <5772E79F.3040504@oracle.com> Message-ID: <57732DDF.4070904@oracle.com> On 6/28/16 18:44, David Holmes wrote: > On 29/06/2016 7:09 AM, serguei.spitsyn at oracle.com wrote: >> On 6/28/16 14:02, Daniel D. Daugherty wrote: >>> On 6/28/16 2:11 PM, serguei.spitsyn at oracle.com wrote: >>>> On 6/28/16 11:19, Daniel D. Daugherty wrote: >>>> >>>>> >>>>> I'll have to check the upper layers of this API, but if an >>>>> agent can pass a bad 'class_loader' parameter and get this >>>>> assert() to fire, then that's not good. Hopefully a bad >>>>> 'class_loader' parameter is caught at a higher layer. >>>> >>>> Not sure, what do you mean. >>>> Do you mean the generated JVMTI upper layer or the >>>> JvmtiEnv::GetNamedModule? >>>> Probably, the generated code. >>> >>> I did mean the generated layer. >> >> Ok, thanks. >> >>> >>> >>>> >>>>> >>>>> Update: Yes, passing a non-NULL jobject as the class_loader >>>>> parameter >>>>> when the jobject does not refer to a "class loader" is >>>>> caught >>>>> at the upper layer. >>>> >>>> The upper layer does not check that it is a class loader, just for >>>> non-NULL. >>>> I think, it is good to have an assert here to double-checks the >>>> pre-conditions as other caller can be added later. >>>> But I'm Ok to get rid of it if you suggest. >>> >>> Please keep the asserts. Basically I was mumbling to myself to >>> make sure that the asserts could not be reached by user code >>> and the "Update:" was to indicate that I did do. >> >> Ok, thanks. >> >> >>> >>> >>>> >>>>> >>>>> src/share/vm/prims/jvmti.xml >>>>> L6550: >>>>> L6551: >>>>> L6552: >>>>> L6553: On return, points to a >>>>> java.lang.reflect.Module object. >>>>> L6554: >>>>> L6555: >>>>> >>>>> The above wording doesn't allow for module_ptr to be NULL >>>>> which >>>>> is a mismatch with the description. >>>> >>>> I disagree (or maybe I got it incorrectly). >>>> Pointing to NULL and be NULL is different. >>>> It is not allowed for the module_ptr to be NULL but Ok to pint to >>>> NULL on return. >>> >>> I think the description needs to be: >>> >>> On return, points to a java.lang.reflect.Module object >>> or points to a NULL. >> >> Agreed, fixed. > > Disagree. You would say that a pointer is NULL, not that it points to > a NULL. Why are you disagree? The module_ptr is an out argument, it is not allowed to be NULL. But the returning value by this pointer can be NULL. Thanks, Serguei > > David > > >> >> Thanks, >> Serguei >> >> >>> >>> >>> Dan >> From david.holmes at oracle.com Wed Jun 29 02:17:34 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Jun 2016 12:17:34 +1000 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <5772E130.40109@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772E130.40109@oracle.com> Message-ID: <8bfa102b-48fc-42e3-04f8-efcd7ded3589@oracle.com> Hi Serguei, Looks good to me. A couple of comments ... On 29/06/2016 6:42 AM, serguei.spitsyn at oracle.com wrote: > Dan, > > The updated webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.6/ src/share/vm/classfile/modules.cpp Nit: + const PackageEntry* const pkg_entry = + get_package_entry_by_name(package_sym, h_loader, THREAD); indent on a line continuation should be 4 not 2. (no need to see updated webrev). --- src/share/vm/prims/jvmti.xml + or points to NULL. I would have suggested "or is NULL." as per other email, but I see that this terminology is pre-existing, so ignore that other email. > > >> Has someone checked the generated glue code for completeness and > proper checks? > > This is the generated upper layer function in the jvmtiEnter.cpp: > > 3185 static jvmtiError JNICALL > 3186 jvmti_GetNamedModule(jvmtiEnv* env, > 3187 jobject class_loader, > 3188 const char* package_name, > 3189 jobject* module_ptr) { > 3190 > 3191 #if !INCLUDE_JVMTI > 3192 return JVMTI_ERROR_NOT_AVAILABLE; > 3193 #else > 3194 if(!JvmtiEnv::is_vm_live()) { > 3195 return JVMTI_ERROR_WRONG_PHASE; > 3196 } > 3197 Thread* this_thread = Thread::current_or_null(); > 3198 if (this_thread == NULL || !this_thread->is_Java_thread()) { > 3199 return JVMTI_ERROR_UNATTACHED_THREAD; > 3200 } > 3201 JavaThread* current_thread = (JavaThread*)this_thread; > 3202 ThreadInVMfromNative __tiv(current_thread); > 3203 VM_ENTRY_BASE(jvmtiError, jvmti_GetNamedModule , current_thread) > 3204 debug_only(VMNativeEntryWrapper __vew;) > 3205 CautiouslyPreserveExceptionMark __em(this_thread); > 3206 JvmtiEnv* jvmti_env = JvmtiEnv::JvmtiEnv_from_jvmti_env(env); > 3207 if (!jvmti_env->is_valid()) { > 3208 return JVMTI_ERROR_INVALID_ENVIRONMENT; > 3209 } > 3210 jvmtiError err; > 3211 if (package_name == NULL) { > 3212 return JVMTI_ERROR_NULL_POINTER; > 3213 } > 3214 if (module_ptr == NULL) { > 3215 return JVMTI_ERROR_NULL_POINTER; > 3216 } > 3217 err = jvmti_env->GetNamedModule(class_loader, package_name, > module_ptr); > 3218 return err; > 3219 #endif // INCLUDE_JVMTI > 3220 } > > > I do not see any problems in the above. Looks good to me too. Thanks, David > > Thanks, > Serguei > > > > > On 6/28/16 11:19, Daniel D. Daugherty wrote: >> On 6/28/16 10:37 AM, serguei.spitsyn at oracle.com wrote: >>> Hi Harold, >>> >>> Thank you again for the comments! >>> This is the updated webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.5/ >>> >> >> make/test/JtregNative.gmk >> No comments. >> >> src/share/vm/classfile/modules.hpp >> No comments. >> >> src/share/vm/classfile/modules.cpp >> L826: assert(h_loader.is_null() || >> java_lang_ClassLoader::is_subclass(h_loader->klass()), >> L827: "Class loader is not a subclass of >> java.lang.ClassLoader"); >> nit: indent on L827 is off by 1 space >> >> I'll have to check the upper layers of this API, but if an >> agent can pass a bad 'class_loader' parameter and get this >> assert() to fire, then that's not good. Hopefully a bad >> 'class_loader' parameter is caught at a higher layer. >> >> Update: Yes, passing a non-NULL jobject as the class_loader >> parameter >> when the jobject does not refer to a "class loader" is caught >> at the upper layer. >> >> L828: assert(package_str != NULL, "the package_str should not be >> NULL"); >> Same concern about the package_str parameter. >> >> Update: Yes, the generated JVM/TI glue code should catch a >> NULL package_name/package_str at the upper layers. >> >> >> src/share/vm/prims/jvmti.xml >> L6550: >> L6551: >> L6552: >> L6553: On return, points to a >> java.lang.reflect.Module object. >> L6554: >> L6555: >> >> The above wording doesn't allow for module_ptr to be NULL which >> is a mismatch with the description. >> >> L2518: function can be used to map class loader and package >> name to a module. >> Typo: 'map class loader and package name' >> -> 'map a class loader and a package name' >> >> >> src/share/vm/prims/jvmtiEnv.cpp >> L204: // class_loader - NULL is a valid value, must be pre-checked >> L205: // package_name - pre-checked for NULL >> L206: // module_ptr - pre-checked for NULL >> The jvmti.xml file doesn't mark package_name or module_ptr >> with so both of those should be checked by the >> generated glue code. >> >> class_loader is marked with so a NULL class_loader >> will get to here: >> >> L217: jobject module = Modules::get_named_module(h_loader, >> package_name, THREAD); >> >> and it looks like all the code paths in get_named_module() >> properly account for both NULL and non-NULL h_loader. Cool. >> >> test/serviceability/jvmti/GetNamedModule/MyPackage/GetNamedModuleTest.java >> >> L42: System.err.println("java.library.path:" >> nit: a space between the ':' and '"' would make the >> output more readable >> >> test/serviceability/jvmti/GetNamedModule/libGetNamedModuleTest.c >> L81: res = JNI_ENV_PTR(jvm)->GetEnv(JNI_ENV_ARG(jvm, (void **) >> &jvmti), >> L82: JVMTI_VERSION_1_1); >> I was expecting this test to ask for the JVM/TI version that >> includes support for GetAllModules() and GetNamesModule(). >> Looks like that is version 9.0.0 or newer aka JVMTI_VERSION_9. >> >> L360: if (module != NULL || mod_name !=NULL) { >> bit: space after '!=' and before NULL >> >> Has someone checked the generated glue code for completeness and >> proper checks? >> >> Dan >> >> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 6/28/16 07:32, harold seigel wrote: >>>> >>>> Hi Serguei, >>>> >>>> Looks good. >>>> >>>> 1. In modules.cpp, the first assert in get_named_module() has the >>>> wrong function name: >>>> >>>> 825 assert(ModuleEntryTable::javabase_defined(), >>>> 826 "Attempt to call *get_module_by_package_name* before java.base >>>> is defined"); >>>> >>>> 2. Also, is a check needed to ensure that package_str is not null? >>>> >>>> 3. Is the ResourceMark(THREAD) needed at line 824? >>>> >>>> Thanks, Harold >>>> >>>> On 6/28/2016 4:54 AM, serguei.spitsyn at oracle.com wrote: >>>>> Hi David, >>>>> >>>>> Thank you for the comments! >>>>> I agree with you. >>>>> >>>>> Updated Hotspot webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.4/ >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>> On 6/27/16 22:06, David Holmes wrote: >>>>>> Hi Serguei, >>>>>> >>>>>> Overall this looks a lot clearer/simpler. >>>>>> >>>>>> On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>>>>>>> Please, review the Jigsaw fix for the enhancement: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>>>>>> >>>>>>>> >>>>>>>> The Hotspot webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>>>>>>> >>>>>> >>>>>> Are there intended to be other callers of >>>>>> Module::get_named_module? If not it seems odd to go to all the >>>>>> trouble of throwing exceptions, just to have the caller clear them >>>>>> and return an error code. Or you could move all that argument >>>>>> checking code into the JVMTI function directly - if called >>>>>> internally you would just assert that arguments are as expected. >>>>>> >>>>>> >>>>>> src/share/vm/prims/jvmti.xml >>>>>> >>>>>> + otherwise the NULL is returned. >>>>>> >>>>>> Delete "the". >>>>>> >>>>>> Otherwise all looks good to me. >>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The Jdk webrev is the same: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>>>>>> >>>>>>> >>>>>>> Sorry, the Jdk webrev changed as well: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >>>>>>> >>>>>> >>>>>> Looks fine. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Summary: >>>>>>>> >>>>>>>> This is the review round #3. >>>>>>>> Alan suggested to replace the function GetModuleByPackageName >>>>>>>> with >>>>>>>> the GetNamedModule. >>>>>>>> New function will return NULL if the package is not in a module >>>>>>>> defined to the class loader. >>>>>>>> It simplifies the API and makes it easier to specify. >>>>>>>> JVM TI agents that instrument code in named modules need the >>>>>>>> Module >>>>>>>> at class load time. >>>>>>>> >>>>>>>> One question that came from the function semantics change. >>>>>>>> I had to implement the Modules::get_named_module() from scratch >>>>>>>> independently of the existing >>>>>>>> Modules::get_module_by_package_name() and Modules::get_module(). >>>>>>>> The issue is that the Modules::get_module() can return the >>>>>>>> unnamed >>>>>>>> module whereas the >>>>>>>> JVMTI helper Modules::get_named_module() should return NULL >>>>>>>> instead >>>>>>>> of the unnamed module. >>>>>>>> Please, let me know if it is Ok or if you have better ideas >>>>>>>> how to >>>>>>>> share the code. >>>>>>>> >>>>>>>> This is the Summary from review round #1: >>>>>>>> >>>>>>>> One way to do this is by introducing a new ClassFileLoadHook that >>>>>>>> takes an additional parameter but this approach is disruptive. >>>>>>>> The alternative option is a JVM TI function that maps a >>>>>>>> classloader >>>>>>>> + package name to a module. >>>>>>>> We were initially not confident with this approach so we >>>>>>>> introduced >>>>>>>> it as JVM function JVM_GetModuleByPackageName. >>>>>>>> Based on experience to date then this approach seems okay and so >>>>>>>> this function needs to be promoted to a JVMTI function. >>>>>>>> >>>>>>>> It includes new jtreg test with native JVMTI agent. >>>>>>>> >>>>>>>> >>>>>>>> Testing: >>>>>>>> Run newly developed jtreg test. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>> >>>>> >>>> >>> >> > From mandy.chung at oracle.com Wed Jun 29 02:28:46 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 28 Jun 2016 19:28:46 -0700 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <3f6719ad-95a3-12eb-572a-8c171306fc8d@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <3f6719ad-95a3-12eb-572a-8c171306fc8d@oracle.com> Message-ID: <94572805-06D5-456B-B73E-70BBD642CA22@oracle.com> > On Jun 28, 2016, at 4:23 PM, David Holmes wrote: > > On 29/06/2016 8:43 AM, Kim Barrett wrote: >> Updated webrevs: >> >> Full: >> http://cr.openjdk.java.net/~kbarrett/8156500/jdk.01/ >> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.01/ >> >> Incremental: >> http://cr.openjdk.java.net/~kbarrett/8156500/jdk.01.inc/ > > Did Reference not work? Just curious. I used to be a qualified Java programmer back in the Java 5 era, but wildcards were always a bit iffy :) A related post in compiler-dev w.r.t. Reference: http://mail.openjdk.java.net/pipermail/compiler-dev/2014-January/008457.html Looks like no reply on that thread though. > >> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.01.inc/ >> >> Still investigating the initialization order for core exceptions. > > I suspect it is as Coleen indicated that the module changes introduced the new failure path that you hit. I did a quick check of the initialization order in an old b50: > > 33 Initializing 'java/lang/Throwable' (0x0000001780002990) > ... > 46 Initializing 'java/lang/Exception'(no method) (0x0000001780003158) > 47 Initializing 'java/lang/InterruptedException'(no method) (0x00000017800178a8) > > Compare that with a current build: > > 60 Initializing 'java/lang/ref/Reference$ReferenceHandler' (0x000000080001e3f0) > 61 Initializing 'java/lang/Throwable' (0x00000008000029f8) > 62 Initializing 'java/lang/Exception'(no method) (0x00000008000031a8) > 63 Initializing 'java/lang/InterruptedException'(no method) (0x000000080001e6e0) > 64 Initializing 'java/lang/ref/PhantomReference'(no method) (0x0000000800006440) > How do you get this list? > Initialization of Throwable is much, much later (large parts of java.lang and java.util are now initialized first!) and is obviously a direct consequence of preinitializing InterruptedException. > Do you mind trying b110 before JEP 261 was integrated in jdk-9+111 and see any difference? initPhase1 is expected to be called very early in the VM initialization after the primordial classes are loaded. IIRC, the exception classes are preallocated to improve diagnosability in the case when we run out of memory VM can still throw a preallocated instance with an preallocated stack trace buffer. I don?t think these exception classes are expected to be loaded initPhase1. More to dig here. Mandy > So I would say that the module change did break this and that initialization of Throwable (only) should be restored to a much higher place in the initialization sequence. > > Thanks, > David > From serguei.spitsyn at oracle.com Wed Jun 29 02:29:31 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 19:29:31 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <8bfa102b-48fc-42e3-04f8-efcd7ded3589@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772E130.40109@oracle.com> <8bfa102b-48fc-42e3-04f8-efcd7ded3589@oracle.com> Message-ID: <5773328B.1090805@oracle.com> Hi David, On 6/28/16 19:17, David Holmes wrote: > Hi Serguei, > > Looks good to me. A couple of comments ... Thank you for reviewing it! > > On 29/06/2016 6:42 AM, serguei.spitsyn at oracle.com wrote: >> Dan, >> >> The updated webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.6/ >> > > src/share/vm/classfile/modules.cpp > > Nit: > > + const PackageEntry* const pkg_entry = > + get_package_entry_by_name(package_sym, h_loader, THREAD); > > indent on a line continuation should be 4 not 2. (no need to see > updated webrev). This fragment was taken from the function get_module() with the pre-existing indent. There are a couple of other fragments with the indent like this. There is a rule to follow the the file style. > > --- > > src/share/vm/prims/jvmti.xml > > + or points to NULL. > > I would have suggested "or is NULL." as per other email, > but I see that this terminology is pre-existing, so ignore that other > email. Ok, thanks! > >> >> >>> Has someone checked the generated glue code for completeness and >> proper checks? >> >> This is the generated upper layer function in the jvmtiEnter.cpp: >> >> 3185 static jvmtiError JNICALL >> 3186 jvmti_GetNamedModule(jvmtiEnv* env, >> 3187 jobject class_loader, >> 3188 const char* package_name, >> 3189 jobject* module_ptr) { >> 3190 >> 3191 #if !INCLUDE_JVMTI >> 3192 return JVMTI_ERROR_NOT_AVAILABLE; >> 3193 #else >> 3194 if(!JvmtiEnv::is_vm_live()) { >> 3195 return JVMTI_ERROR_WRONG_PHASE; >> 3196 } >> 3197 Thread* this_thread = Thread::current_or_null(); >> 3198 if (this_thread == NULL || !this_thread->is_Java_thread()) { >> 3199 return JVMTI_ERROR_UNATTACHED_THREAD; >> 3200 } >> 3201 JavaThread* current_thread = (JavaThread*)this_thread; >> 3202 ThreadInVMfromNative __tiv(current_thread); >> 3203 VM_ENTRY_BASE(jvmtiError, jvmti_GetNamedModule , current_thread) >> 3204 debug_only(VMNativeEntryWrapper __vew;) >> 3205 CautiouslyPreserveExceptionMark __em(this_thread); >> 3206 JvmtiEnv* jvmti_env = JvmtiEnv::JvmtiEnv_from_jvmti_env(env); >> 3207 if (!jvmti_env->is_valid()) { >> 3208 return JVMTI_ERROR_INVALID_ENVIRONMENT; >> 3209 } >> 3210 jvmtiError err; >> 3211 if (package_name == NULL) { >> 3212 return JVMTI_ERROR_NULL_POINTER; >> 3213 } >> 3214 if (module_ptr == NULL) { >> 3215 return JVMTI_ERROR_NULL_POINTER; >> 3216 } >> 3217 err = jvmti_env->GetNamedModule(class_loader, package_name, >> module_ptr); >> 3218 return err; >> 3219 #endif // INCLUDE_JVMTI >> 3220 } >> >> >> I do not see any problems in the above. > > Looks good to me too. Good. Thanks! Serguei > > Thanks, > David > >> >> Thanks, >> Serguei >> >> >> >> >> On 6/28/16 11:19, Daniel D. Daugherty wrote: >>> On 6/28/16 10:37 AM, serguei.spitsyn at oracle.com wrote: >>>> Hi Harold, >>>> >>>> Thank you again for the comments! >>>> This is the updated webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.5/ >>>> >>>> >>> >>> make/test/JtregNative.gmk >>> No comments. >>> >>> src/share/vm/classfile/modules.hpp >>> No comments. >>> >>> src/share/vm/classfile/modules.cpp >>> L826: assert(h_loader.is_null() || >>> java_lang_ClassLoader::is_subclass(h_loader->klass()), >>> L827: "Class loader is not a subclass of >>> java.lang.ClassLoader"); >>> nit: indent on L827 is off by 1 space >>> >>> I'll have to check the upper layers of this API, but if an >>> agent can pass a bad 'class_loader' parameter and get this >>> assert() to fire, then that's not good. Hopefully a bad >>> 'class_loader' parameter is caught at a higher layer. >>> >>> Update: Yes, passing a non-NULL jobject as the class_loader >>> parameter >>> when the jobject does not refer to a "class loader" is >>> caught >>> at the upper layer. >>> >>> L828: assert(package_str != NULL, "the package_str should not be >>> NULL"); >>> Same concern about the package_str parameter. >>> >>> Update: Yes, the generated JVM/TI glue code should catch a >>> NULL package_name/package_str at the upper layers. >>> >>> >>> src/share/vm/prims/jvmti.xml >>> L6550: >>> L6551: >>> L6552: >>> L6553: On return, points to a >>> java.lang.reflect.Module object. >>> L6554: >>> L6555: >>> >>> The above wording doesn't allow for module_ptr to be NULL which >>> is a mismatch with the description. >>> >>> L2518: function can be used to map class loader and package >>> name to a module. >>> Typo: 'map class loader and package name' >>> -> 'map a class loader and a package name' >>> >>> >>> src/share/vm/prims/jvmtiEnv.cpp >>> L204: // class_loader - NULL is a valid value, must be pre-checked >>> L205: // package_name - pre-checked for NULL >>> L206: // module_ptr - pre-checked for NULL >>> The jvmti.xml file doesn't mark package_name or module_ptr >>> with so both of those should be checked by the >>> generated glue code. >>> >>> class_loader is marked with so a NULL class_loader >>> will get to here: >>> >>> L217: jobject module = Modules::get_named_module(h_loader, >>> package_name, THREAD); >>> >>> and it looks like all the code paths in get_named_module() >>> properly account for both NULL and non-NULL h_loader. Cool. >>> >>> test/serviceability/jvmti/GetNamedModule/MyPackage/GetNamedModuleTest.java >>> >>> >>> L42: System.err.println("java.library.path:" >>> nit: a space between the ':' and '"' would make the >>> output more readable >>> >>> test/serviceability/jvmti/GetNamedModule/libGetNamedModuleTest.c >>> L81: res = JNI_ENV_PTR(jvm)->GetEnv(JNI_ENV_ARG(jvm, (void **) >>> &jvmti), >>> L82: JVMTI_VERSION_1_1); >>> I was expecting this test to ask for the JVM/TI version that >>> includes support for GetAllModules() and GetNamesModule(). >>> Looks like that is version 9.0.0 or newer aka JVMTI_VERSION_9. >>> >>> L360: if (module != NULL || mod_name !=NULL) { >>> bit: space after '!=' and before NULL >>> >>> Has someone checked the generated glue code for completeness and >>> proper checks? >>> >>> Dan >>> >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 6/28/16 07:32, harold seigel wrote: >>>>> >>>>> Hi Serguei, >>>>> >>>>> Looks good. >>>>> >>>>> 1. In modules.cpp, the first assert in get_named_module() has the >>>>> wrong function name: >>>>> >>>>> 825 assert(ModuleEntryTable::javabase_defined(), >>>>> 826 "Attempt to call *get_module_by_package_name* before java.base >>>>> is defined"); >>>>> >>>>> 2. Also, is a check needed to ensure that package_str is not null? >>>>> >>>>> 3. Is the ResourceMark(THREAD) needed at line 824? >>>>> >>>>> Thanks, Harold >>>>> >>>>> On 6/28/2016 4:54 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Hi David, >>>>>> >>>>>> Thank you for the comments! >>>>>> I agree with you. >>>>>> >>>>>> Updated Hotspot webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.4/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>> On 6/27/16 22:06, David Holmes wrote: >>>>>>> Hi Serguei, >>>>>>> >>>>>>> Overall this looks a lot clearer/simpler. >>>>>>> >>>>>>> On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Please, review the Jigsaw fix for the enhancement: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>>>>>>> >>>>>>>>> >>>>>>>>> The Hotspot webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> Are there intended to be other callers of >>>>>>> Module::get_named_module? If not it seems odd to go to all the >>>>>>> trouble of throwing exceptions, just to have the caller clear them >>>>>>> and return an error code. Or you could move all that argument >>>>>>> checking code into the JVMTI function directly - if called >>>>>>> internally you would just assert that arguments are as expected. >>>>>>> >>>>>>> >>>>>>> src/share/vm/prims/jvmti.xml >>>>>>> >>>>>>> + otherwise the NULL is returned. >>>>>>> >>>>>>> Delete "the". >>>>>>> >>>>>>> Otherwise all looks good to me. >>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The Jdk webrev is the same: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Sorry, the Jdk webrev changed as well: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Looks fine. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Summary: >>>>>>>>> >>>>>>>>> This is the review round #3. >>>>>>>>> Alan suggested to replace the function GetModuleByPackageName >>>>>>>>> with >>>>>>>>> the GetNamedModule. >>>>>>>>> New function will return NULL if the package is not in a module >>>>>>>>> defined to the class loader. >>>>>>>>> It simplifies the API and makes it easier to specify. >>>>>>>>> JVM TI agents that instrument code in named modules need the >>>>>>>>> Module >>>>>>>>> at class load time. >>>>>>>>> >>>>>>>>> One question that came from the function semantics change. >>>>>>>>> I had to implement the Modules::get_named_module() from scratch >>>>>>>>> independently of the existing >>>>>>>>> Modules::get_module_by_package_name() and >>>>>>>>> Modules::get_module(). >>>>>>>>> The issue is that the Modules::get_module() can return the >>>>>>>>> unnamed >>>>>>>>> module whereas the >>>>>>>>> JVMTI helper Modules::get_named_module() should return NULL >>>>>>>>> instead >>>>>>>>> of the unnamed module. >>>>>>>>> Please, let me know if it is Ok or if you have better ideas >>>>>>>>> how to >>>>>>>>> share the code. >>>>>>>>> >>>>>>>>> This is the Summary from review round #1: >>>>>>>>> >>>>>>>>> One way to do this is by introducing a new ClassFileLoadHook >>>>>>>>> that >>>>>>>>> takes an additional parameter but this approach is disruptive. >>>>>>>>> The alternative option is a JVM TI function that maps a >>>>>>>>> classloader >>>>>>>>> + package name to a module. >>>>>>>>> We were initially not confident with this approach so we >>>>>>>>> introduced >>>>>>>>> it as JVM function JVM_GetModuleByPackageName. >>>>>>>>> Based on experience to date then this approach seems okay >>>>>>>>> and so >>>>>>>>> this function needs to be promoted to a JVMTI function. >>>>>>>>> >>>>>>>>> It includes new jtreg test with native JVMTI agent. >>>>>>>>> >>>>>>>>> >>>>>>>>> Testing: >>>>>>>>> Run newly developed jtreg test. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>> >>>>>> >>>>> >>>> >>> >> From david.holmes at oracle.com Wed Jun 29 02:30:35 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Jun 2016 12:30:35 +1000 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <57732DDF.4070904@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> <5772E79F.3040504@oracle.com> <57732DDF.4070904@oracle.com> Message-ID: On 29/06/2016 12:09 PM, serguei.spitsyn at oracle.com wrote: > On 6/28/16 18:44, David Holmes wrote: >> On 29/06/2016 7:09 AM, serguei.spitsyn at oracle.com wrote: >>> On 6/28/16 14:02, Daniel D. Daugherty wrote: >>>> On 6/28/16 2:11 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 6/28/16 11:19, Daniel D. Daugherty wrote: >>>>> >>>>>> >>>>>> I'll have to check the upper layers of this API, but if an >>>>>> agent can pass a bad 'class_loader' parameter and get this >>>>>> assert() to fire, then that's not good. Hopefully a bad >>>>>> 'class_loader' parameter is caught at a higher layer. >>>>> >>>>> Not sure, what do you mean. >>>>> Do you mean the generated JVMTI upper layer or the >>>>> JvmtiEnv::GetNamedModule? >>>>> Probably, the generated code. >>>> >>>> I did mean the generated layer. >>> >>> Ok, thanks. >>> >>>> >>>> >>>>> >>>>>> >>>>>> Update: Yes, passing a non-NULL jobject as the class_loader >>>>>> parameter >>>>>> when the jobject does not refer to a "class loader" is >>>>>> caught >>>>>> at the upper layer. >>>>> >>>>> The upper layer does not check that it is a class loader, just for >>>>> non-NULL. >>>>> I think, it is good to have an assert here to double-checks the >>>>> pre-conditions as other caller can be added later. >>>>> But I'm Ok to get rid of it if you suggest. >>>> >>>> Please keep the asserts. Basically I was mumbling to myself to >>>> make sure that the asserts could not be reached by user code >>>> and the "Update:" was to indicate that I did do. >>> >>> Ok, thanks. >>> >>> >>>> >>>> >>>>> >>>>>> >>>>>> src/share/vm/prims/jvmti.xml >>>>>> L6550: >>>>>> L6551: >>>>>> L6552: >>>>>> L6553: On return, points to a >>>>>> java.lang.reflect.Module object. >>>>>> L6554: >>>>>> L6555: >>>>>> >>>>>> The above wording doesn't allow for module_ptr to be NULL >>>>>> which >>>>>> is a mismatch with the description. >>>>> >>>>> I disagree (or maybe I got it incorrectly). >>>>> Pointing to NULL and be NULL is different. >>>>> It is not allowed for the module_ptr to be NULL but Ok to pint to >>>>> NULL on return. >>>> >>>> I think the description needs to be: >>>> >>>> On return, points to a java.lang.reflect.Module object >>>> or points to a NULL. >>> >>> Agreed, fixed. >> >> Disagree. You would say that a pointer is NULL, not that it points to >> a NULL. > > Why are you disagree? > The module_ptr is an out argument, it is not allowed to be NULL. > But the returning value by this pointer can be NULL. As per later email I see this terminology already exists so is fine, but I find it confusing to say "points to a NULL" - a NULL is not an entity. If "foo points to a NULL" that implies to me "foo == &NULL;" which is nonsense - foo == NULL, and if foo==NULL then foo points to nothing. But the "pointer to a pointer" aspect here does confuse things. Thanks, David > > Thanks, > Serguei > > >> >> David >> >> >>> >>> Thanks, >>> Serguei >>> >>> >>>> >>>> >>>> Dan >>> > From serguei.spitsyn at oracle.com Wed Jun 29 02:35:10 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 19:35:10 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> <5772E79F.3040504@oracle.com> <57732DDF.4070904@oracle.com> Message-ID: <577333DE.8090001@oracle.com> On 6/28/16 19:30, David Holmes wrote: > On 29/06/2016 12:09 PM, serguei.spitsyn at oracle.com wrote: >> On 6/28/16 18:44, David Holmes wrote: >>> On 29/06/2016 7:09 AM, serguei.spitsyn at oracle.com wrote: >>>> On 6/28/16 14:02, Daniel D. Daugherty wrote: >>>>> On 6/28/16 2:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 6/28/16 11:19, Daniel D. Daugherty wrote: >>>>>> >>>>>>> >>>>>>> I'll have to check the upper layers of this API, but if an >>>>>>> agent can pass a bad 'class_loader' parameter and get this >>>>>>> assert() to fire, then that's not good. Hopefully a bad >>>>>>> 'class_loader' parameter is caught at a higher layer. >>>>>> >>>>>> Not sure, what do you mean. >>>>>> Do you mean the generated JVMTI upper layer or the >>>>>> JvmtiEnv::GetNamedModule? >>>>>> Probably, the generated code. >>>>> >>>>> I did mean the generated layer. >>>> >>>> Ok, thanks. >>>> >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> Update: Yes, passing a non-NULL jobject as the class_loader >>>>>>> parameter >>>>>>> when the jobject does not refer to a "class loader" is >>>>>>> caught >>>>>>> at the upper layer. >>>>>> >>>>>> The upper layer does not check that it is a class loader, just for >>>>>> non-NULL. >>>>>> I think, it is good to have an assert here to double-checks the >>>>>> pre-conditions as other caller can be added later. >>>>>> But I'm Ok to get rid of it if you suggest. >>>>> >>>>> Please keep the asserts. Basically I was mumbling to myself to >>>>> make sure that the asserts could not be reached by user code >>>>> and the "Update:" was to indicate that I did do. >>>> >>>> Ok, thanks. >>>> >>>> >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> src/share/vm/prims/jvmti.xml >>>>>>> L6550: >>>>>>> L6551: >>>>>>> L6552: >>>>>>> L6553: On return, points to a >>>>>>> java.lang.reflect.Module object. >>>>>>> L6554: >>>>>>> L6555: >>>>>>> >>>>>>> The above wording doesn't allow for module_ptr to be NULL >>>>>>> which >>>>>>> is a mismatch with the description. >>>>>> >>>>>> I disagree (or maybe I got it incorrectly). >>>>>> Pointing to NULL and be NULL is different. >>>>>> It is not allowed for the module_ptr to be NULL but Ok to pint to >>>>>> NULL on return. >>>>> >>>>> I think the description needs to be: >>>>> >>>>> On return, points to a java.lang.reflect.Module >>>>> object >>>>> or points to a NULL. >>>> >>>> Agreed, fixed. >>> >>> Disagree. You would say that a pointer is NULL, not that it points to >>> a NULL. >> >> Why are you disagree? >> The module_ptr is an out argument, it is not allowed to be NULL. >> But the returning value by this pointer can be NULL. > > As per later email I see this terminology already exists so is fine, > but I find it confusing to say "points to a NULL" - a NULL is not an > entity. If "foo points to a NULL" that implies to me "foo == &NULL;" > which is nonsense - foo == NULL, and if foo==NULL then foo points to > nothing. But the "pointer to a pointer" aspect here does confuse things. Agreed. It is a little bit confusing but users seems to be Ok with it. So that there is no motivation to improve it as it would touch many fragments. Thanks, Serguei > > Thanks, > David > >> >> Thanks, >> Serguei >> >> >>> >>> David >>> >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> >>>>> >>>>> Dan >>>> >> From david.holmes at oracle.com Wed Jun 29 02:37:26 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Jun 2016 12:37:26 +1000 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <5773328B.1090805@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772E130.40109@oracle.com> <8bfa102b-48fc-42e3-04f8-efcd7ded3589@oracle.com> <5773328B.1090805@oracle.com> Message-ID: On 29/06/2016 12:29 PM, serguei.spitsyn at oracle.com wrote: > Hi David, > > > On 6/28/16 19:17, David Holmes wrote: >> Hi Serguei, >> >> Looks good to me. A couple of comments ... > > Thank you for reviewing it! > > >> >> On 29/06/2016 6:42 AM, serguei.spitsyn at oracle.com wrote: >>> Dan, >>> >>> The updated webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.6/ >>> >> >> src/share/vm/classfile/modules.cpp >> >> Nit: >> >> + const PackageEntry* const pkg_entry = >> + get_package_entry_by_name(package_sym, h_loader, THREAD); >> >> indent on a line continuation should be 4 not 2. (no need to see >> updated webrev). > > This fragment was taken from the function get_module() with the > pre-existing indent. > There are a couple of other fragments with the indent like this. > There is a rule to follow the the file style. There are a number of indentation and line-length issues in this new file. David > >> >> --- >> >> src/share/vm/prims/jvmti.xml >> >> + or points to NULL. >> >> I would have suggested "or is NULL." as per other email, >> but I see that this terminology is pre-existing, so ignore that other >> email. > > Ok, thanks! > > >> >>> >>> >>>> Has someone checked the generated glue code for completeness and >>> proper checks? >>> >>> This is the generated upper layer function in the jvmtiEnter.cpp: >>> >>> 3185 static jvmtiError JNICALL >>> 3186 jvmti_GetNamedModule(jvmtiEnv* env, >>> 3187 jobject class_loader, >>> 3188 const char* package_name, >>> 3189 jobject* module_ptr) { >>> 3190 >>> 3191 #if !INCLUDE_JVMTI >>> 3192 return JVMTI_ERROR_NOT_AVAILABLE; >>> 3193 #else >>> 3194 if(!JvmtiEnv::is_vm_live()) { >>> 3195 return JVMTI_ERROR_WRONG_PHASE; >>> 3196 } >>> 3197 Thread* this_thread = Thread::current_or_null(); >>> 3198 if (this_thread == NULL || !this_thread->is_Java_thread()) { >>> 3199 return JVMTI_ERROR_UNATTACHED_THREAD; >>> 3200 } >>> 3201 JavaThread* current_thread = (JavaThread*)this_thread; >>> 3202 ThreadInVMfromNative __tiv(current_thread); >>> 3203 VM_ENTRY_BASE(jvmtiError, jvmti_GetNamedModule , current_thread) >>> 3204 debug_only(VMNativeEntryWrapper __vew;) >>> 3205 CautiouslyPreserveExceptionMark __em(this_thread); >>> 3206 JvmtiEnv* jvmti_env = JvmtiEnv::JvmtiEnv_from_jvmti_env(env); >>> 3207 if (!jvmti_env->is_valid()) { >>> 3208 return JVMTI_ERROR_INVALID_ENVIRONMENT; >>> 3209 } >>> 3210 jvmtiError err; >>> 3211 if (package_name == NULL) { >>> 3212 return JVMTI_ERROR_NULL_POINTER; >>> 3213 } >>> 3214 if (module_ptr == NULL) { >>> 3215 return JVMTI_ERROR_NULL_POINTER; >>> 3216 } >>> 3217 err = jvmti_env->GetNamedModule(class_loader, package_name, >>> module_ptr); >>> 3218 return err; >>> 3219 #endif // INCLUDE_JVMTI >>> 3220 } >>> >>> >>> I do not see any problems in the above. >> >> Looks good to me too. > > Good. > > > Thanks! > Serguei > > >> >> Thanks, >> David >> >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> >>> On 6/28/16 11:19, Daniel D. Daugherty wrote: >>>> On 6/28/16 10:37 AM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Harold, >>>>> >>>>> Thank you again for the comments! >>>>> This is the updated webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.5/ >>>>> >>>>> >>>> >>>> make/test/JtregNative.gmk >>>> No comments. >>>> >>>> src/share/vm/classfile/modules.hpp >>>> No comments. >>>> >>>> src/share/vm/classfile/modules.cpp >>>> L826: assert(h_loader.is_null() || >>>> java_lang_ClassLoader::is_subclass(h_loader->klass()), >>>> L827: "Class loader is not a subclass of >>>> java.lang.ClassLoader"); >>>> nit: indent on L827 is off by 1 space >>>> >>>> I'll have to check the upper layers of this API, but if an >>>> agent can pass a bad 'class_loader' parameter and get this >>>> assert() to fire, then that's not good. Hopefully a bad >>>> 'class_loader' parameter is caught at a higher layer. >>>> >>>> Update: Yes, passing a non-NULL jobject as the class_loader >>>> parameter >>>> when the jobject does not refer to a "class loader" is >>>> caught >>>> at the upper layer. >>>> >>>> L828: assert(package_str != NULL, "the package_str should not be >>>> NULL"); >>>> Same concern about the package_str parameter. >>>> >>>> Update: Yes, the generated JVM/TI glue code should catch a >>>> NULL package_name/package_str at the upper layers. >>>> >>>> >>>> src/share/vm/prims/jvmti.xml >>>> L6550: >>>> L6551: >>>> L6552: >>>> L6553: On return, points to a >>>> java.lang.reflect.Module object. >>>> L6554: >>>> L6555: >>>> >>>> The above wording doesn't allow for module_ptr to be NULL which >>>> is a mismatch with the description. >>>> >>>> L2518: function can be used to map class loader and package >>>> name to a module. >>>> Typo: 'map class loader and package name' >>>> -> 'map a class loader and a package name' >>>> >>>> >>>> src/share/vm/prims/jvmtiEnv.cpp >>>> L204: // class_loader - NULL is a valid value, must be pre-checked >>>> L205: // package_name - pre-checked for NULL >>>> L206: // module_ptr - pre-checked for NULL >>>> The jvmti.xml file doesn't mark package_name or module_ptr >>>> with so both of those should be checked by the >>>> generated glue code. >>>> >>>> class_loader is marked with so a NULL class_loader >>>> will get to here: >>>> >>>> L217: jobject module = Modules::get_named_module(h_loader, >>>> package_name, THREAD); >>>> >>>> and it looks like all the code paths in get_named_module() >>>> properly account for both NULL and non-NULL h_loader. Cool. >>>> >>>> test/serviceability/jvmti/GetNamedModule/MyPackage/GetNamedModuleTest.java >>>> >>>> >>>> L42: System.err.println("java.library.path:" >>>> nit: a space between the ':' and '"' would make the >>>> output more readable >>>> >>>> test/serviceability/jvmti/GetNamedModule/libGetNamedModuleTest.c >>>> L81: res = JNI_ENV_PTR(jvm)->GetEnv(JNI_ENV_ARG(jvm, (void **) >>>> &jvmti), >>>> L82: JVMTI_VERSION_1_1); >>>> I was expecting this test to ask for the JVM/TI version that >>>> includes support for GetAllModules() and GetNamesModule(). >>>> Looks like that is version 9.0.0 or newer aka JVMTI_VERSION_9. >>>> >>>> L360: if (module != NULL || mod_name !=NULL) { >>>> bit: space after '!=' and before NULL >>>> >>>> Has someone checked the generated glue code for completeness and >>>> proper checks? >>>> >>>> Dan >>>> >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 6/28/16 07:32, harold seigel wrote: >>>>>> >>>>>> Hi Serguei, >>>>>> >>>>>> Looks good. >>>>>> >>>>>> 1. In modules.cpp, the first assert in get_named_module() has the >>>>>> wrong function name: >>>>>> >>>>>> 825 assert(ModuleEntryTable::javabase_defined(), >>>>>> 826 "Attempt to call *get_module_by_package_name* before java.base >>>>>> is defined"); >>>>>> >>>>>> 2. Also, is a check needed to ensure that package_str is not null? >>>>>> >>>>>> 3. Is the ResourceMark(THREAD) needed at line 824? >>>>>> >>>>>> Thanks, Harold >>>>>> >>>>>> On 6/28/2016 4:54 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> Thank you for the comments! >>>>>>> I agree with you. >>>>>>> >>>>>>> Updated Hotspot webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.4/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 6/27/16 22:06, David Holmes wrote: >>>>>>>> Hi Serguei, >>>>>>>> >>>>>>>> Overall this looks a lot clearer/simpler. >>>>>>>> >>>>>>>> On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Please, review the Jigsaw fix for the enhancement: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The Hotspot webrev: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> Are there intended to be other callers of >>>>>>>> Module::get_named_module? If not it seems odd to go to all the >>>>>>>> trouble of throwing exceptions, just to have the caller clear them >>>>>>>> and return an error code. Or you could move all that argument >>>>>>>> checking code into the JVMTI function directly - if called >>>>>>>> internally you would just assert that arguments are as expected. >>>>>>>> >>>>>>>> >>>>>>>> src/share/vm/prims/jvmti.xml >>>>>>>> >>>>>>>> + otherwise the NULL is returned. >>>>>>>> >>>>>>>> Delete "the". >>>>>>>> >>>>>>>> Otherwise all looks good to me. >>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The Jdk webrev is the same: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> Sorry, the Jdk webrev changed as well: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Looks fine. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Summary: >>>>>>>>>> >>>>>>>>>> This is the review round #3. >>>>>>>>>> Alan suggested to replace the function GetModuleByPackageName >>>>>>>>>> with >>>>>>>>>> the GetNamedModule. >>>>>>>>>> New function will return NULL if the package is not in a module >>>>>>>>>> defined to the class loader. >>>>>>>>>> It simplifies the API and makes it easier to specify. >>>>>>>>>> JVM TI agents that instrument code in named modules need the >>>>>>>>>> Module >>>>>>>>>> at class load time. >>>>>>>>>> >>>>>>>>>> One question that came from the function semantics change. >>>>>>>>>> I had to implement the Modules::get_named_module() from scratch >>>>>>>>>> independently of the existing >>>>>>>>>> Modules::get_module_by_package_name() and >>>>>>>>>> Modules::get_module(). >>>>>>>>>> The issue is that the Modules::get_module() can return the >>>>>>>>>> unnamed >>>>>>>>>> module whereas the >>>>>>>>>> JVMTI helper Modules::get_named_module() should return NULL >>>>>>>>>> instead >>>>>>>>>> of the unnamed module. >>>>>>>>>> Please, let me know if it is Ok or if you have better ideas >>>>>>>>>> how to >>>>>>>>>> share the code. >>>>>>>>>> >>>>>>>>>> This is the Summary from review round #1: >>>>>>>>>> >>>>>>>>>> One way to do this is by introducing a new ClassFileLoadHook >>>>>>>>>> that >>>>>>>>>> takes an additional parameter but this approach is disruptive. >>>>>>>>>> The alternative option is a JVM TI function that maps a >>>>>>>>>> classloader >>>>>>>>>> + package name to a module. >>>>>>>>>> We were initially not confident with this approach so we >>>>>>>>>> introduced >>>>>>>>>> it as JVM function JVM_GetModuleByPackageName. >>>>>>>>>> Based on experience to date then this approach seems okay >>>>>>>>>> and so >>>>>>>>>> this function needs to be promoted to a JVMTI function. >>>>>>>>>> >>>>>>>>>> It includes new jtreg test with native JVMTI agent. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Testing: >>>>>>>>>> Run newly developed jtreg test. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > From david.holmes at oracle.com Wed Jun 29 05:19:23 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Jun 2016 15:19:23 +1000 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <94572805-06D5-456B-B73E-70BBD642CA22@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <3f6719ad-95a3-12eb-572a-8c171306fc8d@oracle.com> <94572805-06D5-456B-B73E-70BBD642CA22@oracle.com> Message-ID: <59522cd6-3823-bfa2-8785-bb472dd875ca@oracle.com> Hi Mandy, On 29/06/2016 12:28 PM, Mandy Chung wrote: > >> On Jun 28, 2016, at 4:23 PM, David Holmes wrote: >> >> On 29/06/2016 8:43 AM, Kim Barrett wrote: >>> Updated webrevs: >>> >>> Full: >>> http://cr.openjdk.java.net/~kbarrett/8156500/jdk.01/ >>> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.01/ >>> >>> Incremental: >>> http://cr.openjdk.java.net/~kbarrett/8156500/jdk.01.inc/ >> >> Did Reference not work? Just curious. I used to be a qualified Java programmer back in the Java 5 era, but wildcards were always a bit iffy :) > > > A related post in compiler-dev w.r.t. Reference: > http://mail.openjdk.java.net/pipermail/compiler-dev/2014-January/008457.html > > Looks like no reply on that thread though. > >> >>> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.01.inc/ >>> >>> Still investigating the initialization order for core exceptions. >> >> I suspect it is as Coleen indicated that the module changes introduced the new failure path that you hit. I did a quick check of the initialization order in an old b50: >> >> 33 Initializing 'java/lang/Throwable' (0x0000001780002990) >> ... >> 46 Initializing 'java/lang/Exception'(no method) (0x0000001780003158) >> 47 Initializing 'java/lang/InterruptedException'(no method) (0x00000017800178a8) >> >> Compare that with a current build: >> >> 60 Initializing 'java/lang/ref/Reference$ReferenceHandler' (0x000000080001e3f0) >> 61 Initializing 'java/lang/Throwable' (0x00000008000029f8) >> 62 Initializing 'java/lang/Exception'(no method) (0x00000008000031a8) >> 63 Initializing 'java/lang/InterruptedException'(no method) (0x000000080001e6e0) >> 64 Initializing 'java/lang/ref/PhantomReference'(no method) (0x0000000800006440) >> > > How do you get this list? For current builds: java -Xlog:class+init -version (and I trimmed the output) For slightly older builds: java -Xlog:classinit -version For pre UL you need a fastdebug build and: java -XX:+TraceClassInitialization -version > >> Initialization of Throwable is much, much later (large parts of java.lang and java.util are now initialized first!) and is obviously a direct consequence of preinitializing InterruptedException. >> > > Do you mind trying b110 before JEP 261 was integrated in jdk-9+111 and see any difference? Here's fragment from b109: 31 Initializing 'java/lang/ref/Reference' (0x0000000800005a08) 32 Initializing 'java/lang/ref/Reference$Lock'(no method) (0x00000008000181c0) 33 Initializing 'java/lang/ref/Reference$ReferenceHandler' (0x00000008000183b8) 34 Initializing 'java/lang/Throwable' (0x00000008000028f0) > initPhase1 is expected to be called very early in the VM initialization after the primordial classes are loaded. > > IIRC, the exception classes are preallocated to improve diagnosability in the case when we run out of memory VM can still throw a preallocated instance with an preallocated stack trace buffer. I don?t think these exception classes are expected to be loaded initPhase1. So here is what I see has happened. Looking back at 9-b01, before we forced the initialization of InterruptedException and thus Throwable we find: 58 Initializing 'java/lang/Throwable' (0x0000000800002990) So Kim is right this was working by accident. It just seems that back then there was less memory required by the initialization of all the collection and other classes and so we didn't run into this problem. Post the InterruptedException change the initialization order made it unlikely an OOME could be encountered before Throwable was initialized (and after we have reached a point where we can throw without the VM crashing or instead doing a vm_exit_during_initialization). Post modules those collection classes, and others, are now done earlier again and before Throwable. And presumably their memory demands have increased. Although we preallocate the OutOfMemoryError instances, and avoid executing any java code to do so, we can't necessarily** "throw" them until after Throwable is initialized. We now have a lot more initialization occurring before we init Throwable and so OOME is more likely and so it will fail as Kim observed. ** I say necessarily because I still believe it is the fact we attempt to fill in the stacktrace that leads to the dependency on Throwable being initialized, and we should be able to avoid that if we check the VM initialization state in gen_out_of_memory_error(). Thanks, David > More to dig here. > > Mandy > >> So I would say that the module change did break this and that initialization of Throwable (only) should be restored to a much higher place in the initialization sequence. >> >> Thanks, >> David >> > From jesper.wilhelmsson at oracle.com Wed Jun 29 08:45:00 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 29 Jun 2016 10:45:00 +0200 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> <5772E79F.3040504@oracle.com> <57732DDF.4070904@oracle.com> Message-ID: 29 juni 2016 kl. 04:30 skrev David Holmes : > >> On 29/06/2016 12:09 PM, serguei.spitsyn at oracle.com wrote: >>> On 6/28/16 18:44, David Holmes wrote: >>>> On 29/06/2016 7:09 AM, serguei.spitsyn at oracle.com wrote: >>>>> On 6/28/16 14:02, Daniel D. Daugherty wrote: >>>>>> On 6/28/16 2:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> On 6/28/16 11:19, Daniel D. Daugherty wrote: >>>>>>> >>>>>>> >>>>>>> I'll have to check the upper layers of this API, but if an >>>>>>> agent can pass a bad 'class_loader' parameter and get this >>>>>>> assert() to fire, then that's not good. Hopefully a bad >>>>>>> 'class_loader' parameter is caught at a higher layer. >>>>>> >>>>>> Not sure, what do you mean. >>>>>> Do you mean the generated JVMTI upper layer or the >>>>>> JvmtiEnv::GetNamedModule? >>>>>> Probably, the generated code. >>>>> >>>>> I did mean the generated layer. >>>> >>>> Ok, thanks. >>>> >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> Update: Yes, passing a non-NULL jobject as the class_loader >>>>>>> parameter >>>>>>> when the jobject does not refer to a "class loader" is >>>>>>> caught >>>>>>> at the upper layer. >>>>>> >>>>>> The upper layer does not check that it is a class loader, just for >>>>>> non-NULL. >>>>>> I think, it is good to have an assert here to double-checks the >>>>>> pre-conditions as other caller can be added later. >>>>>> But I'm Ok to get rid of it if you suggest. >>>>> >>>>> Please keep the asserts. Basically I was mumbling to myself to >>>>> make sure that the asserts could not be reached by user code >>>>> and the "Update:" was to indicate that I did do. >>>> >>>> Ok, thanks. >>>> >>>> >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> src/share/vm/prims/jvmti.xml >>>>>>> L6550: >>>>>>> L6551: >>>>>>> L6552: >>>>>>> L6553: On return, points to a >>>>>>> java.lang.reflect.Module object. >>>>>>> L6554: >>>>>>> L6555: >>>>>>> >>>>>>> The above wording doesn't allow for module_ptr to be NULL >>>>>>> which >>>>>>> is a mismatch with the description. >>>>>> >>>>>> I disagree (or maybe I got it incorrectly). >>>>>> Pointing to NULL and be NULL is different. >>>>>> It is not allowed for the module_ptr to be NULL but Ok to pint to >>>>>> NULL on return. >>>>> >>>>> I think the description needs to be: >>>>> >>>>> On return, points to a java.lang.reflect.Module object >>>>> or points to a NULL. >>>> >>>> Agreed, fixed. >>> >>> Disagree. You would say that a pointer is NULL, not that it points to >>> a NULL. >> >> Why are you disagree? >> The module_ptr is an out argument, it is not allowed to be NULL. >> But the returning value by this pointer can be NULL. > > As per later email I see this terminology already exists so is fine, but I find it confusing to say "points to a NULL" - a NULL is not an entity. If "foo points to a NULL" that implies to me "foo == &NULL;" which is nonsense - foo == NULL, and if foo==NULL then foo points to nothing. But the "pointer to a pointer" aspect here does confuse things. I would prefer if it said "points to a NULL pointer", or NULL-pointer. I'm not sure what would be the more correct way to write it. Anyway, a NULL pointer is an entity :-) /Jesper > > Thanks, > David > >> >> Thanks, >> Serguei >> >> >>> >>> David >>> >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> >>>>> >>>>> Dan >>>> >> From serguei.spitsyn at oracle.com Wed Jun 29 08:53:59 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Jun 2016 01:53:59 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> <5772E79F.3040504@oracle.com> <57732DDF.4070904@oracle.com> Message-ID: <57738CA7.2080404@oracle.com> On 6/29/16 01:45, Jesper Wilhelmsson wrote: > 29 juni 2016 kl. 04:30 skrev David Holmes : >>> On 29/06/2016 12:09 PM, serguei.spitsyn at oracle.com wrote: >>>> On 6/28/16 18:44, David Holmes wrote: >>>>> On 29/06/2016 7:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>> On 6/28/16 14:02, Daniel D. Daugherty wrote: >>>>>>> On 6/28/16 2:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> On 6/28/16 11:19, Daniel D. Daugherty wrote: >>>>>>>> >>>>>>>> >>>>>>>> I'll have to check the upper layers of this API, but if an >>>>>>>> agent can pass a bad 'class_loader' parameter and get this >>>>>>>> assert() to fire, then that's not good. Hopefully a bad >>>>>>>> 'class_loader' parameter is caught at a higher layer. >>>>>>> Not sure, what do you mean. >>>>>>> Do you mean the generated JVMTI upper layer or the >>>>>>> JvmtiEnv::GetNamedModule? >>>>>>> Probably, the generated code. >>>>>> I did mean the generated layer. >>>>> Ok, thanks. >>>>> >>>>>> >>>>>>>> Update: Yes, passing a non-NULL jobject as the class_loader >>>>>>>> parameter >>>>>>>> when the jobject does not refer to a "class loader" is >>>>>>>> caught >>>>>>>> at the upper layer. >>>>>>> The upper layer does not check that it is a class loader, just for >>>>>>> non-NULL. >>>>>>> I think, it is good to have an assert here to double-checks the >>>>>>> pre-conditions as other caller can be added later. >>>>>>> But I'm Ok to get rid of it if you suggest. >>>>>> Please keep the asserts. Basically I was mumbling to myself to >>>>>> make sure that the asserts could not be reached by user code >>>>>> and the "Update:" was to indicate that I did do. >>>>> Ok, thanks. >>>>> >>>>> >>>>>> >>>>>>>> src/share/vm/prims/jvmti.xml >>>>>>>> L6550: >>>>>>>> L6551: >>>>>>>> L6552: >>>>>>>> L6553: On return, points to a >>>>>>>> java.lang.reflect.Module object. >>>>>>>> L6554: >>>>>>>> L6555: >>>>>>>> >>>>>>>> The above wording doesn't allow for module_ptr to be NULL >>>>>>>> which >>>>>>>> is a mismatch with the description. >>>>>>> I disagree (or maybe I got it incorrectly). >>>>>>> Pointing to NULL and be NULL is different. >>>>>>> It is not allowed for the module_ptr to be NULL but Ok to pint to >>>>>>> NULL on return. >>>>>> I think the description needs to be: >>>>>> >>>>>> On return, points to a java.lang.reflect.Module object >>>>>> or points to a NULL. >>>>> Agreed, fixed. >>>> Disagree. You would say that a pointer is NULL, not that it points to >>>> a NULL. >>> Why are you disagree? >>> The module_ptr is an out argument, it is not allowed to be NULL. >>> But the returning value by this pointer can be NULL. >> As per later email I see this terminology already exists so is fine, but I find it confusing to say "points to a NULL" - a NULL is not an entity. If "foo points to a NULL" that implies to me "foo == &NULL;" which is nonsense - foo == NULL, and if foo==NULL then foo points to nothing. But the "pointer to a pointer" aspect here does confuse things. > I would prefer if it said "points to a NULL pointer", or NULL-pointer. I'm not sure what would be the more correct way to write it. Anyway, a NULL pointer is an entity :-) Jesper, Thank you for the comment. In fact, I've just used a pattern that is already present in the JVMTI spec. Objections to the existing pattern are minor, so it is better to be more conservative here. Thanks, Serguei > /Jesper > > >> Thanks, >> David >> >>> Thanks, >>> Serguei >>> >>> >>>> David >>>> >>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>>> >>>>>> Dan From peter.levart at gmail.com Wed Jun 29 11:22:55 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 29 Jun 2016 13:22:55 +0200 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <6C2DABC1-AB1D-4CF1-BB40-22107A37D122@oracle.com> References: <5772447E.9020900@oracle.com> <6C2DABC1-AB1D-4CF1-BB40-22107A37D122@oracle.com> Message-ID: Hi Kim, Let me chime-in although it's a bit late... I think this is a good change to finally get rid of OOME problems in this area. On 06/28/2016 07:45 PM, Kim Barrett wrote: >> On Jun 28, 2016, at 5:33 AM, Per Liden wrote: >> Patch looks good. The only thing I don't feel qualified to review is the initialization order change in thread.cpp, so I'll let others comments on that. > Thanks. I?ll be following up on that area. > >> I like the pop-one-reference-at-a-time semantics, which simplifies things a lot and keeps the interface nice and clean. I was previously afraid that it might cause a noticeable performance degradation compared to lifting the whole list into Java in one go, but your testing seem to prove that's not the case. > I was concerned about that too, and had tried a different approach that also still supported the existing "some callers wait and others don?t" API, but it was a bit messy. Coleen convinced me to try this (since it was easy) and do the measurement, and it worked out well. > The repeated JNI invocations do not present a big overhead, but it is measurable. For example, the following benchmark measures the time it takes after a GC cycle for a bunch of references to be transfered to Java side, enqueued into ReferenceQueue and dequeued from it: http://cr.openjdk.java.net/~plevart/misc/PendingReferenceHandling/ReferenceEnqueueBench.java The results on my i7-4771 PC: Original JDK 9: Benchmark (refCount) Mode Cnt Score Error Units ReferenceEnqueueBench.dequeueReferences 100000 ss 100 38410.515 ? 1011.769 us/op Patched (by Kim): Benchmark (refCount) Mode Cnt Score Error Units ReferenceEnqueueBench.dequeueReferences 100000 ss 100 42197.522 ? 1161.451 us/op So, about 10% worse for this benchmark. Transfering the whole list in one JNI invocation has the potential for further optimizations on the Java side (like handling the whole popped list privately without additional synchronization - if we ever find a way for java.nio.Bits to wait for it reliably - or even enqueue-ing a chunk of consecutive references destined for the same queue using a single synchronized action on the queue, etc...) If the JNI API was something like the following: /* Atomically pop the pending reference list if wholeList is true, * or just next pending reference if wholeList is false. * If wait is true and the pending reference list is empty, blocks until * it becomes non-empty, or returns null if wait is false. */ private static native Reference popReferencePendingList(boolean wholeList, boolean wait); Then not too much complication is needed in Reference.java (diff to current JDK 9 sources) to consume this API and already have some benefit from it: http://cr.openjdk.java.net/~plevart/misc/PendingReferenceHandling/webrev/ There is a possible race here between ReferenceHandler calling tryHandlePending(true) and java.nio.Bits calling tryHandlePending(false) that can make the method return false to java.nio.Bits when ReferenceHandler has just popped the whole list and not yet installed it in the private pendingList field, but java.nio.Bits makes several retries in this case with exponentially increasing delays, so that does not currently present a problem. java/nio/Buffer/DirectBufferAllocTest.java test passes with this change. And the above benchmark shows improvement instead of regression: Proposed (my Peter): Benchmark (refCount) Mode Cnt Score Error Units ReferenceEnqueueBench.dequeueReferences 100000 ss 100 34134.977 ? 1274.753 us/op So what do you think? Is it worth the little additional logic on the Java side? Regards, Peter From aph at redhat.com Wed Jun 29 13:00:11 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 Jun 2016 14:00:11 +0100 Subject: Many jtreg errors Message-ID: <5773C65B.9000602@redhat.com> This is hs-comp, x86-64, jtreg 4.2 dev b02 zebedee:test $ JAVA_HOME=/home/aph/hs-comp/build/linux-x86_64-normal-server-fastdebug//jdk/ ~/jtreg/bin/jtreg -v gc/arguments/TestSurvivorRatioFlag.java Exception in thread "main" java.lang.NoClassDefFoundError: java/lang/management/ManagementFactory at requires.VMProps.vmFlightRecorder(VMProps.java:134) at requires.VMProps.call(VMProps.java:58) at requires.VMProps.call(VMProps.java:44) at com.sun.javatest.regtest.agent.GetJDKProperties.main(GetJDKProperties.java:49) Caused by: java.lang.ClassNotFoundException: java.lang.management.ManagementFactory at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base/BuiltinClassLoader.java:366) at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base/ClassLoaders.java:185) at java.lang.ClassLoader.loadClass(java.base/ClassLoader.java:419) ... 4 more Error: failed to get JDK properties for /home/aph/hs-comp/build/linux-x86_64-normal-server-fastdebug/jdk/bin/java ; exit code 1 I'm seeing a lot of things like this. Is there something else that I should be doing? Thanks, Andrew. From vladimir.x.ivanov at oracle.com Wed Jun 29 13:05:47 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 29 Jun 2016 16:05:47 +0300 Subject: Many jtreg errors In-Reply-To: <5773C65B.9000602@redhat.com> References: <5773C65B.9000602@redhat.com> Message-ID: <594e6f6e-582c-0700-34c1-767e4ab32e2c@oracle.com> Most likely, it's JDK-8154239 [1], which is specific to exploded build. Have you tried to run the tests using complete jdk images? Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8154239 On 6/29/16 4:00 PM, Andrew Haley wrote: > This is hs-comp, x86-64, jtreg 4.2 dev b02 > > zebedee:test $ JAVA_HOME=/home/aph/hs-comp/build/linux-x86_64-normal-server-fastdebug//jdk/ ~/jtreg/bin/jtreg -v gc/arguments/TestSurvivorRatioFlag.java > Exception in thread "main" java.lang.NoClassDefFoundError: java/lang/management/ManagementFactory > at requires.VMProps.vmFlightRecorder(VMProps.java:134) > at requires.VMProps.call(VMProps.java:58) > at requires.VMProps.call(VMProps.java:44) > at com.sun.javatest.regtest.agent.GetJDKProperties.main(GetJDKProperties.java:49) > Caused by: java.lang.ClassNotFoundException: java.lang.management.ManagementFactory > at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base/BuiltinClassLoader.java:366) > at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base/ClassLoaders.java:185) > at java.lang.ClassLoader.loadClass(java.base/ClassLoader.java:419) > ... 4 more > Error: failed to get JDK properties for /home/aph/hs-comp/build/linux-x86_64-normal-server-fastdebug/jdk/bin/java ; exit code 1 > > I'm seeing a lot of things like this. Is there something else that > I should be doing? > > Thanks, > > Andrew. > From kirill.zhaldybin at oracle.com Wed Jun 29 13:15:23 2016 From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin) Date: Wed, 29 Jun 2016 16:15:23 +0300 Subject: Many jtreg errors In-Reply-To: <5773C65B.9000602@redhat.com> References: <5773C65B.9000602@redhat.com> Message-ID: <5773C9EB.2080008@oracle.com> Andrew, Could you please try to use jdk from build//images/jdk? JDK from build//jdk as far as I understand is not final jdk. Thank you. Regards, Kirill On 29.06.2016 16:00, Andrew Haley wrote: > This is hs-comp, x86-64, jtreg 4.2 dev b02 > > zebedee:test $ JAVA_HOME=/home/aph/hs-comp/build/linux-x86_64-normal-server-fastdebug//jdk/ ~/jtreg/bin/jtreg -v gc/arguments/TestSurvivorRatioFlag.java > Exception in thread "main" java.lang.NoClassDefFoundError: java/lang/management/ManagementFactory > at requires.VMProps.vmFlightRecorder(VMProps.java:134) > at requires.VMProps.call(VMProps.java:58) > at requires.VMProps.call(VMProps.java:44) > at com.sun.javatest.regtest.agent.GetJDKProperties.main(GetJDKProperties.java:49) > Caused by: java.lang.ClassNotFoundException: java.lang.management.ManagementFactory > at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base/BuiltinClassLoader.java:366) > at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base/ClassLoaders.java:185) > at java.lang.ClassLoader.loadClass(java.base/ClassLoader.java:419) > ... 4 more > Error: failed to get JDK properties for /home/aph/hs-comp/build/linux-x86_64-normal-server-fastdebug/jdk/bin/java ; exit code 1 > > I'm seeing a lot of things like this. Is there something else that > I should be doing? > > Thanks, > > Andrew. > From aph at redhat.com Wed Jun 29 13:26:31 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 Jun 2016 14:26:31 +0100 Subject: Many jtreg errors In-Reply-To: <594e6f6e-582c-0700-34c1-767e4ab32e2c@oracle.com> References: <5773C65B.9000602@redhat.com> <594e6f6e-582c-0700-34c1-767e4ab32e2c@oracle.com> Message-ID: <5773CC87.4080904@redhat.com> On 29/06/16 14:05, Vladimir Ivanov wrote: > Most likely, it's JDK-8154239 [1], which is specific to exploded build. > Have you tried to run the tests using complete jdk images? Oh, that again. I remember now that jtreg testing broke in the same way last year. Yes, that seems to fix it. Thanks, Andrew. From peter.levart at gmail.com Wed Jun 29 13:30:08 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 29 Jun 2016 15:30:08 +0200 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: <5772447E.9020900@oracle.com> <6C2DABC1-AB1D-4CF1-BB40-22107A37D122@oracle.com> Message-ID: <820a2afb-02fa-e841-0dfe-0f3d9ee41c66@gmail.com> Hi Kim, On 06/29/2016 01:22 PM, Peter Levart wrote: > Transfering the whole list in one JNI invocation has the potential for > further optimizations on the Java side (like handling the whole popped > list privately without additional synchronization - if we ever find a > way for java.nio.Bits to wait for it reliably - or even enqueue-ing a > chunk of consecutive references destined for the same queue using a > single synchronized action on the queue, etc...) Just to show what I mean, here's a simple optimization that doesn't use a private pendingList of references shared among callers of tryHandlePanding(true/false), but instead uses course-grained synchronization and waiting for tryHandlePanding(false) callers while ReferenceHandler is privately processing the whole list of pending references: http://cr.openjdk.java.net/~plevart/misc/PendingReferenceHandling/webrev.02/ This further improves benchmark results and it still passes the DirectBufferAllocTest: Original JDK 9: Benchmark (refCount) Mode Cnt Score Error Units ReferenceEnqueueBench.dequeueReferences 100000 ss 100 38410.515 ? 1011.769 us/op Patched (by Kim): Benchmark (refCount) Mode Cnt Score Error Units ReferenceEnqueueBench.dequeueReferences 100000 ss 100 42197.522 ? 1161.451 us/op Proposed (by Peter, webrev): Benchmark (refCount) Mode Cnt Score Error Units ReferenceEnqueueBench.dequeueReferences 100000 ss 100 34134.977 ? 1274.753 us/op Proposed (by Peter, webrev.02): Benchmark (refCount) Mode Cnt Score Error Units ReferenceEnqueueBench.dequeueReferences 100000 ss 100 27935.929 ? 1128.678 us/op Regards, Peter From daniel.daugherty at oracle.com Wed Jun 29 14:59:06 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 29 Jun 2016 08:59:06 -0600 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <57738CA7.2080404@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> <5772E79F.3040504@oracle.com> <57732DDF.4070904@oracle.com> <57738CA7.2080404@oracle.com> Message-ID: <4edd4611-6e6b-d61d-22c4-c099f02db2d8@oracle.com> On 6/29/16 2:53 AM, serguei.spitsyn at oracle.com wrote: > On 6/29/16 01:45, Jesper Wilhelmsson wrote: >> 29 juni 2016 kl. 04:30 skrev David Holmes : >>>> On 29/06/2016 12:09 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 6/28/16 18:44, David Holmes wrote: >>>>>> On 29/06/2016 7:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> On 6/28/16 14:02, Daniel D. Daugherty wrote: >>>>>>>> On 6/28/16 2:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> On 6/28/16 11:19, Daniel D. Daugherty wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> I'll have to check the upper layers of this API, but >>>>>>>>> if an >>>>>>>>> agent can pass a bad 'class_loader' parameter and get >>>>>>>>> this >>>>>>>>> assert() to fire, then that's not good. Hopefully a bad >>>>>>>>> 'class_loader' parameter is caught at a higher layer. >>>>>>>> Not sure, what do you mean. >>>>>>>> Do you mean the generated JVMTI upper layer or the >>>>>>>> JvmtiEnv::GetNamedModule? >>>>>>>> Probably, the generated code. >>>>>>> I did mean the generated layer. >>>>>> Ok, thanks. >>>>>> >>>>>>> >>>>>>>>> Update: Yes, passing a non-NULL jobject as the >>>>>>>>> class_loader >>>>>>>>> parameter >>>>>>>>> when the jobject does not refer to a "class >>>>>>>>> loader" is >>>>>>>>> caught >>>>>>>>> at the upper layer. >>>>>>>> The upper layer does not check that it is a class loader, just for >>>>>>>> non-NULL. >>>>>>>> I think, it is good to have an assert here to double-checks the >>>>>>>> pre-conditions as other caller can be added later. >>>>>>>> But I'm Ok to get rid of it if you suggest. >>>>>>> Please keep the asserts. Basically I was mumbling to myself to >>>>>>> make sure that the asserts could not be reached by user code >>>>>>> and the "Update:" was to indicate that I did do. >>>>>> Ok, thanks. >>>>>> >>>>>> >>>>>>> >>>>>>>>> src/share/vm/prims/jvmti.xml >>>>>>>>> L6550: >>>>>>>>> L6551: >>>>>>>>> L6552: >>>>>>>>> L6553: On return, points to a >>>>>>>>> java.lang.reflect.Module object. >>>>>>>>> L6554: >>>>>>>>> L6555: >>>>>>>>> >>>>>>>>> The above wording doesn't allow for module_ptr to be NULL >>>>>>>>> which >>>>>>>>> is a mismatch with the description. >>>>>>>> I disagree (or maybe I got it incorrectly). >>>>>>>> Pointing to NULL and be NULL is different. >>>>>>>> It is not allowed for the module_ptr to be NULL but Ok to pint to >>>>>>>> NULL on return. >>>>>>> I think the description needs to be: >>>>>>> >>>>>>> On return, points to a java.lang.reflect.Module >>>>>>> object >>>>>>> or points to a NULL. >>>>>> Agreed, fixed. >>>>> Disagree. You would say that a pointer is NULL, not that it points to >>>>> a NULL. >>>> Why are you disagree? >>>> The module_ptr is an out argument, it is not allowed to be NULL. >>>> But the returning value by this pointer can be NULL. >>> As per later email I see this terminology already exists so is fine, >>> but I find it confusing to say "points to a NULL" - a NULL is not an >>> entity. If "foo points to a NULL" that implies to me "foo == &NULL;" >>> which is nonsense - foo == NULL, and if foo==NULL then foo points to >>> nothing. But the "pointer to a pointer" aspect here does confuse >>> things. >> I would prefer if it said "points to a NULL pointer", or >> NULL-pointer. I'm not sure what would be the more correct way to >> write it. Anyway, a NULL pointer is an entity :-) > Jesper, > > Thank you for the comment. > In fact, I've just used a pattern that is already present in the JVMTI > spec. > Objections to the existing pattern are minor, so it is better to be > more conservative here. Perhaps we can use the wording in this JVM/TI function as a model: http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#GetCurrentContendedMonitor This function takes a "jobject *" as a parameter and returns a monitor pointer via that parameter. Pretty similar to what we're discussing... So here's the existing wording example: Name Type Description =========== ======== =========== monitor_ptr jobject* On return, filled with the current contended monitor, or NULL if there is none. Agent passes a pointer to a jobject. On return, the jobject has been set. The object returned by monitor_ptr is a JNI local reference and must be managed. So for the new function: module_ptr jobject* On return, filled with a java.lang.reflect.Module object or NULL if there is none. This "filled with" style is used for return parameters in ~13 places in the JVM/TI spec. Of course, now that I've found the GetCurrentContendedMonitor example, That second paragraph or something like it is also going to be needed with our new function... Spec wording is very difficult... :-) Dan > > Thanks, > Serguei > > > >> /Jesper >> >> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> David >>>>> >>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>>> >>>>>>> Dan > From peter.levart at gmail.com Wed Jun 29 15:19:09 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 29 Jun 2016 17:19:09 +0200 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <820a2afb-02fa-e841-0dfe-0f3d9ee41c66@gmail.com> References: <5772447E.9020900@oracle.com> <6C2DABC1-AB1D-4CF1-BB40-22107A37D122@oracle.com> <820a2afb-02fa-e841-0dfe-0f3d9ee41c66@gmail.com> Message-ID: <6e73bb64-de04-fcbd-a17b-6bde2ef53ddb@gmail.com> Hi again, On 06/29/2016 03:30 PM, Peter Levart wrote: > Just to show what I mean, here's a simple optimization that doesn't > use a private pendingList of references shared among callers of > tryHandlePanding(true/false), but instead uses course-grained > synchronization and waiting for tryHandlePanding(false) callers while > ReferenceHandler is privately processing the whole list of pending > references: > > http://cr.openjdk.java.net/~plevart/misc/PendingReferenceHandling/webrev.02/ > ...and now, on top of above, for some more involved optimization that is most effective when a chunk of pending references is discovered where majority are destined for the same ReferenceQueue (as in our benchmark): http://cr.openjdk.java.net/~plevart/misc/PendingReferenceHandling/webrev.03/ The results of benchmark: Original JDK 9: Benchmark (refCount) Mode Cnt Score Error Units ReferenceEnqueueBench.dequeueReferences 100000 ss 100 38410.515 ? 1011.769 us/op Patched (by Kim): Benchmark (refCount) Mode Cnt Score Error Units ReferenceEnqueueBench.dequeueReferences 100000 ss 100 42197.522 ? 1161.451 us/op Proposed (by Peter, webrev): Benchmark (refCount) Mode Cnt Score Error Units ReferenceEnqueueBench.dequeueReferences 100000 ss 100 34134.977 ? 1274.753 us/op Proposed (by Peter, webrev.02): Benchmark (refCount) Mode Cnt Score Error Units ReferenceEnqueueBench.dequeueReferences 100000 ss 100 27935.929 ? 1128.678 us/op Proposed (by Peter, webrev.03): Benchmark (refCount) Mode Cnt Score Error Units ReferenceEnqueueBench.dequeueReferences 100000 ss 100 6603.009 ? 59.051 us/op That's already 6x faster than baseline! I'm not suggesting that any of these optimizations is applied. I just wanted to show that a JNI call that allows retrieving the whole pending list has potential to allow such optimizations. Regards, Peter From jesper.wilhelmsson at oracle.com Wed Jun 29 16:55:15 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 29 Jun 2016 18:55:15 +0200 Subject: RFR: 8048093 - Explicitly setting := vs = in the -XX:+PrintFlagsFinal output In-Reply-To: References: <838ed626-566c-963c-9b9b-2fb76e0820cf@oracle.com> <1eeb5ef3-06bc-072a-070b-b3732cf5332b@oracle.com> Message-ID: After some more testing I made a few smaller updates: * Using jio_snprintf instead of snprintf in Flag::print_kind_and_origin() Looking at other code, it seemed to be the right thing to do. * Using size_t instead of int for the size and used counter in Flag::print_kind_and_origin() Windows compiler complained. * ORIG_COMMAND_LINE = 1 << 19 * Fixed some tests that was surprised by the new output from PrintFlagsFinal. New webrev: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.02/ Thanks, /Jesper Den 23/6/16 kl. 20:54, skrev Jesper Wilhelmsson: > Den 23/6/16 kl. 20:22, skrev Vladimir Kozlov: >> why you skipped 19?: >> >> ORIG_COMMAND_LINE = 1 << 20, > > No good reason really, just leaving some space since ORIG_COMMAND_LINE is not a > kind. I can change it to 19 if you think that's better. > >> >> Otherwise looks good. > > Thanks for reviewing! > > /Jesper > >> >> Thanks, >> Vladimir >> >> On 6/23/16 8:04 AM, Jesper Wilhelmsson wrote: >>> Den 22/6/16 kl. 21:33, skrev Coleen Phillimore: >>> >>>> >>>> I agree with Vladimir. There's no way I'm going to remember that a colon >>>> mean that the value was changed. >>> The colon is what we have today to indicate that a value was changed :) >>> >>> I made a different solution in which I explicitly print the origin with words. >>> To make it look better I changed the >>> printing routine somewhat. The origin is currently at the end of the line. >>> This version will also print other origins like config file, environment, and >>> management as suggested by Dan. >>> >>> New webrev: >>> http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.01/ >>> >>> Examples of -XX:+PrintFlagsFinal with and without the change: >>> >>> This is the new version: >>> >>> ccstr AbortVMOnExceptionMessage = >>> {diagnostic} {default} >>> uintx AdaptiveSizeDecrementScaleFactor = >>> 4 {product} {default} >>> intx AliasLevel = >>> 3 {C2 product} {default} >>> intx CMSAbortablePrecleanWaitMillis = >>> 100 {manageable} {default} >>> bool CMSClassUnloadingEnabled = >>> false {product} {command line} >>> intx ConditionalMoveLimit = >>> 3 {C2 pd product} {default} >>> size_t InitialHeapSize = >>> 134217728 {product} {ergonomic} >>> size_t MaxMetaspaceSize = >>> 18446744073709547520 {product} {default} >>> size_t NewSize = >>> 1966080 {product} {command line, >>> ergonomic} >>> ccstrlist OnError = {product} {default} >>> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >>> -1 {develop} {default} >>> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >>> true {product} {default} >>> bool UseCISCSpill = >>> true {C2 pd develop} {default} >>> bool UseCLMUL = >>> true {ARCH product} {default} >>> bool UseCompressedOops = >>> true {lp64_product} {ergonomic} >>> bool UseConcMarkSweepGC = >>> true {product} {command line} >>> >>> This is the old (current) version: >>> >>> ccstr AbortVMOnExceptionMessage = >>> {diagnostic} >>> uintx AdaptiveSizeDecrementScaleFactor = >>> 4 {product} >>> intx AliasLevel = >>> 3 {C2 product} >>> intx CMSAbortablePrecleanWaitMillis = >>> 100 {manageable} >>> bool CMSClassUnloadingEnabled := >>> false {product} >>> intx ConditionalMoveLimit = >>> 3 {C2 pd product} >>> size_t InitialHeapSize := >>> 134217728 {product} >>> size_t MaxMetaspaceSize = >>> 18446744073709547520 {product} >>> size_t NewSize := >>> 1966080 {product} >>> ccstrlist OnError = {product} >>> intx PSAdaptiveSizePolicyResizeVirtualSpaceAlot = >>> -1 {develop} >>> bool UseAdaptiveGenerationSizePolicyAtMajorCollection = >>> true {product} >>> bool UseCISCSpill = >>> true {C2 pd develop} >>> bool UseCompressedOops := >>> true {lp64_product} >>> bool UseConcMarkSweepGC := >>> true {product} >>> >>> /Jesper >>> >>>> Coleen >>>> >>>> >>>> On 6/21/16 4:15 PM, Vladimir Kozlov wrote: >>>>> Nobody will remember the meaning of such marking. You should use normal words. >>>>> The output already have flag's type as, for example, "{C2 product}". You can >>>>> add an other word there to indicate type >>>>> of initialization: default|command|ergo. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 6/21/16 12:09 PM, Jesper Wilhelmsson wrote: >>>>>> Hi, >>>>>> >>>>>> Please review this change to make -XX:+PrintFlagsFinal distinguish between >>>>>> flags changed on the command line and flags >>>>>> changed by the ergonomics. >>>>>> >>>>>> To enable us to remember if a flag was set on the command line or not after >>>>>> having been changed by the ergonomics I use >>>>>> another bit in the Flag struct. >>>>>> >>>>>> The actual symbols printed by PrintFlagsFinal are chosen somewhat arbitrary >>>>>> and I'm open to suggestions (bike sheding) >>>>>> about how to visualize this the best. >>>>>> >>>>>> The old decorations are: >>>>>> >>>>>> ' =' - Default value (no decoration) >>>>>> ':=' - Value was changed, either by command line or ergonomics or other >>>>>> >>>>>> The new decorations are: >>>>>> >>>>>> ' =' - Default value (no decoration) >>>>>> ':=' - Set on the command line >>>>>> '?=' - Changed by the ergonomics >>>>>> '!=' - Set on the command line AND changed by the ergonomics >>>>>> '-=' - Any other origin, like changed by management API or taken from a >>>>>> config file >>>>>> >>>>>> My reasoning behind selecting these characters are that ':=' looks like a >>>>>> solid assignment and will therefore represent >>>>>> the command line. You never know what you get from the ergonomics, so '?=' >>>>>> seems appropriate. '!=' because you'd >>>>>> want to >>>>>> know that the ergonomics changed a value you had set on the command line. >>>>>> >>>>>> Another option could be to use a colon ':=' for the command line, and a >>>>>> comma ',=' for the ergonomics. That would >>>>>> naturally give us the semi-colon ';=' for something set on the command line >>>>>> and changed by the ergonomics. I didn't go >>>>>> with this because the colon and semi-colon can be hard to distinguish from >>>>>> each other. >>>>>> >>>>>> As mentioned above there are other origins, the enum contains eight values. >>>>>> There is no mention of the other types in >>>>>> the bug and there are no is_...() for the other types in globals.cpp, so >>>>>> they didn't seem as important. If the general >>>>>> opinion is that these other origins are as important, or we might as >>>>>> well..., I'd suggest that we use letters as >>>>>> decorations. Let me know if you have an opinion. >>>>>> >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048093 >>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8048093/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> /Jesper >>>> >>> From mandy.chung at oracle.com Wed Jun 29 17:43:48 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 29 Jun 2016 10:43:48 -0700 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> Message-ID: <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> > On Jun 28, 2016, at 3:43 PM, Kim Barrett wrote: > > Updated webrevs: > > Full: > http://cr.openjdk.java.net/~kbarrett/8156500/jdk.01/ > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.01/ > The VM change does simplify the implementation a lot. Does/should the reference processing and enqueue them in the pending list at a safepoint? Or does the enqueuing happen while other Java threads are running except that it holds Heap_lock? My main concern is that the ReferenceHandler thread now has to make a VM upcall to dequeue a reference object for every iteration. I believe this is what the original implementation tried to avoid. Would it be feasible for popReferencePendingList to be intrinsified? If it is infeasible, we should think through other alternatives for example like Peter?s suggestion to get the entire pending list at a time. Comments on Reference.java 143 /* Atomically pop the next pending reference. If should_wait is 144 * true and there are no pending references, block until the 145 * pending reference list becomes non-empty. The GC adds 146 * references to the list, and notifies waiting threads when 147 * references are added. 148 */ 149 private static native Reference popReferencePendingList(boolean should_wait); The parameter name ?should_wait? - I would avoid using the word ?should? and `_`. What about ?await?? The spec needs to specify: What happens if the thread calling this method is interrupted? What does it return? Does it throw InterruptedException? What happens to the thread?s interrupted status? This method is significant and can you add @param, @return, @throws to make it a proper javadoc. This change is small but the implication is significant. JDK-7103238 would be more appropriate for this change than JDK-8156400 and its synopsis that does not highlight what the changeset is about. > Still investigating the initialization order for core exceptions. > This would be good to understand what?s going on there. Mandy From kim.barrett at oracle.com Wed Jun 29 18:54:20 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 29 Jun 2016 14:54:20 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <3f6719ad-95a3-12eb-572a-8c171306fc8d@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <3f6719ad-95a3-12eb-572a-8c171306fc8d@oracle.com> Message-ID: > On Jun 28, 2016, at 7:23 PM, David Holmes wrote: > > On 29/06/2016 8:43 AM, Kim Barrett wrote: >> Updated webrevs: >> >> Full: >> http://cr.openjdk.java.net/~kbarrett/8156500/jdk.01/ >> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.01/ >> >> Incremental: >> http://cr.openjdk.java.net/~kbarrett/8156500/jdk.01.inc/ > > Did Reference not work? Just curious. I used to be a qualified Java programmer back in the Java 5 era, but wildcards were always a bit iffy :) It did not, or at least not without more contortions than I wanted to make. The old code used , so I decided to fall back to that. Specifically, the type parameter in the type of "ref" needs to be compatible with the type parameter in the type of "q", and that seems to be messy to make happen when wildcards are involved. Having popXXX return Reference and splitting most of the body of tryHandlePending into a new parameterized helper boolean tryHandlePendingAux(Reference ref, boolean should_wait) did seem to do the trick, but also seemed like it was trying too hard... >> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.01.inc/ >> >> Still investigating the initialization order for core exceptions. > > I suspect it is as Coleen indicated that the module changes introduced the new failure path that you hit. I did a quick check of the initialization order in an old b50: > > 33 Initializing 'java/lang/Throwable' (0x0000001780002990) > ... > 46 Initializing 'java/lang/Exception'(no method) (0x0000001780003158) > 47 Initializing 'java/lang/InterruptedException'(no method) (0x00000017800178a8) > > Compare that with a current build: > > 60 Initializing 'java/lang/ref/Reference$ReferenceHandler' (0x000000080001e3f0) > 61 Initializing 'java/lang/Throwable' (0x00000008000029f8) > 62 Initializing 'java/lang/Exception'(no method) (0x00000008000031a8) > 63 Initializing 'java/lang/InterruptedException'(no method) (0x000000080001e6e0) > 64 Initializing 'java/lang/ref/PhantomReference'(no method) (0x0000000800006440) > > Initialization of Throwable is much, much later (large parts of java.lang and java.util are now initialized first!) and is obviously a direct consequence of preinitializing InterruptedException. > > So I would say that the module change did break this and that initialization of Throwable (only) should be restored to a much higher place in the initialization sequence. I think the problem may have existed long before modules, but simply wasn't noticed. That is, I suspect trying the test case mentioned below with a pre-June-2014 fastdebug build (when Reference started initializing InterruptedException) might trip the same assert. I'm presently trying to obtain a sufficiently old fastdebug build to run the experiment. The thing that has changed is that we now have a test (ol' reliable tickler of bugs TestOptionsWithRanges) that tries all kinds of wacky configurations that had never been seen before. It tripped the init order problem by trying -XX:AutoBoxCacheMax with a value of jint_max, which led to an attempt to allocate an array whose size exceeds the maximum allowed, which is reported as OOME with a specialized message, which led to the assertion failure in java_lang_Throwable::fill_in_stack_trace_of_preallocated_backtrace because java_lang_Throwable::unassigned_stacktrace() == NULL. Note that with a smaller -XX:AutoBoxCacheMax value of 1G we instead get a VM shutdown during initialization, because we are trying to GC before that's allowed, rather than trying to make an array with an impossible size. Aside: Reporting an attempt to allocate a mere 2G element objarray using an OOME seems a bit quaint these days. :-) From kim.barrett at oracle.com Wed Jun 29 19:12:08 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 29 Jun 2016 15:12:08 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <3f6719ad-95a3-12eb-572a-8c171306fc8d@oracle.com> Message-ID: <09F6BEC0-EE9E-4A48-A4CC-724DBAB0F9F9@oracle.com> > On Jun 29, 2016, at 2:54 PM, Kim Barrett wrote: > > I think the problem may have existed long before modules, but simply > wasn't noticed. That is, I suspect trying the test case mentioned > below with a pre-June-2014 fastdebug build (when Reference started > initializing InterruptedException) might trip the same assert. I'm > presently trying to obtain a sufficiently old fastdebug build to run > the experiment. Nope, works fine with JDK 9 b01. ./jdk1.9.0/fastdebug/bin/java -XX:AutoBoxCacheMax=2147483647 -version Error occurred during initialization of VM java.lang.OutOfMemoryError: Requested array size exceeds VM limit at java.lang.Integer$IntegerCache.(Integer.java:799) at java.lang.Integer.valueOf(Integer.java:827) at sun.misc.Signal.handle(Signal.java:169) at java.lang.Terminator.setup(Terminator.java:60) at java.lang.System.initializeSystemClass(System.java:1197) From coleen.phillimore at oracle.com Wed Jun 29 21:13:42 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 29 Jun 2016 17:13:42 -0400 Subject: RFR 8160551: assert(c == Bytecodes::_putfield) failed: must be putfield Message-ID: Summary: Illegal bytecodes which are detected later hit this assert first. Removed the asserts in the new code in the rewriter, and added a test that verifies that ICCE is thrown for the case in question. Tested in progress with jck tests. open webrev at http://cr.openjdk.java.net/~coleenp/8160551.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8160551 Zoltan: I borrowed your test directory name from your last review to also include my test. Thanks, Coleen From john.r.rose at oracle.com Wed Jun 29 21:26:43 2016 From: john.r.rose at oracle.com (John Rose) Date: Wed, 29 Jun 2016 14:26:43 -0700 Subject: RFR 8160551: assert(c == Bytecodes::_putfield) failed: must be putfield In-Reply-To: References: Message-ID: <48261FBA-4C7D-492D-A482-8CDC110962F7@oracle.com> Reviewed. One nit: To read the test case more easily, I would like to see the original source code for Bad, preferably commented out in the main test file like so: public class PutfieldError { ? } /* recoded in jasm: class Bad { public static final int i; //rewritten //rewritten to: public final int i; static { i = 5; } // putstatic instruction } */ On Jun 29, 2016, at 2:13 PM, Coleen Phillimore wrote: > > Summary: Illegal bytecodes which are detected later hit this assert first. > > Removed the asserts in the new code in the rewriter, and added a test that verifies that ICCE is thrown for the case in question. > > Tested in progress with jck tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8160551.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8160551 > > Zoltan: I borrowed your test directory name from your last review to also include my test. > > Thanks, > Coleen From coleen.phillimore at oracle.com Wed Jun 29 21:28:48 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 29 Jun 2016 17:28:48 -0400 Subject: RFR 8160551: assert(c == Bytecodes::_putfield) failed: must be putfield In-Reply-To: <48261FBA-4C7D-492D-A482-8CDC110962F7@oracle.com> References: <48261FBA-4C7D-492D-A482-8CDC110962F7@oracle.com> Message-ID: <83f9e27f-d023-73ef-bc8a-aa51bca9ccd9@oracle.com> On 6/29/16 5:26 PM, John Rose wrote: > Reviewed. > > One nit: To read the test case more easily, I would like to see the original source code for Bad, preferably commented out in the main test file like so: > > public class PutfieldError { > ? > } > /* recoded in jasm: > class Bad { > public static final int i; //rewritten > //rewritten to: public final int i; > static { i = 5; } // putstatic instruction > } > */ Okay, will do. Having a side-by-side .java file sometimes causes problems in jtreg so I'll add as a comment as you suggest. thanks! Coleen > > On Jun 29, 2016, at 2:13 PM, Coleen Phillimore wrote: >> Summary: Illegal bytecodes which are detected later hit this assert first. >> >> Removed the asserts in the new code in the rewriter, and added a test that verifies that ICCE is thrown for the case in question. >> >> Tested in progress with jck tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8160551.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8160551 >> >> Zoltan: I borrowed your test directory name from your last review to also include my test. >> >> Thanks, >> Coleen From david.holmes at oracle.com Wed Jun 29 21:57:05 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Jun 2016 07:57:05 +1000 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <09F6BEC0-EE9E-4A48-A4CC-724DBAB0F9F9@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <3f6719ad-95a3-12eb-572a-8c171306fc8d@oracle.com> <09F6BEC0-EE9E-4A48-A4CC-724DBAB0F9F9@oracle.com> Message-ID: <74f86fa8-cb49-d68f-6738-7467050c7d10@oracle.com> On 30/06/2016 5:12 AM, Kim Barrett wrote: >> On Jun 29, 2016, at 2:54 PM, Kim Barrett wrote: >> >> I think the problem may have existed long before modules, but simply >> wasn't noticed. That is, I suspect trying the test case mentioned >> below with a pre-June-2014 fastdebug build (when Reference started >> initializing InterruptedException) might trip the same assert. I'm >> presently trying to obtain a sufficiently old fastdebug build to run >> the experiment. > > Nope, works fine with JDK 9 b01. See my response to Mandy above. David ----- > ./jdk1.9.0/fastdebug/bin/java -XX:AutoBoxCacheMax=2147483647 -version > Error occurred during initialization of VM > java.lang.OutOfMemoryError: Requested array size exceeds VM limit > at java.lang.Integer$IntegerCache.(Integer.java:799) > at java.lang.Integer.valueOf(Integer.java:827) > at sun.misc.Signal.handle(Signal.java:169) > at java.lang.Terminator.setup(Terminator.java:60) > at java.lang.System.initializeSystemClass(System.java:1197) > From yasuenag at gmail.com Wed Jun 29 23:30:33 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 30 Jun 2016 08:30:33 +0900 Subject: [OpenJDK 2D-Dev] JDK 9 build with GCC 6.1.1 In-Reply-To: <5772B61E.7060606@oracle.com> References: <57F3A28D-6FFD-45D6-B85C-1B5638CE29F4@oracle.com> <5772B61E.7060606@oracle.com> Message-ID: <67542003-65a5-4791-dc27-e02f129a4d97@gmail.com> Hi Kim, Phil, Can I push this patch? It has been reviewed. http://cr.openjdk.java.net/~ysuenaga/JDK-8160294/webrev.01/ Thanks, Yasumasa On 2016/06/29 2:38, Phil Race wrote: > On 06/27/2016 08:50 PM, Yasumasa Suenaga wrote: >> Hi Kim, >> >> The newest changes for jdk repos is [1]. >> Erik points we should use DISABLED_WARNINGS_gcc to handle unknown warning tags. [2] >> [1] is implemented with it. >> >> This change is already reviewed by 2d folks. >> So I want to merge it ASAP. >> >> Do you have any objection? >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007090.html >> [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004499.html >> >> >> On 2016/06/28 8:37, Kim Barrett wrote: >>>> On Jun 25, 2016, at 9:57 AM, Yasumasa Suenaga wrote: >>>> >>>> Hi all, >>>> >>>> This review request relates to [1]. >>>> >>>> I've tried to build OpenJDK 9 at Fedora 24 x64. >>>> Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. >>>> >>>> I fixed build error and several issues (VM crash and internal error) as below: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ >>>> >>>> Does someone work for it? >>>> If no one works for it, I will file it to JBS and will send review request. >>>> >>>> For jdk repos, I've sent review request [2]. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html >>>> [2] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007081.html >>> >>> Having gone through these, I think all of them are arising due to >>> build system problems, where we seem to have lost the compiler >>> configuration to use explicit selection of the language standard and >>> some additional options. > > Do tell more about what this means. Where would this previously have been seen ? > Different versions of Visual Studio / CLANG / GCC all emit different warnings > and it is not always monotonically increasing with compiler version, and I > can imagine someone might want to have different sets of flags in general > depending on compiler version in use, but I have not seen a pattern of this > being applied to the warnings on any of the platforms. > > in the makefile here there is just one special case of this .. > > 474 # Suppress gcc warnings like "variable might be clobbered by 'longjmp' > 475 # or 'vfork'": this warning indicates that some variable is placed to > 476 # a register by optimized compiler and it's value might be lost on longjmp(). > 477 # Recommended way to avoid such warning is to declare the variable as > 478 # volatile to prevent the optimization. However, this approach does not > 479 # work because we have to declare all variables as volatile in result. > 480 #ifndef CROSS_COMPILE_ARCH > 481 # CC_43_OR_NEWER := \ > 482 # $(shell $(EXPR) $(CC_MAJORVER) \> 4 \| \ > 483 # \( $(CC_MAJORVER) = 4 \& $(CC_MINORVER) \>= 3 \) ) > 484 # ifeq ($(CC_43_OR_NEWER), 1) > 485 # BUILD_LIBJAVAJPEG_CFLAGS_linux += -Wno-clobbered > 486 # endif > 487 #endif > > >>> >>> For now I think we should fix the build system problems, and file >>> additional bugs or update existing ones as needed to fix the root >>> causes of the problems encountered. I think many of the proposed >>> changes do not address the root causes, and should not be made. See >>> my comments for the specific bugs. >>> >>> I'm not on the mailing list where the jdk RFR was submitted. I took a >>> look at them though, and >>> >>> ------------------------------------------------------------------------------ >>> make/lib/Awt2dLibraries.gmk >>> 407 # Avoid warning for GCC 6 >>> 408 ifeq ($(TOOLCHAIN_TYPE), gcc) >>> 409 LCMS_CFLAGS += -Wno-misleading-indentation >>> 410 endif >>> >>> 926 # Avoid warning for GCC 6 >>> 927 ifeq ($(TOOLCHAIN_TYPE), gcc) >>> 928 BUILD_LIBSPLASHSCREEN_jdhuff.c_CFLAGS += -Wno-shift-negative-value >>> 929 BUILD_LIBSPLASHSCREEN_jdphuff.c_CFLAGS += -Wno-shift-negative-value >>> 930 endif >>> >>> The -Wmisleading-indentation and -Wshift-negative-value options are >>> new in gcc 6. gcc has for some time (starting with gcc 4.4) silently >>> ignored unrecognized -Wno-XXX options. But some folks (like SAP) are >>> still using older versions. So these will need to be conditionalized >>> on the gcc version. >>> >>> ------------------------------------------------------------------------------ >>> src/java.desktop/share/native/libfontmanager/layout/SunLayoutEngine.cpp >>> 154 if (min < 0) min = 0; >>> 155 if (max < min) max = min; /* defensive coding */ >>> >>> [splitting the line] >>> >>> Seems like this would be suppressed by -Wno-misleading-indentation, >>> especially since the reported warning is for that. Why change both >>> the code and the build configuration? > > Was that something seen in the original fix ? It is not in the version I reviewed. > The current version of the fix does not update the makefile to add this > .. except for LCMS - which is a different library. > > > -phil. > >>> >>> ------------------------------------------------------------------------------ >>> >>> The changes in AlphaMath.c and splashscreen_jpeg.c look ok. >>> > From coleen.phillimore at oracle.com Thu Jun 30 00:15:51 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 29 Jun 2016 20:15:51 -0400 Subject: RFR 8160551: assert(c == Bytecodes::_putfield) failed: must be putfield In-Reply-To: <83f9e27f-d023-73ef-bc8a-aa51bca9ccd9@oracle.com> References: <48261FBA-4C7D-492D-A482-8CDC110962F7@oracle.com> <83f9e27f-d023-73ef-bc8a-aa51bca9ccd9@oracle.com> Message-ID: Under the trivial rules and because it's an integration blocker, I'm going to commit. jck tests passed. Thanks, Coleen On 6/29/16 5:28 PM, Coleen Phillimore wrote: > > > On 6/29/16 5:26 PM, John Rose wrote: >> Reviewed. >> >> One nit: To read the test case more easily, I would like to see the >> original source code for Bad, preferably commented out in the main >> test file like so: >> >> public class PutfieldError { >> ? >> } >> /* recoded in jasm: >> class Bad { >> public static final int i; //rewritten >> //rewritten to: public final int i; >> static { i = 5; } // putstatic instruction >> } >> */ > > Okay, will do. Having a side-by-side .java file sometimes causes > problems in jtreg so I'll add as a comment as you suggest. > > thanks! > Coleen > >> >> On Jun 29, 2016, at 2:13 PM, Coleen Phillimore >> wrote: >>> Summary: Illegal bytecodes which are detected later hit this assert >>> first. >>> >>> Removed the asserts in the new code in the rewriter, and added a >>> test that verifies that ICCE is thrown for the case in question. >>> >>> Tested in progress with jck tests. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8160551.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8160551 >>> >>> Zoltan: I borrowed your test directory name from your last review to >>> also include my test. >>> >>> Thanks, >>> Coleen > From serguei.spitsyn at oracle.com Thu Jun 30 00:21:46 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Jun 2016 17:21:46 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <4edd4611-6e6b-d61d-22c4-c099f02db2d8@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> <5772E79F.3040504@oracle.com> <57732DDF.4070904@oracle.com> <57738CA7.2080404@oracle.com> <4edd4611-6e6b-d61d-22c4-c099f02db2d8@oracle.com> Message-ID: <5774661A.3080500@oracle.com> Hi Dan, On 6/29/16 07:59, Daniel D. Daugherty wrote: > On 6/29/16 2:53 AM, serguei.spitsyn at oracle.com wrote: >> On 6/29/16 01:45, Jesper Wilhelmsson wrote: >>> 29 juni 2016 kl. 04:30 skrev David Holmes : >>>>> On 29/06/2016 12:09 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 6/28/16 18:44, David Holmes wrote: >>>>>>> On 29/06/2016 7:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>> On 6/28/16 14:02, Daniel D. Daugherty wrote: >>>>>>>>> On 6/28/16 2:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> On 6/28/16 11:19, Daniel D. Daugherty wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'll have to check the upper layers of this API, but >>>>>>>>>> if an >>>>>>>>>> agent can pass a bad 'class_loader' parameter and get >>>>>>>>>> this >>>>>>>>>> assert() to fire, then that's not good. Hopefully a bad >>>>>>>>>> 'class_loader' parameter is caught at a higher layer. >>>>>>>>> Not sure, what do you mean. >>>>>>>>> Do you mean the generated JVMTI upper layer or the >>>>>>>>> JvmtiEnv::GetNamedModule? >>>>>>>>> Probably, the generated code. >>>>>>>> I did mean the generated layer. >>>>>>> Ok, thanks. >>>>>>> >>>>>>>> >>>>>>>>>> Update: Yes, passing a non-NULL jobject as the >>>>>>>>>> class_loader >>>>>>>>>> parameter >>>>>>>>>> when the jobject does not refer to a "class >>>>>>>>>> loader" is >>>>>>>>>> caught >>>>>>>>>> at the upper layer. >>>>>>>>> The upper layer does not check that it is a class loader, just >>>>>>>>> for >>>>>>>>> non-NULL. >>>>>>>>> I think, it is good to have an assert here to double-checks the >>>>>>>>> pre-conditions as other caller can be added later. >>>>>>>>> But I'm Ok to get rid of it if you suggest. >>>>>>>> Please keep the asserts. Basically I was mumbling to myself to >>>>>>>> make sure that the asserts could not be reached by user code >>>>>>>> and the "Update:" was to indicate that I did do. >>>>>>> Ok, thanks. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>>> src/share/vm/prims/jvmti.xml >>>>>>>>>> L6550: >>>>>>>>>> L6551: >>>>>>>>>> L6552: >>>>>>>>>> L6553: On return, points to a >>>>>>>>>> java.lang.reflect.Module object. >>>>>>>>>> L6554: >>>>>>>>>> L6555: >>>>>>>>>> >>>>>>>>>> The above wording doesn't allow for module_ptr to be >>>>>>>>>> NULL >>>>>>>>>> which >>>>>>>>>> is a mismatch with the description. >>>>>>>>> I disagree (or maybe I got it incorrectly). >>>>>>>>> Pointing to NULL and be NULL is different. >>>>>>>>> It is not allowed for the module_ptr to be NULL but Ok to pint to >>>>>>>>> NULL on return. >>>>>>>> I think the description needs to be: >>>>>>>> >>>>>>>> On return, points to a >>>>>>>> java.lang.reflect.Module object >>>>>>>> or points to a NULL. >>>>>>> Agreed, fixed. >>>>>> Disagree. You would say that a pointer is NULL, not that it >>>>>> points to >>>>>> a NULL. >>>>> Why are you disagree? >>>>> The module_ptr is an out argument, it is not allowed to be NULL. >>>>> But the returning value by this pointer can be NULL. >>>> As per later email I see this terminology already exists so is >>>> fine, but I find it confusing to say "points to a NULL" - a NULL is >>>> not an entity. If "foo points to a NULL" that implies to me "foo == >>>> &NULL;" which is nonsense - foo == NULL, and if foo==NULL then foo >>>> points to nothing. But the "pointer to a pointer" aspect here does >>>> confuse things. >>> I would prefer if it said "points to a NULL pointer", or >>> NULL-pointer. I'm not sure what would be the more correct way to >>> write it. Anyway, a NULL pointer is an entity :-) >> Jesper, >> >> Thank you for the comment. >> In fact, I've just used a pattern that is already present in the >> JVMTI spec. >> Objections to the existing pattern are minor, so it is better to be >> more conservative here. > > Perhaps we can use the wording in this JVM/TI function as a model: > > http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#GetCurrentContendedMonitor > > > This function takes a "jobject *" as a parameter and returns a > monitor pointer via that parameter. Pretty similar to what we're > discussing... > > So here's the existing wording example: > > Name Type Description > =========== ======== =========== > monitor_ptr jobject* On return, filled with the current contended > monitor, > or NULL if there is none. > > Agent passes a pointer to a jobject. On return, > the > jobject has been set. The object returned by > monitor_ptr > is a JNI local reference and must be managed. > > So for the new function: > > module_ptr jobject* On return, filled with a > java.lang.reflect.Module > object or NULL if there is none. > > This "filled with" style is used for return parameters in > ~13 places in the JVM/TI spec. Thank you for pointing to the example. This discussion deviated to the question what the JVMTI pattern is better to copy as a best practice. > > Of course, now that I've found the GetCurrentContendedMonitor > example, That second paragraph or something like it is also > going to be needed with our new function... Just wanted to note that this paragraph is not strictly necessary as it is already covered in the common part of the spec: http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#refs However, the second sentence is auto-generated from the jvmti.xml: "Agent passes a pointer to a |jobject|. On return, the |jobject| has been set. The object returned by |module_ptr| is a JNI local reference and must be managed." Please, find the specdiff in the attachment. Thanks, Serguei > > Spec wording is very difficult... :-) > > Dan > > >> >> Thanks, >> Serguei >> >> >> >>> /Jesper >>> >>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>>> David >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Dan >> > From mandy.chung at oracle.com Thu Jun 30 00:32:08 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 29 Jun 2016 17:32:08 -0700 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <59522cd6-3823-bfa2-8785-bb472dd875ca@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <3f6719ad-95a3-12eb-572a-8c171306fc8d@oracle.com> <94572805-06D5-456B-B73E-70BBD642CA22@oracle.com> <59522cd6-3823-bfa2-8785-bb472dd875ca@oracle.com> Message-ID: <68FE13E8-532E-40A9-886D-2C40D25775DC@oracle.com> > On Jun 28, 2016, at 10:19 PM, David Holmes wrote: > > So here is what I see has happened. > > Looking back at 9-b01, before we forced the initialization of InterruptedException and thus Throwable we find: > > 58 Initializing 'java/lang/Throwable' (0x0000000800002990) > > So Kim is right this was working by accident. It just seems that back then there was less memory required by the initialization of all the collection and other classes and so we didn't run into this problem. > > Post the InterruptedException change the initialization order made it unlikely an OOME could be encountered before Throwable was initialized (and after we have reached a point where we can throw without the VM crashing or instead doing a vm_exit_during_initialization). > > Post modules those collection classes, and others, are now done earlier again and before Throwable. And presumably their memory demands have increased. > This is the new primordial class added by modules that causes additional classes to be loaded early before initPhase1. // The VM creates objects of this class. initialize_class(vmSymbols::java_lang_reflect_Module(), CHECK); > Although we preallocate the OutOfMemoryError instances, and avoid executing any java code to do so, we can't necessarily** "throw" them until after Throwable is initialized. We now have a lot more initialization occurring before we init Throwable and so OOME is more likely and so it will fail as Kim observed. Would initializing java.lang.Throwable after java.lang.reflect.Module address this issue? I don?t think I fully follow the problem Kim observed and below. > > ** I say necessarily because I still believe it is the fact we attempt to fill in the stacktrace that leads to the dependency on Throwable being initialized, and we should be able to avoid that if we check the VM initialization state in gen_out_of_memory_error(). Mandy From philip.race at oracle.com Thu Jun 30 00:44:29 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 29 Jun 2016 17:44:29 -0700 Subject: [OpenJDK 2D-Dev] JDK 9 build with GCC 6.1.1 In-Reply-To: <67542003-65a5-4791-dc27-e02f129a4d97@gmail.com> References: <57F3A28D-6FFD-45D6-B85C-1B5638CE29F4@oracle.com> <5772B61E.7060606@oracle.com> <67542003-65a5-4791-dc27-e02f129a4d97@gmail.com> Message-ID: <57746B6D.5030405@oracle.com> Hi, Not just yet. Whilst I am OK with it ... 1) We like 2 (two) reviewers to approve. 2) I would like Kim to reply to the questions so I understand his concerns first. -phil. On 6/29/16, 4:30 PM, Yasumasa Suenaga wrote: > Hi Kim, Phil, > > Can I push this patch? > It has been reviewed. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8160294/webrev.01/ > > > Thanks, > > Yasumasa > > > On 2016/06/29 2:38, Phil Race wrote: >> On 06/27/2016 08:50 PM, Yasumasa Suenaga wrote: >>> Hi Kim, >>> >>> The newest changes for jdk repos is [1]. >>> Erik points we should use DISABLED_WARNINGS_gcc to handle unknown >>> warning tags. [2] >>> [1] is implemented with it. >>> >>> This change is already reviewed by 2d folks. >>> So I want to merge it ASAP. >>> >>> Do you have any objection? >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007090.html >>> [2] >>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004499.html >>> >>> >>> On 2016/06/28 8:37, Kim Barrett wrote: >>>>> On Jun 25, 2016, at 9:57 AM, Yasumasa Suenaga >>>>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> This review request relates to [1]. >>>>> >>>>> I've tried to build OpenJDK 9 at Fedora 24 x64. >>>>> Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed. >>>>> >>>>> I fixed build error and several issues (VM crash and internal >>>>> error) as below: >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/ >>>>> >>>>> Does someone work for it? >>>>> If no one works for it, I will file it to JBS and will send review >>>>> request. >>>>> >>>>> For jdk repos, I've sent review request [2]. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] >>>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html >>>>> [2] >>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007081.html >>>> >>>> Having gone through these, I think all of them are arising due to >>>> build system problems, where we seem to have lost the compiler >>>> configuration to use explicit selection of the language standard and >>>> some additional options. >> >> Do tell more about what this means. Where would this previously have >> been seen ? >> Different versions of Visual Studio / CLANG / GCC all emit different >> warnings >> and it is not always monotonically increasing with compiler version, >> and I >> can imagine someone might want to have different sets of flags in >> general >> depending on compiler version in use, but I have not seen a pattern >> of this >> being applied to the warnings on any of the platforms. >> >> in the makefile here there is just one special case of this .. >> >> 474 # Suppress gcc warnings like "variable might be clobbered by >> 'longjmp' >> 475 # or 'vfork'": this warning indicates that some variable is >> placed to >> 476 # a register by optimized compiler and it's value might be lost >> on longjmp(). >> 477 # Recommended way to avoid such warning is to declare the >> variable as >> 478 # volatile to prevent the optimization. However, this approach >> does not >> 479 # work because we have to declare all variables as volatile in >> result. >> 480 #ifndef CROSS_COMPILE_ARCH >> 481 # CC_43_OR_NEWER := \ >> 482 # $(shell $(EXPR) $(CC_MAJORVER) \> 4 \| \ >> 483 # \( $(CC_MAJORVER) = 4 \& $(CC_MINORVER) \>= 3 \) ) >> 484 # ifeq ($(CC_43_OR_NEWER), 1) >> 485 # BUILD_LIBJAVAJPEG_CFLAGS_linux += -Wno-clobbered >> 486 # endif >> 487 #endif >> >> >>>> >>>> For now I think we should fix the build system problems, and file >>>> additional bugs or update existing ones as needed to fix the root >>>> causes of the problems encountered. I think many of the proposed >>>> changes do not address the root causes, and should not be made. See >>>> my comments for the specific bugs. >>>> >>>> I'm not on the mailing list where the jdk RFR was submitted. I took a >>>> look at them though, and >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> make/lib/Awt2dLibraries.gmk >>>> 407 # Avoid warning for GCC 6 >>>> 408 ifeq ($(TOOLCHAIN_TYPE), gcc) >>>> 409 LCMS_CFLAGS += -Wno-misleading-indentation >>>> 410 endif >>>> >>>> 926 # Avoid warning for GCC 6 >>>> 927 ifeq ($(TOOLCHAIN_TYPE), gcc) >>>> 928 BUILD_LIBSPLASHSCREEN_jdhuff.c_CFLAGS += >>>> -Wno-shift-negative-value >>>> 929 BUILD_LIBSPLASHSCREEN_jdphuff.c_CFLAGS += >>>> -Wno-shift-negative-value >>>> 930 endif >>>> >>>> The -Wmisleading-indentation and -Wshift-negative-value options are >>>> new in gcc 6. gcc has for some time (starting with gcc 4.4) silently >>>> ignored unrecognized -Wno-XXX options. But some folks (like SAP) are >>>> still using older versions. So these will need to be conditionalized >>>> on the gcc version. >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> src/java.desktop/share/native/libfontmanager/layout/SunLayoutEngine.cpp >>>> >>>> 154 if (min < 0) min = 0; >>>> 155 if (max < min) max = min; /* defensive coding */ >>>> >>>> [splitting the line] >>>> >>>> Seems like this would be suppressed by -Wno-misleading-indentation, >>>> especially since the reported warning is for that. Why change both >>>> the code and the build configuration? >> >> Was that something seen in the original fix ? It is not in the >> version I reviewed. >> The current version of the fix does not update the makefile to add this >> .. except for LCMS - which is a different library. >> >> >> -phil. >> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> The changes in AlphaMath.c and splashscreen_jpeg.c look ok. >>>> >> From david.holmes at oracle.com Thu Jun 30 01:42:59 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Jun 2016 11:42:59 +1000 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <68FE13E8-532E-40A9-886D-2C40D25775DC@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <3f6719ad-95a3-12eb-572a-8c171306fc8d@oracle.com> <94572805-06D5-456B-B73E-70BBD642CA22@oracle.com> <59522cd6-3823-bfa2-8785-bb472dd875ca@oracle.com> <68FE13E8-532E-40A9-886D-2C40D25775DC@oracle.com> Message-ID: <22d31b42-df55-1d7e-ca95-9d22d86bcd21@oracle.com> On 30/06/2016 10:32 AM, Mandy Chung wrote: > >> On Jun 28, 2016, at 10:19 PM, David Holmes wrote: >> >> So here is what I see has happened. >> >> Looking back at 9-b01, before we forced the initialization of InterruptedException and thus Throwable we find: >> >> 58 Initializing 'java/lang/Throwable' (0x0000000800002990) >> >> So Kim is right this was working by accident. It just seems that back then there was less memory required by the initialization of all the collection and other classes and so we didn't run into this problem. >> >> Post the InterruptedException change the initialization order made it unlikely an OOME could be encountered before Throwable was initialized (and after we have reached a point where we can throw without the VM crashing or instead doing a vm_exit_during_initialization). >> >> Post modules those collection classes, and others, are now done earlier again and before Throwable. And presumably their memory demands have increased. >> > > This is the new primordial class added by modules that causes additional classes to be loaded early before initPhase1. > > // The VM creates objects of this class. > initialize_class(vmSymbols::java_lang_reflect_Module(), CHECK); > >> Although we preallocate the OutOfMemoryError instances, and avoid executing any java code to do so, we can't necessarily** "throw" them until after Throwable is initialized. We now have a lot more initialization occurring before we init Throwable and so OOME is more likely and so it will fail as Kim observed. > > > Would initializing java.lang.Throwable after java.lang.reflect.Module address this issue? I don?t think I fully follow the problem Kim observed and below. The earlier you initialize Throwable the earlier you can try to create an exception that has a backtrace. But there will always be a region of code where we can't throw an OOME with a backtrace because of the missing initialization of Throwable. So we can narrow that window by moving the initialization of Throwable (which in turn requires a whole bunch of collection classes - so the window has a fixed minimum size [ unless we do some creative restructuring of Throwable's static initialization]). My argument, which I think I've now convinced Kim of, is that we shouldn't be trying to throw an OOME with a stacktrace if Throwable has not been initialized - and that is where the change to gen_out_of_memory_error comes in. It is actually passed the pre-allocated OOME that has no backtrace and will never have a backtrace, and that is what should be thrown when Throwable has not been initialized. Cheers, David >> >> ** I say necessarily because I still believe it is the fact we attempt to fill in the stacktrace that leads to the dependency on Throwable being initialized, and we should be able to avoid that if we check the VM initialization state in gen_out_of_memory_error(). > > Mandy > From mandy.chung at oracle.com Thu Jun 30 02:02:15 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 29 Jun 2016 19:02:15 -0700 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <22d31b42-df55-1d7e-ca95-9d22d86bcd21@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <3f6719ad-95a3-12eb-572a-8c171306fc8d@oracle.com> <94572805-06D5-456B-B73E-70BBD642CA22@oracle.com> <59522cd6-3823-bfa2-8785-bb472dd875ca@oracle.com> <68FE13E8-532E-40A9-886D-2C40D25775DC@oracle.com> <22d31b42-df55-1d7e-ca95-9d22d86bcd21@oracle.com> Message-ID: <9DF9FAD2-681A-4ACA-B36D-072DEF6E5C9B@oracle.com> > On Jun 29, 2016, at 6:42 PM, David Holmes wrote: > > The earlier you initialize Throwable the earlier you can try to create an exception that has a backtrace. But there will always be a region of code where we can't throw an OOME with a backtrace because of the missing initialization of Throwable. So we can narrow that window by moving the initialization of Throwable (which in turn requires a whole bunch of collection classes - so the window has a fixed minimum size [ unless we do some creative restructuring of Throwable's static initialization]). My argument, which I think I've now convinced Kim of, is that we shouldn't be trying to throw an OOME with a stacktrace if Throwable has not been initialized - and that is where the change to gen_out_of_memory_error comes in. It is actually passed the pre-allocated OOME that has no backtrace and will never have a backtrace, and that is what should be thrown when Throwable has not been initialized. Thanks for the clarification. It makes sense and the pre-allocated OOME with no backtrace should be used for this early OOM scenario. Mandy From daniel.daugherty at oracle.com Thu Jun 30 02:07:03 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 29 Jun 2016 20:07:03 -0600 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <5774661A.3080500@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> <5772E79F.3040504@oracle.com> <57732DDF.4070904@oracle.com> <57738CA7.2080404@oracle.com> <4edd4611-6e6b-d61d-22c4-c099f02db2d8@oracle.com> <5774661A.3080500@oracle.com> Message-ID: <263e1aac-5876-111b-0ee8-7ea5a3f9d883@oracle.com> On 6/29/16 6:21 PM, serguei.spitsyn at oracle.com wrote: > Hi Dan, > > On 6/29/16 07:59, Daniel D. Daugherty wrote: >> On 6/29/16 2:53 AM, serguei.spitsyn at oracle.com wrote: >>> On 6/29/16 01:45, Jesper Wilhelmsson wrote: >>>> 29 juni 2016 kl. 04:30 skrev David Holmes : >>>>>> On 29/06/2016 12:09 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> On 6/28/16 18:44, David Holmes wrote: >>>>>>>> On 29/06/2016 7:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> On 6/28/16 14:02, Daniel D. Daugherty wrote: >>>>>>>>>> On 6/28/16 2:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> On 6/28/16 11:19, Daniel D. Daugherty wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I'll have to check the upper layers of this API, but >>>>>>>>>>> if an >>>>>>>>>>> agent can pass a bad 'class_loader' parameter and >>>>>>>>>>> get this >>>>>>>>>>> assert() to fire, then that's not good. Hopefully a bad >>>>>>>>>>> 'class_loader' parameter is caught at a higher layer. >>>>>>>>>> Not sure, what do you mean. >>>>>>>>>> Do you mean the generated JVMTI upper layer or the >>>>>>>>>> JvmtiEnv::GetNamedModule? >>>>>>>>>> Probably, the generated code. >>>>>>>>> I did mean the generated layer. >>>>>>>> Ok, thanks. >>>>>>>> >>>>>>>>> >>>>>>>>>>> Update: Yes, passing a non-NULL jobject as the >>>>>>>>>>> class_loader >>>>>>>>>>> parameter >>>>>>>>>>> when the jobject does not refer to a "class >>>>>>>>>>> loader" is >>>>>>>>>>> caught >>>>>>>>>>> at the upper layer. >>>>>>>>>> The upper layer does not check that it is a class loader, >>>>>>>>>> just for >>>>>>>>>> non-NULL. >>>>>>>>>> I think, it is good to have an assert here to double-checks the >>>>>>>>>> pre-conditions as other caller can be added later. >>>>>>>>>> But I'm Ok to get rid of it if you suggest. >>>>>>>>> Please keep the asserts. Basically I was mumbling to myself to >>>>>>>>> make sure that the asserts could not be reached by user code >>>>>>>>> and the "Update:" was to indicate that I did do. >>>>>>>> Ok, thanks. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>>> src/share/vm/prims/jvmti.xml >>>>>>>>>>> L6550: >>>>>>>>>>> L6551: >>>>>>>>>>> L6552: >>>>>>>>>>> L6553: On return, points to a >>>>>>>>>>> java.lang.reflect.Module object. >>>>>>>>>>> L6554: >>>>>>>>>>> L6555: >>>>>>>>>>> >>>>>>>>>>> The above wording doesn't allow for module_ptr to be >>>>>>>>>>> NULL >>>>>>>>>>> which >>>>>>>>>>> is a mismatch with the description. >>>>>>>>>> I disagree (or maybe I got it incorrectly). >>>>>>>>>> Pointing to NULL and be NULL is different. >>>>>>>>>> It is not allowed for the module_ptr to be NULL but Ok to >>>>>>>>>> pint to >>>>>>>>>> NULL on return. >>>>>>>>> I think the description needs to be: >>>>>>>>> >>>>>>>>> On return, points to a >>>>>>>>> java.lang.reflect.Module object >>>>>>>>> or points to a NULL. >>>>>>>> Agreed, fixed. >>>>>>> Disagree. You would say that a pointer is NULL, not that it >>>>>>> points to >>>>>>> a NULL. >>>>>> Why are you disagree? >>>>>> The module_ptr is an out argument, it is not allowed to be NULL. >>>>>> But the returning value by this pointer can be NULL. >>>>> As per later email I see this terminology already exists so is >>>>> fine, but I find it confusing to say "points to a NULL" - a NULL >>>>> is not an entity. If "foo points to a NULL" that implies to me >>>>> "foo == &NULL;" which is nonsense - foo == NULL, and if foo==NULL >>>>> then foo points to nothing. But the "pointer to a pointer" aspect >>>>> here does confuse things. >>>> I would prefer if it said "points to a NULL pointer", or >>>> NULL-pointer. I'm not sure what would be the more correct way to >>>> write it. Anyway, a NULL pointer is an entity :-) >>> Jesper, >>> >>> Thank you for the comment. >>> In fact, I've just used a pattern that is already present in the >>> JVMTI spec. >>> Objections to the existing pattern are minor, so it is better to be >>> more conservative here. >> >> Perhaps we can use the wording in this JVM/TI function as a model: >> >> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#GetCurrentContendedMonitor >> >> >> This function takes a "jobject *" as a parameter and returns a >> monitor pointer via that parameter. Pretty similar to what we're >> discussing... >> >> So here's the existing wording example: >> >> Name Type Description >> =========== ======== =========== >> monitor_ptr jobject* On return, filled with the current contended >> monitor, >> or NULL if there is none. >> >> Agent passes a pointer to a jobject. On >> return, the >> jobject has been set. The object returned by >> monitor_ptr >> is a JNI local reference and must be managed. >> >> So for the new function: >> >> module_ptr jobject* On return, filled with a >> java.lang.reflect.Module >> object or NULL if there is none. >> >> This "filled with" style is used for return parameters in >> ~13 places in the JVM/TI spec. > > Thank you for pointing to the example. > This discussion deviated to the question what the JVMTI pattern is > better to copy as a best practice. > > >> >> Of course, now that I've found the GetCurrentContendedMonitor >> example, That second paragraph or something like it is also >> going to be needed with our new function... > > Just wanted to note that this paragraph is not strictly necessary as > it is already covered in the common part of the spec: > http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#refs > > However, the second sentence is auto-generated from the jvmti.xml: > "Agent passes a pointer to a |jobject|. On return, the |jobject| > has been set. > The object returned by |module_ptr| is a JNI local reference and must > be managed." > > Please, find the specdiff in the attachment. The specdiff looks good. There is one strange sentence: > If class_loader is NULL, the bootstrap loader. Perhaps "the bootstrap loader is assumed."? Your call. Dan > > Thanks, > Serguei > >> >> Spec wording is very difficult... :-) >> >> Dan >> >> >>> >>> Thanks, >>> Serguei >>> >>> >>> >>>> /Jesper >>>> >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>>> David >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Dan >>> >> > From serguei.spitsyn at oracle.com Thu Jun 30 03:34:09 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Jun 2016 20:34:09 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <263e1aac-5876-111b-0ee8-7ea5a3f9d883@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> <5772E79F.3040504@oracle.com> <57732DDF.4070904@oracle.com> <57738CA7.2080404@oracle.com> <4edd4611-6e6b-d61d-22c4-c099f02db2d8@oracle.com> <5774661A.3080500@oracle.com> <263e1aac-5876-111b-0ee8-7ea5a3f9d883@oracle.com> Message-ID: <57749331.2030701@oracle.com> On 6/29/16 19:07, Daniel D. Daugherty wrote: > On 6/29/16 6:21 PM, serguei.spitsyn at oracle.com wrote: >> Hi Dan, >> >> On 6/29/16 07:59, Daniel D. Daugherty wrote: >>> On 6/29/16 2:53 AM, serguei.spitsyn at oracle.com wrote: >>>> On 6/29/16 01:45, Jesper Wilhelmsson wrote: >>>>> 29 juni 2016 kl. 04:30 skrev David Holmes : >>>>>>> On 29/06/2016 12:09 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> On 6/28/16 18:44, David Holmes wrote: >>>>>>>>> On 29/06/2016 7:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> On 6/28/16 14:02, Daniel D. Daugherty wrote: >>>>>>>>>>> On 6/28/16 2:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>> On 6/28/16 11:19, Daniel D. Daugherty wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I'll have to check the upper layers of this API, >>>>>>>>>>>> but if an >>>>>>>>>>>> agent can pass a bad 'class_loader' parameter and >>>>>>>>>>>> get this >>>>>>>>>>>> assert() to fire, then that's not good. Hopefully a >>>>>>>>>>>> bad >>>>>>>>>>>> 'class_loader' parameter is caught at a higher layer. >>>>>>>>>>> Not sure, what do you mean. >>>>>>>>>>> Do you mean the generated JVMTI upper layer or the >>>>>>>>>>> JvmtiEnv::GetNamedModule? >>>>>>>>>>> Probably, the generated code. >>>>>>>>>> I did mean the generated layer. >>>>>>>>> Ok, thanks. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> Update: Yes, passing a non-NULL jobject as the >>>>>>>>>>>> class_loader >>>>>>>>>>>> parameter >>>>>>>>>>>> when the jobject does not refer to a "class >>>>>>>>>>>> loader" is >>>>>>>>>>>> caught >>>>>>>>>>>> at the upper layer. >>>>>>>>>>> The upper layer does not check that it is a class loader, >>>>>>>>>>> just for >>>>>>>>>>> non-NULL. >>>>>>>>>>> I think, it is good to have an assert here to double-checks the >>>>>>>>>>> pre-conditions as other caller can be added later. >>>>>>>>>>> But I'm Ok to get rid of it if you suggest. >>>>>>>>>> Please keep the asserts. Basically I was mumbling to myself to >>>>>>>>>> make sure that the asserts could not be reached by user code >>>>>>>>>> and the "Update:" was to indicate that I did do. >>>>>>>>> Ok, thanks. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> src/share/vm/prims/jvmti.xml >>>>>>>>>>>> L6550: >>>>>>>>>>>> L6551: >>>>>>>>>>>> L6552: >>>>>>>>>>>> L6553: On return, points to a >>>>>>>>>>>> java.lang.reflect.Module object. >>>>>>>>>>>> L6554: >>>>>>>>>>>> L6555: >>>>>>>>>>>> >>>>>>>>>>>> The above wording doesn't allow for module_ptr to >>>>>>>>>>>> be NULL >>>>>>>>>>>> which >>>>>>>>>>>> is a mismatch with the description. >>>>>>>>>>> I disagree (or maybe I got it incorrectly). >>>>>>>>>>> Pointing to NULL and be NULL is different. >>>>>>>>>>> It is not allowed for the module_ptr to be NULL but Ok to >>>>>>>>>>> pint to >>>>>>>>>>> NULL on return. >>>>>>>>>> I think the description needs to be: >>>>>>>>>> >>>>>>>>>> On return, points to a >>>>>>>>>> java.lang.reflect.Module object >>>>>>>>>> or points to a NULL. >>>>>>>>> Agreed, fixed. >>>>>>>> Disagree. You would say that a pointer is NULL, not that it >>>>>>>> points to >>>>>>>> a NULL. >>>>>>> Why are you disagree? >>>>>>> The module_ptr is an out argument, it is not allowed to be NULL. >>>>>>> But the returning value by this pointer can be NULL. >>>>>> As per later email I see this terminology already exists so is >>>>>> fine, but I find it confusing to say "points to a NULL" - a NULL >>>>>> is not an entity. If "foo points to a NULL" that implies to me >>>>>> "foo == &NULL;" which is nonsense - foo == NULL, and if foo==NULL >>>>>> then foo points to nothing. But the "pointer to a pointer" aspect >>>>>> here does confuse things. >>>>> I would prefer if it said "points to a NULL pointer", or >>>>> NULL-pointer. I'm not sure what would be the more correct way to >>>>> write it. Anyway, a NULL pointer is an entity :-) >>>> Jesper, >>>> >>>> Thank you for the comment. >>>> In fact, I've just used a pattern that is already present in the >>>> JVMTI spec. >>>> Objections to the existing pattern are minor, so it is better to be >>>> more conservative here. >>> >>> Perhaps we can use the wording in this JVM/TI function as a model: >>> >>> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#GetCurrentContendedMonitor >>> >>> >>> This function takes a "jobject *" as a parameter and returns a >>> monitor pointer via that parameter. Pretty similar to what we're >>> discussing... >>> >>> So here's the existing wording example: >>> >>> Name Type Description >>> =========== ======== =========== >>> monitor_ptr jobject* On return, filled with the current contended >>> monitor, >>> or NULL if there is none. >>> >>> Agent passes a pointer to a jobject. On >>> return, the >>> jobject has been set. The object returned by >>> monitor_ptr >>> is a JNI local reference and must be managed. >>> >>> So for the new function: >>> >>> module_ptr jobject* On return, filled with a >>> java.lang.reflect.Module >>> object or NULL if there is none. >>> >>> This "filled with" style is used for return parameters in >>> ~13 places in the JVM/TI spec. >> >> Thank you for pointing to the example. >> This discussion deviated to the question what the JVMTI pattern is >> better to copy as a best practice. >> >> >>> >>> Of course, now that I've found the GetCurrentContendedMonitor >>> example, That second paragraph or something like it is also >>> going to be needed with our new function... >> >> Just wanted to note that this paragraph is not strictly necessary as >> it is already covered in the common part of the spec: >> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#refs >> >> However, the second sentence is auto-generated from the jvmti.xml: >> "Agent passes a pointer to a |jobject|. On return, the |jobject| >> has been set. >> The object returned by |module_ptr| is a JNI local reference and must >> be managed." >> >> Please, find the specdiff in the attachment. > > The specdiff looks good. > > There is one strange sentence: > > > If class_loader is NULL, the bootstrap loader. > > Perhaps "the bootstrap loader is assumed."? > > Your call. Interesting that a part of this sentence is auto-generated. Fixed it, thanks! Thanks, Serguei > > Dan > >> >> Thanks, >> Serguei >> >>> >>> Spec wording is very difficult... :-) >>> >>> Dan >>> >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>>> /Jesper >>>>> >>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Dan >>>> >>> >> > From zoltan.majo at oracle.com Thu Jun 30 07:42:40 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 30 Jun 2016 09:42:40 +0200 Subject: RFR 8160551: assert(c == Bytecodes::_putfield) failed: must be putfield In-Reply-To: References: Message-ID: <5774CD70.5090105@oracle.com> Hi Coleen, thank you for taking care of this issue! On 06/29/2016 11:13 PM, Coleen Phillimore wrote: > Summary: Illegal bytecodes which are detected later hit this assert > first. > > Removed the asserts in the new code in the rewriter, and added a test > that verifies that ICCE is thrown for the case in question. > > Tested in progress with jck tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8160551.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8160551 > > Zoltan: I borrowed your test directory name from your last review to > also include my test. Thank you for letting me know. I'll take that into consideration when sending out the updated webrev for 8160527. Best regards, Zoltan > > Thanks, > Coleen From edward.nevill at gmail.com Thu Jun 30 12:56:16 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 30 Jun 2016 13:56:16 +0100 Subject: RFD: C2 bug: 8157306 random infrequent null pointer exceptions in javac In-Reply-To: <576AD768.3070005@redhat.com> References: <576AD768.3070005@redhat.com> Message-ID: <1467291376.6034.12.camel@gmail.com> Hi Andrew, On Wed, 2016-06-22 at 19:22 +0100, Andrew Haley wrote: > This bogus NullPointerException happens because nodes are cloned from > a block into its successors by PhaseCFG::call_catch_cleanup.??When the > clone is performed we don't do an anti-dependence check, so scheduling > is free to move a store even above a load which has an anti-dependence. Well done on finding this! We had previously disabled the use of FP as an allocatable register because we thought this was the cause of the problem. The problem seemed to start happening with the introduction of FP as an allocatable register.w See the following JBS/change https://bugs.openjdk.java.net/browse/JDK-8148240 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ec13f1d4a9d3 However, it looks like this was just shifting the furniture around and made the problem go away for it to reappear later. Could we re-introduce the use of FP as an allocatable register now? All the best, Ed. From aph at redhat.com Thu Jun 30 13:39:44 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 30 Jun 2016 14:39:44 +0100 Subject: RFD: C2 bug: 8157306 random infrequent null pointer exceptions in javac In-Reply-To: <1467291376.6034.12.camel@gmail.com> References: <576AD768.3070005@redhat.com> <1467291376.6034.12.camel@gmail.com> Message-ID: <57752120.6000802@redhat.com> On 30/06/16 13:56, Edward Nevill wrote: > Could we re-introduce the use of FP as an allocatable register now? JDK 10. Andrew. From boris.molodenkov at oracle.com Thu Jun 30 16:40:44 2016 From: boris.molodenkov at oracle.com (Boris Molodenkov) Date: Thu, 30 Jun 2016 19:40:44 +0300 Subject: RFR(XS): 8160119: Utils.tryFindJvmPid sometimes find incorrect pid Message-ID: <57754B8C.5040801@oracle.com> Hi All, Could you please review fix? Utils.tryFindJvmPid incorrectly determines process id from jcmd output if line which contains desired PID is just after line which ends with numbers. Fixed pattern. JBS: https://bugs.openjdk.java.net/browse/JDK-8160119 Webrev: http://cr.openjdk.java.net/~bmoloden/8160119/webrev.00 Thanks, Boris From coleen.phillimore at oracle.com Thu Jun 30 19:27:39 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 30 Jun 2016 15:27:39 -0400 Subject: RFR 8160551: assert(c == Bytecodes::_putfield) failed: must be putfield In-Reply-To: <5774CD70.5090105@oracle.com> References: <5774CD70.5090105@oracle.com> Message-ID: <4125b3cf-d410-fcaa-1069-7e0774988db4@oracle.com> On 6/30/16 3:42 AM, Zolt?n Maj? wrote: > Hi Coleen, > > > thank you for taking care of this issue! You're welcome - I'd figured it passed your timezone and had a sense of urgency, was a simple fix and was fun to write the test case. Coleen > > On 06/29/2016 11:13 PM, Coleen Phillimore wrote: >> Summary: Illegal bytecodes which are detected later hit this assert >> first. >> >> Removed the asserts in the new code in the rewriter, and added a test >> that verifies that ICCE is thrown for the case in question. >> >> Tested in progress with jck tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8160551.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8160551 >> >> Zoltan: I borrowed your test directory name from your last review to >> also include my test. > > Thank you for letting me know. I'll take that into consideration when > sending out the updated webrev for 8160527. > > Best regards, > > > Zoltan > >> >> Thanks, >> Coleen >