From david.holmes at oracle.com Mon Jan 1 07:48:36 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 1 Jan 2018 17:48:36 +1000 Subject: [patch] support zhaoxin x86 cpu vendor ids CentaurHauls and Shanghai In-Reply-To: References: Message-ID: <9fa3cca9-4032-8b08-b36a-be8e2ebcc6e5@oracle.com> Hi Vic, Have you, or your company signed the OCA? [1] Unfortunately there seems to be a problem accessing the signatory list at the moment so I can't check myself. Thanks, David [1] http://openjdk.java.net/contribute/ On 28/12/2017 4:59 PM, Vic Wang(BJ-RD) wrote: > Hi, > Here is a hotspot patch for supporting zhaoxin x86 cpu vendor ids (CentaurHauls id and Shanghai id). The original repository is http://hg.openjdk.java.net/jdk/hs. > Please help me to submit the changes . If there is anything incorrectly, please let me know. Thank you very much. > > The following is the changeset by the diff command. > > diff -Nur org/jdk/src/hotspot/cpu/x86/assembler_x86.cpp zx/jdk/src/hotspot/cpu/x86/assembler_x86.cpp > --- org/jdk/src/hotspot/cpu/x86/assembler_x86.cpp2017-12-08 03:33:00.000000000 +0800 > +++ zx/jdk/src/hotspot/cpu/x86/assembler_x86.cpp2017-12-28 11:31:30.000000000 +0800 > @@ -3167,6 +3167,89 @@ > return; > } > > + if (UseAddressNop && VM_Version::is_zx()) { > + // > + // Using multi-bytes nops "0x0F 0x1F [address]" for ZX > + // 1: 0x90 > + // 2: 0x66 0x90 > + // 3: 0x66 0x66 0x90 (don't use "0x0F 0x1F 0x00" - need patching safe padding) > + // 4: 0x0F 0x1F 0x40 0x00 > + // 5: 0x0F 0x1F 0x44 0x00 0x00 > + // 6: 0x66 0x0F 0x1F 0x44 0x00 0x00 > + // 7: 0x0F 0x1F 0x80 0x00 0x00 0x00 0x00 > + // 8: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > + // 9: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > + // 10: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > + // 11: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > + > + // The rest coding is ZX specific - don't use consecutive address nops > + > + // 12: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 > + // 13: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 > + // 14: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 > + // 15: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 > + > + while(i >= 15) { > + // For ZX don't generate consecutive addess nops (mix with regular nops) > + i -= 15; > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + addr_nop_8(); > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8((unsigned char)0x90); > + // nop > + } > + switch (i) { > + case 14: > + emit_int8(0x66); // size prefix > + case 13: > + emit_int8(0x66); // size prefix > + case 12: > + addr_nop_8(); > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8((unsigned char)0x90); > + // nop > + break; > + case 11: > + emit_int8(0x66); // size prefix > + case 10: > + emit_int8(0x66); // size prefix > + case 9: > + emit_int8(0x66); // size prefix > + case 8: > + addr_nop_8(); > + break; > + case 7: > + addr_nop_7(); > + break; > + case 6: > + emit_int8(0x66); // size prefix > + case 5: > + addr_nop_5(); > + break; > + case 4: > + addr_nop_4(); > + break; > + case 3: > + // Don't use "0x0F 0x1F 0x00" - need patching safe padding > + emit_int8(0x66); // size prefix > + case 2: > + emit_int8(0x66); // size prefix > + case 1: > + emit_int8((unsigned char)0x90); > + // nop > + break; > + default: > + assert(i == 0, " "); > + } > + return; > + } > + > // Using nops with size prefixes "0x66 0x90". > // From AMD Optimization Guide: > // 1: 0x90 > diff -Nur org/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp zx/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp > --- org/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp2017-12-08 03:33:00.000000000 +0800 > +++ zx/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp2017-12-28 11:30:40.000000000 +0800 > @@ -628,6 +628,11 @@ > if (UseSSE < 1) > _features &= ~CPU_SSE; > > + //since AVX instructions is slower than SSE in some ZX cpus, force USEAVX=0. > + if(is_zx() && ((cpu_family()==6)||(cpu_family()==7))){ > +UseAVX = 0; > + } > + > // first try initial setting and detect what we can support > int use_avx_limit = 0; > if (UseAVX > 0) { > @@ -1078,6 +1083,66 @@ > // UseXmmRegToRegMoveAll == true --> movaps(xmm, xmm), movapd(xmm, xmm). > // UseXmmRegToRegMoveAll == false --> movss(xmm, xmm), movsd(xmm, xmm). > > + > + if( is_zx() ) { // ZX cpus specific settings > + if( FLAG_IS_DEFAULT(UseStoreImmI16) ) { > + UseStoreImmI16 = false; // don't use it on ZX cpus > + } > + if( (cpu_family() == 6)|| (cpu_family() == 7) ) { > + if( FLAG_IS_DEFAULT(UseAddressNop) ) { > + // Use it on all ZX cpus > + UseAddressNop = true; > + } > + } > + if( FLAG_IS_DEFAULT(UseXmmLoadAndClearUpper) ) { > + UseXmmLoadAndClearUpper = true; // use movsd on all ZX cpus > + } > + if( FLAG_IS_DEFAULT(UseXmmRegToRegMoveAll) ) { > + if( supports_sse3() ) { > + UseXmmRegToRegMoveAll = true; // use movaps, movapd on new ZX cpus > + } else { > + UseXmmRegToRegMoveAll = false; > + } > + } > + if( ((cpu_family() == 6)||(cpu_family() == 7)) && supports_sse3() ) { // new ZX cpus > +#ifdef COMPILER2 > + if( FLAG_IS_DEFAULT(MaxLoopPad) ) { > + // For new ZX cpus do the next optimization: > + // don't align the beginning of a loop if there are enough instructions > + // left (NumberOfLoopInstrToAlign defined in c2_globals.hpp) > + // in current fetch line (OptoLoopAlignment) or the padding > + // is big (> MaxLoopPad). > + // Set MaxLoopPad to 11 for new ZX cpus to reduce number of > + // generated NOP instructions. 11 is the largest size of one > + // address NOP instruction '0F 1F' (see Assembler::nop(i)). > + MaxLoopPad = 11; > + } > +#endif // COMPILER2 > + if (FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { > + UseXMMForArrayCopy = true; // use SSE2 movq on new ZX cpus > + } > + if (supports_sse4_2()) { // new ZX cpus > + if (FLAG_IS_DEFAULT(UseUnalignedLoadStores)) { > + UseUnalignedLoadStores = true; // use movdqu on newest ZX cpus > + } > + } > + if (supports_sse4_2()) { > + if (FLAG_IS_DEFAULT(UseSSE42Intrinsics)) { > + FLAG_SET_DEFAULT(UseSSE42Intrinsics, true); > + } > + } else { > + if (UseSSE42Intrinsics && !FLAG_IS_DEFAULT(UseAESIntrinsics)) { > + warning("SSE4.2 intrinsics require SSE4.2 instructions or higher. Intrinsics will be disabled."); > + } > + FLAG_SET_DEFAULT(UseSSE42Intrinsics, false); > + } > + } > + > + if(FLAG_IS_DEFAULT(AllocatePrefetchInstr) && supports_3dnow_prefetch()) { > + FLAG_SET_DEFAULT(AllocatePrefetchInstr, 3); > + } > + } > + > if( is_amd() ) { // AMD cpus specific settings > if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { > // Use it on new AMD cpus starting from Opteron. > @@ -1370,6 +1435,14 @@ > #ifdef COMPILER2 > if (FLAG_IS_DEFAULT(UseFPUForSpilling) && supports_sse4_2()) { > FLAG_SET_DEFAULT(UseFPUForSpilling, true); > + } > +#endif > + } > + > + if (is_zx() && ((cpu_family() == 6)||(cpu_family() == 7)) && supports_sse3()) { > +#ifdef COMPILER2 > + if (FLAG_IS_DEFAULT(UseFPUForSpilling) && supports_sse4_2()) { > + FLAG_SET_DEFAULT(UseFPUForSpilling, true); > } > #endif > } > diff -Nur org/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp zx/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp > --- org/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp2017-12-08 03:33:00.000000000 +0800 > +++ zx/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp2017-12-28 14:15:18.000000000 +0800 > @@ -305,6 +305,9 @@ > enum Extended_Family { > // AMD > CPU_FAMILY_AMD_11H = 0x11, > + // ZX > + CPU_FAMILY_ZX_CORE_F6 = 6, > + CPU_FAMILY_ZX_CORE_F7 = 7, > // Intel > CPU_FAMILY_INTEL_CORE = 6, > CPU_MODEL_NEHALEM = 0x1e, > @@ -549,6 +552,16 @@ > } > } > > +// ZX features. > + if(is_zx()) { > + if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) > + result |= CPU_LZCNT; > + // for ZX, ecx.bits.misalignsse bit (bit 8) indicates support for prefetchw > + if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { > + result |= CPU_3DNOW_PREFETCH; > + } > + } > + > return result; > } > > @@ -657,6 +670,7 @@ > static bool is_P6() { return cpu_family() >= 6; } > static bool is_amd() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' > static bool is_intel() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' > + static bool is_zx() { assert_is_initialized(); return (_cpuid_info.std_vendor_name_0 == 0x746e6543)||(_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS ' > static bool is_atom_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton > static bool is_knights_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x57) || (extended_cpu_model() == 0x85))); } // Xeon Phi 3200/5200/7200 and Future Xeon Phi > > @@ -680,7 +694,16 @@ > } > } else if (is_amd()) { > result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); > - } > + } else if (is_zx()) { > + bool supports_topology = supports_processor_topology(); > + if (supports_topology) { > + result = _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus / > + _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; > + } > + if (!supports_topology || result == 0) { > + result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); > + } > +} > return result; > } > > @@ -688,7 +711,9 @@ > uint result = 1; > if (is_intel() && supports_processor_topology()) { > result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; > - } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { > + } else if (is_zx() && supports_processor_topology()) { > + result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; > +} else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { > if (cpu_family() >= 0x17) { > result = _cpuid_info.ext_cpuid1E_ebx.bits.threads_per_core + 1; > } else { > @@ -705,7 +730,9 @@ > result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); > } else if (is_amd()) { > result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; > - } > + } else if (is_zx()) { > + result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); > +} > if (result < 32) // not defined ? > result = 32; // 32 bytes by default on x86 and other x64 > return result; > > Finally, running the jtreg test. I run 2 jtreg tests(jtreg:test/jdk:tier1 and jtreg:test/langtools:tier1) and both of them are pass. > The results are as follows. > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/jdk:tier1 1660 1660 0 0 > jtreg:test/langtools:tier1 3828 3828 0 0 > jtreg:test/nashorn:tier1 0 0 0 0 > jtreg:test/jaxp:tier1 0 0 0 0 > ============================== > TEST SUCCESS > > Best Regards! > VicWang | R&D > Telephone:+86-01082695388-892477 > > > ????? > ????????????????????????????????????????????????????? > CONFIDENTIAL NOTE: > This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited. > From VicWang at zhaoxin.com Mon Jan 1 08:48:34 2018 From: VicWang at zhaoxin.com (Vic Wang(BJ-RD)) Date: Mon, 1 Jan 2018 08:48:34 +0000 Subject: =?gb2312?B?tPC4tDogW3BhdGNoXSBzdXBwb3J0IHpoYW94aW4geDg2IGNwdSB2ZW5kb3Ig?= =?gb2312?Q?ids_CentaurHauls_and_Shanghai?= In-Reply-To: <9fa3cca9-4032-8b08-b36a-be8e2ebcc6e5@oracle.com> References: , <9fa3cca9-4032-8b08-b36a-be8e2ebcc6e5@oracle.com> Message-ID: <48316fe2f5d1433e8d07545895dec18e@zhaoxin.com> Hi David: My company has already signed the OCA, and I can find my company's name(Shanghai Zhaoxin Semiconductor Co. Ltd.) in the signatories list. Please check it again. Thanks very much. Best Regards! Vic ________________________________ ???: David Holmes ????: 2018?1?1? 15:48 ???: Vic Wang(BJ-RD); hotspot-dev at openjdk.java.net ??: Cobe Chen(BJ-RD) ??: Re: [patch] support zhaoxin x86 cpu vendor ids CentaurHauls and Shanghai Hi Vic, Have you, or your company signed the OCA? [1] Unfortunately there seems to be a problem accessing the signatory list at the moment so I can't check myself. Thanks, David [1] http://openjdk.java.net/contribute/ On 28/12/2017 4:59 PM, Vic Wang(BJ-RD) wrote: > Hi, > Here is a hotspot patch for supporting zhaoxin x86 cpu vendor ids (CentaurHauls id and Shanghai id). The original repository is http://hg.openjdk.java.net/jdk/hs. > Please help me to submit the changes . If there is anything incorrectly, please let me know. Thank you very much. > > The following is the changeset by the diff command. > > diff -Nur org/jdk/src/hotspot/cpu/x86/assembler_x86.cpp zx/jdk/src/hotspot/cpu/x86/assembler_x86.cpp > --- org/jdk/src/hotspot/cpu/x86/assembler_x86.cpp2017-12-08 03:33:00.000000000 +0800 > +++ zx/jdk/src/hotspot/cpu/x86/assembler_x86.cpp2017-12-28 11:31:30.000000000 +0800 > @@ -3167,6 +3167,89 @@ > return; > } > > + if (UseAddressNop && VM_Version::is_zx()) { > + // > + // Using multi-bytes nops "0x0F 0x1F [address]" for ZX > + // 1: 0x90 > + // 2: 0x66 0x90 > + // 3: 0x66 0x66 0x90 (don't use "0x0F 0x1F 0x00" - need patching safe padding) > + // 4: 0x0F 0x1F 0x40 0x00 > + // 5: 0x0F 0x1F 0x44 0x00 0x00 > + // 6: 0x66 0x0F 0x1F 0x44 0x00 0x00 > + // 7: 0x0F 0x1F 0x80 0x00 0x00 0x00 0x00 > + // 8: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > + // 9: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > + // 10: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > + // 11: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > + > + // The rest coding is ZX specific - don't use consecutive address nops > + > + // 12: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 > + // 13: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 > + // 14: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 > + // 15: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 > + > + while(i >= 15) { > + // For ZX don't generate consecutive addess nops (mix with regular nops) > + i -= 15; > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + addr_nop_8(); > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8((unsigned char)0x90); > + // nop > + } > + switch (i) { > + case 14: > + emit_int8(0x66); // size prefix > + case 13: > + emit_int8(0x66); // size prefix > + case 12: > + addr_nop_8(); > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8((unsigned char)0x90); > + // nop > + break; > + case 11: > + emit_int8(0x66); // size prefix > + case 10: > + emit_int8(0x66); // size prefix > + case 9: > + emit_int8(0x66); // size prefix > + case 8: > + addr_nop_8(); > + break; > + case 7: > + addr_nop_7(); > + break; > + case 6: > + emit_int8(0x66); // size prefix > + case 5: > + addr_nop_5(); > + break; > + case 4: > + addr_nop_4(); > + break; > + case 3: > + // Don't use "0x0F 0x1F 0x00" - need patching safe padding > + emit_int8(0x66); // size prefix > + case 2: > + emit_int8(0x66); // size prefix > + case 1: > + emit_int8((unsigned char)0x90); > + // nop > + break; > + default: > + assert(i == 0, " "); > + } > + return; > + } > + > // Using nops with size prefixes "0x66 0x90". > // From AMD Optimization Guide: > // 1: 0x90 > diff -Nur org/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp zx/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp > --- org/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp2017-12-08 03:33:00.000000000 +0800 > +++ zx/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp2017-12-28 11:30:40.000000000 +0800 > @@ -628,6 +628,11 @@ > if (UseSSE < 1) > _features &= ~CPU_SSE; > > + //since AVX instructions is slower than SSE in some ZX cpus, force USEAVX=0. > + if(is_zx() && ((cpu_family()==6)||(cpu_family()==7))){ > +UseAVX = 0; > + } > + > // first try initial setting and detect what we can support > int use_avx_limit = 0; > if (UseAVX > 0) { > @@ -1078,6 +1083,66 @@ > // UseXmmRegToRegMoveAll == true --> movaps(xmm, xmm), movapd(xmm, xmm). > // UseXmmRegToRegMoveAll == false --> movss(xmm, xmm), movsd(xmm, xmm). > > + > + if( is_zx() ) { // ZX cpus specific settings > + if( FLAG_IS_DEFAULT(UseStoreImmI16) ) { > + UseStoreImmI16 = false; // don't use it on ZX cpus > + } > + if( (cpu_family() == 6)|| (cpu_family() == 7) ) { > + if( FLAG_IS_DEFAULT(UseAddressNop) ) { > + // Use it on all ZX cpus > + UseAddressNop = true; > + } > + } > + if( FLAG_IS_DEFAULT(UseXmmLoadAndClearUpper) ) { > + UseXmmLoadAndClearUpper = true; // use movsd on all ZX cpus > + } > + if( FLAG_IS_DEFAULT(UseXmmRegToRegMoveAll) ) { > + if( supports_sse3() ) { > + UseXmmRegToRegMoveAll = true; // use movaps, movapd on new ZX cpus > + } else { > + UseXmmRegToRegMoveAll = false; > + } > + } > + if( ((cpu_family() == 6)||(cpu_family() == 7)) && supports_sse3() ) { // new ZX cpus > +#ifdef COMPILER2 > + if( FLAG_IS_DEFAULT(MaxLoopPad) ) { > + // For new ZX cpus do the next optimization: > + // don't align the beginning of a loop if there are enough instructions > + // left (NumberOfLoopInstrToAlign defined in c2_globals.hpp) > + // in current fetch line (OptoLoopAlignment) or the padding > + // is big (> MaxLoopPad). > + // Set MaxLoopPad to 11 for new ZX cpus to reduce number of > + // generated NOP instructions. 11 is the largest size of one > + // address NOP instruction '0F 1F' (see Assembler::nop(i)). > + MaxLoopPad = 11; > + } > +#endif // COMPILER2 > + if (FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { > + UseXMMForArrayCopy = true; // use SSE2 movq on new ZX cpus > + } > + if (supports_sse4_2()) { // new ZX cpus > + if (FLAG_IS_DEFAULT(UseUnalignedLoadStores)) { > + UseUnalignedLoadStores = true; // use movdqu on newest ZX cpus > + } > + } > + if (supports_sse4_2()) { > + if (FLAG_IS_DEFAULT(UseSSE42Intrinsics)) { > + FLAG_SET_DEFAULT(UseSSE42Intrinsics, true); > + } > + } else { > + if (UseSSE42Intrinsics && !FLAG_IS_DEFAULT(UseAESIntrinsics)) { > + warning("SSE4.2 intrinsics require SSE4.2 instructions or higher. Intrinsics will be disabled."); > + } > + FLAG_SET_DEFAULT(UseSSE42Intrinsics, false); > + } > + } > + > + if(FLAG_IS_DEFAULT(AllocatePrefetchInstr) && supports_3dnow_prefetch()) { > + FLAG_SET_DEFAULT(AllocatePrefetchInstr, 3); > + } > + } > + > if( is_amd() ) { // AMD cpus specific settings > if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { > // Use it on new AMD cpus starting from Opteron. > @@ -1370,6 +1435,14 @@ > #ifdef COMPILER2 > if (FLAG_IS_DEFAULT(UseFPUForSpilling) && supports_sse4_2()) { > FLAG_SET_DEFAULT(UseFPUForSpilling, true); > + } > +#endif > + } > + > + if (is_zx() && ((cpu_family() == 6)||(cpu_family() == 7)) && supports_sse3()) { > +#ifdef COMPILER2 > + if (FLAG_IS_DEFAULT(UseFPUForSpilling) && supports_sse4_2()) { > + FLAG_SET_DEFAULT(UseFPUForSpilling, true); > } > #endif > } > diff -Nur org/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp zx/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp > --- org/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp2017-12-08 03:33:00.000000000 +0800 > +++ zx/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp2017-12-28 14:15:18.000000000 +0800 > @@ -305,6 +305,9 @@ > enum Extended_Family { > // AMD > CPU_FAMILY_AMD_11H = 0x11, > + // ZX > + CPU_FAMILY_ZX_CORE_F6 = 6, > + CPU_FAMILY_ZX_CORE_F7 = 7, > // Intel > CPU_FAMILY_INTEL_CORE = 6, > CPU_MODEL_NEHALEM = 0x1e, > @@ -549,6 +552,16 @@ > } > } > > +// ZX features. > + if(is_zx()) { > + if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) > + result |= CPU_LZCNT; > + // for ZX, ecx.bits.misalignsse bit (bit 8) indicates support for prefetchw > + if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { > + result |= CPU_3DNOW_PREFETCH; > + } > + } > + > return result; > } > > @@ -657,6 +670,7 @@ > static bool is_P6() { return cpu_family() >= 6; } > static bool is_amd() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' > static bool is_intel() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' > + static bool is_zx() { assert_is_initialized(); return (_cpuid_info.std_vendor_name_0 == 0x746e6543)||(_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS ' > static bool is_atom_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton > static bool is_knights_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x57) || (extended_cpu_model() == 0x85))); } // Xeon Phi 3200/5200/7200 and Future Xeon Phi > > @@ -680,7 +694,16 @@ > } > } else if (is_amd()) { > result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); > - } > + } else if (is_zx()) { > + bool supports_topology = supports_processor_topology(); > + if (supports_topology) { > + result = _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus / > + _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; > + } > + if (!supports_topology || result == 0) { > + result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); > + } > +} > return result; > } > > @@ -688,7 +711,9 @@ > uint result = 1; > if (is_intel() && supports_processor_topology()) { > result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; > - } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { > + } else if (is_zx() && supports_processor_topology()) { > + result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; > +} else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { > if (cpu_family() >= 0x17) { > result = _cpuid_info.ext_cpuid1E_ebx.bits.threads_per_core + 1; > } else { > @@ -705,7 +730,9 @@ > result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); > } else if (is_amd()) { > result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; > - } > + } else if (is_zx()) { > + result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); > +} > if (result < 32) // not defined ? > result = 32; // 32 bytes by default on x86 and other x64 > return result; > > Finally, running the jtreg test. I run 2 jtreg tests(jtreg:test/jdk:tier1 and jtreg:test/langtools:tier1) and both of them are pass. > The results are as follows. > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/jdk:tier1 1660 1660 0 0 > jtreg:test/langtools:tier1 3828 3828 0 0 > jtreg:test/nashorn:tier1 0 0 0 0 > jtreg:test/jaxp:tier1 0 0 0 0 > ============================== > TEST SUCCESS > > Best Regards! > VicWang | R&D > Telephone:+86-01082695388-892477 > > > ????? > ????????????????????????????????????????????????????? > CONFIDENTIAL NOTE: > This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited. > ????? ????????????????????????????????????????????????????? CONFIDENTIAL NOTE: This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited. From david.holmes at oracle.com Mon Jan 1 12:47:55 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 1 Jan 2018 22:47:55 +1000 Subject: =?UTF-8?Q?Re:_=e7=ad=94=e5=a4=8d:_[patch]_support_zhaoxin_x86_cpu_v?= =?UTF-8?Q?endor_ids_CentaurHauls_and_Shanghai?= In-Reply-To: <48316fe2f5d1433e8d07545895dec18e@zhaoxin.com> References: <9fa3cca9-4032-8b08-b36a-be8e2ebcc6e5@oracle.com> <48316fe2f5d1433e8d07545895dec18e@zhaoxin.com> Message-ID: <22954e39-5ebd-4a10-1a17-538be6358078@oracle.com> On 1/01/2018 6:48 PM, Vic Wang(BJ-RD) wrote: > Hi David: > > > My company has already signed the OCA, and I can find my company's > name(Shanghai Zhaoxin Semiconductor Co. Ltd.) in the signatories list. Thanks for confirming that. > Please check it again. I can't access it - I just get one of those "the server is redirecting the request for this address in a way that will never complete" errors. I'll take a look at the patch itself tomorrow once I'm back at work. David > Thanks very much. > > > Best Regards! > Vic > ------------------------------------------------------------------------ > *???:* David Holmes > *????:* 2018?1?1? 15:48 > *???:* Vic Wang(BJ-RD); hotspot-dev at openjdk.java.net > *??:* Cobe Chen(BJ-RD) > *??:* Re: [patch] support zhaoxin x86 cpu vendor ids CentaurHauls and > Shanghai > Hi Vic, > > Have you, or your company signed the OCA? [1] Unfortunately there seems > to be a problem accessing the signatory list at the moment so I can't > check myself. > > Thanks, > David > [1] http://openjdk.java.net/contribute/ > > > On 28/12/2017 4:59 PM, Vic Wang(BJ-RD) wrote: >> Hi, >> Here is a hotspot patch for supporting zhaoxin x86 cpu vendor ids (CentaurHauls id and Shanghai id). The original repository is http://hg.openjdk.java.net/jdk/hs. >> Please help me to submit the changes . If there is anything incorrectly, please let me know. Thank you very much. >> >> The following is the changeset by the diff command. >> >> diff -Nur org/jdk/src/hotspot/cpu/x86/assembler_x86.cpp zx/jdk/src/hotspot/cpu/x86/assembler_x86.cpp >> --- org/jdk/src/hotspot/cpu/x86/assembler_x86.cpp2017-12-08 03:33:00.000000000 +0800 >> +++ zx/jdk/src/hotspot/cpu/x86/assembler_x86.cpp2017-12-28 11:31:30.000000000 +0800 >> @@ -3167,6 +3167,89 @@ >>?????? return; >>???? } >> >> +? if (UseAddressNop && VM_Version::is_zx()) { >> +??? // >> +??? // Using multi-bytes nops "0x0F 0x1F [address]" for ZX >> +??? //? 1: 0x90 >> +??? //? 2: 0x66 0x90 >> +??? //? 3: 0x66 0x66 0x90 (don't use "0x0F 0x1F 0x00" - need patching safe padding) >> +??? //? 4: 0x0F 0x1F 0x40 0x00 >> +??? //? 5: 0x0F 0x1F 0x44 0x00 0x00 >> +??? //? 6: 0x66 0x0F 0x1F 0x44 0x00 0x00 >> +??? //? 7: 0x0F 0x1F 0x80 0x00 0x00 0x00 0x00 >> +??? //? 8: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 >> +??? //? 9: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 >> +??? // 10: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 >> +??? // 11: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 >> + >> +??? // The rest coding is ZX specific - don't use consecutive address nops >> + >> +??? // 12: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 >> +??? // 13: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 >> +??? // 14: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 >> +??? // 15: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 >> + >> +??? while(i >= 15) { >> +????? // For ZX don't generate consecutive addess nops (mix with regular nops) >> +????? i -= 15; >> +????? emit_int8(0x66);?? // size prefix >> +????? emit_int8(0x66);?? // size prefix >> +????? emit_int8(0x66);?? // size prefix >> +????? addr_nop_8(); >> +????? emit_int8(0x66);?? // size prefix >> +????? emit_int8(0x66);?? // size prefix >> +????? emit_int8(0x66);?? // size prefix >> +????? emit_int8((unsigned char)0x90); >> +???????????????????????? // nop >> +??? } >> +??? switch (i) { >> +????? case 14: >> +??????? emit_int8(0x66); // size prefix >> +????? case 13: >> +??????? emit_int8(0x66); // size prefix >> +????? case 12: >> +??????? addr_nop_8(); >> +??????? emit_int8(0x66); // size prefix >> +??????? emit_int8(0x66); // size prefix >> +??????? emit_int8(0x66); // size prefix >> +??????? emit_int8((unsigned char)0x90); >> +???????????????????????? // nop >> +??????? break; >> +????? case 11: >> +??????? emit_int8(0x66); // size prefix >> +????? case 10: >> +??????? emit_int8(0x66); // size prefix >> +????? case 9: >> +??????? emit_int8(0x66); // size prefix >> +????? case 8: >> +??????? addr_nop_8(); >> +??????? break; >> +????? case 7: >> +??????? addr_nop_7(); >> +??????? break; >> +????? case 6: >> +??????? emit_int8(0x66); // size prefix >> +????? case 5: >> +??????? addr_nop_5(); >> +??????? break; >> +????? case 4: >> +??????? addr_nop_4(); >> +??????? break; >> +????? case 3: >> +??????? // Don't use "0x0F 0x1F 0x00" - need patching safe padding >> +??????? emit_int8(0x66); // size prefix >> +????? case 2: >> +??????? emit_int8(0x66); // size prefix >> +????? case 1: >> +??????? emit_int8((unsigned char)0x90); >> +???????????????????????? // nop >> +??????? break; >> +????? default: >> +??????? assert(i == 0, " "); >> +??? } >> +??? return; >> +? } >> + >>???? // Using nops with size prefixes "0x66 0x90". >>???? // From AMD Optimization Guide: >>???? //? 1: 0x90 >> diff -Nur org/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp zx/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp >> --- org/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp2017-12-08 03:33:00.000000000 +0800 >> +++ zx/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp2017-12-28 11:30:40.000000000 +0800 >> @@ -628,6 +628,11 @@ >>???? if (UseSSE < 1) >>?????? _features &= ~CPU_SSE; >> >> +? //since AVX instructions is slower than SSE in some ZX cpus, force USEAVX=0. >> +? if(is_zx() && ((cpu_family()==6)||(cpu_family()==7))){ >> +UseAVX = 0; >> +? } >> + >>???? // first try initial setting and detect what we can support >>???? int use_avx_limit = 0; >>???? if (UseAVX > 0) { >> @@ -1078,6 +1083,66 @@ >>???? // UseXmmRegToRegMoveAll == true? --> movaps(xmm, xmm), movapd(xmm, xmm). >>???? // UseXmmRegToRegMoveAll == false --> movss(xmm, xmm),? movsd(xmm, xmm). >> >> + >> +? if( is_zx() ) { // ZX cpus specific settings >> +??? if( FLAG_IS_DEFAULT(UseStoreImmI16) ) { >> +????? UseStoreImmI16 = false; // don't use it on ZX cpus >> +??? } >> +??? if( (cpu_family() == 6)|| (cpu_family() == 7) ) { >> +????? if( FLAG_IS_DEFAULT(UseAddressNop) ) { >> +??????? // Use it on all ZX cpus >> +??????? UseAddressNop = true; >> +????? } >> +??? } >> +??? if( FLAG_IS_DEFAULT(UseXmmLoadAndClearUpper) ) { >> +????? UseXmmLoadAndClearUpper = true; // use movsd on all ZX cpus >> +??? } >> +??? if( FLAG_IS_DEFAULT(UseXmmRegToRegMoveAll) ) { >> +????? if( supports_sse3() ) { >> +??????? UseXmmRegToRegMoveAll = true; // use movaps, movapd on new ZX cpus >> +????? } else { >> +??????? UseXmmRegToRegMoveAll = false; >> +????? } >> +??? } >> +??? if( ((cpu_family() == 6)||(cpu_family() == 7)) && supports_sse3() ) { // new ZX cpus >> +#ifdef COMPILER2 >> +????? if( FLAG_IS_DEFAULT(MaxLoopPad) ) { >> +??????? // For new ZX cpus do the next optimization: >> +??????? // don't align the beginning of a loop if there are enough instructions >> +??????? // left (NumberOfLoopInstrToAlign defined in c2_globals.hpp) >> +??????? // in current fetch line (OptoLoopAlignment) or the padding >> +??????? // is big (> MaxLoopPad). >> +??????? // Set MaxLoopPad to 11 for new ZX cpus to reduce number of >> +??????? // generated NOP instructions. 11 is the largest size of one >> +??????? // address NOP instruction '0F 1F' (see Assembler::nop(i)). >> +??????? MaxLoopPad = 11; >> +????? } >> +#endif // COMPILER2 >> +????? if (FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >> +??????? UseXMMForArrayCopy = true; // use SSE2 movq on new ZX cpus >> +????? } >> +????? if (supports_sse4_2()) { // new ZX cpus >> +??????? if (FLAG_IS_DEFAULT(UseUnalignedLoadStores)) { >> +????????? UseUnalignedLoadStores = true; // use movdqu on newest ZX cpus >> +??????? } >> +????? } >> +????? if (supports_sse4_2()) { >> +??????? if (FLAG_IS_DEFAULT(UseSSE42Intrinsics)) { >> +????????? FLAG_SET_DEFAULT(UseSSE42Intrinsics, true); >> +??????? } >> +????? } else { >> +??????? if (UseSSE42Intrinsics && !FLAG_IS_DEFAULT(UseAESIntrinsics)) { >> +????????? warning("SSE4.2 intrinsics require SSE4.2 instructions or higher. Intrinsics will be disabled."); >> +??????? } >> +??????? FLAG_SET_DEFAULT(UseSSE42Intrinsics, false); >> +????? } >> +??? } >> + >> +??? if(FLAG_IS_DEFAULT(AllocatePrefetchInstr) && supports_3dnow_prefetch()) { >> +????? FLAG_SET_DEFAULT(AllocatePrefetchInstr, 3); >> +??? } >> +? } >> + >>???? if( is_amd() ) { // AMD cpus specific settings >>?????? if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { >>???????? // Use it on new AMD cpus starting from Opteron. >> @@ -1370,6 +1435,14 @@ >>?? #ifdef COMPILER2 >>?????? if (FLAG_IS_DEFAULT(UseFPUForSpilling) && supports_sse4_2()) { >>???????? FLAG_SET_DEFAULT(UseFPUForSpilling, true); >> +??? } >> +#endif >> +? } >> + >> +??? if (is_zx() && ((cpu_family() == 6)||(cpu_family() == 7)) && supports_sse3()) { >> +#ifdef COMPILER2 >> +??? if (FLAG_IS_DEFAULT(UseFPUForSpilling) && supports_sse4_2()) { >> +????? FLAG_SET_DEFAULT(UseFPUForSpilling, true); >>?????? } >>?? #endif >>???? } >> diff -Nur org/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp zx/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp >> --- org/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp2017-12-08 03:33:00.000000000 +0800 >> +++ zx/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp2017-12-28 14:15:18.000000000 +0800 >> @@ -305,6 +305,9 @@ >>???? enum Extended_Family { >>?????? // AMD >>?????? CPU_FAMILY_AMD_11H?????? = 0x11, >> +??? // ZX >> +??? CPU_FAMILY_ZX_CORE_F6??? = 6, >> +??? CPU_FAMILY_ZX_CORE_F7??? = 7, >>?????? // Intel >>?????? CPU_FAMILY_INTEL_CORE??? = 6, >>?????? CPU_MODEL_NEHALEM??????? = 0x1e, >> @@ -549,6 +552,16 @@ >>???????? } >>?????? } >> >> +// ZX features. >> +??? if(is_zx()) { >> +????? if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) >> +??????? result |= CPU_LZCNT; >> +????? // for ZX, ecx.bits.misalignsse bit (bit 8) indicates support for prefetchw >> +????? if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { >> +??????? result |= CPU_3DNOW_PREFETCH; >> +????? } >> +??? } >> + >>?????? return result; >>???? } >> >> @@ -657,6 +670,7 @@ >>???? static bool is_P6()???????????? { return cpu_family() >= 6; } >>???? static bool is_amd()??????????? { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' >>???? static bool is_intel()????????? { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' >> +? static bool is_zx()???????????? { assert_is_initialized(); return (_cpuid_info.std_vendor_name_0 == 0x746e6543)||(_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS? ' >>???? static bool is_atom_family()??? { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton >>???? static bool is_knights_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x57) || (extended_cpu_model() == 0x85))); } // Xeon Phi 3200/5200/7200 and Future Xeon Phi >> >> @@ -680,7 +694,16 @@ >>???????? } >>?????? } else if (is_amd()) { >>???????? result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); >> -??? } >> +??? } else if (is_zx()) { >> +? bool supports_topology = supports_processor_topology(); >> +????? if (supports_topology) { >> +??????? result = _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus / >> +???????????????? _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; >> +????? } >> +????? if (!supports_topology || result == 0) { >> +??????? result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); >> +????? } >> +} >>?????? return result; >>???? } >> >> @@ -688,7 +711,9 @@ >>?????? uint result = 1; >>?????? if (is_intel() && supports_processor_topology()) { >>???????? result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; >> -??? } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { >> +??? } else if (is_zx() && supports_processor_topology()) { >> +? result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; >> +} else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { >>???????? if (cpu_family() >= 0x17) { >>?????????? result = _cpuid_info.ext_cpuid1E_ebx.bits.threads_per_core + 1; >>???????? } else { >> @@ -705,7 +730,9 @@ >>???????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>?????? } else if (is_amd()) { >>???????? result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; >> -??? } >> +??? } else if (is_zx()) { >> +? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >> +} >>?????? if (result < 32) // not defined ? >>???????? result = 32;?? // 32 bytes by default on x86 and other x64 >>?????? return result; >> >> Finally, running the jtreg test. I run 2 jtreg tests(jtreg:test/jdk:tier1 and jtreg:test/langtools:tier1) and both of them are pass. >> The results are as follows. >> ============================== >> Test summary >> ============================== >>???? TEST????????????????????????????????????????????? TOTAL? PASS? FAIL ERROR >>???? jtreg:test/jdk:tier1?????????????????????????????? 1660? 1660???? 0???? 0 >>???? jtreg:test/langtools:tier1????????????????????????? 3828? 3828???? 0???? 0 >>???? jtreg:test/nashorn:tier1????????????????????????????? 0???? 0???? 0???? 0 >>???? jtreg:test/jaxp:tier1???????????????????????????????? 0???? 0???? 0???? 0 >> ============================== >> TEST SUCCESS >> >> Best Regards! >> VicWang | R&D >> Telephone:+86-01082695388-892477 >> >> >> ????? >> ????????????????????????????????????????????????????? >> CONFIDENTIAL NOTE: >> This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited. >> > > > > ????? > ???????????????????????????????????? > ????????????????? > /CONFIDENTIAL NOTE: / > /This email contains confidential or legally privileged information and > is for the sole use of its intended recipient. Any unauthorized review, > use, copying or forwarding of this email or the content of this email is > strictly prohibited./ From david.holmes at oracle.com Mon Jan 1 21:17:59 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 2 Jan 2018 07:17:59 +1000 Subject: [patch] support zhaoxin x86 cpu vendor ids CentaurHauls and Shanghai In-Reply-To: References: Message-ID: <3f71a3a2-624a-76c8-6d2d-0d3eca13c189@oracle.com> Hi, I've created a JBS issue for this enhancement request: https://bugs.openjdk.java.net/browse/JDK-8194279 On 28/12/2017 4:59 PM, Vic Wang(BJ-RD) wrote: > Hi, > Here is a hotspot patch for supporting zhaoxin x86 cpu vendor ids (CentaurHauls id and Shanghai id). The original repository is http://hg.openjdk.java.net/jdk/hs. > Please help me to submit the changes . If there is anything incorrectly, please let me know. Thank you very much. > > The following is the changeset by the diff command. Can you generate a patch using "hg diff" or "hg export" please. The raw diff can't be applied directly to an existing repo without manual editing. Thanks, David > diff -Nur org/jdk/src/hotspot/cpu/x86/assembler_x86.cpp zx/jdk/src/hotspot/cpu/x86/assembler_x86.cpp > --- org/jdk/src/hotspot/cpu/x86/assembler_x86.cpp2017-12-08 03:33:00.000000000 +0800 > +++ zx/jdk/src/hotspot/cpu/x86/assembler_x86.cpp2017-12-28 11:31:30.000000000 +0800 > @@ -3167,6 +3167,89 @@ > return; > } > > + if (UseAddressNop && VM_Version::is_zx()) { > + // > + // Using multi-bytes nops "0x0F 0x1F [address]" for ZX > + // 1: 0x90 > + // 2: 0x66 0x90 > + // 3: 0x66 0x66 0x90 (don't use "0x0F 0x1F 0x00" - need patching safe padding) > + // 4: 0x0F 0x1F 0x40 0x00 > + // 5: 0x0F 0x1F 0x44 0x00 0x00 > + // 6: 0x66 0x0F 0x1F 0x44 0x00 0x00 > + // 7: 0x0F 0x1F 0x80 0x00 0x00 0x00 0x00 > + // 8: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > + // 9: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > + // 10: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > + // 11: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > + > + // The rest coding is ZX specific - don't use consecutive address nops > + > + // 12: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 > + // 13: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 > + // 14: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 > + // 15: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 > + > + while(i >= 15) { > + // For ZX don't generate consecutive addess nops (mix with regular nops) > + i -= 15; > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + addr_nop_8(); > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8((unsigned char)0x90); > + // nop > + } > + switch (i) { > + case 14: > + emit_int8(0x66); // size prefix > + case 13: > + emit_int8(0x66); // size prefix > + case 12: > + addr_nop_8(); > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8((unsigned char)0x90); > + // nop > + break; > + case 11: > + emit_int8(0x66); // size prefix > + case 10: > + emit_int8(0x66); // size prefix > + case 9: > + emit_int8(0x66); // size prefix > + case 8: > + addr_nop_8(); > + break; > + case 7: > + addr_nop_7(); > + break; > + case 6: > + emit_int8(0x66); // size prefix > + case 5: > + addr_nop_5(); > + break; > + case 4: > + addr_nop_4(); > + break; > + case 3: > + // Don't use "0x0F 0x1F 0x00" - need patching safe padding > + emit_int8(0x66); // size prefix > + case 2: > + emit_int8(0x66); // size prefix > + case 1: > + emit_int8((unsigned char)0x90); > + // nop > + break; > + default: > + assert(i == 0, " "); > + } > + return; > + } > + > // Using nops with size prefixes "0x66 0x90". > // From AMD Optimization Guide: > // 1: 0x90 > diff -Nur org/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp zx/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp > --- org/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp2017-12-08 03:33:00.000000000 +0800 > +++ zx/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp2017-12-28 11:30:40.000000000 +0800 > @@ -628,6 +628,11 @@ > if (UseSSE < 1) > _features &= ~CPU_SSE; > > + //since AVX instructions is slower than SSE in some ZX cpus, force USEAVX=0. > + if(is_zx() && ((cpu_family()==6)||(cpu_family()==7))){ > +UseAVX = 0; > + } > + > // first try initial setting and detect what we can support > int use_avx_limit = 0; > if (UseAVX > 0) { > @@ -1078,6 +1083,66 @@ > // UseXmmRegToRegMoveAll == true --> movaps(xmm, xmm), movapd(xmm, xmm). > // UseXmmRegToRegMoveAll == false --> movss(xmm, xmm), movsd(xmm, xmm). > > + > + if( is_zx() ) { // ZX cpus specific settings > + if( FLAG_IS_DEFAULT(UseStoreImmI16) ) { > + UseStoreImmI16 = false; // don't use it on ZX cpus > + } > + if( (cpu_family() == 6)|| (cpu_family() == 7) ) { > + if( FLAG_IS_DEFAULT(UseAddressNop) ) { > + // Use it on all ZX cpus > + UseAddressNop = true; > + } > + } > + if( FLAG_IS_DEFAULT(UseXmmLoadAndClearUpper) ) { > + UseXmmLoadAndClearUpper = true; // use movsd on all ZX cpus > + } > + if( FLAG_IS_DEFAULT(UseXmmRegToRegMoveAll) ) { > + if( supports_sse3() ) { > + UseXmmRegToRegMoveAll = true; // use movaps, movapd on new ZX cpus > + } else { > + UseXmmRegToRegMoveAll = false; > + } > + } > + if( ((cpu_family() == 6)||(cpu_family() == 7)) && supports_sse3() ) { // new ZX cpus > +#ifdef COMPILER2 > + if( FLAG_IS_DEFAULT(MaxLoopPad) ) { > + // For new ZX cpus do the next optimization: > + // don't align the beginning of a loop if there are enough instructions > + // left (NumberOfLoopInstrToAlign defined in c2_globals.hpp) > + // in current fetch line (OptoLoopAlignment) or the padding > + // is big (> MaxLoopPad). > + // Set MaxLoopPad to 11 for new ZX cpus to reduce number of > + // generated NOP instructions. 11 is the largest size of one > + // address NOP instruction '0F 1F' (see Assembler::nop(i)). > + MaxLoopPad = 11; > + } > +#endif // COMPILER2 > + if (FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { > + UseXMMForArrayCopy = true; // use SSE2 movq on new ZX cpus > + } > + if (supports_sse4_2()) { // new ZX cpus > + if (FLAG_IS_DEFAULT(UseUnalignedLoadStores)) { > + UseUnalignedLoadStores = true; // use movdqu on newest ZX cpus > + } > + } > + if (supports_sse4_2()) { > + if (FLAG_IS_DEFAULT(UseSSE42Intrinsics)) { > + FLAG_SET_DEFAULT(UseSSE42Intrinsics, true); > + } > + } else { > + if (UseSSE42Intrinsics && !FLAG_IS_DEFAULT(UseAESIntrinsics)) { > + warning("SSE4.2 intrinsics require SSE4.2 instructions or higher. Intrinsics will be disabled."); > + } > + FLAG_SET_DEFAULT(UseSSE42Intrinsics, false); > + } > + } > + > + if(FLAG_IS_DEFAULT(AllocatePrefetchInstr) && supports_3dnow_prefetch()) { > + FLAG_SET_DEFAULT(AllocatePrefetchInstr, 3); > + } > + } > + > if( is_amd() ) { // AMD cpus specific settings > if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { > // Use it on new AMD cpus starting from Opteron. > @@ -1370,6 +1435,14 @@ > #ifdef COMPILER2 > if (FLAG_IS_DEFAULT(UseFPUForSpilling) && supports_sse4_2()) { > FLAG_SET_DEFAULT(UseFPUForSpilling, true); > + } > +#endif > + } > + > + if (is_zx() && ((cpu_family() == 6)||(cpu_family() == 7)) && supports_sse3()) { > +#ifdef COMPILER2 > + if (FLAG_IS_DEFAULT(UseFPUForSpilling) && supports_sse4_2()) { > + FLAG_SET_DEFAULT(UseFPUForSpilling, true); > } > #endif > } > diff -Nur org/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp zx/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp > --- org/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp2017-12-08 03:33:00.000000000 +0800 > +++ zx/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp2017-12-28 14:15:18.000000000 +0800 > @@ -305,6 +305,9 @@ > enum Extended_Family { > // AMD > CPU_FAMILY_AMD_11H = 0x11, > + // ZX > + CPU_FAMILY_ZX_CORE_F6 = 6, > + CPU_FAMILY_ZX_CORE_F7 = 7, > // Intel > CPU_FAMILY_INTEL_CORE = 6, > CPU_MODEL_NEHALEM = 0x1e, > @@ -549,6 +552,16 @@ > } > } > > +// ZX features. > + if(is_zx()) { > + if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) > + result |= CPU_LZCNT; > + // for ZX, ecx.bits.misalignsse bit (bit 8) indicates support for prefetchw > + if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { > + result |= CPU_3DNOW_PREFETCH; > + } > + } > + > return result; > } > > @@ -657,6 +670,7 @@ > static bool is_P6() { return cpu_family() >= 6; } > static bool is_amd() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' > static bool is_intel() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' > + static bool is_zx() { assert_is_initialized(); return (_cpuid_info.std_vendor_name_0 == 0x746e6543)||(_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS ' > static bool is_atom_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton > static bool is_knights_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x57) || (extended_cpu_model() == 0x85))); } // Xeon Phi 3200/5200/7200 and Future Xeon Phi > > @@ -680,7 +694,16 @@ > } > } else if (is_amd()) { > result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); > - } > + } else if (is_zx()) { > + bool supports_topology = supports_processor_topology(); > + if (supports_topology) { > + result = _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus / > + _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; > + } > + if (!supports_topology || result == 0) { > + result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); > + } > +} > return result; > } > > @@ -688,7 +711,9 @@ > uint result = 1; > if (is_intel() && supports_processor_topology()) { > result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; > - } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { > + } else if (is_zx() && supports_processor_topology()) { > + result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; > +} else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { > if (cpu_family() >= 0x17) { > result = _cpuid_info.ext_cpuid1E_ebx.bits.threads_per_core + 1; > } else { > @@ -705,7 +730,9 @@ > result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); > } else if (is_amd()) { > result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; > - } > + } else if (is_zx()) { > + result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); > +} > if (result < 32) // not defined ? > result = 32; // 32 bytes by default on x86 and other x64 > return result; > > Finally, running the jtreg test. I run 2 jtreg tests(jtreg:test/jdk:tier1 and jtreg:test/langtools:tier1) and both of them are pass. > The results are as follows. > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/jdk:tier1 1660 1660 0 0 > jtreg:test/langtools:tier1 3828 3828 0 0 > jtreg:test/nashorn:tier1 0 0 0 0 > jtreg:test/jaxp:tier1 0 0 0 0 > ============================== > TEST SUCCESS > > Best Regards! > VicWang | R&D > Telephone:+86-01082695388-892477 > > > ????? > ????????????????????????????????????????????????????? > CONFIDENTIAL NOTE: > This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited. > From muthusamy.chinnathambi at oracle.com Tue Jan 2 06:08:45 2018 From: muthusamy.chinnathambi at oracle.com (Muthusamy Chinnathambi) Date: Mon, 1 Jan 2018 22:08:45 -0800 (PST) Subject: [8u] RFR for backport of JDK-8169931: 8k class metaspace chunks misallocated from 4k chunk freelist In-Reply-To: <14de408c-48f8-462d-8652-9c4b210f0129@default> References: <14de408c-48f8-462d-8652-9c4b210f0129@default> Message-ID: Ping.. May I please get a review for this? Regards, Muthusamy C -----Original Message----- From: Muthusamy Chinnathambi Sent: Monday, December 18, 2017 3:06 PM To: HotSpot Open Source Developers Subject: [8u] RFR for backport of JDK-8169931: 8k class metaspace chunks misallocated from 4k chunk freelist Hi, Please review the backport of bug: "JDK-8169931: 8k class metaspace chunks misallocated from 4k chunk freelist" to jdk8u-dev Please note that this is not a clean backport due to new entries in jni.cpp. Webrev: http://cr.openjdk.java.net/~mchinnathamb/JDK-8169931/webrev.01/ jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8169931 Original patch pushed to jdk9: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8d26435a4c69 Test: Had run jtreg, jprt hotspot testset and with -XX:+ExecuteInternalVMTests. Regards, Muthusamy C From david.holmes at oracle.com Tue Jan 2 06:50:55 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 2 Jan 2018 16:50:55 +1000 Subject: [8u] RFR for backport of JDK-8169931: 8k class metaspace chunks misallocated from 4k chunk freelist In-Reply-To: References: <14de408c-48f8-462d-8652-9c4b210f0129@default> Message-ID: Hi Muthusamy, On 2/01/2018 4:08 PM, Muthusamy Chinnathambi wrote: > Ping.. > > May I please get a review for this? > > Regards, > Muthusamy C > > -----Original Message----- > From: Muthusamy Chinnathambi > Sent: Monday, December 18, 2017 3:06 PM > To: HotSpot Open Source Developers > Subject: [8u] RFR for backport of JDK-8169931: 8k class metaspace chunks misallocated from 4k chunk freelist > > Hi, > > Please review the backport of bug: "JDK-8169931: 8k class metaspace chunks misallocated from 4k chunk freelist" to jdk8u-dev > > Please note that this is not a clean backport due to new entries in jni.cpp. > > > Webrev: http://cr.openjdk.java.net/~mchinnathamb/JDK-8169931/webrev.01/ > jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8169931 > Original patch pushed to jdk9: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8d26435a4c69 The functional backport appears to be a correct copy of the JDK 9 fix. The use of the test code in jni.cpp also appears correct. Copyright dates will now need to be updated to 2018. Thanks, David > Test: Had run jtreg, jprt hotspot testset and with -XX:+ExecuteInternalVMTests. > > Regards, > Muthusamy C > From muthusamy.chinnathambi at oracle.com Tue Jan 2 11:04:22 2018 From: muthusamy.chinnathambi at oracle.com (Muthusamy Chinnathambi) Date: Tue, 2 Jan 2018 03:04:22 -0800 (PST) Subject: [8u] RFR for backport of JDK-8169931: 8k class metaspace chunks misallocated from 4k chunk freelist In-Reply-To: References: <14de408c-48f8-462d-8652-9c4b210f0129@default> Message-ID: <62865dea-89e7-40c2-821e-f2e34e3d924f@default> Hi David, Thanks for the review. > Copyright dates will now need to be updated to 2018. Yes. Please find the updated webrev link below. http://cr.openjdk.java.net/~mchinnathamb/JDK-8169931/webrev.02/ Regards, Muthusamy C -----Original Message----- From: David Holmes Sent: Tuesday, January 2, 2018 12:21 PM To: Muthusamy Chinnathambi ; HotSpot Open Source Developers Cc: Stephen Fitch Subject: Re: [8u] RFR for backport of JDK-8169931: 8k class metaspace chunks misallocated from 4k chunk freelist Hi Muthusamy, On 2/01/2018 4:08 PM, Muthusamy Chinnathambi wrote: > Ping.. > > May I please get a review for this? > > Regards, > Muthusamy C > > -----Original Message----- > From: Muthusamy Chinnathambi > Sent: Monday, December 18, 2017 3:06 PM > To: HotSpot Open Source Developers > Subject: [8u] RFR for backport of JDK-8169931: 8k class metaspace chunks misallocated from 4k chunk freelist > > Hi, > > Please review the backport of bug: "JDK-8169931: 8k class metaspace chunks misallocated from 4k chunk freelist" to jdk8u-dev > > Please note that this is not a clean backport due to new entries in jni.cpp. > > > Webrev: http://cr.openjdk.java.net/~mchinnathamb/JDK-8169931/webrev.01/ > jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8169931 > Original patch pushed to jdk9: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8d26435a4c69 The functional backport appears to be a correct copy of the JDK 9 fix. The use of the test code in jni.cpp also appears correct. Copyright dates will now need to be updated to 2018. Thanks, David > Test: Had run jtreg, jprt hotspot testset and with -XX:+ExecuteInternalVMTests. > > Regards, > Muthusamy C > From kevin.walls at oracle.com Tue Jan 2 11:43:43 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Tue, 2 Jan 2018 11:43:43 +0000 Subject: [8u] RFR for backport of JDK-8169931: 8k class metaspace chunks misallocated from 4k chunk freelist In-Reply-To: <62865dea-89e7-40c2-821e-f2e34e3d924f@default> References: <14de408c-48f8-462d-8652-9c4b210f0129@default> <62865dea-89e7-40c2-821e-f2e34e3d924f@default> Message-ID: <804ca9fc-ecde-f9f2-3bb3-f8a855abe46c@oracle.com> Hi Muthu, Yes looks good to me, let me know if you need help with the push, Thanks Kevin On 02/01/2018 11:04, Muthusamy Chinnathambi wrote: > Hi David, > > Thanks for the review. > >> Copyright dates will now need to be updated to 2018. > Yes. Please find the updated webrev link below. > http://cr.openjdk.java.net/~mchinnathamb/JDK-8169931/webrev.02/ > > Regards, > Muthusamy C > > -----Original Message----- > From: David Holmes > Sent: Tuesday, January 2, 2018 12:21 PM > To: Muthusamy Chinnathambi ; HotSpot Open Source Developers > Cc: Stephen Fitch > Subject: Re: [8u] RFR for backport of JDK-8169931: 8k class metaspace chunks misallocated from 4k chunk freelist > > Hi Muthusamy, > > On 2/01/2018 4:08 PM, Muthusamy Chinnathambi wrote: >> Ping.. >> >> May I please get a review for this? >> >> Regards, >> Muthusamy C >> >> -----Original Message----- >> From: Muthusamy Chinnathambi >> Sent: Monday, December 18, 2017 3:06 PM >> To: HotSpot Open Source Developers >> Subject: [8u] RFR for backport of JDK-8169931: 8k class metaspace chunks misallocated from 4k chunk freelist >> >> Hi, >> >> Please review the backport of bug: "JDK-8169931: 8k class metaspace chunks misallocated from 4k chunk freelist" to jdk8u-dev >> >> Please note that this is not a clean backport due to new entries in jni.cpp. >> >> >> Webrev: http://cr.openjdk.java.net/~mchinnathamb/JDK-8169931/webrev.01/ >> jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8169931 >> Original patch pushed to jdk9: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8d26435a4c69 > The functional backport appears to be a correct copy of the JDK 9 fix. > > The use of the test code in jni.cpp also appears correct. > > Copyright dates will now need to be updated to 2018. > > Thanks, > David > >> Test: Had run jtreg, jprt hotspot testset and with -XX:+ExecuteInternalVMTests. >> >> Regards, >> Muthusamy C >> From muthusamy.chinnathambi at oracle.com Tue Jan 2 11:47:59 2018 From: muthusamy.chinnathambi at oracle.com (Muthusamy Chinnathambi) Date: Tue, 2 Jan 2018 03:47:59 -0800 (PST) Subject: [8u] RFR for backport of JDK-8169931: 8k class metaspace chunks misallocated from 4k chunk freelist In-Reply-To: <804ca9fc-ecde-f9f2-3bb3-f8a855abe46c@oracle.com> References: <14de408c-48f8-462d-8652-9c4b210f0129@default> <62865dea-89e7-40c2-821e-f2e34e3d924f@default> <804ca9fc-ecde-f9f2-3bb3-f8a855abe46c@oracle.com> Message-ID: Hi Kevin, > Yes looks good to me, let me know if you need help with the push, Thanks. Yes, it would be great if you could help with the push. Regards, Muthusamy C -----Original Message----- From: Kevin Walls Sent: Tuesday, January 2, 2018 5:14 PM To: Muthusamy Chinnathambi ; David Holmes ; HotSpot Open Source Developers Cc: Stephen Fitch Subject: Re: [8u] RFR for backport of JDK-8169931: 8k class metaspace chunks misallocated from 4k chunk freelist Hi Muthu, Yes looks good to me, let me know if you need help with the push, Thanks Kevin On 02/01/2018 11:04, Muthusamy Chinnathambi wrote: > Hi David, > > Thanks for the review. > >> Copyright dates will now need to be updated to 2018. > Yes. Please find the updated webrev link below. > http://cr.openjdk.java.net/~mchinnathamb/JDK-8169931/webrev.02/ > > Regards, > Muthusamy C > > -----Original Message----- > From: David Holmes > Sent: Tuesday, January 2, 2018 12:21 PM > To: Muthusamy Chinnathambi ; HotSpot Open Source Developers > Cc: Stephen Fitch > Subject: Re: [8u] RFR for backport of JDK-8169931: 8k class metaspace chunks misallocated from 4k chunk freelist > > Hi Muthusamy, > > On 2/01/2018 4:08 PM, Muthusamy Chinnathambi wrote: >> Ping.. >> >> May I please get a review for this? >> >> Regards, >> Muthusamy C >> >> -----Original Message----- >> From: Muthusamy Chinnathambi >> Sent: Monday, December 18, 2017 3:06 PM >> To: HotSpot Open Source Developers >> Subject: [8u] RFR for backport of JDK-8169931: 8k class metaspace chunks misallocated from 4k chunk freelist >> >> Hi, >> >> Please review the backport of bug: "JDK-8169931: 8k class metaspace chunks misallocated from 4k chunk freelist" to jdk8u-dev >> >> Please note that this is not a clean backport due to new entries in jni.cpp. >> >> >> Webrev: http://cr.openjdk.java.net/~mchinnathamb/JDK-8169931/webrev.01/ >> jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8169931 >> Original patch pushed to jdk9: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8d26435a4c69 > The functional backport appears to be a correct copy of the JDK 9 fix. > > The use of the test code in jni.cpp also appears correct. > > Copyright dates will now need to be updated to 2018. > > Thanks, > David > >> Test: Had run jtreg, jprt hotspot testset and with -XX:+ExecuteInternalVMTests. >> >> Regards, >> Muthusamy C >> From aph at redhat.com Tue Jan 2 16:46:54 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 2 Jan 2018 16:46:54 +0000 Subject: Request for sponsor: 8193260: AArch64: JVMCI: Implement trampoline calls Message-ID: This is already reviewed: it just needs somebody to push it through jprt because it touches the shared JVMCI. Thanks. http://cr.openjdk.java.net/~aph/8193260-2/ -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From jcbeyler at google.com Tue Jan 2 17:19:42 2018 From: jcbeyler at google.com (JC Beyler) Date: Tue, 2 Jan 2018 09:19:42 -0800 Subject: RFR 8191985: Tlab refills for ARM In-Reply-To: <1514484882.2264.6.camel@gmail.com> References: <356550c0-adb7-bc91-c28f-e1943fad0f81@oracle.com> <1513776075.2757.7.camel@gmail.com> <8d5adc6a-86f0-7c18-5785-97d163159af2@oracle.com> <1514484882.2264.6.camel@gmail.com> Message-ID: Perfect, thanks Edward for testing :) Jc On Thu, Dec 28, 2017 at 10:14 AM, Edward Nevill wrote: > Hi, > > I have built and tested this on a Samsung Chromebook (armv7l). > > The tests I ran were jtreg hotspot tests patched vs original in three configurations, default gc (g1gc), parallelgc and serialgc. The results in all cases were identical before and after patching. > > Default gc (g1gc): passed: 1,435; failed: 9; error: 116 > ParallelGC: passed: 1,331; failed: 8; error: 112 > SerialGC: passed: 1,326; failed: 7; error: 112 > > Patch looks good to me. > > All the best, > Ed. > > On Wed, 2017-12-20 at 09:06 -0800, JC Beyler wrote: >> Hi all, >> >> Thanks for taking a look at the webrev! >> >> Here is the change relative to jdk/hs: >> http://cr.openjdk.java.net/~jcbeyler/8191985/webrev.02/ >> >> Let me know what you think, hopefully I didn't make a mistake when >> making the webrev :) >> Jc >> >> >> On Wed, Dec 20, 2017 at 5:50 AM, Daniel D. Daugherty >> wrote: >> > On 12/20/17 8:21 AM, Edward Nevill wrote: >> > > >> > > Hi Robin, >> > > >> > > I have eyeballed this, comparing it against the x86 version, and it looks >> > > good to me. >> > > >> > > I'll try to build and test this, but it will probably be sometime between >> > > Christmas and New Year. >> > > >> > > Just to confirm, the repo I should be patching and building is the >> > > following? >> > > >> > > > From kim.barrett at oracle.com Tue Jan 2 21:41:48 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 2 Jan 2018 16:41:48 -0500 Subject: RFR: 8194312: Support parallel and concurrent JNI global handle processing Message-ID: <48A47626-1FB7-4215-8A8C-B66E8D01FB70@oracle.com> Please review this change to the implementation of JNI global and weak global handles, providing infrastructure for parallel and concurrent processing of such handles. This change introduces OopStorage, a data structure for managing off-heap references to objects allocated in the Java heap. JNI global and weak global handles are reimplemented using OopStorage, rather than using JNIHandleBlock. (JNI local handles continue to use JNIHandleBlock; the lifetime management and concurrency issues are very different for local vs global handles.) This change does not change any GCs to use the new parallel and concurrent capabilities, only laying the foundations for doing so. Other uses of OopStorage are also being considered, in the context of runtime latency improvements for ZGC and other collectors. The idea is to change some (often weak) oop references in runtime data structures to OopStorage-managed handles, simplifying the GC processing and avoiding (potentially concurrent) GC walks of runtime data structures. As a side effect, this enhancement fixes these bugs: 8174790: Race adding (weak) global JNI handles and determining type of handle 8176454: Performance: jweak references not suitable for robust cache architecture Some things not addressed by this change include: - 8194309: JNI handle allocation failure not reported correctly For now, the pre-existing vm_exit_out_of_memory behavior is retained. - Updating JNIHandles to use the new Access protocol. - Serviceability Agent updates for OopStorage and JNI usage. Just enough has been done to allow existing SA tests to "pass". This will be addressed as a followup. CR: https://bugs.openjdk.java.net/browse/JDK-8194312 Webrev: http://cr.openjdk.java.net/~kbarrett/8194312/open.00/ Testing: Mach5 hs-tier1 through hs-tier5, jdk-nightly From vladimir.kozlov at oracle.com Tue Jan 2 23:21:53 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 2 Jan 2018 15:21:53 -0800 Subject: Request for sponsor: 8193260: AArch64: JVMCI: Implement trampoline calls In-Reply-To: References: Message-ID: Hi Andrew, It failed SPARC build since it missed implementation: "src/hotspot/cpu/sparc/jvmciCodeInstaller_sparc.cpp", line 118: Error: "CodeInstaller::pd_relocate_JavaMethod(Handle, int, Thread*)" was previously declared "CodeInstaller::pd_relocate_JavaMethod(CodeBuffer&, Handle, int, Thread*)". 1 Error(s) detected. Vladimir On 1/2/18 8:46 AM, Andrew Haley wrote: > This is already reviewed: it just needs somebody to push it through > jprt because it touches the shared JVMCI. Thanks. > > http://cr.openjdk.java.net/~aph/8193260-2/ > From kim.barrett at oracle.com Wed Jan 3 04:02:09 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 2 Jan 2018 23:02:09 -0500 Subject: RFR: 8194406: Use Atomic::replace_if_null Message-ID: <42C38DE3-03F5-484E-BD1A-7D2F715DFC75@oracle.com> Please review this change to use Atomic::replace_if_null where applicable. CR: https://bugs.openjdk.java.net/browse/JDK-8194406 Webrev: http://cr.openjdk.java.net/~kbarrett/8194406/open.00/ Testing: Mach5 hs-tier1,2,3 From david.holmes at oracle.com Wed Jan 3 04:41:44 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 3 Jan 2018 14:41:44 +1000 Subject: RFR: 8194406: Use Atomic::replace_if_null In-Reply-To: <42C38DE3-03F5-484E-BD1A-7D2F715DFC75@oracle.com> References: <42C38DE3-03F5-484E-BD1A-7D2F715DFC75@oracle.com> Message-ID: Hi Kim, On 3/01/2018 2:02 PM, Kim Barrett wrote: > Please review this change to use Atomic::replace_if_null where > applicable. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8194406 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8194406/open.00/ Looks good, but I also see: ./share/utilities/bitMap.cpp: if (Atomic::cmpxchg(table, &_pop_count_table, (BitMap::idx_t*)NULL) != NULL) { Thanks, David > Testing: > Mach5 hs-tier1,2,3 > From kim.barrett at oracle.com Wed Jan 3 08:15:48 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 3 Jan 2018 03:15:48 -0500 Subject: RFR: 8194406: Use Atomic::replace_if_null In-Reply-To: References: <42C38DE3-03F5-484E-BD1A-7D2F715DFC75@oracle.com> Message-ID: <38915D43-959C-4D9B-AA79-773629A7AB61@oracle.com> > On Jan 2, 2018, at 11:41 PM, David Holmes wrote: > > Hi Kim, > > On 3/01/2018 2:02 PM, Kim Barrett wrote: >> Please review this change to use Atomic::replace_if_null where >> applicable. >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8194406 >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8194406/open.00/ > > Looks good, but I also see: Thanks. > ./share/utilities/bitMap.cpp: if (Atomic::cmpxchg(table, &_pop_count_table, (BitMap::idx_t*)NULL) != NULL) { Thanks for spotting that one. From VicWang at zhaoxin.com Wed Jan 3 08:32:35 2018 From: VicWang at zhaoxin.com (Vic Wang(BJ-RD)) Date: Wed, 3 Jan 2018 08:32:35 +0000 Subject: =?utf-8?B?562U5aSNOiBbcGF0Y2hdIHN1cHBvcnQgemhhb3hpbiB4ODYgY3B1IHZlbmRv?= =?utf-8?Q?r_ids_CentaurHauls_and_Shanghai?= In-Reply-To: <3f71a3a2-624a-76c8-6d2d-0d3eca13c189@oracle.com> References: <3f71a3a2-624a-76c8-6d2d-0d3eca13c189@oracle.com> Message-ID: Hi David: I generate a patch using "hg diff". Please check it again. Thanks very much. diff -r 4d28288c9f9e src/hotspot/cpu/x86/assembler_x86.cpp --- a/src/hotspot/cpu/x86/assembler_x86.cppThu Dec 07 15:52:46 2017 +0100 +++ b/src/hotspot/cpu/x86/assembler_x86.cppWed Jan 03 16:04:30 2018 +0800 @@ -3167,6 +3167,89 @@ return; } + if (UseAddressNop && VM_Version::is_zx()) { + // + // Using multi-bytes nops "0x0F 0x1F [address]" for ZX + // 1: 0x90 + // 2: 0x66 0x90 + // 3: 0x66 0x66 0x90 (don't use "0x0F 0x1F 0x00" - need patching safe padding) + // 4: 0x0F 0x1F 0x40 0x00 + // 5: 0x0F 0x1F 0x44 0x00 0x00 + // 6: 0x66 0x0F 0x1F 0x44 0x00 0x00 + // 7: 0x0F 0x1F 0x80 0x00 0x00 0x00 0x00 + // 8: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 + // 9: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 + // 10: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 + // 11: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 + + // The rest coding is ZX specific - don't use consecutive address nops + + // 12: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 + // 13: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 + // 14: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 + // 15: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 + + while(i >= 15) { + // For ZX don't generate consecutive addess nops (mix with regular nops) + i -= 15; + emit_int8(0x66); // size prefix + emit_int8(0x66); // size prefix + emit_int8(0x66); // size prefix + addr_nop_8(); + emit_int8(0x66); // size prefix + emit_int8(0x66); // size prefix + emit_int8(0x66); // size prefix + emit_int8((unsigned char)0x90); + // nop + } + switch (i) { + case 14: + emit_int8(0x66); // size prefix + case 13: + emit_int8(0x66); // size prefix + case 12: + addr_nop_8(); + emit_int8(0x66); // size prefix + emit_int8(0x66); // size prefix + emit_int8(0x66); // size prefix + emit_int8((unsigned char)0x90); + // nop + break; + case 11: + emit_int8(0x66); // size prefix + case 10: + emit_int8(0x66); // size prefix + case 9: + emit_int8(0x66); // size prefix + case 8: + addr_nop_8(); + break; + case 7: + addr_nop_7(); + break; + case 6: + emit_int8(0x66); // size prefix + case 5: + addr_nop_5(); + break; + case 4: + addr_nop_4(); + break; + case 3: + // Don't use "0x0F 0x1F 0x00" - need patching safe padding + emit_int8(0x66); // size prefix + case 2: + emit_int8(0x66); // size prefix + case 1: + emit_int8((unsigned char)0x90); + // nop + break; + default: + assert(i == 0, " "); + } + return; + } + // Using nops with size prefixes "0x66 0x90". // From AMD Optimization Guide: // 1: 0x90 diff -r 4d28288c9f9e src/hotspot/cpu/x86/vm_version_x86.cpp --- a/src/hotspot/cpu/x86/vm_version_x86.cppThu Dec 07 15:52:46 2017 +0100 +++ b/src/hotspot/cpu/x86/vm_version_x86.cppWed Jan 03 16:04:30 2018 +0800 @@ -628,6 +628,11 @@ if (UseSSE < 1) _features &= ~CPU_SSE; + //since AVX instructions is slower than SSE in some ZX cpus, force USEAVX=0. + if(is_zx() && ((cpu_family()==6)||(cpu_family()==7))){ +UseAVX = 0; + } + // first try initial setting and detect what we can support int use_avx_limit = 0; if (UseAVX > 0) { @@ -1078,6 +1083,66 @@ // UseXmmRegToRegMoveAll == true --> movaps(xmm, xmm), movapd(xmm, xmm). // UseXmmRegToRegMoveAll == false --> movss(xmm, xmm), movsd(xmm, xmm). + + if( is_zx() ) { // ZX cpus specific settings + if( FLAG_IS_DEFAULT(UseStoreImmI16) ) { + UseStoreImmI16 = false; // don't use it on ZX cpus + } + if( (cpu_family() == 6)|| (cpu_family() == 7) ) { + if( FLAG_IS_DEFAULT(UseAddressNop) ) { + // Use it on all ZX cpus + UseAddressNop = true; + } + } + if( FLAG_IS_DEFAULT(UseXmmLoadAndClearUpper) ) { + UseXmmLoadAndClearUpper = true; // use movsd on all ZX cpus + } + if( FLAG_IS_DEFAULT(UseXmmRegToRegMoveAll) ) { + if( supports_sse3() ) { + UseXmmRegToRegMoveAll = true; // use movaps, movapd on new ZX cpus + } else { + UseXmmRegToRegMoveAll = false; + } + } + if( ((cpu_family() == 6)||(cpu_family() == 7)) && supports_sse3() ) { // new ZX cpus +#ifdef COMPILER2 + if( FLAG_IS_DEFAULT(MaxLoopPad) ) { + // For new ZX cpus do the next optimization: + // don't align the beginning of a loop if there are enough instructions + // left (NumberOfLoopInstrToAlign defined in c2_globals.hpp) + // in current fetch line (OptoLoopAlignment) or the padding + // is big (> MaxLoopPad). + // Set MaxLoopPad to 11 for new ZX cpus to reduce number of + // generated NOP instructions. 11 is the largest size of one + // address NOP instruction '0F 1F' (see Assembler::nop(i)). + MaxLoopPad = 11; + } +#endif // COMPILER2 + if (FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { + UseXMMForArrayCopy = true; // use SSE2 movq on new ZX cpus + } + if (supports_sse4_2()) { // new ZX cpus + if (FLAG_IS_DEFAULT(UseUnalignedLoadStores)) { + UseUnalignedLoadStores = true; // use movdqu on newest ZX cpus + } + } + if (supports_sse4_2()) { + if (FLAG_IS_DEFAULT(UseSSE42Intrinsics)) { + FLAG_SET_DEFAULT(UseSSE42Intrinsics, true); + } + } else { + if (UseSSE42Intrinsics && !FLAG_IS_DEFAULT(UseAESIntrinsics)) { + warning("SSE4.2 intrinsics require SSE4.2 instructions or higher. Intrinsics will be disabled."); + } + FLAG_SET_DEFAULT(UseSSE42Intrinsics, false); + } + } + + if(FLAG_IS_DEFAULT(AllocatePrefetchInstr) && supports_3dnow_prefetch()) { + FLAG_SET_DEFAULT(AllocatePrefetchInstr, 3); + } + } + if( is_amd() ) { // AMD cpus specific settings if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { // Use it on new AMD cpus starting from Opteron. @@ -1374,6 +1439,14 @@ #endif } + if (is_zx() && ((cpu_family() == 6)||(cpu_family() == 7)) && supports_sse3()) { +#ifdef COMPILER2 + if (FLAG_IS_DEFAULT(UseFPUForSpilling) && supports_sse4_2()) { + FLAG_SET_DEFAULT(UseFPUForSpilling, true); + } +#endif + } + #ifdef _LP64 // Prefetch settings diff -r 4d28288c9f9e src/hotspot/cpu/x86/vm_version_x86.hpp --- a/src/hotspot/cpu/x86/vm_version_x86.hppThu Dec 07 15:52:46 2017 +0100 +++ b/src/hotspot/cpu/x86/vm_version_x86.hppWed Jan 03 16:04:30 2018 +0800 @@ -305,6 +305,9 @@ enum Extended_Family { // AMD CPU_FAMILY_AMD_11H = 0x11, + // ZX + CPU_FAMILY_ZX_CORE_F6 = 6, +CPU_FAMILY_ZX_CORE_F7 = 7, // Intel CPU_FAMILY_INTEL_CORE = 6, CPU_MODEL_NEHALEM = 0x1e, @@ -549,6 +552,16 @@ } } +// ZX features. + if(is_zx()) { + if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) + result |= CPU_LZCNT; + // for ZX, ecx.bits.misalignsse bit (bit 8) indicates support for prefetchw + if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { + result |= CPU_3DNOW_PREFETCH; + } + } + return result; } @@ -657,6 +670,7 @@ static bool is_P6() { return cpu_family() >= 6; } static bool is_amd() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' static bool is_intel() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' + static bool is_zx() { assert_is_initialized(); return (_cpuid_info.std_vendor_name_0 == 0x746e6543)||(_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS ' static bool is_atom_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton static bool is_knights_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x57) || (extended_cpu_model() == 0x85))); } // Xeon Phi 3200/5200/7200 and Future Xeon Phi @@ -680,7 +694,16 @@ } } else if (is_amd()) { result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); - } + } else if (is_zx()) { + bool supports_topology = supports_processor_topology(); + if (supports_topology) { + result = _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus / + _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; + } + if (!supports_topology || result == 0) { + result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); + } +} return result; } @@ -688,7 +711,9 @@ uint result = 1; if (is_intel() && supports_processor_topology()) { result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; - } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { + } else if (is_zx() && supports_processor_topology()) { + result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; +} else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { if (cpu_family() >= 0x17) { result = _cpuid_info.ext_cpuid1E_ebx.bits.threads_per_core + 1; } else { @@ -705,7 +730,9 @@ result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); } else if (is_amd()) { result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; - } + } else if (is_zx()) { + result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); +} if (result < 32) // not defined ? result = 32; // 32 bytes by default on x86 and other x64 return result; Best Regards! VicWang | R&D Telephone:+86-01082695388-892477 -----????----- ???: David Holmes [mailto:david.holmes at oracle.com] ????: 2018?1?2? 5:18 ???: Vic Wang(BJ-RD) ; hotspot-dev at openjdk.java.net ??: Cobe Chen(BJ-RD) ??: Re: [patch] support zhaoxin x86 cpu vendor ids CentaurHauls and Shanghai Hi, I've created a JBS issue for this enhancement request: https://bugs.openjdk.java.net/browse/JDK-8194279 On 28/12/2017 4:59 PM, Vic Wang(BJ-RD) wrote: > Hi, > Here is a hotspot patch for supporting zhaoxin x86 cpu vendor ids (CentaurHauls id and Shanghai id). The original repository is http://hg.openjdk.java.net/jdk/hs. > Please help me to submit the changes . If there is anything incorrectly, please let me know. Thank you very much. > > The following is the changeset by the diff command. Can you generate a patch using "hg diff" or "hg export" please. The raw diff can't be applied directly to an existing repo without manual editing. Thanks, David > diff -Nur org/jdk/src/hotspot/cpu/x86/assembler_x86.cpp > zx/jdk/src/hotspot/cpu/x86/assembler_x86.cpp > --- org/jdk/src/hotspot/cpu/x86/assembler_x86.cpp2017-12-08 > 03:33:00.000000000 +0800 > +++ zx/jdk/src/hotspot/cpu/x86/assembler_x86.cpp2017-12-28 > +++ 11:31:30.000000000 +0800 > @@ -3167,6 +3167,89 @@ > return; > } > > + if (UseAddressNop && VM_Version::is_zx()) { > + // > + // Using multi-bytes nops "0x0F 0x1F [address]" for ZX > + // 1: 0x90 > + // 2: 0x66 0x90 > + // 3: 0x66 0x66 0x90 (don't use "0x0F 0x1F 0x00" - need patching safe padding) > + // 4: 0x0F 0x1F 0x40 0x00 > + // 5: 0x0F 0x1F 0x44 0x00 0x00 > + // 6: 0x66 0x0F 0x1F 0x44 0x00 0x00 > + // 7: 0x0F 0x1F 0x80 0x00 0x00 0x00 0x00 > + // 8: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > + // 9: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > + // 10: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > + // 11: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > + > + // The rest coding is ZX specific - don't use consecutive address > + nops > + > + // 12: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 > + // 13: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 > + // 14: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 > + // 15: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > + 0x66 0x66 0x66 0x90 > + > + while(i >= 15) { > + // For ZX don't generate consecutive addess nops (mix with regular nops) > + i -= 15; > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + addr_nop_8(); > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8((unsigned char)0x90); > + // nop > + } > + switch (i) { > + case 14: > + emit_int8(0x66); // size prefix > + case 13: > + emit_int8(0x66); // size prefix > + case 12: > + addr_nop_8(); > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8((unsigned char)0x90); > + // nop > + break; > + case 11: > + emit_int8(0x66); // size prefix > + case 10: > + emit_int8(0x66); // size prefix > + case 9: > + emit_int8(0x66); // size prefix > + case 8: > + addr_nop_8(); > + break; > + case 7: > + addr_nop_7(); > + break; > + case 6: > + emit_int8(0x66); // size prefix > + case 5: > + addr_nop_5(); > + break; > + case 4: > + addr_nop_4(); > + break; > + case 3: > + // Don't use "0x0F 0x1F 0x00" - need patching safe padding > + emit_int8(0x66); // size prefix > + case 2: > + emit_int8(0x66); // size prefix > + case 1: > + emit_int8((unsigned char)0x90); > + // nop > + break; > + default: > + assert(i == 0, " "); > + } > + return; > + } > + > // Using nops with size prefixes "0x66 0x90". > // From AMD Optimization Guide: > // 1: 0x90 > diff -Nur org/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp > zx/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp > --- org/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp2017-12-08 > 03:33:00.000000000 +0800 > +++ zx/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp2017-12-28 > +++ 11:30:40.000000000 +0800 > @@ -628,6 +628,11 @@ > if (UseSSE < 1) > _features &= ~CPU_SSE; > > + //since AVX instructions is slower than SSE in some ZX cpus, force USEAVX=0. > + if(is_zx() && ((cpu_family()==6)||(cpu_family()==7))){ > +UseAVX = 0; > + } > + > // first try initial setting and detect what we can support > int use_avx_limit = 0; > if (UseAVX > 0) { > @@ -1078,6 +1083,66 @@ > // UseXmmRegToRegMoveAll == true --> movaps(xmm, xmm), movapd(xmm, xmm). > // UseXmmRegToRegMoveAll == false --> movss(xmm, xmm), movsd(xmm, xmm). > > + > + if( is_zx() ) { // ZX cpus specific settings > + if( FLAG_IS_DEFAULT(UseStoreImmI16) ) { > + UseStoreImmI16 = false; // don't use it on ZX cpus > + } > + if( (cpu_family() == 6)|| (cpu_family() == 7) ) { > + if( FLAG_IS_DEFAULT(UseAddressNop) ) { > + // Use it on all ZX cpus > + UseAddressNop = true; > + } > + } > + if( FLAG_IS_DEFAULT(UseXmmLoadAndClearUpper) ) { > + UseXmmLoadAndClearUpper = true; // use movsd on all ZX cpus > + } > + if( FLAG_IS_DEFAULT(UseXmmRegToRegMoveAll) ) { > + if( supports_sse3() ) { > + UseXmmRegToRegMoveAll = true; // use movaps, movapd on new ZX cpus > + } else { > + UseXmmRegToRegMoveAll = false; > + } > + } > + if( ((cpu_family() == 6)||(cpu_family() == 7)) && supports_sse3() > +) { // new ZX cpus #ifdef COMPILER2 > + if( FLAG_IS_DEFAULT(MaxLoopPad) ) { > + // For new ZX cpus do the next optimization: > + // don't align the beginning of a loop if there are enough instructions > + // left (NumberOfLoopInstrToAlign defined in c2_globals.hpp) > + // in current fetch line (OptoLoopAlignment) or the padding > + // is big (> MaxLoopPad). > + // Set MaxLoopPad to 11 for new ZX cpus to reduce number of > + // generated NOP instructions. 11 is the largest size of one > + // address NOP instruction '0F 1F' (see Assembler::nop(i)). > + MaxLoopPad = 11; > + } > +#endif // COMPILER2 > + if (FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { > + UseXMMForArrayCopy = true; // use SSE2 movq on new ZX cpus > + } > + if (supports_sse4_2()) { // new ZX cpus > + if (FLAG_IS_DEFAULT(UseUnalignedLoadStores)) { > + UseUnalignedLoadStores = true; // use movdqu on newest ZX cpus > + } > + } > + if (supports_sse4_2()) { > + if (FLAG_IS_DEFAULT(UseSSE42Intrinsics)) { > + FLAG_SET_DEFAULT(UseSSE42Intrinsics, true); > + } > + } else { > + if (UseSSE42Intrinsics && !FLAG_IS_DEFAULT(UseAESIntrinsics)) { > + warning("SSE4.2 intrinsics require SSE4.2 instructions or higher. Intrinsics will be disabled."); > + } > + FLAG_SET_DEFAULT(UseSSE42Intrinsics, false); > + } > + } > + > + if(FLAG_IS_DEFAULT(AllocatePrefetchInstr) && supports_3dnow_prefetch()) { > + FLAG_SET_DEFAULT(AllocatePrefetchInstr, 3); > + } > + } > + > if( is_amd() ) { // AMD cpus specific settings > if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { > // Use it on new AMD cpus starting from Opteron. > @@ -1370,6 +1435,14 @@ > #ifdef COMPILER2 > if (FLAG_IS_DEFAULT(UseFPUForSpilling) && supports_sse4_2()) { > FLAG_SET_DEFAULT(UseFPUForSpilling, true); > + } > +#endif > + } > + > + if (is_zx() && ((cpu_family() == 6)||(cpu_family() == 7)) && > +supports_sse3()) { #ifdef COMPILER2 > + if (FLAG_IS_DEFAULT(UseFPUForSpilling) && supports_sse4_2()) { > + FLAG_SET_DEFAULT(UseFPUForSpilling, true); > } > #endif > } > diff -Nur org/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp > zx/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp > --- org/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp2017-12-08 > 03:33:00.000000000 +0800 > +++ zx/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp2017-12-28 > +++ 14:15:18.000000000 +0800 > @@ -305,6 +305,9 @@ > enum Extended_Family { > // AMD > CPU_FAMILY_AMD_11H = 0x11, > + // ZX > + CPU_FAMILY_ZX_CORE_F6 = 6, > + CPU_FAMILY_ZX_CORE_F7 = 7, > // Intel > CPU_FAMILY_INTEL_CORE = 6, > CPU_MODEL_NEHALEM = 0x1e, > @@ -549,6 +552,16 @@ > } > } > > +// ZX features. > + if(is_zx()) { > + if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) > + result |= CPU_LZCNT; > + // for ZX, ecx.bits.misalignsse bit (bit 8) indicates support for prefetchw > + if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { > + result |= CPU_3DNOW_PREFETCH; > + } > + } > + > return result; > } > > @@ -657,6 +670,7 @@ > static bool is_P6() { return cpu_family() >= 6; } > static bool is_amd() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' > static bool is_intel() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' > + static bool is_zx() { assert_is_initialized(); return (_cpuid_info.std_vendor_name_0 == 0x746e6543)||(_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS ' > static bool is_atom_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton > static bool is_knights_family() { return ((cpu_family() == 0x06) > && ((extended_cpu_model() == 0x57) || (extended_cpu_model() == > 0x85))); } // Xeon Phi 3200/5200/7200 and Future Xeon Phi > > @@ -680,7 +694,16 @@ > } > } else if (is_amd()) { > result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); > - } > + } else if (is_zx()) { > + bool supports_topology = supports_processor_topology(); > + if (supports_topology) { > + result = _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus / > + _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; > + } > + if (!supports_topology || result == 0) { > + result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); > + } > +} > return result; > } > > @@ -688,7 +711,9 @@ > uint result = 1; > if (is_intel() && supports_processor_topology()) { > result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; > - } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { > + } else if (is_zx() && supports_processor_topology()) { > + result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; > +} else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { > if (cpu_family() >= 0x17) { > result = _cpuid_info.ext_cpuid1E_ebx.bits.threads_per_core + 1; > } else { > @@ -705,7 +730,9 @@ > result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); > } else if (is_amd()) { > result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; > - } > + } else if (is_zx()) { > + result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); } > if (result < 32) // not defined ? > result = 32; // 32 bytes by default on x86 and other x64 > return result; > > Finally, running the jtreg test. I run 2 jtreg tests(jtreg:test/jdk:tier1 and jtreg:test/langtools:tier1) and both of them are pass. > The results are as follows. > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/jdk:tier1 1660 1660 0 0 > jtreg:test/langtools:tier1 3828 3828 0 0 > jtreg:test/nashorn:tier1 0 0 0 0 > jtreg:test/jaxp:tier1 0 0 0 0 > ============================== > TEST SUCCESS > > Best Regards! > VicWang | R&D > Telephone:+86-01082695388-892477 > > > ????? > ????????????????????????????????????????????????????? > CONFIDENTIAL NOTE: > This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited. > ????? ????????????????????????????????????????????????????? CONFIDENTIAL NOTE: This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited. From aph at redhat.com Wed Jan 3 09:31:58 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 3 Jan 2018 09:31:58 +0000 Subject: Request for sponsor: 8193260: AArch64: JVMCI: Implement trampoline calls In-Reply-To: References: Message-ID: <196de5dc-0a4e-e1dc-9608-e277e5d02fba@redhat.com> On 02/01/18 23:21, Vladimir Kozlov wrote: > It failed SPARC build since it missed implementation: > > "src/hotspot/cpu/sparc/jvmciCodeInstaller_sparc.cpp", line 118: Error: > "CodeInstaller::pd_relocate_JavaMethod(Handle, int, Thread*)" was previously declared > "CodeInstaller::pd_relocate_JavaMethod(CodeBuffer&, Handle, int, Thread*)". > 1 Error(s) detected. OK, thanks. I totally forgot that SPARC was supported. :-) Will fix. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From david.holmes at oracle.com Wed Jan 3 10:02:46 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 3 Jan 2018 20:02:46 +1000 Subject: =?UTF-8?Q?Re:_=e7=ad=94=e5=a4=8d:_[patch]_support_zhaoxin_x86_cpu_v?= =?UTF-8?Q?endor_ids_CentaurHauls_and_Shanghai?= In-Reply-To: References: <3f71a3a2-624a-76c8-6d2d-0d3eca13c189@oracle.com> Message-ID: <37eb76db-f9ca-d95d-e740-de7b315b3244@oracle.com> On 3/01/2018 6:32 PM, Vic Wang(BJ-RD) wrote: > Hi David: > I generate a patch using "hg diff". Please check it again. Thanks very much. Thanks. > diff -r 4d28288c9f9e src/hotspot/cpu/x86/assembler_x86.cpp > --- a/src/hotspot/cpu/x86/assembler_x86.cppThu Dec 07 15:52:46 2017 +0100 Something stripped out the spaces between the file name and timestamp. I've hosted a webrev for the patch at: http://cr.openjdk.java.net/~dholmes/8194279/webrev A few minor comments. I can't comment on the technical accuracy of course :) All copyright notices need the second year updated to 2018. - src/hotspot/cpu/x86/assembler_x86.cpp Seems fine - you copied the existing pattern so I won't call out any style bugs. :) --- - src/hotspot/cpu/x86/vm_version_x86.cpp 633 UseAVX = 0; Indention is missing. General style nit: your if statements are very inconsistently formatted. A statement like: if( is_zx() ) should be written: if (is_zx()) - space after the "if" and no space after ( or before ) In this block: + if (is_zx() && ((cpu_family() == 6)||(cpu_family() == 7)) && supports_sse3()) { + #ifdef COMPILER2 + if (FLAG_IS_DEFAULT(UseFPUForSpilling) && supports_sse4_2()) { + FLAG_SET_DEFAULT(UseFPUForSpilling, true); + } + #endif I see this copies the existing pattern but isn't it simpler just to write: if (is_zx() && ((cpu_family() == 6)||(cpu_family() == 7)) && supports_sse4_2()) { #ifdef COMPILER2 if (FLAG_IS_DEFAULT(UseFPUForSpilling)) { FLAG_SET_DEFAULT(UseFPUForSpilling, true); } #endif ? --- - src/hotspot/cpu/x86/vm_version_x86.hpp 310 CPU_FAMILY_ZX_CORE_F7 = 7, Indentation is missing. 555 // ZX features. Indentation is missing. 556 if(is_zx()) { 557 if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) 558 result |= CPU_LZCNT; 559 // for ZX, ecx.bits.misalignsse bit (bit 8) indicates support for prefetchw 560 if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { 561 result |= CPU_3DNOW_PREFETCH; 562 } 563 } The "intel" block you copied is full of style issues :( But as it is exactly the same can't you just adjust: 546 if(is_intel()) { to 546 if (is_intel() || is_zx()) { ? Similarly for cores_per_cpu(), threads_per_core() and L1_line_size(). Otherwise there are indentation issues in your changes to all those functions. Thanks, David ----- From stuart.monteith at linaro.org Wed Jan 3 13:53:07 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Wed, 3 Jan 2018 13:53:07 +0000 Subject: [aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV In-Reply-To: References: <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com> <20e812bc-d132-9863-815b-345283f9517e@redhat.com> Message-ID: Hello, I've redone the patch such that we're passing different values depending on whether we are dumping or are using shared classes. There is a point before this initialisation where the default is used, which is 4GB: http://cr.openjdk.java.net/~smonteith/8193266/webrev-3/ BR, Stuart On 18 December 2017 at 13:41, Stuart Monteith wrote: > Ok, the constant was just an attempt at reducing the likelihood of the > backend generating bad addresses if the range changes. We have a > testcase that might trip if the future changes. > > We'll need the 4GB limit during dumping the shared metaspace. During > runtime, we'll need the maximum size of the compressed metaspace. I > suppose that's the intention behind using CompressedClassSpaceSize. > I've just been checking to see if that still holds. > > BR, > Stuart > > > On 18 December 2017 at 09:15, Andrew Haley wrote: >> On 13/12/17 15:56, Stuart Monteith wrote: >>> I've moved the constant "UnscaledClassSpaceMax" from metaspace.cpp >>> and metaspaceShared.cpp >>> MetaspaceShared::initialize_dumptime_shared_and_meta_spaces. This is >>> the same value as UnscaledOopHeapMax. Perhaps that should be used >>> instead of UnscaledClassSpaceMax in all three places. >>> I'm using the constant in MacroAssembler_aarch64.hpp in the >>> MacroAssembler constructor instead of CompressedClassSpaceSize. >> >> I don't thing that really helps. We don't need a global constant >> which is the worst possible case for UnscaledClassSpaceMax because >> we already know what that is: it's 2**32. >> >> We need to know how much space is in use. >> >> -- >> Andrew Haley >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From coleen.phillimore at oracle.com Wed Jan 3 14:16:21 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 3 Jan 2018 09:16:21 -0500 Subject: RFR: 8194406: Use Atomic::replace_if_null In-Reply-To: <42C38DE3-03F5-484E-BD1A-7D2F715DFC75@oracle.com> References: <42C38DE3-03F5-484E-BD1A-7D2F715DFC75@oracle.com> Message-ID: Looks good. Coleen On 1/2/18 11:02 PM, Kim Barrett wrote: > Please review this change to use Atomic::replace_if_null where > applicable. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8194406 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8194406/open.00/ > > Testing: > Mach5 hs-tier1,2,3 > From aph at redhat.com Wed Jan 3 14:27:47 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 3 Jan 2018 14:27:47 +0000 Subject: [aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV In-Reply-To: References: <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com> <20e812bc-d132-9863-815b-345283f9517e@redhat.com> Message-ID: On 03/01/18 13:53, Stuart Monteith wrote: > I've redone the patch such that we're passing different values > depending on whether we are dumping or are using shared classes. There > is a point before this initialisation where the default is used, > which is 4GB: > > http://cr.openjdk.java.net/~smonteith/8193266/webrev-3/ That looks good, except that you seem to have deleted a line (by mistake?) in universe.hpp. If I were doing this, I'd also take the opportunity to calculate can_use_XOR once, and take it out of the Assembler's constructor. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Jan 3 17:36:59 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 3 Jan 2018 17:36:59 +0000 Subject: Request for sponsor: 8193260: AArch64: JVMCI: Implement trampoline calls In-Reply-To: References: Message-ID: <6da0bf5a-4a56-4409-1309-3b36885cb88d@redhat.com> On 02/01/18 23:21, Vladimir Kozlov wrote: > It failed SPARC build since it missed implementation: > > "src/hotspot/cpu/sparc/jvmciCodeInstaller_sparc.cpp", line 118: Error: > "CodeInstaller::pd_relocate_JavaMethod(Handle, int, Thread*)" was previously declared > "CodeInstaller::pd_relocate_JavaMethod(CodeBuffer&, Handle, int, Thread*)". > 1 Error(s) detected. Sorry about that. http://cr.openjdk.java.net/~aph/8193260-3 Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From kim.barrett at oracle.com Wed Jan 3 18:51:17 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 3 Jan 2018 13:51:17 -0500 Subject: RFR: 8194406: Use Atomic::replace_if_null In-Reply-To: References: <42C38DE3-03F5-484E-BD1A-7D2F715DFC75@oracle.com> Message-ID: <083BFDAC-1031-4795-8716-290F9F94DBE2@oracle.com> > On Jan 3, 2018, at 9:16 AM, coleen.phillimore at oracle.com wrote: > > Looks good. > Coleen Thanks. > > On 1/2/18 11:02 PM, Kim Barrett wrote: >> Please review this change to use Atomic::replace_if_null where >> applicable. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8194406 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8194406/open.00/ >> >> Testing: >> Mach5 hs-tier1,2,3 From vladimir.kozlov at oracle.com Wed Jan 3 19:27:40 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 3 Jan 2018 11:27:40 -0800 Subject: Request for sponsor: 8193260: AArch64: JVMCI: Implement trampoline calls In-Reply-To: <6da0bf5a-4a56-4409-1309-3b36885cb88d@redhat.com> References: <6da0bf5a-4a56-4409-1309-3b36885cb88d@redhat.com> Message-ID: <9137e39b-cd48-ad64-f41c-67744dde4bd3@oracle.com> Pushed. Vladimir On 1/3/18 9:36 AM, Andrew Haley wrote: > On 02/01/18 23:21, Vladimir Kozlov wrote: >> It failed SPARC build since it missed implementation: >> >> "src/hotspot/cpu/sparc/jvmciCodeInstaller_sparc.cpp", line 118: Error: >> "CodeInstaller::pd_relocate_JavaMethod(Handle, int, Thread*)" was previously declared >> "CodeInstaller::pd_relocate_JavaMethod(CodeBuffer&, Handle, int, Thread*)". >> 1 Error(s) detected. > > Sorry about that. > > http://cr.openjdk.java.net/~aph/8193260-3 > > Thanks. > From kim.barrett at oracle.com Thu Jan 4 07:57:35 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 4 Jan 2018 02:57:35 -0500 Subject: RFR: 8194406: Use Atomic::replace_if_null In-Reply-To: <38915D43-959C-4D9B-AA79-773629A7AB61@oracle.com> References: <42C38DE3-03F5-484E-BD1A-7D2F715DFC75@oracle.com> <38915D43-959C-4D9B-AA79-773629A7AB61@oracle.com> Message-ID: <18CD9B86-36F6-4D81-9C32-7B677B8BC9F1@oracle.com> > On Jan 3, 2018, at 3:15 AM, Kim Barrett wrote: > >> On Jan 2, 2018, at 11:41 PM, David Holmes wrote: > >> ./share/utilities/bitMap.cpp: if (Atomic::cmpxchg(table, &_pop_count_table, (BitMap::idx_t*)NULL) != NULL) { > > Thanks for spotting that one. I missed that one because my grep pattern didn't include qualified type names in the cast. Fixing my search, I didn't find any other calls to update. Here's the updated webrev: http://cr.openjdk.java.net/~kbarrett/8194406/open.01/ Only change is to bitMap.cpp. From VicWang at zhaoxin.com Thu Jan 4 08:35:30 2018 From: VicWang at zhaoxin.com (Vic Wang(BJ-RD)) Date: Thu, 4 Jan 2018 08:35:30 +0000 Subject: =?utf-8?B?562U5aSNOiDnrZTlpI06IFtwYXRjaF0gc3VwcG9ydCB6aGFveGluIHg4NiBj?= =?utf-8?Q?pu_vendor_ids_CentaurHauls_and_Shanghai?= In-Reply-To: <37eb76db-f9ca-d95d-e740-de7b315b3244@oracle.com> References: <3f71a3a2-624a-76c8-6d2d-0d3eca13c189@oracle.com> <37eb76db-f9ca-d95d-e740-de7b315b3244@oracle.com> Message-ID: Hi David: Thanks for the detailed review. I've regenerated the patch by "hg diff" for modifying the coding style issues. Additionally, I don't merge some of the branches into intel's because it may add some codes when the new cpu features are added. diff -r 4d28288c9f9e src/hotspot/cpu/x86/assembler_x86.cpp --- a/src/hotspot/cpu/x86/assembler_x86.cppThu Dec 07 15:52:46 2017 +0100 +++ b/src/hotspot/cpu/x86/assembler_x86.cppThu Jan 04 12:20:31 2018 +0800 @@ -3167,6 +3167,89 @@ return; } + if (UseAddressNop && VM_Version::is_zx()) { + // + // Using multi-bytes nops "0x0F 0x1F [address]" for ZX + // 1: 0x90 + // 2: 0x66 0x90 + // 3: 0x66 0x66 0x90 (don't use "0x0F 0x1F 0x00" - need patching safe padding) + // 4: 0x0F 0x1F 0x40 0x00 + // 5: 0x0F 0x1F 0x44 0x00 0x00 + // 6: 0x66 0x0F 0x1F 0x44 0x00 0x00 + // 7: 0x0F 0x1F 0x80 0x00 0x00 0x00 0x00 + // 8: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 + // 9: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 + // 10: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 + // 11: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 + + // The rest coding is ZX specific - don't use consecutive address nops + + // 12: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 + // 13: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 + // 14: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 + // 15: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 + + while(i >= 15) { + // For ZX don't generate consecutive addess nops (mix with regular nops) + i -= 15; + emit_int8(0x66); // size prefix + emit_int8(0x66); // size prefix + emit_int8(0x66); // size prefix + addr_nop_8(); + emit_int8(0x66); // size prefix + emit_int8(0x66); // size prefix + emit_int8(0x66); // size prefix + emit_int8((unsigned char)0x90); + // nop + } + switch (i) { + case 14: + emit_int8(0x66); // size prefix + case 13: + emit_int8(0x66); // size prefix + case 12: + addr_nop_8(); + emit_int8(0x66); // size prefix + emit_int8(0x66); // size prefix + emit_int8(0x66); // size prefix + emit_int8((unsigned char)0x90); + // nop + break; + case 11: + emit_int8(0x66); // size prefix + case 10: + emit_int8(0x66); // size prefix + case 9: + emit_int8(0x66); // size prefix + case 8: + addr_nop_8(); + break; + case 7: + addr_nop_7(); + break; + case 6: + emit_int8(0x66); // size prefix + case 5: + addr_nop_5(); + break; + case 4: + addr_nop_4(); + break; + case 3: + // Don't use "0x0F 0x1F 0x00" - need patching safe padding + emit_int8(0x66); // size prefix + case 2: + emit_int8(0x66); // size prefix + case 1: + emit_int8((unsigned char)0x90); + // nop + break; + default: + assert(i == 0, " "); + } + return; + } + // Using nops with size prefixes "0x66 0x90". // From AMD Optimization Guide: // 1: 0x90 diff -r 4d28288c9f9e src/hotspot/cpu/x86/vm_version_x86.cpp --- a/src/hotspot/cpu/x86/vm_version_x86.cppThu Dec 07 15:52:46 2017 +0100 +++ b/src/hotspot/cpu/x86/vm_version_x86.cppThu Jan 04 12:20:31 2018 +0800 @@ -628,6 +628,11 @@ if (UseSSE < 1) _features &= ~CPU_SSE; + //since AVX instructions is slower than SSE in some ZX cpus, force USEAVX=0. + if (is_zx() && ((cpu_family() == 6) || (cpu_family() == 7))){ +UseAVX = 0; + } + // first try initial setting and detect what we can support int use_avx_limit = 0; if (UseAVX > 0) { @@ -1078,6 +1083,66 @@ // UseXmmRegToRegMoveAll == true --> movaps(xmm, xmm), movapd(xmm, xmm). // UseXmmRegToRegMoveAll == false --> movss(xmm, xmm), movsd(xmm, xmm). + + if (is_zx()) { // ZX cpus specific settings + if (FLAG_IS_DEFAULT(UseStoreImmI16)) { + UseStoreImmI16 = false; // don't use it on ZX cpus + } + if ((cpu_family() == 6) || (cpu_family() == 7)) { + if (FLAG_IS_DEFAULT(UseAddressNop)) { + // Use it on all ZX cpus + UseAddressNop = true; + } + } + if (FLAG_IS_DEFAULT(UseXmmLoadAndClearUpper)) { + UseXmmLoadAndClearUpper = true; // use movsd on all ZX cpus + } + if (FLAG_IS_DEFAULT(UseXmmRegToRegMoveAll)) { + if (supports_sse3()) { + UseXmmRegToRegMoveAll = true; // use movaps, movapd on new ZX cpus + } else { + UseXmmRegToRegMoveAll = false; + } + } + if (((cpu_family() == 6) || (cpu_family() == 7)) && supports_sse3()) { // new ZX cpus +#ifdef COMPILER2 + if (FLAG_IS_DEFAULT(MaxLoopPad)) { + // For new ZX cpus do the next optimization: + // don't align the beginning of a loop if there are enough instructions + // left (NumberOfLoopInstrToAlign defined in c2_globals.hpp) + // in current fetch line (OptoLoopAlignment) or the padding + // is big (> MaxLoopPad). + // Set MaxLoopPad to 11 for new ZX cpus to reduce number of + // generated NOP instructions. 11 is the largest size of one + // address NOP instruction '0F 1F' (see Assembler::nop(i)). + MaxLoopPad = 11; + } +#endif // COMPILER2 + if (FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { + UseXMMForArrayCopy = true; // use SSE2 movq on new ZX cpus + } + if (supports_sse4_2()) { // new ZX cpus + if (FLAG_IS_DEFAULT(UseUnalignedLoadStores)) { + UseUnalignedLoadStores = true; // use movdqu on newest ZX cpus + } + } + if (supports_sse4_2()) { + if (FLAG_IS_DEFAULT(UseSSE42Intrinsics)) { + FLAG_SET_DEFAULT(UseSSE42Intrinsics, true); + } + } else { + if (UseSSE42Intrinsics && !FLAG_IS_DEFAULT(UseAESIntrinsics)) { + warning("SSE4.2 intrinsics require SSE4.2 instructions or higher. Intrinsics will be disabled."); + } + FLAG_SET_DEFAULT(UseSSE42Intrinsics, false); + } + } + + if (FLAG_IS_DEFAULT(AllocatePrefetchInstr) && supports_3dnow_prefetch()) { + FLAG_SET_DEFAULT(AllocatePrefetchInstr, 3); + } + } + if( is_amd() ) { // AMD cpus specific settings if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { // Use it on new AMD cpus starting from Opteron. @@ -1374,6 +1439,14 @@ #endif } + if (is_zx() && ((cpu_family() == 6) || (cpu_family() == 7)) && supports_sse4_2()) { +#ifdef COMPILER2 + if (FLAG_IS_DEFAULT(UseFPUForSpilling)) { + FLAG_SET_DEFAULT(UseFPUForSpilling, true); + } +#endif + } + #ifdef _LP64 // Prefetch settings diff -r 4d28288c9f9e src/hotspot/cpu/x86/vm_version_x86.hpp --- a/src/hotspot/cpu/x86/vm_version_x86.hppThu Dec 07 15:52:46 2017 +0100 +++ b/src/hotspot/cpu/x86/vm_version_x86.hppThu Jan 04 12:20:31 2018 +0800 @@ -305,6 +305,9 @@ enum Extended_Family { // AMD CPU_FAMILY_AMD_11H = 0x11, + // ZX + CPU_FAMILY_ZX_CORE_F6 = 6, + CPU_FAMILY_ZX_CORE_F7 = 7, // Intel CPU_FAMILY_INTEL_CORE = 6, CPU_MODEL_NEHALEM = 0x1e, @@ -549,6 +552,16 @@ } } + // ZX features. + if (is_zx()) { + if (_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) + result |= CPU_LZCNT; + // for ZX, ecx.bits.misalignsse bit (bit 8) indicates support for prefetchw + if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { + result |= CPU_3DNOW_PREFETCH; + } + } + return result; } @@ -657,6 +670,7 @@ static bool is_P6() { return cpu_family() >= 6; } static bool is_amd() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' static bool is_intel() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' + static bool is_zx() { assert_is_initialized(); return (_cpuid_info.std_vendor_name_0 == 0x746e6543) || (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS ' static bool is_atom_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton static bool is_knights_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x57) || (extended_cpu_model() == 0x85))); } // Xeon Phi 3200/5200/7200 and Future Xeon Phi @@ -680,6 +694,15 @@ } } else if (is_amd()) { result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); + } else if (is_zx()) { + bool supports_topology = supports_processor_topology(); + if (supports_topology) { + result = _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus / + _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; + } + if (!supports_topology || result == 0) { + result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); + } } return result; } @@ -688,6 +711,8 @@ uint result = 1; if (is_intel() && supports_processor_topology()) { result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; + } else if (is_zx() && supports_processor_topology()) { + result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { if (cpu_family() >= 0x17) { result = _cpuid_info.ext_cpuid1E_ebx.bits.threads_per_core + 1; @@ -705,6 +730,8 @@ result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); } else if (is_amd()) { result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; + } else if (is_zx()) { + result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); } if (result < 32) // not defined ? result = 32; // 32 bytes by default on x86 and other x64 Best Regards! VicWang | R&D Telephone:+86-01082695388-892477 -----????----- ???: David Holmes [mailto:david.holmes at oracle.com] ????: 2018?1?3? 18:03 ???: Vic Wang(BJ-RD) ; hotspot-dev at openjdk.java.net ??: Cobe Chen(BJ-RD) ??: Re: ??: [patch] support zhaoxin x86 cpu vendor ids CentaurHauls and Shanghai On 3/01/2018 6:32 PM, Vic Wang(BJ-RD) wrote: > Hi David: > I generate a patch using "hg diff". Please check it again. Thanks very much. Thanks. > diff -r 4d28288c9f9e src/hotspot/cpu/x86/assembler_x86.cpp > --- a/src/hotspot/cpu/x86/assembler_x86.cppThu Dec 07 15:52:46 2017 > +0100 Something stripped out the spaces between the file name and timestamp. I've hosted a webrev for the patch at: http://cr.openjdk.java.net/~dholmes/8194279/webrev A few minor comments. I can't comment on the technical accuracy of course :) All copyright notices need the second year updated to 2018. - src/hotspot/cpu/x86/assembler_x86.cpp Seems fine - you copied the existing pattern so I won't call out any style bugs. :) --- - src/hotspot/cpu/x86/vm_version_x86.cpp 633 UseAVX = 0; Indention is missing. General style nit: your if statements are very inconsistently formatted. A statement like: if( is_zx() ) should be written: if (is_zx()) - space after the "if" and no space after ( or before ) In this block: + if (is_zx() && ((cpu_family() == 6)||(cpu_family() == 7)) && supports_sse3()) { + #ifdef COMPILER2 + if (FLAG_IS_DEFAULT(UseFPUForSpilling) && supports_sse4_2()) { + FLAG_SET_DEFAULT(UseFPUForSpilling, true); + } + #endif I see this copies the existing pattern but isn't it simpler just to write: if (is_zx() && ((cpu_family() == 6)||(cpu_family() == 7)) && supports_sse4_2()) { #ifdef COMPILER2 if (FLAG_IS_DEFAULT(UseFPUForSpilling)) { FLAG_SET_DEFAULT(UseFPUForSpilling, true); } #endif ? --- - src/hotspot/cpu/x86/vm_version_x86.hpp 310 CPU_FAMILY_ZX_CORE_F7 = 7, Indentation is missing. 555 // ZX features. Indentation is missing. 556 if(is_zx()) { 557 if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) 558 result |= CPU_LZCNT; 559 // for ZX, ecx.bits.misalignsse bit (bit 8) indicates support for prefetchw 560 if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { 561 result |= CPU_3DNOW_PREFETCH; 562 } 563 } The "intel" block you copied is full of style issues :( But as it is exactly the same can't you just adjust: 546 if(is_intel()) { to 546 if (is_intel() || is_zx()) { ? Similarly for cores_per_cpu(), threads_per_core() and L1_line_size(). Otherwise there are indentation issues in your changes to all those functions. Thanks, David ----- ????? ????????????????????????????????????????????????????? CONFIDENTIAL NOTE: This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited. From stuart.monteith at linaro.org Thu Jan 4 11:35:03 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Thu, 4 Jan 2018 11:35:03 +0000 Subject: [aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV In-Reply-To: References: <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com> <20e812bc-d132-9863-815b-345283f9517e@redhat.com> Message-ID: Hello, Yes, I deleted a line by mistake. I've moved the calculation, as you suggest, and hold the result in Universe: http://cr.openjdk.java.net/~smonteith/8193266/webrev-4/ I've changed the type of use_XOR_for_compressed_class_base from uint64_t to bool, I saw no reason for it to be anything else. BR, Stuart On 3 January 2018 at 14:27, Andrew Haley wrote: > On 03/01/18 13:53, Stuart Monteith wrote: >> I've redone the patch such that we're passing different values >> depending on whether we are dumping or are using shared classes. There >> is a point before this initialisation where the default is used, >> which is 4GB: >> >> http://cr.openjdk.java.net/~smonteith/8193266/webrev-3/ > > That looks good, except that you seem to have deleted a line > (by mistake?) in universe.hpp. > > If I were doing this, I'd also take the opportunity to calculate > can_use_XOR once, and take it out of the Assembler's constructor. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From david.holmes at oracle.com Thu Jan 4 11:54:35 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 4 Jan 2018 21:54:35 +1000 Subject: RFR: 8194406: Use Atomic::replace_if_null In-Reply-To: <18CD9B86-36F6-4D81-9C32-7B677B8BC9F1@oracle.com> References: <42C38DE3-03F5-484E-BD1A-7D2F715DFC75@oracle.com> <38915D43-959C-4D9B-AA79-773629A7AB61@oracle.com> <18CD9B86-36F6-4D81-9C32-7B677B8BC9F1@oracle.com> Message-ID: Looks good. Thanks, David On 4/01/2018 5:57 PM, Kim Barrett wrote: >> On Jan 3, 2018, at 3:15 AM, Kim Barrett wrote: >> >>> On Jan 2, 2018, at 11:41 PM, David Holmes wrote: >> >>> ./share/utilities/bitMap.cpp: if (Atomic::cmpxchg(table, &_pop_count_table, (BitMap::idx_t*)NULL) != NULL) { >> >> Thanks for spotting that one. > > I missed that one because my grep pattern didn't include qualified > type names in the cast. Fixing my search, I didn't find any other > calls to update. > > Here's the updated webrev: > http://cr.openjdk.java.net/~kbarrett/8194406/open.01/ > > Only change is to bitMap.cpp. > From david.holmes at oracle.com Thu Jan 4 12:20:07 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 4 Jan 2018 22:20:07 +1000 Subject: [patch] support zhaoxin x86 cpu vendor ids CentaurHauls and Shanghai In-Reply-To: References: <3f71a3a2-624a-76c8-6d2d-0d3eca13c189@oracle.com> <37eb76db-f9ca-d95d-e740-de7b315b3244@oracle.com> Message-ID: <7f8ad836-e510-554f-3128-9c7e2c4c1c7f@oracle.com> Hi, On 4/01/2018 6:35 PM, Vic Wang(BJ-RD) wrote: > Hi David: > Thanks for the detailed review. > I've regenerated the patch by "hg diff" for modifying the coding style issues. > Additionally, I don't merge some of the branches into intel's because it may add some codes when the new cpu features are added. Okay this all seems fine. I've updated the webrev in place and fixed the copyright years and a couple of space/indent issues: http://cr.openjdk.java.net/~dholmes/8194279/webrev if you'd like to check it. Also please advise how you wish the "contributed-by:" line to appear. For now I'm assuming: contributed-by: Vic Wang We still need a second reviewer. Thanks, David > > diff -r 4d28288c9f9e src/hotspot/cpu/x86/assembler_x86.cpp > --- a/src/hotspot/cpu/x86/assembler_x86.cppThu Dec 07 15:52:46 2017 +0100 > +++ b/src/hotspot/cpu/x86/assembler_x86.cppThu Jan 04 12:20:31 2018 +0800 > @@ -3167,6 +3167,89 @@ > return; > } > > + if (UseAddressNop && VM_Version::is_zx()) { > + // > + // Using multi-bytes nops "0x0F 0x1F [address]" for ZX > + // 1: 0x90 > + // 2: 0x66 0x90 > + // 3: 0x66 0x66 0x90 (don't use "0x0F 0x1F 0x00" - need patching safe padding) > + // 4: 0x0F 0x1F 0x40 0x00 > + // 5: 0x0F 0x1F 0x44 0x00 0x00 > + // 6: 0x66 0x0F 0x1F 0x44 0x00 0x00 > + // 7: 0x0F 0x1F 0x80 0x00 0x00 0x00 0x00 > + // 8: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > + // 9: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > + // 10: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > + // 11: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 > + > + // The rest coding is ZX specific - don't use consecutive address nops > + > + // 12: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 > + // 13: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 > + // 14: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 > + // 15: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 > + > + while(i >= 15) { > + // For ZX don't generate consecutive addess nops (mix with regular nops) > + i -= 15; > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + addr_nop_8(); > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8((unsigned char)0x90); > + // nop > + } > + switch (i) { > + case 14: > + emit_int8(0x66); // size prefix > + case 13: > + emit_int8(0x66); // size prefix > + case 12: > + addr_nop_8(); > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8(0x66); // size prefix > + emit_int8((unsigned char)0x90); > + // nop > + break; > + case 11: > + emit_int8(0x66); // size prefix > + case 10: > + emit_int8(0x66); // size prefix > + case 9: > + emit_int8(0x66); // size prefix > + case 8: > + addr_nop_8(); > + break; > + case 7: > + addr_nop_7(); > + break; > + case 6: > + emit_int8(0x66); // size prefix > + case 5: > + addr_nop_5(); > + break; > + case 4: > + addr_nop_4(); > + break; > + case 3: > + // Don't use "0x0F 0x1F 0x00" - need patching safe padding > + emit_int8(0x66); // size prefix > + case 2: > + emit_int8(0x66); // size prefix > + case 1: > + emit_int8((unsigned char)0x90); > + // nop > + break; > + default: > + assert(i == 0, " "); > + } > + return; > + } > + > // Using nops with size prefixes "0x66 0x90". > // From AMD Optimization Guide: > // 1: 0x90 > diff -r 4d28288c9f9e src/hotspot/cpu/x86/vm_version_x86.cpp > --- a/src/hotspot/cpu/x86/vm_version_x86.cppThu Dec 07 15:52:46 2017 +0100 > +++ b/src/hotspot/cpu/x86/vm_version_x86.cppThu Jan 04 12:20:31 2018 +0800 > @@ -628,6 +628,11 @@ > if (UseSSE < 1) > _features &= ~CPU_SSE; > > + //since AVX instructions is slower than SSE in some ZX cpus, force USEAVX=0. > + if (is_zx() && ((cpu_family() == 6) || (cpu_family() == 7))){ > +UseAVX = 0; > + } > + > // first try initial setting and detect what we can support > int use_avx_limit = 0; > if (UseAVX > 0) { > @@ -1078,6 +1083,66 @@ > // UseXmmRegToRegMoveAll == true --> movaps(xmm, xmm), movapd(xmm, xmm). > // UseXmmRegToRegMoveAll == false --> movss(xmm, xmm), movsd(xmm, xmm). > > + > + if (is_zx()) { // ZX cpus specific settings > + if (FLAG_IS_DEFAULT(UseStoreImmI16)) { > + UseStoreImmI16 = false; // don't use it on ZX cpus > + } > + if ((cpu_family() == 6) || (cpu_family() == 7)) { > + if (FLAG_IS_DEFAULT(UseAddressNop)) { > + // Use it on all ZX cpus > + UseAddressNop = true; > + } > + } > + if (FLAG_IS_DEFAULT(UseXmmLoadAndClearUpper)) { > + UseXmmLoadAndClearUpper = true; // use movsd on all ZX cpus > + } > + if (FLAG_IS_DEFAULT(UseXmmRegToRegMoveAll)) { > + if (supports_sse3()) { > + UseXmmRegToRegMoveAll = true; // use movaps, movapd on new ZX cpus > + } else { > + UseXmmRegToRegMoveAll = false; > + } > + } > + if (((cpu_family() == 6) || (cpu_family() == 7)) && supports_sse3()) { // new ZX cpus > +#ifdef COMPILER2 > + if (FLAG_IS_DEFAULT(MaxLoopPad)) { > + // For new ZX cpus do the next optimization: > + // don't align the beginning of a loop if there are enough instructions > + // left (NumberOfLoopInstrToAlign defined in c2_globals.hpp) > + // in current fetch line (OptoLoopAlignment) or the padding > + // is big (> MaxLoopPad). > + // Set MaxLoopPad to 11 for new ZX cpus to reduce number of > + // generated NOP instructions. 11 is the largest size of one > + // address NOP instruction '0F 1F' (see Assembler::nop(i)). > + MaxLoopPad = 11; > + } > +#endif // COMPILER2 > + if (FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { > + UseXMMForArrayCopy = true; // use SSE2 movq on new ZX cpus > + } > + if (supports_sse4_2()) { // new ZX cpus > + if (FLAG_IS_DEFAULT(UseUnalignedLoadStores)) { > + UseUnalignedLoadStores = true; // use movdqu on newest ZX cpus > + } > + } > + if (supports_sse4_2()) { > + if (FLAG_IS_DEFAULT(UseSSE42Intrinsics)) { > + FLAG_SET_DEFAULT(UseSSE42Intrinsics, true); > + } > + } else { > + if (UseSSE42Intrinsics && !FLAG_IS_DEFAULT(UseAESIntrinsics)) { > + warning("SSE4.2 intrinsics require SSE4.2 instructions or higher. Intrinsics will be disabled."); > + } > + FLAG_SET_DEFAULT(UseSSE42Intrinsics, false); > + } > + } > + > + if (FLAG_IS_DEFAULT(AllocatePrefetchInstr) && supports_3dnow_prefetch()) { > + FLAG_SET_DEFAULT(AllocatePrefetchInstr, 3); > + } > + } > + > if( is_amd() ) { // AMD cpus specific settings > if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { > // Use it on new AMD cpus starting from Opteron. > @@ -1374,6 +1439,14 @@ > #endif > } > > + if (is_zx() && ((cpu_family() == 6) || (cpu_family() == 7)) && supports_sse4_2()) { > +#ifdef COMPILER2 > + if (FLAG_IS_DEFAULT(UseFPUForSpilling)) { > + FLAG_SET_DEFAULT(UseFPUForSpilling, true); > + } > +#endif > + } > + > #ifdef _LP64 > // Prefetch settings > > diff -r 4d28288c9f9e src/hotspot/cpu/x86/vm_version_x86.hpp > --- a/src/hotspot/cpu/x86/vm_version_x86.hppThu Dec 07 15:52:46 2017 +0100 > +++ b/src/hotspot/cpu/x86/vm_version_x86.hppThu Jan 04 12:20:31 2018 +0800 > @@ -305,6 +305,9 @@ > enum Extended_Family { > // AMD > CPU_FAMILY_AMD_11H = 0x11, > + // ZX > + CPU_FAMILY_ZX_CORE_F6 = 6, > + CPU_FAMILY_ZX_CORE_F7 = 7, > // Intel > CPU_FAMILY_INTEL_CORE = 6, > CPU_MODEL_NEHALEM = 0x1e, > @@ -549,6 +552,16 @@ > } > } > > + // ZX features. > + if (is_zx()) { > + if (_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) > + result |= CPU_LZCNT; > + // for ZX, ecx.bits.misalignsse bit (bit 8) indicates support for prefetchw > + if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { > + result |= CPU_3DNOW_PREFETCH; > + } > + } > + > return result; > } > > @@ -657,6 +670,7 @@ > static bool is_P6() { return cpu_family() >= 6; } > static bool is_amd() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' > static bool is_intel() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' > + static bool is_zx() { assert_is_initialized(); return (_cpuid_info.std_vendor_name_0 == 0x746e6543) || (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS ' > static bool is_atom_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton > static bool is_knights_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x57) || (extended_cpu_model() == 0x85))); } // Xeon Phi 3200/5200/7200 and Future Xeon Phi > > @@ -680,6 +694,15 @@ > } > } else if (is_amd()) { > result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); > + } else if (is_zx()) { > + bool supports_topology = supports_processor_topology(); > + if (supports_topology) { > + result = _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus / > + _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; > + } > + if (!supports_topology || result == 0) { > + result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); > + } > } > return result; > } > @@ -688,6 +711,8 @@ > uint result = 1; > if (is_intel() && supports_processor_topology()) { > result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; > + } else if (is_zx() && supports_processor_topology()) { > + result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; > } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { > if (cpu_family() >= 0x17) { > result = _cpuid_info.ext_cpuid1E_ebx.bits.threads_per_core + 1; > @@ -705,6 +730,8 @@ > result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); > } else if (is_amd()) { > result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; > + } else if (is_zx()) { > + result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); > } > if (result < 32) // not defined ? > result = 32; // 32 bytes by default on x86 and other x64 > > > Best Regards! > VicWang | R&D > Telephone:+86-01082695388-892477 > -----????----- > ???: David Holmes [mailto:david.holmes at oracle.com] > ????: 2018?1?3? 18:03 > ???: Vic Wang(BJ-RD) ; hotspot-dev at openjdk.java.net > ??: Cobe Chen(BJ-RD) > ??: Re: ??: [patch] support zhaoxin x86 cpu vendor ids CentaurHauls and Shanghai > > On 3/01/2018 6:32 PM, Vic Wang(BJ-RD) wrote: >> Hi David: >> I generate a patch using "hg diff". Please check it again. Thanks very much. > > Thanks. > >> diff -r 4d28288c9f9e src/hotspot/cpu/x86/assembler_x86.cpp >> --- a/src/hotspot/cpu/x86/assembler_x86.cppThu Dec 07 15:52:46 2017 >> +0100 > > Something stripped out the spaces between the file name and timestamp. > > I've hosted a webrev for the patch at: > > http://cr.openjdk.java.net/~dholmes/8194279/webrev > > > A few minor comments. I can't comment on the technical accuracy of course :) > > All copyright notices need the second year updated to 2018. > > - src/hotspot/cpu/x86/assembler_x86.cpp > > Seems fine - you copied the existing pattern so I won't call out any style bugs. :) > > --- > > - src/hotspot/cpu/x86/vm_version_x86.cpp > > 633 UseAVX = 0; > > Indention is missing. > > General style nit: your if statements are very inconsistently formatted. > A statement like: > > if( is_zx() ) > > should be written: > > if (is_zx()) > > - space after the "if" and no space after ( or before ) > > > In this block: > > + if (is_zx() && ((cpu_family() == 6)||(cpu_family() == 7)) && > supports_sse3()) { > + #ifdef COMPILER2 > + if (FLAG_IS_DEFAULT(UseFPUForSpilling) && supports_sse4_2()) { > + FLAG_SET_DEFAULT(UseFPUForSpilling, true); > + } > + #endif > > I see this copies the existing pattern but isn't it simpler just to write: > > if (is_zx() && ((cpu_family() == 6)||(cpu_family() == 7)) && > supports_sse4_2()) { > #ifdef COMPILER2 > if (FLAG_IS_DEFAULT(UseFPUForSpilling)) { > FLAG_SET_DEFAULT(UseFPUForSpilling, true); > } > #endif > > ? > > --- > > - src/hotspot/cpu/x86/vm_version_x86.hpp > > 310 CPU_FAMILY_ZX_CORE_F7 = 7, > > Indentation is missing. > > 555 // ZX features. > > Indentation is missing. > > 556 if(is_zx()) { > 557 if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) > 558 result |= CPU_LZCNT; > 559 // for ZX, ecx.bits.misalignsse bit (bit 8) indicates > support for prefetchw > 560 if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { > 561 result |= CPU_3DNOW_PREFETCH; > 562 } > 563 } > > The "intel" block you copied is full of style issues :( But as it is exactly the same can't you just adjust: > > 546 if(is_intel()) { > > to > > 546 if (is_intel() || is_zx()) { > > ? Similarly for cores_per_cpu(), threads_per_core() and L1_line_size(). > > Otherwise there are indentation issues in your changes to all those functions. > > Thanks, > David > ----- > > > ????? > ????????????????????????????????????????????????????? > CONFIDENTIAL NOTE: > This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited. > From coleen.phillimore at oracle.com Thu Jan 4 14:26:42 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 4 Jan 2018 09:26:42 -0500 Subject: [aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV In-Reply-To: References: <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com> <20e812bc-d132-9863-815b-345283f9517e@redhat.com> Message-ID: Hi I was going to offer to sponsor this since it touches shared code but I'm not sure I like that there's AARCH64 specific code in universe.cpp/hpp.?? And the name is somewhat offputting, suggesting implementation details of one target leaking into shared code. set_use_XOR_for_compressed_class_base I think webrev-3 looked more reasonable, and could elide the #ifdef AARCH64 in the shared code for that version.?? And the indentation is better. Coleen On 1/4/18 6:35 AM, Stuart Monteith wrote: > Hello, > Yes, I deleted a line by mistake. I've moved the calculation, as you > suggest, and hold the result in Universe: > > http://cr.openjdk.java.net/~smonteith/8193266/webrev-4/ > > I've changed the type of use_XOR_for_compressed_class_base from > uint64_t to bool, I saw no reason for it to be anything else. > > BR, > Stuart > > On 3 January 2018 at 14:27, Andrew Haley wrote: >> On 03/01/18 13:53, Stuart Monteith wrote: >>> I've redone the patch such that we're passing different values >>> depending on whether we are dumping or are using shared classes. There >>> is a point before this initialisation where the default is used, >>> which is 4GB: >>> >>> http://cr.openjdk.java.net/~smonteith/8193266/webrev-3/ >> That looks good, except that you seem to have deleted a line >> (by mistake?) in universe.hpp. >> >> If I were doing this, I'd also take the opportunity to calculate >> can_use_XOR once, and take it out of the Assembler's constructor. >> >> -- >> Andrew Haley >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Jan 4 14:45:16 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 4 Jan 2018 14:45:16 +0000 Subject: [aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV In-Reply-To: References: <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com> <20e812bc-d132-9863-815b-345283f9517e@redhat.com> Message-ID: <3c83440f-dd4b-f988-1f96-afa88dff36eb@redhat.com> Hi, On 04/01/18 14:26, coleen.phillimore at oracle.com wrote: > I was going to offer to sponsor this since it touches shared code but > I'm not sure I like that there's AARCH64 specific code in > universe.cpp/hpp. And the name is somewhat offputting, suggesting > implementation details of one target leaking into shared code. > > set_use_XOR_for_compressed_class_base > > I think webrev-3 looked more reasonable, and could elide the #ifdef > AARCH64 in the shared code for that version. And the indentation is > better. I hate the #ifdef AARCH64 stuff too, but it's always a sign that there is something wrong with the front-end to back-end modularization. We can handle the use_XOR_for_compressed_class_base later: we really should have a way to communicate with the back ends when the memory layout is initialized. We can go with webrev-3. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From stuart.monteith at linaro.org Thu Jan 4 14:56:05 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Thu, 4 Jan 2018 14:56:05 +0000 Subject: [aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV In-Reply-To: References: <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com> <20e812bc-d132-9863-815b-345283f9517e@redhat.com> Message-ID: Thank you for looking at it Coleen. I share your dissatisfaction with webrev-4. I an uneasy about solving the problem in this way, as before given narrow_klass_base and CompressedClassSpaceSize, you would know what addresses to expect. However, this contract changed when during dumping the class space size changes to 4GB, and CompressedClassSpaceSize no longer matched this size. So webrev-3 is my attempt to work round this by ignoring CompressedClassSpaceSize and have another value tell us what we really want to know. The name is perhaps less than ideal, but it really does contain an implementation detail leaking into shared code. Perhaps I misunderstood Andrew's intentions. BR, Stuart On 4 January 2018 at 14:26, wrote: > Hi I was going to offer to sponsor this since it touches shared code but I'm > not sure I like that there's AARCH64 specific code in universe.cpp/hpp. > And the name is somewhat offputting, suggesting implementation details of > one target leaking into shared code. > > set_use_XOR_for_compressed_class_base > > I think webrev-3 looked more reasonable, and could elide the #ifdef AARCH64 > in the shared code for that version. And the indentation is better. > > Coleen > > > On 1/4/18 6:35 AM, Stuart Monteith wrote: >> >> Hello, >> Yes, I deleted a line by mistake. I've moved the calculation, as you >> suggest, and hold the result in Universe: >> >> http://cr.openjdk.java.net/~smonteith/8193266/webrev-4/ >> >> I've changed the type of use_XOR_for_compressed_class_base from >> uint64_t to bool, I saw no reason for it to be anything else. >> >> BR, >> Stuart >> >> On 3 January 2018 at 14:27, Andrew Haley wrote: >>> >>> On 03/01/18 13:53, Stuart Monteith wrote: >>>> >>>> I've redone the patch such that we're passing different values >>>> depending on whether we are dumping or are using shared classes. There >>>> is a point before this initialisation where the default is used, >>>> which is 4GB: >>>> >>>> http://cr.openjdk.java.net/~smonteith/8193266/webrev-3/ >>> >>> That looks good, except that you seem to have deleted a line >>> (by mistake?) in universe.hpp. >>> >>> If I were doing this, I'd also take the opportunity to calculate >>> can_use_XOR once, and take it out of the Assembler's constructor. >>> >>> -- >>> Andrew Haley >>> Java Platform Lead Engineer >>> Red Hat UK Ltd. >>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > From vladimir.kozlov at oracle.com Thu Jan 4 19:47:46 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 4 Jan 2018 11:47:46 -0800 Subject: [patch] support zhaoxin x86 cpu vendor ids CentaurHauls and Shanghai In-Reply-To: <7f8ad836-e510-554f-3128-9c7e2c4c1c7f@oracle.com> References: <3f71a3a2-624a-76c8-6d2d-0d3eca13c189@oracle.com> <37eb76db-f9ca-d95d-e740-de7b315b3244@oracle.com> <7f8ad836-e510-554f-3128-9c7e2c4c1c7f@oracle.com> Message-ID: Looks good to me. Thanks, Vladimir On 1/4/18 4:20 AM, David Holmes wrote: > Hi, > > On 4/01/2018 6:35 PM, Vic Wang(BJ-RD) wrote: >> Hi David: >> Thanks for the detailed review. >> I've regenerated the patch by "hg diff" for modifying the coding style issues. >> Additionally, I don't merge some of the branches into intel's because it may add some codes when >> the new cpu features are added. > > Okay this all seems fine. I've updated the webrev in place and fixed the copyright years and a > couple of space/indent issues: > > http://cr.openjdk.java.net/~dholmes/8194279/webrev > > if you'd like to check it. Also please advise how you wish the "contributed-by:" line to appear. For > now I'm assuming: > > contributed-by: Vic Wang > > We still need a second reviewer. > > Thanks, > David > >> >> diff -r 4d28288c9f9e src/hotspot/cpu/x86/assembler_x86.cpp >> --- a/src/hotspot/cpu/x86/assembler_x86.cppThu Dec 07 15:52:46 2017 +0100 >> +++ b/src/hotspot/cpu/x86/assembler_x86.cppThu Jan 04 12:20:31 2018 +0800 >> @@ -3167,6 +3167,89 @@ >> ????? return; >> ??? } >> >> +? if (UseAddressNop && VM_Version::is_zx()) { >> +??? // >> +??? // Using multi-bytes nops "0x0F 0x1F [address]" for ZX >> +??? //? 1: 0x90 >> +??? //? 2: 0x66 0x90 >> +??? //? 3: 0x66 0x66 0x90 (don't use "0x0F 0x1F 0x00" - need patching safe padding) >> +??? //? 4: 0x0F 0x1F 0x40 0x00 >> +??? //? 5: 0x0F 0x1F 0x44 0x00 0x00 >> +??? //? 6: 0x66 0x0F 0x1F 0x44 0x00 0x00 >> +??? //? 7: 0x0F 0x1F 0x80 0x00 0x00 0x00 0x00 >> +??? //? 8: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 >> +??? //? 9: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 >> +??? // 10: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 >> +??? // 11: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 >> + >> +??? // The rest coding is ZX specific - don't use consecutive address nops >> + >> +??? // 12: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 >> +??? // 13: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 >> +??? // 14: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 >> +??? // 15: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90 >> + >> +??? while(i >= 15) { >> +????? // For ZX don't generate consecutive addess nops (mix with regular nops) >> +????? i -= 15; >> +????? emit_int8(0x66);?? // size prefix >> +????? emit_int8(0x66);?? // size prefix >> +????? emit_int8(0x66);?? // size prefix >> +????? addr_nop_8(); >> +????? emit_int8(0x66);?? // size prefix >> +????? emit_int8(0x66);?? // size prefix >> +????? emit_int8(0x66);?? // size prefix >> +????? emit_int8((unsigned char)0x90); >> +???????????????????????? // nop >> +??? } >> +??? switch (i) { >> +????? case 14: >> +??????? emit_int8(0x66); // size prefix >> +????? case 13: >> +??????? emit_int8(0x66); // size prefix >> +????? case 12: >> +??????? addr_nop_8(); >> +??????? emit_int8(0x66); // size prefix >> +??????? emit_int8(0x66); // size prefix >> +??????? emit_int8(0x66); // size prefix >> +??????? emit_int8((unsigned char)0x90); >> +???????????????????????? // nop >> +??????? break; >> +????? case 11: >> +??????? emit_int8(0x66); // size prefix >> +????? case 10: >> +??????? emit_int8(0x66); // size prefix >> +????? case 9: >> +??????? emit_int8(0x66); // size prefix >> +????? case 8: >> +??????? addr_nop_8(); >> +??????? break; >> +????? case 7: >> +??????? addr_nop_7(); >> +??????? break; >> +????? case 6: >> +??????? emit_int8(0x66); // size prefix >> +????? case 5: >> +??????? addr_nop_5(); >> +??????? break; >> +????? case 4: >> +??????? addr_nop_4(); >> +??????? break; >> +????? case 3: >> +??????? // Don't use "0x0F 0x1F 0x00" - need patching safe padding >> +??????? emit_int8(0x66); // size prefix >> +????? case 2: >> +??????? emit_int8(0x66); // size prefix >> +????? case 1: >> +??????? emit_int8((unsigned char)0x90); >> +???????????????????????? // nop >> +??????? break; >> +????? default: >> +??????? assert(i == 0, " "); >> +??? } >> +??? return; >> +? } >> + >> ??? // Using nops with size prefixes "0x66 0x90". >> ??? // From AMD Optimization Guide: >> ??? //? 1: 0x90 >> diff -r 4d28288c9f9e src/hotspot/cpu/x86/vm_version_x86.cpp >> --- a/src/hotspot/cpu/x86/vm_version_x86.cppThu Dec 07 15:52:46 2017 +0100 >> +++ b/src/hotspot/cpu/x86/vm_version_x86.cppThu Jan 04 12:20:31 2018 +0800 >> @@ -628,6 +628,11 @@ >> ??? if (UseSSE < 1) >> ????? _features &= ~CPU_SSE; >> >> +? //since AVX instructions is slower than SSE in some ZX cpus, force USEAVX=0. >> +? if (is_zx() && ((cpu_family() == 6) || (cpu_family() == 7))){ >> +UseAVX = 0; >> +? } >> + >> ??? // first try initial setting and detect what we can support >> ??? int use_avx_limit = 0; >> ??? if (UseAVX > 0) { >> @@ -1078,6 +1083,66 @@ >> ??? // UseXmmRegToRegMoveAll == true? --> movaps(xmm, xmm), movapd(xmm, xmm). >> ??? // UseXmmRegToRegMoveAll == false --> movss(xmm, xmm),? movsd(xmm, xmm). >> >> + >> +? if (is_zx()) { // ZX cpus specific settings >> +??? if (FLAG_IS_DEFAULT(UseStoreImmI16)) { >> +????? UseStoreImmI16 = false; // don't use it on ZX cpus >> +??? } >> +??? if ((cpu_family() == 6) || (cpu_family() == 7)) { >> +????? if (FLAG_IS_DEFAULT(UseAddressNop)) { >> +??????? // Use it on all ZX cpus >> +??????? UseAddressNop = true; >> +????? } >> +??? } >> +??? if (FLAG_IS_DEFAULT(UseXmmLoadAndClearUpper)) { >> +????? UseXmmLoadAndClearUpper = true; // use movsd on all ZX cpus >> +??? } >> +??? if (FLAG_IS_DEFAULT(UseXmmRegToRegMoveAll)) { >> +????? if (supports_sse3()) { >> +??????? UseXmmRegToRegMoveAll = true; // use movaps, movapd on new ZX cpus >> +????? } else { >> +??????? UseXmmRegToRegMoveAll = false; >> +????? } >> +??? } >> +??? if (((cpu_family() == 6) || (cpu_family() == 7)) && supports_sse3()) { // new ZX cpus >> +#ifdef COMPILER2 >> +????? if (FLAG_IS_DEFAULT(MaxLoopPad)) { >> +??????? // For new ZX cpus do the next optimization: >> +??????? // don't align the beginning of a loop if there are enough instructions >> +??????? // left (NumberOfLoopInstrToAlign defined in c2_globals.hpp) >> +??????? // in current fetch line (OptoLoopAlignment) or the padding >> +??????? // is big (> MaxLoopPad). >> +??????? // Set MaxLoopPad to 11 for new ZX cpus to reduce number of >> +??????? // generated NOP instructions. 11 is the largest size of one >> +??????? // address NOP instruction '0F 1F' (see Assembler::nop(i)). >> +??????? MaxLoopPad = 11; >> +????? } >> +#endif // COMPILER2 >> +????? if (FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >> +??????? UseXMMForArrayCopy = true; // use SSE2 movq on new ZX cpus >> +????? } >> +????? if (supports_sse4_2()) { // new ZX cpus >> +??????? if (FLAG_IS_DEFAULT(UseUnalignedLoadStores)) { >> +????????? UseUnalignedLoadStores = true; // use movdqu on newest ZX cpus >> +??????? } >> +????? } >> +????? if (supports_sse4_2()) { >> +??????? if (FLAG_IS_DEFAULT(UseSSE42Intrinsics)) { >> +????????? FLAG_SET_DEFAULT(UseSSE42Intrinsics, true); >> +??????? } >> +????? } else { >> +??????? if (UseSSE42Intrinsics && !FLAG_IS_DEFAULT(UseAESIntrinsics)) { >> +????????? warning("SSE4.2 intrinsics require SSE4.2 instructions or higher. Intrinsics will be >> disabled."); >> +??????? } >> +??????? FLAG_SET_DEFAULT(UseSSE42Intrinsics, false); >> +????? } >> +??? } >> + >> +??? if (FLAG_IS_DEFAULT(AllocatePrefetchInstr) && supports_3dnow_prefetch()) { >> +????? FLAG_SET_DEFAULT(AllocatePrefetchInstr, 3); >> +??? } >> +? } >> + >> ??? if( is_amd() ) { // AMD cpus specific settings >> ????? if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { >> ??????? // Use it on new AMD cpus starting from Opteron. >> @@ -1374,6 +1439,14 @@ >> ? #endif >> ??? } >> >> +? if (is_zx() && ((cpu_family() == 6) || (cpu_family() == 7)) && supports_sse4_2()) { >> +#ifdef COMPILER2 >> +??? if (FLAG_IS_DEFAULT(UseFPUForSpilling)) { >> +????? FLAG_SET_DEFAULT(UseFPUForSpilling, true); >> +??? } >> +#endif >> +? } >> + >> ? #ifdef _LP64 >> ??? // Prefetch settings >> >> diff -r 4d28288c9f9e src/hotspot/cpu/x86/vm_version_x86.hpp >> --- a/src/hotspot/cpu/x86/vm_version_x86.hppThu Dec 07 15:52:46 2017 +0100 >> +++ b/src/hotspot/cpu/x86/vm_version_x86.hppThu Jan 04 12:20:31 2018 +0800 >> @@ -305,6 +305,9 @@ >> ??? enum Extended_Family { >> ????? // AMD >> ????? CPU_FAMILY_AMD_11H?????? = 0x11, >> +??? // ZX >> +??? CPU_FAMILY_ZX_CORE_F6??? = 6, >> +??? CPU_FAMILY_ZX_CORE_F7??? = 7, >> ????? // Intel >> ????? CPU_FAMILY_INTEL_CORE??? = 6, >> ????? CPU_MODEL_NEHALEM??????? = 0x1e, >> @@ -549,6 +552,16 @@ >> ??????? } >> ????? } >> >> +??? // ZX features. >> +??? if (is_zx()) { >> +????? if (_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) >> +??????? result |= CPU_LZCNT; >> +????? // for ZX, ecx.bits.misalignsse bit (bit 8) indicates support for prefetchw >> +????? if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { >> +??????? result |= CPU_3DNOW_PREFETCH; >> +????? } >> +??? } >> + >> ????? return result; >> ??? } >> >> @@ -657,6 +670,7 @@ >> ??? static bool is_P6()???????????? { return cpu_family() >= 6; } >> ??? static bool is_amd()??????????? { assert_is_initialized(); return >> _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' >> ??? static bool is_intel()????????? { assert_is_initialized(); return >> _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' >> +? static bool is_zx()???????????? { assert_is_initialized(); return >> (_cpuid_info.std_vendor_name_0 == 0x746e6543) || (_cpuid_info.std_vendor_name_0 == 0x68532020); } >> // 'tneC'||'hS? ' >> ??? static bool is_atom_family()??? { return ((cpu_family() == 0x06) && ((extended_cpu_model() == >> 0x36) || (extended_cpu_model() == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont and >> Centerton >> ??? static bool is_knights_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == >> 0x57) || (extended_cpu_model() == 0x85))); } // Xeon Phi 3200/5200/7200 and Future Xeon Phi >> >> @@ -680,6 +694,15 @@ >> ??????? } >> ????? } else if (is_amd()) { >> ??????? result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); >> +??? } else if (is_zx()) { >> +????? bool supports_topology = supports_processor_topology(); >> +????? if (supports_topology) { >> +??????? result = _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus / >> +???????????????? _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; >> +????? } >> +????? if (!supports_topology || result == 0) { >> +??????? result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); >> +????? } >> ????? } >> ????? return result; >> ??? } >> @@ -688,6 +711,8 @@ >> ????? uint result = 1; >> ????? if (is_intel() && supports_processor_topology()) { >> ??????? result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; >> +??? } else if (is_zx() && supports_processor_topology()) { >> +????? result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; >> ????? } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { >> ??????? if (cpu_family() >= 0x17) { >> ????????? result = _cpuid_info.ext_cpuid1E_ebx.bits.threads_per_core + 1; >> @@ -705,6 +730,8 @@ >> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >> ????? } else if (is_amd()) { >> ??????? result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; >> +??? } else if (is_zx()) { >> +????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >> ????? } >> ????? if (result < 32) // not defined ? >> ??????? result = 32;?? // 32 bytes by default on x86 and other x64 >> >> >> Best Regards! >> VicWang | R&D >> Telephone:+86-01082695388-892477 >> -----????----- >> ???: David Holmes [mailto:david.holmes at oracle.com] >> ????: 2018?1?3? 18:03 >> ???: Vic Wang(BJ-RD) ; hotspot-dev at openjdk.java.net >> ??: Cobe Chen(BJ-RD) >> ??: Re: ??: [patch] support zhaoxin x86 cpu vendor ids CentaurHauls and Shanghai >> >> On 3/01/2018 6:32 PM, Vic Wang(BJ-RD) wrote: >>> Hi David: >>> I generate a patch using "hg diff". Please check it again. Thanks very much. >> >> Thanks. >> >>> diff -r 4d28288c9f9e src/hotspot/cpu/x86/assembler_x86.cpp >>> --- a/src/hotspot/cpu/x86/assembler_x86.cppThu Dec 07 15:52:46 2017 >>> +0100 >> >> Something stripped out the spaces between the file name and timestamp. >> >> I've hosted a webrev for the patch at: >> >> http://cr.openjdk.java.net/~dholmes/8194279/webrev >> >> >> A few minor comments. I can't comment on the technical accuracy of course :) >> >> All copyright notices need the second year updated to 2018. >> >> - src/hotspot/cpu/x86/assembler_x86.cpp >> >> Seems fine - you copied the existing pattern so I won't call out any style bugs. :) >> >> --- >> >> - src/hotspot/cpu/x86/vm_version_x86.cpp >> >> 633 UseAVX = 0; >> >> Indention is missing. >> >> General style nit: your if statements are very inconsistently formatted. >> A statement like: >> >> if( is_zx() ) >> >> should be written: >> >> if (is_zx()) >> >> - space after the "if" and no space after ( or before ) >> >> >> In this block: >> >> +???? if (is_zx() && ((cpu_family() == 6)||(cpu_family() == 7)) && >> supports_sse3()) { >> + #ifdef COMPILER2 >> +???? if (FLAG_IS_DEFAULT(UseFPUForSpilling) && supports_sse4_2()) { >> +?????? FLAG_SET_DEFAULT(UseFPUForSpilling, true); >> +???? } >> + #endif >> >> I see this copies the existing pattern but isn't it simpler just to write: >> >> ????? if (is_zx() && ((cpu_family() == 6)||(cpu_family() == 7)) && >> supports_sse4_2()) { >> #ifdef COMPILER2 >> ????? if (FLAG_IS_DEFAULT(UseFPUForSpilling)) { >> ??????? FLAG_SET_DEFAULT(UseFPUForSpilling, true); >> ????? } >> #endif >> >> ? >> >> --- >> >> -? src/hotspot/cpu/x86/vm_version_x86.hpp >> >> 310 CPU_FAMILY_ZX_CORE_F7??? = 7, >> >> Indentation is missing. >> >> 555 // ZX features. >> >> Indentation is missing. >> >> ?? 556???? if(is_zx()) { >> ?? 557?????? if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) >> ?? 558???????? result |= CPU_LZCNT; >> ?? 559?????? // for ZX, ecx.bits.misalignsse bit (bit 8) indicates >> support for prefetchw >> ?? 560?????? if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { >> ?? 561???????? result |= CPU_3DNOW_PREFETCH; >> ?? 562?????? } >> ?? 563???? } >> >> The "intel" block you copied is full of style issues :( But as it is exactly the same can't you >> just adjust: >> >> 546???? if(is_intel()) { >> >> to >> >> 546???? if (is_intel() || is_zx()) { >> >> ? Similarly for cores_per_cpu(), threads_per_core() and L1_line_size(). >> >> Otherwise there are indentation issues in your changes to all those functions. >> >> Thanks, >> David >> ----- >> >> >> ????? >> ????????????????????????????????????????????????? >> ???? >> CONFIDENTIAL NOTE: >> This email contains confidential or legally privileged information and is for the sole use of its >> intended recipient. Any unauthorized review, use, copying or forwarding of this email or the >> content of this email is strictly prohibited. >> From kim.barrett at oracle.com Thu Jan 4 23:22:18 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 4 Jan 2018 18:22:18 -0500 Subject: RFR: 8194406: Use Atomic::replace_if_null In-Reply-To: References: <42C38DE3-03F5-484E-BD1A-7D2F715DFC75@oracle.com> <38915D43-959C-4D9B-AA79-773629A7AB61@oracle.com> <18CD9B86-36F6-4D81-9C32-7B677B8BC9F1@oracle.com> Message-ID: <088E9639-47A5-4770-9F7A-A4934E743152@oracle.com> > On Jan 4, 2018, at 6:54 AM, David Holmes wrote: > > Looks good. Thanks. > > Thanks, > David > > On 4/01/2018 5:57 PM, Kim Barrett wrote: >>> On Jan 3, 2018, at 3:15 AM, Kim Barrett wrote: >>> >>>> On Jan 2, 2018, at 11:41 PM, David Holmes wrote: >>> >>>> ./share/utilities/bitMap.cpp: if (Atomic::cmpxchg(table, &_pop_count_table, (BitMap::idx_t*)NULL) != NULL) { >>> >>> Thanks for spotting that one. >> I missed that one because my grep pattern didn't include qualified >> type names in the cast. Fixing my search, I didn't find any other >> calls to update. >> Here's the updated webrev: >> http://cr.openjdk.java.net/~kbarrett/8194406/open.01/ >> Only change is to bitMap.cpp. From VicWang at zhaoxin.com Fri Jan 5 01:54:14 2018 From: VicWang at zhaoxin.com (Vic Wang(BJ-RD)) Date: Fri, 5 Jan 2018 01:54:14 +0000 Subject: =?utf-8?B?562U5aSNOiBbcGF0Y2hdIHN1cHBvcnQgemhhb3hpbiB4ODYgY3B1IHZlbmRv?= =?utf-8?Q?r_ids_CentaurHauls_and_Shanghai?= In-Reply-To: References: <3f71a3a2-624a-76c8-6d2d-0d3eca13c189@oracle.com> <37eb76db-f9ca-d95d-e740-de7b315b3244@oracle.com> <7f8ad836-e510-554f-3128-9c7e2c4c1c7f@oracle.com> Message-ID: <5830414698174c66a771f117b7e8f77e@zhaoxin.com> Hi Vladimir and David: Thanks for the review. >if you'd like to check it. Also please advise how you wish the "contributed-by:" line to appear. For now I'm assuming: >contributed-by: Vic Wang You're right. Thanks. Vic -----????----- ???: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] ????: 2018?1?5? 3:48 ???: David Holmes ; Vic Wang(BJ-RD) ; hotspot-dev at openjdk.java.net ??: Cobe Chen(BJ-RD) ??: Re: [patch] support zhaoxin x86 cpu vendor ids CentaurHauls and Shanghai Looks good to me. Thanks, Vladimir On 1/4/18 4:20 AM, David Holmes wrote: > Hi, > > On 4/01/2018 6:35 PM, Vic Wang(BJ-RD) wrote: >> Hi David: >> Thanks for the detailed review. >> I've regenerated the patch by "hg diff" for modifying the coding style issues. >> Additionally, I don't merge some of the branches into intel's because >> it may add some codes when the new cpu features are added. > > Okay this all seems fine. I've updated the webrev in place and fixed > the copyright years and a couple of space/indent issues: > > http://cr.openjdk.java.net/~dholmes/8194279/webrev > > if you'd like to check it. Also please advise how you wish the > "contributed-by:" line to appear. For now I'm assuming: > > contributed-by: Vic Wang > > We still need a second reviewer. > > Thanks, > David > >> >> diff -r 4d28288c9f9e src/hotspot/cpu/x86/assembler_x86.cpp >> --- a/src/hotspot/cpu/x86/assembler_x86.cppThu Dec 07 15:52:46 2017 >> +0100 >> +++ b/src/hotspot/cpu/x86/assembler_x86.cppThu Jan 04 12:20:31 2018 >> +++ +0800 >> @@ -3167,6 +3167,89 @@ >> return; >> } >> >> + if (UseAddressNop && VM_Version::is_zx()) { >> + // >> + // Using multi-bytes nops "0x0F 0x1F [address]" for ZX >> + // 1: 0x90 >> + // 2: 0x66 0x90 >> + // 3: 0x66 0x66 0x90 (don't use "0x0F 0x1F 0x00" - need >> +patching safe padding) >> + // 4: 0x0F 0x1F 0x40 0x00 >> + // 5: 0x0F 0x1F 0x44 0x00 0x00 >> + // 6: 0x66 0x0F 0x1F 0x44 0x00 0x00 >> + // 7: 0x0F 0x1F 0x80 0x00 0x00 0x00 0x00 >> + // 8: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 >> + // 9: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 >> + // 10: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 >> + // 11: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 >> + >> + // The rest coding is ZX specific - don't use consecutive >> +address nops >> + >> + // 12: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 >> +0x90 >> + // 13: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 >> +0x66 0x90 >> + // 14: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 >> +0x66 0x66 0x90 >> + // 15: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 >> +0x66 0x66 0x66 0x90 >> + >> + while(i >= 15) { >> + // For ZX don't generate consecutive addess nops (mix with >> +regular nops) >> + i -= 15; >> + emit_int8(0x66); // size prefix >> + emit_int8(0x66); // size prefix >> + emit_int8(0x66); // size prefix >> + addr_nop_8(); >> + emit_int8(0x66); // size prefix >> + emit_int8(0x66); // size prefix >> + emit_int8(0x66); // size prefix >> + emit_int8((unsigned char)0x90); >> + // nop >> + } >> + switch (i) { >> + case 14: >> + emit_int8(0x66); // size prefix >> + case 13: >> + emit_int8(0x66); // size prefix >> + case 12: >> + addr_nop_8(); >> + emit_int8(0x66); // size prefix >> + emit_int8(0x66); // size prefix >> + emit_int8(0x66); // size prefix >> + emit_int8((unsigned char)0x90); >> + // nop >> + break; >> + case 11: >> + emit_int8(0x66); // size prefix >> + case 10: >> + emit_int8(0x66); // size prefix >> + case 9: >> + emit_int8(0x66); // size prefix >> + case 8: >> + addr_nop_8(); >> + break; >> + case 7: >> + addr_nop_7(); >> + break; >> + case 6: >> + emit_int8(0x66); // size prefix >> + case 5: >> + addr_nop_5(); >> + break; >> + case 4: >> + addr_nop_4(); >> + break; >> + case 3: >> + // Don't use "0x0F 0x1F 0x00" - need patching safe padding >> + emit_int8(0x66); // size prefix >> + case 2: >> + emit_int8(0x66); // size prefix >> + case 1: >> + emit_int8((unsigned char)0x90); >> + // nop >> + break; >> + default: >> + assert(i == 0, " "); >> + } >> + return; >> + } >> + >> // Using nops with size prefixes "0x66 0x90". >> // From AMD Optimization Guide: >> // 1: 0x90 >> diff -r 4d28288c9f9e src/hotspot/cpu/x86/vm_version_x86.cpp >> --- a/src/hotspot/cpu/x86/vm_version_x86.cppThu Dec 07 15:52:46 2017 >> +0100 >> +++ b/src/hotspot/cpu/x86/vm_version_x86.cppThu Jan 04 12:20:31 2018 >> +++ +0800 >> @@ -628,6 +628,11 @@ >> if (UseSSE < 1) >> _features &= ~CPU_SSE; >> >> + //since AVX instructions is slower than SSE in some ZX cpus, force USEAVX=0. >> + if (is_zx() && ((cpu_family() == 6) || (cpu_family() == 7))){ >> +UseAVX = 0; >> + } >> + >> // first try initial setting and detect what we can support >> int use_avx_limit = 0; >> if (UseAVX > 0) { >> @@ -1078,6 +1083,66 @@ >> // UseXmmRegToRegMoveAll == true --> movaps(xmm, xmm), movapd(xmm, xmm). >> // UseXmmRegToRegMoveAll == false --> movss(xmm, xmm), movsd(xmm, xmm). >> >> + >> + if (is_zx()) { // ZX cpus specific settings >> + if (FLAG_IS_DEFAULT(UseStoreImmI16)) { >> + UseStoreImmI16 = false; // don't use it on ZX cpus >> + } >> + if ((cpu_family() == 6) || (cpu_family() == 7)) { >> + if (FLAG_IS_DEFAULT(UseAddressNop)) { >> + // Use it on all ZX cpus >> + UseAddressNop = true; >> + } >> + } >> + if (FLAG_IS_DEFAULT(UseXmmLoadAndClearUpper)) { >> + UseXmmLoadAndClearUpper = true; // use movsd on all ZX cpus >> + } >> + if (FLAG_IS_DEFAULT(UseXmmRegToRegMoveAll)) { >> + if (supports_sse3()) { >> + UseXmmRegToRegMoveAll = true; // use movaps, movapd on new >> +ZX cpus >> + } else { >> + UseXmmRegToRegMoveAll = false; >> + } >> + } >> + if (((cpu_family() == 6) || (cpu_family() == 7)) && >> +supports_sse3()) { // new ZX cpus #ifdef COMPILER2 >> + if (FLAG_IS_DEFAULT(MaxLoopPad)) { >> + // For new ZX cpus do the next optimization: >> + // don't align the beginning of a loop if there are enough >> +instructions >> + // left (NumberOfLoopInstrToAlign defined in c2_globals.hpp) >> + // in current fetch line (OptoLoopAlignment) or the padding >> + // is big (> MaxLoopPad). >> + // Set MaxLoopPad to 11 for new ZX cpus to reduce number of >> + // generated NOP instructions. 11 is the largest size of one >> + // address NOP instruction '0F 1F' (see Assembler::nop(i)). >> + MaxLoopPad = 11; >> + } >> +#endif // COMPILER2 >> + if (FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >> + UseXMMForArrayCopy = true; // use SSE2 movq on new ZX cpus >> + } >> + if (supports_sse4_2()) { // new ZX cpus >> + if (FLAG_IS_DEFAULT(UseUnalignedLoadStores)) { >> + UseUnalignedLoadStores = true; // use movdqu on newest ZX >> +cpus >> + } >> + } >> + if (supports_sse4_2()) { >> + if (FLAG_IS_DEFAULT(UseSSE42Intrinsics)) { >> + FLAG_SET_DEFAULT(UseSSE42Intrinsics, true); >> + } >> + } else { >> + if (UseSSE42Intrinsics && >> +!FLAG_IS_DEFAULT(UseAESIntrinsics)) { >> + warning("SSE4.2 intrinsics require SSE4.2 instructions or >> +higher. Intrinsics will be >> disabled."); >> + } >> + FLAG_SET_DEFAULT(UseSSE42Intrinsics, false); >> + } >> + } >> + >> + if (FLAG_IS_DEFAULT(AllocatePrefetchInstr) && >> +supports_3dnow_prefetch()) { >> + FLAG_SET_DEFAULT(AllocatePrefetchInstr, 3); >> + } >> + } >> + >> if( is_amd() ) { // AMD cpus specific settings >> if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { >> // Use it on new AMD cpus starting from Opteron. >> @@ -1374,6 +1439,14 @@ >> #endif >> } >> >> + if (is_zx() && ((cpu_family() == 6) || (cpu_family() == 7)) && >> +supports_sse4_2()) { #ifdef COMPILER2 >> + if (FLAG_IS_DEFAULT(UseFPUForSpilling)) { >> + FLAG_SET_DEFAULT(UseFPUForSpilling, true); >> + } >> +#endif >> + } >> + >> #ifdef _LP64 >> // Prefetch settings >> >> diff -r 4d28288c9f9e src/hotspot/cpu/x86/vm_version_x86.hpp >> --- a/src/hotspot/cpu/x86/vm_version_x86.hppThu Dec 07 15:52:46 2017 >> +0100 >> +++ b/src/hotspot/cpu/x86/vm_version_x86.hppThu Jan 04 12:20:31 2018 >> +++ +0800 >> @@ -305,6 +305,9 @@ >> enum Extended_Family { >> // AMD >> CPU_FAMILY_AMD_11H = 0x11, >> + // ZX >> + CPU_FAMILY_ZX_CORE_F6 = 6, >> + CPU_FAMILY_ZX_CORE_F7 = 7, >> // Intel >> CPU_FAMILY_INTEL_CORE = 6, >> CPU_MODEL_NEHALEM = 0x1e, @@ -549,6 +552,16 @@ >> } >> } >> >> + // ZX features. >> + if (is_zx()) { >> + if (_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) >> + result |= CPU_LZCNT; >> + // for ZX, ecx.bits.misalignsse bit (bit 8) indicates support >> +for prefetchw >> + if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { >> + result |= CPU_3DNOW_PREFETCH; >> + } >> + } >> + >> return result; >> } >> >> @@ -657,6 +670,7 @@ >> static bool is_P6() { return cpu_family() >= 6; } >> static bool is_amd() { assert_is_initialized(); return >> _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' >> static bool is_intel() { assert_is_initialized(); return >> _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' >> + static bool is_zx() { assert_is_initialized(); return >> (_cpuid_info.std_vendor_name_0 == 0x746e6543) || >> (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS ' >> static bool is_atom_family() { return ((cpu_family() == 0x06) >> && ((extended_cpu_model() == >> 0x36) || (extended_cpu_model() == 0x37) || (extended_cpu_model() == >> 0x4D))); } //Silvermont and Centerton >> static bool is_knights_family() { return ((cpu_family() == 0x06) >> && ((extended_cpu_model() == >> 0x57) || (extended_cpu_model() == 0x85))); } // Xeon Phi >> 3200/5200/7200 and Future Xeon Phi >> >> @@ -680,6 +694,15 @@ >> } >> } else if (is_amd()) { >> result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); >> + } else if (is_zx()) { >> + bool supports_topology = supports_processor_topology(); >> + if (supports_topology) { >> + result = _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus / >> + _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; >> + } >> + if (!supports_topology || result == 0) { >> + result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + >> +1); >> + } >> } >> return result; >> } >> @@ -688,6 +711,8 @@ >> uint result = 1; >> if (is_intel() && supports_processor_topology()) { >> result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; >> + } else if (is_zx() && supports_processor_topology()) { >> + result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; >> } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { >> if (cpu_family() >= 0x17) { >> result = _cpuid_info.ext_cpuid1E_ebx.bits.threads_per_core >> + 1; @@ -705,6 +730,8 @@ >> result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >> } else if (is_amd()) { >> result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; >> + } else if (is_zx()) { >> + result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >> } >> if (result < 32) // not defined ? >> result = 32; // 32 bytes by default on x86 and other x64 >> >> >> Best Regards! >> VicWang | R&D >> Telephone:+86-01082695388-892477 >> -----????----- >> ???: David Holmes [mailto:david.holmes at oracle.com] >> ????: 2018?1?3? 18:03 >> ???: Vic Wang(BJ-RD) ; >> hotspot-dev at openjdk.java.net >> ??: Cobe Chen(BJ-RD) >> ??: Re: ??: [patch] support zhaoxin x86 cpu vendor ids CentaurHauls >> and Shanghai >> >> On 3/01/2018 6:32 PM, Vic Wang(BJ-RD) wrote: >>> Hi David: >>> I generate a patch using "hg diff". Please check it again. Thanks very much. >> >> Thanks. >> >>> diff -r 4d28288c9f9e src/hotspot/cpu/x86/assembler_x86.cpp >>> --- a/src/hotspot/cpu/x86/assembler_x86.cppThu Dec 07 15:52:46 2017 >>> +0100 >> >> Something stripped out the spaces between the file name and timestamp. >> >> I've hosted a webrev for the patch at: >> >> http://cr.openjdk.java.net/~dholmes/8194279/webrev >> >> >> A few minor comments. I can't comment on the technical accuracy of >> course :) >> >> All copyright notices need the second year updated to 2018. >> >> - src/hotspot/cpu/x86/assembler_x86.cpp >> >> Seems fine - you copied the existing pattern so I won't call out any >> style bugs. :) >> >> --- >> >> - src/hotspot/cpu/x86/vm_version_x86.cpp >> >> 633 UseAVX = 0; >> >> Indention is missing. >> >> General style nit: your if statements are very inconsistently formatted. >> A statement like: >> >> if( is_zx() ) >> >> should be written: >> >> if (is_zx()) >> >> - space after the "if" and no space after ( or before ) >> >> >> In this block: >> >> + if (is_zx() && ((cpu_family() == 6)||(cpu_family() == 7)) && >> supports_sse3()) { >> + #ifdef COMPILER2 >> + if (FLAG_IS_DEFAULT(UseFPUForSpilling) && supports_sse4_2()) { >> + FLAG_SET_DEFAULT(UseFPUForSpilling, true); >> + } >> + #endif >> >> I see this copies the existing pattern but isn't it simpler just to write: >> >> if (is_zx() && ((cpu_family() == 6)||(cpu_family() == 7)) && >> supports_sse4_2()) { >> #ifdef COMPILER2 >> if (FLAG_IS_DEFAULT(UseFPUForSpilling)) { >> FLAG_SET_DEFAULT(UseFPUForSpilling, true); >> } >> #endif >> >> ? >> >> --- >> >> - src/hotspot/cpu/x86/vm_version_x86.hpp >> >> 310 CPU_FAMILY_ZX_CORE_F7 = 7, >> >> Indentation is missing. >> >> 555 // ZX features. >> >> Indentation is missing. >> >> 556 if(is_zx()) { >> 557 if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) >> 558 result |= CPU_LZCNT; >> 559 // for ZX, ecx.bits.misalignsse bit (bit 8) indicates >> support for prefetchw >> 560 if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { >> 561 result |= CPU_3DNOW_PREFETCH; >> 562 } >> 563 } >> >> The "intel" block you copied is full of style issues :( But as it is >> exactly the same can't you just adjust: >> >> 546 if(is_intel()) { >> >> to >> >> 546 if (is_intel() || is_zx()) { >> >> ? Similarly for cores_per_cpu(), threads_per_core() and L1_line_size(). >> >> Otherwise there are indentation issues in your changes to all those functions. >> >> Thanks, >> David >> ----- >> >> >> ????? >> ????????????????????????????????????????????????? >> ???? >> CONFIDENTIAL NOTE: >> This email contains confidential or legally privileged information >> and is for the sole use of its intended recipient. Any unauthorized >> review, use, copying or forwarding of this email or the content of this email is strictly prohibited. >> ????? ????????????????????????????????????????????????????? CONFIDENTIAL NOTE: This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited. From coleen.phillimore at oracle.com Fri Jan 5 02:29:57 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 4 Jan 2018 21:29:57 -0500 Subject: RFR (M) 8058259: compute_offset() is confusing for static fields Message-ID: <26d630c4-19e7-f783-41c0-166a770578f8@oracle.com> Summary: remove most hard-coded offsets, have compute_offset function that takes a string and creates a TempNewSymbol, have static_field_addr() not add in InstanceMirrorKlass::offset_of_static_fields, ie use offset from find_field The jvmci code uses find_field to get the offset of static fields, then used static_field_addr() and then subtracted InstanceMirrorKlass::offset_of_static fields because the function expected the hardcoded offsets.? Removed hardcoded static offsets and non-static offsets where possible. This change also removes the nonproduct flag CheckAssertionStatusDirectives (default false). Tested with tier1-5 tests on Oracle platforms, and temporary code to get failures in known class layouts, and see error logging. open webrev at http://cr.openjdk.java.net/~coleenp/8058259.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8058259 thanks, Coleen From kim.barrett at oracle.com Fri Jan 5 06:51:23 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 5 Jan 2018 01:51:23 -0500 Subject: RFR (M) 8058259: compute_offset() is confusing for static fields In-Reply-To: <26d630c4-19e7-f783-41c0-166a770578f8@oracle.com> References: <26d630c4-19e7-f783-41c0-166a770578f8@oracle.com> Message-ID: <5965F467-C84B-4E98-8138-AE018A1107DB@oracle.com> > On Jan 4, 2018, at 9:29 PM, coleen.phillimore at oracle.com wrote: > > Summary: remove most hard-coded offsets, have compute_offset function that takes a string and creates a TempNewSymbol, have static_field_addr() not add in InstanceMirrorKlass::offset_of_static_fields, ie use offset from find_field > > The jvmci code uses find_field to get the offset of static fields, then used static_field_addr() and then subtracted InstanceMirrorKlass::offset_of_static fields because the function expected the hardcoded offsets. Removed hardcoded static offsets and non-static offsets where possible. > > This change also removes the nonproduct flag CheckAssertionStatusDirectives (default false). > > Tested with tier1-5 tests on Oracle platforms, and temporary code to get failures in known class layouts, and see error logging. > > open webrev at http://cr.openjdk.java.net/~coleenp/8058259.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8058259 > > thanks, > Coleen Looks good. Just a couple minor things. I don't need another webrev for any of these. ------------------------------------------------------------------------------ src/hotspot/share/classfile/javaClasses.cpp 1229 void java_lang_Thread::compute_offsets() { Wondering why some of the field names are referred to via vmSymbols::XXX_name(), while others use string constants? ------------------------------------------------------------------------------ src/hotspot/share/runtime/arguments.cpp 526 { "CheckAssertionStatusDirectives",JDK_Version::undefined(), JDK_Version::jdk(10), JDK_Version::jdk(11) }, Expired version should be jdk(12) rather than jdk(11). Obsolete version should be jdk(11) rather than jdk(10), but that may not be possible until we've updated to be building 11. ------------------------------------------------------------------------------ From edward.nevill at gmail.com Fri Jan 5 11:13:42 2018 From: edward.nevill at gmail.com (Edward Nevill) Date: Fri, 05 Jan 2018 11:13:42 +0000 Subject: RFR 8191985: Tlab refills for ARM In-Reply-To: References: <356550c0-adb7-bc91-c28f-e1943fad0f81@oracle.com> <1513776075.2757.7.camel@gmail.com> <8d5adc6a-86f0-7c18-5785-97d163159af2@oracle.com> <1514484882.2264.6.camel@gmail.com> Message-ID: <1515150822.4807.3.camel@gmail.com> Hi, Can this change be pushed to jdk/hs now? Have we got a formal Reviewer? I can push it if required. http://cr.openjdk.java.net/~jcbeyler/8191985/webrev.02/ https://bugs.openjdk.java.net/browse/JDK-8191985 All the best, Ed. On Tue, 2018-01-02 at 09:19 -0800, JC Beyler wrote: > Perfect, thanks Edward for testing :) > Jc > > > On Thu, Dec 28, 2017 at 10:14 AM, Edward Nevill com> wrote: > > Hi, > > > > I have built and tested this on a Samsung Chromebook (armv7l). > > > > The tests I ran were jtreg hotspot tests patched vs original in > > three configurations, default gc (g1gc), parallelgc and serialgc. > > The results in all cases were identical before and after patching. > > > > Default gc (g1gc): passed: 1,435; failed: 9; error: 116 > > ParallelGC: passed: 1,331; failed: 8; error: 112 > > SerialGC: passed: 1,326; failed: 7; error: 112 > > > > Patch looks good to me. > > > > All the best, > > Ed. > > > > On Wed, 2017-12-20 at 09:06 -0800, JC Beyler wrote: > > > Hi all, > > > > > > Thanks for taking a look at the webrev! > > > > > > Here is the change relative to jdk/hs: > > > http://cr.openjdk.java.net/~jcbeyler/8191985/webrev.02/ > > > > > > Let me know what you think, hopefully I didn't make a mistake > > > when > > > making the webrev :) > > > Jc > > > > > > From coleen.phillimore at oracle.com Fri Jan 5 13:25:27 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 5 Jan 2018 08:25:27 -0500 Subject: RFR (M) 8058259: compute_offset() is confusing for static fields In-Reply-To: <5965F467-C84B-4E98-8138-AE018A1107DB@oracle.com> References: <26d630c4-19e7-f783-41c0-166a770578f8@oracle.com> <5965F467-C84B-4E98-8138-AE018A1107DB@oracle.com> Message-ID: <007b7bb1-8d00-9100-05e5-858e2c27cf4a@oracle.com> Hi Kim,? Thanks for the review (and pre-review). On 1/5/18 1:51 AM, Kim Barrett wrote: >> On Jan 4, 2018, at 9:29 PM, coleen.phillimore at oracle.com wrote: >> >> Summary: remove most hard-coded offsets, have compute_offset function that takes a string and creates a TempNewSymbol, have static_field_addr() not add in InstanceMirrorKlass::offset_of_static_fields, ie use offset from find_field >> >> The jvmci code uses find_field to get the offset of static fields, then used static_field_addr() and then subtracted InstanceMirrorKlass::offset_of_static fields because the function expected the hardcoded offsets. Removed hardcoded static offsets and non-static offsets where possible. >> >> This change also removes the nonproduct flag CheckAssertionStatusDirectives (default false). >> >> Tested with tier1-5 tests on Oracle platforms, and temporary code to get failures in known class layouts, and see error logging. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8058259.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8058259 >> >> thanks, >> Coleen > Looks good. Just a couple minor things. I don't need another webrev > for any of these. > > ------------------------------------------------------------------------------ > src/hotspot/share/classfile/javaClasses.cpp > 1229 void java_lang_Thread::compute_offsets() { > > Wondering why some of the field names are referred to via > vmSymbols::XXX_name(), while others use string constants? I left some string constants because they were used more than once, so it seemed slightly better and not worth changing for consistency.? My main purpose of doing this was so when new fields are added for classes, they don't have to be added to vmSymbols. > > ------------------------------------------------------------------------------ > src/hotspot/share/runtime/arguments.cpp > 526 { "CheckAssertionStatusDirectives",JDK_Version::undefined(), JDK_Version::jdk(10), JDK_Version::jdk(11) }, > > Expired version should be jdk(12) rather than jdk(11). > > Obsolete version should be jdk(11) rather than jdk(10), but that may > not be possible until we've updated to be building 11. Oh I forgot to change that back.? I'm waiting for the version to change, then I'll change it to 11, 12. Thanks, Coleen > > ------------------------------------------------------------------------------ > From aph at redhat.com Fri Jan 5 17:15:40 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 5 Jan 2018 17:15:40 +0000 Subject: RFR 8191985: Tlab refills for ARM In-Reply-To: <1515150822.4807.3.camel@gmail.com> References: <356550c0-adb7-bc91-c28f-e1943fad0f81@oracle.com> <1513776075.2757.7.camel@gmail.com> <8d5adc6a-86f0-7c18-5785-97d163159af2@oracle.com> <1514484882.2264.6.camel@gmail.com> <1515150822.4807.3.camel@gmail.com> Message-ID: On 05/01/18 11:13, Edward Nevill wrote: > Can this change be pushed to jdk/hs now? Have we got a formal Reviewer? > I can push it if required. > > http://cr.openjdk.java.net/~jcbeyler/8191985/webrev.02/ > > https://bugs.openjdk.java.net/browse/JDK-8191985 OK. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From stuart.monteith at linaro.org Fri Jan 5 18:43:48 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Fri, 5 Jan 2018 18:43:48 +0000 Subject: [aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV In-Reply-To: <3c83440f-dd4b-f988-1f96-afa88dff36eb@redhat.com> References: <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com> <20e812bc-d132-9863-815b-345283f9517e@redhat.com> <3c83440f-dd4b-f988-1f96-afa88dff36eb@redhat.com> Message-ID: I've removed the AARCH64 conditionals, added the empty line I removed, and changed the type of "use_XOR_for_compressed_class_base" to bool. http://cr.openjdk.java.net/~smonteith/8193266/webrev-5/ BR, Stuart On 4 January 2018 at 14:45, Andrew Haley wrote: > Hi, > > On 04/01/18 14:26, coleen.phillimore at oracle.com wrote: >> I was going to offer to sponsor this since it touches shared code but >> I'm not sure I like that there's AARCH64 specific code in >> universe.cpp/hpp. And the name is somewhat offputting, suggesting >> implementation details of one target leaking into shared code. >> >> set_use_XOR_for_compressed_class_base >> >> I think webrev-3 looked more reasonable, and could elide the #ifdef >> AARCH64 in the shared code for that version. And the indentation is >> better. > > I hate the #ifdef AARCH64 stuff too, but it's always a sign that there > is something wrong with the front-end to back-end modularization. We > can handle the use_XOR_for_compressed_class_base later: we really > should have a way to communicate with the back ends when the memory > layout is initialized. We can go with webrev-3. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From kim.barrett at oracle.com Fri Jan 5 18:59:07 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 5 Jan 2018 13:59:07 -0500 Subject: RFR (M) 8058259: compute_offset() is confusing for static fields In-Reply-To: <007b7bb1-8d00-9100-05e5-858e2c27cf4a@oracle.com> References: <26d630c4-19e7-f783-41c0-166a770578f8@oracle.com> <5965F467-C84B-4E98-8138-AE018A1107DB@oracle.com> <007b7bb1-8d00-9100-05e5-858e2c27cf4a@oracle.com> Message-ID: > On Jan 5, 2018, at 8:25 AM, coleen.phillimore at oracle.com wrote: > > Hi Kim, Thanks for the review (and pre-review). > > On 1/5/18 1:51 AM, Kim Barrett wrote: >>> On Jan 4, 2018, at 9:29 PM, coleen.phillimore at oracle.com wrote: >>> >>> Summary: remove most hard-coded offsets, have compute_offset function that takes a string and creates a TempNewSymbol, have static_field_addr() not add in InstanceMirrorKlass::offset_of_static_fields, ie use offset from find_field >>> >>> The jvmci code uses find_field to get the offset of static fields, then used static_field_addr() and then subtracted InstanceMirrorKlass::offset_of_static fields because the function expected the hardcoded offsets. Removed hardcoded static offsets and non-static offsets where possible. >>> >>> This change also removes the nonproduct flag CheckAssertionStatusDirectives (default false). >>> >>> Tested with tier1-5 tests on Oracle platforms, and temporary code to get failures in known class layouts, and see error logging. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8058259.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8058259 >>> >>> thanks, >>> Coleen >> Looks good. Just a couple minor things. I don't need another webrev >> for any of these. >> >> ------------------------------------------------------------------------------ >> src/hotspot/share/classfile/javaClasses.cpp >> 1229 void java_lang_Thread::compute_offsets() { >> >> Wondering why some of the field names are referred to via >> vmSymbols::XXX_name(), while others use string constants? > > I left some string constants because they were used more than once, so it seemed slightly better and not worth changing for consistency. My main purpose of doing this was so when new fields are added for classes, they don't have to be added to vmSymbols. Okay. >> >> ------------------------------------------------------------------------------ >> src/hotspot/share/runtime/arguments.cpp >> 526 { "CheckAssertionStatusDirectives",JDK_Version::undefined(), JDK_Version::jdk(10), JDK_Version::jdk(11) }, >> >> Expired version should be jdk(12) rather than jdk(11). >> >> Obsolete version should be jdk(11) rather than jdk(10), but that may >> not be possible until we've updated to be building 11. > > Oh I forgot to change that back. I'm waiting for the version to change, then I'll change it to 11, 12. Okay. > > Thanks, > Coleen >> >> ------------------------------------------------------------------------------ From jcbeyler at google.com Fri Jan 5 19:41:24 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 5 Jan 2018 11:41:24 -0800 Subject: RFR 8191985: Tlab refills for ARM In-Reply-To: References: <356550c0-adb7-bc91-c28f-e1943fad0f81@oracle.com> <1513776075.2757.7.camel@gmail.com> <8d5adc6a-86f0-7c18-5785-97d163159af2@oracle.com> <1514484882.2264.6.camel@gmail.com> <1515150822.4807.3.camel@gmail.com> Message-ID: Thanks both, Anything I need to do on my side? Jc On Fri, Jan 5, 2018 at 9:15 AM, Andrew Haley wrote: > On 05/01/18 11:13, Edward Nevill wrote: >> Can this change be pushed to jdk/hs now? Have we got a formal Reviewer? >> I can push it if required. >> >> http://cr.openjdk.java.net/~jcbeyler/8191985/webrev.02/ >> >> https://bugs.openjdk.java.net/browse/JDK-8191985 > > OK. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From serguei.spitsyn at oracle.com Fri Jan 5 19:46:19 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 5 Jan 2018 11:46:19 -0800 Subject: RFR (M) 8058259: compute_offset() is confusing for static fields In-Reply-To: <26d630c4-19e7-f783-41c0-166a770578f8@oracle.com> References: <26d630c4-19e7-f783-41c0-166a770578f8@oracle.com> Message-ID: <22e9e291-d139-ee32-c1f6-3bc839ec667a@oracle.com> Hi Coleen, The fix looks good to me. Looks like a nice cleanup. Thanks, Serguei On 1/4/18 18:29, coleen.phillimore at oracle.com wrote: > Summary: remove most hard-coded offsets, have compute_offset function > that takes a string and creates a TempNewSymbol, have > static_field_addr() not add in > InstanceMirrorKlass::offset_of_static_fields, ie use offset from > find_field > > The jvmci code uses find_field to get the offset of static fields, > then used static_field_addr() and then subtracted > InstanceMirrorKlass::offset_of_static fields because the function > expected the hardcoded offsets.? Removed hardcoded static offsets and > non-static offsets where possible. > > This change also removes the nonproduct flag > CheckAssertionStatusDirectives (default false). > > Tested with tier1-5 tests on Oracle platforms, and temporary code to > get failures in known class layouts, and see error logging. > > open webrev at http://cr.openjdk.java.net/~coleenp/8058259.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8058259 > > thanks, > Coleen From coleen.phillimore at oracle.com Fri Jan 5 20:15:28 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 5 Jan 2018 15:15:28 -0500 Subject: RFR (M) 8058259: compute_offset() is confusing for static fields In-Reply-To: References: <26d630c4-19e7-f783-41c0-166a770578f8@oracle.com> <5965F467-C84B-4E98-8138-AE018A1107DB@oracle.com> <007b7bb1-8d00-9100-05e5-858e2c27cf4a@oracle.com> Message-ID: Thank you, Kim. Coleen On 1/5/18 1:59 PM, Kim Barrett wrote: >> On Jan 5, 2018, at 8:25 AM, coleen.phillimore at oracle.com wrote: >> >> Hi Kim, Thanks for the review (and pre-review). >> >> On 1/5/18 1:51 AM, Kim Barrett wrote: >>>> On Jan 4, 2018, at 9:29 PM, coleen.phillimore at oracle.com wrote: >>>> >>>> Summary: remove most hard-coded offsets, have compute_offset function that takes a string and creates a TempNewSymbol, have static_field_addr() not add in InstanceMirrorKlass::offset_of_static_fields, ie use offset from find_field >>>> >>>> The jvmci code uses find_field to get the offset of static fields, then used static_field_addr() and then subtracted InstanceMirrorKlass::offset_of_static fields because the function expected the hardcoded offsets. Removed hardcoded static offsets and non-static offsets where possible. >>>> >>>> This change also removes the nonproduct flag CheckAssertionStatusDirectives (default false). >>>> >>>> Tested with tier1-5 tests on Oracle platforms, and temporary code to get failures in known class layouts, and see error logging. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8058259.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8058259 >>>> >>>> thanks, >>>> Coleen >>> Looks good. Just a couple minor things. I don't need another webrev >>> for any of these. >>> >>> ------------------------------------------------------------------------------ >>> src/hotspot/share/classfile/javaClasses.cpp >>> 1229 void java_lang_Thread::compute_offsets() { >>> >>> Wondering why some of the field names are referred to via >>> vmSymbols::XXX_name(), while others use string constants? >> I left some string constants because they were used more than once, so it seemed slightly better and not worth changing for consistency. My main purpose of doing this was so when new fields are added for classes, they don't have to be added to vmSymbols. > Okay. > >>> ------------------------------------------------------------------------------ >>> src/hotspot/share/runtime/arguments.cpp >>> 526 { "CheckAssertionStatusDirectives",JDK_Version::undefined(), JDK_Version::jdk(10), JDK_Version::jdk(11) }, >>> >>> Expired version should be jdk(12) rather than jdk(11). >>> >>> Obsolete version should be jdk(11) rather than jdk(10), but that may >>> not be possible until we've updated to be building 11. >> Oh I forgot to change that back. I'm waiting for the version to change, then I'll change it to 11, 12. > Okay. > >> Thanks, >> Coleen >>> ------------------------------------------------------------------------------ > From coleen.phillimore at oracle.com Fri Jan 5 20:15:12 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 5 Jan 2018 15:15:12 -0500 Subject: RFR (M) 8058259: compute_offset() is confusing for static fields In-Reply-To: <22e9e291-d139-ee32-c1f6-3bc839ec667a@oracle.com> References: <26d630c4-19e7-f783-41c0-166a770578f8@oracle.com> <22e9e291-d139-ee32-c1f6-3bc839ec667a@oracle.com> Message-ID: <02980b34-8c39-2384-5abe-af3eceedd791@oracle.com> Thank you, Serguei! Coleen On 1/5/18 2:46 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > The fix looks good to me. > Looks like a nice cleanup. > > Thanks, > Serguei > > > On 1/4/18 18:29, coleen.phillimore at oracle.com wrote: >> Summary: remove most hard-coded offsets, have compute_offset function >> that takes a string and creates a TempNewSymbol, have >> static_field_addr() not add in >> InstanceMirrorKlass::offset_of_static_fields, ie use offset from >> find_field >> >> The jvmci code uses find_field to get the offset of static fields, >> then used static_field_addr() and then subtracted >> InstanceMirrorKlass::offset_of_static fields because the function >> expected the hardcoded offsets.? Removed hardcoded static offsets and >> non-static offsets where possible. >> >> This change also removes the nonproduct flag >> CheckAssertionStatusDirectives (default false). >> >> Tested with tier1-5 tests on Oracle platforms, and temporary code to >> get failures in known class layouts, and see error logging. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8058259.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8058259 >> >> thanks, >> Coleen > From stewartd.qdt at qualcommdatacenter.com Fri Jan 5 22:15:55 2018 From: stewartd.qdt at qualcommdatacenter.com (stewartd.qdt) Date: Fri, 5 Jan 2018 22:15:55 +0000 Subject: RFR: Message-ID: <8e2ce10d541a4ef0a24f45e7358f2c2a@NASANEXM01E.na.qualcomm.com> Please see the webrev [1] for fixing a JTReg failure when using -XX:+AggressiveHeap [2]. [1] http://cr.openjdk.java.net/~dstewart/8194689/webrev.00/ [2] https://bugs.openjdk.java.net/browse/JDK-8194689 Thank you, Daniel Stewart From goetz.lindenmaier at sap.com Fri Jan 5 22:24:16 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 5 Jan 2018 22:24:16 +0000 Subject: In-Reply-To: <8e2ce10d541a4ef0a24f45e7358f2c2a@NASANEXM01E.na.qualcomm.com> References: <8e2ce10d541a4ef0a24f45e7358f2c2a@NASANEXM01E.na.qualcomm.com> Message-ID: Hi Stewart, I just fixed this the other day in jdk10. The fix will be promoted to jdk/hs within the next weeks. http://hg.openjdk.java.net/jdk/jdk10/rev/efb9f4c91bde https://bugs.openjdk.java.net/browse/JDK-8194232 My original fix was exactly as yours :) Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of stewartd.qdt Sent: Friday, January 5, 2018 11:16 PM To: hotspot-dev at openjdk.java.net Subject: RFR: Please see the webrev [1] for fixing a JTReg failure when using -XX:+AggressiveHeap [2]. [1] http://cr.openjdk.java.net/~dstewart/8194689/webrev.00/ [2] https://bugs.openjdk.java.net/browse/JDK-8194689 Thank you, Daniel Stewart From coleen.phillimore at oracle.com Mon Jan 8 20:22:09 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 8 Jan 2018 15:22:09 -0500 Subject: RFR: 8194312: Support parallel and concurrent JNI global handle processing In-Reply-To: <48A47626-1FB7-4215-8A8C-B66E8D01FB70@oracle.com> References: <48A47626-1FB7-4215-8A8C-B66E8D01FB70@oracle.com> Message-ID: <8159e4d8-a7e7-ddbd-f55e-adf596f2399d@oracle.com> http://cr.openjdk.java.net/~kbarrett/8194312/open.00/src/hotspot/share/gc/shared/oopStorage.hpp.html 463 template // [const] Block* 464 inline bool OopStorage::Block::iterate_impl(F f, BlockPtr block) { Not my typical comment, but this (above) is too terse. 489 template // Storage := [const] OopStorage 490 inline bool OopStorage::iterate_impl(F f, Storage* storage) { This too.? Can you add a comment before each of these that they can be instantiated with a const OopStorage or non-const.? ie that the function provides a const and non-const iteration over the block list depending on how instantiated.? For those of us who find English easier than template code. 492 typedef typename Conditional::value, const Block*, Block*>::type BlockPtr; add some short comment like: +492: // If OopStorage is const then the Block pointers are also const. http://cr.openjdk.java.net/~kbarrett/8194312/open.00/src/hotspot/share/gc/shared/oopStorage.cpp.html 109 #ifdef _WINDOWS 110 #pragma warning(push) 111 #pragma warning(disable: 4351) 112 #endif // _WINDOWS 113 OopStorage::Block::Block(const OopStorage* owner, void* memory) : 114 // VS2013 warns (C4351) that elements of _data will be *correctly* default 115 // initialized, unlike earlier versions that *incorrectly* did not do so. 116 // Using push/disable/pop because suppress here doesn't work. Can you move the comment to line 110 before the pragma? 134 OopStorage::Block::~Block() { 135 #ifdef ASSERT 136 // Clear fields used by block_for_ptr and entry validation, which 137 // might help catch bugs. 138 _allocated_bitmask = 0; 139 _owner = NULL; 140 #endif // ASSERT 141 } Why not clear the fields anyway?? Seems like the expected behavior of the destructor. I feel like BasicParState should be in an oopStorage.inline.hpp file to be included by the GCs that need it.?? Runtime code only needs to include oopStorage.hpp and doesn't need this code. I don't have any other comments and looks like you've addressed most of my preview comments that I remember.? I've looked at the runtime changes for JNI and they look good.?? I haven't looked at the parallel/concurrent iterator code that GC uses, and I only skimmed the test which is quite significant but good to have. This change looks great.? Looking forward to parallel/concurrent JNI handle garbage collection and weak pointers from the runtime. Thanks, Coleen On 1/2/18 4:41 PM, Kim Barrett wrote: > Please review this change to the implementation of JNI global and weak > global handles, providing infrastructure for parallel and concurrent > processing of such handles. > > This change introduces OopStorage, a data structure for managing > off-heap references to objects allocated in the Java heap. JNI global > and weak global handles are reimplemented using OopStorage, rather > than using JNIHandleBlock. (JNI local handles continue to use > JNIHandleBlock; the lifetime management and concurrency issues are > very different for local vs global handles.) > > This change does not change any GCs to use the new parallel and > concurrent capabilities, only laying the foundations for doing so. > > Other uses of OopStorage are also being considered, in the context of > runtime latency improvements for ZGC and other collectors. The idea is > to change some (often weak) oop references in runtime data structures > to OopStorage-managed handles, simplifying the GC processing and > avoiding (potentially concurrent) GC walks of runtime data structures. > > As a side effect, this enhancement fixes these bugs: > 8174790: Race adding (weak) global JNI handles and determining type of handle > 8176454: Performance: jweak references not suitable for robust cache architecture > > Some things not addressed by this change include: > > - 8194309: JNI handle allocation failure not reported correctly > For now, the pre-existing vm_exit_out_of_memory behavior is retained. > > - Updating JNIHandles to use the new Access protocol. > > - Serviceability Agent updates for OopStorage and JNI usage. Just > enough has been done to allow existing SA tests to "pass". This will > be addressed as a followup. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8194312 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8194312/open.00/ > > Testing: > Mach5 hs-tier1 through hs-tier5, jdk-nightly > From kim.barrett at oracle.com Tue Jan 9 00:58:27 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 8 Jan 2018 19:58:27 -0500 Subject: RFR: 8194312: Support parallel and concurrent JNI global handle processing In-Reply-To: References: <48A47626-1FB7-4215-8A8C-B66E8D01FB70@oracle.com> Message-ID: > On Jan 8, 2018, at 7:20 PM, serguei.spitsyn at oracle.com wrote: > > Hi Kim, > > A couple of quick minor comments. Thanks. > http://cr.openjdk.java.net/~kbarrett/8194312/open.00/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerLocation.java.frames.html > 241 } else if (isInStrongGlobalJNIHandles() || > 242 isInWeakGlobalJNIHandles()) { > > 243 tty.print("In "); > > 244 if (isInStrongGlobalJNIHandles()) { > > 245 tty.print("strong global"); > > 246 } else if (isInWeakGlobalJNIHandles()) { > > 247 tty.print("weak global"); > 248 } > > A suggestion to simplify it a little bit as follows: > } else if (isInStrongGlobalJNIHandles()) { > > tty.print("In strong global"); > > } else if (isInWeakGlobalJNIHandles()) { > > tty.print("In weak global"); > } Good idea. Will do. > http://cr.openjdk.java.net/~kbarrett/8194312/open.00/src/hotspot/share/gc/shared/oopStorage.cpp.html > 61 void OopStorage::BlockList::push_back(const Block& block) { > 62 const Block* old = _tail; > 63 if (old == NULL) { > 64 assert(_tail == NULL, "invariant"); > 65 _head = _tail = █ > 66 } else { > 67 _get_entry(*old)._next = █ > 68 _get_entry(block)._prev = old; > 69 _tail = █ > 70 } > 71 } > > It seems, the assert should check _head instead of _tail. Oops! Will do. From david.holmes at oracle.com Tue Jan 9 03:18:51 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 9 Jan 2018 13:18:51 +1000 Subject: RFR: 8194312: Support parallel and concurrent JNI global handle processing In-Reply-To: <48A47626-1FB7-4215-8A8C-B66E8D01FB70@oracle.com> References: <48A47626-1FB7-4215-8A8C-B66E8D01FB70@oracle.com> Message-ID: Hi Kim, As per direct email I'm concerned about the impact the parallel processing may have on the ability of jni checking to work correctly. At the moment most (all?) checking is done IN_VM so that no safepoint can occur and the data being examined is 'stable'. I think it safe to say that jniCheck does not (and probably was not intended to) handle race conditions with other JNI using threads (ie thread B deletes a handle being checked in thread A). But the IN_VM ensures the check is not racing with the GC or other relevant safepoint VM ops. With these changes it is far from clear if such races have now been introduced and that jniCheck will become unreliable for the limited checking it does ? Thanks, David On 3/01/2018 7:41 AM, Kim Barrett wrote: > Please review this change to the implementation of JNI global and weak > global handles, providing infrastructure for parallel and concurrent > processing of such handles. > > This change introduces OopStorage, a data structure for managing > off-heap references to objects allocated in the Java heap. JNI global > and weak global handles are reimplemented using OopStorage, rather > than using JNIHandleBlock. (JNI local handles continue to use > JNIHandleBlock; the lifetime management and concurrency issues are > very different for local vs global handles.) > > This change does not change any GCs to use the new parallel and > concurrent capabilities, only laying the foundations for doing so. > > Other uses of OopStorage are also being considered, in the context of > runtime latency improvements for ZGC and other collectors. The idea is > to change some (often weak) oop references in runtime data structures > to OopStorage-managed handles, simplifying the GC processing and > avoiding (potentially concurrent) GC walks of runtime data structures. > > As a side effect, this enhancement fixes these bugs: > 8174790: Race adding (weak) global JNI handles and determining type of handle > 8176454: Performance: jweak references not suitable for robust cache architecture > > Some things not addressed by this change include: > > - 8194309: JNI handle allocation failure not reported correctly > For now, the pre-existing vm_exit_out_of_memory behavior is retained. > > - Updating JNIHandles to use the new Access protocol. > > - Serviceability Agent updates for OopStorage and JNI usage. Just > enough has been done to allow existing SA tests to "pass". This will > be addressed as a followup. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8194312 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8194312/open.00/ > > Testing: > Mach5 hs-tier1 through hs-tier5, jdk-nightly > From kim.barrett at oracle.com Tue Jan 9 03:44:23 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 8 Jan 2018 22:44:23 -0500 Subject: RFR: 8194312: Support parallel and concurrent JNI global handle processing In-Reply-To: <8159e4d8-a7e7-ddbd-f55e-adf596f2399d@oracle.com> References: <48A47626-1FB7-4215-8A8C-B66E8D01FB70@oracle.com> <8159e4d8-a7e7-ddbd-f55e-adf596f2399d@oracle.com> Message-ID: <4D514E8F-B4A4-4B44-8734-E55D541EEA1D@oracle.com> > On Jan 8, 2018, at 3:22 PM, coleen.phillimore at oracle.com wrote: > > > > http://cr.openjdk.java.net/~kbarrett/8194312/open.00/src/hotspot/share/gc/shared/oopStorage.hpp.html > > 463 template // [const] Block* > 464 inline bool OopStorage::Block::iterate_impl(F f, BlockPtr block) { > > Not my typical comment, but this (above) is too terse. Okay. > 489 template // Storage := [const] OopStorage > 490 inline bool OopStorage::iterate_impl(F f, Storage* storage) { > > This too. Can you add a comment before each of these that they can be instantiated with a const OopStorage or non-const. ie that the function provides a const and non-const iteration over the block list depending on how instantiated. For those of us who find English easier than template code. Okay. > 492 typedef typename Conditional::value, const Block*, Block*>::type BlockPtr; > > add some short comment like: > +492: // If OopStorage is const then the Block pointers are also const. Okay. > http://cr.openjdk.java.net/~kbarrett/8194312/open.00/src/hotspot/share/gc/shared/oopStorage.cpp.html > > 109 #ifdef _WINDOWS > 110 #pragma warning(push) > 111 #pragma warning(disable: 4351) > 112 #endif // _WINDOWS > 113 OopStorage::Block::Block(const OopStorage* owner, void* memory) : > 114 // VS2013 warns (C4351) that elements of _data will be *correctly* default > 115 // initialized, unlike earlier versions that *incorrectly* did not do so. > 116 // Using push/disable/pop because suppress here doesn't work. > > Can you move the comment to line 110 before the pragma? Okay. > 134 OopStorage::Block::~Block() { > 135 #ifdef ASSERT > 136 // Clear fields used by block_for_ptr and entry validation, which > 137 // might help catch bugs. > 138 _allocated_bitmask = 0; > 139 _owner = NULL; > 140 #endif // ASSERT > 141 } > > Why not clear the fields anyway? Seems like the expected behavior of the destructor. Okay. While doing that, it occurred to me these are dead stores, and hence the compiler could optimize them away. Since I'd like to prevent that, I added some volatile casts. And while I was at it, I added ~BlockEntry and ~BlockList with some asserts. > I feel like BasicParState should be in an oopStorage.inline.hpp file to be included by the GCs that need it. Runtime code only needs to include oopStorage.hpp and doesn't need this code. I forgot to deal with your pre-review suggestion of moving some stuff to oopStorage.inline.hpp. I'd like to defer making such a change until this review is (mostly) done, rather than clutter up diffs. I think all (or very nearly all) of the inline definitions in oopStorage.hpp could be moved. I think they're all related to iteration, and I think most clients (other than GC) won't be using iteration at all. I think having the parallel iteration support wrapped with #ifdef INCLUDE_ALL_GCS (as is already the case) deals with the conditional GC usage; I think that all except Serial will eventually use it. The parallel iteration support could be split out into another file, so places that only use serial iteration (like jvmti) wouldn't include it, but I think the number of such places doesn't warrant another file. > > I don't have any other comments and looks like you've addressed most of my preview comments that I remember. I've looked at the runtime changes for JNI and they look good. I haven't looked at the parallel/concurrent iterator code that GC uses, and I only skimmed the test which is quite significant but good to have. > > This change looks great. Looking forward to parallel/concurrent JNI handle garbage collection and weak pointers from the runtime. Thanks. New webrevs (for comments from Coleen and Serguei) full: http://cr.openjdk.java.net/~kbarrett/8194312/open.01/ incr: http://cr.openjdk.java.net/~kbarrett/8194312/open.01.inc/ Oh, and I need to go through and update all the copyrights to 2018. From serguei.spitsyn at oracle.com Tue Jan 9 03:57:21 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 8 Jan 2018 19:57:21 -0800 Subject: RFR: 8194312: Support parallel and concurrent JNI global handle processing In-Reply-To: References: <48A47626-1FB7-4215-8A8C-B66E8D01FB70@oracle.com> Message-ID: <409b5b8e-55e5-17d0-8468-ab8b1458df4a@oracle.com> On 1/8/18 16:58, Kim Barrett wrote: >> On Jan 8, 2018, at 7:20 PM, serguei.spitsyn at oracle.com wrote: >> >> Hi Kim, >> >> A couple of quick minor comments. > Thanks. > >> http://cr.openjdk.java.net/~kbarrett/8194312/open.00/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerLocation.java.frames.html >> 241 } else if (isInStrongGlobalJNIHandles() || >> 242 isInWeakGlobalJNIHandles()) { >> >> 243 tty.print("In "); >> >> 244 if (isInStrongGlobalJNIHandles()) { >> >> 245 tty.print("strong global"); >> >> 246 } else if (isInWeakGlobalJNIHandles()) { >> >> 247 tty.print("weak global"); >> 248 } >> >> A suggestion to simplify it a little bit as follows: >> } else if (isInStrongGlobalJNIHandles()) { >> >> tty.print("In strong global"); >> >> } else if (isInWeakGlobalJNIHandles()) { >> >> tty.print("In weak global"); >> } > Good idea. Will do. > >> http://cr.openjdk.java.net/~kbarrett/8194312/open.00/src/hotspot/share/gc/shared/oopStorage.cpp.html >> 61 void OopStorage::BlockList::push_back(const Block& block) { >> 62 const Block* old = _tail; >> 63 if (old == NULL) { >> 64 assert(_tail == NULL, "invariant"); >> 65 _head = _tail = █ >> 66 } else { >> 67 _get_entry(*old)._next = █ >> 68 _get_entry(block)._prev = old; >> 69 _tail = █ >> 70 } >> 71 } >> >> It seems, the assert should check _head instead of _tail. > Oops! Will do. Thanks! Also, this fragment looks strange: 354 if (block->is_empty()) { 355 log_debug(oopstorage, blocks)("%s: block not empty " PTR_FORMAT, name(), p2i(block)); 356 --_empty_block_count; 357 } Should the message tell "block is empty" instead of "block not empty"? Thanks, Serguei From kim.barrett at oracle.com Tue Jan 9 04:10:06 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 8 Jan 2018 23:10:06 -0500 Subject: RFR: 8194312: Support parallel and concurrent JNI global handle processing In-Reply-To: <409b5b8e-55e5-17d0-8468-ab8b1458df4a@oracle.com> References: <48A47626-1FB7-4215-8A8C-B66E8D01FB70@oracle.com> <409b5b8e-55e5-17d0-8468-ab8b1458df4a@oracle.com> Message-ID: <053E1625-13B5-4EB0-B0BE-CE916A156BBF@oracle.com> > On Jan 8, 2018, at 10:57 PM, serguei.spitsyn at oracle.com wrote: > Also, this fragment looks strange: > > 354 if (block->is_empty()) { > 355 log_debug(oopstorage, blocks)("%s: block not empty " PTR_FORMAT, name(), p2i(block)); > 356 --_empty_block_count; > 357 } > > > Should the message tell "block is empty" instead of "block not empty?? This is logging the transition from empty to non-empty. I could introduce a bool was_empty flag at line 354 to capture the is_empty state before the allocation, and then log the transition and update the counter after the allocation, if was_empty is true. The current code order is just to remove the need for that extra boolean flag. From serguei.spitsyn at oracle.com Tue Jan 9 04:49:30 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 8 Jan 2018 20:49:30 -0800 Subject: RFR: 8194312: Support parallel and concurrent JNI global handle processing In-Reply-To: <053E1625-13B5-4EB0-B0BE-CE916A156BBF@oracle.com> References: <48A47626-1FB7-4215-8A8C-B66E8D01FB70@oracle.com> <409b5b8e-55e5-17d0-8468-ab8b1458df4a@oracle.com> <053E1625-13B5-4EB0-B0BE-CE916A156BBF@oracle.com> Message-ID: On 1/8/18 20:10, Kim Barrett wrote: >> On Jan 8, 2018, at 10:57 PM, serguei.spitsyn at oracle.com wrote: >> Also, this fragment looks strange: >> >> 354 if (block->is_empty()) { >> 355 log_debug(oopstorage, blocks)("%s: block not empty " PTR_FORMAT, name(), p2i(block)); >> 356 --_empty_block_count; >> 357 } >> >> >> Should the message tell "block is empty" instead of "block not empty?? > This is logging the transition from empty to non-empty. > > I could introduce a bool was_empty flag at line 354 to capture the is_empty state before the allocation, > and then log the transition and update the counter after the allocation, if was_empty is true. The current > code order is just to remove the need for that extra boolean flag. Got it, thanks! Serguei From serguei.spitsyn at oracle.com Tue Jan 9 05:07:01 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 8 Jan 2018 21:07:01 -0800 Subject: RFR: 8194312: Support parallel and concurrent JNI global handle processing In-Reply-To: <4D514E8F-B4A4-4B44-8734-E55D541EEA1D@oracle.com> References: <48A47626-1FB7-4215-8A8C-B66E8D01FB70@oracle.com> <8159e4d8-a7e7-ddbd-f55e-adf596f2399d@oracle.com> <4D514E8F-B4A4-4B44-8734-E55D541EEA1D@oracle.com> Message-ID: <846be484-f95a-87e0-e884-ed6bb337316a@oracle.com> On 1/8/18 19:44, Kim Barrett wrote: >> On Jan 8, 2018, at 3:22 PM, coleen.phillimore at oracle.com wrote: >> >> >> >> http://cr.openjdk.java.net/~kbarrett/8194312/open.00/src/hotspot/share/gc/shared/oopStorage.hpp.html >> >> 463 template // [const] Block* >> 464 inline bool OopStorage::Block::iterate_impl(F f, BlockPtr block) { >> >> Not my typical comment, but this (above) is too terse. > Okay. > >> 489 template // Storage := [const] OopStorage >> 490 inline bool OopStorage::iterate_impl(F f, Storage* storage) { >> >> This too. Can you add a comment before each of these that they can be instantiated with a const OopStorage or non-const. ie that the function provides a const and non-const iteration over the block list depending on how instantiated. For those of us who find English easier than template code. > Okay. > >> 492 typedef typename Conditional::value, const Block*, Block*>::type BlockPtr; >> >> add some short comment like: >> +492: // If OopStorage is const then the Block pointers are also const. > Okay. > >> http://cr.openjdk.java.net/~kbarrett/8194312/open.00/src/hotspot/share/gc/shared/oopStorage.cpp.html >> >> 109 #ifdef _WINDOWS >> 110 #pragma warning(push) >> 111 #pragma warning(disable: 4351) >> 112 #endif // _WINDOWS >> 113 OopStorage::Block::Block(const OopStorage* owner, void* memory) : >> 114 // VS2013 warns (C4351) that elements of _data will be *correctly* default >> 115 // initialized, unlike earlier versions that *incorrectly* did not do so. >> 116 // Using push/disable/pop because suppress here doesn't work. >> >> Can you move the comment to line 110 before the pragma? > Okay. > >> 134 OopStorage::Block::~Block() { >> 135 #ifdef ASSERT >> 136 // Clear fields used by block_for_ptr and entry validation, which >> 137 // might help catch bugs. >> 138 _allocated_bitmask = 0; >> 139 _owner = NULL; >> 140 #endif // ASSERT >> 141 } >> >> Why not clear the fields anyway? Seems like the expected behavior of the destructor. > Okay. While doing that, it occurred to me these are dead stores, > and hence the compiler could optimize them away. Since I'd like to > prevent that, I added some volatile casts. > > And while I was at it, I added ~BlockEntry and ~BlockList with some > asserts. > >> I feel like BasicParState should be in an oopStorage.inline.hpp file to be included by the GCs that need it. Runtime code only needs to include oopStorage.hpp and doesn't need this code. > I forgot to deal with your pre-review suggestion of moving some stuff > to oopStorage.inline.hpp. I'd like to defer making such a change > until this review is (mostly) done, rather than clutter up diffs. > > I think all (or very nearly all) of the inline definitions in > oopStorage.hpp could be moved. I think they're all related to > iteration, and I think most clients (other than GC) won't be using > iteration at all. > > I think having the parallel iteration support wrapped with > #ifdef INCLUDE_ALL_GCS (as is already the case) deals with the > conditional GC usage; I think that all except Serial will eventually > use it. > > The parallel iteration support could be split out into another file, > so places that only use serial iteration (like jvmti) wouldn't include > it, but I think the number of such places doesn't warrant another > file. > >> I don't have any other comments and looks like you've addressed most of my preview comments that I remember. I've looked at the runtime changes for JNI and they look good. I haven't looked at the parallel/concurrent iterator code that GC uses, and I only skimmed the test which is quite significant but good to have. >> >> This change looks great. Looking forward to parallel/concurrent JNI handle garbage collection and weak pointers from the runtime. > Thanks. > > New webrevs (for comments from Coleen and Serguei) > full: http://cr.openjdk.java.net/~kbarrett/8194312/open.01/ > incr: http://cr.openjdk.java.net/~kbarrett/8194312/open.01.inc/ The incremental update looks good to me. > Oh, and I need to go through and update all the copyrights to 2018. I was about to point to it. :) Thanks, Serguei > From goetz.lindenmaier at sap.com Tue Jan 9 08:10:43 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 9 Jan 2018 08:10:43 +0000 Subject: RFR(M): 8194814 [ppc, s390] A row of minor fixes and cleanups Message-ID: <85965bbdb1c849fbb9486101e97a3399@sap.com> Hi, could I please get a review for this collection of minor fixes and cleanups in the ppc and s390 platform files? http://cr.openjdk.java.net/~goetz/wr18/8194814-ppcCleanup/webrev.01/ Thanks, Goetz. From dmitry.samersoff at bell-sw.com Tue Jan 9 10:52:29 2018 From: dmitry.samersoff at bell-sw.com (Dmitry Samersov) Date: Tue, 9 Jan 2018 13:52:29 +0300 Subject: RFR 8191985: Tlab refills for ARM In-Reply-To: <1515150822.4807.3.camel@gmail.com> References: <356550c0-adb7-bc91-c28f-e1943fad0f81@oracle.com> <1513776075.2757.7.camel@gmail.com> <8d5adc6a-86f0-7c18-5785-97d163159af2@oracle.com> <1514484882.2264.6.camel@gmail.com> <1515150822.4807.3.camel@gmail.com> Message-ID: <62804c78-5243-2462-9204-ec59cb67d63d@bell-sw.com> Edward, On 05.01.2018 14:13, Edward Nevill wrote: > Hi, > > Can this change be pushed to jdk/hs now? > Have we got a formal Reviewer? The fix looks good to me. > I can push it if required. Let me know if you need a help to push the fix. -Dmitry > > http://cr.openjdk.java.net/~jcbeyler/8191985/webrev.02/ > > https://bugs.openjdk.java.net/browse/JDK-8191985 > > All the best, > Ed. > > On Tue, 2018-01-02 at 09:19 -0800, JC Beyler wrote: >> Perfect, thanks Edward for testing :) >> Jc >> >> >> On Thu, Dec 28, 2017 at 10:14 AM, Edward Nevill > com> wrote: >>> Hi, >>> >>> I have built and tested this on a Samsung Chromebook (armv7l). >>> >>> The tests I ran were jtreg hotspot tests patched vs original in >>> three configurations, default gc (g1gc), parallelgc and serialgc. >>> The results in all cases were identical before and after patching. >>> >>> Default gc (g1gc): passed: 1,435; failed: 9; error: 116 >>> ParallelGC: passed: 1,331; failed: 8; error: 112 >>> SerialGC: passed: 1,326; failed: 7; error: 112 >>> >>> Patch looks good to me. >>> >>> All the best, >>> Ed. >>> >>> On Wed, 2017-12-20 at 09:06 -0800, JC Beyler wrote: >>>> Hi all, >>>> >>>> Thanks for taking a look at the webrev! >>>> >>>> Here is the change relative to jdk/hs: >>>> http://cr.openjdk.java.net/~jcbeyler/8191985/webrev.02/ >>>> >>>> Let me know what you think, hopefully I didn't make a mistake >>>> when >>>> making the webrev :) >>>> Jc >>>> >>>> From martin.doerr at sap.com Tue Jan 9 11:50:30 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 9 Jan 2018 11:50:30 +0000 Subject: RFR(M): 8194814 [ppc, s390] A row of minor fixes and cleanups In-Reply-To: <85965bbdb1c849fbb9486101e97a3399@sap.com> References: <85965bbdb1c849fbb9486101e97a3399@sap.com> Message-ID: Hi G?tz, looks basically good. I only have minor change requests. icache_ppc.cpp doesn't need anything from asm/... so I'd prefer to remove the include. vtable_stubs_ppc_64.cpp changes may interfere with changes in other repositories. I suggest to skip this file for now to avoid merge conflicts. Best regards, Martin -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz Sent: Dienstag, 9. Januar 2018 09:11 To: hotspot-dev at openjdk.java.net Subject: RFR(M): 8194814 [ppc, s390] A row of minor fixes and cleanups Hi, could I please get a review for this collection of minor fixes and cleanups in the ppc and s390 platform files? http://cr.openjdk.java.net/~goetz/wr18/8194814-ppcCleanup/webrev.01/ Thanks, Goetz. From goetz.lindenmaier at sap.com Tue Jan 9 12:47:34 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 9 Jan 2018 12:47:34 +0000 Subject: RFR(M): 8194814 [ppc, s390] A row of minor fixes and cleanups In-Reply-To: References: <85965bbdb1c849fbb9486101e97a3399@sap.com> Message-ID: <79ab7dfb60024df4b7c58c41499af02c@sap.com> Hi Martin, I implemented your requests: http://cr.openjdk.java.net/~goetz/wr18/8194814-ppcCleanup/webrev.02/ Thanks for your review! Best regards, Goetz > -----Original Message----- > From: Doerr, Martin > Sent: Dienstag, 9. Januar 2018 12:51 > To: Lindenmaier, Goetz ; hotspot- > dev at openjdk.java.net > Subject: RE: RFR(M): 8194814 [ppc, s390] A row of minor fixes and cleanups > > Hi G?tz, > > looks basically good. > > I only have minor change requests. > > icache_ppc.cpp doesn't need anything from asm/... so I'd prefer to remove > the include. > > vtable_stubs_ppc_64.cpp changes may interfere with changes in other > repositories. I suggest to skip this file for now to avoid merge conflicts. > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Lindenmaier, Goetz > Sent: Dienstag, 9. Januar 2018 09:11 > To: hotspot-dev at openjdk.java.net > Subject: RFR(M): 8194814 [ppc, s390] A row of minor fixes and cleanups > > Hi, > > could I please get a review for this collection of minor fixes > and cleanups in the ppc and s390 platform files? > http://cr.openjdk.java.net/~goetz/wr18/8194814-ppcCleanup/webrev.01/ > > Thanks, > Goetz. From martin.doerr at sap.com Tue Jan 9 15:27:24 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 9 Jan 2018 15:27:24 +0000 Subject: RFR(M): 8194814 [ppc, s390] A row of minor fixes and cleanups In-Reply-To: <79ab7dfb60024df4b7c58c41499af02c@sap.com> References: <85965bbdb1c849fbb9486101e97a3399@sap.com> <79ab7dfb60024df4b7c58c41499af02c@sap.com> Message-ID: <999cad21bbf24fbea2b67b1af00695df@sap.com> Hi G?tz, looks good, now. Best regards, Martin -----Original Message----- From: Lindenmaier, Goetz Sent: Dienstag, 9. Januar 2018 13:48 To: Doerr, Martin ; hotspot-dev at openjdk.java.net Subject: RE: RFR(M): 8194814 [ppc, s390] A row of minor fixes and cleanups Hi Martin, I implemented your requests: http://cr.openjdk.java.net/~goetz/wr18/8194814-ppcCleanup/webrev.02/ Thanks for your review! Best regards, Goetz > -----Original Message----- > From: Doerr, Martin > Sent: Dienstag, 9. Januar 2018 12:51 > To: Lindenmaier, Goetz ; hotspot- > dev at openjdk.java.net > Subject: RE: RFR(M): 8194814 [ppc, s390] A row of minor fixes and cleanups > > Hi G?tz, > > looks basically good. > > I only have minor change requests. > > icache_ppc.cpp doesn't need anything from asm/... so I'd prefer to remove > the include. > > vtable_stubs_ppc_64.cpp changes may interfere with changes in other > repositories. I suggest to skip this file for now to avoid merge conflicts. > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Lindenmaier, Goetz > Sent: Dienstag, 9. Januar 2018 09:11 > To: hotspot-dev at openjdk.java.net > Subject: RFR(M): 8194814 [ppc, s390] A row of minor fixes and cleanups > > Hi, > > could I please get a review for this collection of minor fixes > and cleanups in the ppc and s390 platform files? > http://cr.openjdk.java.net/~goetz/wr18/8194814-ppcCleanup/webrev.01/ > > Thanks, > Goetz. From david.holmes at oracle.com Wed Jan 10 00:48:58 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 10 Jan 2018 10:48:58 +1000 Subject: RFR: 8194312: Support parallel and concurrent JNI global handle processing In-Reply-To: References: <48A47626-1FB7-4215-8A8C-B66E8D01FB70@oracle.com> Message-ID: <531277eb-558e-e69f-4277-a386fd05f938@oracle.com> On 9/01/2018 1:18 PM, David Holmes wrote: > Hi Kim, > > As per direct email I'm concerned about the impact the parallel > processing may have on the ability of jni checking to work correctly. At > the moment most (all?) checking is done IN_VM so that no safepoint can > occur and the data being examined is 'stable'. I think it safe to say > that jniCheck does not (and probably was not intended to) handle race > conditions with other JNI using threads (ie thread B deletes a handle > being checked in thread A). But the IN_VM ensures the check is not > racing with the GC or other relevant safepoint VM ops. With these > changes it is far from clear if such races have now been introduced and > that jniCheck will become unreliable for the limited checking it does ? To clarify the above. oopStorage is an enabling technology that provides the support for potential parallel/concurrent JNI global handle processing. My concern is with any GC that in the future takes advantage of this and starts doing things outside of a safepoint, that is currently done at a safepoint, and which may impact the assumptions within the JNI checking code, within the IN_VM sections, that expects to execute atomically with respect to such code. Cheers, David > Thanks, > David > > > > > On 3/01/2018 7:41 AM, Kim Barrett wrote: >> Please review this change to the implementation of JNI global and weak >> global handles, providing infrastructure for parallel and concurrent >> processing of such handles. >> >> This change introduces OopStorage, a data structure for managing >> off-heap references to objects allocated in the Java heap. JNI global >> and weak global handles are reimplemented using OopStorage, rather >> than using JNIHandleBlock. (JNI local handles continue to use >> JNIHandleBlock; the lifetime management and concurrency issues are >> very different for local vs global handles.) >> >> This change does not change any GCs to use the new parallel and >> concurrent capabilities, only laying the foundations for doing so. >> >> Other uses of OopStorage are also being considered, in the context of >> runtime latency improvements for ZGC and other collectors. The idea is >> to change some (often weak) oop references in runtime data structures >> to OopStorage-managed handles, simplifying the GC processing and >> avoiding (potentially concurrent) GC walks of runtime data structures. >> >> As a side effect, this enhancement fixes these bugs: >> 8174790: Race adding (weak) global JNI handles and determining type of >> handle >> 8176454: Performance: jweak references not suitable for robust cache >> architecture >> >> Some things not addressed by this change include: >> >> - 8194309: JNI handle allocation failure not reported correctly >> For now, the pre-existing vm_exit_out_of_memory behavior is retained. >> >> - Updating JNIHandles to use the new Access protocol. >> >> - Serviceability Agent updates for OopStorage and JNI usage.? Just >> enough has been done to allow existing SA tests to "pass".? This will >> be addressed as a followup. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8194312 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8194312/open.00/ >> >> Testing: >> Mach5 hs-tier1 through hs-tier5, jdk-nightly >> From HORIE at jp.ibm.com Wed Jan 10 06:10:07 2018 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Wed, 10 Jan 2018 15:10:07 +0900 Subject: RFR : PPC64 : Need support for VSR spills in ppc.ad Message-ID: Hi Martin, Would you review the following change that fixes the SLP for PPC? In this change, I added support for VSR spills. Also, I fixed how to specify registers in postalloc_expand for the float constant replication. I confirmed this change works with JTREG. Bug: https://bugs.openjdk.java.net/browse/JDK-8194861 webrev: http://cr.openjdk.java.net/~mhorie/8194861/webrev.00/ (I created a webrev under jdk/hs.) Best regards, -- Michihiro, IBM Research - Tokyo From martin.doerr at sap.com Wed Jan 10 11:17:43 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 10 Jan 2018 11:17:43 +0000 Subject: RFR : PPC64 : Need support for VSR spills in ppc.ad In-Reply-To: References: Message-ID: <409187f381384294a5f5c1a38b66a840@sap.com> Hi Michihiro, thanks for implementing it. I wonder how the content of R19 should get preserved. Shouldn't repl4F_immF_Ex use a temp register instead of R19? SuperwordUseVSX is still not activated in vm_version_ppc.cpp. I think we should turn it on with this change (see the TODO). We will run tests when the R19 question is clarified. Best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Mittwoch, 10. Januar 2018 07:10 To: Doerr, Martin Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; Gustavo Romero Subject: RFR : PPC64 : Need support for VSR spills in ppc.ad Hi Martin, Would you review the following change that fixes the SLP for PPC? In this change, I added support for VSR spills. Also, I fixed how to specify registers in postalloc_expand for the float constant replication. I confirmed this change works with JTREG. Bug: https://bugs.openjdk.java.net/browse/JDK-8194861 webrev: http://cr.openjdk.java.net/~mhorie/8194861/webrev.00/ (I created a webrev under jdk/hs.) Best regards, -- Michihiro, IBM Research - Tokyo From erik.osterlund at oracle.com Wed Jan 10 13:50:04 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 10 Jan 2018 14:50:04 +0100 Subject: RFR: 8194312: Support parallel and concurrent JNI global handle processing In-Reply-To: <48A47626-1FB7-4215-8A8C-B66E8D01FB70@oracle.com> References: <48A47626-1FB7-4215-8A8C-B66E8D01FB70@oracle.com> Message-ID: <5A561A0C.90803@oracle.com> Hi Kim, I have already seen earlier incarnations of this code so I only have a few comments regarding things that were not in that incarnation. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/OopStorage.java: The Java implementation of OopStorage for the SA agent seems a bit empty and full of TODO comments to actually implement something. It seems like quite a bit of the other changes to the SA assumes that this actually does something. For example there are changes to use OopStorage oopsDo instead of JNIHandleBlock oopsDo, which I presume means there has to be some oopsDo implementation in place for OopStorage. Is the intention to implement that later on in a separate RFE? src/hotspot/share/gc/shared/oopStorage.hpp: The OopStorage::oops_do functions accept some kind of OopClosure and performs iteration with it. I'm curious though why it takes the specific type of OopClosure as a template parameter, passes it around, and eventually discards the information without making use of it? I was thinking perhaps the intention was to use the closure type information to devirtualize the do_oop() call, but that does not appear to be the case. To do that you would have to in OopStorage::OopFn::operator()() perform a qualified _cl->Closure::do_oop() call instead of _cl->do_oop() (and possibly take some care to prevent abstract oop closure types like OopClosure or ExtendedOopClosure from being devirtualized, which would be awkward (doable with some EnableIf::value>::type overload, or something like that). In other words, it seems like either this template parameter is unnecessary and you could just replace uses of it with OopClosure, or it should be made useful, e.g. by devirtualizing the calls or something. Same goes for the IsAliveClosure parameter for weak_oops_do. src/hotspot/share/gc/shared/oopStorage.cpp: I recall in the pre-review we had some discussion about whether the infrastructure for supporting early iteration termination was necessary or not. You had me convinced that JNI would need it for something. Is this still the case, or has that use case been revised? Reading through the new JNI code, I could not find uses of OopStorage::iterate_safepoint() from the JNI code, and hence no uses of early termination. Having said that, it does look rather simple now with only the sequential case supporting early termination. However, if there is indeed no use any longer for OopStorage::iterate() and hence the only publicly available tool for early iteration exit, I wonder if perhaps it should be reconsidered if we want to remove that infrastructure. Or will there be other use cases down the road? Currently I find it at least a bit confusing that, e.g. OopStorage::iterate_safepoint() expects a function of type F that returns bool while OopStorage::BasicParState::iterate() expects a function of type F that returns void. For the OopStorage::iterate_safepoint() case it is clearly described in the documentation, in the OopStorage::BasicParState::iterate() case I did not find it clear that this F is a different F to the safepoint one. I guess I propose either removing early termination support alltogether if nobody is using it anyway (and hence having the F function type consistently return void), or documenting clearly that the sequential and parallel iteration functions expect different function types - one with bool return type and one with void return type, depending on whether early termination is supported or not. Apart from the above minor remarks, I am delighted to see these changes. I am extra delighted to see deleted_handle() disappear. I am also delighted to see the new simplified synchronization for parallel iteration - that worked out nicely. Thank you for building a good oop storage solution. Thanks, /Erik On 2018-01-02 22:41, Kim Barrett wrote: > Please review this change to the implementation of JNI global and weak > global handles, providing infrastructure for parallel and concurrent > processing of such handles. > > This change introduces OopStorage, a data structure for managing > off-heap references to objects allocated in the Java heap. JNI global > and weak global handles are reimplemented using OopStorage, rather > than using JNIHandleBlock. (JNI local handles continue to use > JNIHandleBlock; the lifetime management and concurrency issues are > very different for local vs global handles.) > > This change does not change any GCs to use the new parallel and > concurrent capabilities, only laying the foundations for doing so. > > Other uses of OopStorage are also being considered, in the context of > runtime latency improvements for ZGC and other collectors. The idea is > to change some (often weak) oop references in runtime data structures > to OopStorage-managed handles, simplifying the GC processing and > avoiding (potentially concurrent) GC walks of runtime data structures. > > As a side effect, this enhancement fixes these bugs: > 8174790: Race adding (weak) global JNI handles and determining type of handle > 8176454: Performance: jweak references not suitable for robust cache architecture > > Some things not addressed by this change include: > > - 8194309: JNI handle allocation failure not reported correctly > For now, the pre-existing vm_exit_out_of_memory behavior is retained. > > - Updating JNIHandles to use the new Access protocol. > > - Serviceability Agent updates for OopStorage and JNI usage. Just > enough has been done to allow existing SA tests to "pass". This will > be addressed as a followup. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8194312 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8194312/open.00/ > > Testing: > Mach5 hs-tier1 through hs-tier5, jdk-nightly > From coleen.phillimore at oracle.com Wed Jan 10 13:56:44 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 10 Jan 2018 08:56:44 -0500 Subject: RFR: 8194312: Support parallel and concurrent JNI global handle processing In-Reply-To: <4D514E8F-B4A4-4B44-8734-E55D541EEA1D@oracle.com> References: <48A47626-1FB7-4215-8A8C-B66E8D01FB70@oracle.com> <8159e4d8-a7e7-ddbd-f55e-adf596f2399d@oracle.com> <4D514E8F-B4A4-4B44-8734-E55D541EEA1D@oracle.com> Message-ID: <987c2652-ef28-2546-e351-d70e5be2d35c@oracle.com> On 1/8/18 10:44 PM, Kim Barrett wrote: >> On Jan 8, 2018, at 3:22 PM, coleen.phillimore at oracle.com wrote: >> >> >> >> http://cr.openjdk.java.net/~kbarrett/8194312/open.00/src/hotspot/share/gc/shared/oopStorage.hpp.html >> >> 463 template // [const] Block* >> 464 inline bool OopStorage::Block::iterate_impl(F f, BlockPtr block) { >> >> Not my typical comment, but this (above) is too terse. > Okay. > >> 489 template // Storage := [const] OopStorage >> 490 inline bool OopStorage::iterate_impl(F f, Storage* storage) { >> >> This too. Can you add a comment before each of these that they can be instantiated with a const OopStorage or non-const. ie that the function provides a const and non-const iteration over the block list depending on how instantiated. For those of us who find English easier than template code. > Okay. > >> 492 typedef typename Conditional::value, const Block*, Block*>::type BlockPtr; >> >> add some short comment like: >> +492: // If OopStorage is const then the Block pointers are also const. > Okay. > >> http://cr.openjdk.java.net/~kbarrett/8194312/open.00/src/hotspot/share/gc/shared/oopStorage.cpp.html >> >> 109 #ifdef _WINDOWS >> 110 #pragma warning(push) >> 111 #pragma warning(disable: 4351) >> 112 #endif // _WINDOWS >> 113 OopStorage::Block::Block(const OopStorage* owner, void* memory) : >> 114 // VS2013 warns (C4351) that elements of _data will be *correctly* default >> 115 // initialized, unlike earlier versions that *incorrectly* did not do so. >> 116 // Using push/disable/pop because suppress here doesn't work. >> >> Can you move the comment to line 110 before the pragma? > Okay. > >> 134 OopStorage::Block::~Block() { >> 135 #ifdef ASSERT >> 136 // Clear fields used by block_for_ptr and entry validation, which >> 137 // might help catch bugs. >> 138 _allocated_bitmask = 0; >> 139 _owner = NULL; >> 140 #endif // ASSERT >> 141 } >> >> Why not clear the fields anyway? Seems like the expected behavior of the destructor. > Okay. While doing that, it occurred to me these are dead stores, > and hence the compiler could optimize them away. Since I'd like to > prevent that, I added some volatile casts. > > And while I was at it, I added ~BlockEntry and ~BlockList with some > asserts. > >> I feel like BasicParState should be in an oopStorage.inline.hpp file to be included by the GCs that need it. Runtime code only needs to include oopStorage.hpp and doesn't need this code. > I forgot to deal with your pre-review suggestion of moving some stuff > to oopStorage.inline.hpp. I'd like to defer making such a change > until this review is (mostly) done, rather than clutter up diffs. > > I think all (or very nearly all) of the inline definitions in > oopStorage.hpp could be moved. I think they're all related to > iteration, and I think most clients (other than GC) won't be using > iteration at all. > > I think having the parallel iteration support wrapped with > #ifdef INCLUDE_ALL_GCS (as is already the case) deals with the > conditional GC usage; I think that all except Serial will eventually > use it. > > The parallel iteration support could be split out into another file, > so places that only use serial iteration (like jvmti) wouldn't include > it, but I think the number of such places doesn't warrant another > file. I would like that it be split out into another file.? A lot of places in the runtime will only create and add oops to OopStorage and shouldn't care about iteration.? I'm fine with making this change as a further improvement. Thanks, Coleen > >> I don't have any other comments and looks like you've addressed most of my preview comments that I remember. I've looked at the runtime changes for JNI and they look good. I haven't looked at the parallel/concurrent iterator code that GC uses, and I only skimmed the test which is quite significant but good to have. >> >> This change looks great. Looking forward to parallel/concurrent JNI handle garbage collection and weak pointers from the runtime. > Thanks. > > New webrevs (for comments from Coleen and Serguei) > full: http://cr.openjdk.java.net/~kbarrett/8194312/open.01/ > incr: http://cr.openjdk.java.net/~kbarrett/8194312/open.01.inc/ > > Oh, and I need to go through and update all the copyrights to 2018. > From stewartd.qdt at qualcommdatacenter.com Wed Jan 10 15:28:25 2018 From: stewartd.qdt at qualcommdatacenter.com (stewartd.qdt) Date: Wed, 10 Jan 2018 15:28:25 +0000 Subject: RFR: JDK-8194762: JTReg failure of "runtime/NMT/PrintNMTStatistics.java" Message-ID: <933348e1c66f46d68b5c5cab3b200c44@NASANEXM01E.na.qualcomm.com> Please review this small webrev [1] that removes the search for the word "error" in stdout for the PrintNMTStatistics during the NativeMemoryTracking=details sub-test of the JTReg test. I have found that on my test machine (AArch64, Linux) when the detailed list is printed there is a module called "LogOutputList" that has as one of the listed functions "_dl_catch_error". Since the HTReg test simply searches for the word "error" in stdout, this test fails. However, there really isn't a failure to behave correctly and all the details are printed correctly. It also returns 0 on exit, as it should. The full log is attached to the bug report. I have created this patch in the belief that the test is being overly restrictive in searching for "error" In stdout and that printing out "_dl_catch_error" is correct behavior and shouldn't cause the test to fail. Please let me know if this is a bad approach and I'll be happy to change as required. Thanks, Daniel Stewart [1] webrev: http://cr.openjdk.java.net/~dstewart/8194762/webrev.00/ [2] CR: https://bugs.openjdk.java.net/browse/JDK-8194762 From martin.doerr at sap.com Wed Jan 10 17:19:29 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 10 Jan 2018 17:19:29 +0000 Subject: RFR : PPC64 : Need support for VSR spills in ppc.ad In-Reply-To: References: <409187f381384294a5f5c1a38b66a840@sap.com>, Message-ID: <5f8786f3d20649d697b99f4d663cd110@sap.com> Hi Michihiro, > R19 is commented out in bits64_constant_table_base so as not to be used: Not to be used by MachConstantBaseNode. I don?t see how this should help. I still suggest to add ?iRegLdst tmp? with ?effect(TEMP tmp)? to repl4F_immF_Ex. Best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Mittwoch, 10. Januar 2018 16:29 To: Doerr, Martin Cc: Lindenmaier, Goetz ; gromero at linux.vnet.ibm.com; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: RE: RFR : PPC64 : Need support for VSR spills in ppc.ad Hi Martin, Thanks a lot for your review. >I wonder how the content of R19 should get preserved. R19 is commented out in bits64_constant_table_base so as not to be used: reg_class bits64_constant_table_base( : R18_H, R18, /*R19_H, R19*/ R20_H, R20, : ); Although bits64_constant_table_base is not directly referred from anywhere, it seems to be used at the following line in ppc.ad: const RegMask& MachConstantBaseNode::_out_RegMask = BITS64_CONSTANT_TABLE_BASE_mask(); (When I remove the declaration of bits64_constant_table_base, a build error arises at this line telling the lack of the declaration.) >Shouldn?t repl4F_immF_Ex use a temp register instead of R19? Thank you for the suggestion, which makes sense very much. I think I can declare temp registers in repl4F_immF_Ex. I will try this approach if using R19 does not make sense. I changed vm_version_ppc.cpp: webrev: http://cr.openjdk.java.net/~mhorie/8194861/webrev.01/ Best regards, -- Michihiro, IBM Research - Tokyo ----- Original message ----- From: "Doerr, Martin" > To: Michihiro Horie > Cc: "ppc-aix-port-dev at openjdk.java.net" >, "hotspot-dev at openjdk.java.net" >, Gustavo Romero >, "Lindenmaier, Goetz" > Subject: RE: RFR : PPC64 : Need support for VSR spills in ppc.ad Date: Wed, Jan 10, 2018 8:17 PM Hi Michihiro, thanks for implementing it. I wonder how the content of R19 should get preserved. Shouldn?t repl4F_immF_Ex use a temp register instead of R19? SuperwordUseVSX is still not activated in vm_version_ppc.cpp. I think we should turn it on with this change (see the TODO). We will run tests when the R19 question is clarified. Best regards, Martin From: Michihiro Horie [mailto:HORIE at jp.ibm.com] Sent: Mittwoch, 10. Januar 2018 07:10 To: Doerr, Martin > Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; Gustavo Romero > Subject: RFR : PPC64 : Need support for VSR spills in ppc.ad Hi Martin, Would you review the following change that fixes the SLP for PPC? In this change, I added support for VSR spills. Also, I fixed how to specify registers in postalloc_expand for the float constant replication. I confirmed this change works with JTREG. Bug: https://bugs.openjdk.java.net/browse/JDK-8194861 webrev: http://cr.openjdk.java.net/~mhorie/8194861/webrev.00/ (I created a webrev under jdk/hs.) Best regards, -- Michihiro, IBM Research - Tokyo From kim.barrett at oracle.com Wed Jan 10 20:57:07 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 10 Jan 2018 15:57:07 -0500 Subject: RFR: 8194312: Support parallel and concurrent JNI global handle processing In-Reply-To: <5A561A0C.90803@oracle.com> References: <48A47626-1FB7-4215-8A8C-B66E8D01FB70@oracle.com> <5A561A0C.90803@oracle.com> Message-ID: <4D611A04-F9AB-4681-80DC-DAA53D1EE3A9@oracle.com> > On Jan 10, 2018, at 8:50 AM, Erik ?sterlund wrote: > > Hi Kim, > > I have already seen earlier incarnations of this code so I only have a few comments regarding things that were not in that incarnation. Thanks for looking at it yet again. > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/OopStorage.java: > > The Java implementation of OopStorage for the SA agent seems a bit empty and full of TODO comments to actually implement something. It seems like quite a bit of the other changes to the SA assumes that this actually does something. For example there are changes to use OopStorage oopsDo instead of JNIHandleBlock oopsDo, which I presume means there has to be some oopsDo implementation in place for OopStorage. > Is the intention to implement that later on in a separate RFE? Quoting from the original RFR email: - Serviceability Agent updates for OopStorage and JNI usage. Just enough has been done to allow existing SA tests to "pass". This will be addressed as a followup. I haven't filed that RFE yet, but will be doing so. > src/hotspot/share/gc/shared/oopStorage.hpp: > > The OopStorage::oops_do functions accept some kind of OopClosure and performs iteration with it. I'm curious though why it takes the specific type of OopClosure as a template parameter, passes it around, and eventually discards the information without making use of it? I was thinking perhaps the intention was to use the closure type information to devirtualize the do_oop() call, but that does not appear to be the case. To do that you would have to in OopStorage::OopFn::operator()() perform a qualified _cl->Closure::do_oop() call instead of _cl->do_oop() (and possibly take some care to prevent abstract oop closure types like OopClosure or ExtendedOopClosure from being devirtualized, which would be awkward (doable with some EnableIf::value>::type overload, or something like that). > In other words, it seems like either this template parameter is unnecessary and you could just replace uses of it with OopClosure, or it should be made useful, e.g. by devirtualizing the calls or something. Same goes for the IsAliveClosure parameter for weak_oops_do. Sorry, but I'm not understanding what problem is being suggested. OopStorage doesn't depend on OopClosure as a type, at all, anywhere. There are no occurrences of the type OopClosure anywhere in the OopStorage implementation. The types coming in to OopStorage iteration are preserved and used, without any need for odd syntax. With the type preserved like that, for common use-cases such as MyClosureType my_closure; storage->oops_do(&my_closure); the compiler can know the exact type of my_closure at the call site for do_oop(), in which case the compiler can devirtualize the call (and I would expect any decent compiler to do so; I've seen gcc do it). Maybe the issue is about JNIHandles::oops_do and friends, which presently are ordinary functions with OopClosure* arguments and the like? Yes, the type information isn't flowing through there from the caller to the OopStorage infrastructure. That's because that was going to introduce some additional fannout in this changeset. I was going to move the inline definitions to oopStorage.inline.hpp (per Coleen's pre-review request), and all uses of iteration would then need to be changed to include that, which would have required a new jniHandles.inline.hpp, which would have required at least some additional downstream include changes. I'm planning to make those changes as a followup. Of course, I then forgot Coleen's pre-review request. > src/hotspot/share/gc/shared/oopStorage.cpp: > > I recall in the pre-review we had some discussion about whether the infrastructure for supporting early iteration termination was necessary or not. You had me convinced that JNI would need it for something. Is this still the case, or has that use case been revised? Reading through the new JNI code, I could not find uses of OopStorage::iterate_safepoint() from the JNI code, and hence no uses of early termination. Having said that, it does look rather simple now with only the sequential case supporting early termination. > However, if there is indeed no use any longer for OopStorage::iterate() and hence the only publicly available tool for early iteration exit, I wonder if perhaps it should be reconsidered if we want to remove that infrastructure. Or will there be other use cases down the road? Currently I find it at least a bit confusing that, e.g. OopStorage::iterate_safepoint() expects a function of type F that returns bool while OopStorage::BasicParState::iterate() expects a function of type F that returns void. For the OopStorage::iterate_safepoint() case it is clearly described in the documentation, in the OopStorage::BasicParState::iterate() case I did not find it clear that this F is a different F to the safepoint one. > I guess I propose either removing early termination support alltogether if nobody is using it anyway (and hence having the F function type consistently return void), or documenting clearly that the sequential and parallel iteration functions expect different function types - one with bool return type and one with void return type, depending on whether early termination is supported or not. The SimpleRootsClosure used by VM_HeapWalkOperation::collect_simple_roots is a use-case for early termination. iteration_safepoint documents a requirement on the result of the argument function (the result must be implicitly convertible to bool), and the associated behavior. ParState::iterate doesn't specify any requirements on the result of the argument function, nor specify any associated behavior, so has none. I should make that explicit though, e.g. document that any result returned by f is ignored. Since oops_do and weak_oops_do are expected to be the usual iteration entry points, and the early termination support doesn't affect them at all, I would like to leave it in place, to support use-cases like that one from JVMTI. As we discussed during pre-review, ParState doesn't support early termination, since ParState is for exclusive use by GC, and we don't have or envision use-cases for early termination by GC. > Apart from the above minor remarks, I am delighted to see these changes. I am extra delighted to see deleted_handle() disappear. I am also delighted to see the new simplified synchronization for parallel iteration - that worked out nicely. Thank you for building a good oop storage solution. Thanks. From kim.barrett at oracle.com Wed Jan 10 21:10:44 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 10 Jan 2018 16:10:44 -0500 Subject: RFR: 8194312: Support parallel and concurrent JNI global handle processing In-Reply-To: <987c2652-ef28-2546-e351-d70e5be2d35c@oracle.com> References: <48A47626-1FB7-4215-8A8C-B66E8D01FB70@oracle.com> <8159e4d8-a7e7-ddbd-f55e-adf596f2399d@oracle.com> <4D514E8F-B4A4-4B44-8734-E55D541EEA1D@oracle.com> <987c2652-ef28-2546-e351-d70e5be2d35c@oracle.com> Message-ID: <804848F6-6A8C-4C0C-B14F-1804C81612B9@oracle.com> > On Jan 10, 2018, at 8:56 AM, coleen.phillimore at oracle.com wrote: > > > > On 1/8/18 10:44 PM, Kim Barrett wrote: >>> I feel like BasicParState should be in an oopStorage.inline.hpp file to be included by the GCs that need it. Runtime code only needs to include oopStorage.hpp and doesn't need this code. >> I forgot to deal with your pre-review suggestion of moving some stuff >> to oopStorage.inline.hpp. I'd like to defer making such a change >> until this review is (mostly) done, rather than clutter up diffs. >> >> I think all (or very nearly all) of the inline definitions in >> oopStorage.hpp could be moved. I think they're all related to >> iteration, and I think most clients (other than GC) won't be using >> iteration at all. >> >> I think having the parallel iteration support wrapped with >> #ifdef INCLUDE_ALL_GCS (as is already the case) deals with the >> conditional GC usage; I think that all except Serial will eventually >> use it. >> >> The parallel iteration support could be split out into another file, >> so places that only use serial iteration (like jvmti) wouldn't include >> it, but I think the number of such places doesn't warrant another >> file. > > I would like that it be split out into another file. A lot of places in the runtime will only create and add oops to OopStorage and shouldn't care about iteration. I'm fine with making this change as a further improvement. I'm unclear on what you are asking for. Do you want A. Two files: (1) oopStorage.hpp - contains just class OopStorage. (2) oopStorage.inline.hpp - contains all the inline definitions presently in oopStorage.hpp. or B. Three files: (1) oopStorage.hpp - contains just class OopStorage. (2) oopStorage.inline.hpp - contains all the inline definitions presently in oopStorage.hpp, except for the ParState stuff. (3) oopStorageParState.inline.hpp - contains the ParState stuff. or C. Two files: (1) oopStorage.hpp - contains class OopStorage and all the inline definitions presently in oopStorage.hpp, except for the ParState stuff. (2) oopStorage.inline.hpp - contains the ParState stuff. I'm fine with option (A). Option (B) is unusual, but plausible; among other things, inclusion of the ParState header by non-GC code is suspicious. I'm not sure that's worth another file. Option (C) doesn't seem like what you are asking for, but included for completeness. From coleen.phillimore at oracle.com Wed Jan 10 21:15:39 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 10 Jan 2018 16:15:39 -0500 Subject: RFR: 8194312: Support parallel and concurrent JNI global handle processing In-Reply-To: <804848F6-6A8C-4C0C-B14F-1804C81612B9@oracle.com> References: <48A47626-1FB7-4215-8A8C-B66E8D01FB70@oracle.com> <8159e4d8-a7e7-ddbd-f55e-adf596f2399d@oracle.com> <4D514E8F-B4A4-4B44-8734-E55D541EEA1D@oracle.com> <987c2652-ef28-2546-e351-d70e5be2d35c@oracle.com> <804848F6-6A8C-4C0C-B14F-1804C81612B9@oracle.com> Message-ID: On 1/10/18 4:10 PM, Kim Barrett wrote: >> On Jan 10, 2018, at 8:56 AM, coleen.phillimore at oracle.com wrote: >> >> >> >> On 1/8/18 10:44 PM, Kim Barrett wrote: >>>> I feel like BasicParState should be in an oopStorage.inline.hpp file to be included by the GCs that need it. Runtime code only needs to include oopStorage.hpp and doesn't need this code. >>> I forgot to deal with your pre-review suggestion of moving some stuff >>> to oopStorage.inline.hpp. I'd like to defer making such a change >>> until this review is (mostly) done, rather than clutter up diffs. >>> >>> I think all (or very nearly all) of the inline definitions in >>> oopStorage.hpp could be moved. I think they're all related to >>> iteration, and I think most clients (other than GC) won't be using >>> iteration at all. >>> >>> I think having the parallel iteration support wrapped with >>> #ifdef INCLUDE_ALL_GCS (as is already the case) deals with the >>> conditional GC usage; I think that all except Serial will eventually >>> use it. >>> >>> The parallel iteration support could be split out into another file, >>> so places that only use serial iteration (like jvmti) wouldn't include >>> it, but I think the number of such places doesn't warrant another >>> file. >> I would like that it be split out into another file. A lot of places in the runtime will only create and add oops to OopStorage and shouldn't care about iteration. I'm fine with making this change as a further improvement. > I'm unclear on what you are asking for. Do you want > > A. Two files: > > (1) oopStorage.hpp - contains just class OopStorage. > > (2) oopStorage.inline.hpp - contains all the inline definitions > presently in oopStorage.hpp. > > or > > B. Three files: > > (1) oopStorage.hpp - contains just class OopStorage. > > (2) oopStorage.inline.hpp - contains all the inline definitions > presently in oopStorage.hpp, except for the ParState stuff. > > (3) oopStorageParState.inline.hpp - contains the ParState stuff. > > or > > C. Two files: > > (1) oopStorage.hpp - contains class OopStorage and all the inline > definitions presently in oopStorage.hpp, except for the ParState > stuff. > > (2) oopStorage.inline.hpp - contains the ParState stuff. > > I'm fine with option (A). Option (B) is unusual, but plausible; among > other things, inclusion of the ParState header by non-GC code is > suspicious. I'm not sure that's worth another file. Option (C) > doesn't seem like what you are asking for, but included for > completeness. > I think B.? I'd have to see it.?? Put this in the RFE. Coleen From david.holmes at oracle.com Wed Jan 10 22:26:24 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Jan 2018 08:26:24 +1000 Subject: RFR: JDK-8194762: JTReg failure of "runtime/NMT/PrintNMTStatistics.java" In-Reply-To: <933348e1c66f46d68b5c5cab3b200c44@NASANEXM01E.na.qualcomm.com> References: <933348e1c66f46d68b5c5cab3b200c44@NASANEXM01E.na.qualcomm.com> Message-ID: <3268e828-84dc-cac6-6600-932000908b40@oracle.com> Hi Daniel, I think we will need Zhengyu to chime in and explain what NMT related errors this was intending to catch. The simple search for "error" is obviously too coarse when you may have various logging output enabled. Even this: 64 output_summary.shouldNotContain("error"); may fail if there is additional logging output. Thanks, David On 11/01/2018 1:28 AM, stewartd.qdt wrote: > Please review this small webrev [1] that removes the search for the word "error" in stdout for the PrintNMTStatistics during the NativeMemoryTracking=details sub-test of the JTReg test. > > I have found that on my test machine (AArch64, Linux) when the detailed list is printed there is a module called "LogOutputList" that has as one of the listed functions "_dl_catch_error". Since the HTReg test simply searches for the word "error" in stdout, this test fails. However, there really isn't a failure to behave correctly and all the details are printed correctly. It also returns 0 on exit, as it should. The full log is attached to the bug report. > > I have created this patch in the belief that the test is being overly restrictive in searching for "error" In stdout and that printing out "_dl_catch_error" is correct behavior and shouldn't cause the test to fail. > > Please let me know if this is a bad approach and I'll be happy to change as required. > > Thanks, > Daniel Stewart > > [1] webrev: http://cr.openjdk.java.net/~dstewart/8194762/webrev.00/ > [2] CR: https://bugs.openjdk.java.net/browse/JDK-8194762 > From erik.osterlund at oracle.com Thu Jan 11 00:23:03 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 11 Jan 2018 01:23:03 +0100 Subject: RFR: 8194312: Support parallel and concurrent JNI global handle processing In-Reply-To: <4D611A04-F9AB-4681-80DC-DAA53D1EE3A9@oracle.com> References: <48A47626-1FB7-4215-8A8C-B66E8D01FB70@oracle.com> <5A561A0C.90803@oracle.com> <4D611A04-F9AB-4681-80DC-DAA53D1EE3A9@oracle.com> Message-ID: <64b74847-c0bc-713d-cf12-4083aa6ca5a8@oracle.com> Hi Kim, On 2018-01-10 21:57, Kim Barrett wrote: >> On Jan 10, 2018, at 8:50 AM, Erik ?sterlund wrote: >> >> Hi Kim, >> >> I have already seen earlier incarnations of this code so I only have a few comments regarding things that were not in that incarnation. > Thanks for looking at it yet again. > >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/OopStorage.java: >> >> The Java implementation of OopStorage for the SA agent seems a bit empty and full of TODO comments to actually implement something. It seems like quite a bit of the other changes to the SA assumes that this actually does something. For example there are changes to use OopStorage oopsDo instead of JNIHandleBlock oopsDo, which I presume means there has to be some oopsDo implementation in place for OopStorage. >> Is the intention to implement that later on in a separate RFE? > Quoting from the original RFR email: > > - Serviceability Agent updates for OopStorage and JNI usage. Just > enough has been done to allow existing SA tests to "pass". This > will be addressed as a followup. > > I haven't filed that RFE yet, but will be doing so. Okay, I see. Thank you for the explanation. I missed that. >> src/hotspot/share/gc/shared/oopStorage.hpp: >> >> The OopStorage::oops_do functions accept some kind of OopClosure and performs iteration with it. I'm curious though why it takes the specific type of OopClosure as a template parameter, passes it around, and eventually discards the information without making use of it? I was thinking perhaps the intention was to use the closure type information to devirtualize the do_oop() call, but that does not appear to be the case. To do that you would have to in OopStorage::OopFn::operator()() perform a qualified _cl->Closure::do_oop() call instead of _cl->do_oop() (and possibly take some care to prevent abstract oop closure types like OopClosure or ExtendedOopClosure from being devirtualized, which would be awkward (doable with some EnableIf::value>::type overload, or something like that). >> In other words, it seems like either this template parameter is unnecessary and you could just replace uses of it with OopClosure, or it should be made useful, e.g. by devirtualizing the calls or something. Same goes for the IsAliveClosure parameter for weak_oops_do. > Sorry, but I'm not understanding what problem is being suggested. > OopStorage doesn't depend on OopClosure as a type, at all, anywhere. > There are no occurrences of the type OopClosure anywhere in the > OopStorage implementation. The types coming in to OopStorage > iteration are preserved and used, without any need for odd syntax. > > With the type preserved like that, for common use-cases such as > > MyClosureType my_closure; > storage->oops_do(&my_closure); > > the compiler can know the exact type of my_closure at the call site > for do_oop(), in which case the compiler can devirtualize the call > (and I would expect any decent compiler to do so; I've seen gcc do it). > > Maybe the issue is about JNIHandles::oops_do and friends, which > presently are ordinary functions with OopClosure* arguments and the > like? Yes, the type information isn't flowing through there from the > caller to the OopStorage infrastructure. That's because that was > going to introduce some additional fannout in this changeset. I was > going to move the inline definitions to oopStorage.inline.hpp (per > Coleen's pre-review request), and all uses of iteration would then > need to be changed to include that, which would have required a new > jniHandles.inline.hpp, which would have required at least some > additional downstream include changes. I'm planning to make those > changes as a followup. Of course, I then forgot Coleen's pre-review > request. Your example may very well be devirtualized. But your assumption that passing around the type information is what allows that devirtualization is incorrect. In fact it does not make it any easier at all. If you have a class A and a class B derived from A (and no other classes in your program), then seeing an arbitrary value of type B* at a call site does not make it safe to devirtualize calls to such objects in the general case. You need more than the type information here. There is no way for the compiler to prove that there is not another class C deriving from B in some other compilation unit that will be linked in at some later stage (link-time or even run-time), and hence unless otherwise proven through something other than the declared type, the B* might (from the compiler point of view) hypothetically point at a C* instance. What the compiler may do though which is probably what you have observed, is to perform points-to analysis that proves that all possible values of the object at the call site have the exact type of B, by following the object as it gets passed around back to all possible allocation sites from the call site, using data-flow analysis, proving that all those allocation sites were of type B. And that points-to analysis is not being helped in any way by passing around the exact type in declarations. In fact, you could pass the type inaccurately as A* and the compiler will still see that all possible values of the object at the callsite are exactly B and devirtualize the call anyway. When points-to analysis can prove the type of the object, the passed around type information no longer matters. And when points-to analysis can not prove the type of the object, the passed around type information still does not matter. Here is a small sample program you can compile to assembly to demonstrate my point with clang/g++ -O3 -S main.cpp: #include class A { public: ? virtual void foo() { ??? printf("A::foo"); ? } }; class B: public A { public: ? virtual void foo() { ??? printf("B::foo"); ? } }; extern B& get_b(); int main(int argc, char* argv[]) { ? B& b_ref = get_b(); ? B b; ? A& a_ref = b; ? b.foo();??????? // generates non-virtual call; points-to analysis (trivially) determines the derived type of all possible values of b is B ? a_ref.foo();??? // generates non-virtual call; points-to analysis determines the derived type of all possible values of a_ref is B (despite declared type being A - it does not matter) ? b_ref.foo();??? // generates virtual call; points-to analysis can not determine the derived type of all possible values of b_ref is B. The declared type B does not matter or help in any way, as another compilation unit could have derived B. Only with link-time optimization is it safe to remove the virtual call ? b_ref.B::foo(); // generates non-virtual call; qualifier forces B interpretation and devirtualizes the call; no need to worry about having no clue about the dynamic type ? return 0; } I disassembled with both clang and gcc to verify that my comments reflect reality. What I am trying to say is that the compiler will not be able to devirtualize any more or less calls to the OopClosure by passing around its exact type as a Closure type parameter, unless you utilize that type information to devirtualize it with a qualified _cl->Closure::do_oop(), which is the proper way to devirtualize calls (without relying on the success of points-to analysis finding all allocation sites, which still is invariant of the passed around Closure type information). Therefore, it seems strange to me to pass around the Closure type as a template parameter, but then never make any use of that type information. So my suggestion remains the same: either make use of the type information by explicitly devirtualizing the calls to do_oop, or remove that template type and replace it with OopClosure instead, as that is equally as accurate for virtual calls that are not explicitly devirtualized, and makes it a bit easier to read. > >> src/hotspot/share/gc/shared/oopStorage.cpp: >> >> I recall in the pre-review we had some discussion about whether the infrastructure for supporting early iteration termination was necessary or not. You had me convinced that JNI would need it for something. Is this still the case, or has that use case been revised? Reading through the new JNI code, I could not find uses of OopStorage::iterate_safepoint() from the JNI code, and hence no uses of early termination. Having said that, it does look rather simple now with only the sequential case supporting early termination. >> However, if there is indeed no use any longer for OopStorage::iterate() and hence the only publicly available tool for early iteration exit, I wonder if perhaps it should be reconsidered if we want to remove that infrastructure. Or will there be other use cases down the road? Currently I find it at least a bit confusing that, e.g. OopStorage::iterate_safepoint() expects a function of type F that returns bool while OopStorage::BasicParState::iterate() expects a function of type F that returns void. For the OopStorage::iterate_safepoint() case it is clearly described in the documentation, in the OopStorage::BasicParState::iterate() case I did not find it clear that this F is a different F to the safepoint one. >> I guess I propose either removing early termination support alltogether if nobody is using it anyway (and hence having the F function type consistently return void), or documenting clearly that the sequential and parallel iteration functions expect different function types - one with bool return type and one with void return type, depending on whether early termination is supported or not. > The SimpleRootsClosure used by > VM_HeapWalkOperation::collect_simple_roots is a use-case for early > termination. I see. Sounds like it is still worthwhile to keep early termination then. > iteration_safepoint documents a requirement on the result of the > argument function (the result must be implicitly convertible to > bool), and the associated behavior. ParState::iterate doesn't specify > any requirements on the result of the argument function, nor specify > any associated behavior, so has none. I should make that explicit > though, e.g. document that any result returned by f is ignored. Yes, documenting that explicitly would be fantastic. > Since oops_do and weak_oops_do are expected to be the usual iteration > entry points, and the early termination support doesn't affect them at > all, I would like to leave it in place, to support use-cases like that > one from JVMTI. As we discussed during pre-review, ParState doesn't > support early termination, since ParState is for exclusive use by GC, > and we don't have or envision use-cases for early termination by GC. I am okay with leaving it in place. Thanks, /Erik >> Apart from the above minor remarks, I am delighted to see these changes. I am extra delighted to see deleted_handle() disappear. I am also delighted to see the new simplified synchronization for parallel iteration - that worked out nicely. Thank you for building a good oop storage solution. > Thanks. > From zgu at redhat.com Thu Jan 11 02:19:56 2018 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 10 Jan 2018 21:19:56 -0500 Subject: RFR: JDK-8194762: JTReg failure of "runtime/NMT/PrintNMTStatistics.java" In-Reply-To: <3268e828-84dc-cac6-6600-932000908b40@oracle.com> References: <933348e1c66f46d68b5c5cab3b200c44@NASANEXM01E.na.qualcomm.com> <3268e828-84dc-cac6-6600-932000908b40@oracle.com> Message-ID: <5b29173f-6dd6-e6b0-c351-0d2b3208a0d0@redhat.com> The fix looks fine to me. On 01/10/2018 05:26 PM, David Holmes wrote: > Hi Daniel, > > I think we will need Zhengyu to chime in and explain what NMT related > errors this was intending to catch. The simple search for "error" is > obviously too coarse when you may have various logging output enabled. > Even this: > > 64 output_summary.shouldNotContain("error"); I don't think NMT emits any error messages, so this line does not make sense. Thanks, -Zhengyu > > may fail if there is additional logging output. > > Thanks, > David > > On 11/01/2018 1:28 AM, stewartd.qdt wrote: >> Please review this small webrev [1] that removes the search for the >> word "error" in stdout for the PrintNMTStatistics during the >> NativeMemoryTracking=details sub-test of the JTReg test. >> >> I have found that on my test machine (AArch64, Linux) when the >> detailed list is printed there is a module called "LogOutputList" that >> has as one of the listed functions "_dl_catch_error". Since the HTReg >> test simply searches for the word "error" in stdout, this test fails. >> However, there really isn't a failure to behave correctly and all the >> details are printed correctly. It also returns 0 on exit, as it >> should. The full log is attached to the bug report. >> >> I have created this patch in the belief that the test is being overly >> restrictive in searching for "error" In stdout and that printing out >> "_dl_catch_error" is correct behavior and shouldn't cause the test to >> fail. >> >> Please let me know if this is a bad approach and I'll be happy to >> change as required. >> >> Thanks, >> Daniel Stewart >> >> [1] webrev: http://cr.openjdk.java.net/~dstewart/8194762/webrev.00/ >> [2] CR: https://bugs.openjdk.java.net/browse/JDK-8194762 >> From david.holmes at oracle.com Thu Jan 11 02:35:40 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Jan 2018 12:35:40 +1000 Subject: RFR: JDK-8194762: JTReg failure of "runtime/NMT/PrintNMTStatistics.java" In-Reply-To: <5b29173f-6dd6-e6b0-c351-0d2b3208a0d0@redhat.com> References: <933348e1c66f46d68b5c5cab3b200c44@NASANEXM01E.na.qualcomm.com> <3268e828-84dc-cac6-6600-932000908b40@oracle.com> <5b29173f-6dd6-e6b0-c351-0d2b3208a0d0@redhat.com> Message-ID: <7569fa88-f57e-5385-c722-c6c242cc3fff@oracle.com> Okay I'm happy that the test will not accidentally pass if unexpected errors occurs. As the test just does -version then the only errors would be initialization errors that result in a non-zero return code. As the test checks for expected output from NMT and that output is produced as the VM shuts down, then it seems very unlikely for an unrelated error to occur but still see the NMT output and get a zero return code. So both occurrences of: output_detail.shouldNotContain("error"); can be removed. Thanks, David On 11/01/2018 12:19 PM, Zhengyu Gu wrote: > The fix looks fine to me. > > On 01/10/2018 05:26 PM, David Holmes wrote: >> Hi Daniel, >> >> I think we will need Zhengyu to chime in and explain what NMT related >> errors this was intending to catch. The simple search for "error" is >> obviously too coarse when you may have various logging output enabled. >> Even this: >> >> ?? 64???? output_summary.shouldNotContain("error"); > > I don't think NMT emits any error messages, so this line does not make > sense. > > Thanks, > > -Zhengyu > > >> >> may fail if there is additional logging output. >> >> Thanks, >> David >> >> On 11/01/2018 1:28 AM, stewartd.qdt wrote: >>> Please review this small webrev [1] that removes the search for the >>> word "error" in stdout for the PrintNMTStatistics during the >>> NativeMemoryTracking=details sub-test of the JTReg test. >>> >>> I have found that on my test machine (AArch64, Linux) when the >>> detailed list is printed there is a module called "LogOutputList" >>> that has as one of the listed functions "_dl_catch_error". Since the >>> HTReg test simply searches for the word "error" in stdout, this test >>> fails. However, there really isn't a failure to behave correctly and >>> all the details are printed correctly. It also returns 0 on exit, as >>> it should. The full log is attached to the bug report. >>> >>> I have created this patch in the belief that the test is being overly >>> restrictive in searching for "error" In stdout and that printing out >>> "_dl_catch_error" is correct behavior and shouldn't cause the test to >>> fail. >>> >>> Please let me know if this is a bad approach and I'll be happy to >>> change as required. >>> >>> Thanks, >>> Daniel Stewart >>> >>> [1] webrev: http://cr.openjdk.java.net/~dstewart/8194762/webrev.00/ >>> [2] CR: https://bugs.openjdk.java.net/browse/JDK-8194762 >>> From rahul.v.raghavan at oracle.com Thu Jan 11 08:20:58 2018 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Thu, 11 Jan 2018 13:50:58 +0530 Subject: [aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV In-Reply-To: References: <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com> <20e812bc-d132-9863-815b-345283f9517e@redhat.com> <3c83440f-dd4b-f988-1f96-afa88dff36eb@redhat.com> Message-ID: < Just resending below review request email from Stuart for 8193266 including aarch64-port-dev also. Thanks.> -- On Saturday 06 January 2018 12:13 AM, Stuart Monteith wrote: I've removed the AARCH64 conditionals, added the empty line I removed, and changed the type of "use_XOR_for_compressed_class_base" to bool. http://cr.openjdk.java.net/~smonteith/8193266/webrev-5/ BR, Stuart > On 4 January 2018 at 14:45, Andrew Haley wrote: >> Hi, >> >> On 04/01/18 14:26, coleen.phillimore at oracle.com wrote: >>> I was going to offer to sponsor this since it touches shared code but >>> I'm not sure I like that there's AARCH64 specific code in >>> universe.cpp/hpp. And the name is somewhat offputting, suggesting >>> implementation details of one target leaking into shared code. >>> >>> set_use_XOR_for_compressed_class_base >>> >>> I think webrev-3 looked more reasonable, and could elide the #ifdef >>> AARCH64 in the shared code for that version. And the indentation is >>> better. >> >> I hate the #ifdef AARCH64 stuff too, but it's always a sign that there >> is something wrong with the front-end to back-end modularization. We >> can handle the use_XOR_for_compressed_class_base later: we really >> should have a way to communicate with the back ends when the memory >> layout is initialized. We can go with webrev-3. >> >> -- >> Andrew Haley >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From coleen.phillimore at oracle.com Thu Jan 11 12:29:58 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 11 Jan 2018 07:29:58 -0500 Subject: [aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV In-Reply-To: References: <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com> <20e812bc-d132-9863-815b-345283f9517e@redhat.com> <3c83440f-dd4b-f988-1f96-afa88dff36eb@redhat.com> Message-ID: <30064ec2-224f-174a-8eb2-670123edf2e3@oracle.com> This looks good to me.?? I will sponsor this fix, once we confirm the reviewers and you commit the patch and rerun the webrev (so it's in jdk10.patch).?? I see this is for jdk10. thanks, Coleen On 1/5/18 1:43 PM, Stuart Monteith wrote: > I've removed the AARCH64 conditionals, added the empty line I removed, > and changed the type of "use_XOR_for_compressed_class_base" to bool. > > http://cr.openjdk.java.net/~smonteith/8193266/webrev-5/ > > BR, > Stuart > > > On 4 January 2018 at 14:45, Andrew Haley wrote: >> Hi, >> >> On 04/01/18 14:26, coleen.phillimore at oracle.com wrote: >>> I was going to offer to sponsor this since it touches shared code but >>> I'm not sure I like that there's AARCH64 specific code in >>> universe.cpp/hpp. And the name is somewhat offputting, suggesting >>> implementation details of one target leaking into shared code. >>> >>> set_use_XOR_for_compressed_class_base >>> >>> I think webrev-3 looked more reasonable, and could elide the #ifdef >>> AARCH64 in the shared code for that version. And the indentation is >>> better. >> I hate the #ifdef AARCH64 stuff too, but it's always a sign that there >> is something wrong with the front-end to back-end modularization. We >> can handle the use_XOR_for_compressed_class_base later: we really >> should have a way to communicate with the back ends when the memory >> layout is initialized. We can go with webrev-3. >> >> -- >> Andrew Haley >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From glaubitz at physik.fu-berlin.de Thu Jan 11 13:15:09 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 11 Jan 2018 14:15:09 +0100 Subject: [PATCH] Fail to build zero on x86 In-Reply-To: References: <7cb322b4-4fae-2f78-b5cc-5b1d0e7cb4e8@physik.fu-berlin.de> Message-ID: Hi Ao! On 01/10/2018 01:58 AM, Ao Qi wrote: > Thanks for your information. We have a Jenkins server to build OpenJDK 8/9/10 on x86 > and MIPS (loongson3a), and I have already used those patches:) Hope those patches > can be submitted to upstream. Yes, they definitely will be. In the meantime, I wanted to open a bug report with the issue you reported, so I started building OpenJDK with the --disable-warnings-treated-as-errors configure flag removed. However, I did not run into the issue you reported but my build bailed out earlier already: === Output from failing command(s) repeated here === /usr/bin/printf "* For target support_native_java.base_libjava_TimeZone_md.o:\n" * For target support_native_java.base_libjava_TimeZone_md.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/upstream/hs/build/linux-x86_64-normal-zero-release/make-support/failure-logs/support_native_java.base_libjava_TimeZone_md.o.log || true) | /usr/bin/head -n 12 /home/glaubitz/upstream/hs/src/java.base/unix/native/libjava/TimeZone_md.c: In function ?findZoneinfoFile?: /home/glaubitz/upstream/hs/src/java.base/unix/native/libjava/TimeZone_md.c:150:5: error: ?readdir64_r? is deprecated [-Werror=deprecated-declarations] while (readdir64_r(dirp, entry, &dp) == 0 && dp != NULL) { ^~~~~ In file included from /home/glaubitz/upstream/hs/src/java.base/unix/native/libjava/TimeZone_md.c:36:0: /usr/include/dirent.h:201:12: note: declared here extern int readdir64_r (DIR *__restrict __dirp, ^~~~~~~~~~~ cc1: all warnings being treated as errors if test `/usr/bin/wc -l < /home/glaubitz/upstream/hs/build/linux-x86_64-normal-zero-release/make-support/failure-logs/support_native_java.base_libjava_TimeZone_md.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi /usr/bin/printf "* For target support_native_java.base_libverify_check_code.o:\n" * For target support_native_java.base_libverify_check_code.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/upstream/hs/build/linux-x86_64-normal-zero-release/make-support/failure-logs/support_native_java.base_libverify_check_code.o.log || true) | /usr/bin/head -n 12 /home/glaubitz/upstream/hs/src/java.base/share/native/libverify/check_code.c: In function ?verify_opcode_operands?: /home/glaubitz/upstream/hs/src/java.base/share/native/libverify/check_code.c:1391:9: error: this statement may fall through [-Werror=implicit-fallthrough=] CCerror(context, ^~~~~~~~~~~~~~~~ "invokedynamic bytecode is not supported in this class file version"); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/glaubitz/upstream/hs/src/java.base/share/native/libverify/check_code.c:1394:5: note: here case JVM_OPC_instanceof: ^~~~ cc1: all warnings being treated as errors if test `/usr/bin/wc -l < /home/glaubitz/upstream/hs/build/linux-x86_64-normal-zero-release/make-support/failure-logs/support_native_java.base_libverify_check_code.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi /usr/bin/printf "\n* All command lines available in /home/glaubitz/upstream/hs/build/linux-x86_64-normal-zero-release/make-support/failure-logs.\n" * All command lines available in /home/glaubitz/upstream/hs/build/linux-x86_64-normal-zero-release/make-support/failure-logs. /usr/bin/printf "=== End of repeated output ===\n" === End of repeated output === if /bin/grep -q "recipe for target .* failed" /home/glaubitz/upstream/hs/build/linux-x86_64-normal-zero-release/build.log 2> /dev/null; then /usr/bin/printf "\n=== Make failed targets repeated here ===\n" ; /bin/grep "recipe for target .* failed" /home/glaubitz/upstream/hs/build/linux-x86_64-normal-zero-release/build.log ; /usr/bin/printf "=== End of repeated output ===\n" ; /usr/bin/printf "\nHint: Try searching the build log for the name of the first failed target.\n" ; else /usr/bin/printf "\nNo indication of failed target found.\n" ; /usr/bin/printf "Hint: Try searching the build log for '] Error'.\n" ; fi === Make failed targets repeated here === CoreLibraries.gmk:157: recipe for target '/home/glaubitz/upstream/hs/build/linux-x86_64-normal-zero-release/support/native/java.base/libjava/TimeZone_md.o' failed CoreLibraries.gmk:110: recipe for target '/home/glaubitz/upstream/hs/build/linux-x86_64-normal-zero-release/support/native/java.base/libverify/check_code.o' failed make/Main.gmk:226: recipe for target 'java.base-libs' failed === End of repeated output === Did you run into this issue as well? We should probably deal with this issue first depending on whether it affects the Server variant as well. I am testing this now. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Thu Jan 11 13:21:07 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 11 Jan 2018 14:21:07 +0100 Subject: [PATCH] Fail to build zero on x86 In-Reply-To: References: <7cb322b4-4fae-2f78-b5cc-5b1d0e7cb4e8@physik.fu-berlin.de> Message-ID: On 01/11/2018 02:15 PM, John Paul Adrian Glaubitz wrote: > Did you run into this issue as well? We should probably deal with this > issue first depending on whether it affects the Server variant as well. > > I am testing this now. And it seems the Server variant will also fail without --disable-warnings-as-errors, but the builds bails out at a different place: === Output from failing command(s) repeated here === /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_assembler_x86.o:\n" * For target hotspot_variant-server_libjvm_objs_assembler_x86.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/upstream/hs/build/linux-x86_64-normal-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_assembler_x86.o.log || true) | /usr/bin/head -n 12 /home/glaubitz/upstream/hs/src/hotspot/cpu/x86/assembler_x86.cpp: In static member function ?static Address Address::make_raw(int, int, int, int, relocInfo::relocType)?: /home/glaubitz/upstream/hs/src/hotspot/cpu/x86/assembler_x86.cpp:199:12: error: ?*((void*)& rspec +32)? may be used uninitialized in this function [-Werror=maybe-uninitialized] return madr; ^~~~ /home/glaubitz/upstream/hs/src/hotspot/cpu/x86/assembler_x86.cpp:199:12: error: ?*((void*)& rspec +24)? may be used uninitialized in this function [-Werror=maybe-uninitialized] /home/glaubitz/upstream/hs/src/hotspot/cpu/x86/assembler_x86.cpp:199:12: error: ?*((void*)& rspec +16)? may be used uninitialized in this function [-Werror=maybe-uninitialized] cc1plus: all warnings being treated as errors if test `/usr/bin/wc -l < /home/glaubitz/upstream/hs/build/linux-x86_64-normal-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_assembler_x86.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi /usr/bin/printf "\n* All command lines available in /home/glaubitz/upstream/hs/build/linux-x86_64-normal-server-release/make-support/failure-logs.\n" * All command lines available in /home/glaubitz/upstream/hs/build/linux-x86_64-normal-server-release/make-support/failure-logs. /usr/bin/printf "=== End of repeated output ===\n" === End of repeated output === So, I guess we should have a discussion in general whether and how to handle these issues in OpenJDK-11, i.e. whether we should have one big patch to address all of these warnings or whether we should have individual bug reports and changesets. Opinions? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From sgehwolf at redhat.com Thu Jan 11 14:00:19 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 11 Jan 2018 15:00:19 +0100 Subject: [PATCH] Fail to build zero on x86 In-Reply-To: References: <7cb322b4-4fae-2f78-b5cc-5b1d0e7cb4e8@physik.fu-berlin.de> Message-ID: <1515679219.6689.17.camel@redhat.com> On Thu, 2018-01-11 at 14:21 +0100, John Paul Adrian Glaubitz wrote: > On 01/11/2018 02:15 PM, John Paul Adrian Glaubitz wrote: > > Did you run into this issue as well? We should probably deal with this > > issue first depending on whether it affects the Server variant as well. > > > > I am testing this now. > > And it seems the Server variant will also fail without --disable-warnings-as-errors, > but the builds bails out at a different place: > > === Output from failing command(s) repeated here === > /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_assembler_x86.o:\n" > * For target hotspot_variant-server_libjvm_objs_assembler_x86.o: > (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/upstream/hs/build/linux-x86_64-normal-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_assembler_x86.o.log || true) | /usr/bin/head -n 12 > /home/glaubitz/upstream/hs/src/hotspot/cpu/x86/assembler_x86.cpp: In static member function ?static Address Address::make_raw(int, int, int, int, relocInfo::relocType)?: > /home/glaubitz/upstream/hs/src/hotspot/cpu/x86/assembler_x86.cpp:199:12: error: ?*((void*)& rspec +32)? may be used uninitialized in this function [-Werror=maybe-uninitialized] > return madr; > ^~~~ > /home/glaubitz/upstream/hs/src/hotspot/cpu/x86/assembler_x86.cpp:199:12: error: ?*((void*)& rspec +24)? may be used uninitialized in this function [-Werror=maybe-uninitialized] > /home/glaubitz/upstream/hs/src/hotspot/cpu/x86/assembler_x86.cpp:199:12: error: ?*((void*)& rspec +16)? may be used uninitialized in this function [-Werror=maybe-uninitialized] > cc1plus: all warnings being treated as errors > if test `/usr/bin/wc -l < /home/glaubitz/upstream/hs/build/linux-x86_64-normal-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_assembler_x86.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi > /usr/bin/printf "\n* All command lines available in /home/glaubitz/upstream/hs/build/linux-x86_64-normal-server-release/make-support/failure-logs.\n" > > * All command lines available in /home/glaubitz/upstream/hs/build/linux-x86_64-normal-server-release/make-support/failure-logs. > /usr/bin/printf "=== End of repeated output ===\n" > === End of repeated output === > > So, I guess we should have a discussion in general whether and how to handle > these issues in OpenJDK-11, i.e. whether we should have one big patch to > address all of these warnings or whether we should have individual bug > reports and changesets. > > Opinions? As far as I know this heavily depends on the toolchain used to compile OpenJDK. Changing the compiler will produce different warnings. We usually run into this when building on Fedora with newer toolchains. If you fix the toolchain versions, which I believe Oracle does for their builds, you might be able to get a build with no warnings. I'm doubtful Zero would build without warnings even on such a toolchain, though. Once you deviate from the officially supported toolchain in some form you'll end up with some warnings. Getting rid of all warnings for all compiler versions/variants combinations might be a daunting task. My $0.02 Thanks, Severin From stewartd.qdt at qualcommdatacenter.com Thu Jan 11 14:06:47 2018 From: stewartd.qdt at qualcommdatacenter.com (stewartd.qdt) Date: Thu, 11 Jan 2018 14:06:47 +0000 Subject: RFR: JDK-8194762: JTReg failure of "runtime/NMT/PrintNMTStatistics.java" In-Reply-To: <7569fa88-f57e-5385-c722-c6c242cc3fff@oracle.com> References: <933348e1c66f46d68b5c5cab3b200c44@NASANEXM01E.na.qualcomm.com> <3268e828-84dc-cac6-6600-932000908b40@oracle.com> <5b29173f-6dd6-e6b0-c351-0d2b3208a0d0@redhat.com> <7569fa88-f57e-5385-c722-c6c242cc3fff@oracle.com> Message-ID: <1d35d1fee5dc44b6b628effdf83777bf@NASANEXM01E.na.qualcomm.com> Thanks, David. Please see the modified webrev: http://cr.openjdk.java.net/~dstewart/8194762/webrev.01/ Regards, Daniel -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Wednesday, January 10, 2018 9:36 PM To: Zhengyu Gu ; stewartd.qdt ; hotspot-dev at openjdk.java.net Subject: Re: RFR: JDK-8194762: JTReg failure of "runtime/NMT/PrintNMTStatistics.java" Okay I'm happy that the test will not accidentally pass if unexpected errors occurs. As the test just does -version then the only errors would be initialization errors that result in a non-zero return code. As the test checks for expected output from NMT and that output is produced as the VM shuts down, then it seems very unlikely for an unrelated error to occur but still see the NMT output and get a zero return code. So both occurrences of: output_detail.shouldNotContain("error"); can be removed. Thanks, David On 11/01/2018 12:19 PM, Zhengyu Gu wrote: > The fix looks fine to me. > > On 01/10/2018 05:26 PM, David Holmes wrote: >> Hi Daniel, >> >> I think we will need Zhengyu to chime in and explain what NMT related >> errors this was intending to catch. The simple search for "error" is >> obviously too coarse when you may have various logging output enabled. >> Even this: >> >> ?? 64???? output_summary.shouldNotContain("error"); > > I don't think NMT emits any error messages, so this line does not make > sense. > > Thanks, > > -Zhengyu > > >> >> may fail if there is additional logging output. >> >> Thanks, >> David >> >> On 11/01/2018 1:28 AM, stewartd.qdt wrote: >>> Please review this small webrev [1] that removes the search for the >>> word "error" in stdout for the PrintNMTStatistics during the >>> NativeMemoryTracking=details sub-test of the JTReg test. >>> >>> I have found that on my test machine (AArch64, Linux) when the >>> detailed list is printed there is a module called "LogOutputList" >>> that has as one of the listed functions "_dl_catch_error". Since the >>> HTReg test simply searches for the word "error" in stdout, this test >>> fails. However, there really isn't a failure to behave correctly and >>> all the details are printed correctly. It also returns 0 on exit, as >>> it should. The full log is attached to the bug report. >>> >>> I have created this patch in the belief that the test is being >>> overly restrictive in searching for "error" In stdout and that >>> printing out "_dl_catch_error" is correct behavior and shouldn't >>> cause the test to fail. >>> >>> Please let me know if this is a bad approach and I'll be happy to >>> change as required. >>> >>> Thanks, >>> Daniel Stewart >>> >>> [1] webrev: http://cr.openjdk.java.net/~dstewart/8194762/webrev.00/ >>> [2] CR: https://bugs.openjdk.java.net/browse/JDK-8194762 >>> From aph at redhat.com Thu Jan 11 14:59:36 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 11 Jan 2018 14:59:36 +0000 Subject: [PATCH] Fail to build zero on x86 In-Reply-To: <1515679219.6689.17.camel@redhat.com> References: <7cb322b4-4fae-2f78-b5cc-5b1d0e7cb4e8@physik.fu-berlin.de> <1515679219.6689.17.camel@redhat.com> Message-ID: On 11/01/18 14:00, Severin Gehwolf wrote: > As far as I know this heavily depends on the toolchain used to compile > OpenJDK. Changing the compiler will produce different warnings. We > usually run into this when building on Fedora with newer toolchains. Indeed. -Wall -Werror will break your build every time GCC is revised. This is because GCC adds warnings. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From andrew_m_leonard at uk.ibm.com Thu Jan 11 15:34:54 2018 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 11 Jan 2018 15:34:54 +0000 Subject: JVM interface header src location? Message-ID: Hi, with the new repo consolidation in JDK10+ the JVM interface headers (jvm.h and jvm_md.h) have moved from under jdk/src/java.base/share|/native/include/ to src/hotspot/share/include/jvm.h src/hotspot/os/windows/include/jvm_md.h src/hotspot/os/posix/include/jvm_md.h This implies these are "hotspot" headers, when they are actually generic JVM interface definitions. So for example if previously a 3rd party JVM implementor (eg.Eclipse OpenJ9) who does not clone the hotspot repo, and now does not clone the hotspot "folder", will now fail to find these generic headers... Wouldn't it be better for these headers to be under some generic "jvm" or "base" include folder? Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From bob.vandette at oracle.com Thu Jan 11 18:41:40 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 11 Jan 2018 13:41:40 -0500 Subject: RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers Message-ID: <39C5B4B1-6EEF-4E07-90BA-5EC77B83195B@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8193710 Webrev: http://cr.openjdk.java.net/~bobv/8193710/webrev.00/ Summary: This changeset enables the ability to use jcmd and jps running on a Host to list the java processes that are running in docker (cgroup based) containers. I?ve tested this change by examining processes running as root on both host and in docker containers as well as under my userid using ?jps and jcmd -l?. I?ve also tested the getFile functions with a small example program that I wrote. From what I can tell, these two getFile functions are not used in the JDK sources and in fact the PerfDataFile.getFile(int lvmid) method doesn?t appear to have never worked! I?d really like to remove these two methods. 140 candidate = new File(f.getName(), name); < References: Message-ID: <772a0b04-40a7-4c1a-ebf1-bedfd29bea21@oracle.com> Hi Andrew, On 12/01/2018 1:34 AM, Andrew Leonard wrote: > Hi, with the new repo consolidation in JDK10+ the JVM interface headers > (jvm.h and jvm_md.h) have moved from under > jdk/src/java.base/share|/native/include/ to > src/hotspot/share/include/jvm.h > src/hotspot/os/windows/include/jvm_md.h > src/hotspot/os/posix/include/jvm_md.h > This implies these are "hotspot" headers, when they are actually generic I wouldn't call them generic. They define the API that hotspot provides for use by the JDK. The JDK in turn is written to use whatever hotspot exports. Now we can treat that as a de-facto generic definition of what any VM that works with the JDK needs to provide, but it would be wrong to pretend/assume that this is somehow some nice clean abstract interface between the JDK and any VM. In short any VM you want to plug into the JDK has to impersonate hotspot from this API perspective. > JVM interface definitions. So for example if previously a 3rd party JVM > implementor (eg.Eclipse OpenJ9) who does not clone the hotspot repo, and > now does not clone the hotspot "folder", will now fail to find these > generic headers... Right ... it would have been good to have gotten some feedback on this when we did the file consolidation work: https://bugs.openjdk.java.net/browse/JDK-8189610 and then relocation: https://bugs.openjdk.java.net/browse/JDK-8190484 > Wouldn't it be better for these headers to be under some generic "jvm" or > "base" include folder? It would solve your problem. :) And I'm not opposed to moving them as a convenience to you. My main concern would be that this is not seen as a supported, exported, external contract between the JDK libraries and any VM. I would still consider it a private interface between the JDK and hotspot that changes whenever hotspot (or the JDK) needs it to. Cheers, David > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From mandy.chung at oracle.com Thu Jan 11 23:27:24 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 11 Jan 2018 15:27:24 -0800 Subject: JVM interface header src location? In-Reply-To: <772a0b04-40a7-4c1a-ebf1-bedfd29bea21@oracle.com> References: <772a0b04-40a7-4c1a-ebf1-bedfd29bea21@oracle.com> Message-ID: On 1/11/18 2:01 PM, David Holmes wrote: > >> Wouldn't it be better for these headers to be under some generic >> "jvm" or >> "base" include folder? > > It would solve your problem. :) And I'm not opposed to moving them as > a convenience to you. My main concern would be that this is not seen > as a supported, exported, external contract between the JDK libraries > and any VM. I would still consider it a private interface between the > JDK and hotspot that changes whenever hotspot (or the JDK) needs it to. > Right.? It's internal interface between JDK and hotspot. src/java.base/share/include wasn't the desired location for it and hence the relocation. Would it be an alternative if the source location of these header files can be configured at build time so that other JVM implementor can build JDK with an alternate location??? I would expect that other VM implementation would have to do some work for any change to jvm.h regardless of where it's located.? The extra (hopefully minimal) work is to update its own copy of jvm.h. Mandy From kim.barrett at oracle.com Fri Jan 12 00:56:57 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 11 Jan 2018 19:56:57 -0500 Subject: RFR: 8194312: Support parallel and concurrent JNI global handle processing In-Reply-To: <64b74847-c0bc-713d-cf12-4083aa6ca5a8@oracle.com> References: <48A47626-1FB7-4215-8A8C-B66E8D01FB70@oracle.com> <5A561A0C.90803@oracle.com> <4D611A04-F9AB-4681-80DC-DAA53D1EE3A9@oracle.com> <64b74847-c0bc-713d-cf12-4083aa6ca5a8@oracle.com> Message-ID: <5E6F31A5-E3EA-46C4-B488-9D97C6DB18D3@oracle.com> > On Jan 10, 2018, at 7:23 PM, Erik ?sterlund wrote: > > Your example may very well be devirtualized. But your assumption that passing around the type information is what allows that devirtualization is incorrect. In fact it does not make it any easier at all. > If you have a class A and a class B derived from A (and no other classes in your program), then seeing an arbitrary value of type B* at a call site does not make it safe to devirtualize calls to such objects in the general case. You need more than the type information here. There is no way for the compiler to prove that there is not another class C deriving from B in some other compilation unit that will be linked in at some later stage (link-time or even run-time), and hence unless otherwise proven through something other than the declared type, the B* might (from the compiler point of view) hypothetically point at a C* instance. > What the compiler may do though which is probably what you have observed, is to perform points-to analysis that proves that all possible values of the object at the call site have the exact type of B, by following the object as it gets passed around back to all possible allocation sites from the call site, using data-flow analysis, proving that all those allocation sites were of type B. And that points-to analysis is not being helped in any way by passing around the exact type in declarations. In fact, you could pass the type inaccurately as A* and the compiler will still see that all possible values of the object at the callsite are exactly B and devirtualize the call anyway. When points-to analysis can prove the type of the object, the passed around type information no longer matters. And when points-to analysis can not prove the type of the object, the passed around type information still does not matter. > > Here is a small sample program you can compile to assembly to demonstrate my point with clang/g++ -O3 -S main.cpp: > > #include > > class A { > public: > virtual void foo() { > printf("A::foo"); > } > }; > > class B: public A { > public: > virtual void foo() { > printf("B::foo"); > } > }; > > extern B& get_b(); > > int main(int argc, char* argv[]) { > B& b_ref = get_b(); > B b; > A& a_ref = b; > b.foo(); // generates non-virtual call; points-to analysis (trivially) determines the derived type of all possible values of b is B > a_ref.foo(); // generates non-virtual call; points-to analysis determines the derived type of all possible values of a_ref is B (despite declared type being A - it does not matter) > b_ref.foo(); // generates virtual call; points-to analysis can not determine the derived type of all possible values of b_ref is B. The declared type B does not matter or help in any way, as another compilation unit could have derived B. Only with link-time optimization is it safe to remove the virtual call > b_ref.B::foo(); // generates non-virtual call; qualifier forces B interpretation and devirtualizes the call; no need to worry about having no clue about the dynamic type > > return 0; > } > > I disassembled with both clang and gcc to verify that my comments reflect reality. > > What I am trying to say is that the compiler will not be able to devirtualize any more or less calls to the OopClosure by passing around its exact type as a Closure type parameter, unless you utilize that type information to devirtualize it with a qualified _cl->Closure::do_oop(), which is the proper way to devirtualize calls (without relying on the success of points-to analysis finding all allocation sites, which still is invariant of the passed around Closure type information). Therefore, it seems strange to me to pass around the Closure type as a template parameter, but then never make any use of that type information. > > So my suggestion remains the same: either make use of the type information by explicitly devirtualizing the calls to do_oop, or remove that template type and replace it with OopClosure instead, as that is equally as accurate for virtual calls that are not explicitly devirtualized, and makes it a bit easier to read. Okay, I understand what you are talking about now. And my earlier response was poor in a number of ways. I knew this question had come up before (during pre-review), but I completely misremembered the rationale and botched the response. You are correct that points-to analysis deals with a lot of issues. (Speculative devirtualization can help address some additional cases. Various mechanisms for informing the compiler that a visible definition is the final one and can't be further overridden can also help; local classes, classes in anonymous namespaces, C++11 final class and function annotations.) It would be incorrect for OopStorage to directly call a specific function via cl->ClosureType::do_oop, since ClosureType::do_oop might not be the most specialized definition. There's not a (good) way for the OopStorage source code to know or check that. (Actually, C++11 might provide some tools that could help in some cases.) One reason for iteration templates is to support const iteration. There are many iterations of collections of oops that never modify the contents of the collections, and really ought to be declared const. (Hotspot code seems often quite bad about const-correctness. OopStorage supports const iterations, though I'm not sure there's a use-case for const weak_oops_do; certainly the two argument form that nulls out dead entries can't be const. So that isn't supported.) OopClosure does not support const iteration, because it doesn't support application to a const oop*. By making iterate and oops_do be function templates, we don't require the "closure" argument to be derived from any particular base class, merely that it models the appropriate concept. So we can iterate using something which does support application to a const oop*. Another reason for iteration templates is to be forward-looking to C++11, where it becomes easy to pass in an instance of a local type, or a lambda, or a bind expression, all of which are ways to make used-in-one-place function objects conveniently at the point of use. This can often make the code much easier to understand than having to go somewhere else to find out what do_oop for *this* closure does. With a little work we could always use oops_do for iteration (and make iterate/iterate_safepoint private). There would be two versions of oops_do, one using cl->do_oop(p), the other cl(p), selected via a little metaprogramming (in C++11, I don't remember how hard it is in C++03, or if it's even possible.) From david.holmes at oracle.com Fri Jan 12 01:28:18 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Jan 2018 11:28:18 +1000 Subject: RFR: JDK-8194762: JTReg failure of "runtime/NMT/PrintNMTStatistics.java" In-Reply-To: <1d35d1fee5dc44b6b628effdf83777bf@NASANEXM01E.na.qualcomm.com> References: <933348e1c66f46d68b5c5cab3b200c44@NASANEXM01E.na.qualcomm.com> <3268e828-84dc-cac6-6600-932000908b40@oracle.com> <5b29173f-6dd6-e6b0-c351-0d2b3208a0d0@redhat.com> <7569fa88-f57e-5385-c722-c6c242cc3fff@oracle.com> <1d35d1fee5dc44b6b628effdf83777bf@NASANEXM01E.na.qualcomm.com> Message-ID: <40b319cb-dd89-d26c-18d4-ffd6103bf64d@oracle.com> Thanks Daniel. Reviewed and sponsored. Pushed to jdk/hs David On 12/01/2018 12:06 AM, stewartd.qdt wrote: > Thanks, David. > > Please see the modified webrev: http://cr.openjdk.java.net/~dstewart/8194762/webrev.01/ > > Regards, > Daniel > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Wednesday, January 10, 2018 9:36 PM > To: Zhengyu Gu ; stewartd.qdt ; hotspot-dev at openjdk.java.net > Subject: Re: RFR: JDK-8194762: JTReg failure of "runtime/NMT/PrintNMTStatistics.java" > > Okay I'm happy that the test will not accidentally pass if unexpected errors occurs. As the test just does -version then the only errors would be initialization errors that result in a non-zero return code. As the test checks for expected output from NMT and that output is produced as the VM shuts down, then it seems very unlikely for an unrelated error to occur but still see the NMT output and get a zero return code. > > So both occurrences of: > > output_detail.shouldNotContain("error"); > > can be removed. > > Thanks, > David > > On 11/01/2018 12:19 PM, Zhengyu Gu wrote: >> The fix looks fine to me. >> >> On 01/10/2018 05:26 PM, David Holmes wrote: >>> Hi Daniel, >>> >>> I think we will need Zhengyu to chime in and explain what NMT related >>> errors this was intending to catch. The simple search for "error" is >>> obviously too coarse when you may have various logging output enabled. >>> Even this: >>> >>> ?? 64???? output_summary.shouldNotContain("error"); >> >> I don't think NMT emits any error messages, so this line does not make >> sense. >> >> Thanks, >> >> -Zhengyu >> >> >>> >>> may fail if there is additional logging output. >>> >>> Thanks, >>> David >>> >>> On 11/01/2018 1:28 AM, stewartd.qdt wrote: >>>> Please review this small webrev [1] that removes the search for the >>>> word "error" in stdout for the PrintNMTStatistics during the >>>> NativeMemoryTracking=details sub-test of the JTReg test. >>>> >>>> I have found that on my test machine (AArch64, Linux) when the >>>> detailed list is printed there is a module called "LogOutputList" >>>> that has as one of the listed functions "_dl_catch_error". Since the >>>> HTReg test simply searches for the word "error" in stdout, this test >>>> fails. However, there really isn't a failure to behave correctly and >>>> all the details are printed correctly. It also returns 0 on exit, as >>>> it should. The full log is attached to the bug report. >>>> >>>> I have created this patch in the belief that the test is being >>>> overly restrictive in searching for "error" In stdout and that >>>> printing out "_dl_catch_error" is correct behavior and shouldn't >>>> cause the test to fail. >>>> >>>> Please let me know if this is a bad approach and I'll be happy to >>>> change as required. >>>> >>>> Thanks, >>>> Daniel Stewart >>>> >>>> [1] webrev: http://cr.openjdk.java.net/~dstewart/8194762/webrev.00/ >>>> [2] CR: https://bugs.openjdk.java.net/browse/JDK-8194762 >>>> From david.holmes at oracle.com Fri Jan 12 02:44:04 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Jan 2018 12:44:04 +1000 Subject: RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers In-Reply-To: <39C5B4B1-6EEF-4E07-90BA-5EC77B83195B@oracle.com> References: <39C5B4B1-6EEF-4E07-90BA-5EC77B83195B@oracle.com> Message-ID: Hi Bob, Some initial discussion and commentary. I'm a bit concerned by how much accommodating docker penalises code that is not using containers. On 12/01/2018 4:41 AM, Bob Vandette wrote: > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8193710 > > Webrev: > > http://cr.openjdk.java.net/~bobv/8193710/webrev.00/ > > Summary: > > This changeset enables the ability to use jcmd and jps running on a Host to > list the java processes that are running in docker (cgroup based) containers. Can you clarify this for me please. I assume we are still only listing processes for the current user - correct? So the issue is if I am running mutiple JVMs and also running a Docker process that itself contains JVMs then jps outside of Docker won't show the JVMs that are inside Docker. And presumably the opposite is also true? If we change jps to find all JVMs on the host for the current user, whether in a container or not (and whether jps is run from in a container or not?) are the process id's that get returned directly useable from where jps was run? > I?ve tested this change by examining processes running as root on both host and in > docker containers as well as under my userid using ?jps and jcmd -l?. > I?ve also tested the getFile functions with a small example program that I wrote. > From what I can tell, these two getFile functions are not used in the JDK sources > and in fact the PerfDataFile.getFile(int lvmid) method doesn?t appear to have never worked! > I?d really like to remove these two methods. If they are not used by anything then by all means drop them. > 140 candidate = new File(f.getName(), name); < > Here are some implementation details that I?ve added added to one of the Unix > specific source files (src/java.base/unix/classes/jdk/internal/vm/VMSupportImpl.java) I have an issue with this. This is not "unix" (ie anything other than windows) support code, it is Linux support code. I'm also unclear why this needs to be lifted out of the PerfMemory subsystem. And if you're going to mess with the jdk.internal module then I think core-libs folk will want to know before hand. Other comments ... src/hotspot/os/linux/perfMemory_linux.cpp I'm concerned about the MAXPATHLEN stack buffers and the extra overhead being added to the normal non-container path. We've had issues in the past where a newly added stack buffer caused StackOverflowError. We don't need a 4K buffer because os::get_temp_directory() just returns "/tmp" and we're dealing with all Linux code here. I don't like making assumptions like this but ... #define TMP_BUFFER_LEN (4 + 21) static char* get_user_tmp_dir(const char* user, int vmid, int nspid) { char buffer[TMP_BUFFER_LEN]; char* tmpdir = os::get_temp_directory(); assert(strlen(tmpdir) == 4, "No longer using /tmp - update buffer size"); if (nspid != -1) { jio_snprintf(buffer, TMP_BUFFER_LEN, "/proc/%d/root%s", vmid, tmpdir); tmpdir = buffer; } ... 657 char fname[64]; Maximum length of "/proc/%d/status" is 23. Thanks, David From kim.barrett at oracle.com Fri Jan 12 08:53:41 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 12 Jan 2018 03:53:41 -0500 Subject: RFR: 8194312: Support parallel and concurrent JNI global handle processing In-Reply-To: <5E6F31A5-E3EA-46C4-B488-9D97C6DB18D3@oracle.com> References: <48A47626-1FB7-4215-8A8C-B66E8D01FB70@oracle.com> <5A561A0C.90803@oracle.com> <4D611A04-F9AB-4681-80DC-DAA53D1EE3A9@oracle.com> <64b74847-c0bc-713d-cf12-4083aa6ca5a8@oracle.com> <5E6F31A5-E3EA-46C4-B488-9D97C6DB18D3@oracle.com> Message-ID: > On Jan 11, 2018, at 7:56 PM, Kim Barrett wrote: > One reason for iteration templates is to support const iteration. > [?] > > Another reason for iteration templates is to be forward-looking to > C++11, where it becomes easy to pass in an instance of a local type, > or a lambda, or a bind expression, all of which are ways to make > used-in-one-place function objects conveniently at the point of use. > This can often make the code much easier to understand than having to > go somewhere else to find out what do_oop for *this* closure does. > > With a little work we could always use oops_do for iteration (and make > iterate/iterate_safepoint private). There would be two versions of > oops_do, one using cl->do_oop(p), the other cl(p), selected via a > little metaprogramming (in C++11, I don't remember how hard it is in > C++03, or if it's even possible.) Hm, maybe this is easier than I was thinking it might be. The difficulty I was remembering seems to be a somewhat different case, and a simple solution seems obvious now, except it?s kind of late, so maybe I?m tired and missing something. I?ll look at it tomorrow. From goetz.lindenmaier at sap.com Fri Jan 12 11:35:32 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 12 Jan 2018 11:35:32 +0000 Subject: RFR : PPC64 : Need support for VSR spills in ppc.ad In-Reply-To: References: <409187f381384294a5f5c1a38b66a840@sap.com>, <5f8786f3d20649d697b99f4d663cd110@sap.com> Message-ID: <183dc8d4630d4bc7930fd17b757c054d@sap.com> Hi Michihiro, I had a look at your change. Thanks for fixing this. In the MachSpillNode::implementation() implementation, why is there no case Reg->Reg? For other register sets, this is the MachSpillNode used the most. In case this is pushed to jdk10, I would appreciate to leave the flag off. (I.e., push without the change to vm_version_ppc.cpp.) Usage of this is probably quite rare, so that uncommon effects e.g. when spilling to the stack are unlikely to be catched by the remaining testing before delivery. Please adapt the comment above enum RC {...} Besides this, the change looks good! Best regards, Goetz. > -----Original Message----- > From: Michihiro Horie [mailto:HORIE at jp.ibm.com] > Sent: Donnerstag, 11. Januar 2018 05:01 > To: Doerr, Martin > Cc: Lindenmaier, Goetz ; > gromero at linux.vnet.ibm.com; hotspot-dev at openjdk.java.net; ppc-aix- > port-dev at openjdk.java.net > Subject: RE: RFR : PPC64 : Need support for VSR spills in ppc.ad > > Hi Martin, > > >Not to be used by MachConstantBaseNode. > Thank you for the confirmation. > > >I still suggest to add "iRegLdst tmp" with "effect(TEMP tmp)" to > repl4F_immF_Ex. > Sure, I updated code with a tmp register instead of R19: > http://cr.openjdk.java.net/~mhorie/8194861/webrev.02/ > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > "Doerr, Martin" ---2018/01/11 02:19:30---Hi Michihiro, > R19 is commented > out in bits64_constant_table_base so as not to be used: > > From: "Doerr, Martin" > To: Michihiro Horie > Cc: "Lindenmaier, Goetz" , > "gromero at linux.vnet.ibm.com" , "hotspot- > dev at openjdk.java.net" , "ppc-aix-port- > dev at openjdk.java.net" > Date: 2018/01/11 02:19 > Subject: RE: RFR : PPC64 : Need support for VSR spills in ppc.ad > > ________________________________ > > > > > Hi Michihiro, > > > R19 is commented out in bits64_constant_table_base so as not to be used: > Not to be used by MachConstantBaseNode. I don't see how this should help. > > I still suggest to add "iRegLdst tmp" with "effect(TEMP tmp)" to > repl4F_immF_Ex. > > Best regards, > Martin > > > From: Michihiro Horie [mailto:HORIE at jp.ibm.com] > Sent: Mittwoch, 10. Januar 2018 16:29 > To: Doerr, Martin > Cc: Lindenmaier, Goetz ; > gromero at linux.vnet.ibm.com; hotspot-dev at openjdk.java.net; ppc-aix- > port-dev at openjdk.java.net > Subject: RE: RFR : PPC64 : Need support for VSR spills in ppc.ad > > Hi Martin, > > Thanks a lot for your review. > > >I wonder how the content of R19 should get preserved. > R19 is commented out in bits64_constant_table_base so as not to be used: > reg_class bits64_constant_table_base( > : > R18_H, R18, > /*R19_H, R19*/ > R20_H, R20, > : > ); > > Although bits64_constant_table_base is not directly referred from > anywhere, it seems to be used at the following line in ppc.ad: > const RegMask& MachConstantBaseNode::_out_RegMask = > BITS64_CONSTANT_TABLE_BASE_mask(); > (When I remove the declaration of bits64_constant_table_base, a build error > arises at this line telling the lack of the declaration.) > > >Shouldn't repl4F_immF_Ex use a temp register instead of R19? > Thank you for the suggestion, which makes sense very much. I think I can > declare temp registers in repl4F_immF_Ex. > I will try this approach if using R19 does not make sense. > > I changed vm_version_ppc.cpp: > webrev: http://cr.openjdk.java.net/~mhorie/8194861/webrev.01/ > 3A__cr.openjdk.java.net_- > 7Emhorie_8194861_webrev.01_&d=DwMGaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=oecsIpYF- > cifqq2i1JEH0Q&m=SOGOvG8yFchCvPeC1Pr5_BJNIaBdg1G1IXaEeMgwpWI&s > =kFfDKuiMdVnWKBy0FOjXCTzN430PRKsHQgSCRWkdR8w&e=> > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > > ----- Original message ----- > From: "Doerr, Martin" > > To: Michihiro Horie > > Cc: "ppc-aix-port-dev at openjdk.java.net dev at openjdk.java.net> " aix-port-dev at openjdk.java.net> >, "hotspot-dev at openjdk.java.net > " >, Gustavo Romero > >, > "Lindenmaier, Goetz" > > Subject: RE: RFR : PPC64 : Need support for VSR spills in ppc.ad > Date: Wed, Jan 10, 2018 8:17 PM > > > Hi Michihiro, > > thanks for implementing it. > > I wonder how the content of R19 should get preserved. > > Shouldn't repl4F_immF_Ex use a temp register instead of R19? > > SuperwordUseVSX is still not activated in vm_version_ppc.cpp. I think we > should turn it on with this change (see the TODO). > > We will run tests when the R19 question is clarified. > > Best regards, > > Martin > > From: Michihiro Horie [mailto:HORIE at jp.ibm.com > ] > Sent: Mittwoch, 10. Januar 2018 07:10 > To: Doerr, Martin > > > 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> ; Gustavo Romero > > Subject: RFR : PPC64 : Need support for VSR spills in ppc.ad > > Hi Martin, > > Would you review the following change that fixes the SLP for PPC? > > In this change, I added support for VSR spills. Also, I fixed how to specify > registers in postalloc_expand for the float constant replication. I confirmed > this change works with JTREG. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8194861 > 3A__bugs.openjdk.java.net_browse_JDK- > 2D8194861&d=DwMFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF- > cifqq2i1JEH0Q&m=6pCaUQ4ll6S-hRCrDXsSKjl9NrczviVl3vOv0- > KnizA&s=HtvmfHT8WviFbLWwFAnJ1KOrzvPiwqleI_inLbbJqTE&e=> > webrev: http://cr.openjdk.java.net/~mhorie/8194861/webrev.00 > 3A__cr.openjdk.java.net_- > 7Emhorie_8194861_webrev.00&d=DwMGaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=oecsIpYF- > cifqq2i1JEH0Q&m=SOGOvG8yFchCvPeC1Pr5_BJNIaBdg1G1IXaEeMgwpWI&s > =RceHIxj8obNFdZExh6_lDeUnogfNv-qGZWuh_RRuHRQ&e=> / > (I created a webrev under jdk/hs.) > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > > From bob.vandette at oracle.com Fri Jan 12 13:59:16 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 12 Jan 2018 08:59:16 -0500 Subject: RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers In-Reply-To: References: <39C5B4B1-6EEF-4E07-90BA-5EC77B83195B@oracle.com> Message-ID: <9FEEDEC9-2BF5-4CEC-A6D4-E11273573204@oracle.com> > On Jan 11, 2018, at 9:44 PM, David Holmes wrote: > > Hi Bob, > > Some initial discussion and commentary. I'm a bit concerned by how much accommodating docker penalises code that is not using containers. True but querying the number of Java processes is at least not in a performance critical area. > > On 12/01/2018 4:41 AM, Bob Vandette wrote: >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8193710 >> Webrev: >> http://cr.openjdk.java.net/~bobv/8193710/webrev.00/ >> Summary: >> This changeset enables the ability to use jcmd and jps running on a Host to >> list the java processes that are running in docker (cgroup based) containers. > > Can you clarify this for me please. I assume we are still only listing processes for the current user - correct? No, it will report any Java processes that the current user has permission to see (hsperfdata* files are readable). If you run as root, you see all processes. > So the issue is if I am running mutiple JVMs and also running a Docker process that itself contains JVMs then jps outside of Docker won't show the JVMs that are inside Docker. Yes, this is what is being fixed. > And presumably the opposite is also true? > Yes, this is also true but is not being fixed by this change. I am only fixing the case where you run jps on a host and want to see all java processes running (in and out of containers). > If we change jps to find all JVMs on the host for the current user, whether in a container or not (and whether jps is run from in a container or not?) are the process id's that get returned directly useable from where jps was run? Given the above constraints, yes. The results jps can passed to jcmd to query things like VM.version > >> I?ve tested this change by examining processes running as root on both host and in >> docker containers as well as under my userid using ?jps and jcmd -l?. >> I?ve also tested the getFile functions with a small example program that I wrote. >> From what I can tell, these two getFile functions are not used in the JDK sources >> and in fact the PerfDataFile.getFile(int lvmid) method doesn?t appear to have never worked! >> I?d really like to remove these two methods. > > If they are not used by anything then by all means drop them. I saw some Javadocs on the web documenting these methods leading me to believe that we would need to deprecate these even though they are internal APIs. I?ll ask core-libs. http://openjdk.java.net/groups/serviceability/jvmstat/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataFile.html#getFile(int) > >> 140 candidate = new File(f.getName(), name); <> Here are some implementation details that I?ve added added to one of the Unix >> specific source files (src/java.base/unix/classes/jdk/internal/vm/VMSupportImpl.java) > > I have an issue with this. This is not "unix" (ie anything other than windows) support code, it is Linux support code. I'm also unclear why this needs to be lifted out of the PerfMemory subsystem. You are correct, I?ll move this into a linux specific directory. I factored these functions in order to isolate the cgroup specific functionality in an OS specific tree. > > And if you're going to mess with the jdk.internal module then I think core-libs folk will want to know before hand. Will do. > > Other comments ... > > src/hotspot/os/linux/perfMemory_linux.cpp > > I'm concerned about the MAXPATHLEN stack buffers and the extra overhead being added to the normal non-container path. I believe the impacted paths are only used when attaching to the VM and should not impact normal startup. > We've had issues in the past where a newly added stack buffer caused StackOverflowError. We don't need a 4K buffer because os::get_temp_directory() just returns "/tmp" and we're dealing with all Linux code here. I don't like making assumptions like this but ... > > #define TMP_BUFFER_LEN (4 + 21) > static char* get_user_tmp_dir(const char* user, int vmid, int nspid) { > char buffer[TMP_BUFFER_LEN]; > char* tmpdir = os::get_temp_directory(); > assert(strlen(tmpdir) == 4, "No longer using /tmp - update buffer size"); > if (nspid != -1) { > jio_snprintf(buffer, TMP_BUFFER_LEN, "/proc/%d/root%s", vmid, tmpdir); > tmpdir = buffer; > } > ... > > > 657 char fname[64]; > > Maximum length of "/proc/%d/status" is 23. Ok, I?ll reduce the buffer sizes I use. Thanks, Bob. > > Thanks, > David From stuart.monteith at linaro.org Fri Jan 12 14:25:09 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Fri, 12 Jan 2018 14:25:09 +0000 Subject: [aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV In-Reply-To: <30064ec2-224f-174a-8eb2-670123edf2e3@oracle.com> References: <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com> <20e812bc-d132-9863-815b-345283f9517e@redhat.com> <3c83440f-dd4b-f988-1f96-afa88dff36eb@redhat.com> <30064ec2-224f-174a-8eb2-670123edf2e3@oracle.com> Message-ID: Thanks Coleen, So once somebody here manages to review it, I can commit the patch. I might have this backwards, but should the patch target jdk/jdk or jdk/jdk10? Thanks again, Stuart On 11 January 2018 at 12:29, wrote: > > This looks good to me. I will sponsor this fix, once we confirm the > reviewers and you commit the patch and rerun the webrev (so it's in > jdk10.patch). I see this is for jdk10. > > thanks, > Coleen > > > On 1/5/18 1:43 PM, Stuart Monteith wrote: >> >> I've removed the AARCH64 conditionals, added the empty line I removed, >> and changed the type of "use_XOR_for_compressed_class_base" to bool. >> >> http://cr.openjdk.java.net/~smonteith/8193266/webrev-5/ >> >> BR, >> Stuart >> >> >> On 4 January 2018 at 14:45, Andrew Haley wrote: >>> >>> Hi, >>> >>> On 04/01/18 14:26, coleen.phillimore at oracle.com wrote: >>>> >>>> I was going to offer to sponsor this since it touches shared code but >>>> I'm not sure I like that there's AARCH64 specific code in >>>> universe.cpp/hpp. And the name is somewhat offputting, suggesting >>>> implementation details of one target leaking into shared code. >>>> >>>> set_use_XOR_for_compressed_class_base >>>> >>>> I think webrev-3 looked more reasonable, and could elide the #ifdef >>>> AARCH64 in the shared code for that version. And the indentation is >>>> better. >>> >>> I hate the #ifdef AARCH64 stuff too, but it's always a sign that there >>> is something wrong with the front-end to back-end modularization. We >>> can handle the use_XOR_for_compressed_class_base later: we really >>> should have a way to communicate with the back ends when the memory >>> layout is initialized. We can go with webrev-3. >>> >>> -- >>> Andrew Haley >>> Java Platform Lead Engineer >>> Red Hat UK Ltd. >>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > From bob.vandette at oracle.com Fri Jan 12 15:02:28 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 12 Jan 2018 10:02:28 -0500 Subject: RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers In-Reply-To: <9FEEDEC9-2BF5-4CEC-A6D4-E11273573204@oracle.com> References: <39C5B4B1-6EEF-4E07-90BA-5EC77B83195B@oracle.com> <9FEEDEC9-2BF5-4CEC-A6D4-E11273573204@oracle.com> Message-ID: <88DDE9EA-91B7-4249-B45B-27C8D550DD8C@oracle.com> Looping in core-libs. The following fix alters the module-info for java.base. Can someone from the core-libs comment on these changes? I?d also like to remove the two PerfDataFile.getFile methods? Since these are in jdk.internal.jvmstat, can I just pull them or do they need to go through deprecation/CSR? Thanks, Bob. > On Jan 12, 2018, at 8:59 AM, Bob Vandette wrote: > > > >> On Jan 11, 2018, at 9:44 PM, David Holmes wrote: >> >> Hi Bob, >> >> Some initial discussion and commentary. I'm a bit concerned by how much accommodating docker penalises code that is not using containers. > > True but querying the number of Java processes is at least not in a performance critical area. > >> >> On 12/01/2018 4:41 AM, Bob Vandette wrote: >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8193710 >>> Webrev: >>> http://cr.openjdk.java.net/~bobv/8193710/webrev.00/ >>> Summary: >>> This changeset enables the ability to use jcmd and jps running on a Host to >>> list the java processes that are running in docker (cgroup based) containers. >> >> Can you clarify this for me please. I assume we are still only listing processes for the current user - correct? > > No, it will report any Java processes that the current user has permission to see (hsperfdata* files are readable). > If you run as root, you see all processes. > >> So the issue is if I am running mutiple JVMs and also running a Docker process that itself contains JVMs then jps outside of Docker won't show the JVMs that are inside Docker. > > Yes, this is what is being fixed. > >> And presumably the opposite is also true? >> > > Yes, this is also true but is not being fixed by this change. I am only fixing the case where you run jps on a host and > want to see all java processes running (in and out of containers). > > >> If we change jps to find all JVMs on the host for the current user, whether in a container or not (and whether jps is run from in a container or not?) are the process id's that get returned directly useable from where jps was run? > > Given the above constraints, yes. > > The results jps can passed to jcmd to query things like VM.version > >> >>> I?ve tested this change by examining processes running as root on both host and in >>> docker containers as well as under my userid using ?jps and jcmd -l?. >>> I?ve also tested the getFile functions with a small example program that I wrote. >>> From what I can tell, these two getFile functions are not used in the JDK sources >>> and in fact the PerfDataFile.getFile(int lvmid) method doesn?t appear to have never worked! >>> I?d really like to remove these two methods. >> >> If they are not used by anything then by all means drop them. > I saw some Javadocs on the web documenting these methods leading me to believe that we would need > to deprecate these even though they are internal APIs. I?ll ask core-libs. > > http://openjdk.java.net/groups/serviceability/jvmstat/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataFile.html#getFile(int) > >> >>> 140 candidate = new File(f.getName(), name); <>> Here are some implementation details that I?ve added added to one of the Unix >>> specific source files (src/java.base/unix/classes/jdk/internal/vm/VMSupportImpl.java) >> >> I have an issue with this. This is not "unix" (ie anything other than windows) support code, it is Linux support code. I'm also unclear why this needs to be lifted out of the PerfMemory subsystem. > You are correct, I?ll move this into a linux specific directory. I factored these functions in order to isolate the cgroup specific functionality > in an OS specific tree. > >> >> And if you're going to mess with the jdk.internal module then I think core-libs folk will want to know before hand. > > Will do. > >> >> Other comments ... >> >> src/hotspot/os/linux/perfMemory_linux.cpp >> >> I'm concerned about the MAXPATHLEN stack buffers and the extra overhead being added to the normal non-container path. > > I believe the impacted paths are only used when attaching to the VM and should not impact normal startup. > >> We've had issues in the past where a newly added stack buffer caused StackOverflowError. We don't need a 4K buffer because os::get_temp_directory() just returns "/tmp" and we're dealing with all Linux code here. I don't like making assumptions like this but ... >> >> #define TMP_BUFFER_LEN (4 + 21) >> static char* get_user_tmp_dir(const char* user, int vmid, int nspid) { >> char buffer[TMP_BUFFER_LEN]; >> char* tmpdir = os::get_temp_directory(); >> assert(strlen(tmpdir) == 4, "No longer using /tmp - update buffer size"); >> if (nspid != -1) { >> jio_snprintf(buffer, TMP_BUFFER_LEN, "/proc/%d/root%s", vmid, tmpdir); >> tmpdir = buffer; >> } >> ... >> >> >> 657 char fname[64]; >> >> Maximum length of "/proc/%d/status" is 23. > > Ok, I?ll reduce the buffer sizes I use. > > Thanks, > Bob. > > >> >> Thanks, >> David > From jesper.wilhelmsson at oracle.com Fri Jan 12 15:13:59 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Fri, 12 Jan 2018 16:13:59 +0100 Subject: [aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV In-Reply-To: References: <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com> <20e812bc-d132-9863-815b-345283f9517e@redhat.com> <3c83440f-dd4b-f988-1f96-afa88dff36eb@redhat.com> <30064ec2-224f-174a-8eb2-670123edf2e3@oracle.com> Message-ID: <27F30ADE-7E63-4CFF-8443-39BEB0E7341A@oracle.com> > On 12 Jan 2018, at 15:25, Stuart Monteith wrote: > > Thanks Coleen, > So once somebody here manages to review it, I can commit the patch. > I might have this backwards, but should the patch target jdk/jdk or > jdk/jdk10? If it's for JDK 10 it should be pushed to jdk/jdk10 /Jesper > > Thanks again, > Stuart > > > On 11 January 2018 at 12:29, wrote: >> >> This looks good to me. I will sponsor this fix, once we confirm the >> reviewers and you commit the patch and rerun the webrev (so it's in >> jdk10.patch). I see this is for jdk10. >> >> thanks, >> Coleen >> >> >> On 1/5/18 1:43 PM, Stuart Monteith wrote: >>> >>> I've removed the AARCH64 conditionals, added the empty line I removed, >>> and changed the type of "use_XOR_for_compressed_class_base" to bool. >>> >>> http://cr.openjdk.java.net/~smonteith/8193266/webrev-5/ >>> >>> BR, >>> Stuart >>> >>> >>> On 4 January 2018 at 14:45, Andrew Haley wrote: >>>> >>>> Hi, >>>> >>>> On 04/01/18 14:26, coleen.phillimore at oracle.com wrote: >>>>> >>>>> I was going to offer to sponsor this since it touches shared code but >>>>> I'm not sure I like that there's AARCH64 specific code in >>>>> universe.cpp/hpp. And the name is somewhat offputting, suggesting >>>>> implementation details of one target leaking into shared code. >>>>> >>>>> set_use_XOR_for_compressed_class_base >>>>> >>>>> I think webrev-3 looked more reasonable, and could elide the #ifdef >>>>> AARCH64 in the shared code for that version. And the indentation is >>>>> better. >>>> >>>> I hate the #ifdef AARCH64 stuff too, but it's always a sign that there >>>> is something wrong with the front-end to back-end modularization. We >>>> can handle the use_XOR_for_compressed_class_base later: we really >>>> should have a way to communicate with the back ends when the memory >>>> layout is initialized. We can go with webrev-3. >>>> >>>> -- >>>> Andrew Haley >>>> Java Platform Lead Engineer >>>> Red Hat UK Ltd. >>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >> >> From andrew_m_leonard at uk.ibm.com Fri Jan 12 09:03:17 2018 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Fri, 12 Jan 2018 09:03:17 +0000 Subject: JVM interface header src location? In-Reply-To: <772a0b04-40a7-4c1a-ebf1-bedfd29bea21@oracle.com> References: <772a0b04-40a7-4c1a-ebf1-bedfd29bea21@oracle.com> Message-ID: Thanks for the feedback David. I agree with your point, and understand JVM implementors are really just hotspot imitators(!) :-) It would be as a convenience to 3rd party JVM implementors, and ease the job of extracting just those necessary files... Cheers Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: David Holmes To: Andrew Leonard , hotspot-dev at openjdk.java.net Date: 11/01/2018 22:01 Subject: Re: JVM interface header src location? Hi Andrew, On 12/01/2018 1:34 AM, Andrew Leonard wrote: > Hi, with the new repo consolidation in JDK10+ the JVM interface headers > (jvm.h and jvm_md.h) have moved from under > jdk/src/java.base/share|/native/include/ to > src/hotspot/share/include/jvm.h > src/hotspot/os/windows/include/jvm_md.h > src/hotspot/os/posix/include/jvm_md.h > This implies these are "hotspot" headers, when they are actually generic I wouldn't call them generic. They define the API that hotspot provides for use by the JDK. The JDK in turn is written to use whatever hotspot exports. Now we can treat that as a de-facto generic definition of what any VM that works with the JDK needs to provide, but it would be wrong to pretend/assume that this is somehow some nice clean abstract interface between the JDK and any VM. In short any VM you want to plug into the JDK has to impersonate hotspot from this API perspective. > JVM interface definitions. So for example if previously a 3rd party JVM > implementor (eg.Eclipse OpenJ9) who does not clone the hotspot repo, and > now does not clone the hotspot "folder", will now fail to find these > generic headers... Right ... it would have been good to have gotten some feedback on this when we did the file consolidation work: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8189610&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=cmDyJIWgzK0nr0h1WHwc0TKtWEAPcz8g_pN-h1eSKEQ&s=VgwZL88Bpwz77SYajN1T2qt0yfLDzC0WRgTczBJtzSw&e= and then relocation: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8190484&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=cmDyJIWgzK0nr0h1WHwc0TKtWEAPcz8g_pN-h1eSKEQ&s=fED9Yhb2hFGVHbWqOIrtjZsOSvhU7FDmv_SwI5ay3nM&e= > Wouldn't it be better for these headers to be under some generic "jvm" or > "base" include folder? It would solve your problem. :) And I'm not opposed to moving them as a convenience to you. My main concern would be that this is not seen as a supported, exported, external contract between the JDK libraries and any VM. I would still consider it a private interface between the JDK and hotspot that changes whenever hotspot (or the JDK) needs it to. Cheers, David > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From andrew_m_leonard at uk.ibm.com Fri Jan 12 09:10:56 2018 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Fri, 12 Jan 2018 09:10:56 +0000 Subject: JVM interface header src location? In-Reply-To: References: <772a0b04-40a7-4c1a-ebf1-bedfd29bea21@oracle.com> Message-ID: Eclipse OpenJ9 for example imitates the jvm.h interface without any change to it, so in essence they treat it as a defined "interface", but as you say it's really not a "supported" one, so I can understand both sides... Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: mandy chung To: David Holmes , Andrew Leonard Cc: hotspot-dev at openjdk.java.net Date: 11/01/2018 23:27 Subject: Re: JVM interface header src location? On 1/11/18 2:01 PM, David Holmes wrote: Wouldn't it be better for these headers to be under some generic "jvm" or "base" include folder? It would solve your problem. :) And I'm not opposed to moving them as a convenience to you. My main concern would be that this is not seen as a supported, exported, external contract between the JDK libraries and any VM. I would still consider it a private interface between the JDK and hotspot that changes whenever hotspot (or the JDK) needs it to. Right. It's internal interface between JDK and hotspot. src/java.base/share/include wasn't the desired location for it and hence the relocation. Would it be an alternative if the source location of these header files can be configured at build time so that other JVM implementor can build JDK with an alternate location? I would expect that other VM implementation would have to do some work for any change to jvm.h regardless of where it's located. The extra (hopefully minimal) work is to update its own copy of jvm.h. Mandy Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Alan.Bateman at oracle.com Fri Jan 12 19:00:07 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 12 Jan 2018 19:00:07 +0000 Subject: JVM interface header src location? In-Reply-To: References: <772a0b04-40a7-4c1a-ebf1-bedfd29bea21@oracle.com> Message-ID: <1c4135a8-3a8a-5c1f-2884-abda801cc445@oracle.com> On 12/01/2018 09:10, Andrew Leonard wrote: > Eclipse OpenJ9 for example imitates the jvm.h interface without any change > to it, so in essence they treat it as a defined "interface", but as you > say it's really not a "supported" one, so I can understand both sides... > Does OpenJ9 implement the JDK-internal JMM interface (jmm.h) too? -Alan From david.holmes at oracle.com Fri Jan 12 23:57:27 2018 From: david.holmes at oracle.com (David Holmes) Date: Sat, 13 Jan 2018 09:57:27 +1000 Subject: JVM interface header src location? In-Reply-To: References: <772a0b04-40a7-4c1a-ebf1-bedfd29bea21@oracle.com> Message-ID: <7dbc6eb3-3ad6-f397-abe5-c19f3ad639eb@oracle.com> On 12/01/2018 7:03 PM, Andrew Leonard wrote: > Thanks for the feedback David. I agree with your point, and understand > JVM implementors are really just hotspot imitators(!) :-) > It would be as a convenience to 3rd party JVM implementors, and ease the > job of extracting just those necessary files... After some further internal discussions it was decided that as jvm*.h is really the exported hotspot interface (as previously discussed when the files were combined and relocated) that it belongs in the hotspot src directory. David ----- > Cheers > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: David Holmes > To: Andrew Leonard , > hotspot-dev at openjdk.java.net > Date: 11/01/2018 22:01 > Subject: Re: JVM interface header src location? > ------------------------------------------------------------------------ > > > > Hi Andrew, > > On 12/01/2018 1:34 AM, Andrew Leonard wrote: > > Hi, with the new repo consolidation in JDK10+ the JVM interface headers > > (jvm.h and jvm_md.h) have moved from under > > jdk/src/java.base/share|/native/include/ to > > ? ? ?src/hotspot/share/include/jvm.h > > ? ? ?src/hotspot/os/windows/include/jvm_md.h > > ? ? ?src/hotspot/os/posix/include/jvm_md.h > > This implies these are "hotspot" headers, when they are actually generic > > I wouldn't call them generic. They define the API that hotspot provides > for use by the JDK. The JDK in turn is written to use whatever hotspot > exports. Now we can treat that as a de-facto generic definition of what > any VM that works with the JDK needs to provide, but it would be wrong > to pretend/assume that this is somehow some nice clean abstract > interface between the JDK and any VM. > > In short any VM you want to plug into the JDK has to impersonate hotspot > from this API perspective. > > > JVM interface definitions. So for example if previously a 3rd party JVM > > implementor (eg.Eclipse OpenJ9) who does not clone the hotspot repo, and > > now does not clone the hotspot "folder", will now fail to find these > > generic headers... > > Right ... it would have been good to have gotten some feedback on this > when we did the file consolidation work: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8189610&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=cmDyJIWgzK0nr0h1WHwc0TKtWEAPcz8g_pN-h1eSKEQ&s=VgwZL88Bpwz77SYajN1T2qt0yfLDzC0WRgTczBJtzSw&e= > > and then relocation: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8190484&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=cmDyJIWgzK0nr0h1WHwc0TKtWEAPcz8g_pN-h1eSKEQ&s=fED9Yhb2hFGVHbWqOIrtjZsOSvhU7FDmv_SwI5ay3nM&e= > > > Wouldn't it be better for these headers to be under some generic "jvm" or > > "base" include folder? > > It would solve your problem. :) And I'm not opposed to moving them as a > convenience to you. My main concern would be that this is not seen as a > supported, exported, external contract between the JDK libraries and any > VM. I would still consider it a private interface between the JDK and > hotspot that changes whenever hotspot (or the JDK) needs it to. > > Cheers, > David > > > Thanks > > Andrew > > > > Andrew Leonard > > Java Runtimes Development > > IBM Hursley > > IBM United Kingdom Ltd > > Phone internal: 245913, external: 01962 815913 > > internet email: andrew_m_leonard at uk.ibm.com > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From kim.barrett at oracle.com Mon Jan 15 05:56:15 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 15 Jan 2018 00:56:15 -0500 Subject: RFR: 8194312: Support parallel and concurrent JNI global handle processing In-Reply-To: References: <48A47626-1FB7-4215-8A8C-B66E8D01FB70@oracle.com> <5A561A0C.90803@oracle.com> <4D611A04-F9AB-4681-80DC-DAA53D1EE3A9@oracle.com> <64b74847-c0bc-713d-cf12-4083aa6ca5a8@oracle.com> <5E6F31A5-E3EA-46C4-B488-9D97C6DB18D3@oracle.com> Message-ID: > On Jan 12, 2018, at 3:53 AM, Kim Barrett wrote: > >> On Jan 11, 2018, at 7:56 PM, Kim Barrett wrote: >> One reason for iteration templates is to support const iteration. >> [?] >> >> Another reason for iteration templates is to be forward-looking to >> C++11, where it becomes easy to pass in an instance of a local type, >> or a lambda, or a bind expression, all of which are ways to make >> used-in-one-place function objects conveniently at the point of use. >> This can often make the code much easier to understand than having to >> go somewhere else to find out what do_oop for *this* closure does. >> >> With a little work we could always use oops_do for iteration (and make >> iterate/iterate_safepoint private). There would be two versions of >> oops_do, one using cl->do_oop(p), the other cl(p), selected via a >> little metaprogramming (in C++11, I don't remember how hard it is in >> C++03, or if it's even possible.) > > Hm, maybe this is easier than I was thinking it might be. The difficulty > I was remembering seems to be a somewhat different case, and a simple > solution seems obvious now, except it?s kind of late, so maybe I?m tired > and missing something. > > I?ll look at it tomorrow. Never mind, I?m not seeing a way to do that selection easily with C++03. And the reasons for considering doing it don?t really exist until C++11. So I?m wanting to leave it as is. From erik.osterlund at oracle.com Mon Jan 15 07:31:19 2018 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Mon, 15 Jan 2018 08:31:19 +0100 Subject: RFR: 8194312: Support parallel and concurrent JNI global handle processing In-Reply-To: References: <48A47626-1FB7-4215-8A8C-B66E8D01FB70@oracle.com> <5A561A0C.90803@oracle.com> <4D611A04-F9AB-4681-80DC-DAA53D1EE3A9@oracle.com> <64b74847-c0bc-713d-cf12-4083aa6ca5a8@oracle.com> <5E6F31A5-E3EA-46C4-B488-9D97C6DB18D3@oracle.com> Message-ID: <1F9A95F5-D5C3-4D6A-AB92-EEDA16CA20A1@oracle.com> Hi Kim, On 15 Jan 2018, at 06:56, Kim Barrett wrote: >> On Jan 12, 2018, at 3:53 AM, Kim Barrett wrote: >> >>> On Jan 11, 2018, at 7:56 PM, Kim Barrett wrote: >>> One reason for iteration templates is to support const iteration. >>> [?] >>> >>> Another reason for iteration templates is to be forward-looking to >>> C++11, where it becomes easy to pass in an instance of a local type, >>> or a lambda, or a bind expression, all of which are ways to make >>> used-in-one-place function objects conveniently at the point of use. >>> This can often make the code much easier to understand than having to >>> go somewhere else to find out what do_oop for *this* closure does. >>> >>> With a little work we could always use oops_do for iteration (and make >>> iterate/iterate_safepoint private). There would be two versions of >>> oops_do, one using cl->do_oop(p), the other cl(p), selected via a >>> little metaprogramming (in C++11, I don't remember how hard it is in >>> C++03, or if it's even possible.) >> >> Hm, maybe this is easier than I was thinking it might be. The difficulty >> I was remembering seems to be a somewhat different case, and a simple >> solution seems obvious now, except it?s kind of late, so maybe I?m tired >> and missing something. >> >> I?ll look at it tomorrow. > > Never mind, I?m not seeing a way to do that selection easily with C++03. > And the reasons for considering doing it don?t really exist until C++11. > So I?m wanting to leave it as is. Okay. Let?s revisit that in the future instead then. Ship it! Thanks, /Erik From kim.barrett at oracle.com Mon Jan 15 22:18:54 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 15 Jan 2018 17:18:54 -0500 Subject: RFR: 8194312: Support parallel and concurrent JNI global handle processing In-Reply-To: <1F9A95F5-D5C3-4D6A-AB92-EEDA16CA20A1@oracle.com> References: <48A47626-1FB7-4215-8A8C-B66E8D01FB70@oracle.com> <5A561A0C.90803@oracle.com> <4D611A04-F9AB-4681-80DC-DAA53D1EE3A9@oracle.com> <64b74847-c0bc-713d-cf12-4083aa6ca5a8@oracle.com> <5E6F31A5-E3EA-46C4-B488-9D97C6DB18D3@oracle.com> <1F9A95F5-D5C3-4D6A-AB92-EEDA16CA20A1@oracle.com> Message-ID: <4D6A6B21-740D-4F6B-9A71-67345C3E289D@oracle.com> > On Jan 15, 2018, at 2:31 AM, Erik Osterlund wrote: > > Hi Kim, > > On 15 Jan 2018, at 06:56, Kim Barrett wrote: >> >> Never mind, I?m not seeing a way to do that selection easily with C++03. >> And the reasons for considering doing it don?t really exist until C++11. >> So I?m wanting to leave it as is. > > Okay. Let?s revisit that in the future instead then. Ship it! > > Thanks, > /Erik Thanks. From vladimir.kozlov at oracle.com Tue Jan 16 17:16:10 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 16 Jan 2018 09:16:10 -0800 Subject: RFR 8192004: InspectedFrame.materializeVirtualObjects only updates locals with new objects In-Reply-To: References: <5A3BE1E2.6030105@oracle.com> <5A3D581B.8080601@oracle.com> Message-ID: <4752003c-b879-f0a0-f863-fad713ab6004@oracle.com> No response from JVMTI so I looked again through it. It seems fine to me. Reviewed. Thanks, Vladimir On 12/22/17 12:14 PM, Vladimir Kozlov wrote: > Posting to hotspot-dev alias since our group does not have JVMTI experts. > I looked and it seems fine but someone from serviceability should look too. > > Thanks, > Vladimir > > On 12/22/17 11:08 AM, Tom Rodriguez wrote: >> Could I get some reviews?? This doesn't change the way the logic >> behaves for the core use of JVMTI.? It just extends the encoding so >> that numbers after the locals are interpreted as expression stack and >> monitor values. ??I believe there are existing tests of the JVMTI set >> locals part and JVMCI is the only only consumer of the monitor and >> expression stack part. >> >> tom >> >> Tom Rodriguez wrote: >>> JVMCI adds the ability to introspect on deoptimized frames which >>> requires early materialization of escape analyzed objects. The >>> jvmtiDeferredLocalVariableSet machinery is reused to capture the local >>> updates required for this. The existing code only updates locals, >>> leaving the stack and monitor information with out of date values. This >>> can lead to deadlocks and incorrect execution. The fix is to slightly >>> generalize jvmtiDeferredLocalVariableSet to handle expression stack and >>> monitor slots. Tested with new graal regression test >>> https://github.com/graalvm/graal/blob/7fd37bde8955780a57049964d87a51aa2407d86b/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotStackIntrospectionTest.java >>> >>> and previously failing Truffle use cases. I assume the new test case >>> will come across with a normal graal update. The clean mach5 run is in >>> the bug report. >>> >>> http://cr.openjdk.java.net/~never/8192004/webrev >>> https://bugs.openjdk.java.net/browse/JDK-8192004 > From andrew_m_leonard at uk.ibm.com Mon Jan 15 11:33:01 2018 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 15 Jan 2018 11:33:01 +0000 Subject: JVM interface header src location? In-Reply-To: <1c4135a8-3a8a-5c1f-2884-abda801cc445@oracle.com> References: <772a0b04-40a7-4c1a-ebf1-bedfd29bea21@oracle.com> <1c4135a8-3a8a-5c1f-2884-abda801cc445@oracle.com> Message-ID: Hi Alan, I don't believe OpenJ9 uses jmm.h, it has it's own "management" interface impl. Cheers Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Alan Bateman To: Andrew Leonard , mandy chung Cc: hotspot-dev at openjdk.java.net Date: 12/01/2018 19:00 Subject: Re: JVM interface header src location? On 12/01/2018 09:10, Andrew Leonard wrote: > Eclipse OpenJ9 for example imitates the jvm.h interface without any change > to it, so in essence they treat it as a defined "interface", but as you > say it's really not a "supported" one, so I can understand both sides... > Does OpenJ9 implement the JDK-internal JMM interface (jmm.h) too? -Alan Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From serguei.spitsyn at oracle.com Wed Jan 17 05:49:11 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 16 Jan 2018 21:49:11 -0800 Subject: RFR 8192004: InspectedFrame.materializeVirtualObjects only updates locals with new objects In-Reply-To: <4752003c-b879-f0a0-f863-fad713ab6004@oracle.com> References: <5A3BE1E2.6030105@oracle.com> <5A3D581B.8080601@oracle.com> <4752003c-b879-f0a0-f863-fad713ab6004@oracle.com> Message-ID: <9274a55e-8f58-8201-62e6-846228ea960a@oracle.com> Tom and Vladimir, I'm looking at it. Thanks, Serguei On 1/16/18 09:16, Vladimir Kozlov wrote: > No response from JVMTI so I looked again through it. It seems fine to > me. Reviewed. > > Thanks, > Vladimir > > On 12/22/17 12:14 PM, Vladimir Kozlov wrote: >> Posting to hotspot-dev alias since our group does not have JVMTI >> experts. >> I looked and it seems fine but someone from serviceability should >> look too. >> >> Thanks, >> Vladimir >> >> On 12/22/17 11:08 AM, Tom Rodriguez wrote: >>> Could I get some reviews?? This doesn't change the way the logic >>> behaves for the core use of JVMTI. It just extends the encoding so >>> that numbers after the locals are interpreted as expression stack >>> and monitor values. ??I believe there are existing tests of the >>> JVMTI set locals part and JVMCI is the only only consumer of the >>> monitor and expression stack part. >>> >>> tom >>> >>> Tom Rodriguez wrote: >>>> JVMCI adds the ability to introspect on deoptimized frames which >>>> requires early materialization of escape analyzed objects. The >>>> jvmtiDeferredLocalVariableSet machinery is reused to capture the local >>>> updates required for this. The existing code only updates locals, >>>> leaving the stack and monitor information with out of date values. >>>> This >>>> can lead to deadlocks and incorrect execution. The fix is to slightly >>>> generalize jvmtiDeferredLocalVariableSet to handle expression stack >>>> and >>>> monitor slots. Tested with new graal regression test >>>> https://github.com/graalvm/graal/blob/7fd37bde8955780a57049964d87a51aa2407d86b/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotStackIntrospectionTest.java >>>> >>>> and previously failing Truffle use cases. I assume the new test case >>>> will come across with a normal graal update. The clean mach5 run is in >>>> the bug report. >>>> >>>> http://cr.openjdk.java.net/~never/8192004/webrev >>>> https://bugs.openjdk.java.net/browse/JDK-8192004 >> From volker.simonis at gmail.com Wed Jan 17 08:26:25 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 17 Jan 2018 09:26:25 +0100 Subject: [10] RFR (XXS): 8195153: [test] runtime/6981737/Test6981737.java shouldn't check 'java.vendor' and 'java.vm.vendor' properties Message-ID: Hi, can I please have a review and sponsor for the following trivial test fix: https://bugs.openjdk.java.net/browse/JDK-8195153 http://cr.openjdk.java.net/~simonis/webrevs/2018/8195153/ The test checks that the 'java.vendor' and 'java.vm.vendor' properties are equal to "Oracle Corporation", but that's wrong! Only "java.specification.vendor" and "java.vm.specification.vendor" have to be equal to "Oracle Corporation", the other vendor properties can be customized by the corresponding OpenJDK distributor. Thank you and best regards, Volker From david.holmes at oracle.com Wed Jan 17 10:21:42 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Jan 2018 20:21:42 +1000 Subject: [10] RFR (XXS): 8195153: [test] runtime/6981737/Test6981737.java shouldn't check 'java.vendor' and 'java.vm.vendor' properties In-Reply-To: References: Message-ID: <7a0d2941-7eec-5ced-4444-3c15494d6b08@oracle.com> Hi Volker, I agree. Changes look good. Thanks, David On 17/01/2018 6:26 PM, Volker Simonis wrote: > Hi, > > can I please have a review and sponsor for the following trivial test fix: > > https://bugs.openjdk.java.net/browse/JDK-8195153 > http://cr.openjdk.java.net/~simonis/webrevs/2018/8195153/ > > The test checks that the 'java.vendor' and 'java.vm.vendor' properties > are equal to "Oracle Corporation", but that's wrong! Only > "java.specification.vendor" and "java.vm.specification.vendor" have to > be equal to "Oracle Corporation", the other vendor properties can be > customized by the corresponding OpenJDK distributor. > > Thank you and best regards, > Volker > From erik.osterlund at oracle.com Wed Jan 17 12:54:06 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 17 Jan 2018 13:54:06 +0100 Subject: RFR(L): 8195142: Refactor out card table from CardTableModRefBS to flatten the BarrierSet hierarchy Message-ID: <5A5F476E.6080000@oracle.com> Hi, Today, both Parallel, CMS and Serial share the same code for its card marking barrier. However, they have different requirements how to manage its card tables by the GC. And as the card table itself is embedded as a part of the CardTableModRefBS barrier set, this has led to an unnecessary inheritance hierarchy for CardTableModRefBS, where for example CardTableModRefBSForCTRS and CardTableExtension are CardTableModRefBS subclasses that do not change anything to do with the barriers. To clean up the code, there should really be a separate CardTable hierarchy that contains the differences how to manage the card table from the GC point of view, and simply let CardTableModRefBS have a CardTable. This would allow removing CardTableModRefBSForCTRS and CardTableExtension and their references from shared code (that really have nothing to do with the barriers, despite being barrier sets), and significantly simplify the barrier set code. This patch mechanically performs this refactoring. A new CardTable class has been created with a PSCardTable subclass for Parallel, a CardTableRS for CMS and Serial, and a G1CardTable for G1. All references to card tables and their values have been updated accordingly. This touches a lot of platform specific code, so would be fantastic if port maintainers could have a look that I have not broken anything. There is a slight problem that should be pointed out. There is an unfortunate interaction between Graal and hotspot. Graal needs to know the values of g1 young cards and dirty cards. This is queried in different ways in different versions of the JDK in the ||GraalHotSpotVMConfig.java file. Now these values will move from their barrier set class to their card table class. That means we have at least three cases how to find the correct values. There is one for JDK8, one for JDK9, and now a new one for JDK11. Except, we have not yet bumped the version number to 11 in the repo, and therefore it has to be from JDK10 - 11 for now and updated after incrementing the version number. But that means that it will be temporarily incompatible with JDK10. That is okay for our own copy of Graal, but can not be used by upstream Graal as they are given the choice whether to support the public JDK10 or the JDK11 that does not quite admit to being 11 yet. I chose the solution that works in our repository. I will notify Graal folks of this issue. In the long run, it would be nice if we could have a more solid interface here. However, as an added benefit, this changeset brings about a hundred copyright headers up to date, so others do not have to update them for a while. Bug: https://bugs.openjdk.java.net/browse/JDK-8195142 Webrev: http://cr.openjdk.java.net/~eosterlund/8195142/webrev.00/ Testing: mach5 hs-tier1-5 plus local AoT testing. Thanks, /Erik From volker.simonis at gmail.com Wed Jan 17 16:03:05 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 17 Jan 2018 17:03:05 +0100 Subject: [10] RFR(S): 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag Message-ID: Hi, can I please have a review and sponsor for this change which finally exposes the various "vendor*" properties: java.vendor java.vm.vendor java.vendor.url java.vendor.url.bug as configure arguments: http://cr.openjdk.java.net/~simonis/webrevs/2018/8189761 https://bugs.openjdk.java.net/browse/JDK-8189761 With this change, "java.vendor" and "java.vm.vendor" still default to "Oracle Corporation" which is defined in System.c (for "java.vendor") and in vm_version.cpp (for "java.vm.version") unless the new "--with-vendor-name" option introduced by JDK-8193764 will be used in the configure step. If the "--with-vendor-name" option will be used, its value will now, with this change, also be assigned to both, the "java.vendor" and "java.vm.vendor" properties. I don't think that we need a separate configure option for "java.vm.vendor" because if somebody is building the OpenJDK with a different VM, he will own the source code of that VM anyway and can easily set "java.vm.vendor" in his code. For "java.vendor.url" and "java.vendor.url.bug" I've introduced the two new configure options "--with-vendor-url" and "--with-vendor-bug-url" which should be self explanatory. If they are not set, the old default values will be used. In the case of a VM crash, the HotSpot displays a second, different bug URL which is currently only configured in the arguments.cpp file. I've exposed this URL as well to configure with the new "--with-vendor-vm-bug-url" configure option. Again, if this option will not use, the VM will fall back to the old default value. Notice that this patch also fixes a bug introduced by "8193764: Cannot set COMPANY_NAME when configuring a build" because of which the jtreg test "test/jdk/tools/jlink/ReleaseImplementorTest.java" fails if the testee was configured without "--with-vendor-name". The problem is that the code introduced by 8193764 unconditionally sets COMPANY_NAME to the empty string, if no "--with-vendor-name" option was given. This overrides the default setting of COMPANY_NAME=N/A from $AUTOCONF_DIR/version-numbers. I want to bring this into jdk10 if possible. I need a sponsor because this change requires the regeneration of "generated-configure.sh" (which I've included in the webrev for your convenience only) and because it touches a HotSpot file and external contributors still can't push such changes :( Thank you and best regards, Volker From volker.simonis at gmail.com Wed Jan 17 16:20:10 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 17 Jan 2018 17:20:10 +0100 Subject: [10] RFR (XXS): 8195153: [test] runtime/6981737/Test6981737.java shouldn't check 'java.vendor' and 'java.vm.vendor' properties In-Reply-To: <7a0d2941-7eec-5ced-4444-3c15494d6b08@oracle.com> References: <7a0d2941-7eec-5ced-4444-3c15494d6b08@oracle.com> Message-ID: Hi David, thanks for your review! Regards, Volker On Wed, Jan 17, 2018 at 11:21 AM, David Holmes wrote: > Hi Volker, > > I agree. Changes look good. > > Thanks, > David > > > On 17/01/2018 6:26 PM, Volker Simonis wrote: >> >> Hi, >> >> can I please have a review and sponsor for the following trivial test fix: >> >> https://bugs.openjdk.java.net/browse/JDK-8195153 >> http://cr.openjdk.java.net/~simonis/webrevs/2018/8195153/ >> >> The test checks that the 'java.vendor' and 'java.vm.vendor' properties >> are equal to "Oracle Corporation", but that's wrong! Only >> "java.specification.vendor" and "java.vm.specification.vendor" have to >> be equal to "Oracle Corporation", the other vendor properties can be >> customized by the corresponding OpenJDK distributor. >> >> Thank you and best regards, >> Volker >> > From stewartd.qdt at qualcommdatacenter.com Wed Jan 17 17:41:22 2018 From: stewartd.qdt at qualcommdatacenter.com (stewartd.qdt) Date: Wed, 17 Jan 2018 17:41:22 +0000 Subject: RFR: 8195621: JTReg failure in gc/g1/TestLargePageUseForAuxMemory.java Message-ID: <9db53780099e44d4a60ff8bf4944a657@NASANEXM01E.na.qualcomm.com> Please review this webrev [1] which attempts to fix a test error in gc/g1/TestLargePageUseForAuxMemory when it is run on a machine with 64K pages. See the bug report [2] for further details of why the error occurs. Essentially the test tries to allocate 512 times the huge page size and fails when the huge page size is around ? - 1 GB is size, because there simply isn't enough physical memory in the system. This fix adds a function to WhiteBox to get the physical memory and then uses that to ensure we are not trying to allocate more than the physical amount of memory for our heap. Please let me know if this is a bad approach and I'll be happy to change as required. Thanks, Daniel Stewart [1] - http://cr.openjdk.java.net/~dstewart/8195621/webrev.00/ [2] - https://bugs.openjdk.java.net/browse/JDK-8195621 From erik.joelsson at oracle.com Wed Jan 17 19:16:28 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 17 Jan 2018 11:16:28 -0800 Subject: [10] RFR(S): 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag In-Reply-To: References: Message-ID: <925deb32-a6af-d835-3ea9-d7b09c80e688@oracle.com> Looks good to me. I can sponsor it. /Erik On 2018-01-17 08:03, Volker Simonis wrote: > Hi, > > can I please have a review and sponsor for this change which finally > exposes the various "vendor*" properties: > > java.vendor > java.vm.vendor > java.vendor.url > java.vendor.url.bug > > as configure arguments: > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8189761 > https://bugs.openjdk.java.net/browse/JDK-8189761 > > With this change, "java.vendor" and "java.vm.vendor" still default to > "Oracle Corporation" which is defined in System.c (for "java.vendor") > and in vm_version.cpp (for "java.vm.version") unless the new > "--with-vendor-name" option introduced by JDK-8193764 will be used in > the configure step. > > If the "--with-vendor-name" option will be used, its value will now, > with this change, also be assigned to both, the "java.vendor" and > "java.vm.vendor" properties. I don't think that we need a separate > configure option for "java.vm.vendor" because if somebody is building > the OpenJDK with a different VM, he will own the source code of that > VM anyway and can easily set "java.vm.vendor" in his code. > > For "java.vendor.url" and "java.vendor.url.bug" I've introduced the > two new configure options "--with-vendor-url" and > "--with-vendor-bug-url" which should be self explanatory. If they are > not set, the old default values will be used. > > In the case of a VM crash, the HotSpot displays a second, different > bug URL which is currently only configured in the arguments.cpp file. > I've exposed this URL as well to configure with the new > "--with-vendor-vm-bug-url" configure option. Again, if this option > will not use, the VM will fall back to the old default value. > > Notice that this patch also fixes a bug introduced by "8193764: Cannot > set COMPANY_NAME when configuring a build" because of which the jtreg > test "test/jdk/tools/jlink/ReleaseImplementorTest.java" fails if the > testee was configured without "--with-vendor-name". The problem is > that the code introduced by 8193764 unconditionally sets COMPANY_NAME > to the empty string, if no "--with-vendor-name" option was given. This > overrides the default setting of COMPANY_NAME=N/A from > $AUTOCONF_DIR/version-numbers. > > I want to bring this into jdk10 if possible. > > I need a sponsor because this change requires the regeneration of > "generated-configure.sh" (which I've included in the webrev for your > convenience only) and because it touches a HotSpot file and external > contributors still can't push such changes :( > > Thank you and best regards, > Volker From volker.simonis at gmail.com Wed Jan 17 21:14:13 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 17 Jan 2018 21:14:13 +0000 Subject: [10] RFR(S): 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag In-Reply-To: <925deb32-a6af-d835-3ea9-d7b09c80e688@oracle.com> References: <925deb32-a6af-d835-3ea9-d7b09c80e688@oracle.com> Message-ID: Erik Joelsson schrieb am Mi. 17. Jan. 2018 um 20:16: > Looks good to me. I can sponsor it. Thanks a lot Erik! Regards, Volker > > /Erik > > > On 2018-01-17 08:03, Volker Simonis wrote: > > Hi, > > > > can I please have a review and sponsor for this change which finally > > exposes the various "vendor*" properties: > > > > java.vendor > > java.vm.vendor > > java.vendor.url > > java.vendor.url.bug > > > > as configure arguments: > > > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8189761 > > https://bugs.openjdk.java.net/browse/JDK-8189761 > > > > With this change, "java.vendor" and "java.vm.vendor" still default to > > "Oracle Corporation" which is defined in System.c (for "java.vendor") > > and in vm_version.cpp (for "java.vm.version") unless the new > > "--with-vendor-name" option introduced by JDK-8193764 will be used in > > the configure step. > > > > If the "--with-vendor-name" option will be used, its value will now, > > with this change, also be assigned to both, the "java.vendor" and > > "java.vm.vendor" properties. I don't think that we need a separate > > configure option for "java.vm.vendor" because if somebody is building > > the OpenJDK with a different VM, he will own the source code of that > > VM anyway and can easily set "java.vm.vendor" in his code. > > > > For "java.vendor.url" and "java.vendor.url.bug" I've introduced the > > two new configure options "--with-vendor-url" and > > "--with-vendor-bug-url" which should be self explanatory. If they are > > not set, the old default values will be used. > > > > In the case of a VM crash, the HotSpot displays a second, different > > bug URL which is currently only configured in the arguments.cpp file. > > I've exposed this URL as well to configure with the new > > "--with-vendor-vm-bug-url" configure option. Again, if this option > > will not use, the VM will fall back to the old default value. > > > > Notice that this patch also fixes a bug introduced by "8193764: Cannot > > set COMPANY_NAME when configuring a build" because of which the jtreg > > test "test/jdk/tools/jlink/ReleaseImplementorTest.java" fails if the > > testee was configured without "--with-vendor-name". The problem is > > that the code introduced by 8193764 unconditionally sets COMPANY_NAME > > to the empty string, if no "--with-vendor-name" option was given. This > > overrides the default setting of COMPANY_NAME=N/A from > > $AUTOCONF_DIR/version-numbers. > > > > I want to bring this into jdk10 if possible. > > > > I need a sponsor because this change requires the regeneration of > > "generated-configure.sh" (which I've included in the webrev for your > > convenience only) and because it touches a HotSpot file and external > > contributors still can't push such changes :( > > > > Thank you and best regards, > > Volker > > From david.holmes at oracle.com Wed Jan 17 21:55:18 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Jan 2018 07:55:18 +1000 Subject: [10] RFR(S): 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag In-Reply-To: References: Message-ID: <2baa67e0-89e0-42d9-9b6e-affe0094e908@oracle.com> Hi Volker, Changes seem okay to me too. spec.gmk.in: ! # Only export VENDOR_URL, VENDOR_URL_BUG and VENDOR_VM_URL_BUG tot he build if they Typo: tot he -> to the I'm also surprised this doesn't need any quoting: ifneq ($(COMPANY_NAME), N/A) Thanks, David On 18/01/2018 2:03 AM, Volker Simonis wrote: > Hi, > > can I please have a review and sponsor for this change which finally > exposes the various "vendor*" properties: > > java.vendor > java.vm.vendor > java.vendor.url > java.vendor.url.bug > > as configure arguments: > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8189761 > https://bugs.openjdk.java.net/browse/JDK-8189761 > > With this change, "java.vendor" and "java.vm.vendor" still default to > "Oracle Corporation" which is defined in System.c (for "java.vendor") > and in vm_version.cpp (for "java.vm.version") unless the new > "--with-vendor-name" option introduced by JDK-8193764 will be used in > the configure step. > > If the "--with-vendor-name" option will be used, its value will now, > with this change, also be assigned to both, the "java.vendor" and > "java.vm.vendor" properties. I don't think that we need a separate > configure option for "java.vm.vendor" because if somebody is building > the OpenJDK with a different VM, he will own the source code of that > VM anyway and can easily set "java.vm.vendor" in his code. > > For "java.vendor.url" and "java.vendor.url.bug" I've introduced the > two new configure options "--with-vendor-url" and > "--with-vendor-bug-url" which should be self explanatory. If they are > not set, the old default values will be used. > > In the case of a VM crash, the HotSpot displays a second, different > bug URL which is currently only configured in the arguments.cpp file. > I've exposed this URL as well to configure with the new > "--with-vendor-vm-bug-url" configure option. Again, if this option > will not use, the VM will fall back to the old default value. > > Notice that this patch also fixes a bug introduced by "8193764: Cannot > set COMPANY_NAME when configuring a build" because of which the jtreg > test "test/jdk/tools/jlink/ReleaseImplementorTest.java" fails if the > testee was configured without "--with-vendor-name". The problem is > that the code introduced by 8193764 unconditionally sets COMPANY_NAME > to the empty string, if no "--with-vendor-name" option was given. This > overrides the default setting of COMPANY_NAME=N/A from > $AUTOCONF_DIR/version-numbers. > > I want to bring this into jdk10 if possible. > > I need a sponsor because this change requires the regeneration of > "generated-configure.sh" (which I've included in the webrev for your > convenience only) and because it touches a HotSpot file and external > contributors still can't push such changes :( > > Thank you and best regards, > Volker > From david.holmes at oracle.com Wed Jan 17 22:43:21 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Jan 2018 08:43:21 +1000 Subject: RFR: 8195621: JTReg failure in gc/g1/TestLargePageUseForAuxMemory.java In-Reply-To: <9db53780099e44d4a60ff8bf4944a657@NASANEXM01E.na.qualcomm.com> References: <9db53780099e44d4a60ff8bf4944a657@NASANEXM01E.na.qualcomm.com> Message-ID: Hi Daniel, On 18/01/2018 3:41 AM, stewartd.qdt wrote: > Please review this webrev [1] which attempts to fix a test error in gc/g1/TestLargePageUseForAuxMemory when it is run on a machine with 64K pages. See the bug report [2] for further details of why the error occurs. Essentially the test tries to allocate 512 times the huge page size and fails when the huge page size is around ? - 1 GB is size, because there simply isn't enough physical memory in the system. > > > This fix adds a function to WhiteBox to get the physical memory and then uses that to ensure we are not trying to allocate more than the physical amount of memory for our heap. Please let me know if this is a bad approach and I'll be happy to change as required. This seems an improvement though I would expect the test to fail long before we get close to the amount of physical memory available. Should the test be adjusting what it does based on the page size being used, in conjunction with the amount of "physical memory"? Hopefully one of the GC folk will chime in. Thanks, David > > > Thanks, > > Daniel Stewart > > > [1] - http://cr.openjdk.java.net/~dstewart/8195621/webrev.00/ > [2] - https://bugs.openjdk.java.net/browse/JDK-8195621 > From volker.simonis at gmail.com Wed Jan 17 22:59:07 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 17 Jan 2018 22:59:07 +0000 Subject: [10] RFR(S): 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag In-Reply-To: <2baa67e0-89e0-42d9-9b6e-affe0094e908@oracle.com> References: <2baa67e0-89e0-42d9-9b6e-affe0094e908@oracle.com> Message-ID: David Holmes schrieb am Mi. 17. Jan. 2018 um 22:55: > Hi Volker, > > Changes seem okay to me too. > Thanks David! > spec.gmk.in: > > ! # Only export VENDOR_URL, VENDOR_URL_BUG and VENDOR_VM_URL_BUG tot he > build if they > > Typo: tot he -> to the > Will fix tomorrow morning when I?m back in the office! > I'm also surprised this doesn't need any quoting: > > ifneq ($(COMPANY_NAME), N/A) > Me too, but I can assure you that it doesn?t work if quoted. I?ve tried it :) > Thanks, > David > > On 18/01/2018 2:03 AM, Volker Simonis wrote: > > Hi, > > > > can I please have a review and sponsor for this change which finally > > exposes the various "vendor*" properties: > > > > java.vendor > > java.vm.vendor > > java.vendor.url > > java.vendor.url.bug > > > > as configure arguments: > > > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8189761 > > https://bugs.openjdk.java.net/browse/JDK-8189761 > > > > With this change, "java.vendor" and "java.vm.vendor" still default to > > "Oracle Corporation" which is defined in System.c (for "java.vendor") > > and in vm_version.cpp (for "java.vm.version") unless the new > > "--with-vendor-name" option introduced by JDK-8193764 will be used in > > the configure step. > > > > If the "--with-vendor-name" option will be used, its value will now, > > with this change, also be assigned to both, the "java.vendor" and > > "java.vm.vendor" properties. I don't think that we need a separate > > configure option for "java.vm.vendor" because if somebody is building > > the OpenJDK with a different VM, he will own the source code of that > > VM anyway and can easily set "java.vm.vendor" in his code. > > > > For "java.vendor.url" and "java.vendor.url.bug" I've introduced the > > two new configure options "--with-vendor-url" and > > "--with-vendor-bug-url" which should be self explanatory. If they are > > not set, the old default values will be used. > > > > In the case of a VM crash, the HotSpot displays a second, different > > bug URL which is currently only configured in the arguments.cpp file. > > I've exposed this URL as well to configure with the new > > "--with-vendor-vm-bug-url" configure option. Again, if this option > > will not use, the VM will fall back to the old default value. > > > > Notice that this patch also fixes a bug introduced by "8193764: Cannot > > set COMPANY_NAME when configuring a build" because of which the jtreg > > test "test/jdk/tools/jlink/ReleaseImplementorTest.java" fails if the > > testee was configured without "--with-vendor-name". The problem is > > that the code introduced by 8193764 unconditionally sets COMPANY_NAME > > to the empty string, if no "--with-vendor-name" option was given. This > > overrides the default setting of COMPANY_NAME=N/A from > > $AUTOCONF_DIR/version-numbers. > > > > I want to bring this into jdk10 if possible. > > > > I need a sponsor because this change requires the regeneration of > > "generated-configure.sh" (which I've included in the webrev for your > > convenience only) and because it touches a HotSpot file and external > > contributors still can't push such changes :( > > > > Thank you and best regards, > > Volker > > > From erik.joelsson at oracle.com Wed Jan 17 23:07:33 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 17 Jan 2018 15:07:33 -0800 Subject: [10] RFR(S): 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag In-Reply-To: <2baa67e0-89e0-42d9-9b6e-affe0094e908@oracle.com> References: <2baa67e0-89e0-42d9-9b6e-affe0094e908@oracle.com> Message-ID: <01230026-887e-766b-b9ec-6c4f9047bb5f@oracle.com> I can just adjust that before I push. I'm running it through internal testing now. Regarding quoting, make doesn't really do quotes. When you see quoted strings in make, it's generally done for shell consumption. /Erik On 2018-01-17 13:55, David Holmes wrote: > Hi Volker, > > Changes seem okay to me too. > > spec.gmk.in: > > ! # Only export VENDOR_URL, VENDOR_URL_BUG and VENDOR_VM_URL_BUG tot > he build if they > > Typo: tot he -> to the > > I'm also surprised this doesn't need any quoting: > > ? ifneq ($(COMPANY_NAME), N/A) > > Thanks, > David > > On 18/01/2018 2:03 AM, Volker Simonis wrote: >> Hi, >> >> can I please have a review and sponsor for this change which finally >> exposes the various "vendor*" properties: >> >> java.vendor >> java.vm.vendor >> java.vendor.url >> java.vendor.url.bug >> >> as configure arguments: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2018/8189761 >> https://bugs.openjdk.java.net/browse/JDK-8189761 >> >> With this change, "java.vendor" and "java.vm.vendor" still default to >> "Oracle Corporation" which is defined in System.c (for "java.vendor") >> and in vm_version.cpp (for "java.vm.version") unless the new >> "--with-vendor-name" option introduced by JDK-8193764 will be used in >> the configure step. >> >> If the "--with-vendor-name" option will be used, its value will now, >> with this change, also be assigned to both, the "java.vendor" and >> "java.vm.vendor" properties. I don't think that we need a separate >> configure option for "java.vm.vendor" because if somebody is building >> the OpenJDK with a different VM, he will own the source code of that >> VM anyway and can easily set "java.vm.vendor" in his code. >> >> For "java.vendor.url" and "java.vendor.url.bug" I've introduced the >> two new configure options "--with-vendor-url" and >> "--with-vendor-bug-url" which should be self explanatory. If they are >> not set, the old default values will be used. >> >> In the case of a VM crash, the HotSpot displays a second, different >> bug URL which is currently only configured in the arguments.cpp file. >> I've exposed this URL as well to configure with the new >> "--with-vendor-vm-bug-url" configure option. Again, if this option >> will not use, the VM will fall back to the old default value. >> >> Notice that this patch also fixes a bug introduced by "8193764: Cannot >> set COMPANY_NAME when configuring a build" because of which the jtreg >> test "test/jdk/tools/jlink/ReleaseImplementorTest.java" fails if the >> testee was configured without "--with-vendor-name". The problem is >> that the code introduced by 8193764 unconditionally sets COMPANY_NAME >> to the empty string, if no "--with-vendor-name" option was given. This >> overrides the default setting of COMPANY_NAME=N/A from >> $AUTOCONF_DIR/version-numbers. >> >> I want to bring this into jdk10 if possible. >> >> I need a sponsor because this change requires the regeneration of >> "generated-configure.sh" (which I've included in the webrev for your >> convenience only) and because it touches a HotSpot file and external >> contributors still can't push such changes :( >> >> Thank you and best regards, >> Volker >> From igor.ignatyev at oracle.com Thu Jan 18 00:27:49 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 17 Jan 2018 16:27:49 -0800 Subject: RFR(M) : 8186635: ClassFileInstaller should be run as a driver Message-ID: <76BF25DE-1734-4FCB-9AEE-2422C8B9555A@oracle.com> http://cr.openjdk.java.net/~iignatyev//8186635/webrev.00/index.html > 194 lines changed: 0 ins; 0 del; Hi all, could you please review the patch which replaces all '@run main ClassFileInstaller' w/ '@run driver ClassFileInstaller' in hotspot tests? ClassFileInstaller is a widely used aux class which doesn't have to be run in JVM under test and/or w/ external flags. Running ClassFileInstaller as a driver can not only improve test stability, but also speed up test execution as jtreg will be able to reuse agent JVMs and these JVMs won't have any stress flags. webrev: http://cr.openjdk.java.net/~iignatyev//8186635/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8186635 testing: all changed tests Thanks, -- Igor From david.holmes at oracle.com Thu Jan 18 01:21:32 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Jan 2018 11:21:32 +1000 Subject: RFR(M) : 8186635: ClassFileInstaller should be run as a driver In-Reply-To: <76BF25DE-1734-4FCB-9AEE-2422C8B9555A@oracle.com> References: <76BF25DE-1734-4FCB-9AEE-2422C8B9555A@oracle.com> Message-ID: <7a351c8d-4f82-e576-ea12-67d21a643034@oracle.com> Hi Igor, This looks very reasonable! Reviewed. Do you have any speedup numbers? Thanks, David On 18/01/2018 10:27 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8186635/webrev.00/index.html >> 194 lines changed: 0 ins; 0 del; > > Hi all, > > could you please review the patch which replaces all '@run main ClassFileInstaller' w/ '@run driver ClassFileInstaller' in hotspot tests? > > ClassFileInstaller is a widely used aux class which doesn't have to be run in JVM under test and/or w/ external flags. Running ClassFileInstaller as a driver can not only improve test stability, but also speed up test execution as jtreg will be able to reuse agent JVMs and these JVMs won't have any stress flags. > > webrev: http://cr.openjdk.java.net/~iignatyev//8186635/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8186635 > testing: all changed tests > > Thanks, > -- Igor > From david.holmes at oracle.com Thu Jan 18 01:21:32 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Jan 2018 11:21:32 +1000 Subject: RFR(M) : 8186635: ClassFileInstaller should be run as a driver In-Reply-To: <76BF25DE-1734-4FCB-9AEE-2422C8B9555A@oracle.com> References: <76BF25DE-1734-4FCB-9AEE-2422C8B9555A@oracle.com> Message-ID: <7a351c8d-4f82-e576-ea12-67d21a643034@oracle.com> Hi Igor, This looks very reasonable! Reviewed. Do you have any speedup numbers? Thanks, David On 18/01/2018 10:27 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8186635/webrev.00/index.html >> 194 lines changed: 0 ins; 0 del; > > Hi all, > > could you please review the patch which replaces all '@run main ClassFileInstaller' w/ '@run driver ClassFileInstaller' in hotspot tests? > > ClassFileInstaller is a widely used aux class which doesn't have to be run in JVM under test and/or w/ external flags. Running ClassFileInstaller as a driver can not only improve test stability, but also speed up test execution as jtreg will be able to reuse agent JVMs and these JVMs won't have any stress flags. > > webrev: http://cr.openjdk.java.net/~iignatyev//8186635/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8186635 > testing: all changed tests > > Thanks, > -- Igor > From serguei.spitsyn at oracle.com Thu Jan 18 03:22:48 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 17 Jan 2018 19:22:48 -0800 Subject: RFR 8192004: InspectedFrame.materializeVirtualObjects only updates locals with new objects In-Reply-To: <4752003c-b879-f0a0-f863-fad713ab6004@oracle.com> References: <5A3BE1E2.6030105@oracle.com> <5A3D581B.8080601@oracle.com> <4752003c-b879-f0a0-f863-fad713ab6004@oracle.com> Message-ID: <7f65fea0-2646-e174-cd58-bfe44f67be91@oracle.com> It looks good to me. Sorry for the latency. Thanks, Serguei On 1/16/18 09:16, Vladimir Kozlov wrote: > No response from JVMTI so I looked again through it. It seems fine to > me. Reviewed. > > Thanks, > Vladimir > > On 12/22/17 12:14 PM, Vladimir Kozlov wrote: >> Posting to hotspot-dev alias since our group does not have JVMTI >> experts. >> I looked and it seems fine but someone from serviceability should >> look too. >> >> Thanks, >> Vladimir >> >> On 12/22/17 11:08 AM, Tom Rodriguez wrote: >>> Could I get some reviews?? This doesn't change the way the logic >>> behaves for the core use of JVMTI. It just extends the encoding so >>> that numbers after the locals are interpreted as expression stack >>> and monitor values. ??I believe there are existing tests of the >>> JVMTI set locals part and JVMCI is the only only consumer of the >>> monitor and expression stack part. >>> >>> tom >>> >>> Tom Rodriguez wrote: >>>> JVMCI adds the ability to introspect on deoptimized frames which >>>> requires early materialization of escape analyzed objects. The >>>> jvmtiDeferredLocalVariableSet machinery is reused to capture the local >>>> updates required for this. The existing code only updates locals, >>>> leaving the stack and monitor information with out of date values. >>>> This >>>> can lead to deadlocks and incorrect execution. The fix is to slightly >>>> generalize jvmtiDeferredLocalVariableSet to handle expression stack >>>> and >>>> monitor slots. Tested with new graal regression test >>>> https://github.com/graalvm/graal/blob/7fd37bde8955780a57049964d87a51aa2407d86b/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotStackIntrospectionTest.java >>>> >>>> and previously failing Truffle use cases. I assume the new test case >>>> will come across with a normal graal update. The clean mach5 run is in >>>> the bug report. >>>> >>>> http://cr.openjdk.java.net/~never/8192004/webrev >>>> https://bugs.openjdk.java.net/browse/JDK-8192004 >> From marcus.larsson at oracle.com Thu Jan 18 15:20:53 2018 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Thu, 18 Jan 2018 16:20:53 +0100 Subject: RFR(S): 8170941: Executing gtest with invalid -Xlog argument crashes gtestLauncher Message-ID: Hi, Please review the following small patch to prevent the gtest runner from crashing if invalid VM arguments are passed in. The launcher will now exit with an error message rather than hit some assert in the half initialized VM. Issue: https://bugs.openjdk.java.net/browse/JDK-8170941 Webrev: http://cr.openjdk.java.net/~mlarsson/8170941/webrev.00 Thanks, Marcus From tom.rodriguez at oracle.com Thu Jan 18 16:56:20 2018 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 18 Jan 2018 08:56:20 -0800 Subject: RFR 8192004: InspectedFrame.materializeVirtualObjects only updates locals with new objects In-Reply-To: <7f65fea0-2646-e174-cd58-bfe44f67be91@oracle.com> References: <5A3BE1E2.6030105@oracle.com> <5A3D581B.8080601@oracle.com> <4752003c-b879-f0a0-f863-fad713ab6004@oracle.com> <7f65fea0-2646-e174-cd58-bfe44f67be91@oracle.com> Message-ID: <5A60D1B4.8070706@oracle.com> Thanks! tom serguei.spitsyn at oracle.com wrote: > It looks good to me. > Sorry for the latency. > > Thanks, > Serguei > > > On 1/16/18 09:16, Vladimir Kozlov wrote: >> No response from JVMTI so I looked again through it. It seems fine to >> me. Reviewed. >> >> Thanks, >> Vladimir >> >> On 12/22/17 12:14 PM, Vladimir Kozlov wrote: >>> Posting to hotspot-dev alias since our group does not have JVMTI >>> experts. >>> I looked and it seems fine but someone from serviceability should >>> look too. >>> >>> Thanks, >>> Vladimir >>> >>> On 12/22/17 11:08 AM, Tom Rodriguez wrote: >>>> Could I get some reviews? This doesn't change the way the logic >>>> behaves for the core use of JVMTI. It just extends the encoding so >>>> that numbers after the locals are interpreted as expression stack >>>> and monitor values. I believe there are existing tests of the >>>> JVMTI set locals part and JVMCI is the only only consumer of the >>>> monitor and expression stack part. >>>> >>>> tom >>>> >>>> Tom Rodriguez wrote: >>>>> JVMCI adds the ability to introspect on deoptimized frames which >>>>> requires early materialization of escape analyzed objects. The >>>>> jvmtiDeferredLocalVariableSet machinery is reused to capture the local >>>>> updates required for this. The existing code only updates locals, >>>>> leaving the stack and monitor information with out of date values. >>>>> This >>>>> can lead to deadlocks and incorrect execution. The fix is to slightly >>>>> generalize jvmtiDeferredLocalVariableSet to handle expression stack >>>>> and >>>>> monitor slots. Tested with new graal regression test >>>>> https://github.com/graalvm/graal/blob/7fd37bde8955780a57049964d87a51aa2407d86b/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotStackIntrospectionTest.java >>>>> >>>>> and previously failing Truffle use cases. I assume the new test case >>>>> will come across with a normal graal update. The clean mach5 run is in >>>>> the bug report. >>>>> >>>>> http://cr.openjdk.java.net/~never/8192004/webrev >>>>> https://bugs.openjdk.java.net/browse/JDK-8192004 >>> > From mikhailo.seledtsov at oracle.com Thu Jan 18 18:07:27 2018 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Thu, 18 Jan 2018 10:07:27 -0800 Subject: RFR(M) : 8186635: ClassFileInstaller should be run as a driver In-Reply-To: <76BF25DE-1734-4FCB-9AEE-2422C8B9555A@oracle.com> References: <76BF25DE-1734-4FCB-9AEE-2422C8B9555A@oracle.com> Message-ID: <5A60E25F.40506@oracle.com> Change looks good to me, Misha On 1/17/18, 4:27 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8186635/webrev.00/index.html >> 194 lines changed: 0 ins; 0 del; > Hi all, > > could you please review the patch which replaces all '@run main ClassFileInstaller' w/ '@run driver ClassFileInstaller' in hotspot tests? > > ClassFileInstaller is a widely used aux class which doesn't have to be run in JVM under test and/or w/ external flags. Running ClassFileInstaller as a driver can not only improve test stability, but also speed up test execution as jtreg will be able to reuse agent JVMs and these JVMs won't have any stress flags. > > webrev: http://cr.openjdk.java.net/~iignatyev//8186635/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8186635 > testing: all changed tests > > Thanks, > -- Igor > From stewartd.qdt at qualcommdatacenter.com Fri Jan 19 15:11:58 2018 From: stewartd.qdt at qualcommdatacenter.com (stewartd.qdt) Date: Fri, 19 Jan 2018 15:11:58 +0000 Subject: RFR: 8195621: JTReg failure in gc/g1/TestLargePageUseForAuxMemory.java In-Reply-To: References: <9db53780099e44d4a60ff8bf4944a657@NASANEXM01E.na.qualcomm.com> Message-ID: <72d9ad5d97c842608633c114f2c0b227@NASANEXM01E.na.qualcomm.com> Yes, I too wondered if the test should be changed to be a bit more discerning in how it operates. I agree it would be great if a member of the GC team could chime in on this issue. Daniel -----Original Message----- > This fix adds a function to WhiteBox to get the physical memory and then uses that to ensure we are not trying to allocate more than the physical amount of memory for our heap. Please let me know if this is a bad approach and I'll be happy to change as required. This seems an improvement though I would expect the test to fail long before we get close to the amount of physical memory available. Should the test be adjusting what it does based on the page size being used, in conjunction with the amount of "physical memory"? Hopefully one of the GC folk will chime in. Thanks, David > > > Thanks, > > Daniel Stewart > > > [1] - http://cr.openjdk.java.net/~dstewart/8195621/webrev.00/ > [2] - https://bugs.openjdk.java.net/browse/JDK-8195621 > From kim.barrett at oracle.com Fri Jan 19 19:59:37 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 19 Jan 2018 14:59:37 -0500 Subject: RFR: 8194898: Move OopStorage inline definitions to an .inline.hpp Message-ID: Please review this code reorg for the recently added OopStorage. During the review of OopStorage (JDK-8194312) it was requested that the inline member function definitions and inner class definitions be moved to .inline.hpp file(s). The changes are: (1) ParState and BasicParState are moved to the new file oopStorageParState.inline.hpp. Also moved AlwaysTrueFn into BasicParState, which is the only user. (2) Moved the inline member function to the new file oopStorage.inline.hpp, along with most of the inner class definitions. The complete definitions of BlockEntry and BlockList remain within the OopStorage definition, as they are needed for member types. (3) Added inline qualifiers to public OopStorage function declarations when the function definition is in an inline header. This may produce better error messages by some compilers when the inline header is needed but not included. Note: This change will likely have a simple merge conflict (unrelated nearby changes to oopStorage.hpp) with the fix for JDK-8195691. Since I'm sponsoring the latter, I'll deal with that when the time comes, for whichever order these changes end up being pushed. CR: https://bugs.openjdk.java.net/browse/JDK-8194898 Webrev: http://cr.openjdk.java.net/~kbarrett/8194898/open.00/ Testing: hs-tier1,2,3 From sean.mullan at oracle.com Fri Jan 19 20:28:09 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 19 Jan 2018 15:28:09 -0500 Subject: sunrsasign.jar still searched in java 8? In-Reply-To: References: Message-ID: <554203c4-e9e3-4c63-b1b1-c74332a9fff5@oracle.com> I believe sunrsasign.jar was removed in JDK 1.5. So it seems like the line below is no longer necessary and should be removed. I have copied hotspot-dev to see if this is a known issue or if I am missing something. --Sean On 1/19/18 1:28 PM, Bernd wrote: > Hello, > > I noticed that when I strace a "java -version" with 8u152 JRE it > searches for sunrsasign.jar which is not found. Is that a compatibility > thing or should it not happen? > > It seems to be in the boot classpath even when the associated classes > are in rt.jar: > > http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/tip/src/share/vm/runtime/os.cpp#l1197 > > Gruss > Bernd > From david.holmes at oracle.com Sat Jan 20 09:19:54 2018 From: david.holmes at oracle.com (David Holmes) Date: Sat, 20 Jan 2018 19:19:54 +1000 Subject: sunrsasign.jar still searched in java 8? In-Reply-To: <554203c4-e9e3-4c63-b1b1-c74332a9fff5@oracle.com> References: <554203c4-e9e3-4c63-b1b1-c74332a9fff5@oracle.com> Message-ID: <35115f6f-c041-2179-fa60-eb3ccd25f561@oracle.com> On 20/01/2018 6:28 AM, Sean Mullan wrote: > I believe sunrsasign.jar was removed in JDK 1.5. So it seems like the > line below is no longer necessary and should be removed. I have copied > hotspot-dev to see if this is a known issue or if I am missing something. As per Brad's filing of https://bugs.openjdk.java.net/browse/JDK-8195794 this was claimed to have been done in another bug report, but it seems it got lost somewhere. Also see: https://bugs.openjdk.java.net/browse/JDK-7036474 which seems fixed in 8+ but not 7u. David > --Sean > > On 1/19/18 1:28 PM, Bernd wrote: >> Hello, >> >> I noticed that when I strace a "java -version" with 8u152 JRE it >> searches for sunrsasign.jar which is not found. Is that a >> compatibility thing or should it not happen? >> >> It seems to be in the boot classpath even when the associated classes >> are in rt.jar: >> >> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/tip/src/share/vm/runtime/os.cpp#l1197 >> >> >> Gruss >> Bernd >> From robbin.ehn at oracle.com Mon Jan 22 08:14:28 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 22 Jan 2018 09:14:28 +0100 Subject: RFR(S): 8170941: Executing gtest with invalid -Xlog argument crashes gtestLauncher In-Reply-To: References: Message-ID: Hi Marcus, looks good! /Robbin On 01/18/2018 04:20 PM, Marcus Larsson wrote: > Hi, > > Please review the following small patch to prevent the gtest runner from > crashing if invalid VM arguments are passed in. > The launcher will now exit with an error message rather than hit some assert in > the half initialized VM. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8170941 > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8170941/webrev.00 > > Thanks, > Marcus From marcus.larsson at oracle.com Mon Jan 22 08:25:10 2018 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 22 Jan 2018 09:25:10 +0100 Subject: RFR(S): 8170941: Executing gtest with invalid -Xlog argument crashes gtestLauncher In-Reply-To: References: Message-ID: <4f0da4c3-1378-c53b-71de-a156a7ad8f1e@oracle.com> Thanks Robbin! On 2018-01-22 09:14, Robbin Ehn wrote: > Hi Marcus, looks good! > > /Robbin > > On 01/18/2018 04:20 PM, Marcus Larsson wrote: >> Hi, >> >> Please review the following small patch to prevent the gtest runner >> from crashing if invalid VM arguments are passed in. >> The launcher will now exit with an error message rather than hit some >> assert in the half initialized VM. >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8170941 >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8170941/webrev.00 >> >> Thanks, >> Marcus From thomas.stuefe at gmail.com Mon Jan 22 11:57:57 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 22 Jan 2018 12:57:57 +0100 Subject: RFR(S): 8170941: Executing gtest with invalid -Xlog argument crashes gtestLauncher In-Reply-To: <4f0da4c3-1378-c53b-71de-a156a7ad8f1e@oracle.com> References: <4f0da4c3-1378-c53b-71de-a156a7ad8f1e@oracle.com> Message-ID: Thanks Marcus for fixing this. Looks fine. On Mon, Jan 22, 2018 at 9:25 AM, Marcus Larsson wrote: > Thanks Robbin! > > > > On 2018-01-22 09:14, Robbin Ehn wrote: > >> Hi Marcus, looks good! >> >> /Robbin >> >> On 01/18/2018 04:20 PM, Marcus Larsson wrote: >> >>> Hi, >>> >>> Please review the following small patch to prevent the gtest runner from >>> crashing if invalid VM arguments are passed in. >>> The launcher will now exit with an error message rather than hit some >>> assert in the half initialized VM. >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8170941 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mlarsson/8170941/webrev.00 >>> >>> Thanks, >>> Marcus >>> >> > From aph at redhat.com Mon Jan 22 12:00:13 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 22 Jan 2018 12:00:13 +0000 Subject: RFR: 8194739: Zero port of 8174962: Better interface invocations Message-ID: Fixes the breakage to Zero caused by 8174962: Better interface invocations. http://cr.openjdk.java.net/~aph/8194739/ -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From marcus.larsson at oracle.com Mon Jan 22 12:02:12 2018 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 22 Jan 2018 13:02:12 +0100 Subject: RFR(S): 8170941: Executing gtest with invalid -Xlog argument crashes gtestLauncher In-Reply-To: References: <4f0da4c3-1378-c53b-71de-a156a7ad8f1e@oracle.com> Message-ID: <678f3bf6-9171-984a-a16b-33a3ca3ef075@oracle.com> Thanks Thomas! On 2018-01-22 12:57, Thomas St?fe wrote: > Thanks Marcus for fixing this. Looks fine. > > On Mon, Jan 22, 2018 at 9:25 AM, Marcus Larsson > > wrote: > > Thanks Robbin! > > > > On 2018-01-22 09:14, Robbin Ehn wrote: > > Hi Marcus, looks good! > > /Robbin > > On 01/18/2018 04:20 PM, Marcus Larsson wrote: > > Hi, > > Please review the following small patch to prevent the > gtest runner from crashing if invalid VM arguments are > passed in. > The launcher will now exit with an error message rather > than hit some assert in the half initialized VM. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8170941 > > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8170941/webrev.00 > > > Thanks, > Marcus > > > From glaubitz at physik.fu-berlin.de Mon Jan 22 12:22:43 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 22 Jan 2018 13:22:43 +0100 Subject: RFR: 8194739: Zero port of 8174962: Better interface invocations In-Reply-To: References: Message-ID: <23b838a5-8d9b-141d-5d9c-585776b4d852@physik.fu-berlin.de> Hi Andrew! On 01/22/2018 01:00 PM, Andrew Haley wrote: > Fixes the breakage to Zero caused by 8174962: Better interface invocations. > > http://cr.openjdk.java.net/~aph/8194739/ I just wanted to review this change and make a test build when I noticed that invoking configure now constantly opens a text pager, i.e. less. I have to press "q" all the time to get the build to continue. Did anyone run into this issue as well? Did someone add some automatic pager view or something? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Mon Jan 22 12:44:46 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 22 Jan 2018 13:44:46 +0100 Subject: RFR: 8194739: Zero port of 8174962: Better interface invocations In-Reply-To: <23b838a5-8d9b-141d-5d9c-585776b4d852@physik.fu-berlin.de> References: <23b838a5-8d9b-141d-5d9c-585776b4d852@physik.fu-berlin.de> Message-ID: <2d1d9e0e-aad5-9f4f-cff6-7eef7645b5a4@physik.fu-berlin.de> On 01/22/2018 01:22 PM, John Paul Adrian Glaubitz wrote: > I just wanted to review this change and make a test build when I noticed that > invoking configure now constantly opens a text pager, i.e. less. I have to > press "q" all the time to get the build to continue. > > Did anyone run into this issue as well? Did someone add some automatic pager > view or something? This is caused by "PAGER='less -r'" which I had in my .bashrc. Odd, it was never a problem before. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Mon Jan 22 13:07:24 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 22 Jan 2018 14:07:24 +0100 Subject: RFR: 8194739: Zero port of 8174962: Better interface invocations In-Reply-To: References: Message-ID: On 01/22/2018 01:00 PM, Andrew Haley wrote: > Fixes the breakage to Zero caused by 8174962: Better interface invocations. > > http://cr.openjdk.java.net/~aph/8194739/ Hmm, what breakage does it actually fix? A standard build with "make images" still works for me. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From aph at redhat.com Mon Jan 22 13:46:01 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 22 Jan 2018 13:46:01 +0000 Subject: RFR: 8194739: Zero port of 8174962: Better interface invocations In-Reply-To: References: Message-ID: <3b5b371d-3c3a-5132-ceee-fa539a31ab61@redhat.com> On 22/01/18 13:07, John Paul Adrian Glaubitz wrote: > On 01/22/2018 01:00 PM, Andrew Haley wrote: >> Fixes the breakage to Zero caused by 8174962: Better interface invocations. >> >> http://cr.openjdk.java.net/~aph/8194739/ > > Hmm, what breakage does it actually fix? > > A standard build with "make images" still works for me. My apologies: this is a patch to ssh://hg.openjdk.java.net/jdk-updates/jdk9u/hotspot I should have said. I'll resend. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From glaubitz at physik.fu-berlin.de Mon Jan 22 13:52:16 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 22 Jan 2018 14:52:16 +0100 Subject: RFR: 8194739: Zero port of 8174962: Better interface invocations In-Reply-To: <3b5b371d-3c3a-5132-ceee-fa539a31ab61@redhat.com> References: <3b5b371d-3c3a-5132-ceee-fa539a31ab61@redhat.com> Message-ID: On 01/22/2018 02:46 PM, Andrew Haley wrote: >> A standard build with "make images" still works for me. > > My apologies: this is a patch to ssh://hg.openjdk.java.net/jdk-updates/jdk9u/hotspot > > I should have said. I'll resend. Ah, ok. Never mind then. Thanks for fixing jdk9 :). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From aph at redhat.com Mon Jan 22 15:23:51 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 22 Jan 2018 15:23:51 +0000 Subject: RFR: JDK10: 8194739: Zero port of 8174962: Better interface invocations Message-ID: Needs an additional fix to build in debug mode. http://cr.openjdk.java.net/~aph/8194739-jdk10/ -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Jan 22 16:30:52 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 22 Jan 2018 16:30:52 +0000 Subject: JDK8u: RFR: 8194739: Zero port of 8174962: Better interface invocations Message-ID: <7c1ee9d4-5791-538c-9585-b6c1b7cf5592@redhat.com> Backport, applies cleanly. http://cr.openjdk.java.net/~aph/8194739-jdk8/ -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Mon Jan 22 16:48:13 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 22 Jan 2018 17:48:13 +0100 Subject: RFR: JDK10: 8194739: Zero port of 8174962: Better interface invocations In-Reply-To: References: Message-ID: <1516639693.4142.14.camel@redhat.com> On Mon, 2018-01-22 at 15:23 +0000, Andrew Haley wrote: > Needs an additional fix to build in debug mode. > > http://cr.openjdk.java.net/~aph/8194739-jdk10/ FWIW, a release build of a JDK 10 tree with 8174962 fails to build Zero for me as well. I've tested the patch and it builds fine for me. So +1. Thanks, Severin From bob.vandette at oracle.com Mon Jan 22 17:20:17 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 22 Jan 2018 12:20:17 -0500 Subject: RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers Message-ID: Please review this change that resolves the detection of Java processes that are running in cgroup based containers. This latest (and hopefully final) update of this fix addresses comments from David Holmes and Mandy Chung. Bug: https://bugs.openjdk.java.net/browse/JDK-8193710 Webrev: http://cr.openjdk.java.net/~bobv/8193710/webrev.02/ Summary: This changeset enables the ability to use jcmd and jps running on a Host to list the java processes that are running in docker (cgroup based) containers. I?ve tested this change by examining processes running as root on both host and in docker containers as well as under my userid using ?jps and jcmd -l?. I?ve also tested updates to the getFile functions with a small example program that I wrote. Here are some implementation details that I?ve added to the Linux specific implementation class: src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java /* Implementation Details: * * Java processes that run in docker containers are typically running * under cgroups with separate pid namespaces which means that pids * within the container are different that the pid which is visible * from the host. The container pids typically start with 1 and * increase. The java process running in the container will use these * pids when creating the hsperfdata files. In order to locate java * processes that are running in containers, we take advantage of * the Linux proc file system which maps the containers tmp directory * to the hosts under /proc/{hostpid}/root/tmp. We use the /proc status * file /proc/{hostpid}/status to determine the containers pid and * then access the hsperfdata file. The status file contains an * entry "NSPid:" which shows the mapping from the hostpid to the * containers pid. * * Example: * * NSPid: 24345 11 * * In this example process 24345 is visible from the host, * is running under the PID namespace and has a container specific * pid of 11. * * The search for Java processes is done by first looking in the * traditional /tmp for host process hsperfdata files and then * the search will container in every /proc/*/root/tmp directory. * There are of course added complications to this search that * need to be taken into account. * * 1. duplication of tmp directories * * /proc/{hostpid}/root/tmp directories exist for many processes * that are running on a Linux kernel that has cgroups enabled even * if they are not running in a container. To avoid this duplication, * we compare the inode of the /proc tmp directories to /tmp and * skip these duplicated directories. * * 2. Containerized processes without PID namespaces being enabled. * * If a container is running a Java process without namespaces being * enabled, an hsperfdata file will only be located at * /proc/{hostpid}/root/tmp/{hostpid}. This is handled by * checking the last component in the path for both the hostpid * and potential namespacepids (if one exists). */ Bob. From mandy.chung at oracle.com Mon Jan 22 18:32:32 2018 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 22 Jan 2018 10:32:32 -0800 Subject: RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers In-Reply-To: References: Message-ID: On 1/22/18 9:20 AM, Bob Vandette wrote: > : > > Webrev: > > http://cr.openjdk.java.net/~bobv/8193710/webrev.02/ Thanks for the update.? Looks good to me. It would be good to add a comment in PlatformSupport::getInstance to explain that PlatformSupport provides the default implementation that can be overridden by a platform-specific version PlatformSupportImpl, if present. We discussed that PlatformSupport::getLocalVmId could throw IAE rather than NumberFormatException if the given file is invalid. This carries from existing jvmstat code and so agree to leave it as a future clean up.? PlatformSupportImpl::getTemporaryDirectories can be simplified with java.nio.file.Path but what you have is fine with me. Mandy From coleen.phillimore at oracle.com Mon Jan 22 19:03:55 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 22 Jan 2018 14:03:55 -0500 Subject: RFR: JDK10: 8194739: Zero port of 8174962: Better interface invocations In-Reply-To: <1516639693.4142.14.camel@redhat.com> References: <1516639693.4142.14.camel@redhat.com> Message-ID: <47cf3d74-81fc-6ede-4a94-048a5696191d@oracle.com> This? change looks good to me. Coleen On 1/22/18 11:48 AM, Severin Gehwolf wrote: > On Mon, 2018-01-22 at 15:23 +0000, Andrew Haley wrote: >> Needs an additional fix to build in debug mode. >> >> http://cr.openjdk.java.net/~aph/8194739-jdk10/ > FWIW, a release build of a JDK 10 tree with 8174962 fails to build Zero > for me as well. > > I've tested the patch and it builds fine for me. So +1. > > Thanks, > Severin From coleen.phillimore at oracle.com Mon Jan 22 19:04:21 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 22 Jan 2018 14:04:21 -0500 Subject: RFR: 8194739: Zero port of 8174962: Better interface invocations In-Reply-To: <3b5b371d-3c3a-5132-ceee-fa539a31ab61@redhat.com> References: <3b5b371d-3c3a-5132-ceee-fa539a31ab61@redhat.com> Message-ID: <2d744598-1607-75b8-43cb-f6ad75cae611@oracle.com> This looks good to me also. Coleen On 1/22/18 8:46 AM, Andrew Haley wrote: > On 22/01/18 13:07, John Paul Adrian Glaubitz wrote: >> On 01/22/2018 01:00 PM, Andrew Haley wrote: >>> Fixes the breakage to Zero caused by 8174962: Better interface invocations. >>> >>> http://cr.openjdk.java.net/~aph/8194739/ >> Hmm, what breakage does it actually fix? >> >> A standard build with "make images" still works for me. > My apologies: this is a patch to ssh://hg.openjdk.java.net/jdk-updates/jdk9u/hotspot > > I should have said. I'll resend. > From david.holmes at oracle.com Mon Jan 22 22:15:46 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jan 2018 08:15:46 +1000 Subject: RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers In-Reply-To: References: Message-ID: Thanks Bob. Seems okay. David On 23/01/2018 3:20 AM, Bob Vandette wrote: > Please review this change that resolves the detection of Java processes that are running in cgroup > based containers. > > This latest (and hopefully final) update of this fix addresses comments from David Holmes and Mandy Chung. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8193710 > > Webrev: > > http://cr.openjdk.java.net/~bobv/8193710/webrev.02/ > > Summary: > > This changeset enables the ability to use jcmd and jps running on a Host to > list the java processes that are running in docker (cgroup based) containers. > > I?ve tested this change by examining processes running as root on both host and in > docker containers as well as under my userid using ?jps and jcmd -l?. > I?ve also tested updates to the getFile functions with a small example program that I wrote. > > > Here are some implementation details that I?ve added to the Linux specific implementation class: > > src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java > > /* Implementation Details: > * > * Java processes that run in docker containers are typically running > * under cgroups with separate pid namespaces which means that pids > * within the container are different that the pid which is visible > * from the host. The container pids typically start with 1 and > * increase. The java process running in the container will use these > * pids when creating the hsperfdata files. In order to locate java > * processes that are running in containers, we take advantage of > * the Linux proc file system which maps the containers tmp directory > * to the hosts under /proc/{hostpid}/root/tmp. We use the /proc status > * file /proc/{hostpid}/status to determine the containers pid and > * then access the hsperfdata file. The status file contains an > * entry "NSPid:" which shows the mapping from the hostpid to the > * containers pid. > * > * Example: > * > * NSPid: 24345 11 > * > * In this example process 24345 is visible from the host, > * is running under the PID namespace and has a container specific > * pid of 11. > * > * The search for Java processes is done by first looking in the > * traditional /tmp for host process hsperfdata files and then > * the search will container in every /proc/*/root/tmp directory. > * There are of course added complications to this search that > * need to be taken into account. > * > * 1. duplication of tmp directories > * > * /proc/{hostpid}/root/tmp directories exist for many processes > * that are running on a Linux kernel that has cgroups enabled even > * if they are not running in a container. To avoid this duplication, > * we compare the inode of the /proc tmp directories to /tmp and > * skip these duplicated directories. > * > * 2. Containerized processes without PID namespaces being enabled. > * > * If a container is running a Java process without namespaces being > * enabled, an hsperfdata file will only be located at > * /proc/{hostpid}/root/tmp/{hostpid}. This is handled by > * checking the last component in the path for both the hostpid > * and potential namespacepids (if one exists). > */ > > Bob. > From matthias.baesken at sap.com Tue Jan 23 08:24:59 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 23 Jan 2018 08:24:59 +0000 Subject: RFR : 8195857 : Posix platforms : move os::is_headless_jre check coding to os::Posix and remove test for libmawt Message-ID: <83c352c941374468bd811f611dfc2aff@sap.com> Hello, I noticed that os::is_headless_jre() still checks on the Posix platforms for libmawt which is not present any longer. Additionally the os::is_headless_jre() function could be put in a central place at os_posix to avoid code duplication. Could you please review my change . Webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8195857/ Bug : https://bugs.openjdk.java.net/browse/JDK-8195857 Thanks, Matthias From david.holmes at oracle.com Tue Jan 23 10:29:48 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jan 2018 20:29:48 +1000 Subject: RFR : 8195857 : Posix platforms : move os::is_headless_jre check coding to os::Posix and remove test for libmawt In-Reply-To: <83c352c941374468bd811f611dfc2aff@sap.com> References: <83c352c941374468bd811f611dfc2aff@sap.com> Message-ID: <292752fd-8152-216d-c09c-2236485c4a58@oracle.com> Hi Matthias, Some preliminary comments ... On 23/01/2018 6:24 PM, Baesken, Matthias wrote: > Hello, I noticed that os::is_headless_jre() still checks on the Posix platforms for libmawt which is not present any longer. I wonder why that comment was put in but the code not changed ... > Additionally the os::is_headless_jre() function could be put in a central place at os_posix to avoid code duplication. I think you could simplify further and just define in os.cpp with three cases: windows, OS X, posix. I normally wouldn't suggest that but given Windows and OS X are always false, it's quite trivial. That said this may simplify even further because I don't know if the concept of a headless JRE is even meaningful anymore. This what put in place in 2010 to support Java SE Embedded. We had a special build process that would remove the library from the JRE image, then a runtime check os::is_headless_jre() run during argument processing, that if true, caused the java.awt.headless property to be set to true (unless already set). I don't think we can even build a "headless JRE" any more. I'd need to do some checking but I think this may all be effectively dead code. Thanks, David ------- > Could you please review my change . > > Webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8195857/ > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-8195857 > > > > Thanks, Matthias > From david.holmes at oracle.com Tue Jan 23 10:36:42 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jan 2018 20:36:42 +1000 Subject: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot build with JDK-8174962 In-Reply-To: <81a1f298-25fe-62a1-1f33-151a6dcf9ff5@redhat.com> References: <099d09c1-93e6-dd29-68da-4a9a9cb5e420@redhat.com> <0aecad5e-30e5-1b90-5d48-f45a6144e215@redhat.com> <81a1f298-25fe-62a1-1f33-151a6dcf9ff5@redhat.com> Message-ID: <7c83e330-769e-847a-6f33-85962e004b57@oracle.com> Adding in hotspot-dev and Jesper Hi Andrew, On 23/01/2018 8:16 PM, Andrew Dinn wrote: > On 23/01/18 08:46, Andrew Dinn wrote: >> I am afraid I messed up by pushing the patch for 8195685 to both >> jdkdev/jdk and jdkdev/hs. While the former was correct and approved by >> Vladimir the latter was a stupid neglect of the appropriate protocol on >> my part. Apologies for making such a mess. > The patch included below reverts the erroneous push of 8195685 to > jdk/hs. I'm not sure of the procedure to get this into the repo but > until that is resolved this can be used by anyone working on AArch64 to > get their hg tree back to a clean state. I don't think you want to push this to jdk/hs, else you'll have a worse problem. If this undoes the fix, and the changeset with the fix is already seen to be in jdk/hs then when we sync with jdk/jdk we will end up without the fix! You may be lucky in that Jesper has been holding off pulling jdk/jdk into jdk/hs due to some test failures in jdk/jdk. If those are fixed (and I know one has been) then Jesper may merge jdk/jdk to jdk/hs "real soon now" and all the necessary pieces will be in place in jdk/hs. David > 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 > > ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- > # HG changeset patch > # User adinn > # Date 1516702051 0 > # Tue Jan 23 10:07:31 2018 +0000 > # Node ID a7e77acacaad73682a6dd70801502dad55450d41 > # Parent 8f451978683ce3193c302f6140ecf05afee1754a > revert wrong commit of 8195685 > > diff -r 8f451978683c -r a7e77acacaad > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp > --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp Tue Jan 23 > 08:55:47 2018 +0100 > +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp Tue Jan 23 > 10:07:31 2018 +0000 > @@ -963,12 +963,8 @@ > RegisterOrConstant > itable_index, > Register method_result, > Register scan_temp, > - Label& L_no_such_interface, > - bool return_method) { > - assert_different_registers(recv_klass, intf_klass, scan_temp); > - assert_different_registers(method_result, intf_klass, scan_temp); > - assert(recv_klass != method_result || !return_method, > - "recv_klass can be destroyed when method isn't needed"); > + Label& L_no_such_interface) { > + assert_different_registers(recv_klass, intf_klass, method_result, > scan_temp); > assert(itable_index.is_constant() || itable_index.as_register() == > method_result, > "caller must use same register for non-constant itable index > as for method"); > > @@ -986,14 +982,12 @@ > lea(scan_temp, Address(recv_klass, scan_temp, Address::lsl(3))); > add(scan_temp, scan_temp, vtable_base); > > - if (return_method) { > - // Adjust recv_klass by scaled itable_index, so we can free > itable_index. > - assert(itableMethodEntry::size() * wordSize == wordSize, "adjust > the scaling in the code below"); > - // lea(recv_klass, Address(recv_klass, itable_index, > Address::times_ptr, itentry_off)); > - lea(recv_klass, Address(recv_klass, itable_index, Address::lsl(3))); > - if (itentry_off) > - add(recv_klass, recv_klass, itentry_off); > - } > + // Adjust recv_klass by scaled itable_index, so we can free itable_index. > + assert(itableMethodEntry::size() * wordSize == wordSize, "adjust the > scaling in the code below"); > + // lea(recv_klass, Address(recv_klass, itable_index, > Address::times_ptr, itentry_off)); > + lea(recv_klass, Address(recv_klass, itable_index, Address::lsl(3))); > + if (itentry_off) > + add(recv_klass, recv_klass, itentry_off); > > // for (scan = klass->itable(); scan->interface() != NULL; scan += > scan_step) { > // if (scan->interface() == intf) { > @@ -1027,10 +1021,8 @@ > bind(found_method); > > // Got a hit. > - if (return_method) { > - ldrw(scan_temp, Address(scan_temp, > itableOffsetEntry::offset_offset_in_bytes())); > - ldr(method_result, Address(recv_klass, scan_temp, Address::uxtw(0))); > - } > + ldr(scan_temp, Address(scan_temp, > itableOffsetEntry::offset_offset_in_bytes())); > + ldr(method_result, Address(recv_klass, scan_temp)); > } > > // virtual method calling > diff -r 8f451978683c -r a7e77acacaad > src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp > --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Tue Jan 23 > 08:55:47 2018 +0100 > +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Tue Jan 23 > 10:07:31 2018 +0000 > @@ -875,8 +875,7 @@ > RegisterOrConstant itable_index, > Register method_result, > Register scan_temp, > - Label& no_such_interface, > - bool return_method = true); > + Label& no_such_interface); > > // virtual method calling > // n.b. x86 allows RegisterOrConstant for vtable_index > diff -r 8f451978683c -r a7e77acacaad > src/hotspot/cpu/aarch64/templateTable_aarch64.cpp > --- a/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp Tue Jan 23 > 08:55:47 2018 +0100 > +++ b/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp Tue Jan 23 > 10:07:31 2018 +0000 > @@ -3279,11 +3279,11 @@ > transition(vtos, vtos); > assert(byte_no == f1_byte, "use this argument"); > > - prepare_invoke(byte_no, r0, rmethod, // get f1 Klass*, f2 Method* > + prepare_invoke(byte_no, r0, rmethod, // get f1 Klass*, f2 itable index > r2, r3); // recv, flags > > // r0: interface klass (from f1) > - // rmethod: method (from f2) > + // rmethod: itable index (from f2) > // r2: receiver > // r3: flags > > @@ -3302,27 +3302,10 @@ > __ null_check(r2, oopDesc::klass_offset_in_bytes()); > __ load_klass(r3, r2); > > - Label no_such_interface, no_such_method; > - > - // Receiver subtype check against REFC. > - // Superklass in r0. Subklass in r3. Blows rscratch2, r13 > - __ lookup_interface_method(// inputs: rec. class, interface, itable index > - r3, r0, noreg, > - // outputs: scan temp. reg, scan temp. reg > - rscratch2, r13, > - no_such_interface, > - /*return_method=*/false); > - > // profile this call > __ profile_virtual_call(r3, r13, r19); > > - // Get declaring interface class from method, and itable index > - __ ldr(r0, Address(rmethod, Method::const_offset())); > - __ ldr(r0, Address(r0, ConstMethod::constants_offset())); > - __ ldr(r0, Address(r0, ConstantPool::pool_holder_offset_in_bytes())); > - __ ldrw(rmethod, Address(rmethod, Method::itable_index_offset())); > - __ subw(rmethod, rmethod, Method::itable_index_max); > - __ negw(rmethod, rmethod); > + Label no_such_interface, no_such_method; > > __ lookup_interface_method(// inputs: rec. class, interface, itable index > r3, r0, rmethod, > diff -r 8f451978683c -r a7e77acacaad > src/hotspot/cpu/aarch64/vtableStubs_aarch64.cpp > --- a/src/hotspot/cpu/aarch64/vtableStubs_aarch64.cpp Tue Jan 23 > 08:55:47 2018 +0100 > +++ b/src/hotspot/cpu/aarch64/vtableStubs_aarch64.cpp Tue Jan 23 > 10:07:31 2018 +0000 > @@ -29,7 +29,6 @@ > #include "code/vtableStubs.hpp" > #include "interp_masm_aarch64.hpp" > #include "memory/resourceArea.hpp" > -#include "oops/compiledICHolder.hpp" > #include "oops/instanceKlass.hpp" > #include "oops/klassVtable.hpp" > #include "runtime/sharedRuntime.hpp" > @@ -141,44 +140,28 @@ > #endif > > // Entry arguments: > - // rscratch2: CompiledICHolder > + // rscratch2: Interface > // j_rarg0: Receiver > > - > - // Most registers are in use; we'll use r0, rmethod, r10, r11 > - const Register recv_klass_reg = r10; > - const Register holder_klass_reg = r0; // declaring interface klass > (DECC) > - const Register resolved_klass_reg = rmethod; // resolved interface > klass (REFC) > - const Register temp_reg = r11; > - const Register icholder_reg = rscratch2; > - > - Label L_no_such_interface; > - > - __ ldr(resolved_klass_reg, Address(icholder_reg, > CompiledICHolder::holder_klass_offset())); > - __ ldr(holder_klass_reg, Address(icholder_reg, > CompiledICHolder::holder_metadata_offset())); > + // Free registers (non-args) are r0 (interface), rmethod > > // get receiver (need to skip return address on top of stack) > + > assert(VtableStub::receiver_location() == j_rarg0->as_VMReg(), > "receiver expected in j_rarg0"); > // get receiver klass (also an implicit null-check) > address npe_addr = __ pc(); > - __ load_klass(recv_klass_reg, j_rarg0); > > - // Receiver subtype check against REFC. > - // Destroys recv_klass_reg value. > - __ lookup_interface_method(// inputs: rec. class, interface > - recv_klass_reg, resolved_klass_reg, noreg, > - // outputs: scan temp. reg1, scan temp. reg2 > - recv_klass_reg, temp_reg, > - L_no_such_interface, > - /*return_method=*/false); > + // Most registers are in use; we'll use r0, rmethod, r10, r11 > + __ load_klass(r10, j_rarg0); > > - // Get selected method from declaring class and itable index > - __ load_klass(recv_klass_reg, j_rarg0); // restore recv_klass_reg > + Label throw_icce; > + > + // Get Method* and entrypoint for compiler > __ lookup_interface_method(// inputs: rec. class, interface, itable index > - recv_klass_reg, holder_klass_reg, itable_index, > - // outputs: method, scan temp. reg > - rmethod, temp_reg, > - L_no_such_interface); > + r10, rscratch2, itable_index, > + // outputs: method, scan temp. reg > + rmethod, r11, > + throw_icce); > > // method (rmethod): Method* > // j_rarg0: receiver > @@ -200,7 +183,7 @@ > __ ldr(rscratch1, Address(rmethod, Method::from_compiled_offset())); > __ br(rscratch1); > > - __ bind(L_no_such_interface); > + __ bind(throw_icce); > __ > far_jump(RuntimeAddress(StubRoutines::throw_IncompatibleClassChangeError_entry())); > > __ flush(); > @@ -222,11 +205,11 @@ > int size = DebugVtables ? 216 : 0; > if (CountCompiledCalls) > size += 6 * 4; > - // FIXME: vtable stubs only need 36 bytes > + // FIXME > if (is_vtable_stub) > size += 52; > else > - size += 176; > + size += 104; > return size; > > // In order to tune these parameters, run the JVM with VM options > @@ -234,58 +217,33 @@ > // actual itable stubs. Run it with -Xmx31G -XX:+UseCompressedOops. > // > // If Universe::narrow_klass_base is nonzero, decoding a compressed > - // class can take zeveral instructions. > + // class can take zeveral instructions. Run it with -Xmx31G > + // -XX:+UseCompressedOops. > // > // The JVM98 app. _202_jess has a megamorphic interface call. > // The itable code looks like this: > - > - // ldr xmethod, [xscratch2,#CompiledICHolder::holder_klass_offset] > - // ldr x0, [xscratch2] > - // ldr w10, [x1,#oopDesc::klass_offset_in_bytes] > - // mov xheapbase, #0x3c000000 // > #narrow_klass_base > - // movk xheapbase, #0x3f7, lsl #32 > - // add x10, xheapbase, x10 > - // mov xheapbase, #0xe7ff0000 // #heapbase > - // movk xheapbase, #0x3f7, lsl #32 > - // ldr w11, [x10,#vtable_length_offset] > - // add x11, x10, x11, uxtx #3 > - // add x11, x11, #itableMethodEntry::method_offset_in_bytes > - // ldr x10, [x11] > - // cmp xmethod, x10 > - // b.eq found_method > - // search: > - // cbz x10, no_such_interface > - // add x11, x11, #0x10 > - // ldr x10, [x11] > - // cmp xmethod, x10 > - // b.ne search > - // found_method: > - // ldr w10, [x1,#oopDesc::klass_offset_in_bytes] > - // mov xheapbase, #0x3c000000 // > #narrow_klass_base > - // movk xheapbase, #0x3f7, lsl #32 > - // add x10, xheapbase, x10 > - // mov xheapbase, #0xe7ff0000 // #heapbase > - // movk xheapbase, #0x3f7, lsl #32 > - // ldr w11, [x10,#vtable_length_offset] > - // add x11, x10, x11, uxtx #3 > - // add x11, x11, #itableMethodEntry::method_offset_in_bytes > - // add x10, x10, #itentry_off > - // ldr xmethod, [x11] > - // cmp x0, xmethod > - // b.eq found_method2 > - // search2: > - // cbz xmethod, 0x000003ffa872e6cc > - // add x11, x11, #0x10 > - // ldr xmethod, [x11] > - // cmp x0, xmethod > - // b.ne search2 > - // found_method2: > - // ldr w11, [x11,#itableOffsetEntry::offset_offset_in_bytes] > - // ldr xmethod, [x10,w11,uxtw] > - // ldr xscratch1, [xmethod,#Method::from_compiled_offset] > - // br xscratch1 > - // no_such_interface: > - // b throw_ICCE_entry > + // Decoding VtableStub itbl[1]@12 > + // ldr w10, [x1,#8] > + // lsl x10, x10, #3 > + // ldr w11, [x10,#280] > + // add x11, x10, x11, uxtx #3 > + // add x11, x11, #0x1b8 > + // ldr x12, [x11] > + // cmp x9, x12 > + // b.eq success > + // loop: > + // cbz x12, throw_icce > + // add x11, x11, #0x10 > + // ldr x12, [x11] > + // cmp x9, x12 > + // b.ne loop > + // success: > + // ldr x11, [x11,#8] > + // ldr x12, [x10,x11] > + // ldr x8, [x12,#72] > + // br x8 > + // throw_icce: > + // b throw_ICCE_entry > > } > > ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- > From adinn at redhat.com Tue Jan 23 10:54:23 2018 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 23 Jan 2018 10:54:23 +0000 Subject: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot build with JDK-8174962 In-Reply-To: <7c83e330-769e-847a-6f33-85962e004b57@oracle.com> References: <099d09c1-93e6-dd29-68da-4a9a9cb5e420@redhat.com> <0aecad5e-30e5-1b90-5d48-f45a6144e215@redhat.com> <81a1f298-25fe-62a1-1f33-151a6dcf9ff5@redhat.com> <7c83e330-769e-847a-6f33-85962e004b57@oracle.com> Message-ID: <45b525dc-2554-b441-bf27-9c2a9bb520c6@redhat.com> Hi David, On 23/01/18 10:36, David Holmes wrote: > Adding in hotspot-dev and Jesper Thanks! > I don't think you want to push this to jdk/hs, else you'll have a worse > problem. If this undoes the fix, and the changeset with the fix is > already seen to be in jdk/hs then when we sync with jdk/jdk we will end > up without the fix! Yeah, I thought that was probably going to be the problem. > You may be lucky in that Jesper has been holding off pulling jdk/jdk > into jdk/hs due to some test failures in jdk/jdk. If those are fixed > (and I know one has been) then Jesper may merge jdk/jdk to jdk/hs "real > soon now" and all the necessary pieces will be in place in jdk/hs. Yes, I guess once the other changes make it in "real soon" the out of order, early application of this one will not matter. Thanks for explaining things and, once again, apologies for the mess. 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 matthias.baesken at sap.com Tue Jan 23 10:57:28 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 23 Jan 2018 10:57:28 +0000 Subject: RFR : 8195857 : Posix platforms : move os::is_headless_jre check coding to os::Posix and remove test for libmawt In-Reply-To: <292752fd-8152-216d-c09c-2236485c4a58@oracle.com> References: <83c352c941374468bd811f611dfc2aff@sap.com> <292752fd-8152-216d-c09c-2236485c4a58@oracle.com> Message-ID: <08f18f12f480493e9b00cfdcc99ef1bc@sap.com> Hi David, thanks for the comments. > I'd need to do some checking but I think this may all be effectively > dead code. Please do the checking, maybe we can completely remove it. Best Regards, Matthias > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 23. Januar 2018 11:30 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Subject: Re: RFR : 8195857 : Posix platforms : move os::is_headless_jre check > coding to os::Posix and remove test for libmawt > > Hi Matthias, > > Some preliminary comments ... > > On 23/01/2018 6:24 PM, Baesken, Matthias wrote: > > Hello, I noticed that os::is_headless_jre() still checks on the Posix > platforms for libmawt which is not present any longer. > > I wonder why that comment was put in but the code not changed ... > > > Additionally the os::is_headless_jre() function could be put in a central > place at os_posix to avoid code duplication. > > I think you could simplify further and just define in os.cpp with three > cases: windows, OS X, posix. I normally wouldn't suggest that but given > Windows and OS X are always false, it's quite trivial. > > That said this may simplify even further because I don't know if the > concept of a headless JRE is even meaningful anymore. This what put in > place in 2010 to support Java SE Embedded. We had a special build > process that would remove the library from the JRE image, then a runtime > check os::is_headless_jre() run during argument processing, that if > true, caused the java.awt.headless property to be set to true (unless > already set). I don't think we can even build a "headless JRE" any more. > > I'd need to do some checking but I think this may all be effectively > dead code. > > Thanks, > David > ------- > > > Could you please review my change . > > > > Webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8195857/ > > > > Bug : > > > > https://bugs.openjdk.java.net/browse/JDK-8195857 > > > > > > > > Thanks, Matthias > > From jesper.wilhelmsson at oracle.com Tue Jan 23 14:17:55 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 23 Jan 2018 15:17:55 +0100 Subject: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot build with JDK-8174962 In-Reply-To: <45b525dc-2554-b441-bf27-9c2a9bb520c6@redhat.com> References: <099d09c1-93e6-dd29-68da-4a9a9cb5e420@redhat.com> <0aecad5e-30e5-1b90-5d48-f45a6144e215@redhat.com> <81a1f298-25fe-62a1-1f33-151a6dcf9ff5@redhat.com> <7c83e330-769e-847a-6f33-85962e004b57@oracle.com> <45b525dc-2554-b441-bf27-9c2a9bb520c6@redhat.com> Message-ID: <04B7021B-3F93-45DE-9A1F-728FD4DB0DA6@oracle.com> > On 23 Jan 2018, at 11:54, Andrew Dinn wrote: > > Hi David, > > On 23/01/18 10:36, David Holmes wrote: >> Adding in hotspot-dev and Jesper > > Thanks! > >> I don't think you want to push this to jdk/hs, else you'll have a worse >> problem. If this undoes the fix, and the changeset with the fix is >> already seen to be in jdk/hs then when we sync with jdk/jdk we will end >> up without the fix! > > Yeah, I thought that was probably going to be the problem. > >> You may be lucky in that Jesper has been holding off pulling jdk/jdk >> into jdk/hs due to some test failures in jdk/jdk. If those are fixed >> (and I know one has been) then Jesper may merge jdk/jdk to jdk/hs "real >> soon now" and all the necessary pieces will be in place in jdk/hs. > Yes, I guess once the other changes make it in "real soon" the out of > order, early application of this one will not matter. Thanks for > explaining things and, once again, apologies for the mess. The merge is done. I'll just run a sanity test cycle on the result and then pull jdk/jdk into jdk/hs provided there are no errors. /Jesper > > 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 bob.vandette at oracle.com Tue Jan 23 15:25:13 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 23 Jan 2018 10:25:13 -0500 Subject: RFR : 8195857 : Posix platforms : move os::is_headless_jre check coding to os::Posix and remove test for libmawt In-Reply-To: <08f18f12f480493e9b00cfdcc99ef1bc@sap.com> References: <83c352c941374468bd811f611dfc2aff@sap.com> <292752fd-8152-216d-c09c-2236485c4a58@oracle.com> <08f18f12f480493e9b00cfdcc99ef1bc@sap.com> Message-ID: <042CA641-9057-444D-BFA9-CB4B2737ADF4@oracle.com> If we are going to preserve this functionality and make alterations, I suggest that we try to move this into the desktop module and remove it from the hotspot sources. Other than finding an appropriate path at startup to initialize the property, there is no reason why this check can?t be written in Java. This functionality has nothing to do with Hotspot or VMs. (I should have probably done this when I first added this check). Bob. > On Jan 23, 2018, at 5:57 AM, Baesken, Matthias wrote: > > Hi David, thanks for the comments. > >> I'd need to do some checking but I think this may all be effectively >> dead code. > > Please do the checking, maybe we can completely remove it. > > Best Regards, Matthias > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Dienstag, 23. Januar 2018 11:30 >> To: Baesken, Matthias ; 'hotspot- >> dev at openjdk.java.net' >> Subject: Re: RFR : 8195857 : Posix platforms : move os::is_headless_jre check >> coding to os::Posix and remove test for libmawt >> >> Hi Matthias, >> >> Some preliminary comments ... >> >> On 23/01/2018 6:24 PM, Baesken, Matthias wrote: >>> Hello, I noticed that os::is_headless_jre() still checks on the Posix >> platforms for libmawt which is not present any longer. >> >> I wonder why that comment was put in but the code not changed ... >> >>> Additionally the os::is_headless_jre() function could be put in a central >> place at os_posix to avoid code duplication. >> >> I think you could simplify further and just define in os.cpp with three >> cases: windows, OS X, posix. I normally wouldn't suggest that but given >> Windows and OS X are always false, it's quite trivial. >> >> That said this may simplify even further because I don't know if the >> concept of a headless JRE is even meaningful anymore. This what put in >> place in 2010 to support Java SE Embedded. We had a special build >> process that would remove the library from the JRE image, then a runtime >> check os::is_headless_jre() run during argument processing, that if >> true, caused the java.awt.headless property to be set to true (unless >> already set). I don't think we can even build a "headless JRE" any more. >> >> I'd need to do some checking but I think this may all be effectively >> dead code. >> >> Thanks, >> David >> ------- >> >>> Could you please review my change . >>> >>> Webrev : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8195857/ >>> >>> Bug : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8195857 >>> >>> >>> >>> Thanks, Matthias >>> From david.holmes at oracle.com Tue Jan 23 22:50:27 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jan 2018 08:50:27 +1000 Subject: RFR : 8195857 : Posix platforms : move os::is_headless_jre check coding to os::Posix and remove test for libmawt In-Reply-To: <042CA641-9057-444D-BFA9-CB4B2737ADF4@oracle.com> References: <83c352c941374468bd811f611dfc2aff@sap.com> <292752fd-8152-216d-c09c-2236485c4a58@oracle.com> <08f18f12f480493e9b00cfdcc99ef1bc@sap.com> <042CA641-9057-444D-BFA9-CB4B2737ADF4@oracle.com> Message-ID: <9b649a09-29ea-c8e6-1ddb-7a22b5a54e57@oracle.com> Hi Bob, On 24/01/2018 1:25 AM, Bob Vandette wrote: > If we are going to preserve this functionality and make alterations, I suggest that > we try to move this into the desktop module and remove it from the hotspot sources. > Other than finding an appropriate path at startup to initialize the property, there is > no reason why this check can?t be written in Java. This functionality has nothing to > do with Hotspot or VMs. (I should have probably done this when I first added this check). Well we hacked it into the SE Embedded builds so we knew what lib was missing. I don't think what you suggest really makes sense in a modular world because I don't think we expect to have java.desktop but not some of its native parts - so there would be no trigger to force into headless mode. More likely there is simply no java.desktop module at all. That said I was reminded that this is also used by the Compact Profiles that were added in Java 8, but for which support was removed as from Java 9 (and modules). However the build logic is still present, and they still use this functionality. I think we can remove compact profiles completely in JDK 11, but that's a seperate tasks. Meanwhile if we kill off the os::is_headless_jre() logic then the compact profiles would not default to headless mode even though they can't run headful (due to the missing native library as well as other Java APIs). But the only impact I can see there would be for running tests - and we're not testing compact profiles. So ... I still think this can be removed, but want to do a couple more checks. Cheers, David > Bob. > >> On Jan 23, 2018, at 5:57 AM, Baesken, Matthias wrote: >> >> Hi David, thanks for the comments. >> >>> I'd need to do some checking but I think this may all be effectively >>> dead code. >> >> Please do the checking, maybe we can completely remove it. >> >> Best Regards, Matthias >> >> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Dienstag, 23. Januar 2018 11:30 >>> To: Baesken, Matthias ; 'hotspot- >>> dev at openjdk.java.net' >>> Subject: Re: RFR : 8195857 : Posix platforms : move os::is_headless_jre check >>> coding to os::Posix and remove test for libmawt >>> >>> Hi Matthias, >>> >>> Some preliminary comments ... >>> >>> On 23/01/2018 6:24 PM, Baesken, Matthias wrote: >>>> Hello, I noticed that os::is_headless_jre() still checks on the Posix >>> platforms for libmawt which is not present any longer. >>> >>> I wonder why that comment was put in but the code not changed ... >>> >>>> Additionally the os::is_headless_jre() function could be put in a central >>> place at os_posix to avoid code duplication. >>> >>> I think you could simplify further and just define in os.cpp with three >>> cases: windows, OS X, posix. I normally wouldn't suggest that but given >>> Windows and OS X are always false, it's quite trivial. >>> >>> That said this may simplify even further because I don't know if the >>> concept of a headless JRE is even meaningful anymore. This what put in >>> place in 2010 to support Java SE Embedded. We had a special build >>> process that would remove the library from the JRE image, then a runtime >>> check os::is_headless_jre() run during argument processing, that if >>> true, caused the java.awt.headless property to be set to true (unless >>> already set). I don't think we can even build a "headless JRE" any more. >>> >>> I'd need to do some checking but I think this may all be effectively >>> dead code. >>> >>> Thanks, >>> David >>> ------- >>> >>>> Could you please review my change . >>>> >>>> Webrev : >>>> >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8195857/ >>>> >>>> Bug : >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8195857 >>>> >>>> >>>> >>>> Thanks, Matthias >>>> > From thomas.schatzl at oracle.com Wed Jan 24 09:16:39 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 24 Jan 2018 10:16:39 +0100 Subject: RFR: 8195621: JTReg failure in gc/g1/TestLargePageUseForAuxMemory.java In-Reply-To: <72d9ad5d97c842608633c114f2c0b227@NASANEXM01E.na.qualcomm.com> References: <9db53780099e44d4a60ff8bf4944a657@NASANEXM01E.na.qualcomm.com> <72d9ad5d97c842608633c114f2c0b227@NASANEXM01E.na.qualcomm.com> Message-ID: <1516785399.2365.7.camel@oracle.com> Hi, On Fri, 2018-01-19 at 15:11 +0000, stewartd.qdt wrote: > Yes, I too wondered if the test should be changed to be a bit more > discerning in how it operates. > > I agree it would be great if a member of the GC team could chime in > on this issue. > > Daniel > > -----Original Message----- > > > This fix adds a function to WhiteBox to get the physical memory and > > then uses that to ensure we are not trying to allocate more than > > the physical amount of memory for our heap. Please let me know if > > this is a bad approach and I'll be happy to change as required. > > This seems an improvement though I would expect the test to fail long > before we get close to the amount of physical memory available. > Should the test be adjusting what it does based on the page size > being used, in conjunction with the amount of "physical memory"? > > Hopefully one of the GC folk will chime in. The test has obviously been written with existing test setups we have that are configured accordingly. I think for the test it may be sufficient to simply remove the -Xms flags in the VM invocations. Then the test would not try to actually commit all of the pages for e.g. the heap. That assumes it is no problem for these systems to only reserve 512G, and the systems themselves, if configured to use 1g huge pages is configured properly, i.e. there are actually have a few gb of memory available (unless -version does not even create objects on the java heap). Otherwise, instead of adding a new whitebox method, it might be preferable to get free/physical memory using standard Java means like OperatingSystemMXBean [1]. Thanks, Thomas [1] https://docs.oracle.com/javase/9/docs/api/com/sun/management/Operat ingSystemMXBean.html From shafi.s.ahmad at oracle.com Wed Jan 24 09:46:09 2018 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Wed, 24 Jan 2018 01:46:09 -0800 (PST) Subject: [8u] RFR for backport of JDK-8026331: hs_err improvement: Print if we have seen any OutOfMemoryErrors or StackOverflowErrors Message-ID: <84e4010f-e1ed-4940-ad24-5e7fc1667899@default> Hi, Please review the backport of bug: " JDK-8026331: hs_err improvement: Print if we have seen any OutOfMemoryErrors or StackOverflowErrors" to jdk8u-dev. Please note that this is not a clean backport as I got below conflicts - hotspot$ find ./ -name "*.rej" -exec cat {} \; --- metaspace.cpp +++ metaspace.cpp @@ -3132,10 +3132,21 @@ initialize_class_space(metaspace_rs); if (PrintCompressedOopsMode || (PrintMiscellaneous && Verbose)) { - gclog_or_tty->print_cr("Narrow klass base: " PTR_FORMAT ", Narrow klass shift: %d", - p2i(Universe::narrow_klass_base()), Universe::narrow_klass_shift()); - gclog_or_tty->print_cr("Compressed class space size: " SIZE_FORMAT " Address: " PTR_FORMAT " Req Addr: " PTR_FORMAT, - compressed_class_space_size(), p2i(metaspace_rs.base()), p2i(requested_addr)); + print_compressed_class_space(gclog_or_tty, requested_addr); + } +} + +void Metaspace::print_compressed_class_space(outputStream* st, const char* requested_addr) { + st->print_cr("Narrow klass base: " PTR_FORMAT ", Narrow klass shift: %d", + p2i(Universe::narrow_klass_base()), Universe::narrow_klass_shift()); + if (_class_space_list != NULL) { + address base = (address)_class_space_list->current_virtual_space()->bottom(); + st->print("Compressed class space size: " SIZE_FORMAT " Address: " PTR_FORMAT, + compressed_class_space_size(), p2i(base)); + if (requested_addr != 0) { + st->print(" Req Addr: " PTR_FORMAT, p2i(requested_addr)); + } + st->cr(); } } --- universe.cpp +++ universe.cpp @@ -781,27 +781,24 @@ return JNI_OK; } -void Universe::print_compressed_oops_mode() { - tty->cr(); - tty->print("heap address: " PTR_FORMAT ", size: " SIZE_FORMAT " MB", +void Universe::print_compressed_oops_mode(outputStream* st) { + st->print("heap address: " PTR_FORMAT ", size: " SIZE_FORMAT " MB", p2i(Universe::heap()->base()), Universe::heap()->reserved_region().byte_size()/M); - tty->print(", Compressed Oops mode: %s", narrow_oop_mode_to_string(narrow_oop_mode())); + st->print(", Compressed Oops mode: %s", narrow_oop_mode_to_string(narrow_oop_mode())); if (Universe::narrow_oop_base() != 0) { - tty->print(": " PTR_FORMAT, p2i(Universe::narrow_oop_base())); + st->print(": " PTR_FORMAT, p2i(Universe::narrow_oop_base())); } if (Universe::narrow_oop_shift() != 0) { - tty->print(", Oop shift amount: %d", Universe::narrow_oop_shift()); + st->print(", Oop shift amount: %d", Universe::narrow_oop_shift()); } if (!Universe::narrow_oop_use_implicit_null_checks()) { - tty->print(", no protected page in front of the heap"); + st->print(", no protected page in front of the heap"); } - - tty->cr(); - tty->cr(); + st->cr(); } Webrev: http://cr.openjdk.java.net/~shshahma/8026331/webrev.00/ Jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8026331 Original patch pushed to jdk9: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/cf5a0377f578 Test: Run jprt -testset hotspot and jtreg - hotspot/test Regards, Shafi From gromero at linux.vnet.ibm.com Wed Jan 24 12:39:55 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 24 Jan 2018 10:39:55 -0200 Subject: RFR : PPC64 : Need support for VSR spills in ppc.ad In-Reply-To: References: <409187f381384294a5f5c1a38b66a840@sap.com> <5f8786f3d20649d697b99f4d663cd110@sap.com> <183dc8d4630d4bc7930fd17b757c054d@sap.com> <32adbeb39b9a4f74b48f04345e587b36@sap.com> Message-ID: <5A687E9B.6010903@linux.vnet.ibm.com> Hi Martin, I think Michi measured the effectivity of this change using SPECjbb2015 and got about 4% of performance improvement in max-jOPS. Many of our clients still use OpenJDK 8 and I understand that although currently there isn't a new schedule ahead of 8u162 [1], 8 will continue to receive updates once 8u162 is GA. So I would to backport it to jdk8u/jdk8u so distros can grab it on the next security update (roughly). Are you ok with that? If you are ok, since this change depends upon other changes that introduced the support for VSX, is it fine if I start backporting them firstly instead of this one? What do you recommend? Thank you. Regards, Gustavo [1] http://openjdk.java.net/projects/jdk8u/ From gromero at linux.vnet.ibm.com Wed Jan 24 12:52:18 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 24 Jan 2018 10:52:18 -0200 Subject: RFR : PPC64 : Need support for VSR spills in ppc.ad In-Reply-To: <5A687E9B.6010903@linux.vnet.ibm.com> References: <409187f381384294a5f5c1a38b66a840@sap.com> <5f8786f3d20649d697b99f4d663cd110@sap.com> <183dc8d4630d4bc7930fd17b757c054d@sap.com> <32adbeb39b9a4f74b48f04345e587b36@sap.com> <5A687E9B.6010903@linux.vnet.ibm.com> Message-ID: <5A688182.7080506@linux.vnet.ibm.com> On 01/24/2018 10:39 AM, Gustavo Romero wrote: > Hi Martin, > > I think Michi measured the effectivity of this change using SPECjbb2015 and got > about 4% of performance improvement in max-jOPS. Actually for SLP in a whole, but it holds the same. > Many of our clients still use OpenJDK 8 and I understand that although currently > there isn't a new schedule ahead of 8u162 [1], 8 will continue to receive > updates once 8u162 is GA. So I would to backport it to jdk8u/jdk8u so distros > can grab it on the next security update (roughly). Are you ok with that? > > If you are ok, since this change depends upon other changes that introduced the > support for VSX, is it fine if I start backporting them firstly instead > of this one? What do you recommend? > > Thank you. > > > Regards, > Gustavo > > [1] http://openjdk.java.net/projects/jdk8u/ > From thomas.stuefe at gmail.com Wed Jan 24 13:00:25 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 24 Jan 2018 14:00:25 +0100 Subject: RFR: 8195621: JTReg failure in gc/g1/TestLargePageUseForAuxMemory.java In-Reply-To: References: <9db53780099e44d4a60ff8bf4944a657@NASANEXM01E.na.qualcomm.com> Message-ID: On Wed, Jan 17, 2018 at 11:43 PM, David Holmes wrote: > Hi Daniel, > > On 18/01/2018 3:41 AM, stewartd.qdt wrote: > >> Please review this webrev [1] which attempts to fix a test error in >> gc/g1/TestLargePageUseForAuxMemory when it is run on a machine with 64K >> pages. See the bug report [2] for further details of why the error occurs. >> Essentially the test tries to allocate 512 times the huge page size and >> fails when the huge page size is around ? - 1 GB is size, because there >> simply isn't enough physical memory in the system. >> >> >> This fix adds a function to WhiteBox to get the physical memory and then >> uses that to ensure we are not trying to allocate more than the physical >> amount of memory for our heap. Please let me know if this is a bad approach >> and I'll be happy to change as required. >> > > This seems an improvement though I would expect the test to fail long > before we get close to the amount of physical memory available. Should the > test be adjusting what it does based on the page size being used, in > conjunction with the amount of "physical memory"? > > I am not even sure os::physical_memory() would be meaningful on Linux with huge pages. Would the real limiting factor not be the size of the huge page pool (vm.nr_hugepages) ? If that one is too small, or the user has no access rights to the pool, you would get huge page allocation errors regardless what physical memory is in the system, no? Kind Regards, Thomas Hopefully one of the GC folk will chime in. > > Thanks, > David > > > >> >> Thanks, >> >> Daniel Stewart >> >> >> [1] - http://cr.openjdk.java.net/~dstewart/8195621/webrev.00/ >> [2] - https://bugs.openjdk.java.net/browse/JDK-8195621 >> >> From david.holmes at oracle.com Wed Jan 24 13:03:26 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jan 2018 23:03:26 +1000 Subject: RFR: 8195621: JTReg failure in gc/g1/TestLargePageUseForAuxMemory.java In-Reply-To: References: <9db53780099e44d4a60ff8bf4944a657@NASANEXM01E.na.qualcomm.com> Message-ID: <74584b62-0845-75b9-f893-e8d5519637d0@oracle.com> On 24/01/2018 11:00 PM, Thomas St?fe wrote: > On Wed, Jan 17, 2018 at 11:43 PM, David Holmes > wrote: > > Hi Daniel, > > On 18/01/2018 3:41 AM, stewartd.qdt wrote: > > Please review this webrev [1] which attempts to fix a test error > in gc/g1/TestLargePageUseForAuxMemory when it is run on a > machine with 64K pages. See the bug report [2] for further > details of why the error occurs. Essentially the test tries to > allocate 512 times the huge page size and fails when the huge > page size is around ? - 1 GB is size, because there simply isn't > enough physical memory in the system. > > > This fix adds a function to WhiteBox to get the physical memory > and then uses that to ensure we are not trying to allocate more > than the physical amount of memory for our heap. Please let me > know if this is a bad approach and I'll be happy to change as > required. > > > This seems an improvement though I would expect the test to fail > long before we get close to the amount of physical memory available. > Should the test be adjusting what it does based on the page size > being used, in conjunction with the amount of "physical memory"? > > > I am not even sure os::physical_memory() would be meaningful on Linux > with huge pages. That's why I said "physical memory" not os::physical_memory() :) > Would the real limiting factor not be the size of the huge page pool > (vm.nr_hugepages) ? If that one is too small, or the user has no access > rights to the pool, you would get huge page allocation errors regardless > what physical memory is in the system, no? I don't know. Thanks for raising the question. Cheers, David > Kind Regards, Thomas > > Hopefully one of the GC folk will chime in. > > Thanks, > David > > > > > Thanks, > > Daniel Stewart > > > [1] - http://cr.openjdk.java.net/~dstewart/8195621/webrev.00/ > > [2] - https://bugs.openjdk.java.net/browse/JDK-8195621 > > > From martin.doerr at sap.com Wed Jan 24 13:07:09 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 24 Jan 2018 13:07:09 +0000 Subject: RFR : PPC64 : Need support for VSR spills in ppc.ad In-Reply-To: <5A687E9B.6010903@linux.vnet.ibm.com> References: <409187f381384294a5f5c1a38b66a840@sap.com> <5f8786f3d20649d697b99f4d663cd110@sap.com> <183dc8d4630d4bc7930fd17b757c054d@sap.com> <32adbeb39b9a4f74b48f04345e587b36@sap.com> <5A687E9B.6010903@linux.vnet.ibm.com> Message-ID: Hi Gustavo, I think the change should be tested a little longer before requesting a backport. But in general, I'm not against it if you do all the work. Please note that I can't push to 8u (I'm not a 8u committer or reviewer). Best regards, Martin -----Original Message----- From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] Sent: Mittwoch, 24. Januar 2018 13:40 To: Michihiro Horie ; Doerr, Martin Cc: Lindenmaier, Goetz ; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR : PPC64 : Need support for VSR spills in ppc.ad Hi Martin, I think Michi measured the effectivity of this change using SPECjbb2015 and got about 4% of performance improvement in max-jOPS. Many of our clients still use OpenJDK 8 and I understand that although currently there isn't a new schedule ahead of 8u162 [1], 8 will continue to receive updates once 8u162 is GA. So I would to backport it to jdk8u/jdk8u so distros can grab it on the next security update (roughly). Are you ok with that? If you are ok, since this change depends upon other changes that introduced the support for VSX, is it fine if I start backporting them firstly instead of this one? What do you recommend? Thank you. Regards, Gustavo [1] http://openjdk.java.net/projects/jdk8u/ From bob.vandette at oracle.com Wed Jan 24 13:16:56 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 24 Jan 2018 08:16:56 -0500 Subject: RFR : 8195857 : Posix platforms : move os::is_headless_jre check coding to os::Posix and remove test for libmawt In-Reply-To: <9b649a09-29ea-c8e6-1ddb-7a22b5a54e57@oracle.com> References: <83c352c941374468bd811f611dfc2aff@sap.com> <292752fd-8152-216d-c09c-2236485c4a58@oracle.com> <08f18f12f480493e9b00cfdcc99ef1bc@sap.com> <042CA641-9057-444D-BFA9-CB4B2737ADF4@oracle.com> <9b649a09-29ea-c8e6-1ddb-7a22b5a54e57@oracle.com> Message-ID: <0E2C7BA4-689D-4B6A-AC72-1ACE02DCD8F1@oracle.com> > On Jan 23, 2018, at 5:50 PM, David Holmes wrote: > > Hi Bob, > > On 24/01/2018 1:25 AM, Bob Vandette wrote: >> If we are going to preserve this functionality and make alterations, I suggest that >> we try to move this into the desktop module and remove it from the hotspot sources. >> Other than finding an appropriate path at startup to initialize the property, there is >> no reason why this check can?t be written in Java. This functionality has nothing to >> do with Hotspot or VMs. (I should have probably done this when I first added this check). > > Well we hacked it into the SE Embedded builds so we knew what lib was missing. > > I don't think what you suggest really makes sense in a modular world because I don't think we expect to have java.desktop but not some of its native parts - so there would be no trigger to force into headless mode. More likely there is simply no java.desktop module at all. The automatic setting of java.awt.headless has nothing to do with compact profiles. This support was available in JDK 7 before profiles even existed. This automatic headless detection was added in order to allow Java to be ported to platforms that do not have a native windowing toolkit available. This was used in embedded to also reduce the size of the binary by removing this big library. A configuration that contains java.desktop can absolutely be supported and the JCK can be passed without this native library. This Java property is only referenced by the desktop module. This is why I suggested that this functionality be moved out of the hotspot VM. Bob. > > That said I was reminded that this is also used by the Compact Profiles that were added in Java 8, but for which support was removed as from Java 9 (and modules). However the build logic is still present, and they still use this functionality. I think we can remove compact profiles completely in JDK 11, but that's a seperate tasks. > > Meanwhile if we kill off the os::is_headless_jre() logic then the compact profiles would not default to headless mode even though they can't run headful (due to the missing native library as well as other Java APIs). But the only impact I can see there would be for running tests - and we're not testing compact profiles. So ... I still think this can be removed, but want to do a couple more checks. > > Cheers, > David > >> Bob. >>> On Jan 23, 2018, at 5:57 AM, Baesken, Matthias wrote: >>> >>> Hi David, thanks for the comments. >>> >>>> I'd need to do some checking but I think this may all be effectively >>>> dead code. >>> >>> Please do the checking, maybe we can completely remove it. >>> >>> Best Regards, Matthias >>> >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Dienstag, 23. Januar 2018 11:30 >>>> To: Baesken, Matthias ; 'hotspot- >>>> dev at openjdk.java.net' >>>> Subject: Re: RFR : 8195857 : Posix platforms : move os::is_headless_jre check >>>> coding to os::Posix and remove test for libmawt >>>> >>>> Hi Matthias, >>>> >>>> Some preliminary comments ... >>>> >>>> On 23/01/2018 6:24 PM, Baesken, Matthias wrote: >>>>> Hello, I noticed that os::is_headless_jre() still checks on the Posix >>>> platforms for libmawt which is not present any longer. >>>> >>>> I wonder why that comment was put in but the code not changed ... >>>> >>>>> Additionally the os::is_headless_jre() function could be put in a central >>>> place at os_posix to avoid code duplication. >>>> >>>> I think you could simplify further and just define in os.cpp with three >>>> cases: windows, OS X, posix. I normally wouldn't suggest that but given >>>> Windows and OS X are always false, it's quite trivial. >>>> >>>> That said this may simplify even further because I don't know if the >>>> concept of a headless JRE is even meaningful anymore. This what put in >>>> place in 2010 to support Java SE Embedded. We had a special build >>>> process that would remove the library from the JRE image, then a runtime >>>> check os::is_headless_jre() run during argument processing, that if >>>> true, caused the java.awt.headless property to be set to true (unless >>>> already set). I don't think we can even build a "headless JRE" any more. >>>> >>>> I'd need to do some checking but I think this may all be effectively >>>> dead code. >>>> >>>> Thanks, >>>> David >>>> ------- >>>> >>>>> Could you please review my change . >>>>> >>>>> Webrev : >>>>> >>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8195857/ >>>>> >>>>> Bug : >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8195857 >>>>> >>>>> >>>>> >>>>> Thanks, Matthias >>>>> From gromero at linux.vnet.ibm.com Wed Jan 24 13:30:36 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 24 Jan 2018 11:30:36 -0200 Subject: RFR : PPC64 : Need support for VSR spills in ppc.ad In-Reply-To: References: <409187f381384294a5f5c1a38b66a840@sap.com> <5f8786f3d20649d697b99f4d663cd110@sap.com> <183dc8d4630d4bc7930fd17b757c054d@sap.com> <32adbeb39b9a4f74b48f04345e587b36@sap.com> <5A687E9B.6010903@linux.vnet.ibm.com> Message-ID: <5A688A7C.70705@linux.vnet.ibm.com> Hi Martin, On 01/24/2018 11:07 AM, Doerr, Martin wrote: > Hi Gustavo, > > I think the change should be tested a little longer before requesting a backport. I see. Do you suggest testing it in any particular way or should we wait OpenJDK 11 LTS goes GA so it begins to be tested more widely once it reaches out the distros (Ubuntu, SLES, and RHEL)? > But in general, I'm not against it if you do all the work. Please note that I can't push to 8u (I'm not a 8u committer or reviewer). Got it. Sure, I would do all the work in that case :-) I think you can still be a (r)eviewer even not being an 8u (R)eviewer in case a backport does not apply cleanly to 8u and needs a new review on the hotspot ML? Best regards, Gustavo > Best regards, > Martin > > > -----Original Message----- > From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] > Sent: Mittwoch, 24. Januar 2018 13:40 > To: Michihiro Horie ; Doerr, Martin > Cc: Lindenmaier, Goetz ; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: Re: RFR : PPC64 : Need support for VSR spills in ppc.ad > > Hi Martin, > > I think Michi measured the effectivity of this change using SPECjbb2015 and got > about 4% of performance improvement in max-jOPS. > > Many of our clients still use OpenJDK 8 and I understand that although currently > there isn't a new schedule ahead of 8u162 [1], 8 will continue to receive > updates once 8u162 is GA. So I would to backport it to jdk8u/jdk8u so distros > can grab it on the next security update (roughly). Are you ok with that? > > If you are ok, since this change depends upon other changes that introduced the > support for VSX, is it fine if I start backporting them firstly instead > of this one? What do you recommend? > > Thank you. > > > Regards, > Gustavo > > [1] http://openjdk.java.net/projects/jdk8u/ > From martin.doerr at sap.com Wed Jan 24 13:48:58 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 24 Jan 2018 13:48:58 +0000 Subject: RFR : PPC64 : Need support for VSR spills in ppc.ad In-Reply-To: <5A688A7C.70705@linux.vnet.ibm.com> References: <409187f381384294a5f5c1a38b66a840@sap.com> <5f8786f3d20649d697b99f4d663cd110@sap.com> <183dc8d4630d4bc7930fd17b757c054d@sap.com> <32adbeb39b9a4f74b48f04345e587b36@sap.com> <5A687E9B.6010903@linux.vnet.ibm.com> <5A688A7C.70705@linux.vnet.ibm.com> Message-ID: Hi Gustavo, > Do you suggest testing it in any particular way or should we wait > OpenJDK 11 LTS goes GA so it begins to be tested more widely once it reaches > out the distros (Ubuntu, SLES, and RHEL)? We have nightly tests for jdk/hs so it gets tested automatically to some extent. More tests will run when we integrate it into SAP JVM. So I think you don't necessarily have to wait until GA. Backport changes should be tested better than running a few tests for a couple of days. Maybe you have nightly tests for 8u where you can test the backport for some time? I think this would be ideal. Otherwise, I'm a little concerned about possibly required shared fixes which were not backported to 8u. > I think you can still be a (r)eviewer even not being an 8u (R)eviewer in case a > backport does not apply cleanly to 8u and needs a new review on the hotspot ML? I can answer questions or write an additional review. Best regards, Martin From gromero at linux.vnet.ibm.com Wed Jan 24 14:18:36 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 24 Jan 2018 12:18:36 -0200 Subject: RFR : PPC64 : Need support for VSR spills in ppc.ad In-Reply-To: References: <409187f381384294a5f5c1a38b66a840@sap.com> <5f8786f3d20649d697b99f4d663cd110@sap.com> <183dc8d4630d4bc7930fd17b757c054d@sap.com> <32adbeb39b9a4f74b48f04345e587b36@sap.com> <5A687E9B.6010903@linux.vnet.ibm.com> <5A688A7C.70705@linux.vnet.ibm.com> Message-ID: <5A6895BC.504@linux.vnet.ibm.com> Hi Martin, On 01/24/2018 11:48 AM, Doerr, Martin wrote: > Hi Gustavo, > >> Do you suggest testing it in any particular way or should we wait >> OpenJDK 11 LTS goes GA so it begins to be tested more widely once it reaches >> out the distros (Ubuntu, SLES, and RHEL)? > We have nightly tests for jdk/hs so it gets tested automatically to some extent. More tests will run when we integrate it into SAP JVM. > So I think you don't necessarily have to wait until GA. I see. Thanks for sharing this information. > Backport changes should be tested better than running a few tests for a couple of days. Maybe you have nightly tests for 8u where you can test the backport for some time? I think this would be ideal. Otherwise, I'm a little concerned about possibly required shared fixes which were not backported to 8u. Unfortunately I dont't have a setup ready. I'll have to check if somebody working on AdoptOpenJDK.net / PowerPC initiative can help on that. Otherwise I need to setup something manually, but it would cover just POWER8 LE. I've already talked to Volker about it in the past but I never got the proper infrastructure resources to make it happen. Btw, I think SAP is not testing 8u for ppc64le [1], correct? But is jdk/hs tested on ppc64le or SAP does not perform nightly tests on LE at all? >> I think you can still be a (r)eviewer even not being an 8u (R)eviewer in case a >> backport does not apply cleanly to 8u and needs a new review on the hotspot ML? > I can answer questions or write an additional review. Thanks a lot. That would be very helpful. Best regards, Gustavo [1] http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2017-October/003216.html From matthias.baesken at sap.com Wed Jan 24 14:24:19 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 24 Jan 2018 14:24:19 +0000 Subject: RFR : 8196062 : Enable docker container related tests for linux ppc64le Message-ID: Hello, could you please review the following change : 8196062 : Enable docker container related tests for linux ppc64le . It adds docker container testing for linux ppc64 le (little endian) . A number of things had to be done : * Add a separate docker file test/hotspot/jtreg/runtime/containers/docker/Dockerfile-BasicTest-ppc64le for linux ppc64 le which uses Ubuntu ( the Oracle Linux 7.2 used for x86_64 seems not to be available for ppc64le ) * Fix parsing /proc/self/mountinfo and /proc/self/cgroup in src/hotspot/os/linux/osContainer_linux.cpp , it could not handle the format seen on SUSE LINUX 12.1 ppc64le (Host) and Ubuntu (Docker container) * Add a bit more logging Webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8196062/ Bug : https://bugs.openjdk.java.net/browse/JDK-8196062 After these adjustments I could run the runtime/containers/docker - jtreg tests successfully . Best regards, Matthias From martin.doerr at sap.com Wed Jan 24 14:28:05 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 24 Jan 2018 14:28:05 +0000 Subject: RFR : PPC64 : Need support for VSR spills in ppc.ad In-Reply-To: <5A6895BC.504@linux.vnet.ibm.com> References: <409187f381384294a5f5c1a38b66a840@sap.com> <5f8786f3d20649d697b99f4d663cd110@sap.com> <183dc8d4630d4bc7930fd17b757c054d@sap.com> <32adbeb39b9a4f74b48f04345e587b36@sap.com> <5A687E9B.6010903@linux.vnet.ibm.com> <5A688A7C.70705@linux.vnet.ibm.com> <5A6895BC.504@linux.vnet.ibm.com> Message-ID: <6993d16207264964b61256eb6798c9f0@sap.com> Hi Gustavo, we currently run a few nightly tests for jdk9, jdk10, jdk/jdk and jdk/hs on PPC64le. (And a lot more for SAP JVM.) The change is currently in jdk/hs where we have quite a few tests. It will probably get merged to jdk/jdk soon. For jdk8u, you will have to perform all testing on your own. Best regards, Martin -----Original Message----- From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] Sent: Mittwoch, 24. Januar 2018 15:19 To: Doerr, Martin ; Michihiro Horie Cc: Lindenmaier, Goetz ; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR : PPC64 : Need support for VSR spills in ppc.ad Hi Martin, On 01/24/2018 11:48 AM, Doerr, Martin wrote: > Hi Gustavo, > >> Do you suggest testing it in any particular way or should we wait >> OpenJDK 11 LTS goes GA so it begins to be tested more widely once it reaches >> out the distros (Ubuntu, SLES, and RHEL)? > We have nightly tests for jdk/hs so it gets tested automatically to some extent. More tests will run when we integrate it into SAP JVM. > So I think you don't necessarily have to wait until GA. I see. Thanks for sharing this information. > Backport changes should be tested better than running a few tests for a couple of days. Maybe you have nightly tests for 8u where you can test the backport for some time? I think this would be ideal. Otherwise, I'm a little concerned about possibly required shared fixes which were not backported to 8u. Unfortunately I dont't have a setup ready. I'll have to check if somebody working on AdoptOpenJDK.net / PowerPC initiative can help on that. Otherwise I need to setup something manually, but it would cover just POWER8 LE. I've already talked to Volker about it in the past but I never got the proper infrastructure resources to make it happen. Btw, I think SAP is not testing 8u for ppc64le [1], correct? But is jdk/hs tested on ppc64le or SAP does not perform nightly tests on LE at all? >> I think you can still be a (r)eviewer even not being an 8u (R)eviewer in case a >> backport does not apply cleanly to 8u and needs a new review on the hotspot ML? > I can answer questions or write an additional review. Thanks a lot. That would be very helpful. Best regards, Gustavo [1] http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2017-October/003216.html From gromero at linux.vnet.ibm.com Wed Jan 24 14:31:14 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 24 Jan 2018 12:31:14 -0200 Subject: RFR : PPC64 : Need support for VSR spills in ppc.ad In-Reply-To: <6993d16207264964b61256eb6798c9f0@sap.com> References: <409187f381384294a5f5c1a38b66a840@sap.com> <5f8786f3d20649d697b99f4d663cd110@sap.com> <183dc8d4630d4bc7930fd17b757c054d@sap.com> <32adbeb39b9a4f74b48f04345e587b36@sap.com> <5A687E9B.6010903@linux.vnet.ibm.com> <5A688A7C.70705@linux.vnet.ibm.com> <5A6895BC.504@linux.vnet.ibm.com> <6993d16207264964b61256eb6798c9f0@sap.com> Message-ID: <5A6898B2.5050102@linux.vnet.ibm.com> Hi Martin, On 01/24/2018 12:28 PM, Doerr, Martin wrote: > Hi Gustavo, > > we currently run a few nightly tests for jdk9, jdk10, jdk/jdk and jdk/hs on PPC64le. > (And a lot more for SAP JVM.) > The change is currently in jdk/hs where we have quite a few tests. It will probably get merged to jdk/jdk soon. > > For jdk8u, you will have to perform all testing on your own. Got it. Thanks! Best regards, Gustavo From bob.vandette at oracle.com Wed Jan 24 15:13:39 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 24 Jan 2018 10:13:39 -0500 Subject: RFR : 8196062 : Enable docker container related tests for linux ppc64le In-Reply-To: References: Message-ID: osContainer_linux.cpp: Can you add "return;" in each test for subsystem not found messages and remove these 3 lines OR move your tests for NULL & messages inside. The compiler can probably optimize this but I?d prefer more compact code. if (memory == NULL || cpuset == NULL || cpu == NULL || cpuacct == NULL) { 342 return; 343 } The other changes in osContainer_linux.cpp look ok. I forwarded your test changes to Misha, who wrote these. Since it?s likely that other platforms, such as aarch64, are going to run into the same problem, It would have been better to enable the tests based on the existence of an arch specific Dockerfile-BasicTest-{os.arch} rather than enabling specific arch?s in VPProps.java. This approach would reduce the number of changes significantly and allow support to be added with 1 new file. You wouldn?t need "String dockerFileName = Common.getDockerFileName();? in every test. Just make DockerTestUtils automatically add arch. Bob. > On Jan 24, 2018, at 9:24 AM, Baesken, Matthias wrote: > > Hello, could you please review the following change : 8196062 : Enable docker container related tests for linux ppc64le . > > It adds docker container testing for linux ppc64 le (little endian) . > > A number of things had to be done : > ? Add a separate docker file test/hotspot/jtreg/runtime/containers/docker/Dockerfile-BasicTest-ppc64le for linux ppc64 le which uses Ubuntu ( the Oracle Linux 7.2 used for x86_64 seems not to be available for ppc64le ) > ? Fix parsing /proc/self/mountinfo and /proc/self/cgroup in src/hotspot/os/linux/osContainer_linux.cpp , it could not handle the format seen on SUSE LINUX 12.1 ppc64le (Host) and Ubuntu (Docker container) > ? Add a bit more logging > > > Webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8196062/ > > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-8196062 > > > After these adjustments I could run the runtime/containers/docker - jtreg tests successfully . > > > Best regards, Matthias From matthias.baesken at sap.com Wed Jan 24 16:33:46 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 24 Jan 2018 16:33:46 +0000 Subject: RFR : 8196062 : Enable docker container related tests for linux ppc64le In-Reply-To: References: Message-ID: <6685ddb72d0349669c61657a98858690@sap.com> Thanks for your input ; > Can you add "return;" in each test for subsystem not found messages and > remove these 3 lines OR move your tests for NULL & messages inside. ... Sure I can do so. Regarding the test / platform handling improvement you propose - I would prefer doing this in a separate change (or when later enabling Docker detection + testing on our other additional platform zLinux / s390x which supports Docker as well ). Best Regards, Matthias > -----Original Message----- > From: Bob Vandette [mailto:bob.vandette at oracle.com] > Sent: Mittwoch, 24. Januar 2018 16:14 > To: Baesken, Matthias > Cc: hotspot-dev at openjdk.java.net; Lindenmaier, Goetz > ; Langer, Christoph > ; Doerr, Martin ; > Mikhailo Seledtsov > Subject: Re: RFR : 8196062 : Enable docker container related tests for linux > ppc64le > > osContainer_linux.cpp: > > Can you add "return;" in each test for subsystem not found messages and > remove these 3 lines OR move your tests for NULL & messages inside. The > compiler can > probably optimize this but I?d prefer more compact code. > > if (memory == NULL || cpuset == NULL || cpu == NULL || cpuacct == NULL) { > > 342 return; > 343 } > > > The other changes in osContainer_linux.cpp look ok. > > I forwarded your test changes to Misha, who wrote these. > > Since it?s likely that other platforms, such as aarch64, are going to run into the > same problem, > It would have been better to enable the tests based on the existence of an > arch specific > Dockerfile-BasicTest-{os.arch} rather than enabling specific arch?s in > VPProps.java. > This approach would reduce the number of changes significantly and allow > support to > be added with 1 new file. > > You wouldn?t need "String dockerFileName = > Common.getDockerFileName();? > in every test. Just make DockerTestUtils automatically add arch. > > Bob. > > > > > On Jan 24, 2018, at 9:24 AM, Baesken, Matthias > wrote: > > > > Hello, could you please review the following change : 8196062 : Enable > docker container related tests for linux ppc64le . > > > > It adds docker container testing for linux ppc64 le (little endian) . > > > > A number of things had to be done : > > ? Add a separate docker file > test/hotspot/jtreg/runtime/containers/docker/Dockerfile-BasicTest-ppc64le > for linux ppc64 le which uses Ubuntu ( the Oracle Linux 7.2 used for > x86_64 seems not to be available for ppc64le ) > > ? Fix parsing /proc/self/mountinfo and /proc/self/cgroup in > src/hotspot/os/linux/osContainer_linux.cpp , it could not handle the > format seen on SUSE LINUX 12.1 ppc64le (Host) and Ubuntu (Docker > container) > > ? Add a bit more logging > > > > > > Webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8196062/ > > > > > > Bug : > > > > https://bugs.openjdk.java.net/browse/JDK-8196062 > > > > > > After these adjustments I could run the runtime/containers/docker - > jtreg tests successfully . > > > > > > Best regards, Matthias From bob.vandette at oracle.com Wed Jan 24 17:01:41 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 24 Jan 2018 12:01:41 -0500 Subject: RFR : 8196062 : Enable docker container related tests for linux ppc64le In-Reply-To: <6685ddb72d0349669c61657a98858690@sap.com> References: <6685ddb72d0349669c61657a98858690@sap.com> Message-ID: > On Jan 24, 2018, at 11:33 AM, Baesken, Matthias wrote: > > Thanks for your input ; > >> Can you add "return;" in each test for subsystem not found messages and >> remove these 3 lines OR move your tests for NULL & messages inside. ... > > Sure I can do so. > > Regarding the test / platform handling improvement you propose - I would prefer doing this in a separate change (or when later enabling Docker detection + testing on our other additional platform zLinux / s390x > which supports Docker as well ). > I?m not an official reviewer so we?ll have to see what others think. Typically platform extensibility is taken into account after there?s more than 1 platform requiring support. Churning the sources even if they are tests, make maintaining and back-porting features more difficult. Bob. > > Best Regards, Matthias > > >> -----Original Message----- >> From: Bob Vandette [mailto:bob.vandette at oracle.com] >> Sent: Mittwoch, 24. Januar 2018 16:14 >> To: Baesken, Matthias >> Cc: hotspot-dev at openjdk.java.net; Lindenmaier, Goetz >> ; Langer, Christoph >> ; Doerr, Martin ; >> Mikhailo Seledtsov >> Subject: Re: RFR : 8196062 : Enable docker container related tests for linux >> ppc64le >> >> osContainer_linux.cpp: >> >> Can you add "return;" in each test for subsystem not found messages and >> remove these 3 lines OR move your tests for NULL & messages inside. The >> compiler can >> probably optimize this but I?d prefer more compact code. >> >> if (memory == NULL || cpuset == NULL || cpu == NULL || cpuacct == NULL) { >> >> 342 return; >> 343 } >> >> >> The other changes in osContainer_linux.cpp look ok. >> >> I forwarded your test changes to Misha, who wrote these. >> >> Since it?s likely that other platforms, such as aarch64, are going to run into the >> same problem, >> It would have been better to enable the tests based on the existence of an >> arch specific >> Dockerfile-BasicTest-{os.arch} rather than enabling specific arch?s in >> VPProps.java. >> This approach would reduce the number of changes significantly and allow >> support to >> be added with 1 new file. >> >> You wouldn?t need "String dockerFileName = >> Common.getDockerFileName();? >> in every test. Just make DockerTestUtils automatically add arch. >> >> Bob. >> >> >> >>> On Jan 24, 2018, at 9:24 AM, Baesken, Matthias >> wrote: >>> >>> Hello, could you please review the following change : 8196062 : Enable >> docker container related tests for linux ppc64le . >>> >>> It adds docker container testing for linux ppc64 le (little endian) . >>> >>> A number of things had to be done : >>> ? Add a separate docker file >> test/hotspot/jtreg/runtime/containers/docker/Dockerfile-BasicTest-ppc64le >> for linux ppc64 le which uses Ubuntu ( the Oracle Linux 7.2 used for >> x86_64 seems not to be available for ppc64le ) >>> ? Fix parsing /proc/self/mountinfo and /proc/self/cgroup in >> src/hotspot/os/linux/osContainer_linux.cpp , it could not handle the >> format seen on SUSE LINUX 12.1 ppc64le (Host) and Ubuntu (Docker >> container) >>> ? Add a bit more logging >>> >>> >>> Webrev : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8196062/ >>> >>> >>> Bug : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8196062 >>> >>> >>> After these adjustments I could run the runtime/containers/docker - >> jtreg tests successfully . >>> >>> >>> Best regards, Matthias > From stewartd.qdt at qualcommdatacenter.com Wed Jan 24 19:03:35 2018 From: stewartd.qdt at qualcommdatacenter.com (stewartd.qdt) Date: Wed, 24 Jan 2018 19:03:35 +0000 Subject: RFR: 8195621: JTReg failure in gc/g1/TestLargePageUseForAuxMemory.java In-Reply-To: <1516785399.2365.7.camel@oracle.com> References: <9db53780099e44d4a60ff8bf4944a657@NASANEXM01E.na.qualcomm.com> <72d9ad5d97c842608633c114f2c0b227@NASANEXM01E.na.qualcomm.com> <1516785399.2365.7.camel@oracle.com> Message-ID: Looking at the test, I think we can remove the -Xms flags from the test. In doing this, the test passes and it still seems to generate the right page sizes, which appears to be what the test was looking for. I have updated the webrev: http://cr.openjdk.java.net/~dstewart/8195621/webrev.01/ Please let me know if this is acceptable. Daniel -----Original Message----- From: Thomas Schatzl [mailto:thomas.schatzl at oracle.com] Sent: Wednesday, January 24, 2018 4:17 AM To: stewartd.qdt ; David Holmes ; hotspot-dev at openjdk.java.net Subject: Re: RFR: 8195621: JTReg failure in gc/g1/TestLargePageUseForAuxMemory.java Hi, On Fri, 2018-01-19 at 15:11 +0000, stewartd.qdt wrote: > Yes, I too wondered if the test should be changed to be a bit more > discerning in how it operates. > > I agree it would be great if a member of the GC team could chime in on > this issue. > > Daniel > > -----Original Message----- > > > This fix adds a function to WhiteBox to get the physical memory and > > then uses that to ensure we are not trying to allocate more than the > > physical amount of memory for our heap. Please let me know if this > > is a bad approach and I'll be happy to change as required. > > This seems an improvement though I would expect the test to fail long > before we get close to the amount of physical memory available. > Should the test be adjusting what it does based on the page size being > used, in conjunction with the amount of "physical memory"? > > Hopefully one of the GC folk will chime in. The test has obviously been written with existing test setups we have that are configured accordingly. I think for the test it may be sufficient to simply remove the -Xms flags in the VM invocations. Then the test would not try to actually commit all of the pages for e.g. the heap. That assumes it is no problem for these systems to only reserve 512G, and the systems themselves, if configured to use 1g huge pages is configured properly, i.e. there are actually have a few gb of memory available (unless -version does not even create objects on the java heap). Otherwise, instead of adding a new whitebox method, it might be preferable to get free/physical memory using standard Java means like OperatingSystemMXBean [1]. Thanks, Thomas [1] https://docs.oracle.com/javase/9/docs/api/com/sun/management/Operat ingSystemMXBean.html From mikhailo.seledtsov at oracle.com Wed Jan 24 19:09:12 2018 From: mikhailo.seledtsov at oracle.com (mikhailo) Date: Wed, 24 Jan 2018 11:09:12 -0800 Subject: RFR : 8196062 : Enable docker container related tests for linux ppc64le In-Reply-To: References: Message-ID: <3374db8c-6e7b-fe0b-6874-8289e9e369bc@oracle.com> Hi Matthias, ?? Please see my comments about the test changes inline. On 01/24/2018 07:13 AM, Bob Vandette wrote: > osContainer_linux.cpp: > > Can you add "return;" in each test for subsystem not found messages and > remove these 3 lines OR move your tests for NULL & messages inside. The compiler can > probably optimize this but I?d prefer more compact code. > > if (memory == NULL || cpuset == NULL || cpu == NULL || cpuacct == NULL) { > > 342 return; > 343 } > > > The other changes in osContainer_linux.cpp look ok. > > I forwarded your test changes to Misha, who wrote these. > > Since it?s likely that other platforms, such as aarch64, are going to run into the same problem, > It would have been better to enable the tests based on the existence of an arch specific > Dockerfile-BasicTest-{os.arch} rather than enabling specific arch?s in VPProps.java. > This approach would reduce the number of changes significantly and allow support to > be added with 1 new file. > > You wouldn?t need "String dockerFileName = Common.getDockerFileName();? > in every test. Just make DockerTestUtils automatically add arch. I like Bob's idea on handling platform-specific Dockerfiles. Perhaps, you could add code to DockerTestUtils.buildJdkDockerImage() that does the following or similar: ??? 1. Construct a name for platform-specific docker file: ?????????? String platformSpecificDockerfile = dockerfile + "-" + Platform.getOsArch(); ?????????? (Platform is jdk.test.lib.Platform) ??? 2. Check if platformSpecificDockerfile file exists in the test source directory ????????? File.exists(Paths.get(Utils.TEST_SRC, platformSpecificDockerFile) ????????? If it does, then use it. Otherwise continue using the default/original dockerfile name. I think this will considerably simplify your change, as well as make it easy to extend support to other platforms/configurations in the future. Let us know what you think of this approach ? Once your change gets (R)eviewed and approved, I can sponsor the push. Thank you, Misha > > Bob. > > > >> On Jan 24, 2018, at 9:24 AM, Baesken, Matthias wrote: >> >> Hello, could you please review the following change : 8196062 : Enable docker container related tests for linux ppc64le . >> >> It adds docker container testing for linux ppc64 le (little endian) . >> >> A number of things had to be done : >> ? Add a separate docker file test/hotspot/jtreg/runtime/containers/docker/Dockerfile-BasicTest-ppc64le for linux ppc64 le which uses Ubuntu ( the Oracle Linux 7.2 used for x86_64 seems not to be available for ppc64le ) >> ? Fix parsing /proc/self/mountinfo and /proc/self/cgroup in src/hotspot/os/linux/osContainer_linux.cpp , it could not handle the format seen on SUSE LINUX 12.1 ppc64le (Host) and Ubuntu (Docker container) >> ? Add a bit more logging >> >> >> Webrev : >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8196062/ >> >> >> Bug : >> >> https://bugs.openjdk.java.net/browse/JDK-8196062 >> >> >> After these adjustments I could run the runtime/containers/docker - jtreg tests successfully . >> >> >> Best regards, Matthias From coleen.phillimore at oracle.com Wed Jan 24 19:54:21 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 24 Jan 2018 14:54:21 -0500 Subject: RFR: 8194898: Move OopStorage inline definitions to an .inline.hpp In-Reply-To: References: Message-ID: This looks very nice! There's a minor inconsistency with the hotspot code, most nonstatic data members are declared at the beginning of the class: 160 OopStorage* _storage; 161 void* volatile _next_block; 162 bool _concurrent; These should move up to line 144.?? Some people like the member names lined up too. :) I don't need to see this trivial change. Thanks, Coleen On 1/19/18 2:59 PM, Kim Barrett wrote: > Please review this code reorg for the recently added OopStorage. > During the review of OopStorage (JDK-8194312) it was requested that > the inline member function definitions and inner class definitions be > moved to .inline.hpp file(s). > > The changes are: > > (1) ParState and BasicParState are moved to the new file > oopStorageParState.inline.hpp. Also moved AlwaysTrueFn into BasicParState, > which is the only user. > > (2) Moved the inline member function to the new file oopStorage.inline.hpp, > along with most of the inner class definitions. The complete definitions of > BlockEntry and BlockList remain within the OopStorage definition, as they are > needed for member types. > > (3) Added inline qualifiers to public OopStorage function declarations > when the function definition is in an inline header. This may produce > better error messages by some compilers when the inline header is > needed but not included. > > Note: This change will likely have a simple merge conflict (unrelated > nearby changes to oopStorage.hpp) with the fix for JDK-8195691. Since > I'm sponsoring the latter, I'll deal with that when the time comes, > for whichever order these changes end up being pushed. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8194898 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8194898/open.00/ > > Testing: > hs-tier1,2,3 > From kim.barrett at oracle.com Wed Jan 24 19:52:57 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 24 Jan 2018 14:52:57 -0500 Subject: RFR: 8195979: [Graal] crash in src/hotspot/share/runtime/mutex.cpp:1341 when Graal JIT is used Message-ID: Please review this workaround for a lock rank ordering issue. When using Graal, JNI references are released while holding the Patching_lock (a rank=special lock). Before the reimplementation of JNI global and weak global handles using OopStorage (JDK-8194312), releasing such references was accomplished without any locking. However, OopStorage::release sometimes locks its allocation mutex. This change led to the reported lock rank order problem for Graal. As a temporary workaround we're reducing the ranks of the JNI oopstorage mutexes, making them more special than "special", so they can be locked while holding the Patching_lock. A better solution (JDK-8196083) is being developed, but may take a little time. In the interest of unblocking Graal testing, the simple rank reduction is being proposed, even though it's ugly. CR: https://bugs.openjdk.java.net/browse/JDK-8195979 Webrev: http://cr.openjdk.java.net/~kbarrett/8195979/open.00/ Testing: Mach5 hs-tier{1-5}, jdk-tier{1-3} Local testing of Ekaterina's reproducer in CR. From erik.osterlund at oracle.com Wed Jan 24 21:25:48 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 24 Jan 2018 22:25:48 +0100 Subject: RFR: 8195979: [Graal] crash in src/hotspot/share/runtime/mutex.cpp:1341 when Graal JIT is used In-Reply-To: References: Message-ID: Hi Kim, I guess the ranks you use now are really equivalent to the 'access' ranks, that I introduced earlier, and are currently used by G1 barrier locks. I don't mind though if you call them that or not, and understand you just want a quick fix for this. Looks good. Thanks, /Erik On 2018-01-24 20:52, Kim Barrett wrote: > Please review this workaround for a lock rank ordering issue. When > using Graal, JNI references are released while holding the > Patching_lock (a rank=special lock). > > Before the reimplementation of JNI global and weak global handles > using OopStorage (JDK-8194312), releasing such references was > accomplished without any locking. However, OopStorage::release > sometimes locks its allocation mutex. This change led to the reported > lock rank order problem for Graal. > > As a temporary workaround we're reducing the ranks of the JNI > oopstorage mutexes, making them more special than "special", so they > can be locked while holding the Patching_lock. A better solution > (JDK-8196083) is being developed, but may take a little time. In the > interest of unblocking Graal testing, the simple rank reduction is > being proposed, even though it's ugly. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8195979 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8195979/open.00/ > > Testing: > Mach5 hs-tier{1-5}, jdk-tier{1-3} > Local testing of Ekaterina's reproducer in CR. > From karen.kinnear at oracle.com Wed Jan 24 21:22:22 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 24 Jan 2018 16:22:22 -0500 Subject: RFR: 8195979: [Graal] crash in src/hotspot/share/runtime/mutex.cpp:1341 when Graal JIT is used In-Reply-To: References: Message-ID: <83AE423C-5E71-43B9-8E5A-21A0964A0FB5@oracle.com> Code looks good for temporary workaround - thank you for putting the comment in that this is temporary. thanks, Karen > On Jan 24, 2018, at 2:52 PM, Kim Barrett wrote: > > Please review this workaround for a lock rank ordering issue. When > using Graal, JNI references are released while holding the > Patching_lock (a rank=special lock). > > Before the reimplementation of JNI global and weak global handles > using OopStorage (JDK-8194312), releasing such references was > accomplished without any locking. However, OopStorage::release > sometimes locks its allocation mutex. This change led to the reported > lock rank order problem for Graal. > > As a temporary workaround we're reducing the ranks of the JNI > oopstorage mutexes, making them more special than "special", so they > can be locked while holding the Patching_lock. A better solution > (JDK-8196083) is being developed, but may take a little time. In the > interest of unblocking Graal testing, the simple rank reduction is > being proposed, even though it's ugly. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8195979 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8195979/open.00/ > > Testing: > Mach5 hs-tier{1-5}, jdk-tier{1-3} > Local testing of Ekaterina's reproducer in CR. > From coleen.phillimore at oracle.com Wed Jan 24 21:29:22 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 24 Jan 2018 16:29:22 -0500 Subject: RFR: 8195979: [Graal] crash in src/hotspot/share/runtime/mutex.cpp:1341 when Graal JIT is used In-Reply-To: References: Message-ID: <69230d39-6647-c51d-bb99-d380bc9dd209@oracle.com> Yeah it's ugly.? But it's good for unblocking testing. thanks, Coleen On 1/24/18 2:52 PM, Kim Barrett wrote: > Please review this workaround for a lock rank ordering issue. When > using Graal, JNI references are released while holding the > Patching_lock (a rank=special lock). > > Before the reimplementation of JNI global and weak global handles > using OopStorage (JDK-8194312), releasing such references was > accomplished without any locking. However, OopStorage::release > sometimes locks its allocation mutex. This change led to the reported > lock rank order problem for Graal. > > As a temporary workaround we're reducing the ranks of the JNI > oopstorage mutexes, making them more special than "special", so they > can be locked while holding the Patching_lock. A better solution > (JDK-8196083) is being developed, but may take a little time. In the > interest of unblocking Graal testing, the simple rank reduction is > being proposed, even though it's ugly. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8195979 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8195979/open.00/ > > Testing: > Mach5 hs-tier{1-5}, jdk-tier{1-3} > Local testing of Ekaterina's reproducer in CR. > From kim.barrett at oracle.com Wed Jan 24 21:32:34 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 24 Jan 2018 16:32:34 -0500 Subject: RFR: 8195979: [Graal] crash in src/hotspot/share/runtime/mutex.cpp:1341 when Graal JIT is used In-Reply-To: <83AE423C-5E71-43B9-8E5A-21A0964A0FB5@oracle.com> References: <83AE423C-5E71-43B9-8E5A-21A0964A0FB5@oracle.com> Message-ID: <65BCA71D-5C40-4613-B4CB-029BDA6DD992@oracle.com> > On Jan 24, 2018, at 4:22 PM, Karen Kinnear wrote: > > Code looks good for temporary workaround - thank you for putting the comment > in that this is temporary. Thanks. > thanks, > Karen > > >> On Jan 24, 2018, at 2:52 PM, Kim Barrett wrote: >> >> Please review this workaround for a lock rank ordering issue. When >> using Graal, JNI references are released while holding the >> Patching_lock (a rank=special lock). >> >> Before the reimplementation of JNI global and weak global handles >> using OopStorage (JDK-8194312), releasing such references was >> accomplished without any locking. However, OopStorage::release >> sometimes locks its allocation mutex. This change led to the reported >> lock rank order problem for Graal. >> >> As a temporary workaround we're reducing the ranks of the JNI >> oopstorage mutexes, making them more special than "special", so they >> can be locked while holding the Patching_lock. A better solution >> (JDK-8196083) is being developed, but may take a little time. In the >> interest of unblocking Graal testing, the simple rank reduction is >> being proposed, even though it's ugly. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8195979 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8195979/open.00/ >> >> Testing: >> Mach5 hs-tier{1-5}, jdk-tier{1-3} >> Local testing of Ekaterina's reproducer in CR. From kim.barrett at oracle.com Wed Jan 24 21:32:53 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 24 Jan 2018 16:32:53 -0500 Subject: RFR: 8195979: [Graal] crash in src/hotspot/share/runtime/mutex.cpp:1341 when Graal JIT is used In-Reply-To: <69230d39-6647-c51d-bb99-d380bc9dd209@oracle.com> References: <69230d39-6647-c51d-bb99-d380bc9dd209@oracle.com> Message-ID: > On Jan 24, 2018, at 4:29 PM, coleen.phillimore at oracle.com wrote: > > > Yeah it's ugly. But it's good for unblocking testing. Thanks. > thanks, > Coleen > > On 1/24/18 2:52 PM, Kim Barrett wrote: >> Please review this workaround for a lock rank ordering issue. When >> using Graal, JNI references are released while holding the >> Patching_lock (a rank=special lock). >> >> Before the reimplementation of JNI global and weak global handles >> using OopStorage (JDK-8194312), releasing such references was >> accomplished without any locking. However, OopStorage::release >> sometimes locks its allocation mutex. This change led to the reported >> lock rank order problem for Graal. >> >> As a temporary workaround we're reducing the ranks of the JNI >> oopstorage mutexes, making them more special than "special", so they >> can be locked while holding the Patching_lock. A better solution >> (JDK-8196083) is being developed, but may take a little time. In the >> interest of unblocking Graal testing, the simple rank reduction is >> being proposed, even though it's ugly. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8195979 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8195979/open.00/ >> >> Testing: >> Mach5 hs-tier{1-5}, jdk-tier{1-3} >> Local testing of Ekaterina's reproducer in CR. From kim.barrett at oracle.com Wed Jan 24 21:32:15 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 24 Jan 2018 16:32:15 -0500 Subject: RFR: 8195979: [Graal] crash in src/hotspot/share/runtime/mutex.cpp:1341 when Graal JIT is used In-Reply-To: References: Message-ID: <71EBC47A-7F96-4BFB-874D-A15C1E6E2489@oracle.com> > On Jan 24, 2018, at 4:25 PM, Erik ?sterlund wrote: > > Hi Kim, > > I guess the ranks you use now are really equivalent to the 'access' ranks, that I introduced earlier, and are currently used by G1 barrier locks. > I don't mind though if you call them that or not, and understand you just want a quick fix for this. I intentionally didn?t name them relative to the ?access" ranks. The desired ranks need to be more special than ?special?, and are semantically unrelated to the ?access" ranks. That they are numerically equivalent to the ?access? ranks is coincidental. > Looks good. Thanks. > Thanks, > /Erik > > > On 2018-01-24 20:52, Kim Barrett wrote: >> Please review this workaround for a lock rank ordering issue. When >> using Graal, JNI references are released while holding the >> Patching_lock (a rank=special lock). >> >> Before the reimplementation of JNI global and weak global handles >> using OopStorage (JDK-8194312), releasing such references was >> accomplished without any locking. However, OopStorage::release >> sometimes locks its allocation mutex. This change led to the reported >> lock rank order problem for Graal. >> >> As a temporary workaround we're reducing the ranks of the JNI >> oopstorage mutexes, making them more special than "special", so they >> can be locked while holding the Patching_lock. A better solution >> (JDK-8196083) is being developed, but may take a little time. In the >> interest of unblocking Graal testing, the simple rank reduction is >> being proposed, even though it's ugly. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8195979 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8195979/open.00/ >> >> Testing: >> Mach5 hs-tier{1-5}, jdk-tier{1-3} >> Local testing of Ekaterina's reproducer in CR. From kim.barrett at oracle.com Wed Jan 24 22:54:33 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 24 Jan 2018 17:54:33 -0500 Subject: RFR: 8195979: [Graal] crash in src/hotspot/share/runtime/mutex.cpp:1341 when Graal JIT is used In-Reply-To: References: Message-ID: > On Jan 24, 2018, at 2:52 PM, Kim Barrett wrote: > > Please review this workaround for a lock rank ordering issue. When > using Graal, JNI references are released while holding the > Patching_lock (a rank=special lock). > > [?] > > CR: > https://bugs.openjdk.java.net/browse/JDK-8195979 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8195979/open.00/ > > Testing: > Mach5 hs-tier{1-5}, jdk-tier{1-3} > Local testing of Ekaterina's reproducer in CR. The change is small, has been run through lots of tests, and I have several reviewers (and Reviewers). Given those positives, and that the bug is a P2 integration blocker and blocking some other testing, I'm going to ignore the 24 hour rule and go ahead and push. From david.holmes at oracle.com Thu Jan 25 01:15:36 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Jan 2018 11:15:36 +1000 Subject: RFR : 8195857 : Posix platforms : move os::is_headless_jre check coding to os::Posix and remove test for libmawt In-Reply-To: <0E2C7BA4-689D-4B6A-AC72-1ACE02DCD8F1@oracle.com> References: <83c352c941374468bd811f611dfc2aff@sap.com> <292752fd-8152-216d-c09c-2236485c4a58@oracle.com> <08f18f12f480493e9b00cfdcc99ef1bc@sap.com> <042CA641-9057-444D-BFA9-CB4B2737ADF4@oracle.com> <9b649a09-29ea-c8e6-1ddb-7a22b5a54e57@oracle.com> <0E2C7BA4-689D-4B6A-AC72-1ACE02DCD8F1@oracle.com> Message-ID: On 24/01/2018 11:16 PM, Bob Vandette wrote: >> On Jan 23, 2018, at 5:50 PM, David Holmes wrote: >> >> Hi Bob, >> >> On 24/01/2018 1:25 AM, Bob Vandette wrote: >>> If we are going to preserve this functionality and make alterations, I suggest that >>> we try to move this into the desktop module and remove it from the hotspot sources. >>> Other than finding an appropriate path at startup to initialize the property, there is >>> no reason why this check can?t be written in Java. This functionality has nothing to >>> do with Hotspot or VMs. (I should have probably done this when I first added this check). >> >> Well we hacked it into the SE Embedded builds so we knew what lib was missing. >> >> I don't think what you suggest really makes sense in a modular world because I don't think we expect to have java.desktop but not some of its native parts - so there would be no trigger to force into headless mode. More likely there is simply no java.desktop module at all. > The automatic setting of java.awt.headless has nothing to do with compact profiles. This support was available in JDK 7 before profiles even existed. This > automatic headless detection was added in order to allow Java to be ported to platforms that do not have a native windowing toolkit available. This was > used in embedded to also reduce the size of the binary by removing this big library. A configuration that contains java.desktop can absolutely be supported > and the JCK can be passed without this native library. > > This Java property is only referenced by the desktop module. This is why I suggested that this functionality be moved out of the hotspot VM. Yes we forced the AWT into headless mode if there was no native graphics library support available. For some of those platforms we even did this at build time, not via a runtime check. For SE Embedded support we would strip the library out at image build time, and so the runtime check would force AWT into headless mode. For compact profiles there is no AWT at all, and no native library in the built image so the runtime check still (vacuously) sets the property for headless mode. If you have the java.desktop module, then you have everything - there is no fragmentation of that module that I am aware of, that would allow you strip out the library that triggers os::is_headless_jre() or some other check that forces the AWT into headless mode. If you have java.desktop and you want headless mode then you have to ask for it explicitly. Bottom line: os::is_headless_jre() is dead code as far as I can see. Separately I'll file a bug to remove the compact profile builds. David ----- > Bob. > > >> >> That said I was reminded that this is also used by the Compact Profiles that were added in Java 8, but for which support was removed as from Java 9 (and modules). However the build logic is still present, and they still use this functionality. I think we can remove compact profiles completely in JDK 11, but that's a seperate tasks. >> >> Meanwhile if we kill off the os::is_headless_jre() logic then the compact profiles would not default to headless mode even though they can't run headful (due to the missing native library as well as other Java APIs). But the only impact I can see there would be for running tests - and we're not testing compact profiles. So ... I still think this can be removed, but want to do a couple more checks. >> >> Cheers, >> David >> >>> Bob. >>>> On Jan 23, 2018, at 5:57 AM, Baesken, Matthias wrote: >>>> >>>> Hi David, thanks for the comments. >>>> >>>>> I'd need to do some checking but I think this may all be effectively >>>>> dead code. >>>> >>>> Please do the checking, maybe we can completely remove it. >>>> >>>> Best Regards, Matthias >>>> >>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Dienstag, 23. Januar 2018 11:30 >>>>> To: Baesken, Matthias ; 'hotspot- >>>>> dev at openjdk.java.net' >>>>> Subject: Re: RFR : 8195857 : Posix platforms : move os::is_headless_jre check >>>>> coding to os::Posix and remove test for libmawt >>>>> >>>>> Hi Matthias, >>>>> >>>>> Some preliminary comments ... >>>>> >>>>> On 23/01/2018 6:24 PM, Baesken, Matthias wrote: >>>>>> Hello, I noticed that os::is_headless_jre() still checks on the Posix >>>>> platforms for libmawt which is not present any longer. >>>>> >>>>> I wonder why that comment was put in but the code not changed ... >>>>> >>>>>> Additionally the os::is_headless_jre() function could be put in a central >>>>> place at os_posix to avoid code duplication. >>>>> >>>>> I think you could simplify further and just define in os.cpp with three >>>>> cases: windows, OS X, posix. I normally wouldn't suggest that but given >>>>> Windows and OS X are always false, it's quite trivial. >>>>> >>>>> That said this may simplify even further because I don't know if the >>>>> concept of a headless JRE is even meaningful anymore. This what put in >>>>> place in 2010 to support Java SE Embedded. We had a special build >>>>> process that would remove the library from the JRE image, then a runtime >>>>> check os::is_headless_jre() run during argument processing, that if >>>>> true, caused the java.awt.headless property to be set to true (unless >>>>> already set). I don't think we can even build a "headless JRE" any more. >>>>> >>>>> I'd need to do some checking but I think this may all be effectively >>>>> dead code. >>>>> >>>>> Thanks, >>>>> David >>>>> ------- >>>>> >>>>>> Could you please review my change . >>>>>> >>>>>> Webrev : >>>>>> >>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8195857/ >>>>>> >>>>>> Bug : >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8195857 >>>>>> >>>>>> >>>>>> >>>>>> Thanks, Matthias >>>>>> > From matthias.baesken at sap.com Thu Jan 25 06:36:21 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 25 Jan 2018 06:36:21 +0000 Subject: RFR : 8195857 : Posix platforms : move os::is_headless_jre check coding to os::Posix and remove test for libmawt In-Reply-To: References: <83c352c941374468bd811f611dfc2aff@sap.com> <292752fd-8152-216d-c09c-2236485c4a58@oracle.com> <08f18f12f480493e9b00cfdcc99ef1bc@sap.com> <042CA641-9057-444D-BFA9-CB4B2737ADF4@oracle.com> <9b649a09-29ea-c8e6-1ddb-7a22b5a54e57@oracle.com> <0E2C7BA4-689D-4B6A-AC72-1ACE02DCD8F1@oracle.com> Message-ID: <56671fcf61cb45f8a5f1c2b4607c5b03@sap.com> > > Bottom line: os::is_headless_jre() is dead code as far as I can see. > Hi David, so do you suggest I prepare a new webrev where os::is_headless_jre() is completely removed ? What about the code block in hotspot/share/runtime/arguments.cpp , do you think this can be completely removed as well ? 3495 if (os::is_headless_jre()) { 3496 const char* headless = Arguments::get_property("java.awt.headless"); 3497 if (headless == NULL) { 3498 const char *headless_env = ::getenv("JAVA_AWT_HEADLESS"); 3499 if (headless_env == NULL) { 3500 if (!add_property("java.awt.headless=true")) { 3501 return JNI_ENOMEM; 3502 } 3503 } else { 3504 char buffer[256]; 3505 jio_snprintf(buffer, sizeof(buffer), "java.awt.headless=%s", headless_env); 3506 if (!add_property(buffer)) { 3507 return JNI_ENOMEM; 3508 } 3509 } 3510 } 3511 } Best regards, Matthias > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 25. Januar 2018 02:16 > To: Bob Vandette > Cc: Baesken, Matthias ; hotspot- > dev at openjdk.java.net > Subject: Re: RFR : 8195857 : Posix platforms : move os::is_headless_jre check > coding to os::Posix and remove test for libmawt > > On 24/01/2018 11:16 PM, Bob Vandette wrote: > >> On Jan 23, 2018, at 5:50 PM, David Holmes > wrote: > >> > >> Hi Bob, > >> > >> On 24/01/2018 1:25 AM, Bob Vandette wrote: > >>> If we are going to preserve this functionality and make alterations, I > suggest that > >>> we try to move this into the desktop module and remove it from the > hotspot sources. > >>> Other than finding an appropriate path at startup to initialize the > property, there is > >>> no reason why this check can?t be written in Java. This functionality has > nothing to > >>> do with Hotspot or VMs. (I should have probably done this when I first > added this check). > >> > >> Well we hacked it into the SE Embedded builds so we knew what lib was > missing. > >> > >> I don't think what you suggest really makes sense in a modular world > because I don't think we expect to have java.desktop but not some of its > native parts - so there would be no trigger to force into headless mode. > More likely there is simply no java.desktop module at all. > > The automatic setting of java.awt.headless has nothing to do with compact > profiles. This support was available in JDK 7 before profiles even existed. > This > > automatic headless detection was added in order to allow Java to be > ported to platforms that do not have a native windowing toolkit available. > This was > > used in embedded to also reduce the size of the binary by removing this > big library. A configuration that contains java.desktop can absolutely be > supported > > and the JCK can be passed without this native library. > > > > This Java property is only referenced by the desktop module. This is why I > suggested that this functionality be moved out of the hotspot VM. > > Yes we forced the AWT into headless mode if there was no native graphics > library support available. For some of those platforms we even did this > at build time, not via a runtime check. For SE Embedded support we would > strip the library out at image build time, and so the runtime check > would force AWT into headless mode. For compact profiles there is no AWT > at all, and no native library in the built image so the runtime check > still (vacuously) sets the property for headless mode. > > If you have the java.desktop module, then you have everything - there is > no fragmentation of that module that I am aware of, that would allow you > strip out the library that triggers os::is_headless_jre() or some other > check that forces the AWT into headless mode. If you have java.desktop > and you want headless mode then you have to ask for it explicitly. > > Bottom line: os::is_headless_jre() is dead code as far as I can see. > > Separately I'll file a bug to remove the compact profile builds. > > David > ----- > > > Bob. > > > > > >> > >> That said I was reminded that this is also used by the Compact Profiles > that were added in Java 8, but for which support was removed as from Java 9 > (and modules). However the build logic is still present, and they still use this > functionality. I think we can remove compact profiles completely in JDK 11, > but that's a seperate tasks. > >> > >> Meanwhile if we kill off the os::is_headless_jre() logic then the compact > profiles would not default to headless mode even though they can't run > headful (due to the missing native library as well as other Java APIs). But the > only impact I can see there would be for running tests - and we're not testing > compact profiles. So ... I still think this can be removed, but want to do a > couple more checks. > >> > >> Cheers, > >> David > >> > >>> Bob. > >>>> On Jan 23, 2018, at 5:57 AM, Baesken, Matthias > wrote: > >>>> > >>>> Hi David, thanks for the comments. > >>>> > >>>>> I'd need to do some checking but I think this may all be effectively > >>>>> dead code. > >>>> > >>>> Please do the checking, maybe we can completely remove it. > >>>> > >>>> Best Regards, Matthias > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>> Sent: Dienstag, 23. Januar 2018 11:30 > >>>>> To: Baesken, Matthias ; 'hotspot- > >>>>> dev at openjdk.java.net' > >>>>> Subject: Re: RFR : 8195857 : Posix platforms : move > os::is_headless_jre check > >>>>> coding to os::Posix and remove test for libmawt > >>>>> > >>>>> Hi Matthias, > >>>>> > >>>>> Some preliminary comments ... > >>>>> > >>>>> On 23/01/2018 6:24 PM, Baesken, Matthias wrote: > >>>>>> Hello, I noticed that os::is_headless_jre() still checks on the Posix > >>>>> platforms for libmawt which is not present any longer. > >>>>> > >>>>> I wonder why that comment was put in but the code not changed ... > >>>>> > >>>>>> Additionally the os::is_headless_jre() function could be put in a > central > >>>>> place at os_posix to avoid code duplication. > >>>>> > >>>>> I think you could simplify further and just define in os.cpp with three > >>>>> cases: windows, OS X, posix. I normally wouldn't suggest that but > given > >>>>> Windows and OS X are always false, it's quite trivial. > >>>>> > >>>>> That said this may simplify even further because I don't know if the > >>>>> concept of a headless JRE is even meaningful anymore. This what put > in > >>>>> place in 2010 to support Java SE Embedded. We had a special build > >>>>> process that would remove the library from the JRE image, then a > runtime > >>>>> check os::is_headless_jre() run during argument processing, that if > >>>>> true, caused the java.awt.headless property to be set to true (unless > >>>>> already set). I don't think we can even build a "headless JRE" any > more. > >>>>> > >>>>> I'd need to do some checking but I think this may all be effectively > >>>>> dead code. > >>>>> > >>>>> Thanks, > >>>>> David > >>>>> ------- > >>>>> > >>>>>> Could you please review my change . > >>>>>> > >>>>>> Webrev : > >>>>>> > >>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8195857/ > >>>>>> > >>>>>> Bug : > >>>>>> > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8195857 > >>>>>> > >>>>>> > >>>>>> > >>>>>> Thanks, Matthias > >>>>>> > > From david.holmes at oracle.com Thu Jan 25 06:39:28 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Jan 2018 16:39:28 +1000 Subject: RFR : 8195857 : Posix platforms : move os::is_headless_jre check coding to os::Posix and remove test for libmawt In-Reply-To: <56671fcf61cb45f8a5f1c2b4607c5b03@sap.com> References: <83c352c941374468bd811f611dfc2aff@sap.com> <292752fd-8152-216d-c09c-2236485c4a58@oracle.com> <08f18f12f480493e9b00cfdcc99ef1bc@sap.com> <042CA641-9057-444D-BFA9-CB4B2737ADF4@oracle.com> <9b649a09-29ea-c8e6-1ddb-7a22b5a54e57@oracle.com> <0E2C7BA4-689D-4B6A-AC72-1ACE02DCD8F1@oracle.com> <56671fcf61cb45f8a5f1c2b4607c5b03@sap.com> Message-ID: Hi Matthias, On 25/01/2018 4:36 PM, Baesken, Matthias wrote: >> >> Bottom line: os::is_headless_jre() is dead code as far as I can see. >> > > Hi David, so do you suggest I prepare a new webrev where os::is_headless_jre() is completely removed ? > > What about the code block in hotspot/share/runtime/arguments.cpp , do you think this can be completely removed as well ? Yes - everything pertaining to os::is_headless_jre() can be removed. Thanks, David ----- > > 3495 if (os::is_headless_jre()) { > 3496 const char* headless = Arguments::get_property("java.awt.headless"); > 3497 if (headless == NULL) { > 3498 const char *headless_env = ::getenv("JAVA_AWT_HEADLESS"); > 3499 if (headless_env == NULL) { > 3500 if (!add_property("java.awt.headless=true")) { > 3501 return JNI_ENOMEM; > 3502 } > 3503 } else { > 3504 char buffer[256]; > 3505 jio_snprintf(buffer, sizeof(buffer), "java.awt.headless=%s", headless_env); > 3506 if (!add_property(buffer)) { > 3507 return JNI_ENOMEM; > 3508 } > 3509 } > 3510 } > 3511 } > > Best regards, Matthias > > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Donnerstag, 25. Januar 2018 02:16 >> To: Bob Vandette >> Cc: Baesken, Matthias ; hotspot- >> dev at openjdk.java.net >> Subject: Re: RFR : 8195857 : Posix platforms : move os::is_headless_jre check >> coding to os::Posix and remove test for libmawt >> >> On 24/01/2018 11:16 PM, Bob Vandette wrote: >>>> On Jan 23, 2018, at 5:50 PM, David Holmes >> wrote: >>>> >>>> Hi Bob, >>>> >>>> On 24/01/2018 1:25 AM, Bob Vandette wrote: >>>>> If we are going to preserve this functionality and make alterations, I >> suggest that >>>>> we try to move this into the desktop module and remove it from the >> hotspot sources. >>>>> Other than finding an appropriate path at startup to initialize the >> property, there is >>>>> no reason why this check can?t be written in Java. This functionality has >> nothing to >>>>> do with Hotspot or VMs. (I should have probably done this when I first >> added this check). >>>> >>>> Well we hacked it into the SE Embedded builds so we knew what lib was >> missing. >>>> >>>> I don't think what you suggest really makes sense in a modular world >> because I don't think we expect to have java.desktop but not some of its >> native parts - so there would be no trigger to force into headless mode. >> More likely there is simply no java.desktop module at all. >>> The automatic setting of java.awt.headless has nothing to do with compact >> profiles. This support was available in JDK 7 before profiles even existed. >> This >>> automatic headless detection was added in order to allow Java to be >> ported to platforms that do not have a native windowing toolkit available. >> This was >>> used in embedded to also reduce the size of the binary by removing this >> big library. A configuration that contains java.desktop can absolutely be >> supported >>> and the JCK can be passed without this native library. >>> >>> This Java property is only referenced by the desktop module. This is why I >> suggested that this functionality be moved out of the hotspot VM. >> >> Yes we forced the AWT into headless mode if there was no native graphics >> library support available. For some of those platforms we even did this >> at build time, not via a runtime check. For SE Embedded support we would >> strip the library out at image build time, and so the runtime check >> would force AWT into headless mode. For compact profiles there is no AWT >> at all, and no native library in the built image so the runtime check >> still (vacuously) sets the property for headless mode. >> >> If you have the java.desktop module, then you have everything - there is >> no fragmentation of that module that I am aware of, that would allow you >> strip out the library that triggers os::is_headless_jre() or some other >> check that forces the AWT into headless mode. If you have java.desktop >> and you want headless mode then you have to ask for it explicitly. >> >> Bottom line: os::is_headless_jre() is dead code as far as I can see. >> >> Separately I'll file a bug to remove the compact profile builds. >> >> David >> ----- >> >>> Bob. >>> >>> >>>> >>>> That said I was reminded that this is also used by the Compact Profiles >> that were added in Java 8, but for which support was removed as from Java 9 >> (and modules). However the build logic is still present, and they still use this >> functionality. I think we can remove compact profiles completely in JDK 11, >> but that's a seperate tasks. >>>> >>>> Meanwhile if we kill off the os::is_headless_jre() logic then the compact >> profiles would not default to headless mode even though they can't run >> headful (due to the missing native library as well as other Java APIs). But the >> only impact I can see there would be for running tests - and we're not testing >> compact profiles. So ... I still think this can be removed, but want to do a >> couple more checks. >>>> >>>> Cheers, >>>> David >>>> >>>>> Bob. >>>>>> On Jan 23, 2018, at 5:57 AM, Baesken, Matthias >> wrote: >>>>>> >>>>>> Hi David, thanks for the comments. >>>>>> >>>>>>> I'd need to do some checking but I think this may all be effectively >>>>>>> dead code. >>>>>> >>>>>> Please do the checking, maybe we can completely remove it. >>>>>> >>>>>> Best Regards, Matthias >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Dienstag, 23. Januar 2018 11:30 >>>>>>> To: Baesken, Matthias ; 'hotspot- >>>>>>> dev at openjdk.java.net' >>>>>>> Subject: Re: RFR : 8195857 : Posix platforms : move >> os::is_headless_jre check >>>>>>> coding to os::Posix and remove test for libmawt >>>>>>> >>>>>>> Hi Matthias, >>>>>>> >>>>>>> Some preliminary comments ... >>>>>>> >>>>>>> On 23/01/2018 6:24 PM, Baesken, Matthias wrote: >>>>>>>> Hello, I noticed that os::is_headless_jre() still checks on the Posix >>>>>>> platforms for libmawt which is not present any longer. >>>>>>> >>>>>>> I wonder why that comment was put in but the code not changed ... >>>>>>> >>>>>>>> Additionally the os::is_headless_jre() function could be put in a >> central >>>>>>> place at os_posix to avoid code duplication. >>>>>>> >>>>>>> I think you could simplify further and just define in os.cpp with three >>>>>>> cases: windows, OS X, posix. I normally wouldn't suggest that but >> given >>>>>>> Windows and OS X are always false, it's quite trivial. >>>>>>> >>>>>>> That said this may simplify even further because I don't know if the >>>>>>> concept of a headless JRE is even meaningful anymore. This what put >> in >>>>>>> place in 2010 to support Java SE Embedded. We had a special build >>>>>>> process that would remove the library from the JRE image, then a >> runtime >>>>>>> check os::is_headless_jre() run during argument processing, that if >>>>>>> true, caused the java.awt.headless property to be set to true (unless >>>>>>> already set). I don't think we can even build a "headless JRE" any >> more. >>>>>>> >>>>>>> I'd need to do some checking but I think this may all be effectively >>>>>>> dead code. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ------- >>>>>>> >>>>>>>> Could you please review my change . >>>>>>>> >>>>>>>> Webrev : >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8195857/ >>>>>>>> >>>>>>>> Bug : >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8195857 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, Matthias >>>>>>>> >>> From matthias.baesken at sap.com Thu Jan 25 07:49:16 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 25 Jan 2018 07:49:16 +0000 Subject: RFR : 8195857 : Posix platforms : move os::is_headless_jre check coding to os::Posix and remove test for libmawt In-Reply-To: References: <83c352c941374468bd811f611dfc2aff@sap.com> <292752fd-8152-216d-c09c-2236485c4a58@oracle.com> <08f18f12f480493e9b00cfdcc99ef1bc@sap.com> <042CA641-9057-444D-BFA9-CB4B2737ADF4@oracle.com> <9b649a09-29ea-c8e6-1ddb-7a22b5a54e57@oracle.com> <0E2C7BA4-689D-4B6A-AC72-1ACE02DCD8F1@oracle.com> <56671fcf61cb45f8a5f1c2b4607c5b03@sap.com> Message-ID: Hi David, I created a new webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8195857.1/ This one removes os::is_headless_jre() . Please review. Thanks, Matthias > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 25. Januar 2018 07:39 > To: Baesken, Matthias ; Bob Vandette > > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR : 8195857 : Posix platforms : move os::is_headless_jre check > coding to os::Posix and remove test for libmawt > > Hi Matthias, > > On 25/01/2018 4:36 PM, Baesken, Matthias wrote: > >> > >> Bottom line: os::is_headless_jre() is dead code as far as I can see. > >> > > > > Hi David, so do you suggest I prepare a new webrev where > os::is_headless_jre() is completely removed ? > > > > What about the code block in hotspot/share/runtime/arguments.cpp , do > you think this can be completely removed as well ? > > Yes - everything pertaining to os::is_headless_jre() can be removed. > > Thanks, > David > ----- > > > > > 3495 if (os::is_headless_jre()) { > > 3496 const char* headless = > Arguments::get_property("java.awt.headless"); > > 3497 if (headless == NULL) { > > 3498 const char *headless_env = ::getenv("JAVA_AWT_HEADLESS"); > > 3499 if (headless_env == NULL) { > > 3500 if (!add_property("java.awt.headless=true")) { > > 3501 return JNI_ENOMEM; > > 3502 } > > 3503 } else { > > 3504 char buffer[256]; > > 3505 jio_snprintf(buffer, sizeof(buffer), "java.awt.headless=%s", > headless_env); > > 3506 if (!add_property(buffer)) { > > 3507 return JNI_ENOMEM; > > 3508 } > > 3509 } > > 3510 } > > 3511 } > > > > Best regards, Matthias > > > > > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Donnerstag, 25. Januar 2018 02:16 > >> To: Bob Vandette > >> Cc: Baesken, Matthias ; hotspot- > >> dev at openjdk.java.net > >> Subject: Re: RFR : 8195857 : Posix platforms : move os::is_headless_jre > check > >> coding to os::Posix and remove test for libmawt > >> > >> On 24/01/2018 11:16 PM, Bob Vandette wrote: > >>>> On Jan 23, 2018, at 5:50 PM, David Holmes > >> wrote: > >>>> > >>>> Hi Bob, > >>>> > >>>> On 24/01/2018 1:25 AM, Bob Vandette wrote: > >>>>> If we are going to preserve this functionality and make alterations, I > >> suggest that > >>>>> we try to move this into the desktop module and remove it from the > >> hotspot sources. > >>>>> Other than finding an appropriate path at startup to initialize the > >> property, there is > >>>>> no reason why this check can?t be written in Java. This functionality > has > >> nothing to > >>>>> do with Hotspot or VMs. (I should have probably done this when I > first > >> added this check). > >>>> > >>>> Well we hacked it into the SE Embedded builds so we knew what lib > was > >> missing. > >>>> > >>>> I don't think what you suggest really makes sense in a modular world > >> because I don't think we expect to have java.desktop but not some of its > >> native parts - so there would be no trigger to force into headless mode. > >> More likely there is simply no java.desktop module at all. > >>> The automatic setting of java.awt.headless has nothing to do with > compact > >> profiles. This support was available in JDK 7 before profiles even existed. > >> This > >>> automatic headless detection was added in order to allow Java to be > >> ported to platforms that do not have a native windowing toolkit available. > >> This was > >>> used in embedded to also reduce the size of the binary by removing this > >> big library. A configuration that contains java.desktop can absolutely be > >> supported > >>> and the JCK can be passed without this native library. > >>> > >>> This Java property is only referenced by the desktop module. This is why > I > >> suggested that this functionality be moved out of the hotspot VM. > >> > >> Yes we forced the AWT into headless mode if there was no native > graphics > >> library support available. For some of those platforms we even did this > >> at build time, not via a runtime check. For SE Embedded support we > would > >> strip the library out at image build time, and so the runtime check > >> would force AWT into headless mode. For compact profiles there is no > AWT > >> at all, and no native library in the built image so the runtime check > >> still (vacuously) sets the property for headless mode. > >> > >> If you have the java.desktop module, then you have everything - there is > >> no fragmentation of that module that I am aware of, that would allow you > >> strip out the library that triggers os::is_headless_jre() or some other > >> check that forces the AWT into headless mode. If you have java.desktop > >> and you want headless mode then you have to ask for it explicitly. > >> > >> Bottom line: os::is_headless_jre() is dead code as far as I can see. > >> > >> Separately I'll file a bug to remove the compact profile builds. > >> > >> David > >> ----- > >> > >>> Bob. > >>> > >>> > >>>> > >>>> That said I was reminded that this is also used by the Compact Profiles > >> that were added in Java 8, but for which support was removed as from > Java 9 > >> (and modules). However the build logic is still present, and they still use > this > >> functionality. I think we can remove compact profiles completely in JDK > 11, > >> but that's a seperate tasks. > >>>> > >>>> Meanwhile if we kill off the os::is_headless_jre() logic then the > compact > >> profiles would not default to headless mode even though they can't run > >> headful (due to the missing native library as well as other Java APIs). But > the > >> only impact I can see there would be for running tests - and we're not > testing > >> compact profiles. So ... I still think this can be removed, but want to do a > >> couple more checks. > >>>> > >>>> Cheers, > >>>> David > >>>> > >>>>> Bob. > >>>>>> On Jan 23, 2018, at 5:57 AM, Baesken, Matthias > >> wrote: > >>>>>> > >>>>>> Hi David, thanks for the comments. > >>>>>> > >>>>>>> I'd need to do some checking but I think this may all be effectively > >>>>>>> dead code. > >>>>>> > >>>>>> Please do the checking, maybe we can completely remove it. > >>>>>> > >>>>>> Best Regards, Matthias > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>> Sent: Dienstag, 23. Januar 2018 11:30 > >>>>>>> To: Baesken, Matthias ; 'hotspot- > >>>>>>> dev at openjdk.java.net' > >>>>>>> Subject: Re: RFR : 8195857 : Posix platforms : move > >> os::is_headless_jre check > >>>>>>> coding to os::Posix and remove test for libmawt > >>>>>>> > >>>>>>> Hi Matthias, > >>>>>>> > >>>>>>> Some preliminary comments ... > >>>>>>> > >>>>>>> On 23/01/2018 6:24 PM, Baesken, Matthias wrote: > >>>>>>>> Hello, I noticed that os::is_headless_jre() still checks on the > Posix > >>>>>>> platforms for libmawt which is not present any longer. > >>>>>>> > >>>>>>> I wonder why that comment was put in but the code not changed > ... > >>>>>>> > >>>>>>>> Additionally the os::is_headless_jre() function could be put in a > >> central > >>>>>>> place at os_posix to avoid code duplication. > >>>>>>> > >>>>>>> I think you could simplify further and just define in os.cpp with > three > >>>>>>> cases: windows, OS X, posix. I normally wouldn't suggest that but > >> given > >>>>>>> Windows and OS X are always false, it's quite trivial. > >>>>>>> > >>>>>>> That said this may simplify even further because I don't know if the > >>>>>>> concept of a headless JRE is even meaningful anymore. This what > put > >> in > >>>>>>> place in 2010 to support Java SE Embedded. We had a special build > >>>>>>> process that would remove the library from the JRE image, then a > >> runtime > >>>>>>> check os::is_headless_jre() run during argument processing, that if > >>>>>>> true, caused the java.awt.headless property to be set to true > (unless > >>>>>>> already set). I don't think we can even build a "headless JRE" any > >> more. > >>>>>>> > >>>>>>> I'd need to do some checking but I think this may all be effectively > >>>>>>> dead code. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> David > >>>>>>> ------- > >>>>>>> > >>>>>>>> Could you please review my change . > >>>>>>>> > >>>>>>>> Webrev : > >>>>>>>> > >>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8195857/ > >>>>>>>> > >>>>>>>> Bug : > >>>>>>>> > >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8195857 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Thanks, Matthias > >>>>>>>> > >>> From matthias.baesken at sap.com Thu Jan 25 08:15:33 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 25 Jan 2018 08:15:33 +0000 Subject: RFR : 8196062 : Enable docker container related tests for linux ppc64le In-Reply-To: <3374db8c-6e7b-fe0b-6874-8289e9e369bc@oracle.com> References: <3374db8c-6e7b-fe0b-6874-8289e9e369bc@oracle.com> Message-ID: <6fa3fe84aad946eabb2b46281031e21d@sap.com> > > Perhaps, you could add code to DockerTestUtils.buildJdkDockerImage() > that does the following or similar: > 1. Construct a name for platform-specific docker file: > String platformSpecificDockerfile = dockerfile + "-" + > Platform.getOsArch(); > (Platform is jdk.test.lib.Platform) > Hello, the doc says : * Build a docker image that contains JDK under test. * The jdk will be placed under the "/jdk/" folder inside the docker file system. ..... param dockerfile name of the dockerfile residing in the test source ..... public static void buildJdkDockerImage(String imageName, String dockerfile, String buildDirName) It does not say anything about doing hidden insertions of some platform names into the dockerfile name. So should the jtreg API doc be changed ? If so who needs to approve this ? (as far as I see so far only the test at hotspot/jtreg/runtime/containers/docker/ use this so it should not be a big deal to change the interface?) Best regards, Matthias > -----Original Message----- > From: mikhailo [mailto:mikhailo.seledtsov at oracle.com] > Sent: Mittwoch, 24. Januar 2018 20:09 > To: Bob Vandette ; Baesken, Matthias > > Cc: hotspot-dev at openjdk.java.net; Lindenmaier, Goetz > ; Langer, Christoph > ; Doerr, Martin > Subject: Re: RFR : 8196062 : Enable docker container related tests for linux > ppc64le > > Hi Matthias, > > ?? Please see my comments about the test changes inline. > > > On 01/24/2018 07:13 AM, Bob Vandette wrote: > > osContainer_linux.cpp: > > > > Can you add "return;" in each test for subsystem not found messages and > > remove these 3 lines OR move your tests for NULL & messages inside. The > compiler can > > probably optimize this but I?d prefer more compact code. > > > > if (memory == NULL || cpuset == NULL || cpu == NULL || cpuacct == NULL) > { > > > > 342 return; > > 343 } > > > > > > The other changes in osContainer_linux.cpp look ok. > > > > I forwarded your test changes to Misha, who wrote these. > > > > Since it?s likely that other platforms, such as aarch64, are going to run into > the same problem, > > It would have been better to enable the tests based on the existence of an > arch specific > > Dockerfile-BasicTest-{os.arch} rather than enabling specific arch?s in > VPProps.java. > > This approach would reduce the number of changes significantly and allow > support to > > be added with 1 new file. > > > > You wouldn?t need "String dockerFileName = > Common.getDockerFileName();? > > in every test. Just make DockerTestUtils automatically add arch. > I like Bob's idea on handling platform-specific Dockerfiles. > > Perhaps, you could add code to DockerTestUtils.buildJdkDockerImage() > that does the following or similar: > ??? 1. Construct a name for platform-specific docker file: > ?????????? String platformSpecificDockerfile = dockerfile + "-" + > Platform.getOsArch(); > ?????????? (Platform is jdk.test.lib.Platform) > > ??? 2. Check if platformSpecificDockerfile file exists in the test > source directory > ????????? File.exists(Paths.get(Utils.TEST_SRC, platformSpecificDockerFile) > ????????? If it does, then use it. Otherwise continue using the > default/original dockerfile name. > > I think this will considerably simplify your change, as well as make it > easy to extend support to other platforms/configurations > in the future. Let us know what you think of this approach ? > > > Once your change gets (R)eviewed and approved, I can sponsor the push. > > > Thank you, > Misha > > > > > > > Bob. > > > > > > > >> On Jan 24, 2018, at 9:24 AM, Baesken, Matthias > wrote: > >> > >> Hello, could you please review the following change : 8196062 : Enable > docker container related tests for linux ppc64le . > >> > >> It adds docker container testing for linux ppc64 le (little endian) . > >> > >> A number of things had to be done : > >> ? Add a separate docker file > test/hotspot/jtreg/runtime/containers/docker/Dockerfile-BasicTest-ppc64le > for linux ppc64 le which uses Ubuntu ( the Oracle Linux 7.2 used for > x86_64 seems not to be available for ppc64le ) > >> ? Fix parsing /proc/self/mountinfo and /proc/self/cgroup in > src/hotspot/os/linux/osContainer_linux.cpp , it could not handle the > format seen on SUSE LINUX 12.1 ppc64le (Host) and Ubuntu (Docker > container) > >> ? Add a bit more logging > >> > >> > >> Webrev : > >> > >> http://cr.openjdk.java.net/~mbaesken/webrevs/8196062/ > >> > >> > >> Bug : > >> > >> https://bugs.openjdk.java.net/browse/JDK-8196062 > >> > >> > >> After these adjustments I could run the runtime/containers/docker - > jtreg tests successfully . > >> > >> > >> Best regards, Matthias From goetz.lindenmaier at sap.com Thu Jan 25 09:15:13 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 25 Jan 2018 09:15:13 +0000 Subject: RFR : 8195857 : Posix platforms : move os::is_headless_jre check coding to os::Posix and remove test for libmawt In-Reply-To: References: <83c352c941374468bd811f611dfc2aff@sap.com> <292752fd-8152-216d-c09c-2236485c4a58@oracle.com> <08f18f12f480493e9b00cfdcc99ef1bc@sap.com> <042CA641-9057-444D-BFA9-CB4B2737ADF4@oracle.com> <9b649a09-29ea-c8e6-1ddb-7a22b5a54e57@oracle.com> <0E2C7BA4-689D-4B6A-AC72-1ACE02DCD8F1@oracle.com> <56671fcf61cb45f8a5f1c2b4607c5b03@sap.com> Message-ID: Hi, Change looks good :) Would it make sense to rename the bug to "Remove os::is_headless_jre"? Best regards, Goetz. -----Original Message----- From: Baesken, Matthias Sent: Thursday, January 25, 2018 8:49 AM To: David Holmes ; Bob Vandette Cc: hotspot-dev at openjdk.java.net; Lindenmaier, Goetz Subject: RE: RFR : 8195857 : Posix platforms : move os::is_headless_jre check coding to os::Posix and remove test for libmawt Hi David, I created a new webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8195857.1/ This one removes os::is_headless_jre() . Please review. Thanks, Matthias > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 25. Januar 2018 07:39 > To: Baesken, Matthias ; Bob Vandette > > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR : 8195857 : Posix platforms : move os::is_headless_jre check > coding to os::Posix and remove test for libmawt > > Hi Matthias, > > On 25/01/2018 4:36 PM, Baesken, Matthias wrote: > >> > >> Bottom line: os::is_headless_jre() is dead code as far as I can see. > >> > > > > Hi David, so do you suggest I prepare a new webrev where > os::is_headless_jre() is completely removed ? > > > > What about the code block in hotspot/share/runtime/arguments.cpp , do > you think this can be completely removed as well ? > > Yes - everything pertaining to os::is_headless_jre() can be removed. > > Thanks, > David > ----- > > > > > 3495 if (os::is_headless_jre()) { > > 3496 const char* headless = > Arguments::get_property("java.awt.headless"); > > 3497 if (headless == NULL) { > > 3498 const char *headless_env = ::getenv("JAVA_AWT_HEADLESS"); > > 3499 if (headless_env == NULL) { > > 3500 if (!add_property("java.awt.headless=true")) { > > 3501 return JNI_ENOMEM; > > 3502 } > > 3503 } else { > > 3504 char buffer[256]; > > 3505 jio_snprintf(buffer, sizeof(buffer), "java.awt.headless=%s", > headless_env); > > 3506 if (!add_property(buffer)) { > > 3507 return JNI_ENOMEM; > > 3508 } > > 3509 } > > 3510 } > > 3511 } > > > > Best regards, Matthias > > > > > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Donnerstag, 25. Januar 2018 02:16 > >> To: Bob Vandette > >> Cc: Baesken, Matthias ; hotspot- > >> dev at openjdk.java.net > >> Subject: Re: RFR : 8195857 : Posix platforms : move os::is_headless_jre > check > >> coding to os::Posix and remove test for libmawt > >> > >> On 24/01/2018 11:16 PM, Bob Vandette wrote: > >>>> On Jan 23, 2018, at 5:50 PM, David Holmes > >> wrote: > >>>> > >>>> Hi Bob, > >>>> > >>>> On 24/01/2018 1:25 AM, Bob Vandette wrote: > >>>>> If we are going to preserve this functionality and make alterations, I > >> suggest that > >>>>> we try to move this into the desktop module and remove it from the > >> hotspot sources. > >>>>> Other than finding an appropriate path at startup to initialize the > >> property, there is > >>>>> no reason why this check can?t be written in Java. This functionality > has > >> nothing to > >>>>> do with Hotspot or VMs. (I should have probably done this when I > first > >> added this check). > >>>> > >>>> Well we hacked it into the SE Embedded builds so we knew what lib > was > >> missing. > >>>> > >>>> I don't think what you suggest really makes sense in a modular world > >> because I don't think we expect to have java.desktop but not some of its > >> native parts - so there would be no trigger to force into headless mode. > >> More likely there is simply no java.desktop module at all. > >>> The automatic setting of java.awt.headless has nothing to do with > compact > >> profiles. This support was available in JDK 7 before profiles even existed. > >> This > >>> automatic headless detection was added in order to allow Java to be > >> ported to platforms that do not have a native windowing toolkit available. > >> This was > >>> used in embedded to also reduce the size of the binary by removing this > >> big library. A configuration that contains java.desktop can absolutely be > >> supported > >>> and the JCK can be passed without this native library. > >>> > >>> This Java property is only referenced by the desktop module. This is why > I > >> suggested that this functionality be moved out of the hotspot VM. > >> > >> Yes we forced the AWT into headless mode if there was no native > graphics > >> library support available. For some of those platforms we even did this > >> at build time, not via a runtime check. For SE Embedded support we > would > >> strip the library out at image build time, and so the runtime check > >> would force AWT into headless mode. For compact profiles there is no > AWT > >> at all, and no native library in the built image so the runtime check > >> still (vacuously) sets the property for headless mode. > >> > >> If you have the java.desktop module, then you have everything - there is > >> no fragmentation of that module that I am aware of, that would allow you > >> strip out the library that triggers os::is_headless_jre() or some other > >> check that forces the AWT into headless mode. If you have java.desktop > >> and you want headless mode then you have to ask for it explicitly. > >> > >> Bottom line: os::is_headless_jre() is dead code as far as I can see. > >> > >> Separately I'll file a bug to remove the compact profile builds. > >> > >> David > >> ----- > >> > >>> Bob. > >>> > >>> > >>>> > >>>> That said I was reminded that this is also used by the Compact Profiles > >> that were added in Java 8, but for which support was removed as from > Java 9 > >> (and modules). However the build logic is still present, and they still use > this > >> functionality. I think we can remove compact profiles completely in JDK > 11, > >> but that's a seperate tasks. > >>>> > >>>> Meanwhile if we kill off the os::is_headless_jre() logic then the > compact > >> profiles would not default to headless mode even though they can't run > >> headful (due to the missing native library as well as other Java APIs). But > the > >> only impact I can see there would be for running tests - and we're not > testing > >> compact profiles. So ... I still think this can be removed, but want to do a > >> couple more checks. > >>>> > >>>> Cheers, > >>>> David > >>>> > >>>>> Bob. > >>>>>> On Jan 23, 2018, at 5:57 AM, Baesken, Matthias > >> wrote: > >>>>>> > >>>>>> Hi David, thanks for the comments. > >>>>>> > >>>>>>> I'd need to do some checking but I think this may all be effectively > >>>>>>> dead code. > >>>>>> > >>>>>> Please do the checking, maybe we can completely remove it. > >>>>>> > >>>>>> Best Regards, Matthias > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>> Sent: Dienstag, 23. Januar 2018 11:30 > >>>>>>> To: Baesken, Matthias ; 'hotspot- > >>>>>>> dev at openjdk.java.net' > >>>>>>> Subject: Re: RFR : 8195857 : Posix platforms : move > >> os::is_headless_jre check > >>>>>>> coding to os::Posix and remove test for libmawt > >>>>>>> > >>>>>>> Hi Matthias, > >>>>>>> > >>>>>>> Some preliminary comments ... > >>>>>>> > >>>>>>> On 23/01/2018 6:24 PM, Baesken, Matthias wrote: > >>>>>>>> Hello, I noticed that os::is_headless_jre() still checks on the > Posix > >>>>>>> platforms for libmawt which is not present any longer. > >>>>>>> > >>>>>>> I wonder why that comment was put in but the code not changed > ... > >>>>>>> > >>>>>>>> Additionally the os::is_headless_jre() function could be put in a > >> central > >>>>>>> place at os_posix to avoid code duplication. > >>>>>>> > >>>>>>> I think you could simplify further and just define in os.cpp with > three > >>>>>>> cases: windows, OS X, posix. I normally wouldn't suggest that but > >> given > >>>>>>> Windows and OS X are always false, it's quite trivial. > >>>>>>> > >>>>>>> That said this may simplify even further because I don't know if the > >>>>>>> concept of a headless JRE is even meaningful anymore. This what > put > >> in > >>>>>>> place in 2010 to support Java SE Embedded. We had a special build > >>>>>>> process that would remove the library from the JRE image, then a > >> runtime > >>>>>>> check os::is_headless_jre() run during argument processing, that if > >>>>>>> true, caused the java.awt.headless property to be set to true > (unless > >>>>>>> already set). I don't think we can even build a "headless JRE" any > >> more. > >>>>>>> > >>>>>>> I'd need to do some checking but I think this may all be effectively > >>>>>>> dead code. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> David > >>>>>>> ------- > >>>>>>> > >>>>>>>> Could you please review my change . > >>>>>>>> > >>>>>>>> Webrev : > >>>>>>>> > >>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8195857/ > >>>>>>>> > >>>>>>>> Bug : > >>>>>>>> > >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8195857 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Thanks, Matthias > >>>>>>>> > >>> From david.holmes at oracle.com Thu Jan 25 11:56:53 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Jan 2018 21:56:53 +1000 Subject: RFR : 8195857 : Posix platforms : move os::is_headless_jre check coding to os::Posix and remove test for libmawt In-Reply-To: References: <83c352c941374468bd811f611dfc2aff@sap.com> <292752fd-8152-216d-c09c-2236485c4a58@oracle.com> <08f18f12f480493e9b00cfdcc99ef1bc@sap.com> <042CA641-9057-444D-BFA9-CB4B2737ADF4@oracle.com> <9b649a09-29ea-c8e6-1ddb-7a22b5a54e57@oracle.com> <0E2C7BA4-689D-4B6A-AC72-1ACE02DCD8F1@oracle.com> <56671fcf61cb45f8a5f1c2b4607c5b03@sap.com> Message-ID: <7d0e32c8-4648-6d88-8646-61b47526bcfc@oracle.com> On 25/01/2018 7:15 PM, Lindenmaier, Goetz wrote: > Hi, > > Change looks good :) +1 - thanks Matthias! > Would it make sense to rename the bug to "Remove os::is_headless_jre"? +1 on that too! David ------ > Best regards, > Goetz. > > -----Original Message----- > From: Baesken, Matthias > Sent: Thursday, January 25, 2018 8:49 AM > To: David Holmes ; Bob Vandette > Cc: hotspot-dev at openjdk.java.net; Lindenmaier, Goetz > Subject: RE: RFR : 8195857 : Posix platforms : move os::is_headless_jre check coding to os::Posix and remove test for libmawt > > Hi David, I created a new webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8195857.1/ > > This one removes os::is_headless_jre() . > > Please review. > > Thanks, Matthias > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Donnerstag, 25. Januar 2018 07:39 >> To: Baesken, Matthias ; Bob Vandette >> >> Cc: hotspot-dev at openjdk.java.net >> Subject: Re: RFR : 8195857 : Posix platforms : move os::is_headless_jre check >> coding to os::Posix and remove test for libmawt >> >> Hi Matthias, >> >> On 25/01/2018 4:36 PM, Baesken, Matthias wrote: >>>> >>>> Bottom line: os::is_headless_jre() is dead code as far as I can see. >>>> >>> >>> Hi David, so do you suggest I prepare a new webrev where >> os::is_headless_jre() is completely removed ? >>> >>> What about the code block in hotspot/share/runtime/arguments.cpp , do >> you think this can be completely removed as well ? >> >> Yes - everything pertaining to os::is_headless_jre() can be removed. >> >> Thanks, >> David >> ----- >> >>> >>> 3495 if (os::is_headless_jre()) { >>> 3496 const char* headless = >> Arguments::get_property("java.awt.headless"); >>> 3497 if (headless == NULL) { >>> 3498 const char *headless_env = ::getenv("JAVA_AWT_HEADLESS"); >>> 3499 if (headless_env == NULL) { >>> 3500 if (!add_property("java.awt.headless=true")) { >>> 3501 return JNI_ENOMEM; >>> 3502 } >>> 3503 } else { >>> 3504 char buffer[256]; >>> 3505 jio_snprintf(buffer, sizeof(buffer), "java.awt.headless=%s", >> headless_env); >>> 3506 if (!add_property(buffer)) { >>> 3507 return JNI_ENOMEM; >>> 3508 } >>> 3509 } >>> 3510 } >>> 3511 } >>> >>> Best regards, Matthias >>> >>> >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Donnerstag, 25. Januar 2018 02:16 >>>> To: Bob Vandette >>>> Cc: Baesken, Matthias ; hotspot- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR : 8195857 : Posix platforms : move os::is_headless_jre >> check >>>> coding to os::Posix and remove test for libmawt >>>> >>>> On 24/01/2018 11:16 PM, Bob Vandette wrote: >>>>>> On Jan 23, 2018, at 5:50 PM, David Holmes >>>> wrote: >>>>>> >>>>>> Hi Bob, >>>>>> >>>>>> On 24/01/2018 1:25 AM, Bob Vandette wrote: >>>>>>> If we are going to preserve this functionality and make alterations, I >>>> suggest that >>>>>>> we try to move this into the desktop module and remove it from the >>>> hotspot sources. >>>>>>> Other than finding an appropriate path at startup to initialize the >>>> property, there is >>>>>>> no reason why this check can?t be written in Java. This functionality >> has >>>> nothing to >>>>>>> do with Hotspot or VMs. (I should have probably done this when I >> first >>>> added this check). >>>>>> >>>>>> Well we hacked it into the SE Embedded builds so we knew what lib >> was >>>> missing. >>>>>> >>>>>> I don't think what you suggest really makes sense in a modular world >>>> because I don't think we expect to have java.desktop but not some of its >>>> native parts - so there would be no trigger to force into headless mode. >>>> More likely there is simply no java.desktop module at all. >>>>> The automatic setting of java.awt.headless has nothing to do with >> compact >>>> profiles. This support was available in JDK 7 before profiles even existed. >>>> This >>>>> automatic headless detection was added in order to allow Java to be >>>> ported to platforms that do not have a native windowing toolkit available. >>>> This was >>>>> used in embedded to also reduce the size of the binary by removing this >>>> big library. A configuration that contains java.desktop can absolutely be >>>> supported >>>>> and the JCK can be passed without this native library. >>>>> >>>>> This Java property is only referenced by the desktop module. This is why >> I >>>> suggested that this functionality be moved out of the hotspot VM. >>>> >>>> Yes we forced the AWT into headless mode if there was no native >> graphics >>>> library support available. For some of those platforms we even did this >>>> at build time, not via a runtime check. For SE Embedded support we >> would >>>> strip the library out at image build time, and so the runtime check >>>> would force AWT into headless mode. For compact profiles there is no >> AWT >>>> at all, and no native library in the built image so the runtime check >>>> still (vacuously) sets the property for headless mode. >>>> >>>> If you have the java.desktop module, then you have everything - there is >>>> no fragmentation of that module that I am aware of, that would allow you >>>> strip out the library that triggers os::is_headless_jre() or some other >>>> check that forces the AWT into headless mode. If you have java.desktop >>>> and you want headless mode then you have to ask for it explicitly. >>>> >>>> Bottom line: os::is_headless_jre() is dead code as far as I can see. >>>> >>>> Separately I'll file a bug to remove the compact profile builds. >>>> >>>> David >>>> ----- >>>> >>>>> Bob. >>>>> >>>>> >>>>>> >>>>>> That said I was reminded that this is also used by the Compact Profiles >>>> that were added in Java 8, but for which support was removed as from >> Java 9 >>>> (and modules). However the build logic is still present, and they still use >> this >>>> functionality. I think we can remove compact profiles completely in JDK >> 11, >>>> but that's a seperate tasks. >>>>>> >>>>>> Meanwhile if we kill off the os::is_headless_jre() logic then the >> compact >>>> profiles would not default to headless mode even though they can't run >>>> headful (due to the missing native library as well as other Java APIs). But >> the >>>> only impact I can see there would be for running tests - and we're not >> testing >>>> compact profiles. So ... I still think this can be removed, but want to do a >>>> couple more checks. >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>>> Bob. >>>>>>>> On Jan 23, 2018, at 5:57 AM, Baesken, Matthias >>>> wrote: >>>>>>>> >>>>>>>> Hi David, thanks for the comments. >>>>>>>> >>>>>>>>> I'd need to do some checking but I think this may all be effectively >>>>>>>>> dead code. >>>>>>>> >>>>>>>> Please do the checking, maybe we can completely remove it. >>>>>>>> >>>>>>>> Best Regards, Matthias >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> Sent: Dienstag, 23. Januar 2018 11:30 >>>>>>>>> To: Baesken, Matthias ; 'hotspot- >>>>>>>>> dev at openjdk.java.net' >>>>>>>>> Subject: Re: RFR : 8195857 : Posix platforms : move >>>> os::is_headless_jre check >>>>>>>>> coding to os::Posix and remove test for libmawt >>>>>>>>> >>>>>>>>> Hi Matthias, >>>>>>>>> >>>>>>>>> Some preliminary comments ... >>>>>>>>> >>>>>>>>> On 23/01/2018 6:24 PM, Baesken, Matthias wrote: >>>>>>>>>> Hello, I noticed that os::is_headless_jre() still checks on the >> Posix >>>>>>>>> platforms for libmawt which is not present any longer. >>>>>>>>> >>>>>>>>> I wonder why that comment was put in but the code not changed >> ... >>>>>>>>> >>>>>>>>>> Additionally the os::is_headless_jre() function could be put in a >>>> central >>>>>>>>> place at os_posix to avoid code duplication. >>>>>>>>> >>>>>>>>> I think you could simplify further and just define in os.cpp with >> three >>>>>>>>> cases: windows, OS X, posix. I normally wouldn't suggest that but >>>> given >>>>>>>>> Windows and OS X are always false, it's quite trivial. >>>>>>>>> >>>>>>>>> That said this may simplify even further because I don't know if the >>>>>>>>> concept of a headless JRE is even meaningful anymore. This what >> put >>>> in >>>>>>>>> place in 2010 to support Java SE Embedded. We had a special build >>>>>>>>> process that would remove the library from the JRE image, then a >>>> runtime >>>>>>>>> check os::is_headless_jre() run during argument processing, that if >>>>>>>>> true, caused the java.awt.headless property to be set to true >> (unless >>>>>>>>> already set). I don't think we can even build a "headless JRE" any >>>> more. >>>>>>>>> >>>>>>>>> I'd need to do some checking but I think this may all be effectively >>>>>>>>> dead code. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> ------- >>>>>>>>> >>>>>>>>>> Could you please review my change . >>>>>>>>>> >>>>>>>>>> Webrev : >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8195857/ >>>>>>>>>> >>>>>>>>>> Bug : >>>>>>>>>> >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8195857 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, Matthias >>>>>>>>>> >>>>> From matthias.baesken at sap.com Thu Jan 25 12:08:47 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 25 Jan 2018 12:08:47 +0000 Subject: RFR : 8195857 : Posix platforms : move os::is_headless_jre check coding to os::Posix and remove test for libmawt In-Reply-To: <7d0e32c8-4648-6d88-8646-61b47526bcfc@oracle.com> References: <83c352c941374468bd811f611dfc2aff@sap.com> <292752fd-8152-216d-c09c-2236485c4a58@oracle.com> <08f18f12f480493e9b00cfdcc99ef1bc@sap.com> <042CA641-9057-444D-BFA9-CB4B2737ADF4@oracle.com> <9b649a09-29ea-c8e6-1ddb-7a22b5a54e57@oracle.com> <0E2C7BA4-689D-4B6A-AC72-1ACE02DCD8F1@oracle.com> <56671fcf61cb45f8a5f1c2b4607c5b03@sap.com> <7d0e32c8-4648-6d88-8646-61b47526bcfc@oracle.com> Message-ID: > > Would it make sense to rename the bug to "Remove os::is_headless_jre"? > > +1 on that too! > Hi David and Goetz, I renamed the bug . So we have 2 reviews now --> who can push it for me ? Best regards, Matthias > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 25. Januar 2018 12:57 > To: Baesken, Matthias ; Bob Vandette > > Cc: Lindenmaier, Goetz ; hotspot- > dev at openjdk.java.net > Subject: Re: RFR : 8195857 : Posix platforms : move os::is_headless_jre check > coding to os::Posix and remove test for libmawt > > On 25/01/2018 7:15 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > Change looks good :) > > +1 - thanks Matthias! > > > Would it make sense to rename the bug to "Remove os::is_headless_jre"? > > +1 on that too! > > David > ------ > > > Best regards, > > Goetz. > > > > -----Original Message----- > > From: Baesken, Matthias > > Sent: Thursday, January 25, 2018 8:49 AM > > To: David Holmes ; Bob Vandette > > > Cc: hotspot-dev at openjdk.java.net; Lindenmaier, Goetz > > > Subject: RE: RFR : 8195857 : Posix platforms : move os::is_headless_jre > check coding to os::Posix and remove test for libmawt > > > > Hi David, I created a new webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8195857.1/ > > > > This one removes os::is_headless_jre() . > > > > Please review. > > > > Thanks, Matthias > > > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Donnerstag, 25. Januar 2018 07:39 > >> To: Baesken, Matthias ; Bob Vandette > >> > >> Cc: hotspot-dev at openjdk.java.net > >> Subject: Re: RFR : 8195857 : Posix platforms : move os::is_headless_jre > check > >> coding to os::Posix and remove test for libmawt > >> > >> Hi Matthias, > >> > >> On 25/01/2018 4:36 PM, Baesken, Matthias wrote: > >>>> > >>>> Bottom line: os::is_headless_jre() is dead code as far as I can see. > >>>> > >>> > >>> Hi David, so do you suggest I prepare a new webrev where > >> os::is_headless_jre() is completely removed ? > >>> > >>> What about the code block in hotspot/share/runtime/arguments.cpp , > do > >> you think this can be completely removed as well ? > >> > >> Yes - everything pertaining to os::is_headless_jre() can be removed. > >> > >> Thanks, > >> David > >> ----- > >> > >>> > >>> 3495 if (os::is_headless_jre()) { > >>> 3496 const char* headless = > >> Arguments::get_property("java.awt.headless"); > >>> 3497 if (headless == NULL) { > >>> 3498 const char *headless_env = ::getenv("JAVA_AWT_HEADLESS"); > >>> 3499 if (headless_env == NULL) { > >>> 3500 if (!add_property("java.awt.headless=true")) { > >>> 3501 return JNI_ENOMEM; > >>> 3502 } > >>> 3503 } else { > >>> 3504 char buffer[256]; > >>> 3505 jio_snprintf(buffer, sizeof(buffer), "java.awt.headless=%s", > >> headless_env); > >>> 3506 if (!add_property(buffer)) { > >>> 3507 return JNI_ENOMEM; > >>> 3508 } > >>> 3509 } > >>> 3510 } > >>> 3511 } > >>> > >>> Best regards, Matthias > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Donnerstag, 25. Januar 2018 02:16 > >>>> To: Bob Vandette > >>>> Cc: Baesken, Matthias ; hotspot- > >>>> dev at openjdk.java.net > >>>> Subject: Re: RFR : 8195857 : Posix platforms : move os::is_headless_jre > >> check > >>>> coding to os::Posix and remove test for libmawt > >>>> > >>>> On 24/01/2018 11:16 PM, Bob Vandette wrote: > >>>>>> On Jan 23, 2018, at 5:50 PM, David Holmes > > >>>> wrote: > >>>>>> > >>>>>> Hi Bob, > >>>>>> > >>>>>> On 24/01/2018 1:25 AM, Bob Vandette wrote: > >>>>>>> If we are going to preserve this functionality and make alterations, I > >>>> suggest that > >>>>>>> we try to move this into the desktop module and remove it from > the > >>>> hotspot sources. > >>>>>>> Other than finding an appropriate path at startup to initialize the > >>>> property, there is > >>>>>>> no reason why this check can?t be written in Java. This > functionality > >> has > >>>> nothing to > >>>>>>> do with Hotspot or VMs. (I should have probably done this when I > >> first > >>>> added this check). > >>>>>> > >>>>>> Well we hacked it into the SE Embedded builds so we knew what lib > >> was > >>>> missing. > >>>>>> > >>>>>> I don't think what you suggest really makes sense in a modular world > >>>> because I don't think we expect to have java.desktop but not some of > its > >>>> native parts - so there would be no trigger to force into headless mode. > >>>> More likely there is simply no java.desktop module at all. > >>>>> The automatic setting of java.awt.headless has nothing to do with > >> compact > >>>> profiles. This support was available in JDK 7 before profiles even > existed. > >>>> This > >>>>> automatic headless detection was added in order to allow Java to be > >>>> ported to platforms that do not have a native windowing toolkit > available. > >>>> This was > >>>>> used in embedded to also reduce the size of the binary by removing > this > >>>> big library. A configuration that contains java.desktop can absolutely be > >>>> supported > >>>>> and the JCK can be passed without this native library. > >>>>> > >>>>> This Java property is only referenced by the desktop module. This is > why > >> I > >>>> suggested that this functionality be moved out of the hotspot VM. > >>>> > >>>> Yes we forced the AWT into headless mode if there was no native > >> graphics > >>>> library support available. For some of those platforms we even did this > >>>> at build time, not via a runtime check. For SE Embedded support we > >> would > >>>> strip the library out at image build time, and so the runtime check > >>>> would force AWT into headless mode. For compact profiles there is no > >> AWT > >>>> at all, and no native library in the built image so the runtime check > >>>> still (vacuously) sets the property for headless mode. > >>>> > >>>> If you have the java.desktop module, then you have everything - there > is > >>>> no fragmentation of that module that I am aware of, that would allow > you > >>>> strip out the library that triggers os::is_headless_jre() or some other > >>>> check that forces the AWT into headless mode. If you have > java.desktop > >>>> and you want headless mode then you have to ask for it explicitly. > >>>> > >>>> Bottom line: os::is_headless_jre() is dead code as far as I can see. > >>>> > >>>> Separately I'll file a bug to remove the compact profile builds. > >>>> > >>>> David > >>>> ----- > >>>> > >>>>> Bob. > >>>>> > >>>>> > >>>>>> > >>>>>> That said I was reminded that this is also used by the Compact > Profiles > >>>> that were added in Java 8, but for which support was removed as from > >> Java 9 > >>>> (and modules). However the build logic is still present, and they still use > >> this > >>>> functionality. I think we can remove compact profiles completely in JDK > >> 11, > >>>> but that's a seperate tasks. > >>>>>> > >>>>>> Meanwhile if we kill off the os::is_headless_jre() logic then the > >> compact > >>>> profiles would not default to headless mode even though they can't > run > >>>> headful (due to the missing native library as well as other Java APIs). > But > >> the > >>>> only impact I can see there would be for running tests - and we're not > >> testing > >>>> compact profiles. So ... I still think this can be removed, but want to do > a > >>>> couple more checks. > >>>>>> > >>>>>> Cheers, > >>>>>> David > >>>>>> > >>>>>>> Bob. > >>>>>>>> On Jan 23, 2018, at 5:57 AM, Baesken, Matthias > >>>> wrote: > >>>>>>>> > >>>>>>>> Hi David, thanks for the comments. > >>>>>>>> > >>>>>>>>> I'd need to do some checking but I think this may all be > effectively > >>>>>>>>> dead code. > >>>>>>>> > >>>>>>>> Please do the checking, maybe we can completely remove it. > >>>>>>>> > >>>>>>>> Best Regards, Matthias > >>>>>>>> > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>> Sent: Dienstag, 23. Januar 2018 11:30 > >>>>>>>>> To: Baesken, Matthias ; 'hotspot- > >>>>>>>>> dev at openjdk.java.net' > >>>>>>>>> Subject: Re: RFR : 8195857 : Posix platforms : move > >>>> os::is_headless_jre check > >>>>>>>>> coding to os::Posix and remove test for libmawt > >>>>>>>>> > >>>>>>>>> Hi Matthias, > >>>>>>>>> > >>>>>>>>> Some preliminary comments ... > >>>>>>>>> > >>>>>>>>> On 23/01/2018 6:24 PM, Baesken, Matthias wrote: > >>>>>>>>>> Hello, I noticed that os::is_headless_jre() still checks on the > >> Posix > >>>>>>>>> platforms for libmawt which is not present any longer. > >>>>>>>>> > >>>>>>>>> I wonder why that comment was put in but the code not > changed > >> ... > >>>>>>>>> > >>>>>>>>>> Additionally the os::is_headless_jre() function could be put in > a > >>>> central > >>>>>>>>> place at os_posix to avoid code duplication. > >>>>>>>>> > >>>>>>>>> I think you could simplify further and just define in os.cpp with > >> three > >>>>>>>>> cases: windows, OS X, posix. I normally wouldn't suggest that but > >>>> given > >>>>>>>>> Windows and OS X are always false, it's quite trivial. > >>>>>>>>> > >>>>>>>>> That said this may simplify even further because I don't know if > the > >>>>>>>>> concept of a headless JRE is even meaningful anymore. This > what > >> put > >>>> in > >>>>>>>>> place in 2010 to support Java SE Embedded. We had a special > build > >>>>>>>>> process that would remove the library from the JRE image, then > a > >>>> runtime > >>>>>>>>> check os::is_headless_jre() run during argument processing, that > if > >>>>>>>>> true, caused the java.awt.headless property to be set to true > >> (unless > >>>>>>>>> already set). I don't think we can even build a "headless JRE" any > >>>> more. > >>>>>>>>> > >>>>>>>>> I'd need to do some checking but I think this may all be > effectively > >>>>>>>>> dead code. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> David > >>>>>>>>> ------- > >>>>>>>>> > >>>>>>>>>> Could you please review my change . > >>>>>>>>>> > >>>>>>>>>> Webrev : > >>>>>>>>>> > >>>>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8195857/ > >>>>>>>>>> > >>>>>>>>>> Bug : > >>>>>>>>>> > >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8195857 > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Thanks, Matthias > >>>>>>>>>> > >>>>> From david.holmes at oracle.com Thu Jan 25 12:16:03 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Jan 2018 22:16:03 +1000 Subject: RFR : 8195857 : Posix platforms : move os::is_headless_jre check coding to os::Posix and remove test for libmawt In-Reply-To: References: <83c352c941374468bd811f611dfc2aff@sap.com> <292752fd-8152-216d-c09c-2236485c4a58@oracle.com> <08f18f12f480493e9b00cfdcc99ef1bc@sap.com> <042CA641-9057-444D-BFA9-CB4B2737ADF4@oracle.com> <9b649a09-29ea-c8e6-1ddb-7a22b5a54e57@oracle.com> <0E2C7BA4-689D-4B6A-AC72-1ACE02DCD8F1@oracle.com> <56671fcf61cb45f8a5f1c2b4607c5b03@sap.com> <7d0e32c8-4648-6d88-8646-61b47526bcfc@oracle.com> Message-ID: On 25/01/2018 10:08 PM, Baesken, Matthias wrote: > >>> Would it make sense to rename the bug to "Remove os::is_headless_jre"? >> >> +1 on that too! >> > > Hi David and Goetz, I renamed the bug . > > So we have 2 reviews now --> who can push it for me ? I can sponsor it for you, but I'll let it sit for a while to give a chance for any other comments. Thanks, David > Best regards, Matthias > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Donnerstag, 25. Januar 2018 12:57 >> To: Baesken, Matthias ; Bob Vandette >> >> Cc: Lindenmaier, Goetz ; hotspot- >> dev at openjdk.java.net >> Subject: Re: RFR : 8195857 : Posix platforms : move os::is_headless_jre check >> coding to os::Posix and remove test for libmawt >> >> On 25/01/2018 7:15 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> Change looks good :) >> >> +1 - thanks Matthias! >> >>> Would it make sense to rename the bug to "Remove os::is_headless_jre"? >> >> +1 on that too! >> >> David >> ------ >> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: Baesken, Matthias >>> Sent: Thursday, January 25, 2018 8:49 AM >>> To: David Holmes ; Bob Vandette >> >>> Cc: hotspot-dev at openjdk.java.net; Lindenmaier, Goetz >> >>> Subject: RE: RFR : 8195857 : Posix platforms : move os::is_headless_jre >> check coding to os::Posix and remove test for libmawt >>> >>> Hi David, I created a new webrev : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8195857.1/ >>> >>> This one removes os::is_headless_jre() . >>> >>> Please review. >>> >>> Thanks, Matthias >>> >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Donnerstag, 25. Januar 2018 07:39 >>>> To: Baesken, Matthias ; Bob Vandette >>>> >>>> Cc: hotspot-dev at openjdk.java.net >>>> Subject: Re: RFR : 8195857 : Posix platforms : move os::is_headless_jre >> check >>>> coding to os::Posix and remove test for libmawt >>>> >>>> Hi Matthias, >>>> >>>> On 25/01/2018 4:36 PM, Baesken, Matthias wrote: >>>>>> >>>>>> Bottom line: os::is_headless_jre() is dead code as far as I can see. >>>>>> >>>>> >>>>> Hi David, so do you suggest I prepare a new webrev where >>>> os::is_headless_jre() is completely removed ? >>>>> >>>>> What about the code block in hotspot/share/runtime/arguments.cpp , >> do >>>> you think this can be completely removed as well ? >>>> >>>> Yes - everything pertaining to os::is_headless_jre() can be removed. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> >>>>> 3495 if (os::is_headless_jre()) { >>>>> 3496 const char* headless = >>>> Arguments::get_property("java.awt.headless"); >>>>> 3497 if (headless == NULL) { >>>>> 3498 const char *headless_env = ::getenv("JAVA_AWT_HEADLESS"); >>>>> 3499 if (headless_env == NULL) { >>>>> 3500 if (!add_property("java.awt.headless=true")) { >>>>> 3501 return JNI_ENOMEM; >>>>> 3502 } >>>>> 3503 } else { >>>>> 3504 char buffer[256]; >>>>> 3505 jio_snprintf(buffer, sizeof(buffer), "java.awt.headless=%s", >>>> headless_env); >>>>> 3506 if (!add_property(buffer)) { >>>>> 3507 return JNI_ENOMEM; >>>>> 3508 } >>>>> 3509 } >>>>> 3510 } >>>>> 3511 } >>>>> >>>>> Best regards, Matthias >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Donnerstag, 25. Januar 2018 02:16 >>>>>> To: Bob Vandette >>>>>> Cc: Baesken, Matthias ; hotspot- >>>>>> dev at openjdk.java.net >>>>>> Subject: Re: RFR : 8195857 : Posix platforms : move os::is_headless_jre >>>> check >>>>>> coding to os::Posix and remove test for libmawt >>>>>> >>>>>> On 24/01/2018 11:16 PM, Bob Vandette wrote: >>>>>>>> On Jan 23, 2018, at 5:50 PM, David Holmes >> >>>>>> wrote: >>>>>>>> >>>>>>>> Hi Bob, >>>>>>>> >>>>>>>> On 24/01/2018 1:25 AM, Bob Vandette wrote: >>>>>>>>> If we are going to preserve this functionality and make alterations, I >>>>>> suggest that >>>>>>>>> we try to move this into the desktop module and remove it from >> the >>>>>> hotspot sources. >>>>>>>>> Other than finding an appropriate path at startup to initialize the >>>>>> property, there is >>>>>>>>> no reason why this check can?t be written in Java. This >> functionality >>>> has >>>>>> nothing to >>>>>>>>> do with Hotspot or VMs. (I should have probably done this when I >>>> first >>>>>> added this check). >>>>>>>> >>>>>>>> Well we hacked it into the SE Embedded builds so we knew what lib >>>> was >>>>>> missing. >>>>>>>> >>>>>>>> I don't think what you suggest really makes sense in a modular world >>>>>> because I don't think we expect to have java.desktop but not some of >> its >>>>>> native parts - so there would be no trigger to force into headless mode. >>>>>> More likely there is simply no java.desktop module at all. >>>>>>> The automatic setting of java.awt.headless has nothing to do with >>>> compact >>>>>> profiles. This support was available in JDK 7 before profiles even >> existed. >>>>>> This >>>>>>> automatic headless detection was added in order to allow Java to be >>>>>> ported to platforms that do not have a native windowing toolkit >> available. >>>>>> This was >>>>>>> used in embedded to also reduce the size of the binary by removing >> this >>>>>> big library. A configuration that contains java.desktop can absolutely be >>>>>> supported >>>>>>> and the JCK can be passed without this native library. >>>>>>> >>>>>>> This Java property is only referenced by the desktop module. This is >> why >>>> I >>>>>> suggested that this functionality be moved out of the hotspot VM. >>>>>> >>>>>> Yes we forced the AWT into headless mode if there was no native >>>> graphics >>>>>> library support available. For some of those platforms we even did this >>>>>> at build time, not via a runtime check. For SE Embedded support we >>>> would >>>>>> strip the library out at image build time, and so the runtime check >>>>>> would force AWT into headless mode. For compact profiles there is no >>>> AWT >>>>>> at all, and no native library in the built image so the runtime check >>>>>> still (vacuously) sets the property for headless mode. >>>>>> >>>>>> If you have the java.desktop module, then you have everything - there >> is >>>>>> no fragmentation of that module that I am aware of, that would allow >> you >>>>>> strip out the library that triggers os::is_headless_jre() or some other >>>>>> check that forces the AWT into headless mode. If you have >> java.desktop >>>>>> and you want headless mode then you have to ask for it explicitly. >>>>>> >>>>>> Bottom line: os::is_headless_jre() is dead code as far as I can see. >>>>>> >>>>>> Separately I'll file a bug to remove the compact profile builds. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> Bob. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> That said I was reminded that this is also used by the Compact >> Profiles >>>>>> that were added in Java 8, but for which support was removed as from >>>> Java 9 >>>>>> (and modules). However the build logic is still present, and they still use >>>> this >>>>>> functionality. I think we can remove compact profiles completely in JDK >>>> 11, >>>>>> but that's a seperate tasks. >>>>>>>> >>>>>>>> Meanwhile if we kill off the os::is_headless_jre() logic then the >>>> compact >>>>>> profiles would not default to headless mode even though they can't >> run >>>>>> headful (due to the missing native library as well as other Java APIs). >> But >>>> the >>>>>> only impact I can see there would be for running tests - and we're not >>>> testing >>>>>> compact profiles. So ... I still think this can be removed, but want to do >> a >>>>>> couple more checks. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> David >>>>>>>> >>>>>>>>> Bob. >>>>>>>>>> On Jan 23, 2018, at 5:57 AM, Baesken, Matthias >>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi David, thanks for the comments. >>>>>>>>>> >>>>>>>>>>> I'd need to do some checking but I think this may all be >> effectively >>>>>>>>>>> dead code. >>>>>>>>>> >>>>>>>>>> Please do the checking, maybe we can completely remove it. >>>>>>>>>> >>>>>>>>>> Best Regards, Matthias >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>> Sent: Dienstag, 23. Januar 2018 11:30 >>>>>>>>>>> To: Baesken, Matthias ; 'hotspot- >>>>>>>>>>> dev at openjdk.java.net' >>>>>>>>>>> Subject: Re: RFR : 8195857 : Posix platforms : move >>>>>> os::is_headless_jre check >>>>>>>>>>> coding to os::Posix and remove test for libmawt >>>>>>>>>>> >>>>>>>>>>> Hi Matthias, >>>>>>>>>>> >>>>>>>>>>> Some preliminary comments ... >>>>>>>>>>> >>>>>>>>>>> On 23/01/2018 6:24 PM, Baesken, Matthias wrote: >>>>>>>>>>>> Hello, I noticed that os::is_headless_jre() still checks on the >>>> Posix >>>>>>>>>>> platforms for libmawt which is not present any longer. >>>>>>>>>>> >>>>>>>>>>> I wonder why that comment was put in but the code not >> changed >>>> ... >>>>>>>>>>> >>>>>>>>>>>> Additionally the os::is_headless_jre() function could be put in >> a >>>>>> central >>>>>>>>>>> place at os_posix to avoid code duplication. >>>>>>>>>>> >>>>>>>>>>> I think you could simplify further and just define in os.cpp with >>>> three >>>>>>>>>>> cases: windows, OS X, posix. I normally wouldn't suggest that but >>>>>> given >>>>>>>>>>> Windows and OS X are always false, it's quite trivial. >>>>>>>>>>> >>>>>>>>>>> That said this may simplify even further because I don't know if >> the >>>>>>>>>>> concept of a headless JRE is even meaningful anymore. This >> what >>>> put >>>>>> in >>>>>>>>>>> place in 2010 to support Java SE Embedded. We had a special >> build >>>>>>>>>>> process that would remove the library from the JRE image, then >> a >>>>>> runtime >>>>>>>>>>> check os::is_headless_jre() run during argument processing, that >> if >>>>>>>>>>> true, caused the java.awt.headless property to be set to true >>>> (unless >>>>>>>>>>> already set). I don't think we can even build a "headless JRE" any >>>>>> more. >>>>>>>>>>> >>>>>>>>>>> I'd need to do some checking but I think this may all be >> effectively >>>>>>>>>>> dead code. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> ------- >>>>>>>>>>> >>>>>>>>>>>> Could you please review my change . >>>>>>>>>>>> >>>>>>>>>>>> Webrev : >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8195857/ >>>>>>>>>>>> >>>>>>>>>>>> Bug : >>>>>>>>>>>> >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8195857 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, Matthias >>>>>>>>>>>> >>>>>>> From aph at redhat.com Thu Jan 25 12:24:46 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 25 Jan 2018 12:24:46 +0000 Subject: RFR: 8196136: AArch64: Correct register use in patch for JDK-8195685 In-Reply-To: References: Message-ID: <3d345d66-47ca-246c-a894-df5e0504a591@redhat.com> On 25/01/18 11:24, Andrew Dinn wrote: > JDK-8195685 introduced aarch64 patches to complete the interface lookup > changes made in JDK-8174962. This included a patch to the generated > itable stubs which employed r0 as a scratch register. Unfortunately, > this causes problems in the very rare case where the stub fields an > interface call with 7 arguments. r0 is used to hold the 7th argument in > the stub call so the stub code corrupts the supplied argument. This > manifested in the maven setup for jcstress tests. OK, I've found the call so I can confirm the diagnosis. Interface method org.codehaus.plexus.component.configurator.converters.ConfigurationConverter.fromConfiguration( org.codehaus.plexus.component.configurator.converters.lookup.ConverterLookup, org.codehaus.plexus.configuration.PlexusConfiguration, java.lang.Class, java.lang.Class, java.lang.ClassLoader, org.codehaus.plexus.component.configurator.expression.ExpressionEvaluator, org.codehaus.plexus.component.configurator.ConfigurationListener) is called from org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure( org.codehaus.plexus.configuration.PlexusConfiguration, java.lang.ClassLoader, org.codehaus.plexus.component.configurator.expression.ExpressionEvaluator) fromConfiguration has 8 args (7 + this) and the arg which gets corrupted is indeed ComponentValueSetter.listener, Argument 8 in the call. I can see this in the debugger: org.codehaus.plexus.component.configurator.converters.ComponentValueSetter {0x00000007219346c0} - klass: 'org/codehaus/plexus/component/configurator/converters/ComponentValueSetter' - ---- fields (total size 8 words): - private final 'object' 'Ljava/lang/Object;' @12 a 'org/apache/maven/plugins/shade/resource/ManifestResourceTransformer'{0x00000007219346a0} (e43268d4 e4326922) - private final 'fieldName' 'Ljava/lang/String;' @16 "mainClass"{0x0000000721934910} (e4326922 dfce3c71) - private final 'lookup' 'Lorg/codehaus/plexus/component/configurator/converters/lookup/ConverterLookup;' @20 a 'org/codehaus/plexus/component/configurator/converters/lookup/DefaultConverterLookup'{0x00000006fe71e388} (dfce3c71 0) - private 'setter' 'Ljava/lang/reflect/Method;' @24 NULL (0 0) - private 'setterParamType' 'Ljava/lang/Class;' @28 NULL (0 0) - private 'setterTypeConverter' 'Lorg/codehaus/plexus/component/configurator/converters/ConfigurationConverter;' @32 NULL (0 0) - private 'setterTypeArguments' '[Ljava/lang/reflect/Type;' @36 NULL (0 e4326aa9) - private 'field' 'Ljava/lang/reflect/Field;' @40 a 'java/lang/reflect/Field'{0x0000000721935548} (e4326aa9 dfc08605) - private 'fieldType' 'Ljava/lang/Class;' @44 a 'java/lang/Class'{0x00000006fe043028} = 'java/lang/String' (dfc08605 dfce3c9a) - private 'fieldTypeConverter' 'Lorg/codehaus/plexus/component/configurator/converters/ConfigurationConverter;' @48 a 'org/codehaus/plexus/component/configurator/converters/basic/StringConverter'{0x00000006fe71e4d0} (dfce3c9a 0) - private 'fieldTypeArguments' '[Ljava/lang/reflect/Type;' @52 NULL (0 3f99b) - private final 'listener' 'Lorg/codehaus/plexus/component/configurator/ConfigurationListener;' @56 Program received signal SIGSEGV, Segmentation fault. Good catch! -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Thu Jan 25 13:10:22 2018 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 25 Jan 2018 13:10:22 +0000 Subject: RFR: 8195859: AArch64: vtableStubs gtest fails after 8174962 Message-ID: <3ce91e13-5465-62ec-6da7-038503bb3962@redhat.com> This new gtest exercises the i/vtable lookup code using very large table indexes. This causes a test failure on AArch64 when the vtable offset is too large to use as an immmediate literal in an ldr instruction (the assembler barfs). This patch fixes the problem by using a load constant and indirect register load in cases where the offset is to large for a load immediate. jira: https://bugs.openjdk.java.net/browse/JDK-8195859 webrev: http://cr.openjdk.java.net/~adinn/8195859/ Reviews welcome. Testing: The fix ensures that the test now passes. The JIRA is marked with fix-version 11. I'm not really sure if it also needs to be in 10 but I think it probably does -- because a class with a suitably large number of methods could cause an itable or vtable lookup to fail. Opinions from reviewers would be welcome. 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 aph at redhat.com Thu Jan 25 13:22:53 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 25 Jan 2018 13:22:53 +0000 Subject: RFR: 8195859: AArch64: vtableStubs gtest fails after 8174962 In-Reply-To: <3ce91e13-5465-62ec-6da7-038503bb3962@redhat.com> References: <3ce91e13-5465-62ec-6da7-038503bb3962@redhat.com> Message-ID: On 25/01/18 13:10, Andrew Dinn wrote: > Reviews welcome. Can you use MacroAssembler::form_address instead? That'd be much cleaner. > Testing: > > The fix ensures that the test now passes. > > The JIRA is marked with fix-version 11. I'm not really sure if it also > needs to be in 10 but I think it probably does -- because a class with a > suitably large number of methods could cause an itable or vtable lookup > to fail. Opinions from reviewers would be welcome. I guess it should be. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From david.lloyd at redhat.com Thu Jan 25 14:59:29 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 25 Jan 2018 08:59:29 -0600 Subject: Reserving an extra slot on the stack Message-ID: For an experiment I'm working on, I'd like to modify the JVM to reserve one reference-sized slot (which eventually should be visible to GC) on every stack frame at a fixed well-known offset (such that I can reach it via Unsafe from Java-space). But it appears that the stack layout code is pretty deep in per-CPU areas. Is there a generic mechanism that I've missed? Like some way to make the compiler act as if there were one extra local variable or something like that? -- - DML From coleen.phillimore at oracle.com Thu Jan 25 15:12:11 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 25 Jan 2018 10:12:11 -0500 Subject: Reserving an extra slot on the stack In-Reply-To: References: Message-ID: On 1/25/18 9:59 AM, David Lloyd wrote: > For an experiment I'm working on, I'd like to modify the JVM to > reserve one reference-sized slot (which eventually should be visible > to GC) on every stack frame at a fixed well-known offset (such that I > can reach it via Unsafe from Java-space). But it appears that the > stack layout code is pretty deep in per-CPU areas. Yes. > Is there a generic > mechanism that I've missed? Like some way to make the compiler act as > if there were one extra local variable or something like that? No.?? The mirror is stored in the interpreter stack frame at a fixed offset so maybe you can use that as a model. Coleen > From aph at redhat.com Thu Jan 25 15:13:46 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 25 Jan 2018 15:13:46 +0000 Subject: Reserving an extra slot on the stack In-Reply-To: References: Message-ID: <2b9d617c-479a-2b71-38b2-bd128bb5ce96@redhat.com> On 25/01/18 14:59, David Lloyd wrote: > For an experiment I'm working on, I'd like to modify the JVM to > reserve one reference-sized slot (which eventually should be visible > to GC) on every stack frame at a fixed well-known offset (such that I > can reach it via Unsafe from Java-space). But it appears that the > stack layout code is pretty deep in per-CPU areas. Is there a generic > mechanism that I've missed? Like some way to make the compiler act as > if there were one extra local variable or something like that? Each compiler does its own stack layout. The only thing that's fixed is the calling convention. To make this work you'd need to change C1, C2, and the template interpreter. As it happens, the interpreter has an unused slot on most architectures, so you can have that for free. Do you actually need to test your experiment with C1 and C2? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Thu Jan 25 15:19:38 2018 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 25 Jan 2018 15:19:38 +0000 Subject: Reserving an extra slot on the stack In-Reply-To: References: Message-ID: <1a06d261-cb5b-4949-a221-ed79fe0249ee@redhat.com> On 25/01/18 14:59, David Lloyd wrote: > For an experiment I'm working on, I'd like to modify the JVM to > reserve one reference-sized slot (which eventually should be visible > to GC) on every stack frame at a fixed well-known offset (such that I > can reach it via Unsafe from Java-space). But it appears that the > stack layout code is pretty deep in per-CPU areas. Is there a generic > mechanism that I've missed? Like some way to make the compiler act as > if there were one extra local variable or something like that? Not really. Stack layouts are, of necessity, quite tightly coupled to the underlying cpu and os. Can you explain what you are trying to achieve so we might perhaps be able better to advise on how to get there? There are so many gotchas in the area of GC operation and stack frame management that questions like "can I modify mechanism X" (where X relates to either or both topics) are very hard to answer. It is much easier to scope and determine a complete and correct response to questions like "can I achieve goal Y". 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 Thu Jan 25 15:22:26 2018 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 25 Jan 2018 15:22:26 +0000 Subject: RFR: 8195859: AArch64: vtableStubs gtest fails after 8174962 In-Reply-To: References: <3ce91e13-5465-62ec-6da7-038503bb3962@redhat.com> Message-ID: <85574d0b-c964-e83a-d8e1-6a67ea863d1c@redhat.com> On 25/01/18 13:22, Andrew Haley wrote: > On 25/01/18 13:10, Andrew Dinn wrote: >> Reviews welcome. > > Can you use MacroAssembler::form_address instead? That'd be > much cleaner. Ooh, nice. I didn't know that existed. Revised and retested version webrev: http://cr.openjdk.java.net/~adinn/8195859/webrev.02/ >> The JIRA is marked with fix-version 11. I'm not really sure if it also >> needs to be in 10 but I think it probably does -- because a class with a >> suitably large number of methods could cause an itable or vtable lookup >> to fail. Opinions from reviewers would be welcome. > > I guess it should be. Ok, I will update the JIRA accordingly to request (late) inclusion in jdk10. 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.lloyd at redhat.com Thu Jan 25 15:22:43 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 25 Jan 2018 09:22:43 -0600 Subject: Reserving an extra slot on the stack In-Reply-To: <1a06d261-cb5b-4949-a221-ed79fe0249ee@redhat.com> References: <1a06d261-cb5b-4949-a221-ed79fe0249ee@redhat.com> Message-ID: On Thu, Jan 25, 2018 at 9:19 AM, Andrew Dinn wrote: > On 25/01/18 14:59, David Lloyd wrote: >> For an experiment I'm working on, I'd like to modify the JVM to >> reserve one reference-sized slot (which eventually should be visible >> to GC) on every stack frame at a fixed well-known offset (such that I >> can reach it via Unsafe from Java-space). But it appears that the >> stack layout code is pretty deep in per-CPU areas. Is there a generic >> mechanism that I've missed? Like some way to make the compiler act as >> if there were one extra local variable or something like that? > Not really. Stack layouts are, of necessity, quite tightly coupled to > the underlying cpu and os. > > Can you explain what you are trying to achieve so we might perhaps be > able better to advise on how to get there? There are so many gotchas in > the area of GC operation and stack frame management that questions like > "can I modify mechanism X" (where X relates to either or both topics) > are very hard to answer. It is much easier to scope and determine a > complete and correct response to questions like "can I achieve goal Y". Essentially it's a one-reference cache for code which otherwise has to iterate the stack (likely frequently). The use area is the experimental pure-Java AccessController implementation I'm working on [1]. [1] http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html -- - DML From david.lloyd at redhat.com Thu Jan 25 15:23:13 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 25 Jan 2018 09:23:13 -0600 Subject: Reserving an extra slot on the stack In-Reply-To: <2b9d617c-479a-2b71-38b2-bd128bb5ce96@redhat.com> References: <2b9d617c-479a-2b71-38b2-bd128bb5ce96@redhat.com> Message-ID: On Thu, Jan 25, 2018 at 9:13 AM, Andrew Haley wrote: > On 25/01/18 14:59, David Lloyd wrote: >> For an experiment I'm working on, I'd like to modify the JVM to >> reserve one reference-sized slot (which eventually should be visible >> to GC) on every stack frame at a fixed well-known offset (such that I >> can reach it via Unsafe from Java-space). But it appears that the >> stack layout code is pretty deep in per-CPU areas. Is there a generic >> mechanism that I've missed? Like some way to make the compiler act as >> if there were one extra local variable or something like that? > > Each compiler does its own stack layout. The only thing that's fixed > is the calling convention. To make this work you'd need to change C1, > C2, and the template interpreter. As it happens, the interpreter has > an unused slot on most architectures, so you can have that for free. > Do you actually need to test your experiment with C1 and C2? Eventually, yes: the cache would exist for performance purposes, so I'd want to ensure that performance is actually improved. -- - DML From david.lloyd at redhat.com Thu Jan 25 15:23:53 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 25 Jan 2018 09:23:53 -0600 Subject: Reserving an extra slot on the stack In-Reply-To: References: Message-ID: On Thu, Jan 25, 2018 at 9:12 AM, wrote: > On 1/25/18 9:59 AM, David Lloyd wrote: >> mechanism that I've missed? Like some way to make the compiler act as >> if there were one extra local variable or something like that? > > No. The mirror is stored in the interpreter stack frame at a fixed offset > so maybe you can use that as a model. Thanks for the info, I'll look into it. -- - DML From aph at redhat.com Thu Jan 25 15:41:32 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 25 Jan 2018 15:41:32 +0000 Subject: RFR: 8195859: AArch64: vtableStubs gtest fails after 8174962 In-Reply-To: <85574d0b-c964-e83a-d8e1-6a67ea863d1c@redhat.com> References: <3ce91e13-5465-62ec-6da7-038503bb3962@redhat.com> <85574d0b-c964-e83a-d8e1-6a67ea863d1c@redhat.com> Message-ID: <269bdea2-7c4e-da11-5a19-58a008745dbd@redhat.com> On 25/01/18 15:22, Andrew Dinn wrote: > Revised and retested version > > webrev: http://cr.openjdk.java.net/~adinn/8195859/webrev.02/ OK, thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Jan 25 15:48:22 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 25 Jan 2018 15:48:22 +0000 Subject: Reserving an extra slot on the stack In-Reply-To: References: <2b9d617c-479a-2b71-38b2-bd128bb5ce96@redhat.com> Message-ID: <204a76ca-4478-deff-650e-0f36667b7fac@redhat.com> On 25/01/18 15:23, David Lloyd wrote: > On Thu, Jan 25, 2018 at 9:13 AM, Andrew Haley wrote: >> On 25/01/18 14:59, David Lloyd wrote: >>> For an experiment I'm working on, I'd like to modify the JVM to >>> reserve one reference-sized slot (which eventually should be visible >>> to GC) on every stack frame at a fixed well-known offset (such that I >>> can reach it via Unsafe from Java-space). But it appears that the >>> stack layout code is pretty deep in per-CPU areas. Is there a generic >>> mechanism that I've missed? Like some way to make the compiler act as >>> if there were one extra local variable or something like that? >> >> Each compiler does its own stack layout. The only thing that's fixed >> is the calling convention. To make this work you'd need to change C1, >> C2, and the template interpreter. As it happens, the interpreter has >> an unused slot on most architectures, so you can have that for free. >> Do you actually need to test your experiment with C1 and C2? > > Eventually, yes: the cache would exist for performance purposes, so > I'd want to ensure that performance is actually improved. So every frame has an extra slot, and you want that slot to be easy to find. That's trivial to do in the interpreter and not terribly hard in C1, slightly harder in C2. The easiest thing to do would be to add a fixed slot just beneath the return address in the compiler code. On x86 and AArch64, the return address is stashed at the very highest address in the frame. You can fairly easily tweak the code that builds and tears down the method context to adjust the size. None of this can be done in portable code, though: you'll have to tweak the back end. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From mikhailo.seledtsov at oracle.com Thu Jan 25 17:42:33 2018 From: mikhailo.seledtsov at oracle.com (mikhailo) Date: Thu, 25 Jan 2018 09:42:33 -0800 Subject: RFR : 8196062 : Enable docker container related tests for linux ppc64le In-Reply-To: <6fa3fe84aad946eabb2b46281031e21d@sap.com> References: <3374db8c-6e7b-fe0b-6874-8289e9e369bc@oracle.com> <6fa3fe84aad946eabb2b46281031e21d@sap.com> Message-ID: <4be36ed6-2f8e-2dd8-a87a-5f76d639550e@oracle.com> Hi Matthias, On 01/25/2018 12:15 AM, Baesken, Matthias wrote: >> Perhaps, you could add code to DockerTestUtils.buildJdkDockerImage() >> that does the following or similar: >> 1. Construct a name for platform-specific docker file: >> String platformSpecificDockerfile = dockerfile + "-" + >> Platform.getOsArch(); >> (Platform is jdk.test.lib.Platform) >> > Hello, the doc says : > > * Build a docker image that contains JDK under test. > * The jdk will be placed under the "/jdk/" folder inside the docker file system. > ..... > param dockerfile name of the dockerfile residing in the test source > ..... > public static void buildJdkDockerImage(String imageName, String dockerfile, String buildDirName) > > > > It does not say anything about doing hidden insertions of some platform names into the dockerfile name. > So should the jtreg API doc be changed ? > If so who needs to approve this ? Thank you for your concerns about the clarity of API and corresponding documentation. This is a test library API, so no need to file CCC or CSR. This API can be changed via a regular RFR/webrev review process, as soon as on one objects. I am a VM SQE engineer covering the docker and Linux container area, I am OK with this change. And I agree with you, we should update the javadoc header on this method to reflect this implicit part of API contract. Thank you, Misha > (as far as I see so far only the test at hotspot/jtreg/runtime/containers/docker/ use this so it should not be a big deal to change the interface?) > > Best regards, Matthias > > > > >> -----Original Message----- >> From: mikhailo [mailto:mikhailo.seledtsov at oracle.com] >> Sent: Mittwoch, 24. Januar 2018 20:09 >> To: Bob Vandette ; Baesken, Matthias >> >> Cc: hotspot-dev at openjdk.java.net; Lindenmaier, Goetz >> ; Langer, Christoph >> ; Doerr, Martin >> Subject: Re: RFR : 8196062 : Enable docker container related tests for linux >> ppc64le >> >> Hi Matthias, >> >> ?? Please see my comments about the test changes inline. >> >> >> On 01/24/2018 07:13 AM, Bob Vandette wrote: >>> osContainer_linux.cpp: >>> >>> Can you add "return;" in each test for subsystem not found messages and >>> remove these 3 lines OR move your tests for NULL & messages inside. The >> compiler can >>> probably optimize this but I?d prefer more compact code. >>> >>> if (memory == NULL || cpuset == NULL || cpu == NULL || cpuacct == NULL) >> { >>> 342 return; >>> 343 } >>> >>> >>> The other changes in osContainer_linux.cpp look ok. >>> >>> I forwarded your test changes to Misha, who wrote these. >>> >>> Since it?s likely that other platforms, such as aarch64, are going to run into >> the same problem, >>> It would have been better to enable the tests based on the existence of an >> arch specific >>> Dockerfile-BasicTest-{os.arch} rather than enabling specific arch?s in >> VPProps.java. >>> This approach would reduce the number of changes significantly and allow >> support to >>> be added with 1 new file. >>> >>> You wouldn?t need "String dockerFileName = >> Common.getDockerFileName();? >>> in every test. Just make DockerTestUtils automatically add arch. >> I like Bob's idea on handling platform-specific Dockerfiles. >> >> Perhaps, you could add code to DockerTestUtils.buildJdkDockerImage() >> that does the following or similar: >> ??? 1. Construct a name for platform-specific docker file: >> ?????????? String platformSpecificDockerfile = dockerfile + "-" + >> Platform.getOsArch(); >> ?????????? (Platform is jdk.test.lib.Platform) >> >> ??? 2. Check if platformSpecificDockerfile file exists in the test >> source directory >> ????????? File.exists(Paths.get(Utils.TEST_SRC, platformSpecificDockerFile) >> ????????? If it does, then use it. Otherwise continue using the >> default/original dockerfile name. >> >> I think this will considerably simplify your change, as well as make it >> easy to extend support to other platforms/configurations >> in the future. Let us know what you think of this approach ? >> >> >> Once your change gets (R)eviewed and approved, I can sponsor the push. >> >> >> Thank you, >> Misha >> >> >> >>> Bob. >>> >>> >>> >>>> On Jan 24, 2018, at 9:24 AM, Baesken, Matthias >> wrote: >>>> Hello, could you please review the following change : 8196062 : Enable >> docker container related tests for linux ppc64le . >>>> It adds docker container testing for linux ppc64 le (little endian) . >>>> >>>> A number of things had to be done : >>>> ? Add a separate docker file >> test/hotspot/jtreg/runtime/containers/docker/Dockerfile-BasicTest-ppc64le >> for linux ppc64 le which uses Ubuntu ( the Oracle Linux 7.2 used for >> x86_64 seems not to be available for ppc64le ) >>>> ? Fix parsing /proc/self/mountinfo and /proc/self/cgroup in >> src/hotspot/os/linux/osContainer_linux.cpp , it could not handle the >> format seen on SUSE LINUX 12.1 ppc64le (Host) and Ubuntu (Docker >> container) >>>> ? Add a bit more logging >>>> >>>> >>>> Webrev : >>>> >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8196062/ >>>> >>>> >>>> Bug : >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8196062 >>>> >>>> >>>> After these adjustments I could run the runtime/containers/docker - >> jtreg tests successfully . >>>> >>>> Best regards, Matthias From thomas.schatzl at oracle.com Thu Jan 25 17:57:47 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 25 Jan 2018 18:57:47 +0100 Subject: RFR: 8195621: JTReg failure in gc/g1/TestLargePageUseForAuxMemory.java In-Reply-To: References: <9db53780099e44d4a60ff8bf4944a657@NASANEXM01E.na.qualcomm.com> <72d9ad5d97c842608633c114f2c0b227@NASANEXM01E.na.qualcomm.com> <1516785399.2365.7.camel@oracle.com> Message-ID: <1516903067.3223.2.camel@oracle.com> Hi, On Wed, 2018-01-24 at 19:03 +0000, stewartd.qdt wrote: > Looking at the test, I think we can remove the -Xms flags from the > test. In doing this, the test passes and it still seems to generate > the right page sizes, which appears to be what the test was looking > for. > Yeah, the test was only verifying the internal calculation. No actual work is done by the VM. > I have updated the webrev: > http://cr.openjdk.java.net/~dstewart/8195621/webrev.01/ > > Please let me know if this is acceptable. > Fine with me. I can sponsor, I will wait a bit for the other participants in this thread to eventually respond. Thanks, Thomas From thomas.stuefe at gmail.com Thu Jan 25 18:00:15 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 25 Jan 2018 19:00:15 +0100 Subject: RFR: 8195621: JTReg failure in gc/g1/TestLargePageUseForAuxMemory.java In-Reply-To: <1516903067.3223.2.camel@oracle.com> References: <9db53780099e44d4a60ff8bf4944a657@NASANEXM01E.na.qualcomm.com> <72d9ad5d97c842608633c114f2c0b227@NASANEXM01E.na.qualcomm.com> <1516785399.2365.7.camel@oracle.com> <1516903067.3223.2.camel@oracle.com> Message-ID: +1 Regards, Thomas On Thu, Jan 25, 2018 at 6:57 PM, Thomas Schatzl wrote: > Hi, > > On Wed, 2018-01-24 at 19:03 +0000, stewartd.qdt wrote: > > Looking at the test, I think we can remove the -Xms flags from the > > test. In doing this, the test passes and it still seems to generate > > the right page sizes, which appears to be what the test was looking > > for. > > > > Yeah, the test was only verifying the internal calculation. No actual > work is done by the VM. > > > I have updated the webrev: > > http://cr.openjdk.java.net/~dstewart/8195621/webrev.01/ > > > > Please let me know if this is acceptable. > > > > Fine with me. I can sponsor, I will wait a bit for the other > participants in this thread to eventually respond. > > Thanks, > Thomas > > From coleen.phillimore at oracle.com Fri Jan 26 16:44:01 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 26 Jan 2018 11:44:01 -0500 Subject: RFR 8153783: UnlockDiagnosticVMOptions should not be trueInDebug Message-ID: Summary: Make default false in all builds like UnlockExperimentalVMOptions and fix tests. Ran all jtreg hotspot tests and jdk/java/lang tests, and sun.misc. There's some compiler test that I fixed. Please check if I did this right: TestPrintPreciseRTMLockingStatisticsBase.java. open webrev at http://cr.openjdk.java.net/~coleenp/8153783.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8153783 Thanks, Coleen From harold.seigel at oracle.com Fri Jan 26 16:47:41 2018 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 26 Jan 2018 11:47:41 -0500 Subject: RFR 8153783: UnlockDiagnosticVMOptions should not be trueInDebug In-Reply-To: References: Message-ID: Hi Coleen, That looks good. Thanks, Harold On 1/26/2018 11:44 AM, coleen.phillimore at oracle.com wrote: > Summary: Make default false in all builds like > UnlockExperimentalVMOptions and fix tests. > > Ran all jtreg hotspot tests and jdk/java/lang tests, and sun.misc. > There's some compiler test that I fixed. Please check if I did this > right: > TestPrintPreciseRTMLockingStatisticsBase.java. > > open webrev at http://cr.openjdk.java.net/~coleenp/8153783.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8153783 > > Thanks, > Coleen From adinn at redhat.com Fri Jan 26 17:26:50 2018 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 26 Jan 2018 17:26:50 +0000 Subject: RFR: 8196221: AArch64: Mistake in committed patch for JDK-8195859 Message-ID: <44f0459a-0c32-6b9e-9324-418616a69f97@redhat.com> Apologies in advance -- I'm really not having a very good week ... The patch submitted for review for 8195859 )and, worse, committed to the dev jdk and jdk10 repos) was not the one applied to the test JVM. It omitted a call argument. As a consequence my testing succeeded but the AArch64 build is still broken and in need of update -- both the dev jdk tree and jdk10. The following extra patch inserts the extra argument in the offending call. jira: https://bugs.openjdk.java.net/browse/JDK-8196221 webrev: http://cr.openjdk.java.net/~adinn/8196221/webrev/ Testing: As per 8195859 i.e. the gtest now succeeds and standard java programs work. But ... this time the submitted patch was definitely the one used to update the dev jdk and jdk10 test JVMs which passed the tests. 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 aph at redhat.com Fri Jan 26 17:36:08 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 26 Jan 2018 17:36:08 +0000 Subject: [aarch64-port-dev ] RFR: 8196221: AArch64: Mistake in committed patch for JDK-8195859 In-Reply-To: <44f0459a-0c32-6b9e-9324-418616a69f97@redhat.com> References: <44f0459a-0c32-6b9e-9324-418616a69f97@redhat.com> Message-ID: On 26/01/18 17:26, Andrew Dinn wrote: > jira: https://bugs.openjdk.java.net/browse/JDK-8196221 > webrev: http://cr.openjdk.java.net/~adinn/8196221/webrev/ OK, thanks. :-) -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From vladimir.kozlov at oracle.com Fri Jan 26 19:41:52 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 26 Jan 2018 11:41:52 -0800 Subject: RFR: 8196221: AArch64: Mistake in committed patch for JDK-8195859 In-Reply-To: <44f0459a-0c32-6b9e-9324-418616a69f97@redhat.com> References: <44f0459a-0c32-6b9e-9324-418616a69f97@redhat.com> Message-ID: Hi Andrew, Please, follow fix request process for jdk 10 if you want to push this into jdk10: http://openjdk.java.net/projects/jdk/10/fix-request-process Vladimir On 1/26/18 9:26 AM, Andrew Dinn wrote: > Apologies in advance -- I'm really not having a very good week ... > > The patch submitted for review for 8195859 )and, worse, committed to the > dev jdk and jdk10 repos) was not the one applied to the test JVM. It > omitted a call argument. As a consequence my testing succeeded but the > AArch64 build is still broken and in need of update -- both the dev jdk > tree and jdk10. > > The following extra patch inserts the extra argument in the offending call. > > jira: https://bugs.openjdk.java.net/browse/JDK-8196221 > webrev: http://cr.openjdk.java.net/~adinn/8196221/webrev/ > > Testing: > > As per 8195859 i.e. the gtest now succeeds and standard java programs > work. But ... this time the submitted patch was definitely the one used > to update the dev jdk and jdk10 test JVMs which passed the tests. > > 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 Fri Jan 26 19:39:50 2018 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 26 Jan 2018 14:39:50 -0500 Subject: RFR 8153783: UnlockDiagnosticVMOptions should not be trueInDebug In-Reply-To: References: Message-ID: <4c9b05a2-f8a5-d525-56f0-c25a54f8fada@oracle.com> Looks good. Lois On 1/26/2018 11:44 AM, coleen.phillimore at oracle.com wrote: > Summary: Make default false in all builds like > UnlockExperimentalVMOptions and fix tests. > > Ran all jtreg hotspot tests and jdk/java/lang tests, and sun.misc. > There's some compiler test that I fixed. Please check if I did this > right: > TestPrintPreciseRTMLockingStatisticsBase.java. > > open webrev at http://cr.openjdk.java.net/~coleenp/8153783.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8153783 > > Thanks, > Coleen From daniel.daugherty at oracle.com Fri Jan 26 20:19:12 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 26 Jan 2018 15:19:12 -0500 Subject: RFR 8153783: UnlockDiagnosticVMOptions should not be trueInDebug In-Reply-To: References: Message-ID: <45b2d4ed-d55e-5163-9eb6-eee58be7c04c@oracle.com> On 1/26/18 11:44 AM, coleen.phillimore at oracle.com wrote: > Summary: Make default false in all builds like > UnlockExperimentalVMOptions and fix tests. > > Ran all jtreg hotspot tests and jdk/java/lang tests, and sun.misc. > There's some compiler test that I fixed. Please check if I did this > right: > TestPrintPreciseRTMLockingStatisticsBase.java. > > open webrev at http://cr.openjdk.java.net/~coleenp/8153783.01/webrev src/hotspot/share/runtime/globals.hpp ??? No comments. test/hotspot/jtreg/compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsBase.java ??? No comments. Messy test, but I think it is correct. test/hotspot/jtreg/runtime/Unsafe/RangeCheck.java ??? No comments. test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java ??? No comments. test/hotspot/jtreg/runtime/handshake/HandshakeTransitionTest.java ??? No comments. Thumbs up on the code! The meta question is, of course, that this changes things for folks that use non-product builds on a daily basis. Personally, I like the idea of removing one more annoying difference between 'release' and 'fastdebug' bits. Yes, that means I have to remember to to include -XX:+UnlockDiagnosticVMOptions but I typically run things from scripts so I've been training myself to always include that option when I'm setting a script for bug hunt. So this change in behavior isn't a big deal for me. Dan > bug link https://bugs.openjdk.java.net/browse/JDK-8153783 > > Thanks, > Coleen > From coleen.phillimore at oracle.com Fri Jan 26 21:08:51 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 26 Jan 2018 16:08:51 -0500 Subject: RFR 8153783: UnlockDiagnosticVMOptions should not be trueInDebug In-Reply-To: <45b2d4ed-d55e-5163-9eb6-eee58be7c04c@oracle.com> References: <45b2d4ed-d55e-5163-9eb6-eee58be7c04c@oracle.com> Message-ID: <0e7a8b88-dd2c-763f-169e-f869406c85dd@oracle.com> Thanks Dan, Lois and Harold for the code reviews. We're still trying to answer the meta-question of whether we want to use this option in day to day development, when using flags like VerifyDuringGC, and PrintNMethods, vs. having diagnostic options added to tests or sent to other parties missing the necessary -XX:+UnlockDiagnosticVMOptions. Thanks, Coleen On 1/26/18 3:19 PM, Daniel D. Daugherty wrote: > On 1/26/18 11:44 AM, coleen.phillimore at oracle.com wrote: >> Summary: Make default false in all builds like >> UnlockExperimentalVMOptions and fix tests. >> >> Ran all jtreg hotspot tests and jdk/java/lang tests, and sun.misc. >> There's some compiler test that I fixed. Please check if I did this >> right: >> TestPrintPreciseRTMLockingStatisticsBase.java. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8153783.01/webrev > > src/hotspot/share/runtime/globals.hpp > ??? No comments. > > test/hotspot/jtreg/compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsBase.java > > ??? No comments. Messy test, but I think it is correct. > > test/hotspot/jtreg/runtime/Unsafe/RangeCheck.java > ??? No comments. > > test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java > ??? No comments. > > test/hotspot/jtreg/runtime/handshake/HandshakeTransitionTest.java > ??? No comments. > > Thumbs up on the code! > > The meta question is, of course, that this changes things for folks that > use non-product builds on a daily basis. Personally, I like the idea of > removing one more annoying difference between 'release' and 'fastdebug' > bits. > > Yes, that means I have to remember to to include > -XX:+UnlockDiagnosticVMOptions > but I typically run things from scripts so I've been training myself > to always > include that option when I'm setting a script for bug hunt. So this > change in > behavior isn't a big deal for me. > > Dan > > >> bug link https://bugs.openjdk.java.net/browse/JDK-8153783 >> >> Thanks, >> Coleen >> > From vladimir.x.ivanov at oracle.com Fri Jan 26 21:41:44 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 26 Jan 2018 13:41:44 -0800 Subject: RFR 8153783: UnlockDiagnosticVMOptions should not be trueInDebug In-Reply-To: <0e7a8b88-dd2c-763f-169e-f869406c85dd@oracle.com> References: <45b2d4ed-d55e-5163-9eb6-eee58be7c04c@oracle.com> <0e7a8b88-dd2c-763f-169e-f869406c85dd@oracle.com> Message-ID: <56cd296a-c4e0-2388-c570-d409786d7ecb@oracle.com> As for me, I'd prefer to leave it as is. I use debug builds on daily basis and requiring to specify -XX:+UnlockDiagnosticVMOptions would add observable overhead into my development workflow. IMO missing -XX:+UnlockDiagnosticVMOptions in a test manifests more serious issue it is proposed to fix: the test was never run with product binaries and we shouldn't try to hide that by unifying flag's default value between product & debug binaries. And it's not a theoretical possibility: I regularly run into slight differences in behavior between product & fastdebug binaries while writing (and testing externally contributed) JIT-compiler regression tests which cause failures. Best regards, Vladimir Ivanov On 1/26/18 1:08 PM, coleen.phillimore at oracle.com wrote: > > Thanks Dan, Lois and Harold for the code reviews. > > We're still trying to answer the meta-question of whether we want to use > this option in day to day development, when using flags like > VerifyDuringGC, and PrintNMethods, vs. having diagnostic options added > to tests or sent to other parties missing the necessary > -XX:+UnlockDiagnosticVMOptions. > > Thanks, > Coleen > > > On 1/26/18 3:19 PM, Daniel D. Daugherty wrote: >> On 1/26/18 11:44 AM, coleen.phillimore at oracle.com wrote: >>> Summary: Make default false in all builds like >>> UnlockExperimentalVMOptions and fix tests. >>> >>> Ran all jtreg hotspot tests and jdk/java/lang tests, and sun.misc. >>> There's some compiler test that I fixed. Please check if I did this >>> right: >>> TestPrintPreciseRTMLockingStatisticsBase.java. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8153783.01/webrev >> >> src/hotspot/share/runtime/globals.hpp >> ??? No comments. >> >> test/hotspot/jtreg/compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsBase.java >> >> ??? No comments. Messy test, but I think it is correct. >> >> test/hotspot/jtreg/runtime/Unsafe/RangeCheck.java >> ??? No comments. >> >> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java >> ??? No comments. >> >> test/hotspot/jtreg/runtime/handshake/HandshakeTransitionTest.java >> ??? No comments. >> >> Thumbs up on the code! >> >> The meta question is, of course, that this changes things for folks that >> use non-product builds on a daily basis. Personally, I like the idea of >> removing one more annoying difference between 'release' and 'fastdebug' >> bits. >> >> Yes, that means I have to remember to to include >> -XX:+UnlockDiagnosticVMOptions >> but I typically run things from scripts so I've been training myself >> to always >> include that option when I'm setting a script for bug hunt. So this >> change in >> behavior isn't a big deal for me. >> >> Dan >> >> >>> bug link https://bugs.openjdk.java.net/browse/JDK-8153783 >>> >>> Thanks, >>> Coleen >>> >> > From stefan.karlsson at oracle.com Fri Jan 26 21:58:42 2018 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 26 Jan 2018 22:58:42 +0100 Subject: RFR 8153783: UnlockDiagnosticVMOptions should not be trueInDebug In-Reply-To: <56cd296a-c4e0-2388-c570-d409786d7ecb@oracle.com> References: <45b2d4ed-d55e-5163-9eb6-eee58be7c04c@oracle.com> <0e7a8b88-dd2c-763f-169e-f869406c85dd@oracle.com> <56cd296a-c4e0-2388-c570-d409786d7ecb@oracle.com> Message-ID: <121de797-5245-7db1-cab2-be6e428e39e9@oracle.com> On 2018-01-26 22:41, Vladimir Ivanov wrote: > As for me, I'd prefer to leave it as is. > > I use debug builds on daily basis and requiring to specify > -XX:+UnlockDiagnosticVMOptions would add observable overhead > into my development workflow. I agree. StefanK > > IMO missing -XX:+UnlockDiagnosticVMOptions in a test manifests more > serious issue it is proposed to fix: the test was never run with > product binaries and we shouldn't try to hide that by unifying flag's > default value between product & debug binaries. > > And it's not a theoretical possibility: I regularly run into slight > differences in behavior between product & fastdebug binaries while > writing (and testing externally contributed) JIT-compiler regression > tests which cause failures. > > Best regards, > Vladimir Ivanov > > On 1/26/18 1:08 PM, coleen.phillimore at oracle.com wrote: >> >> Thanks Dan, Lois and Harold for the code reviews. >> >> We're still trying to answer the meta-question of whether we want to >> use this option in day to day development, when using flags like >> VerifyDuringGC, and PrintNMethods, vs. having diagnostic options >> added to tests or sent to other parties missing the necessary >> -XX:+UnlockDiagnosticVMOptions. >> >> Thanks, >> Coleen >> >> >> On 1/26/18 3:19 PM, Daniel D. Daugherty wrote: >>> On 1/26/18 11:44 AM, coleen.phillimore at oracle.com wrote: >>>> Summary: Make default false in all builds like >>>> UnlockExperimentalVMOptions and fix tests. >>>> >>>> Ran all jtreg hotspot tests and jdk/java/lang tests, and sun.misc. >>>> There's some compiler test that I fixed. Please check if I did this >>>> right: >>>> TestPrintPreciseRTMLockingStatisticsBase.java. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8153783.01/webrev >>> >>> src/hotspot/share/runtime/globals.hpp >>> ??? No comments. >>> >>> test/hotspot/jtreg/compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsBase.java >>> >>> ??? No comments. Messy test, but I think it is correct. >>> >>> test/hotspot/jtreg/runtime/Unsafe/RangeCheck.java >>> ??? No comments. >>> >>> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java >>> ??? No comments. >>> >>> test/hotspot/jtreg/runtime/handshake/HandshakeTransitionTest.java >>> ??? No comments. >>> >>> Thumbs up on the code! >>> >>> The meta question is, of course, that this changes things for folks >>> that >>> use non-product builds on a daily basis. Personally, I like the idea of >>> removing one more annoying difference between 'release' and 'fastdebug' >>> bits. >>> >>> Yes, that means I have to remember to to include >>> -XX:+UnlockDiagnosticVMOptions >>> but I typically run things from scripts so I've been training myself >>> to always >>> include that option when I'm setting a script for bug hunt. So this >>> change in >>> behavior isn't a big deal for me. >>> >>> Dan >>> >>> >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8153783 >>>> >>>> Thanks, >>>> Coleen >>>> >>> >> From jesper.wilhelmsson at oracle.com Fri Jan 26 22:08:40 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Fri, 26 Jan 2018 23:08:40 +0100 Subject: RFR 8153783: UnlockDiagnosticVMOptions should not be trueInDebug In-Reply-To: <121de797-5245-7db1-cab2-be6e428e39e9@oracle.com> References: <45b2d4ed-d55e-5163-9eb6-eee58be7c04c@oracle.com> <0e7a8b88-dd2c-763f-169e-f869406c85dd@oracle.com> <56cd296a-c4e0-2388-c570-d409786d7ecb@oracle.com> <121de797-5245-7db1-cab2-be6e428e39e9@oracle.com> Message-ID: > On 26 Jan 2018, at 22:58, Stefan Karlsson wrote: > > On 2018-01-26 22:41, Vladimir Ivanov wrote: >> As for me, I'd prefer to leave it as is. >> >> I use debug builds on daily basis and requiring to specify -XX:+UnlockDiagnosticVMOptions would add observable overhead >> into my development workflow. > > I agree. +1 /Jesper > > StefanK > >> >> IMO missing -XX:+UnlockDiagnosticVMOptions in a test manifests more serious issue it is proposed to fix: the test was never run with product binaries and we shouldn't try to hide that by unifying flag's default value between product & debug binaries. >> >> And it's not a theoretical possibility: I regularly run into slight differences in behavior between product & fastdebug binaries while writing (and testing externally contributed) JIT-compiler regression tests which cause failures. >> >> Best regards, >> Vladimir Ivanov >> >> On 1/26/18 1:08 PM, coleen.phillimore at oracle.com wrote: >>> >>> Thanks Dan, Lois and Harold for the code reviews. >>> >>> We're still trying to answer the meta-question of whether we want to use this option in day to day development, when using flags like VerifyDuringGC, and PrintNMethods, vs. having diagnostic options added to tests or sent to other parties missing the necessary -XX:+UnlockDiagnosticVMOptions. >>> >>> Thanks, >>> Coleen >>> >>> >>> On 1/26/18 3:19 PM, Daniel D. Daugherty wrote: >>>> On 1/26/18 11:44 AM, coleen.phillimore at oracle.com wrote: >>>>> Summary: Make default false in all builds like UnlockExperimentalVMOptions and fix tests. >>>>> >>>>> Ran all jtreg hotspot tests and jdk/java/lang tests, and sun.misc. There's some compiler test that I fixed. Please check if I did this right: >>>>> TestPrintPreciseRTMLockingStatisticsBase.java. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8153783.01/webrev >>>> >>>> src/hotspot/share/runtime/globals.hpp >>>> No comments. >>>> >>>> test/hotspot/jtreg/compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsBase.java >>>> No comments. Messy test, but I think it is correct. >>>> >>>> test/hotspot/jtreg/runtime/Unsafe/RangeCheck.java >>>> No comments. >>>> >>>> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java >>>> No comments. >>>> >>>> test/hotspot/jtreg/runtime/handshake/HandshakeTransitionTest.java >>>> No comments. >>>> >>>> Thumbs up on the code! >>>> >>>> The meta question is, of course, that this changes things for folks that >>>> use non-product builds on a daily basis. Personally, I like the idea of >>>> removing one more annoying difference between 'release' and 'fastdebug' >>>> bits. >>>> >>>> Yes, that means I have to remember to to include -XX:+UnlockDiagnosticVMOptions >>>> but I typically run things from scripts so I've been training myself to always >>>> include that option when I'm setting a script for bug hunt. So this change in >>>> behavior isn't a big deal for me. >>>> >>>> Dan >>>> >>>> >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8153783 >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>> >>> > From david.holmes at oracle.com Sat Jan 27 07:25:21 2018 From: david.holmes at oracle.com (David Holmes) Date: Sat, 27 Jan 2018 17:25:21 +1000 Subject: RFR 8153783: UnlockDiagnosticVMOptions should not be trueInDebug In-Reply-To: <56cd296a-c4e0-2388-c570-d409786d7ecb@oracle.com> References: <45b2d4ed-d55e-5163-9eb6-eee58be7c04c@oracle.com> <0e7a8b88-dd2c-763f-169e-f869406c85dd@oracle.com> <56cd296a-c4e0-2388-c570-d409786d7ecb@oracle.com> Message-ID: On 27/01/2018 7:41 AM, Vladimir Ivanov wrote: > As for me, I'd prefer to leave it as is. > > I use debug builds on daily basis and requiring to specify > -XX:+UnlockDiagnosticVMOptions would add observable overhead > into my development workflow. > > IMO missing -XX:+UnlockDiagnosticVMOptions in a test manifests more > serious issue it is proposed to fix: the test was never run with product > binaries and we shouldn't try to hide that by unifying flag's default > value between product & debug binaries. +1 Failing to run tests in product mode is the real problem. David ----- > And it's not a theoretical possibility: I regularly run into slight > differences in behavior between product & fastdebug binaries while > writing (and testing externally contributed) JIT-compiler regression > tests which cause failures. > > Best regards, > Vladimir Ivanov > > On 1/26/18 1:08 PM, coleen.phillimore at oracle.com wrote: >> >> Thanks Dan, Lois and Harold for the code reviews. >> >> We're still trying to answer the meta-question of whether we want to >> use this option in day to day development, when using flags like >> VerifyDuringGC, and PrintNMethods, vs. having diagnostic options added >> to tests or sent to other parties missing the necessary >> -XX:+UnlockDiagnosticVMOptions. >> >> Thanks, >> Coleen >> >> >> On 1/26/18 3:19 PM, Daniel D. Daugherty wrote: >>> On 1/26/18 11:44 AM, coleen.phillimore at oracle.com wrote: >>>> Summary: Make default false in all builds like >>>> UnlockExperimentalVMOptions and fix tests. >>>> >>>> Ran all jtreg hotspot tests and jdk/java/lang tests, and sun.misc. >>>> There's some compiler test that I fixed. Please check if I did this >>>> right: >>>> TestPrintPreciseRTMLockingStatisticsBase.java. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8153783.01/webrev >>> >>> src/hotspot/share/runtime/globals.hpp >>> ??? No comments. >>> >>> test/hotspot/jtreg/compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsBase.java >>> >>> ??? No comments. Messy test, but I think it is correct. >>> >>> test/hotspot/jtreg/runtime/Unsafe/RangeCheck.java >>> ??? No comments. >>> >>> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java >>> ??? No comments. >>> >>> test/hotspot/jtreg/runtime/handshake/HandshakeTransitionTest.java >>> ??? No comments. >>> >>> Thumbs up on the code! >>> >>> The meta question is, of course, that this changes things for folks that >>> use non-product builds on a daily basis. Personally, I like the idea of >>> removing one more annoying difference between 'release' and 'fastdebug' >>> bits. >>> >>> Yes, that means I have to remember to to include >>> -XX:+UnlockDiagnosticVMOptions >>> but I typically run things from scripts so I've been training myself >>> to always >>> include that option when I'm setting a script for bug hunt. So this >>> change in >>> behavior isn't a big deal for me. >>> >>> Dan >>> >>> >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8153783 >>>> >>>> Thanks, >>>> Coleen >>>> >>> >> From dmitry.samersoff at bell-sw.com Sat Jan 27 12:23:53 2018 From: dmitry.samersoff at bell-sw.com (Dmitry Samersoff) Date: Sat, 27 Jan 2018 15:23:53 +0300 Subject: RFR : 8196062 : Enable docker container related tests for linux ppc64le In-Reply-To: References: Message-ID: Matthias, osContainer_linux.cpp: Could you cleanup the code a bit? It might be better to log && bailout if c == NULL, c->subsystem_path() == NULL, strlen(c->subsystem_path()) + strlen(filename) > MAXPATHLEN right after start of function (at l. 124) it reduces number of branches below and makes code much more readable, also we don't need str*n*cat at l. 133 because we checked for overflow before. -Dmitry On 01/24/2018 05:24 PM, Baesken, Matthias wrote: > Hello, could you please review the following change : 8196062 : Enable docker container related tests for linux ppc64le . > > It adds docker container testing for linux ppc64 le (little endian) . > > A number of things had to be done : > > * Add a separate docker file test/hotspot/jtreg/runtime/containers/docker/Dockerfile-BasicTest-ppc64le for linux ppc64 le which uses Ubuntu ( the Oracle Linux 7.2 used for x86_64 seems not to be available for ppc64le ) > * Fix parsing /proc/self/mountinfo and /proc/self/cgroup in src/hotspot/os/linux/osContainer_linux.cpp , it could not handle the format seen on SUSE LINUX 12.1 ppc64le (Host) and Ubuntu (Docker container) > * Add a bit more logging > > > Webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8196062/ > > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-8196062 > > > After these adjustments I could run the runtime/containers/docker - jtreg tests successfully . > > > Best regards, Matthias > > From ecki at zusammenkunft.net Fri Jan 19 21:59:57 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 19 Jan 2018 22:59:57 +0100 Subject: [JDK-8195794]: sunrsasign.jar still searched in java 8? In-Reply-To: <0507c4ed-158f-8e47-576f-ebda1c2103f1@oracle.com> References: <0507c4ed-158f-8e47-576f-ebda1c2103f1@oracle.com> Message-ID: <5a626a5e.95811c0a.78dc0.6a4a@mx.google.com> Hello, I agree that it is most likely low priority. I catched it since for some reason I have a Ant Job which is pretty slow on a VM and when stracing it stats this file multiple times and even worse it reads ct.sym (which I dont know yet whats going on). But I dont think this failed stat() causes my slowness ? however it seems to happen repeatingly in some situations. I can try to propose a patch to hotspot-dev and find a sponsor, I just wont have good means to run Tests. The lib/classes/ is also a interesting find on the boot classpath ?? Gruss Bernd -- http://bernd.eckenfels.net Von: Bradford Wetmore Gesendet: Freitag, 19. Januar 2018 22:21 An: Bernd; security-dev at openjdk.java.net Betreff: Re: sunrsasign.jar still searched in java 8? Hrm...this was (supposedly) fixed/removed on 2003-10-20 for JDK 5...but I can't find anything in the old SCCS workspace history to indicate it was (old bug id is nowhere to be found). It's been there ever since we migrated to Mercurial. Anyway, it's gone in JDK 9 as a result of the modularity code changes. I've filed: https://bugs.openjdk.java.net/browse/JDK-8195794 Other than a bit of search overhead, I don't think it should cause a problem. This will be a pretty low bug priority bug for sustaining to fix, unless there is something I'm not catching. If someone is looking for a simple bug to learn the process of how to contribute to OpenJDK 8, this is a good candidate. That someone should probably followup with hotspot-dev [1], as this is their code. Brad [1] http://mail.openjdk.java.net/mailman/listinfo/hotspot-dev On 1/19/2018 10:28 AM, Bernd wrote: > Hello, > > I noticed that when I strace a "java -version" with 8u152 JRE it > searches for sunrsasign.jar which is not found. Is that a compatibility > thing or should it not happen? > > It seems to be in the boot classpath even when the associated classes > are in rt.jar: > > http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/tip/src/share/vm/runtime/os.cpp#l1197 > > Gruss > Bernd > From bradford.wetmore at oracle.com Fri Jan 19 22:25:28 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 19 Jan 2018 14:25:28 -0800 Subject: [JDK-8195794]: sunrsasign.jar still searched in java 8? In-Reply-To: <5a626a5e.95811c0a.78dc0.6a4a@mx.google.com> References: <0507c4ed-158f-8e47-576f-ebda1c2103f1@oracle.com> <5a626a5e.95811c0a.78dc0.6a4a@mx.google.com> Message-ID: <143602b6-1bb3-fa7e-4f6e-0ec15fbc99b8@oracle.com> On 1/19/2018 1:59 PM, Bernd Eckenfels wrote: > I can try to propose a patch to hotspot-dev and find a sponsor, I just > wont have good means to run Tests. If you get an Oracle sponsor, (s)he should be able to put it through the regular hot-spot integration tests they have. > The lib/classes/ is also a interesting find on the boot classpath ?? It's been a while since I've been working on a JDK 8 build, but I think lib/classes is the default location for classes in non-image builds. Brad > Gruss > > Bernd > > -- > http://bernd.eckenfels.net > > *Von: *Bradford Wetmore > *Gesendet: *Freitag, 19. Januar 2018 22:21 > *An: *Bernd ; > security-dev at openjdk.java.net > *Betreff: *Re: sunrsasign.jar still searched in java 8? > > Hrm...this was (supposedly) fixed/removed on 2003-10-20 for JDK 5...but > > I can't find anything in the old SCCS workspace history to indicate it > > was (old bug id is nowhere to be found).? It's been there ever since we > > migrated to Mercurial. > > Anyway, it's gone in JDK 9 as a result of the modularity code changes. > > I've filed: > > ???? https://bugs.openjdk.java.net/browse/JDK-8195794 > > Other than a bit of search overhead, I don't think it should cause a > > problem.? This will be a pretty low bug priority bug for sustaining to > > fix, unless there is something I'm not catching. > > If someone is looking for a simple bug to learn the process of how to > > contribute to OpenJDK 8, this is a good candidate.? That someone should > > probably followup with hotspot-dev [1], as this is their code. > > Brad > > [1]? http://mail.openjdk.java.net/mailman/listinfo/hotspot-dev > > On 1/19/2018 10:28 AM, Bernd wrote: > > > Hello, > > > > > > I noticed that when I strace a "java -version" with 8u152 JRE it > > > searches for sunrsasign.jar which is not found. Is that a compatibility > > > thing or should it not happen? > > > > > > It seems to be in the boot classpath even when the associated classes > > > are in rt.jar: > > > > > > > http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/tip/src/share/vm/runtime/os.cpp#l1197 > > > > > > Gruss > > > Bernd > > > > From bradford.wetmore at oracle.com Sun Jan 21 16:28:16 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Sun, 21 Jan 2018 08:28:16 -0800 Subject: sunrsasign.jar still searched in java 8? In-Reply-To: <35115f6f-c041-2179-fa60-eb3ccd25f561@oracle.com> References: <554203c4-e9e3-4c63-b1b1-c74332a9fff5@oracle.com> <35115f6f-c041-2179-fa60-eb3ccd25f561@oracle.com> Message-ID: <4c12683c-1a20-bfaa-75df-a60125740199@oracle.com> JDK-7036474 is still open and is in another part of the code. I've linked them so maybe if one gets fixed, maybe the other will also. (*crosses fingers*) Brad On 1/20/2018 1:19 AM, David Holmes wrote: > On 20/01/2018 6:28 AM, Sean Mullan wrote: >> I believe sunrsasign.jar was removed in JDK 1.5. So it seems like the >> line below is no longer necessary and should be removed. I have copied >> hotspot-dev to see if this is a known issue or if I am missing something. > > As per Brad's filing of > > https://bugs.openjdk.java.net/browse/JDK-8195794 > > this was claimed to have been done in another bug report, but it seems > it got lost somewhere. > > Also see: > > https://bugs.openjdk.java.net/browse/JDK-7036474 > > which seems fixed in 8+ but not 7u. > > David > >> --Sean >> >> On 1/19/18 1:28 PM, Bernd wrote: >>> Hello, >>> >>> I noticed that when I strace a "java -version" with 8u152 JRE it >>> searches for sunrsasign.jar which is not found. Is that a >>> compatibility thing or should it not happen? >>> >>> It seems to be in the boot classpath even when the associated classes >>> are in rt.jar: >>> >>> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/tip/src/share/vm/runtime/os.cpp#l1197 >>> >>> >>> Gruss >>> Bernd >>> From adinn at redhat.com Sat Jan 27 16:53:42 2018 From: adinn at redhat.com (Andrew Dinn) Date: Sat, 27 Jan 2018 16:53:42 +0000 Subject: RFR: 8196221: AArch64: Mistake in committed patch for JDK-8195859 In-Reply-To: References: <44f0459a-0c32-6b9e-9324-418616a69f97@redhat.com> Message-ID: Hi Vladimir, On 26/01/18 19:41, Vladimir Kozlov wrote: > Hi Andrew, > > Please, follow fix request process for jdk 10 if you want to push this > into jdk10: > > http://openjdk.java.net/projects/jdk/10/fix-request-process I have labelled the JIRA withjdk10-fix-request and added the necessary explanatory comment. Thanks for responding to this (and also the previous patches). regards, Andrew Dinn ----------- From shafi.s.ahmad at oracle.com Mon Jan 29 04:45:52 2018 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Sun, 28 Jan 2018 20:45:52 -0800 (PST) Subject: [8u] RFR for backport of JDK-8026331: hs_err improvement: Print if we have seen any OutOfMemoryErrors or StackOverflowErrors In-Reply-To: <84e4010f-e1ed-4940-ad24-5e7fc1667899@default> References: <84e4010f-e1ed-4940-ad24-5e7fc1667899@default> Message-ID: <1e6b48f9-9d19-40f4-aae0-61ffa4d51800@default> 2nd try... Regards, Shafi > -----Original Message----- > From: Shafi Ahmad > Sent: Wednesday, January 24, 2018 3:16 PM > To: hotspot-dev at openjdk.java.net > Subject: [8u] RFR for backport of JDK-8026331: hs_err improvement: Print if > we have seen any OutOfMemoryErrors or StackOverflowErrors > > Hi, > > Please review the backport of bug: " JDK-8026331: hs_err improvement: Print > if we have seen any OutOfMemoryErrors or StackOverflowErrors" to jdk8u- > dev. > > Please note that this is not a clean backport as I got below conflicts - > > hotspot$ find ./ -name "*.rej" -exec cat {} \; > --- metaspace.cpp > +++ metaspace.cpp > @@ -3132,10 +3132,21 @@ > initialize_class_space(metaspace_rs); > > if (PrintCompressedOopsMode || (PrintMiscellaneous && Verbose)) { > - gclog_or_tty->print_cr("Narrow klass base: " PTR_FORMAT ", Narrow > klass shift: %d", > - p2i(Universe::narrow_klass_base()), > Universe::narrow_klass_shift()); > - gclog_or_tty->print_cr("Compressed class space size: " SIZE_FORMAT " > Address: " PTR_FORMAT " Req Addr: " PTR_FORMAT, > - compressed_class_space_size(), p2i(metaspace_rs.base()), > p2i(requested_addr)); > + print_compressed_class_space(gclog_or_tty, requested_addr); > + } > +} > + > +void Metaspace::print_compressed_class_space(outputStream* st, const > char* requested_addr) { > + st->print_cr("Narrow klass base: " PTR_FORMAT ", Narrow klass shift: %d", > + p2i(Universe::narrow_klass_base()), > Universe::narrow_klass_shift()); > + if (_class_space_list != NULL) { > + address base = (address)_class_space_list->current_virtual_space()- > >bottom(); > + st->print("Compressed class space size: " SIZE_FORMAT " Address: " > PTR_FORMAT, > + compressed_class_space_size(), p2i(base)); > + if (requested_addr != 0) { > + st->print(" Req Addr: " PTR_FORMAT, p2i(requested_addr)); > + } > + st->cr(); > } > } > > --- universe.cpp > +++ universe.cpp > @@ -781,27 +781,24 @@ > return JNI_OK; > } > > -void Universe::print_compressed_oops_mode() { > - tty->cr(); > - tty->print("heap address: " PTR_FORMAT ", size: " SIZE_FORMAT " MB", > +void Universe::print_compressed_oops_mode(outputStream* st) { > + st->print("heap address: " PTR_FORMAT ", size: " SIZE_FORMAT " MB", > p2i(Universe::heap()->base()), Universe::heap()- > >reserved_region().byte_size()/M); > > - tty->print(", Compressed Oops mode: %s", > narrow_oop_mode_to_string(narrow_oop_mode())); > + st->print(", Compressed Oops mode: %s", > narrow_oop_mode_to_string(narrow_oop_mode())); > > if (Universe::narrow_oop_base() != 0) { > - tty->print(": " PTR_FORMAT, p2i(Universe::narrow_oop_base())); > + st->print(": " PTR_FORMAT, p2i(Universe::narrow_oop_base())); > } > > if (Universe::narrow_oop_shift() != 0) { > - tty->print(", Oop shift amount: %d", Universe::narrow_oop_shift()); > + st->print(", Oop shift amount: %d", Universe::narrow_oop_shift()); > } > > if (!Universe::narrow_oop_use_implicit_null_checks()) { > - tty->print(", no protected page in front of the heap"); > + st->print(", no protected page in front of the heap"); > } > - > - tty->cr(); > - tty->cr(); > + st->cr(); > } > > Webrev: http://cr.openjdk.java.net/~shshahma/8026331/webrev.00/ > Jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8026331 > Original patch pushed to jdk9: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/cf5a0377f578 > > Test: Run jprt -testset hotspot and jtreg - hotspot/test > > Regards, > Shafi From coleen.phillimore at oracle.com Mon Jan 29 13:35:06 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 29 Jan 2018 08:35:06 -0500 Subject: RFR 8153783: UnlockDiagnosticVMOptions should not be trueInDebug In-Reply-To: References: <45b2d4ed-d55e-5163-9eb6-eee58be7c04c@oracle.com> <0e7a8b88-dd2c-763f-169e-f869406c85dd@oracle.com> <56cd296a-c4e0-2388-c570-d409786d7ecb@oracle.com> Message-ID: <229ac8bb-e225-906f-fd2f-bd024808f332@oracle.com> Thank you everyone for your feedback and reviews.?? Due to the reasonable and strong objection to this change, I am closing it as WNF and withdrawing this RFR. Thanks, Coleen On 1/27/18 2:25 AM, David Holmes wrote: > On 27/01/2018 7:41 AM, Vladimir Ivanov wrote: >> As for me, I'd prefer to leave it as is. >> >> I use debug builds on daily basis and requiring to specify >> -XX:+UnlockDiagnosticVMOptions would add observable overhead >> into my development workflow. >> >> IMO missing -XX:+UnlockDiagnosticVMOptions in a test manifests more >> serious issue it is proposed to fix: the test was never run with >> product binaries and we shouldn't try to hide that by unifying flag's >> default value between product & debug binaries. > > +1 > > Failing to run tests in product mode is the real problem. > > David > ----- > >> And it's not a theoretical possibility: I regularly run into slight >> differences in behavior between product & fastdebug binaries while >> writing (and testing externally contributed) JIT-compiler regression >> tests which cause failures. >> >> Best regards, >> Vladimir Ivanov >> >> On 1/26/18 1:08 PM, coleen.phillimore at oracle.com wrote: >>> >>> Thanks Dan, Lois and Harold for the code reviews. >>> >>> We're still trying to answer the meta-question of whether we want to >>> use this option in day to day development, when using flags like >>> VerifyDuringGC, and PrintNMethods, vs. having diagnostic options >>> added to tests or sent to other parties missing the necessary >>> -XX:+UnlockDiagnosticVMOptions. >>> >>> Thanks, >>> Coleen >>> >>> >>> On 1/26/18 3:19 PM, Daniel D. Daugherty wrote: >>>> On 1/26/18 11:44 AM, coleen.phillimore at oracle.com wrote: >>>>> Summary: Make default false in all builds like >>>>> UnlockExperimentalVMOptions and fix tests. >>>>> >>>>> Ran all jtreg hotspot tests and jdk/java/lang tests, and sun.misc. >>>>> There's some compiler test that I fixed. Please check if I did >>>>> this right: >>>>> TestPrintPreciseRTMLockingStatisticsBase.java. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8153783.01/webrev >>>> >>>> src/hotspot/share/runtime/globals.hpp >>>> ??? No comments. >>>> >>>> test/hotspot/jtreg/compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsBase.java >>>> >>>> ??? No comments. Messy test, but I think it is correct. >>>> >>>> test/hotspot/jtreg/runtime/Unsafe/RangeCheck.java >>>> ??? No comments. >>>> >>>> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java >>>> ??? No comments. >>>> >>>> test/hotspot/jtreg/runtime/handshake/HandshakeTransitionTest.java >>>> ??? No comments. >>>> >>>> Thumbs up on the code! >>>> >>>> The meta question is, of course, that this changes things for folks >>>> that >>>> use non-product builds on a daily basis. Personally, I like the >>>> idea of >>>> removing one more annoying difference between 'release' and >>>> 'fastdebug' >>>> bits. >>>> >>>> Yes, that means I have to remember to to include >>>> -XX:+UnlockDiagnosticVMOptions >>>> but I typically run things from scripts so I've been training >>>> myself to always >>>> include that option when I'm setting a script for bug hunt. So this >>>> change in >>>> behavior isn't a big deal for me. >>>> >>>> Dan >>>> >>>> >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8153783 >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>> >>> From harold.seigel at oracle.com Mon Jan 29 17:06:02 2018 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 29 Jan 2018 12:06:02 -0500 Subject: RFR: 8194898: Move OopStorage inline definitions to an .inline.hpp In-Reply-To: References: Message-ID: Hi Kim, These changes looks good. Thanks, Harold On 1/24/2018 2:54 PM, coleen.phillimore at oracle.com wrote: > > This looks very nice! > > There's a minor inconsistency with the hotspot code, most nonstatic > data members are declared at the beginning of the class: > > 160?? OopStorage* _storage; > 161?? void* volatile _next_block; > 162?? bool _concurrent; > > These should move up to line 144.?? Some people like the member names > lined up too. :) > > I don't need to see this trivial change. > > Thanks, > Coleen > > On 1/19/18 2:59 PM, Kim Barrett wrote: >> Please review this code reorg for the recently added OopStorage. >> During the review of OopStorage (JDK-8194312) it was requested that >> the inline member function definitions and inner class definitions be >> moved to .inline.hpp file(s). >> >> The changes are: >> >> (1) ParState and BasicParState are moved to the new file >> oopStorageParState.inline.hpp. Also moved AlwaysTrueFn into >> BasicParState, >> which is the only user. >> >> (2) Moved the inline member function to the new file >> oopStorage.inline.hpp, >> along with most of the inner class definitions.? The complete >> definitions of >> BlockEntry and BlockList remain within the OopStorage definition, as >> they are >> needed for member types. >> >> (3) Added inline qualifiers to public OopStorage function declarations >> when the function definition is in an inline header.? This may produce >> better error messages by some compilers when the inline header is >> needed but not included. >> >> Note: This change will likely have a simple merge conflict (unrelated >> nearby changes to oopStorage.hpp) with the fix for JDK-8195691. Since >> I'm sponsoring the latter, I'll deal with that when the time comes, >> for whichever order these changes end up being pushed. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8194898 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8194898/open.00/ >> >> Testing: >> hs-tier1,2,3 >> > From vladimir.kozlov at oracle.com Mon Jan 29 20:21:38 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 29 Jan 2018 12:21:38 -0800 Subject: RFR: 8196221: AArch64: Mistake in committed patch for JDK-8195859 In-Reply-To: References: <44f0459a-0c32-6b9e-9324-418616a69f97@redhat.com> Message-ID: <8c5be771-5738-a179-6165-094386bfb463@oracle.com> Approved. Regards, Vladimir On 1/27/18 8:53 AM, Andrew Dinn wrote: > Hi Vladimir, > > On 26/01/18 19:41, Vladimir Kozlov wrote: >> Hi Andrew, >> >> Please, follow fix request process for jdk 10 if you want to push this >> into jdk10: >> >> http://openjdk.java.net/projects/jdk/10/fix-request-process > I have labelled the JIRA withjdk10-fix-request and added the necessary > explanatory comment. > > Thanks for responding to this (and also the previous patches). > > regards, > > > Andrew Dinn > ----------- > From kim.barrett at oracle.com Mon Jan 29 20:50:17 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 29 Jan 2018 15:50:17 -0500 Subject: RFR: 8194898: Move OopStorage inline definitions to an .inline.hpp In-Reply-To: References: Message-ID: > On Jan 24, 2018, at 2:54 PM, coleen.phillimore at oracle.com wrote: > > > This looks very nice! > > There's a minor inconsistency with the hotspot code, most nonstatic data members are declared at the beginning of the class: > > 160 OopStorage* _storage; > 161 void* volatile _next_block; > 162 bool _concurrent; > > These should move up to line 144. Some people like the member names lined up too. :) Thanks. I?ll move these declarations. From kim.barrett at oracle.com Mon Jan 29 20:50:44 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 29 Jan 2018 15:50:44 -0500 Subject: RFR: 8194898: Move OopStorage inline definitions to an .inline.hpp In-Reply-To: References: Message-ID: <67C81B63-6BAB-41A9-BC32-DD186BA2295B@oracle.com> > On Jan 29, 2018, at 12:06 PM, harold seigel wrote: > > Hi Kim, > > These changes looks good. > > Thanks, Harold Thanks. From stewartd.qdt at qualcommdatacenter.com Mon Jan 29 21:53:00 2018 From: stewartd.qdt at qualcommdatacenter.com (stewartd.qdt) Date: Mon, 29 Jan 2018 21:53:00 +0000 Subject: RFR: 8196361: JTReg failure in serviceability/sa/ClhsdbInspect.java Message-ID: <6e3441f3c28f4f7387d2174f52283fa7@NASANEXM01E.na.qualcomm.com> Please review this webrev [1] which attempts to fix a test error in serviceability/sa/ClhsdbInspect.java when it is run under an AArch64 system (not necessarily exclusive to this system, but it was the system under test). The bug report [2] provides further details. Essentially the line "waiting to re-lock in wait" never actually occurs. Instead I have the line "waiting to lock" which occurs for the referenced item of /java/lang/ref/ReferenceQueue$Lock. Unfortunately the test is written such that only the first "waiting to lock" occurrence is seen (for java/lang/Class), which is already accounted for in the test. I'm not overly happy with this approach as it actually removes a test line. However, the test line does not actually appear in the output (at least on my system) and the test is not currently written to look for the second occurrence of the line "waiting to lock". Perhaps the original author could chime in and provide further guidance as to the intention of the test. I am happy to modify the patch as necessary. Regards, Daniel Stewart [1] - http://cr.openjdk.java.net/~dstewart/8196361/webrev.00/ [2] - https://bugs.openjdk.java.net/browse/JDK-8196361 From david.holmes at oracle.com Mon Jan 29 22:05:44 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Jan 2018 08:05:44 +1000 Subject: RFR: 8196361: JTReg failure in serviceability/sa/ClhsdbInspect.java In-Reply-To: <6e3441f3c28f4f7387d2174f52283fa7@NASANEXM01E.na.qualcomm.com> References: <6e3441f3c28f4f7387d2174f52283fa7@NASANEXM01E.na.qualcomm.com> Message-ID: <44a71e46-3da2-53c6-7e6b-82658183ae8c@oracle.com> Hi Daniel, Serviceability issues should go to serviceability-dev at openjdk.java.net - now cc'd. On 30/01/2018 7:53 AM, stewartd.qdt wrote: > Please review this webrev [1] which attempts to fix a test error in serviceability/sa/ClhsdbInspect.java when it is run under an AArch64 system (not necessarily exclusive to this system, but it was the system under test). The bug report [2] provides further details. Essentially the line "waiting to re-lock in wait" never actually occurs. Instead I have the line "waiting to lock" which occurs for the referenced item of /java/lang/ref/ReferenceQueue$Lock. Unfortunately the test is written such that only the first "waiting to lock" occurrence is seen (for java/lang/Class), which is already accounted for in the test. I can't tell exactly what the test expects, or why, but it would be extremely hard to arrange for "waiting to re-lock in wait" to be seen for the ReferenceQueue lock! That requires acquiring the lock yourself, issuing a notify() to unblock the wait(), and then issuing the jstack command while still holding the lock! David ----- > I'm not overly happy with this approach as it actually removes a test line. However, the test line does not actually appear in the output (at least on my system) and the test is not currently written to look for the second occurrence of the line "waiting to lock". Perhaps the original author could chime in and provide further guidance as to the intention of the test. > > I am happy to modify the patch as necessary. > > Regards, > Daniel Stewart > > > [1] - http://cr.openjdk.java.net/~dstewart/8196361/webrev.00/ > [2] - https://bugs.openjdk.java.net/browse/JDK-8196361 > From adinn at redhat.com Tue Jan 30 08:56:10 2018 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 30 Jan 2018 08:56:10 +0000 Subject: RFR: 8196221: AArch64: Mistake in committed patch for JDK-8195859 In-Reply-To: <8c5be771-5738-a179-6165-094386bfb463@oracle.com> References: <44f0459a-0c32-6b9e-9324-418616a69f97@redhat.com> <8c5be771-5738-a179-6165-094386bfb463@oracle.com> Message-ID: <46dff0d1-ca3d-d321-821f-afa9eba20efe@redhat.com> On 29/01/18 20:21, Vladimir Kozlov wrote: > Approved. Thanks, Vladimir. I have pushed the patch to the jdk development jdk10 and jdk trees. 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 jini.george at oracle.com Tue Jan 30 11:57:36 2018 From: jini.george at oracle.com (Jini George) Date: Tue, 30 Jan 2018 17:27:36 +0530 Subject: RFR: 8196361: JTReg failure in serviceability/sa/ClhsdbInspect.java In-Reply-To: <44a71e46-3da2-53c6-7e6b-82658183ae8c@oracle.com> References: <6e3441f3c28f4f7387d2174f52283fa7@NASANEXM01E.na.qualcomm.com> <44a71e46-3da2-53c6-7e6b-82658183ae8c@oracle.com> Message-ID: <3318aed7-f04a-3b92-2660-39cdf13c2d24@oracle.com> Hi Daniel, David, Thanks, Daniel, for bringing this up. The intent of the test is to get the oop address corresponding to a java.lang.ref.ReferenceQueue$Lock, which can typically be obtained from the stack traces of the Common-Cleaner or the Finalizer threads. The stack traces which I had been noticing were typically of the form: "Common-Cleaner" #8 daemon prio=8 tid=0x00007f09c82ac000 nid=0xf6e in Object.wait() [0x00007f09a18d2000] java.lang.Thread.State: TIMED_WAITING (on object monitor) JavaThread state: _thread_blocked - java.lang.Object.wait(long) @bci=0, pc=0x00007f09b7d6480b, Method*=0x00007f09acc43d60 (Interpreted frame) - waiting on <0x000000072e61f6e0> (a java.lang.ref.ReferenceQueue$Lock) - java.lang.ref.ReferenceQueue.remove(long) @bci=59, line=151, pc=0x00007f09b7d55243, Method*=0x00007f09acdab9b0 (Interpreted frame) - waiting to re-lock in wait() <0x000000072e61f6e0> (a java.lang.ref.ReferenceQueue$Lock) ... I chose 'waiting to re-lock in wait' since that was what I had been observing next to the oop address of java.lang.ref.ReferenceQueue$Lock. But I see how with a timing difference, one could get 'waiting to lock' as in your case. So, a good way to fix might be to check for the line containing '(a java.lang.ref.ReferenceQueue$Lock)', getting the oop address from that line (should be the address appearing immediately before '(a java.lang.ref.ReferenceQueue$Lock)') and passing that to the 'inspect' command. Thanks much, Jini. On 1/30/2018 3:35 AM, David Holmes wrote: > Hi Daniel, > > Serviceability issues should go to serviceability-dev at openjdk.java.net - > now cc'd. > > On 30/01/2018 7:53 AM, stewartd.qdt wrote: >> Please review this webrev [1] which attempts to fix a test error in >> serviceability/sa/ClhsdbInspect.java when it is run under an AArch64 >> system (not necessarily exclusive to this system, but it was the >> system under test). The bug report [2] provides further details. >> Essentially the line "waiting to re-lock in wait" never actually >> occurs. Instead I have the line "waiting to lock" which occurs for the >> referenced item of /java/lang/ref/ReferenceQueue$Lock. Unfortunately >> the test is written such that only the first "waiting to lock" >> occurrence is seen (for java/lang/Class), which is already accounted >> for in the test. > > I can't tell exactly what the test expects, or why, but it would be > extremely hard to arrange for "waiting to re-lock in wait" to be seen > for the ReferenceQueue lock! That requires acquiring the lock yourself, > issuing a notify() to unblock the wait(), and then issuing the jstack > command while still holding the lock! > > David > ----- > >> I'm not overly happy with this approach as it actually removes a test >> line. However, the test line does not actually appear in the output >> (at least on my system) and the test is not currently written to look >> for the second occurrence of the line "waiting to lock". Perhaps the >> original author could chime in and provide further guidance as to the >> intention of the test. >> >> I am happy to modify the patch as necessary. >> >> Regards, >> Daniel Stewart >> >> >> [1] -? http://cr.openjdk.java.net/~dstewart/8196361/webrev.00/ >> [2] - https://bugs.openjdk.java.net/browse/JDK-8196361 >> From jesper.wilhelmsson at oracle.com Tue Jan 30 16:04:44 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 30 Jan 2018 17:04:44 +0100 Subject: RFR: JDK-8196372 - [BACKOUT] NMT: add_committed_regions doesn't merge succeeding regions Message-ID: Hi, Please review this backout of JDK-8196217 that is currently causing tier 1 failures in HotSpot testing. Bug: https://bugs.openjdk.java.net/browse/JDK-8196372 Webrev: http://cr.openjdk.java.net/~jwilhelm/8196372/webrev.00/ Thanks, /Jesper From stefan.karlsson at oracle.com Tue Jan 30 16:09:16 2018 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 30 Jan 2018 17:09:16 +0100 Subject: RFR: JDK-8196372 - [BACKOUT] NMT: add_committed_regions doesn't merge succeeding regions In-Reply-To: References: Message-ID: Looks good. Thanks for fixing! StefanK On 2018-01-30 17:04, jesper.wilhelmsson at oracle.com wrote: > Hi, > > Please review this backout of JDK-8196217 that is currently causing tier 1 failures in HotSpot testing. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196372 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8196372/webrev.00/ > > Thanks, > /Jesper > From jesper.wilhelmsson at oracle.com Tue Jan 30 16:11:46 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 30 Jan 2018 17:11:46 +0100 Subject: RFR: JDK-8196372 - [BACKOUT] NMT: add_committed_regions doesn't merge succeeding regions In-Reply-To: References: Message-ID: <4F5EA70E-1916-4CF9-86E7-CB0BDEB41FF4@oracle.com> Thanks! I'll push this immediately under the trivial rule. /Jesper > On 30 Jan 2018, at 17:09, Stefan Karlsson wrote: > > Looks good. Thanks for fixing! > > StefanK > > On 2018-01-30 17:04, jesper.wilhelmsson at oracle.com wrote: >> Hi, >> Please review this backout of JDK-8196217 that is currently causing tier 1 failures in HotSpot testing. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196372 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8196372/webrev.00/ >> Thanks, >> /Jesper From coleen.phillimore at oracle.com Tue Jan 30 22:58:08 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 30 Jan 2018 17:58:08 -0500 Subject: RFR (S) 8196199: Remove miscellaneous oop comparison operators Message-ID: <0a17630f-3132-f5fa-fc87-7dd8023b02b1@oracle.com> CheckUnhandledOops had defined some oop comparison operators that will have to be rewritten for new GCs.?? Kim Barrett did most of this change. ? See CR for more info. Tested with JPRT (using currently supported GCs) tier1 and locally. open webrev at http://cr.openjdk.java.net/~coleenp/8196199.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8196199 Thanks, Coleen From thomas.stuefe at gmail.com Wed Jan 31 13:52:02 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 31 Jan 2018 14:52:02 +0100 Subject: fastdebug vs optimized? Message-ID: Hi all, Sorry for asking the same question again, but I still struggle to understand the difference between fastdebug and optimized builds. Not the technical details, that is clear (I hope): optimized: optimized build with !ASSERT !PRODUCT fastdebug: optimized build with ASSERT !PRODUCT but what the point is for having two builds with such similarities. What is the optimized build used for? When should I guard verification code with ASSERT, when with !PRODUCT? As for the latter, it feels weird to use guarantee and then having to guard it explicitly with !PRODUCT, but that is what I would have to do to get assertions in optimized build while still suppressing them in release builds, yes? I always assumed that the optimized build is supposed to be faster than fastdebug, so, expensive verifications should be better left to ASSERT? But then, I see quite some coding contradicting this expectation. The coding itself is no real guideline either, I see both ASSERT and !PRODUCT used without recognizing a clear pattern. So, still confused. Can someone enlighten me please :) Thanks & Regards, Thomas From matthias.baesken at sap.com Wed Jan 31 14:15:26 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 31 Jan 2018 14:15:26 +0000 Subject: RFR : 8196062 : Enable docker container related tests for linux ppc64le In-Reply-To: <4be36ed6-2f8e-2dd8-a87a-5f76d639550e@oracle.com> References: <3374db8c-6e7b-fe0b-6874-8289e9e369bc@oracle.com> <6fa3fe84aad946eabb2b46281031e21d@sap.com> <4be36ed6-2f8e-2dd8-a87a-5f76d639550e@oracle.com> Message-ID: <64a3268575d14ddcad90f7d46bab64dd@sap.com> Hello , I created a second webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8196062.1/8196062.1/webrev/ - changed DockerTestUtils.buildJdkDockerImage in the suggested way (this should be extendable to linux s390x soon) > >>> Can you add "return;" in each test for subsystem not found messages - added returns in the tests for the subsystems in osContainer_linux.cpp - moved some checks at the beginning of subsystem_file_contents (suggested by Dmitry) Best regards, Matthias > -----Original Message----- > From: mikhailo [mailto:mikhailo.seledtsov at oracle.com] > Sent: Donnerstag, 25. Januar 2018 18:43 > To: Baesken, Matthias ; Bob Vandette > > Cc: hotspot-dev at openjdk.java.net; Lindenmaier, Goetz > ; Langer, Christoph > ; Doerr, Martin > Subject: Re: RFR : 8196062 : Enable docker container related tests for linux > ppc64le > > Hi Matthias, > > > On 01/25/2018 12:15 AM, Baesken, Matthias wrote: > >> Perhaps, you could add code to DockerTestUtils.buildJdkDockerImage() > >> that does the following or similar: > >> 1. Construct a name for platform-specific docker file: > >> String platformSpecificDockerfile = dockerfile + "-" + > >> Platform.getOsArch(); > >> (Platform is jdk.test.lib.Platform) > >> > > Hello, the doc says : > > > > * Build a docker image that contains JDK under test. > > * The jdk will be placed under the "/jdk/" folder inside the docker file > system. > > ..... > > param dockerfile name of the dockerfile residing in the test source > > ..... > > public static void buildJdkDockerImage(String imageName, String > dockerfile, String buildDirName) > > > > > > > > It does not say anything about doing hidden insertions of some platform > names into the dockerfile name. > > So should the jtreg API doc be changed ? > > If so who needs to approve this ? > Thank you for your concerns about the clarity of API and corresponding > documentation. This is a test library API, so no need to file CCC or CSR. > > This API can be changed via a regular RFR/webrev review process, as soon > as on one objects. I am a VM SQE engineer covering the docker and Linux > container area, I am OK with this change. > And I agree with you, we should update the javadoc header on this method > to reflect this implicit part of API contract. > > > Thank you, > Misha > > > > > (as far as I see so far only the test at > hotspot/jtreg/runtime/containers/docker/ use this so it should not be a big > deal to change the interface?) > > > > Best regards, Matthias > > > > > > > > > >> -----Original Message----- > >> From: mikhailo [mailto:mikhailo.seledtsov at oracle.com] > >> Sent: Mittwoch, 24. Januar 2018 20:09 > >> To: Bob Vandette ; Baesken, Matthias > >> > >> Cc: hotspot-dev at openjdk.java.net; Lindenmaier, Goetz > >> ; Langer, Christoph > >> ; Doerr, Martin > >> Subject: Re: RFR : 8196062 : Enable docker container related tests for linux > >> ppc64le > >> > >> Hi Matthias, > >> > >> ?? Please see my comments about the test changes inline. > >> > >> > >> On 01/24/2018 07:13 AM, Bob Vandette wrote: > >>> osContainer_linux.cpp: > >>> > >>> Can you add "return;" in each test for subsystem not found messages > and > >>> remove these 3 lines OR move your tests for NULL & messages inside. > The > >> compiler can > >>> probably optimize this but I?d prefer more compact code. > >>> > >>> if (memory == NULL || cpuset == NULL || cpu == NULL || cpuacct == > NULL) > >> { > >>> 342 return; > >>> 343 } > >>> > >>> > >>> The other changes in osContainer_linux.cpp look ok. > >>> > >>> I forwarded your test changes to Misha, who wrote these. > >>> > >>> Since it?s likely that other platforms, such as aarch64, are going to run > into > >> the same problem, > >>> It would have been better to enable the tests based on the existence of > an > >> arch specific > >>> Dockerfile-BasicTest-{os.arch} rather than enabling specific arch?s in > >> VPProps.java. > >>> This approach would reduce the number of changes significantly and > allow > >> support to > >>> be added with 1 new file. > >>> > >>> You wouldn?t need "String dockerFileName = > >> Common.getDockerFileName();? > >>> in every test. Just make DockerTestUtils automatically add arch. > >> I like Bob's idea on handling platform-specific Dockerfiles. > >> > >> Perhaps, you could add code to DockerTestUtils.buildJdkDockerImage() > >> that does the following or similar: > >> ??? 1. Construct a name for platform-specific docker file: > >> ?????????? String platformSpecificDockerfile = dockerfile + "-" + > >> Platform.getOsArch(); > >> ?????????? (Platform is jdk.test.lib.Platform) > >> > >> ??? 2. Check if platformSpecificDockerfile file exists in the test > >> source directory > >> ????????? File.exists(Paths.get(Utils.TEST_SRC, platformSpecificDockerFile) > >> ????????? If it does, then use it. Otherwise continue using the > >> default/original dockerfile name. > >> > >> I think this will considerably simplify your change, as well as make it > >> easy to extend support to other platforms/configurations > >> in the future. Let us know what you think of this approach ? > >> > >> > >> Once your change gets (R)eviewed and approved, I can sponsor the push. > >> > >> > >> Thank you, > >> Misha > >> > >> > >> > >>> Bob. > >>> > >>> > >>> > >>>> On Jan 24, 2018, at 9:24 AM, Baesken, Matthias > >> wrote: > >>>> Hello, could you please review the following change : 8196062 : Enable > >> docker container related tests for linux ppc64le . > >>>> It adds docker container testing for linux ppc64 le (little endian) . > >>>> > >>>> A number of things had to be done : > >>>> ? Add a separate docker file > >> test/hotspot/jtreg/runtime/containers/docker/Dockerfile-BasicTest- > ppc64le > >> for linux ppc64 le which uses Ubuntu ( the Oracle Linux 7.2 used for > >> x86_64 seems not to be available for ppc64le ) > >>>> ? Fix parsing /proc/self/mountinfo and /proc/self/cgroup in > >> src/hotspot/os/linux/osContainer_linux.cpp , it could not handle the > >> format seen on SUSE LINUX 12.1 ppc64le (Host) and Ubuntu (Docker > >> container) > >>>> ? Add a bit more logging > >>>> > >>>> > >>>> Webrev : > >>>> > >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8196062/ > >>>> > >>>> > >>>> Bug : > >>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8196062 > >>>> > >>>> > >>>> After these adjustments I could run the runtime/containers/docker > - > >> jtreg tests successfully . > >>>> > >>>> Best regards, Matthias From coleen.phillimore at oracle.com Wed Jan 31 14:22:47 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 31 Jan 2018 09:22:47 -0500 Subject: fastdebug vs optimized? In-Reply-To: References: Message-ID: <5d2c26ec-10ac-db5f-22c0-0ee4ecdeb4fe@oracle.com> The idea of optimized was to have the performance of product but the printing and diagnostic options of debug.? We used to use it for debugging when we had a lot of race conditions in the vm (a long time ago now there are none J)?? We were sensitive to the size of the libjvm.so but since then and since logging, many of the printing functions have been exposed and diagnostic() flags were introduced. https://bugs.openjdk.java.net/browse/JDK-8183287 It's time to remove it and clean up the assert vs. debug macros, but currently unassigned. Thanks, Coleen On 1/31/18 8:52 AM, Thomas St?fe wrote: > Hi all, > > Sorry for asking the same question again, but I still struggle to > understand the difference between fastdebug and optimized builds. Not the > technical details, that is clear (I hope): > > optimized: optimized build with !ASSERT !PRODUCT > fastdebug: optimized build with ASSERT !PRODUCT > > but what the point is for having two builds with such similarities. What is > the optimized build used for? > > When should I guard verification code with ASSERT, when with !PRODUCT? As > for the latter, it feels weird to use guarantee and then having to guard it > explicitly with !PRODUCT, but that is what I would have to do to get > assertions in optimized build while still suppressing them in release > builds, yes? > > I always assumed that the optimized build is supposed to be faster than > fastdebug, so, expensive verifications should be better left to ASSERT? But > then, I see quite some coding contradicting this expectation. The coding > itself is no real guideline either, I see both ASSERT and !PRODUCT used > without recognizing a clear pattern. > > So, still confused. Can someone enlighten me please :) > > Thanks & Regards, Thomas From thomas.stuefe at gmail.com Wed Jan 31 14:43:21 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 31 Jan 2018 15:43:21 +0100 Subject: fastdebug vs optimized? In-Reply-To: <5d2c26ec-10ac-db5f-22c0-0ee4ecdeb4fe@oracle.com> References: <5d2c26ec-10ac-db5f-22c0-0ee4ecdeb4fe@oracle.com> Message-ID: On Wed, Jan 31, 2018 at 3:22 PM, wrote: > > The idea of optimized was to have the performance of product but the > printing and diagnostic options of debug. We used to use it for debugging > when we had a lot of race conditions in the vm (a long time ago now there > are none J) We were sensitive to the size of the libjvm.so but since then > and since logging, many of the printing functions have been exposed and > diagnostic() flags were introduced. > > https://bugs.openjdk.java.net/browse/JDK-8183287 > > It's time to remove it and clean up the assert vs. debug macros, but > currently unassigned. > > Thanks, > Coleen > > Thanks, Coleen! So, for me that means probably not to bother with !PRODUCT and just use ASSERT on verification code, right? ..Thomas > > On 1/31/18 8:52 AM, Thomas St?fe wrote: > >> Hi all, >> >> Sorry for asking the same question again, but I still struggle to >> understand the difference between fastdebug and optimized builds. Not the >> technical details, that is clear (I hope): >> >> optimized: optimized build with !ASSERT !PRODUCT >> fastdebug: optimized build with ASSERT !PRODUCT >> >> but what the point is for having two builds with such similarities. What >> is >> the optimized build used for? >> >> When should I guard verification code with ASSERT, when with !PRODUCT? As >> for the latter, it feels weird to use guarantee and then having to guard >> it >> explicitly with !PRODUCT, but that is what I would have to do to get >> assertions in optimized build while still suppressing them in release >> builds, yes? >> >> I always assumed that the optimized build is supposed to be faster than >> fastdebug, so, expensive verifications should be better left to ASSERT? >> But >> then, I see quite some coding contradicting this expectation. The coding >> itself is no real guideline either, I see both ASSERT and !PRODUCT used >> without recognizing a clear pattern. >> >> So, still confused. Can someone enlighten me please :) >> >> Thanks & Regards, Thomas >> > > From coleen.phillimore at oracle.com Wed Jan 31 15:59:01 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 31 Jan 2018 10:59:01 -0500 Subject: fastdebug vs optimized? In-Reply-To: References: <5d2c26ec-10ac-db5f-22c0-0ee4ecdeb4fe@oracle.com> Message-ID: <1b7fef9d-6138-72c1-fa52-8506dfd68c85@oracle.com> On 1/31/18 9:43 AM, Thomas St?fe wrote: > > > On Wed, Jan 31, 2018 at 3:22 PM, > wrote: > > > The idea of optimized was to have the performance of product but > the printing and diagnostic options of debug. We used to use it > for debugging when we had a lot of race conditions in the vm (a > long time ago now there are none J)?? We were sensitive to the > size of the libjvm.so but since then and since logging, many of > the printing functions have been exposed and diagnostic() flags > were introduced. > > https://bugs.openjdk.java.net/browse/JDK-8183287 > > > It's time to remove it and clean up the assert vs. debug macros, > but currently unassigned. > > Thanks, > Coleen > > > Thanks, Coleen! > > So, for me that means probably not to bother with !PRODUCT and just > use ASSERT on verification code, right? Yes, that seems right. Coleen > > ..Thomas > > > On 1/31/18 8:52 AM, Thomas St?fe wrote: > > Hi all, > > Sorry for asking the same question again, but I still struggle to > understand the difference between fastdebug and optimized > builds. Not the > technical details, that is clear (I hope): > > optimized: optimized build with !ASSERT !PRODUCT > fastdebug: optimized build with ASSERT !PRODUCT > > but what the point is for having two builds with such > similarities. What is > the optimized build used for? > > When should I guard verification code with ASSERT, when with > !PRODUCT? As > for the latter, it feels weird to use guarantee and then > having to guard it > explicitly with !PRODUCT, but that is what I would have to do > to get > assertions in optimized build while still suppressing them in > release > builds, yes? > > I always assumed that the optimized build is supposed to be > faster than > fastdebug, so, expensive verifications should be better left > to ASSERT? But > then, I see quite some coding contradicting this expectation. > The coding > itself is no real guideline either, I see both ASSERT and > !PRODUCT used > without recognizing a clear pattern. > > So, still confused. Can someone enlighten me please :) > > Thanks & Regards, Thomas > > > From stewartd.qdt at qualcommdatacenter.com Wed Jan 31 16:45:12 2018 From: stewartd.qdt at qualcommdatacenter.com (stewartd.qdt) Date: Wed, 31 Jan 2018 16:45:12 +0000 Subject: RFR: 8196361: JTReg failure in serviceability/sa/ClhsdbInspect.java In-Reply-To: <3318aed7-f04a-3b92-2660-39cdf13c2d24@oracle.com> References: <6e3441f3c28f4f7387d2174f52283fa7@NASANEXM01E.na.qualcomm.com> <44a71e46-3da2-53c6-7e6b-82658183ae8c@oracle.com> <3318aed7-f04a-3b92-2660-39cdf13c2d24@oracle.com> Message-ID: <24c556061ffb4fde9e87a8806c04c8f7@NASANEXM01E.na.qualcomm.com> Hi Jini, David, Please have a look at the revised webrev: http://cr.openjdk.java.net/~dstewart/8196361/webrev.01/ In this webrev I have changed the approach to finding the addresses. This was necessary because in the case of matching for the locks the addresses are before what is matched and in the case of Method the address is after it. The existing code only looked for the addresses after the matched string. I've also tried to align what tokens are being looked for in the lock case. I've taken an approach of breaking the jstack output into lines and then searching each line for it containing what we want. Once found, the line is broken into pieces to find the actual address we want. Please let me know if this is an unacceptable approach or any changes you would like to see. Thanks, Daniel -----Original Message----- From: Jini George [mailto:jini.george at oracle.com] Sent: Tuesday, January 30, 2018 6:58 AM To: David Holmes ; stewartd.qdt Cc: serviceability-dev ; hotspot-dev at openjdk.java.net Subject: Re: RFR: 8196361: JTReg failure in serviceability/sa/ClhsdbInspect.java Hi Daniel, David, Thanks, Daniel, for bringing this up. The intent of the test is to get the oop address corresponding to a java.lang.ref.ReferenceQueue$Lock, which can typically be obtained from the stack traces of the Common-Cleaner or the Finalizer threads. The stack traces which I had been noticing were typically of the form: "Common-Cleaner" #8 daemon prio=8 tid=0x00007f09c82ac000 nid=0xf6e in Object.wait() [0x00007f09a18d2000] java.lang.Thread.State: TIMED_WAITING (on object monitor) JavaThread state: _thread_blocked - java.lang.Object.wait(long) @bci=0, pc=0x00007f09b7d6480b, Method*=0x00007f09acc43d60 (Interpreted frame) - waiting on <0x000000072e61f6e0> (a java.lang.ref.ReferenceQueue$Lock) - java.lang.ref.ReferenceQueue.remove(long) @bci=59, line=151, pc=0x00007f09b7d55243, Method*=0x00007f09acdab9b0 (Interpreted frame) - waiting to re-lock in wait() <0x000000072e61f6e0> (a java.lang.ref.ReferenceQueue$Lock) ... I chose 'waiting to re-lock in wait' since that was what I had been observing next to the oop address of java.lang.ref.ReferenceQueue$Lock. But I see how with a timing difference, one could get 'waiting to lock' as in your case. So, a good way to fix might be to check for the line containing '(a java.lang.ref.ReferenceQueue$Lock)', getting the oop address from that line (should be the address appearing immediately before '(a java.lang.ref.ReferenceQueue$Lock)') and passing that to the 'inspect' command. Thanks much, Jini. On 1/30/2018 3:35 AM, David Holmes wrote: > Hi Daniel, > > Serviceability issues should go to serviceability-dev at openjdk.java.net > - now cc'd. > > On 30/01/2018 7:53 AM, stewartd.qdt wrote: >> Please review this webrev [1] which attempts to fix a test error in >> serviceability/sa/ClhsdbInspect.java when it is run under an AArch64 >> system (not necessarily exclusive to this system, but it was the >> system under test). The bug report [2] provides further details. >> Essentially the line "waiting to re-lock in wait" never actually >> occurs. Instead I have the line "waiting to lock" which occurs for >> the referenced item of /java/lang/ref/ReferenceQueue$Lock. >> Unfortunately the test is written such that only the first "waiting to lock" >> occurrence is seen (for java/lang/Class), which is already accounted >> for in the test. > > I can't tell exactly what the test expects, or why, but it would be > extremely hard to arrange for "waiting to re-lock in wait" to be seen > for the ReferenceQueue lock! That requires acquiring the lock > yourself, issuing a notify() to unblock the wait(), and then issuing > the jstack command while still holding the lock! > > David > ----- > >> I'm not overly happy with this approach as it actually removes a test >> line. However, the test line does not actually appear in the output >> (at least on my system) and the test is not currently written to look >> for the second occurrence of the line "waiting to lock". Perhaps the >> original author could chime in and provide further guidance as to the >> intention of the test. >> >> I am happy to modify the patch as necessary. >> >> Regards, >> Daniel Stewart >> >> >> [1] -? http://cr.openjdk.java.net/~dstewart/8196361/webrev.00/ >> [2] - https://bugs.openjdk.java.net/browse/JDK-8196361 >> From paul.sandoz at oracle.com Wed Jan 31 17:07:14 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 31 Jan 2018 09:07:14 -0800 Subject: RFR 8196508 Add jdeprscan test TestRelease.java to the problem list Message-ID: <6591CD48-B459-47A5-B293-7A75D30266D4@oracle.com> Hi, I am blocked pushing the change sets to constant dynamic due to the failure of jdeprscan test TestRelease.java. So i would like to add this to the problem list, push to the hs repo, and then i can push constant dynamic to hs. I have conservatively used a separate issue to that of another possibly related test on the problem list. Without further investigation it?s hard to tell if the two are related and i would prefer not to get side-tracked right now. Paul. # jdeps tools/jdeprscan/tests/jdk/jdeprscan/TestNotFound.java 8193784 generic-all temporary until support for --release 11 is worked out +tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java 8196479 generic-all temporary until support for --release 11 is worked out From stuart.marks at oracle.com Wed Jan 31 18:35:08 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 31 Jan 2018 10:35:08 -0800 Subject: RFR 8196508 Add jdeprscan test TestRelease.java to the problem list In-Reply-To: <6591CD48-B459-47A5-B293-7A75D30266D4@oracle.com> References: <6591CD48-B459-47A5-B293-7A75D30266D4@oracle.com> Message-ID: <2842cafe-b87e-55cb-33b1-d97ac37e4a46@oracle.com> Hi Paul, This looks fine. I think it makes sense to use a separate bug for this, since JDK-8193784 seems to cover --release support for tools in general, and JDK-8196479 covers specific jdeprscan changes. Thanks, s'marks On 1/31/18 9:07 AM, Paul Sandoz wrote: > Hi, > > I am blocked pushing the change sets to constant dynamic due to the failure of jdeprscan test TestRelease.java. > > So i would like to add this to the problem list, push to the hs repo, and then i can push constant dynamic to hs. > > I have conservatively used a separate issue to that of another possibly related test on the problem list. Without further investigation it?s hard to tell if the two are related and i would prefer not to get side-tracked right now. > > Paul. > > # jdeps > > tools/jdeprscan/tests/jdk/jdeprscan/TestNotFound.java 8193784 generic-all temporary until support for --release 11 is worked out > +tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java 8196479 generic-all temporary until support for --release 11 is worked out > From harold.seigel at oracle.com Wed Jan 31 19:30:05 2018 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 31 Jan 2018 14:30:05 -0500 Subject: RFR (S) 8196199: Remove miscellaneous oop comparison operators In-Reply-To: <0a17630f-3132-f5fa-fc87-7dd8023b02b1@oracle.com> References: <0a17630f-3132-f5fa-fc87-7dd8023b02b1@oracle.com> Message-ID: <63314b97-a727-68cb-f56a-b911e5809ba3@oracle.com> Hi Coleen, This change looks good. In jniCheck.cpp, you could use the is_null(oop obj) function defined in oop.hpp instead of 'oop == NULL'. Harold On 1/30/2018 5:58 PM, coleen.phillimore at oracle.com wrote: > CheckUnhandledOops had defined some oop comparison operators that will > have to be rewritten for new GCs.?? Kim Barrett did most of this > change. See CR for more info. > > Tested with JPRT (using currently supported GCs) tier1 and locally. > > open webrev at http://cr.openjdk.java.net/~coleenp/8196199.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8196199 > > Thanks, > Coleen From lois.foltan at oracle.com Wed Jan 31 20:11:55 2018 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 31 Jan 2018 15:11:55 -0500 Subject: RFR (S) 8196199: Remove miscellaneous oop comparison operators In-Reply-To: <0a17630f-3132-f5fa-fc87-7dd8023b02b1@oracle.com> References: <0a17630f-3132-f5fa-fc87-7dd8023b02b1@oracle.com> Message-ID: <87ceccae-e241-5c4d-5c10-f6a6a38ec736@oracle.com> On 1/30/2018 5:58 PM, coleen.phillimore at oracle.com wrote: > CheckUnhandledOops had defined some oop comparison operators that will > have to be rewritten for new GCs.?? Kim Barrett did most of this > change. See CR for more info. Looks good!? Just curious did you build and test the VM with CheckUnhandledOops defined and without? Thanks, Lois > > Tested with JPRT (using currently supported GCs) tier1 and locally. > > open webrev at http://cr.openjdk.java.net/~coleenp/8196199.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8196199 > > Thanks, > Coleen From coleen.phillimore at oracle.com Wed Jan 31 20:14:13 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 31 Jan 2018 15:14:13 -0500 Subject: RFR (S) 8196199: Remove miscellaneous oop comparison operators In-Reply-To: <87ceccae-e241-5c4d-5c10-f6a6a38ec736@oracle.com> References: <0a17630f-3132-f5fa-fc87-7dd8023b02b1@oracle.com> <87ceccae-e241-5c4d-5c10-f6a6a38ec736@oracle.com> Message-ID: On 1/31/18 3:11 PM, Lois Foltan wrote: > On 1/30/2018 5:58 PM, coleen.phillimore at oracle.com wrote: > >> CheckUnhandledOops had defined some oop comparison operators that >> will have to be rewritten for new GCs.?? Kim Barrett did most of this >> change. See CR for more info. > > Looks good!? Just curious did you build and test the VM with > CheckUnhandledOops defined and without? Thanks Lois.?? Yes I did.? I built in JPRT with build fastdebug and product.? I'll do a mach5 run in case windows compiler has a difference though. Thanks, Coleen > Thanks, > Lois > >> >> Tested with JPRT (using currently supported GCs) tier1 and locally. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8196199.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8196199 >> >> Thanks, >> Coleen > From lois.foltan at oracle.com Wed Jan 31 20:15:58 2018 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 31 Jan 2018 15:15:58 -0500 Subject: RFR (S) 8196199: Remove miscellaneous oop comparison operators In-Reply-To: References: <0a17630f-3132-f5fa-fc87-7dd8023b02b1@oracle.com> <87ceccae-e241-5c4d-5c10-f6a6a38ec736@oracle.com> Message-ID: On 1/31/2018 3:14 PM, coleen.phillimore at oracle.com wrote: > > > On 1/31/18 3:11 PM, Lois Foltan wrote: >> On 1/30/2018 5:58 PM, coleen.phillimore at oracle.com wrote: >> >>> CheckUnhandledOops had defined some oop comparison operators that >>> will have to be rewritten for new GCs.?? Kim Barrett did most of >>> this change. See CR for more info. >> >> Looks good!? Just curious did you build and test the VM with >> CheckUnhandledOops defined and without? > > Thanks Lois.?? Yes I did.? I built in JPRT with build fastdebug and > product.? I'll do a mach5 run in case windows compiler has a > difference though. Great, thank you! Lois > > Thanks, > Coleen > >> Thanks, >> Lois >> >>> >>> Tested with JPRT (using currently supported GCs) tier1 and locally. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8196199.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8196199 >>> >>> Thanks, >>> Coleen >> > From kim.barrett at oracle.com Wed Jan 31 21:01:02 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 31 Jan 2018 16:01:02 -0500 Subject: RFR (S) 8196199: Remove miscellaneous oop comparison operators In-Reply-To: <63314b97-a727-68cb-f56a-b911e5809ba3@oracle.com> References: <0a17630f-3132-f5fa-fc87-7dd8023b02b1@oracle.com> <63314b97-a727-68cb-f56a-b911e5809ba3@oracle.com> Message-ID: > On Jan 31, 2018, at 2:30 PM, harold seigel wrote: > > Hi Coleen, > > This change looks good. > > In jniCheck.cpp, you could use the is_null(oop obj) function defined in oop.hpp instead of 'oop == NULL?. I like this suggestion, and wish I?d thought of it while writing the initial code. I think it should be applied to all of the former uses of operator!. Coleen? > Harold > > > On 1/30/2018 5:58 PM, coleen.phillimore at oracle.com wrote: >> CheckUnhandledOops had defined some oop comparison operators that will have to be rewritten for new GCs. Kim Barrett did most of this change. See CR for more info. >> >> Tested with JPRT (using currently supported GCs) tier1 and locally. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8196199.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8196199 >> >> Thanks, >> Coleen From coleen.phillimore at oracle.com Wed Jan 31 21:05:56 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 31 Jan 2018 16:05:56 -0500 Subject: RFR (S) 8196199: Remove miscellaneous oop comparison operators In-Reply-To: References: <0a17630f-3132-f5fa-fc87-7dd8023b02b1@oracle.com> <63314b97-a727-68cb-f56a-b911e5809ba3@oracle.com> Message-ID: <4041e0ac-fef5-a20c-b249-29a3987a7328@oracle.com> On 1/31/18 4:01 PM, Kim Barrett wrote: >> On Jan 31, 2018, at 2:30 PM, harold seigel wrote: >> >> Hi Coleen, >> >> This change looks good. >> >> In jniCheck.cpp, you could use the is_null(oop obj) function defined in oop.hpp instead of 'oop == NULL?. > I like this suggestion, and wish I?d thought of it while writing the initial code. I think it should be applied to all of the former uses of operator!. Coleen? There are a zillion places where oop is compared with NULL.?? Or this pattern: Handle h(THREAD, someoop); if (h() != NULL) as well as if (h.is_not_null()) and if (!h.is_null()) which is my favorite thing because I can never remember offhand if the above is Handle::is_non_null() or Handle::is_not_null(). I don't think I would like to make this change. The oopDesc::is_null() function exists because it needs the overload for oop vs. narrowOop in the template instantiations of decode_heap_oop.? I think it's messy to use otherwise, and not needed for the new GCs. thanks, Coleen > >> Harold >> >> >> On 1/30/2018 5:58 PM, coleen.phillimore at oracle.com wrote: >>> CheckUnhandledOops had defined some oop comparison operators that will have to be rewritten for new GCs. Kim Barrett did most of this change. See CR for more info. >>> >>> Tested with JPRT (using currently supported GCs) tier1 and locally. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8196199.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8196199 >>> >>> Thanks, >>> Coleen > From david.holmes at oracle.com Wed Jan 31 21:46:04 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Feb 2018 07:46:04 +1000 Subject: fastdebug vs optimized? In-Reply-To: <5d2c26ec-10ac-db5f-22c0-0ee4ecdeb4fe@oracle.com> References: <5d2c26ec-10ac-db5f-22c0-0ee4ecdeb4fe@oracle.com> Message-ID: On 1/02/2018 12:22 AM, coleen.phillimore at oracle.com wrote: > The idea of optimized was to have the performance of product but the > printing and diagnostic options of debug.? We used to use it for I'll add though that for a long time there has been a lot of confusion around code conditional on DEBUG/ASSERT versus !PRODUCT. I think it would be hard to see much consistency on the usage now. > debugging when we had a lot of race conditions in the vm (a long time > ago now there are none J)?? We were sensitive to the size of the > libjvm.so but since then and since logging, many of the printing > functions have been exposed and diagnostic() flags were introduced. > > https://bugs.openjdk.java.net/browse/JDK-8183287 I think we had/have other issues relating to (mis)use of DEBUG, ASSERT, PRODUCT conditionals. David > It's time to remove it and clean up the assert vs. debug macros, but > currently unassigned. > > Thanks, > Coleen > > On 1/31/18 8:52 AM, Thomas St?fe wrote: >> Hi all, >> >> Sorry for asking the same question again, but I still struggle to >> understand the difference between fastdebug and optimized builds. Not the >> technical details, that is clear (I hope): >> >> optimized: optimized build with !ASSERT !PRODUCT >> fastdebug: optimized build with ASSERT !PRODUCT >> >> but what the point is for having two builds with such similarities. >> What is >> the optimized build used for? >> >> When should I guard verification code with ASSERT, when with !PRODUCT? As >> for the latter, it feels weird to use guarantee and then having to >> guard it >> explicitly with !PRODUCT, but that is what I would have to do to get >> assertions in optimized build while still suppressing them in release >> builds, yes? >> >> I always assumed that the optimized build is supposed to be faster than >> fastdebug, so, expensive verifications should be better left to >> ASSERT? But >> then, I see quite some coding contradicting this expectation. The coding >> itself is no real guideline either, I see both ASSERT and !PRODUCT used >> without recognizing a clear pattern. >> >> So, still confused. Can someone enlighten me please :) >> >> Thanks & Regards, Thomas > From kim.barrett at oracle.com Wed Jan 31 22:11:24 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 31 Jan 2018 17:11:24 -0500 Subject: RFR (S) 8196199: Remove miscellaneous oop comparison operators In-Reply-To: <4041e0ac-fef5-a20c-b249-29a3987a7328@oracle.com> References: <0a17630f-3132-f5fa-fc87-7dd8023b02b1@oracle.com> <63314b97-a727-68cb-f56a-b911e5809ba3@oracle.com> <4041e0ac-fef5-a20c-b249-29a3987a7328@oracle.com> Message-ID: > On Jan 31, 2018, at 4:05 PM, coleen.phillimore at oracle.com wrote: > > > > On 1/31/18 4:01 PM, Kim Barrett wrote: >>> On Jan 31, 2018, at 2:30 PM, harold seigel wrote: >>> >>> Hi Coleen, >>> >>> This change looks good. >>> >>> In jniCheck.cpp, you could use the is_null(oop obj) function defined in oop.hpp instead of 'oop == NULL?. >> I like this suggestion, and wish I?d thought of it while writing the initial code. I think it should be applied to all of the former uses of operator!. Coleen? > > There are a zillion places where oop is compared with NULL. I wasn?t suggesting a zillion places be changed. Only the half dozen places that formerly used operator! (via ?!x?) and are being changed to instead use ?x == NULL? in 8196199.01/webrev. From paul.sandoz at oracle.com Wed Jan 31 22:43:02 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 31 Jan 2018 14:43:02 -0800 Subject: Constant dynamic pushed to the hs repo Message-ID: Hi, I just pushed the constant dynamic change sets to hs [*]. It took a little longer than I anticipated to work through some of the review process given the holiday break. We should now be able to follow up, in the hs repo until the merge in some cases, with dependent issues such as the changes to support AArch64, SPARC, AoT/Graal, additional tests, and some bug/performance fixes. Thanks, Paul. [*] I?ll delay marking the JEP as integrated until a merge with the jdk master repo. After that we can then garbage collect the condy branch in the amber repo. From paul.sandoz at oracle.com Wed Jan 31 23:15:36 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 31 Jan 2018 15:15:36 -0800 Subject: [11] RFR 8195694: ConstantBootstraps.invoke does not preserve variable arity Message-ID: <6A5707B7-518C-43C2-98C9-6F52AAF3FE6F@oracle.com> Hi, Please review this fix to the invoke BSM so that it preserves variable arity, if any: http://cr.openjdk.java.net/~psandoz/jdk/JDK-8195694-constant-bsms-invoke-arity/webrev/ This will be pushed to the hs repo. Thanks, Paul. From john.r.rose at oracle.com Wed Jan 31 23:23:54 2018 From: john.r.rose at oracle.com (John Rose) Date: Wed, 31 Jan 2018 15:23:54 -0800 Subject: [11] RFR 8195694: ConstantBootstraps.invoke does not preserve variable arity In-Reply-To: <6A5707B7-518C-43C2-98C9-6F52AAF3FE6F@oracle.com> References: <6A5707B7-518C-43C2-98C9-6F52AAF3FE6F@oracle.com> Message-ID: If you remove the old asType call it?s good! > On Jan 31, 2018, at 3:15 PM, Paul Sandoz wrote: > > Hi, > > Please review this fix to the invoke BSM so that it preserves variable arity, if any: > > http://cr.openjdk.java.net/~psandoz/jdk/JDK-8195694-constant-bsms-invoke-arity/webrev/ > > This will be pushed to the hs repo. > > Thanks, > Paul. From john.r.rose at oracle.com Wed Jan 31 23:49:40 2018 From: john.r.rose at oracle.com (John Rose) Date: Wed, 31 Jan 2018 15:49:40 -0800 Subject: [11] RFR 8195694: ConstantBootstraps.invoke does not preserve variable arity In-Reply-To: References: <6A5707B7-518C-43C2-98C9-6F52AAF3FE6F@oracle.com> Message-ID: <476DA321-6EAB-4C27-A5CE-5776E29F7646@oracle.com> On second thought, you should also use invokeWithArguments to support jumbo arities. This tricky idiom should be put into a utility method, package private for starters. A version of it also appears in BSM invocation code. > On Jan 31, 2018, at 3:23 PM, John Rose wrote: > > If you remove the old asType call it?s good! > >> On Jan 31, 2018, at 3:15 PM, Paul Sandoz wrote: >> >> Hi, >> >> Please review this fix to the invoke BSM so that it preserves variable arity, if any: >> >> http://cr.openjdk.java.net/~psandoz/jdk/JDK-8195694-constant-bsms-invoke-arity/webrev/ >> >> This will be pushed to the hs repo. >> >> Thanks, >> Paul. >