From jamsheed.c.m at oracle.com Sat Jun 1 07:26:39 2019 From: jamsheed.c.m at oracle.com (Jamsheed) Date: Sat, 1 Jun 2019 12:56:39 +0530 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <611e1925-5384-9c74-064a-da30ba523268@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <718af50a-74b0-6417-55b5-9b8badcc1f4e@oracle.com> <742307c4-9dd0-4c5f-514b-e53fa3ac51a8@oracle.com> <7ce71707-967b-4748-f7e0-12c1743e939a@oracle.com> <5ddacc0b-a534-d751-73fa-3e2af7a70065@oracle.com> <8b4629d4-6b3a-0e29-82f8-760719c5daeb@redhat.com> <0ea5f1b5-1245-551b-90fd-7a63e8f15e92@oracle.com> <4354a0db-8f50-4eb0-af63-cadd5dde7ae5@oracle.com> <95af6958-6512-d894-2076-74f1b68e3dbe@oracle.com> <5422bc1c-4640-b3c8-bf26-b91a6df34f1e@oracle.com> <2848933c-e6bc-be44-7970-436ac00f0479@oracle.com> <188da7c3-7384-220a-9290-cdd4bad25fce@oracle.com> <2ddfbcbd-4dff-4b86-ba0b-d5920b80e7ec@oracle.com> <38eaa1b2-5fde-ca1d-0842-3d7f2b34e483@oracle.com> <611e1925-5384-9c74-064a-da30ba523268@oracle.com> Message-ID: <5e8afd81-37db-3a3f-1589-97a447cdc206@oracle.com> Hi Dan, i understand it is incorrect to assume bool(cpp compiler) implementation above byte level. in that case i will just put an assert. +? BasicType doing_unsafe_access_bt = T_BYTE; + assert(sizeof(bool) == 1, "not implemented"); Best regards, Jamsheed On 31/05/19 10:34 PM, Jamsheed wrote: >> src/hotspot/share/opto/library_call.cpp >> ??? In src/hotspot/share/runtime/thread.hpp: >> ??? L1090: ? volatile bool???????? _doing_unsafe_access; >> >> ??? L4220: ? store_to_memory(control(), doing_unsafe_access_addr, >> intcon(1), T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); >> ??? L4230: ? store_to_memory(control(), doing_unsafe_access_addr, >> intcon(0), T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); >> ??????? Is T_BYTE a safe assumption (size wise) for writing to a C++ >> bool? > > Thanks for pointing this. > > hope [1] will work ? [1] +? BasicType doing_unsafe_access_bt = T_BYTE; +? switch(sizeof(bool)) { +??? case 1: doing_unsafe_access_bt = T_BYTE;? break; +??? case 2: doing_unsafe_access_bt = T_SHORT; break; +??? case 4: doing_unsafe_access_bt = T_INT;?? break; +??? case 8: doing_unsafe_access_bt = T_LONG;? break; +??? default: ShouldNotReachHere(); +? } ?? // update volatile field -? store_to_memory(control(), doing_unsafe_access_addr, intcon(1), T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); +? store_to_memory(control(), doing_unsafe_access_addr, intcon(1), doing_unsafe_access_bt, Compile::AliasIdxRaw, MemNode::unordered); ?? // Call it.? Note that the length argument is not scaled. ?? make_runtime_call(RC_LEAF|RC_NO_FP, ???????????????????? OptoRuntime::fast_arraycopy_Type(), ???????????????????? StubRoutines::unsafe_arraycopy(), ???????????????????? "unsafe_arraycopy", ???????????????????? TypeRawPtr::BOTTOM, ???????????????????? src, dst, size XTOP); -? store_to_memory(control(), doing_unsafe_access_addr, intcon(0), T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); +? store_to_memory(control(), doing_unsafe_access_addr, intcon(0), doing_unsafe_access_bt, Compile::AliasIdxRaw, MemNode::unordered); From jamsheed.c.m at oracle.com Sat Jun 1 09:11:16 2019 From: jamsheed.c.m at oracle.com (Jamsheed) Date: Sat, 1 Jun 2019 14:41:16 +0530 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <5e8afd81-37db-3a3f-1589-97a447cdc206@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <742307c4-9dd0-4c5f-514b-e53fa3ac51a8@oracle.com> <7ce71707-967b-4748-f7e0-12c1743e939a@oracle.com> <5ddacc0b-a534-d751-73fa-3e2af7a70065@oracle.com> <8b4629d4-6b3a-0e29-82f8-760719c5daeb@redhat.com> <0ea5f1b5-1245-551b-90fd-7a63e8f15e92@oracle.com> <4354a0db-8f50-4eb0-af63-cadd5dde7ae5@oracle.com> <95af6958-6512-d894-2076-74f1b68e3dbe@oracle.com> <5422bc1c-4640-b3c8-bf26-b91a6df34f1e@oracle.com> <2848933c-e6bc-be44-7970-436ac00f0479@oracle.com> <188da7c3-7384-220a-9290-cdd4bad25fce@oracle.com> <2ddfbcbd-4dff-4b86-ba0b-d5920b80e7ec@oracle.com> <38eaa1b2-5fde-ca1d-0842-3d7f2b34e483@oracle.com> <611e1925-5384-9c74-064a-da30ba523268@oracle.com> <5e8afd81-37db-3a3f-1589-97a447cdc206@oracle.com> Message-ID: Hi Dan, updated webrev in place added only assert +? BasicType doing_unsafe_access_bt = T_BYTE; +? assert((sizeof(bool) * CHAR_BIT) == 8, "not implemented"); Best regards, Jamsheed On 01/06/19 12:56 PM, Jamsheed wrote: > > Hi Dan, > > i understand it is incorrect to assume bool(cpp compiler) > implementation above byte level. > > in that case i will just put an assert. > > +? BasicType doing_unsafe_access_bt = T_BYTE; > > + assert(sizeof(bool) == 1, "not implemented"); > > Best regards, > > Jamsheed > > On 31/05/19 10:34 PM, Jamsheed wrote: >>> src/hotspot/share/opto/library_call.cpp >>> ??? In src/hotspot/share/runtime/thread.hpp: >>> ??? L1090: ? volatile bool???????? _doing_unsafe_access; >>> >>> ??? L4220: ? store_to_memory(control(), doing_unsafe_access_addr, >>> intcon(1), T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); >>> ??? L4230: ? store_to_memory(control(), doing_unsafe_access_addr, >>> intcon(0), T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); >>> ??????? Is T_BYTE a safe assumption (size wise) for writing to a C++ >>> bool? >> >> Thanks for pointing this. >> >> hope [1] will work ? > [1] > +? BasicType doing_unsafe_access_bt = T_BYTE; > +? switch(sizeof(bool)) { > +??? case 1: doing_unsafe_access_bt = T_BYTE;? break; > +??? case 2: doing_unsafe_access_bt = T_SHORT; break; > +??? case 4: doing_unsafe_access_bt = T_INT;?? break; > +??? case 8: doing_unsafe_access_bt = T_LONG;? break; > +??? default: ShouldNotReachHere(); > +? } > > ?? // update volatile field > -? store_to_memory(control(), doing_unsafe_access_addr, intcon(1), > T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); > +? store_to_memory(control(), doing_unsafe_access_addr, intcon(1), > doing_unsafe_access_bt, Compile::AliasIdxRaw, MemNode::unordered); > > ?? // Call it.? Note that the length argument is not scaled. > ?? make_runtime_call(RC_LEAF|RC_NO_FP, > ???????????????????? OptoRuntime::fast_arraycopy_Type(), > ???????????????????? StubRoutines::unsafe_arraycopy(), > ???????????????????? "unsafe_arraycopy", > ???????????????????? TypeRawPtr::BOTTOM, > ???????????????????? src, dst, size XTOP); > > -? store_to_memory(control(), doing_unsafe_access_addr, intcon(0), > T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); > +? store_to_memory(control(), doing_unsafe_access_addr, intcon(0), > doing_unsafe_access_bt, Compile::AliasIdxRaw, MemNode::unordered); From daniel.daugherty at oracle.com Sat Jun 1 12:58:42 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 1 Jun 2019 08:58:42 -0400 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <5e8afd81-37db-3a3f-1589-97a447cdc206@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <742307c4-9dd0-4c5f-514b-e53fa3ac51a8@oracle.com> <7ce71707-967b-4748-f7e0-12c1743e939a@oracle.com> <5ddacc0b-a534-d751-73fa-3e2af7a70065@oracle.com> <8b4629d4-6b3a-0e29-82f8-760719c5daeb@redhat.com> <0ea5f1b5-1245-551b-90fd-7a63e8f15e92@oracle.com> <4354a0db-8f50-4eb0-af63-cadd5dde7ae5@oracle.com> <95af6958-6512-d894-2076-74f1b68e3dbe@oracle.com> <5422bc1c-4640-b3c8-bf26-b91a6df34f1e@oracle.com> <2848933c-e6bc-be44-7970-436ac00f0479@oracle.com> <188da7c3-7384-220a-9290-cdd4bad25fce@oracle.com> <2ddfbcbd-4dff-4b86-ba0b-d5920b80e7ec@oracle.com> <38eaa1b2-5fde-ca1d-0842-3d7f2b34e483@oracle.com> <611e1925-5384-9c74-064a-da30ba523268@oracle.com> <5e8afd81-37db-3a3f-1589-97a447cdc206@oracle.com> Message-ID: That sounds like a good guard. Thanks. Dan On 6/1/19 3:26 AM, Jamsheed wrote: > > Hi Dan, > > i understand it is incorrect to assume bool(cpp compiler) > implementation above byte level. > > in that case i will just put an assert. > > +? BasicType doing_unsafe_access_bt = T_BYTE; > > + assert(sizeof(bool) == 1, "not implemented"); > > Best regards, > > Jamsheed > > On 31/05/19 10:34 PM, Jamsheed wrote: >>> src/hotspot/share/opto/library_call.cpp >>> ??? In src/hotspot/share/runtime/thread.hpp: >>> ??? L1090: ? volatile bool???????? _doing_unsafe_access; >>> >>> ??? L4220: ? store_to_memory(control(), doing_unsafe_access_addr, >>> intcon(1), T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); >>> ??? L4230: ? store_to_memory(control(), doing_unsafe_access_addr, >>> intcon(0), T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); >>> ??????? Is T_BYTE a safe assumption (size wise) for writing to a C++ >>> bool? >> >> Thanks for pointing this. >> >> hope [1] will work ? > [1] > +? BasicType doing_unsafe_access_bt = T_BYTE; > +? switch(sizeof(bool)) { > +??? case 1: doing_unsafe_access_bt = T_BYTE;? break; > +??? case 2: doing_unsafe_access_bt = T_SHORT; break; > +??? case 4: doing_unsafe_access_bt = T_INT;?? break; > +??? case 8: doing_unsafe_access_bt = T_LONG;? break; > +??? default: ShouldNotReachHere(); > +? } > > ?? // update volatile field > -? store_to_memory(control(), doing_unsafe_access_addr, intcon(1), > T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); > +? store_to_memory(control(), doing_unsafe_access_addr, intcon(1), > doing_unsafe_access_bt, Compile::AliasIdxRaw, MemNode::unordered); > > ?? // Call it.? Note that the length argument is not scaled. > ?? make_runtime_call(RC_LEAF|RC_NO_FP, > ???????????????????? OptoRuntime::fast_arraycopy_Type(), > ???????????????????? StubRoutines::unsafe_arraycopy(), > ???????????????????? "unsafe_arraycopy", > ???????????????????? TypeRawPtr::BOTTOM, > ???????????????????? src, dst, size XTOP); > > -? store_to_memory(control(), doing_unsafe_access_addr, intcon(0), > T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); > +? store_to_memory(control(), doing_unsafe_access_addr, intcon(0), > doing_unsafe_access_bt, Compile::AliasIdxRaw, MemNode::unordered); From daniel.daugherty at oracle.com Sat Jun 1 12:59:28 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 1 Jun 2019 08:59:28 -0400 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <7ce71707-967b-4748-f7e0-12c1743e939a@oracle.com> <5ddacc0b-a534-d751-73fa-3e2af7a70065@oracle.com> <8b4629d4-6b3a-0e29-82f8-760719c5daeb@redhat.com> <0ea5f1b5-1245-551b-90fd-7a63e8f15e92@oracle.com> <4354a0db-8f50-4eb0-af63-cadd5dde7ae5@oracle.com> <95af6958-6512-d894-2076-74f1b68e3dbe@oracle.com> <5422bc1c-4640-b3c8-bf26-b91a6df34f1e@oracle.com> <2848933c-e6bc-be44-7970-436ac00f0479@oracle.com> <188da7c3-7384-220a-9290-cdd4bad25fce@oracle.com> <2ddfbcbd-4dff-4b86-ba0b-d5920b80e7ec@oracle.com> <38eaa1b2-5fde-ca1d-0842-3d7f2b34e483@oracle.com> <611e1925-5384-9c74-064a-da30ba523268@oracle.com> <5e8afd81-37db-3a3f-1589-97a447cdc206@oracle.com> Message-ID: That's even better. Thanks. Dan On 6/1/19 5:11 AM, Jamsheed wrote: > > Hi Dan, > > updated webrev in place > > added only assert > > +? BasicType doing_unsafe_access_bt = T_BYTE; > +? assert((sizeof(bool) * CHAR_BIT) == 8, "not implemented"); > > Best regards, > > Jamsheed > > On 01/06/19 12:56 PM, Jamsheed wrote: >> >> Hi Dan, >> >> i understand it is incorrect to assume bool(cpp compiler) >> implementation above byte level. >> >> in that case i will just put an assert. >> >> +? BasicType doing_unsafe_access_bt = T_BYTE; >> >> + assert(sizeof(bool) == 1, "not implemented"); >> >> Best regards, >> >> Jamsheed >> >> On 31/05/19 10:34 PM, Jamsheed wrote: >>>> src/hotspot/share/opto/library_call.cpp >>>> ??? In src/hotspot/share/runtime/thread.hpp: >>>> ??? L1090: ? volatile bool???????? _doing_unsafe_access; >>>> >>>> ??? L4220: ? store_to_memory(control(), doing_unsafe_access_addr, >>>> intcon(1), T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); >>>> ??? L4230: ? store_to_memory(control(), doing_unsafe_access_addr, >>>> intcon(0), T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); >>>> ??????? Is T_BYTE a safe assumption (size wise) for writing to a >>>> C++ bool? >>> >>> Thanks for pointing this. >>> >>> hope [1] will work ? >> [1] >> +? BasicType doing_unsafe_access_bt = T_BYTE; >> +? switch(sizeof(bool)) { >> +??? case 1: doing_unsafe_access_bt = T_BYTE;? break; >> +??? case 2: doing_unsafe_access_bt = T_SHORT; break; >> +??? case 4: doing_unsafe_access_bt = T_INT;?? break; >> +??? case 8: doing_unsafe_access_bt = T_LONG;? break; >> +??? default: ShouldNotReachHere(); >> +? } >> >> ?? // update volatile field >> -? store_to_memory(control(), doing_unsafe_access_addr, intcon(1), >> T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); >> +? store_to_memory(control(), doing_unsafe_access_addr, intcon(1), >> doing_unsafe_access_bt, Compile::AliasIdxRaw, MemNode::unordered); >> >> ?? // Call it.? Note that the length argument is not scaled. >> ?? make_runtime_call(RC_LEAF|RC_NO_FP, >> ???????????????????? OptoRuntime::fast_arraycopy_Type(), >> ???????????????????? StubRoutines::unsafe_arraycopy(), >> ???????????????????? "unsafe_arraycopy", >> ???????????????????? TypeRawPtr::BOTTOM, >> ???????????????????? src, dst, size XTOP); >> >> -? store_to_memory(control(), doing_unsafe_access_addr, intcon(0), >> T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); >> +? store_to_memory(control(), doing_unsafe_access_addr, intcon(0), >> doing_unsafe_access_bt, Compile::AliasIdxRaw, MemNode::unordered); From thomas.stuefe at gmail.com Mon Jun 3 06:08:45 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 3 Jun 2019 08:08:45 +0200 Subject: RFR(s): 8224600: Provide VM.events command In-Reply-To: References: Message-ID: Hi David, thanks for reviewing! New webrev below and comments inline. On Thu, May 30, 2019 at 8:48 AM David Holmes wrote: > Hi Thomas, > > On 24/05/2019 5:51 am, Thomas St?fe wrote: > > Hi all, > > > > May I please have reviews for the following addition to jcmd. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224600 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8224601 > > webrev: > > > http://cr.openjdk.java.net/~stuefe/webrevs/vm.events/webrev.00/webrev/index.html > > This seems quite reasonable but I have a couple of queries/comments: > > Where do the short-names of the logs get used? Is that what you ask for > via the Dcmd? I added the short names (now renamed to "handle") because selecting by the event log full name was cumbersome. The full name is more of a headline consisting of multiple words, e.g. "Deoptimization events". > How does the user know what logs are available? > I print a list of valid names out if the user specifies an event log which does not exist. See Events::print_one(). I would have liked to print this list as part of the command help; however, that would have made the patch larger, added code duplication and made it much more complicated since the help command (HelpDCmd) is not really flexible and cannot deal easily with dynamic content. Especially not content which is order-of-initialization-dependend (diagnostic command initialization vs event log initialization). > > > // Print log names (for help output of VM.events > > This comment appears in a few places but is missing the final ). > > The test should have a single copyright year of 2019. > > Fixed. > The test should be checking all the variations to ensure if you ask for > exceptions you only get exceptions etc. > > Okay, I did add a test testing the selection feature. Since all I test is for the log event *headers* to appear - regardless of whether or not they are empty - this is okay. Any test relying on actual event log content would be way more difficult to do. Please note that I only tested the selection feature to work, but I see little value in testing any permutation of the "log" option. Would just make the test larger and more brittle and burn test machine time without any real value. Is the test guaranteed to see events of all types? In particular class > unloading may not occur in a short run (and only anonymous classes would > get unloaded unless custom loaders are involved). > > See above. Only test for the headers to appear. They also appear when the log is empty (e.g.: Deoptimization events (0 events): No events Classes unloaded (0 events): No events Classes redefined (0 events): No events Internal exceptions (0 events): No events Events (20 events): Event: 0,063 Executing VM operation: RevokeBias done Event: 0,071 Executing VM operation: HandshakeAllThreads Event: 0,071 Executing VM operation: HandshakeAllThreads done ... New webrev: delta: http://cr.openjdk.java.net/~stuefe/webrevs/vm.events/webrev_delta.01/webrev/ full: http://cr.openjdk.java.net/~stuefe/webrevs/vm.events/webrev.01/webrev/ I renamed "short name" to "handle" and rewrote a number of comments to make the code clearer. Do you know when I can expect the CSR to be approved? Thanks & Cheers, Thomas > From david.holmes at oracle.com Mon Jun 3 06:27:25 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 3 Jun 2019 16:27:25 +1000 Subject: RFR(s): 8224600: Provide VM.events command In-Reply-To: References: Message-ID: <459cf904-fbf8-b690-6017-61dca8816af4@oracle.com> Hi Thomas, Thanks for clarifying a few things. The updates look fine to me. For the CSR I suggest moving it to Finalized. Thanks, David On 3/06/2019 4:08 pm, Thomas St?fe wrote: > Hi David, > > thanks for reviewing! > > New webrev below and comments inline. > > On Thu, May 30, 2019 at 8:48 AM David Holmes > wrote: > > Hi Thomas, > > On 24/05/2019 5:51 am, Thomas St?fe wrote: > > Hi all, > > > > May I please have reviews for the following addition to jcmd. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224600 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8224601 > > webrev: > > > http://cr.openjdk.java.net/~stuefe/webrevs/vm.events/webrev.00/webrev/index.html > > This seems quite reasonable but I have a couple of queries/comments: > > Where do the short-names of the logs get used? Is that what you ask for > via the Dcmd? > > > I added the short names (now renamed to "handle") because selecting by > the event log full name was cumbersome. The full name is more of a > headline consisting of multiple words, e.g. "Deoptimization events". > > How does the user know what logs are available? > > > I print a list of valid names out if the user specifies an event log > which does not exist. See?Events::print_one(). > > I would have liked to print this list as part of the command help; > however, that would have made the patch larger, added code duplication > and made it much more complicated since the help command (HelpDCmd) is > not really flexible and cannot deal easily with dynamic content. > Especially not content which is order-of-initialization-dependend > (diagnostic command initialization vs event log initialization). > > > > // Print log names (for help output of VM.events > > This comment appears in a few places but is missing the final ). > > The test should have a single copyright year of 2019. > > > Fixed. > > The test should be checking all the variations to ensure if you ask for > exceptions you only get exceptions etc. > > > Okay, I did add a test testing the selection feature. Since all I test > is for the log event *headers* to appear - regardless of whether or not > they are empty - this is okay. Any test relying on actual event log > content would be way more difficult to do. > > Please note that I only tested the selection feature to work, but I see > little value in testing any permutation of the "log" option. Would just > make the test larger and more brittle and burn test machine time without > any real value. > > Is the test guaranteed to see events of all types? In particular class > unloading may not occur in a short run (and only anonymous classes > would > get unloaded unless custom loaders are involved). > > > See above. Only test for the headers to appear. They also appear when > the log is empty (e.g.: > > > Deoptimization events (0 events): > No events > > Classes unloaded (0 events): > No events > > Classes redefined (0 events): > No events > > Internal exceptions (0 events): > No events > > Events (20 events): > Event: 0,063 Executing VM operation: RevokeBias done > Event: 0,071 Executing VM operation: HandshakeAllThreads > Event: 0,071 Executing VM operation: HandshakeAllThreads done > ... > > > New webrev: > delta: > http://cr.openjdk.java.net/~stuefe/webrevs/vm.events/webrev_delta.01/webrev/ > full: http://cr.openjdk.java.net/~stuefe/webrevs/vm.events/webrev.01/webrev/ > > I renamed "short name" to "handle" and rewrote a number of comments to > make the code clearer. > > Do you know when I can expect the CSR to be approved? > > Thanks & Cheers, Thomas > > From nick.gasson at arm.com Mon Jun 3 06:58:39 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Mon, 3 Jun 2019 14:58:39 +0800 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com> References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com> <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com> Message-ID: <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com> Hi Kim, > If I'm reading the gcc documentation for __sync_add_and_fetch > correctly, I think the following (completely untested) should work, > and won't cause Andrew to (I think rightly) complain about > type-punning reinterpret_casts. > > Though I wonder if this is a clang bug. (See below.) > > template > struct Atomic::PlatformAdd > : Atomic::AddAndFetch > > { > template > D add_and_fetch(I add_value, D volatile* dest, atomic_memory_order order) const { > // Cast to work around clang pointer arithmetic bug. > return PrimitiveConversions::cast(__sync_add_and_fetch(dest, add_value)); > } > } This fails with: /home/nicgas01/jdk/src/hotspot/share/metaprogramming/primitiveConversions.hpp:162:10: error: invalid use of incomplete type 'struct PrimitiveConversions::Cast' return Cast()(x); ^~~~~~~~~~~~ I think because all the specialisations of PrimitiveConversions are only enabled if T is an integral type and here it's char*? > > The key bit from the documentation is "Operations on pointer arguments > are performed as if the operands were of the uintptr_t type." > > The bug description says this warning only arises with clang. It > seems like clang is overdoing that as-if, and treating it literally as > uintptr_t all the way through to the result type. > I think Clang is actually complaining about the argument types mismatching here. According to the GCC docs the __sync_add_and_fetch prototype looks like: type __sync_add_and_fetch (type *ptr, type value, ...) I guess Clang infers type=char* from the first argument, and complains that the second argument is unsigned long. So Clang gives an error for the following but GCC accepts it: char *ptr; unsigned long val; __sync_add_and_fetch(&ptr, val); Another way round this is to use __atomic_add_fetch instead which both Clang and GCC accept: template D add_and_fetch(I add_value, D volatile* dest, atomic_memory_order order) const { D res = __atomic_add_fetch(dest, add_value, __ATOMIC_RELEASE); FULL_MEM_BARRIER; return res; } > Or don't change the code at all here, and say that clang is not (currently) a supported > compiler for this platform. Yes, that's an option too :-). But we should change the configure script to give an error on --with-toolchain-type=clang on AArch64. Thanks, Nick From thomas.schatzl at oracle.com Mon Jun 3 08:16:53 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 03 Jun 2019 10:16:53 +0200 Subject: RFR: 8213415: BitMap::word_index_round_up overflow problems In-Reply-To: <24C2BDC9-AC35-4804-95C8-1B59747C1494@oracle.com> References: <24C2BDC9-AC35-4804-95C8-1B59747C1494@oracle.com> Message-ID: <33426790910a9238999256062c81ec708c93d638.camel@oracle.com> Hi, On Tue, 2019-05-28 at 14:10 -0400, Kim Barrett wrote: > Please review this change to BitMap index alignment to check for > overflows (in debug builds). Also made a few related API cleanups. > > Constructing a BitMap now ensures the size is such that rounding it > up to a word boundary won't overflow. This is the new > max_size_in_bits() value. This lets us add some asserts and otherwise > tidy things up in some places by making use of that information. > > This engendered some changes to ParallelGC's ParMarkBitMap. It no > longer uses the obsolete BitMap::word_align_up, instead having its > own internal helper for aligning range ends that knows about > invariants in ParMarkBitMap. > > Removed the following static functions from BitMap: word_align_up, > word_align_down, and is_word_aligned. word_align_up is no longer > used, after the ParMarkBitMap changes. The others were only used in > a small number of places in tests and asserts, and didn't seem worth > keeping instead of just using align.hpp stuff with BitsPerWord > alignment value. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8213415 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8213415/open.00/ > > Testing: > mach5 tier1-3 Minor comment: - bitmap.hpp: 52 // the bitmap. BitsPerWord bits per element. The second part is not a sentence. Maybe join these with a "with" instead of the full stop? Or "An element has BitsPerWord bits". Not sure this fact actually needs mention though. Maybe it would be useful to do a static assert like the following somewhere: STATIC_ASSERT(sizeof(bm_word_t) * BitsPerByte == BitsPerWord); To actually enforce this and not only talk about it in some comment? It's up to you whether you pick up these suggestions. Looks good. Thanks, Thomas From thomas.stuefe at gmail.com Mon Jun 3 08:17:20 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 3 Jun 2019 10:17:20 +0200 Subject: RFR(s): 8224600: Provide VM.events command In-Reply-To: <459cf904-fbf8-b690-6017-61dca8816af4@oracle.com> References: <459cf904-fbf8-b690-6017-61dca8816af4@oracle.com> Message-ID: Thanks a lot, David! On Mon, Jun 3, 2019 at 8:27 AM David Holmes wrote: > Hi Thomas, > > Thanks for clarifying a few things. The updates look fine to me. > > For the CSR I suggest moving it to Finalized. > > Thanks, > David > > On 3/06/2019 4:08 pm, Thomas St?fe wrote: > > Hi David, > > > > thanks for reviewing! > > > > New webrev below and comments inline. > > > > On Thu, May 30, 2019 at 8:48 AM David Holmes > > wrote: > > > > Hi Thomas, > > > > On 24/05/2019 5:51 am, Thomas St?fe wrote: > > > Hi all, > > > > > > May I please have reviews for the following addition to jcmd. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224600 > > > CSR: https://bugs.openjdk.java.net/browse/JDK-8224601 > > > webrev: > > > > > > http://cr.openjdk.java.net/~stuefe/webrevs/vm.events/webrev.00/webrev/index.html > > > > This seems quite reasonable but I have a couple of queries/comments: > > > > Where do the short-names of the logs get used? Is that what you ask > for > > via the Dcmd? > > > > > > I added the short names (now renamed to "handle") because selecting by > > the event log full name was cumbersome. The full name is more of a > > headline consisting of multiple words, e.g. "Deoptimization events". > > > > How does the user know what logs are available? > > > > > > I print a list of valid names out if the user specifies an event log > > which does not exist. See Events::print_one(). > > > > I would have liked to print this list as part of the command help; > > however, that would have made the patch larger, added code duplication > > and made it much more complicated since the help command (HelpDCmd) is > > not really flexible and cannot deal easily with dynamic content. > > Especially not content which is order-of-initialization-dependend > > (diagnostic command initialization vs event log initialization). > > > > > > > > // Print log names (for help output of VM.events > > > > This comment appears in a few places but is missing the final ). > > > > The test should have a single copyright year of 2019. > > > > > > Fixed. > > > > The test should be checking all the variations to ensure if you ask > for > > exceptions you only get exceptions etc. > > > > > > Okay, I did add a test testing the selection feature. Since all I test > > is for the log event *headers* to appear - regardless of whether or not > > they are empty - this is okay. Any test relying on actual event log > > content would be way more difficult to do. > > > > Please note that I only tested the selection feature to work, but I see > > little value in testing any permutation of the "log" option. Would just > > make the test larger and more brittle and burn test machine time without > > any real value. > > > > Is the test guaranteed to see events of all types? In particular > class > > unloading may not occur in a short run (and only anonymous classes > > would > > get unloaded unless custom loaders are involved). > > > > > > See above. Only test for the headers to appear. They also appear when > > the log is empty (e.g.: > > > > > > Deoptimization events (0 events): > > No events > > > > Classes unloaded (0 events): > > No events > > > > Classes redefined (0 events): > > No events > > > > Internal exceptions (0 events): > > No events > > > > Events (20 events): > > Event: 0,063 Executing VM operation: RevokeBias done > > Event: 0,071 Executing VM operation: HandshakeAllThreads > > Event: 0,071 Executing VM operation: HandshakeAllThreads done > > ... > > > > > > New webrev: > > delta: > > > http://cr.openjdk.java.net/~stuefe/webrevs/vm.events/webrev_delta.01/webrev/ > > full: > http://cr.openjdk.java.net/~stuefe/webrevs/vm.events/webrev.01/webrev/ > > > > I renamed "short name" to "handle" and rewrote a number of comments to > > make the code clearer. > > > > Do you know when I can expect the CSR to be approved? > > > > Thanks & Cheers, Thomas > > > > > From thomas.stuefe at gmail.com Mon Jun 3 08:19:38 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 3 Jun 2019 10:19:38 +0200 Subject: PING: RFR(s): 8224600: Provide VM.events command In-Reply-To: References: Message-ID: Hi all, may I please have a second reviewer for this. It is a rather small addition to add a new jcmd to print event logs. Bug: https://bugs.openjdk.java.net/browse/JDK-8224601 Latest webrev: http://cr.openjdk.java.net/~stuefe/webrevs/vm.events/webrev.01/webrev/ Thank you, Thomas On Thu, May 23, 2019 at 9:51 PM Thomas St?fe wrote: > Hi all, > > May I please have reviews for the following addition to jcmd. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224600 > CSR: https://bugs.openjdk.java.net/browse/JDK-8224601 > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/vm.events/webrev.00/webrev/index.html > > This adds a new command, "VM.events", which can be used to display VM > event logs. Please see linked CSR for details. > > The CSR itself is not yet approved but already in proposed state. > > Thanks, Thomas > From aph at redhat.com Mon Jun 3 08:32:13 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 3 Jun 2019 09:32:13 +0100 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com> References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com> <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com> <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com> Message-ID: <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com> On 6/3/19 7:58 AM, Nick Gasson wrote: > >> If I'm reading the gcc documentation for __sync_add_and_fetch >> correctly, I think the following (completely untested) should work, >> and won't cause Andrew to (I think rightly) complain about >> type-punning reinterpret_casts. >> >> Though I wonder if this is a clang bug. (See below.) It's arguably a mistake in the GCC documentation, but adding two pointers is not well defined whereas adding a pointer and an integer is. >> template >> struct Atomic::PlatformAdd >> : Atomic::AddAndFetch > >> { >> template >> D add_and_fetch(I add_value, D volatile* dest, atomic_memory_order order) const { >> // Cast to work around clang pointer arithmetic bug. >> return PrimitiveConversions::cast(__sync_add_and_fetch(dest, add_value)); >> } >> } > > This fails with: > > /home/nicgas01/jdk/src/hotspot/share/metaprogramming/primitiveConversions.hpp:162:10: error: invalid use of incomplete type 'struct PrimitiveConversions::Cast' > return Cast()(x); > ^~~~~~~~~~~~ > > I think because all the specialisations of PrimitiveConversions are only > enabled if T is an integral type and here it's char*? > >> >> The key bit from the documentation is "Operations on pointer arguments >> are performed as if the operands were of the uintptr_t type." >> >> The bug description says this warning only arises with clang. It >> seems like clang is overdoing that as-if, and treating it literally as >> uintptr_t all the way through to the result type. >> > > I think Clang is actually complaining about the argument types > mismatching here. According to the GCC docs the __sync_add_and_fetch > prototype looks like: > > type __sync_add_and_fetch (type *ptr, type value, ...) > > I guess Clang infers type=char* from the first argument, and complains > that the second argument is unsigned long. So Clang gives an error for > the following but GCC accepts it: > > char *ptr; > unsigned long val; > __sync_add_and_fetch(&ptr, val); > > Another way round this is to use __atomic_add_fetch instead which both > Clang and GCC accept: > > template > D add_and_fetch(I add_value, D volatile* dest, atomic_memory_order order) const { > D res = __atomic_add_fetch(dest, add_value, __ATOMIC_RELEASE); > FULL_MEM_BARRIER; > return res; > } I could live with that. >> Or don't change the code at all here, and say that clang is not >> (currently) a supported compiler for this platform. > > Yes, that's an option too :-). But we should change the configure script > to give an error on --with-toolchain-type=clang on AArch64. I don't think there's any need to boycott the whole compiler because of this bug. It would make more sense to try to get clang fixed. Maybe for now put the cast in #ifdef CLANG ? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nick.gasson at arm.com Mon Jun 3 09:08:45 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Mon, 3 Jun 2019 17:08:45 +0800 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com> References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com> <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com> <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com> <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com> Message-ID: <94de2466-4b73-7091-17ee-7168114df1ee@arm.com> Hi Andrew, On 03/06/2019 16:32, Andrew Haley wrote: > > I don't think there's any need to boycott the whole compiler because > of this bug. It would make more sense to try to get clang fixed. > > Maybe for now put the cast in #ifdef CLANG ? > I think I'd rather put the __atomic_fetch_add in an #ifdef CLANG? This seems a bit neater than casting the integer argument to a pointer. Did you have any thoughts about os::current_stack_pointer() from my earlier email? Thanks, Nick From aph at redhat.com Mon Jun 3 10:24:04 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 3 Jun 2019 11:24:04 +0100 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: <94de2466-4b73-7091-17ee-7168114df1ee@arm.com> References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com> <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com> <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com> <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com> <94de2466-4b73-7091-17ee-7168114df1ee@arm.com> Message-ID: <0b355166-4bb7-7de2-b30b-9a481aa085a2@redhat.com> On 6/3/19 10:08 AM, Nick Gasson wrote: > Hi Andrew, > > On 03/06/2019 16:32, Andrew Haley wrote: >> >> I don't think there's any need to boycott the whole compiler because >> of this bug. It would make more sense to try to get clang fixed. >> >> Maybe for now put the cast in #ifdef CLANG ? >> > > I think I'd rather put the __atomic_fetch_add in an #ifdef CLANG? This > seems a bit neater than casting the integer argument to a pointer. I guess the solution which uses __atomic_add_fetch instead is best. > Did you have any thoughts about os::current_stack_pointer() from my > earlier email? We need to know what it's used for to know which solution is right. I'm guessing the primary use case is asynchronous runtime stack probes, used by debugging tools. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nick.gasson at arm.com Mon Jun 3 10:36:10 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Mon, 3 Jun 2019 18:36:10 +0800 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: <0b355166-4bb7-7de2-b30b-9a481aa085a2@redhat.com> References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com> <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com> <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com> <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com> <94de2466-4b73-7091-17ee-7168114df1ee@arm.com> <0b355166-4bb7-7de2-b30b-9a481aa085a2@redhat.com> Message-ID: Hi Andrew, > > We need to know what it's used for to know which solution is right. I'm > guessing the primary use case is asynchronous runtime stack probes, used > by debugging tools. > Yes, we also have os::stack_shadow_pages_available() which uses it to calculate how much space there is between the current SP and the end of the stack. In this case I think it's ok as long as we don't return a value that's *above* the actual stack pointer. And os::current_frame(), which constructs a `frame' object using the FP of the caller, but the SP will point into the frame of os::current_frame(), so it seems it's already inaccurate. There's also a comment in os_linux.cpp that says "Don't use os::current_stack_pointer(), as its result can be slightly below current stack pointer". So I'm wondering if we can simplify this a lot and use __builtin_frame_address(0) which will give us the FP in os::current_stack_pointer (ought to be the caller's SP - 16). Zero does this currently. And maybe we can replace _get_previous_fp() with __builtin_frame_address(1)? Thanks, Nick From aph at redhat.com Mon Jun 3 11:03:53 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 3 Jun 2019 12:03:53 +0100 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com> <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com> <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com> <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com> <94de2466-4b73-7091-17ee-7168114df1ee@arm.com> <0b355166-4bb7-7de2-b30b-9a481aa085a2@redhat.com> Message-ID: Hi, On 6/3/19 11:36 AM, Nick Gasson wrote: > >> We need to know what it's used for to know which solution is right. I'm >> guessing the primary use case is asynchronous runtime stack probes, used >> by debugging tools. >> > > Yes, we also have os::stack_shadow_pages_available() which uses it to > calculate how much space there is between the current SP and the end of > the stack. In this case I think it's ok as long as we don't return a > value that's *above* the actual stack pointer. And os::current_frame(), > which constructs a `frame' object using the FP of the caller, but the SP > will point into the frame of os::current_frame(), so it seems it's > already inaccurate. Eww. > There's also a comment in os_linux.cpp that says "Don't use > os::current_stack_pointer(), as its result can be slightly below current > stack pointer". So I'm wondering if we can simplify this a lot and use > __builtin_frame_address(0) which will give us the FP in > os::current_stack_pointer (ought to be the caller's SP - 16). Zero does > this currently. And maybe we can replace _get_previous_fp() with > __builtin_frame_address(1)? Let's make os::current_stack_pointer() noinline, then make it return __builtin_frame_address(0). -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Mon Jun 3 17:13:22 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 3 Jun 2019 19:13:22 +0200 Subject: RFR: [8u] 8202353: os::readdir should use readdir instead of readdir_r In-Reply-To: References: Message-ID: <98eb0d53-beb8-92b7-cc99-69a4cbf587c9@redhat.com> On 5/31/19 7:17 PM, Andrew John Hughes wrote: > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8202353/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8202353 Looks fine. src/os/windows/vm/os_windows.cpp has the trailing newline removed? -Aleksey From jamsheed.c.m at oracle.com Mon Jun 3 18:42:47 2019 From: jamsheed.c.m at oracle.com (Jamsheed) Date: Tue, 4 Jun 2019 00:12:47 +0530 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <0486af70-8345-f631-3a49-2d7bb5d0081b@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <718af50a-74b0-6417-55b5-9b8badcc1f4e@oracle.com> <742307c4-9dd0-4c5f-514b-e53fa3ac51a8@oracle.com> <7ce71707-967b-4748-f7e0-12c1743e939a@oracle.com> <5ddacc0b-a534-d751-73fa-3e2af7a70065@oracle.com> <8b4629d4-6b3a-0e29-82f8-760719c5daeb@redhat.com> <0ea5f1b5-1245-551b-90fd-7a63e8f15e92@oracle.com> <4354a0db-8f50-4eb0-af63-cadd5dde7ae5@oracle.com> <95af6958-6512-d894-2076-74f1b68e3dbe@oracle.com> <5422bc1c-4640-b3c8-bf26-b91a6df34f1e@oracle.com> <2848933c-e6bc-be44-7970-436ac00f0479@oracle.com> <188da7c3-7384-220a-9290-cdd4bad25fce@oracle.com> <2ddfbcbd-4dff-4b86-ba0b-d5920b80e7ec@oracle.com> <59f2ec26-9945-3547-ada9-69b84928edbc@oracle.com> <0486af70-8345-f631-3a49-2d7bb5d0081b@oracle.com> Message-ID: <405296a4-a921-2f44-b823-53160ed2d1a4@oracle.com> Hi Vladimir, Dan, added two cases in? Assembler::locate_operand as movdqa was unrecognized. update webrev in place +??? case 0x6F: // movdq +??? case 0x7F: // movdq full diff : http://cr.openjdk.java.net/~jcm/8191278/webrev.06/ http://cr.openjdk.java.net/~jcm/8191278/webrev.05/ + (incremental patch) http://cr.openjdk.java.net/~jcm/8191278/webrev.06_02/ Best regards, Jamsheed On 31/05/19 10:34 PM, Jamsheed wrote: > Hi Vladimir, Dan, > > On 15/05/19 2:24 AM, Vladimir Kozlov wrote: >> Sorry, I missed this. Please "ping" if you do not get responses. >> >> It become even more complicated :( but I understand why you are doing >> this way. You did great job. >> >> I am thinking about separating the fix for arraycopy stubs fix and >> adding graceful exit for Unsafe_CopyMemory and Unsafe_CopySwapMemory. > ? It would be really good if it can be done in runtime, i tried this > approach as it seemed far more easier. > > ? aarch64 port cpp implementation actually crashes for Unsafe_CopyMemory. > >> >> My main concern is new swap code complicates reliable arraycopy code >> for very corner case. And you implemented it only for x64 anyway. > > copySwap cpp code may work for all cases (depends on compiler again) , > so i am ok with removing the changes. > > but today when i was testing the removed code[1], found another issue. > some x86 instructions generated by cpp copyswap code? is not > recognized by our assembler and it crashes in signalHandler > Assembler::locate_next_instruction(pc). i will investigate and file a > bug. > > Best regards, > > Jamsheed > > [1] > > full diff : http://cr.openjdk.java.net/~jcm/8191278/webrev.06/ > > http://cr.openjdk.java.net/~jcm/8191278/webrev.05/ + (incremental > patch) http://cr.openjdk.java.net/~jcm/8191278/webrev.06_02/ > >> >> I would like to hear what Runtime group think. >> >> On 4/30/19 8:17 PM, Jamsheed wrote: >>> Hi Vladimir, >>> >>> Thank you for all the feedback. >>> >>> please find the revised webrev. >>> >>> http://cr.openjdk.java.net/~jcm/8191278/webrev.05/ >>> >>> what changed >>> >>> 1) Unsafe Copy Memory regions, error exits are captured using >>> UnsafeCopyMemoryMark, UnsafeCopyMemory. >> >> This is good. >> >>> >>> 2) all Unsafe copy (intrinsic or native) ,uses array copy stub. >> >> Right, otherwise we would have to duplicate logic in Copy:: platform >> specific C++ methods. But may be it is fine to do in C++ in this >> case. Or not do that at all as other platforms. >> >>> >>> 3) Unsafe copyswap x64 implementation extends arraycopy stub and >>> used as reliable exit(fast exit too)*. it is not implemented for >>> other platforms. >> >> As I said I have concern about this. >> >> Thanks, >> Vladimir >> >>> >>> *copySwap was tested using copySwap test in jdk dir(with different >>> buffer sizes) >>> >>> newly added test tested on linux(aarch64,arm32,x86(32/64)) and >>> platforms in mach5. + mach(1-5) >>> >>> ppc test is not done. >>> >>> Best regards, >>> >>> Jamsheed >>> >>> >>> On 12/04/19 9:14 PM, Vladimir Kozlov wrote: >>>> Hi Jamsheed >>>> >>>> I think new methods and the table don't need to be part of >>>> StubRoutines class. Your new class is visible in all places too. >>>> You can move methods and table into new class. Then you don't need >>>> long names and new code will be in one place. >>>> >>>> Vladimir >>>> >>>> On 4/11/19 11:00 PM, Jamsheed wrote: >>>>> Hi Vladimir, >>>>> >>>>> On 12/04/19 12:20 AM, Vladimir Kozlov wrote: >>>>>> On 4/11/19 10:25 AM, Jamsheed wrote: >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> the runtime calls uses indirect call, and it is not that >>>>>>> straight forward to compare dst i guess. >>>>>> >>>>>> Okay. Yes, we may load dest into register since it is considered >>>>>> far call (outside CodeCache). >>>>>> But at least you can find nmethod. So we can do >>>>>> nm->has_unsafe_access() check. >>>>>> >>>>>>> >>>>>>> will use doing_unsafe_access and error table as you suggested, >>>>>>> doing_unsafe_access for intrinsic call doesn't require volatile >>>>>>> semantics in c2 i believe. >>>>>> >>>>>> Yes, we don't need fragile frame walking if we use >>>>>> doing_unsafe_access. >>>>>> >>>>>> There is MemBarCPUOrder already in inline_unsafe_copyMemory() >>>>>> which will prevent store instruction moves in generated code. But >>>>>> it does not prevent CPU (Aarch64?) to schedule store in different >>>>>> place. >>>>>> >>>>>> On other hand we need to read it in Signal handle. I would assume >>>>>> all stores should be flushed when we hit SEGV. >>>>> yes >>>>>> >>>>>> I thought about avoiding your error table. But you really need >>>>>> continuation PC for graceful return. >>>>>> I was thinking to have a new separate stub to restore registers >>>>>> and pop frame. But return code in stubs varies unfortunately. So >>>>>> we need a table. >>>>>> >>>>>> One complain about table is its name too long. And it should be >>>>>> unsafe_copymemory to hint intrinsic. Can it be >>>>>> unsafe_copymemory_error and UnsafeCopyMemoryError class. >>>>>> StubRoutines:: is_unsafe_copymemory() and >>>>>> next_pc_for_unsafe_copymemory_error() >>>>> yes >>>>>> >>>>>> I did not get why you providing next PC only for 64 bit VM. >>>>> >>>>> next_pc is calculated for all case(both 32 bit and 64 bit). this >>>>> should work for c2-intrisics at-least except for arm. >>>>> >>>>> fast exit is implemented only for x64, as of now. >>>>> >>>>>> >>>>>>> >>>>>>> all code whose behavior is unpredictable will be removed. like >>>>>>> arm int/c1, non intrinsic c2 (And other platforms). >>>>>> >>>>>> Okay. >>>>> >>>>> so i am planning to remove graceful exit for all unpredictable >>>>> cases. so old behavior will be seen if there is an exit at >>>>> startup(SIGBUS crash). >>>>> >>>>> and steady state use will be mostly c2 intrinsic and will have >>>>> graceful exit. >>>>> >>>>> Best regards, >>>>> >>>>> Jamsheed >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Jamsheed >>>>>>> >>>>>>> On 11/04/19 5:17 AM, Jamsheed wrote: >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> On 10/04/19 10:03 PM, Vladimir Kozlov wrote: >>>>>>>>> Okay, I see what you did. But it seems incomplete. You did not >>>>>>>>> set continue_pc for some platforms. Why? >>>>>>>> for some platform i don't have testing setup, others are not >>>>>>>> very much used in servers(32 bit case). >>>>>>>>> >>>>>>>>> Also this will trigger the code if we hit segv for normal >>>>>>>>> arraycopy. You may want to lookup caller frame to get address >>>>>>>>> from call instruction and compare it with _unsafe_arraycopy: >>>>>>>>> >>>>>>>>> if (StubCodeDesc::desc_for(pc)) { >>>>>>>>> ? frame fr = os::fetch_frame_from_context(uc); >>>>>>>>> ? address ret_pc = fr.sender_pc(); >>>>>>>>> ? CodeBlob* cb = CodeCache::find_blob_unsafe(ret_pc); >>>>>>>>> ? CompiledMethod* nm = (cb != NULL) ? >>>>>>>>> cb->as_compiled_method_or_null() : NULL; >>>>>>>>> ? if (nm != NULL && NativeCall::is_call_before(ret_pc)) { >>>>>>>>> ??? address dest = nativeCall_before(ret_pc)->destination(); >>>>>>>>> ??? if (dest == StubRoutines::_unsafe_arraycopy) { >>>>>>>>> >>>>>>>>> But you need to verify if it works. >>>>>>>> >>>>>>>> this should work i guess. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Jamsheed >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 4/9/19 8:08 PM, Jamsheed wrote: >>>>>>>>>> Hi Vladimir, >>>>>>>>>> >>>>>>>>>> Thank you for looking at this. >>>>>>>>>> >>>>>>>>>> On 10/04/19 4:01 AM, Vladimir Kozlov wrote: >>>>>>>>>>> Hi Jamsheed, >>>>>>>>>>> >>>>>>>>>>> Instead of finding PC in stubs we should use something >>>>>>>>>>> similar to GuardUnsafeAccess to set thread's >>>>>>>>>>> doing_unsafe_access flag when we call copy stub for unsafe >>>>>>>>>>> memory as you suggested first (in bug report). >>>>>>>>>>> >>>>>>>>>>> Interpreter set the flag for Unsafe.CopyMemory0() and >>>>>>>>>>> Unsafe.copySwapMemory0(). C2 has intrinsic only for >>>>>>>>>>> CopyMemory0(): >>>>>>>>>>> >>>>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/6ad0281a654e/src/hotspot/share/opto/library_call.cpp#l4189 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> It only use unsafe_arraycopy stab: >>>>>>>>>>> >>>>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/6ad0281a654e/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#l2434 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Setting on it's entry and cleaning on exit >>>>>>>>>>> Thread::_doing_unsafe_access field should be enough. Right? >>>>>>>>>>> >>>>>>>>>>> Or I am missing something? >>>>>>>>>> >>>>>>>>>> initially thought of implementing it that way[1], but as it >>>>>>>>>> is having both store and volatile semantics went with this >>>>>>>>>> zero overhead solution. >>>>>>>>>> >>>>>>>>>> also, that doesn't provide me? continuation pc, which is >>>>>>>>>> required for fast exit for bulkaccess or even for graceful >>>>>>>>>> exit in platform like arm. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> An other thing which bothering me is Harold's comment: >>>>>>>>>>> >>>>>>>>>>> "Unfortunately, "CompiledMethod* nm" gets set to NULL and so >>>>>>>>>>> handle_unsafe_access() is not executed." >>>>>>>>>>> >>>>>>>>>>> Where/why nm is NULLed? >>>>>>>>>> as we are in BufferBlob/RuntimeBlob(stub frame). >>>>>>>>>>> >>>>>>>>>>> Actually I think the whole code for "// BugId 4454115" is >>>>>>>>>>> questionable since it replaces any crash (most likely not >>>>>>>>>>> related to unsafe access) in compiled method which has at >>>>>>>>>>> least one unsafe access with exception. May be we should use >>>>>>>>>>> PcDesc to record unsafe instructions and compare with SEGV >>>>>>>>>>> PC. But it is separate RFE. For this one we need to fix only >>>>>>>>>>> Unsafe.CopyMemory0() C2 inrinsic. >>>>>>>>>> >>>>>>>>>> Right, Ok. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> >>>>>>>>>> Jamsheed >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>> [1]http://cr.openjdk.java.net/~jcm/8191278/webrev.00/src/hotspot/share/opto/library_call.cpp.udiff.html >>>>>>>>>> >>>>>>>>>>> On 4/8/19 4:21 AM, Tobias Hartmann wrote: >>>>>>>>>>>> Hi Jamsheed, >>>>>>>>>>>> >>>>>>>>>>>> On 05.04.19 15:11, Jamsheed wrote: >>>>>>>>>>>>> On 04/04/19 7:23 PM, Andrew Haley wrote: >>>>>>>>>>>>>>> this looks reasonable to me although the code is getting >>>>>>>>>>>>>>> quite complicated to handle this edge case. >>>>>>>>>>>>>> Yeah, it really is. Can't we just assume that *any* fault >>>>>>>>>>>>>> in these stubs is >>>>>>>>>>>>>> caused via Unsafe, and get rid of bool >>>>>>>>>>>>>> unsafe_copy_code_range? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for the feedback Tobias, Andrew, removed >>>>>>>>>>>>> unsafe_copy_code_range. >>>>>>>>>>>>> >>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~jcm/8191278/webrev.04/ >>>>>>>>>>>> >>>>>>>>>>>> I think what Andrew meant is basically to go with webrev.01: >>>>>>>>>>>> http://cr.openjdk.java.net/~jcm/8191278/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> Right? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Tobias >>>>>>>>>>>> From jamsheed.c.m at oracle.com Mon Jun 3 18:43:47 2019 From: jamsheed.c.m at oracle.com (Jamsheed) Date: Tue, 4 Jun 2019 00:13:47 +0530 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <5ddacc0b-a534-d751-73fa-3e2af7a70065@oracle.com> <8b4629d4-6b3a-0e29-82f8-760719c5daeb@redhat.com> <0ea5f1b5-1245-551b-90fd-7a63e8f15e92@oracle.com> <4354a0db-8f50-4eb0-af63-cadd5dde7ae5@oracle.com> <95af6958-6512-d894-2076-74f1b68e3dbe@oracle.com> <5422bc1c-4640-b3c8-bf26-b91a6df34f1e@oracle.com> <2848933c-e6bc-be44-7970-436ac00f0479@oracle.com> <188da7c3-7384-220a-9290-cdd4bad25fce@oracle.com> <2ddfbcbd-4dff-4b86-ba0b-d5920b80e7ec@oracle.com> <38eaa1b2-5fde-ca1d-0842-3d7f2b34e483@oracle.com> <611e1925-5384-9c74-064a-da30ba523268@oracle.com> <5e8afd81-37db-3a3f-1589-97a447cdc206@oracle.com> Message-ID: <891289e9-e661-bee7-7365-5266e894b721@oracle.com> Hi Dan, Thanks for the review. Best regards, Jamsheed On 01/06/19 6:29 PM, Daniel D. Daugherty wrote: > That's even better. Thanks. > > Dan > > > On 6/1/19 5:11 AM, Jamsheed wrote: >> >> Hi Dan, >> >> updated webrev in place >> >> added only assert >> >> +? BasicType doing_unsafe_access_bt = T_BYTE; >> +? assert((sizeof(bool) * CHAR_BIT) == 8, "not implemented"); >> >> Best regards, >> >> Jamsheed >> >> On 01/06/19 12:56 PM, Jamsheed wrote: >>> >>> Hi Dan, >>> >>> i understand it is incorrect to assume bool(cpp compiler) >>> implementation above byte level. >>> >>> in that case i will just put an assert. >>> >>> +? BasicType doing_unsafe_access_bt = T_BYTE; >>> >>> + assert(sizeof(bool) == 1, "not implemented"); >>> >>> Best regards, >>> >>> Jamsheed >>> >>> On 31/05/19 10:34 PM, Jamsheed wrote: >>>>> src/hotspot/share/opto/library_call.cpp >>>>> ??? In src/hotspot/share/runtime/thread.hpp: >>>>> ??? L1090: ? volatile bool???????? _doing_unsafe_access; >>>>> >>>>> ??? L4220: ? store_to_memory(control(), doing_unsafe_access_addr, >>>>> intcon(1), T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); >>>>> ??? L4230: ? store_to_memory(control(), doing_unsafe_access_addr, >>>>> intcon(0), T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); >>>>> ??????? Is T_BYTE a safe assumption (size wise) for writing to a >>>>> C++ bool? >>>> >>>> Thanks for pointing this. >>>> >>>> hope [1] will work ? >>> [1] >>> +? BasicType doing_unsafe_access_bt = T_BYTE; >>> +? switch(sizeof(bool)) { >>> +??? case 1: doing_unsafe_access_bt = T_BYTE;? break; >>> +??? case 2: doing_unsafe_access_bt = T_SHORT; break; >>> +??? case 4: doing_unsafe_access_bt = T_INT;?? break; >>> +??? case 8: doing_unsafe_access_bt = T_LONG;? break; >>> +??? default: ShouldNotReachHere(); >>> +? } >>> >>> ?? // update volatile field >>> -? store_to_memory(control(), doing_unsafe_access_addr, intcon(1), >>> T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); >>> +? store_to_memory(control(), doing_unsafe_access_addr, intcon(1), >>> doing_unsafe_access_bt, Compile::AliasIdxRaw, MemNode::unordered); >>> >>> ?? // Call it.? Note that the length argument is not scaled. >>> ?? make_runtime_call(RC_LEAF|RC_NO_FP, >>> ???????????????????? OptoRuntime::fast_arraycopy_Type(), >>> ???????????????????? StubRoutines::unsafe_arraycopy(), >>> ???????????????????? "unsafe_arraycopy", >>> ???????????????????? TypeRawPtr::BOTTOM, >>> ???????????????????? src, dst, size XTOP); >>> >>> -? store_to_memory(control(), doing_unsafe_access_addr, intcon(0), >>> T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); >>> +? store_to_memory(control(), doing_unsafe_access_addr, intcon(0), >>> doing_unsafe_access_bt, Compile::AliasIdxRaw, MemNode::unordered); > From abdoulk.keita at gmail.com Mon Jun 3 19:14:05 2019 From: abdoulk.keita at gmail.com (keita abdoul-kader) Date: Mon, 3 Jun 2019 12:14:05 -0700 Subject: Questions around codeheaps, codeblobs and code locality Message-ID: Hello, I have been looking into the code cache layout and ways to reduce the high amount of iTLB we are observing on some of our workloads. It seems that after the works on segmented codeHeaps, the plan was to add support for non contiguous codeBlobs as the next step to improve code locality in the code cache. is the work on non contiguous codeBlobs still active ? Also, does the hotspot has support for any form of code compaction ? Compacting the code heap is mentioned in one of the comment in relocInfo.hpp, but browsing the source code it seems that once the codeBlobs is filled with the content of a codeBuffer, they are never moved in a way to reduce codeheap fragmentation. In general, is there an umbrella project or a set of open task around improving code locality ? Please note that most of my observation driving this come from spark-sql workloads. Since spark-sql generates dynamically generate a lots of code, i might simply be observing a pathological case. Thanks From hohensee at amazon.com Mon Jun 3 19:26:38 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 3 Jun 2019 19:26:38 +0000 Subject: [8u] 8202353: os::readdir should use readdir instead of readdir_r In-Reply-To: References: Message-ID: Looks good. Paul ?On 5/31/19, 10:18 AM, "hotspot-dev on behalf of Andrew John Hughes" wrote: Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8202353/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8202353 As came up again this week [0], 8u doesn't currently build with newer versions of glibc >= 2.24 that deprecate readdir_r. There have been a number of attempts to fix this upstream, some of which I've attempted to backport to 8u in the past. 8202353 seems to be the most complete, so I've backported this and propose it for review. Differences from the 11u version: * The AIX implementation of readdir_r is slightly different in 8u, as 8u lacks JDK-8079125 ([aix] clean up Linux-specific code remnants in AIX coding). As the function is being removed, the difference seems negligible. * Changes to os_perf_aix.cpp, os_perf_linux.cpp, os_perf_solaris.cpp, jfrRepository.cpp & ProblemList.txt are missing, because 8u currently lacks JFR. These will need to be applied to the JFR tree separately. * The readdir_r in Linux is different in 8u because it still actually uses readdir_r, hence causing our problem. 11u already had JDK-8179887 (Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated) before JDK-8202353 was applied. * The readdir_r in Solaris is slightly more convoluted in 8u because it doesn't contain JDK-8181787 (Remove Solaris SPARC GCC code). Again, this is immaterial as the function is removed. * There are some slight formatting differences in src/hotspot/os/windows/os_windows.cpp. The 8u style is retained. * The 8u version contains changes to src/share/vm/runtime/arguments.cpp which are similar to those applied in the various perfMemory files. This was necessary because 8u's arguments.cpp still uses readdir_r, while these functions were removed in 11u as part of the removal of support for endorsed JARs (JDK-8183238). i've built the patched version on GNU/Linux and also checked the source for remaining references to the removed readdir_buf_size. Testing on other affected platforms (AIX, Windows, Solaris, *BSD) would be appreciated. [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009477.html -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From dean.long at oracle.com Mon Jun 3 21:55:04 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 3 Jun 2019 14:55:04 -0700 Subject: Questions around codeheaps, codeblobs and code locality In-Reply-To: References: Message-ID: <4057ea87-f2dd-34c5-9d15-c2183c9874b2@oracle.com> I wonder if something like -XX:+UseTransparentHugePages would help with the iTLB issue. dl On 6/3/19 12:14 PM, keita abdoul-kader wrote: > Hello, > > I have been looking into the code cache layout and ways to reduce the high > amount of iTLB we are observing on some of our workloads. It seems that > after the works on segmented codeHeaps, the plan was to add support for non > contiguous codeBlobs as the next step to improve code locality in the code > cache. is the work on non contiguous codeBlobs still active ? > > Also, does the hotspot has support for any form of code compaction ? > Compacting the code heap is mentioned in one of the comment in > relocInfo.hpp, but browsing the source code it seems that once the > codeBlobs is filled with the content of a codeBuffer, they are never moved > in a way to reduce codeheap fragmentation. > > In general, is there an umbrella project or a set of open task around > improving code locality ? Please note that most of my observation driving > this come from spark-sql workloads. Since spark-sql generates dynamically > generate a lots of code, i might simply be observing a pathological case. > > Thanks From kim.barrett at oracle.com Mon Jun 3 23:24:35 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 3 Jun 2019 19:24:35 -0400 Subject: RFR: 8213415: BitMap::word_index_round_up overflow problems In-Reply-To: <33426790910a9238999256062c81ec708c93d638.camel@oracle.com> References: <24C2BDC9-AC35-4804-95C8-1B59747C1494@oracle.com> <33426790910a9238999256062c81ec708c93d638.camel@oracle.com> Message-ID: > On Jun 3, 2019, at 4:16 AM, Thomas Schatzl wrote: > > Hi, > > On Tue, 2019-05-28 at 14:10 -0400, Kim Barrett wrote: >> Please review this change to BitMap index alignment to check for >> overflows (in debug builds). Also made a few related API cleanups. >> >> Constructing a BitMap now ensures the size is such that rounding it >> up to a word boundary won't overflow. This is the new >> max_size_in_bits() value. This lets us add some asserts and otherwise >> tidy things up in some places by making use of that information. >> >> This engendered some changes to ParallelGC's ParMarkBitMap. It no >> longer uses the obsolete BitMap::word_align_up, instead having its >> own internal helper for aligning range ends that knows about >> invariants in ParMarkBitMap. >> >> Removed the following static functions from BitMap: word_align_up, >> word_align_down, and is_word_aligned. word_align_up is no longer >> used, after the ParMarkBitMap changes. The others were only used in >> a small number of places in tests and asserts, and didn't seem worth >> keeping instead of just using align.hpp stuff with BitsPerWord >> alignment value. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8213415 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8213415/open.00/ >> >> Testing: >> mach5 tier1-3 > > Minor comment: > > - bitmap.hpp: > > 52 // the bitmap. BitsPerWord bits per element. > > The second part is not a sentence. Maybe join these with a "with" > instead of the full stop? Or "An element has BitsPerWord bits?. Fixed. > Not sure this fact actually needs mention though. Maybe it would be > useful to do a static assert like the following somewhere: > > STATIC_ASSERT(sizeof(bm_word_t) * BitsPerByte == BitsPerWord); > > To actually enforce this and not only talk about it in some comment? There are a bunch of places that assume this, currently using BitsPerWord directly. I considered adding a BitMap constant for this value, but decided to just document it. I've added an assertion in the BitMap class (so no longer _just_ a comment), but that won't help find places that are broken if the assertion ever fails. > It's up to you whether you pick up these suggestions. > > Looks good. Thanks. > > Thanks, > Thomas From abdoulk.keita at gmail.com Tue Jun 4 00:30:47 2019 From: abdoulk.keita at gmail.com (keita abdoul-kader) Date: Mon, 3 Jun 2019 17:30:47 -0700 Subject: Questions around codeheaps, codeblobs and code locality In-Reply-To: <4057ea87-f2dd-34c5-9d15-c2183c9874b2@oracle.com> References: <4057ea87-f2dd-34c5-9d15-c2183c9874b2@oracle.com> Message-ID: Hello dean, We did try -XX:+UseTransparentHugePages in production and saw no performance improvements (although i check if there was a reduction in iTLB misses). Also i should probably note that we are still using java 8 and as such still using the unify/non segmented code cache. On Mon, Jun 3, 2019 at 2:55 PM wrote: > I wonder if something like -XX:+UseTransparentHugePages would help with > the iTLB issue. > > dl > > On 6/3/19 12:14 PM, keita abdoul-kader wrote: > > Hello, > > > > I have been looking into the code cache layout and ways to reduce the > high > > amount of iTLB we are observing on some of our workloads. It seems that > > after the works on segmented codeHeaps, the plan was to add support for > non > > contiguous codeBlobs as the next step to improve code locality in the > code > > cache. is the work on non contiguous codeBlobs still active ? > > > > Also, does the hotspot has support for any form of code compaction ? > > Compacting the code heap is mentioned in one of the comment in > > relocInfo.hpp, but browsing the source code it seems that once the > > codeBlobs is filled with the content of a codeBuffer, they are never > moved > > in a way to reduce codeheap fragmentation. > > > > In general, is there an umbrella project or a set of open task around > > improving code locality ? Please note that most of my observation > driving > > this come from spark-sql workloads. Since spark-sql generates dynamically > > generate a lots of code, i might simply be observing a pathological case. > > > > Thanks > > From vladimir.kozlov at oracle.com Tue Jun 4 01:06:18 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 3 Jun 2019 18:06:18 -0700 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <405296a4-a921-2f44-b823-53160ed2d1a4@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <742307c4-9dd0-4c5f-514b-e53fa3ac51a8@oracle.com> <7ce71707-967b-4748-f7e0-12c1743e939a@oracle.com> <5ddacc0b-a534-d751-73fa-3e2af7a70065@oracle.com> <8b4629d4-6b3a-0e29-82f8-760719c5daeb@redhat.com> <0ea5f1b5-1245-551b-90fd-7a63e8f15e92@oracle.com> <4354a0db-8f50-4eb0-af63-cadd5dde7ae5@oracle.com> <95af6958-6512-d894-2076-74f1b68e3dbe@oracle.com> <5422bc1c-4640-b3c8-bf26-b91a6df34f1e@oracle.com> <2848933c-e6bc-be44-7970-436ac00f0479@oracle.com> <188da7c3-7384-220a-9290-cdd4bad25fce@oracle.com> <2ddfbcbd-4dff-4b86-ba0b-d5920b80e7ec@oracle.com> <59f2ec26-9945-3547-ada9-69b84928edbc@oracle.com> <0486af70-8345-f631-3a49-2d7bb5d0081b@oracle.com> <405296a4-a921-2f44-b823-53160ed2d1a4@oracle.com> Message-ID: Looks good. Thanks, Vladimir On 6/3/19 11:42 AM, Jamsheed wrote: > Hi Vladimir, Dan, > > added two cases in? Assembler::locate_operand as movdqa was unrecognized. update webrev in place > > +??? case 0x6F: // movdq > +??? case 0x7F: // movdq > > full diff : http://cr.openjdk.java.net/~jcm/8191278/webrev.06/ > > http://cr.openjdk.java.net/~jcm/8191278/webrev.05/ + (incremental patch) > http://cr.openjdk.java.net/~jcm/8191278/webrev.06_02/ > > Best regards, > > Jamsheed > > On 31/05/19 10:34 PM, Jamsheed wrote: >> Hi Vladimir, Dan, >> >> On 15/05/19 2:24 AM, Vladimir Kozlov wrote: >>> Sorry, I missed this. Please "ping" if you do not get responses. >>> >>> It become even more complicated :( but I understand why you are doing this way. You did great job. >>> >>> I am thinking about separating the fix for arraycopy stubs fix and adding graceful exit for Unsafe_CopyMemory and >>> Unsafe_CopySwapMemory. >> ? It would be really good if it can be done in runtime, i tried this approach as it seemed far more easier. >> >> ? aarch64 port cpp implementation actually crashes for Unsafe_CopyMemory. >> >>> >>> My main concern is new swap code complicates reliable arraycopy code for very corner case. And you implemented it >>> only for x64 anyway. >> >> copySwap cpp code may work for all cases (depends on compiler again) , so i am ok with removing the changes. >> >> but today when i was testing the removed code[1], found another issue. some x86 instructions generated by cpp copyswap >> code? is not recognized by our assembler and it crashes in signalHandler Assembler::locate_next_instruction(pc). i >> will investigate and file a bug. >> >> Best regards, >> >> Jamsheed >> >> [1] >> >> full diff : http://cr.openjdk.java.net/~jcm/8191278/webrev.06/ >> >> http://cr.openjdk.java.net/~jcm/8191278/webrev.05/ + (incremental patch) >> http://cr.openjdk.java.net/~jcm/8191278/webrev.06_02/ >> >>> >>> I would like to hear what Runtime group think. >>> >>> On 4/30/19 8:17 PM, Jamsheed wrote: >>>> Hi Vladimir, >>>> >>>> Thank you for all the feedback. >>>> >>>> please find the revised webrev. >>>> >>>> http://cr.openjdk.java.net/~jcm/8191278/webrev.05/ >>>> >>>> what changed >>>> >>>> 1) Unsafe Copy Memory regions, error exits are captured using UnsafeCopyMemoryMark, UnsafeCopyMemory. >>> >>> This is good. >>> >>>> >>>> 2) all Unsafe copy (intrinsic or native) ,uses array copy stub. >>> >>> Right, otherwise we would have to duplicate logic in Copy:: platform specific C++ methods. But may be it is fine to >>> do in C++ in this case. Or not do that at all as other platforms. >>> >>>> >>>> 3) Unsafe copyswap x64 implementation extends arraycopy stub and used as reliable exit(fast exit too)*. it is not >>>> implemented for other platforms. >>> >>> As I said I have concern about this. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> *copySwap was tested using copySwap test in jdk dir(with different buffer sizes) >>>> >>>> newly added test tested on linux(aarch64,arm32,x86(32/64)) and platforms in mach5. + mach(1-5) >>>> >>>> ppc test is not done. >>>> >>>> Best regards, >>>> >>>> Jamsheed >>>> >>>> >>>> On 12/04/19 9:14 PM, Vladimir Kozlov wrote: >>>>> Hi Jamsheed >>>>> >>>>> I think new methods and the table don't need to be part of StubRoutines class. Your new class is visible in all >>>>> places too. You can move methods and table into new class. Then you don't need long names and new code will be in >>>>> one place. >>>>> >>>>> Vladimir >>>>> >>>>> On 4/11/19 11:00 PM, Jamsheed wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> On 12/04/19 12:20 AM, Vladimir Kozlov wrote: >>>>>>> On 4/11/19 10:25 AM, Jamsheed wrote: >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> the runtime calls uses indirect call, and it is not that straight forward to compare dst i guess. >>>>>>> >>>>>>> Okay. Yes, we may load dest into register since it is considered far call (outside CodeCache). >>>>>>> But at least you can find nmethod. So we can do nm->has_unsafe_access() check. >>>>>>> >>>>>>>> >>>>>>>> will use doing_unsafe_access and error table as you suggested, doing_unsafe_access for intrinsic call doesn't >>>>>>>> require volatile semantics in c2 i believe. >>>>>>> >>>>>>> Yes, we don't need fragile frame walking if we use doing_unsafe_access. >>>>>>> >>>>>>> There is MemBarCPUOrder already in inline_unsafe_copyMemory() which will prevent store instruction moves in >>>>>>> generated code. But it does not prevent CPU (Aarch64?) to schedule store in different place. >>>>>>> >>>>>>> On other hand we need to read it in Signal handle. I would assume all stores should be flushed when we hit SEGV. >>>>>> yes >>>>>>> >>>>>>> I thought about avoiding your error table. But you really need continuation PC for graceful return. >>>>>>> I was thinking to have a new separate stub to restore registers and pop frame. But return code in stubs varies >>>>>>> unfortunately. So we need a table. >>>>>>> >>>>>>> One complain about table is its name too long. And it should be unsafe_copymemory to hint intrinsic. Can it be >>>>>>> unsafe_copymemory_error and UnsafeCopyMemoryError class. >>>>>>> StubRoutines:: is_unsafe_copymemory() and next_pc_for_unsafe_copymemory_error() >>>>>> yes >>>>>>> >>>>>>> I did not get why you providing next PC only for 64 bit VM. >>>>>> >>>>>> next_pc is calculated for all case(both 32 bit and 64 bit). this should work for c2-intrisics at-least except for >>>>>> arm. >>>>>> >>>>>> fast exit is implemented only for x64, as of now. >>>>>> >>>>>>> >>>>>>>> >>>>>>>> all code whose behavior is unpredictable will be removed. like arm int/c1, non intrinsic c2 (And other platforms). >>>>>>> >>>>>>> Okay. >>>>>> >>>>>> so i am planning to remove graceful exit for all unpredictable cases. so old behavior will be seen if there is an >>>>>> exit at startup(SIGBUS crash). >>>>>> >>>>>> and steady state use will be mostly c2 intrinsic and will have graceful exit. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Jamsheed >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Jamsheed >>>>>>>> >>>>>>>> On 11/04/19 5:17 AM, Jamsheed wrote: >>>>>>>>> Hi Vladimir, >>>>>>>>> >>>>>>>>> On 10/04/19 10:03 PM, Vladimir Kozlov wrote: >>>>>>>>>> Okay, I see what you did. But it seems incomplete. You did not set continue_pc for some platforms. Why? >>>>>>>>> for some platform i don't have testing setup, others are not very much used in servers(32 bit case). >>>>>>>>>> >>>>>>>>>> Also this will trigger the code if we hit segv for normal arraycopy. You may want to lookup caller frame to >>>>>>>>>> get address from call instruction and compare it with _unsafe_arraycopy: >>>>>>>>>> >>>>>>>>>> if (StubCodeDesc::desc_for(pc)) { >>>>>>>>>> ? frame fr = os::fetch_frame_from_context(uc); >>>>>>>>>> ? address ret_pc = fr.sender_pc(); >>>>>>>>>> ? CodeBlob* cb = CodeCache::find_blob_unsafe(ret_pc); >>>>>>>>>> ? CompiledMethod* nm = (cb != NULL) ? cb->as_compiled_method_or_null() : NULL; >>>>>>>>>> ? if (nm != NULL && NativeCall::is_call_before(ret_pc)) { >>>>>>>>>> ??? address dest = nativeCall_before(ret_pc)->destination(); >>>>>>>>>> ??? if (dest == StubRoutines::_unsafe_arraycopy) { >>>>>>>>>> >>>>>>>>>> But you need to verify if it works. >>>>>>>>> >>>>>>>>> this should work i guess. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Jamsheed >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 4/9/19 8:08 PM, Jamsheed wrote: >>>>>>>>>>> Hi Vladimir, >>>>>>>>>>> >>>>>>>>>>> Thank you for looking at this. >>>>>>>>>>> >>>>>>>>>>> On 10/04/19 4:01 AM, Vladimir Kozlov wrote: >>>>>>>>>>>> Hi Jamsheed, >>>>>>>>>>>> >>>>>>>>>>>> Instead of finding PC in stubs we should use something similar to GuardUnsafeAccess to set thread's >>>>>>>>>>>> doing_unsafe_access flag when we call copy stub for unsafe memory as you suggested first (in bug report). >>>>>>>>>>>> >>>>>>>>>>>> Interpreter set the flag for Unsafe.CopyMemory0() and Unsafe.copySwapMemory0(). C2 has intrinsic only for >>>>>>>>>>>> CopyMemory0(): >>>>>>>>>>>> >>>>>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/6ad0281a654e/src/hotspot/share/opto/library_call.cpp#l4189 >>>>>>>>>>>> >>>>>>>>>>>> It only use unsafe_arraycopy stab: >>>>>>>>>>>> >>>>>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/6ad0281a654e/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#l2434 >>>>>>>>>>>> >>>>>>>>>>>> Setting on it's entry and cleaning on exit Thread::_doing_unsafe_access field should be enough. Right? >>>>>>>>>>>> >>>>>>>>>>>> Or I am missing something? >>>>>>>>>>> >>>>>>>>>>> initially thought of implementing it that way[1], but as it is having both store and volatile semantics went >>>>>>>>>>> with this zero overhead solution. >>>>>>>>>>> >>>>>>>>>>> also, that doesn't provide me? continuation pc, which is required for fast exit for bulkaccess or even for >>>>>>>>>>> graceful exit in platform like arm. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> An other thing which bothering me is Harold's comment: >>>>>>>>>>>> >>>>>>>>>>>> "Unfortunately, "CompiledMethod* nm" gets set to NULL and so handle_unsafe_access() is not executed." >>>>>>>>>>>> >>>>>>>>>>>> Where/why nm is NULLed? >>>>>>>>>>> as we are in BufferBlob/RuntimeBlob(stub frame). >>>>>>>>>>>> >>>>>>>>>>>> Actually I think the whole code for "// BugId 4454115" is questionable since it replaces any crash (most >>>>>>>>>>>> likely not related to unsafe access) in compiled method which has at least one unsafe access with exception. >>>>>>>>>>>> May be we should use PcDesc to record unsafe instructions and compare with SEGV PC. But it is separate RFE. >>>>>>>>>>>> For this one we need to fix only Unsafe.CopyMemory0() C2 inrinsic. >>>>>>>>>>> >>>>>>>>>>> Right, Ok. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> >>>>>>>>>>> Jamsheed >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>> [1]http://cr.openjdk.java.net/~jcm/8191278/webrev.00/src/hotspot/share/opto/library_call.cpp.udiff.html >>>>>>>>>>>> On 4/8/19 4:21 AM, Tobias Hartmann wrote: >>>>>>>>>>>>> Hi Jamsheed, >>>>>>>>>>>>> >>>>>>>>>>>>> On 05.04.19 15:11, Jamsheed wrote: >>>>>>>>>>>>>> On 04/04/19 7:23 PM, Andrew Haley wrote: >>>>>>>>>>>>>>>> this looks reasonable to me although the code is getting quite complicated to handle this edge case. >>>>>>>>>>>>>>> Yeah, it really is. Can't we just assume that *any* fault in these stubs is >>>>>>>>>>>>>>> caused via Unsafe, and get rid of bool unsafe_copy_code_range? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for the feedback Tobias, Andrew, removed unsafe_copy_code_range. >>>>>>>>>>>>>> >>>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~jcm/8191278/webrev.04/ >>>>>>>>>>>>> >>>>>>>>>>>>> I think what Andrew meant is basically to go with webrev.01: >>>>>>>>>>>>> http://cr.openjdk.java.net/~jcm/8191278/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> Right? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Tobias >>>>>>>>>>>>> From vladimir.kozlov at oracle.com Tue Jun 4 01:18:15 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 3 Jun 2019 18:18:15 -0700 Subject: deoptimization.cpp Events::log / Events::log_deopt_message - was : RE: RFR: 8224221: add memprotect calls to event log In-Reply-To: References: Message-ID: log_deopt_message() is used for crashes to list these events in hs_err file: https://bugs.openjdk.java.net/browse/JDK-7141200 Vladimir On 5/23/19 4:16 AM, Baesken, Matthias wrote: > Hello, could please someone comment on the Events::log / Events::log_deopt_message calls in deoptimization.cpp , should they better all > Go to the depot log ( Events::log_deopt_message ) ? > > Best regards, Matthias > >>> >>> Btw when looking into the other already present Events::log* calls I wondered about this : >>> In deoptimization.cpp , there are 3 calls to Events:log, like >>> >>> Events::log(thread, "DEOPT UNPACKING pc=" INTPTR_FORMAT " sp=" >> INTPTR_FORMAT " mode %d", >>> p2i(stub_frame.pc()), p2i(stub_frame.sp()), exec_mode); >>> >>> But just one Events::log_deopt_message >>> >>> Events::log_deopt_message(thread, "Uncommon trap: reason=%s >> action=%s pc=" INTPTR_FORMAT " method=%s @ %d %s", >>> trap_reason_name(reason), trap_action_name(action), >> p2i(fr.pc()), >>> trap_method->name_and_sig_as_C_string(), trap_bci, nm- >>> compiler_name()); >>> >>> I think all 4 messages should go to the separate deoptimization - log and use Events::log_deopt_message. >>> Or is there a special intentation why some go into the depot-log (Events::log_deopt_message ) and some into the general events log (Events::log) ? >> >> I have no idea sorry. Best to open an issue and/or discuss this with the >> compiler folk. >> > From kim.barrett at oracle.com Tue Jun 4 03:03:30 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 3 Jun 2019 23:03:30 -0400 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com> References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com> <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com> <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com> <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com> Message-ID: <8F37D029-DE22-4CE5-981C-A87CB97C7690@oracle.com> > On Jun 3, 2019, at 4:32 AM, Andrew Haley wrote: > > On 6/3/19 7:58 AM, Nick Gasson wrote: >> >>> If I'm reading the gcc documentation for __sync_add_and_fetch >>> correctly, I think the following (completely untested) should work, >>> and won't cause Andrew to (I think rightly) complain about >>> type-punning reinterpret_casts. >>> >>> Though I wonder if this is a clang bug. (See below.) > > It's arguably a mistake in the GCC documentation, but adding two > pointers is not well defined whereas adding a pointer and an integer > is. Yes, the gcc documentation seems to be a bit botched here. But there is also the semantic description, e.g. for __sync_OP_and_fetch: { *ptr OP= value; return *ptr; } >> Another way round this is to use __atomic_add_fetch instead which both >> Clang and GCC accept: >> >> template >> D add_and_fetch(I add_value, D volatile* dest, atomic_memory_order order) const { >> D res = __atomic_add_fetch(dest, add_value, __ATOMIC_RELEASE); >> FULL_MEM_BARRIER; >> return res; >> } > > I could live with that. The __atomic_xxx operations seem to have the same documentation issues. It's strange that clang would get one set right and the other wrong. But okay, using them seems like a good workaround. And maybe someday the order argument will be used to select the barriers to use. From christoph.langer at sap.com Tue Jun 4 07:49:53 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 4 Jun 2019 07:49:53 +0000 Subject: PING: RFR(s): 8224600: Provide VM.events command In-Reply-To: References: Message-ID: Hi Thomas, I had a look at your patch and it looks good to me. One minor thing: copyright year in diagnosticCommand.cpp. Also, the bug is https://bugs.openjdk.java.net/browse/JDK-8224600, JDK-8224601 is the CSR ?? Best regards Christoph > -----Original Message----- > From: hotspot-dev On Behalf Of > Thomas St?fe > Sent: Montag, 3. Juni 2019 10:20 > To: HotSpot Open Source Developers > Subject: PING: RFR(s): 8224600: Provide VM.events command > > Hi all, > > may I please have a second reviewer for this. It is a rather small addition > to add a new jcmd to print event logs. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224601 > Latest webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/vm.events/webrev.01/webrev > / > > Thank you, Thomas > > On Thu, May 23, 2019 at 9:51 PM Thomas St?fe > wrote: > > > Hi all, > > > > May I please have reviews for the following addition to jcmd. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224600 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8224601 > > webrev: > > > http://cr.openjdk.java.net/~stuefe/webrevs/vm.events/webrev.00/webrev > /index.html > > > > This adds a new command, "VM.events", which can be used to display VM > > event logs. Please see linked CSR for details. > > > > The CSR itself is not yet approved but already in proposed state. > > > > Thanks, Thomas > > From thomas.stuefe at gmail.com Tue Jun 4 08:04:00 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 4 Jun 2019 10:04:00 +0200 Subject: PING: RFR(s): 8224600: Provide VM.events command In-Reply-To: References: Message-ID: Thank you Christoph! I'll give Yumin time for feedback then will push later today or tomorrow. Cheers, Thomas On Tue, Jun 4, 2019 at 9:49 AM Langer, Christoph wrote: > Hi Thomas, > > I had a look at your patch and it looks good to me. > > One minor thing: copyright year in diagnosticCommand.cpp. > > Also, the bug is https://bugs.openjdk.java.net/browse/JDK-8224600, > JDK-8224601 is the CSR ?? > > Best regards > Christoph > > > -----Original Message----- > > From: hotspot-dev On Behalf Of > > Thomas St?fe > > Sent: Montag, 3. Juni 2019 10:20 > > To: HotSpot Open Source Developers > > Subject: PING: RFR(s): 8224600: Provide VM.events command > > > > Hi all, > > > > may I please have a second reviewer for this. It is a rather small > addition > > to add a new jcmd to print event logs. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224601 > > Latest webrev: > > http://cr.openjdk.java.net/~stuefe/webrevs/vm.events/webrev.01/webrev > > / > > > > Thank you, Thomas > > > > On Thu, May 23, 2019 at 9:51 PM Thomas St?fe > > wrote: > > > > > Hi all, > > > > > > May I please have reviews for the following addition to jcmd. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224600 > > > CSR: https://bugs.openjdk.java.net/browse/JDK-8224601 > > > webrev: > > > > > http://cr.openjdk.java.net/~stuefe/webrevs/vm.events/webrev.00/webrev > > /index.html > > > > > > This adds a new command, "VM.events", which can be used to display VM > > > event logs. Please see linked CSR for details. > > > > > > The CSR itself is not yet approved but already in proposed state. > > > > > > Thanks, Thomas > > > > From matthias.baesken at sap.com Tue Jun 4 08:04:21 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 4 Jun 2019 08:04:21 +0000 Subject: : PING: RFR(s): 8224600: Provide VM.events command Message-ID: Hello, shouldn't you check as well in test/hotspot/jtreg/serviceability/dcmd/vm/EventsTest.java public void run_all(CommandExecutor executor) { ... } for the event log parts "Classes redefined" and "Internal exceptions" ? Otherwise looks good, no new webrev needed . Best regards, Matthias > Date: Mon, 3 Jun 2019 10:19:38 +0200 > From: Thomas St?fe > To: HotSpot Open Source Developers > Subject: PING: RFR(s): 8224600: Provide VM.events command > Message-ID: > _rxPekyw at mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi all, > > may I please have a second reviewer for this. It is a rather small addition > to add a new jcmd to print event logs. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224601 > Latest webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/vm.events/webrev.01/webrev > / > > Thank you, Thomas > > On Thu, May 23, 2019 at 9:51 PM Thomas St?fe > wrote: > > > Hi all, > > > > May I please have reviews for the following addition to jcmd. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224600 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8224601 > > webrev: > > > http://cr.openjdk.java.net/~stuefe/webrevs/vm.events/webrev.00/webrev > /index.html > > > > This adds a new command, "VM.events", which can be used to display VM > > event logs. Please see linked CSR for details. > > > > The CSR itself is not yet approved but already in proposed state. > > > > Thanks, Thomas > > > From thomas.stuefe at gmail.com Tue Jun 4 08:14:59 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 4 Jun 2019 10:14:59 +0200 Subject: : PING: RFR(s): 8224600: Provide VM.events command In-Reply-To: References: Message-ID: Hi Matthias, thanks for the review. See my answer to David: https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-June/038344.html >* > Please note that I only tested the selection feature to work, but I see *>* > little value in testing any permutation of the "log" option. Would just *>* > make the test larger and more brittle and burn test machine time without *>* > any real value.* Cheers, Thomas On Tue, Jun 4, 2019 at 10:04 AM Baesken, Matthias wrote: > > Hello, shouldn't you check as well in > > test/hotspot/jtreg/serviceability/dcmd/vm/EventsTest.java > > public void run_all(CommandExecutor executor) { > ... > } > > for the event log parts > > "Classes redefined" > > and > > "Internal exceptions" ? > > > Otherwise looks good, no new webrev needed . > > > Best regards, Matthias > > > > > Date: Mon, 3 Jun 2019 10:19:38 +0200 > > From: Thomas St?fe > > To: HotSpot Open Source Developers > > Subject: PING: RFR(s): 8224600: Provide VM.events command > > Message-ID: > > > _rxPekyw at mail.gmail.com> > > Content-Type: text/plain; charset="UTF-8" > > > > Hi all, > > > > may I please have a second reviewer for this. It is a rather small > addition > > to add a new jcmd to print event logs. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224601 > > Latest webrev: > > http://cr.openjdk.java.net/~stuefe/webrevs/vm.events/webrev.01/webrev > > / > > > > Thank you, Thomas > > > > On Thu, May 23, 2019 at 9:51 PM Thomas St?fe > > wrote: > > > > > Hi all, > > > > > > May I please have reviews for the following addition to jcmd. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224600 > > > CSR: https://bugs.openjdk.java.net/browse/JDK-8224601 > > > webrev: > > > > > http://cr.openjdk.java.net/~stuefe/webrevs/vm.events/webrev.00/webrev > > /index.html > > > > > > This adds a new command, "VM.events", which can be used to display VM > > > event logs. Please see linked CSR for details. > > > > > > The CSR itself is not yet approved but already in proposed state. > > > > > > Thanks, Thomas > > > > > > > From matthias.baesken at sap.com Tue Jun 4 08:27:58 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 4 Jun 2019 08:27:58 +0000 Subject: deoptimization.cpp Events::log / Events::log_deopt_message - was : RE: RFR: 8224221: add memprotect calls to event log Message-ID: Hi Vladimir , sure the log_deopt_message() is used for the event-logging and the events are later shown in the hs_err file . However my question was : in deoptimization.cpp we have ***both*** calls to Events::log and Events::log_deopt_message . // Log a message Events::log(thread, "Uncommon trap: trap_request=" PTR32_FORMAT " fr.pc=" INTPTR_FORMAT " relative=" INTPTR_FORMAT, trap_request, p2i(fr.pc()), fr.pc() - fr.cb()->code_begin()); Events::log(thread, "DEOPT PACKING pc=" INTPTR_FORMAT " sp=" INTPTR_FORMAT, p2i(fr.pc()), p2i(fr.sp())); // Log a message Events::log_deopt_message(thread, "Uncommon trap: reason=%s action=%s pc=" INTPTR_FORMAT " method=%s @ %d %s", trap_reason_name(reason), trap_action_name(action), p2i(fr.pc()), trap_method->name_and_sig_as_C_string(), trap_bci, nm->compiler_name()); I think they all should call Events::log_deopt_message , so that they go into the same event log part that is collecting the de-opt event messages . Deoptimization events (19 events): < the deoptimization part > .. Events (20 events): < the "general" events part > ... Best regards, Matthias > From: Vladimir Kozlov > To: "Baesken, Matthias" , > "'hotspot-dev at openjdk.java.net'" dev at openjdk.java.net>, > "hotspot-compiler-dev at openjdk.java.net" > > Subject: Re: deoptimization.cpp Events::log / > Events::log_deopt_message - was : RE: RFR: 8224221: add > memprotect > calls to event log > Message-ID: > Content-Type: text/plain; charset=utf-8; format=flowed > > log_deopt_message() is used for crashes to list these events in hs_err file: > > https://bugs.openjdk.java.net/browse/JDK-7141200 > > Vladimir > > On 5/23/19 4:16 AM, Baesken, Matthias wrote: > > Hello, could please someone comment on the Events::log / > Events::log_deopt_message calls in deoptimization.cpp , should they > better all > > Go to the deopt log ( Events::log_deopt_message ) ? > > > > Best regards, Matthias From jamsheed.c.m at oracle.com Tue Jun 4 11:31:24 2019 From: jamsheed.c.m at oracle.com (Jamsheed) Date: Tue, 4 Jun 2019 17:01:24 +0530 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <7ce71707-967b-4748-f7e0-12c1743e939a@oracle.com> <5ddacc0b-a534-d751-73fa-3e2af7a70065@oracle.com> <8b4629d4-6b3a-0e29-82f8-760719c5daeb@redhat.com> <0ea5f1b5-1245-551b-90fd-7a63e8f15e92@oracle.com> <4354a0db-8f50-4eb0-af63-cadd5dde7ae5@oracle.com> <95af6958-6512-d894-2076-74f1b68e3dbe@oracle.com> <5422bc1c-4640-b3c8-bf26-b91a6df34f1e@oracle.com> <2848933c-e6bc-be44-7970-436ac00f0479@oracle.com> <188da7c3-7384-220a-9290-cdd4bad25fce@oracle.com> <2ddfbcbd-4dff-4b86-ba0b-d5920b80e7ec@oracle.com> <59f2ec26-9945-3547-ada9-69b84928edbc@oracle.com> <0486af70-8345-f631-3a49-2d7bb5d0081b@oracle.com> <405296a4-a921-2f44-b823-53160ed2d1a4@oracle.com> Message-ID: Hi Vladimir, Thanks for the review. Best regards, Jamsheed On 04/06/19 6:36 AM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 6/3/19 11:42 AM, Jamsheed wrote: >> Hi Vladimir, Dan, >> >> added two cases in? Assembler::locate_operand as movdqa was >> unrecognized. update webrev in place >> >> +??? case 0x6F: // movdq >> +??? case 0x7F: // movdq >> >> full diff : http://cr.openjdk.java.net/~jcm/8191278/webrev.06/ >> >> http://cr.openjdk.java.net/~jcm/8191278/webrev.05/ + (incremental >> patch) http://cr.openjdk.java.net/~jcm/8191278/webrev.06_02/ >> >> Best regards, >> >> Jamsheed >> >> On 31/05/19 10:34 PM, Jamsheed wrote: >>> Hi Vladimir, Dan, >>> >>> On 15/05/19 2:24 AM, Vladimir Kozlov wrote: >>>> Sorry, I missed this. Please "ping" if you do not get responses. >>>> >>>> It become even more complicated :( but I understand why you are >>>> doing this way. You did great job. >>>> >>>> I am thinking about separating the fix for arraycopy stubs fix and >>>> adding graceful exit for Unsafe_CopyMemory and Unsafe_CopySwapMemory. >>> ? It would be really good if it can be done in runtime, i tried this >>> approach as it seemed far more easier. >>> >>> ? aarch64 port cpp implementation actually crashes for >>> Unsafe_CopyMemory. >>> >>>> >>>> My main concern is new swap code complicates reliable arraycopy >>>> code for very corner case. And you implemented it only for x64 anyway. >>> >>> copySwap cpp code may work for all cases (depends on compiler again) >>> , so i am ok with removing the changes. >>> >>> but today when i was testing the removed code[1], found another >>> issue. some x86 instructions generated by cpp copyswap code? is not >>> recognized by our assembler and it crashes in signalHandler >>> Assembler::locate_next_instruction(pc). i will investigate and file >>> a bug. >>> >>> Best regards, >>> >>> Jamsheed >>> >>> [1] >>> >>> full diff : http://cr.openjdk.java.net/~jcm/8191278/webrev.06/ >>> >>> http://cr.openjdk.java.net/~jcm/8191278/webrev.05/ + (incremental >>> patch) http://cr.openjdk.java.net/~jcm/8191278/webrev.06_02/ >>> >>>> >>>> I would like to hear what Runtime group think. >>>> >>>> On 4/30/19 8:17 PM, Jamsheed wrote: >>>>> Hi Vladimir, >>>>> >>>>> Thank you for all the feedback. >>>>> >>>>> please find the revised webrev. >>>>> >>>>> http://cr.openjdk.java.net/~jcm/8191278/webrev.05/ >>>>> >>>>> what changed >>>>> >>>>> 1) Unsafe Copy Memory regions, error exits are captured using >>>>> UnsafeCopyMemoryMark, UnsafeCopyMemory. >>>> >>>> This is good. >>>> >>>>> >>>>> 2) all Unsafe copy (intrinsic or native) ,uses array copy stub. >>>> >>>> Right, otherwise we would have to duplicate logic in Copy:: >>>> platform specific C++ methods. But may be it is fine to do in C++ >>>> in this case. Or not do that at all as other platforms. >>>> >>>>> >>>>> 3) Unsafe copyswap x64 implementation extends arraycopy stub and >>>>> used as reliable exit(fast exit too)*. it is not implemented for >>>>> other platforms. >>>> >>>> As I said I have concern about this. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> *copySwap was tested using copySwap test in jdk dir(with different >>>>> buffer sizes) >>>>> >>>>> newly added test tested on linux(aarch64,arm32,x86(32/64)) and >>>>> platforms in mach5. + mach(1-5) >>>>> >>>>> ppc test is not done. >>>>> >>>>> Best regards, >>>>> >>>>> Jamsheed >>>>> >>>>> >>>>> On 12/04/19 9:14 PM, Vladimir Kozlov wrote: >>>>>> Hi Jamsheed >>>>>> >>>>>> I think new methods and the table don't need to be part of >>>>>> StubRoutines class. Your new class is visible in all places too. >>>>>> You can move methods and table into new class. Then you don't >>>>>> need long names and new code will be in one place. >>>>>> >>>>>> Vladimir >>>>>> >>>>>> On 4/11/19 11:00 PM, Jamsheed wrote: >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> On 12/04/19 12:20 AM, Vladimir Kozlov wrote: >>>>>>>> On 4/11/19 10:25 AM, Jamsheed wrote: >>>>>>>>> Hi Vladimir, >>>>>>>>> >>>>>>>>> the runtime calls uses indirect call, and it is not that >>>>>>>>> straight forward to compare dst i guess. >>>>>>>> >>>>>>>> Okay. Yes, we may load dest into register since it is >>>>>>>> considered far call (outside CodeCache). >>>>>>>> But at least you can find nmethod. So we can do >>>>>>>> nm->has_unsafe_access() check. >>>>>>>> >>>>>>>>> >>>>>>>>> will use doing_unsafe_access and error table as you suggested, >>>>>>>>> doing_unsafe_access for intrinsic call doesn't require >>>>>>>>> volatile semantics in c2 i believe. >>>>>>>> >>>>>>>> Yes, we don't need fragile frame walking if we use >>>>>>>> doing_unsafe_access. >>>>>>>> >>>>>>>> There is MemBarCPUOrder already in inline_unsafe_copyMemory() >>>>>>>> which will prevent store instruction moves in generated code. >>>>>>>> But it does not prevent CPU (Aarch64?) to schedule store in >>>>>>>> different place. >>>>>>>> >>>>>>>> On other hand we need to read it in Signal handle. I would >>>>>>>> assume all stores should be flushed when we hit SEGV. >>>>>>> yes >>>>>>>> >>>>>>>> I thought about avoiding your error table. But you really need >>>>>>>> continuation PC for graceful return. >>>>>>>> I was thinking to have a new separate stub to restore registers >>>>>>>> and pop frame. But return code in stubs varies unfortunately. >>>>>>>> So we need a table. >>>>>>>> >>>>>>>> One complain about table is its name too long. And it should be >>>>>>>> unsafe_copymemory to hint intrinsic. Can it be >>>>>>>> unsafe_copymemory_error and UnsafeCopyMemoryError class. >>>>>>>> StubRoutines:: is_unsafe_copymemory() and >>>>>>>> next_pc_for_unsafe_copymemory_error() >>>>>>> yes >>>>>>>> >>>>>>>> I did not get why you providing next PC only for 64 bit VM. >>>>>>> >>>>>>> next_pc is calculated for all case(both 32 bit and 64 bit). this >>>>>>> should work for c2-intrisics at-least except for arm. >>>>>>> >>>>>>> fast exit is implemented only for x64, as of now. >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> all code whose behavior is unpredictable will be removed. like >>>>>>>>> arm int/c1, non intrinsic c2 (And other platforms). >>>>>>>> >>>>>>>> Okay. >>>>>>> >>>>>>> so i am planning to remove graceful exit for all unpredictable >>>>>>> cases. so old behavior will be seen if there is an exit at >>>>>>> startup(SIGBUS crash). >>>>>>> >>>>>>> and steady state use will be mostly c2 intrinsic and will have >>>>>>> graceful exit. >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Jamsheed >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Jamsheed >>>>>>>>> >>>>>>>>> On 11/04/19 5:17 AM, Jamsheed wrote: >>>>>>>>>> Hi Vladimir, >>>>>>>>>> >>>>>>>>>> On 10/04/19 10:03 PM, Vladimir Kozlov wrote: >>>>>>>>>>> Okay, I see what you did. But it seems incomplete. You did >>>>>>>>>>> not set continue_pc for some platforms. Why? >>>>>>>>>> for some platform i don't have testing setup, others are not >>>>>>>>>> very much used in servers(32 bit case). >>>>>>>>>>> >>>>>>>>>>> Also this will trigger the code if we hit segv for normal >>>>>>>>>>> arraycopy. You may want to lookup caller frame to get >>>>>>>>>>> address from call instruction and compare it with >>>>>>>>>>> _unsafe_arraycopy: >>>>>>>>>>> >>>>>>>>>>> if (StubCodeDesc::desc_for(pc)) { >>>>>>>>>>> ? frame fr = os::fetch_frame_from_context(uc); >>>>>>>>>>> ? address ret_pc = fr.sender_pc(); >>>>>>>>>>> ? CodeBlob* cb = CodeCache::find_blob_unsafe(ret_pc); >>>>>>>>>>> ? CompiledMethod* nm = (cb != NULL) ? >>>>>>>>>>> cb->as_compiled_method_or_null() : NULL; >>>>>>>>>>> ? if (nm != NULL && NativeCall::is_call_before(ret_pc)) { >>>>>>>>>>> ??? address dest = nativeCall_before(ret_pc)->destination(); >>>>>>>>>>> ??? if (dest == StubRoutines::_unsafe_arraycopy) { >>>>>>>>>>> >>>>>>>>>>> But you need to verify if it works. >>>>>>>>>> >>>>>>>>>> this should work i guess. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> >>>>>>>>>> Jamsheed >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> On 4/9/19 8:08 PM, Jamsheed wrote: >>>>>>>>>>>> Hi Vladimir, >>>>>>>>>>>> >>>>>>>>>>>> Thank you for looking at this. >>>>>>>>>>>> >>>>>>>>>>>> On 10/04/19 4:01 AM, Vladimir Kozlov wrote: >>>>>>>>>>>>> Hi Jamsheed, >>>>>>>>>>>>> >>>>>>>>>>>>> Instead of finding PC in stubs we should use something >>>>>>>>>>>>> similar to GuardUnsafeAccess to set thread's >>>>>>>>>>>>> doing_unsafe_access flag when we call copy stub for unsafe >>>>>>>>>>>>> memory as you suggested first (in bug report). >>>>>>>>>>>>> >>>>>>>>>>>>> Interpreter set the flag for Unsafe.CopyMemory0() and >>>>>>>>>>>>> Unsafe.copySwapMemory0(). C2 has intrinsic only for >>>>>>>>>>>>> CopyMemory0(): >>>>>>>>>>>>> >>>>>>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/6ad0281a654e/src/hotspot/share/opto/library_call.cpp#l4189 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> It only use unsafe_arraycopy stab: >>>>>>>>>>>>> >>>>>>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/6ad0281a654e/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#l2434 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Setting on it's entry and cleaning on exit >>>>>>>>>>>>> Thread::_doing_unsafe_access field should be enough. Right? >>>>>>>>>>>>> >>>>>>>>>>>>> Or I am missing something? >>>>>>>>>>>> >>>>>>>>>>>> initially thought of implementing it that way[1], but as it >>>>>>>>>>>> is having both store and volatile semantics went with this >>>>>>>>>>>> zero overhead solution. >>>>>>>>>>>> >>>>>>>>>>>> also, that doesn't provide me? continuation pc, which is >>>>>>>>>>>> required for fast exit for bulkaccess or even for graceful >>>>>>>>>>>> exit in platform like arm. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> An other thing which bothering me is Harold's comment: >>>>>>>>>>>>> >>>>>>>>>>>>> "Unfortunately, "CompiledMethod* nm" gets set to NULL and >>>>>>>>>>>>> so handle_unsafe_access() is not executed." >>>>>>>>>>>>> >>>>>>>>>>>>> Where/why nm is NULLed? >>>>>>>>>>>> as we are in BufferBlob/RuntimeBlob(stub frame). >>>>>>>>>>>>> >>>>>>>>>>>>> Actually I think the whole code for "// BugId 4454115" is >>>>>>>>>>>>> questionable since it replaces any crash (most likely not >>>>>>>>>>>>> related to unsafe access) in compiled method which has at >>>>>>>>>>>>> least one unsafe access with exception. May be we should >>>>>>>>>>>>> use PcDesc to record unsafe instructions and compare with >>>>>>>>>>>>> SEGV PC. But it is separate RFE. For this one we need to >>>>>>>>>>>>> fix only Unsafe.CopyMemory0() C2 inrinsic. >>>>>>>>>>>> >>>>>>>>>>>> Right, Ok. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> >>>>>>>>>>>> Jamsheed >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Vladimir >>>>>>>>>>>>> >>>>>>>>>>>> [1]http://cr.openjdk.java.net/~jcm/8191278/webrev.00/src/hotspot/share/opto/library_call.cpp.udiff.html >>>>>>>>>>>> >>>>>>>>>>>>> On 4/8/19 4:21 AM, Tobias Hartmann wrote: >>>>>>>>>>>>>> Hi Jamsheed, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 05.04.19 15:11, Jamsheed wrote: >>>>>>>>>>>>>>> On 04/04/19 7:23 PM, Andrew Haley wrote: >>>>>>>>>>>>>>>>> this looks reasonable to me although the code is >>>>>>>>>>>>>>>>> getting quite complicated to handle this edge case. >>>>>>>>>>>>>>>> Yeah, it really is. Can't we just assume that *any* >>>>>>>>>>>>>>>> fault in these stubs is >>>>>>>>>>>>>>>> caused via Unsafe, and get rid of bool >>>>>>>>>>>>>>>> unsafe_copy_code_range? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks for the feedback Tobias, Andrew, removed >>>>>>>>>>>>>>> unsafe_copy_code_range. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~jcm/8191278/webrev.04/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think what Andrew meant is basically to go with webrev.01: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~jcm/8191278/webrev.01/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Right? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Tobias >>>>>>>>>>>>>> From matthias.baesken at sap.com Tue Jun 4 12:02:46 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 4 Jun 2019 12:02:46 +0000 Subject: RFR [XS]: 8224958: add os::dll_load calls to event log Message-ID: Hello, please review the following small change . The current event log holds the last n events of various interesting operations. It is printed in the hs_err file and helps to analyze various issues / bugs . I would like to add shared library loading operations (os::dll_load) to the events added by calling Events::log. Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8224958 http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.0/ Best regards, Matthias From thomas.stuefe at gmail.com Tue Jun 4 12:13:57 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 4 Jun 2019 14:13:57 +0200 Subject: RFR [XS]: 8224958: add os::dll_load calls to event log In-Reply-To: References: Message-ID: Hi Matthias, this is useful. Can you please - add the dlerror output to the log (where easily available) - I see an existing issue on some platforms where the return value of dlerror() is copied without null check first. dlerror() may return NULL. Can you please add null checks where needed? Thanks! ..Thomas On Tue, Jun 4, 2019 at 2:03 PM Baesken, Matthias wrote: > Hello, please review the following small change . > > The current event log holds the last n events of various interesting > operations. > It is printed in the hs_err file and helps to analyze various issues / > bugs . > I would like to add shared library loading operations (os::dll_load) to > the events added by calling Events::log. > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8224958 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.0/ > > > Best regards, Matthias > > From matthias.baesken at sap.com Tue Jun 4 12:24:55 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 4 Jun 2019 12:24:55 +0000 Subject: RFR [XS]: 8224958: add os::dll_load calls to event log In-Reply-To: References: Message-ID: Hi Thomas thanks for the input ! * . dlerror() may return NULL Sure I can add this , makes sense to check for NULL ! Looks like there are a few other places of dlerror usage where a NULL check is missing , one example : jdk/src/jdk.crypto.cryptoki/unix/native/libj2pkcs11/p11_md.c 108 systemErrorMessage = dlerror(); 109 exceptionMessage = (char *) malloc(sizeof(char) * (strlen(systemErrorMessage) + strlen(libraryNameStr) + 1)); * add the dlerror output to the log (where easily available) My ?fear? was the messages might get a bit too long and eat up too much space , do you think it is fine ? Best regards, Matthias From: Thomas St?fe Sent: Dienstag, 4. Juni 2019 14:14 To: Baesken, Matthias Cc: hotspot-dev at openjdk.java.net Subject: Re: RFR [XS]: 8224958: add os::dll_load calls to event log Hi Matthias, this is useful. Can you please - add the dlerror output to the log (where easily available) - I see an existing issue on some platforms where the return value of dlerror() is copied without null check first. dlerror() may return NULL. Can you please add null checks where needed? Thanks! ..Thomas On Tue, Jun 4, 2019 at 2:03 PM Baesken, Matthias > wrote: Hello, please review the following small change . The current event log holds the last n events of various interesting operations. It is printed in the hs_err file and helps to analyze various issues / bugs . I would like to add shared library loading operations (os::dll_load) to the events added by calling Events::log. Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8224958 http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.0/ Best regards, Matthias From thomas.stuefe at gmail.com Tue Jun 4 12:36:23 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 4 Jun 2019 14:36:23 +0200 Subject: RFR [XS]: 8224958: add os::dll_load calls to event log In-Reply-To: References: Message-ID: On Tue, Jun 4, 2019 at 2:24 PM Baesken, Matthias wrote: > Hi Thomas thanks for the input ! > > > > - . dlerror() may return NULL > > > > Sure I can add this , makes sense to check for NULL ! > > > > > > Looks like there are a few other places of dlerror usage where a NULL > check is missing , one example : > > > > jdk/src/jdk.crypto.cryptoki/unix/native/libj2pkcs11/p11_md.c > > > > 108 systemErrorMessage = dlerror(); > > 109 exceptionMessage = (char *) malloc(sizeof(char) * > (strlen(systemErrorMessage) + strlen(libraryNameStr) + 1)); > > > > > > > > - add the dlerror output to the log (where easily available) > > > > My ?fear? was the messages might get a bit too long and eat up too much > space , do you think it is fine ? > > > I think they are rather short. They are static strings baked into the libc. You could manually truncate them via %.xxxs, e.g. to 64 chars with %.64s . You also could just print to the log, since it will automatically truncate at 255 or 512 chars (I forgot which). Cheers, Thomas > Best regards, Matthias > > > > > > *From:* Thomas St?fe > *Sent:* Dienstag, 4. Juni 2019 14:14 > *To:* Baesken, Matthias > *Cc:* hotspot-dev at openjdk.java.net > *Subject:* Re: RFR [XS]: 8224958: add os::dll_load calls to event log > > > > Hi Matthias, > > > > this is useful. Can you please > > > > - add the dlerror output to the log (where easily available) > > - I see an existing issue on some platforms where the return value of > dlerror() is copied without null check first. dlerror() may return NULL. > Can you please add null checks where needed? > > > > Thanks! > > > > ..Thomas > > > > On Tue, Jun 4, 2019 at 2:03 PM Baesken, Matthias > wrote: > > Hello, please review the following small change . > > The current event log holds the last n events of various interesting > operations. > It is printed in the hs_err file and helps to analyze various issues / > bugs . > I would like to add shared library loading operations (os::dll_load) to > the events added by calling Events::log. > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8224958 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.0/ > > > Best regards, Matthias > > From thomas.stuefe at gmail.com Tue Jun 4 15:46:49 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 4 Jun 2019 17:46:49 +0200 Subject: RFR(m, tedious): 8224212: stringStream::as_string() is inefficient Message-ID: Hi all, may I have your opinion - and, if you think this is worthwhile patch, your reviews - for the following issue: webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8224212-stringstream-as_string-inefficient/webrev.00/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8224212 This patch exchanges calls to stringStream::as_string() with stringStream::base() in a number of places. stringStream::as_string() creates a temporary copy of the string as resource area, and for many call sites this is unnecessary and we could just as well use the internal buffer directly. I carefully combed thru the many call sites of stringStream::as_string() and only exchanged those which were clearly obvious: the returned resource-area string was processed right away, not returned from a function nore stored, and the associated stringStream was not reset over the lifetime of the returned string. At some points I also removed ResourceMark's where not needed anymore (stringStream does C heap allocation now). Do you think this makes sense? Thanks, Thomas From joe.darcy at oracle.com Tue Jun 4 16:56:46 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 4 Jun 2019 09:56:46 -0700 Subject: RFR [XXS] JDK 13 of JDK-8164819: Make javac's toString() on annotation objects consistent with core reflection Message-ID: <5d79793f-0d10-f55b-1174-d874cafb7a73@oracle.com> Hello, In the course of working on the fix for ??? ??? JDK-8164819: Make javac's toString() on annotation objects consistent with core reflection which updates the core reflection toString output of annotations, one HotSpot test relies on the old format. This RFR is for the needed update to the HotSpot test. The rest of the fix has been out for review on core-libs and compiler-dev: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013427.html https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-June/060592.html The latest webrev ??? http://cr.openjdk.java.net/~darcy/8164819.3/ updates test/hotspot/jtreg/runtime/8007320/ConstMethodTest.java to use the new format: @@ -120,12 +120,12 @@ ???????????? if (m.getName().equals("kitchenSinkFunc")) { ???????????????? Annotation[][] ann = m.getParameterAnnotations(); ???????????????? equal(ann.length, 3); ???????????????? Annotation foo = ann[0][0]; ???????????????? Annotation bar = ann[1][0]; -??????????????? equal(foo.toString(), "@Named(value=\"aName\")"); -??????????????? equal(bar.toString(), "@Named(value=\"bName\")"); +??????????????? equal(foo.toString(), "@Named(\"aName\")"); +??????????????? equal(bar.toString(), "@Named(\"bName\")"); ???????????????? check(foo.equals(foo)); ???????????????? check(bar.equals(bar)); ???????????????? check(! foo.equals(bar)); ???????????????? // method annotations ???????????????? Annotation[] ann2 = m.getAnnotations(); Thanks, -Joe From coleen.phillimore at oracle.com Tue Jun 4 18:30:01 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 4 Jun 2019 14:30:01 -0400 Subject: RFR [XXS] JDK 13 of JDK-8164819: Make javac's toString() on annotation objects consistent with core reflection In-Reply-To: <5d79793f-0d10-f55b-1174-d874cafb7a73@oracle.com> References: <5d79793f-0d10-f55b-1174-d874cafb7a73@oracle.com> Message-ID: <5325fde9-627e-0773-a491-7e6048900b1f@oracle.com> I wrote that test and the change looks good to me. thanks, Coleen On 6/4/19 12:56 PM, Joe Darcy wrote: > Hello, > > In the course of working on the fix for > > ??? ??? JDK-8164819: Make javac's toString() on annotation objects > consistent with core reflection > > which updates the core reflection toString output of annotations, one > HotSpot test relies on the old format. This RFR is for the needed > update to the HotSpot test. The rest of the fix has been out for > review on core-libs and compiler-dev: > > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-June/013427.html > > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-June/060592.html > > > The latest webrev > > ??? http://cr.openjdk.java.net/~darcy/8164819.3/ > > updates test/hotspot/jtreg/runtime/8007320/ConstMethodTest.java to use > the new format: > > @@ -120,12 +120,12 @@ > ???????????? if (m.getName().equals("kitchenSinkFunc")) { > ???????????????? Annotation[][] ann = m.getParameterAnnotations(); > ???????????????? equal(ann.length, 3); > ???????????????? Annotation foo = ann[0][0]; > ???????????????? Annotation bar = ann[1][0]; > -??????????????? equal(foo.toString(), "@Named(value=\"aName\")"); > -??????????????? equal(bar.toString(), "@Named(value=\"bName\")"); > +??????????????? equal(foo.toString(), "@Named(\"aName\")"); > +??????????????? equal(bar.toString(), "@Named(\"bName\")"); > ???????????????? check(foo.equals(foo)); > ???????????????? check(bar.equals(bar)); > ???????????????? check(! foo.equals(bar)); > ???????????????? // method annotations > ???????????????? Annotation[] ann2 = m.getAnnotations(); > > Thanks, > > -Joe > From david.holmes at oracle.com Tue Jun 4 22:56:08 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 5 Jun 2019 08:56:08 +1000 Subject: RFR: 8225217: Backout: JDK-8224814: Remove dead JNIHandleBlock freelist code Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8225217 webrev: http://cr.openjdk.java.net/~dholmes/8225217/webrev/ Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/47d928ba8733 It turns out the freelist code wasn't quite dead but played a role in cleaning up deleted local references, without which we end up with "null" handles being left around. Simplest solution is to backout that change and it will be re-examined for 14. Thanks, David ----- From vladimir.kozlov at oracle.com Tue Jun 4 23:30:36 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 4 Jun 2019 16:30:36 -0700 Subject: RFR: 8225217: Backout: JDK-8224814: Remove dead JNIHandleBlock freelist code In-Reply-To: References: Message-ID: Looks good. Thanks, Vladimir On 6/4/19 3:56 PM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8225217 > webrev: http://cr.openjdk.java.net/~dholmes/8225217/webrev/ > > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/47d928ba8733 > > It turns out the freelist code wasn't quite dead but played a role in cleaning up deleted local references, without > which we end up with "null" handles being left around. > > Simplest solution is to backout that change and it will be re-examined for 14. > > Thanks, > David > ----- From kim.barrett at oracle.com Tue Jun 4 23:44:28 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 4 Jun 2019 19:44:28 -0400 Subject: RFR: 8225217: Backout: JDK-8224814: Remove dead JNIHandleBlock freelist code In-Reply-To: References: Message-ID: <28135F00-42CD-4C96-AE3B-C9DD84E24393@oracle.com> > On Jun 4, 2019, at 6:56 PM, David Holmes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8225217 > webrev: http://cr.openjdk.java.net/~dholmes/8225217/webrev/ > > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/47d928ba8733 > > It turns out the freelist code wasn't quite dead but played a role in cleaning up deleted local references, without which we end up with "null" handles being left around. > > Simplest solution is to backout that change and it will be re-examined for 14. > > Thanks, > David > ----- Looks good. From david.holmes at oracle.com Wed Jun 5 01:24:33 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 5 Jun 2019 11:24:33 +1000 Subject: RFR: 8225217: Backout: JDK-8224814: Remove dead JNIHandleBlock freelist code In-Reply-To: References: Message-ID: <4df27990-f8e8-4c13-68f5-6cbf1c2927d2@oracle.com> Thanks Vladimir! David On 5/06/2019 9:30 am, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 6/4/19 3:56 PM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8225217 >> webrev: http://cr.openjdk.java.net/~dholmes/8225217/webrev/ >> >> Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/47d928ba8733 >> >> It turns out the freelist code wasn't quite dead but played a role in >> cleaning up deleted local references, without which we end up with >> "null" handles being left around. >> >> Simplest solution is to backout that change and it will be re-examined >> for 14. >> >> Thanks, >> David >> ----- From david.holmes at oracle.com Wed Jun 5 01:24:50 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 5 Jun 2019 11:24:50 +1000 Subject: RFR: 8225217: Backout: JDK-8224814: Remove dead JNIHandleBlock freelist code In-Reply-To: <28135F00-42CD-4C96-AE3B-C9DD84E24393@oracle.com> References: <28135F00-42CD-4C96-AE3B-C9DD84E24393@oracle.com> Message-ID: Thanks Kim! David On 5/06/2019 9:44 am, Kim Barrett wrote: >> On Jun 4, 2019, at 6:56 PM, David Holmes wrote: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8225217 >> webrev: http://cr.openjdk.java.net/~dholmes/8225217/webrev/ >> >> Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/47d928ba8733 >> >> It turns out the freelist code wasn't quite dead but played a role in cleaning up deleted local references, without which we end up with "null" handles being left around. >> >> Simplest solution is to backout that change and it will be re-examined for 14. >> >> Thanks, >> David >> ----- > > Looks good. > From stuart.marks at oracle.com Wed Jun 5 02:46:11 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 4 Jun 2019 19:46:11 -0700 Subject: RFR(s): 8205131: remove Runtime trace methods Message-ID: <054319c6-0f4e-757d-6c04-3d244b6d1d84@oracle.com> Hi all, Please review this changeset and CSR request that remove the traceInstructions() and traceMethodCalls() methods from java.lang.Runtime. These methods have been deprecated for removal since Java 9, and they do nothing. I've also removed a couple mentions of these methods from some tests. After this changeset, the only times these methods are mentioned is in javac's symbol tables (for example, make/data/symbols/java.base-9.sym.txt) where they are kept because they are present in earlier releases. They are also mentioned in the file test/hotspot/jtreg/runtime/appcds/ExtraSymbols.symbols.txt However, this file has a comment > 68 -1: # The values in this file are only used for testing the operation of > 63 -1: # adding extra symbols into the CDS archive. None of the values > 70 -1: # are interpreted in any way. So even if they contain names of classes > 70 -1: # that have been renamed or removed, or string literals that have been > 66 -1: # changed or remove from Java source code, it would not affect the > 26 -1: # correctness of the test. so it seems that leaving mention of these methods in this file is harmless. Based on this comment I've decided not to change this file. Nonetheless, I'm including hotspot-dev in this review to make sure this is ok. (I seem to recall a similar issue came up the last time I removed something.) Bug: https://bugs.openjdk.java.net/browse/JDK-8205131 Webrev: http://cr.openjdk.java.net/~smarks/reviews/8205131/webrev.0/ CSR request: https://bugs.openjdk.java.net/browse/JDK-8225330 (if you review, please edit this issue and add yourself to the Reviewed By field) Thanks, s'marks From matthias.baesken at sap.com Wed Jun 5 07:10:45 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 5 Jun 2019 07:10:45 +0000 Subject: RFR [XS]: 8224958: add os::dll_load calls to event log In-Reply-To: References: Message-ID: Hello here is the new webrev , it handles now dlerror returning NULL (in os::dll_load ) : http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.1/ Best regards, Matthias From: Thomas St?fe Sent: Dienstag, 4. Juni 2019 14:36 To: Baesken, Matthias Cc: hotspot-dev at openjdk.java.net Subject: Re: RFR [XS]: 8224958: add os::dll_load calls to event log On Tue, Jun 4, 2019 at 2:24 PM Baesken, Matthias > wrote: Hi Thomas thanks for the input ! * . dlerror() may return NULL Sure I can add this , makes sense to check for NULL ! Looks like there are a few other places of dlerror usage where a NULL check is missing , one example : jdk/src/jdk.crypto.cryptoki/unix/native/libj2pkcs11/p11_md.c 108 systemErrorMessage = dlerror(); 109 exceptionMessage = (char *) malloc(sizeof(char) * (strlen(systemErrorMessage) + strlen(libraryNameStr) + 1)); * add the dlerror output to the log (where easily available) My ?fear? was the messages might get a bit too long and eat up too much space , do you think it is fine ? I think they are rather short. They are static strings baked into the libc. You could manually truncate them via %.xxxs, e.g. to 64 chars with %.64s . You also could just print to the log, since it will automatically truncate at 255 or 512 chars (I forgot which). Cheers, Thomas From thomas.stuefe at gmail.com Wed Jun 5 07:31:07 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 5 Jun 2019 09:31:07 +0200 Subject: RFR [XS]: 8224958: add os::dll_load calls to event log In-Reply-To: References: Message-ID: Hi Matthias, looks good. Minor nit: + if (error_report == NULL) { + error_report = "dlerror returned no error description"; + } + if (error_report && ebuf && ebuflen > 0) { Since you ensure error_report is always set - with a default text, if needed - you do not need to check it for NULL afterwards. If you only fix this, I do not need a new webrev. --- Side note: http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.1/src/hotspot/os/windows/os_windows.cpp.udiff.html You moved lasterror() up to get a "fresh" error value before calling into event logging right? I needed a while to understand that. Okay. This shows that lasterror() is actually not well designed. lasterror() does two things: 1) get the error code with GetLastError and 2) translate that numerical code to a text. It would be better to have a function which only does the text translation, using an error code we give it as parameter. Then we could have given it the errcode we already have. Would be good for a future improvement. Cheers, Thomas On Wed, Jun 5, 2019 at 9:10 AM Baesken, Matthias wrote: > Hello here is the new webrev , it handles now dlerror returning > NULL (in os::dll_load ) : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.1/ > > > > > > Best regards, Matthias > > > > > > *From:* Thomas St?fe > *Sent:* Dienstag, 4. Juni 2019 14:36 > *To:* Baesken, Matthias > *Cc:* hotspot-dev at openjdk.java.net > *Subject:* Re: RFR [XS]: 8224958: add os::dll_load calls to event log > > > > > > > > On Tue, Jun 4, 2019 at 2:24 PM Baesken, Matthias > wrote: > > Hi Thomas thanks for the input ! > > > > - . dlerror() may return NULL > > > > Sure I can add this , makes sense to check for NULL ! > > > > > > Looks like there are a few other places of dlerror usage where a NULL > check is missing , one example : > > > > jdk/src/jdk.crypto.cryptoki/unix/native/libj2pkcs11/p11_md.c > > > > 108 systemErrorMessage = dlerror(); > > 109 exceptionMessage = (char *) malloc(sizeof(char) * > (strlen(systemErrorMessage) + strlen(libraryNameStr) + 1)); > > > > > > > > - add the dlerror output to the log (where easily available) > > > > My ?fear? was the messages might get a bit too long and eat up too much > space , do you think it is fine ? > > > > > > I think they are rather short. They are static strings baked into the > libc. You could manually truncate them via %.xxxs, e.g. to 64 chars with > %.64s . You also could just print to the log, since it will automatically > truncate at 255 or 512 chars (I forgot which). > > > > Cheers, Thomas > > > From matthias.baesken at sap.com Wed Jun 5 09:06:21 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 5 Jun 2019 09:06:21 +0000 Subject: RFR [XS]: 8224958: add os::dll_load calls to event log In-Reply-To: References: Message-ID: Hi Thomas , I removed the error_report _ NULL check http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.2/ * You moved lasterror() up to get a "fresh" error value before calling into event logging right? I needed a while to understand that. Okay. Yes this was my intention . * It would be better to have a function which only does the text translation, using an error code we give it as parameter. * Then we could have given it the errcode we already have. Would be good for a future improvement. There are not so many os::lasterror usages currently . So I am not sure if it is really needed , let?s do it in a separate CR any way ? Best regards, Matthias From: Thomas St?fe Sent: Mittwoch, 5. Juni 2019 09:31 To: Baesken, Matthias Cc: hotspot-dev at openjdk.java.net Subject: Re: RFR [XS]: 8224958: add os::dll_load calls to event log Hi Matthias, looks good. Minor nit: + if (error_report == NULL) { + error_report = "dlerror returned no error description"; + } + if (error_report && ebuf && ebuflen > 0) { Since you ensure error_report is always set - with a default text, if needed - you do not need to check it for NULL afterwards. If you only fix this, I do not need a new webrev. --- Side note: http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.1/src/hotspot/os/windows/os_windows.cpp.udiff.html You moved lasterror() up to get a "fresh" error value before calling into event logging right? I needed a while to understand that. Okay. This shows that lasterror() is actually not well designed. lasterror() does two things: 1) get the error code with GetLastError and 2) translate that numerical code to a text. It would be better to have a function which only does the text translation, using an error code we give it as parameter. Then we could have given it the errcode we already have. Would be good for a future improvement. Cheers, Thomas From thomas.stuefe at gmail.com Wed Jun 5 09:10:55 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 5 Jun 2019 11:10:55 +0200 Subject: RFR [XS]: 8224958: add os::dll_load calls to event log In-Reply-To: References: Message-ID: On Wed, Jun 5, 2019 at 11:06 AM Baesken, Matthias wrote: > Hi Thomas , I removed the error_report _ NULL check > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.2/ > > > > - You moved lasterror() up to get a "fresh" error value before calling > into event logging right? I needed a while to understand that. Okay. > > > > Yes this was my intention . > > > > - It would be better to have a function which only does the text > translation, using an error code we give it as parameter. > - Then we could have given it the errcode we already have. Would be > good for a future improvement. > > > > There are not so many os::lasterror usages currently . So I am not > sure if it is really needed , let?s do it in a separate CR any way ? > > > > > Yeah sure. Maybe we can remove it altogether. Patch looks good to me. Cheers, Thomas > > > Best regards, Matthias > > > > > > *From:* Thomas St?fe > *Sent:* Mittwoch, 5. Juni 2019 09:31 > *To:* Baesken, Matthias > *Cc:* hotspot-dev at openjdk.java.net > *Subject:* Re: RFR [XS]: 8224958: add os::dll_load calls to event log > > > > Hi Matthias, > > looks good. Minor nit: > > > + if (error_report == NULL) { > + error_report = "dlerror returned no error description"; > + } > + if (error_report && ebuf && ebuflen > 0) { > > Since you ensure error_report is always set - with a default text, if > needed - you do not need to check it for NULL afterwards. > > If you only fix this, I do not need a new webrev. > > > --- > > Side note: > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.1/src/hotspot/os/windows/os_windows.cpp.udiff.html > > You moved lasterror() up to get a "fresh" error value before calling into > event logging right? I needed a while to understand that. Okay. > > This shows that lasterror() is actually not well designed. lasterror() > does two things: 1) get the error code with GetLastError and 2) translate > that numerical code to a text. > > It would be better to have a function which only does the text > translation, using an error code we give it as parameter. Then we could > have given it the errcode we already have. Would be good for a future > improvement. > > Cheers, Thomas > > > > > From david.holmes at oracle.com Wed Jun 5 12:50:02 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 5 Jun 2019 22:50:02 +1000 Subject: RFR [XS]: 8224958: add os::dll_load calls to event log In-Reply-To: References: Message-ID: <558c4f7d-8070-3b02-e667-dc5613e87286@oracle.com> On 5/06/2019 7:06 pm, Baesken, Matthias wrote: > Hi Thomas , I removed the error_report _ NULL check > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.2/ You missed one in src/hotspot/os/bsd/os_bsd.cpp + if (error_report == NULL) { + error_report = "dlerror returned no error description"; + } + if (error_report && ebuf && ebuflen > 0) { > > * You moved lasterror() up to get a "fresh" error value before calling into event logging right? I needed a while to understand that. Okay. > > Yes this was my intention . Not sure I'd say "fresh" is the right description. An error has occurred and you want the error message for log statement. Its the same error message you'd get later as no other system call is being made. There's no difference to the how the code currently works, we just want the error text earlier for the log. David ----- > > > * It would be better to have a function which only does the text translation, using an error code we give it as parameter. > * Then we could have given it the errcode we already have. Would be good for a future improvement. > > There are not so many os::lasterror usages currently . So I am not sure if it is really needed , let?s do it in a separate CR any way ? > > > > Best regards, Matthias > > > From: Thomas St?fe > Sent: Mittwoch, 5. Juni 2019 09:31 > To: Baesken, Matthias > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR [XS]: 8224958: add os::dll_load calls to event log > > Hi Matthias, > > looks good. Minor nit: > > + if (error_report == NULL) { > + error_report = "dlerror returned no error description"; > + } > + if (error_report && ebuf && ebuflen > 0) { > > Since you ensure error_report is always set - with a default text, if needed - you do not need to check it for NULL afterwards. > > If you only fix this, I do not need a new webrev. > > --- > > Side note: > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.1/src/hotspot/os/windows/os_windows.cpp.udiff.html > > You moved lasterror() up to get a "fresh" error value before calling into event logging right? I needed a while to understand that. Okay. > > This shows that lasterror() is actually not well designed. lasterror() does two things: 1) get the error code with GetLastError and 2) translate that numerical code to a text. > > It would be better to have a function which only does the text translation, using an error code we give it as parameter. Then we could have given it the errcode we already have. Would be good for a future improvement. > Cheers, Thomas > > From thomas.stuefe at gmail.com Wed Jun 5 12:58:34 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 5 Jun 2019 14:58:34 +0200 Subject: RFR [XS]: 8224958: add os::dll_load calls to event log In-Reply-To: <558c4f7d-8070-3b02-e667-dc5613e87286@oracle.com> References: <558c4f7d-8070-3b02-e667-dc5613e87286@oracle.com> Message-ID: On Wed, Jun 5, 2019 at 2:50 PM David Holmes wrote: > On 5/06/2019 7:06 pm, Baesken, Matthias wrote: > > Hi Thomas , I removed the error_report _ NULL check > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.2/ > > You missed one in src/hotspot/os/bsd/os_bsd.cpp > > + if (error_report == NULL) { > + error_report = "dlerror returned no error description"; > + } > + if (error_report && ebuf && ebuflen > 0) { > > > > > * You moved lasterror() up to get a "fresh" error value before > calling into event logging right? I needed a while to understand that. Okay. > > > > Yes this was my intention . > > Not sure I'd say "fresh" is the right description. An error has occurred > and you want the error message for log statement. Its the same error > message you'd get later as no other system call is being made. There's > no difference to the how the code currently works, we just want the > error text earlier for the log. > not quite :) Matthias prints out the numerical errcode in his call to Events::log, retrieved by GetLastError() some lines above. That has nothing to do with lasterror and errbuf. lasterror() is used to fill errbuf. It too calls GetLastError(), which makes it position dependend. Matthias added a new call into the EventLog system, so he is careful and moves the call to lasterror() up in case the EventLog system calls system APIs and overwrites the error code. ..Thomas > > David > ----- > > > > > > > * It would be better to have a function which only does the text > translation, using an error code we give it as parameter. > > * Then we could have given it the errcode we already have. Would be > good for a future improvement. > > > > There are not so many os::lasterror usages currently . So I am not > sure if it is really needed , let?s do it in a separate CR any way ? > > > > > > > > Best regards, Matthias > > > > > > From: Thomas St?fe > > Sent: Mittwoch, 5. Juni 2019 09:31 > > To: Baesken, Matthias > > Cc: hotspot-dev at openjdk.java.net > > Subject: Re: RFR [XS]: 8224958: add os::dll_load calls to event log > > > > Hi Matthias, > > > > looks good. Minor nit: > > > > + if (error_report == NULL) { > > + error_report = "dlerror returned no error description"; > > + } > > + if (error_report && ebuf && ebuflen > 0) { > > > > Since you ensure error_report is always set - with a default text, if > needed - you do not need to check it for NULL afterwards. > > > > If you only fix this, I do not need a new webrev. > > > > --- > > > > Side note: > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.1/src/hotspot/os/windows/os_windows.cpp.udiff.html > > > > You moved lasterror() up to get a "fresh" error value before calling > into event logging right? I needed a while to understand that. Okay. > > > > This shows that lasterror() is actually not well designed. lasterror() > does two things: 1) get the error code with GetLastError and 2) translate > that numerical code to a text. > > > > It would be better to have a function which only does the text > translation, using an error code we give it as parameter. Then we could > have given it the errcode we already have. Would be good for a future > improvement. > > Cheers, Thomas > > > > > From daniel.daugherty at oracle.com Wed Jun 5 14:43:23 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 5 Jun 2019 10:43:23 -0400 Subject: RFR [XS]: 8224958: add os::dll_load calls to event log In-Reply-To: <558c4f7d-8070-3b02-e667-dc5613e87286@oracle.com> References: <558c4f7d-8070-3b02-e667-dc5613e87286@oracle.com> Message-ID: <5aad9590-b719-b1b8-645a-a4d37ef16f54@oracle.com> On 6/5/19 8:50 AM, David Holmes wrote: > On 5/06/2019 7:06 pm, Baesken, Matthias wrote: >> Hi Thomas , I removed? the error_report _ NULL check >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.2/ > > You missed one in src/hotspot/os/bsd/os_bsd.cpp > > +?? if (error_report == NULL) { > +???? error_report = "dlerror returned no error description"; > +?? } > +?? if (error_report && ebuf && ebuflen > 0) { Ummm... Why check error_report in the second if-statement? Because of the preceding if-statement it can never be NULL. Also the implied booleans need to be fixed: ??? s/ebuf/ebuf != NULL/ I haven't reviewed the whole thing. This just jumped out at me as I was reading the thread... Dan > >> >> ?? *?? You moved lasterror() up to get a "fresh" error value before >> calling into event logging right? I needed a while to understand >> that. Okay. >> >> Yes this was my intention . > > Not sure I'd say "fresh" is the right description. An error has > occurred and you want the error message for log statement. Its the > same error message you'd get later as no other system call is being > made. There's no difference to the how the code currently works, we > just want the error text earlier for the log. > > David > ----- > >> >> >> ?? *?? It would be better to have a function which only does the text >> translation, using an error code we give it as parameter. >> ?? *?? Then we could have given it the errcode we already have. Would >> be good for a future improvement. >> >> There are not so many? os::lasterror?? usages currently .? So I am >> not sure if it is really needed ,?? let?s? do it in a separate CR? >> any way ? >> >> >> >> Best regards, Matthias >> >> >> From: Thomas St?fe >> Sent: Mittwoch, 5. Juni 2019 09:31 >> To: Baesken, Matthias >> Cc: hotspot-dev at openjdk.java.net >> Subject: Re: RFR [XS]: 8224958: add os::dll_load calls to event log >> >> Hi Matthias, >> >> looks good. Minor nit: >> >> +? if (error_report == NULL) { >> +??? error_report = "dlerror returned no error description"; >> +? } >> +? if (error_report && ebuf && ebuflen > 0) { >> >> Since you ensure error_report is always set - with a default text, if >> needed - you do not need to check it for NULL afterwards. >> >> If you only fix this, I do not need a new webrev. >> >> --- >> >> Side note: >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.1/src/hotspot/os/windows/os_windows.cpp.udiff.html >> >> >> You moved lasterror() up to get a "fresh" error value before calling >> into event logging right? I needed a while to understand that. Okay. >> >> This shows that lasterror() is actually not well designed. >> lasterror() does two things: 1) get the error code with GetLastError >> and 2) translate that numerical code to a text. >> >> It would be better to have a function which only does the text >> translation, using an error code we give it as parameter. Then we >> could have given it the errcode we already have. Would be good for a >> future improvement. >> Cheers, Thomas >> >> From matthias.baesken at sap.com Wed Jun 5 15:05:58 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 5 Jun 2019 15:05:58 +0000 Subject: RFR [XS]: 8224958: add os::dll_load calls to event log In-Reply-To: <5aad9590-b719-b1b8-645a-a4d37ef16f54@oracle.com> References: <558c4f7d-8070-3b02-e667-dc5613e87286@oracle.com> <5aad9590-b719-b1b8-645a-a4d37ef16f54@oracle.com> Message-ID: Hello, here is an updated webrev with adjusted NULL checks : http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.3/ Best regards, Matthias > -----Original Message----- > From: Daniel D. Daugherty > Sent: Mittwoch, 5. Juni 2019 16:43 > To: David Holmes ; Baesken, Matthias > ; Thomas St?fe > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR [XS]: 8224958: add os::dll_load calls to event log > > On 6/5/19 8:50 AM, David Holmes wrote: > > On 5/06/2019 7:06 pm, Baesken, Matthias wrote: > >> Hi Thomas , I removed? the error_report _ NULL check > >> > >> http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.2/ > > > > You missed one in src/hotspot/os/bsd/os_bsd.cpp > > > > +?? if (error_report == NULL) { > > +???? error_report = "dlerror returned no error description"; > > +?? } > > +?? if (error_report && ebuf && ebuflen > 0) { > > Ummm... Why check error_report in the second if-statement? > Because of the preceding if-statement it can never be NULL. > > Also the implied booleans need to be fixed: > > ??? s/ebuf/ebuf != NULL/ > > I haven't reviewed the whole thing. This just jumped out at > me as I was reading the thread... > > Dan > > > > > >> > >> ?? *?? You moved lasterror() up to get a "fresh" error value before > >> calling into event logging right? I needed a while to understand > >> that. Okay. > >> > >> Yes this was my intention . > > > > Not sure I'd say "fresh" is the right description. An error has > > occurred and you want the error message for log statement. Its the > > same error message you'd get later as no other system call is being > > made. There's no difference to the how the code currently works, we > > just want the error text earlier for the log. > > > > David > > ----- > > > >> > >> > >> ?? *?? It would be better to have a function which only does the text > >> translation, using an error code we give it as parameter. > >> ?? *?? Then we could have given it the errcode we already have. Would > >> be good for a future improvement. > >> > >> There are not so many? os::lasterror?? usages currently .? So I am > >> not sure if it is really needed ,?? let?s? do it in a separate CR > >> any way ? > >> > >> > >> > >> Best regards, Matthias > >> > >> > >> From: Thomas St?fe > >> Sent: Mittwoch, 5. Juni 2019 09:31 > >> To: Baesken, Matthias > >> Cc: hotspot-dev at openjdk.java.net > >> Subject: Re: RFR [XS]: 8224958: add os::dll_load calls to event log > >> > >> Hi Matthias, > >> > >> looks good. Minor nit: > >> > >> +? if (error_report == NULL) { > >> +??? error_report = "dlerror returned no error description"; > >> +? } > >> +? if (error_report && ebuf && ebuflen > 0) { > >> > >> Since you ensure error_report is always set - with a default text, if > >> needed - you do not need to check it for NULL afterwards. > >> > >> If you only fix this, I do not need a new webrev. > >> > >> --- > >> > >> Side note: > >> > >> > http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.1/src/hotspot/os/ > windows/os_windows.cpp.udiff.html > >> > >> > >> You moved lasterror() up to get a "fresh" error value before calling > >> into event logging right? I needed a while to understand that. Okay. > >> > >> This shows that lasterror() is actually not well designed. > >> lasterror() does two things: 1) get the error code with GetLastError > >> and 2) translate that numerical code to a text. > >> > >> It would be better to have a function which only does the text > >> translation, using an error code we give it as parameter. Then we > >> could have given it the errcode we already have. Would be good for a > >> future improvement. > >> Cheers, Thomas > >> > >> From vladimir.kozlov at oracle.com Wed Jun 5 16:40:17 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 5 Jun 2019 09:40:17 -0700 Subject: deoptimization.cpp Events::log / Events::log_deopt_message - was : RE: RFR: 8224221: add memprotect calls to event log In-Reply-To: References: Message-ID: <50683fa6-2138-ec3f-1ce7-839a3a1f28ac@oracle.com> Got it. Yes, I agree that they should be also in deopt log. Thanks, Vladimir On 6/4/19 1:27 AM, Baesken, Matthias wrote: > Hi Vladimir , sure the log_deopt_message() is used for the event-logging and the events are later shown in the hs_err file . > > However my question was : in deoptimization.cpp we have ***both*** calls to Events::log and Events::log_deopt_message . > > // Log a message > Events::log(thread, "Uncommon trap: trap_request=" PTR32_FORMAT " fr.pc=" INTPTR_FORMAT " relative=" INTPTR_FORMAT, > trap_request, p2i(fr.pc()), fr.pc() - fr.cb()->code_begin()); > > Events::log(thread, "DEOPT PACKING pc=" INTPTR_FORMAT " sp=" INTPTR_FORMAT, p2i(fr.pc()), p2i(fr.sp())); > > > // Log a message > Events::log_deopt_message(thread, "Uncommon trap: reason=%s action=%s pc=" INTPTR_FORMAT " method=%s @ %d %s", > trap_reason_name(reason), trap_action_name(action), p2i(fr.pc()), > trap_method->name_and_sig_as_C_string(), trap_bci, nm->compiler_name()); > > > > > I think they all should call Events::log_deopt_message , so that they go into the same event log part that is collecting the de-opt event messages . > > Deoptimization events (19 events): < the deoptimization part > > .. > > Events (20 events): < the "general" events part > > ... > > > > Best regards, Matthias > > > >> From: Vladimir Kozlov >> To: "Baesken, Matthias" , >> "'hotspot-dev at openjdk.java.net'" > dev at openjdk.java.net>, >> "hotspot-compiler-dev at openjdk.java.net" >> >> Subject: Re: deoptimization.cpp Events::log / >> Events::log_deopt_message - was : RE: RFR: 8224221: add >> memprotect >> calls to event log >> Message-ID: >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> log_deopt_message() is used for crashes to list these events in hs_err file: >> >> https://bugs.openjdk.java.net/browse/JDK-7141200 >> >> Vladimir >> >> On 5/23/19 4:16 AM, Baesken, Matthias wrote: >>> Hello, could please someone comment on the Events::log / >> Events::log_deopt_message calls in deoptimization.cpp , should they >> better all >>> Go to the deopt log ( Events::log_deopt_message ) ? >>> >>> Best regards, Matthias > From martin.doerr at sap.com Wed Jun 5 16:59:12 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 5 Jun 2019 16:59:12 +0000 Subject: RFR [XS]: 8224958: add os::dll_load calls to event log In-Reply-To: References: <558c4f7d-8070-3b02-e667-dc5613e87286@oracle.com> <5aad9590-b719-b1b8-645a-a4d37ef16f54@oracle.com> Message-ID: Hi Matthias, looks good. Best regards, Martin > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Mittwoch, 5. Juni 2019 17:06 > To: daniel.daugherty at oracle.com; David Holmes > ; Thomas St?fe > Cc: hotspot-dev at openjdk.java.net > Subject: RE: RFR [XS]: 8224958: add os::dll_load calls to event log > > Hello, here is an updated webrev with adjusted NULL checks : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.3/ > > Best regards, Matthias > > > > -----Original Message----- > > From: Daniel D. Daugherty > > Sent: Mittwoch, 5. Juni 2019 16:43 > > To: David Holmes ; Baesken, Matthias > > ; Thomas St?fe > > > Cc: hotspot-dev at openjdk.java.net > > Subject: Re: RFR [XS]: 8224958: add os::dll_load calls to event log > > > > On 6/5/19 8:50 AM, David Holmes wrote: > > > On 5/06/2019 7:06 pm, Baesken, Matthias wrote: > > >> Hi Thomas , I removed? the error_report _ NULL check > > >> > > >> http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.2/ > > > > > > You missed one in src/hotspot/os/bsd/os_bsd.cpp > > > > > > +?? if (error_report == NULL) { > > > +???? error_report = "dlerror returned no error description"; > > > +?? } > > > +?? if (error_report && ebuf && ebuflen > 0) { > > > > Ummm... Why check error_report in the second if-statement? > > Because of the preceding if-statement it can never be NULL. > > > > Also the implied booleans need to be fixed: > > > > ??? s/ebuf/ebuf != NULL/ > > > > I haven't reviewed the whole thing. This just jumped out at > > me as I was reading the thread... > > > > Dan > > > > > > > > > >> > > >> ?? *?? You moved lasterror() up to get a "fresh" error value before > > >> calling into event logging right? I needed a while to understand > > >> that. Okay. > > >> > > >> Yes this was my intention . > > > > > > Not sure I'd say "fresh" is the right description. An error has > > > occurred and you want the error message for log statement. Its the > > > same error message you'd get later as no other system call is being > > > made. There's no difference to the how the code currently works, we > > > just want the error text earlier for the log. > > > > > > David > > > ----- > > > > > >> > > >> > > >> ?? *?? It would be better to have a function which only does the text > > >> translation, using an error code we give it as parameter. > > >> ?? *?? Then we could have given it the errcode we already have. Would > > >> be good for a future improvement. > > >> > > >> There are not so many? os::lasterror?? usages currently .? So I am > > >> not sure if it is really needed ,?? let?s? do it in a separate CR > > >> any way ? > > >> > > >> > > >> > > >> Best regards, Matthias > > >> > > >> > > >> From: Thomas St?fe > > >> Sent: Mittwoch, 5. Juni 2019 09:31 > > >> To: Baesken, Matthias > > >> Cc: hotspot-dev at openjdk.java.net > > >> Subject: Re: RFR [XS]: 8224958: add os::dll_load calls to event log > > >> > > >> Hi Matthias, > > >> > > >> looks good. Minor nit: > > >> > > >> +? if (error_report == NULL) { > > >> +??? error_report = "dlerror returned no error description"; > > >> +? } > > >> +? if (error_report && ebuf && ebuflen > 0) { > > >> > > >> Since you ensure error_report is always set - with a default text, if > > >> needed - you do not need to check it for NULL afterwards. > > >> > > >> If you only fix this, I do not need a new webrev. > > >> > > >> --- > > >> > > >> Side note: > > >> > > >> > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.1/src/hotspot/os/ > > windows/os_windows.cpp.udiff.html > > >> > > >> > > >> You moved lasterror() up to get a "fresh" error value before calling > > >> into event logging right? I needed a while to understand that. Okay. > > >> > > >> This shows that lasterror() is actually not well designed. > > >> lasterror() does two things: 1) get the error code with GetLastError > > >> and 2) translate that numerical code to a text. > > >> > > >> It would be better to have a function which only does the text > > >> translation, using an error code we give it as parameter. Then we > > >> could have given it the errcode we already have. Would be good for a > > >> future improvement. > > >> Cheers, Thomas > > >> > > >> From harold.seigel at oracle.com Wed Jun 5 18:55:19 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Wed, 5 Jun 2019 14:55:19 -0400 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <891289e9-e661-bee7-7365-5266e894b721@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <8b4629d4-6b3a-0e29-82f8-760719c5daeb@redhat.com> <0ea5f1b5-1245-551b-90fd-7a63e8f15e92@oracle.com> <4354a0db-8f50-4eb0-af63-cadd5dde7ae5@oracle.com> <95af6958-6512-d894-2076-74f1b68e3dbe@oracle.com> <5422bc1c-4640-b3c8-bf26-b91a6df34f1e@oracle.com> <2848933c-e6bc-be44-7970-436ac00f0479@oracle.com> <188da7c3-7384-220a-9290-cdd4bad25fce@oracle.com> <2ddfbcbd-4dff-4b86-ba0b-d5920b80e7ec@oracle.com> <38eaa1b2-5fde-ca1d-0842-3d7f2b34e483@oracle.com> <611e1925-5384-9c74-064a-da30ba523268@oracle.com> <5e8afd81-37db-3a3f-1589-97a447cdc206@oracle.com> <891289e9-e661-bee7-7365-5266e894b721@oracle.com> Message-ID: Hi Jamsheed, Test hotspot/jtreg/runtime/Unsafe/InternalErrorTest.java fails on Windows with: java.nio.file.FileSystemException: The requested operation cannot be performed on a file with a user-mapped section open. at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92) at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103) at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108) at java.base/sun.nio.fs.WindowsFileSystemProvider.newByteChannel(WindowsFileSystemProvider.java:235) at java.base/java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:478) at java.base/java.nio.file.Files.newOutputStream(Files.java:223) at java.base/java.nio.file.Files.write(Files.java:3488) at InternalErrorTest.main(InternalErrorTest.java:91) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:830) Can you add this to the test? * @requires os.family != "windows" Thanks, Harold On 6/3/2019 2:43 PM, Jamsheed wrote: > Hi Dan, > > Thanks for the review. > > Best regards, > > Jamsheed > > On 01/06/19 6:29 PM, Daniel D. Daugherty wrote: >> That's even better. Thanks. >> >> Dan >> >> >> On 6/1/19 5:11 AM, Jamsheed wrote: >>> >>> Hi Dan, >>> >>> updated webrev in place >>> >>> added only assert >>> >>> +? BasicType doing_unsafe_access_bt = T_BYTE; >>> +? assert((sizeof(bool) * CHAR_BIT) == 8, "not implemented"); >>> >>> Best regards, >>> >>> Jamsheed >>> >>> On 01/06/19 12:56 PM, Jamsheed wrote: >>>> >>>> Hi Dan, >>>> >>>> i understand it is incorrect to assume bool(cpp compiler) >>>> implementation above byte level. >>>> >>>> in that case i will just put an assert. >>>> >>>> +? BasicType doing_unsafe_access_bt = T_BYTE; >>>> >>>> + assert(sizeof(bool) == 1, "not implemented"); >>>> >>>> Best regards, >>>> >>>> Jamsheed >>>> >>>> On 31/05/19 10:34 PM, Jamsheed wrote: >>>>>> src/hotspot/share/opto/library_call.cpp >>>>>> ??? In src/hotspot/share/runtime/thread.hpp: >>>>>> ??? L1090: ? volatile bool???????? _doing_unsafe_access; >>>>>> >>>>>> ??? L4220: ? store_to_memory(control(), doing_unsafe_access_addr, >>>>>> intcon(1), T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); >>>>>> ??? L4230: ? store_to_memory(control(), doing_unsafe_access_addr, >>>>>> intcon(0), T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); >>>>>> ??????? Is T_BYTE a safe assumption (size wise) for writing to a >>>>>> C++ bool? >>>>> >>>>> Thanks for pointing this. >>>>> >>>>> hope [1] will work ? >>>> [1] >>>> +? BasicType doing_unsafe_access_bt = T_BYTE; >>>> +? switch(sizeof(bool)) { >>>> +??? case 1: doing_unsafe_access_bt = T_BYTE;? break; >>>> +??? case 2: doing_unsafe_access_bt = T_SHORT; break; >>>> +??? case 4: doing_unsafe_access_bt = T_INT;?? break; >>>> +??? case 8: doing_unsafe_access_bt = T_LONG;? break; >>>> +??? default: ShouldNotReachHere(); >>>> +? } >>>> >>>> ?? // update volatile field >>>> -? store_to_memory(control(), doing_unsafe_access_addr, intcon(1), >>>> T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); >>>> +? store_to_memory(control(), doing_unsafe_access_addr, intcon(1), >>>> doing_unsafe_access_bt, Compile::AliasIdxRaw, MemNode::unordered); >>>> >>>> ?? // Call it.? Note that the length argument is not scaled. >>>> ?? make_runtime_call(RC_LEAF|RC_NO_FP, >>>> ???????????????????? OptoRuntime::fast_arraycopy_Type(), >>>> ???????????????????? StubRoutines::unsafe_arraycopy(), >>>> ???????????????????? "unsafe_arraycopy", >>>> ???????????????????? TypeRawPtr::BOTTOM, >>>> ???????????????????? src, dst, size XTOP); >>>> >>>> -? store_to_memory(control(), doing_unsafe_access_addr, intcon(0), >>>> T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); >>>> +? store_to_memory(control(), doing_unsafe_access_addr, intcon(0), >>>> doing_unsafe_access_bt, Compile::AliasIdxRaw, MemNode::unordered); >> From david.holmes at oracle.com Wed Jun 5 23:18:33 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 6 Jun 2019 09:18:33 +1000 Subject: RFR [XS]: 8224958: add os::dll_load calls to event log In-Reply-To: References: <558c4f7d-8070-3b02-e667-dc5613e87286@oracle.com> Message-ID: <06927025-ecc0-812d-7512-78ff4bf5a46c@oracle.com> On 5/06/2019 10:58 pm, Thomas St?fe wrote: > On Wed, Jun 5, 2019 at 2:50 PM David Holmes > wrote: > > On 5/06/2019 7:06 pm, Baesken, Matthias wrote: > > Hi Thomas , I removed? the error_report _ NULL check > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.2/ > > You missed one in src/hotspot/os/bsd/os_bsd.cpp > > +? ?if (error_report == NULL) { > +? ? ?error_report = "dlerror returned no error description"; > +? ?} > +? ?if (error_report && ebuf && ebuflen > 0) { > > > > >? ? *? ?You moved lasterror() up to get a "fresh" error value > before calling into event logging right? I needed a while to > understand that. Okay. > > > > Yes this was my intention . > > Not sure I'd say "fresh" is the right description. An error has > occurred > and you want the error message for log statement. Its the same error > message you'd get later as no other system call is being made. There's > no difference to the how the code currently works, we just want the > error text earlier for the log. > > > not quite :) > > Matthias prints out the numerical errcode in his call to Events::log, > retrieved by GetLastError() some lines above. That has nothing to do > with lasterror and errbuf. lasterror() is used to fill errbuf. It too > calls GetLastError(), which makes it position dependend. Matthias added > a new call into the EventLog system, so he is careful and moves the call > to lasterror() up in case the EventLog system calls system APIs and > overwrites the error code. Sometimes my brain continues to see what it thinks it should be seeing. I thought we were logging the text version of the error - why aren't we? The error message has to be captured before the log call as logging may change what is returned by GetLastError. David > > ..Thomas > > > David > ----- > > > > > > >? ? *? ?It would be better to have a function which only does the > text translation, using an error code we give it as parameter. > >? ? *? ?Then we could have given it the errcode we already have. > Would be good for a future improvement. > > > > There are not so many? os::lasterror? ?usages currently .? So I > am not sure if it is really needed ,? ?let?s? do it in a separate > CR? any way ? > > > > > > > > Best regards, Matthias > > > > > > From: Thomas St?fe > > > Sent: Mittwoch, 5. Juni 2019 09:31 > > To: Baesken, Matthias > > > Cc: hotspot-dev at openjdk.java.net > > > Subject: Re: RFR [XS]: 8224958: add os::dll_load calls to event log > > > > Hi Matthias, > > > > looks good. Minor nit: > > > > +? if (error_report == NULL) { > > +? ? error_report = "dlerror returned no error description"; > > +? } > > +? if (error_report && ebuf && ebuflen > 0) { > > > > Since you ensure error_report is always set - with a default > text, if needed - you do not need to check it for NULL afterwards. > > > > If you only fix this, I do not need a new webrev. > > > > --- > > > > Side note: > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.1/src/hotspot/os/windows/os_windows.cpp.udiff.html > > > > You moved lasterror() up to get a "fresh" error value before > calling into event logging right? I needed a while to understand > that. Okay. > > > > This shows that lasterror() is actually not well designed. > lasterror() does two things: 1) get the error code with GetLastError > and 2) translate that numerical code to a text. > > > > It would be better to have a function which only does the text > translation, using an error code we give it as parameter. Then we > could have given it the errcode we already have. Would be good for a > future improvement. > > Cheers, Thomas > > > > > From vladimir.kozlov at oracle.com Wed Jun 5 23:58:00 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 5 Jun 2019 16:58:00 -0700 Subject: [13] RFR(S) 8222371: Use UL for TraceNMethodInstalls code Message-ID: https://cr.openjdk.java.net/~kvn/8222371/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8222371 Replace -XX:+TraceNMethodInstalls with -Xlog:nmethod+install. Thanks, Vladimir From joe.darcy at oracle.com Thu Jun 6 01:31:11 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 05 Jun 2019 18:31:11 -0700 Subject: RFR [XS] of VM portions of JDK-8214546: Start of release updates for JDK 14 Message-ID: <5CF86CDF.9020706@oracle.com> Hello, The time for the fork of JDK 13 approaches and therefore preparations for transitioning jdk/jdk to be JDK 14 are underway. Please review the VM portions of the in-progress start of release updates for 14: http://cr.openjdk.java.net/~darcy/jdk14-fork.2/ Patches for the few VM-related changes are listed as diffs below. Builds and langtools aspects of this change are being reviewed separately on the appropriate mailing lists. Before this change is eventually pushed, I'll regenerate the javac --release symbol information from the latest JDK 13 promoted build and redo a build + test cycle to make sure no additional tests need to be updated, etc. Thanks, -Joe --- old/src/hotspot/share/classfile/classFileParser.cpp 2019-05-17 09:42:36.328000000 -0700 +++ new/src/hotspot/share/classfile/classFileParser.cpp 2019-05-17 09:42:35.944000000 -0700 @@ -125,6 +125,8 @@ #define JAVA_13_VERSION 57 +#define JAVA_14_VERSION 58 + void ClassFileParser::set_class_bad_constant_seen(short bad_constant) { assert((bad_constant == JVM_CONSTANT_Module || bad_constant == JVM_CONSTANT_Package) && _major_version >= JAVA_9_VERSION, --- old/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/classfile/Classfile.java 2019-05-17 09:42:59.588000000 -0700 +++ new/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/classfile/Classfile.java 2019-05-17 09:42:59.188000000 -0700 @@ -49,7 +49,7 @@ private final List codeAttributes; private static final int MAJOR_VERSION_JAVA_MIN = 51; // JDK7 - private static final int MAJOR_VERSION_JAVA_MAX = 57; // JDK13 + private static final int MAJOR_VERSION_JAVA_MAX = 58; // JDK14 private static final int MAGIC = 0xCAFEBABE; /** --- old/test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java 2019-05-17 09:43:02.244000000 -0700 +++ new/test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java 2019-05-17 09:43:01.844000000 -0700 @@ -45,8 +45,6 @@ {"MinRAMFraction", "2"}, {"InitialRAMFraction", "64"}, {"TLABStats", "false"}, - {"ThreadLocalHandshakes", "true"}, - {"AllowJNIEnvProxy", "true"}, {"AllowRedefinitionToAddDeleteMethods", "true"}, // deprecated alias flags (see also aliased_jvm_flags): From igor.ignatyev at oracle.com Thu Jun 6 01:46:03 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 5 Jun 2019 18:46:03 -0700 Subject: RFR(T) : 8209917 : fix TODO in GatherDiagnosticInfoObserver Message-ID: <884B83E5-38CE-46CD-8304-585005660F22@oracle.com> http://cr.openjdk.java.net/~iignatyev//8209917/webrev.00/index.html > 11 lines changed: 0 ins; 3 del; 8 mod; Hi all, could you please review this small and trivial clean up in failure_handler library? webrev: http://cr.openjdk.java.net/~iignatyev//8209917/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8209917 testing: make test TEST=failure-handler; tier1 Thanks, -- Igor From coleen.phillimore at oracle.com Thu Jun 6 01:53:39 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 5 Jun 2019 21:53:39 -0400 Subject: RFR (S) 8224151: Test vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java might hang with release binaries Message-ID: <7060291e-67a2-97d0-c3cc-40df304bfc9d@oracle.com> Summary: Fix deadlock on ClassLoaderDataGraph_lock and g1 clear_claimed_marks. Thank you to Stefan for finding the deadlock and Thomas for suggestions on the fix, plus text for comments. Tested with this test 100s of times, tier1-3 and tier6 almost complete. open webrev at http://cr.openjdk.java.net/~coleenp/2019/8224151.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8224151 Thanks, Coleen From david.holmes at oracle.com Thu Jun 6 02:00:12 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 6 Jun 2019 12:00:12 +1000 Subject: [13] RFR(S) 8222371: Use UL for TraceNMethodInstalls code In-Reply-To: References: Message-ID: Hi Vladimir, This looks good to me. This implicitly makes TraceNMethodInstalls deprecated. Is there a plan to actually remove it later? Thanks, David On 6/06/2019 9:58 am, Vladimir Kozlov wrote: > https://cr.openjdk.java.net/~kvn/8222371/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8222371 > > Replace -XX:+TraceNMethodInstalls with -Xlog:nmethod+install. > > Thanks, > Vladimir From david.holmes at oracle.com Thu Jun 6 02:11:33 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 6 Jun 2019 12:11:33 +1000 Subject: RFR [XS] of VM portions of JDK-8214546: Start of release updates for JDK 14 In-Reply-To: <5CF86CDF.9020706@oracle.com> References: <5CF86CDF.9020706@oracle.com> Message-ID: <11047a49-4c07-2ef0-b5dd-df89199b2783@oracle.com> Hi Joe, Hotspot changes look good to me. Thanks, David On 6/06/2019 11:31 am, Joseph D. Darcy wrote: > Hello, > > The time for the fork of JDK 13 approaches and therefore preparations > for transitioning jdk/jdk to be JDK 14 are underway. > > Please review the VM portions of the in-progress start of release > updates for 14: > > ??? http://cr.openjdk.java.net/~darcy/jdk14-fork.2/ > > Patches for the few VM-related changes are listed as diffs below. Builds > and langtools aspects of this change are being reviewed separately on > the appropriate mailing lists. Before this change is eventually pushed, > I'll regenerate the javac --release symbol information from the latest > JDK 13 promoted build and redo a build + test cycle to make sure no > additional tests need to be updated, etc. > > Thanks, > > -Joe > > --- old/src/hotspot/share/classfile/classFileParser.cpp 2019-05-17 > 09:42:36.328000000 -0700 > +++ new/src/hotspot/share/classfile/classFileParser.cpp 2019-05-17 > 09:42:35.944000000 -0700 > @@ -125,6 +125,8 @@ > > ?#define JAVA_13_VERSION?????????????????? 57 > > +#define JAVA_14_VERSION?????????????????? 58 > + > ?void ClassFileParser::set_class_bad_constant_seen(short bad_constant) { > ?? assert((bad_constant == JVM_CONSTANT_Module || > ?????????? bad_constant == JVM_CONSTANT_Package) && _major_version >= > JAVA_9_VERSION, > > --- > old/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/classfile/Classfile.java > 2019-05-17 09:42:59.588000000 -0700 > +++ > new/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/classfile/Classfile.java > 2019-05-17 09:42:59.188000000 -0700 > @@ -49,7 +49,7 @@ > ???? private final List codeAttributes; > > ???? private static final int MAJOR_VERSION_JAVA_MIN = 51; // JDK7 > -??? private static final int MAJOR_VERSION_JAVA_MAX = 57; // JDK13 > +??? private static final int MAJOR_VERSION_JAVA_MAX = 58; // JDK14 > ???? private static final int MAGIC = 0xCAFEBABE; > > ???? /** > > --- old/test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java > 2019-05-17 09:43:02.244000000 -0700 > +++ new/test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java > 2019-05-17 09:43:01.844000000 -0700 > @@ -45,8 +45,6 @@ > ???????? {"MinRAMFraction",??????????? "2"}, > ???????? {"InitialRAMFraction",??????? "64"}, > ???????? {"TLABStats",???????????????? "false"}, > -??????? {"ThreadLocalHandshakes",???? "true"}, > -??????? {"AllowJNIEnvProxy",????????? "true"}, > ???????? {"AllowRedefinitionToAddDeleteMethods", "true"}, > > ???????? // deprecated alias flags (see also aliased_jvm_flags): > > From thomas.stuefe at gmail.com Thu Jun 6 06:57:11 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 6 Jun 2019 08:57:11 +0200 Subject: RFR [XS]: 8224958: add os::dll_load calls to event log In-Reply-To: <06927025-ecc0-812d-7512-78ff4bf5a46c@oracle.com> References: <558c4f7d-8070-3b02-e667-dc5613e87286@oracle.com> <06927025-ecc0-812d-7512-78ff4bf5a46c@oracle.com> Message-ID: On Thu, Jun 6, 2019 at 1:18 AM David Holmes wrote: > On 5/06/2019 10:58 pm, Thomas St?fe wrote: > > On Wed, Jun 5, 2019 at 2:50 PM David Holmes > > wrote: > > > > On 5/06/2019 7:06 pm, Baesken, Matthias wrote: > > > Hi Thomas , I removed the error_report _ NULL check > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.2/ > > > > You missed one in src/hotspot/os/bsd/os_bsd.cpp > > > > + if (error_report == NULL) { > > + error_report = "dlerror returned no error description"; > > + } > > + if (error_report && ebuf && ebuflen > 0) { > > > > > > > > * You moved lasterror() up to get a "fresh" error value > > before calling into event logging right? I needed a while to > > understand that. Okay. > > > > > > Yes this was my intention . > > > > Not sure I'd say "fresh" is the right description. An error has > > occurred > > and you want the error message for log statement. Its the same error > > message you'd get later as no other system call is being made. > There's > > no difference to the how the code currently works, we just want the > > error text earlier for the log. > > > > > > not quite :) > > > > Matthias prints out the numerical errcode in his call to Events::log, > > retrieved by GetLastError() some lines above. That has nothing to do > > with lasterror and errbuf. lasterror() is used to fill errbuf. It too > > calls GetLastError(), which makes it position dependend. Matthias added > > a new call into the EventLog system, so he is careful and moves the call > > to lasterror() up in case the EventLog system calls system APIs and > > overwrites the error code. > > Sometimes my brain continues to see what it thinks it should be > seeing. Lack of coffee :) > I thought we were logging the text version of the error - why > aren't we? > This comes down to taste. I personally prefer a numerical error code (would prefer this on the POSIX platforms too but dlopen() is this weird outlier that does not set errno). I'm fine with both error code or error text. Matthias should decide. > The error message has to be captured before the log call as logging may > change what is returned by GetLastError. > > Which is what Matthias did? Cheers, Thomas > David > > > > > ..Thomas > > > > > > David > > ----- > > > > > > > > > > > * It would be better to have a function which only does the > > text translation, using an error code we give it as parameter. > > > * Then we could have given it the errcode we already have. > > Would be good for a future improvement. > > > > > > There are not so many os::lasterror usages currently . So I > > am not sure if it is really needed , let?s do it in a separate > > CR any way ? > > > > > > > > > > > > Best regards, Matthias > > > > > > > > > From: Thomas St?fe > > > > > Sent: Mittwoch, 5. Juni 2019 09:31 > > > To: Baesken, Matthias > > > > > Cc: hotspot-dev at openjdk.java.net > > > > > Subject: Re: RFR [XS]: 8224958: add os::dll_load calls to event > log > > > > > > Hi Matthias, > > > > > > looks good. Minor nit: > > > > > > + if (error_report == NULL) { > > > + error_report = "dlerror returned no error description"; > > > + } > > > + if (error_report && ebuf && ebuflen > 0) { > > > > > > Since you ensure error_report is always set - with a default > > text, if needed - you do not need to check it for NULL afterwards. > > > > > > If you only fix this, I do not need a new webrev. > > > > > > --- > > > > > > Side note: > > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.1/src/hotspot/os/windows/os_windows.cpp.udiff.html > > > > > > You moved lasterror() up to get a "fresh" error value before > > calling into event logging right? I needed a while to understand > > that. Okay. > > > > > > This shows that lasterror() is actually not well designed. > > lasterror() does two things: 1) get the error code with GetLastError > > and 2) translate that numerical code to a text. > > > > > > It would be better to have a function which only does the text > > translation, using an error code we give it as parameter. Then we > > could have given it the errcode we already have. Would be good for a > > future improvement. > > > Cheers, Thomas > > > > > > > > > From david.holmes at oracle.com Thu Jun 6 07:02:22 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 6 Jun 2019 17:02:22 +1000 Subject: RFR [XS]: 8224958: add os::dll_load calls to event log In-Reply-To: References: <558c4f7d-8070-3b02-e667-dc5613e87286@oracle.com> <06927025-ecc0-812d-7512-78ff4bf5a46c@oracle.com> Message-ID: <2137ae75-732a-5169-aa9e-a8ea28831d5e@oracle.com> On 6/06/2019 4:57 pm, Thomas St?fe wrote: > On Thu, Jun 6, 2019 at 1:18 AM David Holmes > wrote: > > On 5/06/2019 10:58 pm, Thomas St?fe wrote: > > On Wed, Jun 5, 2019 at 2:50 PM David Holmes > > > >> wrote: > > > >? ? ?On 5/06/2019 7:06 pm, Baesken, Matthias wrote: > >? ? ? > Hi Thomas , I removed? the error_report _ NULL check > >? ? ? > > >? ? ? > http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.2/ > > > >? ? ?You missed one in src/hotspot/os/bsd/os_bsd.cpp > > > >? ? ?+? ?if (error_report == NULL) { > >? ? ?+? ? ?error_report = "dlerror returned no error description"; > >? ? ?+? ?} > >? ? ?+? ?if (error_report && ebuf && ebuflen > 0) { > > > >? ? ? > > >? ? ? >? ? *? ?You moved lasterror() up to get a "fresh" error value > >? ? ?before calling into event logging right? I needed a while to > >? ? ?understand that. Okay. > >? ? ? > > >? ? ? > Yes this was my intention . > > > >? ? ?Not sure I'd say "fresh" is the right description. An error has > >? ? ?occurred > >? ? ?and you want the error message for log statement. Its the > same error > >? ? ?message you'd get later as no other system call is being > made. There's > >? ? ?no difference to the how the code currently works, we just > want the > >? ? ?error text earlier for the log. > > > > > > not quite :) > > > > Matthias prints out the numerical errcode in his call to > Events::log, > > retrieved by GetLastError() some lines above. That has nothing to do > > with lasterror and errbuf. lasterror() is used to fill errbuf. It > too > > calls GetLastError(), which makes it position dependend. Matthias > added > > a new call into the EventLog system, so he is careful and moves > the call > > to lasterror() up in case the EventLog system calls system APIs and > > overwrites the error code. > > Sometimes my brain continues to see what it thinks it should be > seeing. > > > Lack of coffee :) Alas I have tried a range of beverages but none seem to help ;-) > I thought we were logging the text version of the error - why > aren't we? > > > This comes down to taste. I personally prefer a numerical error code > (would prefer this on the POSIX platforms too but dlopen() is this weird > outlier that does not set errno). > > I'm fine with both error code or error text. Matthias should decide. Okay I'm fine with that. > The error message has to be captured before the log call as logging may > change what is returned by GetLastError. > > Which is what Matthias did? Yes. Cheers, David > Cheers, Thomas > > David > > > > > ..Thomas > > > > > >? ? ?David > >? ? ?----- > > > >? ? ? > > >? ? ? > > >? ? ? >? ? *? ?It would be better to have a function which only > does the > >? ? ?text translation, using an error code we give it as parameter. > >? ? ? >? ? *? ?Then we could have given it the errcode we already > have. > >? ? ?Would be good for a future improvement. > >? ? ? > > >? ? ? > There are not so many? os::lasterror? ?usages currently . > So I > >? ? ?am not sure if it is really needed ,? ?let?s? do it in a separate > >? ? ?CR? any way ? > >? ? ? > > >? ? ? > > >? ? ? > > >? ? ? > Best regards, Matthias > >? ? ? > > >? ? ? > > >? ? ? > From: Thomas St?fe > >? ? ? >> > >? ? ? > Sent: Mittwoch, 5. Juni 2019 09:31 > >? ? ? > To: Baesken, Matthias > >? ? ? >> > >? ? ? > Cc: hotspot-dev at openjdk.java.net > > >? ? ? > > >? ? ? > Subject: Re: RFR [XS]: 8224958: add os::dll_load calls to > event log > >? ? ? > > >? ? ? > Hi Matthias, > >? ? ? > > >? ? ? > looks good. Minor nit: > >? ? ? > > >? ? ? > +? if (error_report == NULL) { > >? ? ? > +? ? error_report = "dlerror returned no error description"; > >? ? ? > +? } > >? ? ? > +? if (error_report && ebuf && ebuflen > 0) { > >? ? ? > > >? ? ? > Since you ensure error_report is always set - with a default > >? ? ?text, if needed - you do not need to check it for NULL > afterwards. > >? ? ? > > >? ? ? > If you only fix this, I do not need a new webrev. > >? ? ? > > >? ? ? > --- > >? ? ? > > >? ? ? > Side note: > >? ? ? > > >? ? ? > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.1/src/hotspot/os/windows/os_windows.cpp.udiff.html > >? ? ? > > >? ? ? > You moved lasterror() up to get a "fresh" error value before > >? ? ?calling into event logging right? I needed a while to understand > >? ? ?that. Okay. > >? ? ? > > >? ? ? > This shows that lasterror() is actually not well designed. > >? ? ?lasterror() does two things: 1) get the error code with > GetLastError > >? ? ?and 2) translate that numerical code to a text. > >? ? ? > > >? ? ? > It would be better to have a function which only does the text > >? ? ?translation, using an error code we give it as parameter. Then we > >? ? ?could have given it the errcode we already have. Would be > good for a > >? ? ?future improvement. > >? ? ? > Cheers, Thomas > >? ? ? > > >? ? ? > > > > From matthias.baesken at sap.com Thu Jun 6 07:15:08 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 6 Jun 2019 07:15:08 +0000 Subject: RFR [XS]: 8224958: add os::dll_load calls to event log In-Reply-To: <2137ae75-732a-5169-aa9e-a8ea28831d5e@oracle.com> References: <558c4f7d-8070-3b02-e667-dc5613e87286@oracle.com> <06927025-ecc0-812d-7512-78ff4bf5a46c@oracle.com> <2137ae75-732a-5169-aa9e-a8ea28831d5e@oracle.com> Message-ID: Hello, I would keep the last revision as it is . David may I add you as reviewer ? Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Donnerstag, 6. Juni 2019 09:02 > To: Thomas St?fe > Cc: Baesken, Matthias ; hotspot- > dev at openjdk.java.net > Subject: Re: RFR [XS]: 8224958: add os::dll_load calls to event log > > On 6/06/2019 4:57 pm, Thomas St?fe wrote: > > On Thu, Jun 6, 2019 at 1:18 AM David Holmes > > wrote: > > > > On 5/06/2019 10:58 pm, Thomas St?fe wrote: > > > On Wed, Jun 5, 2019 at 2:50 PM David Holmes > > > > > > >> wrote: > > > > > >? ? ?On 5/06/2019 7:06 pm, Baesken, Matthias wrote: > > >? ? ? > Hi Thomas , I removed? the error_report _ NULL check > > >? ? ? > > > >? ? ? > http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.2/ > > > > > >? ? ?You missed one in src/hotspot/os/bsd/os_bsd.cpp > > > > > >? ? ?+? ?if (error_report == NULL) { > > >? ? ?+? ? ?error_report = "dlerror returned no error description"; > > >? ? ?+? ?} > > >? ? ?+? ?if (error_report && ebuf && ebuflen > 0) { > > > > > >? ? ? > > > >? ? ? >? ? *? ?You moved lasterror() up to get a "fresh" error value > > >? ? ?before calling into event logging right? I needed a while to > > >? ? ?understand that. Okay. > > >? ? ? > > > >? ? ? > Yes this was my intention . > > > > > >? ? ?Not sure I'd say "fresh" is the right description. An error has > > >? ? ?occurred > > >? ? ?and you want the error message for log statement. Its the > > same error > > >? ? ?message you'd get later as no other system call is being > > made. There's > > >? ? ?no difference to the how the code currently works, we just > > want the > > >? ? ?error text earlier for the log. > > > > > > > > > not quite :) > > > > > > Matthias prints out the numerical errcode in his call to > > Events::log, > > > retrieved by GetLastError() some lines above. That has nothing to do > > > with lasterror and errbuf. lasterror() is used to fill errbuf. It > > too > > > calls GetLastError(), which makes it position dependend. Matthias > > added > > > a new call into the EventLog system, so he is careful and moves > > the call > > > to lasterror() up in case the EventLog system calls system APIs and > > > overwrites the error code. > > > > Sometimes my brain continues to see what it thinks it should be > > seeing. > > > > > > Lack of coffee :) > > Alas I have tried a range of beverages but none seem to help ;-) > > > I thought we were logging the text version of the error - why > > aren't we? > > > > > > This comes down to taste. I personally prefer a numerical error code > > (would prefer this on the POSIX platforms too but dlopen() is this weird > > outlier that does not set errno). > > > > I'm fine with both error code or error text. Matthias should decide. > > Okay I'm fine with that. > > > The error message has to be captured before the log call as logging may > > change what is returned by GetLastError. > > > > Which is what Matthias did? > > Yes. > > Cheers, > David > > > Cheers, Thomas > > > > David > > > > > > > > ..Thomas > > > > > > > > >? ? ?David > > >? ? ?----- > > > > > >? ? ? > > > >? ? ? > > > >? ? ? >? ? *? ?It would be better to have a function which only > > does the > > >? ? ?text translation, using an error code we give it as parameter. > > >? ? ? >? ? *? ?Then we could have given it the errcode we already > > have. > > >? ? ?Would be good for a future improvement. > > >? ? ? > > > >? ? ? > There are not so many? os::lasterror? ?usages currently . > > So I > > >? ? ?am not sure if it is really needed ,? ?let?s? do it in a separate > > >? ? ?CR? any way ? > > >? ? ? > From david.holmes at oracle.com Thu Jun 6 07:39:28 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 6 Jun 2019 17:39:28 +1000 Subject: RFR [XS]: 8224958: add os::dll_load calls to event log In-Reply-To: References: <558c4f7d-8070-3b02-e667-dc5613e87286@oracle.com> <06927025-ecc0-812d-7512-78ff4bf5a46c@oracle.com> <2137ae75-732a-5169-aa9e-a8ea28831d5e@oracle.com> Message-ID: <731b0e72-16c8-a947-20d3-0e2daa4a0f59@oracle.com> On 6/06/2019 5:15 pm, Baesken, Matthias wrote: > Hello, I would keep the last revision as it is . > David may I add you as reviewer ? Yes. Thanks, David > Best regards, Matthias > > >> -----Original Message----- >> From: David Holmes >> Sent: Donnerstag, 6. Juni 2019 09:02 >> To: Thomas St?fe >> Cc: Baesken, Matthias ; hotspot- >> dev at openjdk.java.net >> Subject: Re: RFR [XS]: 8224958: add os::dll_load calls to event log >> >> On 6/06/2019 4:57 pm, Thomas St?fe wrote: >>> On Thu, Jun 6, 2019 at 1:18 AM David Holmes >> > wrote: >>> >>> On 5/06/2019 10:58 pm, Thomas St?fe wrote: >>> > On Wed, Jun 5, 2019 at 2:50 PM David Holmes >>> >>> > >> >> wrote: >>> > >>> >? ? ?On 5/06/2019 7:06 pm, Baesken, Matthias wrote: >>> >? ? ? > Hi Thomas , I removed? the error_report _ NULL check >>> >? ? ? > >>> >? ? ? > http://cr.openjdk.java.net/~mbaesken/webrevs/8224958.2/ >>> > >>> >? ? ?You missed one in src/hotspot/os/bsd/os_bsd.cpp >>> > >>> >? ? ?+? ?if (error_report == NULL) { >>> >? ? ?+? ? ?error_report = "dlerror returned no error description"; >>> >? ? ?+? ?} >>> >? ? ?+? ?if (error_report && ebuf && ebuflen > 0) { >>> > >>> >? ? ? > >>> >? ? ? >? ? *? ?You moved lasterror() up to get a "fresh" error value >>> >? ? ?before calling into event logging right? I needed a while to >>> >? ? ?understand that. Okay. >>> >? ? ? > >>> >? ? ? > Yes this was my intention . >>> > >>> >? ? ?Not sure I'd say "fresh" is the right description. An error has >>> >? ? ?occurred >>> >? ? ?and you want the error message for log statement. Its the >>> same error >>> >? ? ?message you'd get later as no other system call is being >>> made. There's >>> >? ? ?no difference to the how the code currently works, we just >>> want the >>> >? ? ?error text earlier for the log. >>> > >>> > >>> > not quite :) >>> > >>> > Matthias prints out the numerical errcode in his call to >>> Events::log, >>> > retrieved by GetLastError() some lines above. That has nothing to do >>> > with lasterror and errbuf. lasterror() is used to fill errbuf. It >>> too >>> > calls GetLastError(), which makes it position dependend. Matthias >>> added >>> > a new call into the EventLog system, so he is careful and moves >>> the call >>> > to lasterror() up in case the EventLog system calls system APIs and >>> > overwrites the error code. >>> >>> Sometimes my brain continues to see what it thinks it should be >>> seeing. >>> >>> >>> Lack of coffee :) >> >> Alas I have tried a range of beverages but none seem to help ;-) >> >>> I thought we were logging the text version of the error - why >>> aren't we? >>> >>> >>> This comes down to taste. I personally prefer a numerical error code >>> (would prefer this on the POSIX platforms too but dlopen() is this weird >>> outlier that does not set errno). >>> >>> I'm fine with both error code or error text. Matthias should decide. >> >> Okay I'm fine with that. >> >>> The error message has to be captured before the log call as logging may >>> change what is returned by GetLastError. >>> >>> Which is what Matthias did? >> >> Yes. >> >> Cheers, >> David >> >>> Cheers, Thomas >>> >>> David >>> >>> > >>> > ..Thomas >>> > >>> > >>> >? ? ?David >>> >? ? ?----- >>> > >>> >? ? ? > >>> >? ? ? > >>> >? ? ? >? ? *? ?It would be better to have a function which only >>> does the >>> >? ? ?text translation, using an error code we give it as parameter. >>> >? ? ? >? ? *? ?Then we could have given it the errcode we already >>> have. >>> >? ? ?Would be good for a future improvement. >>> >? ? ? > >>> >? ? ? > There are not so many? os::lasterror? ?usages currently . >>> So I >>> >? ? ?am not sure if it is really needed ,? ?let?s? do it in a separate >>> >? ? ?CR? any way ? >>> >? ? ? > > From matthias.baesken at sap.com Thu Jun 6 08:20:51 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 6 Jun 2019 08:20:51 +0000 Subject: RFR [XXS] 8225402: events logging in deoptimization.cpp should go to deopt-log Message-ID: > > Got it. Yes, I agree that they should be also in deopt log. > Hello here is an XXS change that adjusts the events - logging in deoptimization.cpp as discussed . Please review . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8225402 http://cr.openjdk.java.net/~mbaesken/webrevs/8225402.0/ Thanks, Matthias > -----Original Message----- > From: Vladimir Kozlov > Sent: Mittwoch, 5. Juni 2019 18:40 > To: Baesken, Matthias ; hotspot- > dev at openjdk.java.net > Subject: Re: deoptimization.cpp Events::log / Events::log_deopt_message - > was : RE: RFR: 8224221: add memprotect calls to event log > > Got it. Yes, I agree that they should be also in deopt log. > > Thanks, > Vladimir > > On 6/4/19 1:27 AM, Baesken, Matthias wrote: > > Hi Vladimir , sure the log_deopt_message() is used for the event-logging > and the events are later shown in the hs_err file . > > > > However my question was : in deoptimization.cpp we have ***both*** > calls to Events::log and Events::log_deopt_message . > > > > // Log a message > > Events::log(thread, "Uncommon trap: trap_request=" PTR32_FORMAT " > fr.pc=" INTPTR_FORMAT " relative=" INTPTR_FORMAT, > > trap_request, p2i(fr.pc()), fr.pc() - fr.cb()->code_begin()); > > > > Events::log(thread, "DEOPT PACKING pc=" INTPTR_FORMAT " sp=" > INTPTR_FORMAT, p2i(fr.pc()), p2i(fr.sp())); > > > > > > // Log a message > > Events::log_deopt_message(thread, "Uncommon trap: reason=%s > action=%s pc=" INTPTR_FORMAT " method=%s @ %d %s", > > trap_reason_name(reason), trap_action_name(action), > p2i(fr.pc()), > > trap_method->name_and_sig_as_C_string(), trap_bci, nm- > >compiler_name()); > > > > > > > > > > I think they all should call Events::log_deopt_message , so that they go > into the same event log part that is collecting the de-opt event messages . > > From jamsheed.c.m at oracle.com Thu Jun 6 08:47:54 2019 From: jamsheed.c.m at oracle.com (Jamsheed) Date: Thu, 6 Jun 2019 14:17:54 +0530 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <0ea5f1b5-1245-551b-90fd-7a63e8f15e92@oracle.com> <4354a0db-8f50-4eb0-af63-cadd5dde7ae5@oracle.com> <95af6958-6512-d894-2076-74f1b68e3dbe@oracle.com> <5422bc1c-4640-b3c8-bf26-b91a6df34f1e@oracle.com> <2848933c-e6bc-be44-7970-436ac00f0479@oracle.com> <188da7c3-7384-220a-9290-cdd4bad25fce@oracle.com> <2ddfbcbd-4dff-4b86-ba0b-d5920b80e7ec@oracle.com> <38eaa1b2-5fde-ca1d-0842-3d7f2b34e483@oracle.com> <611e1925-5384-9c74-064a-da30ba523268@oracle.com> <5e8afd81-37db-3a3f-1589-97a447cdc206@oracle.com> <891289e9-e661-bee7-7365-5266e894b721@oracle.com> Message-ID: Hi Harold, Yes, it is known issue, i removed all @requires just for testing purposes. will add? "* @requires os.family != "windows" " just before checkin. Best regards, Jamsheed On 06/06/19 12:25 AM, Harold Seigel wrote: > Hi Jamsheed, > > Test hotspot/jtreg/runtime/Unsafe/InternalErrorTest.java fails on > Windows with: > > ?? java.nio.file.FileSystemException: The requested operation cannot > be performed on a file with a user-mapped section open. > > ?????? at > java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92) > ?????? at > java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103) > ?????? at > java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108) > ?????? at > java.base/sun.nio.fs.WindowsFileSystemProvider.newByteChannel(WindowsFileSystemProvider.java:235) > ?????? at > java.base/java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:478) > ?????? at java.base/java.nio.file.Files.newOutputStream(Files.java:223) > ?????? at java.base/java.nio.file.Files.write(Files.java:3488) > ?????? at InternalErrorTest.main(InternalErrorTest.java:91) > ?????? at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > ?????? at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > ?????? at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > ?????? at java.base/java.lang.reflect.Method.invoke(Method.java:567) > ?????? at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > ?????? at java.base/java.lang.Thread.run(Thread.java:830) > > Can you add this to the test? > > ???? * @requires os.family != "windows" > > Thanks, Harold > > On 6/3/2019 2:43 PM, Jamsheed wrote: >> Hi Dan, >> >> Thanks for the review. >> >> Best regards, >> >> Jamsheed >> >> On 01/06/19 6:29 PM, Daniel D. Daugherty wrote: >>> That's even better. Thanks. >>> >>> Dan >>> >>> >>> On 6/1/19 5:11 AM, Jamsheed wrote: >>>> >>>> Hi Dan, >>>> >>>> updated webrev in place >>>> >>>> added only assert >>>> >>>> +? BasicType doing_unsafe_access_bt = T_BYTE; >>>> +? assert((sizeof(bool) * CHAR_BIT) == 8, "not implemented"); >>>> >>>> Best regards, >>>> >>>> Jamsheed >>>> >>>> On 01/06/19 12:56 PM, Jamsheed wrote: >>>>> >>>>> Hi Dan, >>>>> >>>>> i understand it is incorrect to assume bool(cpp compiler) >>>>> implementation above byte level. >>>>> >>>>> in that case i will just put an assert. >>>>> >>>>> +? BasicType doing_unsafe_access_bt = T_BYTE; >>>>> >>>>> + assert(sizeof(bool) == 1, "not implemented"); >>>>> >>>>> Best regards, >>>>> >>>>> Jamsheed >>>>> >>>>> On 31/05/19 10:34 PM, Jamsheed wrote: >>>>>>> src/hotspot/share/opto/library_call.cpp >>>>>>> ??? In src/hotspot/share/runtime/thread.hpp: >>>>>>> ??? L1090: ? volatile bool _doing_unsafe_access; >>>>>>> >>>>>>> ??? L4220: ? store_to_memory(control(), >>>>>>> doing_unsafe_access_addr, intcon(1), T_BYTE, >>>>>>> Compile::AliasIdxRaw, MemNode::unordered); >>>>>>> ??? L4230: ? store_to_memory(control(), >>>>>>> doing_unsafe_access_addr, intcon(0), T_BYTE, >>>>>>> Compile::AliasIdxRaw, MemNode::unordered); >>>>>>> ??????? Is T_BYTE a safe assumption (size wise) for writing to a >>>>>>> C++ bool? >>>>>> >>>>>> Thanks for pointing this. >>>>>> >>>>>> hope [1] will work ? >>>>> [1] >>>>> +? BasicType doing_unsafe_access_bt = T_BYTE; >>>>> +? switch(sizeof(bool)) { >>>>> +??? case 1: doing_unsafe_access_bt = T_BYTE;? break; >>>>> +??? case 2: doing_unsafe_access_bt = T_SHORT; break; >>>>> +??? case 4: doing_unsafe_access_bt = T_INT;?? break; >>>>> +??? case 8: doing_unsafe_access_bt = T_LONG;? break; >>>>> +??? default: ShouldNotReachHere(); >>>>> +? } >>>>> >>>>> ?? // update volatile field >>>>> -? store_to_memory(control(), doing_unsafe_access_addr, intcon(1), >>>>> T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); >>>>> +? store_to_memory(control(), doing_unsafe_access_addr, intcon(1), >>>>> doing_unsafe_access_bt, Compile::AliasIdxRaw, MemNode::unordered); >>>>> >>>>> ?? // Call it.? Note that the length argument is not scaled. >>>>> ?? make_runtime_call(RC_LEAF|RC_NO_FP, >>>>> ???????????????????? OptoRuntime::fast_arraycopy_Type(), >>>>> ???????????????????? StubRoutines::unsafe_arraycopy(), >>>>> ???????????????????? "unsafe_arraycopy", >>>>> ???????????????????? TypeRawPtr::BOTTOM, >>>>> ???????????????????? src, dst, size XTOP); >>>>> >>>>> -? store_to_memory(control(), doing_unsafe_access_addr, intcon(0), >>>>> T_BYTE, Compile::AliasIdxRaw, MemNode::unordered); >>>>> +? store_to_memory(control(), doing_unsafe_access_addr, intcon(0), >>>>> doing_unsafe_access_bt, Compile::AliasIdxRaw, MemNode::unordered); >>> From martin.doerr at sap.com Thu Jun 6 09:02:33 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 6 Jun 2019 09:02:33 +0000 Subject: RFR [XXS] 8225402: events logging in deoptimization.cpp should go to deopt-log In-Reply-To: References: Message-ID: Hi Matthias, looks good and trivial. Best regards, Martin > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Donnerstag, 6. Juni 2019 10:21 > To: Vladimir Kozlov ; hotspot- > dev at openjdk.java.net > Subject: RFR [XXS] 8225402: events logging in deoptimization.cpp should go > to deopt-log > > > > > > Got it. Yes, I agree that they should be also in deopt log. > > > > Hello here is an XXS change that adjusts the events - logging in > deoptimization.cpp as discussed . Please review . > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8225402 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8225402.0/ > > > Thanks, Matthias > > > > > -----Original Message----- > > From: Vladimir Kozlov > > Sent: Mittwoch, 5. Juni 2019 18:40 > > To: Baesken, Matthias ; hotspot- > > dev at openjdk.java.net > > Subject: Re: deoptimization.cpp Events::log / Events::log_deopt_message - > > was : RE: RFR: 8224221: add memprotect calls to event log > > > > Got it. Yes, I agree that they should be also in deopt log. > > > > Thanks, > > Vladimir > > > > On 6/4/19 1:27 AM, Baesken, Matthias wrote: > > > Hi Vladimir , sure the log_deopt_message() is used for the event- > logging > > and the events are later shown in the hs_err file . > > > > > > However my question was : in deoptimization.cpp we have > ***both*** > > calls to Events::log and Events::log_deopt_message . > > > > > > // Log a message > > > Events::log(thread, "Uncommon trap: trap_request=" PTR32_FORMAT " > > fr.pc=" INTPTR_FORMAT " relative=" INTPTR_FORMAT, > > > trap_request, p2i(fr.pc()), fr.pc() - fr.cb()->code_begin()); > > > > > > Events::log(thread, "DEOPT PACKING pc=" INTPTR_FORMAT " sp=" > > INTPTR_FORMAT, p2i(fr.pc()), p2i(fr.sp())); > > > > > > > > > // Log a message > > > Events::log_deopt_message(thread, "Uncommon trap: reason=%s > > action=%s pc=" INTPTR_FORMAT " method=%s @ %d %s", > > > trap_reason_name(reason), trap_action_name(action), > > p2i(fr.pc()), > > > trap_method->name_and_sig_as_C_string(), trap_bci, > nm- > > >compiler_name()); > > > > > > > > > > > > > > > I think they all should call Events::log_deopt_message , so that they go > > into the same event log part that is collecting the de-opt event messages . > > > From thomas.stuefe at gmail.com Thu Jun 6 09:07:37 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 6 Jun 2019 11:07:37 +0200 Subject: RFR [XXS] 8225402: events logging in deoptimization.cpp should go to deopt-log In-Reply-To: References: Message-ID: +1 ..Thomas On Thu, Jun 6, 2019 at 10:22 AM Baesken, Matthias wrote: > > > > > Got it. Yes, I agree that they should be also in deopt log. > > > > Hello here is an XXS change that adjusts the events - logging in > deoptimization.cpp as discussed . Please review . > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8225402 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8225402.0/ > > > Thanks, Matthias > > > > > -----Original Message----- > > From: Vladimir Kozlov > > Sent: Mittwoch, 5. Juni 2019 18:40 > > To: Baesken, Matthias ; hotspot- > > dev at openjdk.java.net > > Subject: Re: deoptimization.cpp Events::log / Events::log_deopt_message - > > was : RE: RFR: 8224221: add memprotect calls to event log > > > > Got it. Yes, I agree that they should be also in deopt log. > > > > Thanks, > > Vladimir > > > > On 6/4/19 1:27 AM, Baesken, Matthias wrote: > > > Hi Vladimir , sure the log_deopt_message() is used for the > event-logging > > and the events are later shown in the hs_err file . > > > > > > However my question was : in deoptimization.cpp we have ***both*** > > calls to Events::log and Events::log_deopt_message . > > > > > > // Log a message > > > Events::log(thread, "Uncommon trap: trap_request=" PTR32_FORMAT " > > fr.pc=" INTPTR_FORMAT " relative=" INTPTR_FORMAT, > > > trap_request, p2i(fr.pc()), fr.pc() - > fr.cb()->code_begin()); > > > > > > Events::log(thread, "DEOPT PACKING pc=" INTPTR_FORMAT " sp=" > > INTPTR_FORMAT, p2i(fr.pc()), p2i(fr.sp())); > > > > > > > > > // Log a message > > > Events::log_deopt_message(thread, "Uncommon trap: reason=%s > > action=%s pc=" INTPTR_FORMAT " method=%s @ %d %s", > > > trap_reason_name(reason), > trap_action_name(action), > > p2i(fr.pc()), > > > > trap_method->name_and_sig_as_C_string(), trap_bci, nm- > > >compiler_name()); > > > > > > > > > > > > > > > I think they all should call Events::log_deopt_message , so that > they go > > into the same event log part that is collecting the de-opt event > messages . > > > > > From thomas.schatzl at oracle.com Thu Jun 6 09:22:41 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 06 Jun 2019 11:22:41 +0200 Subject: RFR (S) 8224151: Test vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java might hang with release binaries In-Reply-To: <7060291e-67a2-97d0-c3cc-40df304bfc9d@oracle.com> References: <7060291e-67a2-97d0-c3cc-40df304bfc9d@oracle.com> Message-ID: Hi, On Wed, 2019-06-05 at 21:53 -0400, coleen.phillimore at oracle.com wrote: > Summary: Fix deadlock on ClassLoaderDataGraph_lock and g1 > clear_claimed_marks. > > Thank you to Stefan for finding the deadlock and Thomas for > suggestions > on the fix, plus text for comments. > > Tested with this test 100s of times, tier1-3 and tier6 almost > complete. > > open webrev at > http://cr.openjdk.java.net/~coleenp/2019/8224151.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8224151 > looks good. Maybe in the big comment, also add comment delimitiers between the paragraphs of the text. Do not need to re-review that change. Thanks, Thomas From matthias.baesken at sap.com Thu Jun 6 11:29:03 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 6 Jun 2019 11:29:03 +0000 Subject: RFR : 8225345: Provide Cloud IAAS related info on Linux in the hs_err file Message-ID: Hello, please review the following change . It enhances the hs_error file output on Linux by Cloud IAAS detection . The DMI information exposed by the /sys virtual filesystem can be used to detect various Cloud IAAS on Linux. It is helpful, for instance in support cases, to get some information about the Cloud IAAS in the hs_error file . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8225345 http://cr.openjdk.java.net/~mbaesken/webrevs/8225345.0/ Thanks, Matthias From david.holmes at oracle.com Thu Jun 6 11:50:31 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 6 Jun 2019 21:50:31 +1000 Subject: RFR : 8225345: Provide Cloud IAAS related info on Linux in the hs_err file In-Reply-To: References: Message-ID: <19eec625-e87b-b625-41b1-71b535a671a1@oracle.com> Hi Matthias, On 6/06/2019 9:29 pm, Baesken, Matthias wrote: > Hello, please review the following change . > It enhances the hs_error file output on Linux by Cloud IAAS detection . > > The DMI information exposed by the /sys virtual filesystem can be used to detect various Cloud IAAS on Linux. > It is helpful, for instance in support cases, to get some information about the Cloud IAAS in the hs_error file . Sorry but how is it at all relevant to crash diagnosis? And maybe a customer doesn't want you to know whose Cloud services they use! This seems like something that should be guarded by ExtensiveErrorReports - at best. David ----- > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8225345 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8225345.0/ > > > Thanks, Matthias > From coleen.phillimore at oracle.com Thu Jun 6 12:01:58 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 6 Jun 2019 08:01:58 -0400 Subject: RFR (S) 8224151: Test vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java might hang with release binaries In-Reply-To: References: <7060291e-67a2-97d0-c3cc-40df304bfc9d@oracle.com> Message-ID: On 6/6/19 5:22 AM, Thomas Schatzl wrote: > Hi, > > On Wed, 2019-06-05 at 21:53 -0400, coleen.phillimore at oracle.com wrote: >> Summary: Fix deadlock on ClassLoaderDataGraph_lock and g1 >> clear_claimed_marks. >> >> Thank you to Stefan for finding the deadlock and Thomas for >> suggestions >> on the fix, plus text for comments. >> >> Tested with this test 100s of times, tier1-3 and tier6 almost >> complete. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8224151.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8224151 >> > looks good. > > Maybe in the big comment, also add comment delimitiers between the > paragraphs of the text. Do not need to re-review that change. Do you mean like //$ on the blank lines?? Sure I could do that. Thanks for the review and help! Coleen > > Thanks, > Thomas > > From coleen.phillimore at oracle.com Thu Jun 6 12:03:17 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 6 Jun 2019 08:03:17 -0400 Subject: RFR [XXS] 8225402: events logging in deoptimization.cpp should go to deopt-log In-Reply-To: References: Message-ID: <9b055300-9296-5806-b211-db368ed0b46d@oracle.com> +1 Thank you! Coleen On 6/6/19 5:07 AM, Thomas St?fe wrote: > +1 > > ..Thomas > > On Thu, Jun 6, 2019 at 10:22 AM Baesken, Matthias > wrote: > >>> Got it. Yes, I agree that they should be also in deopt log. >>> >> Hello here is an XXS change that adjusts the events - logging in >> deoptimization.cpp as discussed . Please review . >> >> >> Bug/webrev : >> >> https://bugs.openjdk.java.net/browse/JDK-8225402 >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8225402.0/ >> >> >> Thanks, Matthias >> >> >> >>> -----Original Message----- >>> From: Vladimir Kozlov >>> Sent: Mittwoch, 5. Juni 2019 18:40 >>> To: Baesken, Matthias ; hotspot- >>> dev at openjdk.java.net >>> Subject: Re: deoptimization.cpp Events::log / Events::log_deopt_message - >>> was : RE: RFR: 8224221: add memprotect calls to event log >>> >>> Got it. Yes, I agree that they should be also in deopt log. >>> >>> Thanks, >>> Vladimir >>> >>> On 6/4/19 1:27 AM, Baesken, Matthias wrote: >>>> Hi Vladimir , sure the log_deopt_message() is used for the >> event-logging >>> and the events are later shown in the hs_err file . >>>> However my question was : in deoptimization.cpp we have ***both*** >>> calls to Events::log and Events::log_deopt_message . >>>> // Log a message >>>> Events::log(thread, "Uncommon trap: trap_request=" PTR32_FORMAT " >>> fr.pc=" INTPTR_FORMAT " relative=" INTPTR_FORMAT, >>>> trap_request, p2i(fr.pc()), fr.pc() - >> fr.cb()->code_begin()); >>>> Events::log(thread, "DEOPT PACKING pc=" INTPTR_FORMAT " sp=" >>> INTPTR_FORMAT, p2i(fr.pc()), p2i(fr.sp())); >>>> >>>> // Log a message >>>> Events::log_deopt_message(thread, "Uncommon trap: reason=%s >>> action=%s pc=" INTPTR_FORMAT " method=%s @ %d %s", >>>> trap_reason_name(reason), >> trap_action_name(action), >>> p2i(fr.pc()), >> trap_method->name_and_sig_as_C_string(), trap_bci, nm- >>>> compiler_name()); >>>> >>>> >>>> >>>> >>>> I think they all should call Events::log_deopt_message , so that >> they go >>> into the same event log part that is collecting the de-opt event >> messages . >> From matthias.baesken at sap.com Thu Jun 6 12:17:41 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 6 Jun 2019 12:17:41 +0000 Subject: RFR : 8225345: Provide Cloud IAAS related info on Linux in the hs_err file In-Reply-To: <19eec625-e87b-b625-41b1-71b535a671a1@oracle.com> References: <19eec625-e87b-b625-41b1-71b535a671a1@oracle.com> Message-ID: Hi David , sure I can guard this by "ExtensiveErrorReports" . > > Sorry but how is it at all relevant to crash diagnosis? > It gives a more complete picture where you run , helps to improve the error analysis . ( like - involve the Cloud escalation team because ... ) > > And maybe a customer doesn't want you to know whose Cloud services they use! > Some people might not want the number of cores in hs_err, some might not want to OS version , some people might not want something else in hs_err . That's always hard to say , but I think the Cloud info is on the same technical level than what we currently already have in the hs_err so Nothing special . Best regards, Matthias > From: David Holmes > Sent: Donnerstag, 6. Juni 2019 13:51 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Subject: Re: RFR : 8225345: Provide Cloud IAAS related info on Linux in the > hs_err file > > Hi Matthias, > > On 6/06/2019 9:29 pm, Baesken, Matthias wrote: > > Hello, please review the following change . > > It enhances the hs_error file output on Linux by Cloud IAAS detection . > > > > The DMI information exposed by the /sys virtual filesystem can be used > to detect various Cloud IAAS on Linux. > > It is helpful, for instance in support cases, to get some information about > the Cloud IAAS in the hs_error file . > > Sorry but how is it at all relevant to crash diagnosis? > > And maybe a customer doesn't want you to know whose Cloud services they > use! > > This seems like something that should be guarded by > ExtensiveErrorReports - at best. > > David > ----- > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8225345 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8225345.0/ > > > > > > Thanks, Matthias > > From david.holmes at oracle.com Thu Jun 6 12:51:05 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 6 Jun 2019 22:51:05 +1000 Subject: RFR : 8225345: Provide Cloud IAAS related info on Linux in the hs_err file In-Reply-To: References: <19eec625-e87b-b625-41b1-71b535a671a1@oracle.com> Message-ID: On 6/06/2019 10:17 pm, Baesken, Matthias wrote: > Hi David , sure I can guard this by "ExtensiveErrorReports" . > >> >> Sorry but how is it at all relevant to crash diagnosis? >> > > It gives a more complete picture where you run , helps to improve the error analysis . > ( like - involve the Cloud escalation team because ... ) Sorry not seeing it. >> >> And maybe a customer doesn't want you to know whose Cloud services they use! >> > > Some people might not want the number of cores in hs_err, some might not want to OS version , > some people might not want something else in hs_err . > That's always hard to say , but I think the Cloud info is on the same technical level than what we currently already have in the hs_err so > Nothing special . Vastly different IMO. Whose Cloud services company X uses could be considered commercial-in-confidence. I don't see anything "technical" in knowing whose cloud was used. David ----- > > Best regards, Matthias > > >> From: David Holmes >> Sent: Donnerstag, 6. Juni 2019 13:51 >> To: Baesken, Matthias ; 'hotspot- >> dev at openjdk.java.net' >> Subject: Re: RFR : 8225345: Provide Cloud IAAS related info on Linux in the >> hs_err file >> >> Hi Matthias, >> >> On 6/06/2019 9:29 pm, Baesken, Matthias wrote: >>> Hello, please review the following change . >>> It enhances the hs_error file output on Linux by Cloud IAAS detection . >>> >>> The DMI information exposed by the /sys virtual filesystem can be used >> to detect various Cloud IAAS on Linux. >>> It is helpful, for instance in support cases, to get some information about >> the Cloud IAAS in the hs_error file . >> >> Sorry but how is it at all relevant to crash diagnosis? >> >> And maybe a customer doesn't want you to know whose Cloud services they >> use! >> >> This seems like something that should be guarded by >> ExtensiveErrorReports - at best. >> >> David >> ----- >> >>> >>> Bug/webrev : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8225345 >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8225345.0/ >>> >>> >>> Thanks, Matthias >>> From Alan.Bateman at oracle.com Thu Jun 6 13:26:53 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 6 Jun 2019 14:26:53 +0100 Subject: RFR : 8225345: Provide Cloud IAAS related info on Linux in the hs_err file In-Reply-To: References: <19eec625-e87b-b625-41b1-71b535a671a1@oracle.com> Message-ID: <3f27171d-a3ae-f66c-e2f4-c7264fab2bea@oracle.com> On 06/06/2019 13:17, Baesken, Matthias wrote: > Hi David , sure I can guard this by "ExtensiveErrorReports" . > >> Sorry but how is it at all relevant to crash diagnosis? >> > It gives a more complete picture where you run , helps to improve the error analysis . > ( like - involve the Cloud escalation team because ... ) > How stable is /sys/class/dmi? Is deploying with OnError configured to run dmidecode or some other tool an alternative? -Alan From matthias.baesken at sap.com Thu Jun 6 13:59:42 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 6 Jun 2019 13:59:42 +0000 Subject: RFR : 8225345: Provide Cloud IAAS related info on Linux in the hs_err file In-Reply-To: <3f27171d-a3ae-f66c-e2f4-c7264fab2bea@oracle.com> References: <19eec625-e87b-b625-41b1-71b535a671a1@oracle.com> <3f27171d-a3ae-f66c-e2f4-c7264fab2bea@oracle.com> Message-ID: Hello , from our experience /sys/class/dmi is pretty stable . Of course over time the product_name and chassis_asset_tag entries could change . Best regards, Matthias > -----Original Message----- > From: Alan Bateman > Sent: Donnerstag, 6. Juni 2019 15:27 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Cc: David Holmes > Subject: Re: RFR : 8225345: Provide Cloud IAAS related info on Linux in the > hs_err file > > On 06/06/2019 13:17, Baesken, Matthias wrote: > > Hi David , sure I can guard this by "ExtensiveErrorReports" . > > > >> Sorry but how is it at all relevant to crash diagnosis? > >> > > It gives a more complete picture where you run , helps to improve the > error analysis . > > ( like - involve the Cloud escalation team because ... ) > > > How stable is /sys/class/dmi? Is deploying with OnError configured to > run dmidecode or some other tool an alternative? > > -Alan From aph at redhat.com Thu Jun 6 15:19:05 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 6 Jun 2019 16:19:05 +0100 Subject: RFR: 8225429: Regression in disassembly quality Message-ID: <60b89a4f-655c-d5f8-7d6b-9532c865bba7@redhat.com> In a debug build, if you printed a disassembled method, you used to get a lot of information about a method. Now, you just get raw disassembly. This patch restores the status quo ante, http://cr.openjdk.java.net/~aph/8225429-1/ There are other bugs in the new disassembly output: in particular options processing seems to be very broken. However, this patch is enough to get things going again, so at least we can get some work done. Before: # {method} {0x00007f2f64833660} 'decodeModuleName' '(ILjava/lang/String;)Ljava/lang/String;' in 'jdk/internal/module/ModuleInfo$ConstantPool' # this: rsi:rsi = 'jdk/internal/module/ModuleInfo$ConstantPool' # parm0: rdx = int # parm1: rcx:rcx = 'java/lang/String' # [sp+0x40] (sp of caller) ;; N542: # B1 <- BLOCK HEAD IS JUNK Freq: 1 0x00007f2fb1168440: mov r10d,DWORD PTR [rsi+0x8] 0x00007f2fb1168444: movabs r12,0x800000000 0x00007f2fb116844e: add r10,r12 0x00007f2fb1168451: xor r12,r12 0x00007f2fb1168454: cmp rax,r10 0x00007f2fb1168457: jne 0x00007f2fb104d6a0 ; {runtime_call ic_miss_stub} 0x00007f2fb116845d: nop 0x00007f2fb116845e: nop 0x00007f2fb116845f: nop [Verified Entry Point] ;; B1: # B54 B2 <- BLOCK HEAD IS JUNK Freq: 1 0x00007f2fb1168460: mov DWORD PTR [rsp-0x16000],eax 0x00007f2fb1168467: push rbp 0x00007f2fb1168468: sub rsp,0x30 ;*synchronization entry ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at -1 (line 877) 0x00007f2fb116846c: mov r10,rsi 0x00007f2fb116846f: mov r9,rcx 0x00007f2fb1168472: mov edi,DWORD PTR [rcx+0xc] ;*getfield value {reexecute=0 rethrow=0 return_oop=0} ; - java.lang.String::length at 1 (line 658) ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at 1 (line 877) ; implicit exception: dispatches to 0x00007f2fb116872a ;; B2: # B55 B3 <- B1 Freq: 0.999999 Now you only get this, even in a debug build: 0x00007ff1c5176c20: mov r10d,DWORD PTR [rsi+0x8] 0x00007ff1c5176c24: movabs r12,0x800000000 0x00007ff1c5176c2e: add r10,r12 0x00007ff1c5176c31: xor r12,r12 0x00007ff1c5176c34: cmp rax,r10 0x00007ff1c5176c37: jne 0x00007ff1c5113da0 0x00007ff1c5176c3d: nop 0x00007ff1c5176c3e: nop 0x00007ff1c5176c3f: nop 0x00007ff1c5176c40: mov DWORD PTR [rsp-0x16000],eax 0x00007ff1c5176c47: push rbp 0x00007ff1c5176c48: sub rsp,0x30 0x00007ff1c5176c4c: mov r11,rsi 0x00007ff1c5176c4f: mov r9,rcx 0x00007ff1c5176c52: mov r10d,DWORD PTR [rcx+0xc] There are no comments at all, just raw disassembly. This patch restores the status quo ante: # {method} {0x00007f9f53c2e3c0} 'decodeModuleName' '(ILjava/lang/String;)Ljava/lang/String;' in 'jdk/internal/module/ModuleInfo$ConstantPool' # this: rsi:rsi = 'jdk/internal/module/ModuleInfo$ConstantPool' # parm0: rdx = int # parm1: rcx:rcx = 'java/lang/String' # [sp+0x40] (sp of caller) ;; N551: # out( B1 ) <- BLOCK HEAD IS JUNK Freq: 1 0x00007f9fb4d64620: mov r10d,DWORD PTR [rsi+0x8] 0x00007f9fb4d64624: movabs r12,0x800000000 0x00007f9fb4d6462e: add r10,r12 0x00007f9fb4d64631: xor r12,r12 0x00007f9fb4d64634: cmp rax,r10 0x00007f9fb4d64637: jne 0x00007f9fb4cfeda0 ; {runtime_call ic_miss_stub} 0x00007f9fb4d6463d: nop 0x00007f9fb4d6463e: nop 0x00007f9fb4d6463f: nop [Verified Entry Point] ;; B1: # out( B55 B2 ) <- BLOCK HEAD IS JUNK Freq: 1 0x00007f9fb4d64640: mov DWORD PTR [rsp-0x16000],eax 0x00007f9fb4d64647: push rbp 0x00007f9fb4d64648: sub rsp,0x30 ;*synchronization entry ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at -1 (line 876) 0x00007f9fb4d6464c: mov r11,rsi 0x00007f9fb4d6464f: mov r9,rcx 0x00007f9fb4d64652: mov r10d,DWORD PTR [rcx+0xc] ;*getfield value {reexecute=0 rethrow=0 return_oop=0} ; - java.lang.String::length at 1 (line 673) ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at 1 (line 876) ; implicit exception: dispatches to 0x00007f9fb4d648fe ;; B2: # out( B56 B3 ) <- in( B1 ) Freq: 0.999999 -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From vladimir.kozlov at oracle.com Thu Jun 6 16:58:20 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 6 Jun 2019 09:58:20 -0700 Subject: [13] RFR(S) 8222371: Use UL for TraceNMethodInstalls code In-Reply-To: References: Message-ID: <41cfc3f2-b004-74d4-c922-b6a92c9e4887@oracle.com> Thank you, David Yes, I will file RFE to deprecate it after these changes are pushed. But I most likely will not hit JDK 13 cut off. I forgot do we need CSR for diagnostic flags? I think we do but you I specialist in that so I am asking ;) Thanks, Vladimir On 6/5/19 7:00 PM, David Holmes wrote: > Hi Vladimir, > > This looks good to me. > > This implicitly makes TraceNMethodInstalls deprecated. Is there a plan to actually remove it later? > > Thanks, > David > > On 6/06/2019 9:58 am, Vladimir Kozlov wrote: >> https://cr.openjdk.java.net/~kvn/8222371/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8222371 >> >> Replace -XX:+TraceNMethodInstalls with -Xlog:nmethod+install. >> >> Thanks, >> Vladimir From ioi.lam at oracle.com Thu Jun 6 17:12:34 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 6 Jun 2019 10:12:34 -0700 Subject: RFR: 8225429: Regression in disassembly quality In-Reply-To: <60b89a4f-655c-d5f8-7d6b-9532c865bba7@redhat.com> References: <60b89a4f-655c-d5f8-7d6b-9532c865bba7@redhat.com> Message-ID: Hi Andrew, thanks for fixing this. I tried it and it worked for me :-) I also tried "java -XX:+PrintInterpreter -version" and the comments from the C++ source code has come back to life. - Ioi On 6/6/19 8:19 AM, Andrew Haley wrote: > In a debug build, if you printed a disassembled method, you used to > get a lot of information about a method. Now, you just get raw > disassembly. This patch restores the status quo ante, > > http://cr.openjdk.java.net/~aph/8225429-1/ > > There are other bugs in the new disassembly output: in particular > options processing seems to be very broken. However, this patch is > enough to get things going again, so at least we can get some work > done. > > Before: > > # {method} {0x00007f2f64833660} 'decodeModuleName' '(ILjava/lang/String;)Ljava/lang/String;' in 'jdk/internal/module/ModuleInfo$ConstantPool' > # this: rsi:rsi = 'jdk/internal/module/ModuleInfo$ConstantPool' > # parm0: rdx = int > # parm1: rcx:rcx = 'java/lang/String' > # [sp+0x40] (sp of caller) > ;; N542: # B1 <- BLOCK HEAD IS JUNK Freq: 1 > > 0x00007f2fb1168440: mov r10d,DWORD PTR [rsi+0x8] > 0x00007f2fb1168444: movabs r12,0x800000000 > 0x00007f2fb116844e: add r10,r12 > 0x00007f2fb1168451: xor r12,r12 > 0x00007f2fb1168454: cmp rax,r10 > 0x00007f2fb1168457: jne 0x00007f2fb104d6a0 ; {runtime_call ic_miss_stub} > 0x00007f2fb116845d: nop > 0x00007f2fb116845e: nop > 0x00007f2fb116845f: nop > [Verified Entry Point] > ;; B1: # B54 B2 <- BLOCK HEAD IS JUNK Freq: 1 > > 0x00007f2fb1168460: mov DWORD PTR [rsp-0x16000],eax > 0x00007f2fb1168467: push rbp > 0x00007f2fb1168468: sub rsp,0x30 ;*synchronization entry > ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at -1 (line 877) > > 0x00007f2fb116846c: mov r10,rsi > 0x00007f2fb116846f: mov r9,rcx > 0x00007f2fb1168472: mov edi,DWORD PTR [rcx+0xc] ;*getfield value {reexecute=0 rethrow=0 return_oop=0} > ; - java.lang.String::length at 1 (line 658) > ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at 1 (line 877) > ; implicit exception: dispatches to 0x00007f2fb116872a > ;; B2: # B55 B3 <- B1 Freq: 0.999999 > > Now you only get this, even in a debug build: > > 0x00007ff1c5176c20: mov r10d,DWORD PTR [rsi+0x8] > 0x00007ff1c5176c24: movabs r12,0x800000000 > 0x00007ff1c5176c2e: add r10,r12 > 0x00007ff1c5176c31: xor r12,r12 > 0x00007ff1c5176c34: cmp rax,r10 > 0x00007ff1c5176c37: jne 0x00007ff1c5113da0 > 0x00007ff1c5176c3d: nop > 0x00007ff1c5176c3e: nop > 0x00007ff1c5176c3f: nop > 0x00007ff1c5176c40: mov DWORD PTR [rsp-0x16000],eax > 0x00007ff1c5176c47: push rbp > 0x00007ff1c5176c48: sub rsp,0x30 > 0x00007ff1c5176c4c: mov r11,rsi > 0x00007ff1c5176c4f: mov r9,rcx > 0x00007ff1c5176c52: mov r10d,DWORD PTR [rcx+0xc] > > There are no comments at all, just raw disassembly. > > This patch restores the status quo ante: > > # {method} {0x00007f9f53c2e3c0} 'decodeModuleName' '(ILjava/lang/String;)Ljava/lang/String;' in 'jdk/internal/module/ModuleInfo$ConstantPool' > # this: rsi:rsi = 'jdk/internal/module/ModuleInfo$ConstantPool' > # parm0: rdx = int > # parm1: rcx:rcx = 'java/lang/String' > # [sp+0x40] (sp of caller) > ;; N551: # out( B1 ) <- BLOCK HEAD IS JUNK Freq: 1 > 0x00007f9fb4d64620: mov r10d,DWORD PTR [rsi+0x8] > 0x00007f9fb4d64624: movabs r12,0x800000000 > 0x00007f9fb4d6462e: add r10,r12 > 0x00007f9fb4d64631: xor r12,r12 > 0x00007f9fb4d64634: cmp rax,r10 > 0x00007f9fb4d64637: jne 0x00007f9fb4cfeda0 ; {runtime_call ic_miss_stub} > 0x00007f9fb4d6463d: nop > 0x00007f9fb4d6463e: nop > 0x00007f9fb4d6463f: nop > [Verified Entry Point] > ;; B1: # out( B55 B2 ) <- BLOCK HEAD IS JUNK Freq: 1 > 0x00007f9fb4d64640: mov DWORD PTR [rsp-0x16000],eax > 0x00007f9fb4d64647: push rbp > 0x00007f9fb4d64648: sub rsp,0x30 ;*synchronization entry > ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at -1 (line 876) > 0x00007f9fb4d6464c: mov r11,rsi > 0x00007f9fb4d6464f: mov r9,rcx > 0x00007f9fb4d64652: mov r10d,DWORD PTR [rcx+0xc] ;*getfield value {reexecute=0 rethrow=0 return_oop=0} > ; - java.lang.String::length at 1 (line 673) > ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at 1 (line 876) > ; implicit exception: dispatches to 0x00007f9fb4d648fe > ;; B2: # out( B56 B3 ) <- in( B1 ) Freq: 0.999999 > From lois.foltan at oracle.com Thu Jun 6 17:32:52 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 6 Jun 2019 13:32:52 -0400 Subject: RFR (S) 8224151: Test vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java might hang with release binaries In-Reply-To: <7060291e-67a2-97d0-c3cc-40df304bfc9d@oracle.com> References: <7060291e-67a2-97d0-c3cc-40df304bfc9d@oracle.com> Message-ID: <6b8aee51-a8c7-2cd5-4527-ce6e3dca78f3@oracle.com> Looks good. Lois On 6/5/2019 9:53 PM, coleen.phillimore at oracle.com wrote: > Summary: Fix deadlock on ClassLoaderDataGraph_lock and g1 > clear_claimed_marks. > > Thank you to Stefan for finding the deadlock and Thomas for > suggestions on the fix, plus text for comments. > > Tested with this test 100s of times, tier1-3 and tier6 almost complete. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8224151.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8224151 > > Thanks, > Coleen From coleen.phillimore at oracle.com Thu Jun 6 17:36:35 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 6 Jun 2019 13:36:35 -0400 Subject: RFR (S) 8224151: Test vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java might hang with release binaries In-Reply-To: <6b8aee51-a8c7-2cd5-4527-ce6e3dca78f3@oracle.com> References: <7060291e-67a2-97d0-c3cc-40df304bfc9d@oracle.com> <6b8aee51-a8c7-2cd5-4527-ce6e3dca78f3@oracle.com> Message-ID: <72160cca-868b-04eb-e420-3132cd1b5203@oracle.com> Thanks Lois! Coleen On 6/6/19 1:32 PM, Lois Foltan wrote: > Looks good. > Lois > > On 6/5/2019 9:53 PM, coleen.phillimore at oracle.com wrote: >> Summary: Fix deadlock on ClassLoaderDataGraph_lock and g1 >> clear_claimed_marks. >> >> Thank you to Stefan for finding the deadlock and Thomas for >> suggestions on the fix, plus text for comments. >> >> Tested with this test 100s of times, tier1-3 and tier6 almost complete. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8224151.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8224151 >> >> Thanks, >> Coleen > From erik.osterlund at oracle.com Thu Jun 6 17:56:17 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 6 Jun 2019 19:56:17 +0200 Subject: RFR (S) 8224151: Test vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java might hang with release binaries In-Reply-To: <7060291e-67a2-97d0-c3cc-40df304bfc9d@oracle.com> References: <7060291e-67a2-97d0-c3cc-40df304bfc9d@oracle.com> Message-ID: <5676e591-6583-00b2-78ed-09bc77228234@oracle.com> Hi Coleen, Could you please add Atomic::load() on the CLD::next getter used by the iterator? No need for new webrev. Should remove the lock on the reader side in the future by making the unloading list use a different next pointer. Then the reader side locking won't really do anything for us. Thanks, /Erik On 2019-06-06 03:53, coleen.phillimore at oracle.com wrote: > Summary: Fix deadlock on ClassLoaderDataGraph_lock and g1 > clear_claimed_marks. > > Thank you to Stefan for finding the deadlock and Thomas for suggestions > on the fix, plus text for comments. > > Tested with this test 100s of times, tier1-3 and tier6 almost complete. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8224151.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8224151 > > Thanks, > Coleen From tom.rodriguez at oracle.com Thu Jun 6 17:56:46 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 6 Jun 2019 10:56:46 -0700 Subject: RFR: 8225429: Regression in disassembly quality In-Reply-To: <60b89a4f-655c-d5f8-7d6b-9532c865bba7@redhat.com> References: <60b89a4f-655c-d5f8-7d6b-9532c865bba7@redhat.com> Message-ID: I didn't see the original review for the disassembly change but even in product you used to get most of this information. Assembler comment capturing is a non-product feature unfortunately, so those were never available. Was it intentional to turn all this output off in product? I'd rather see it restored even in product myself. I had made some fixes to the alignment logic that I was planning to send out for review. The whole calculate_alignment logic seems broken to me. It's only called when it matches the addr event, but there's already an addr check above this call so it's unreachable. My changes are at http://cr.openjdk.java.net/~never/printnm/webrev if you would want to incorporate parts of it. I also fixed a problem where the block comment prefix lost a single space, which doesn't show up properly in the webrev. I changed the calculate_alignment so that there's at most a 8 chars between the disassembly and the comment. tom Andrew Haley wrote on 6/6/19 8:19 AM: > In a debug build, if you printed a disassembled method, you used to > get a lot of information about a method. Now, you just get raw > disassembly. This patch restores the status quo ante, > > http://cr.openjdk.java.net/~aph/8225429-1/ > > There are other bugs in the new disassembly output: in particular > options processing seems to be very broken. However, this patch is > enough to get things going again, so at least we can get some work > done. > > Before: > > # {method} {0x00007f2f64833660} 'decodeModuleName' '(ILjava/lang/String;)Ljava/lang/String;' in 'jdk/internal/module/ModuleInfo$ConstantPool' > # this: rsi:rsi = 'jdk/internal/module/ModuleInfo$ConstantPool' > # parm0: rdx = int > # parm1: rcx:rcx = 'java/lang/String' > # [sp+0x40] (sp of caller) > ;; N542: # B1 <- BLOCK HEAD IS JUNK Freq: 1 > > 0x00007f2fb1168440: mov r10d,DWORD PTR [rsi+0x8] > 0x00007f2fb1168444: movabs r12,0x800000000 > 0x00007f2fb116844e: add r10,r12 > 0x00007f2fb1168451: xor r12,r12 > 0x00007f2fb1168454: cmp rax,r10 > 0x00007f2fb1168457: jne 0x00007f2fb104d6a0 ; {runtime_call ic_miss_stub} > 0x00007f2fb116845d: nop > 0x00007f2fb116845e: nop > 0x00007f2fb116845f: nop > [Verified Entry Point] > ;; B1: # B54 B2 <- BLOCK HEAD IS JUNK Freq: 1 > > 0x00007f2fb1168460: mov DWORD PTR [rsp-0x16000],eax > 0x00007f2fb1168467: push rbp > 0x00007f2fb1168468: sub rsp,0x30 ;*synchronization entry > ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at -1 (line 877) > > 0x00007f2fb116846c: mov r10,rsi > 0x00007f2fb116846f: mov r9,rcx > 0x00007f2fb1168472: mov edi,DWORD PTR [rcx+0xc] ;*getfield value {reexecute=0 rethrow=0 return_oop=0} > ; - java.lang.String::length at 1 (line 658) > ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at 1 (line 877) > ; implicit exception: dispatches to 0x00007f2fb116872a > ;; B2: # B55 B3 <- B1 Freq: 0.999999 > > Now you only get this, even in a debug build: > > 0x00007ff1c5176c20: mov r10d,DWORD PTR [rsi+0x8] > 0x00007ff1c5176c24: movabs r12,0x800000000 > 0x00007ff1c5176c2e: add r10,r12 > 0x00007ff1c5176c31: xor r12,r12 > 0x00007ff1c5176c34: cmp rax,r10 > 0x00007ff1c5176c37: jne 0x00007ff1c5113da0 > 0x00007ff1c5176c3d: nop > 0x00007ff1c5176c3e: nop > 0x00007ff1c5176c3f: nop > 0x00007ff1c5176c40: mov DWORD PTR [rsp-0x16000],eax > 0x00007ff1c5176c47: push rbp > 0x00007ff1c5176c48: sub rsp,0x30 > 0x00007ff1c5176c4c: mov r11,rsi > 0x00007ff1c5176c4f: mov r9,rcx > 0x00007ff1c5176c52: mov r10d,DWORD PTR [rcx+0xc] > > There are no comments at all, just raw disassembly. > > This patch restores the status quo ante: > > # {method} {0x00007f9f53c2e3c0} 'decodeModuleName' '(ILjava/lang/String;)Ljava/lang/String;' in 'jdk/internal/module/ModuleInfo$ConstantPool' > # this: rsi:rsi = 'jdk/internal/module/ModuleInfo$ConstantPool' > # parm0: rdx = int > # parm1: rcx:rcx = 'java/lang/String' > # [sp+0x40] (sp of caller) > ;; N551: # out( B1 ) <- BLOCK HEAD IS JUNK Freq: 1 > 0x00007f9fb4d64620: mov r10d,DWORD PTR [rsi+0x8] > 0x00007f9fb4d64624: movabs r12,0x800000000 > 0x00007f9fb4d6462e: add r10,r12 > 0x00007f9fb4d64631: xor r12,r12 > 0x00007f9fb4d64634: cmp rax,r10 > 0x00007f9fb4d64637: jne 0x00007f9fb4cfeda0 ; {runtime_call ic_miss_stub} > 0x00007f9fb4d6463d: nop > 0x00007f9fb4d6463e: nop > 0x00007f9fb4d6463f: nop > [Verified Entry Point] > ;; B1: # out( B55 B2 ) <- BLOCK HEAD IS JUNK Freq: 1 > 0x00007f9fb4d64640: mov DWORD PTR [rsp-0x16000],eax > 0x00007f9fb4d64647: push rbp > 0x00007f9fb4d64648: sub rsp,0x30 ;*synchronization entry > ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at -1 (line 876) > 0x00007f9fb4d6464c: mov r11,rsi > 0x00007f9fb4d6464f: mov r9,rcx > 0x00007f9fb4d64652: mov r10d,DWORD PTR [rcx+0xc] ;*getfield value {reexecute=0 rethrow=0 return_oop=0} > ; - java.lang.String::length at 1 (line 673) > ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at 1 (line 876) > ; implicit exception: dispatches to 0x00007f9fb4d648fe > ;; B2: # out( B56 B3 ) <- in( B1 ) Freq: 0.999999 > From coleen.phillimore at oracle.com Thu Jun 6 18:01:14 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 6 Jun 2019 14:01:14 -0400 Subject: RFR (S) 8224151: Test vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java might hang with release binaries In-Reply-To: <5676e591-6583-00b2-78ed-09bc77228234@oracle.com> References: <7060291e-67a2-97d0-c3cc-40df304bfc9d@oracle.com> <5676e591-6583-00b2-78ed-09bc77228234@oracle.com> Message-ID: <1dc554b7-798b-d1c7-3d8b-701168513708@oracle.com> On 6/6/19 1:56 PM, Erik ?sterlund wrote: > Hi Coleen, > > Could you please add Atomic::load() on the CLD::next getter used by > the iterator? No need for new webrev. Should remove the lock on the > reader side in the future by making the unloading list use a different > next pointer. Then the reader side locking won't really do anything > for us. Okay, I'll do it but there are more places we'd have to fix to make all the readers lock free.? To be continued ... Thanks! Coleen > > Thanks, > /Erik > > On 2019-06-06 03:53, coleen.phillimore at oracle.com wrote: >> Summary: Fix deadlock on ClassLoaderDataGraph_lock and g1 >> clear_claimed_marks. >> >> Thank you to Stefan for finding the deadlock and Thomas for >> suggestions on the fix, plus text for comments. >> >> Tested with this test 100s of times, tier1-3 and tier6 almost complete. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8224151.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8224151 >> >> Thanks, >> Coleen From shade at redhat.com Thu Jun 6 18:55:10 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 6 Jun 2019 20:55:10 +0200 Subject: RFR: 8225429: Regression in disassembly quality In-Reply-To: References: <60b89a4f-655c-d5f8-7d6b-9532c865bba7@redhat.com> Message-ID: <4c02327a-b41f-8831-6aa3-86486da1e543@redhat.com> On 6/6/19 7:56 PM, Tom Rodriguez wrote: > I didn't see the original review for the disassembly change but even in product you used to get most > of this information.? Assembler comment capturing is a non-product feature unfortunately, so those > were never available.? Was it intentional to turn all this output off in product? I'd rather see it > restored even in product myself. +1. I want comments in product disassembly as well. Many (including me) do generated code studies on product builds. Thanks, -Aleksey From john.r.rose at oracle.com Thu Jun 6 20:22:56 2019 From: john.r.rose at oracle.com (John Rose) Date: Thu, 6 Jun 2019 13:22:56 -0700 Subject: RFR: 8225429: Regression in disassembly quality In-Reply-To: References: <60b89a4f-655c-d5f8-7d6b-9532c865bba7@redhat.com> Message-ID: On Jun 6, 2019, at 10:56 AM, Tom Rodriguez wrote: > > I didn't see the original review for the disassembly change but even in product you used to get most of this information. Assembler comment capturing is a non-product feature unfortunately, so those were never available. Was it intentional to turn all this output off in product? I'd rather see it restored even in product myself. Effective diagnosis and performance tuning requires accurate, informative disassembly. I would support moving the assembler comment capture, whenever disassembly is enabled. If there's a risk of disturbing program dynamics with the extra footprint, perhaps it could be broken out as a separate diagnostic option. More disassembly information is better, even in product mode! ? John From john.r.rose at oracle.com Thu Jun 6 20:28:06 2019 From: john.r.rose at oracle.com (John Rose) Date: Thu, 6 Jun 2019 13:28:06 -0700 Subject: RFR: 8225429: Regression in disassembly quality In-Reply-To: References: <60b89a4f-655c-d5f8-7d6b-9532c865bba7@redhat.com> Message-ID: <034C8084-4303-4594-BC64-BADF0A591CDA@oracle.com> On Jun 6, 2019, at 1:22 PM, John Rose wrote: > > I would support moving the assembler > comment capture, whenever disassembly is enabled. s/moving/enabling/ ?was incomplete edit of "moving from debug to product" :-) From david.holmes at oracle.com Thu Jun 6 22:51:10 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 7 Jun 2019 08:51:10 +1000 Subject: [13] RFR(S) 8222371: Use UL for TraceNMethodInstalls code In-Reply-To: <41cfc3f2-b004-74d4-c922-b6a92c9e4887@oracle.com> References: <41cfc3f2-b004-74d4-c922-b6a92c9e4887@oracle.com> Message-ID: <2f9a962d-2422-83ee-8a1e-8d110542d3be@oracle.com> On 7/06/2019 2:58 am, Vladimir Kozlov wrote: > Thank you, David > > Yes, I will file RFE to deprecate it after these changes are pushed. But > I most likely will not hit JDK 13 cut off. This change will automatically deprecate it. You'll need the RFE to Obsolete it. > I forgot do we need CSR for diagnostic flags? I think we do but you I > specialist in that so I am asking ;) No CSR request required for diagnostic or experimental product flags. [1] Cheers, David [1] https://wiki.openjdk.java.net/display/csr/CSR+FAQs > Thanks, > Vladimir > > On 6/5/19 7:00 PM, David Holmes wrote: >> Hi Vladimir, >> >> This looks good to me. >> >> This implicitly makes TraceNMethodInstalls deprecated. Is there a plan >> to actually remove it later? >> >> Thanks, >> David >> >> On 6/06/2019 9:58 am, Vladimir Kozlov wrote: >>> https://cr.openjdk.java.net/~kvn/8222371/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8222371 >>> >>> Replace -XX:+TraceNMethodInstalls with -Xlog:nmethod+install. >>> >>> Thanks, >>> Vladimir From vladimir.kozlov at oracle.com Thu Jun 6 23:12:59 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 6 Jun 2019 16:12:59 -0700 Subject: [13] RFR(S) 8222371: Use UL for TraceNMethodInstalls code In-Reply-To: <2f9a962d-2422-83ee-8a1e-8d110542d3be@oracle.com> References: <41cfc3f2-b004-74d4-c922-b6a92c9e4887@oracle.com> <2f9a962d-2422-83ee-8a1e-8d110542d3be@oracle.com> Message-ID: <5b210971-7e01-12df-1d03-d89871fe683a@oracle.com> Thank you, David On 6/6/19 3:51 PM, David Holmes wrote: > On 7/06/2019 2:58 am, Vladimir Kozlov wrote: >> Thank you, David >> >> Yes, I will file RFE to deprecate it after these changes are pushed. But I most likely will not hit JDK 13 cut off. > > This change will automatically deprecate it. You'll need the RFE to Obsolete it. Nice! Filed RFE [2] to Obsolete it. >> I forgot do we need CSR for diagnostic flags? I think we do but you I specialist in that so I am asking ;) > > No CSR request required for diagnostic or experimental product flags. [1] Bookmarked and recorded. Thanks, Vladimir [2] https://bugs.openjdk.java.net/browse/JDK-8225464 > Cheers, > David > > [1] https://wiki.openjdk.java.net/display/csr/CSR+FAQs >> Thanks, >> Vladimir >> >> On 6/5/19 7:00 PM, David Holmes wrote: >>> Hi Vladimir, >>> >>> This looks good to me. >>> >>> This implicitly makes TraceNMethodInstalls deprecated. Is there a plan to actually remove it later? >>> >>> Thanks, >>> David >>> >>> On 6/06/2019 9:58 am, Vladimir Kozlov wrote: >>>> https://cr.openjdk.java.net/~kvn/8222371/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8222371 >>>> >>>> Replace -XX:+TraceNMethodInstalls with -Xlog:nmethod+install. >>>> >>>> Thanks, >>>> Vladimir From david.holmes at oracle.com Thu Jun 6 23:16:50 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 7 Jun 2019 09:16:50 +1000 Subject: RFR: 8225429: Regression in disassembly quality In-Reply-To: <60b89a4f-655c-d5f8-7d6b-9532c865bba7@redhat.com> References: <60b89a4f-655c-d5f8-7d6b-9532c865bba7@redhat.com> Message-ID: <7787f064-babf-ca06-2d38-d795ec36a763@oracle.com> Hi Andrew, On 7/06/2019 1:19 am, Andrew Haley wrote: > In a debug build, if you printed a disassembled method, you used to > get a lot of information about a method. Now, you just get raw > disassembly. This patch restores the status quo ante, > > http://cr.openjdk.java.net/~aph/8225429-1/ src/hotspot/share/asm/codeBuffer.hpp _collect_comments = ( PrintAssembly || PrintStubCode || PrintMethodHandleStubs || PrintInterpreter || PrintSignatureHandlers + || UnlockDiagnosticVMOptions ); Would it be better to explicitly enable this in debug, using trueInDebug, versus using an otherwise unrelated flag that happens to be "true in debug"? Or is there also some reason to turn this on in product when UnlockDiagnosticVMOptions is used? Thanks, David > There are other bugs in the new disassembly output: in particular > options processing seems to be very broken. However, this patch is > enough to get things going again, so at least we can get some work > done. > > Before: > > # {method} {0x00007f2f64833660} 'decodeModuleName' '(ILjava/lang/String;)Ljava/lang/String;' in 'jdk/internal/module/ModuleInfo$ConstantPool' > # this: rsi:rsi = 'jdk/internal/module/ModuleInfo$ConstantPool' > # parm0: rdx = int > # parm1: rcx:rcx = 'java/lang/String' > # [sp+0x40] (sp of caller) > ;; N542: # B1 <- BLOCK HEAD IS JUNK Freq: 1 > > 0x00007f2fb1168440: mov r10d,DWORD PTR [rsi+0x8] > 0x00007f2fb1168444: movabs r12,0x800000000 > 0x00007f2fb116844e: add r10,r12 > 0x00007f2fb1168451: xor r12,r12 > 0x00007f2fb1168454: cmp rax,r10 > 0x00007f2fb1168457: jne 0x00007f2fb104d6a0 ; {runtime_call ic_miss_stub} > 0x00007f2fb116845d: nop > 0x00007f2fb116845e: nop > 0x00007f2fb116845f: nop > [Verified Entry Point] > ;; B1: # B54 B2 <- BLOCK HEAD IS JUNK Freq: 1 > > 0x00007f2fb1168460: mov DWORD PTR [rsp-0x16000],eax > 0x00007f2fb1168467: push rbp > 0x00007f2fb1168468: sub rsp,0x30 ;*synchronization entry > ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at -1 (line 877) > > 0x00007f2fb116846c: mov r10,rsi > 0x00007f2fb116846f: mov r9,rcx > 0x00007f2fb1168472: mov edi,DWORD PTR [rcx+0xc] ;*getfield value {reexecute=0 rethrow=0 return_oop=0} > ; - java.lang.String::length at 1 (line 658) > ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at 1 (line 877) > ; implicit exception: dispatches to 0x00007f2fb116872a > ;; B2: # B55 B3 <- B1 Freq: 0.999999 > > Now you only get this, even in a debug build: > > 0x00007ff1c5176c20: mov r10d,DWORD PTR [rsi+0x8] > 0x00007ff1c5176c24: movabs r12,0x800000000 > 0x00007ff1c5176c2e: add r10,r12 > 0x00007ff1c5176c31: xor r12,r12 > 0x00007ff1c5176c34: cmp rax,r10 > 0x00007ff1c5176c37: jne 0x00007ff1c5113da0 > 0x00007ff1c5176c3d: nop > 0x00007ff1c5176c3e: nop > 0x00007ff1c5176c3f: nop > 0x00007ff1c5176c40: mov DWORD PTR [rsp-0x16000],eax > 0x00007ff1c5176c47: push rbp > 0x00007ff1c5176c48: sub rsp,0x30 > 0x00007ff1c5176c4c: mov r11,rsi > 0x00007ff1c5176c4f: mov r9,rcx > 0x00007ff1c5176c52: mov r10d,DWORD PTR [rcx+0xc] > > There are no comments at all, just raw disassembly. > > This patch restores the status quo ante: > > # {method} {0x00007f9f53c2e3c0} 'decodeModuleName' '(ILjava/lang/String;)Ljava/lang/String;' in 'jdk/internal/module/ModuleInfo$ConstantPool' > # this: rsi:rsi = 'jdk/internal/module/ModuleInfo$ConstantPool' > # parm0: rdx = int > # parm1: rcx:rcx = 'java/lang/String' > # [sp+0x40] (sp of caller) > ;; N551: # out( B1 ) <- BLOCK HEAD IS JUNK Freq: 1 > 0x00007f9fb4d64620: mov r10d,DWORD PTR [rsi+0x8] > 0x00007f9fb4d64624: movabs r12,0x800000000 > 0x00007f9fb4d6462e: add r10,r12 > 0x00007f9fb4d64631: xor r12,r12 > 0x00007f9fb4d64634: cmp rax,r10 > 0x00007f9fb4d64637: jne 0x00007f9fb4cfeda0 ; {runtime_call ic_miss_stub} > 0x00007f9fb4d6463d: nop > 0x00007f9fb4d6463e: nop > 0x00007f9fb4d6463f: nop > [Verified Entry Point] > ;; B1: # out( B55 B2 ) <- BLOCK HEAD IS JUNK Freq: 1 > 0x00007f9fb4d64640: mov DWORD PTR [rsp-0x16000],eax > 0x00007f9fb4d64647: push rbp > 0x00007f9fb4d64648: sub rsp,0x30 ;*synchronization entry > ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at -1 (line 876) > 0x00007f9fb4d6464c: mov r11,rsi > 0x00007f9fb4d6464f: mov r9,rcx > 0x00007f9fb4d64652: mov r10d,DWORD PTR [rcx+0xc] ;*getfield value {reexecute=0 rethrow=0 return_oop=0} > ; - java.lang.String::length at 1 (line 673) > ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at 1 (line 876) > ; implicit exception: dispatches to 0x00007f9fb4d648fe > ;; B2: # out( B56 B3 ) <- in( B1 ) Freq: 0.999999 > From igor.ignatyev at oracle.com Fri Jun 7 06:03:29 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 6 Jun 2019 23:03:29 -0700 Subject: RFR(T) : 8225469 : clean up problem lists Message-ID: http://cr.openjdk.java.net/~iignatyev//8225469/webrev.00/index.html > 4 lines changed: 0 ins; 4 del; 0 mod; Hi all, could you please review this trivial patch which cleans up graal-specific problem lists? webrev: http://cr.openjdk.java.net/~iignatyev//8225469/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8225469 testing: unproblem-listed tests w/ graal as JIT (hs-tier4-graal) Thanks, -- Igor From vladimir.kozlov at oracle.com Fri Jun 7 06:05:53 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 6 Jun 2019 23:05:53 -0700 Subject: RFR(T) : 8225469 : clean up problem lists In-Reply-To: References: Message-ID: Good. Thanks, Vladimir On 6/6/19 11:03 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8225469/webrev.00/index.html >> 4 lines changed: 0 ins; 4 del; 0 mod; > > Hi all, > > could you please review this trivial patch which cleans up graal-specific problem lists? > > webrev: http://cr.openjdk.java.net/~iignatyev//8225469/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8225469 > testing: unproblem-listed tests w/ graal as JIT (hs-tier4-graal) > > Thanks, > -- Igor > From igor.ignatyev at oracle.com Fri Jun 7 06:10:16 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 6 Jun 2019 23:10:16 -0700 Subject: RFR(T) : 8225469 : clean up problem lists In-Reply-To: References: Message-ID: <18CB1865-4A28-4078-8604-BF4858A0B0EC@oracle.com> Thanks Vladimir! pushed. -- Igor > On Jun 6, 2019, at 11:05 PM, Vladimir Kozlov wrote: > > Good. > > Thanks, > Vladimir > > On 6/6/19 11:03 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8225469/webrev.00/index.html >>> 4 lines changed: 0 ins; 4 del; 0 mod; >> Hi all, >> could you please review this trivial patch which cleans up graal-specific problem lists? >> webrev: http://cr.openjdk.java.net/~iignatyev//8225469/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8225469 >> testing: unproblem-listed tests w/ graal as JIT (hs-tier4-graal) >> Thanks, >> -- Igor From lutz.schmidt at sap.com Fri Jun 7 07:56:36 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 7 Jun 2019 07:56:36 +0000 Subject: 8225429: Regression in disassembly quality Message-ID: <8818B65C-E697-462F-870F-DFBE3F62A58D@sap.com> To all with emotions on PrintAssembly output! I'm actually happy that there is some discussion now on how much information should be printed when. I had sent out a request for comments before I actually started working on this task. Back then, it was around Nov/Dec 2018, I got "bashed" because the sample output I showed seemed bloated and way to verbose for some. As a result of those comments, I introduced all the switches and #defines to make the output configurable in a wide range. The default settings were selected such that only minimal output is generated. I knew that would not satisfy everybody. I am pretty much with Jon Rose: when you run into a problem and print a disassembly, print as much information as you have. You may not have a second chance. In essence, I'm happy with any default setting you may find most helpful. If there is anything I can do to help (fixing bugs, enhancing functionality), let me know. Thanks, Lutz ?On 07.06.19, 01:16, "hotspot-dev on behalf of David Holmes" wrote: Hi Andrew, On 7/06/2019 1:19 am, Andrew Haley wrote: > In a debug build, if you printed a disassembled method, you used to > get a lot of information about a method. Now, you just get raw > disassembly. This patch restores the status quo ante, > > http://cr.openjdk.java.net/~aph/8225429-1/ src/hotspot/share/asm/codeBuffer.hpp _collect_comments = ( PrintAssembly || PrintStubCode || PrintMethodHandleStubs || PrintInterpreter || PrintSignatureHandlers + || UnlockDiagnosticVMOptions ); Would it be better to explicitly enable this in debug, using trueInDebug, versus using an otherwise unrelated flag that happens to be "true in debug"? Or is there also some reason to turn this on in product when UnlockDiagnosticVMOptions is used? Thanks, David > There are other bugs in the new disassembly output: in particular > options processing seems to be very broken. However, this patch is > enough to get things going again, so at least we can get some work > done. > > Before: > > # {method} {0x00007f2f64833660} 'decodeModuleName' '(ILjava/lang/String;)Ljava/lang/String;' in 'jdk/internal/module/ModuleInfo$ConstantPool' > # this: rsi:rsi = 'jdk/internal/module/ModuleInfo$ConstantPool' > # parm0: rdx = int > # parm1: rcx:rcx = 'java/lang/String' > # [sp+0x40] (sp of caller) > ;; N542: # B1 <- BLOCK HEAD IS JUNK Freq: 1 > > 0x00007f2fb1168440: mov r10d,DWORD PTR [rsi+0x8] > 0x00007f2fb1168444: movabs r12,0x800000000 > 0x00007f2fb116844e: add r10,r12 > 0x00007f2fb1168451: xor r12,r12 > 0x00007f2fb1168454: cmp rax,r10 > 0x00007f2fb1168457: jne 0x00007f2fb104d6a0 ; {runtime_call ic_miss_stub} > 0x00007f2fb116845d: nop > 0x00007f2fb116845e: nop > 0x00007f2fb116845f: nop > [Verified Entry Point] > ;; B1: # B54 B2 <- BLOCK HEAD IS JUNK Freq: 1 > > 0x00007f2fb1168460: mov DWORD PTR [rsp-0x16000],eax > 0x00007f2fb1168467: push rbp > 0x00007f2fb1168468: sub rsp,0x30 ;*synchronization entry > ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at -1 (line 877) > > 0x00007f2fb116846c: mov r10,rsi > 0x00007f2fb116846f: mov r9,rcx > 0x00007f2fb1168472: mov edi,DWORD PTR [rcx+0xc] ;*getfield value {reexecute=0 rethrow=0 return_oop=0} > ; - java.lang.String::length at 1 (line 658) > ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at 1 (line 877) > ; implicit exception: dispatches to 0x00007f2fb116872a > ;; B2: # B55 B3 <- B1 Freq: 0.999999 > > Now you only get this, even in a debug build: > > 0x00007ff1c5176c20: mov r10d,DWORD PTR [rsi+0x8] > 0x00007ff1c5176c24: movabs r12,0x800000000 > 0x00007ff1c5176c2e: add r10,r12 > 0x00007ff1c5176c31: xor r12,r12 > 0x00007ff1c5176c34: cmp rax,r10 > 0x00007ff1c5176c37: jne 0x00007ff1c5113da0 > 0x00007ff1c5176c3d: nop > 0x00007ff1c5176c3e: nop > 0x00007ff1c5176c3f: nop > 0x00007ff1c5176c40: mov DWORD PTR [rsp-0x16000],eax > 0x00007ff1c5176c47: push rbp > 0x00007ff1c5176c48: sub rsp,0x30 > 0x00007ff1c5176c4c: mov r11,rsi > 0x00007ff1c5176c4f: mov r9,rcx > 0x00007ff1c5176c52: mov r10d,DWORD PTR [rcx+0xc] > > There are no comments at all, just raw disassembly. > > This patch restores the status quo ante: > > # {method} {0x00007f9f53c2e3c0} 'decodeModuleName' '(ILjava/lang/String;)Ljava/lang/String;' in 'jdk/internal/module/ModuleInfo$ConstantPool' > # this: rsi:rsi = 'jdk/internal/module/ModuleInfo$ConstantPool' > # parm0: rdx = int > # parm1: rcx:rcx = 'java/lang/String' > # [sp+0x40] (sp of caller) > ;; N551: # out( B1 ) <- BLOCK HEAD IS JUNK Freq: 1 > 0x00007f9fb4d64620: mov r10d,DWORD PTR [rsi+0x8] > 0x00007f9fb4d64624: movabs r12,0x800000000 > 0x00007f9fb4d6462e: add r10,r12 > 0x00007f9fb4d64631: xor r12,r12 > 0x00007f9fb4d64634: cmp rax,r10 > 0x00007f9fb4d64637: jne 0x00007f9fb4cfeda0 ; {runtime_call ic_miss_stub} > 0x00007f9fb4d6463d: nop > 0x00007f9fb4d6463e: nop > 0x00007f9fb4d6463f: nop > [Verified Entry Point] > ;; B1: # out( B55 B2 ) <- BLOCK HEAD IS JUNK Freq: 1 > 0x00007f9fb4d64640: mov DWORD PTR [rsp-0x16000],eax > 0x00007f9fb4d64647: push rbp > 0x00007f9fb4d64648: sub rsp,0x30 ;*synchronization entry > ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at -1 (line 876) > 0x00007f9fb4d6464c: mov r11,rsi > 0x00007f9fb4d6464f: mov r9,rcx > 0x00007f9fb4d64652: mov r10d,DWORD PTR [rcx+0xc] ;*getfield value {reexecute=0 rethrow=0 return_oop=0} > ; - java.lang.String::length at 1 (line 673) > ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at 1 (line 876) > ; implicit exception: dispatches to 0x00007f9fb4d648fe > ;; B2: # out( B56 B3 ) <- in( B1 ) Freq: 0.999999 > From aph at redhat.com Fri Jun 7 08:16:27 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 7 Jun 2019 09:16:27 +0100 Subject: RFR: 8225429: Regression in disassembly quality In-Reply-To: <7787f064-babf-ca06-2d38-d795ec36a763@oracle.com> References: <60b89a4f-655c-d5f8-7d6b-9532c865bba7@redhat.com> <7787f064-babf-ca06-2d38-d795ec36a763@oracle.com> Message-ID: <92fb78ea-5907-e547-2f1b-2ec11c5855a1@redhat.com> Hi, On 6/7/19 12:16 AM, David Holmes wrote: > On 7/06/2019 1:19 am, Andrew Haley wrote: >> In a debug build, if you printed a disassembled method, you used to >> get a lot of information about a method. Now, you just get raw >> disassembly. This patch restores the status quo ante, >> >> http://cr.openjdk.java.net/~aph/8225429-1/ > > src/hotspot/share/asm/codeBuffer.hpp > > _collect_comments = ( PrintAssembly > || PrintStubCode > || PrintMethodHandleStubs > || PrintInterpreter > || PrintSignatureHandlers > + || UnlockDiagnosticVMOptions > ); > > Would it be better to explicitly enable this in debug, using > trueInDebug, versus using an otherwise unrelated flag that happens to be > "true in debug"? Or is there also some reason to turn this on in product > when UnlockDiagnosticVMOptions is used? Exactly. If we can get comments enabled in product builds this will just work. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Jun 7 08:18:04 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 7 Jun 2019 09:18:04 +0100 Subject: RFR: 8225429: Regression in disassembly quality In-Reply-To: References: <60b89a4f-655c-d5f8-7d6b-9532c865bba7@redhat.com> Message-ID: <7ae9dcac-e7d9-5989-1ae7-3743c9775dc9@redhat.com> On 6/6/19 9:22 PM, John Rose wrote: > On Jun 6, 2019, at 10:56 AM, Tom Rodriguez wrote: > > Effective diagnosis and performance tuning requires accurate, > informative disassembly. I would support moving the assembler > comment capture, whenever disassembly is enabled. If there's > a risk of disturbing program dynamics with the extra footprint, > perhaps it could be broken out as a separate diagnostic option. > > More disassembly information is better, even in product mode! OK. I can do that later, but I'd like this patch (which fixes the regression) in now. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From cnewland at chrisnewland.com Fri Jun 7 08:41:55 2019 From: cnewland at chrisnewland.com (Chris Newland) Date: Fri, 7 Jun 2019 09:41:55 +0100 Subject: 8225429: Regression in disassembly quality In-Reply-To: <8818B65C-E697-462F-870F-DFBE3F62A58D@sap.com> References: <8818B65C-E697-462F-870F-DFBE3F62A58D@sap.com> Message-ID: <21f684a7cee3f523354e738bbc353884.squirrel@excalibur.xssl.net> Hi all, Just a note that JITWatch is aimed at product VM users and expects the old (full) PrintAssembly output. If that's changing I can work around it but just thought I'd mention it. Kind regards, Chris On Fri, June 7, 2019 08:56, Schmidt, Lutz wrote: > To all with emotions on PrintAssembly output! > > > I'm actually happy that there is some discussion now on how much > information should be printed when. > > I had sent out a request for comments before I actually started working > on this task. Back then, it was around Nov/Dec 2018, I got "bashed" > because the sample output I showed seemed bloated and way to verbose for > some. > > As a result of those comments, I introduced all the switches and #defines > to make the output configurable in a wide range. The default settings > were selected such that only minimal output is generated. I knew that > would not satisfy everybody. I am pretty much with Jon Rose: when you run > into a problem and print a disassembly, print as much information as you > have. You may not have a second chance. > > In essence, I'm happy with any default setting you may find most helpful. > If there is anything I can do to help (fixing bugs, enhancing > functionality), let me know. > > Thanks, > Lutz > > > > ?On 07.06.19, 01:16, "hotspot-dev on behalf of David Holmes" > david.holmes at oracle.com> wrote: > > Hi Andrew, > > > On 7/06/2019 1:19 am, Andrew Haley wrote: > >> In a debug build, if you printed a disassembled method, you used to >> get a lot of information about a method. Now, you just get raw >> disassembly. This patch restores the status quo ante, >> >> http://cr.openjdk.java.net/~aph/8225429-1/ >> > > src/hotspot/share/asm/codeBuffer.hpp > > _collect_comments = ( PrintAssembly > || PrintStubCode > || PrintMethodHandleStubs > || PrintInterpreter > || PrintSignatureHandlers > + || UnlockDiagnosticVMOptions > ); > > > Would it be better to explicitly enable this in debug, using > trueInDebug, versus using an otherwise unrelated flag that happens to be > "true in debug"? Or is there also some reason to turn this on in product > when UnlockDiagnosticVMOptions is used? > > Thanks, > David > > > >> There are other bugs in the new disassembly output: in particular >> options processing seems to be very broken. However, this patch is enough >> to get things going again, so at least we can get some work done. >> >> Before: >> >> >> # {method} {0x00007f2f64833660} 'decodeModuleName' >> '(ILjava/lang/String;)Ljava/lang/String;' in >> 'jdk/internal/module/ModuleInfo$ConstantPool' >> # this: rsi:rsi = 'jdk/internal/module/ModuleInfo$ConstantPool' >> # parm0: rdx = int >> # parm1: rcx:rcx = 'java/lang/String' >> # [sp+0x40] (sp of caller) >> ;; N542: # B1 <- BLOCK HEAD IS JUNK Freq: 1 >> >> >> 0x00007f2fb1168440: mov r10d,DWORD PTR [rsi+0x8] >> 0x00007f2fb1168444: movabs r12,0x800000000 >> 0x00007f2fb116844e: add r10,r12 >> 0x00007f2fb1168451: xor r12,r12 >> 0x00007f2fb1168454: cmp rax,r10 >> 0x00007f2fb1168457: jne 0x00007f2fb104d6a0 ; {runtime_call ic_miss_stub} >> 0x00007f2fb116845d: nop >> 0x00007f2fb116845e: nop >> 0x00007f2fb116845f: nop >> [Verified Entry Point] >> ;; B1: # B54 B2 <- BLOCK HEAD IS JUNK Freq: 1 >> >> >> 0x00007f2fb1168460: mov DWORD PTR [rsp-0x16000],eax >> 0x00007f2fb1168467: push rbp >> 0x00007f2fb1168468: sub rsp,0x30 ;*synchronization entry >> ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at -1 >> (line 877) >> >> >> 0x00007f2fb116846c: mov r10,rsi >> 0x00007f2fb116846f: mov r9,rcx >> 0x00007f2fb1168472: mov edi,DWORD PTR [rcx+0xc] ;*getfield value >> {reexecute=0 rethrow=0 return_oop=0} >> ; - java.lang.String::length at 1 (line 658) >> ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at 1 >> (line 877) >> ; implicit exception: dispatches to 0x00007f2fb116872a >> ;; B2: # B55 B3 <- B1 Freq: 0.999999 >> >> >> Now you only get this, even in a debug build: >> >> >> 0x00007ff1c5176c20: mov r10d,DWORD PTR [rsi+0x8] >> 0x00007ff1c5176c24: movabs r12,0x800000000 >> 0x00007ff1c5176c2e: add r10,r12 >> 0x00007ff1c5176c31: xor r12,r12 >> 0x00007ff1c5176c34: cmp rax,r10 >> 0x00007ff1c5176c37: jne 0x00007ff1c5113da0 >> 0x00007ff1c5176c3d: nop >> 0x00007ff1c5176c3e: nop >> 0x00007ff1c5176c3f: nop >> 0x00007ff1c5176c40: mov DWORD PTR [rsp-0x16000],eax >> 0x00007ff1c5176c47: push rbp >> 0x00007ff1c5176c48: sub rsp,0x30 >> 0x00007ff1c5176c4c: mov r11,rsi >> 0x00007ff1c5176c4f: mov r9,rcx >> 0x00007ff1c5176c52: mov r10d,DWORD PTR [rcx+0xc] >> >> >> There are no comments at all, just raw disassembly. >> >> >> This patch restores the status quo ante: >> >> >> # {method} {0x00007f9f53c2e3c0} 'decodeModuleName' >> '(ILjava/lang/String;)Ljava/lang/String;' in >> 'jdk/internal/module/ModuleInfo$ConstantPool' >> # this: rsi:rsi = 'jdk/internal/module/ModuleInfo$ConstantPool' >> # parm0: rdx = int >> # parm1: rcx:rcx = 'java/lang/String' >> # [sp+0x40] (sp of caller) >> ;; N551: # out( B1 ) <- BLOCK HEAD IS JUNK Freq: 1 >> 0x00007f9fb4d64620: mov r10d,DWORD PTR [rsi+0x8] >> 0x00007f9fb4d64624: movabs r12,0x800000000 >> 0x00007f9fb4d6462e: add r10,r12 >> 0x00007f9fb4d64631: xor r12,r12 >> 0x00007f9fb4d64634: cmp rax,r10 >> 0x00007f9fb4d64637: jne 0x00007f9fb4cfeda0 ; >> {runtime_call ic_miss_stub} >> 0x00007f9fb4d6463d: nop >> 0x00007f9fb4d6463e: nop >> 0x00007f9fb4d6463f: nop >> [Verified Entry Point] >> ;; B1: # out( B55 B2 ) <- BLOCK HEAD IS JUNK Freq: 1 >> 0x00007f9fb4d64640: mov DWORD PTR [rsp-0x16000],eax >> 0x00007f9fb4d64647: push rbp >> 0x00007f9fb4d64648: sub rsp,0x30 >> ;*synchronization entry >> ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at -1 >> (line 876) >> 0x00007f9fb4d6464c: mov r11,rsi >> 0x00007f9fb4d6464f: mov r9,rcx >> 0x00007f9fb4d64652: mov r10d,DWORD PTR [rcx+0xc] ;*getfield >> value {reexecute=0 rethrow=0 return_oop=0} ; - >> java.lang.String::length at 1 (line 673) >> ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at 1 >> (line 876) >> ; implicit exception: dispatches to 0x00007f9fb4d648fe >> ;; B2: # out( B56 B3 ) <- in( B1 ) Freq: 0.999999 >> >> > > > From aph at redhat.com Fri Jun 7 09:05:26 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 7 Jun 2019 10:05:26 +0100 Subject: RFR: 8225429: Regression in disassembly quality In-Reply-To: <92fb78ea-5907-e547-2f1b-2ec11c5855a1@redhat.com> References: <60b89a4f-655c-d5f8-7d6b-9532c865bba7@redhat.com> <7787f064-babf-ca06-2d38-d795ec36a763@oracle.com> <92fb78ea-5907-e547-2f1b-2ec11c5855a1@redhat.com> Message-ID: <138a0699-0cfd-5fc4-32e8-464575620490@redhat.com> On 6/7/19 9:16 AM, Andrew Haley wrote: >> Would it be better to explicitly enable this in debug, using >> trueInDebug, versus using an otherwise unrelated flag that happens to be >> "true in debug"? Or is there also some reason to turn this on in product >> when UnlockDiagnosticVMOptions is used? > Exactly. If we can get comments enabled in product builds this will > just work. And in addition, I don't think that UnlockDiagnosticVMOptions is an unrelated flag. But we can discuss exact flag names and what colour we should paint it later. I'm not going to forget about getting debug assembly fixed properly, but in the meantime HotSpot debugging is seriously broken, and this is enough for us to get our work done. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From lutz.schmidt at sap.com Fri Jun 7 09:27:19 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 7 Jun 2019 09:27:19 +0000 Subject: 8225429: Regression in disassembly quality In-Reply-To: <21f684a7cee3f523354e738bbc353884.squirrel@excalibur.xssl.net> References: <8818B65C-E697-462F-870F-DFBE3F62A58D@sap.com> <21f684a7cee3f523354e738bbc353884.squirrel@excalibur.xssl.net> Message-ID: <23B9B0C0-C836-4DC9-A962-806BD5919249@sap.com> Hi Chris, if, after all the default value adjustments, the disassembler output still does not fit your needs, tweaking it further with -XX:PrintAssemblyOptions might help. Regards, Lutz ?On 07.06.19, 10:41, "Chris Newland" wrote: Hi all, Just a note that JITWatch is aimed at product VM users and expects the old (full) PrintAssembly output. If that's changing I can work around it but just thought I'd mention it. Kind regards, Chris On Fri, June 7, 2019 08:56, Schmidt, Lutz wrote: > To all with emotions on PrintAssembly output! > > > I'm actually happy that there is some discussion now on how much > information should be printed when. > > I had sent out a request for comments before I actually started working > on this task. Back then, it was around Nov/Dec 2018, I got "bashed" > because the sample output I showed seemed bloated and way to verbose for > some. > > As a result of those comments, I introduced all the switches and #defines > to make the output configurable in a wide range. The default settings > were selected such that only minimal output is generated. I knew that > would not satisfy everybody. I am pretty much with Jon Rose: when you run > into a problem and print a disassembly, print as much information as you > have. You may not have a second chance. > > In essence, I'm happy with any default setting you may find most helpful. > If there is anything I can do to help (fixing bugs, enhancing > functionality), let me know. > > Thanks, > Lutz > > > > On 07.06.19, 01:16, "hotspot-dev on behalf of David Holmes" > david.holmes at oracle.com> wrote: > > Hi Andrew, > > > On 7/06/2019 1:19 am, Andrew Haley wrote: > >> In a debug build, if you printed a disassembled method, you used to >> get a lot of information about a method. Now, you just get raw >> disassembly. This patch restores the status quo ante, >> >> http://cr.openjdk.java.net/~aph/8225429-1/ >> > > src/hotspot/share/asm/codeBuffer.hpp > > _collect_comments = ( PrintAssembly > || PrintStubCode > || PrintMethodHandleStubs > || PrintInterpreter > || PrintSignatureHandlers > + || UnlockDiagnosticVMOptions > ); > > > Would it be better to explicitly enable this in debug, using > trueInDebug, versus using an otherwise unrelated flag that happens to be > "true in debug"? Or is there also some reason to turn this on in product > when UnlockDiagnosticVMOptions is used? > > Thanks, > David > > > >> There are other bugs in the new disassembly output: in particular >> options processing seems to be very broken. However, this patch is enough >> to get things going again, so at least we can get some work done. >> >> Before: >> >> >> # {method} {0x00007f2f64833660} 'decodeModuleName' >> '(ILjava/lang/String;)Ljava/lang/String;' in >> 'jdk/internal/module/ModuleInfo$ConstantPool' >> # this: rsi:rsi = 'jdk/internal/module/ModuleInfo$ConstantPool' >> # parm0: rdx = int >> # parm1: rcx:rcx = 'java/lang/String' >> # [sp+0x40] (sp of caller) >> ;; N542: # B1 <- BLOCK HEAD IS JUNK Freq: 1 >> >> >> 0x00007f2fb1168440: mov r10d,DWORD PTR [rsi+0x8] >> 0x00007f2fb1168444: movabs r12,0x800000000 >> 0x00007f2fb116844e: add r10,r12 >> 0x00007f2fb1168451: xor r12,r12 >> 0x00007f2fb1168454: cmp rax,r10 >> 0x00007f2fb1168457: jne 0x00007f2fb104d6a0 ; {runtime_call ic_miss_stub} >> 0x00007f2fb116845d: nop >> 0x00007f2fb116845e: nop >> 0x00007f2fb116845f: nop >> [Verified Entry Point] >> ;; B1: # B54 B2 <- BLOCK HEAD IS JUNK Freq: 1 >> >> >> 0x00007f2fb1168460: mov DWORD PTR [rsp-0x16000],eax >> 0x00007f2fb1168467: push rbp >> 0x00007f2fb1168468: sub rsp,0x30 ;*synchronization entry >> ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at -1 >> (line 877) >> >> >> 0x00007f2fb116846c: mov r10,rsi >> 0x00007f2fb116846f: mov r9,rcx >> 0x00007f2fb1168472: mov edi,DWORD PTR [rcx+0xc] ;*getfield value >> {reexecute=0 rethrow=0 return_oop=0} >> ; - java.lang.String::length at 1 (line 658) >> ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at 1 >> (line 877) >> ; implicit exception: dispatches to 0x00007f2fb116872a >> ;; B2: # B55 B3 <- B1 Freq: 0.999999 >> >> >> Now you only get this, even in a debug build: >> >> >> 0x00007ff1c5176c20: mov r10d,DWORD PTR [rsi+0x8] >> 0x00007ff1c5176c24: movabs r12,0x800000000 >> 0x00007ff1c5176c2e: add r10,r12 >> 0x00007ff1c5176c31: xor r12,r12 >> 0x00007ff1c5176c34: cmp rax,r10 >> 0x00007ff1c5176c37: jne 0x00007ff1c5113da0 >> 0x00007ff1c5176c3d: nop >> 0x00007ff1c5176c3e: nop >> 0x00007ff1c5176c3f: nop >> 0x00007ff1c5176c40: mov DWORD PTR [rsp-0x16000],eax >> 0x00007ff1c5176c47: push rbp >> 0x00007ff1c5176c48: sub rsp,0x30 >> 0x00007ff1c5176c4c: mov r11,rsi >> 0x00007ff1c5176c4f: mov r9,rcx >> 0x00007ff1c5176c52: mov r10d,DWORD PTR [rcx+0xc] >> >> >> There are no comments at all, just raw disassembly. >> >> >> This patch restores the status quo ante: >> >> >> # {method} {0x00007f9f53c2e3c0} 'decodeModuleName' >> '(ILjava/lang/String;)Ljava/lang/String;' in >> 'jdk/internal/module/ModuleInfo$ConstantPool' >> # this: rsi:rsi = 'jdk/internal/module/ModuleInfo$ConstantPool' >> # parm0: rdx = int >> # parm1: rcx:rcx = 'java/lang/String' >> # [sp+0x40] (sp of caller) >> ;; N551: # out( B1 ) <- BLOCK HEAD IS JUNK Freq: 1 >> 0x00007f9fb4d64620: mov r10d,DWORD PTR [rsi+0x8] >> 0x00007f9fb4d64624: movabs r12,0x800000000 >> 0x00007f9fb4d6462e: add r10,r12 >> 0x00007f9fb4d64631: xor r12,r12 >> 0x00007f9fb4d64634: cmp rax,r10 >> 0x00007f9fb4d64637: jne 0x00007f9fb4cfeda0 ; >> {runtime_call ic_miss_stub} >> 0x00007f9fb4d6463d: nop >> 0x00007f9fb4d6463e: nop >> 0x00007f9fb4d6463f: nop >> [Verified Entry Point] >> ;; B1: # out( B55 B2 ) <- BLOCK HEAD IS JUNK Freq: 1 >> 0x00007f9fb4d64640: mov DWORD PTR [rsp-0x16000],eax >> 0x00007f9fb4d64647: push rbp >> 0x00007f9fb4d64648: sub rsp,0x30 >> ;*synchronization entry >> ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at -1 >> (line 876) >> 0x00007f9fb4d6464c: mov r11,rsi >> 0x00007f9fb4d6464f: mov r9,rcx >> 0x00007f9fb4d64652: mov r10d,DWORD PTR [rcx+0xc] ;*getfield >> value {reexecute=0 rethrow=0 return_oop=0} ; - >> java.lang.String::length at 1 (line 673) >> ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at 1 >> (line 876) >> ; implicit exception: dispatches to 0x00007f9fb4d648fe >> ;; B2: # out( B56 B3 ) <- in( B1 ) Freq: 0.999999 >> >> > > > From tobias.hartmann at oracle.com Fri Jun 7 09:36:25 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 7 Jun 2019 11:36:25 +0200 Subject: RFC: JWarmup precompile java hot methods at application startup In-Reply-To: References: <8cfbaa83-c50f-61c4-5336-5f30b3885d45@oracle.com> Message-ID: Hi Yumin, On 19.05.19 19:28, yumin qi wrote: > ? Have done changes based on Tobias' comments.? New webrev based on most recent base is updated at: > ? ?http://cr.openjdk.java.net/~minqi/8220692/webrev-03/ Thanks, the compiler changes look reasonable to me. Best regards, Tobias From tobias.hartmann at oracle.com Fri Jun 7 09:51:04 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 7 Jun 2019 11:51:04 +0200 Subject: Questions around codeheaps, codeblobs and code locality In-Reply-To: <4057ea87-f2dd-34c5-9d15-c2183c9874b2@oracle.com> References: <4057ea87-f2dd-34c5-9d15-c2183c9874b2@oracle.com> Message-ID: <726994dd-fd15-cadb-7a1c-9daac1780050@oracle.com> Hi, > On 6/3/19 12:14 PM, keita abdoul-kader wrote: >> I have been looking into the code cache layout and ways to reduce the high >> amount of iTLB we are observing on some of our workloads. It seems that >> after the works on segmented codeHeaps, the plan was to add support for non >> contiguous codeBlobs as the next step to improve code locality in the code >> cache. is the work? on non contiguous codeBlobs still active ? With the segmented code cache, we've seen some nice improvements (slide 19 onwards): http://cr.openjdk.java.net/~thartmann/talks/2014-Efficient_Code_Cache_Management.pdf We had several ideas on how to improve things further (see slide 31) but there are currently no plans to work on any of these. >> Also, does the hotspot has support for any form of code compaction ? >> Compacting the code heap is mentioned in one of the comment in >> relocInfo.hpp, but browsing the source code it seems that once? the >> codeBlobs is filled with the content of a codeBuffer, they are never moved >> in a way to reduce codeheap fragmentation. No, code in the code cache is not moved/compacted but only removed. >> ? In general, is there an umbrella project or a set of open task around >> improving code locality ?? Please note that most of my observation driving >> this come from spark-sql workloads. Since spark-sql generates dynamically >> generate a lots of code, i might simply be observing a pathological case. No, we don't have any umbrella project for this. Best regards, Tobias From Alan.Bateman at oracle.com Fri Jun 7 10:21:13 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 7 Jun 2019 11:21:13 +0100 Subject: RFR : 8225345: Provide Cloud IAAS related info on Linux in the hs_err file In-Reply-To: References: <19eec625-e87b-b625-41b1-71b535a671a1@oracle.com> <3f27171d-a3ae-f66c-e2f4-c7264fab2bea@oracle.com> Message-ID: <60405082-e37b-f0cb-a28f-864133c25f2d@oracle.com> On 06/06/2019 14:59, Baesken, Matthias wrote: > Hello , from our experience /sys/class/dmi is pretty stable . > Of course over time the product_name and chassis_asset_tag entries could change . > I assume the values may change too, maybe with new versions of the infrastructure. Have you looked at just printing the values of the interesting keys (seems to be product_name, chassis_assert_tag and a few others) and not attempt to match values to specific vendor strings? Many of the interesting keys have the company name in the value anyway. -Alan From david.holmes at oracle.com Fri Jun 7 10:58:54 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 7 Jun 2019 20:58:54 +1000 Subject: RFR : 8225345: Provide Cloud IAAS related info on Linux in the hs_err file In-Reply-To: <60405082-e37b-f0cb-a28f-864133c25f2d@oracle.com> References: <19eec625-e87b-b625-41b1-71b535a671a1@oracle.com> <3f27171d-a3ae-f66c-e2f4-c7264fab2bea@oracle.com> <60405082-e37b-f0cb-a28f-864133c25f2d@oracle.com> Message-ID: <5f048388-7c2d-755c-775e-76734d091861@oracle.com> On 7/06/2019 8:21 pm, Alan Bateman wrote: > On 06/06/2019 14:59, Baesken, Matthias wrote: >> Hello ,?? from our experience /sys/class/dmi?? is pretty stable . >> Of course over time? the?? product_name?? and?? chassis_asset_tag >> entries? could change? . >> > I assume the values may change too, maybe with new versions of the > infrastructure. > > Have you looked at just printing the values of the interesting keys > (seems to be product_name, chassis_assert_tag and a few others) and not > attempt to match values to specific vendor strings? Many of the > interesting keys have the company name in the value anyway. I agree. Ignoring the "should we do this" aspect, it seems preferable to just report whatever is present rather than having lists of known vendors for which we specialize the code. Though of course that information may not relate to a Cloud at all. David > -Alan From matthias.baesken at sap.com Fri Jun 7 11:00:29 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 7 Jun 2019 11:00:29 +0000 Subject: RFR : 8225345: Provide Cloud IAAS related info on Linux in the hs_err file In-Reply-To: <60405082-e37b-f0cb-a28f-864133c25f2d@oracle.com> References: <19eec625-e87b-b625-41b1-71b535a671a1@oracle.com> <3f27171d-a3ae-f66c-e2f4-c7264fab2bea@oracle.com> <60405082-e37b-f0cb-a28f-864133c25f2d@oracle.com> Message-ID: Hello Alan , that sounds like a good idea ; we could have a section (output probably guarded by "ExtensiveErrorReports" ) with DMI information : product_name: .... product_version: .... chassis_asset_tag: .... chassis_vendor: ... bios_version: ... bios_vendor: .... ( in the case of Azure we would get the strange '7783-7084-3265-9085-8269-3286-77' , but otherwise it would look fine [and also work for other IAAS like OpenStack ] ) . Best regards, Matthias > -----Original Message----- > From: Alan Bateman > Sent: Freitag, 7. Juni 2019 12:21 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Cc: David Holmes > Subject: Re: RFR : 8225345: Provide Cloud IAAS related info on Linux in the > hs_err file > > On 06/06/2019 14:59, Baesken, Matthias wrote: > > Hello , from our experience /sys/class/dmi is pretty stable . > > Of course over time the product_name and chassis_asset_tag entries > could change . > > > I assume the values may change too, maybe with new versions of the > infrastructure. > > Have you looked at just printing the values of the interesting keys > (seems to be product_name, chassis_assert_tag and a few others) and not > attempt to match values to specific vendor strings? Many of the > interesting keys have the company name in the value anyway. > > -Alan From thomas.stuefe at gmail.com Fri Jun 7 11:58:19 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 7 Jun 2019 13:58:19 +0200 Subject: RFR : 8225345: Provide Cloud IAAS related info on Linux in the hs_err file In-Reply-To: References: <19eec625-e87b-b625-41b1-71b535a671a1@oracle.com> Message-ID: On Thu, Jun 6, 2019 at 2:51 PM David Holmes wrote: > On 6/06/2019 10:17 pm, Baesken, Matthias wrote: > > Hi David , sure I can guard this by "ExtensiveErrorReports" . > > > >> > >> Sorry but how is it at all relevant to crash diagnosis? > >> > > > > It gives a more complete picture where you run , helps to improve the > error analysis . > > ( like - involve the Cloud escalation team because ... ) > > Sorry not seeing it. > > >> > >> And maybe a customer doesn't want you to know whose Cloud services > they use! > >> > > > > Some people might not want the number of cores in hs_err, some might > not want to OS version , > > some people might not want something else in hs_err . > > That's always hard to say , but I think the Cloud info is on the same > technical level than what we currently already have in the hs_err so > > Nothing special . > > Vastly different IMO. Whose Cloud services company X uses could be > considered commercial-in-confidence. I don't see anything "technical" in > knowing whose cloud was used. > > Hate to say this, but I agree with David. This is even making me uncomfortable. To say this clearly, I am not denying this information is not useful. Of course it is. But I think putting this into crash reports is a) not the right place since it has not much to do with crashes and b) has the potential of damaging the trust of users. More generally, I would like a clear conversation and negotiation - with written down results - about what should and should not go into the crash report. Otherwise this is will be a continuous source of friction. I value an easy and trustful cooperation and trustful users more highly that detailed crash reports (which I do value very highly! :-). As an added benefit of such a discussion, having a Wiki page defining which information a crash report may contain (and which not) can build trust with our users. Just my five cent, Thomas > David > ----- > > > > > Best regards, Matthias > > > > > >> From: David Holmes > >> Sent: Donnerstag, 6. Juni 2019 13:51 > >> To: Baesken, Matthias ; 'hotspot- > >> dev at openjdk.java.net' > >> Subject: Re: RFR : 8225345: Provide Cloud IAAS related info on Linux in > the > >> hs_err file > >> > >> Hi Matthias, > >> > >> On 6/06/2019 9:29 pm, Baesken, Matthias wrote: > >>> Hello, please review the following change . > >>> It enhances the hs_error file output on Linux by Cloud IAAS > detection . > >>> > >>> The DMI information exposed by the /sys virtual filesystem can be > used > >> to detect various Cloud IAAS on Linux. > >>> It is helpful, for instance in support cases, to get some information > about > >> the Cloud IAAS in the hs_error file . > >> > >> Sorry but how is it at all relevant to crash diagnosis? > >> > >> And maybe a customer doesn't want you to know whose Cloud services they > >> use! > >> > >> This seems like something that should be guarded by > >> ExtensiveErrorReports - at best. > >> > >> David > >> ----- > >> > >>> > >>> Bug/webrev : > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8225345 > >>> > >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8225345.0/ > >>> > >>> > >>> Thanks, Matthias > >>> > From matthias.baesken at sap.com Fri Jun 7 12:26:41 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 7 Jun 2019 12:26:41 +0000 Subject: RFR : 8225345: Provide Cloud IAAS related info on Linux in the hs_err file In-Reply-To: References: <19eec625-e87b-b625-41b1-71b535a671a1@oracle.com> Message-ID: The last iteration of the discussion was just to write out the dmi information , without interpretation. These are technical values . Regards, Matthias From: Thomas St?fe Sent: Freitag, 7. Juni 2019 13:58 To: David Holmes ; Baesken, Matthias Cc: hotspot-dev at openjdk.java.net Subject: Re: RFR : 8225345: Provide Cloud IAAS related info on Linux in the hs_err file On Thu, Jun 6, 2019 at 2:51 PM David Holmes > wrote: On 6/06/2019 10:17 pm, Baesken, Matthias wrote: > Hi David , sure I can guard this by "ExtensiveErrorReports" . > >> >> Sorry but how is it at all relevant to crash diagnosis? >> > > It gives a more complete picture where you run , helps to improve the error analysis . > ( like - involve the Cloud escalation team because ... ) Sorry not seeing it. >> >> And maybe a customer doesn't want you to know whose Cloud services they use! >> > > Some people might not want the number of cores in hs_err, some might not want to OS version , > some people might not want something else in hs_err . > That's always hard to say , but I think the Cloud info is on the same technical level than what we currently already have in the hs_err so > Nothing special . Vastly different IMO. Whose Cloud services company X uses could be considered commercial-in-confidence. I don't see anything "technical" in knowing whose cloud was used. Hate to say this, but I agree with David. This is even making me uncomfortable. To say this clearly, I am not denying this information is not useful. Of course it is. But I think putting this into crash reports is a) not the right place since it has not much to do with crashes and b) has the potential of damaging the trust of users. More generally, I would like a clear conversation and negotiation - with written down results - about what should and should not go into the crash report. Otherwise this is will be a continuous source of friction. I value an easy and trustful cooperation and trustful users more highly that detailed crash reports (which I do value very highly! :-). As an added benefit of such a discussion, having a Wiki page defining which information a crash report may contain (and which not) can build trust with our users. Just my five cent, Thomas David ----- > > Best regards, Matthias > > >> From: David Holmes > >> Sent: Donnerstag, 6. Juni 2019 13:51 >> To: Baesken, Matthias >; 'hotspot- >> dev at openjdk.java.net' > >> Subject: Re: RFR : 8225345: Provide Cloud IAAS related info on Linux in the >> hs_err file >> >> Hi Matthias, >> >> On 6/06/2019 9:29 pm, Baesken, Matthias wrote: >>> Hello, please review the following change . >>> It enhances the hs_error file output on Linux by Cloud IAAS detection . >>> >>> The DMI information exposed by the /sys virtual filesystem can be used >> to detect various Cloud IAAS on Linux. >>> It is helpful, for instance in support cases, to get some information about >> the Cloud IAAS in the hs_error file . >> >> Sorry but how is it at all relevant to crash diagnosis? >> >> And maybe a customer doesn't want you to know whose Cloud services they >> use! >> >> This seems like something that should be guarded by >> ExtensiveErrorReports - at best. >> >> David >> ----- >> >>> >>> Bug/webrev : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8225345 >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8225345.0/ >>> >>> >>> Thanks, Matthias >>> From david.holmes at oracle.com Fri Jun 7 13:09:36 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 7 Jun 2019 23:09:36 +1000 Subject: RFR : 8225345: Provide Cloud IAAS related info on Linux in the hs_err file In-Reply-To: References: <19eec625-e87b-b625-41b1-71b535a671a1@oracle.com> Message-ID: <3b4e4bd9-ee51-ce5a-8e21-cab147b849ed@oracle.com> On 7/06/2019 10:26 pm, Baesken, Matthias wrote: > The? last iteration of the discussion was just? to write out the dmi > information , without ?interpretation. > > These are technical values . No they are not. They still convey the same information that we're concerned about. Look at it this way, we could have been putting SMBIOS/DMI information in the hs_err report from day one. We don't. It's never been relevant. The fact we're executing on an x86 family 5 cpu may be relevant. The fact the machine has an AMI BIOS is not. David ----- > Regards, Matthias > > *From:*Thomas St?fe > *Sent:* Freitag, 7. Juni 2019 13:58 > *To:* David Holmes ; Baesken, Matthias > > *Cc:* hotspot-dev at openjdk.java.net > *Subject:* Re: RFR : 8225345: Provide Cloud IAAS related info on Linux > in the hs_err file > > On Thu, Jun 6, 2019 at 2:51 PM David Holmes > wrote: > > On 6/06/2019 10:17 pm, Baesken, Matthias wrote: > > Hi? David ,? ?sure I can? guard this by? "ExtensiveErrorReports" . > > > >> > >> Sorry but how is it at all relevant to crash diagnosis? > >> > > > > It? gives a more complete picture where you run , helps to > improve the error analysis . > > ( like - involve? the? Cloud escalation team? because ...? ) > > Sorry not seeing it. > > >> > >> And maybe a customer doesn't want you to know whose Cloud > services they? use! > >> > > > > Some people might not want the? number of cores in hs_err, some > might not want to OS version? , > > some people might? not want something else in hs_err . > > That's always hard to say , but I think? the Cloud info is on the > same technical level? than what we? currently? already have in the > hs_err? so > >? ?Nothing special . > > Vastly different IMO. Whose Cloud services company X uses could be > considered commercial-in-confidence. I don't see anything > "technical" in > knowing whose cloud was used. > > Hate to say this, but I agree with David. This is even making me > uncomfortable. > > To say this clearly, I am not denying this information is not useful. Of > course it is. But I think putting this into crash reports is a) not the > right place since it has not much to do with crashes and b) has the > potential of damaging the trust of users. > > More generally, I would like a clear conversation and negotiation - with > written down results - about what should and should not go into the > crash report. Otherwise this is will be a continuous source of friction. > I value an easy and trustful cooperation and trustful users more highly > that detailed crash reports (which I do value very highly! :-). > > As an added benefit of such a discussion, having a Wiki page defining > which information a crash report may contain (and which not) can build > trust with our users. > > Just my five cent, > > Thomas > > David > ----- > > > > > Best regards, Matthias > > > > > >> From: David Holmes > > >> Sent: Donnerstag, 6. Juni 2019 13:51 > >> To: Baesken, Matthias >; 'hotspot- > >> dev at openjdk.java.net ' > > > >> Subject: Re: RFR : 8225345: Provide Cloud IAAS related info on > Linux in the > >> hs_err file > >> > >> Hi Matthias, > >> > >> On 6/06/2019 9:29 pm, Baesken, Matthias wrote: > >>> Hello, please review the following change . > >>> It? enhances the hs_error file? output on Linux by? Cloud IAAS > detection . > >>> > >>> The DMI information? exposed? by the? /sys virtual filesystem > can be used > >> to detect various Cloud IAAS on Linux. > >>> It is helpful, for instance in support cases, to get some > information about > >> the Cloud IAAS in the hs_error file . > >> > >> Sorry but how is it at all relevant to crash diagnosis? > >> > >> And maybe a customer doesn't want you to know whose Cloud > services they > >> use! > >> > >> This seems like something that should be guarded by > >> ExtensiveErrorReports - at best. > >> > >> David > >> ----- > >> > >>> > >>> Bug/webrev : > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8225345 > >>> > >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8225345.0/ > >>> > >>> > >>> Thanks, Matthias > >>> > From matthias.baesken at sap.com Fri Jun 7 13:26:58 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 7 Jun 2019 13:26:58 +0000 Subject: RFR : 8225345: Provide Cloud IAAS related info on Linux in the hs_err file In-Reply-To: <3b4e4bd9-ee51-ce5a-8e21-cab147b849ed@oracle.com> References: <19eec625-e87b-b625-41b1-71b535a671a1@oracle.com> <3b4e4bd9-ee51-ce5a-8e21-cab147b849ed@oracle.com> Message-ID: > fact the machine has an AMI BIOS is not. Printing the BIOS was not part of my original patch . Saying - "Printing the BIOS is not relevant " ... we had a few very complicated and time consuming JVM support cases in the past where BIOS updates where involved . ( but that?s another discussion ) Best regards , Matthias > -----Original Message----- > From: David Holmes > Sent: Freitag, 7. Juni 2019 15:10 > To: Baesken, Matthias ; Thomas St?fe > > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR : 8225345: Provide Cloud IAAS related info on Linux in the > hs_err file > > On 7/06/2019 10:26 pm, Baesken, Matthias wrote: > > The? last iteration of the discussion was just? to write out the dmi > > information , without ?interpretation. > > > > These are technical values . > > No they are not. They still convey the same information that we're > concerned about. > > Look at it this way, we could have been putting SMBIOS/DMI information > in the hs_err report from day one. We don't. It's never been relevant. > The fact we're executing on an x86 family 5 cpu may be relevant. The > fact the machine has an AMI BIOS is not. > > David > ----- > > > Regards, Matthias > > > > *From:*Thomas St?fe > > *Sent:* Freitag, 7. Juni 2019 13:58 > > *To:* David Holmes ; Baesken, Matthias > > > > *Cc:* hotspot-dev at openjdk.java.net > > *Subject:* Re: RFR : 8225345: Provide Cloud IAAS related info on Linux > > in the hs_err file > > > > On Thu, Jun 6, 2019 at 2:51 PM David Holmes > > wrote: > > > > On 6/06/2019 10:17 pm, Baesken, Matthias wrote: > > > Hi? David ,? ?sure I can? guard this by? "ExtensiveErrorReports" . > > > > > >> > > >> Sorry but how is it at all relevant to crash diagnosis? > > >> > > > > > > It? gives a more complete picture where you run , helps to > > improve the error analysis . > > > ( like - involve? the? Cloud escalation team? because ...? ) > > > > Sorry not seeing it. > > > > >> > > >> And maybe a customer doesn't want you to know whose Cloud > > services they? use! > > >> > > > > > > Some people might not want the? number of cores in hs_err, some > > might not want to OS version? , > > > some people might? not want something else in hs_err . > > > That's always hard to say , but I think? the Cloud info is on the > > same technical level? than what we? currently? already have in the > > hs_err? so > > >? ?Nothing special . > > > > Vastly different IMO. Whose Cloud services company X uses could be > > considered commercial-in-confidence. I don't see anything > > "technical" in > > knowing whose cloud was used. > > > > Hate to say this, but I agree with David. This is even making me > > uncomfortable. > > > > To say this clearly, I am not denying this information is not useful. Of > > course it is. But I think putting this into crash reports is a) not the > > right place since it has not much to do with crashes and b) has the > > potential of damaging the trust of users. > > > > More generally, I would like a clear conversation and negotiation - with > > written down results - about what should and should not go into the > > crash report. Otherwise this is will be a continuous source of friction. > > I value an easy and trustful cooperation and trustful users more highly > > that detailed crash reports (which I do value very highly! :-). > > > > As an added benefit of such a discussion, having a Wiki page defining > > which information a crash report may contain (and which not) can build > > trust with our users. > > > > Just my five cent, > > > > Thomas > > > > David > > ----- > > > > > > > > Best regards, Matthias > > > > > > > > >> From: David Holmes > > > > >> Sent: Donnerstag, 6. Juni 2019 13:51 > > >> To: Baesken, Matthias > >; 'hotspot- > > >> dev at openjdk.java.net ' > > dev at openjdk.java.net>> > > >> Subject: Re: RFR : 8225345: Provide Cloud IAAS related info on > > Linux in the > > >> hs_err file > > >> > > >> Hi Matthias, > > >> > > >> On 6/06/2019 9:29 pm, Baesken, Matthias wrote: > > >>> Hello, please review the following change . > > >>> It? enhances the hs_error file? output on Linux by? Cloud IAAS > > detection . > > >>> > > >>> The DMI information? exposed? by the? /sys virtual filesystem > > can be used > > >> to detect various Cloud IAAS on Linux. > > >>> It is helpful, for instance in support cases, to get some > > information about > > >> the Cloud IAAS in the hs_error file . > > >> > > >> Sorry but how is it at all relevant to crash diagnosis? > > >> > > >> And maybe a customer doesn't want you to know whose Cloud > > services they > > >> use! > > >> > > >> This seems like something that should be guarded by > > >> ExtensiveErrorReports - at best. > > >> > > >> David > > >> ----- > > >> > > >>> > > >>> Bug/webrev : > > >>> > > >>> https://bugs.openjdk.java.net/browse/JDK-8225345 > > >>> > > >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8225345.0/ > > >>> > > >>> > > >>> Thanks, Matthias > > >>> > > From thomas.stuefe at gmail.com Fri Jun 7 14:08:16 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 7 Jun 2019 16:08:16 +0200 Subject: RFR : 8225345: Provide Cloud IAAS related info on Linux in the hs_err file In-Reply-To: References: <19eec625-e87b-b625-41b1-71b535a671a1@oracle.com> <3b4e4bd9-ee51-ce5a-8e21-cab147b849ed@oracle.com> Message-ID: On Fri, Jun 7, 2019 at 3:27 PM Baesken, Matthias wrote: > > fact the machine has an AMI BIOS is not. > > Printing the BIOS was not part of my original patch . > > Saying - "Printing the BIOS is not relevant " ... we had a few very > complicated and time consuming JVM support cases in the past where > BIOS updates where involved . > ( but that?s another discussion ) > So where do you draw the line? Since you obviously do not draw it here. At clear user names? Content of user home directory? Topology of the internal network? All of these may be useful to some support case. Which, to me, does not mean they have a place in a crash report. Convenience for developer support is only one side. User trust is another. And there, it does not matter if you think this is harmless. It matters what users think. The moment the first blogger writes about "Look what I found in a JDK crash report" it can be damaging to the platform as a whole. --Thomas > > Best regards , Matthias > > > > > -----Original Message----- > > From: David Holmes > > Sent: Freitag, 7. Juni 2019 15:10 > > To: Baesken, Matthias ; Thomas St?fe > > > > Cc: hotspot-dev at openjdk.java.net > > Subject: Re: RFR : 8225345: Provide Cloud IAAS related info on Linux in > the > > hs_err file > > > > On 7/06/2019 10:26 pm, Baesken, Matthias wrote: > > > The last iteration of the discussion was just to write out the dmi > > > information , without interpretation. > > > > > > These are technical values . > > > > No they are not. They still convey the same information that we're > > concerned about. > > > > Look at it this way, we could have been putting SMBIOS/DMI information > > in the hs_err report from day one. We don't. It's never been relevant. > > The fact we're executing on an x86 family 5 cpu may be relevant. The > > fact the machine has an AMI BIOS is not. > > > > David > > ----- > > > > > Regards, Matthias > > > > > > *From:*Thomas St?fe > > > *Sent:* Freitag, 7. Juni 2019 13:58 > > > *To:* David Holmes ; Baesken, Matthias > > > > > > *Cc:* hotspot-dev at openjdk.java.net > > > *Subject:* Re: RFR : 8225345: Provide Cloud IAAS related info on Linux > > > in the hs_err file > > > > > > On Thu, Jun 6, 2019 at 2:51 PM David Holmes > > > wrote: > > > > > > On 6/06/2019 10:17 pm, Baesken, Matthias wrote: > > > > Hi David , sure I can guard this by > "ExtensiveErrorReports" . > > > > > > > >> > > > >> Sorry but how is it at all relevant to crash diagnosis? > > > >> > > > > > > > > It gives a more complete picture where you run , helps to > > > improve the error analysis . > > > > ( like - involve the Cloud escalation team because ... ) > > > > > > Sorry not seeing it. > > > > > > >> > > > >> And maybe a customer doesn't want you to know whose Cloud > > > services they use! > > > >> > > > > > > > > Some people might not want the number of cores in hs_err, some > > > might not want to OS version , > > > > some people might not want something else in hs_err . > > > > That's always hard to say , but I think the Cloud info is on > the > > > same technical level than what we currently already have in the > > > hs_err so > > > > Nothing special . > > > > > > Vastly different IMO. Whose Cloud services company X uses could be > > > considered commercial-in-confidence. I don't see anything > > > "technical" in > > > knowing whose cloud was used. > > > > > > Hate to say this, but I agree with David. This is even making me > > > uncomfortable. > > > > > > To say this clearly, I am not denying this information is not useful. > Of > > > course it is. But I think putting this into crash reports is a) not the > > > right place since it has not much to do with crashes and b) has the > > > potential of damaging the trust of users. > > > > > > More generally, I would like a clear conversation and negotiation - > with > > > written down results - about what should and should not go into the > > > crash report. Otherwise this is will be a continuous source of > friction. > > > I value an easy and trustful cooperation and trustful users more highly > > > that detailed crash reports (which I do value very highly! :-). > > > > > > As an added benefit of such a discussion, having a Wiki page defining > > > which information a crash report may contain (and which not) can build > > > trust with our users. > > > > > > Just my five cent, > > > > > > Thomas > > > > > > David > > > ----- > > > > > > > > > > > Best regards, Matthias > > > > > > > > > > > >> From: David Holmes > > > > > > >> Sent: Donnerstag, 6. Juni 2019 13:51 > > > >> To: Baesken, Matthias > > >; 'hotspot- > > > >> dev at openjdk.java.net ' > > > > dev at openjdk.java.net>> > > > >> Subject: Re: RFR : 8225345: Provide Cloud IAAS related info on > > > Linux in the > > > >> hs_err file > > > >> > > > >> Hi Matthias, > > > >> > > > >> On 6/06/2019 9:29 pm, Baesken, Matthias wrote: > > > >>> Hello, please review the following change . > > > >>> It enhances the hs_error file output on Linux by Cloud IAAS > > > detection . > > > >>> > > > >>> The DMI information exposed by the /sys virtual filesystem > > > can be used > > > >> to detect various Cloud IAAS on Linux. > > > >>> It is helpful, for instance in support cases, to get some > > > information about > > > >> the Cloud IAAS in the hs_error file . > > > >> > > > >> Sorry but how is it at all relevant to crash diagnosis? > > > >> > > > >> And maybe a customer doesn't want you to know whose Cloud > > > services they > > > >> use! > > > >> > > > >> This seems like something that should be guarded by > > > >> ExtensiveErrorReports - at best. > > > >> > > > >> David > > > >> ----- > > > >> > > > >>> > > > >>> Bug/webrev : > > > >>> > > > >>> https://bugs.openjdk.java.net/browse/JDK-8225345 > > > >>> > > > >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8225345.0/ > > > >>> > > > >>> > > > >>> Thanks, Matthias > > > >>> > > > > From kirk at kodewerk.com Fri Jun 7 16:18:26 2019 From: kirk at kodewerk.com (Kodewerk) Date: Fri, 7 Jun 2019 09:18:26 -0700 Subject: RFR : 8225345: Provide Cloud IAAS related info on Linux in the hs_err file In-Reply-To: References: <19eec625-e87b-b625-41b1-71b535a671a1@oracle.com> <3b4e4bd9-ee51-ce5a-8e21-cab147b849ed@oracle.com> Message-ID: <7BE0A96C-5B38-4EAB-A363-7B18FBC78A51@kodewerk.com> Hi Thomas, I have to agree with you. As it stands, the hs_err does not contain any information that cannot be passed to me with the need of an NDA. Once you start digging deeper into the end users environment you start raising serious security concerns. I would suggest that this information should be collectable in anger and not by default. Kind regards, Kirk > On Jun 7, 2019, at 7:08 AM, Thomas St?fe wrote: > > On Fri, Jun 7, 2019 at 3:27 PM Baesken, Matthias > wrote: > >>> fact the machine has an AMI BIOS is not. >> >> Printing the BIOS was not part of my original patch . >> >> Saying - "Printing the BIOS is not relevant " ... we had a few very >> complicated and time consuming JVM support cases in the past where >> BIOS updates where involved . >> ( but that?s another discussion ) >> > > So where do you draw the line? Since you obviously do not draw it here. At > clear user names? Content of user home directory? Topology of the internal > network? All of these may be useful to some support case. Which, to me, > does not mean they have a place in a crash report. > > Convenience for developer support is only one side. User trust is another. > And there, it does not matter if you think this is harmless. It matters > what users think. The moment the first blogger writes about "Look what I > found in a JDK crash report" it can be damaging to the platform as a whole. > > --Thomas > > >> >> Best regards , Matthias >> >> >> >>> -----Original Message----- >>> From: David Holmes >>> Sent: Freitag, 7. Juni 2019 15:10 >>> To: Baesken, Matthias ; Thomas St?fe >>> >>> Cc: hotspot-dev at openjdk.java.net >>> Subject: Re: RFR : 8225345: Provide Cloud IAAS related info on Linux in >> the >>> hs_err file >>> >>> On 7/06/2019 10:26 pm, Baesken, Matthias wrote: >>>> The last iteration of the discussion was just to write out the dmi >>>> information , without interpretation. >>>> >>>> These are technical values . >>> >>> No they are not. They still convey the same information that we're >>> concerned about. >>> >>> Look at it this way, we could have been putting SMBIOS/DMI information >>> in the hs_err report from day one. We don't. It's never been relevant. >>> The fact we're executing on an x86 family 5 cpu may be relevant. The >>> fact the machine has an AMI BIOS is not. >>> >>> David >>> ----- >>> >>>> Regards, Matthias >>>> >>>> *From:*Thomas St?fe >>>> *Sent:* Freitag, 7. Juni 2019 13:58 >>>> *To:* David Holmes ; Baesken, Matthias >>>> >>>> *Cc:* hotspot-dev at openjdk.java.net >>>> *Subject:* Re: RFR : 8225345: Provide Cloud IAAS related info on Linux >>>> in the hs_err file >>>> >>>> On Thu, Jun 6, 2019 at 2:51 PM David Holmes >>> > wrote: >>>> >>>> On 6/06/2019 10:17 pm, Baesken, Matthias wrote: >>>>> Hi David , sure I can guard this by >> "ExtensiveErrorReports" . >>>>> >>>>>> >>>>>> Sorry but how is it at all relevant to crash diagnosis? >>>>>> >>>>> >>>>> It gives a more complete picture where you run , helps to >>>> improve the error analysis . >>>>> ( like - involve the Cloud escalation team because ... ) >>>> >>>> Sorry not seeing it. >>>> >>>>>> >>>>>> And maybe a customer doesn't want you to know whose Cloud >>>> services they use! >>>>>> >>>>> >>>>> Some people might not want the number of cores in hs_err, some >>>> might not want to OS version , >>>>> some people might not want something else in hs_err . >>>>> That's always hard to say , but I think the Cloud info is on >> the >>>> same technical level than what we currently already have in the >>>> hs_err so >>>>> Nothing special . >>>> >>>> Vastly different IMO. Whose Cloud services company X uses could be >>>> considered commercial-in-confidence. I don't see anything >>>> "technical" in >>>> knowing whose cloud was used. >>>> >>>> Hate to say this, but I agree with David. This is even making me >>>> uncomfortable. >>>> >>>> To say this clearly, I am not denying this information is not useful. >> Of >>>> course it is. But I think putting this into crash reports is a) not the >>>> right place since it has not much to do with crashes and b) has the >>>> potential of damaging the trust of users. >>>> >>>> More generally, I would like a clear conversation and negotiation - >> with >>>> written down results - about what should and should not go into the >>>> crash report. Otherwise this is will be a continuous source of >> friction. >>>> I value an easy and trustful cooperation and trustful users more highly >>>> that detailed crash reports (which I do value very highly! :-). >>>> >>>> As an added benefit of such a discussion, having a Wiki page defining >>>> which information a crash report may contain (and which not) can build >>>> trust with our users. >>>> >>>> Just my five cent, >>>> >>>> Thomas >>>> >>>> David >>>> ----- >>>> >>>>> >>>>> Best regards, Matthias >>>>> >>>>> >>>>>> From: David Holmes >>> > >>>>>> Sent: Donnerstag, 6. Juni 2019 13:51 >>>>>> To: Baesken, Matthias >>> >; 'hotspot- >>>>>> dev at openjdk.java.net ' >>>> >> dev at openjdk.java.net>> >>>>>> Subject: Re: RFR : 8225345: Provide Cloud IAAS related info on >>>> Linux in the >>>>>> hs_err file >>>>>> >>>>>> Hi Matthias, >>>>>> >>>>>> On 6/06/2019 9:29 pm, Baesken, Matthias wrote: >>>>>>> Hello, please review the following change . >>>>>>> It enhances the hs_error file output on Linux by Cloud IAAS >>>> detection . >>>>>>> >>>>>>> The DMI information exposed by the /sys virtual filesystem >>>> can be used >>>>>> to detect various Cloud IAAS on Linux. >>>>>>> It is helpful, for instance in support cases, to get some >>>> information about >>>>>> the Cloud IAAS in the hs_error file . >>>>>> >>>>>> Sorry but how is it at all relevant to crash diagnosis? >>>>>> >>>>>> And maybe a customer doesn't want you to know whose Cloud >>>> services they >>>>>> use! >>>>>> >>>>>> This seems like something that should be guarded by >>>>>> ExtensiveErrorReports - at best. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> >>>>>>> Bug/webrev : >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8225345 >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8225345.0/ >>>>>>> >>>>>>> >>>>>>> Thanks, Matthias >>>>>>> >>>> >> From tom.rodriguez at oracle.com Fri Jun 7 16:52:01 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 7 Jun 2019 09:52:01 -0700 Subject: RFR: 8225429: Regression in disassembly quality In-Reply-To: <7ae9dcac-e7d9-5989-1ae7-3743c9775dc9@redhat.com> References: <60b89a4f-655c-d5f8-7d6b-9532c865bba7@redhat.com> <7ae9dcac-e7d9-5989-1ae7-3743c9775dc9@redhat.com> Message-ID: <78005969-b342-6024-5ce1-031045df8d2d@oracle.com> Andrew Haley wrote on 6/7/19 1:18 AM: > On 6/6/19 9:22 PM, John Rose wrote: >> On Jun 6, 2019, at 10:56 AM, Tom Rodriguez wrote: >> >> Effective diagnosis and performance tuning requires accurate, >> informative disassembly. I would support moving the assembler >> comment capture, whenever disassembly is enabled. If there's >> a risk of disturbing program dynamics with the extra footprint, >> perhaps it could be broken out as a separate diagnostic option. >> >> More disassembly information is better, even in product mode! > > OK. I can do that later, but I'd like this patch (which fixes the > regression) in now. I think your current patch is good given how broken it currently is. So I approve of your current patch, though I would like to see your new defaults abstractDisassembler.cpp apply product as well so it always looks the same as it used to. I'll take care of pushing my own changes separately. tom From aph at redhat.com Fri Jun 7 17:17:31 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 7 Jun 2019 18:17:31 +0100 Subject: RFR: 8225429: Regression in disassembly quality In-Reply-To: <78005969-b342-6024-5ce1-031045df8d2d@oracle.com> References: <60b89a4f-655c-d5f8-7d6b-9532c865bba7@redhat.com> <7ae9dcac-e7d9-5989-1ae7-3743c9775dc9@redhat.com> <78005969-b342-6024-5ce1-031045df8d2d@oracle.com> Message-ID: <12ce99b1-25bd-b965-a3d9-befba0e1d3d3@redhat.com> On 6/7/19 5:52 PM, Tom Rodriguez wrote: > > Andrew Haley wrote on 6/7/19 1:18 AM: >> On 6/6/19 9:22 PM, John Rose wrote: >>> On Jun 6, 2019, at 10:56 AM, Tom Rodriguez wrote: >>> >>> Effective diagnosis and performance tuning requires accurate, >>> informative disassembly. I would support moving the assembler >>> comment capture, whenever disassembly is enabled. If there's >>> a risk of disturbing program dynamics with the extra footprint, >>> perhaps it could be broken out as a separate diagnostic option. >>> >>> More disassembly information is better, even in product mode! >> >> OK. I can do that later, but I'd like this patch (which fixes the >> regression) in now. > > I think your current patch is good given how broken it currently is. So > I approve of your current patch, though I would like to see your new > defaults abstractDisassembler.cpp apply product as well so it always > looks the same as it used to. OK, I'll have a look at what product did. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From yumin.qi at gmail.com Fri Jun 7 17:25:41 2019 From: yumin.qi at gmail.com (yumin qi) Date: Fri, 7 Jun 2019 10:25:41 -0700 Subject: RFC: JWarmup precompile java hot methods at application startup In-Reply-To: References: <8cfbaa83-c50f-61c4-5336-5f30b3885d45@oracle.com> Message-ID: Hi, David and all Can I have one more comment from runtime expert for the JEP? David, can you comment for the changes? Really appreciate your last comment. It is best if you follow the comment. Looking forward to having your comment. Thanks Yumin On Sun, May 19, 2019 at 10:28 AM yumin qi wrote: > Hi, Tobias and all > > Have done changes based on Tobias' comments. New webrev based on most > recent base is updated at: > http://cr.openjdk.java.net/~minqi/8220692/webrev-03/ > > Tested local for jwarmup and compiler. > > Thanks > Yumin > > > On Tue, May 14, 2019 at 11:26 AM yumin qi wrote: > >> HI, Tobias >> >> Thanks very much for the comments. >> >> On Mon, May 13, 2019 at 2:58 AM Tobias Hartmann < >> tobias.hartmann at oracle.com> wrote: >> >>> Hi Yumin, >>> >>> > In this version, the profiled method data is not used at >>> > precomilation, it will be addressed in followed bug fix. After the >>> > first version integrated, will file bug for it. >>> >>> Why is that? I think it would be good to have everything in one JEP. >>> >> >> We have done some tests on adding profiling data and found the result is >> not as expected, and the current version is working well for internal >> online applications. There is no other reason not adding to this patch now, >> we will like to study further to see if we can improve that for a better >> performance. >> >> >>> I've looked at the compiler related changes. Here are some >>> comments/questions. >>> >>> ciMethod.cpp >>> - So CompilationWarmUp is not using any profile information? Not even >>> the profile obtained in the >>> current execution? >>> >>> >> Yes. This is also related to previous question. >> >> compile.cpp >>> - line 748: Why is that required? Couldn't it happen that a method is >>> never compiled because the >>> code that would resolve a field is never executed? >>> >>> >> Here a very aggressive decision --- to avoid compilation failure requires >> that all fields have already been resolved. >> >> >>> graphKit.cpp >>> - line 2832: please add a comment >>> - line 2917: checks should be merged into one if and please add a comment >>> >>> >> Will fix it. >> >> >>> jvm.cpp >>> - Could you explain why it's guaranteed that warmup compilation is >>> completed once the dummy method >>> is compiled? And why is it hardcoded to print >>> "com.alibaba.jwarmup.JWarmUp"? >>> >>> >> This is from practical testing of real applications. Due to the >> parallelism of compilation works, it should check if compilation queue >> contains any of those methods --- completed if no any of them on the queue >> and it is not economic. By using of a dummy method as a simplified version >> for that, in real case, it is not observed that dummy method is not the >> last compilation for warmup. Do you have suggestion of a way to do that? >> The dummy way is not strictly a guaranteed one theoretically. >> Forgot to change the print to new name after renaming package, thanks for >> the catching. >> >> >>> - What is test_symbol_matcher() used for? >>> >>> >> This is a leftover(used to test matching patterns), will remove it from >> the file. >> >> >>> jitWarmUp.cpp: >>> - line 146: So what about methods that are only ever compiled at C1 >>> level? Wouldn't it make sense to >>> keep track of the comp_level during CompilationWarmUpRecording? >>> >>> >>> Will consider your suggestion in future work on it. >> >> >>> I also found several typos while reading through the code (listed in >>> random order): >>> >>> globals.hpp >>> - "flushing profling" -> "flushing profiling" >>> >>> method.hpp >>> - "when this method first been invoked" >>> >>> templateInterpreterGenerator_x86.cpp >>> - initializition -> initialization >>> >>> dict.cpp >>> - initializated -> initialized >>> >>> jitWarmUp.cpp >>> - uninitilaized -> uninitialized >>> - inited -> should be initialized, right? >>> >>> jitWarmUp.hpp >>> . nofityApplicationStartUpIsDone -> notifyApplicationStartUpIsDone >>> >>> constantPool.cpp >>> - recusive -> recursive >>> >>> JWarmUp.java >>> - appliacation -> application >>> >>> TestThrowInitializaitonException.java -> >>> TestThrowInitializationException.java >>> >>> These tests should be renamed (it's not clear what issue the number >>> refers to): >>> - issue9780156.sh >>> - Issue11272598.java >>> >> >> Will fix all above suggestions. >> >> Thanks! >> >> Yumin >> > From tom.rodriguez at oracle.com Fri Jun 7 17:31:54 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 7 Jun 2019 10:31:54 -0700 Subject: RFR: 8225429: Regression in disassembly quality In-Reply-To: <12ce99b1-25bd-b965-a3d9-befba0e1d3d3@redhat.com> References: <60b89a4f-655c-d5f8-7d6b-9532c865bba7@redhat.com> <7ae9dcac-e7d9-5989-1ae7-3743c9775dc9@redhat.com> <78005969-b342-6024-5ce1-031045df8d2d@oracle.com> <12ce99b1-25bd-b965-a3d9-befba0e1d3d3@redhat.com> Message-ID: <40ba5e78-51e7-e628-a765-f4348ba4befb@oracle.com> >> I think your current patch is good given how broken it currently is. So >> I approve of your current patch, though I would like to see your new >> defaults abstractDisassembler.cpp apply product as well so it always >> looks the same as it used to. > > OK, I'll have a look at what product did. I think it would be the same as what you added for non-product, so you new block settings completely replaces the old settings. I don't think there should be any difference between product and non-product in terms of what's emitted by disassembly. Which I think was the gist of John's comment. tom From john.r.rose at oracle.com Fri Jun 7 18:09:48 2019 From: john.r.rose at oracle.com (John Rose) Date: Fri, 7 Jun 2019 11:09:48 -0700 Subject: RFR : 8225345: Provide Cloud IAAS related info on Linux in the hs_err file In-Reply-To: <7BE0A96C-5B38-4EAB-A363-7B18FBC78A51@kodewerk.com> References: <19eec625-e87b-b625-41b1-71b535a671a1@oracle.com> <3b4e4bd9-ee51-ce5a-8e21-cab147b849ed@oracle.com> <7BE0A96C-5B38-4EAB-A363-7B18FBC78A51@kodewerk.com> Message-ID: On Jun 7, 2019, at 9:18 AM, Kodewerk wrote: > > I have to agree with you. As it stands, the hs_err does not contain any information that cannot be passed to me with the need of an NDA. Once you start digging deeper into the end users environment you start raising serious security concerns. I would suggest that this information should be collectable in anger and not by default. +1 from me on this thread also. I like the suggestion of a public wiki doc that says what's in and what's excluded from hs_err. One more idea about adding more information "in anger": This added information could be packaged separately, in a different file from hs_err. Occasionally mixing secrets into usually non-secret channels is an anti-pattern. If there's value in keeping hs_err non-confidential, occasional opt-in confidential info should go into a separate bucket. The usability problem of having to manage two buckets instead of one is not enough to outweigh the value of keeping stuff properly labeled. From lutz.schmidt at sap.com Fri Jun 7 19:11:10 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 7 Jun 2019 19:11:10 +0000 Subject: 8225429: Regression in disassembly quality In-Reply-To: <2544879C-CCC8-4383-A4B3-9C09AD4CD065@kodewerk.com> References: <8818B65C-E697-462F-870F-DFBE3F62A58D@sap.com> <21f684a7cee3f523354e738bbc353884.squirrel@excalibur.xssl.net> <2544879C-CCC8-4383-A4B3-9C09AD4CD065@kodewerk.com> Message-ID: <439421A8-8629-47E8-AF18-FB29EEA6659E@sap.com> Kirk, if the currently active (and failing) nmethod isn't enough for you to debug, the only remedy currently existing is -XX:+PrintAssembly which prints all nmethods at compilation time. If it's just a handful of nmethods under suspicion, you could use CompilerOracle to selectively print those. The "big" solution would be to print/disassemble all nmethods in the code heap at failure time. That functionality doesn't exist yet. Regards, Lutz ?On 07.06.19, 17:50, "Kodewerk" wrote: Hi Chris, I was just recently dealing with a JVM crash caused by C2 compilation missing a barrier. It only showed up on certain production system which could never be replicated in a test environment. Having a full print assembly in that situation wasn?t a great option. Although there is an obscure way to get the assembly for a single method it would be great if there was better ways to easily target specific compilation events. ? Kirk > On Jun 7, 2019, at 1:41 AM, Chris Newland wrote: > > Hi all, > > Just a note that JITWatch is aimed at product VM users and expects the old > (full) PrintAssembly output. > > If that's changing I can work around it but just thought I'd mention it. > > Kind regards, > > Chris > > On Fri, June 7, 2019 08:56, Schmidt, Lutz wrote: >> To all with emotions on PrintAssembly output! >> >> >> I'm actually happy that there is some discussion now on how much >> information should be printed when. >> >> I had sent out a request for comments before I actually started working >> on this task. Back then, it was around Nov/Dec 2018, I got "bashed" >> because the sample output I showed seemed bloated and way to verbose for >> some. >> >> As a result of those comments, I introduced all the switches and #defines >> to make the output configurable in a wide range. The default settings >> were selected such that only minimal output is generated. I knew that >> would not satisfy everybody. I am pretty much with Jon Rose: when you run >> into a problem and print a disassembly, print as much information as you >> have. You may not have a second chance. >> >> In essence, I'm happy with any default setting you may find most helpful. >> If there is anything I can do to help (fixing bugs, enhancing >> functionality), let me know. >> >> Thanks, >> Lutz >> >> >> >> On 07.06.19, 01:16, "hotspot-dev on behalf of David Holmes" >> > david.holmes at oracle.com> wrote: >> >> Hi Andrew, >> >> >> On 7/06/2019 1:19 am, Andrew Haley wrote: >> >>> In a debug build, if you printed a disassembled method, you used to >>> get a lot of information about a method. Now, you just get raw >>> disassembly. This patch restores the status quo ante, >>> >>> http://cr.openjdk.java.net/~aph/8225429-1/ >>> >> >> src/hotspot/share/asm/codeBuffer.hpp >> >> _collect_comments = ( PrintAssembly >> || PrintStubCode >> || PrintMethodHandleStubs >> || PrintInterpreter >> || PrintSignatureHandlers >> + || UnlockDiagnosticVMOptions >> ); >> >> >> Would it be better to explicitly enable this in debug, using >> trueInDebug, versus using an otherwise unrelated flag that happens to be >> "true in debug"? Or is there also some reason to turn this on in product >> when UnlockDiagnosticVMOptions is used? >> >> Thanks, >> David >> >> >> >>> There are other bugs in the new disassembly output: in particular >>> options processing seems to be very broken. However, this patch is enough >>> to get things going again, so at least we can get some work done. >>> >>> Before: >>> >>> >>> # {method} {0x00007f2f64833660} 'decodeModuleName' >>> '(ILjava/lang/String;)Ljava/lang/String;' in >>> 'jdk/internal/module/ModuleInfo$ConstantPool' >>> # this: rsi:rsi = 'jdk/internal/module/ModuleInfo$ConstantPool' >>> # parm0: rdx = int >>> # parm1: rcx:rcx = 'java/lang/String' >>> # [sp+0x40] (sp of caller) >>> ;; N542: # B1 <- BLOCK HEAD IS JUNK Freq: 1 >>> >>> >>> 0x00007f2fb1168440: mov r10d,DWORD PTR [rsi+0x8] >>> 0x00007f2fb1168444: movabs r12,0x800000000 >>> 0x00007f2fb116844e: add r10,r12 >>> 0x00007f2fb1168451: xor r12,r12 >>> 0x00007f2fb1168454: cmp rax,r10 >>> 0x00007f2fb1168457: jne 0x00007f2fb104d6a0 ; {runtime_call ic_miss_stub} >>> 0x00007f2fb116845d: nop >>> 0x00007f2fb116845e: nop >>> 0x00007f2fb116845f: nop >>> [Verified Entry Point] >>> ;; B1: # B54 B2 <- BLOCK HEAD IS JUNK Freq: 1 >>> >>> >>> 0x00007f2fb1168460: mov DWORD PTR [rsp-0x16000],eax >>> 0x00007f2fb1168467: push rbp >>> 0x00007f2fb1168468: sub rsp,0x30 ;*synchronization entry >>> ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at -1 >>> (line 877) >>> >>> >>> 0x00007f2fb116846c: mov r10,rsi >>> 0x00007f2fb116846f: mov r9,rcx >>> 0x00007f2fb1168472: mov edi,DWORD PTR [rcx+0xc] ;*getfield value >>> {reexecute=0 rethrow=0 return_oop=0} >>> ; - java.lang.String::length at 1 (line 658) >>> ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at 1 >>> (line 877) >>> ; implicit exception: dispatches to 0x00007f2fb116872a >>> ;; B2: # B55 B3 <- B1 Freq: 0.999999 >>> >>> >>> Now you only get this, even in a debug build: >>> >>> >>> 0x00007ff1c5176c20: mov r10d,DWORD PTR [rsi+0x8] >>> 0x00007ff1c5176c24: movabs r12,0x800000000 >>> 0x00007ff1c5176c2e: add r10,r12 >>> 0x00007ff1c5176c31: xor r12,r12 >>> 0x00007ff1c5176c34: cmp rax,r10 >>> 0x00007ff1c5176c37: jne 0x00007ff1c5113da0 >>> 0x00007ff1c5176c3d: nop >>> 0x00007ff1c5176c3e: nop >>> 0x00007ff1c5176c3f: nop >>> 0x00007ff1c5176c40: mov DWORD PTR [rsp-0x16000],eax >>> 0x00007ff1c5176c47: push rbp >>> 0x00007ff1c5176c48: sub rsp,0x30 >>> 0x00007ff1c5176c4c: mov r11,rsi >>> 0x00007ff1c5176c4f: mov r9,rcx >>> 0x00007ff1c5176c52: mov r10d,DWORD PTR [rcx+0xc] >>> >>> >>> There are no comments at all, just raw disassembly. >>> >>> >>> This patch restores the status quo ante: >>> >>> >>> # {method} {0x00007f9f53c2e3c0} 'decodeModuleName' >>> '(ILjava/lang/String;)Ljava/lang/String;' in >>> 'jdk/internal/module/ModuleInfo$ConstantPool' >>> # this: rsi:rsi = 'jdk/internal/module/ModuleInfo$ConstantPool' >>> # parm0: rdx = int >>> # parm1: rcx:rcx = 'java/lang/String' >>> # [sp+0x40] (sp of caller) >>> ;; N551: # out( B1 ) <- BLOCK HEAD IS JUNK Freq: 1 >>> 0x00007f9fb4d64620: mov r10d,DWORD PTR [rsi+0x8] >>> 0x00007f9fb4d64624: movabs r12,0x800000000 >>> 0x00007f9fb4d6462e: add r10,r12 >>> 0x00007f9fb4d64631: xor r12,r12 >>> 0x00007f9fb4d64634: cmp rax,r10 >>> 0x00007f9fb4d64637: jne 0x00007f9fb4cfeda0 ; >>> {runtime_call ic_miss_stub} >>> 0x00007f9fb4d6463d: nop >>> 0x00007f9fb4d6463e: nop >>> 0x00007f9fb4d6463f: nop >>> [Verified Entry Point] >>> ;; B1: # out( B55 B2 ) <- BLOCK HEAD IS JUNK Freq: 1 >>> 0x00007f9fb4d64640: mov DWORD PTR [rsp-0x16000],eax >>> 0x00007f9fb4d64647: push rbp >>> 0x00007f9fb4d64648: sub rsp,0x30 >>> ;*synchronization entry >>> ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at -1 >>> (line 876) >>> 0x00007f9fb4d6464c: mov r11,rsi >>> 0x00007f9fb4d6464f: mov r9,rcx >>> 0x00007f9fb4d64652: mov r10d,DWORD PTR [rcx+0xc] ;*getfield >>> value {reexecute=0 rethrow=0 return_oop=0} ; - >>> java.lang.String::length at 1 (line 673) >>> ; - jdk.internal.module.ModuleInfo$ConstantPool::decodeModuleName at 1 >>> (line 876) >>> ; implicit exception: dispatches to 0x00007f9fb4d648fe >>> ;; B2: # out( B56 B3 ) <- in( B1 ) Freq: 0.999999 >>> >>> >> >> >> > > From john.r.rose at oracle.com Fri Jun 7 20:30:28 2019 From: john.r.rose at oracle.com (John Rose) Date: Fri, 7 Jun 2019 13:30:28 -0700 Subject: 8225429: Regression in disassembly quality In-Reply-To: <439421A8-8629-47E8-AF18-FB29EEA6659E@sap.com> References: <8818B65C-E697-462F-870F-DFBE3F62A58D@sap.com> <21f684a7cee3f523354e738bbc353884.squirrel@excalibur.xssl.net> <2544879C-CCC8-4383-A4B3-9C09AD4CD065@kodewerk.com> <439421A8-8629-47E8-AF18-FB29EEA6659E@sap.com> Message-ID: On Jun 7, 2019, at 12:11 PM, Schmidt, Lutz wrote: > > The "big" solution would be to print/disassemble all nmethods in the code heap at failure time. That functionality doesn't exist yet. Yes, that's a good vision, and it's worth an RFE or a JEP. Because of security concerns (noted on other threads today), that function should be opt-in and should place its gigantic output into a separate file from hs_err. From lutz.schmidt at sap.com Sun Jun 9 19:20:23 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Sun, 9 Jun 2019 19:20:23 +0000 Subject: 8225429: Regression in disassembly quality In-Reply-To: References: <8818B65C-E697-462F-870F-DFBE3F62A58D@sap.com> <21f684a7cee3f523354e738bbc353884.squirrel@excalibur.xssl.net> <2544879C-CCC8-4383-A4B3-9C09AD4CD065@kodewerk.com> <439421A8-8629-47E8-AF18-FB29EEA6659E@sap.com>, Message-ID: <6839DCB3-5BCE-49FB-B018-EEE066A561B4@sap.com> Hey John, You just put another work item on my list. :-) I agree, you wouldn?t want that in hs_err. Regards, Lutz Lutz Schmidt | P&I Technology HCP Core | +49 (6227) 7-42834 On 7. Jun 2019, at 22:31, John Rose wrote: > On Jun 7, 2019, at 12:11 PM, Schmidt, Lutz wrote: > > The "big" solution would be to print/disassemble all nmethods in the code heap at failure time. That functionality doesn't exist yet. Yes, that's a good vision, and it's worth an RFE or a JEP. Because of security concerns (noted on other threads today), that function should be opt-in and should place its gigantic output into a separate file from hs_err. From david.holmes at oracle.com Mon Jun 10 07:15:58 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 10 Jun 2019 17:15:58 +1000 Subject: RFC: JWarmup precompile java hot methods at application startup In-Reply-To: References: <8cfbaa83-c50f-61c4-5336-5f30b3885d45@oracle.com> Message-ID: <26f88253-deea-64d5-714c-28bb73989c62@oracle.com> Hi Yumin, On 8/06/2019 3:25 am, yumin qi wrote: > Hi, David and all > > ? Can I have one more comment from runtime expert for the JEP? > ? David, can you comment for the changes? Really appreciate your last > comment. It is best if you follow the comment. > ? Looking forward to having your comment. I still have a lot of trouble understanding the overall design here. The JEP is very high-level; the webrev is very low-level; and there's nothing in between to explain the details of the design - the kind of document you would produce for a design review/walkthrough. For example I can't see why you need to record the "source file"; I can't see why you need to make changes to the superclass resolution. I can't tell when changes outside of Jwarmup may need to make changes to the Jwarmup code - the dependencies are unclear. I'm unclear on the role of the "dummy method" - is it just a sentinel? Why do we need it versus using some state in the JitWarmup instance? Some further code comments, but not a file by file review by any means ... The code split between the JDK and JVM doesn't seem quite right to me. registerNatives is something usually done by the JDK .c files corresponding to the classes defining the native method; it's not something done in jvm.cpp. Or if this is meant to be a special case like JVM_RegisterMethodHandleMethods then probably it should be in the jwarmup.cpp file. Also if you pass the necessary objects through the API you won't need to jump back to native to call a JNI function. AliasedLoggingFlags are for converting legacy flags to unified logging. You should just be using UL and not introducing the PrintCompilationWarmUpDetail psuedo-flag. This work introduces thirteen new VM flags! That's very excessive. Perhaps you should look at defining something more like -Xlog that encodes all the options? (And this will need a very lengthy CSR request!). The init.cpp code should be factored out into jwarmup_init functions in jwarmup.cpp. Mutex initialization should be conditional on jwarmup being enabled. Deoptimization has been changed lately to avoid use of safepoints so you may need to re-examine that aspect. You have a number of uses of patterns like this (but not everywhere): + JitWarmUp* jwp = JitWarmUp::instance(); + assert(jwp != NULL, "sanity check"); + jwp->preloader()->jvm_booted_is_done(); The assertion should be inside instance() so that these collapse to a single line: JitWarmup::instance()->preloader->whatever(); Your Java files have @version 1.8. --- Cheers, David ----- > Thanks > Yumin > > On Sun, May 19, 2019 at 10:28 AM yumin qi > wrote: > > Hi, Tobias and all > ? Have done changes based on Tobias' comments.? New webrev based on > most recent base is updated at: > http://cr.openjdk.java.net/~minqi/8220692/webrev-03/ > > ? ?Tested local for jwarmup and compiler. > > ? Thanks > ? Yumin > > On Tue, May 14, 2019 at 11:26 AM yumin qi > wrote: > > HI, Tobias > > ? Thanks very much for the comments. > > On Mon, May 13, 2019 at 2:58 AM Tobias Hartmann > > > wrote: > > Hi Yumin, > > > In this version, the profiled method data is not used at > > precomilation, it will be addressed in followed bug fix. > After the > > first version integrated, will file bug for it. > > Why is that? I think it would be good to have everything in > one JEP. > > > We have done some tests on adding profiling data and found the > result is not as expected, and the current version is working > well for internal online applications. There is no other reason > not adding to this patch now, we will like to study further to > see if we can improve that for a better performance. > > I've looked at the compiler related changes. Here are some > comments/questions. > > ciMethod.cpp > - So CompilationWarmUp is not using any profile information? > Not even the profile obtained in the > current execution? > > > Yes. This is also related to previous question. > > compile.cpp > - line 748: Why is that required? Couldn't it happen that a > method is never compiled because the > code that would resolve a field is never executed? > > > Here a very aggressive decision --- to avoid compilation failure > requires that all fields have already been resolved. > > graphKit.cpp > - line 2832: please add a comment > - line 2917: checks should be merged into one if and please > add a comment > > > Will fix it. > > jvm.cpp > - Could you explain why it's guaranteed that warmup > compilation is completed once the dummy method > is compiled? And why is it hardcoded to print > "com.alibaba.jwarmup.JWarmUp"? > > > This is from practical testing of real applications. Due to the > parallelism of compilation works, it? should check if > compilation queue contains any of those methods --- completed if > no any of them on the queue and it is not economic. By using of > a dummy method as a simplified version for that, in real case, > it is not observed that dummy method is not the last compilation > for warmup. Do you have suggestion of a way to do that? The > dummy way is not strictly a guaranteed one theoretically. > Forgot to change the print to new name after renaming package, > thanks for the catching. > > - What is test_symbol_matcher() used for? > > > This is a leftover(used to test matching patterns), will remove > it from the file. > > jitWarmUp.cpp: > - line 146: So what about methods that are only ever > compiled at C1 level? Wouldn't it make sense to > keep track of the comp_level during CompilationWarmUpRecording? > > > Will consider your suggestion in future work on it. > > I also found several typos while reading through the code > (listed in random order): > > globals.hpp > - "flushing profling" -> "flushing profiling" > > method.hpp > - "when this method first been invoked" > > templateInterpreterGenerator_x86.cpp > - initializition -> initialization > > dict.cpp > - initializated -> initialized > > jitWarmUp.cpp > - uninitilaized -> uninitialized > - inited -> should be initialized, right? > > jitWarmUp.hpp > . nofityApplicationStartUpIsDone -> > notifyApplicationStartUpIsDone > > constantPool.cpp > - recusive -> recursive > > JWarmUp.java > - appliacation -> application > > TestThrowInitializaitonException.java -> > TestThrowInitializationException.java > > These tests should be renamed (it's not clear what issue the > number refers to): > - issue9780156.sh > - Issue11272598.java > > > Will fix all above suggestions. > > Thanks! > > Yumin > From aph at redhat.com Mon Jun 10 09:29:41 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 10 Jun 2019 10:29:41 +0100 Subject: RFR: 8225429: Regression in disassembly quality In-Reply-To: <40ba5e78-51e7-e628-a765-f4348ba4befb@oracle.com> References: <60b89a4f-655c-d5f8-7d6b-9532c865bba7@redhat.com> <7ae9dcac-e7d9-5989-1ae7-3743c9775dc9@redhat.com> <78005969-b342-6024-5ce1-031045df8d2d@oracle.com> <12ce99b1-25bd-b965-a3d9-befba0e1d3d3@redhat.com> <40ba5e78-51e7-e628-a765-f4348ba4befb@oracle.com> Message-ID: On 6/7/19 6:31 PM, Tom Rodriguez wrote: >>> I think your current patch is good given how broken it currently is. So >>> I approve of your current patch, though I would like to see your new >>> defaults abstractDisassembler.cpp apply product as well so it always >>> looks the same as it used to. >> >> OK, I'll have a look at what product did. > > I think it would be the same as what you added for non-product, so you > new block settings completely replaces the old settings. I don't think > there should be any difference between product and non-product in terms > of what's emitted by disassembly. Which I think was the gist of John's > comment. Sure, I get that, but there are other issues. In particular, code comments are disabled in product by macros such as #ifdef PRODUCT #define BLOCK_COMMENT(str) /* nothing */ #define STOP(error) stop(error) #else #define BLOCK_COMMENT(str) block_comment(str) #define STOP(error) block_comment(error); stop(error) #endif I have no idea why these macros exist: unless debugging is enabled code comments are gated by void CodeBuffer::block_comment(intptr_t offset, const char * comment) { if (_collect_comments) { _code_strings.add_comment(offset, comment); Maybe this is just historical baggage or it's a micro-optimization to save space and a few machine cycles. Anyway, I pushed http://cr.openjdk.java.net/~aph/8225429-2/ to jdk-submit. This sets the default for both product and debug builds the same. If it passes I'll push it to jdk-jdk. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From stefan.karlsson at oracle.com Mon Jun 10 09:34:44 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 10 Jun 2019 11:34:44 +0200 Subject: RFR: 8213415: BitMap::word_index_round_up overflow problems In-Reply-To: <24C2BDC9-AC35-4804-95C8-1B59747C1494@oracle.com> References: <24C2BDC9-AC35-4804-95C8-1B59747C1494@oracle.com> Message-ID: <5bd19480-d570-b73d-70fe-10e93ef2ecb8@oracle.com> http://cr.openjdk.java.net/~kbarrett/8213415/open.00/src/hotspot/share/utilities/bitMap.cpp.udiff.html template BitMap::bm_word_t* BitMap::reallocate(const Allocator& allocator, bm_word_t* old_map, idx_t old_size_in_bits, idx_t new_size_in_bits, bool clear) { + verify_max_size_limited(new_size_in_bits); size_t old_size_in_words = calc_size_in_words(old_size_in_bits); size_t new_size_in_words = calc_size_in_words(new_size_in_bits); calc_size_in_words also calls verify_max_size_limited, so maybe skip adding it here? ---------- +void BitMap::verify_max_size_limited(idx_t bit) { + assert(bit <= max_size_in_bits(), "out of bounds: " SIZE_FORMAT, bit); +} Is the intention to verify that a 'size' is less than or equal to the 'max possible size'? If that's the case, then I think it would be better to use the name size_in_bits. Just like we do for our constructors, allocators, and initializers. Or is this actually meant to check that bit indices are within the max range? If that's the case, then why are we using <= instead of < ? (More about this below) ---------- void BitMap::verify_range(idx_t beg_index, idx_t end_index) const { assert(beg_index <= end_index, "BitMap range error"); // Note that [0,0) and [size,size) are both valid ranges. - if (end_index != _size) verify_index(end_index); + assert(end_index <= _size, "BitMap range out of bounds"); } This allowance to have beg_index outside of the bit range seems dubious to me. It's not something you changed, but I preferred that the old code was explicit that there was an odd special case involved. ========== http://cr.openjdk.java.net/~kbarrett/8213415/open.00/src/hotspot/share/utilities/bitMap.cpp.udiff.html inline BitMap::idx_t BitMap::word_index_round_up(idx_t bit) const { - idx_t bit_rounded_up = bit + (BitsPerWord - 1); - // Check for integer arithmetic overflow. - return bit_rounded_up > bit ? word_index(bit_rounded_up) : size_in_words(); + return calc_size_in_words(bit); } It's not intuitive why word_index_round_up can be implemented with a calc_size_in_words call. I now understand why you had the <= check and 'bit' name in verify_max_size_limited. I would at least have wanted this check in word_index_round_up: assert(bit < max_size_in_bits(), "OOB"); but I fear that it won't work in the cases where beg' is the argument: verify_range(beg, end); idx_t beg_full_word = word_index_round_up(beg); idx_t end_full_word = word_index(end); and verify_range accepts a beg outside of the bit range, so word_index_round_up could actually be called with an OOB bit. With that said, could we turn this the other way around?: BitMap::idx_t BitMap::word_index_round_up(idx_t bit) const { assert(bit <= max_size_in_bits(), "OOB"); return word_index(bit + (BitsPerWord - 1)); } static idx_t calc_size_in_words(idx_t size_in_bits) { return word_index_round_up(size_in_bits); } It's almost what the code used to look like: - static idx_t calc_size_in_words(size_t size_in_bits) { - return word_index(size_in_bits + BitsPerWord - 1); - } Thanks, StefanK On 2019-05-28 20:10, Kim Barrett wrote: > Please review this change to BitMap index alignment to check for > overflows (in debug builds). Also made a few related API cleanups. > > Constructing a BitMap now ensures the size is such that rounding it up > to a word boundary won't overflow. This is the new max_size_in_bits() > value. This lets us add some asserts and otherwise tidy things up in > some places by making use of that information. > > This engendered some changes to ParallelGC's ParMarkBitMap. It no > longer uses the obsolete BitMap::word_align_up, instead having its own > internal helper for aligning range ends that knows about invariants in > ParMarkBitMap. > > Removed the following static functions from BitMap: word_align_up, > word_align_down, and is_word_aligned. word_align_up is no longer > used, after the ParMarkBitMap changes. The others were only used in a > small number of places in tests and asserts, and didn't seem worth > keeping instead of just using align.hpp stuff with BitsPerWord > alignment value. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8213415 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8213415/open.00/ > > Testing: > mach5 tier1-3 > From aph at redhat.com Mon Jun 10 11:41:17 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 10 Jun 2019 12:41:17 +0100 Subject: 8225429: Regression in disassembly quality In-Reply-To: <439421A8-8629-47E8-AF18-FB29EEA6659E@sap.com> References: <8818B65C-E697-462F-870F-DFBE3F62A58D@sap.com> <21f684a7cee3f523354e738bbc353884.squirrel@excalibur.xssl.net> <2544879C-CCC8-4383-A4B3-9C09AD4CD065@kodewerk.com> <439421A8-8629-47E8-AF18-FB29EEA6659E@sap.com> Message-ID: <2a1ed0d1-4c6c-dfa2-08e2-8e172fc2f3c3@redhat.com> ?On 07.06.19, 17:50, "Kodewerk" wrote: > I was just recently dealing with a JVM crash caused by C2 > compilation missing a barrier. It only showed up on certain > production system which could never be replicated in a test > environment. Having a full print assembly in that situation wasn?t a > great option. Although there is an obscure way to get the assembly > for a single method it would be great if there was better ways to > easily target specific compilation events. What do you mean? It's not difficult or obscure to add print java.lang::Object to .hotspot_compiler. I don't know how we could make it simpler; perhaps we could document it better. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Jun 10 11:59:10 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 10 Jun 2019 12:59:10 +0100 Subject: RFR: 8225429: Regression in disassembly quality In-Reply-To: References: <60b89a4f-655c-d5f8-7d6b-9532c865bba7@redhat.com> Message-ID: <7cb59bb3-9890-17d1-2823-52d8778f71cf@redhat.com> On 6/6/19 9:22 PM, John Rose wrote: > Effective diagnosis and performance tuning requires accurate, > informative disassembly. I would support [enabling] the assembler > comment capture, whenever disassembly is enabled. If there's a risk > of disturbing program dynamics with the extra footprint, perhaps it > could be broken out as a separate diagnostic option. > > More disassembly information is better, even in product mode! OK, I'll look at that. There are multiple issues with assembler comments, so I'll try to collect them up. If we're not to slow down code generation we'll need a fast test-and-branch so that we can gate assembler comment capture. That shouldn't be too hard. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ioi.lam at oracle.com Mon Jun 10 17:15:45 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 10 Jun 2019 10:15:45 -0700 Subject: 8225429: Regression in disassembly quality In-Reply-To: <6839DCB3-5BCE-49FB-B018-EEE066A561B4@sap.com> References: <8818B65C-E697-462F-870F-DFBE3F62A58D@sap.com> <21f684a7cee3f523354e738bbc353884.squirrel@excalibur.xssl.net> <2544879C-CCC8-4383-A4B3-9C09AD4CD065@kodewerk.com> <439421A8-8629-47E8-AF18-FB29EEA6659E@sap.com> <6839DCB3-5BCE-49FB-B018-EEE066A561B4@sap.com> Message-ID: On 6/9/19 12:20 PM, Schmidt, Lutz wrote: > Hey John, > > You just put another work item on my list. :-) > > I agree, you wouldn?t want that in hs_err. > > Regards, Lutz > > Lutz Schmidt | P&I Technology HCP Core | +49 (6227) 7-42834 > > On 7. Jun 2019, at 22:31, John Rose wrote: > >> On Jun 7, 2019, at 12:11 PM, Schmidt, Lutz wrote: >> >> The "big" solution would be to print/disassemble all nmethods in the code heap at failure time. That functionality doesn't exist yet. > Yes, that's a good vision, and it's worth an RFE or a JEP. > > Because of security concerns (noted on other threads today), > that function should be opt-in and should place its gigantic > output into a separate file from hs_err. > If the failure produces a core file, you can attach to it using the serviceablility agent. I wonder if SA allows you to disassemble the nmethods with comments. That seems better than dumping tons of stuff into a text file. From tom.rodriguez at oracle.com Mon Jun 10 17:33:24 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 10 Jun 2019 10:33:24 -0700 Subject: RFR: 8225429: Regression in disassembly quality In-Reply-To: References: <60b89a4f-655c-d5f8-7d6b-9532c865bba7@redhat.com> <7ae9dcac-e7d9-5989-1ae7-3743c9775dc9@redhat.com> <78005969-b342-6024-5ce1-031045df8d2d@oracle.com> <12ce99b1-25bd-b965-a3d9-befba0e1d3d3@redhat.com> <40ba5e78-51e7-e628-a765-f4348ba4befb@oracle.com> Message-ID: > Sure, I get that, but there are other issues. In particular, code comments > are disabled in product by macros such as > > #ifdef PRODUCT > #define BLOCK_COMMENT(str) /* nothing */ > #define STOP(error) stop(error) > #else > #define BLOCK_COMMENT(str) block_comment(str) > #define STOP(error) block_comment(error); stop(error) > #endif > > I have no idea why these macros exist: unless debugging is enabled code > comments are gated by > > void CodeBuffer::block_comment(intptr_t offset, const char * comment) { > if (_collect_comments) { > _code_strings.add_comment(offset, comment); > > Maybe this is just historical baggage or it's a micro-optimization to > save space and a few machine cycles. The block comment support definitely went through many iterations and tweaks. The ifdef's seem to be about binary size since the actual recording support was already disabled in product. Though that seems like a pretty micro-optimization. Block comment recording should probably be under a flag since it stores a bunch of extra strings associated with the code blobs which is completely unnecessary unless you are printing. It would cool if it could be driven by PrintNMethods/PrintAssembly/PrintStubCode but having a separate flag might be more convenient. Anyway, as you say there are some issues to be teased out in enabling block comments all the time. > > Anyway, I pushed http://cr.openjdk.java.net/~aph/8225429-2/ to > jdk-submit. This sets the default for both product and debug builds > the same. > > If it passes I'll push it to jdk-jdk. Sounds good to me. tom From aph at redhat.com Mon Jun 10 17:45:01 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 10 Jun 2019 18:45:01 +0100 Subject: RFR: 8225429: Regression in disassembly quality In-Reply-To: References: <60b89a4f-655c-d5f8-7d6b-9532c865bba7@redhat.com> <7ae9dcac-e7d9-5989-1ae7-3743c9775dc9@redhat.com> <78005969-b342-6024-5ce1-031045df8d2d@oracle.com> <12ce99b1-25bd-b965-a3d9-befba0e1d3d3@redhat.com> <40ba5e78-51e7-e628-a765-f4348ba4befb@oracle.com> Message-ID: <6bf60a23-8c01-ed9a-b173-3705cd155127@redhat.com> On 6/10/19 6:33 PM, Tom Rodriguez wrote: >> Sure, I get that, but there are other issues. In particular, code comments >> are disabled in product by macros such as >> >> #ifdef PRODUCT >> #define BLOCK_COMMENT(str) /* nothing */ >> #define STOP(error) stop(error) >> #else >> #define BLOCK_COMMENT(str) block_comment(str) >> #define STOP(error) block_comment(error); stop(error) >> #endif >> >> I have no idea why these macros exist: unless debugging is enabled code >> comments are gated by >> >> void CodeBuffer::block_comment(intptr_t offset, const char * comment) { >> if (_collect_comments) { >> _code_strings.add_comment(offset, comment); >> >> Maybe this is just historical baggage or it's a micro-optimization to >> save space and a few machine cycles. > > The block comment support definitely went through many iterations and > tweaks. The ifdef's seem to be about binary size since the actual > recording support was already disabled in product. Though that seems > like a pretty micro-optimization. Today, yes, I think it probably is, and sustainable engineering would win if we had another look. > Block comment recording should probably be under a flag since it > stores a bunch of extra strings associated with the code blobs which > is completely unnecessary unless you are printing. It would cool if > it could be driven by PrintNMethods/PrintAssembly/PrintStubCode but > having a separate flag might be more convenient. Anyway, as you say > there are some issues to be teased out in enabling block comments > all the time. Yes. I definitely intend to do some more in this area. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From igor.ignatyev at oracle.com Mon Jun 10 21:18:01 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 10 Jun 2019 14:18:01 -0700 Subject: RFR(T) : 8209917 : fix TODO in GatherDiagnosticInfoObserver In-Reply-To: <884B83E5-38CE-46CD-8304-585005660F22@oracle.com> References: <884B83E5-38CE-46CD-8304-585005660F22@oracle.com> Message-ID: ping. > On Jun 5, 2019, at 6:46 PM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8209917/webrev.00/index.html >> 11 lines changed: 0 ins; 3 del; 8 mod; > > Hi all, > > could you please review this small and trivial clean up in failure_handler library? > > webrev: http://cr.openjdk.java.net/~iignatyev//8209917/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8209917 > testing: make test TEST=failure-handler; tier1 > > Thanks, > -- Igor From john.r.rose at oracle.com Mon Jun 10 23:03:32 2019 From: john.r.rose at oracle.com (John Rose) Date: Mon, 10 Jun 2019 16:03:32 -0700 Subject: RFR: 8225429: Regression in disassembly quality In-Reply-To: References: <60b89a4f-655c-d5f8-7d6b-9532c865bba7@redhat.com> <7ae9dcac-e7d9-5989-1ae7-3743c9775dc9@redhat.com> <78005969-b342-6024-5ce1-031045df8d2d@oracle.com> <12ce99b1-25bd-b965-a3d9-befba0e1d3d3@redhat.com> <40ba5e78-51e7-e628-a765-f4348ba4befb@oracle.com> Message-ID: <1C80636C-1E0C-4E8D-8EDB-564492AF0962@oracle.com> On Jun 10, 2019, at 2:29 AM, Andrew Haley wrote: > > Maybe this is just historical baggage or it's a micro-optimization to > save space and a few machine cycles. All of the above. I suppose due diligence to undo the micro-optimization should include noting the static size change in the product build. It might be as much as a kilobyte, which would still be in the noise. I don't think the cycle count change is enough to be measurable. ? John From david.holmes at oracle.com Mon Jun 10 23:19:45 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Jun 2019 09:19:45 +1000 Subject: RFR(T) : 8209917 : fix TODO in GatherDiagnosticInfoObserver In-Reply-To: References: <884B83E5-38CE-46CD-8304-585005660F22@oracle.com> Message-ID: Hi Igor, It may be marginally more efficient to replace the pattern: xxxJdk = Paths.get(rp.getXXXJDK().getAbsolutePath()); with xxxJdk = rp.getXXXJDK().getAbsoluteFile().toPath(); to avoid switching to/from string representations. Thanks, David On 11/06/2019 7:18 am, Igor Ignatyev wrote: > ping. > >> On Jun 5, 2019, at 6:46 PM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev//8209917/webrev.00/index.html >>> 11 lines changed: 0 ins; 3 del; 8 mod; >> >> Hi all, >> >> could you please review this small and trivial clean up in failure_handler library? >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8209917/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8209917 >> testing: make test TEST=failure-handler; tier1 >> >> Thanks, >> -- Igor > From jonathan.gibbons at oracle.com Mon Jun 10 23:27:54 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 10 Jun 2019 16:27:54 -0700 Subject: RFR(T) : 8209917 : fix TODO in GatherDiagnosticInfoObserver In-Reply-To: References: <884B83E5-38CE-46CD-8304-585005660F22@oracle.com> Message-ID: <41fa3e83-ff96-69fe-7799-ddb77c5257c7@oracle.com> OK from the jtreg perspective, but I don't normally review Hotspot files, and so I should not be the only Reviewer on the changeset. -- Jon On 06/10/2019 02:18 PM, Igor Ignatyev wrote: > ping. > >> On Jun 5, 2019, at 6:46 PM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev//8209917/webrev.00/index.html >>> 11 lines changed: 0 ins; 3 del; 8 mod; >> Hi all, >> >> could you please review this small and trivial clean up in failure_handler library? >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8209917/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8209917 >> testing: make test TEST=failure-handler; tier1 >> >> Thanks, >> -- Igor From igor.ignatyev at oracle.com Tue Jun 11 00:03:50 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 10 Jun 2019 17:03:50 -0700 Subject: RFR(T) : 8209917 : fix TODO in GatherDiagnosticInfoObserver In-Reply-To: References: <884B83E5-38CE-46CD-8304-585005660F22@oracle.com> Message-ID: <3E81018E-E6A0-4563-A446-DED52E9550CC@oracle.com> Hi David, thanks for reviewing this. I'll update the patch accordingly to your comment before pushing. -- Igor > On Jun 10, 2019, at 4:19 PM, David Holmes wrote: > > Hi Igor, > > It may be marginally more efficient to replace the pattern: > > xxxJdk = Paths.get(rp.getXXXJDK().getAbsolutePath()); > > with > > xxxJdk = rp.getXXXJDK().getAbsoluteFile().toPath(); > > to avoid switching to/from string representations. > > Thanks, > David > > On 11/06/2019 7:18 am, Igor Ignatyev wrote: >> ping. >>> On Jun 5, 2019, at 6:46 PM, Igor Ignatyev wrote: >>> >>> http://cr.openjdk.java.net/~iignatyev//8209917/webrev.00/index.html >>>> 11 lines changed: 0 ins; 3 del; 8 mod; >>> >>> Hi all, >>> >>> could you please review this small and trivial clean up in failure_handler library? >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev//8209917/webrev.00/index.html >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8209917 >>> testing: make test TEST=failure-handler; tier1 >>> >>> Thanks, >>> -- Igor From igor.ignatyev at oracle.com Tue Jun 11 00:08:31 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 10 Jun 2019 17:08:31 -0700 Subject: RFR(T) : 8209917 : fix TODO in GatherDiagnosticInfoObserver In-Reply-To: <41fa3e83-ff96-69fe-7799-ddb77c5257c7@oracle.com> References: <884B83E5-38CE-46CD-8304-585005660F22@oracle.com> <41fa3e83-ff96-69fe-7799-ddb77c5257c7@oracle.com> Message-ID: Hi Jon, thanks a lot for reviewing this! I've also got a review from David H. -- Igor > On Jun 10, 2019, at 4:27 PM, Jonathan Gibbons wrote: > > OK from the jtreg perspective, but I don't normally review Hotspot files, and so I should not be the only Reviewer on the changeset. > > -- Jon > > > On 06/10/2019 02:18 PM, Igor Ignatyev wrote: >> ping. >> >>> On Jun 5, 2019, at 6:46 PM, Igor Ignatyev wrote: >>> >>> http://cr.openjdk.java.net/~iignatyev//8209917/webrev.00/index.html >>>> 11 lines changed: 0 ins; 3 del; 8 mod; >>> Hi all, >>> >>> could you please review this small and trivial clean up in failure_handler library? >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev//8209917/webrev.00/index.html >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8209917 >>> testing: make test TEST=failure-handler; tier1 >>> >>> Thanks, >>> -- Igor > From kim.barrett at oracle.com Tue Jun 11 01:14:22 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 10 Jun 2019 21:14:22 -0400 Subject: RFR: 8213415: BitMap::word_index_round_up overflow problems In-Reply-To: <5bd19480-d570-b73d-70fe-10e93ef2ecb8@oracle.com> References: <24C2BDC9-AC35-4804-95C8-1B59747C1494@oracle.com> <5bd19480-d570-b73d-70fe-10e93ef2ecb8@oracle.com> Message-ID: <3F4F27AC-4812-4E55-99DF-25F0A7BD991D@oracle.com> > On Jun 10, 2019, at 5:34 AM, Stefan Karlsson wrote: Thanks for looking at this. > http://cr.openjdk.java.net/~kbarrett/8213415/open.00/src/hotspot/share/utilities/bitMap.cpp.udiff.html > > template > BitMap::bm_word_t* BitMap::reallocate(const Allocator& allocator, bm_word_t* old_map, idx_t old_size_in_bits, idx_t new_size_in_bits, bool clear) { > + verify_max_size_limited(new_size_in_bits); > size_t old_size_in_words = calc_size_in_words(old_size_in_bits); > size_t new_size_in_words = calc_size_in_words(new_size_in_bits); > > calc_size_in_words also calls verify_max_size_limited, so maybe skip adding it here? Good point. Done. > ---------- > > +void BitMap::verify_max_size_limited(idx_t bit) { > + assert(bit <= max_size_in_bits(), "out of bounds: " SIZE_FORMAT, bit); > +} > > Is the intention to verify that a 'size' is less than or equal to the 'max possible size'? If that's the case, then I think it would be better to use the name size_in_bits. Just like we do for our constructors, allocators, and initializers. > > Or is this actually meant to check that bit indices are within the max range? If that's the case, then why are we using <= instead of < ? > > (More about this below) [Clipped the ?more below?] Your comments made me rethink some things, some of which I'd not been entirely happy with anyway. verify_max_size_limited is now called verify_valid_size, and is only used for sizes, not for range boundaries. word_index_round_up has been entirely eliminated. Instead, there is a new internal API used by the range operations: range_begin_align_up, range_end_align_down, with is_small_range_of_words replaced by is_small_aligned_range. This required some fairly mechanical updates to the implementations of the large range operations. Fortunately, there are already gtests in this area, from JDK-8211926. I think this tidies things up quite a bit, and hope it addresses your issues. Looking at this also reminded me of some discussion from JDK-8211926 that apparently nobody got around to filing REFs for, so I've done that. JDK-8225546 Cleanup BitMap index types JDK-8225547 Improve BitMap large range handling > void BitMap::verify_range(idx_t beg_index, idx_t end_index) const { > assert(beg_index <= end_index, "BitMap range error"); > // Note that [0,0) and [size,size) are both valid ranges. > - if (end_index != _size) verify_index(end_index); > + assert(end_index <= _size, "BitMap range out of bounds"); > } > > This allowance to have beg_index outside of the bit range seems dubious to me. It's not something you changed, but I preferred that the old code was explicit that there was an odd special case involved. I made this change because I found the old code confusing; I had to think about it to decide it really would assert iff the range was invalid. Also, the old error is confusing since the end of a range is not an index. (Further checking is required for use as an index.) The change makes the implementation directly correspond to the definition of a valid range, e.g. 0 <= begin <= end <= size. (With the negative case impossible because of an unsigned type.) new webrevs: full: http://cr.openjdk.java.net/~kbarrett/8213415/open.01/ incr: http://cr.openjdk.java.net/~kbarrett/8213415/open.01.inc/ From kim.barrett at oracle.com Tue Jun 11 01:28:44 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 10 Jun 2019 21:28:44 -0400 Subject: RFR: 8213415: BitMap::word_index_round_up overflow problems In-Reply-To: <3F4F27AC-4812-4E55-99DF-25F0A7BD991D@oracle.com> References: <24C2BDC9-AC35-4804-95C8-1B59747C1494@oracle.com> <5bd19480-d570-b73d-70fe-10e93ef2ecb8@oracle.com> <3F4F27AC-4812-4E55-99DF-25F0A7BD991D@oracle.com> Message-ID: > On Jun 10, 2019, at 9:14 PM, Kim Barrett wrote: >> void BitMap::verify_range(idx_t beg_index, idx_t end_index) const { >> assert(beg_index <= end_index, "BitMap range error"); >> // Note that [0,0) and [size,size) are both valid ranges. >> - if (end_index != _size) verify_index(end_index); >> + assert(end_index <= _size, "BitMap range out of bounds"); >> } >> >> This allowance to have beg_index outside of the bit range seems dubious to me. It's not something you changed, but I preferred that the old code was explicit that there was an odd special case involved. > > I made this change because I found the old code confusing; I had to > think about it to decide it really would assert iff the range was > invalid. Also, the old error is confusing since the end of a range is > not an index. (Further checking is required for use as an index.) The > change makes the implementation directly correspond to the definition > of a valid range, e.g. 0 <= begin <= end <= size. (With the negative > case impossible because of an unsigned type.) But maybe I should have also removed the not actually helpful comment. From david.holmes at oracle.com Tue Jun 11 11:29:15 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Jun 2019 21:29:15 +1000 Subject: RFR (Trivial) 8225568: ProblemList compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java Message-ID: <89f76c21-215a-852c-c48f-31d4091cf650@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8225568 webrev: http://cr.openjdk.java.net/~dholmes/8225568/webrev/ Related issue: https://bugs.openjdk.java.net/browse/JDK-8225370 Patch below. This test was removed from the ProblemList by JDK-8222103 and has continually failed since in our testing. The test had not previously been run for several years and its condition is unknown. So re-adding it to the ProblemList until it can be properly examined. Thanks, David ----- --- old/test/hotspot/jtreg/ProblemList.txt 2019-06-11 07:23:44.495523657 -0400 +++ new/test/hotspot/jtreg/ProblemList.txt 2019-06-11 07:23:44.002494700 -0400 @@ -43,6 +43,7 @@ compiler/ciReplay/TestSAServer.java 8029528 generic-all compiler/codecache/stress/OverloadCompileQueueTest.java 8166554 generic-all compiler/codegen/Test6896617.java 8193479 generic-all +compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java 8225370 generic-all compiler/jvmci/compilerToVM/GetFlagValueTest.java 8204459 generic-all compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java 8158860 generic-all compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java 8163894 generic-all From tobias.hartmann at oracle.com Tue Jun 11 11:49:36 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 11 Jun 2019 13:49:36 +0200 Subject: RFR (Trivial) 8225568: ProblemList compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java In-Reply-To: <89f76c21-215a-852c-c48f-31d4091cf650@oracle.com> References: <89f76c21-215a-852c-c48f-31d4091cf650@oracle.com> Message-ID: <69725788-53d8-60e1-7e37-07a0e9096812@oracle.com> Hi David, reviewed. Best regards, Tobias On 11.06.19 13:29, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8225568 > webrev: http://cr.openjdk.java.net/~dholmes/8225568/webrev/ > > Related issue: https://bugs.openjdk.java.net/browse/JDK-8225370 > > Patch below. This test was removed from the ProblemList by JDK-8222103 and has continually failed > since in our testing. The test had not previously been run for several years and its condition is > unknown. So re-adding it to the ProblemList until it can be properly examined. > > Thanks, > David > ----- > > --- old/test/hotspot/jtreg/ProblemList.txt??? 2019-06-11 07:23:44.495523657 -0400 > +++ new/test/hotspot/jtreg/ProblemList.txt??? 2019-06-11 07:23:44.002494700 -0400 > @@ -43,6 +43,7 @@ > ?compiler/ciReplay/TestSAServer.java 8029528 generic-all > ?compiler/codecache/stress/OverloadCompileQueueTest.java 8166554 generic-all > ?compiler/codegen/Test6896617.java 8193479 generic-all > +compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java 8225370 generic-all > ?compiler/jvmci/compilerToVM/GetFlagValueTest.java 8204459 generic-all > ?compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java 8158860 generic-all > ?compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java 8163894 generic-all From david.holmes at oracle.com Tue Jun 11 12:02:38 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Jun 2019 22:02:38 +1000 Subject: RFR (Trivial) 8225568: ProblemList compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java In-Reply-To: <69725788-53d8-60e1-7e37-07a0e9096812@oracle.com> References: <89f76c21-215a-852c-c48f-31d4091cf650@oracle.com> <69725788-53d8-60e1-7e37-07a0e9096812@oracle.com> Message-ID: <87d005ea-6469-ba2e-6b09-61880e303e7a@oracle.com> Thanks Tobias! David On 11/06/2019 9:49 pm, Tobias Hartmann wrote: > Hi David, > > reviewed. > > Best regards, > Tobias > > On 11.06.19 13:29, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8225568 >> webrev: http://cr.openjdk.java.net/~dholmes/8225568/webrev/ >> >> Related issue: https://bugs.openjdk.java.net/browse/JDK-8225370 >> >> Patch below. This test was removed from the ProblemList by JDK-8222103 and has continually failed >> since in our testing. The test had not previously been run for several years and its condition is >> unknown. So re-adding it to the ProblemList until it can be properly examined. >> >> Thanks, >> David >> ----- >> >> --- old/test/hotspot/jtreg/ProblemList.txt??? 2019-06-11 07:23:44.495523657 -0400 >> +++ new/test/hotspot/jtreg/ProblemList.txt??? 2019-06-11 07:23:44.002494700 -0400 >> @@ -43,6 +43,7 @@ >> ?compiler/ciReplay/TestSAServer.java 8029528 generic-all >> ?compiler/codecache/stress/OverloadCompileQueueTest.java 8166554 generic-all >> ?compiler/codegen/Test6896617.java 8193479 generic-all >> +compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java 8225370 generic-all >> ?compiler/jvmci/compilerToVM/GetFlagValueTest.java 8204459 generic-all >> ?compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java 8158860 generic-all >> ?compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java 8163894 generic-all From kim.barrett at oracle.com Tue Jun 11 16:42:04 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 11 Jun 2019 12:42:04 -0400 Subject: RFR: 8213415: BitMap::word_index_round_up overflow problems In-Reply-To: <3F4F27AC-4812-4E55-99DF-25F0A7BD991D@oracle.com> References: <24C2BDC9-AC35-4804-95C8-1B59747C1494@oracle.com> <5bd19480-d570-b73d-70fe-10e93ef2ecb8@oracle.com> <3F4F27AC-4812-4E55-99DF-25F0A7BD991D@oracle.com> Message-ID: > On Jun 10, 2019, at 9:14 PM, Kim Barrett wrote: > new webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8213415/open.01/ > incr: http://cr.openjdk.java.net/~kbarrett/8213415/open.01.inc/ Stefan and I have been talking about this offline. We have some ideas for further changes in a slightly different direction, so no point in anyone else reviewing the open.01 changes right now (or maybe ever). From yumin.qi at gmail.com Tue Jun 11 17:50:54 2019 From: yumin.qi at gmail.com (yumin qi) Date: Tue, 11 Jun 2019 10:50:54 -0700 Subject: PING: RFR(s): 8224600: Provide VM.events command In-Reply-To: References: Message-ID: HI, Thomas Sorry for late reply, It looks good to me. Thanks Yumin On Tue, Jun 4, 2019 at 1:04 AM Thomas St?fe wrote: > Thank you Christoph! > > I'll give Yumin time for feedback then will push later today or tomorrow. > > Cheers, Thomas > > On Tue, Jun 4, 2019 at 9:49 AM Langer, Christoph > > wrote: > > > Hi Thomas, > > > > I had a look at your patch and it looks good to me. > > > > One minor thing: copyright year in diagnosticCommand.cpp. > > > > Also, the bug is https://bugs.openjdk.java.net/browse/JDK-8224600, > > JDK-8224601 is the CSR ?? > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: hotspot-dev On Behalf Of > > > Thomas St?fe > > > Sent: Montag, 3. Juni 2019 10:20 > > > To: HotSpot Open Source Developers > > > Subject: PING: RFR(s): 8224600: Provide VM.events command > > > > > > Hi all, > > > > > > may I please have a second reviewer for this. It is a rather small > > addition > > > to add a new jcmd to print event logs. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224601 > > > Latest webrev: > > > http://cr.openjdk.java.net/~stuefe/webrevs/vm.events/webrev.01/webrev > > > / > > > > > > Thank you, Thomas > > > > > > On Thu, May 23, 2019 at 9:51 PM Thomas St?fe > > > wrote: > > > > > > > Hi all, > > > > > > > > May I please have reviews for the following addition to jcmd. > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224600 > > > > CSR: https://bugs.openjdk.java.net/browse/JDK-8224601 > > > > webrev: > > > > > > > http://cr.openjdk.java.net/~stuefe/webrevs/vm.events/webrev.00/webrev > > > /index.html > > > > > > > > This adds a new command, "VM.events", which can be used to display VM > > > > event logs. Please see linked CSR for details. > > > > > > > > The CSR itself is not yet approved but already in proposed state. > > > > > > > > Thanks, Thomas > > > > > > > From thomas.stuefe at gmail.com Tue Jun 11 18:26:07 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 11 Jun 2019 20:26:07 +0200 Subject: PING: RFR(s): 8224600: Provide VM.events command In-Reply-To: References: Message-ID: Thanks Yumin! On Tue, Jun 11, 2019, 19:51 yumin qi wrote: > HI, Thomas > > Sorry for late reply, It looks good to me. > > Thanks > Yumin > > On Tue, Jun 4, 2019 at 1:04 AM Thomas St?fe > wrote: > >> Thank you Christoph! >> >> I'll give Yumin time for feedback then will push later today or tomorrow. >> >> Cheers, Thomas >> >> On Tue, Jun 4, 2019 at 9:49 AM Langer, Christoph < >> christoph.langer at sap.com> >> wrote: >> >> > Hi Thomas, >> > >> > I had a look at your patch and it looks good to me. >> > >> > One minor thing: copyright year in diagnosticCommand.cpp. >> > >> > Also, the bug is https://bugs.openjdk.java.net/browse/JDK-8224600, >> > JDK-8224601 is the CSR ?? >> > >> > Best regards >> > Christoph >> > >> > > -----Original Message----- >> > > From: hotspot-dev On Behalf Of >> > > Thomas St?fe >> > > Sent: Montag, 3. Juni 2019 10:20 >> > > To: HotSpot Open Source Developers >> > > Subject: PING: RFR(s): 8224600: Provide VM.events command >> > > >> > > Hi all, >> > > >> > > may I please have a second reviewer for this. It is a rather small >> > addition >> > > to add a new jcmd to print event logs. >> > > >> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224601 >> > > Latest webrev: >> > > http://cr.openjdk.java.net/~stuefe/webrevs/vm.events/webrev.01/webrev >> > > / >> > > >> > > Thank you, Thomas >> > > >> > > On Thu, May 23, 2019 at 9:51 PM Thomas St?fe > > >> > > wrote: >> > > >> > > > Hi all, >> > > > >> > > > May I please have reviews for the following addition to jcmd. >> > > > >> > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224600 >> > > > CSR: https://bugs.openjdk.java.net/browse/JDK-8224601 >> > > > webrev: >> > > > >> > > http://cr.openjdk.java.net/~stuefe/webrevs/vm.events/webrev.00/webrev >> > > /index.html >> > > > >> > > > This adds a new command, "VM.events", which can be used to display >> VM >> > > > event logs. Please see linked CSR for details. >> > > > >> > > > The CSR itself is not yet approved but already in proposed state. >> > > > >> > > > Thanks, Thomas >> > > > >> > >> > From igor.ignatyev at oracle.com Wed Jun 12 03:18:29 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 11 Jun 2019 20:18:29 -0700 Subject: RFR(S) [13] : 8158048 : Fix failure message from jtreg gtest wrapper Message-ID: <9BBEECA1-7FFD-44CD-96AA-F2F332A161CE@oracle.com> http://cr.openjdk.java.net/~iignatyev//8158048/webrev.00 > 125 lines changed: 108 ins; 10 del; 7 mod Hi all, could you please review this small fix which improves error message generated by jtreg gtest wrapper? now we try to parse xml file generated by gtest in order to get more meaningful error message which will include name of all failed tests. webrev: http://cr.openjdk.java.net/~iignatyev//8158048/webrev.00 JBS: https://bugs.openjdk.java.net/browse/JDK-8158048 testing: manually modified a few tests to fail and checked thrown exception message Thanks, -- Igor From nick.gasson at arm.com Wed Jun 12 09:35:32 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Wed, 12 Jun 2019 17:35:32 +0800 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com> <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com> <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com> <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com> <94de2466-4b73-7091-17ee-7168114df1ee@arm.com> <0b355166-4bb7-7de2-b30b-9a481aa085a2@redhat.com> Message-ID: Hi Andrew, Sorry for the delay, I've put an updated webrev here: http://cr.openjdk.java.net/~ngasson/8224851/webrev.1/ Changes since the last patch: * Replaced ~((1<<12) - 1) with -1u<<12 * Use __atomic_add_fetch in Atomic::PlatformAdd #ifdef __clang__ * Use __builtin_frame_address(0) in os::current_frame() * Use placement new / copy assignment in pf() I also replaced the call to _get_previous_fp() in os::current_frame() with *(intptr_t **)__builtin_frame_address(0); As it generates the same code and avoids the `register intptr_t **fp __asm__ (SPELL_REG_FP);' declaration which clang doesn't support. Also the following comment in _get_previous_fp seems to be wrong: // fp is for this frame (_get_previous_fp). We want the fp for the // caller of os::current_frame*(), so go up two frames. However, for // optimized builds, _get_previous_fp() will be inlined, so only go // up 1 frame in that case. #ifdef _NMT_NOINLINE_ return **(intptr_t***)fp; #else return *fp; #endif Even on -O0 gcc won't generate a stack frame for this function so if _NMT_NOINLINE_ is defined you get the caller's caller's FP rather than the caller's FP. I just deleted the function as it's not used anywhere else. BTW we can't use __builtin_frame_address(1) as GCC gives a warning when this is called with a non-zero argument (-Wframe-address). Tested jtreg hotspot_all_no_apps and jdk_core (gcc 7.3). Thanks, Nick On 03/06/2019 19:03, Andrew Haley wrote: > Hi, > > On 6/3/19 11:36 AM, Nick Gasson wrote: >> >>> We need to know what it's used for to know which solution is right. I'm >>> guessing the primary use case is asynchronous runtime stack probes, used >>> by debugging tools. >>> >> >> Yes, we also have os::stack_shadow_pages_available() which uses it to >> calculate how much space there is between the current SP and the end of >> the stack. In this case I think it's ok as long as we don't return a >> value that's *above* the actual stack pointer. And os::current_frame(), >> which constructs a `frame' object using the FP of the caller, but the SP >> will point into the frame of os::current_frame(), so it seems it's >> already inaccurate. > > Eww. > >> There's also a comment in os_linux.cpp that says "Don't use >> os::current_stack_pointer(), as its result can be slightly below current >> stack pointer". So I'm wondering if we can simplify this a lot and use >> __builtin_frame_address(0) which will give us the FP in >> os::current_stack_pointer (ought to be the caller's SP - 16). Zero does >> this currently. And maybe we can replace _get_previous_fp() with >> __builtin_frame_address(1)? > > Let's make os::current_stack_pointer() noinline, then make it return > __builtin_frame_address(0). > From vladimir.kozlov at oracle.com Wed Jun 12 16:04:19 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Jun 2019 09:04:19 -0700 Subject: RFR(S) [13] : 8158048 : Fix failure message from jtreg gtest wrapper In-Reply-To: <9BBEECA1-7FFD-44CD-96AA-F2F332A161CE@oracle.com> References: <9BBEECA1-7FFD-44CD-96AA-F2F332A161CE@oracle.com> Message-ID: <1e2f8492-d35b-129c-f24f-ba3a6d65d893@oracle.com> Good. thanks, Vladimir On 6/11/19 8:18 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8158048/webrev.00 >> 125 lines changed: 108 ins; 10 del; 7 mod > > > Hi all, > > could you please review this small fix which improves error message generated by jtreg gtest wrapper? now we try to parse xml file generated by gtest in order to get more meaningful error message which will include name of all failed tests. > > webrev: http://cr.openjdk.java.net/~iignatyev//8158048/webrev.00 > JBS: https://bugs.openjdk.java.net/browse/JDK-8158048 > testing: manually modified a few tests to fail and checked thrown exception message > > Thanks, > -- Igor > > > From mikhailo.seledtsov at oracle.com Wed Jun 12 16:31:35 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Wed, 12 Jun 2019 09:31:35 -0700 Subject: RFR(S) [13] : 8158048 : Fix failure message from jtreg gtest wrapper In-Reply-To: <1e2f8492-d35b-129c-f24f-ba3a6d65d893@oracle.com> References: <9BBEECA1-7FFD-44CD-96AA-F2F332A161CE@oracle.com> <1e2f8492-d35b-129c-f24f-ba3a6d65d893@oracle.com> Message-ID: <05e77aa0-65e0-7235-f430-228eaaa85e71@oracle.com> +1 On 6/12/19 9:04 AM, Vladimir Kozlov wrote: > Good. > > thanks, > Vladimir > > On 6/11/19 8:18 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8158048/webrev.00 >>> 125 lines changed: 108 ins; 10 del; 7 mod >> >> >> Hi all, >> >> could you please review this small fix which improves error message >> generated by jtreg gtest wrapper? now we try to parse xml file >> generated by gtest in order to get more meaningful error message >> which will include name of all failed tests. >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8158048/webrev.00 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8158048 >> testing: manually modified a few tests to fail and checked thrown >> exception message >> >> Thanks, >> -- Igor >> >> From igor.ignatyev at oracle.com Wed Jun 12 18:49:31 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 12 Jun 2019 11:49:31 -0700 Subject: RFR(S) [13] : 8158048 : Fix failure message from jtreg gtest wrapper In-Reply-To: <05e77aa0-65e0-7235-f430-228eaaa85e71@oracle.com> References: <9BBEECA1-7FFD-44CD-96AA-F2F332A161CE@oracle.com> <1e2f8492-d35b-129c-f24f-ba3a6d65d893@oracle.com> <05e77aa0-65e0-7235-f430-228eaaa85e71@oracle.com> Message-ID: <9779AC8F-13B2-4DE4-97DB-79CFA31FD545@oracle.com> Vladimir, MIsha, thank you both for your review! pushed. -- Igor > On Jun 12, 2019, at 9:31 AM, mikhailo.seledtsov at oracle.com wrote: > > +1 > > On 6/12/19 9:04 AM, Vladimir Kozlov wrote: >> Good. >> >> thanks, >> Vladimir >> >> On 6/11/19 8:18 PM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8158048/webrev.00 >>>> 125 lines changed: 108 ins; 10 del; 7 mod >>> >>> >>> Hi all, >>> >>> could you please review this small fix which improves error message generated by jtreg gtest wrapper? now we try to parse xml file generated by gtest in order to get more meaningful error message which will include name of all failed tests. >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev//8158048/webrev.00 >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8158048 >>> testing: manually modified a few tests to fail and checked thrown exception message >>> >>> Thanks, >>> -- Igor >>> >>> From igor.ignatyev at oracle.com Wed Jun 12 20:47:13 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 12 Jun 2019 13:47:13 -0700 Subject: RFR(T) [13] : 8225676 : cleanup hotspot ProblemList Message-ID: <0907E9D4-6689-4437-9B44-DAC92846EACA@oracle.com> http://cr.openjdk.java.net/~iignatyev//8225676/webrev.00/index.html > 9 lines changed: 2 ins; 4 del; 3 mod; Hi all, could you please review this small and trivial patch which cleans up hotspot problem lists? - 8224234 : "compiler/codegen/TestCharVect2.java fails in test_mulc" was fixed recently w/o removing problem list entry - 8221577 : "[Graal] Implement basic type consistency checks for Low level MH intrinsics" and 8224254 :"compiler/graalunit/HotspotJdk9Test.java is timing out intermittently" are closed as a dup of next graal update -- 8224254 - 8066173 : "compiler/types/correctness/OffTest.java failed with assert" used wrong bug id to problem list tests on solaris-sparcv9 webrev: http://cr.openjdk.java.net/~iignatyev//8225676/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8225676 Thanks, -- Igor From david.holmes at oracle.com Thu Jun 13 00:16:31 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Jun 2019 10:16:31 +1000 Subject: RFR(T) [13] : 8225676 : cleanup hotspot ProblemList In-Reply-To: <0907E9D4-6689-4437-9B44-DAC92846EACA@oracle.com> References: <0907E9D4-6689-4437-9B44-DAC92846EACA@oracle.com> Message-ID: Hi Igor, On 13/06/2019 6:47 am, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8225676/webrev.00/index.html >> 9 lines changed: 2 ins; 4 del; 3 mod; > > Hi all, > > could you please review this small and trivial patch which cleans up hotspot problem lists? > > - 8224234 : "compiler/codegen/TestCharVect2.java fails in test_mulc" was fixed recently w/o removing problem list entry Okay. > - 8221577 : "[Graal] Implement basic type consistency checks for Low level MH intrinsics" and 8224254 :"compiler/graalunit/HotspotJdk9Test.java is timing out intermittently" are closed as a dup of next graal update -- 8224254 That last 8224254 should be 8223807 right? > - 8066173 : "compiler/types/correctness/OffTest.java failed with assert" used wrong bug id to problem list tests on solaris-sparcv9 Okay. Thanks, David > webrev: http://cr.openjdk.java.net/~iignatyev//8225676/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8225676 > > Thanks, > -- Igor > From igor.ignatyev at oracle.com Thu Jun 13 00:23:55 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 12 Jun 2019 17:23:55 -0700 Subject: RFR(T) [13] : 8225676 : cleanup hotspot ProblemList In-Reply-To: References: <0907E9D4-6689-4437-9B44-DAC92846EACA@oracle.com> Message-ID: <457388D6-7292-438E-B813-8659EC0C0AF2@oracle.com> Hi David, thanks for your review. > That last 8224254 should be 8223807 right? right, copy-paste error in the email. the patch uses 8223807. -- Igor > On Jun 12, 2019, at 5:16 PM, David Holmes wrote: > > Hi Igor, > > On 13/06/2019 6:47 am, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8225676/webrev.00/index.html >>> 9 lines changed: 2 ins; 4 del; 3 mod; >> Hi all, >> could you please review this small and trivial patch which cleans up hotspot problem lists? >> - 8224234 : "compiler/codegen/TestCharVect2.java fails in test_mulc" was fixed recently w/o removing problem list entry > > Okay. > >> - 8221577 : "[Graal] Implement basic type consistency checks for Low level MH intrinsics" and 8224254 :"compiler/graalunit/HotspotJdk9Test.java is timing out intermittently" are closed as a dup of next graal update -- 8224254 > > That last 8224254 should be 8223807 right? > >> - 8066173 : "compiler/types/correctness/OffTest.java failed with assert" used wrong bug id to problem list tests on solaris-sparcv9 > > Okay. > > Thanks, > David > >> webrev: http://cr.openjdk.java.net/~iignatyev//8225676/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8225676 >> Thanks, >> -- Igor From igor.ignatyev at oracle.com Thu Jun 13 00:39:02 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 12 Jun 2019 17:39:02 -0700 Subject: RFR(T) [13] : 8208236 : [TESTBUG] vmTestbase/nsk/stress/stack tests fail by timeout Message-ID: http://cr.openjdk.java.net/~iignatyev//8208236/webrev.00/index.html > 19 lines changed: 0 ins; 0 del; 19 mod; Hi all, could you please review this trivial fix which increases timeout of vmTestbase/nsk/stress/stack tests to 15 minutes? the patch is basically 's-main/othervm -main/othervm/timeout=900 -'. webrev: http://cr.openjdk.java.net/~iignatyev//8208236/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8208236 Thanks, -- Igor From david.holmes at oracle.com Thu Jun 13 00:44:00 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Jun 2019 10:44:00 +1000 Subject: RFR(T) [13] : 8208236 : [TESTBUG] vmTestbase/nsk/stress/stack tests fail by timeout In-Reply-To: References: Message-ID: <45131b04-469e-f287-32d0-2f1aac98ca10@oracle.com> Hi Igor, On 13/06/2019 10:39 am, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8208236/webrev.00/index.html >> 19 lines changed: 0 ins; 0 del; 19 mod; > > Hi all, > > could you please review this trivial fix which increases timeout of vmTestbase/nsk/stress/stack tests to 15 minutes? the patch is basically 's-main/othervm -main/othervm/timeout=900 -'. Don't we need to account for the jtreg timeout factor? Thanks, David > webrev: http://cr.openjdk.java.net/~iignatyev//8208236/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8208236 > > Thanks, > -- Igor > From kim.barrett at oracle.com Thu Jun 13 00:45:45 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 12 Jun 2019 20:45:45 -0400 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com> <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com> <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com> <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com> <94de2466-4b73-7091-17ee-7168114df1ee@arm.com> <0b355166-4bb7-7de2-b30b-9a481aa085a2@redhat.com> Message-ID: <937B29BB-266F-4D62-9FCB-3F2DE6A8376E@oracle.com> > On Jun 12, 2019, at 5:35 AM, Nick Gasson wrote: > > Hi Andrew, > > Sorry for the delay, I've put an updated webrev here: > > http://cr.openjdk.java.net/~ngasson/8224851/webrev.1/ Since I've been commenting on some parts, I decided I might as well look at all of it. So here's a review. I don't need to re-review any of the suggested changes. ------------------------------------------------------------------------------ src/hotspot/cpu/aarch64/frame_aarch64.cpp 772 reg_map = (RegisterMap*)os::malloc(sizeof(RegisterMap), mtNone); Use NEW_C_HEAP_OBJ(RegisterMap, mtNone) ------------------------------------------------------------------------------ src/hotspot/cpu/aarch64/macroAssembler_aarch64_trig.cpp 384 fcmpd(v26, 0.0); // if NE then jx == 2. else it's 1 or 0 and 388 fcmpd(v7, 0.0); // v7 == 0 => jx = 0. Else jx = 1 EOL comments no longer aligned with others nearby. ------------------------------------------------------------------------------ src/hotspot/cpu/aarch64/vm_version_aarch64.cpp 180 if ((p = strchr(buf, ':'))) { Hotspot Coding Style says not to use implicit bool, instead using explicit comparisons, e.g. this should be 180 if ((p = strchr(buf, ':')) != NULL) { That would have avoided the warning in the first place. And yes, I know there are lots of violations of that guideline. ------------------------------------------------------------------------------ src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.hpp 43 #ifdef __clang__ 44 D res = __atomic_add_fetch(dest, add_value, __ATOMIC_RELEASE); 45 FULL_MEM_BARRIER; 46 return res; 47 #else Is there a reason to conditionalize use of __atomic_add_fetch for clang and continue to use __sync_add_and_fetch for gcc, rather than using __atomic_add_fetch unconditionally? Is __ATOMIC_RELEASE and a following FULL_MEM_BARRIER the right usage to get the equivalent of __sync_add_and_fetch? Or should __ATOMIC_SEQ_CST be used? Or should the latter be actively avoided? I remember some discussion and questions in that area, about how to implement memory_order_seq_cst on ARM processors, but wasn't paying close attention since I don't deal with ARM much. Andrew? I'll happily defer to you here. ------------------------------------------------------------------------------ src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp I didn't review the stuff around os::current_stack_pointer and os::current_frame. ------------------------------------------------------------------------------ src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.s 162 prfum pldl1keep, [s, #-256] I didn't review this change. ------------------------------------------------------------------------------ From igor.ignatyev at oracle.com Thu Jun 13 00:54:03 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 12 Jun 2019 17:54:03 -0700 Subject: RFR(T) [13] : 8208236 : [TESTBUG] vmTestbase/nsk/stress/stack tests fail by timeout In-Reply-To: <45131b04-469e-f287-32d0-2f1aac98ca10@oracle.com> References: <45131b04-469e-f287-32d0-2f1aac98ca10@oracle.com> Message-ID: <404687B2-305F-4EBD-8890-729432EA0C44@oracle.com> well, I kinda did. before these tests were converted to jtreg, they had timeout = 30 minutes; my thinking was to set test-specific timeout to a value which will give us 30 minutes w/ the minimal expected timeout, which I assumed is 2. if we are to assume that minimal timeout is 4 (which current default), I can change it to /timeout=450. -- Igor > On Jun 12, 2019, at 5:44 PM, David Holmes wrote: > > Hi Igor, > > On 13/06/2019 10:39 am, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8208236/webrev.00/index.html >>> 19 lines changed: 0 ins; 0 del; 19 mod; >> Hi all, >> could you please review this trivial fix which increases timeout of vmTestbase/nsk/stress/stack tests to 15 minutes? the patch is basically 's-main/othervm -main/othervm/timeout=900 -'. > > Don't we need to account for the jtreg timeout factor? > > Thanks, > David > >> webrev: http://cr.openjdk.java.net/~iignatyev//8208236/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8208236 >> Thanks, >> -- Igor From david.holmes at oracle.com Thu Jun 13 02:25:39 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Jun 2019 12:25:39 +1000 Subject: RFR(T) [13] : 8208236 : [TESTBUG] vmTestbase/nsk/stress/stack tests fail by timeout In-Reply-To: <404687B2-305F-4EBD-8890-729432EA0C44@oracle.com> References: <45131b04-469e-f287-32d0-2f1aac98ca10@oracle.com> <404687B2-305F-4EBD-8890-729432EA0C44@oracle.com> Message-ID: On 13/06/2019 10:54 am, Igor Ignatyev wrote: > well, I kinda did. before these tests were converted to jtreg, they had timeout = 30 minutes; my thinking was to set test-specific timeout to a value which will give us 30 minutes w/ the minimal expected timeout, which I assumed is 2. if we are to assume that minimal timeout is 4 (which current default), I can change it to /timeout=450. I see the timeout factor being set between 1 and 16, and for tier3 hotspot it seems to be 1. I can't tell what it is for sure for other tiers. So confusing :( Lets leave it as-is. Thanks, David > -- Igor > >> On Jun 12, 2019, at 5:44 PM, David Holmes wrote: >> >> Hi Igor, >> >> On 13/06/2019 10:39 am, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8208236/webrev.00/index.html >>>> 19 lines changed: 0 ins; 0 del; 19 mod; >>> Hi all, >>> could you please review this trivial fix which increases timeout of vmTestbase/nsk/stress/stack tests to 15 minutes? the patch is basically 's-main/othervm -main/othervm/timeout=900 -'. >> >> Don't we need to account for the jtreg timeout factor? >> >> Thanks, >> David >> >>> webrev: http://cr.openjdk.java.net/~iignatyev//8208236/webrev.00/index.html >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8208236 >>> Thanks, >>> -- Igor > From igor.ignatyev at oracle.com Thu Jun 13 03:45:12 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 12 Jun 2019 20:45:12 -0700 Subject: RFR(T) [13] : 8208236 : [TESTBUG] vmTestbase/nsk/stress/stack tests fail by timeout In-Reply-To: References: <45131b04-469e-f287-32d0-2f1aac98ca10@oracle.com> <404687B2-305F-4EBD-8890-729432EA0C44@oracle.com> Message-ID: <89A4EBD1-6031-40D3-840D-BE106128AA4B@oracle.com> > On Jun 12, 2019, at 7:25 PM, David Holmes wrote: > > On 13/06/2019 10:54 am, Igor Ignatyev wrote: >> well, I kinda did. before these tests were converted to jtreg, they had timeout = 30 minutes; my thinking was to set test-specific timeout to a value which will give us 30 minutes w/ the minimal expected timeout, which I assumed is 2. if we are to assume that minimal timeout is 4 (which current default), I can change it to /timeout=450. > > I see the timeout factor being set between 1 and 16, and for tier3 hotspot it seems to be 1. I can't tell what it is for sure for other tiers. So confusing :( timeout factors 1 and 2 are usually used for time-based tests, in other words for the tests which try to spend as much of allocated time budget as possible to do more testing. as of today, our tiers run vmTestbase/nsk/stress/stack tests w/ either default timeout factor 4, 8, 10, or 16, I assume depending on used extra vm flags. > > Lets leave it as-is. "as-is" meaning /timeout=900? or default 120s? > > Thanks, > David > >> -- Igor >>> On Jun 12, 2019, at 5:44 PM, David Holmes wrote: >>> >>> Hi Igor, >>> >>> On 13/06/2019 10:39 am, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev//8208236/webrev.00/index.html >>>>> 19 lines changed: 0 ins; 0 del; 19 mod; >>>> Hi all, >>>> could you please review this trivial fix which increases timeout of vmTestbase/nsk/stress/stack tests to 15 minutes? the patch is basically 's-main/othervm -main/othervm/timeout=900 -'. >>> >>> Don't we need to account for the jtreg timeout factor? >>> >>> Thanks, >>> David >>> >>>> webrev: http://cr.openjdk.java.net/~iignatyev//8208236/webrev.00/index.html >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8208236 >>>> Thanks, >>>> -- Igor From david.holmes at oracle.com Thu Jun 13 03:58:10 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Jun 2019 13:58:10 +1000 Subject: RFR(T) [13] : 8208236 : [TESTBUG] vmTestbase/nsk/stress/stack tests fail by timeout In-Reply-To: <89A4EBD1-6031-40D3-840D-BE106128AA4B@oracle.com> References: <45131b04-469e-f287-32d0-2f1aac98ca10@oracle.com> <404687B2-305F-4EBD-8890-729432EA0C44@oracle.com> <89A4EBD1-6031-40D3-840D-BE106128AA4B@oracle.com> Message-ID: On 13/06/2019 1:45 pm, Igor Ignatyev wrote: >> On Jun 12, 2019, at 7:25 PM, David Holmes wrote: >> >> On 13/06/2019 10:54 am, Igor Ignatyev wrote: >>> well, I kinda did. before these tests were converted to jtreg, they had timeout = 30 minutes; my thinking was to set test-specific timeout to a value which will give us 30 minutes w/ the minimal expected timeout, which I assumed is 2. if we are to assume that minimal timeout is 4 (which current default), I can change it to /timeout=450. >> >> I see the timeout factor being set between 1 and 16, and for tier3 hotspot it seems to be 1. I can't tell what it is for sure for other tiers. So confusing :( > timeout factors 1 and 2 are usually used for time-based tests, in other words for the tests which try to spend as much of allocated time budget as possible to do more testing. as of today, our tiers run vmTestbase/nsk/stress/stack tests w/ either default timeout factor 4, 8, 10, or 16, I assume depending on used extra vm flags. >> >> Lets leave it as-is. > "as-is" meaning /timeout=900? or default 120s? "as-is" meaning "as it is in your webrev" as opposed to reducing to 450. David >> >> Thanks, >> David >> >>> -- Igor >>>> On Jun 12, 2019, at 5:44 PM, David Holmes wrote: >>>> >>>> Hi Igor, >>>> >>>> On 13/06/2019 10:39 am, Igor Ignatyev wrote: >>>>> http://cr.openjdk.java.net/~iignatyev//8208236/webrev.00/index.html >>>>>> 19 lines changed: 0 ins; 0 del; 19 mod; >>>>> Hi all, >>>>> could you please review this trivial fix which increases timeout of vmTestbase/nsk/stress/stack tests to 15 minutes? the patch is basically 's-main/othervm -main/othervm/timeout=900 -'. >>>> >>>> Don't we need to account for the jtreg timeout factor? >>>> >>>> Thanks, >>>> David >>>> >>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8208236/webrev.00/index.html >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8208236 >>>>> Thanks, >>>>> -- Igor > From igor.ignatyev at oracle.com Thu Jun 13 04:19:43 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 12 Jun 2019 21:19:43 -0700 Subject: RFR(T) [13] : 8208236 : [TESTBUG] vmTestbase/nsk/stress/stack tests fail by timeout In-Reply-To: References: <45131b04-469e-f287-32d0-2f1aac98ca10@oracle.com> <404687B2-305F-4EBD-8890-729432EA0C44@oracle.com> <89A4EBD1-6031-40D3-840D-BE106128AA4B@oracle.com> Message-ID: ok, thanks for the review, David. pushed. -- Igor > On Jun 12, 2019, at 8:58 PM, David Holmes wrote: > > On 13/06/2019 1:45 pm, Igor Ignatyev wrote: >>> On Jun 12, 2019, at 7:25 PM, David Holmes wrote: >>> >>> On 13/06/2019 10:54 am, Igor Ignatyev wrote: >>>> well, I kinda did. before these tests were converted to jtreg, they had timeout = 30 minutes; my thinking was to set test-specific timeout to a value which will give us 30 minutes w/ the minimal expected timeout, which I assumed is 2. if we are to assume that minimal timeout is 4 (which current default), I can change it to /timeout=450. >>> >>> I see the timeout factor being set between 1 and 16, and for tier3 hotspot it seems to be 1. I can't tell what it is for sure for other tiers. So confusing :( >> timeout factors 1 and 2 are usually used for time-based tests, in other words for the tests which try to spend as much of allocated time budget as possible to do more testing. as of today, our tiers run vmTestbase/nsk/stress/stack tests w/ either default timeout factor 4, 8, 10, or 16, I assume depending on used extra vm flags. >>> >>> Lets leave it as-is. >> "as-is" meaning /timeout=900? or default 120s? > > "as-is" meaning "as it is in your webrev" as opposed to reducing to 450. > > David > >>> >>> Thanks, >>> David >>> >>>> -- Igor >>>>> On Jun 12, 2019, at 5:44 PM, David Holmes wrote: >>>>> >>>>> Hi Igor, >>>>> >>>>> On 13/06/2019 10:39 am, Igor Ignatyev wrote: >>>>>> http://cr.openjdk.java.net/~iignatyev//8208236/webrev.00/index.html >>>>>>> 19 lines changed: 0 ins; 0 del; 19 mod; >>>>>> Hi all, >>>>>> could you please review this trivial fix which increases timeout of vmTestbase/nsk/stress/stack tests to 15 minutes? the patch is basically 's-main/othervm -main/othervm/timeout=900 -'. >>>>> >>>>> Don't we need to account for the jtreg timeout factor? >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8208236/webrev.00/index.html >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8208236 >>>>>> Thanks, >>>>>> -- Igor From nick.gasson at arm.com Thu Jun 13 08:36:02 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Thu, 13 Jun 2019 16:36:02 +0800 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: <937B29BB-266F-4D62-9FCB-3F2DE6A8376E@oracle.com> References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com> <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com> <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com> <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com> <94de2466-4b73-7091-17ee-7168114df1ee@arm.com> <0b355166-4bb7-7de2-b30b-9a481aa085a2@redhat.com> <937B29BB-266F-4D62-9FCB-3F2DE6A8376E@oracle.com> Message-ID: Hi Kim, Thanks for the feedback. I'll make these changes. > > Is there a reason to conditionalize use of __atomic_add_fetch for > clang and continue to use __sync_add_and_fetch for gcc, rather than > using __atomic_add_fetch unconditionally? I think I did it that way because I didn't want to affect the build with gcc, but actually gcc compiles this to the same instructions with either variant so we can get rid of the #ifdef. > > Is __ATOMIC_RELEASE and a following FULL_MEM_BARRIER the right usage > to get the equivalent of __sync_add_and_fetch? Or should > __ATOMIC_SEQ_CST be used? Or should the latter be actively avoided? > I remember some discussion and questions in that area, about how to > implement memory_order_seq_cst on ARM processors, but wasn't paying > close attention since I don't deal with ARM much. > It generates the same instruction sequence as the existing __sync_fetch_and_add. The __sync_XXX builtins have a full barrier at the end [1], so GCC compiles this to: .L2: ldxr w2, [x1] add w2, w2, w0 stlxr w3, w2, [x1] ; Store release cbnz w3, .L2 dmb ish ; Full barrier mov w0, w2 ret Whereas using the __atomic builtin with __ATOMIC_SEQ_CST we get two half-barriers like this: .L2: ldaxr w2, [x1] ; Load acquire add w2, w2, w0 stlxr w3, w2, [x1] ; Store release cbnz w3, .L2 mov w0, w2 ret Thanks, Nick [1] https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html From aph at redhat.com Thu Jun 13 09:12:04 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 13 Jun 2019 10:12:04 +0100 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com> <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com> <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com> <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com> <94de2466-4b73-7091-17ee-7168114df1ee@arm.com> <0b355166-4bb7-7de2-b30b-9a481aa085a2@redhat.com> Message-ID: <4995a613-796b-9370-e8e7-808598529d7a@redhat.com> On 6/12/19 10:35 AM, Nick Gasson wrote: > I also replaced the call to _get_previous_fp() in os::current_frame() with > > *(intptr_t **)__builtin_frame_address(0); > > As it generates the same code and avoids the `register intptr_t **fp > __asm__ (SPELL_REG_FP);' declaration which clang doesn't support. Also > the following comment in _get_previous_fp seems to be wrong: > > // fp is for this frame (_get_previous_fp). We want the fp for the > // caller of os::current_frame*(), so go up two frames. However, for > // optimized builds, _get_previous_fp() will be inlined, so only go > // up 1 frame in that case. > #ifdef _NMT_NOINLINE_ > return **(intptr_t***)fp; > #else > return *fp; > #endif All of this seems horribly fragile. I'll have a look at what this is supposed to be used for and think about a stable and robust way to do it. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thomas.stuefe at gmail.com Thu Jun 13 16:29:02 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 13 Jun 2019 18:29:02 +0200 Subject: [11u] RFR 8224487: outputStream should not be copyable Message-ID: Hi all, I would like to backport to 11u https://bugs.openjdk.java.net/browse/JDK-8224487. It is a precondition to backport three other fixes surrounding stringStream: - https://bugs.openjdk.java.net/browse/JDK-8224193 (stringStream should not use Resource Area) - https://bugs.openjdk.java.net/browse/JDK-8220394 (bufferedStream does not honor size limit) - https://bugs.openjdk.java.net/browse/JDK-8225225 (stringStream internal buffer should always be zero terminated) Original RFR discussion: https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-May/038208.html Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/0927d8c7296f Full patch (with 11u corrections): http://cr.openjdk.java.net/~stuefe/webrevs/backports/8224487-make-streams-not-copyable.patch Delta to original patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8224487-make-streams-not-copyable-11u-changes.patch The patch disables copy and assignment on outputStream child classes, since this has been a source of errors (unintended sharing of the stream backing buffer between two instances of stringStream, for instance). It fixes all resulting build errors - which mostly indicate real errors. Patch did not apply cleanly since 11u misses some work in the event log Coleen did in 12, and a small change Lutz Schmidt did for the code heap printer. Thanks for the review. Cheers, Thomas From igor.ignatyev at oracle.com Thu Jun 13 20:08:45 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 13 Jun 2019 13:08:45 -0700 Subject: RFR(T) [13] : 8225746 : hotspot problem lists list unexciting tests Message-ID: <20FE5F67-2604-455E-AC4E-86FD02E059D6@oracle.com> http://cr.openjdk.java.net/~iignatyev//8225746/webrev.00 > 6 lines changed: 0 ins; 5 del; 1 mod; Hi all, could you please review this trivial cleanup which adjust problem lists to moved/removed tests? from JBS: > runtime/SharedArchiveFile/SASymbolTableTest.java, serviceability/sa/ClhsdbSymbol.java, and serviceability/sa/ClhsdbSymbolTable.java were removed by JDK-8206309 > > vm/gc/InfiniteList.java was moved from open/test/jdk to open/test/hospot/jtreg, and renamed to gc/InfiniteList.java > > vmTestbase/nsk/jdi/Scenarios/invokeMethod/popframes001/TestDescription.jav just misses 'a' JBS: https://bugs.openjdk.java.net/browse/JDK-8225746 webrev: http://cr.openjdk.java.net/~iignatyev//8225746/webrev.00 Thanks, -- Igor From vladimir.kozlov at oracle.com Thu Jun 13 20:39:06 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Jun 2019 13:39:06 -0700 Subject: RFR(T) [13] : 8225746 : hotspot problem lists list unexciting tests In-Reply-To: <20FE5F67-2604-455E-AC4E-86FD02E059D6@oracle.com> References: <20FE5F67-2604-455E-AC4E-86FD02E059D6@oracle.com> Message-ID: <43921805-ab11-0d61-e5b6-9e0a1ad39c17@oracle.com> Good. thanks, Vladimir On 6/13/19 1:08 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8225746/webrev.00 >> 6 lines changed: 0 ins; 5 del; 1 mod; > > Hi all, > > could you please review this trivial cleanup which adjust problem lists to moved/removed tests? > > from JBS: >> runtime/SharedArchiveFile/SASymbolTableTest.java, serviceability/sa/ClhsdbSymbol.java, and serviceability/sa/ClhsdbSymbolTable.java were removed by JDK-8206309 >> >> vm/gc/InfiniteList.java was moved from open/test/jdk to open/test/hospot/jtreg, and renamed to gc/InfiniteList.java >> >> vmTestbase/nsk/jdi/Scenarios/invokeMethod/popframes001/TestDescription.jav just misses 'a' > > JBS: https://bugs.openjdk.java.net/browse/JDK-8225746 > webrev: http://cr.openjdk.java.net/~iignatyev//8225746/webrev.00 > > Thanks, > -- Igor > From igor.ignatyev at oracle.com Thu Jun 13 20:45:04 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 13 Jun 2019 13:45:04 -0700 Subject: RFR(T) [13] : 8225746 : hotspot problem lists list unexciting tests In-Reply-To: <43921805-ab11-0d61-e5b6-9e0a1ad39c17@oracle.com> References: <20FE5F67-2604-455E-AC4E-86FD02E059D6@oracle.com> <43921805-ab11-0d61-e5b6-9e0a1ad39c17@oracle.com> Message-ID: <3FA113FE-BB8A-41DF-AF80-6CD34EBAEF95@oracle.com> thanks Vladimir, pushed. -- Igor > On Jun 13, 2019, at 1:39 PM, Vladimir Kozlov wrote: > > Good. > > thanks, > Vladimir > > On 6/13/19 1:08 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8225746/webrev.00 >>> 6 lines changed: 0 ins; 5 del; 1 mod; >> Hi all, >> could you please review this trivial cleanup which adjust problem lists to moved/removed tests? >> from JBS: >>> runtime/SharedArchiveFile/SASymbolTableTest.java, serviceability/sa/ClhsdbSymbol.java, and serviceability/sa/ClhsdbSymbolTable.java were removed by JDK-8206309 >>> >>> vm/gc/InfiniteList.java was moved from open/test/jdk to open/test/hospot/jtreg, and renamed to gc/InfiniteList.java >>> >>> vmTestbase/nsk/jdi/Scenarios/invokeMethod/popframes001/TestDescription.jav just misses 'a' >> JBS: https://bugs.openjdk.java.net/browse/JDK-8225746 >> webrev: http://cr.openjdk.java.net/~iignatyev//8225746/webrev.00 >> Thanks, >> -- Igor From per.liden at oracle.com Fri Jun 14 06:29:06 2019 From: per.liden at oracle.com (Per Liden) Date: Fri, 14 Jun 2019 08:29:06 +0200 Subject: RFR: 8225779: Remove unused CollectedHeap::cell_header_size() Message-ID: <61d76fc8-d4c1-ee30-7f95-bf2d1222eff0@oracle.com> CollectedHeap::cell_header_size() is no longer used and can be removed. This patch is a hg backout of [1] where it was introduced, plus the two followup bug fixes [2] & [3]. This is a clean backout, with the exception of light editing needed in two places, because: 1) The function Universe::narrow_oop_base() has since been renamed to CompressedOops::base(). 2) The include guard CPU_ARM_VM_MACROASSEMBLER_ARM_HPP has since been renamed to CPU_ARM_MACROASSEMBLER_ARM_HPP. Testing: Tier1-3 on all Oracle platforms Bug: https://bugs.openjdk.java.net/browse/JDK-8225779 Webrev: http://cr.openjdk.java.net/~pliden/8225779/webrev.0 /Per [1] http://hg.openjdk.java.net/jdk/jdk/rev/4ad404da0088 [2] http://hg.openjdk.java.net/jdk/jdk/rev/f642ede2eb07 [3] http://hg.openjdk.java.net/jdk/jdk/rev/18bd95c0e463 From david.holmes at oracle.com Fri Jun 14 06:45:43 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Jun 2019 16:45:43 +1000 Subject: RFR: 8225779: Remove unused CollectedHeap::cell_header_size() In-Reply-To: <61d76fc8-d4c1-ee30-7f95-bf2d1222eff0@oracle.com> References: <61d76fc8-d4c1-ee30-7f95-bf2d1222eff0@oracle.com> Message-ID: <25aab23e-b5fe-5b68-a3eb-01e10d1787cc@oracle.com> Hi Per, On 14/06/2019 4:29 pm, Per Liden wrote: > CollectedHeap::cell_header_size() is no longer used and can be removed. It seems no longer used simply because you are removing the uses. :) > This patch is a hg backout of [1] where it was introduced, plus the two > followup bug fixes [2] & [3]. Can you explain why you are rolling back: "8213199: GC abstraction for Assembler::needs_explicit_null_check()" ? Does Shenandoah no longer need it so we can just return to the simpler code that existed before? > This is a clean backout, with the exception of light editing needed in > two places, because: > > 1) The function Universe::narrow_oop_base() has since been renamed to > CompressedOops::base(). > 2) The include guard CPU_ARM_VM_MACROASSEMBLER_ARM_HPP has since been > renamed to CPU_ARM_MACROASSEMBLER_ARM_HPP. The backout itself looks good. Thanks, David ---- > Testing: Tier1-3 on all Oracle platforms > > Bug: https://bugs.openjdk.java.net/browse/JDK-8225779 > Webrev: http://cr.openjdk.java.net/~pliden/8225779/webrev.0 > > /Per > > [1] http://hg.openjdk.java.net/jdk/jdk/rev/4ad404da0088 > [2] http://hg.openjdk.java.net/jdk/jdk/rev/f642ede2eb07 > [3] http://hg.openjdk.java.net/jdk/jdk/rev/18bd95c0e463 From per.liden at oracle.com Fri Jun 14 06:56:29 2019 From: per.liden at oracle.com (Per Liden) Date: Fri, 14 Jun 2019 08:56:29 +0200 Subject: RFR: 8225779: Remove unused CollectedHeap::cell_header_size() In-Reply-To: <25aab23e-b5fe-5b68-a3eb-01e10d1787cc@oracle.com> References: <61d76fc8-d4c1-ee30-7f95-bf2d1222eff0@oracle.com> <25aab23e-b5fe-5b68-a3eb-01e10d1787cc@oracle.com> Message-ID: Hi, On 6/14/19 8:45 AM, David Holmes wrote: > Hi Per, > > On 14/06/2019 4:29 pm, Per Liden wrote: >> CollectedHeap::cell_header_size() is no longer used and can be removed. > > It seems no longer used simply because you are removing the uses. :) Sorry, I should have been more clear. There are no longer any GC that overrides cell_header_size(). Shenandoah used to do that, but doesn't anymore. > >> This patch is a hg backout of [1] where it was introduced, plus the >> two followup bug fixes [2] & [3]. > > Can you explain why you are rolling back: > > "8213199: GC abstraction for Assembler::needs_explicit_null_check()" > > ? Does Shenandoah no longer need it so we can just return to the simpler > code that existed before? Exactly. Back when this was introduced, there were discussions about making "cell" and "cell header" first class concepts in the GC infrastructure. However, this never went further than the introduction of cell_header_size(). Since Shenandoah doesn't need this anymore, we can revert back to the old code and not have to think/talk about cells anymore. > >> This is a clean backout, with the exception of light editing needed in >> two places, because: >> >> 1) The function Universe::narrow_oop_base() has since been renamed to >> CompressedOops::base(). >> 2) The include guard CPU_ARM_VM_MACROASSEMBLER_ARM_HPP has since been >> renamed to CPU_ARM_MACROASSEMBLER_ARM_HPP. > > The backout itself looks good. Thanks for reviewing, David! cheers, Per > > Thanks, > David > ---- > >> Testing: Tier1-3 on all Oracle platforms >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8225779 >> Webrev: http://cr.openjdk.java.net/~pliden/8225779/webrev.0 >> >> /Per >> >> [1] http://hg.openjdk.java.net/jdk/jdk/rev/4ad404da0088 >> [2] http://hg.openjdk.java.net/jdk/jdk/rev/f642ede2eb07 >> [3] http://hg.openjdk.java.net/jdk/jdk/rev/18bd95c0e463 From david.holmes at oracle.com Fri Jun 14 07:45:54 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Jun 2019 17:45:54 +1000 Subject: RFR: 8225779: Remove unused CollectedHeap::cell_header_size() In-Reply-To: References: <61d76fc8-d4c1-ee30-7f95-bf2d1222eff0@oracle.com> <25aab23e-b5fe-5b68-a3eb-01e10d1787cc@oracle.com> Message-ID: Thanks for clarifying. Cheers, David On 14/06/2019 4:56 pm, Per Liden wrote: > Hi, > > On 6/14/19 8:45 AM, David Holmes wrote: >> Hi Per, >> >> On 14/06/2019 4:29 pm, Per Liden wrote: >>> CollectedHeap::cell_header_size() is no longer used and can be removed. >> >> It seems no longer used simply because you are removing the uses. :) > > Sorry, I should have been more clear. There are no longer any GC that > overrides cell_header_size(). Shenandoah used to do that, but doesn't > anymore. > >> >>> This patch is a hg backout of [1] where it was introduced, plus the >>> two followup bug fixes [2] & [3]. >> >> Can you explain why you are rolling back: >> >> "8213199: GC abstraction for Assembler::needs_explicit_null_check()" >> >> ? Does Shenandoah no longer need it so we can just return to the >> simpler code that existed before? > > Exactly. Back when this was introduced, there were discussions about > making "cell" and "cell header" first class concepts in the GC > infrastructure. However, this never went further than the introduction > of cell_header_size(). Since Shenandoah doesn't need this anymore, we > can revert back to the old code and not have to think/talk about cells > anymore. > >> >>> This is a clean backout, with the exception of light editing needed >>> in two places, because: >>> >>> 1) The function Universe::narrow_oop_base() has since been renamed to >>> CompressedOops::base(). >>> 2) The include guard CPU_ARM_VM_MACROASSEMBLER_ARM_HPP has since been >>> renamed to CPU_ARM_MACROASSEMBLER_ARM_HPP. >> >> The backout itself looks good. > > Thanks for reviewing, David! > > cheers, > Per > >> >> Thanks, >> David >> ---- >> >>> Testing: Tier1-3 on all Oracle platforms >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225779 >>> Webrev: http://cr.openjdk.java.net/~pliden/8225779/webrev.0 >>> >>> /Per >>> >>> [1] http://hg.openjdk.java.net/jdk/jdk/rev/4ad404da0088 >>> [2] http://hg.openjdk.java.net/jdk/jdk/rev/f642ede2eb07 >>> [3] http://hg.openjdk.java.net/jdk/jdk/rev/18bd95c0e463 From shade at redhat.com Fri Jun 14 08:27:53 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 14 Jun 2019 10:27:53 +0200 Subject: RFR: 8225779: Remove unused CollectedHeap::cell_header_size() In-Reply-To: <61d76fc8-d4c1-ee30-7f95-bf2d1222eff0@oracle.com> References: <61d76fc8-d4c1-ee30-7f95-bf2d1222eff0@oracle.com> Message-ID: <075752d4-127a-a88c-63fa-9eedf84afccd@redhat.com> On 6/14/19 8:29 AM, Per Liden wrote: > CollectedHeap::cell_header_size() is no longer used and can be removed. This patch is a hg backout > of [1] where it was introduced, plus the two followup bug fixes [2] & [3]. > > This is a clean backout, with the exception of light editing needed in two places, because: > > 1) The function Universe::narrow_oop_base() has since been renamed to CompressedOops::base(). > 2) The include guard CPU_ARM_VM_MACROASSEMBLER_ARM_HPP has since been renamed to > CPU_ARM_MACROASSEMBLER_ARM_HPP. > > Testing: Tier1-3 on all Oracle platforms > > Bug: https://bugs.openjdk.java.net/browse/JDK-8225779 > Webrev: http://cr.openjdk.java.net/~pliden/8225779/webrev.0 Looks fine. Shenandoah does not need it anymore, because there are no accesses beyond the "regular" objects anymore -- this is why it is not actually used. The patch passes hotspot_gc_shenandoah anyway. -- Thanks, -Aleksey From shade at redhat.com Fri Jun 14 08:33:01 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 14 Jun 2019 10:33:01 +0200 Subject: RFR (S) 8225743: Remove ShenandoahBarrierSetC2::escape_is_barrier_node and related GC interface Message-ID: <46f5d65a-3f45-5065-e552-00632291d44e@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8225743 This is the leftover from the times Shenandoah had an option to not optimize out barriers on newly allocated objects. This is have not been needed for a while. Since Shenandoah is the only user of this method, it makes sense to remove it completely, Fix: http://cr.openjdk.java.net/~shade/8225743/webrev.01/ Testing: hotspot_gc_shenandoah, jdk-submit -- Thanks, -Aleksey From rwestrel at redhat.com Fri Jun 14 08:38:54 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 14 Jun 2019 10:38:54 +0200 Subject: RFR (S) 8225743: Remove ShenandoahBarrierSetC2::escape_is_barrier_node and related GC interface In-Reply-To: <46f5d65a-3f45-5065-e552-00632291d44e@redhat.com> References: <46f5d65a-3f45-5065-e552-00632291d44e@redhat.com> Message-ID: <87h88sd0ip.fsf@redhat.com> > http://cr.openjdk.java.net/~shade/8225743/webrev.01/ Looks good to me. Roland. From rkennke at redhat.com Fri Jun 14 09:15:26 2019 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 14 Jun 2019 11:15:26 +0200 Subject: RFR: 8225779: Remove unused CollectedHeap::cell_header_size() In-Reply-To: <61d76fc8-d4c1-ee30-7f95-bf2d1222eff0@oracle.com> References: <61d76fc8-d4c1-ee30-7f95-bf2d1222eff0@oracle.com> Message-ID: Looks good to me. If we are into cleaning up unused interfaces, there are more candidates: - CH::obj_size() is not needed anymore for the same reason as cell_size() - All object equals is not needed anymore, and hard to maintain if not used by an actual GC - The allocation paths, even though I'd tend to keep it for the GC-owns-it-all paradigm - The primitive barrier stuff, even though I'd tend to keep it for the GC-owns-it-all paradigm I probably missed some too ;-) Cheers, Roman Am 14. Juni 2019 08:29:06 MESZ schrieb Per Liden : >CollectedHeap::cell_header_size() is no longer used and can be removed. > >This patch is a hg backout of [1] where it was introduced, plus the two > >followup bug fixes [2] & [3]. > >This is a clean backout, with the exception of light editing needed in >two places, because: > >1) The function Universe::narrow_oop_base() has since been renamed to >CompressedOops::base(). >2) The include guard CPU_ARM_VM_MACROASSEMBLER_ARM_HPP has since been >renamed to CPU_ARM_MACROASSEMBLER_ARM_HPP. > >Testing: Tier1-3 on all Oracle platforms > >Bug: https://bugs.openjdk.java.net/browse/JDK-8225779 >Webrev: http://cr.openjdk.java.net/~pliden/8225779/webrev.0 > >/Per > >[1] http://hg.openjdk.java.net/jdk/jdk/rev/4ad404da0088 >[2] http://hg.openjdk.java.net/jdk/jdk/rev/f642ede2eb07 >[3] http://hg.openjdk.java.net/jdk/jdk/rev/18bd95c0e463 -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From erik.osterlund at oracle.com Fri Jun 14 09:26:08 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 14 Jun 2019 11:26:08 +0200 Subject: RFR: 8225779: Remove unused CollectedHeap::cell_header_size() In-Reply-To: <61d76fc8-d4c1-ee30-7f95-bf2d1222eff0@oracle.com> References: <61d76fc8-d4c1-ee30-7f95-bf2d1222eff0@oracle.com> Message-ID: <5207d4e5-6feb-b65a-6940-892c0e88f825@oracle.com> Hi Per, I don't think it is a good idea to completely revert the changes made to MacroAssembler::needs_explicit_null_check(). This was not just done for interfacing. The code we had before was actually wrong. We called that function with both addresses (from signal handlers) and offsets (from the compiler), and tried to look at the passed in value whether it quacks like an offset or an address based on its value. If it looked like an address it would first be normalized to look like an offset. But it was possible that a much-larger-than-page offset is passed in that actually looks like an address according to the address quacking code, which turns the supposedly address looking value into an offset normalized form that looks like it wouldn't need explicit null checks because in that form the offset is within one page, while the original offset passed in totally would need an explicit null check really, because it totally wasn't within that one page offset we allowed. To make this more sound, the function was split into two - one used for addresses passed in by signal handlers, and one used for offsets used by the compiler. This completely removed the value based check to determine if the argument looks like an address or offset. I would definitely like to keep that structure going forward, because otherwise that bug will be re-introduced. Otherwise, I do encourage removing the now unnecessary cell header size abstraction. /Erik On 2019-06-14 08:29, Per Liden wrote: > CollectedHeap::cell_header_size() is no longer used and can be removed. > This patch is a hg backout of [1] where it was introduced, plus the two > followup bug fixes [2] & [3]. > > This is a clean backout, with the exception of light editing needed in > two places, because: > > 1) The function Universe::narrow_oop_base() has since been renamed to > CompressedOops::base(). > 2) The include guard CPU_ARM_VM_MACROASSEMBLER_ARM_HPP has since been > renamed to CPU_ARM_MACROASSEMBLER_ARM_HPP. > > Testing: Tier1-3 on all Oracle platforms > > Bug: https://bugs.openjdk.java.net/browse/JDK-8225779 > Webrev: http://cr.openjdk.java.net/~pliden/8225779/webrev.0 > > /Per > > [1] http://hg.openjdk.java.net/jdk/jdk/rev/4ad404da0088 > [2] http://hg.openjdk.java.net/jdk/jdk/rev/f642ede2eb07 > [3] http://hg.openjdk.java.net/jdk/jdk/rev/18bd95c0e463 From erik.osterlund at oracle.com Fri Jun 14 09:32:14 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 14 Jun 2019 11:32:14 +0200 Subject: RFR (S) 8225743: Remove ShenandoahBarrierSetC2::escape_is_barrier_node and related GC interface In-Reply-To: <46f5d65a-3f45-5065-e552-00632291d44e@redhat.com> References: <46f5d65a-3f45-5065-e552-00632291d44e@redhat.com> Message-ID: <78c4567d-cac5-e861-b2c2-78db0cc2953e@oracle.com> Hi Aleksey, Looks good. Thanks, /Erik On 2019-06-14 10:33, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8225743 > > This is the leftover from the times Shenandoah had an option to not optimize out barriers on newly > allocated objects. This is have not been needed for a while. Since Shenandoah is the only user of > this method, it makes sense to remove it completely, > > Fix: > http://cr.openjdk.java.net/~shade/8225743/webrev.01/ > > Testing: hotspot_gc_shenandoah, jdk-submit > From rkennke at redhat.com Fri Jun 14 09:56:58 2019 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 14 Jun 2019 11:56:58 +0200 Subject: RFR: 8225779: Remove unused CollectedHeap::cell_header_size() In-Reply-To: <5207d4e5-6feb-b65a-6940-892c0e88f825@oracle.com> References: <61d76fc8-d4c1-ee30-7f95-bf2d1222eff0@oracle.com> <5207d4e5-6feb-b65a-6940-892c0e88f825@oracle.com> Message-ID: Just as I sent my approval, I was thinking the same. The new needs_explicit_null_check() is more correct and also better readable. Roman Am 14. Juni 2019 11:26:08 MESZ schrieb "Erik ?sterlund" : >Hi Per, > >I don't think it is a good idea to completely revert the changes made >to >MacroAssembler::needs_explicit_null_check(). This was not just done for > >interfacing. The code we had before was actually wrong. > >We called that function with both addresses (from signal handlers) and >offsets (from the compiler), and tried to look at the passed in value >whether it quacks like an offset or an address based on its value. If >it >looked like an address it would first be normalized to look like an >offset. But it was possible that a much-larger-than-page offset is >passed in that actually looks like an address according to the address >quacking code, which turns the supposedly address looking value into an > >offset normalized form that looks like it wouldn't need explicit null >checks because in that form the offset is within one page, while the >original offset passed in totally would need an explicit null check >really, because it totally wasn't within that one page offset we >allowed. > >To make this more sound, the function was split into two - one used for > >addresses passed in by signal handlers, and one used for offsets used >by >the compiler. This completely removed the value based check to >determine >if the argument looks like an address or offset. I would definitely >like >to keep that structure going forward, because otherwise that bug will >be >re-introduced. > >Otherwise, I do encourage removing the now unnecessary cell header size > >abstraction. > >/Erik > >On 2019-06-14 08:29, Per Liden wrote: >> CollectedHeap::cell_header_size() is no longer used and can be >removed. >> This patch is a hg backout of [1] where it was introduced, plus the >two >> followup bug fixes [2] & [3]. >> >> This is a clean backout, with the exception of light editing needed >in >> two places, because: >> >> 1) The function Universe::narrow_oop_base() has since been renamed to > >> CompressedOops::base(). >> 2) The include guard CPU_ARM_VM_MACROASSEMBLER_ARM_HPP has since been > >> renamed to CPU_ARM_MACROASSEMBLER_ARM_HPP. >> >> Testing: Tier1-3 on all Oracle platforms >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8225779 >> Webrev: http://cr.openjdk.java.net/~pliden/8225779/webrev.0 >> >> /Per >> >> [1] http://hg.openjdk.java.net/jdk/jdk/rev/4ad404da0088 >> [2] http://hg.openjdk.java.net/jdk/jdk/rev/f642ede2eb07 >> [3] http://hg.openjdk.java.net/jdk/jdk/rev/18bd95c0e463 -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From per.liden at oracle.com Fri Jun 14 11:43:36 2019 From: per.liden at oracle.com (Per Liden) Date: Fri, 14 Jun 2019 13:43:36 +0200 Subject: RFR: 8225779: Remove unused CollectedHeap::cell_header_size() In-Reply-To: <5207d4e5-6feb-b65a-6940-892c0e88f825@oracle.com> References: <61d76fc8-d4c1-ee30-7f95-bf2d1222eff0@oracle.com> <5207d4e5-6feb-b65a-6940-892c0e88f825@oracle.com> Message-ID: <6df1fa33-2393-d46d-1e43-3d9ee7dc9489@oracle.com> Hi, On 6/14/19 11:26 AM, Erik ?sterlund wrote: > Hi Per, > > I don't think it is a good idea to completely revert the changes made to > MacroAssembler::needs_explicit_null_check(). This was not just done for > interfacing. The code we had before was actually wrong. > > We called that function with both addresses (from signal handlers) and > offsets (from the compiler), and tried to look at the passed in value > whether it quacks like an offset or an address based on its value. If it > looked like an address it would first be normalized to look like an > offset. But it was possible that a much-larger-than-page offset is > passed in that actually looks like an address according to the address > quacking code, which turns the supposedly address looking value into an > offset normalized form that looks like it wouldn't need explicit null > checks because in that form the offset is within one page, while the > original offset passed in totally would need an explicit null check > really, because it totally wasn't within that one page offset we allowed. > > To make this more sound, the function was split into two - one used for > addresses passed in by signal handlers, and one used for offsets used by > the compiler. This completely removed the value based check to determine > if the argument looks like an address or offset. I would definitely like > to keep that structure going forward, because otherwise that bug will be > re-introduced. I see. I'll revise the patch. Thanks! Per > > Otherwise, I do encourage removing the now unnecessary cell header size > abstraction. > > /Erik > > On 2019-06-14 08:29, Per Liden wrote: >> CollectedHeap::cell_header_size() is no longer used and can be >> removed. This patch is a hg backout of [1] where it was introduced, >> plus the two followup bug fixes [2] & [3]. >> >> This is a clean backout, with the exception of light editing needed in >> two places, because: >> >> 1) The function Universe::narrow_oop_base() has since been renamed to >> CompressedOops::base(). >> 2) The include guard CPU_ARM_VM_MACROASSEMBLER_ARM_HPP has since been >> renamed to CPU_ARM_MACROASSEMBLER_ARM_HPP. >> >> Testing: Tier1-3 on all Oracle platforms >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8225779 >> Webrev: http://cr.openjdk.java.net/~pliden/8225779/webrev.0 >> >> /Per >> >> [1] http://hg.openjdk.java.net/jdk/jdk/rev/4ad404da0088 >> [2] http://hg.openjdk.java.net/jdk/jdk/rev/f642ede2eb07 >> [3] http://hg.openjdk.java.net/jdk/jdk/rev/18bd95c0e463 From doko at ubuntu.com Fri Jun 14 12:57:43 2019 From: doko at ubuntu.com (Matthias Klose) Date: Fri, 14 Jun 2019 14:57:43 +0200 Subject: bootcycle build on ix86-linux-gnu broken since jdk-13+18 Message-ID: My last successful bootcycle build on i686-linux-gnu was jdk-13+18. After that I tried jdk-13+22, which didn't build anymore, with no change to the most recent jdk-13+25, and also seen in jdk-14+1. All builds fail with Compiling 12 properties into resource bundles for jdk.jdeps # # There is insufficient memory for the Java Runtime Environment to continue. # Native memory allocation (malloc) failed to allocate 2155274940 bytes for AllocateHeap # An error report file with more information is saved as: It looks like the normal build instead of the bootcycle build succeeds. Does anybody else is doing regular ix86 builds and could help narrowing down when this started to fail? Thanks, Matthias From david.holmes at oracle.com Fri Jun 14 13:10:07 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Jun 2019 23:10:07 +1000 Subject: bootcycle build on ix86-linux-gnu broken since jdk-13+18 In-Reply-To: References: Message-ID: Hi Matthias, On 14/06/2019 10:57 pm, Matthias Klose wrote: > My last successful bootcycle build on i686-linux-gnu was jdk-13+18. After that I > tried jdk-13+22, which didn't build anymore, with no change to the most recent > jdk-13+25, and also seen in jdk-14+1. > > All builds fail with > > Compiling 12 properties into resource bundles for jdk.jdeps > # > # There is insufficient memory for the Java Runtime Environment to continue. > # Native memory allocation (malloc) failed to allocate 2155274940 bytes for > AllocateHeap > # An error report file with more information is saved as: Do you have the full stack for that? It might shed some light. Thanks, David > It looks like the normal build instead of the bootcycle build succeeds. Does > anybody else is doing regular ix86 builds and could help narrowing down when > this started to fail? > > Thanks, Matthias > From shade at redhat.com Fri Jun 14 13:26:32 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 14 Jun 2019 15:26:32 +0200 Subject: bootcycle build on ix86-linux-gnu broken since jdk-13+18 In-Reply-To: References: Message-ID: On 6/14/19 2:57 PM, Matthias Klose wrote: > My last successful bootcycle build on i686-linux-gnu was jdk-13+18. After that I > tried jdk-13+22, which didn't build anymore, with no change to the most recent > jdk-13+25, and also seen in jdk-14+1. > > All builds fail with > > Compiling 12 properties into resource bundles for jdk.jdeps > # > # There is insufficient memory for the Java Runtime Environment to continue. > # Native memory allocation (malloc) failed to allocate 2155274940 bytes for > AllocateHeap This looks like the environmental trouble? It seems to try to allocate 2G heap, and cannot find (contiguous) memory for it? I would suspect recent changes to make it more likely, for example: https://bugs.openjdk.java.net/browse/JDK-8224871 > # An error report file with more information is saved as: > > It looks like the normal build instead of the bootcycle build succeeds. Does > anybody else is doing regular ix86 builds and could help narrowing down when > this started to fail? I build and test x86_32 regularly, but not bootcycle it. Current jdk/jdk does not build on x86_32, due to JDK-8225695. Current jdk/jdk13 build and runs on x86_32 fine, tier1 seems good too. -Aleksey From doko at ubuntu.com Fri Jun 14 14:02:03 2019 From: doko at ubuntu.com (Matthias Klose) Date: Fri, 14 Jun 2019 16:02:03 +0200 Subject: bootcycle build on ix86-linux-gnu broken since jdk-13+18 In-Reply-To: References: Message-ID: <4901e07e-55ea-9e36-1173-9b0a46b2025c@ubuntu.com> On 14.06.19 15:10, David Holmes wrote: > Hi Matthias, > > On 14/06/2019 10:57 pm, Matthias Klose wrote: >> My last successful bootcycle build on i686-linux-gnu was jdk-13+18. After that I >> tried jdk-13+22, which didn't build anymore, with no change to the most recent >> jdk-13+25, and also seen in jdk-14+1. >> >> All builds fail with >> >> Compiling 12 properties into resource bundles for jdk.jdeps >> # >> # There is insufficient memory for the Java Runtime Environment to continue. >> # Native memory allocation (malloc) failed to allocate 2155274940 bytes for >> AllocateHeap >> # An error report file with more information is saved as: > > Do you have the full stack for that? It might shed some light. now attached. From doko at ubuntu.com Fri Jun 14 14:10:52 2019 From: doko at ubuntu.com (Matthias Klose) Date: Fri, 14 Jun 2019 16:10:52 +0200 Subject: bootcycle build on ix86-linux-gnu broken since jdk-13+18 In-Reply-To: <4901e07e-55ea-9e36-1173-9b0a46b2025c@ubuntu.com> References: <4901e07e-55ea-9e36-1173-9b0a46b2025c@ubuntu.com> Message-ID: <1ba8c918-841d-b2ec-43bb-e2521d4b9049@ubuntu.com> On 14.06.19 16:02, Matthias Klose wrote: > On 14.06.19 15:10, David Holmes wrote: >> Hi Matthias, >> >> On 14/06/2019 10:57 pm, Matthias Klose wrote: >>> My last successful bootcycle build on i686-linux-gnu was jdk-13+18. After that I >>> tried jdk-13+22, which didn't build anymore, with no change to the most recent >>> jdk-13+25, and also seen in jdk-14+1. >>> >>> All builds fail with >>> >>> Compiling 12 properties into resource bundles for jdk.jdeps >>> # >>> # There is insufficient memory for the Java Runtime Environment to continue. >>> # Native memory allocation (malloc) failed to allocate 2155274940 bytes for >>> AllocateHeap >>> # An error report file with more information is saved as: >> >> Do you have the full stack for that? It might shed some light. > > now attached. > From aph at redhat.com Fri Jun 14 17:20:08 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 14 Jun 2019 18:20:08 +0100 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com> <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com> <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com> <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com> <94de2466-4b73-7091-17ee-7168114df1ee@arm.com> <0b355166-4bb7-7de2-b30b-9a481aa085a2@redhat.com> Message-ID: Hi, On 6/12/19 10:35 AM, Nick Gasson wrote: > Sorry for the delay, I've put an updated webrev here: > > http://cr.openjdk.java.net/~ngasson/8224851/webrev.1/ > > Changes since the last patch: > > * Replaced ~((1<<12) - 1) with -1u<<12 > > * Use __atomic_add_fetch in Atomic::PlatformAdd #ifdef __clang__ > > * Use __builtin_frame_address(0) in os::current_frame() > > * Use placement new / copy assignment in pf() > > I also replaced the call to _get_previous_fp() in os::current_frame() with > > *(intptr_t **)__builtin_frame_address(0); > > As it generates the same code and avoids the `register intptr_t **fp > __asm__ (SPELL_REG_FP);' declaration which clang doesn't support. Also > the following comment in _get_previous_fp seems to be wrong: > > // fp is for this frame (_get_previous_fp). We want the fp for the > // caller of os::current_frame*(), so go up two frames. However, for > // optimized builds, _get_previous_fp() will be inlined, so only go > // up 1 frame in that case. > #ifdef _NMT_NOINLINE_ > return **(intptr_t***)fp; > #else > return *fp; > #endif > > Even on -O0 gcc won't generate a stack frame for this function so if > _NMT_NOINLINE_ is defined you get the caller's caller's FP rather than > the caller's FP. I just deleted the function as it's not used anywhere else. > > BTW we can't use __builtin_frame_address(1) as GCC gives a warning when > this is called with a non-zero argument (-Wframe-address). > > Tested jtreg hotspot_all_no_apps and jdk_core (gcc 7.3). OK, that's all good. Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From coppa at di.uniroma1.it Sat Jun 15 16:54:34 2019 From: coppa at di.uniroma1.it (Emilio Coppa) Date: Sat, 15 Jun 2019 18:54:34 +0200 Subject: MPLR 2019 - Second Call for Papers Message-ID: (Apologies if you receive multiple copies of this CFP) ============================================= MPLR 2019 16th International Conference on Managed Programming Languages & Runtimes Co-located with SPLASH 2019 Athens, Greece, Oct 20-25, 2019 https://conf.researchr.org/home/mplr-2019 ============================================= The 16th International Conference on Managed Programming Languages & Runtimes (MPLR, formerly ManLang) is a premier forum for presenting and discussing novel results in all aspects of managed programming languages and runtime systems, which serve as building blocks for some of the most important computing systems around, ranging from small-scale (embedded and real-time systems) to large-scale (cloud-computing and big-data platforms) and anything in between (mobile, IoT, and wearable applications). This year, MPLR is co-located with SPLASH 2019 and sponsored by ACM. For more information, check out the conference website: https://conf.researchr.org/home/mplr-2019 # Topics Topics of interest include but are not limited to: * Languages and Compilers - Managed languages (e.g., Java, Scala, JavaScript, Python, Ruby, C#, F#, Clojure, Groovy, Kotlin, R, Smalltalk, Racket, Rust, Go, etc.) - Domain-specific languages - Language design - Compilers and interpreters - Type systems and program logics - Language interoperability - Parallelism, distribution, and concurrency * Virtual Machines - Managed runtime systems (e.g., JVM, Dalvik VM, Android Runtime (ART), LLVM, .NET CLR, RPython, etc.) - VM design and optimization - VMs for mobile and embedded devices - VMs for real-time applications - Memory management - Hardware/software co-design * Techniques, Tools, and Applications - Static and dynamic program analysis - Testing and debugging - Refactoring - Program understanding - Program synthesis - Security and privacy - Performance analysis and monitoring - Compiler and program verification # Submission Categories MPLR accepts four types of submissions: 1. Regular research papers, which describe novel contributions involving managed language platforms (up to 12 pages excluding bibliography and appendix). Research papers will be evaluated based on their relevance, novelty, technical rigor, and contribution to the state-of-the-art. 2. Work-in-progress research papers, which describe promising new ideas but yet have less maturity than full papers (up to 6 pages excluding bibliography and appendix). When evaluating work-in-progress papers, more emphasis will be placed on novelty and the potential of the new ideas than on technical rigor and experimental results. 3. Industry and tool papers, which present technical challenges and solutions for managed language platforms in the context of deployed applications and systems (up to 6 pages excluding bibliography and appendix). Industry and tool papers will be evaluated on their relevance, usefulness, and results. Suitability for demonstration and availability will also be considered for tool papers. 4. Posters, which can be accompanied by a one-page abstract and will be evaluated on similar criteria as Work-in-progress papers. Posters can accompany any submission as a way to provide additional demonstration and discussion opportunities. MPLR 2019 submissions must conform to the ACM Policy on Prior Publication and Simultaneous Submissions and to the SIGPLAN Republication Policy. # Important Dates and Organization Submission Deadline: ***Jul 8, 2019*** Author Notification: Aug 24, 2019 Camera Ready: Sep 12, 2019 Conference Dates: Oct 20-25, 2019 General Chair: Tony Hosking, Australian National University / Data61, Australia Program Chair: Irene Finocchi, Sapienza University of Rome, Italy Program Committee: * Edd Barrett, King's College London, United Kingdom * Steve Blackburn, Australian National University, Australia * Lubomir Bulej, Charles University, Czech Republic * Shigeru Chiba, University of Tokyo, Japan * Daniele Cono D'Elia, Sapienza University of Rome, Italy * Ana Lucia de Moura, Pontifical Catholic University of Rio de Janeiro, Brazil * Erik Ernst, Google, Denmark * Matthew Hertz, University at Buffalo, United States * Vivek Kumar, Indraprastha Institute of Information Technology, Delhi * Doug Lea, State University of New York (SUNY) Oswego, United States * Magnus Madsen, Aarhus University, Denmark * Hidehiko Masuhara, Tokyo Institute of Technology, Japan * Ana Milanova, Rensselaer Polytechnic Institute, United States * Matthew Parkinson, Microsoft Research, United Kingdom * Gregor Richards, University of Waterloo, Canada * Manuel Rigger, ETH Zurich, Switzerland * Andrea Rosa, University of Lugano, Switzerland * Guido Salvaneschi, TU Darmstadt, Germany * Lukas Stadler, Oracle Labs, Austria * Ben L. Titzer, Google, Germany From nick.gasson at arm.com Mon Jun 17 07:46:52 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Mon, 17 Jun 2019 15:46:52 +0800 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com> <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com> <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com> <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com> <94de2466-4b73-7091-17ee-7168114df1ee@arm.com> <0b355166-4bb7-7de2-b30b-9a481aa085a2@redhat.com> Message-ID: <2119382e-9999-a911-d030-e6932ef424dd@arm.com> On 15/06/2019 01:20, Andrew Haley wrote: > > OK, that's all good. Thanks. > Thanks Andrew. Please double check this final webrev is ok to push: http://cr.openjdk.java.net/~ngasson/8224851/webrev.2/ It's webrev.1 plus Kim's review comments. Nick From david.holmes at oracle.com Mon Jun 17 07:45:28 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Jun 2019 17:45:28 +1000 Subject: bootcycle build on ix86-linux-gnu broken since jdk-13+18 In-Reply-To: <4901e07e-55ea-9e36-1173-9b0a46b2025c@ubuntu.com> References: <4901e07e-55ea-9e36-1173-9b0a46b2025c@ubuntu.com> Message-ID: < cc'ing Calvin> Hi Matthias, This looks like an issue with the new Dynamic Archive support. I'm not sure if it is intended for use on 32-bit, but it looks like the size of the file to map is too large. (or it may relate to the issue Aleksey pointed too - either way it starts from dynamic archive code.) Cheers, David On 15/06/2019 12:02 am, Matthias Klose wrote: > On 14.06.19 15:10, David Holmes wrote: >> Hi Matthias, >> >> On 14/06/2019 10:57 pm, Matthias Klose wrote: >>> My last successful bootcycle build on i686-linux-gnu was jdk-13+18. After that I >>> tried jdk-13+22, which didn't build anymore, with no change to the most recent >>> jdk-13+25, and also seen in jdk-14+1. >>> >>> All builds fail with >>> >>> Compiling 12 properties into resource bundles for jdk.jdeps >>> # >>> # There is insufficient memory for the Java Runtime Environment to continue. >>> # Native memory allocation (malloc) failed to allocate 2155274940 bytes for >>> AllocateHeap >>> # An error report file with more information is saved as: >> >> Do you have the full stack for that? It might shed some light. > > now attached. > From aph at redhat.com Mon Jun 17 08:13:30 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 17 Jun 2019 09:13:30 +0100 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: <2119382e-9999-a911-d030-e6932ef424dd@arm.com> References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com> <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com> <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com> <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com> <94de2466-4b73-7091-17ee-7168114df1ee@arm.com> <0b355166-4bb7-7de2-b30b-9a481aa085a2@redhat.com> <2119382e-9999-a911-d030-e6932ef424dd@arm.com> Message-ID: <901dc528-802f-529f-6a20-9a93f45b7ba3@redhat.com> On 6/17/19 8:46 AM, Nick Gasson wrote: > Thanks Andrew. Please double check this final webrev is ok to push: > > http://cr.openjdk.java.net/~ngasson/8224851/webrev.2/ > > It's webrev.1 plus Kim's review comments. OK, thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From doko at ubuntu.com Mon Jun 17 09:35:30 2019 From: doko at ubuntu.com (Matthias Klose) Date: Mon, 17 Jun 2019 11:35:30 +0200 Subject: bootcycle build on ix86-linux-gnu broken since jdk-13+18 In-Reply-To: References: <4901e07e-55ea-9e36-1173-9b0a46b2025c@ubuntu.com> Message-ID: <503407fa-e31e-1f35-d4bd-23a3df334acd@ubuntu.com> On 17.06.19 09:45, David Holmes wrote: > > > < cc'ing Calvin> > > Hi Matthias, > > This looks like an issue with the new Dynamic Archive support. I'm not sure if > it is intended for use on 32-bit, but it looks like the size of the file to map > is too large. (or it may relate to the issue Aleksey pointed too - either way it > starts from dynamic archive code.) yes, configuring with --disable-cds works around the build failure. Looking at the other 32bit hotspot build, it looks like the armhf build works with enabled cds. Matthias > > Cheers, > David > > > > On 15/06/2019 12:02 am, Matthias Klose wrote: >> On 14.06.19 15:10, David Holmes wrote: >>> Hi Matthias, >>> >>> On 14/06/2019 10:57 pm, Matthias Klose wrote: >>>> My last successful bootcycle build on i686-linux-gnu was jdk-13+18. After >>>> that I >>>> tried jdk-13+22, which didn't build anymore, with no change to the most recent >>>> jdk-13+25, and also seen in jdk-14+1. >>>> >>>> All builds fail with >>>> >>>> Compiling 12 properties into resource bundles for jdk.jdeps >>>> # >>>> # There is insufficient memory for the Java Runtime Environment to continue. >>>> # Native memory allocation (malloc) failed to allocate 2155274940 bytes for >>>> AllocateHeap >>>> # An error report file with more information is saved as: >>> >>> Do you have the full stack for that? It might shed some light. >> >> now attached. >> From Pengfei.Li at arm.com Mon Jun 17 10:27:38 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Mon, 17 Jun 2019 10:27:38 +0000 Subject: RFR(T): 8226222: [JVMCI] Export AArch64 field VM_Version::_psr_info.dczid_el0 Message-ID: Hi, Could you help review this small change on JVMCI? Webrev: http://cr.openjdk.java.net/~pli/rfr/8226222/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8226222 We would like to implement memory bulk zeroing by cache maintenance (DC ZVA) instruction in AArch64 Graal compiler. To make AArch64 processor info "dczid_el0" available to get at compile-time, this patch exports AArch64 HotSpot field VM_Version::_psr_info.dczid_el0 and also fixes out-of-date AArch64 macro in JVMCI. -- Thanks, Pengfei From per.liden at oracle.com Mon Jun 17 12:51:13 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 17 Jun 2019 14:51:13 +0200 Subject: RFR: 8225779: Remove unused CollectedHeap::cell_header_size() In-Reply-To: <6df1fa33-2393-d46d-1e43-3d9ee7dc9489@oracle.com> References: <61d76fc8-d4c1-ee30-7f95-bf2d1222eff0@oracle.com> <5207d4e5-6feb-b65a-6940-892c0e88f825@oracle.com> <6df1fa33-2393-d46d-1e43-3d9ee7dc9489@oracle.com> Message-ID: Here's an updated webrev, which just removes the cell_header_size() and its uses, but otherwise keeps the code as is. http://cr.openjdk.java.net/~pliden/8225779/webrev.1 cheers, Per On 6/14/19 1:43 PM, Per Liden wrote: > Hi, > > On 6/14/19 11:26 AM, Erik ?sterlund wrote: >> Hi Per, >> >> I don't think it is a good idea to completely revert the changes made >> to MacroAssembler::needs_explicit_null_check(). This was not just done >> for interfacing. The code we had before was actually wrong. >> >> We called that function with both addresses (from signal handlers) and >> offsets (from the compiler), and tried to look at the passed in value >> whether it quacks like an offset or an address based on its value. If >> it looked like an address it would first be normalized to look like an >> offset. But it was possible that a much-larger-than-page offset is >> passed in that actually looks like an address according to the address >> quacking code, which turns the supposedly address looking value into >> an offset normalized form that looks like it wouldn't need explicit >> null checks because in that form the offset is within one page, while >> the original offset passed in totally would need an explicit null >> check really, because it totally wasn't within that one page offset we >> allowed. >> >> To make this more sound, the function was split into two - one used >> for addresses passed in by signal handlers, and one used for offsets >> used by the compiler. This completely removed the value based check to >> determine if the argument looks like an address or offset. I would >> definitely like to keep that structure going forward, because >> otherwise that bug will be re-introduced. > > I see. I'll revise the patch. > > Thanks! > Per > >> >> Otherwise, I do encourage removing the now unnecessary cell header >> size abstraction. >> >> /Erik >> >> On 2019-06-14 08:29, Per Liden wrote: >>> CollectedHeap::cell_header_size() is no longer used and can be >>> removed. This patch is a hg backout of [1] where it was introduced, >>> plus the two followup bug fixes [2] & [3]. >>> >>> This is a clean backout, with the exception of light editing needed >>> in two places, because: >>> >>> 1) The function Universe::narrow_oop_base() has since been renamed to >>> CompressedOops::base(). >>> 2) The include guard CPU_ARM_VM_MACROASSEMBLER_ARM_HPP has since been >>> renamed to CPU_ARM_MACROASSEMBLER_ARM_HPP. >>> >>> Testing: Tier1-3 on all Oracle platforms >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225779 >>> Webrev: http://cr.openjdk.java.net/~pliden/8225779/webrev.0 >>> >>> /Per >>> >>> [1] http://hg.openjdk.java.net/jdk/jdk/rev/4ad404da0088 >>> [2] http://hg.openjdk.java.net/jdk/jdk/rev/f642ede2eb07 >>> [3] http://hg.openjdk.java.net/jdk/jdk/rev/18bd95c0e463 From shade at redhat.com Mon Jun 17 12:55:13 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 17 Jun 2019 14:55:13 +0200 Subject: RFR: 8225779: Remove unused CollectedHeap::cell_header_size() In-Reply-To: References: <61d76fc8-d4c1-ee30-7f95-bf2d1222eff0@oracle.com> <5207d4e5-6feb-b65a-6940-892c0e88f825@oracle.com> <6df1fa33-2393-d46d-1e43-3d9ee7dc9489@oracle.com> Message-ID: On 6/17/19 2:51 PM, Per Liden wrote: > Here's an updated webrev, which just removes the cell_header_size() and its uses, but otherwise > keeps the code as is. > > http://cr.openjdk.java.net/~pliden/8225779/webrev.1 Still looks good. -Aleksey From vladimir.kozlov at oracle.com Mon Jun 17 15:51:14 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 17 Jun 2019 08:51:14 -0700 Subject: RFR(T): 8226222: [JVMCI] Export AArch64 field VM_Version::_psr_info.dczid_el0 In-Reply-To: References: Message-ID: <45a20e63-2eb6-9627-54e8-1a0a1dcba97a@oracle.com> Hi Pengfei, This looks fine to me. We can push it into jdk/jdk (which is jdk 14 now). I am not sure where we should backport this. Doug, what do you think? The dczid_el0 field was added in JDK 9. Thanks, Vladimir On 6/17/19 3:27 AM, Pengfei Li (Arm Technology China) wrote: > Hi, > > Could you help review this small change on JVMCI? > > Webrev: http://cr.openjdk.java.net/~pli/rfr/8226222/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8226222 > > We would like to implement memory bulk zeroing by cache maintenance (DC ZVA) instruction in AArch64 Graal compiler. To make AArch64 processor info "dczid_el0" available to get at compile-time, this patch exports AArch64 HotSpot field VM_Version::_psr_info.dczid_el0 and also fixes out-of-date AArch64 macro in JVMCI. > > -- > Thanks, > Pengfei > From gnu.andrew at redhat.com Mon Jun 17 16:14:34 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 17 Jun 2019 17:14:34 +0100 Subject: RFR: [8u] 8202353: os::readdir should use readdir instead of readdir_r In-Reply-To: <98eb0d53-beb8-92b7-cc99-69a4cbf587c9@redhat.com> References: <98eb0d53-beb8-92b7-cc99-69a4cbf587c9@redhat.com> Message-ID: On 03/06/2019 18:13, Aleksey Shipilev wrote: > On 5/31/19 7:17 PM, Andrew John Hughes wrote: >> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8202353/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202353 > > Looks fine. > > src/os/windows/vm/os_windows.cpp has the trailing newline removed? > > -Aleksey > I think there was an extra one that was removed by running the normalizer script, but I've removed that change regardless. Pushed the rest: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/0f2fe7d37d8c Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From per.liden at oracle.com Mon Jun 17 20:20:42 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 17 Jun 2019 22:20:42 +0200 Subject: RFR: 8225779: Remove unused CollectedHeap::cell_header_size() In-Reply-To: References: <61d76fc8-d4c1-ee30-7f95-bf2d1222eff0@oracle.com> <5207d4e5-6feb-b65a-6940-892c0e88f825@oracle.com> <6df1fa33-2393-d46d-1e43-3d9ee7dc9489@oracle.com> Message-ID: Thanks for reviewing, Aleksey! /Per On 6/17/19 2:55 PM, Aleksey Shipilev wrote: > On 6/17/19 2:51 PM, Per Liden wrote: >> Here's an updated webrev, which just removes the cell_header_size() and its uses, but otherwise >> keeps the code as is. >> >> http://cr.openjdk.java.net/~pliden/8225779/webrev.1 > > Still looks good. > > -Aleksey > From rkennke at redhat.com Mon Jun 17 20:24:42 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 17 Jun 2019 22:24:42 +0200 Subject: RFR: 8225779: Remove unused CollectedHeap::cell_header_size() In-Reply-To: References: <61d76fc8-d4c1-ee30-7f95-bf2d1222eff0@oracle.com> <5207d4e5-6feb-b65a-6940-892c0e88f825@oracle.com> <6df1fa33-2393-d46d-1e43-3d9ee7dc9489@oracle.com> Message-ID: <0b57cf7d-8942-3ec7-01b4-1f77b4c99e1b@redhat.com> > Here's an updated webrev, which just removes the cell_header_size() and > its uses, but otherwise keeps the code as is. > > http://cr.openjdk.java.net/~pliden/8225779/webrev.1 Looks good! Thanks! Roman > > On 6/14/19 1:43 PM, Per Liden wrote: >> Hi, >> >> On 6/14/19 11:26 AM, Erik ?sterlund wrote: >>> Hi Per, >>> >>> I don't think it is a good idea to completely revert the changes made >>> to MacroAssembler::needs_explicit_null_check(). This was not just >>> done for interfacing. The code we had before was actually wrong. >>> >>> We called that function with both addresses (from signal handlers) >>> and offsets (from the compiler), and tried to look at the passed in >>> value whether it quacks like an offset or an address based on its >>> value. If it looked like an address it would first be normalized to >>> look like an offset. But it was possible that a much-larger-than-page >>> offset is passed in that actually looks like an address according to >>> the address quacking code, which turns the supposedly address looking >>> value into an offset normalized form that looks like it wouldn't need >>> explicit null checks because in that form the offset is within one >>> page, while the original offset passed in totally would need an >>> explicit null check really, because it totally wasn't within that one >>> page offset we allowed. >>> >>> To make this more sound, the function was split into two - one used >>> for addresses passed in by signal handlers, and one used for offsets >>> used by the compiler. This completely removed the value based check >>> to determine if the argument looks like an address or offset. I would >>> definitely like to keep that structure going forward, because >>> otherwise that bug will be re-introduced. >> >> I see. I'll revise the patch. >> >> Thanks! >> Per >> >>> >>> Otherwise, I do encourage removing the now unnecessary cell header >>> size abstraction. >>> >>> /Erik >>> >>> On 2019-06-14 08:29, Per Liden wrote: >>>> CollectedHeap::cell_header_size() is no longer used and can be >>>> removed. This patch is a hg backout of [1] where it was introduced, >>>> plus the two followup bug fixes [2] & [3]. >>>> >>>> This is a clean backout, with the exception of light editing needed >>>> in two places, because: >>>> >>>> 1) The function Universe::narrow_oop_base() has since been renamed >>>> to CompressedOops::base(). >>>> 2) The include guard CPU_ARM_VM_MACROASSEMBLER_ARM_HPP has since >>>> been renamed to CPU_ARM_MACROASSEMBLER_ARM_HPP. >>>> >>>> Testing: Tier1-3 on all Oracle platforms >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225779 >>>> Webrev: http://cr.openjdk.java.net/~pliden/8225779/webrev.0 >>>> >>>> /Per >>>> >>>> [1] http://hg.openjdk.java.net/jdk/jdk/rev/4ad404da0088 >>>> [2] http://hg.openjdk.java.net/jdk/jdk/rev/f642ede2eb07 >>>> [3] http://hg.openjdk.java.net/jdk/jdk/rev/18bd95c0e463 From per.liden at oracle.com Mon Jun 17 20:40:39 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 17 Jun 2019 22:40:39 +0200 Subject: RFR: 8225779: Remove unused CollectedHeap::cell_header_size() In-Reply-To: <0b57cf7d-8942-3ec7-01b4-1f77b4c99e1b@redhat.com> References: <61d76fc8-d4c1-ee30-7f95-bf2d1222eff0@oracle.com> <5207d4e5-6feb-b65a-6940-892c0e88f825@oracle.com> <6df1fa33-2393-d46d-1e43-3d9ee7dc9489@oracle.com> <0b57cf7d-8942-3ec7-01b4-1f77b4c99e1b@redhat.com> Message-ID: Thanks Roman! /Per On 6/17/19 10:24 PM, Roman Kennke wrote: >> Here's an updated webrev, which just removes the cell_header_size() and >> its uses, but otherwise keeps the code as is. >> >> http://cr.openjdk.java.net/~pliden/8225779/webrev.1 > > Looks good! Thanks! > Roman > > >> >> On 6/14/19 1:43 PM, Per Liden wrote: >>> Hi, >>> >>> On 6/14/19 11:26 AM, Erik ?sterlund wrote: >>>> Hi Per, >>>> >>>> I don't think it is a good idea to completely revert the changes made >>>> to MacroAssembler::needs_explicit_null_check(). This was not just >>>> done for interfacing. The code we had before was actually wrong. >>>> >>>> We called that function with both addresses (from signal handlers) >>>> and offsets (from the compiler), and tried to look at the passed in >>>> value whether it quacks like an offset or an address based on its >>>> value. If it looked like an address it would first be normalized to >>>> look like an offset. But it was possible that a much-larger-than-page >>>> offset is passed in that actually looks like an address according to >>>> the address quacking code, which turns the supposedly address looking >>>> value into an offset normalized form that looks like it wouldn't need >>>> explicit null checks because in that form the offset is within one >>>> page, while the original offset passed in totally would need an >>>> explicit null check really, because it totally wasn't within that one >>>> page offset we allowed. >>>> >>>> To make this more sound, the function was split into two - one used >>>> for addresses passed in by signal handlers, and one used for offsets >>>> used by the compiler. This completely removed the value based check >>>> to determine if the argument looks like an address or offset. I would >>>> definitely like to keep that structure going forward, because >>>> otherwise that bug will be re-introduced. >>> >>> I see. I'll revise the patch. >>> >>> Thanks! >>> Per >>> >>>> >>>> Otherwise, I do encourage removing the now unnecessary cell header >>>> size abstraction. >>>> >>>> /Erik >>>> >>>> On 2019-06-14 08:29, Per Liden wrote: >>>>> CollectedHeap::cell_header_size() is no longer used and can be >>>>> removed. This patch is a hg backout of [1] where it was introduced, >>>>> plus the two followup bug fixes [2] & [3]. >>>>> >>>>> This is a clean backout, with the exception of light editing needed >>>>> in two places, because: >>>>> >>>>> 1) The function Universe::narrow_oop_base() has since been renamed >>>>> to CompressedOops::base(). >>>>> 2) The include guard CPU_ARM_VM_MACROASSEMBLER_ARM_HPP has since >>>>> been renamed to CPU_ARM_MACROASSEMBLER_ARM_HPP. >>>>> >>>>> Testing: Tier1-3 on all Oracle platforms >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225779 >>>>> Webrev: http://cr.openjdk.java.net/~pliden/8225779/webrev.0 >>>>> >>>>> /Per >>>>> >>>>> [1] http://hg.openjdk.java.net/jdk/jdk/rev/4ad404da0088 >>>>> [2] http://hg.openjdk.java.net/jdk/jdk/rev/f642ede2eb07 >>>>> [3] http://hg.openjdk.java.net/jdk/jdk/rev/18bd95c0e463 > From per.liden at oracle.com Mon Jun 17 21:36:09 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 17 Jun 2019 23:36:09 +0200 Subject: RFR: 8225779: Remove unused CollectedHeap::cell_header_size() In-Reply-To: References: <61d76fc8-d4c1-ee30-7f95-bf2d1222eff0@oracle.com> <5207d4e5-6feb-b65a-6940-892c0e88f825@oracle.com> <6df1fa33-2393-d46d-1e43-3d9ee7dc9489@oracle.com> Message-ID: Stefan pointed out that it looks like this piece of code can still pass in a negative offset (Type::OffsetBot = -2000000001) to MacroAssembler::needs_explicit_null_check(), which would cause the assert in that function to fail. I'm not hitting this in our testing, but it certainly looks suspicious. void PhaseCFG::implicit_null_check(Block* block, Node *proj, Node *val, int allowed_reasons) { [...] const Node* base = mach->get_base_and_disp(offset, adr_type); if (base == NULL || base == NodeSentinel) { // Narrow oop address doesn't have base, only index. // Give up if offset is beyond page size or if heap base is not protected. if (val->bottom_type()->isa_narrowoop() && (MacroAssembler::needs_explicit_null_check(offset) || !CompressedOops::use_implicit_null_checks())) continue; [...] } Unless someone can explain that this can't happen, I think it would be safer to remove the assert and instead return true for all negative values, like we do today. Diff: http://cr.openjdk.java.net/~pliden/8225779/webrev.2-diff Full: http://cr.openjdk.java.net/~pliden/8225779/webrev.2 Opinions? cheers, Per On 6/17/19 2:51 PM, Per Liden wrote: > Here's an updated webrev, which just removes the cell_header_size() and > its uses, but otherwise keeps the code as is. > > http://cr.openjdk.java.net/~pliden/8225779/webrev.1 > > cheers, > Per > > On 6/14/19 1:43 PM, Per Liden wrote: >> Hi, >> >> On 6/14/19 11:26 AM, Erik ?sterlund wrote: >>> Hi Per, >>> >>> I don't think it is a good idea to completely revert the changes made >>> to MacroAssembler::needs_explicit_null_check(). This was not just >>> done for interfacing. The code we had before was actually wrong. >>> >>> We called that function with both addresses (from signal handlers) >>> and offsets (from the compiler), and tried to look at the passed in >>> value whether it quacks like an offset or an address based on its >>> value. If it looked like an address it would first be normalized to >>> look like an offset. But it was possible that a much-larger-than-page >>> offset is passed in that actually looks like an address according to >>> the address quacking code, which turns the supposedly address looking >>> value into an offset normalized form that looks like it wouldn't need >>> explicit null checks because in that form the offset is within one >>> page, while the original offset passed in totally would need an >>> explicit null check really, because it totally wasn't within that one >>> page offset we allowed. >>> >>> To make this more sound, the function was split into two - one used >>> for addresses passed in by signal handlers, and one used for offsets >>> used by the compiler. This completely removed the value based check >>> to determine if the argument looks like an address or offset. I would >>> definitely like to keep that structure going forward, because >>> otherwise that bug will be re-introduced. >> >> I see. I'll revise the patch. >> >> Thanks! >> Per >> >>> >>> Otherwise, I do encourage removing the now unnecessary cell header >>> size abstraction. >>> >>> /Erik >>> >>> On 2019-06-14 08:29, Per Liden wrote: >>>> CollectedHeap::cell_header_size() is no longer used and can be >>>> removed. This patch is a hg backout of [1] where it was introduced, >>>> plus the two followup bug fixes [2] & [3]. >>>> >>>> This is a clean backout, with the exception of light editing needed >>>> in two places, because: >>>> >>>> 1) The function Universe::narrow_oop_base() has since been renamed >>>> to CompressedOops::base(). >>>> 2) The include guard CPU_ARM_VM_MACROASSEMBLER_ARM_HPP has since >>>> been renamed to CPU_ARM_MACROASSEMBLER_ARM_HPP. >>>> >>>> Testing: Tier1-3 on all Oracle platforms >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225779 >>>> Webrev: http://cr.openjdk.java.net/~pliden/8225779/webrev.0 >>>> >>>> /Per >>>> >>>> [1] http://hg.openjdk.java.net/jdk/jdk/rev/4ad404da0088 >>>> [2] http://hg.openjdk.java.net/jdk/jdk/rev/f642ede2eb07 >>>> [3] http://hg.openjdk.java.net/jdk/jdk/rev/18bd95c0e463 From doug.simon at oracle.com Mon Jun 17 22:10:04 2019 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 18 Jun 2019 00:10:04 +0200 Subject: RFR(T): 8226222: [JVMCI] Export AArch64 field VM_Version::_psr_info.dczid_el0 In-Reply-To: <45a20e63-2eb6-9627-54e8-1a0a1dcba97a@oracle.com> References: <45a20e63-2eb6-9627-54e8-1a0a1dcba97a@oracle.com> Message-ID: > On 17 Jun 2019, at 17:51, Vladimir Kozlov wrote: > > Hi Pengfei, > > This looks fine to me. We can push it into jdk/jdk (which is jdk 14 now). > I am not sure where we should backport this. Doug, what do you think? I?m not familiar with the OpenJDK backport decision making process so I?m not exactly sure what you?re asking me. -Doug > > The dczid_el0 field was added in JDK 9. > > Thanks, > Vladimir > > On 6/17/19 3:27 AM, Pengfei Li (Arm Technology China) wrote: >> Hi, >> Could you help review this small change on JVMCI? >> Webrev: http://cr.openjdk.java.net/~pli/rfr/8226222/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8226222 >> We would like to implement memory bulk zeroing by cache maintenance (DC ZVA) instruction in AArch64 Graal compiler. To make AArch64 processor info "dczid_el0" available to get at compile-time, this patch exports AArch64 HotSpot field VM_Version::_psr_info.dczid_el0 and also fixes out-of-date AArch64 macro in JVMCI. >> -- >> Thanks, >> Pengfei From jianglizhou at google.com Mon Jun 17 22:47:34 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Mon, 17 Jun 2019 15:47:34 -0700 Subject: bootcycle build on ix86-linux-gnu broken since jdk-13+18 In-Reply-To: <4901e07e-55ea-9e36-1173-9b0a46b2025c@ubuntu.com> References: <4901e07e-55ea-9e36-1173-9b0a46b2025c@ubuntu.com> Message-ID: Hi Matthias, Do you have a bug with the trace attached? I couldn't find any attachment in the email. Best regards, Jiangli On Fri, Jun 14, 2019 at 7:02 AM Matthias Klose wrote: > On 14.06.19 15:10, David Holmes wrote: > > Hi Matthias, > > > > On 14/06/2019 10:57 pm, Matthias Klose wrote: > >> My last successful bootcycle build on i686-linux-gnu was jdk-13+18. > After that I > >> tried jdk-13+22, which didn't build anymore, with no change to the most > recent > >> jdk-13+25, and also seen in jdk-14+1. > >> > >> All builds fail with > >> > >> Compiling 12 properties into resource bundles for jdk.jdeps > >> # > >> # There is insufficient memory for the Java Runtime Environment to > continue. > >> # Native memory allocation (malloc) failed to allocate 2155274940 bytes > for > >> AllocateHeap > >> # An error report file with more information is saved as: > > > > Do you have the full stack for that? It might shed some light. > > now attached. > > From matthias.baesken at sap.com Tue Jun 18 07:45:49 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 18 Jun 2019 07:45:49 +0000 Subject: RFR: 8226238: Improve error output and fix elf issues in os::dll_load Message-ID: Hello, please review this change to linux os::dll_load . os::dll_load includes some coding to report error details in cases where the lib loading fails . For this , we ELF header of the shared-object we failed to load is evaluated . However the code currently has some issues . - it misses to convert endianness of elf_head.e_machine (ELF data entry) in case the platform we run on, and the lib we try to load have different endianness - the error message could show the real elf architecture name in mismatch cases (but does not) Adjusted error message looks like this : example from renaissance db-shootout benchmark that runs on linuxs390x and attempts to load an x86_64 JNI lib "by mistake" message without the change : .... ELF file data encoding not big-endian (Possible cause: endianness mismatch)] with change : .... ELF file data encoding not big-endian (Possible cause: can't load AMD 64 .so on a IBM System/390 platform) bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8226238 http://cr.openjdk.java.net/~mbaesken/webrevs/8226238.2/ Thanks, Matthias From Pengfei.Li at arm.com Tue Jun 18 08:02:20 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Tue, 18 Jun 2019 08:02:20 +0000 Subject: RFR(T): 8226222: [JVMCI] Export AArch64 field VM_Version::_psr_info.dczid_el0 In-Reply-To: References: <45a20e63-2eb6-9627-54e8-1a0a1dcba97a@oracle.com> Message-ID: Hi, > > This looks fine to me. We can push it into jdk/jdk (which is jdk 14 now). > > I am not sure where we should backport this. Doug, what do you think? > > I?m not familiar with the OpenJDK backport decision making process so I?m > not exactly sure what you?re asking me. Thanks for your review. I just read the JDK Update Guidance[1] and JDK Release Process[2]. According to the rules, this patch should be backported only to jdk11u. But as this change is just a support of Graal compiler optimization and latest Graal code won't be synced with jdk11u any more, I don't think we have the need to do the backport. On the other hand, the Graal compiler has the ability to check the existence of a given field and give up optimization if required field is not present. So I think there should be no compatibility issue between the Graal compiler and multiple JDK versions, even if we don't do the backport. [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK+Updates+Guidance [2] http://openjdk.java.net/jeps/3 -- Thanks, Pengfei From matthias.baesken at sap.com Tue Jun 18 11:23:48 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 18 Jun 2019 11:23:48 +0000 Subject: RFR: 8226238: Improve error output and fix elf issues in os::dll_load Message-ID: Hello, I noticed the solaris os::dll_load coding has similar issues. New webrev ( handling linux + solaris ) : http://cr.openjdk.java.net/~mbaesken/webrevs/8226238.3/ Best regards, Matthias Hello, please review this change to linux os::dll_load . os::dll_load includes some coding to report error details in cases where the lib loading fails . For this , we ELF header of the shared-object we failed to load is evaluated . However the code currently has some issues . - it misses to convert endianness of elf_head.e_machine (ELF data entry) in case the platform we run on, and the lib we try to load have different endianness - the error message could show the real elf architecture name in mismatch cases (but does not) Adjusted error message looks like this : example from renaissance db-shootout benchmark that runs on linuxs390x and attempts to load an x86_64 JNI lib "by mistake" message without the change : .... ELF file data encoding not big-endian (Possible cause: endianness mismatch)] with change : .... ELF file data encoding not big-endian (Possible cause: can't load AMD 64 .so on a IBM System/390 platform) bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8226238 http://cr.openjdk.java.net/~mbaesken/webrevs/8226238.2/ From erik.osterlund at oracle.com Tue Jun 18 15:09:29 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 18 Jun 2019 17:09:29 +0200 Subject: RFR: 8225779: Remove unused CollectedHeap::cell_header_size() In-Reply-To: References: <61d76fc8-d4c1-ee30-7f95-bf2d1222eff0@oracle.com> <5207d4e5-6feb-b65a-6940-892c0e88f825@oracle.com> <6df1fa33-2393-d46d-1e43-3d9ee7dc9489@oracle.com> Message-ID: <243ceecc-027a-4384-58bd-9500c0c9e2f2@oracle.com> Hi Per, This new revision looks good to me. /Erik On 2019-06-17 23:36, Per Liden wrote: > Stefan pointed out that it looks like this piece of code can still > pass in a negative offset (Type::OffsetBot = -2000000001) to > MacroAssembler::needs_explicit_null_check(), which would cause the > assert in that function to fail. I'm not hitting this in our testing, > but it certainly looks suspicious. > > void PhaseCFG::implicit_null_check(Block* block, Node *proj, Node > *val, int allowed_reasons) { > ? [...] > ????? const Node* base = mach->get_base_and_disp(offset, adr_type); > ????? if (base == NULL || base == NodeSentinel) { > ??????? // Narrow oop address doesn't have base, only index. > ??????? // Give up if offset is beyond page size or if heap base is > not protected. > ??????? if (val->bottom_type()->isa_narrowoop() && > ??????????? (MacroAssembler::needs_explicit_null_check(offset) || > ???????????? !CompressedOops::use_implicit_null_checks())) > ????????? continue; > ? [...] > } > > Unless someone can explain that this can't happen, I think it would be > safer to remove the assert and instead return true for all negative > values, like we do today. > > Diff: http://cr.openjdk.java.net/~pliden/8225779/webrev.2-diff > Full: http://cr.openjdk.java.net/~pliden/8225779/webrev.2 > > Opinions? > > cheers, > Per > > On 6/17/19 2:51 PM, Per Liden wrote: >> Here's an updated webrev, which just removes the cell_header_size() >> and its uses, but otherwise keeps the code as is. >> >> http://cr.openjdk.java.net/~pliden/8225779/webrev.1 >> >> cheers, >> Per >> >> On 6/14/19 1:43 PM, Per Liden wrote: >>> Hi, >>> >>> On 6/14/19 11:26 AM, Erik ?sterlund wrote: >>>> Hi Per, >>>> >>>> I don't think it is a good idea to completely revert the changes >>>> made to MacroAssembler::needs_explicit_null_check(). This was not >>>> just done for interfacing. The code we had before was actually wrong. >>>> >>>> We called that function with both addresses (from signal handlers) >>>> and offsets (from the compiler), and tried to look at the passed in >>>> value whether it quacks like an offset or an address based on its >>>> value. If it looked like an address it would first be normalized to >>>> look like an offset. But it was possible that a >>>> much-larger-than-page offset is passed in that actually looks like >>>> an address according to the address quacking code, which turns the >>>> supposedly address looking value into an offset normalized form >>>> that looks like it wouldn't need explicit null checks because in >>>> that form the offset is within one page, while the original offset >>>> passed in totally would need an explicit null check really, because >>>> it totally wasn't within that one page offset we allowed. >>>> >>>> To make this more sound, the function was split into two - one used >>>> for addresses passed in by signal handlers, and one used for >>>> offsets used by the compiler. This completely removed the value >>>> based check to determine if the argument looks like an address or >>>> offset. I would definitely like to keep that structure going >>>> forward, because otherwise that bug will be re-introduced. >>> >>> I see. I'll revise the patch. >>> >>> Thanks! >>> Per >>> >>>> >>>> Otherwise, I do encourage removing the now unnecessary cell header >>>> size abstraction. >>>> >>>> /Erik >>>> >>>> On 2019-06-14 08:29, Per Liden wrote: >>>>> CollectedHeap::cell_header_size() is no longer used and can be >>>>> removed. This patch is a hg backout of [1] where it was >>>>> introduced, plus the two followup bug fixes [2] & [3]. >>>>> >>>>> This is a clean backout, with the exception of light editing >>>>> needed in two places, because: >>>>> >>>>> 1) The function Universe::narrow_oop_base() has since been renamed >>>>> to CompressedOops::base(). >>>>> 2) The include guard CPU_ARM_VM_MACROASSEMBLER_ARM_HPP has since >>>>> been renamed to CPU_ARM_MACROASSEMBLER_ARM_HPP. >>>>> >>>>> Testing: Tier1-3 on all Oracle platforms >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225779 >>>>> Webrev: http://cr.openjdk.java.net/~pliden/8225779/webrev.0 >>>>> >>>>> /Per >>>>> >>>>> [1] http://hg.openjdk.java.net/jdk/jdk/rev/4ad404da0088 >>>>> [2] http://hg.openjdk.java.net/jdk/jdk/rev/f642ede2eb07 >>>>> [3] http://hg.openjdk.java.net/jdk/jdk/rev/18bd95c0e463 From ioi.lam at oracle.com Tue Jun 18 15:54:23 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 18 Jun 2019 08:54:23 -0700 Subject: bootcycle build on ix86-linux-gnu broken since jdk-13+18 In-Reply-To: <503407fa-e31e-1f35-d4bd-23a3df334acd@ubuntu.com> References: <4901e07e-55ea-9e36-1173-9b0a46b2025c@ubuntu.com> <503407fa-e31e-1f35-d4bd-23a3df334acd@ubuntu.com> Message-ID: <1821a6da-2e4c-9193-c190-a9375077d7ee@oracle.com> Matthias, Could you send the exact steps for reproducing this? Are you doing something like this? cd openjdk13src mkdir build cd build bash ../configure -- --with-target-bits=32 make bootcycle-images Thanks - Ioi On 6/17/19 2:35 AM, Matthias Klose wrote: > On 17.06.19 09:45, David Holmes wrote: >> >> >> < cc'ing Calvin> >> >> Hi Matthias, >> >> This looks like an issue with the new Dynamic Archive support. I'm not sure if >> it is intended for use on 32-bit, but it looks like the size of the file to map >> is too large. (or it may relate to the issue Aleksey pointed too - either way it >> starts from dynamic archive code.) > yes, configuring with --disable-cds works around the build failure. Looking at > the other 32bit hotspot build, it looks like the armhf build works with enabled cds. > > Matthias > >> Cheers, >> David >> >> >> >> On 15/06/2019 12:02 am, Matthias Klose wrote: >>> On 14.06.19 15:10, David Holmes wrote: >>>> Hi Matthias, >>>> >>>> On 14/06/2019 10:57 pm, Matthias Klose wrote: >>>>> My last successful bootcycle build on i686-linux-gnu was jdk-13+18. After >>>>> that I >>>>> tried jdk-13+22, which didn't build anymore, with no change to the most recent >>>>> jdk-13+25, and also seen in jdk-14+1. >>>>> >>>>> All builds fail with >>>>> >>>>> Compiling 12 properties into resource bundles for jdk.jdeps >>>>> # >>>>> # There is insufficient memory for the Java Runtime Environment to continue. >>>>> # Native memory allocation (malloc) failed to allocate 2155274940 bytes for >>>>> AllocateHeap >>>>> # An error report file with more information is saved as: >>>> Do you have the full stack for that? It might shed some light. >>> now attached. >>> From vladimir.kozlov at oracle.com Tue Jun 18 16:55:08 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Jun 2019 09:55:08 -0700 Subject: RFR(T): 8226222: [JVMCI] Export AArch64 field VM_Version::_psr_info.dczid_el0 In-Reply-To: References: <45a20e63-2eb6-9627-54e8-1a0a1dcba97a@oracle.com> Message-ID: <181b26e8-965a-6e9b-1506-8f5e2b5249f6@oracle.com> This is purely JVMCI changes for aarch64 code which is not present in JDK8u and is not requires in graal-jvmci-8. But GraalVM would support jdk11u soon where this code is present. My question was about to have versioned code in graal-jvmci for JDK 11u. On other hand I am perfectly fine to have this change only in latest JDK (jdk 14). As Pengfei correctly pointed we would not do any Graal update in 11u. Pengfei, to you need sponsor to push your changes? Thanks, Vladmir On 6/18/19 1:02 AM, Pengfei Li (Arm Technology China) wrote: > Hi, > >>> This looks fine to me. We can push it into jdk/jdk (which is jdk 14 now). >>> I am not sure where we should backport this. Doug, what do you think? >> >> I?m not familiar with the OpenJDK backport decision making process so I?m >> not exactly sure what you?re asking me. > > Thanks for your review. > > I just read the JDK Update Guidance[1] and JDK Release Process[2]. According to the rules, this patch should be backported only to jdk11u. But as this change is just a support of Graal compiler optimization and latest Graal code won't be synced with jdk11u any more, I don't think we have the need to do the backport. On the other hand, the Graal compiler has the ability to check the existence of a given field and give up optimization if required field is not present. So I think there should be no compatibility issue between the Graal compiler and multiple JDK versions, even if we don't do the backport. > > [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK+Updates+Guidance > [2] http://openjdk.java.net/jeps/3 > > -- > Thanks, > Pengfei > From ioi.lam at oracle.com Tue Jun 18 16:55:40 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 18 Jun 2019 09:55:40 -0700 Subject: bootcycle build on ix86-linux-gnu broken since jdk-13+18 In-Reply-To: <1821a6da-2e4c-9193-c190-a9375077d7ee@oracle.com> References: <4901e07e-55ea-9e36-1173-9b0a46b2025c@ubuntu.com> <503407fa-e31e-1f35-d4bd-23a3df334acd@ubuntu.com> <1821a6da-2e4c-9193-c190-a9375077d7ee@oracle.com> Message-ID: I tried the steps in my previous mail and the build suceeded. build$ ./images/jdk/bin/java -Xshare:on -Xinternalversion -version Java HotSpot(TM) Server VM (14-internal+0-2019-06-18-1551218.iklam.null) for linux-x86 JRE (14-internal+0-2019-06-18-1551218.iklam.null), built on Jun 18 2019 08:54:10 by "iklam" with gcc 8.2.0 build$ ./images/jdk/bin/java -Xshare:on -version java version "14-internal" 2020-03-17 Java(TM) SE Runtime Environment (build 14-internal+0-2019-06-18-1551218.iklam.null) Java HotSpot(TM) Server VM (build 14-internal+0-2019-06-18-1551218.iklam.null, mixed mode, sharing) But ... the funny thing is: build$ find . -name \*.jsa | xargs ls -l -r--r--r-- 1 iklam dba? 8286208 Jun 18 09:06 ./bootcycle-build/images/jdk/lib/server/classes.jsa -r--r--r-- 1 iklam dba 18751488 Jun 18 08:51 ./configure-support/classes.jsa -r--r--r-- 1 iklam dba? 8286208 Jun 18 09:01 ./images/jdk/lib/server/classes.jsa The size of ./configure-support/classes.jsa is exactly the same as my regular x64 build. So it looks like we got it from the boot-jdk (which for me happens to be 64 bit). Notice that none of the JVM binaries under my build directory is 64-bit: build$ find . -name libjvm.so | xargs file ./support/interim-image/lib/server/libjvm.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped ./support/modules_libs/java.base/server/libjvm.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped ./hotspot/variant-server/libjvm/gtest/libjvm.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped ./bootcycle-build/support/modules_libs/java.base/server/libjvm.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped ./bootcycle-build/hotspot/variant-server/libjvm/gtest/libjvm.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped ./bootcycle-build/images/jdk/lib/server/libjvm.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped ./bootcycle-build/jdk/lib/server/libjvm.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped ./images/jdk/lib/server/libjvm.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped ./jdk/lib/server/libjvm.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped Matthias, could you try running your build again with a boot jdk that's 32-bit? I think we have a couple of issues here: + CDS handling of mismatched archive files + Wrong JDK is used to generate ./configure-support/classes.jsa during a bootcycle build. Thanks - Ioi On 6/18/19 8:54 AM, Ioi Lam wrote: > Matthias, > > Could you send the exact steps for reproducing this? Are you doing > something like this? > > ?? cd openjdk13src > ?? mkdir build > ?? cd build > ?? bash ../configure -- --with-target-bits=32 > ?? make bootcycle-images > > Thanks > - Ioi > > > On 6/17/19 2:35 AM, Matthias Klose wrote: >> On 17.06.19 09:45, David Holmes wrote: >>> >>> >>> < cc'ing Calvin> >>> >>> Hi Matthias, >>> >>> This looks like an issue with the new Dynamic Archive support. I'm >>> not sure if >>> it is intended for use on 32-bit, but it looks like the size of the >>> file to map >>> is too large. (or it may relate to the issue Aleksey pointed too - >>> either way it >>> starts from dynamic archive code.) >> yes, configuring with --disable-cds works around the build failure.? >> Looking at >> the other 32bit hotspot build, it looks like the armhf build works >> with enabled cds. >> >> Matthias >> >>> Cheers, >>> David >>> >>> >>> >>> On 15/06/2019 12:02 am, Matthias Klose wrote: >>>> On 14.06.19 15:10, David Holmes wrote: >>>>> Hi Matthias, >>>>> >>>>> On 14/06/2019 10:57 pm, Matthias Klose wrote: >>>>>> My last successful bootcycle build on i686-linux-gnu was >>>>>> jdk-13+18. After >>>>>> that I >>>>>> tried jdk-13+22, which didn't build anymore, with no change to >>>>>> the most recent >>>>>> jdk-13+25, and also seen in jdk-14+1. >>>>>> >>>>>> All builds fail with >>>>>> >>>>>> Compiling 12 properties into resource bundles for jdk.jdeps >>>>>> # >>>>>> # There is insufficient memory for the Java Runtime Environment >>>>>> to continue. >>>>>> # Native memory allocation (malloc) failed to allocate 2155274940 >>>>>> bytes for >>>>>> AllocateHeap >>>>>> # An error report file with more information is saved as: >>>>> Do you have the full stack for that? It might shed some light. >>>> now attached. >>>> > From igor.ignatyev at oracle.com Tue Jun 18 23:19:51 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 18 Jun 2019 16:19:51 -0700 Subject: RFR(S) [13] : 8226360 : merge entries in hotspot problem lists Message-ID: http://cr.openjdk.java.net/~iignatyev//8226360/webrev.00/index.html > 30 lines changed: 0 ins; 20 del; 10 mod; Hi all, because jtreg doesn't support having multiple entries for a test in a problem list (in a way you would expect it to), see CODETOOLS-7902481[1], we need to merge all such cases in our problem lists. this small patch does exactly that for all hotspot-related problem lists. JBS: https://bugs.openjdk.java.net/browse/JDK-8226360 webrev: http://cr.openjdk.java.net/~iignatyev//8226360/webrev.00/index.html [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902481 Thanks, -- Igor From ekaterina.pavlova at oracle.com Tue Jun 18 23:33:18 2019 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Tue, 18 Jun 2019 16:33:18 -0700 Subject: RFR(S) [13] : 8226360 : merge entries in hotspot problem lists In-Reply-To: References: Message-ID: > +vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java 8204506,8195635 macosx-all,generic-all Doesn't generic-all imply macosx-all as well? Otherwise looks good. thanks, -katya On 6/18/19 4:19 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8226360/webrev.00/index.html >> 30 lines changed: 0 ins; 20 del; 10 mod; > > Hi all, > > because jtreg doesn't support having multiple entries for a test in a problem list (in a way you would expect it to), see CODETOOLS-7902481[1], we need to merge all such cases in our problem lists. this small patch does exactly that for all hotspot-related problem lists. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8226360 > webrev: http://cr.openjdk.java.net/~iignatyev//8226360/webrev.00/index.html > [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902481 > > Thanks, > -- Igor > From vladimir.kozlov at oracle.com Wed Jun 19 00:09:08 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Jun 2019 17:09:08 -0700 Subject: RFR(S) [13] : 8226360 : merge entries in hotspot problem lists In-Reply-To: References: Message-ID: How we endup wiith 3 copies of the same test and bug in jdk/ProblemList-graal.txt? We should have some verification to avoid that. Changes are good except what Katya pointed. Thanks, Vladimir On 6/18/19 4:19 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8226360/webrev.00/index.html >> 30 lines changed: 0 ins; 20 del; 10 mod; > > Hi all, > > because jtreg doesn't support having multiple entries for a test in a problem list (in a way you would expect it to), see CODETOOLS-7902481[1], we need to merge all such cases in our problem lists. this small patch does exactly that for all hotspot-related problem lists. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8226360 > webrev: http://cr.openjdk.java.net/~iignatyev//8226360/webrev.00/index.html > [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902481 > > Thanks, > -- Igor > From igor.ignatyev at oracle.com Wed Jun 19 00:10:57 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 18 Jun 2019 17:10:57 -0700 Subject: RFR(S) [13] : 8226360 : merge entries in hotspot problem lists In-Reply-To: References: Message-ID: it is, I however decided to leave macosx-all in an attempt to show that 8204506 affects only that platform. -- Igor > On Jun 18, 2019, at 4:33 PM, Ekaterina Pavlova wrote: > >> +vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java 8204506,8195635 macosx-all,generic-all > > Doesn't generic-all imply macosx-all as well? > > Otherwise looks good. > > thanks, > -katya > > > On 6/18/19 4:19 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8226360/webrev.00/index.html >>> 30 lines changed: 0 ins; 20 del; 10 mod; >> Hi all, >> because jtreg doesn't support having multiple entries for a test in a problem list (in a way you would expect it to), see CODETOOLS-7902481[1], we need to merge all such cases in our problem lists. this small patch does exactly that for all hotspot-related problem lists. >> JBS: https://bugs.openjdk.java.net/browse/JDK-8226360 >> webrev: http://cr.openjdk.java.net/~iignatyev//8226360/webrev.00/index.html >> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902481 >> Thanks, >> -- Igor > From igor.ignatyev at oracle.com Wed Jun 19 00:16:28 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 18 Jun 2019 17:16:28 -0700 Subject: RFR(S) [13] : 8226360 : merge entries in hotspot problem lists In-Reply-To: References: Message-ID: I have no idea how/why we listed com/sun/jdi/ tests thrice. verification of problem lists is discussed in CODETOOLS-7902481, I'd appreciate if you provide your input there. I have answered Katya's comment in a separate thread. -- Igor > On Jun 18, 2019, at 5:09 PM, Vladimir Kozlov wrote: > > How we endup wiith 3 copies of the same test and bug in jdk/ProblemList-graal.txt? > We should have some verification to avoid that. > > Changes are good except what Katya pointed. > > Thanks, > Vladimir > > On 6/18/19 4:19 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8226360/webrev.00/index.html >>> 30 lines changed: 0 ins; 20 del; 10 mod; >> Hi all, >> because jtreg doesn't support having multiple entries for a test in a problem list (in a way you would expect it to), see CODETOOLS-7902481[1], we need to merge all such cases in our problem lists. this small patch does exactly that for all hotspot-related problem lists. >> JBS: https://bugs.openjdk.java.net/browse/JDK-8226360 >> webrev: http://cr.openjdk.java.net/~iignatyev//8226360/webrev.00/index.html >> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902481 >> Thanks, >> -- Igor From vladimir.kozlov at oracle.com Wed Jun 19 00:18:11 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Jun 2019 17:18:11 -0700 Subject: RFR(S) [13] : 8226360 : merge entries in hotspot problem lists In-Reply-To: References: Message-ID: On 6/18/19 5:16 PM, Igor Ignatyev wrote: > I have no idea how/why we listed com/sun/jdi/ tests thrice. verification of problem lists is discussed in CODETOOLS-7902481, I'd appreciate if you provide your input there. > > I have answered Katya's comment in a separate thread. Okay. Thanks, Vladimir > > -- Igor > >> On Jun 18, 2019, at 5:09 PM, Vladimir Kozlov wrote: >> >> How we endup wiith 3 copies of the same test and bug in jdk/ProblemList-graal.txt? >> We should have some verification to avoid that. >> >> Changes are good except what Katya pointed. >> >> Thanks, >> Vladimir >> >> On 6/18/19 4:19 PM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8226360/webrev.00/index.html >>>> 30 lines changed: 0 ins; 20 del; 10 mod; >>> Hi all, >>> because jtreg doesn't support having multiple entries for a test in a problem list (in a way you would expect it to), see CODETOOLS-7902481[1], we need to merge all such cases in our problem lists. this small patch does exactly that for all hotspot-related problem lists. >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8226360 >>> webrev: http://cr.openjdk.java.net/~iignatyev//8226360/webrev.00/index.html >>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902481 >>> Thanks, >>> -- Igor > From ningsheng.jian at arm.com Wed Jun 19 03:46:37 2019 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Wed, 19 Jun 2019 11:46:37 +0800 Subject: RFR(T): 8226222: [JVMCI] Export AArch64 field VM_Version::_psr_info.dczid_el0 In-Reply-To: <181b26e8-965a-6e9b-1506-8f5e2b5249f6@oracle.com> References: <45a20e63-2eb6-9627-54e8-1a0a1dcba97a@oracle.com> <181b26e8-965a-6e9b-1506-8f5e2b5249f6@oracle.com> Message-ID: <9f5008ca-13ce-c8b0-941c-adf2e9a03c76@arm.com> Hi, Yes, I think it's OK for latest jdk, since Graal code will check the field presence before using the instruction. I can do the push for Pengfei. Thanks, Ningsheng On 6/19/19 12:55 AM, Vladimir Kozlov wrote: > This is purely JVMCI changes for aarch64 code which is not present in JDK8u and is not requires in graal-jvmci-8. > But GraalVM would support jdk11u soon where this code is present. My question was about to have versioned code in > graal-jvmci for JDK 11u. > > On other hand I am perfectly fine to have this change only in latest JDK (jdk 14). As Pengfei correctly pointed we would > not do any Graal update in 11u. > > Pengfei, to you need sponsor to push your changes? > > Thanks, > Vladmir > > On 6/18/19 1:02 AM, Pengfei Li (Arm Technology China) wrote: >> Hi, >> >>>> This looks fine to me. We can push it into jdk/jdk (which is jdk 14 now). >>>> I am not sure where we should backport this. Doug, what do you think? >>> >>> I?m not familiar with the OpenJDK backport decision making process so I?m >>> not exactly sure what you?re asking me. >> >> Thanks for your review. >> >> I just read the JDK Update Guidance[1] and JDK Release Process[2]. According to the rules, this patch should be backported only to jdk11u. But as this change is just a support of Graal compiler optimization and latest Graal code won't be synced with jdk11u any more, I don't think we have the need to do the backport. On the other hand, the Graal compiler has the ability to check the existence of a given field and give up optimization if required field is not present. So I think there should be no compatibility issue between the Graal compiler and multiple JDK versions, even if we don't do the backport. >> >> [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK+Updates+Guidance >> [2] http://openjdk.java.net/jeps/3 >> >> -- >> Thanks, >> Pengfei >> From per.liden at oracle.com Wed Jun 19 06:31:53 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 19 Jun 2019 08:31:53 +0200 Subject: RFR: 8225779: Remove unused CollectedHeap::cell_header_size() In-Reply-To: <243ceecc-027a-4384-58bd-9500c0c9e2f2@oracle.com> References: <61d76fc8-d4c1-ee30-7f95-bf2d1222eff0@oracle.com> <5207d4e5-6feb-b65a-6940-892c0e88f825@oracle.com> <6df1fa33-2393-d46d-1e43-3d9ee7dc9489@oracle.com> <243ceecc-027a-4384-58bd-9500c0c9e2f2@oracle.com> Message-ID: <14a4856c-c84a-fed7-ddd0-c0e84634b2d0@oracle.com> Thanks Erik! /Per On 6/18/19 5:09 PM, Erik ?sterlund wrote: > Hi Per, > > This new revision looks good to me. > > /Erik > > On 2019-06-17 23:36, Per Liden wrote: >> Stefan pointed out that it looks like this piece of code can still >> pass in a negative offset (Type::OffsetBot = -2000000001) to >> MacroAssembler::needs_explicit_null_check(), which would cause the >> assert in that function to fail. I'm not hitting this in our testing, >> but it certainly looks suspicious. >> >> void PhaseCFG::implicit_null_check(Block* block, Node *proj, Node >> *val, int allowed_reasons) { >> ? [...] >> ????? const Node* base = mach->get_base_and_disp(offset, adr_type); >> ????? if (base == NULL || base == NodeSentinel) { >> ??????? // Narrow oop address doesn't have base, only index. >> ??????? // Give up if offset is beyond page size or if heap base is >> not protected. >> ??????? if (val->bottom_type()->isa_narrowoop() && >> ??????????? (MacroAssembler::needs_explicit_null_check(offset) || >> ???????????? !CompressedOops::use_implicit_null_checks())) >> ????????? continue; >> ? [...] >> } >> >> Unless someone can explain that this can't happen, I think it would be >> safer to remove the assert and instead return true for all negative >> values, like we do today. >> >> Diff: http://cr.openjdk.java.net/~pliden/8225779/webrev.2-diff >> Full: http://cr.openjdk.java.net/~pliden/8225779/webrev.2 >> >> Opinions? >> >> cheers, >> Per >> >> On 6/17/19 2:51 PM, Per Liden wrote: >>> Here's an updated webrev, which just removes the cell_header_size() >>> and its uses, but otherwise keeps the code as is. >>> >>> http://cr.openjdk.java.net/~pliden/8225779/webrev.1 >>> >>> cheers, >>> Per >>> >>> On 6/14/19 1:43 PM, Per Liden wrote: >>>> Hi, >>>> >>>> On 6/14/19 11:26 AM, Erik ?sterlund wrote: >>>>> Hi Per, >>>>> >>>>> I don't think it is a good idea to completely revert the changes >>>>> made to MacroAssembler::needs_explicit_null_check(). This was not >>>>> just done for interfacing. The code we had before was actually wrong. >>>>> >>>>> We called that function with both addresses (from signal handlers) >>>>> and offsets (from the compiler), and tried to look at the passed in >>>>> value whether it quacks like an offset or an address based on its >>>>> value. If it looked like an address it would first be normalized to >>>>> look like an offset. But it was possible that a >>>>> much-larger-than-page offset is passed in that actually looks like >>>>> an address according to the address quacking code, which turns the >>>>> supposedly address looking value into an offset normalized form >>>>> that looks like it wouldn't need explicit null checks because in >>>>> that form the offset is within one page, while the original offset >>>>> passed in totally would need an explicit null check really, because >>>>> it totally wasn't within that one page offset we allowed. >>>>> >>>>> To make this more sound, the function was split into two - one used >>>>> for addresses passed in by signal handlers, and one used for >>>>> offsets used by the compiler. This completely removed the value >>>>> based check to determine if the argument looks like an address or >>>>> offset. I would definitely like to keep that structure going >>>>> forward, because otherwise that bug will be re-introduced. >>>> >>>> I see. I'll revise the patch. >>>> >>>> Thanks! >>>> Per >>>> >>>>> >>>>> Otherwise, I do encourage removing the now unnecessary cell header >>>>> size abstraction. >>>>> >>>>> /Erik >>>>> >>>>> On 2019-06-14 08:29, Per Liden wrote: >>>>>> CollectedHeap::cell_header_size() is no longer used and can be >>>>>> removed. This patch is a hg backout of [1] where it was >>>>>> introduced, plus the two followup bug fixes [2] & [3]. >>>>>> >>>>>> This is a clean backout, with the exception of light editing >>>>>> needed in two places, because: >>>>>> >>>>>> 1) The function Universe::narrow_oop_base() has since been renamed >>>>>> to CompressedOops::base(). >>>>>> 2) The include guard CPU_ARM_VM_MACROASSEMBLER_ARM_HPP has since >>>>>> been renamed to CPU_ARM_MACROASSEMBLER_ARM_HPP. >>>>>> >>>>>> Testing: Tier1-3 on all Oracle platforms >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225779 >>>>>> Webrev: http://cr.openjdk.java.net/~pliden/8225779/webrev.0 >>>>>> >>>>>> /Per >>>>>> >>>>>> [1] http://hg.openjdk.java.net/jdk/jdk/rev/4ad404da0088 >>>>>> [2] http://hg.openjdk.java.net/jdk/jdk/rev/f642ede2eb07 >>>>>> [3] http://hg.openjdk.java.net/jdk/jdk/rev/18bd95c0e463 > From aph at redhat.com Wed Jun 19 12:12:14 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Jun 2019 13:12:14 +0100 Subject: bootcycle build on ix86-linux-gnu broken since jdk-13+18 In-Reply-To: References: Message-ID: On 6/14/19 2:26 PM, Aleksey Shipilev wrote: > Current jdk/jdk does not build on x86_32, due to JDK-8225695. Bootcycle works for me, but I'm building on a 64-bit system. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Jun 19 12:12:26 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Jun 2019 13:12:26 +0100 Subject: bootcycle build on ix86-linux-gnu broken since jdk-13+18 In-Reply-To: References: Message-ID: <352fea90-2cf2-adca-53c8-e2fa80da32b6@redhat.com> On 6/14/19 1:57 PM, Matthias Klose wrote: > Compiling 12 properties into resource bundles for jdk.jdeps > # > # There is insufficient memory for the Java Runtime Environment to continue. > # Native memory allocation (malloc) failed to allocate 2155274940 bytes for > AllocateHeap > # An error report file with more information is saved as: > > It looks like the normal build instead of the bootcycle build succeeds. Does > anybody else is doing regular ix86 builds and could help narrowing down when > this started to fail? Is this a 32-bit x86 kernel virtual machione or are you building a 32-bit JDK in a 64-bit environment? What does cat /proc/meminfo say? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From fweimer at redhat.com Wed Jun 19 16:03:31 2019 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 19 Jun 2019 18:03:31 +0200 Subject: RFR(m): 8220351: Cross-modifying code In-Reply-To: (Martin Doerr's message of "Tue, 19 Mar 2019 16:52:40 +0000") References: <4021e6fe-a2e7-7e66-bd54-1ea9d80863ae@oracle.com> Message-ID: <87fto536lo.fsf@oldenburg2.str.redhat.com> * Martin Doerr: > Not sure if the inline assembler code on x86 necessarily needs a "clobber memory" effect. > I don't know what a C++ compiler is allowed to do if it doesn't know that the code has some kind of memory effect. > > For ebx...edx, you could also use clobber if you want to make it shorter. > E.g. with "+a" to use eax as input and output: > int idx = 0; > __asm__ volatile ("cpuid " : "+a" (idx) : : "ebx", "ecx", "edx", "memory"); ebx clobbers are not supported on older GCC versions. src/hotspot/os_cpu/linux_x86/orderAccess_linux_x86.hpp currently says this: // Compiler version last used for testing: gcc 4.8.2 But this is blatantly not true because GCC 4.8 cannot spill ebx in PIC mode. Thanks, Florian From ioi.lam at oracle.com Wed Jun 19 17:06:17 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 19 Jun 2019 10:06:17 -0700 Subject: bootcycle build on ix86-linux-gnu broken since jdk-13+18 In-Reply-To: <352fea90-2cf2-adca-53c8-e2fa80da32b6@redhat.com> References: <352fea90-2cf2-adca-53c8-e2fa80da32b6@redhat.com> Message-ID: On 6/19/19 5:12 AM, Andrew Haley wrote: > On 6/14/19 1:57 PM, Matthias Klose wrote: >> Compiling 12 properties into resource bundles for jdk.jdeps >> # >> # There is insufficient memory for the Java Runtime Environment to continue. >> # Native memory allocation (malloc) failed to allocate 2155274940 bytes for >> AllocateHeap >> # An error report file with more information is saved as: >> >> It looks like the normal build instead of the bootcycle build succeeds. Does >> anybody else is doing regular ix86 builds and could help narrowing down when >> this started to fail? > Is this a 32-bit x86 kernel virtual machione or are you building a > 32-bit JDK in a 64-bit environment? What does cat /proc/meminfo say? > Andrew, the bug that causes the broken build is https://bugs.openjdk.java.net/browse/JDK-8226404 The failure doesn't always happen, but it's more likely to happen when your BOOT_JDK is significantly different than the JDK sources in both age and 32/64 bit-ness. Thanks - Ioi From fweimer at redhat.com Wed Jun 19 17:15:41 2019 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 19 Jun 2019 19:15:41 +0200 Subject: RFR(m): 8220351: Cross-modifying code In-Reply-To: <87fto536lo.fsf@oldenburg2.str.redhat.com> (Florian Weimer's message of "Wed, 19 Jun 2019 18:03:31 +0200") References: <4021e6fe-a2e7-7e66-bd54-1ea9d80863ae@oracle.com> <87fto536lo.fsf@oldenburg2.str.redhat.com> Message-ID: <8736k5339e.fsf@oldenburg2.str.redhat.com> * Florian Weimer: > * Martin Doerr: > >> Not sure if the inline assembler code on x86 necessarily needs a "clobber memory" effect. >> I don't know what a C++ compiler is allowed to do if it doesn't know that the code has some kind of memory effect. >> >> For ebx...edx, you could also use clobber if you want to make it shorter. >> E.g. with "+a" to use eax as input and output: >> int idx = 0; >> __asm__ volatile ("cpuid " : "+a" (idx) : : "ebx", "ecx", "edx", "memory"); > > ebx clobbers are not supported on older GCC versions. > src/hotspot/os_cpu/linux_x86/orderAccess_linux_x86.hpp currently says > this: > > // Compiler version last used for testing: gcc 4.8.2 > > But this is blatantly not true because GCC 4.8 cannot spill ebx in PIC > mode. I got this patch from Andrew Haley, and the build works again with GCC 4.8.5 (the system compiler on Red Hat Enterprise Linux 7): diff -r d7da94e6c169 src/hotspot/os_cpu/linux_x86/orderAccess_linux_x86.hpp --- a/src/hotspot/os_cpu/linux_x86/orderAccess_linux_x86.hpp Tue Jun 18 16:15:15 2019 +0100 +++ b/src/hotspot/os_cpu/linux_x86/orderAccess_linux_x86.hpp Wed Jun 19 17:52:26 2019 +0100 @@ -57,7 +57,11 @@ inline void OrderAccess::cross_modify_fence() { int idx = 0; +#ifdef AMD64 __asm__ volatile ("cpuid " : "+a" (idx) : : "ebx", "ecx", "edx", "memory"); +#else + __asm__ volatile ("xchg %%esi, %%ebx; cpuid; xchg %%esi, %%ebx " : "+a" (idx) : : "esi", "ecx", "edx", "memory"); +#endif } template<> GCC can spill %esi without problems since forever, so this should work everywhere. Thanks, Florian From doko at ubuntu.com Wed Jun 19 20:44:05 2019 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 19 Jun 2019 22:44:05 +0200 Subject: bootcycle build on ix86-linux-gnu broken since jdk-13+18 In-Reply-To: References: <352fea90-2cf2-adca-53c8-e2fa80da32b6@redhat.com> Message-ID: On 19.06.19 19:06, Ioi Lam wrote: > On 6/19/19 5:12 AM, Andrew Haley wrote: >> On 6/14/19 1:57 PM, Matthias Klose wrote: >>> Compiling 12 properties into resource bundles for jdk.jdeps >>> # >>> # There is insufficient memory for the Java Runtime Environment to continue. >>> # Native memory allocation (malloc) failed to allocate 2155274940 bytes for >>> AllocateHeap >>> # An error report file with more information is saved as: >>> >>> It looks like the normal build instead of the bootcycle build succeeds.? Does >>> anybody else is doing regular ix86 builds and could help narrowing down when >>> this started to fail? >> Is this a 32-bit x86 kernel virtual machione or are you building a >> 32-bit JDK in a 64-bit environment? What does cat /proc/meminfo say? this is a pure 32bit chroot, run with a 64bit kernel, using the linux32 personality to enter the chroot. The build should not see any hint about the 64bit kernel. The bootstrap JDK is OpenJDK 12 (32bit). Most buildd infrastructure for any Linux distribution doesn't mix 32/64 bit, including Fedora, Debian, Ubuntu. > Andrew, the bug that causes the broken build is > https://bugs.openjdk.java.net/browse/JDK-8226404 > > The failure doesn't always happen, but it's more likely to happen when your > BOOT_JDK is significantly different than the JDK sources in both age and 32/64 > bit-ness. yes, using the work-around, the build succeeds. Thanks, Matthias From thomas.stuefe at gmail.com Thu Jun 20 06:09:15 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 20 Jun 2019 08:09:15 +0200 Subject: [11u] RFR 8224487: outputStream should not be copyable In-Reply-To: References: Message-ID: Ping.. On Thu, Jun 13, 2019, 18:29 Thomas St?fe wrote: > Hi all, > > I would like to backport to 11u > > https://bugs.openjdk.java.net/browse/JDK-8224487. > > It is a precondition to backport three other fixes surrounding > stringStream: > - https://bugs.openjdk.java.net/browse/JDK-8224193 (stringStream should > not use Resource Area) > - https://bugs.openjdk.java.net/browse/JDK-8220394 (bufferedStream does > not honor size limit) > - https://bugs.openjdk.java.net/browse/JDK-8225225 (stringStream internal > buffer should always be zero terminated) > > Original RFR discussion: > https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-May/038208.html > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/0927d8c7296f > > Full patch (with 11u corrections): > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8224487-make-streams-not-copyable.patch > Delta to original patch: > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8224487-make-streams-not-copyable-11u-changes.patch > > The patch disables copy and assignment on outputStream child classes, > since this has been a source of errors (unintended sharing of the stream > backing buffer between two instances of stringStream, for instance). It > fixes all resulting build errors - which mostly indicate real errors. > > Patch did not apply cleanly since 11u misses some work in the event log > Coleen did in 12, and a small change Lutz Schmidt did for the code heap > printer. > > Thanks for the review. > > Cheers, Thomas > > From aph at redhat.com Thu Jun 20 16:49:14 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 Jun 2019 17:49:14 +0100 Subject: RFR(m): 8220351: Cross-modifying code In-Reply-To: <87fto536lo.fsf@oldenburg2.str.redhat.com> References: <4021e6fe-a2e7-7e66-bd54-1ea9d80863ae@oracle.com> <87fto536lo.fsf@oldenburg2.str.redhat.com> Message-ID: On 6/19/19 5:03 PM, Florian Weimer wrote: > ebx clobbers are not supported on older GCC versions. > src/hotspot/os_cpu/linux_x86/orderAccess_linux_x86.hpp currently says > this: > > // Compiler version last used for testing: gcc 4.8.2 > > But this is blatantly not true because GCC 4.8 cannot spill ebx in PIC > mode. https://bugs.openjdk.java.net/browse/JDK-8226525 -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From coleen.phillimore at oracle.com Thu Jun 20 17:28:31 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 20 Jun 2019 13:28:31 -0400 Subject: RFR (S) 8222446: assert(C->env()->system_dictionary_modification_counter_changed()) failed: Must invalidate if TypeFuncs differ Message-ID: <703b29a2-71a6-27d7-99e3-d54216332c33@oracle.com> Summary: Remove SystemDictionary::modification_counter optimization See bug for more details.? To avoid the assert in the bug report, it's necessary to also increase the modification counter for class unloading, which needs special code for concurrent class unloading. The global counter is used to verify that validate_dependencies() gets the same answer based on the subklass hierarchy, but provides a quick exit in production mode.? Removing it may allow more nmethods to be created that don't depend on the classes that may be loaded while the Method is being compiled.? Performance testing was done on this with no change in performance.? Also investigated the breakpoint setting code which incremented the modification counter. Dependent compilations are invalidated using evol_method dependencies, so updating the system dictionary modification counter isn't unnecessary. Tested with hs-tier1-8 testing, and CTW, and local jvmti/jdi/jdwp test runs with -Xcomp. open webrev at http://cr.openjdk.java.net/~coleenp/2019/8222446.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8222446 Thanks, Coleen From kuaiwei.kw at alibaba-inc.com Fri Jun 21 07:18:33 2019 From: kuaiwei.kw at alibaba-inc.com (Kuai Wei) Date: Fri, 21 Jun 2019 15:18:33 +0800 Subject: =?UTF-8?B?UmU6IFJGQzogSldhcm11cCBwcmVjb21waWxlIGphdmEgaG90IG1ldGhvZHMgYXQgYXBwbGlj?= =?UTF-8?B?YXRpb24gc3RhcnR1cA==?= In-Reply-To: <26f88253-deea-64d5-714c-28bb73989c62@oracle.com> References: <8cfbaa83-c50f-61c4-5336-5f30b3885d45@oracle.com> , <26f88253-deea-64d5-714c-28bb73989c62@oracle.com> Message-ID: <40bd126f-ca71-4a71-8fda-552cf8f289ad.kuaiwei.kw@alibaba-inc.com> Hi David, Sorry for the late reply. We plan to create a wiki page on OpenJDK website and put the design documents there. How do you think about it? Here are the answers to some questions in your last message: - "source file" in JWarmUp record: Application will load same class from multiple places. For example, logging jar will be packaged by different web apps. So we record this property. - super class resolution It's used for diagnostic. Same class loaded by different loaders will cause a warning message in PreloadClassChain::record_loaded_class(). We use the super class resolve mark to reduce warning messages when resolving super class. We are thinking to refine it. - dummy method It's hard to know whether JWarmUp compilations are completed or not. The dummy method is used as the last method compiled due to JWarmUp. We are able to check its entry to see whether all compilations are finished. - native entry in jvm.cpp JWarmUp defined some jvm entries which are invoked by java. We assume all jvm entries are put into jvm.cpp. Would you give us some reference we can follow? - logging flags JWarmUp was initially developed for JDK8. A flag was used to print out trace. When we ported the patch to JDK tip, we changed code to use the new log utility but with the legacy flag kept. - VM flags We will check and remove unnecessary flags. - init.cpp and mutex initialization We will modify that. - Deoptimization change I'm not clear about that. Would you like to provide more details? We will check the impact on our patch. Thanks, Kuai Wei ------------------------------------------------------------------ From:David Holmes Send Time:2019?6?10?(???) 15:18 To:yumin qi ; hotspot-runtim. Cc:hotspot-dev Subject:Re: RFC: JWarmup precompile java hot methods at application startup Hi Yumin, On 8/06/2019 3:25 am, yumin qi wrote: > Hi, David and all > > Can I have one more comment from runtime expert for the JEP? > David, can you comment for the changes? Really appreciate your last > comment. It is best if you follow the comment. > Looking forward to having your comment. I still have a lot of trouble understanding the overall design here. The JEP is very high-level; the webrev is very low-level; and there's nothing in between to explain the details of the design - the kind of document you would produce for a design review/walkthrough. For example I can't see why you need to record the "source file"; I can't see why you need to make changes to the superclass resolution. I can't tell when changes outside of Jwarmup may need to make changes to the Jwarmup code - the dependencies are unclear. I'm unclear on the role of the "dummy method" - is it just a sentinel? Why do we need it versus using some state in the JitWarmup instance? Some further code comments, but not a file by file review by any means ... The code split between the JDK and JVM doesn't seem quite right to me. registerNatives is something usually done by the JDK .c files corresponding to the classes defining the native method; it's not something done in jvm.cpp. Or if this is meant to be a special case like JVM_RegisterMethodHandleMethods then probably it should be in the jwarmup.cpp file. Also if you pass the necessary objects through the API you won't need to jump back to native to call a JNI function. AliasedLoggingFlags are for converting legacy flags to unified logging. You should just be using UL and not introducing the PrintCompilationWarmUpDetail psuedo-flag. This work introduces thirteen new VM flags! That's very excessive. Perhaps you should look at defining something more like -Xlog that encodes all the options? (And this will need a very lengthy CSR request!). The init.cpp code should be factored out into jwarmup_init functions in jwarmup.cpp. Mutex initialization should be conditional on jwarmup being enabled. Deoptimization has been changed lately to avoid use of safepoints so you may need to re-examine that aspect. You have a number of uses of patterns like this (but not everywhere): + JitWarmUp* jwp = JitWarmUp::instance(); + assert(jwp != NULL, "sanity check"); + jwp->preloader()->jvm_booted_is_done(); The assertion should be inside instance() so that these collapse to a single line: JitWarmup::instance()->preloader->whatever(); Your Java files have @version 1.8. --- Cheers, David ----- > Thanks > Yumin > > On Sun, May 19, 2019 at 10:28 AM yumin qi > wrote: > > Hi, Tobias and all > Have done changes based on Tobias' comments. New webrev based on > most recent base is updated at: > http://cr.openjdk.java.net/~minqi/8220692/webrev-03/ > > Tested local for jwarmup and compiler. > > Thanks > Yumin > > On Tue, May 14, 2019 at 11:26 AM yumin qi > wrote: > > HI, Tobias > > Thanks very much for the comments. > > On Mon, May 13, 2019 at 2:58 AM Tobias Hartmann > > > wrote: > > Hi Yumin, > > > In this version, the profiled method data is not used at > > precomilation, it will be addressed in followed bug fix. > After the > > first version integrated, will file bug for it. > > Why is that? I think it would be good to have everything in > one JEP. > > > We have done some tests on adding profiling data and found the > result is not as expected, and the current version is working > well for internal online applications. There is no other reason > not adding to this patch now, we will like to study further to > see if we can improve that for a better performance. > > I've looked at the compiler related changes. Here are some > comments/questions. > > ciMethod.cpp > - So CompilationWarmUp is not using any profile information? > Not even the profile obtained in the > current execution? > > > Yes. This is also related to previous question. > > compile.cpp > - line 748: Why is that required? Couldn't it happen that a > method is never compiled because the > code that would resolve a field is never executed? > > > Here a very aggressive decision --- to avoid compilation failure > requires that all fields have already been resolved. > > graphKit.cpp > - line 2832: please add a comment > - line 2917: checks should be merged into one if and please > add a comment > > > Will fix it. > > jvm.cpp > - Could you explain why it's guaranteed that warmup > compilation is completed once the dummy method > is compiled? And why is it hardcoded to print > "com.alibaba.jwarmup.JWarmUp"? > > > This is from practical testing of real applications. Due to the > parallelism of compilation works, it should check if > compilation queue contains any of those methods --- completed if > no any of them on the queue and it is not economic. By using of > a dummy method as a simplified version for that, in real case, > it is not observed that dummy method is not the last compilation > for warmup. Do you have suggestion of a way to do that? The > dummy way is not strictly a guaranteed one theoretically. > Forgot to change the print to new name after renaming package, > thanks for the catching. > > - What is test_symbol_matcher() used for? > > > This is a leftover(used to test matching patterns), will remove > it from the file. > > jitWarmUp.cpp: > - line 146: So what about methods that are only ever > compiled at C1 level? Wouldn't it make sense to > keep track of the comp_level during CompilationWarmUpRecording? > > > Will consider your suggestion in future work on it. > > I also found several typos while reading through the code > (listed in random order): > > globals.hpp > - "flushing profling" -> "flushing profiling" > > method.hpp > - "when this method first been invoked" > > templateInterpreterGenerator_x86.cpp > - initializition -> initialization > > dict.cpp > - initializated -> initialized > > jitWarmUp.cpp > - uninitilaized -> uninitialized > - inited -> should be initialized, right? > > jitWarmUp.hpp > . nofityApplicationStartUpIsDone -> > notifyApplicationStartUpIsDone > > constantPool.cpp > - recusive -> recursive > > JWarmUp.java > - appliacation -> application > > TestThrowInitializaitonException.java -> > TestThrowInitializationException.java > > These tests should be renamed (it's not clear what issue the > number refers to): > - issue9780156.sh > - Issue11272598.java > > > Will fix all above suggestions. > > Thanks! > > Yumin > From dean.long at oracle.com Fri Jun 21 19:48:25 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 21 Jun 2019 12:48:25 -0700 Subject: RFR (S) 8222446: assert(C->env()->system_dictionary_modification_counter_changed()) failed: Must invalidate if TypeFuncs differ In-Reply-To: <703b29a2-71a6-27d7-99e3-d54216332c33@oracle.com> References: <703b29a2-71a6-27d7-99e3-d54216332c33@oracle.com> Message-ID: For the most part, this looks good.? I only have a couple concerns: 1) The distinction in both validate_compile_task_dependencies functions between "dependencies failed" and "dependencies invalid" is even more fuzzy after this change.? I suggest filing an RFE to remove this distinction. 2) In Parse::do_exits(), we don't know that concurrent class loading didn't cause the problem.? We should be optimistic and allow the retry: C->record_failure(C2Compiler::retry_class_loading_during_parsing()); rather than more drastic ??? C->record_method_not_compilable This is actually what the code did in an earlier revision. dl On 6/20/19 10:28 AM, coleen.phillimore at oracle.com wrote: > Summary: Remove SystemDictionary::modification_counter optimization > > See bug for more details.? To avoid the assert in the bug report, it's > necessary to also increase the modification counter for class > unloading, which needs special code for concurrent class unloading. > The global counter is used to verify that validate_dependencies() gets > the same answer based on the subklass hierarchy, but provides a quick > exit in production mode.? Removing it may allow more nmethods to be > created that don't depend on the classes that may be loaded while the > Method is being compiled. Performance testing was done on this with no > change in performance.? Also investigated the breakpoint setting code > which incremented the modification counter. Dependent compilations are > invalidated using evol_method dependencies, so updating the system > dictionary modification counter isn't unnecessary. > > Tested with hs-tier1-8 testing, and CTW, and local jvmti/jdi/jdwp test > runs with -Xcomp. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8222446.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8222446 > > Thanks, > Coleen From coleen.phillimore at oracle.com Fri Jun 21 20:44:52 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 21 Jun 2019 16:44:52 -0400 Subject: RFR (S) 8222446: assert(C->env()->system_dictionary_modification_counter_changed()) failed: Must invalidate if TypeFuncs differ In-Reply-To: References: <703b29a2-71a6-27d7-99e3-d54216332c33@oracle.com> Message-ID: <154ad551-d397-5abe-1b6a-7a3ddd129f3d@oracle.com> Dean,? Thank you for reviewing and for your help and discussion of this change. On 6/21/19 3:48 PM, dean.long at oracle.com wrote: > For the most part, this looks good.? I only have a couple concerns: > > 1) The distinction in both validate_compile_task_dependencies > functions between "dependencies failed" and "dependencies invalid" is > even more fuzzy after this change.? I suggest filing an RFE to remove > this distinction. Yes, in jvmciRuntime I had to carefully preserve this logic or some tests failed.?? I'll file an RFE for you. > > 2) In Parse::do_exits(), we don't know that concurrent class loading > didn't cause the problem.? We should be optimistic and allow the retry: > C->record_failure(C2Compiler::retry_class_loading_during_parsing()); > rather than more drastic > ??? C->record_method_not_compilable > This is actually what the code did in an earlier revision. Erik and I were trying to guess which was the right answer.? It seemed too lucky that you'd do concurrent class loading in this time period, so we picked the more drastic answer, but I tested both.? So I'll change it to the optimistic answer. Thanks! Coleen > > dl > > On 6/20/19 10:28 AM, coleen.phillimore at oracle.com wrote: >> Summary: Remove SystemDictionary::modification_counter optimization >> >> See bug for more details.? To avoid the assert in the bug report, >> it's necessary to also increase the modification counter for class >> unloading, which needs special code for concurrent class unloading. >> The global counter is used to verify that validate_dependencies() >> gets the same answer based on the subklass hierarchy, but provides a >> quick exit in production mode.? Removing it may allow more nmethods >> to be created that don't depend on the classes that may be loaded >> while the Method is being compiled. Performance testing was done on >> this with no change in performance.? Also investigated the breakpoint >> setting code which incremented the modification counter. Dependent >> compilations are invalidated using evol_method dependencies, so >> updating the system dictionary modification counter isn't unnecessary. >> >> Tested with hs-tier1-8 testing, and CTW, and local jvmti/jdi/jdwp >> test runs with -Xcomp. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8222446.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8222446 >> >> Thanks, >> Coleen > From thomas.stuefe at gmail.com Mon Jun 24 05:43:41 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 24 Jun 2019 07:43:41 +0200 Subject: [11u] RFR 8224487: outputStream should not be copyable In-Reply-To: References: Message-ID: Ping... no takers? On Thu, Jun 20, 2019 at 8:09 AM Thomas St?fe wrote: > Ping.. > > On Thu, Jun 13, 2019, 18:29 Thomas St?fe wrote: > >> Hi all, >> >> I would like to backport to 11u >> >> https://bugs.openjdk.java.net/browse/JDK-8224487. >> >> It is a precondition to backport three other fixes surrounding >> stringStream: >> - https://bugs.openjdk.java.net/browse/JDK-8224193 (stringStream should >> not use Resource Area) >> - https://bugs.openjdk.java.net/browse/JDK-8220394 (bufferedStream does >> not honor size limit) >> - https://bugs.openjdk.java.net/browse/JDK-8225225 (stringStream >> internal buffer should always be zero terminated) >> >> Original RFR discussion: >> https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-May/038208.html >> Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/0927d8c7296f >> >> Full patch (with 11u corrections): >> http://cr.openjdk.java.net/~stuefe/webrevs/backports/8224487-make-streams-not-copyable.patch >> Delta to original patch: >> http://cr.openjdk.java.net/~stuefe/webrevs/backports/8224487-make-streams-not-copyable-11u-changes.patch >> >> The patch disables copy and assignment on outputStream child classes, >> since this has been a source of errors (unintended sharing of the stream >> backing buffer between two instances of stringStream, for instance). It >> fixes all resulting build errors - which mostly indicate real errors. >> >> Patch did not apply cleanly since 11u misses some work in the event log >> Coleen did in 12, and a small change Lutz Schmidt did for the code heap >> printer. >> >> Thanks for the review. >> >> Cheers, Thomas >> >> From christoph.langer at sap.com Mon Jun 24 07:44:44 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 24 Jun 2019 07:44:44 +0000 Subject: [11u] RFR 8224487: outputStream should not be copyable In-Reply-To: References: Message-ID: Hi Thomas, I think this is good. Looks like you resolved the rejects correctly. Will you run it through our test system? I don't see the patch in there currently... Thanks & Best regards Christoph > -----Original Message----- > From: hotspot-dev On Behalf Of > Thomas St?fe > Sent: Donnerstag, 13. Juni 2019 18:29 > To: jdk-updates-dev at openjdk.java.net > Cc: HotSpot Open Source Developers > Subject: [11u] RFR 8224487: outputStream should not be copyable > > Hi all, > > I would like to backport to 11u > > https://bugs.openjdk.java.net/browse/JDK-8224487. > > It is a precondition to backport three other fixes surrounding > stringStream: > - https://bugs.openjdk.java.net/browse/JDK-8224193 (stringStream should > not use Resource Area) > - https://bugs.openjdk.java.net/browse/JDK-8220394 (bufferedStream > does > not honor size limit) > - https://bugs.openjdk.java.net/browse/JDK-8225225 (stringStream internal > buffer should always be zero terminated) > > Original RFR discussion: > https://mail.openjdk.java.net/pipermail/hotspot-dev/2019- > May/038208.html > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/0927d8c7296f > > Full patch (with 11u corrections): > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8224487-make- > streams-not-copyable.patch > Delta to original patch: > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8224487-make- > streams-not-copyable-11u-changes.patch > > The patch disables copy and assignment on outputStream child classes, since > this has been a source of errors (unintended sharing of the stream backing > buffer between two instances of stringStream, for instance). It fixes all > resulting build errors - which mostly indicate real errors. > > Patch did not apply cleanly since 11u misses some work in the event log > Coleen did in 12, and a small change Lutz Schmidt did for the code heap > printer. > > Thanks for the review. > > Cheers, Thomas From thomas.stuefe at gmail.com Mon Jun 24 09:32:37 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 24 Jun 2019 11:32:37 +0200 Subject: [11u] RFR 8224487: outputStream should not be copyable In-Reply-To: References: Message-ID: Thank you Christoph. Patch has been tested in 11u-dev for the last ~10 nights. Cheers, Thomas On Mon, Jun 24, 2019 at 9:44 AM Langer, Christoph wrote: > Hi Thomas, > > I think this is good. Looks like you resolved the rejects correctly. > > Will you run it through our test system? I don't see the patch in there > currently... > > Thanks & Best regards > Christoph > > > -----Original Message----- > > From: hotspot-dev On Behalf Of > > Thomas St?fe > > Sent: Donnerstag, 13. Juni 2019 18:29 > > To: jdk-updates-dev at openjdk.java.net > > Cc: HotSpot Open Source Developers > > Subject: [11u] RFR 8224487: outputStream should not be copyable > > > > Hi all, > > > > I would like to backport to 11u > > > > https://bugs.openjdk.java.net/browse/JDK-8224487. > > > > It is a precondition to backport three other fixes surrounding > > stringStream: > > - https://bugs.openjdk.java.net/browse/JDK-8224193 (stringStream should > > not use Resource Area) > > - https://bugs.openjdk.java.net/browse/JDK-8220394 (bufferedStream > > does > > not honor size limit) > > - https://bugs.openjdk.java.net/browse/JDK-8225225 (stringStream > internal > > buffer should always be zero terminated) > > > > Original RFR discussion: > > https://mail.openjdk.java.net/pipermail/hotspot-dev/2019- > > May/038208.html > > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/0927d8c7296f > > > > Full patch (with 11u corrections): > > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8224487-make- > > streams-not-copyable.patch > > Delta to original patch: > > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8224487-make- > > streams-not-copyable-11u-changes.patch > > > > The patch disables copy and assignment on outputStream child classes, > since > > this has been a source of errors (unintended sharing of the stream > backing > > buffer between two instances of stringStream, for instance). It fixes all > > resulting build errors - which mostly indicate real errors. > > > > Patch did not apply cleanly since 11u misses some work in the event log > > Coleen did in 12, and a small change Lutz Schmidt did for the code heap > > printer. > > > > Thanks for the review. > > > > Cheers, Thomas > From christoph.langer at sap.com Mon Jun 24 09:36:50 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 24 Jun 2019 09:36:50 +0000 Subject: [11u] RFR 8224487: outputStream should not be copyable In-Reply-To: References: Message-ID: Hi Thomas, thanks, I see the patch in the system ? just didn?t look right before ?? /Christoph From: Thomas St?fe Sent: Montag, 24. Juni 2019 11:33 To: Langer, Christoph Cc: jdk-updates-dev at openjdk.java.net; HotSpot Open Source Developers Subject: Re: [11u] RFR 8224487: outputStream should not be copyable Thank you Christoph. Patch has been tested in 11u-dev for the last ~10 nights. Cheers, Thomas On Mon, Jun 24, 2019 at 9:44 AM Langer, Christoph > wrote: Hi Thomas, I think this is good. Looks like you resolved the rejects correctly. Will you run it through our test system? I don't see the patch in there currently... Thanks & Best regards Christoph > -----Original Message----- > From: hotspot-dev > On Behalf Of > Thomas St?fe > Sent: Donnerstag, 13. Juni 2019 18:29 > To: jdk-updates-dev at openjdk.java.net > Cc: HotSpot Open Source Developers > > Subject: [11u] RFR 8224487: outputStream should not be copyable > > Hi all, > > I would like to backport to 11u > > https://bugs.openjdk.java.net/browse/JDK-8224487. > > It is a precondition to backport three other fixes surrounding > stringStream: > - https://bugs.openjdk.java.net/browse/JDK-8224193 (stringStream should > not use Resource Area) > - https://bugs.openjdk.java.net/browse/JDK-8220394 (bufferedStream > does > not honor size limit) > - https://bugs.openjdk.java.net/browse/JDK-8225225 (stringStream internal > buffer should always be zero terminated) > > Original RFR discussion: > https://mail.openjdk.java.net/pipermail/hotspot-dev/2019- > May/038208.html > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/0927d8c7296f > > Full patch (with 11u corrections): > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8224487-make- > streams-not-copyable.patch > Delta to original patch: > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8224487-make- > streams-not-copyable-11u-changes.patch > > The patch disables copy and assignment on outputStream child classes, since > this has been a source of errors (unintended sharing of the stream backing > buffer between two instances of stringStream, for instance). It fixes all > resulting build errors - which mostly indicate real errors. > > Patch did not apply cleanly since 11u misses some work in the event log > Coleen did in 12, and a small change Lutz Schmidt did for the code heap > printer. > > Thanks for the review. > > Cheers, Thomas From matthias.baesken at sap.com Tue Jun 25 07:43:17 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 25 Jun 2019 07:43:17 +0000 Subject: RFR: 8226238: Improve error output and fix elf issues in os::dll_load Message-ID: Ping ... Best regards, Matthias From: Baesken, Matthias Sent: Dienstag, 18. Juni 2019 13:24 To: 'hotspot-dev at openjdk.java.net' Subject: RE: RFR: 8226238: Improve error output and fix elf issues in os::dll_load Hello, I noticed the solaris os::dll_load coding has similar issues. New webrev ( handling linux + solaris ) : http://cr.openjdk.java.net/~mbaesken/webrevs/8226238.3/ Best regards, Matthias Hello, please review this change to linux os::dll_load . os::dll_load includes some coding to report error details in cases where the lib loading fails . For this , we ELF header of the shared-object we failed to load is evaluated . However the code currently has some issues . - it misses to convert endianness of elf_head.e_machine (ELF data entry) in case the platform we run on, and the lib we try to load have different endianness - the error message could show the real elf architecture name in mismatch cases (but does not) Adjusted error message looks like this : example from renaissance db-shootout benchmark that runs on linuxs390x and attempts to load an x86_64 JNI lib "by mistake" message without the change : .... ELF file data encoding not big-endian (Possible cause: endianness mismatch)] with change : .... ELF file data encoding not big-endian (Possible cause: can't load AMD 64 .so on a IBM System/390 platform) bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8226238 http://cr.openjdk.java.net/~mbaesken/webrevs/8226238.2/ From kim.barrett at oracle.com Wed Jun 26 02:38:57 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 25 Jun 2019 22:38:57 -0400 Subject: RFR[13]: 8226366: Excessive ServiceThread wakeups for OopStorage cleanup Message-ID: Please review this change to OopStorage's notifications to the ServiceThread to perform empty block deletion. The existing mechanism (introduced by JDK-8210986) is driven by entry allocation, and may arbitrarily delay such cleanup, or alternatively may be much too enthusiastic about waking up the ServiceThread. The new mechanism does not depend on allocations. Instead, a new safepoint cleanup task is used to (irregularly) check for pending requests and notify the ServiceThread. That notification has a time-based throttle, and also avoids duplicate notifications. Also, requests are now only recorded for to-empty transitions and not for full to not-full transitions. Changed the work limit for delete_empty_blocks to have a small surplus to avoid some common cases with small number of blocks leading to unnecessarily spinning the ServiceThread. While making these changes, noticed and fixed a problem in block allocation that could result in a mistaken report of allocation failure. CR: https://bugs.openjdk.java.net/browse/JDK-8226366 Webrev: http://cr.openjdk.java.net/~kbarrett/8226366/open.00/ Testing: mach5 tier1-5 Locally ran gc/stress/TestReclaimStringsLeaksMemory.java with some extra logging and verified that the number of ServiceThread notifications was reduced by a *lot*, down to something reasonable. From matthias.baesken at sap.com Wed Jun 26 06:48:42 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 26 Jun 2019 06:48:42 +0000 Subject: RFR [jdk11u] : 8224221: add memprotect calls to event log Message-ID: Hello, please review the downport of 8224221: add memprotect calls to event log to jdk11 . The "good old" patch from jdk7jdk mostly applies nicely . However the changes to src/hotspot/share/utilities/events.hpp had to be adjusted a bit manually because Events.hpp differs a bit when you compare jdk11u and jdk/jdk . Bug/webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8224221_11udev.0/ https://bugs.openjdk.java.net/browse/JDK-8224221 Thanks and best regards, Matthias From christoph.langer at sap.com Wed Jun 26 08:15:56 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 26 Jun 2019 08:15:56 +0000 Subject: RFR [jdk11u] : 8224221: add memprotect calls to event log In-Reply-To: References: Message-ID: Hi Matthias, I eyeballed it and it looks good to me. After it runs without regressions through our test system I guess you are good to go. /Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Baesken, Matthias > Sent: Mittwoch, 26. Juni 2019 08:49 > To: 'hotspot-dev at openjdk.java.net' ; jdk- > updates-dev at openjdk.java.net > Subject: [CAUTION] RFR [jdk11u] : 8224221: add memprotect calls to event > log > > Hello, please review the downport of 8224221: add memprotect calls to > event log to jdk11 . > The "good old" patch from jdk7jdk mostly applies nicely . > However the changes to src/hotspot/share/utilities/events.hpp had to be > adjusted a bit manually because > Events.hpp differs a bit when you compare jdk11u and jdk/jdk . > > > Bug/webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224221_11udev.0/ > > https://bugs.openjdk.java.net/browse/JDK-8224221 > > > Thanks and best regards, Matthias From matthias.baesken at sap.com Wed Jun 26 10:19:32 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 26 Jun 2019 10:19:32 +0000 Subject: RFR [jdk11u] : 8224221: add memprotect calls to event log In-Reply-To: References: Message-ID: Hi Christoph, thanks for the review ! Best regards, Matthias > -----Original Message----- > From: Langer, Christoph > Sent: Mittwoch, 26. Juni 2019 10:16 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; jdk-updates- > dev at openjdk.java.net > Subject: RE: RFR [jdk11u] : 8224221: add memprotect calls to event log > > Hi Matthias, > > I eyeballed it and it looks good to me. After it runs without regressions > through our test system I guess you are good to go. > > /Christoph > From coleen.phillimore at oracle.com Wed Jun 26 15:02:51 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 26 Jun 2019 11:02:51 -0400 Subject: RFR (S) 8225437: JvmtiExport::gc_epilogue is unnecessary Message-ID: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> Summary: Remove jvmtiExport::gc_epilogue after full GCs See bug for more information. open webrev at http://cr.openjdk.java.net/~coleenp/2019/8225437.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8225437 Tested with hs-tier1-3. Thanks, Coleen From david.holmes at oracle.com Wed Jun 26 15:44:42 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Jun 2019 11:44:42 -0400 Subject: RFR (S) 8225437: JvmtiExport::gc_epilogue is unnecessary In-Reply-To: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> References: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> Message-ID: <8aa8e760-8d9f-56f3-6daf-c9263539f2a8@oracle.com> Hi Coleen, That seems okay so far, but there seem to be changes missing from ./share/prims/jvmtiImpl.hpp Thanks, David On 26/06/2019 11:02 am, coleen.phillimore at oracle.com wrote: > Summary: Remove jvmtiExport::gc_epilogue after full GCs > > See bug for more information. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8225437.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8225437 > > Tested with hs-tier1-3. > > Thanks, > Coleen From coleen.phillimore at oracle.com Wed Jun 26 17:47:49 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 26 Jun 2019 13:47:49 -0400 Subject: RFR (S) 8225437: JvmtiExport::gc_epilogue is unnecessary In-Reply-To: <8aa8e760-8d9f-56f3-6daf-c9263539f2a8@oracle.com> References: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> <8aa8e760-8d9f-56f3-6daf-c9263539f2a8@oracle.com> Message-ID: On 6/26/19 11:44 AM, David Holmes wrote: > Hi Coleen, > > That seems okay so far, but there seem to be changes missing from > > ./share/prims/jvmtiImpl.hpp Good find.? Also a missing one from jvmtiExport.hpp. open webrev at http://cr.openjdk.java.net/~coleenp/2019/8225437.02/webrev thanks! Coleen > > Thanks, > David > > On 26/06/2019 11:02 am, coleen.phillimore at oracle.com wrote: >> Summary: Remove jvmtiExport::gc_epilogue after full GCs >> >> See bug for more information. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8225437.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8225437 >> >> Tested with hs-tier1-3. >> >> Thanks, >> Coleen From serguei.spitsyn at oracle.com Wed Jun 26 18:03:57 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 26 Jun 2019 11:03:57 -0700 Subject: RFR (S) 8225437: JvmtiExport::gc_epilogue is unnecessary In-Reply-To: References: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> <8aa8e760-8d9f-56f3-6daf-c9263539f2a8@oracle.com> Message-ID: Hi Coleen, It looks good. Thanks, Serguei On 6/26/19 10:47, coleen.phillimore at oracle.com wrote: > > > On 6/26/19 11:44 AM, David Holmes wrote: >> Hi Coleen, >> >> That seems okay so far, but there seem to be changes missing from >> >> ./share/prims/jvmtiImpl.hpp > > Good find.? Also a missing one from jvmtiExport.hpp. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8225437.02/webrev > > thanks! > Coleen >> >> Thanks, >> David >> >> On 26/06/2019 11:02 am, coleen.phillimore at oracle.com wrote: >>> Summary: Remove jvmtiExport::gc_epilogue after full GCs >>> >>> See bug for more information. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2019/8225437.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8225437 >>> >>> Tested with hs-tier1-3. >>> >>> Thanks, >>> Coleen > From david.holmes at oracle.com Wed Jun 26 18:14:13 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Jun 2019 14:14:13 -0400 Subject: RFR (S) 8225437: JvmtiExport::gc_epilogue is unnecessary In-Reply-To: References: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> <8aa8e760-8d9f-56f3-6daf-c9263539f2a8@oracle.com> Message-ID: <28fa313e-e538-96b2-03a3-02124ab97f4d@oracle.com> Hi Coleen, v2 looks complete. Thanks, David On 26/06/2019 1:47 pm, coleen.phillimore at oracle.com wrote: > > > On 6/26/19 11:44 AM, David Holmes wrote: >> Hi Coleen, >> >> That seems okay so far, but there seem to be changes missing from >> >> ./share/prims/jvmtiImpl.hpp > > Good find.? Also a missing one from jvmtiExport.hpp. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8225437.02/webrev > > thanks! > Coleen >> >> Thanks, >> David >> >> On 26/06/2019 11:02 am, coleen.phillimore at oracle.com wrote: >>> Summary: Remove jvmtiExport::gc_epilogue after full GCs >>> >>> See bug for more information. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2019/8225437.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8225437 >>> >>> Tested with hs-tier1-3. >>> >>> Thanks, >>> Coleen > From coleen.phillimore at oracle.com Wed Jun 26 18:41:21 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 26 Jun 2019 14:41:21 -0400 Subject: RFR (S) 8225437: JvmtiExport::gc_epilogue is unnecessary In-Reply-To: References: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> <8aa8e760-8d9f-56f3-6daf-c9263539f2a8@oracle.com> Message-ID: <89cf6834-dccd-a16c-096b-95a64c3ef155@oracle.com> Thanks Serguei! Coleen On 6/26/19 2:03 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > It looks good. > > Thanks, > Serguei > > > On 6/26/19 10:47, coleen.phillimore at oracle.com wrote: >> >> >> On 6/26/19 11:44 AM, David Holmes wrote: >>> Hi Coleen, >>> >>> That seems okay so far, but there seem to be changes missing from >>> >>> ./share/prims/jvmtiImpl.hpp >> >> Good find.? Also a missing one from jvmtiExport.hpp. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8225437.02/webrev >> >> thanks! >> Coleen >>> >>> Thanks, >>> David >>> >>> On 26/06/2019 11:02 am, coleen.phillimore at oracle.com wrote: >>>> Summary: Remove jvmtiExport::gc_epilogue after full GCs >>>> >>>> See bug for more information. >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2019/8225437.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8225437 >>>> >>>> Tested with hs-tier1-3. >>>> >>>> Thanks, >>>> Coleen >> > From coleen.phillimore at oracle.com Wed Jun 26 18:41:46 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 26 Jun 2019 14:41:46 -0400 Subject: RFR (S) 8225437: JvmtiExport::gc_epilogue is unnecessary In-Reply-To: <28fa313e-e538-96b2-03a3-02124ab97f4d@oracle.com> References: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> <8aa8e760-8d9f-56f3-6daf-c9263539f2a8@oracle.com> <28fa313e-e538-96b2-03a3-02124ab97f4d@oracle.com> Message-ID: <646a612a-9ef3-3265-4675-bb5f33596153@oracle.com> Thanks David! Coleen On 6/26/19 2:14 PM, David Holmes wrote: > Hi Coleen, > > v2 looks complete. > > Thanks, > David > > On 26/06/2019 1:47 pm, coleen.phillimore at oracle.com wrote: >> >> >> On 6/26/19 11:44 AM, David Holmes wrote: >>> Hi Coleen, >>> >>> That seems okay so far, but there seem to be changes missing from >>> >>> ./share/prims/jvmtiImpl.hpp >> >> Good find.? Also a missing one from jvmtiExport.hpp. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8225437.02/webrev >> >> thanks! >> Coleen >>> >>> Thanks, >>> David >>> >>> On 26/06/2019 11:02 am, coleen.phillimore at oracle.com wrote: >>>> Summary: Remove jvmtiExport::gc_epilogue after full GCs >>>> >>>> See bug for more information. >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2019/8225437.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8225437 >>>> >>>> Tested with hs-tier1-3. >>>> >>>> Thanks, >>>> Coleen >> From dean.long at oracle.com Wed Jun 26 18:50:20 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 26 Jun 2019 11:50:20 -0700 Subject: RFR (S) 8225437: JvmtiExport::gc_epilogue is unnecessary In-Reply-To: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> References: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> Message-ID: I don't see it removed from the .hpp files. dl On 6/26/19 8:02 AM, coleen.phillimore at oracle.com wrote: > Summary: Remove jvmtiExport::gc_epilogue after full GCs > > See bug for more information. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8225437.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8225437 > > Tested with hs-tier1-3. > > Thanks, > Coleen From coleen.phillimore at oracle.com Wed Jun 26 19:37:16 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 26 Jun 2019 15:37:16 -0400 Subject: RFR (S) 8225437: JvmtiExport::gc_epilogue is unnecessary In-Reply-To: References: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> Message-ID: <7584cd71-5a40-736c-17e8-5578c0711c78@oracle.com> Hi Dean, thank you for reviewing.? I removed the declarations from the .hpp files in this webrev: open webrev at http://cr.openjdk.java.net/~coleenp/2019/8225437.02/webrev thanks, Coleen On 6/26/19 2:50 PM, dean.long at oracle.com wrote: > I don't see it removed from the .hpp files. > > dl > > On 6/26/19 8:02 AM, coleen.phillimore at oracle.com wrote: >> Summary: Remove jvmtiExport::gc_epilogue after full GCs >> >> See bug for more information. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8225437.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8225437 >> >> Tested with hs-tier1-3. >> >> Thanks, >> Coleen > From dean.long at oracle.com Wed Jun 26 21:48:35 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 26 Jun 2019 14:48:35 -0700 Subject: RFR (S) 8225437: JvmtiExport::gc_epilogue is unnecessary In-Reply-To: <28fa313e-e538-96b2-03a3-02124ab97f4d@oracle.com> References: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> <8aa8e760-8d9f-56f3-6daf-c9263539f2a8@oracle.com> <28fa313e-e538-96b2-03a3-02124ab97f4d@oracle.com> Message-ID: <2edada21-df15-09ce-62c9-22fd43314b8e@oracle.com> +1 dl On 6/26/19 11:14 AM, David Holmes wrote: > Hi Coleen, > > v2 looks complete. > > Thanks, > David > > On 26/06/2019 1:47 pm, coleen.phillimore at oracle.com wrote: >> >> >> On 6/26/19 11:44 AM, David Holmes wrote: >>> Hi Coleen, >>> >>> That seems okay so far, but there seem to be changes missing from >>> >>> ./share/prims/jvmtiImpl.hpp >> >> Good find.? Also a missing one from jvmtiExport.hpp. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8225437.02/webrev >> >> thanks! >> Coleen >>> >>> Thanks, >>> David >>> >>> On 26/06/2019 11:02 am, coleen.phillimore at oracle.com wrote: >>>> Summary: Remove jvmtiExport::gc_epilogue after full GCs >>>> >>>> See bug for more information. >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2019/8225437.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8225437 >>>> >>>> Tested with hs-tier1-3. >>>> >>>> Thanks, >>>> Coleen >> From coleen.phillimore at oracle.com Wed Jun 26 22:35:47 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 26 Jun 2019 18:35:47 -0400 Subject: RFR (S) 8225437: JvmtiExport::gc_epilogue is unnecessary In-Reply-To: <2edada21-df15-09ce-62c9-22fd43314b8e@oracle.com> References: <71ebb0fa-9354-21b3-580a-6cb8163a6fb4@oracle.com> <8aa8e760-8d9f-56f3-6daf-c9263539f2a8@oracle.com> <28fa313e-e538-96b2-03a3-02124ab97f4d@oracle.com> <2edada21-df15-09ce-62c9-22fd43314b8e@oracle.com> Message-ID: Thanks Dean! Coleen On 6/26/19 5:48 PM, dean.long at oracle.com wrote: > +1 > > dl > > On 6/26/19 11:14 AM, David Holmes wrote: >> Hi Coleen, >> >> v2 looks complete. >> >> Thanks, >> David >> >> On 26/06/2019 1:47 pm, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 6/26/19 11:44 AM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> That seems okay so far, but there seem to be changes missing from >>>> >>>> ./share/prims/jvmtiImpl.hpp >>> >>> Good find.? Also a missing one from jvmtiExport.hpp. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2019/8225437.02/webrev >>> >>> thanks! >>> Coleen >>>> >>>> Thanks, >>>> David >>>> >>>> On 26/06/2019 11:02 am, coleen.phillimore at oracle.com wrote: >>>>> Summary: Remove jvmtiExport::gc_epilogue after full GCs >>>>> >>>>> See bug for more information. >>>>> >>>>> open webrev at >>>>> http://cr.openjdk.java.net/~coleenp/2019/8225437.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8225437 >>>>> >>>>> Tested with hs-tier1-3. >>>>> >>>>> Thanks, >>>>> Coleen >>> > From matthias.baesken at sap.com Thu Jun 27 08:56:56 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 27 Jun 2019 08:56:56 +0000 Subject: RFR: 8226816: add UserHandler calls to event log Message-ID: Hello, please review the following small patch . It adds event logging to the UserHandler (user signal handler) calls . (additionally it adds a function os::win32::get_signal_name to get signal names for signal numbers ; this is similar to what we already had for posix ). Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8226816 http://cr.openjdk.java.net/~mbaesken/webrevs/8226816.0/ Thanks, Matthias From aoqi at loongson.cn Thu Jun 27 09:49:40 2019 From: aoqi at loongson.cn (Ao Qi) Date: Thu, 27 Jun 2019 17:49:40 +0800 Subject: RFR(trivial): JDK-8226871: invalid use of incomplete type class MacroAssembler when building minimal after JDK-8191278 Message-ID: Hi, Could I please get reviews for this? JBS: https://bugs.openjdk.java.net/browse/JDK-8226871 Fix: http://cr.openjdk.java.net/~aoqi/8226871/webrev.00/ Tested: hotspot:tier1 Thanks, Ao Qi From shade at redhat.com Thu Jun 27 09:53:15 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 27 Jun 2019 11:53:15 +0200 Subject: RFR(trivial): JDK-8226871: invalid use of incomplete type class MacroAssembler when building minimal after JDK-8191278 In-Reply-To: References: Message-ID: <75ea09f6-35ed-df38-acd6-ba5016bef26b@redhat.com> On 6/27/19 11:49 AM, Ao Qi wrote: > JBS: > https://bugs.openjdk.java.net/browse/JDK-8226871 > > Fix: > http://cr.openjdk.java.net/~aoqi/8226871/webrev.00/ I don't think we should be adding .inline.hpp includes into .hpp files. From the failure log in the bug, it seems we'd need to add that include to stubRoutines.cpp instead? -Aleksey From aoqi at loongson.cn Thu Jun 27 10:13:07 2019 From: aoqi at loongson.cn (Ao Qi) Date: Thu, 27 Jun 2019 18:13:07 +0800 Subject: RFR(trivial): JDK-8226871: invalid use of incomplete type class MacroAssembler when building minimal after JDK-8191278 In-Reply-To: <75ea09f6-35ed-df38-acd6-ba5016bef26b@redhat.com> References: <75ea09f6-35ed-df38-acd6-ba5016bef26b@redhat.com> Message-ID: On Thu, Jun 27, 2019 at 5:53 PM Aleksey Shipilev wrote: > > On 6/27/19 11:49 AM, Ao Qi wrote: > > JBS: > > https://bugs.openjdk.java.net/browse/JDK-8226871 > > > > Fix: > > http://cr.openjdk.java.net/~aoqi/8226871/webrev.00/ > > I don't think we should be adding .inline.hpp includes into .hpp files. From the failure log in the > bug, it seems we'd need to add that include to stubRoutines.cpp instead? Yes. You are right. Updated: http://cr.openjdk.java.net/~aoqi/8226871/webrev.01/ Tested: server/minimal build, and hotspot:tier1. Thanks, Ao Qi > > -Aleksey > From shade at redhat.com Thu Jun 27 10:20:25 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 27 Jun 2019 12:20:25 +0200 Subject: RFR(trivial): JDK-8226871: invalid use of incomplete type class MacroAssembler when building minimal after JDK-8191278 In-Reply-To: References: <75ea09f6-35ed-df38-acd6-ba5016bef26b@redhat.com> Message-ID: <80137b36-c6be-2f09-abfd-8efb6b876fc1@redhat.com> On 6/27/19 12:13 PM, Ao Qi wrote: > Yes. You are right. Updated: http://cr.openjdk.java.net/~aoqi/8226871/webrev.01/ Thanks. Looks good and trivial. -Aleksey From aoqi at loongson.cn Thu Jun 27 11:04:23 2019 From: aoqi at loongson.cn (Ao Qi) Date: Thu, 27 Jun 2019 19:04:23 +0800 Subject: RFR: JDK-8226878: zero crashes after JDK-8191278 Message-ID: Hi, On zero, StubRoutines::unsafe_arraycopy() may return ShouldNotCallThisStub() but not NULL. Is it ok to use Copy::conjoint_memory_atomic instead of StubRoutines::UnsafeArrayCopy_stub()(src, dst, sz) on zero? JBS: https://bugs.openjdk.java.net/browse/JDK-8226878 Fix: diff --git a/src/hotspot/share/prims/unsafe.cpp b/src/hotspot/share/prims/unsafe.cpp --- a/src/hotspot/share/prims/unsafe.cpp +++ b/src/hotspot/share/prims/unsafe.cpp @@ -401,7 +401,7 @@ void* dst = index_oop_from_field_offset_long(dstp, dstOffset); { GuardUnsafeAccess guard(thread); - if (StubRoutines::unsafe_arraycopy() != NULL) { + if (StubRoutines::unsafe_arraycopy() != NULL ZERO_ONLY(&& StubRoutines::unsafe_arraycopy() != ShouldNotCallThisStub())) { StubRoutines::UnsafeArrayCopy_stub()(src, dst, sz); } else { Copy::conjoint_memory_atomic(src, dst, sz); Thanks, Ao Qi From aoqi at loongson.cn Thu Jun 27 11:08:07 2019 From: aoqi at loongson.cn (Ao Qi) Date: Thu, 27 Jun 2019 19:08:07 +0800 Subject: RFR(trivial): JDK-8226871: invalid use of incomplete type class MacroAssembler when building minimal after JDK-8191278 In-Reply-To: <80137b36-c6be-2f09-abfd-8efb6b876fc1@redhat.com> References: <75ea09f6-35ed-df38-acd6-ba5016bef26b@redhat.com> <80137b36-c6be-2f09-abfd-8efb6b876fc1@redhat.com> Message-ID: On Thu, Jun 27, 2019 at 6:20 PM Aleksey Shipilev wrote: > > On 6/27/19 12:13 PM, Ao Qi wrote: > > Yes. You are right. Updated: http://cr.openjdk.java.net/~aoqi/8226871/webrev.01/ > > Thanks. Looks good and trivial. Thanks! Could you help to sponsor this? > > -Aleksey > From shade at redhat.com Thu Jun 27 11:19:34 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 27 Jun 2019 13:19:34 +0200 Subject: RFR(trivial): JDK-8226871: invalid use of incomplete type class MacroAssembler when building minimal after JDK-8191278 In-Reply-To: References: <75ea09f6-35ed-df38-acd6-ba5016bef26b@redhat.com> <80137b36-c6be-2f09-abfd-8efb6b876fc1@redhat.com> Message-ID: <0cedcd9f-f096-8b33-abdf-3c6cd404948d@redhat.com> On 6/27/19 1:08 PM, Ao Qi wrote: > On Thu, Jun 27, 2019 at 6:20 PM Aleksey Shipilev wrote: >> On 6/27/19 12:13 PM, Ao Qi wrote: >>> Yes. You are right. Updated: http://cr.openjdk.java.net/~aoqi/8226871/webrev.01/ >> >> Thanks. Looks good and trivial. > > Thanks! Could you help to sponsor this? Sure, here you go: http://hg.openjdk.java.net/jdk/jdk/rev/91b38bfb9079 -Aleksey From aoqi at loongson.cn Thu Jun 27 11:30:08 2019 From: aoqi at loongson.cn (Ao Qi) Date: Thu, 27 Jun 2019 19:30:08 +0800 Subject: RFR(trivial): JDK-8226871: invalid use of incomplete type class MacroAssembler when building minimal after JDK-8191278 In-Reply-To: <0cedcd9f-f096-8b33-abdf-3c6cd404948d@redhat.com> References: <75ea09f6-35ed-df38-acd6-ba5016bef26b@redhat.com> <80137b36-c6be-2f09-abfd-8efb6b876fc1@redhat.com> <0cedcd9f-f096-8b33-abdf-3c6cd404948d@redhat.com> Message-ID: On Thu, Jun 27, 2019 at 7:19 PM Aleksey Shipilev wrote: > > On 6/27/19 1:08 PM, Ao Qi wrote: > > On Thu, Jun 27, 2019 at 6:20 PM Aleksey Shipilev wrote: > >> On 6/27/19 12:13 PM, Ao Qi wrote: > >>> Yes. You are right. Updated: http://cr.openjdk.java.net/~aoqi/8226871/webrev.01/ > >> > >> Thanks. Looks good and trivial. > > > > Thanks! Could you help to sponsor this? > > Sure, here you go: > http://hg.openjdk.java.net/jdk/jdk/rev/91b38bfb9079 Aleksey, thanks again! > > -Aleksey > From shade at redhat.com Thu Jun 27 11:38:16 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 27 Jun 2019 13:38:16 +0200 Subject: RFR: JDK-8226878: zero crashes after JDK-8191278 In-Reply-To: References: Message-ID: <51ec95c9-c9d5-75a7-6f48-462230536c30@redhat.com> On 6/27/19 1:04 PM, Ao Qi wrote: > Hi, > > On zero, StubRoutines::unsafe_arraycopy() may return > ShouldNotCallThisStub() but not NULL. Is it ok to use > Copy::conjoint_memory_atomic instead of > StubRoutines::UnsafeArrayCopy_stub()(src, dst, sz) on zero? > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8226878 > > Fix: > diff --git a/src/hotspot/share/prims/unsafe.cpp > b/src/hotspot/share/prims/unsafe.cpp > --- a/src/hotspot/share/prims/unsafe.cpp > +++ b/src/hotspot/share/prims/unsafe.cpp > @@ -401,7 +401,7 @@ > void* dst = index_oop_from_field_offset_long(dstp, dstOffset); > { > GuardUnsafeAccess guard(thread); > - if (StubRoutines::unsafe_arraycopy() != NULL) { > + if (StubRoutines::unsafe_arraycopy() != NULL ZERO_ONLY(&& > StubRoutines::unsafe_arraycopy() != ShouldNotCallThisStub())) { > StubRoutines::UnsafeArrayCopy_stub()(src, dst, sz); > } else { > Copy::conjoint_memory_atomic(src, dst, sz); Hold on. I think stubGenerator_zero.cpp should just return NULL when stub is not generated. It looks like a Zero-specific problem to return "fake" stubs when they are not actually generated. Like this: diff -r 91b38bfb9079 src/hotspot/cpu/zero/stubGenerator_zero.cpp --- a/src/hotspot/cpu/zero/stubGenerator_zero.cpp Thu Jun 27 18:00:54 2019 +0800 +++ b/src/hotspot/cpu/zero/stubGenerator_zero.cpp Thu Jun 27 13:37:47 2019 +0200 @@ -157,7 +157,9 @@ StubRoutines::_checkcast_arraycopy = ShouldNotCallThisStub(); - StubRoutines::_unsafe_arraycopy = ShouldNotCallThisStub(); StubRoutines::_generic_arraycopy = ShouldNotCallThisStub(); + // Shared code tests for "NULL" to discover the stub is not generated. + StubRoutines::_unsafe_arraycopy = NULL; + // We don't generate specialized code for HeapWord-aligned source // arrays, so just use the code we've already generated -- Thanks, -Aleksey From christoph.langer at sap.com Thu Jun 27 14:59:06 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 27 Jun 2019 14:59:06 +0000 Subject: RFR: 8226238: Improve error output and fix elf issues in os::dll_load In-Reply-To: References: Message-ID: Hi Matthias, your change looks good overall. I only have a few style nits: src/hotspot/os/linux/os_linux.cpp, line 1751 (new): Can you convert unsigned char current_endianness = ELFDATA2MSB; // BE #if defined(VM_LITTLE_ENDIAN) current_endianness = ELFDATA2LSB; // LE #endif to #if defined(VM_LITTLE_ENDIAN) unsigned char current_endianness = ELFDATA2LSB; // LE #else unsigned char current_endianness = ELFDATA2MSB; // BE #endif And the same in line 1611 of src/hotspot/os/solaris/os_solaris.cpp. src/hotspot/os/linux/os_linux.cpp, line 1802: you could fix the indentation of ELFDATA2LSB for EM_ARM same for line 1580 of src/hotspot/os/solaris/os_solaris.cpp. Best regards Christoph > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Dienstag, 25. Juni 2019 09:43 > To: 'hotspot-dev at openjdk.java.net' > Subject: RE: RFR: 8226238: Improve error output and fix elf issues in > os::dll_load > > Ping ... > > Best regards, Matthias > > > From: Baesken, Matthias > Sent: Dienstag, 18. Juni 2019 13:24 > To: 'hotspot-dev at openjdk.java.net' > Subject: RE: RFR: 8226238: Improve error output and fix elf issues in > os::dll_load > > Hello, I noticed the solaris os::dll_load coding has similar issues. > New webrev ( handling linux + solaris ) : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8226238.3/ > > Best regards, Matthias > > > > Hello, > please review this change to linux os::dll_load . > os::dll_load includes some coding to report error details in cases where the > lib loading fails . > For this , we ELF header of the shared-object we failed to load is evaluated > . > > However the code currently has some issues . > - it misses to convert endianness of elf_head.e_machine (ELF data entry) in > case the platform we run on, and the lib we try to load have different > endianness > - the error message could show the real elf architecture name in mismatch > cases (but does not) > > > Adjusted error message looks like this : > example from renaissance db-shootout benchmark that runs on linuxs390x > and attempts to load an x86_64 JNI lib "by mistake" > message without the change : > .... ELF file data encoding not big-endian (Possible cause: endianness > mismatch)] > > > with change : > .... ELF file data encoding not big-endian (Possible cause: can't load AMD 64 > .so on a IBM System/390 platform) > > > bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8226238 > http://cr.openjdk.java.net/~mbaesken/webrevs/8226238.2/ From jamsheed.c.m at oracle.com Thu Jun 27 18:03:26 2019 From: jamsheed.c.m at oracle.com (Jamsheed) Date: Thu, 27 Jun 2019 23:33:26 +0530 Subject: RFR: JDK-8226878: zero crashes after JDK-8191278 In-Reply-To: <51ec95c9-c9d5-75a7-6f48-462230536c30@redhat.com> References: <51ec95c9-c9d5-75a7-6f48-462230536c30@redhat.com> Message-ID: Hi Ao Qi, On 27/06/19 5:08 PM, Aleksey Shipilev wrote: > On 6/27/19 1:04 PM, Ao Qi wrote: >> Hi, >> >> On zero, StubRoutines::unsafe_arraycopy() may return >> ShouldNotCallThisStub() but not NULL. Is it ok to use >> Copy::conjoint_memory_atomic instead of >> StubRoutines::UnsafeArrayCopy_stub()(src, dst, sz) on zero? Yes. >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8226878 >> >> Fix: >> diff --git a/src/hotspot/share/prims/unsafe.cpp >> b/src/hotspot/share/prims/unsafe.cpp >> --- a/src/hotspot/share/prims/unsafe.cpp >> +++ b/src/hotspot/share/prims/unsafe.cpp >> @@ -401,7 +401,7 @@ >> void* dst = index_oop_from_field_offset_long(dstp, dstOffset); >> { >> GuardUnsafeAccess guard(thread); >> - if (StubRoutines::unsafe_arraycopy() != NULL) { >> + if (StubRoutines::unsafe_arraycopy() != NULL ZERO_ONLY(&& >> StubRoutines::unsafe_arraycopy() != ShouldNotCallThisStub())) { >> StubRoutines::UnsafeArrayCopy_stub()(src, dst, sz); >> } else { >> Copy::conjoint_memory_atomic(src, dst, sz); > Hold on. I think stubGenerator_zero.cpp should just return NULL when stub is not generated. It looks > like a Zero-specific problem to return "fake" stubs when they are not actually generated. Like this: > > diff -r 91b38bfb9079 src/hotspot/cpu/zero/stubGenerator_zero.cpp > --- a/src/hotspot/cpu/zero/stubGenerator_zero.cpp Thu Jun 27 18:00:54 2019 +0800 > +++ b/src/hotspot/cpu/zero/stubGenerator_zero.cpp Thu Jun 27 13:37:47 2019 +0200 > @@ -157,7 +157,9 @@ > > StubRoutines::_checkcast_arraycopy = ShouldNotCallThisStub(); > - StubRoutines::_unsafe_arraycopy = ShouldNotCallThisStub(); > StubRoutines::_generic_arraycopy = ShouldNotCallThisStub(); > > + // Shared code tests for "NULL" to discover the stub is not generated. > + StubRoutines::_unsafe_arraycopy = NULL; > + > // We don't generate specialized code for HeapWord-aligned source > // arrays, so just use the code we've already generated > i too think making changes here is more clean. Thanks and Best regards, Jamsheed From christian.tornqvist at oracle.com Thu Jun 27 19:19:27 2019 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 27 Jun 2019 12:19:27 -0700 Subject: [13]RFR: 8226899: Problemlist compiler/rtm tests Message-ID: Please review this small change that adds a few of the compiler/rtm tests to the ProblemList, these tests are consistently failing on Intel Skylake CPUs. Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8226899/webrev.00/ Bug for the failing tests: https://bugs.openjdk.java.net/browse/JDK-8183263 Thanks, Christian From aoqi at loongson.cn Fri Jun 28 00:56:57 2019 From: aoqi at loongson.cn (Ao Qi) Date: Fri, 28 Jun 2019 08:56:57 +0800 Subject: RFR: JDK-8226878: zero crashes after JDK-8191278 In-Reply-To: <51ec95c9-c9d5-75a7-6f48-462230536c30@redhat.com> References: <51ec95c9-c9d5-75a7-6f48-462230536c30@redhat.com> Message-ID: On Thu, Jun 27, 2019 at 7:38 PM Aleksey Shipilev wrote: > > On 6/27/19 1:04 PM, Ao Qi wrote: > > Hi, > > > > On zero, StubRoutines::unsafe_arraycopy() may return > > ShouldNotCallThisStub() but not NULL. Is it ok to use > > Copy::conjoint_memory_atomic instead of > > StubRoutines::UnsafeArrayCopy_stub()(src, dst, sz) on zero? > > > > JBS: > > https://bugs.openjdk.java.net/browse/JDK-8226878 > > > > Fix: > > diff --git a/src/hotspot/share/prims/unsafe.cpp > > b/src/hotspot/share/prims/unsafe.cpp > > --- a/src/hotspot/share/prims/unsafe.cpp > > +++ b/src/hotspot/share/prims/unsafe.cpp > > @@ -401,7 +401,7 @@ > > void* dst = index_oop_from_field_offset_long(dstp, dstOffset); > > { > > GuardUnsafeAccess guard(thread); > > - if (StubRoutines::unsafe_arraycopy() != NULL) { > > + if (StubRoutines::unsafe_arraycopy() != NULL ZERO_ONLY(&& > > StubRoutines::unsafe_arraycopy() != ShouldNotCallThisStub())) { > > StubRoutines::UnsafeArrayCopy_stub()(src, dst, sz); > > } else { > > Copy::conjoint_memory_atomic(src, dst, sz); > Hold on. I think stubGenerator_zero.cpp should just return NULL when stub is not generated. It looks > like a Zero-specific problem to return "fake" stubs when they are not actually generated. Like this: > > diff -r 91b38bfb9079 src/hotspot/cpu/zero/stubGenerator_zero.cpp > --- a/src/hotspot/cpu/zero/stubGenerator_zero.cpp Thu Jun 27 18:00:54 2019 +0800 > +++ b/src/hotspot/cpu/zero/stubGenerator_zero.cpp Thu Jun 27 13:37:47 2019 +0200 > @@ -157,7 +157,9 @@ > > StubRoutines::_checkcast_arraycopy = ShouldNotCallThisStub(); > - StubRoutines::_unsafe_arraycopy = ShouldNotCallThisStub(); > StubRoutines::_generic_arraycopy = ShouldNotCallThisStub(); > > + // Shared code tests for "NULL" to discover the stub is not generated. > + StubRoutines::_unsafe_arraycopy = NULL; > + > // We don't generate specialized code for HeapWord-aligned source > // arrays, so just use the code we've already generated > I'm fine with this fix. Thanks, Ao Qi > -- > Thanks, > -Aleksey > From matthias.baesken at sap.com Fri Jun 28 07:06:29 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 28 Jun 2019 07:06:29 +0000 Subject: RFR: 8226238: Improve error output and fix elf issues in os::dll_load In-Reply-To: References: Message-ID: Hi Christoph, thanks for looking into it. I did the changes you mentioned, here is my new webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8226238.4/ Would be good to get a second review . Thanks and best regards, Matthias > -----Original Message----- > From: Langer, Christoph > Sent: Donnerstag, 27. Juni 2019 16:59 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Subject: RE: RFR: 8226238: Improve error output and fix elf issues in > os::dll_load > > Hi Matthias, > > your change looks good overall. > > I only have a few style nits: > > src/hotspot/os/linux/os_linux.cpp, line 1751 (new): > > Can you convert > > unsigned char current_endianness = ELFDATA2MSB; // BE > #if defined(VM_LITTLE_ENDIAN) > current_endianness = ELFDATA2LSB; // LE > #endif > > to > > #if defined(VM_LITTLE_ENDIAN) > unsigned char current_endianness = ELFDATA2LSB; // LE > #else > unsigned char current_endianness = ELFDATA2MSB; // BE > #endif > > And the same in line 1611 of src/hotspot/os/solaris/os_solaris.cpp. > > src/hotspot/os/linux/os_linux.cpp, line 1802: you could fix the indentation of > ELFDATA2LSB for EM_ARM > same for line 1580 of src/hotspot/os/solaris/os_solaris.cpp. > From matthias.baesken at sap.com Fri Jun 28 11:43:07 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 28 Jun 2019 11:43:07 +0000 Subject: RFR [XS] : 8226943: compile error in libfollowref003.cpp with XCode 10.2 on macosx Message-ID: Hello please review this small fix for a compile issue on OSX . Today I compiled jdk/jdk on a machine with XCode 10.2 . It worked pretty well . However this small issue showed up . In file included from /open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/libfollowref003.cpp:33: /open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/followref003.cpp:813:14: error: comparison of two values with different enumeration types in switch statement ('jvmtiHeapReferenceKind' and 'jvmtiObjectReferenceKind') [-Werror,-Wenum-compare-switch] And here XCode 10 is correct , JVMTI_REFERENCE_ARRAY_ELEMENT is from a different enumeration type and should be replaced with the value from the correct enumeration type . Bug / webrev : https://bugs.openjdk.java.net/browse/JDK-8226943 http://cr.openjdk.java.net/~mbaesken/webrevs/8226943.0/ Thanks, Matthias From shade at redhat.com Fri Jun 28 13:30:06 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 28 Jun 2019 15:30:06 +0200 Subject: RFR: JDK-8226878: zero crashes after JDK-8191278 In-Reply-To: References: <51ec95c9-c9d5-75a7-6f48-462230536c30@redhat.com> Message-ID: <587b3c54-6bec-d667-c54b-a310d4fd932a@redhat.com> On 6/28/19 2:56 AM, Ao Qi wrote: >> Hold on. I think stubGenerator_zero.cpp should just return NULL when stub is not generated. It looks >> like a Zero-specific problem to return "fake" stubs when they are not actually generated. Like this: >> >> diff -r 91b38bfb9079 src/hotspot/cpu/zero/stubGenerator_zero.cpp >> --- a/src/hotspot/cpu/zero/stubGenerator_zero.cpp Thu Jun 27 18:00:54 2019 +0800 >> +++ b/src/hotspot/cpu/zero/stubGenerator_zero.cpp Thu Jun 27 13:37:47 2019 +0200 >> @@ -157,7 +157,9 @@ >> >> StubRoutines::_checkcast_arraycopy = ShouldNotCallThisStub(); >> - StubRoutines::_unsafe_arraycopy = ShouldNotCallThisStub(); >> StubRoutines::_generic_arraycopy = ShouldNotCallThisStub(); >> >> + // Shared code tests for "NULL" to discover the stub is not generated. >> + StubRoutines::_unsafe_arraycopy = NULL; >> + >> // We don't generate specialized code for HeapWord-aligned source >> // arrays, so just use the code we've already generated >> > > I'm fine with this fix. Tad confused here. Are you preparing the updated RFR, or should I? -- Thanks, -Aleksey From aoqi at loongson.cn Fri Jun 28 15:06:09 2019 From: aoqi at loongson.cn (Ao Qi) Date: Fri, 28 Jun 2019 23:06:09 +0800 Subject: RFR: JDK-8226878: zero crashes after JDK-8191278 In-Reply-To: <587b3c54-6bec-d667-c54b-a310d4fd932a@redhat.com> References: <51ec95c9-c9d5-75a7-6f48-462230536c30@redhat.com> <587b3c54-6bec-d667-c54b-a310d4fd932a@redhat.com> Message-ID: On Fri, Jun 28, 2019 at 9:30 PM Aleksey Shipilev wrote: > > On 6/28/19 2:56 AM, Ao Qi wrote: > >> Hold on. I think stubGenerator_zero.cpp should just return NULL when stub is not generated. It looks > >> like a Zero-specific problem to return "fake" stubs when they are not actually generated. Like this: > >> > >> diff -r 91b38bfb9079 src/hotspot/cpu/zero/stubGenerator_zero.cpp > >> --- a/src/hotspot/cpu/zero/stubGenerator_zero.cpp Thu Jun 27 18:00:54 2019 +0800 > >> +++ b/src/hotspot/cpu/zero/stubGenerator_zero.cpp Thu Jun 27 13:37:47 2019 +0200 > >> @@ -157,7 +157,9 @@ > >> > >> StubRoutines::_checkcast_arraycopy = ShouldNotCallThisStub(); > >> - StubRoutines::_unsafe_arraycopy = ShouldNotCallThisStub(); > >> StubRoutines::_generic_arraycopy = ShouldNotCallThisStub(); > >> > >> + // Shared code tests for "NULL" to discover the stub is not generated. > >> + StubRoutines::_unsafe_arraycopy = NULL; > >> + > >> // We don't generate specialized code for HeapWord-aligned source > >> // arrays, so just use the code we've already generated > >> > > > > I'm fine with this fix. > > Tad confused here. Are you preparing the updated RFR, or should I? Updated: http://cr.openjdk.java.net/~aoqi/8226878/webrev.01/ I changed nothing, except copyright year. > > -- > Thanks, > -Aleksey > From shade at redhat.com Fri Jun 28 15:11:14 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 28 Jun 2019 17:11:14 +0200 Subject: RFR: JDK-8226878: zero crashes after JDK-8191278 In-Reply-To: References: <51ec95c9-c9d5-75a7-6f48-462230536c30@redhat.com> <587b3c54-6bec-d667-c54b-a310d4fd932a@redhat.com> Message-ID: <98aa243a-17b9-de90-d73d-c7a557dd574b@redhat.com> On 6/28/19 5:06 PM, Ao Qi wrote: > Updated: http://cr.openjdk.java.net/~aoqi/8226878/webrev.01/ Nice. Looks good! You need a sponsor, right? -Aleksey From aoqi at loongson.cn Fri Jun 28 15:19:31 2019 From: aoqi at loongson.cn (Ao Qi) Date: Fri, 28 Jun 2019 23:19:31 +0800 Subject: RFR: JDK-8226878: zero crashes after JDK-8191278 In-Reply-To: <98aa243a-17b9-de90-d73d-c7a557dd574b@redhat.com> References: <51ec95c9-c9d5-75a7-6f48-462230536c30@redhat.com> <587b3c54-6bec-d667-c54b-a310d4fd932a@redhat.com> <98aa243a-17b9-de90-d73d-c7a557dd574b@redhat.com> Message-ID: On Fri, Jun 28, 2019 at 11:11 PM Aleksey Shipilev wrote: > > On 6/28/19 5:06 PM, Ao Qi wrote: > > Updated: http://cr.openjdk.java.net/~aoqi/8226878/webrev.01/ > > Nice. Looks good! Thanks! > > You need a sponsor, right? Yes. > > -Aleksey > From shade at redhat.com Fri Jun 28 16:04:13 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 28 Jun 2019 18:04:13 +0200 Subject: RFR: JDK-8226878: zero crashes after JDK-8191278 In-Reply-To: References: <51ec95c9-c9d5-75a7-6f48-462230536c30@redhat.com> <587b3c54-6bec-d667-c54b-a310d4fd932a@redhat.com> <98aa243a-17b9-de90-d73d-c7a557dd574b@redhat.com> Message-ID: <17809c86-0275-deb4-ea43-cb85ac228195@redhat.com> On 6/28/19 5:19 PM, Ao Qi wrote: > On Fri, Jun 28, 2019 at 11:11 PM Aleksey Shipilev wrote: >> You need a sponsor, right? > > Yes. There you go: http://hg.openjdk.java.net/jdk/jdk/rev/52ef2c940423 -- Thanks, -Aleksey From aoqi at loongson.cn Fri Jun 28 16:19:13 2019 From: aoqi at loongson.cn (Ao Qi) Date: Sat, 29 Jun 2019 00:19:13 +0800 Subject: RFR: JDK-8226878: zero crashes after JDK-8191278 In-Reply-To: <17809c86-0275-deb4-ea43-cb85ac228195@redhat.com> References: <51ec95c9-c9d5-75a7-6f48-462230536c30@redhat.com> <587b3c54-6bec-d667-c54b-a310d4fd932a@redhat.com> <98aa243a-17b9-de90-d73d-c7a557dd574b@redhat.com> <17809c86-0275-deb4-ea43-cb85ac228195@redhat.com> Message-ID: On Sat, Jun 29, 2019 at 12:04 AM Aleksey Shipilev wrote: > > There you go: > http://hg.openjdk.java.net/jdk/jdk/rev/52ef2c940423 Thank you very much! From mikhailo.seledtsov at oracle.com Fri Jun 28 17:40:55 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Fri, 28 Jun 2019 10:40:55 -0700 Subject: [13]RFR: 8226899: Problemlist compiler/rtm tests In-Reply-To: References: Message-ID: Looks good to me, Misha On 6/27/19 12:19 PM, Christian Tornqvist wrote: > Please review this small change that adds a few of the compiler/rtm tests to the ProblemList, these tests are consistently failing on Intel Skylake CPUs. > > Webrev: > http://cr.openjdk.java.net/~ctornqvi/webrev/8226899/webrev.00/ > > Bug for the failing tests: > https://bugs.openjdk.java.net/browse/JDK-8183263 > > Thanks, > Christian From igor.ignatyev at oracle.com Fri Jun 28 17:51:06 2019 From: igor.ignatyev at oracle.com (Igor Ignatev) Date: Fri, 28 Jun 2019 10:51:06 -0700 Subject: [13]RFR: 8226899: Problemlist compiler/rtm tests In-Reply-To: References: Message-ID: <436AEDD8-2F12-4DD0-9C6B-BF7147381153@oracle.com> LGTM, ? Igor > On Jun 27, 2019, at 12:19 PM, Christian Tornqvist wrote: > > Please review this small change that adds a few of the compiler/rtm tests to the ProblemList, these tests are consistently failing on Intel Skylake CPUs. > > Webrev: > http://cr.openjdk.java.net/~ctornqvi/webrev/8226899/webrev.00/ > > Bug for the failing tests: > https://bugs.openjdk.java.net/browse/JDK-8183263 > > Thanks, > Christian From david.holmes at oracle.com Fri Jun 28 19:04:10 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 28 Jun 2019 15:04:10 -0400 Subject: RFR [XS] : 8226943: compile error in libfollowref003.cpp with XCode 10.2 on macosx In-Reply-To: References: Message-ID: <770df6b7-7588-1030-f13e-e1500a63231e@oracle.com> Hi Matthias, Dropped build-dev and added serviceability-dev as this is a servicability test. On 28/06/2019 7:43 am, Baesken, Matthias wrote: > Hello please review this small fix for a compile issue on OSX . > Today I compiled jdk/jdk on a machine with XCode 10.2 . It worked pretty well . > However this small issue showed up . > > > In file included from /open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/libfollowref003.cpp:33: > /open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/followref003.cpp:813:14: error: > comparison of two values with different enumeration types in switch statement ('jvmtiHeapReferenceKind' and 'jvmtiObjectReferenceKind') [-Werror,-Wenum-compare-switch] > > > And here XCode 10 is correct , JVMTI_REFERENCE_ARRAY_ELEMENT is from a different enumeration type and should be replaced with the value from the correct enumeration type . > > Bug / webrev : > > https://bugs.openjdk.java.net/browse/JDK-8226943 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8226943.0/ The fix seems reasonable but the issue indicates a further problem with the test. If it expected JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT but was checking for JVMTI_REFERENCE_ARRAY_ELEMENT then we should have hit the default clause and failed the test. That suggests the test doesn't actually expect JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT in the first place. Cheers, David > > Thanks, Matthias > From matthias.baesken at sap.com Fri Jun 28 19:41:56 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 28 Jun 2019 19:41:56 +0000 Subject: RFR [XS] : 8226943: compile error in libfollowref003.cpp with XCode 10.2 on macosx In-Reply-To: <4bddba5d-cf94-4c38-48f6-835d76bfdea6@oracle.com> References: <770df6b7-7588-1030-f13e-e1500a63231e@oracle.com>, <4bddba5d-cf94-4c38-48f6-835d76bfdea6@oracle.com> Message-ID: <542721AE-5E8E-476A-B7AE-945809D3A09A@sap.com> Hi Gary and David, yes it is value 3 in both cases, I noticed that in the jvmti XML . Best regards, Matthias Von meinem iPhone gesendet > Am 28.06.2019 um 21:17 schrieb "gary.adams at oracle.com" : > > I believe you will find in the generate jvmti.h header file > that both enumerations had assigned value of 3. > That could explain why a less type strict version of the > compiler would not have complained. > >> On 6/28/19 3:04 PM, David Holmes wrote: >> Hi Matthias, >> >> Dropped build-dev and added serviceability-dev as this is a servicability test. >> >>> On 28/06/2019 7:43 am, Baesken, Matthias wrote: >>> Hello please review this small fix for a compile issue on OSX . >>> Today I compiled jdk/jdk on a machine with XCode 10.2 . It worked pretty well . >>> However this small issue showed up . >>> >>> >>> In file included from /open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/libfollowref003.cpp:33: >>> /open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/followref003.cpp:813:14: error: >>> comparison of two values with different enumeration types in switch statement ('jvmtiHeapReferenceKind' and 'jvmtiObjectReferenceKind') [-Werror,-Wenum-compare-switch] >>> >>> >>> And here XCode 10 is correct , JVMTI_REFERENCE_ARRAY_ELEMENT is from a different enumeration type and should be replaced with the value from the correct enumeration type . >>> >>> Bug / webrev : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8226943 >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8226943.0/ >> >> The fix seems reasonable but the issue indicates a further problem with the test. If it expected JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT but was checking for JVMTI_REFERENCE_ARRAY_ELEMENT then we should have hit the default clause and failed the test. That suggests the test doesn't actually expect JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT in the first place. >> >> Cheers, >> David >> >>> >>> Thanks, Matthias >>> > From gromero at linux.vnet.ibm.com Fri Jun 28 20:26:42 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 28 Jun 2019 17:26:42 -0300 Subject: [13]RFR: 8226899: Problemlist compiler/rtm tests In-Reply-To: References: Message-ID: <06388987-062d-c788-0dea-45aa43d7b2e3@linux.vnet.ibm.com> Hi Christian, On 06/27/2019 04:19 PM, Christian Tornqvist wrote: > Please review this small change that adds a few of the compiler/rtm tests to the ProblemList, these tests are consistently failing on Intel Skylake CPUs. > > Webrev: > http://cr.openjdk.java.net/~ctornqvi/webrev/8226899/webrev.00/ > > Bug for the failing tests: > https://bugs.openjdk.java.net/browse/JDK-8183263 Are you sure these tests are currently failing on Skylake? For changes [1, 2], I recently tested the RTM tests and they were passing consistently both on PPC64 and x86_64. Would bugs JDK-8183263 and JDK-8180723 be outdated? I've just retested it on my Skylake and they still look ok too (Please see the results below with some information about my x86_64 CPU). Thank you. Best regards, Gustavo [1] https://bugs.openjdk.java.net/browse/JDK-8223660 [2] https://bugs.openjdk.java.net/browse/JDK-8225663 gromero at moog:~/hg/jdk/jdk$ make test JTREG="OPTIONS=-nativepath:/home/gromero/hg/jdk/jdk/build/linux-x86_64-server-release/support/test/hotspot/jtreg/native/lib" TEST=./test/hotspot/jtreg/compiler/rtm Building target 'test' in configuration 'linux-x86_64-server-release' Skip building of Graal unit tests because 3rd party libraries directory is not specified Skip building of Graal unit tests because 3rd party libraries directory is not specified Running tests using JTREG control variable 'OPTIONS=-nativepath:/home/gromero/hg/jdk/jdk/build/linux-x86_64-server-release/support/test/hotspot/jtreg/native/lib' Test selection './test/hotspot/jtreg/compiler/rtm', will run: * jtreg:./test/hotspot/jtreg/compiler/rtm Running test 'jtreg:./test/hotspot/jtreg/compiler/rtm' Passed: compiler/rtm/cli/TestRTMLockingCalculationDelayOption.java Passed: compiler/rtm/cli/TestRTMLockingThresholdOption.java Passed: compiler/rtm/cli/TestRTMAbortThresholdOption.java Passed: compiler/rtm/cli/TestRTMRetryCountOption.java Passed: compiler/rtm/cli/TestRTMSpinLoopCountOption.java Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java Passed: compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java Passed: compiler/rtm/cli/TestUseRTMXendForLockBusyOption.java Passed: compiler/rtm/locking/TestRTMAbortRatio.java Passed: compiler/rtm/locking/TestRTMAbortThreshold.java Passed: compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnSupportedConfig.java Passed: compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java Passed: compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java Passed: compiler/rtm/locking/TestRTMLockingThreshold.java Passed: compiler/rtm/locking/TestRTMLockingCalculationDelay.java Passed: compiler/rtm/locking/TestUseRTMAfterLockInflation.java Passed: compiler/rtm/locking/TestRTMTotalCountIncrRate.java Passed: compiler/rtm/locking/TestUseRTMDeopt.java Passed: compiler/rtm/locking/TestUseRTMForInflatedLocks.java Passed: compiler/rtm/locking/TestUseRTMForStackLocks.java Passed: compiler/rtm/method_options/TestNoRTMLockElidingOption.java Passed: compiler/rtm/method_options/TestUseRTMLockElidingOption.java Passed: compiler/rtm/locking/TestRTMSpinLoopCount.java Passed: compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java Passed: compiler/rtm/locking/TestRTMRetryCount.java Passed: compiler/rtm/locking/TestUseRTMXendForLockBusy.java Test results: passed: 30 Report written to /home/gromero/hg/jdk/jdk/build/linux-x86_64-server-release/test-results/jtreg_test_hotspot_jtreg_compiler_rtm/html/report.html Results written to /home/gromero/hg/jdk/jdk/build/linux-x86_64-server-release/test-support/jtreg_test_hotspot_jtreg_compiler_rtm Finished running test 'jtreg:./test/hotspot/jtreg/compiler/rtm' Test report is stored in build/linux-x86_64-server-release/test-results/jtreg_test_hotspot_jtreg_compiler_rtm ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:./test/hotspot/jtreg/compiler/rtm 30 30 0 0 ============================== TEST SUCCESS Finished building target 'test' in configuration 'linux-x86_64-server-release' gromero at moog:~/hg/jdk/jdk$ hg log -vr. changeset: 55524:b279ae9843b8 tag: tip user: ccheung date: Fri Jun 28 09:49:10 2019 -0700 files: src/hotspot/os/aix/os_aix.inline.hpp src/hotspot/os/bsd/os_bsd.inline.hpp src/hotspot/os/linux/os_linux.inline.hpp src/hotspot/os/posix/os_posix.cpp src/hotspot/os/solaris/os_solaris.inline.hpp src/hotspot/os/windows/os_windows.cpp src/hotspot/os/windows/os_windows.inline.hpp src/hotspot/share/classfile/classLoader.cpp src/hotspot/share/classfile/classLoader.hpp src/hotspot/share/classfile/classLoaderExt.cpp src/hotspot/share/classfile/sharedPathsMiscInfo.cpp src/hotspot/share/memory/filemap.cpp src/hotspot/share/memory/filemap.hpp src/hotspot/share/runtime/arguments.cpp src/hotspot/share/runtime/os.hpp test/hotspot/jtreg/TEST.groups test/hotspot/jtreg/runtime/appcds/AppCDSOptions.java test/hotspot/jtreg/runtime/appcds/AppendClasspath.java test/hotspot/jtreg/runtime/appcds/BootClassPathMismatch.java test/hotspot/jtreg/runtime/appcds/PrintSharedArchiveAndExit.java test/hotspot/jtreg/runtime/appcds/RelativePath.java test/hotspot/jtreg/runtime/appcds/TestCommon.java test/hotspot/jtreg/runtime/appcds/dynamicArchive/DynamicArchiveTestBase.java test/hotspot/jtreg/runtime/appcds/dynamicArchive/RelativePath.java description: 8211723: AppCDS: referring to a jar file in any way other than exactly how it was done during dumping doesn't work Summary: Replaced os::file_name_strncmp() with os::same_files(). Reviewed-by: iklam, jiangli gromero at moog:~/hg/jdk/jdk$ hg path default = http://hg.openjdk.java.net/jdk/jdk/ gromero at moog:~/hg/jdk/jdk$ uname -a Linux moog 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24 10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux gromero at moog:~/hg/jdk/jdk$ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 94 Model name: Intel(R) Xeon(R) CPU E3-1280 v5 @ 3.70GHz Stepping: 3 CPU MHz: 900.123 CPU max MHz: 4000.0000 CPU min MHz: 800.0000 BogoMIPS: 7392.00 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 8192K NUMA node0 CPU(s): 0-7 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d From serguei.spitsyn at oracle.com Sat Jun 29 02:05:43 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 28 Jun 2019 19:05:43 -0700 Subject: RFR [XS] : 8226943: compile error in libfollowref003.cpp with XCode 10.2 on macosx In-Reply-To: <770df6b7-7588-1030-f13e-e1500a63231e@oracle.com> References: <770df6b7-7588-1030-f13e-e1500a63231e@oracle.com> Message-ID: Hi Matthias, The fix is good. It worked before because both JVMTI_REFERENCE_ARRAY_ELEMENT and JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT have the same value 3 as Gary noticed. I'd suggest to fix it in 13 as it is the test fix. I've added labels 'testbug' and 'noreg-self'. Thanks, Serguei On 6/28/19 12:04 PM, David Holmes wrote: > Hi Matthias, > > Dropped build-dev and added serviceability-dev as this is a > servicability test. > > On 28/06/2019 7:43 am, Baesken, Matthias wrote: >> Hello please review this? small fix for a compile issue? on OSX . >> Today I? compiled?? jdk/jdk?? on a machine? with?? XCode 10.2? . It >> worked pretty well . >> However this small issue showed up . >> >> >> In file included from >> /open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/libfollowref003.cpp:33: >> /open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/followref003.cpp:813:14: >> error: >> comparison of two values with different enumeration types in switch >> statement ('jvmtiHeapReferenceKind' and 'jvmtiObjectReferenceKind') >> [-Werror,-Wenum-compare-switch] >> >> >> And here XCode 10 is correct , JVMTI_REFERENCE_ARRAY_ELEMENT?? is >> from a different? enumeration type? and should be replaced? with the >> value? from the correct enumeration type?? . >> >> Bug / webrev : >> >> https://bugs.openjdk.java.net/browse/JDK-8226943 >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8226943.0/ > > The fix seems reasonable but the issue indicates a further problem > with the test. If it expected JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT but > was checking for JVMTI_REFERENCE_ARRAY_ELEMENT then we should have hit > the default clause and failed the test. That suggests the test doesn't > actually expect JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT in the first place. > > Cheers, > David > >> >> Thanks, Matthias >>