From david.holmes at oracle.com Wed May 1 00:57:35 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 May 2019 10:57:35 +1000 Subject: RFR (S): 8222534: VerifyBeforeExit is not honored when System.exit is called In-Reply-To: References: <94327eae-0553-a346-bc4f-e0ff8ffa7ce5@oracle.com> Message-ID: Updated webrev: http://cr.openjdk.java.net/~dholmes/8222534/webrev.v2/ The XML xtty logging has been removed as it could potentially lead to assertion failures too, as well as lengthy pauses in some cases. See details in the bug report. So only the changes to vmOperations.cpp remain and are unchanged from v1. (So I'm still claiming Robbin's review :) ). Thanks, David On 30/04/2019 10:52 pm, David Holmes wrote: > Testing has shown some problems with the XML logging. I think I see the > problem - an assert that shouldn't have been copied across - but now I > have to understand the implications of having the assertion fail > > David > > On 30/04/2019 8:45 pm, David Holmes wrote: >> Hi Dean, >> >> Thanks for taking a look at this. >> >> On 30/04/2019 5:07 pm, dean.long at oracle.com wrote: >>> On 4/29/19 8:54 PM, David Holmes wrote: >>>> The IdealGraphPrinter::cleanup was deemed unnecessary due to the >>>> fact the process is being blown away anyway. >>> >>> It looks like, without it, tail(TOP_ELEMENT) won't be called to end >>> the XML output. >> >> Good catch! Unfortunately adding the cleanup call resulted in a crash, >> as it seems another thread can be in the middle of outputting an XML >> element when we hit the terminal safepoint and try to issue the final >> XML element: >> >> #? Internal Error >> (open/src/hotspot/share/utilities/xmlstream.cpp:184), pid=32637, >> tid=32644 >> #? assert((!inside_attrs()) || VMError::is_error_reported()) failed: >> cannot close element inside attrs >> # >> >> I can't see any reason this would be specific to the System.exit case, >> and a fix is beyond the scope of this current bug, so I'll file a new >> bug for this so the compiler team can investigate and fix as needed. >> >> Thanks, >> David >> >>> dl From david.holmes at oracle.com Wed May 1 01:11:07 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 May 2019 11:11:07 +1000 Subject: RFR: 8223089: Stack alignment for x86-32 In-Reply-To: <481b88c2-1243-2990-6898-d5fe3108eb2d@redhat.com> References: <481b88c2-1243-2990-6898-d5fe3108eb2d@redhat.com> Message-ID: Hi Andrew, Is there a full webrev or are you just soliciting feedback on the proposed approach? (On which I can't actually comment.) If it is a Linux-only then I'd prefer to see only Linux being affected by this. Thanks, David On 1/05/2019 12:42 am, Andrew Haley wrote: > We've been seeing segfaults on 32-bit Linux x86. > > Recent Linux distributions' runtime libraries are compiled with SSE > enabled; this means that the stack must be aligned on a 16-bit > boundary when a function is called. GCC has defaulted to > 16-bit-aligned code for many years but HotSpot does not, calling > runtime routines with a misaligned stack. > > There is some code in HotSpot to work around specific instances of > this problem, but it is not applied consistently. If runtime code > calls out to C library functions, the stack remains misaligned and a > segfault can result, We can work around this by compiling the HotSpot > runtime with -mrealign-stack but this causes all code generated by GCC > to realign the stack, which is not efficient. It also prevents us from > compiling HotSpot with SSE enabled. > > I tried a variety of solutions, including rewriting the code which > does runtime calls. Unfortunately, there isn't a common point from > which all runtime calls are made. Instead, there are many places, with > different ways of passing arguments. > > At this stage in the lifetime of 32-bit x86 I don't think we can > justify either the initial cost or the maintanance cost of rewriting > all of the runtime call code. Instead, what I've done at the point of > a call from HotSpot-generated to native code is create a new (aligned) > stack frame, copy outgoing args into it, and call the native code. > > Old Style: > > __ call(RuntimeAddress(target)); > OopMapSet* oop_maps = new OopMapSet(); > oop_maps->add_gc_map(__ offset(), oop_map); > > New Style: > > { > AlignStackWithArgs aligned(sasm, num_rt_args, target); > __ call(RuntimeAddress(target)); > OopMapSet* oop_maps = new OopMapSet(); > oop_maps->add_gc_map(__ offset(), oop_map); > } > > C2 isn't affected: it gets everything right already. > C1 is affected, and so is the interpreter. > > Re-alignment only occurs when we know we are calling external code: we > can tell that because the target is outside the code cache. So, we do > take a performance hit from copying the args, but only at the > transition. > From jamsheed.c.m at oracle.com Wed May 1 03:17:43 2019 From: jamsheed.c.m at oracle.com (Jamsheed) Date: Wed, 1 May 2019 08:47:43 +0530 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <188da7c3-7384-220a-9290-cdd4bad25fce@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <62ad6130-0498-5222-43c7-befa3cea9741@oracle.com> <9dc5704c-7f87-e231-f3cc-7508c1a6d75c@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> Message-ID: <2ddfbcbd-4dff-4b86-ba0b-d5920b80e7ec@oracle.com> 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. 2) all Unsafe copy (intrinsic or native) ,uses array copy stub. 3) Unsafe copyswap x64 implementation extends arraycopy stub and used as reliable exit(fast exit too)*. it is not implemented for other platforms. *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 david.holmes at oracle.com Wed May 1 03:42:13 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 May 2019 13:42:13 +1000 Subject: RFR (S): 8222534: VerifyBeforeExit is not honored when System.exit is called In-Reply-To: <3bf1af77-83d3-04b4-20b5-6950de1d5e5c@oracle.com> References: <94327eae-0553-a346-bc4f-e0ff8ffa7ce5@oracle.com> <3bf1af77-83d3-04b4-20b5-6950de1d5e5c@oracle.com> Message-ID: Hi Coleen, On 1/05/2019 7:59 am, coleen.phillimore at oracle.com wrote: > > David, Thank you for the writeup of the exit paths. > > The reason I added this test with JDK-9074355 is because taking the > Heap_lock in destroy_vm prevented a crash in VerifyBeforeExit. > > http://cr.openjdk.java.net/~coleenp/2019/8074355.06/webrev/test/hotspot/jtreg/runtime/Shutdown/ShutdownTest.java.html > > > I wonder if you need to take the Heap_lock in the VM_Exit path as well. Yes you are right. Sorry I was focusing on the wrong aspect of that discussion. I've updated the v2 webrev in place as java.cpp is now back in it. I will also update the exit path document to show the taking of the Heap_lock. http://cr.openjdk.java.net/~dholmes/8222534/webrev.v2/ Re-testing in mach5 underway - though it probably won't be testing VerifyBeforeExit. I'm assuming, based on the fact the destroy_JavaVM path doesn't hang, that taking the Heap_lock can't succeed until there are no GC safepoint ops queued, and conversely once taken no GC safepoint ops will queue (or if they do they won't block trying to take the heap lock!)? This bug has turned out to be far more complex than originally anticipated :) Seems there are numerous reasons why various actions are not on the vm_exit() path! I only wish someone had documented why they were missing in the first place. So I added a comment about the xtty logging problem in java.cpp (now that it's back in the change). Thanks, David > > Coleen > > On 4/29/19 11:54 PM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8222534 >> Webrev: http://cr.openjdk.java.net/~dholmes/8222534/webrev/ >> >> Stefan noticed that VerifyBeforeExit was not honoured when a Java >> application terminates via System.exit. >> >> Examination of the exit code sequences revealed four differences >> between an exit due to the last non-daemon thread terminating (handled >> via jni_DestroyJavaVM) and a call to System.exit() (handled via >> JVM_Halt()). There are four missing actions on the System.exit() path: >> >> - No processing of VerifyBeforeExit >> - No XML logging before exit >> - No LogConfiguration::finalize() >> - No IdealGraphPrinter::clean_up() >> >> The first three have now been added at the appropriate point. >> VerifyBefore exit was the main omission. The compiler team? (i.e. >> Vladimir K.) indicated they'd also like the XML logging. And the >> LogConfiguration::finalize while possibly not essential avoids any >> doubt as to whether buffered log output may get lost. >> >> The IdealGraphPrinter::cleanup was deemed unnecessary due to the fact >> the process is being blown away anyway. >> >> The bug report contains a lot of details on the exit sequences >> including a side-by-side comparison in the attached pdf, showing the >> relative positioning of each action and that the correct order has >> been maintained. >> >> The vm_exit() code affects a number of "abrupt" exit paths in the VM, >> not just JVM_Halt, and this is discussed in the bug report as well. In >> short the addition of the missing actions should not cause any issues. >> >> Testing: >> ?- some manual checking of exit paths and whether new code was executed >> ?- all hotspot/jtreg/gc tests with -XX:+VerifyBeforeExit added >> ?- mach5 tiers 1-3 >> >> Thanks, >> David > From aph at redhat.com Wed May 1 07:29:05 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 1 May 2019 08:29:05 +0100 Subject: RFR: 8223089: Stack alignment for x86-32 In-Reply-To: References: <481b88c2-1243-2990-6898-d5fe3108eb2d@redhat.com> Message-ID: <00825951-d5ee-c16c-bc76-2a92ab12e6fb@redhat.com> Hi, On 5/1/19 2:11 AM, David Holmes wrote: > Is there a full webrev or are you just soliciting feedback on the > proposed approach? (On which I can't actually comment.) Oh, gosh, I was so relieved to finally get this patch done that I forgot the link to the webrev! :-) http://cr.openjdk.java.net/~aph/8223089/ > If it is a Linux-only then I'd prefer to see only Linux being affected > by this. Sure. I don't know what other operating systems are doing. I guess that Linux is the only one actually moving the 32-bit platform forward. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From david.holmes at oracle.com Wed May 1 13:01:35 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 May 2019 23:01:35 +1000 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: <3d4fe829-05fd-64d7-d75a-6b4d9d59003c@oracle.com> References: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> <5f534345-4224-3eb0-ba7f-0bbd3300f807@oracle.com> <65031818-D07C-4D28-AD80-B5371B61B4F3@oracle.com> <6cc59904-fcfb-d8b7-021e-c9fc2bb39cac@oracle.com> <3d4fe829-05fd-64d7-d75a-6b4d9d59003c@oracle.com> Message-ID: <8b3065f5-67b2-6cec-0c05-c830e34346c0@oracle.com> Hi Coleen, On 1/05/2019 5:03 am, coleen.phillimore at oracle.com wrote: > > I see.? I've rewritten the test as suggested: > http://cr.openjdk.java.net/~coleenp/2019/8074355.06/webrev/test/hotspot/jtreg/runtime/Shutdown/ShutdownTest.java.html A few nits (no need for updated webrev): 54 while (true) { 55 ShutdownTest st = new ShutdownTest(); 56 if (st == null) { 57 System.out.println("st == null"); 58 } "st == null" is impossible in Java - you will have a reference or an exception will be thrown. 63 System.out.println("- ShutdownTest -"); The string should be captured as a static variable so you don't need to repeat it. 65 for(int i = 0; i < 100; i++) { Space after "for" please. 73 private static void startVM(List options) throws Throwable, RuntimeException { Throwable already includes RuntimeException - the latter is redundant. P.S. I'll give this test a whirl with my fix for 8222534. > Whole (non-incremental) webrev is here.? It only has minor changes to > mutex.cpp and oopStorage.cpp. I think I spotted those changes and they seem okay. Thanks, David > http://cr.openjdk.java.net/~coleenp/2019/8074355.06/webrev > > > Thanks! > Coleen > > On 4/30/19 11:57 AM, Leonid Mesnik wrote: >> Hi >> >> I mean that you could re-write your test like: >> >> /* >> * @test >> * @bug 4656449 4945125 8074355 >> * @summary Make MutexLocker smarter about non-Java threads >> * @library /test/lib /runtime/testlibrary >> * @run main/driver ShutdownTest */ >> >> public class ShutdownTest { >> >> ? ? public static void main(String[] args) throws Throwable { >> ? ? ? ? List options = new ArrayList<>(); >> >> // Combine VM flags given from command-line and your additional options >> ? ? ? ? Collections.addAll(options, Utils.getTestJavaOpts()); >> Collections.addAll(options, >> ? ? ? ? ? ? ? ? "-Xmx2500k", >> ? ? ? ? ? ? ? ? "-XX:+UnlockDiagnosticVMOptions", >> ? ? ? ? ? ? ? ? "-XX:+VerifyBeforeExit", >> ? ? ? ? ); >> ? ? ? ? options.add(ShutdownTestThread.class.getName()); >> >> ? ? ? ? for (int iteration = 0; iteration < 30; ++iteration) { >> ? ? ? ? ? ? startVM(options); >> ? ? ? ? } >> ? ? } >> >> ? ? private static void startVM(List options) throws >> Throwable, RuntimeException { >> ? ? ? ? OutputAnalyzer out = >> ProcessTools.executeTestJvm(options.toArray(new String[options.size()])); >> output.shouldContain("- ShutdownTest -"); >> output.shouldHaveExitValue(0); >> >> ? ? } >> >> ? ?static class ShutdownTestThread extends Thread { >> ? ? ... >> ? ? } >> >> } >> >> Also I just find that following 'obj' in lined 47 is not used. The >> allocation in line 50 might be optimized. Why is it needed? >> 47 Object[] obj; >> 48 >> 49 ShutdownTest() { >> 50 obj = new Object[100000]; >> 51 } >> Leonid >> >>> On Apr 30, 2019, at 8:27 AM, coleen.phillimore at oracle.com >>> wrote: >>> >>> >>> >>> On 4/29/19 11:14 PM, Leonid Mesnik wrote: >>>> Hi >>>> >>>> A couple of comments about test. >>>> >>>> I see that test run process with selected GC and some other options. >>>> Original test just propagated all external options. >>>> >>>> Would not be easier to rewrite test like >>>> http://hg.openjdk.java.net/jdk/jdk/file/tip/test/hotspot/jtreg/gc/g1/logging/TestG1LoggingFailure.java >>>> so it combine all external options with '-XX:+VerifyBeforeExit'? >>> >>> I'm not sure what you mean.? This test above only tests G1.?? I think >>> this test follows what the GC team wants to do for testing: if an >>> option is specified globally for the test, we pass that option down >>> through the process builder that way.?? I did forget to fix it now >>> that we now have GC.selected() so the test can just do: >>> >>> ??? public static void main(String[] args) throws Exception { >>> ??????? for (int i = 0; i < 30; i++) { >>> ??????????? test(GC.selected()); >>> ??????? } >>> ??? } >>> >>>> >>>> In this case doesn't need WB anymore. It also could be a 'driver' >>>> and not 'othervm'. >>>> >>>> Also I've thought that "-XX:+UnlockDiagnosticVMOptions" should be >>>> used instead of ?"-XX:+UnlockExperimentalVMOptions" for "-XX:+ >>>> VerifyBeforeExit" option. >>> >>> Good catch!? I need both UnlockDiagnosticVMOptions for >>> VerifyBeforeExit in product, and -XX:+UnlockExperimentalVMOptions for >>> UseZGC. >>> >>> Thanks, >>> Coleen >>> >>>> Leonid >>>> >>>>> On Apr 29, 2019, at 6:23 PM, coleen.phillimore at oracle.com >>>>> wrote: >>>>> >>>>>> I was expecting the constructor to check the name. >>>>> >>>>> Ok, this is a good idea. ? I'm testing this through mach5 now but >>>>> it passes the safepoint tests. >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/2019/8074355.05/webrev >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 4/29/19 8:22 PM, David Holmes wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> I'll respond to a couple of things here relating to the new webrev >>>>>> and your comments below ... >>>>>> >>>>>> On 30/04/2019 8:21 am, coleen.phillimore at oracle.com wrote: >>>>>>> >>>>>>> An updated webrev is below. >>>>>>> >>>>>>> >>>>>>> On 4/29/19 8:11 AM, coleen.phillimore at oracle.com wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 4/28/19 8:42 PM, David Holmes wrote: >>>>>>>>> Hi Coleen, >>>>>>>>> >>>>>>>>> On 27/04/2019 2:10 am, coleen.phillimore at oracle.com wrote: >>>>>>>>>> Summary: Use safepoint_check_always/safepoint_check_never >>>>>>>>>> instead of safepoint_check_sometimes for locks that are taken >>>>>>>>>> by JavaThreads and non-JavaThreads >>>>>>>>> >>>>>>>>> To clarify: the safepoint_check_[always|never|sometimes] >>>>>>>>> pertains only to the behaviour of JavaThreads that use the >>>>>>>>> lock, independently of whether a lock may be used by both >>>>>>>>> JavaThreads and non-JavaThreads. >>>>>>>> >>>>>>>> Yes. >>>>>>>>> >>>>>>>>>> This patch moves all but 3 of the locks to not be >>>>>>>>>> safepoint_check_sometimes.? We have plans to fix these three. >>>>>>>>>> Also, >>>>>>>>> >>>>>>>>> So have you established that the reasons these were 'sometimes' >>>>>>>>> locks no longer apply and so it is correct to change them? Or >>>>>>>>> are you relying on testing to expose any mistaken assumptions? >>>>>>>> >>>>>>>> Oh, I hope not.?? Robbin and I have been looking at them and he >>>>>>>> thinks we can change them for the situations that they had to be >>>>>>>> sometimes locks.? The Heap_lock for example, couldn't be taken >>>>>>>> with a safepoint check on the exit path. >>>>>>>> >>>>>>>>> >>>>>>>>>> this patch allows for being explicit about safepoint checking >>>>>>>>>> or not when the thread is a non-java thread, which is >>>>>>>>>> something that Kim objected to in my first patch. >>>>>>>>> >>>>>>>>> I don't understand what you mean by this. NJTs can currently >>>>>>>>> call either lock() or lock_without_safepoint_check(). >>>>>>>>> >>>>>>>> >>>>>>>> My first patch added the change for NJTs to just call lock and >>>>>>>> didn't call lock_without_safepoint_check for the >>>>>>>> safepoint_check_always flags.?? Now they can call either.?? My >>>>>>>> first patch also made Heap_lock an always lock, which it can't be. >>>>>>>> >>>>>>>> >>>>>>>>>> Tested with mach5 tier1-3. >>>>>>>>>> >>>>>>>>>> open webrev at >>>>>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8074355.03/webrev >>>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8074355 >>>>>>>>> >>>>>>>>> src/hotspot/share/gc/shared/oopStorage.cpp >>>>>>>>> >>>>>>>>> How can these mutexes go from currently always needing >>>>>>>>> safepoint checks to now never needing them? Are they in fact >>>>>>>>> never used by JavaThreads? >>>>>>>>> >>>>>>>> Now, this asserts that they can't be sometimes either.? They >>>>>>>> asserted that they couldn't be "always" locks.? These locks are >>>>>>>> low level locks and should never safepoint check. >>>>>>>> >>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> src/hotspot/share/runtime/mutex.hpp >>>>>>>>> >>>>>>>>> ?95?? void check_safepoint_state?? (Thread* self, bool >>>>>>>>> safepoint_check) NOT_DEBUG_RETURN; >>>>>>>>> >>>>>>>>> Please use the same parameter name as in the implementation: >>>>>>>>> do_safepoint_check. >>>>>>>> >>>>>>>> Fixed. >>>>>>>> >>>>>>>>> >>>>>>>>> 109?? // Java and NonJavaThreads. When the lock is initialized >>>>>>>>> with _safepoint_check_always, >>>>>>>>> ?110?? // that means that whenever the lock is acquired by a >>>>>>>>> JavaThread, it will verify that each >>>>>>>>> ?111?? // acquition from a JavaThread is done with a safepoint >>>>>>>>> check. >>>>>>>>> >>>>>>>>> That can simplify to just: >>>>>>>>> >>>>>>>>> 109?? // Java and NonJavaThreads. When the lock is initialized >>>>>>>>> with _safepoint_check_always, >>>>>>>>> 110?? // that means that whenever the lock is acquired by a >>>>>>>>> JavaThread, it will verify that >>>>>>>>> 111?? // it is done with a safepoint check. >>>>>>>> >>>>>>>> That's better and less redundant. >>>>>>>> >>>>>>>>> >>>>>>>>> Should we then continue: >>>>>>>>> >>>>>>>>> 111?? // it is done with a safepoint check. In corollary when >>>>>>>>> the lock >>>>>>>>> 112?? // is initialized with _safepoint_check_never, that means >>>>>>>>> that >>>>>>>>> 113?? // whenever the lock is acquired by a JavaThread it will >>>>>>>>> verify >>>>>>>>> 114?? // that it is done without a safepoint check. >>>>>>>>> >>>>>>>>> ? >>>>>>>> >>>>>>>> I like it.? Added with some reformatting so the paragraph is >>>>>>>> same width. >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> 38?? SafepointCheckRequired not_allowed = do_safepoint_check ? >>>>>>>>> _safepoint_check_never : _safepoint_check_always; >>>>>>>>> 39 assert(!self->is_Java_thread() || _safepoint_check_required >>>>>>>>> != not_allowed, >>>>>>>>> >>>>>>>>> I found this code very difficult to understand due to some >>>>>>>>> previous choices. All of the names that start with underscore >>>>>>>>> give the illusion (to me) of being variables (or at least being >>>>>>>>> the same kind of thing) but two are enum values and one is a >>>>>>>>> field. Using this->_safepoint_check_required would at least >>>>>>>>> make it clearer which is the field. >>>>>>>> >>>>>>>> Ew. no. The underscore makes it clear it's a field of the class >>>>>>>> Monitor. >>>>>>> >>>>>>> I don't know the convention for enum values, but maybe these >>>>>>> could say Monitor::_safepoint_check_never etc instead.? That's a >>>>>>> typical convention we use even inside member functions of the class. >>>>>> >>>>>> Yes - thanks! That looks much clearer (though I admit enums >>>>>> confuse me in C++, in particular with named enums I would have >>>>>> expected to see SafepointCheckRequired::_safepoint_check_never >>>>>> [which would be quite unwieldy] rather than >>>>>> Monitor::_safepoint_check_never.) >>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> ?43?? // Allow NonJavaThreads to lock and wait with a safepoint >>>>>>>>> check for locks that may be shared with JavaThreads. >>>>>>>>> ?44 assert(self->is_Java_thread() || !do_safepoint_check || >>>>>>>>> _safepoint_check_required != _safepoint_check_never, >>>>>>>>> ?45????????? "NonJavaThreads can only check for safepoints if >>>>>>>>> shared with JavaThreads"); >>>>>>>>> >>>>>>>>> This is very confusing: NJTs don't do safepoint checks. I think >>>>>>>>> what you mean here is that you will allow a NJT to call lock() >>>>>>>>> rather than lock_without_safepoint_check() but only if the >>>>>>>>> mutex is "shared with JavaThreads". But always/sometimes/never >>>>>>>>> has nothing to with whether the lock is shared between JTs and >>>>>>>>> NJTs. I understand that a NJT-only mutex should, by convention, >>>>>>>>> be created with _safepoint_check_never - but it really makes no >>>>>>>>> practical difference. Further, a mutex used only by JavaThreads >>>>>>>>> could in theory also be _safepoint_check_never. >>>>>>>> >>>>>>>> It is confusing but this found some wild use of a lock(do >>>>>>>> safepoint check) call for a lock that is now defined as >>>>>>>> safepoint_check_never. The shared lock commentary was because >>>>>>>> for a shared lock, it can be acquired with the safepoint_check >>>>>>>> parameter from a NonJava thread. >>>>>>>> >>>>>>>> Maybe it should say this instead: >>>>>>>> >>>>>>>> ? // NonJavaThreads defined with safepoint_check_never should >>>>>>>> never ask to safepoint check. >>>>>>>> assert(thread->is_Java_thread() || !do_safepoint_check || >>>>>>>> _safepoint_check_required != _safepoint_check_never, >>>>>>>> ???????? "NonJavaThread should not check for safepoint"); >>>>>>>> >>>>>>>>> >>>>>>>>> 47?? // Only Threads_lock, Heap_lock and SR_lock may be >>>>>>>>> safepoint_check_sometimes. >>>>>>>>> 48 assert(_safepoint_check_required != >>>>>>>>> _safepoint_check_sometimes || this == Threads_lock || this == >>>>>>>>> Heap_lock || >>>>>>>>> 49????????? this->rank() == suspend_resume, >>>>>>>>> 50????????? "Lock has _safepoint_check_sometimes %s", >>>>>>>>> this->name()); >>>>>>>>> >>>>>>>>> This assert belongs in the constructor, not in every lock >>>>>>>>> operation, as it depends only on the monitor instance not on >>>>>>>>> the thread doing the lock. >>>>>>>>> >>>>>>>> >>>>>>>> You're right, that's much better! Fixed. >>>>>>> >>>>>>> This isn't better because I can't check this == Threads_lock when >>>>>>> calling the constructor on Threads_lock.? This code will go away >>>>>>> when the "sometimes" locks are fixed though. >>>>>> >>>>>> I was expecting the constructor to check the name. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8074355.04/webrev >>>>>>> >>>>>>> Sorry for not doing incremental. The only changes were in >>>>>>> mutex.cpp/hpp. >>>>>>> >>>>>>> Thanks! >>>>>>> Coleen >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>>>> --- >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Coleen >>>>>>>> >>>>>>> >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Wed May 1 13:20:27 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 1 May 2019 09:20:27 -0400 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: <8b3065f5-67b2-6cec-0c05-c830e34346c0@oracle.com> References: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> <5f534345-4224-3eb0-ba7f-0bbd3300f807@oracle.com> <65031818-D07C-4D28-AD80-B5371B61B4F3@oracle.com> <6cc59904-fcfb-d8b7-021e-c9fc2bb39cac@oracle.com> <3d4fe829-05fd-64d7-d75a-6b4d9d59003c@oracle.com> <8b3065f5-67b2-6cec-0c05-c830e34346c0@oracle.com> Message-ID: <2e8ffe98-93c5-4c87-fc9c-9bf75fdb2b77@oracle.com> On 5/1/19 9:01 AM, David Holmes wrote: > Hi Coleen, > > On 1/05/2019 5:03 am, coleen.phillimore at oracle.com wrote: >> >> I see.? I've rewritten the test as suggested: >> http://cr.openjdk.java.net/~coleenp/2019/8074355.06/webrev/test/hotspot/jtreg/runtime/Shutdown/ShutdownTest.java.html >> > > A few nits (no need for updated webrev): > > ? 54????????? while (true) { > ? 55??????????? ShutdownTest st = new ShutdownTest(); > ? 56??????????? if (st == null) { > ? 57????????????? System.out.println("st == null"); > ? 58??????????? } > > "st == null" is impossible in Java - you will have a reference or an > exception will be thrown. > > ?63????????? System.out.println("- ShutdownTest -"); > > The string should be captured as a static variable so you don't need > to repeat it. > > ?65????????? for(int i = 0; i < 100; i++) { > > Space after "for" please. > > ?73???? private static void startVM(List options) throws > Throwable, RuntimeException { > > Throwable already includes RuntimeException - the latter is redundant. Fixed all three and retested.? Thank you for taking a closer look! Coleen > > P.S. I'll give this test a whirl with my fix for 8222534. > >> Whole (non-incremental) webrev is here. It only has minor changes to >> mutex.cpp and oopStorage.cpp. > > I think I spotted those changes and they seem okay. > > Thanks, > David > >> http://cr.openjdk.java.net/~coleenp/2019/8074355.06/webrev >> >> >> >> Thanks! >> Coleen >> >> On 4/30/19 11:57 AM, Leonid Mesnik wrote: >>> Hi >>> >>> I mean that you could re-write your test like: >>> >>> /* >>> ? * @test >>> ? * @bug 4656449 4945125 8074355 >>> ? * @summary Make MutexLocker smarter about non-Java threads >>> ? * @library /test/lib /runtime/testlibrary >>> ? * @run main/driver ShutdownTest */ >>> >>> public class ShutdownTest { >>> >>> ? ? public static void main(String[] args) throws Throwable { >>> ? ? ? ? List options = new ArrayList<>(); >>> >>> // Combine VM flags given from command-line and your additional options >>> ? ? ? ? Collections.addAll(options, Utils.getTestJavaOpts()); >>> Collections.addAll(options, >>> ? ? ? ? ? ? ? ? "-Xmx2500k", >>> ? ? ? ? ? ? ? ? "-XX:+UnlockDiagnosticVMOptions", >>> ? ? ? ? ? ? ? ? "-XX:+VerifyBeforeExit", >>> ? ? ? ? ); >>> ? ? ? ? options.add(ShutdownTestThread.class.getName()); >>> >>> ? ? ? ? for (int iteration = 0; iteration < 30; ++iteration) { >>> ? ? ? ? ? ? startVM(options); >>> ? ? ? ? } >>> ? ? } >>> >>> ? ? private static void startVM(List options) throws >>> Throwable, RuntimeException { >>> ? ? ? ? OutputAnalyzer out = >>> ProcessTools.executeTestJvm(options.toArray(new >>> String[options.size()])); >>> output.shouldContain("- ShutdownTest -"); >>> output.shouldHaveExitValue(0); >>> >>> ? ? } >>> >>> ? ?static class ShutdownTestThread extends Thread { >>> ? ? ... >>> ? ? } >>> >>> } >>> >>> Also I just find that following 'obj' in lined 47 is not used. The >>> allocation in line 50 might be optimized. Why is it needed? >>> ?? 47??? Object[] obj; >>> ?? 48 >>> ?? 49??? ShutdownTest() { >>> ?? 50??????? obj = new Object[100000]; >>> ?? 51??? } >>> Leonid >>> >>>> On Apr 30, 2019, at 8:27 AM, coleen.phillimore at oracle.com >>>> wrote: >>>> >>>> >>>> >>>> On 4/29/19 11:14 PM, Leonid Mesnik wrote: >>>>> Hi >>>>> >>>>> A couple of comments about test. >>>>> >>>>> I see that test run process with selected GC and some other >>>>> options. Original test just propagated all external options. >>>>> >>>>> Would not be easier to rewrite test like >>>>> http://hg.openjdk.java.net/jdk/jdk/file/tip/test/hotspot/jtreg/gc/g1/logging/TestG1LoggingFailure.java >>>>> >>>>> so it combine all external options with '-XX:+VerifyBeforeExit'? >>>> >>>> I'm not sure what you mean.? This test above only tests G1.?? I >>>> think this test follows what the GC team wants to do for testing: >>>> if an option is specified globally for the test, we pass that >>>> option down through the process builder that way.?? I did forget to >>>> fix it now that we now have GC.selected() so the test can just do: >>>> >>>> ??? public static void main(String[] args) throws Exception { >>>> ??????? for (int i = 0; i < 30; i++) { >>>> ??????????? test(GC.selected()); >>>> ??????? } >>>> ??? } >>>> >>>>> >>>>> In this case doesn't need WB anymore. It also could be a 'driver' >>>>> and not 'othervm'. >>>>> >>>>> Also I've thought that "-XX:+UnlockDiagnosticVMOptions" should be >>>>> used instead of ?"-XX:+UnlockExperimentalVMOptions" for "-XX:+ >>>>> VerifyBeforeExit" option. >>>> >>>> Good catch!? I need both UnlockDiagnosticVMOptions for >>>> VerifyBeforeExit in product, and -XX:+UnlockExperimentalVMOptions >>>> for UseZGC. >>>> >>>> Thanks, >>>> Coleen >>>> >>>>> Leonid >>>>> >>>>>> On Apr 29, 2019, at 6:23 PM, coleen.phillimore at oracle.com >>>>>> wrote: >>>>>> >>>>>>> I was expecting the constructor to check the name. >>>>>> >>>>>> Ok, this is a good idea. ? I'm testing this through mach5 now but >>>>>> it passes the safepoint tests. >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/2019/8074355.05/webrev >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> On 4/29/19 8:22 PM, David Holmes wrote: >>>>>>> Hi Coleen, >>>>>>> >>>>>>> I'll respond to a couple of things here relating to the new >>>>>>> webrev and your comments below ... >>>>>>> >>>>>>> On 30/04/2019 8:21 am, coleen.phillimore at oracle.com wrote: >>>>>>>> >>>>>>>> An updated webrev is below. >>>>>>>> >>>>>>>> >>>>>>>> On 4/29/19 8:11 AM, coleen.phillimore at oracle.com wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 4/28/19 8:42 PM, David Holmes wrote: >>>>>>>>>> Hi Coleen, >>>>>>>>>> >>>>>>>>>> On 27/04/2019 2:10 am, coleen.phillimore at oracle.com wrote: >>>>>>>>>>> Summary: Use safepoint_check_always/safepoint_check_never >>>>>>>>>>> instead of safepoint_check_sometimes for locks that are >>>>>>>>>>> taken by JavaThreads and non-JavaThreads >>>>>>>>>> >>>>>>>>>> To clarify: the safepoint_check_[always|never|sometimes] >>>>>>>>>> pertains only to the behaviour of JavaThreads that use the >>>>>>>>>> lock, independently of whether a lock may be used by both >>>>>>>>>> JavaThreads and non-JavaThreads. >>>>>>>>> >>>>>>>>> Yes. >>>>>>>>>> >>>>>>>>>>> This patch moves all but 3 of the locks to not be >>>>>>>>>>> safepoint_check_sometimes.? We have plans to fix these >>>>>>>>>>> three.? Also, >>>>>>>>>> >>>>>>>>>> So have you established that the reasons these were >>>>>>>>>> 'sometimes' locks no longer apply and so it is correct to >>>>>>>>>> change them? Or are you relying on testing to expose any >>>>>>>>>> mistaken assumptions? >>>>>>>>> >>>>>>>>> Oh, I hope not.?? Robbin and I have been looking at them and >>>>>>>>> he thinks we can change them for the situations that they had >>>>>>>>> to be sometimes locks. The Heap_lock for example, couldn't be >>>>>>>>> taken with a safepoint check on the exit path. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> this patch allows for being explicit about safepoint >>>>>>>>>>> checking or not when the thread is a non-java thread, which >>>>>>>>>>> is something that Kim objected to in my first patch. >>>>>>>>>> >>>>>>>>>> I don't understand what you mean by this. NJTs can currently >>>>>>>>>> call either lock() or lock_without_safepoint_check(). >>>>>>>>>> >>>>>>>>> >>>>>>>>> My first patch added the change for NJTs to just call lock and >>>>>>>>> didn't call lock_without_safepoint_check for the >>>>>>>>> safepoint_check_always flags.?? Now they can call either.?? My >>>>>>>>> first patch also made Heap_lock an always lock, which it can't >>>>>>>>> be. >>>>>>>>> >>>>>>>>> >>>>>>>>>>> Tested with mach5 tier1-3. >>>>>>>>>>> >>>>>>>>>>> open webrev at >>>>>>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8074355.03/webrev >>>>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8074355 >>>>>>>>>> >>>>>>>>>> src/hotspot/share/gc/shared/oopStorage.cpp >>>>>>>>>> >>>>>>>>>> How can these mutexes go from currently always needing >>>>>>>>>> safepoint checks to now never needing them? Are they in fact >>>>>>>>>> never used by JavaThreads? >>>>>>>>>> >>>>>>>>> Now, this asserts that they can't be sometimes either.? They >>>>>>>>> asserted that they couldn't be "always" locks.? These locks >>>>>>>>> are low level locks and should never safepoint check. >>>>>>>>> >>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> src/hotspot/share/runtime/mutex.hpp >>>>>>>>>> >>>>>>>>>> ?95?? void check_safepoint_state?? (Thread* self, bool >>>>>>>>>> safepoint_check) NOT_DEBUG_RETURN; >>>>>>>>>> >>>>>>>>>> Please use the same parameter name as in the implementation: >>>>>>>>>> do_safepoint_check. >>>>>>>>> >>>>>>>>> Fixed. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 109?? // Java and NonJavaThreads. When the lock is >>>>>>>>>> initialized with _safepoint_check_always, >>>>>>>>>> ?110?? // that means that whenever the lock is acquired by a >>>>>>>>>> JavaThread, it will verify that each >>>>>>>>>> ?111?? // acquition from a JavaThread is done with a >>>>>>>>>> safepoint check. >>>>>>>>>> >>>>>>>>>> That can simplify to just: >>>>>>>>>> >>>>>>>>>> 109?? // Java and NonJavaThreads. When the lock is >>>>>>>>>> initialized with _safepoint_check_always, >>>>>>>>>> 110?? // that means that whenever the lock is acquired by a >>>>>>>>>> JavaThread, it will verify that >>>>>>>>>> 111?? // it is done with a safepoint check. >>>>>>>>> >>>>>>>>> That's better and less redundant. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Should we then continue: >>>>>>>>>> >>>>>>>>>> 111?? // it is done with a safepoint check. In corollary when >>>>>>>>>> the lock >>>>>>>>>> 112?? // is initialized with _safepoint_check_never, that >>>>>>>>>> means that >>>>>>>>>> 113?? // whenever the lock is acquired by a JavaThread it >>>>>>>>>> will verify >>>>>>>>>> 114?? // that it is done without a safepoint check. >>>>>>>>>> >>>>>>>>>> ? >>>>>>>>> >>>>>>>>> I like it.? Added with some reformatting so the paragraph is >>>>>>>>> same width. >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> 38?? SafepointCheckRequired not_allowed = do_safepoint_check >>>>>>>>>> ? _safepoint_check_never : _safepoint_check_always; >>>>>>>>>> 39 assert(!self->is_Java_thread() || >>>>>>>>>> _safepoint_check_required != not_allowed, >>>>>>>>>> >>>>>>>>>> I found this code very difficult to understand due to some >>>>>>>>>> previous choices. All of the names that start with underscore >>>>>>>>>> give the illusion (to me) of being variables (or at least >>>>>>>>>> being the same kind of thing) but two are enum values and one >>>>>>>>>> is a field. Using this->_safepoint_check_required would at >>>>>>>>>> least make it clearer which is the field. >>>>>>>>> >>>>>>>>> Ew. no. The underscore makes it clear it's a field of the >>>>>>>>> class Monitor. >>>>>>>> >>>>>>>> I don't know the convention for enum values, but maybe these >>>>>>>> could say Monitor::_safepoint_check_never etc instead.? That's >>>>>>>> a typical convention we use even inside member functions of the >>>>>>>> class. >>>>>>> >>>>>>> Yes - thanks! That looks much clearer (though I admit enums >>>>>>> confuse me in C++, in particular with named enums I would have >>>>>>> expected to see SafepointCheckRequired::_safepoint_check_never >>>>>>> [which would be quite unwieldy] rather than >>>>>>> Monitor::_safepoint_check_never.) >>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> ?43?? // Allow NonJavaThreads to lock and wait with a >>>>>>>>>> safepoint check for locks that may be shared with JavaThreads. >>>>>>>>>> ?44 assert(self->is_Java_thread() || !do_safepoint_check || >>>>>>>>>> _safepoint_check_required != _safepoint_check_never, >>>>>>>>>> ?45????????? "NonJavaThreads can only check for safepoints if >>>>>>>>>> shared with JavaThreads"); >>>>>>>>>> >>>>>>>>>> This is very confusing: NJTs don't do safepoint checks. I >>>>>>>>>> think what you mean here is that you will allow a NJT to call >>>>>>>>>> lock() rather than lock_without_safepoint_check() but only if >>>>>>>>>> the mutex is "shared with JavaThreads". But >>>>>>>>>> always/sometimes/never has nothing to with whether the lock >>>>>>>>>> is shared between JTs and NJTs. I understand that a NJT-only >>>>>>>>>> mutex should, by convention, be created with >>>>>>>>>> _safepoint_check_never - but it really makes no practical >>>>>>>>>> difference. Further, a mutex used only by JavaThreads could >>>>>>>>>> in theory also be _safepoint_check_never. >>>>>>>>> >>>>>>>>> It is confusing but this found some wild use of a lock(do >>>>>>>>> safepoint check) call for a lock that is now defined as >>>>>>>>> safepoint_check_never. The shared lock commentary was because >>>>>>>>> for a shared lock, it can be acquired with the safepoint_check >>>>>>>>> parameter from a NonJava thread. >>>>>>>>> >>>>>>>>> Maybe it should say this instead: >>>>>>>>> >>>>>>>>> ? // NonJavaThreads defined with safepoint_check_never should >>>>>>>>> never ask to safepoint check. >>>>>>>>> assert(thread->is_Java_thread() || !do_safepoint_check || >>>>>>>>> _safepoint_check_required != _safepoint_check_never, >>>>>>>>> ???????? "NonJavaThread should not check for safepoint"); >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 47?? // Only Threads_lock, Heap_lock and SR_lock may be >>>>>>>>>> safepoint_check_sometimes. >>>>>>>>>> 48 assert(_safepoint_check_required != >>>>>>>>>> _safepoint_check_sometimes || this == Threads_lock || this == >>>>>>>>>> Heap_lock || >>>>>>>>>> 49????????? this->rank() == suspend_resume, >>>>>>>>>> 50????????? "Lock has _safepoint_check_sometimes %s", >>>>>>>>>> this->name()); >>>>>>>>>> >>>>>>>>>> This assert belongs in the constructor, not in every lock >>>>>>>>>> operation, as it depends only on the monitor instance not on >>>>>>>>>> the thread doing the lock. >>>>>>>>>> >>>>>>>>> >>>>>>>>> You're right, that's much better! Fixed. >>>>>>>> >>>>>>>> This isn't better because I can't check this == Threads_lock >>>>>>>> when calling the constructor on Threads_lock.? This code will >>>>>>>> go away when the "sometimes" locks are fixed though. >>>>>>> >>>>>>> I was expecting the constructor to check the name. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8074355.04/webrev >>>>>>>> >>>>>>>> Sorry for not doing incremental. The only changes were in >>>>>>>> mutex.cpp/hpp. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> Coleen >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Coleen >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Coleen >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> From vladimir.x.ivanov at oracle.com Wed May 1 23:17:17 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 1 May 2019 16:17:17 -0700 Subject: [13] RFR (M): 8223213: Implement fast class initialization checks on x86-64 Message-ID: <85a4a478-9200-87f2-c966-49af21f687c2@oracle.com> http://cr.openjdk.java.net/~vlivanov/8223213/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8223213 (It's a followup RFR on a earlier RFC [1].) Recent changes severely affected how static initializers are executed and for long-running initializers it manifested as a severe slowdown. As an example, it led to a 3x slowdown on some Clojure applications (JDK-8219233 [2]). The root cause is that until a class is fully initialized, every invocation of static method on it goes through method resolution. Proposed fix introduces fast class initialization barriers for C1, C2, and template interpreter on x86-64. I did some experiments with cross-platform approaches, but haven't got satisfactory results. On other platforms, behavior stays (mostly) intact. (I had to revert some changes introduced by JDK-8219492 [3], since the assumptions they rely on about accesses inside a class don't hold in all cases.) The barrier is as simple as: if (holder->is_not_initialized() && !holder->is_reentrant_initialization(current_thread)) { // trigger call site re-resolution and block there } There are 3 places where barriers are added: * in template interpreter for invokestatic bytecode; * at nmethod verified entry point (for normal compilations); * c2i adapters; For template interperter, there's additional check added into TemplateTable::resolve_cache_and_index which calls into InterpreterRuntime::resolve_from_cache when fast path checks fail. In case of nmethods, the barrier is put before frame construction, so existing compiler runtime routines can be reused (SharedRuntime::get_handle_wrong_method_stub()). Also, C2 has a guard on entry (Parse::clinit_deopt()) which triggers nmethod recompilation once the class is fully initialized. OSR compilations don't need a barrier. Correspondence between barriers and transitions they cover: (1) from interpreter (barrier on caller side) * all transitions: interpreter, compiled (i2c), native, aot, ... (2) from compiled (barrier on callee side) to compiled, to native (barrier in native wrapper on entry) (3) c2i bypasses both barriers (interpreter and compiled) and requires a dedicated barrier in c2i (4) to Graal/AOT code: from interpreter: covered by interpreter barrier from compiled: call site patching is disabled, leading to repeated call site resolution until method holder is fully initialized (original behavior). Performance experiments with clojure [2] demonstrated that the fix almost completely recuperates the regression: (1) always reresolve (w/o the fix): ~12,0s ( 1x) (2) C1/C2 barriers only: ~3,8s (~3x) (3) int/C1/C2 barriers: ~3,2s (-20%) -------- (4) barriers disabled for invokestatic ~3,2s I deliberately tried to keep the patch backport-friendly for 8u/11u/12u and refrained from using newer features like nmethod barriers introduced recently. The fix can be refactored later specifically for 13 as a followup change. Testing: clojure startup, tier1-5 Thanks! Best regards, Vladimir Ivanov [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-April/037760.html [2] https://bugs.openjdk.java.net/browse/JDK-8219233 [3] https://bugs.openjdk.java.net/browse/JDK-8219492 From vladimir.kozlov at oracle.com Thu May 2 00:40:05 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 1 May 2019 17:40:05 -0700 Subject: [13] RFR (M): 8223213: Implement fast class initialization checks on x86-64 In-Reply-To: <85a4a478-9200-87f2-c966-49af21f687c2@oracle.com> References: <85a4a478-9200-87f2-c966-49af21f687c2@oracle.com> Message-ID: <9e0616f5-d79b-e439-26dd-a8e3334c10ed@oracle.com> Why you skip patching code compiled by Graal and AOT? The flag UseFastClassInitChecks could be diagnostic or even product. The feature is not for debugging. Thanks, Vladimir K On 5/1/19 4:17 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8223213/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8223213 > > (It's a followup RFR on a earlier RFC [1].) > > Recent changes severely affected how static initializers are executed and for long-running initializers it manifested as > a severe slowdown. > As an example, it led to a 3x slowdown on some Clojure applications > (JDK-8219233 [2]). The root cause is that until a class is fully initialized, every invocation of static method on it > goes through method resolution. > > Proposed fix introduces fast class initialization barriers for C1, C2, and template interpreter on x86-64. I did some > experiments with cross-platform approaches, but haven't got satisfactory results. > > On other platforms, behavior stays (mostly) intact. (I had to revert some changes introduced by JDK-8219492 [3], since > the assumptions they rely on about accesses inside a class don't hold in all cases.) > > The barrier is as simple as: > ?? if (holder->is_not_initialized() && > ?????? !holder->is_reentrant_initialization(current_thread)) { > ???? // trigger call site re-resolution and block there > ?? } > > There are 3 places where barriers are added: > ? * in template interpreter for invokestatic bytecode; > ? * at nmethod verified entry point (for normal compilations); > ? * c2i adapters; > > For template interperter, there's additional check added into TemplateTable::resolve_cache_and_index which calls into > InterpreterRuntime::resolve_from_cache when fast path checks fail. > > In case of nmethods, the barrier is put before frame construction, so existing compiler runtime routines can be reused > (SharedRuntime::get_handle_wrong_method_stub()). > > Also, C2 has a guard on entry (Parse::clinit_deopt()) which triggers nmethod recompilation once the class is fully > initialized. > > OSR compilations don't need a barrier. > > Correspondence between barriers and transitions they cover: > ? (1) from interpreter (barrier on caller side) > ?????? * all transitions: interpreter, compiled (i2c), native, aot, ... > > ? (2) from compiled (barrier on callee side) > ?????? to compiled, to native (barrier in native wrapper on entry) > > ? (3) c2i bypasses both barriers (interpreter and compiled) and requires a dedicated barrier in c2i > > ? (4) to Graal/AOT code: > ??????? from interpreter: covered by interpreter barrier > ??????? from compiled: call site patching is disabled, leading to repeated call site resolution until method holder is > fully initialized (original behavior). > > Performance experiments with clojure [2] demonstrated that the fix almost completely recuperates the regression: > > ? (1) always reresolve (w/o the fix):??? ~12,0s ( 1x) > ? (2) C1/C2 barriers only:??????????????? ~3,8s (~3x) > ? (3) int/C1/C2 barriers:???????????????? ~3,2s (-20%) > -------- > ? (4) barriers disabled for invokestatic? ~3,2s > > I deliberately tried to keep the patch backport-friendly for 8u/11u/12u and refrained from using newer features like > nmethod barriers introduced recently. The fix can be refactored later specifically for 13 as a followup change. > > Testing: clojure startup, tier1-5 > > Thanks! > > Best regards, > Vladimir Ivanov > > [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-April/037760.html > [2] https://bugs.openjdk.java.net/browse/JDK-8219233 > [3] https://bugs.openjdk.java.net/browse/JDK-8219492 From yasuenag at gmail.com Thu May 2 02:03:22 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 2 May 2019 11:03:22 +0900 Subject: RFR: 8223186: HotSpot compile warnings from GCC 9 Message-ID: Hi all, Please review this change: JBS: https://bugs.openjdk.java.net/browse/JDK-8223186 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8223186/webrev.00/ I saw following warnings when I compiled HotSpot with GCC 9 on Fedora 30 due to -Wwrite-strings, -Wstringop-truncation and -Wclass-memaccess. I filed all warnings to JBS. Thanks, Yasumasa From vladimir.x.ivanov at oracle.com Thu May 2 02:13:37 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 1 May 2019 19:13:37 -0700 Subject: [13] RFR (M): 8223213: Implement fast class initialization checks on x86-64 In-Reply-To: <9e0616f5-d79b-e439-26dd-a8e3334c10ed@oracle.com> References: <85a4a478-9200-87f2-c966-49af21f687c2@oracle.com> <9e0616f5-d79b-e439-26dd-a8e3334c10ed@oracle.com> Message-ID: <0ceb99f0-2c37-bb27-9ca4-18e1f145dbbe@oracle.com> Thanks for the feedback, Vladimir! > Why you skip patching code compiled by Graal and AOT? It happens only for classes being initialized and effectively preserve current behavior (re-resolution until class is fully initialized). The motivation is the following: * Graal needs to put class init barriers in nmethods at verified entry point in the same way C1/C2 does with this patch; * regarding AOTed code (I haven't done extensive exploration, but based on private discussions), I believe it needs additional barriers at method entry as well. Once proper support lands in Graal or AOT, the patching can be re-enabled. > The flag UseFastClassInitChecks could be diagnostic or even product. The > feature is not for debugging. The flag is used to signal that platform-specific support is available. Unless there's a use case which benefits from ability to turning it off (disable new barriers and fallback to re-resolution) from command line, I don't see much value in turning the flag into diagnostic/product one. Best regards, Vladimir Ivanov > On 5/1/19 4:17 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8223213/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8223213 >> >> (It's a followup RFR on a earlier RFC [1].) >> >> Recent changes severely affected how static initializers are executed >> and for long-running initializers it manifested as a severe slowdown. >> As an example, it led to a 3x slowdown on some Clojure applications >> (JDK-8219233 [2]). The root cause is that until a class is fully >> initialized, every invocation of static method on it goes through >> method resolution. >> >> Proposed fix introduces fast class initialization barriers for C1, C2, >> and template interpreter on x86-64. I did some experiments with >> cross-platform approaches, but haven't got satisfactory results. >> >> On other platforms, behavior stays (mostly) intact. (I had to revert >> some changes introduced by JDK-8219492 [3], since the assumptions they >> rely on about accesses inside a class don't hold in all cases.) >> >> The barrier is as simple as: >> ??? if (holder->is_not_initialized() && >> ??????? !holder->is_reentrant_initialization(current_thread)) { >> ????? // trigger call site re-resolution and block there >> ??? } >> >> There are 3 places where barriers are added: >> ?? * in template interpreter for invokestatic bytecode; >> ?? * at nmethod verified entry point (for normal compilations); >> ?? * c2i adapters; >> >> For template interperter, there's additional check added into >> TemplateTable::resolve_cache_and_index which calls into >> InterpreterRuntime::resolve_from_cache when fast path checks fail. >> >> In case of nmethods, the barrier is put before frame construction, so >> existing compiler runtime routines can be reused >> (SharedRuntime::get_handle_wrong_method_stub()). >> >> Also, C2 has a guard on entry (Parse::clinit_deopt()) which triggers >> nmethod recompilation once the class is fully initialized. >> >> OSR compilations don't need a barrier. >> >> Correspondence between barriers and transitions they cover: >> ?? (1) from interpreter (barrier on caller side) >> ??????? * all transitions: interpreter, compiled (i2c), native, aot, ... >> >> ?? (2) from compiled (barrier on callee side) >> ??????? to compiled, to native (barrier in native wrapper on entry) >> >> ?? (3) c2i bypasses both barriers (interpreter and compiled) and >> requires a dedicated barrier in c2i >> >> ?? (4) to Graal/AOT code: >> ???????? from interpreter: covered by interpreter barrier >> ???????? from compiled: call site patching is disabled, leading to >> repeated call site resolution until method holder is fully initialized >> (original behavior). >> >> Performance experiments with clojure [2] demonstrated that the fix >> almost completely recuperates the regression: >> >> ?? (1) always reresolve (w/o the fix):??? ~12,0s ( 1x) >> ?? (2) C1/C2 barriers only:??????????????? ~3,8s (~3x) >> ?? (3) int/C1/C2 barriers:???????????????? ~3,2s (-20%) >> -------- >> ?? (4) barriers disabled for invokestatic? ~3,2s >> >> I deliberately tried to keep the patch backport-friendly for >> 8u/11u/12u and refrained from using newer features like nmethod >> barriers introduced recently. The fix can be refactored later >> specifically for 13 as a followup change. >> >> Testing: clojure startup, tier1-5 >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov >> >> [1] >> https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-April/037760.html >> >> [2] https://bugs.openjdk.java.net/browse/JDK-8219233 >> [3] https://bugs.openjdk.java.net/browse/JDK-8219492 From vladimir.kozlov at oracle.com Thu May 2 02:34:39 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 1 May 2019 19:34:39 -0700 Subject: [13] RFR (M): 8223213: Implement fast class initialization checks on x86-64 In-Reply-To: <0ceb99f0-2c37-bb27-9ca4-18e1f145dbbe@oracle.com> References: <85a4a478-9200-87f2-c966-49af21f687c2@oracle.com> <9e0616f5-d79b-e439-26dd-a8e3334c10ed@oracle.com> <0ceb99f0-2c37-bb27-9ca4-18e1f145dbbe@oracle.com> Message-ID: On 5/1/19 7:13 PM, Vladimir Ivanov wrote: > Thanks for the feedback, Vladimir! > >> Why you skip patching code compiled by Graal and AOT? > > It happens only for classes being initialized and effectively preserve current behavior (re-resolution until class is > fully initialized). > > The motivation is the following: > > ? * Graal needs to put class init barriers in nmethods at verified entry > point in the same way C1/C2 does with this patch; > > ? * regarding AOTed code (I haven't done extensive exploration, but based on private discussions), I believe it needs > additional barriers at method entry as well. When Graal will add barriers AOT code will get them automatically. > > Once proper support lands in Graal or AOT, the patching can be re-enabled. Got it. > >> The flag UseFastClassInitChecks could be diagnostic or even product. The feature is not for debugging. > The flag is used to signal that platform-specific support is available. Unless there's a use case which benefits from > ability to turning it off (disable new barriers and fallback to re-resolution) from command line, I don't see much value > in turning the flag into diagnostic/product one. Okay. Thanks, Vladimir > > Best regards, > Vladimir Ivanov > >> On 5/1/19 4:17 PM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8223213/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8223213 >>> >>> (It's a followup RFR on a earlier RFC [1].) >>> >>> Recent changes severely affected how static initializers are executed and for long-running initializers it manifested >>> as a severe slowdown. >>> As an example, it led to a 3x slowdown on some Clojure applications >>> (JDK-8219233 [2]). The root cause is that until a class is fully initialized, every invocation of static method on it >>> goes through method resolution. >>> >>> Proposed fix introduces fast class initialization barriers for C1, C2, and template interpreter on x86-64. I did some >>> experiments with cross-platform approaches, but haven't got satisfactory results. >>> >>> On other platforms, behavior stays (mostly) intact. (I had to revert some changes introduced by JDK-8219492 [3], >>> since the assumptions they rely on about accesses inside a class don't hold in all cases.) >>> >>> The barrier is as simple as: >>> ??? if (holder->is_not_initialized() && >>> ??????? !holder->is_reentrant_initialization(current_thread)) { >>> ????? // trigger call site re-resolution and block there >>> ??? } >>> >>> There are 3 places where barriers are added: >>> ?? * in template interpreter for invokestatic bytecode; >>> ?? * at nmethod verified entry point (for normal compilations); >>> ?? * c2i adapters; >>> >>> For template interperter, there's additional check added into TemplateTable::resolve_cache_and_index which calls into >>> InterpreterRuntime::resolve_from_cache when fast path checks fail. >>> >>> In case of nmethods, the barrier is put before frame construction, so existing compiler runtime routines can be >>> reused (SharedRuntime::get_handle_wrong_method_stub()). >>> >>> Also, C2 has a guard on entry (Parse::clinit_deopt()) which triggers nmethod recompilation once the class is fully >>> initialized. >>> >>> OSR compilations don't need a barrier. >>> >>> Correspondence between barriers and transitions they cover: >>> ?? (1) from interpreter (barrier on caller side) >>> ??????? * all transitions: interpreter, compiled (i2c), native, aot, ... >>> >>> ?? (2) from compiled (barrier on callee side) >>> ??????? to compiled, to native (barrier in native wrapper on entry) >>> >>> ?? (3) c2i bypasses both barriers (interpreter and compiled) and requires a dedicated barrier in c2i >>> >>> ?? (4) to Graal/AOT code: >>> ???????? from interpreter: covered by interpreter barrier >>> ???????? from compiled: call site patching is disabled, leading to repeated call site resolution until method holder >>> is fully initialized (original behavior). >>> >>> Performance experiments with clojure [2] demonstrated that the fix almost completely recuperates the regression: >>> >>> ?? (1) always reresolve (w/o the fix):??? ~12,0s ( 1x) >>> ?? (2) C1/C2 barriers only:??????????????? ~3,8s (~3x) >>> ?? (3) int/C1/C2 barriers:???????????????? ~3,2s (-20%) >>> -------- >>> ?? (4) barriers disabled for invokestatic? ~3,2s >>> >>> I deliberately tried to keep the patch backport-friendly for 8u/11u/12u and refrained from using newer features like >>> nmethod barriers introduced recently. The fix can be refactored later specifically for 13 as a followup change. >>> >>> Testing: clojure startup, tier1-5 >>> >>> Thanks! >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-April/037760.html >>> [2] https://bugs.openjdk.java.net/browse/JDK-8219233 >>> [3] https://bugs.openjdk.java.net/browse/JDK-8219492 From erik.osterlund at oracle.com Thu May 2 08:55:07 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 2 May 2019 10:55:07 +0200 Subject: RFR: 8222841: Incorrect static call stub interactions with class unloading In-Reply-To: <1ca35306-6be8-61ec-127f-196367d94899@oracle.com> References: <067fc16e-3104-4e61-b558-9cd4864f079f@oracle.com> <1ca35306-6be8-61ec-127f-196367d94899@oracle.com> Message-ID: <6f615499-6f79-ce41-d835-d64e0741a3be@oracle.com> Hi Coleen, Thank you for the review. On 2019-04-23 23:32, coleen.phillimore at oracle.com wrote: > > http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp.frames.html > > > Can you mention in a comment that incoming rbx is the method? Fixed. > You can't do a JRT_LEAF function from here, can you to some > Method::is_alive() function?? Or even a straight up call ?? This > doesn't seem that it should care about the extra overhead of the call > instruction.? The assembly code looks correct but yuck not more > assembly code. I'm not sure I know how I feel about that. I would have to save and restore all registers then to go into the runtime just to check if the method is alive. Would you be okay with keeping the assembly variant instead until I find a better solution to this problem? (I'm on it) > http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/src/hotspot/share/code/compiledMethod.cpp.frames.html > > > 578 case relocInfo::static_stub_type: { > 579 is_in_static_stub = true; > 580 break; > 581 } > 582 > 583 case relocInfo::metadata_type: { > 584 if (!is_in_static_stub) { > 585 continue; > 586 } > > > This was mystifying to me.? Can you put a comment that after > static_stub_type relocations are generated, the next metadata > relocation contains the address that is patched at runtime, so this is > the metadata that can be stale and should be cleared by unloading. Sure, I updated the comments, and added a better description about what is going on here. Webrev: http://cr.openjdk.java.net/~eosterlund/8222841/webrev.01/ Incremental: http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00_01/ Thanks, /Erik > The clean_ic_stubs() name is my fault.? I didn't know what they were > and just wanted this code out of my way. > > Thank you for explaining how redefinition is broken by this.? I didn't > know these metadata_reloc guys were patched at runtime. > > Thanks, > Coleen > > > > On 4/23/19 4:41 AM, Erik ?sterlund wrote: >> Hi, >> >> Static call stubs are cleared in debug builds before an assert >> checking for dead metadata. This is done in the function >> "clean_ic_stubs()" (which does not clean ICStubs... but >> static/optimized virtual call stubs for calling c2i adapters from >> compiled code...) The reason is that the static call stub has >> metadata, and it complains about dead metadata being left after >> inline cache cleaning of is_alive nmethods. >> >> ...except class redefinition looks at this metadata to determine if >> there is old metadata in subsequent safepoints, and they could have >> been unloaded then. Ouch. So maybe we shouldn't squelch that assert >> in debug builds, because it actually shows there is a real problem. >> >> ...and with concurrent class unloading (ZGC and seemingly soon >> Shenandoah), we can't just clear the call stub of a concurrently >> running JavaThread; they can racingly call in to them before they get >> cleared, and then get stuck in an infinite loop, because clearing >> also involves updating the branch target of the static call stub to a >> self-loop. Or call a dead method, which also seems like a scary >> scenario. >> >> All things considered, clearing static call stubs when unloading the >> code cache seems like a bad idea. >> >> My proposal is the following: >> 1) Make sure that code cache unloading *always* clears out the >> metadata part (but not the branch part) of static call stubs, so that >> subsequent operations such as class redefinition will not blow up >> when looking at the embedded metadata, but it won't get stuck in >> infinite loops with concurrent code cache unloading. >> 2) Make a c2i entry barrier for concurrently unloading GCs that will >> reresolve the call when calling into a stale static call stub (iff >> method is NULL or dead). >> 3) Relax MT-safety asserts to allow the previous medatada to be >> concurrently unloading when setting the new target. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8222841 >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/ >> >> Thanks, >> /Erik > From claes.redestad at oracle.com Thu May 2 11:03:18 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 2 May 2019 13:03:18 +0200 Subject: [13] RFR (M): 8223213: Implement fast class initialization checks on x86-64 In-Reply-To: <85a4a478-9200-87f2-c966-49af21f687c2@oracle.com> References: <85a4a478-9200-87f2-c966-49af21f687c2@oracle.com> Message-ID: <37ee4fe8-d962-6e05-82f0-7258f5083459@oracle.com> Hi Vladimir, On 2019-05-02 01:17, Vladimir Ivanov wrote: > Performance experiments with clojure [2] demonstrated that the fix > almost completely recuperates the regression: > > ? (1) always reresolve (w/o the fix):??? ~12,0s ( 1x) > ? (2) C1/C2 barriers only:??????????????? ~3,8s (~3x) > ? (3) int/C1/C2 barriers:???????????????? ~3,2s (-20%) > -------- > ? (4) barriers disabled for invokestatic? ~3,2s good stuff! Just to add a few data points I turned some of my earlier experiments to try and isolate some of these issues into a little stress test: BadStress[1]: 11.0.1: 136ms 11.0.2: 13500ms jdk/jdk baseline: 126ms jdk/jdk patched: 123ms GoodStress[2] (baseline): 11.0.1: 56ms 11.0.2: 54ms jdk/jdk baseline: 48ms jdk/jdk patched: 47ms Observations: - On latest jdk/jdk, we've already recuperated most of the cost exposed in these synthetic tests due related fixes (mainly https://bugs.openjdk.java.net/browse/JDK-8188133 and https://bugs.openjdk.java.net/browse/JDK-8219974 ), but the patch helps a bit here too and we're net faster than 11.0.1 (also when taking into account how startup in general has improved since) - The small 1ms startup improvement with the patch on the baseline test is sustained and significant, indicating we have some internal JDK classes exercised during bootstrap which benefit directly from your fixes. I've verified this improvement translates to all our other small-app startup tests. - My tests were too na?ve to capture all the overheads seen with clj - Likely still good performance advice to avoid heavy lifting in static initializers. All in all I think this is a great improvement and hope the added complexity is deemed acceptable. Thanks! /Claes [1] public class BadStress { static void foo() {} static void bar() {} public static class Helper { static void foo() { BadStress.foo(); } } static { long start = System.nanoTime(); for (int i = 0; i < 10_000_000; i++) { Helper.foo(); } for (int i = 0; i < 10_000_000; i++) { bar(); } long end = System.nanoTime(); System.out.println("Elapsed: " + (end - start) + " ns"); } public static void main(String... args) {} } [2] public class GoodStress { public static class Helper { static void foo() {} static void bar() {} } static { long start = System.nanoTime(); for (int i = 0; i < 10_000_000; i++) { Helper.foo(); } for (int i = 0; i < 10_000_000; i++) { Helper.bar(); } long end = System.nanoTime(); System.out.println("Elapsed: " + (end - start) + " ns"); } public static void main(String... args) {} } From fweimer at redhat.com Thu May 2 11:32:55 2019 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 02 May 2019 13:32:55 +0200 Subject: RFR: 8223089: Stack alignment for x86-32 References: <481b88c2-1243-2990-6898-d5fe3108eb2d@redhat.com> Message-ID: <87ef5hxfa0.fsf@oldenburg2.str.redhat.com> * Andrew Haley: > We've been seeing segfaults on 32-bit Linux x86. > > Recent Linux distributions' runtime libraries are compiled with SSE > enabled; this means that the stack must be aligned on a 16-bit > boundary when a function is called. GCC has defaulted to > 16-bit-aligned code for many years but HotSpot does not, calling > runtime routines with a misaligned stack. This is not a review of your patch (sorry), but I'd like to share what figured out when setting the compiler flags for current Fedora and downstream. We have built with SSE2 for many, many years in the downstream distribution, but with -O2, so there wasn't any vectorization in older GCC versions. Very few functions, even those performing double arithmetic, had stack spills, so that wasn't a problem in the GCC 4.8 days. As long as you used -O2. With -O3, vectorization could happen even with GCC 4.8, leading to more stack spills and requiring an aligned stack. I see -O3 in Hotspot build logs, so this is one of the issues you might hitting. Later GCC releases (those with the STV pass) also use SSE2 code for integer code, even at -O2. This resulted in practical problems (crahses like the one you're trying to fix), which is why we now build everything with -mstackrealign. -mstackrealign has the nice property that it preserves stack alignment if it encounters it (which is needed for callback-based functions such as qsort_r), but does not actually require it. It disables GCC's STV pass, and the code isn't great in many cases. Our main concern initially was that the flag had not seen much exposure (which is probably good because its documentation is so misleading), but we encountered only very few problems at the distribution level. Most of them were related to explicitly enabled fastcall/regparm calling conventions leaving no registers available for stack realignment, stack protector, and stack clash protection. Anyway, we decided that at this point, i386 is for backwards compatibility with legacy applications, not for performance, which is why we went with the -mstackrealign approach. For the same compatibility reason, we didn't want to stop building with SSE2 instead of the FPU. Switching back to the FPU would have reintroduced excess precision issues. > There is some code in HotSpot to work around specific instances of > this problem, but it is not applied consistently. If runtime code > calls out to C library functions, the stack remains misaligned and a > segfault can result, We can work around this by compiling the HotSpot > runtime with -mrealign-stack but this causes all code generated by GCC > to realign the stack, which is not efficient. It also prevents us from > compiling HotSpot with SSE enabled. If you want to compile Hotspot with SSE2, you will have to realign the stack when JNI code calls back into Hotspot. Otherwose, you lose support for legacy JNI libraries which do not preserve stack alignment (as required after that silent ABI bump). Supporting such legacy code is the reason why the system libraries in our distribution do not require stack realignment on i386, so compiling Hotspot without SSE2 would also avoid the problem there, even if Hotspot code calls such function such as malloc in response to requests from JNI code. Thanks, Florian From stefan.karlsson at oracle.com Thu May 2 12:44:54 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 2 May 2019 14:44:54 +0200 Subject: RFR: 8223136: Move compressed oops functions to CompressedOops class In-Reply-To: <61cb41e8-fcd5-845f-e57f-7a2d46c0c995@oracle.com> References: <61cb41e8-fcd5-845f-e57f-7a2d46c0c995@oracle.com> Message-ID: <612339e6-e693-c1c9-51f6-9316aa90874b@oracle.com> Hi all, Rebased on top of latest changes (jdk/jdk @ edd709e64ea1): http://cr.openjdk.java.net/~stefank/8223136/webrev.02/ Thanks, StefanK On 2019-04-30 10:58, Stefan Karlsson wrote: > Hi all, > > Please review this patch to move the rest of the compressed oops > functions and variables over to CompressedOops. > > http://cr.openjdk.java.net/~stefank/8223136/webrev.01 > https://bugs.openjdk.java.net/browse/JDK-8223136 > > In 'JDK-8199946: Move load/store and encode/decode out of oopDesc' the > decoding and encoding of compressed oops were moved into the namespace > named CompressedOops. > > There infrastructure used by these functions were left in Universe. This > patch moves rest of the functions and variables over to CompressedOops. > I decided to convert the CompressedOops namespace into a proper > AllStatic class, to avoid any potential problems with VMStructs. > > I also moved the corresponding functionality for compressed klass > pointers into a new class named CompressedKlassPointers. > > While doing this change I decided to cleanup the includes regarding > compressed oops, and universe.hpp, where most of the code was moved > from. Therefore, the patch is touching a large number of files. A lot of > the files contain updated header includes and simple renames. If you > want to fast-forward through those, these are the main files where code > related to compressed oops actually moved: > > > http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/universe.cpp.udiff.html > > > http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/universe.hpp.udiff.html > > > http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/compressedOops.hpp.html > > > http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/compressedOops.inline.hpp.udiff.html > > > http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/klass.cpp.udiff.html > > > http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/klass.hpp.udiff.html > > > http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/klass.inline.hpp.udiff.html > > > http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/oop.cpp.udiff.html > > > http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/oop.hpp.udiff.html > > > To get cleaner includes I did some minor restructuring to other files. I > can do these changes a small preparation patches, but would like to get > feedback on the overall patch first. > > Move flag checking out of hpp file, to stop propagation of globals.hpp > to all places where compressedOops.hpp is included: > > > http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.cpp.udiff.html > > > http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.hpp.udiff.html > > > Extract VerifyOption out of universe.hpp: > > > http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/verifyOption.hpp.html > > > http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/verifyOption.hpp.html > > > Moves a usage of CompressedOops to the cpp file: > > > http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/opto/matcher.cpp.udiff.html > > > http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/opto/matcher.hpp.udiff.html > > > Move Universe usage out of hpp files > > > http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/memAllocator.hpp.udiff.html > > > http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/memAllocator.cpp.udiff.html > > > http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/isGCActiveMark.hpp.udiff.html > > http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/isGCActiveMark.cpp.html > > > > http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.cpp.udiff.html > > > http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.hpp.udiff.html > > > > http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/code/oopRecorder.hpp.udiff.html > > > http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/code/oopRecorder.inline.hpp.html > > > I've tried to update all platforms, but would appreciate verification > from platform maintainers that the changes don't break the build. > > I've also left some of the old names in JVMCI, to not disturb ongoing > changes in that area. > > Thanks, > StefanK From coleen.phillimore at oracle.com Thu May 2 14:12:38 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 2 May 2019 10:12:38 -0400 Subject: RFR: 8223136: Move compressed oops functions to CompressedOops class In-Reply-To: <612339e6-e693-c1c9-51f6-9316aa90874b@oracle.com> References: <61cb41e8-fcd5-845f-e57f-7a2d46c0c995@oracle.com> <612339e6-e693-c1c9-51f6-9316aa90874b@oracle.com> Message-ID: Hi Stefan, This seems fine but I'd really like to have the #include universe.hpp part of the patch broken out, as much as possible. Thanks, Coleen On 5/2/19 8:44 AM, Stefan Karlsson wrote: > Hi all, > > Rebased on top of latest changes (jdk/jdk @ edd709e64ea1): > ?http://cr.openjdk.java.net/~stefank/8223136/webrev.02/ > > Thanks, > StefanK > > > On 2019-04-30 10:58, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to move the rest of the compressed oops >> functions and variables over to CompressedOops. >> >> http://cr.openjdk.java.net/~stefank/8223136/webrev.01 >> https://bugs.openjdk.java.net/browse/JDK-8223136 >> >> In 'JDK-8199946: Move load/store and encode/decode out of oopDesc' >> the decoding and encoding of compressed oops were moved into the >> namespace named CompressedOops. >> >> There infrastructure used by these functions were left in Universe. >> This patch moves rest of the functions and variables over to >> CompressedOops. I decided to convert the CompressedOops namespace >> into a proper AllStatic class, to avoid any potential problems with >> VMStructs. >> >> I also moved the corresponding functionality for compressed klass >> pointers into a new class named CompressedKlassPointers. >> >> While doing this change I decided to cleanup the includes regarding >> compressed oops, and universe.hpp, where most of the code was moved >> from. Therefore, the patch is touching a large number of files. A lot >> of the files contain updated header includes and simple renames. If >> you want to fast-forward through those, these are the main files >> where code related to compressed oops actually moved: >> >> >> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/universe.cpp.udiff.html >> >> >> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/universe.hpp.udiff.html >> >> >> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/compressedOops.hpp.html >> >> >> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/compressedOops.inline.hpp.udiff.html >> >> >> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/klass.cpp.udiff.html >> >> >> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/klass.hpp.udiff.html >> >> >> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/klass.inline.hpp.udiff.html >> >> >> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/oop.cpp.udiff.html >> >> >> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/oop.hpp.udiff.html >> >> >> To get cleaner includes I did some minor restructuring to other >> files. I can do these changes a small preparation patches, but would >> like to get feedback on the overall patch first. >> >> Move flag checking out of hpp file, to stop propagation of >> globals.hpp to all places where compressedOops.hpp is included: >> >> >> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.cpp.udiff.html >> >> >> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.hpp.udiff.html >> >> >> Extract VerifyOption out of universe.hpp: >> >> >> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/verifyOption.hpp.html >> >> >> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/verifyOption.hpp.html >> >> >> Moves a usage of CompressedOops to the cpp file: >> >> >> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/opto/matcher.cpp.udiff.html >> >> >> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/opto/matcher.hpp.udiff.html >> >> >> Move Universe usage out of hpp files >> >> >> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/memAllocator.hpp.udiff.html >> >> >> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/memAllocator.cpp.udiff.html >> >> >> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/isGCActiveMark.hpp.udiff.html >> >> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/isGCActiveMark.cpp.html >> >> >> >> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.cpp.udiff.html >> >> >> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.hpp.udiff.html >> >> >> >> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/code/oopRecorder.hpp.udiff.html >> >> >> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/code/oopRecorder.inline.hpp.html >> >> >> I've tried to update all platforms, but would appreciate verification >> from platform maintainers that the changes don't break the build. >> >> I've also left some of the old names in JVMCI, to not disturb ongoing >> changes in that area. >> >> Thanks, >> StefanK From stefan.karlsson at oracle.com Thu May 2 14:17:11 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 2 May 2019 16:17:11 +0200 Subject: RFR: 8223136: Move compressed oops functions to CompressedOops class In-Reply-To: References: <61cb41e8-fcd5-845f-e57f-7a2d46c0c995@oracle.com> <612339e6-e693-c1c9-51f6-9316aa90874b@oracle.com> Message-ID: On 2019-05-02 16:12, coleen.phillimore at oracle.com wrote: > > Hi Stefan, This seems fine but I'd really like to have the #include > universe.hpp part of the patch broken out, as much as possible. OK. Thanks for the feedback. Let me work on that and get back to you with a few separate patches. Thanks, StefanK > > Thanks, > Coleen > > On 5/2/19 8:44 AM, Stefan Karlsson wrote: >> Hi all, >> >> Rebased on top of latest changes (jdk/jdk @ edd709e64ea1): >> ?http://cr.openjdk.java.net/~stefank/8223136/webrev.02/ >> >> Thanks, >> StefanK >> >> >> On 2019-04-30 10:58, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review this patch to move the rest of the compressed oops >>> functions and variables over to CompressedOops. >>> >>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01 >>> https://bugs.openjdk.java.net/browse/JDK-8223136 >>> >>> In 'JDK-8199946: Move load/store and encode/decode out of oopDesc' >>> the decoding and encoding of compressed oops were moved into the >>> namespace named CompressedOops. >>> >>> There infrastructure used by these functions were left in Universe. >>> This patch moves rest of the functions and variables over to >>> CompressedOops. I decided to convert the CompressedOops namespace >>> into a proper AllStatic class, to avoid any potential problems with >>> VMStructs. >>> >>> I also moved the corresponding functionality for compressed klass >>> pointers into a new class named CompressedKlassPointers. >>> >>> While doing this change I decided to cleanup the includes regarding >>> compressed oops, and universe.hpp, where most of the code was moved >>> from. Therefore, the patch is touching a large number of files. A >>> lot of the files contain updated header includes and simple renames. >>> If you want to fast-forward through those, these are the main files >>> where code related to compressed oops actually moved: >>> >>> >>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/universe.cpp.udiff.html >>> >>> >>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/universe.hpp.udiff.html >>> >>> >>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/compressedOops.hpp.html >>> >>> >>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/compressedOops.inline.hpp.udiff.html >>> >>> >>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/klass.cpp.udiff.html >>> >>> >>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/klass.hpp.udiff.html >>> >>> >>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/klass.inline.hpp.udiff.html >>> >>> >>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/oop.cpp.udiff.html >>> >>> >>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/oop.hpp.udiff.html >>> >>> >>> To get cleaner includes I did some minor restructuring to other >>> files. I can do these changes a small preparation patches, but would >>> like to get feedback on the overall patch first. >>> >>> Move flag checking out of hpp file, to stop propagation of >>> globals.hpp to all places where compressedOops.hpp is included: >>> >>> >>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.cpp.udiff.html >>> >>> >>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.hpp.udiff.html >>> >>> >>> Extract VerifyOption out of universe.hpp: >>> >>> >>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/verifyOption.hpp.html >>> >>> >>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/verifyOption.hpp.html >>> >>> >>> Moves a usage of CompressedOops to the cpp file: >>> >>> >>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/opto/matcher.cpp.udiff.html >>> >>> >>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/opto/matcher.hpp.udiff.html >>> >>> >>> Move Universe usage out of hpp files >>> >>> >>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/memAllocator.hpp.udiff.html >>> >>> >>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/memAllocator.cpp.udiff.html >>> >>> >>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/isGCActiveMark.hpp.udiff.html >>> >>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/isGCActiveMark.cpp.html >>> >>> >>> >>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.cpp.udiff.html >>> >>> >>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.hpp.udiff.html >>> >>> >>> >>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/code/oopRecorder.hpp.udiff.html >>> >>> >>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/code/oopRecorder.inline.hpp.html >>> >>> >>> I've tried to update all platforms, but would appreciate >>> verification from platform maintainers that the changes don't break >>> the build. >>> >>> I've also left some of the old names in JVMCI, to not disturb >>> ongoing changes in that area. >>> >>> Thanks, >>> StefanK > From vladimir.x.ivanov at oracle.com Thu May 2 16:26:20 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 2 May 2019 09:26:20 -0700 Subject: [EXT] Re: [13] RFR (M): 8223213: Implement fast class initialization checks on x86-64 In-Reply-To: References: <85a4a478-9200-87f2-c966-49af21f687c2@oracle.com> <37ee4fe8-d962-6e05-82f0-7258f5083459@oracle.com> Message-ID: <0201a50a-0006-1b28-9b7b-4ce5ed534795@oracle.com> Derek, > I want to be clear on the relationship between bugs and patches: > > 8223213 and patchset is intended to *replace* 8219233 and it's patchset, or be applied on top of it? > https://bugs.openjdk.java.net/browse/JDK-8223213, > https://bugs.openjdk.java.net/browse/JDK-8219233 The former: 8223213 supersedes 8219233 patchset. The plan is to use 8219233 as an umbrella for tracking the progress of relevant fixes and backports. Best regards, Vladimir Ivanov >> -----Original Message----- >> From: hotspot-dev On Behalf Of >> Claes Redestad >> Sent: Thursday, May 02, 2019 7:03 AM >> To: Vladimir Ivanov ; hotspot compiler >> ; hotspot-runtime-dev > runtime-dev at openjdk.java.net>; hotspot-dev developers > dev at openjdk.java.net> >> Subject: [EXT] Re: [13] RFR (M): 8223213: Implement fast class initialization >> checks on x86-64 >> >> External Email >> >> ---------------------------------------------------------------------- >> Hi Vladimir, >> >> On 2019-05-02 01:17, Vladimir Ivanov wrote: >>> Performance experiments with clojure [2] demonstrated that the fix >>> almost completely recuperates the regression: >>> >>> ? (1) always reresolve (w/o the fix):??? ~12,0s ( 1x) >>> ? (2) C1/C2 barriers only:??????????????? ~3,8s (~3x) >>> ? (3) int/C1/C2 barriers:???????????????? ~3,2s (-20%) >>> -------- >>> ? (4) barriers disabled for invokestatic? ~3,2s >> >> good stuff! >> >> Just to add a few data points I turned some of my earlier experiments to try >> and isolate some of these issues into a little stress test: >> >> BadStress[1]: >> 11.0.1: 136ms >> 11.0.2: 13500ms >> jdk/jdk baseline: 126ms >> jdk/jdk patched: 123ms >> >> GoodStress[2] (baseline): >> 11.0.1: 56ms >> 11.0.2: 54ms >> jdk/jdk baseline: 48ms >> jdk/jdk patched: 47ms >> >> Observations: >> >> - On latest jdk/jdk, we've already recuperated most of the cost exposed >> in these synthetic tests due related fixes (mainly >> https://bugs.openjdk.java.net/browse/JDK-8188133 and >> https://bugs.openjdk.java.net/browse/JDK-8219974 ), but the patch >> helps a bit here too and we're net faster than 11.0.1 (also when >> taking into account how startup in general has improved since) >> >> - The small 1ms startup improvement with the patch on the baseline test >> is sustained and significant, indicating we have some internal JDK >> classes exercised during bootstrap which benefit directly from your >> fixes. I've verified this improvement translates to all our other >> small-app startup tests. >> >> - My tests were too na?ve to capture all the overheads seen with clj >> >> - Likely still good performance advice to avoid heavy lifting in static >> initializers. >> >> All in all I think this is a great improvement and hope the added complexity is >> deemed acceptable. >> >> Thanks! >> >> /Claes >> >> [1] >> public class BadStress { >> static void foo() {} >> static void bar() {} >> public static class Helper { >> static void foo() { BadStress.foo(); } >> } >> static { >> long start = System.nanoTime(); >> for (int i = 0; i < 10_000_000; i++) { >> Helper.foo(); >> } >> for (int i = 0; i < 10_000_000; i++) { >> bar(); >> } >> long end = System.nanoTime(); >> System.out.println("Elapsed: " + (end - start) + " ns"); >> } >> public static void main(String... args) {} } >> >> [2] >> public class GoodStress { >> public static class Helper { >> static void foo() {} >> static void bar() {} >> } >> static { >> long start = System.nanoTime(); >> for (int i = 0; i < 10_000_000; i++) { >> Helper.foo(); >> } >> for (int i = 0; i < 10_000_000; i++) { >> Helper.bar(); >> } >> long end = System.nanoTime(); >> System.out.println("Elapsed: " + (end - start) + " ns"); >> } >> public static void main(String... args) {} } From stefan.karlsson at oracle.com Thu May 2 16:44:36 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 2 May 2019 18:44:36 +0200 Subject: RFR: 8223136: Move compressed oops functions to CompressedOops class In-Reply-To: References: <61cb41e8-fcd5-845f-e57f-7a2d46c0c995@oracle.com> <612339e6-e693-c1c9-51f6-9316aa90874b@oracle.com> Message-ID: The big patch has been split up into smaller patches: ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/01.compressed/ ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/02.verifyOption/ ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/03.isGCActiveMark/ ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/04.oopRecorder/ ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/05.memAllocator/ ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/06.oopFactory/ ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/07.oopsHierarchy/ ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/08.fixIncludes/ All patches together: ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/all/ Thanks, StefanK On 2019-05-02 16:17, Stefan Karlsson wrote: > On 2019-05-02 16:12, coleen.phillimore at oracle.com wrote: >> >> Hi Stefan, This seems fine but I'd really like to have the #include >> universe.hpp part of the patch broken out, as much as possible. > > OK. Thanks for the feedback. Let me work on that and get back to you > with a few separate patches. > > Thanks, > StefanK > >> >> Thanks, >> Coleen >> >> On 5/2/19 8:44 AM, Stefan Karlsson wrote: >>> Hi all, >>> >>> Rebased on top of latest changes (jdk/jdk @ edd709e64ea1): >>> ?http://cr.openjdk.java.net/~stefank/8223136/webrev.02/ >>> >>> Thanks, >>> StefanK >>> >>> >>> On 2019-04-30 10:58, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> Please review this patch to move the rest of the compressed oops >>>> functions and variables over to CompressedOops. >>>> >>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01 >>>> https://bugs.openjdk.java.net/browse/JDK-8223136 >>>> >>>> In 'JDK-8199946: Move load/store and encode/decode out of oopDesc' >>>> the decoding and encoding of compressed oops were moved into the >>>> namespace named CompressedOops. >>>> >>>> There infrastructure used by these functions were left in Universe. >>>> This patch moves rest of the functions and variables over to >>>> CompressedOops. I decided to convert the CompressedOops namespace >>>> into a proper AllStatic class, to avoid any potential problems with >>>> VMStructs. >>>> >>>> I also moved the corresponding functionality for compressed klass >>>> pointers into a new class named CompressedKlassPointers. >>>> >>>> While doing this change I decided to cleanup the includes regarding >>>> compressed oops, and universe.hpp, where most of the code was moved >>>> from. Therefore, the patch is touching a large number of files. A >>>> lot of the files contain updated header includes and simple >>>> renames. If you want to fast-forward through those, these are the >>>> main files where code related to compressed oops actually moved: >>>> >>>> >>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/universe.cpp.udiff.html >>>> >>>> >>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/universe.hpp.udiff.html >>>> >>>> >>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/compressedOops.hpp.html >>>> >>>> >>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/compressedOops.inline.hpp.udiff.html >>>> >>>> >>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/klass.cpp.udiff.html >>>> >>>> >>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/klass.hpp.udiff.html >>>> >>>> >>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/klass.inline.hpp.udiff.html >>>> >>>> >>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/oop.cpp.udiff.html >>>> >>>> >>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/oop.hpp.udiff.html >>>> >>>> >>>> To get cleaner includes I did some minor restructuring to other >>>> files. I can do these changes a small preparation patches, but >>>> would like to get feedback on the overall patch first. >>>> >>>> Move flag checking out of hpp file, to stop propagation of >>>> globals.hpp to all places where compressedOops.hpp is included: >>>> >>>> >>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.cpp.udiff.html >>>> >>>> >>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.hpp.udiff.html >>>> >>>> >>>> Extract VerifyOption out of universe.hpp: >>>> >>>> >>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/verifyOption.hpp.html >>>> >>>> >>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/verifyOption.hpp.html >>>> >>>> >>>> Moves a usage of CompressedOops to the cpp file: >>>> >>>> >>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/opto/matcher.cpp.udiff.html >>>> >>>> >>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/opto/matcher.hpp.udiff.html >>>> >>>> >>>> Move Universe usage out of hpp files >>>> >>>> >>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/memAllocator.hpp.udiff.html >>>> >>>> >>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/memAllocator.cpp.udiff.html >>>> >>>> >>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/isGCActiveMark.hpp.udiff.html >>>> >>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/isGCActiveMark.cpp.html >>>> >>>> >>>> >>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.cpp.udiff.html >>>> >>>> >>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.hpp.udiff.html >>>> >>>> >>>> >>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/code/oopRecorder.hpp.udiff.html >>>> >>>> >>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/code/oopRecorder.inline.hpp.html >>>> >>>> >>>> I've tried to update all platforms, but would appreciate >>>> verification from platform maintainers that the changes don't break >>>> the build. >>>> >>>> I've also left some of the old names in JVMCI, to not disturb >>>> ongoing changes in that area. >>>> >>>> Thanks, >>>> StefanK >> > From kim.barrett at oracle.com Thu May 2 17:02:15 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 2 May 2019 13:02:15 -0400 Subject: RFR (L, tedious) 8222811: Consolidate MutexLockerEx and MutexLocker In-Reply-To: <8cb48709-fc4a-486e-d406-813b87edbfb5@oracle.com> References: <614f0e46-c4ce-d389-88f9-1a73e14fc5dd@oracle.com> <3aab6fa3-04e3-47e2-ea34-b4c0b997e44f@oracle.com> <302fcf8c-35f6-d5a3-2128-a949150583bf@oracle.com> <4396d1dd-25f9-c5ec-4f95-d8f31a260345@oracle.com> <8cb48709-fc4a-486e-d406-813b87edbfb5@oracle.com> Message-ID: <1B620782-F4B4-43BF-B7CC-9B32B42FD7E9@oracle.com> > On Apr 24, 2019, at 8:14 AM, David Holmes wrote: > > On 24/04/2019 9:23 pm, coleen.phillimore at oracle.com wrote: >> On 4/23/19 9:48 PM, David Holmes wrote: >>> I couldn't easily see how often you used this new constructor, but avoiding an unnecessary call to Thread::current() is good. However the duplicated code in the two constructors is not good and they differ only in the "thread" argument use. I don't know how C++ does constructor chaining but the no-thread version should just call the thread-taking version passing Thread::current() - or fact the body into a helper. Can I also request that the "thread" parameter be renamed "currentThread" (we're far too lax when it comes to clearly identifying when a Thread* must be the current thread) - thanks. >> I tried to do this but calling Thread::current() in the constructor and having a common initialize function, required including thread.hpp into mutex.hpp which then make it circular. In the end the duplicated code was preferrable to any tricks I could find. > > That's a shame. If Kim were around he might be able to suggest a trick :) What you are looking for here is constructor delegation, a C++11 feature. From david.holmes at oracle.com Fri May 3 02:30:13 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 3 May 2019 12:30:13 +1000 Subject: RFR (S): 8222534: VerifyBeforeExit is not honored when System.exit is called In-Reply-To: References: <94327eae-0553-a346-bc4f-e0ff8ffa7ce5@oracle.com> <3bf1af77-83d3-04b4-20b5-6950de1d5e5c@oracle.com> Message-ID: <57a52547-ee3e-0479-6a1d-2e22f2b0fb36@oracle.com> Coleen, Robbin (anyone else) Could you please review the final version of this. In summary the changes are: - Add the VerifyBeforeExit logic, together with acquisition of the Heap_lock by the JavaThread before initiating the terminal safepoint. - Add the missing LogConfiguration::finalize(); - Document why we can't perform XML termination processing for the xtty or IdealGraphPrinter (the comments are placed where the code would be if we could do it) Thanks, David On 1/05/2019 1:42 pm, David Holmes wrote: > Hi Coleen, > > On 1/05/2019 7:59 am, coleen.phillimore at oracle.com wrote: >> >> David, Thank you for the writeup of the exit paths. >> >> The reason I added this test with JDK-9074355 is because taking the >> Heap_lock in destroy_vm prevented a crash in VerifyBeforeExit. >> >> http://cr.openjdk.java.net/~coleenp/2019/8074355.06/webrev/test/hotspot/jtreg/runtime/Shutdown/ShutdownTest.java.html >> >> >> I wonder if you need to take the Heap_lock in the VM_Exit path as well. > > Yes you are right. Sorry I was focusing on the wrong aspect of that > discussion. I've updated the v2 webrev in place as java.cpp is now back > in it. I will also update the exit path document to show the taking of > the Heap_lock. > > http://cr.openjdk.java.net/~dholmes/8222534/webrev.v2/ > > Re-testing in mach5 underway - though it probably won't be testing > VerifyBeforeExit. > > I'm assuming, based on the fact the destroy_JavaVM path doesn't hang, > that taking the Heap_lock can't succeed until there are no GC safepoint > ops queued, and conversely once taken no GC safepoint ops will queue (or > if they do they won't block trying to take the heap lock!)? > > This bug has turned out to be far more complex than originally > anticipated :) Seems there are numerous reasons why various actions are > not on the vm_exit() path! I only wish someone had documented why they > were missing in the first place. So I added a comment about the xtty > logging problem in java.cpp (now that it's back in the change). > > Thanks, > David > >> >> Coleen >> >> On 4/29/19 11:54 PM, David Holmes wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222534 >>> Webrev: http://cr.openjdk.java.net/~dholmes/8222534/webrev/ >>> >>> Stefan noticed that VerifyBeforeExit was not honoured when a Java >>> application terminates via System.exit. >>> >>> Examination of the exit code sequences revealed four differences >>> between an exit due to the last non-daemon thread terminating >>> (handled via jni_DestroyJavaVM) and a call to System.exit() (handled >>> via JVM_Halt()). There are four missing actions on the System.exit() >>> path: >>> >>> - No processing of VerifyBeforeExit >>> - No XML logging before exit >>> - No LogConfiguration::finalize() >>> - No IdealGraphPrinter::clean_up() >>> >>> The first three have now been added at the appropriate point. >>> VerifyBefore exit was the main omission. The compiler team? (i.e. >>> Vladimir K.) indicated they'd also like the XML logging. And the >>> LogConfiguration::finalize while possibly not essential avoids any >>> doubt as to whether buffered log output may get lost. >>> >>> The IdealGraphPrinter::cleanup was deemed unnecessary due to the fact >>> the process is being blown away anyway. >>> >>> The bug report contains a lot of details on the exit sequences >>> including a side-by-side comparison in the attached pdf, showing the >>> relative positioning of each action and that the correct order has >>> been maintained. >>> >>> The vm_exit() code affects a number of "abrupt" exit paths in the VM, >>> not just JVM_Halt, and this is discussed in the bug report as well. >>> In short the addition of the missing actions should not cause any >>> issues. >>> >>> Testing: >>> ?- some manual checking of exit paths and whether new code was executed >>> ?- all hotspot/jtreg/gc tests with -XX:+VerifyBeforeExit added >>> ?- mach5 tiers 1-3 >>> >>> Thanks, >>> David >> From robbin.ehn at oracle.com Fri May 3 07:04:05 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 3 May 2019 09:04:05 +0200 Subject: RFR (S): 8222534: VerifyBeforeExit is not honored when System.exit is called In-Reply-To: <57a52547-ee3e-0479-6a1d-2e22f2b0fb36@oracle.com> References: <94327eae-0553-a346-bc4f-e0ff8ffa7ce5@oracle.com> <3bf1af77-83d3-04b4-20b5-6950de1d5e5c@oracle.com> <57a52547-ee3e-0479-6a1d-2e22f2b0fb36@oracle.com> Message-ID: <61dae955-b072-0daa-f915-7f714f24c57e@oracle.com> Hi David, Looks good. Thanks, Robbin On 5/3/19 4:30 AM, David Holmes wrote: > Coleen, Robbin (anyone else) > > Could you please review the final version of this. In summary the changes are: > > - Add the VerifyBeforeExit logic, together with acquisition of the Heap_lock by > the JavaThread before initiating the terminal safepoint. > - Add the missing LogConfiguration::finalize(); > - Document why we can't perform XML termination processing for the xtty or > IdealGraphPrinter (the comments are placed where the code would be if we could > do it) > > Thanks, > David > > On 1/05/2019 1:42 pm, David Holmes wrote: >> Hi Coleen, >> >> On 1/05/2019 7:59 am, coleen.phillimore at oracle.com wrote: >>> >>> David, Thank you for the writeup of the exit paths. >>> >>> The reason I added this test with JDK-9074355 is because taking the Heap_lock >>> in destroy_vm prevented a crash in VerifyBeforeExit. >>> >>> http://cr.openjdk.java.net/~coleenp/2019/8074355.06/webrev/test/hotspot/jtreg/runtime/Shutdown/ShutdownTest.java.html >>> >>> >>> I wonder if you need to take the Heap_lock in the VM_Exit path as well. >> >> Yes you are right. Sorry I was focusing on the wrong aspect of that >> discussion. I've updated the v2 webrev in place as java.cpp is now back in it. >> I will also update the exit path document to show the taking of the Heap_lock. >> >> http://cr.openjdk.java.net/~dholmes/8222534/webrev.v2/ >> >> Re-testing in mach5 underway - though it probably won't be testing >> VerifyBeforeExit. >> >> I'm assuming, based on the fact the destroy_JavaVM path doesn't hang, that >> taking the Heap_lock can't succeed until there are no GC safepoint ops queued, >> and conversely once taken no GC safepoint ops will queue (or if they do they >> won't block trying to take the heap lock!)? >> >> This bug has turned out to be far more complex than originally anticipated :) >> Seems there are numerous reasons why various actions are not on the vm_exit() >> path! I only wish someone had documented why they were missing in the first >> place. So I added a comment about the xtty logging problem in java.cpp (now >> that it's back in the change). >> >> Thanks, >> David >> >>> >>> Coleen >>> >>> On 4/29/19 11:54 PM, David Holmes wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222534 >>>> Webrev: http://cr.openjdk.java.net/~dholmes/8222534/webrev/ >>>> >>>> Stefan noticed that VerifyBeforeExit was not honoured when a Java >>>> application terminates via System.exit. >>>> >>>> Examination of the exit code sequences revealed four differences between an >>>> exit due to the last non-daemon thread terminating (handled via >>>> jni_DestroyJavaVM) and a call to System.exit() (handled via JVM_Halt()). >>>> There are four missing actions on the System.exit() path: >>>> >>>> - No processing of VerifyBeforeExit >>>> - No XML logging before exit >>>> - No LogConfiguration::finalize() >>>> - No IdealGraphPrinter::clean_up() >>>> >>>> The first three have now been added at the appropriate point. VerifyBefore >>>> exit was the main omission. The compiler team? (i.e. Vladimir K.) indicated >>>> they'd also like the XML logging. And the LogConfiguration::finalize while >>>> possibly not essential avoids any doubt as to whether buffered log output >>>> may get lost. >>>> >>>> The IdealGraphPrinter::cleanup was deemed unnecessary due to the fact the >>>> process is being blown away anyway. >>>> >>>> The bug report contains a lot of details on the exit sequences including a >>>> side-by-side comparison in the attached pdf, showing the relative >>>> positioning of each action and that the correct order has been maintained. >>>> >>>> The vm_exit() code affects a number of "abrupt" exit paths in the VM, not >>>> just JVM_Halt, and this is discussed in the bug report as well. In short the >>>> addition of the missing actions should not cause any issues. >>>> >>>> Testing: >>>> ?- some manual checking of exit paths and whether new code was executed >>>> ?- all hotspot/jtreg/gc tests with -XX:+VerifyBeforeExit added >>>> ?- mach5 tiers 1-3 >>>> >>>> Thanks, >>>> David >>> From david.holmes at oracle.com Fri May 3 07:07:30 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 3 May 2019 17:07:30 +1000 Subject: RFR (S): 8222534: VerifyBeforeExit is not honored when System.exit is called In-Reply-To: <61dae955-b072-0daa-f915-7f714f24c57e@oracle.com> References: <94327eae-0553-a346-bc4f-e0ff8ffa7ce5@oracle.com> <3bf1af77-83d3-04b4-20b5-6950de1d5e5c@oracle.com> <57a52547-ee3e-0479-6a1d-2e22f2b0fb36@oracle.com> <61dae955-b072-0daa-f915-7f714f24c57e@oracle.com> Message-ID: <514a54d1-1b99-8c28-81bf-14e3544f53b7@oracle.com> Thanks Robbin! David On 3/05/2019 5:04 pm, Robbin Ehn wrote: > Hi David, > > Looks good. > > Thanks, Robbin > > On 5/3/19 4:30 AM, David Holmes wrote: >> Coleen, Robbin (anyone else) >> >> Could you please review the final version of this. In summary the >> changes are: >> >> - Add the VerifyBeforeExit logic, together with acquisition of the >> Heap_lock by the JavaThread before initiating the terminal safepoint. >> - Add the missing LogConfiguration::finalize(); >> - Document why we can't perform XML termination processing for the >> xtty or IdealGraphPrinter (the comments are placed where the code >> would be if we could do it) >> >> Thanks, >> David >> >> On 1/05/2019 1:42 pm, David Holmes wrote: >>> Hi Coleen, >>> >>> On 1/05/2019 7:59 am, coleen.phillimore at oracle.com wrote: >>>> >>>> David, Thank you for the writeup of the exit paths. >>>> >>>> The reason I added this test with JDK-9074355 is because taking the >>>> Heap_lock in destroy_vm prevented a crash in VerifyBeforeExit. >>>> >>>> http://cr.openjdk.java.net/~coleenp/2019/8074355.06/webrev/test/hotspot/jtreg/runtime/Shutdown/ShutdownTest.java.html >>>> >>>> >>>> I wonder if you need to take the Heap_lock in the VM_Exit path as well. >>> >>> Yes you are right. Sorry I was focusing on the wrong aspect of that >>> discussion. I've updated the v2 webrev in place as java.cpp is now >>> back in it. I will also update the exit path document to show the >>> taking of the Heap_lock. >>> >>> http://cr.openjdk.java.net/~dholmes/8222534/webrev.v2/ >>> >>> Re-testing in mach5 underway - though it probably won't be testing >>> VerifyBeforeExit. >>> >>> I'm assuming, based on the fact the destroy_JavaVM path doesn't hang, >>> that taking the Heap_lock can't succeed until there are no GC >>> safepoint ops queued, and conversely once taken no GC safepoint ops >>> will queue (or if they do they won't block trying to take the heap >>> lock!)? >>> >>> This bug has turned out to be far more complex than originally >>> anticipated :) Seems there are numerous reasons why various actions >>> are not on the vm_exit() path! I only wish someone had documented why >>> they were missing in the first place. So I added a comment about the >>> xtty logging problem in java.cpp (now that it's back in the change). >>> >>> Thanks, >>> David >>> >>>> >>>> Coleen >>>> >>>> On 4/29/19 11:54 PM, David Holmes wrote: >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222534 >>>>> Webrev: http://cr.openjdk.java.net/~dholmes/8222534/webrev/ >>>>> >>>>> Stefan noticed that VerifyBeforeExit was not honoured when a Java >>>>> application terminates via System.exit. >>>>> >>>>> Examination of the exit code sequences revealed four differences >>>>> between an exit due to the last non-daemon thread terminating >>>>> (handled via jni_DestroyJavaVM) and a call to System.exit() >>>>> (handled via JVM_Halt()). There are four missing actions on the >>>>> System.exit() path: >>>>> >>>>> - No processing of VerifyBeforeExit >>>>> - No XML logging before exit >>>>> - No LogConfiguration::finalize() >>>>> - No IdealGraphPrinter::clean_up() >>>>> >>>>> The first three have now been added at the appropriate point. >>>>> VerifyBefore exit was the main omission. The compiler team? (i.e. >>>>> Vladimir K.) indicated they'd also like the XML logging. And the >>>>> LogConfiguration::finalize while possibly not essential avoids any >>>>> doubt as to whether buffered log output may get lost. >>>>> >>>>> The IdealGraphPrinter::cleanup was deemed unnecessary due to the >>>>> fact the process is being blown away anyway. >>>>> >>>>> The bug report contains a lot of details on the exit sequences >>>>> including a side-by-side comparison in the attached pdf, showing >>>>> the relative positioning of each action and that the correct order >>>>> has been maintained. >>>>> >>>>> The vm_exit() code affects a number of "abrupt" exit paths in the >>>>> VM, not just JVM_Halt, and this is discussed in the bug report as >>>>> well. In short the addition of the missing actions should not cause >>>>> any issues. >>>>> >>>>> Testing: >>>>> ?- some manual checking of exit paths and whether new code was >>>>> executed >>>>> ?- all hotspot/jtreg/gc tests with -XX:+VerifyBeforeExit added >>>>> ?- mach5 tiers 1-3 >>>>> >>>>> Thanks, >>>>> David >>>> From aph at redhat.com Fri May 3 07:49:03 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 3 May 2019 08:49:03 +0100 Subject: RFR: 8223089: Stack alignment for x86-32 In-Reply-To: <87ef5hxfa0.fsf@oldenburg2.str.redhat.com> References: <481b88c2-1243-2990-6898-d5fe3108eb2d@redhat.com> <87ef5hxfa0.fsf@oldenburg2.str.redhat.com> Message-ID: On 5/2/19 12:32 PM, Florian Weimer wrote: > If you want to compile Hotspot with SSE2, you will have to realign the > stack when JNI code calls back into Hotspot. Otherwose, you lose > support for legacy JNI libraries which do not preserve stack alignment > (as required after that silent ABI bump). I'm surprised that's a problem, really. > Supporting such legacy code is the reason why the system libraries in > our distribution do not require stack realignment on i386, so compiling > Hotspot without SSE2 would also avoid the problem there, even if Hotspot > code calls such function such as malloc in response to requests from JNI > code. What about other distros, though? Aren't we just playing with fire? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From fweimer at redhat.com Fri May 3 08:02:48 2019 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 03 May 2019 10:02:48 +0200 Subject: RFR: 8223089: Stack alignment for x86-32 In-Reply-To: (Andrew Haley's message of "Fri, 3 May 2019 08:49:03 +0100") References: <481b88c2-1243-2990-6898-d5fe3108eb2d@redhat.com> <87ef5hxfa0.fsf@oldenburg2.str.redhat.com> Message-ID: <878svoufrr.fsf@oldenburg2.str.redhat.com> * Andrew Haley: > On 5/2/19 12:32 PM, Florian Weimer wrote: >> If you want to compile Hotspot with SSE2, you will have to realign the >> stack when JNI code calls back into Hotspot. Otherwose, you lose >> support for legacy JNI libraries which do not preserve stack alignment >> (as required after that silent ABI bump). > > I'm surprised that's a problem, really. I expect it will be, for some people. >> Supporting such legacy code is the reason why the system libraries in >> our distribution do not require stack realignment on i386, so compiling >> Hotspot without SSE2 would also avoid the problem there, even if Hotspot >> code calls such function such as malloc in response to requests from JNI >> code. > > What about other distros, though? Most other distributions do not build system libraries with SSE2 (via -march=x86-64), and they generally do not build Hotspot with SSE2 support either. The reason is that they still want backwards compatibility with really old CPUs that do not support 64-bit mode and thus do not necessarily support SSE2. Any distribution that wishes to use -march=x86-64 or something newer will eventually end up with what Fedora (and downstream) is doing. I don't think there are many other options if you want SSE2 and backwards compatibility. And if a distribution does not care about compatibility, I don't think it will matter how they build Hotspot. > Aren't we just playing with fire? We've been doing that since the silent i386 ABI bump for SSE2 and stack alignment. This is nothing new at all. Newer GCC versions generate more SSE2 code and therefore more SSE2 stack spills, so the issue becomes more and more visible. Thanks, Florian From coleen.phillimore at oracle.com Fri May 3 14:56:24 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 3 May 2019 10:56:24 -0400 Subject: RFR (S): 8222534: VerifyBeforeExit is not honored when System.exit is called In-Reply-To: References: <94327eae-0553-a346-bc4f-e0ff8ffa7ce5@oracle.com> <3bf1af77-83d3-04b4-20b5-6950de1d5e5c@oracle.com> Message-ID: On 4/30/19 11:42 PM, David Holmes wrote: > Hi Coleen, > > On 1/05/2019 7:59 am, coleen.phillimore at oracle.com wrote: >> >> David, Thank you for the writeup of the exit paths. >> >> The reason I added this test with JDK-9074355 is because taking the >> Heap_lock in destroy_vm prevented a crash in VerifyBeforeExit. >> >> http://cr.openjdk.java.net/~coleenp/2019/8074355.06/webrev/test/hotspot/jtreg/runtime/Shutdown/ShutdownTest.java.html >> >> >> I wonder if you need to take the Heap_lock in the VM_Exit path as well. > > Yes you are right. Sorry I was focusing on the wrong aspect of that > discussion. I've updated the v2 webrev in place as java.cpp is now > back in it. I will also update the exit path document to show the > taking of the Heap_lock. > > http://cr.openjdk.java.net/~dholmes/8222534/webrev.v2/ > > Re-testing in mach5 underway - though it probably won't be testing > VerifyBeforeExit. I thought this change would enable VerifyBeforeExit with all our testing because it's trueInDebug and now on the exit path? > > I'm assuming, based on the fact the destroy_JavaVM path doesn't hang, > that taking the Heap_lock can't succeed until there are no GC > safepoint ops queued, and conversely once taken no GC safepoint ops > will queue (or if they do they won't block trying to take the heap > lock!)? > I believe this is the effect. I'm having trouble with control flow.?? In destroy_vm() the Heap_lock is taken after that JavaThread is removed from the thread list, so we have a _no_safepoint_check_flag.?? In this place, from debugging the thread is on the threads list, so safepoint checking is ok. http://cr.openjdk.java.net/~dholmes/8222534/webrev.v2/src/hotspot/share/runtime/java.cpp.frames.html 536 VM_Exit op(code); Can this line be after the Heap_lock acquisition or does the Heap_lock make this operation wait until GC is done to queue?? ie it's this line, and not this one that we're blocking GC for: 548 VMThread::execute(&op); Also, aside. 546 if (thread->is_Java_thread()) 547 ((JavaThread*)thread)->set_thread_state(_thread_in_vm); Not your change but this is surprising.? I wonder why this is? > This bug has turned out to be far more complex than originally > anticipated :) Seems there are numerous reasons why various actions > are not on the vm_exit() path! I only wish someone had documented why > they were missing in the first place. So I added a comment about the > xtty logging problem in java.cpp (now that it's back in the change). > Thank you for all the comments.? This code is full of land mines without them. Looks good aside from questions. Coleen > Thanks, > David > >> >> Coleen >> >> On 4/29/19 11:54 PM, David Holmes wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222534 >>> Webrev: http://cr.openjdk.java.net/~dholmes/8222534/webrev/ >>> >>> Stefan noticed that VerifyBeforeExit was not honoured when a Java >>> application terminates via System.exit. >>> >>> Examination of the exit code sequences revealed four differences >>> between an exit due to the last non-daemon thread terminating >>> (handled via jni_DestroyJavaVM) and a call to System.exit() (handled >>> via JVM_Halt()). There are four missing actions on the System.exit() >>> path: >>> >>> - No processing of VerifyBeforeExit >>> - No XML logging before exit >>> - No LogConfiguration::finalize() >>> - No IdealGraphPrinter::clean_up() >>> >>> The first three have now been added at the appropriate point. >>> VerifyBefore exit was the main omission. The compiler team (i.e. >>> Vladimir K.) indicated they'd also like the XML logging. And the >>> LogConfiguration::finalize while possibly not essential avoids any >>> doubt as to whether buffered log output may get lost. >>> >>> The IdealGraphPrinter::cleanup was deemed unnecessary due to the >>> fact the process is being blown away anyway. >>> >>> The bug report contains a lot of details on the exit sequences >>> including a side-by-side comparison in the attached pdf, showing the >>> relative positioning of each action and that the correct order has >>> been maintained. >>> >>> The vm_exit() code affects a number of "abrupt" exit paths in the >>> VM, not just JVM_Halt, and this is discussed in the bug report as >>> well. In short the addition of the missing actions should not cause >>> any issues. >>> >>> Testing: >>> ?- some manual checking of exit paths and whether new code was executed >>> ?- all hotspot/jtreg/gc tests with -XX:+VerifyBeforeExit added >>> ?- mach5 tiers 1-3 >>> >>> Thanks, >>> David >> From sgehwolf at redhat.com Fri May 3 16:35:42 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 03 May 2019 18:35:42 +0200 Subject: [8u] RFR: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization Message-ID: Hi, Could I please get reviews for this 8u backport of an optimization fix pertaining to the hotspot copy of fdlibm? Historically, sharedRuntimeTrans.cpp and sharedRuntimeTrig.cpp have been compiled with optimization turned off on x86/x86_64. As JDK-8210416 will be backported to JDK 8u fixing optimization for fdlibm itself, so should be the hotspot copy in OpenJDK 8u. The build system for hotspot in JDK 8u is very different, so the original fix for JDK 12 doesn't apply. It's a complete rewrite. Please see this webrev which shows the prerequisite patch. It adds the FDLIBM_CFLAGS logic: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/jdk8/02/ It also fixes a bug on ppc64{,le} where optimization is being turned on in hotspot (-O3), but not providing the -ffp-contract=off flag (or older equivalent). Before (on ppc64le): /bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. -I/home/openjdk/jdk8u/hotspot/src/share/vm/prims -I/home/openjdk/jdk8u/hotspot/src/share/vm -I/home/openjdk/jdk8u/hotspot/src/share/vm/precompiled -I/home/openjdk/jdk8u/hotspot/src/cpu/ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os_cpu/linux_ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os/linux/vm -I/home/openjdk/jdk8u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.212-b04\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"openjdk\"" -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3 -g -D_LP64=1 -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8 -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -std=gnu++98 -c -MMD -MP -MF ../generated/dependencies/sharedRuntimeTrig.o.d -fpch-deps -o sharedRuntimeTrig.o /home/openjdk/jdk8u/hotspot/src/share/vm/runtime/sharedRuntimeTrig.cpp After (on ppc64le; Note -ffp-contract=off flag): /bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. -I/home/openjdk/jdk8u/hotspot/src/share/vm/prims -I/home/openjdk/jdk8u/hotspot/src/share/vm -I/home/openjdk/jdk8u/hotspot/src/share/vm/precompiled -I/home/openjdk/jdk8u/hotspot/src/cpu/ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os_cpu/linux_ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os/linux/vm -I/home/openjdk/jdk8u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.212-b04\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"openjdk\"" -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3 -ffp-contract=off -D_LP64=1 -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8 -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -std=gnu++98 -c -MMD -MP -MF ../generated/dependencies/sharedRuntimeTrig.o.d -fpch-deps -o sharedRuntimeTrig.o /home/openjdk/jdk8u/hotspot/src/share/vm/runtime/sharedRuntimeTrig.cpp Bug: https://bugs.openjdk.java.net/browse/JDK-8210425 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/jdk8/02/webrev Testing: Builds on x86_64 (server/Zero). Manual inspection of compile log of sharedRuntimeTrans.cpp/sharedRuntimeTrig.cpp. Same for ppc64le. Note that we've been using this patch downstream for a while now. We haven't seen any issues so far. Thanks, Severin From david.holmes at oracle.com Fri May 3 23:45:14 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 4 May 2019 09:45:14 +1000 Subject: RFR (S): 8222534: VerifyBeforeExit is not honored when System.exit is called In-Reply-To: References: <94327eae-0553-a346-bc4f-e0ff8ffa7ce5@oracle.com> <3bf1af77-83d3-04b4-20b5-6950de1d5e5c@oracle.com> Message-ID: <4cb4ab9b-4ed9-ea7f-5823-baa4c06ded59@oracle.com> Hi Coleen, On 4/05/2019 12:56 am, coleen.phillimore at oracle.com wrote: > On 4/30/19 11:42 PM, David Holmes wrote: >> Hi Coleen, >> >> On 1/05/2019 7:59 am, coleen.phillimore at oracle.com wrote: >>> >>> David, Thank you for the writeup of the exit paths. >>> >>> The reason I added this test with JDK-9074355 is because taking the >>> Heap_lock in destroy_vm prevented a crash in VerifyBeforeExit. >>> >>> http://cr.openjdk.java.net/~coleenp/2019/8074355.06/webrev/test/hotspot/jtreg/runtime/Shutdown/ShutdownTest.java.html >>> >>> >>> I wonder if you need to take the Heap_lock in the VM_Exit path as well. >> >> Yes you are right. Sorry I was focusing on the wrong aspect of that >> discussion. I've updated the v2 webrev in place as java.cpp is now >> back in it. I will also update the exit path document to show the >> taking of the Heap_lock. >> >> http://cr.openjdk.java.net/~dholmes/8222534/webrev.v2/ >> >> Re-testing in mach5 underway - though it probably won't be testing >> VerifyBeforeExit. > > I thought this change would enable VerifyBeforeExit with all our testing > because it's trueInDebug and now on the exit path? You are right - I forgot about trueInDebug. >> >> I'm assuming, based on the fact the destroy_JavaVM path doesn't hang, >> that taking the Heap_lock can't succeed until there are no GC >> safepoint ops queued, and conversely once taken no GC safepoint ops >> will queue (or if they do they won't block trying to take the heap >> lock!)? >> > I believe this is the effect. > > I'm having trouble with control flow.?? In destroy_vm() the Heap_lock is > taken after that JavaThread is removed from the thread list, so we have > a _no_safepoint_check_flag.?? In this place, from debugging the thread > is on the threads list, so safepoint checking is ok. > > http://cr.openjdk.java.net/~dholmes/8222534/webrev.v2/src/hotspot/share/runtime/java.cpp.frames.html Not only okay but essential - you will get deadlocks if you try to take without safepoint check (been there done that :) ). And yes this is just a normal live JavaThread executing normally so it has to check safepoints. > 536 VM_Exit op(code); > > Can this line be after the Heap_lock acquisition or does the Heap_lock > make this operation wait until GC is done to queue?? ie it's this line, > and not this one that we're blocking GC for: > > 548 VMThread::execute(&op); We need the heap_lock before line #548 - which never returns. The declaration of the VM_Exit op and the taking of the heap lock can occur in either order. > > Also, aside. > > 546 if (thread->is_Java_thread()) > 547 ((JavaThread*)thread)->set_thread_state(_thread_in_vm); > > Not your change but this is surprising.? I wonder why this is? VMThread::execute (and subsequent code) will expect it ... oh! Shoot! So will trying to take the heap_lock :( I need to move that higher up. I'm assuming that some of the paths to vm_exit may not have the thread "in_vm" - or at least at some point in time there was such a path. I'll do some archaeology on that. Thanks Coleen! David > >> This bug has turned out to be far more complex than originally >> anticipated :) Seems there are numerous reasons why various actions >> are not on the vm_exit() path! I only wish someone had documented why >> they were missing in the first place. So I added a comment about the >> xtty logging problem in java.cpp (now that it's back in the change). >> > > Thank you for all the comments.? This code is full of land mines without > them. > > Looks good aside from questions. > > Coleen > >> Thanks, >> David >> >>> >>> Coleen >>> >>> On 4/29/19 11:54 PM, David Holmes wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222534 >>>> Webrev: http://cr.openjdk.java.net/~dholmes/8222534/webrev/ >>>> >>>> Stefan noticed that VerifyBeforeExit was not honoured when a Java >>>> application terminates via System.exit. >>>> >>>> Examination of the exit code sequences revealed four differences >>>> between an exit due to the last non-daemon thread terminating >>>> (handled via jni_DestroyJavaVM) and a call to System.exit() (handled >>>> via JVM_Halt()). There are four missing actions on the System.exit() >>>> path: >>>> >>>> - No processing of VerifyBeforeExit >>>> - No XML logging before exit >>>> - No LogConfiguration::finalize() >>>> - No IdealGraphPrinter::clean_up() >>>> >>>> The first three have now been added at the appropriate point. >>>> VerifyBefore exit was the main omission. The compiler team (i.e. >>>> Vladimir K.) indicated they'd also like the XML logging. And the >>>> LogConfiguration::finalize while possibly not essential avoids any >>>> doubt as to whether buffered log output may get lost. >>>> >>>> The IdealGraphPrinter::cleanup was deemed unnecessary due to the >>>> fact the process is being blown away anyway. >>>> >>>> The bug report contains a lot of details on the exit sequences >>>> including a side-by-side comparison in the attached pdf, showing the >>>> relative positioning of each action and that the correct order has >>>> been maintained. >>>> >>>> The vm_exit() code affects a number of "abrupt" exit paths in the >>>> VM, not just JVM_Halt, and this is discussed in the bug report as >>>> well. In short the addition of the missing actions should not cause >>>> any issues. >>>> >>>> Testing: >>>> ?- some manual checking of exit paths and whether new code was executed >>>> ?- all hotspot/jtreg/gc tests with -XX:+VerifyBeforeExit added >>>> ?- mach5 tiers 1-3 >>>> >>>> Thanks, >>>> David >>> > From david.holmes at oracle.com Sat May 4 06:09:27 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 4 May 2019 16:09:27 +1000 Subject: RFR (S): 8222534: VerifyBeforeExit is not honored when System.exit is called In-Reply-To: <4cb4ab9b-4ed9-ea7f-5823-baa4c06ded59@oracle.com> References: <94327eae-0553-a346-bc4f-e0ff8ffa7ce5@oracle.com> <3bf1af77-83d3-04b4-20b5-6950de1d5e5c@oracle.com> <4cb4ab9b-4ed9-ea7f-5823-baa4c06ded59@oracle.com> Message-ID: Updated webrev: http://cr.openjdk.java.net/~dholmes/8222534/webrev.v2/ The historic setting of the thread state to _thread_in_vm is moved ahead of the taking of the heap_lock. That logic has been there since "exit at a safepoint" was introduced by JDK-4526887, and there's nothing to tell you how we might get there in a different state. To be safe I've left it and added a comment. Thanks, David On 4/05/2019 9:45 am, David Holmes wrote: > Hi Coleen, > > On 4/05/2019 12:56 am, coleen.phillimore at oracle.com wrote: >> On 4/30/19 11:42 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 1/05/2019 7:59 am, coleen.phillimore at oracle.com wrote: >>>> >>>> David, Thank you for the writeup of the exit paths. >>>> >>>> The reason I added this test with JDK-9074355 is because taking the >>>> Heap_lock in destroy_vm prevented a crash in VerifyBeforeExit. >>>> >>>> http://cr.openjdk.java.net/~coleenp/2019/8074355.06/webrev/test/hotspot/jtreg/runtime/Shutdown/ShutdownTest.java.html >>>> >>>> >>>> I wonder if you need to take the Heap_lock in the VM_Exit path as well. >>> >>> Yes you are right. Sorry I was focusing on the wrong aspect of that >>> discussion. I've updated the v2 webrev in place as java.cpp is now >>> back in it. I will also update the exit path document to show the >>> taking of the Heap_lock. >>> >>> http://cr.openjdk.java.net/~dholmes/8222534/webrev.v2/ >>> >>> Re-testing in mach5 underway - though it probably won't be testing >>> VerifyBeforeExit. >> >> I thought this change would enable VerifyBeforeExit with all our >> testing because it's trueInDebug and now on the exit path? > > You are right - I forgot about trueInDebug. > >>> >>> I'm assuming, based on the fact the destroy_JavaVM path doesn't hang, >>> that taking the Heap_lock can't succeed until there are no GC >>> safepoint ops queued, and conversely once taken no GC safepoint ops >>> will queue (or if they do they won't block trying to take the heap >>> lock!)? >>> >> I believe this is the effect. >> >> I'm having trouble with control flow.?? In destroy_vm() the Heap_lock >> is taken after that JavaThread is removed from the thread list, so we >> have a _no_safepoint_check_flag.?? In this place, from debugging the >> thread is on the threads list, so safepoint checking is ok. >> >> http://cr.openjdk.java.net/~dholmes/8222534/webrev.v2/src/hotspot/share/runtime/java.cpp.frames.html >> > > Not only okay but essential - you will get deadlocks if you try to take > without safepoint check (been there done that :) ). And yes this is just > a normal live JavaThread executing normally so it has to check safepoints. > >> ? 536???? VM_Exit op(code); >> >> Can this line be after the Heap_lock acquisition or does the Heap_lock >> make this operation wait until GC is done to queue?? ie it's this >> line, and not this one that we're blocking GC for: >> >> ? 548???? VMThread::execute(&op); > > We need the heap_lock before line #548 - which never returns. The > declaration of the VM_Exit op and the taking of the heap lock can occur > in either order. > >> >> Also, aside. >> >> ? 546???? if (thread->is_Java_thread()) >> ? 547?????? ((JavaThread*)thread)->set_thread_state(_thread_in_vm); >> >> Not your change but this is surprising.? I wonder why this is? > > VMThread::execute (and subsequent code) will expect it ... oh! Shoot! So > will trying to take the heap_lock :( I need to move that higher up. I'm > assuming that some of the paths to vm_exit may not have the thread > "in_vm" - or at least at some point in time there was such a path. I'll > do some archaeology on that. > > Thanks Coleen! > > David > >> >>> This bug has turned out to be far more complex than originally >>> anticipated :) Seems there are numerous reasons why various actions >>> are not on the vm_exit() path! I only wish someone had documented why >>> they were missing in the first place. So I added a comment about the >>> xtty logging problem in java.cpp (now that it's back in the change). >>> >> >> Thank you for all the comments.? This code is full of land mines >> without them. >> >> Looks good aside from questions. >> >> Coleen >> >>> Thanks, >>> David >>> >>>> >>>> Coleen >>>> >>>> On 4/29/19 11:54 PM, David Holmes wrote: >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222534 >>>>> Webrev: http://cr.openjdk.java.net/~dholmes/8222534/webrev/ >>>>> >>>>> Stefan noticed that VerifyBeforeExit was not honoured when a Java >>>>> application terminates via System.exit. >>>>> >>>>> Examination of the exit code sequences revealed four differences >>>>> between an exit due to the last non-daemon thread terminating >>>>> (handled via jni_DestroyJavaVM) and a call to System.exit() >>>>> (handled via JVM_Halt()). There are four missing actions on the >>>>> System.exit() path: >>>>> >>>>> - No processing of VerifyBeforeExit >>>>> - No XML logging before exit >>>>> - No LogConfiguration::finalize() >>>>> - No IdealGraphPrinter::clean_up() >>>>> >>>>> The first three have now been added at the appropriate point. >>>>> VerifyBefore exit was the main omission. The compiler team (i.e. >>>>> Vladimir K.) indicated they'd also like the XML logging. And the >>>>> LogConfiguration::finalize while possibly not essential avoids any >>>>> doubt as to whether buffered log output may get lost. >>>>> >>>>> The IdealGraphPrinter::cleanup was deemed unnecessary due to the >>>>> fact the process is being blown away anyway. >>>>> >>>>> The bug report contains a lot of details on the exit sequences >>>>> including a side-by-side comparison in the attached pdf, showing >>>>> the relative positioning of each action and that the correct order >>>>> has been maintained. >>>>> >>>>> The vm_exit() code affects a number of "abrupt" exit paths in the >>>>> VM, not just JVM_Halt, and this is discussed in the bug report as >>>>> well. In short the addition of the missing actions should not cause >>>>> any issues. >>>>> >>>>> Testing: >>>>> ?- some manual checking of exit paths and whether new code was >>>>> executed >>>>> ?- all hotspot/jtreg/gc tests with -XX:+VerifyBeforeExit added >>>>> ?- mach5 tiers 1-3 >>>>> >>>>> Thanks, >>>>> David >>>> >> From Pengfei.Li at arm.com Sun May 5 01:32:34 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Sun, 5 May 2019 01:32:34 +0000 Subject: RFR(trivial): 8223054: [TESTBUG] Put graalJarsCP before existing classpath in GraalUnitTestLauncher Message-ID: Hi, Please help review this trivial change on GraalUnitTestLauncher. Webrev: http://cr.openjdk.java.net/~pli/rfr/8223054/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8223054 Current graal unit test in jtreg requires junit-4.12.jar as a dependency. In GraalUnitTestLauncher.java, we put the path of this file into graalJarsCP and concat it with existing classpath. But existing classpath may contain another version of junit with which the jtreg tool is built. (According to OpenJDK "Building jtreg" webpage[1], the recommended version of Junit to build jtreg is junit-4.10). In this patch, graalJarsCP is put before existing classpath returned by System.getProperty() when generating the new classpath string to avoid incompatibility issues. Jteg graal unit test cases passed after this change. [1] https://openjdk.java.net/jtreg/build.html -- Thanks, Pengfei From igor.ignatyev at oracle.com Mon May 6 03:31:37 2019 From: igor.ignatyev at oracle.com (Igor Ignatev) Date: Sun, 5 May 2019 20:31:37 -0700 Subject: RFR(trivial): 8223054: [TESTBUG] Put graalJarsCP before existing classpath in GraalUnitTestLauncher In-Reply-To: References: Message-ID: <803B96E9-8EDD-4469-9137-63451E825724@oracle.com> Looks good to me. // moved to hotspot compiler list ? Igor > On May 4, 2019, at 6:32 PM, Pengfei Li (Arm Technology China) wrote: > > Hi, > > Please help review this trivial change on GraalUnitTestLauncher. > > Webrev: http://cr.openjdk.java.net/~pli/rfr/8223054/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8223054 > > Current graal unit test in jtreg requires junit-4.12.jar as a dependency. In GraalUnitTestLauncher.java, we put the path of this file into graalJarsCP and concat it with existing classpath. But existing classpath may contain another version of junit with which the jtreg tool is built. (According to OpenJDK "Building jtreg" webpage[1], the recommended version of Junit to build jtreg is junit-4.10). > > In this patch, graalJarsCP is put before existing classpath returned by System.getProperty() when generating the new classpath string to avoid incompatibility issues. Jteg graal unit test cases passed after this change. > > [1] https://openjdk.java.net/jtreg/build.html > > -- > Thanks, > Pengfei > From goetz.lindenmaier at sap.com Mon May 6 10:39:39 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 6 May 2019 10:39:39 +0000 Subject: RFR(M): jdk11u-dev backport 8205611: Improve the wording of LinkageErrors to include module and class loader information In-Reply-To: References: Message-ID: Hi Paul, thanks for reviewing this change! Best regards, Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Donnerstag, 11. April 2019 16:03 > To: jdk-updates-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: RFR(M): jdk11u-dev backport 8205611: Improve the wording of > LinkageErrors to include module and class loader information > > Hi, > > > > I would like to backport 8205611. Unfortunately, it does not apply clean, > > as 8212937, a fix that came after 8205611, was already downported. > > I needed changes at two places: > > Deleting obsolete java_lang_ClassLoader::describe_external() does > > not apply because 8212937 changed in this function. See > > http://cr.openjdk.java.net/~goetz/wr19/8205611- > exMsg_LinkageError/webrev/src/hotspot/share/classfile/javaClasses.cpp.udiff. > html > > Further the exception message in duplicateParentLE/Test.java had to be > adapted. > > > > New webrev for 11u-dev: > > http://cr.openjdk.java.net/~goetz/wr19/8205611- > exMsg_LinkageError/webrev/ > > Original change: > > http://hg.openjdk.java.net/jdk/jdk12/rev/bef02342d179 > > Original bug: > > https://bugs.openjdk.java.net/browse/JDK-8205611 > > > > The conflicting change in jdk12: > > http://hg.openjdk.java.net/jdk/jdk12/rev/de25152e5ec4 > > And downported to jdk11: > > http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/8687668b33da > > https://bugs.openjdk.java.net/browse/JDK-8212937 > > > > See also the original review thread: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-June/033325.html > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-July/033409.html > > > > Best regards, > > Goetz. > > > > From Pengfei.Li at arm.com Mon May 6 10:41:00 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Mon, 6 May 2019 10:41:00 +0000 Subject: RFR(trivial): 8223054: [TESTBUG] Put graalJarsCP before existing classpath in GraalUnitTestLauncher In-Reply-To: <803B96E9-8EDD-4469-9137-63451E825724@oracle.com> References: <803B96E9-8EDD-4469-9137-63451E825724@oracle.com> Message-ID: Thanks Igor. Do I need another reviewer for this trivial change? // Also cc graal-dev list -- Thanks, Pengfei > > Looks good to me. > > // moved to hotspot compiler list > > ? Igor > > > On May 4, 2019, at 6:32 PM, Pengfei Li (Arm Technology China) > wrote: > > > > Hi, > > > > Please help review this trivial change on GraalUnitTestLauncher. > > > > Webrev: http://cr.openjdk.java.net/~pli/rfr/8223054/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8223054 > > > > Current graal unit test in jtreg requires junit-4.12.jar as a dependency. In > GraalUnitTestLauncher.java, we put the path of this file into graalJarsCP and > concat it with existing classpath. But existing classpath may contain another > version of junit with which the jtreg tool is built. (According to OpenJDK > "Building jtreg" webpage[1], the recommended version of Junit to build jtreg > is junit-4.10). > > > > In this patch, graalJarsCP is put before existing classpath returned by > System.getProperty() when generating the new classpath string to avoid > incompatibility issues. Jteg graal unit test cases passed after this change. > > > > [1] https://openjdk.java.net/jtreg/build.html > > > > -- > > Thanks, > > Pengfei > > From stefan.karlsson at oracle.com Mon May 6 11:14:54 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 6 May 2019 13:14:54 +0200 Subject: RFR: 8223392: Add missing BitMap comments for JDK-8222986 Message-ID: <2fa037b0-9da8-9c55-dfa3-5247e69192f4@oracle.com> Hi all, Please review this small patch to add comments that should have been pushed with JDK-8222986. http://cr.openjdk.java.net/~stefank/8223392/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8223392 Thanks, StefanK From thomas.schatzl at oracle.com Mon May 6 11:18:05 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 06 May 2019 13:18:05 +0200 Subject: RFR: 8223392: Add missing BitMap comments for JDK-8222986 In-Reply-To: <2fa037b0-9da8-9c55-dfa3-5247e69192f4@oracle.com> References: <2fa037b0-9da8-9c55-dfa3-5247e69192f4@oracle.com> Message-ID: Hi, On Mon, 2019-05-06 at 13:14 +0200, Stefan Karlsson wrote: > Hi all, > > Please review this small patch to add comments that should have been > pushed with JDK-8222986. > > http://cr.openjdk.java.net/~stefank/8223392/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8223392 > looks good and trivial. Thomas From stefan.karlsson at oracle.com Mon May 6 11:18:33 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 6 May 2019 13:18:33 +0200 Subject: RFR: 8223392: Add missing BitMap comments for JDK-8222986 In-Reply-To: References: <2fa037b0-9da8-9c55-dfa3-5247e69192f4@oracle.com> Message-ID: Thanks, Thomas. StefanK On 2019-05-06 13:18, Thomas Schatzl wrote: > Hi, > > On Mon, 2019-05-06 at 13:14 +0200, Stefan Karlsson wrote: >> Hi all, >> >> Please review this small patch to add comments that should have been >> pushed with JDK-8222986. >> >> http://cr.openjdk.java.net/~stefank/8223392/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8223392 >> > > looks good and trivial. > > Thomas > From martin.doerr at sap.com Mon May 6 12:40:54 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 6 May 2019 12:40:54 +0000 Subject: RFR(M): jdk11u-dev backport 8205611: Improve the wording of LinkageErrors to include module and class loader information In-Reply-To: <2183FC12-27E9-420C-8906-35138923D8CB@amazon.com> References: <2183FC12-27E9-420C-8906-35138923D8CB@amazon.com> Message-ID: Hi G?tz, thanks for backporting. It would have been much easier to backport the issues in the correct order. I think you resolved that correctly. The jdk11u backport of JDK-8212937 diffs from the jdk12u version. diff -r test/hotspot/jtreg/runtime/LoaderConstraints/ ../jdk12u/test/hotspot/jtreg/runtime/LoaderConstraints/ diff -r test/hotspot/jtreg/runtime/LoaderConstraints/duplicateParentLE/Test.java ../jdk12u/test/hotspot/jtreg/runtime/LoaderConstraints/duplicateParentLE/Test.java 72c72 < System.out.println("Expected: " + expectedErrorMessage_part1 + "" + expectedErrorMessage_part2 + "" + expectedErrorMessage_part3 + "\n" + --- > System.out.println("Expected: " + expectedErrorMessage_part1 + "" + expectedErrorMessage_part2 + "\n" + But that's not related to your change. So your backport change looks good. Reviewed. Best regards, Martin -----Original Message----- From: jdk-updates-dev On Behalf Of Hohensee, Paul Sent: Freitag, 12. April 2019 19:21 To: Lindenmaier, Goetz ; jdk-updates-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR(M): jdk11u-dev backport 8205611: Improve the wording of LinkageErrors to include module and class loader information Looks good. I applied the patch and the modified tests pass on my osx laptop. Paul ?On 4/11/19, 7:04 AM, "jdk-updates-dev on behalf of Lindenmaier, Goetz" wrote: Hi, I would like to backport 8205611. Unfortunately, it does not apply clean, as 8212937, a fix that came after 8205611, was already downported. I needed changes at two places: Deleting obsolete java_lang_ClassLoader::describe_external() does not apply because 8212937 changed in this function. See http://cr.openjdk.java.net/~goetz/wr19/8205611-exMsg_LinkageError/webrev/src/hotspot/share/classfile/javaClasses.cpp.udiff.html Further the exception message in duplicateParentLE/Test.java had to be adapted. New webrev for 11u-dev: http://cr.openjdk.java.net/~goetz/wr19/8205611-exMsg_LinkageError/webrev/ Original change: http://hg.openjdk.java.net/jdk/jdk12/rev/bef02342d179 Original bug: https://bugs.openjdk.java.net/browse/JDK-8205611 The conflicting change in jdk12: http://hg.openjdk.java.net/jdk/jdk12/rev/de25152e5ec4 And downported to jdk11: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/8687668b33da https://bugs.openjdk.java.net/browse/JDK-8212937 See also the original review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-June/033325.html http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-July/033409.html Best regards, Goetz. From goetz.lindenmaier at sap.com Mon May 6 12:49:22 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 6 May 2019 12:49:22 +0000 Subject: RFR(M): jdk11u-dev backport 8205611: Improve the wording of LinkageErrors to include module and class loader information In-Reply-To: References: <2183FC12-27E9-420C-8906-35138923D8CB@amazon.com> Message-ID: Hi Martin, thanks for looking at this! Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Montag, 6. Mai 2019 14:41 > To: Hohensee, Paul ; Lindenmaier, Goetz > ; jdk-updates-dev at openjdk.java.net; hotspot- > dev at openjdk.java.net > Subject: RE: RFR(M): jdk11u-dev backport 8205611: Improve the wording of > LinkageErrors to include module and class loader information > > Hi G?tz, > > thanks for backporting. > It would have been much easier to backport the issues in the correct order. > I think you resolved that correctly. > > The jdk11u backport of JDK-8212937 diffs from the jdk12u version. > diff -r test/hotspot/jtreg/runtime/LoaderConstraints/ > ../jdk12u/test/hotspot/jtreg/runtime/LoaderConstraints/ > diff -r > test/hotspot/jtreg/runtime/LoaderConstraints/duplicateParentLE/Test.java > ../jdk12u/test/hotspot/jtreg/runtime/LoaderConstraints/duplicateParentLE/Te > st.java > 72c72 > < System.out.println("Expected: " + expectedErrorMessage_part1 + > "" + expectedErrorMessage_part2 + "" + expectedErrorMessage_part3 > + "\n" + > --- > > System.out.println("Expected: " + expectedErrorMessage_part1 + > "" + expectedErrorMessage_part2 + "\n" + > > But that's not related to your change. > > So your backport change looks good. Reviewed. > > Best regards, > Martin > > > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Hohensee, Paul > Sent: Freitag, 12. April 2019 19:21 > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR(M): jdk11u-dev backport 8205611: Improve the wording of > LinkageErrors to include module and class loader information > > Looks good. I applied the patch and the modified tests pass on my osx laptop. > > Paul > > ?On 4/11/19, 7:04 AM, "jdk-updates-dev on behalf of Lindenmaier, Goetz" updates-dev-bounces at openjdk.java.net on behalf of > goetz.lindenmaier at sap.com> wrote: > > Hi, > > I would like to backport 8205611. Unfortunately, it does not apply clean, > as 8212937, a fix that came after 8205611, was already downported. > I needed changes at two places: > Deleting obsolete java_lang_ClassLoader::describe_external() does > not apply because 8212937 changed in this function. See > http://cr.openjdk.java.net/~goetz/wr19/8205611- > exMsg_LinkageError/webrev/src/hotspot/share/classfile/javaClasses.cpp.udiff. > html > Further the exception message in duplicateParentLE/Test.java had to be > adapted. > > New webrev for 11u-dev: > http://cr.openjdk.java.net/~goetz/wr19/8205611- > exMsg_LinkageError/webrev/ > Original change: > http://hg.openjdk.java.net/jdk/jdk12/rev/bef02342d179 > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8205611 > > The conflicting change in jdk12: > http://hg.openjdk.java.net/jdk/jdk12/rev/de25152e5ec4 > And downported to jdk11: > http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/8687668b33da > https://bugs.openjdk.java.net/browse/JDK-8212937 > > See also the original review thread: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018- > June/033325.html > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-July/033409.html > > Best regards, > Goetz. > > > From richard.reingruber at sap.com Mon May 6 13:34:03 2019 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Mon, 6 May 2019 13:34:03 +0000 Subject: Should ~ThreadInVMForHandshake() call handle_special_runtime_exit_condition() ? Message-ID: Hi, there's an execution path, where a java thread T transitions from _thread_in_Java to _thread_in_vm and back again using an instance of ThreadInVMForHandshake without checking has_special_runtime_exit_condition() and calling handle_special_runtime_exit_condition() if true. I would consider this a bug. Would you agree? What about changing transition_back() like this? diff -r 61d0e96a6b2d src/hotspot/share/runtime/interfaceSupport.inline.hpp --- a/src/hotspot/share/runtime/interfaceSupport.inline.hpp Thu May 02 15:46:34 2019 -0700 +++ b/src/hotspot/share/runtime/interfaceSupport.inline.hpp Mon May 06 14:30:59 2019 +0200 @@ -137,6 +137,11 @@ SafepointMechanism::block_if_requested(_thread); _thread->set_thread_state(_original_state); + + if ((_original_state == _thread_in_Java || _original_state == _thread_in_native) && + _thread->has_special_runtime_exit_condition()) { + _thread->handle_special_runtime_exit_condition(!_thread->is_at_poll_safepoint()); + } } public: Without that patch an issue could be that thread T continues executing bytecodes after it was suspended by a JVMTI agent like this: - Handshake operation H is executed for T - T calls ThreadSafepointState::handle_polling_page_exception() - T arrives in HandshakeState::process_self_inner() - T transitions from _thread_in_Java to _thread_in_vm - but too lated: the VM thread already claimed H - T calls _semaphore.wait_with_safepoint_check() - T transitions from _thread_in_vm to _thread_blocked - The VM thread completes H and calls _semaphore.signal() - Before T can transition back to _thread_in_vm, the VM thread schedules another safepoint and executes VM_ThreadSuspend on behalf of a JVMTI agent that wants to suspend T - After the safepoint T transitions back to _thread_in_vm and then to _thread_in_Java. - T continues executing an undefined number of bytecodes ... Cheers, Richard. From dean.long at oracle.com Mon May 6 18:45:33 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 6 May 2019 11:45:33 -0700 Subject: RFR(trivial): 8223054: [TESTBUG] Put graalJarsCP before existing classpath in GraalUnitTestLauncher In-Reply-To: References: <803B96E9-8EDD-4469-9137-63451E825724@oracle.com> Message-ID: Looks good (and trivial) to me. dl On 5/6/19 3:41 AM, Pengfei Li (Arm Technology China) wrote: > Thanks Igor. Do I need another reviewer for this trivial change? > > // Also cc graal-dev list > > -- > Thanks, > Pengfei > >> Looks good to me. >> >> // moved to hotspot compiler list >> >> ? Igor >> >>> On May 4, 2019, at 6:32 PM, Pengfei Li (Arm Technology China) >> wrote: >>> Hi, >>> >>> Please help review this trivial change on GraalUnitTestLauncher. >>> >>> Webrev: http://cr.openjdk.java.net/~pli/rfr/8223054/webrev.00/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8223054 >>> >>> Current graal unit test in jtreg requires junit-4.12.jar as a dependency. In >> GraalUnitTestLauncher.java, we put the path of this file into graalJarsCP and >> concat it with existing classpath. But existing classpath may contain another >> version of junit with which the jtreg tool is built. (According to OpenJDK >> "Building jtreg" webpage[1], the recommended version of Junit to build jtreg >> is junit-4.10). >>> In this patch, graalJarsCP is put before existing classpath returned by >> System.getProperty() when generating the new classpath string to avoid >> incompatibility issues. Jteg graal unit test cases passed after this change. >>> [1] https://openjdk.java.net/jtreg/build.html >>> >>> -- >>> Thanks, >>> Pengfei >>> From coleen.phillimore at oracle.com Mon May 6 20:06:37 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 6 May 2019 16:06:37 -0400 Subject: RFR (S): 8222534: VerifyBeforeExit is not honored when System.exit is called In-Reply-To: References: <94327eae-0553-a346-bc4f-e0ff8ffa7ce5@oracle.com> <3bf1af77-83d3-04b4-20b5-6950de1d5e5c@oracle.com> <4cb4ab9b-4ed9-ea7f-5823-baa4c06ded59@oracle.com> Message-ID: <993e50e0-1d40-9080-828b-1926e4c5b0be@oracle.com> I looked at v3.? I suppose there's more to learn about the exit paths, but this solves the problem and looks good. Thanks, Coleen On 5/4/19 2:09 AM, David Holmes wrote: > Updated webrev: http://cr.openjdk.java.net/~dholmes/8222534/webrev.v2/ > > The historic setting of the thread state to _thread_in_vm is moved > ahead of the taking of the heap_lock. That logic has been there since > "exit at a safepoint" was introduced by JDK-4526887, and there's > nothing to tell you how we might get there in a different state. To be > safe I've left it and added a comment. > > Thanks, > David > > On 4/05/2019 9:45 am, David Holmes wrote: >> Hi Coleen, >> >> On 4/05/2019 12:56 am, coleen.phillimore at oracle.com wrote: >>> On 4/30/19 11:42 PM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> On 1/05/2019 7:59 am, coleen.phillimore at oracle.com wrote: >>>>> >>>>> David, Thank you for the writeup of the exit paths. >>>>> >>>>> The reason I added this test with JDK-9074355 is because taking >>>>> the Heap_lock in destroy_vm prevented a crash in VerifyBeforeExit. >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/2019/8074355.06/webrev/test/hotspot/jtreg/runtime/Shutdown/ShutdownTest.java.html >>>>> >>>>> >>>>> I wonder if you need to take the Heap_lock in the VM_Exit path as >>>>> well. >>>> >>>> Yes you are right. Sorry I was focusing on the wrong aspect of that >>>> discussion. I've updated the v2 webrev in place as java.cpp is now >>>> back in it. I will also update the exit path document to show the >>>> taking of the Heap_lock. >>>> >>>> http://cr.openjdk.java.net/~dholmes/8222534/webrev.v2/ >>>> >>>> Re-testing in mach5 underway - though it probably won't be testing >>>> VerifyBeforeExit. >>> >>> I thought this change would enable VerifyBeforeExit with all our >>> testing because it's trueInDebug and now on the exit path? >> >> You are right - I forgot about trueInDebug. >> >>>> >>>> I'm assuming, based on the fact the destroy_JavaVM path doesn't >>>> hang, that taking the Heap_lock can't succeed until there are no GC >>>> safepoint ops queued, and conversely once taken no GC safepoint ops >>>> will queue (or if they do they won't block trying to take the heap >>>> lock!)? >>>> >>> I believe this is the effect. >>> >>> I'm having trouble with control flow.?? In destroy_vm() the >>> Heap_lock is taken after that JavaThread is removed from the thread >>> list, so we have a _no_safepoint_check_flag.?? In this place, from >>> debugging the thread is on the threads list, so safepoint checking >>> is ok. >>> >>> http://cr.openjdk.java.net/~dholmes/8222534/webrev.v2/src/hotspot/share/runtime/java.cpp.frames.html >>> >> >> Not only okay but essential - you will get deadlocks if you try to >> take without safepoint check (been there done that :) ). And yes this >> is just a normal live JavaThread executing normally so it has to >> check safepoints. >> >>> ? 536???? VM_Exit op(code); >>> >>> Can this line be after the Heap_lock acquisition or does the >>> Heap_lock make this operation wait until GC is done to queue? ie >>> it's this line, and not this one that we're blocking GC for: >>> >>> ? 548???? VMThread::execute(&op); >> >> We need the heap_lock before line #548 - which never returns. The >> declaration of the VM_Exit op and the taking of the heap lock can >> occur in either order. >> >>> >>> Also, aside. >>> >>> ? 546???? if (thread->is_Java_thread()) >>> ? 547 ((JavaThread*)thread)->set_thread_state(_thread_in_vm); >>> >>> Not your change but this is surprising.? I wonder why this is? >> >> VMThread::execute (and subsequent code) will expect it ... oh! Shoot! >> So will trying to take the heap_lock :( I need to move that higher >> up. I'm assuming that some of the paths to vm_exit may not have the >> thread "in_vm" - or at least at some point in time there was such a >> path. I'll do some archaeology on that. >> >> Thanks Coleen! >> >> David >> >>> >>>> This bug has turned out to be far more complex than originally >>>> anticipated :) Seems there are numerous reasons why various actions >>>> are not on the vm_exit() path! I only wish someone had documented >>>> why they were missing in the first place. So I added a comment >>>> about the xtty logging problem in java.cpp (now that it's back in >>>> the change). >>>> >>> >>> Thank you for all the comments.? This code is full of land mines >>> without them. >>> >>> Looks good aside from questions. >>> >>> Coleen >>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> Coleen >>>>> >>>>> On 4/29/19 11:54 PM, David Holmes wrote: >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222534 >>>>>> Webrev: http://cr.openjdk.java.net/~dholmes/8222534/webrev/ >>>>>> >>>>>> Stefan noticed that VerifyBeforeExit was not honoured when a Java >>>>>> application terminates via System.exit. >>>>>> >>>>>> Examination of the exit code sequences revealed four differences >>>>>> between an exit due to the last non-daemon thread terminating >>>>>> (handled via jni_DestroyJavaVM) and a call to System.exit() >>>>>> (handled via JVM_Halt()). There are four missing actions on the >>>>>> System.exit() path: >>>>>> >>>>>> - No processing of VerifyBeforeExit >>>>>> - No XML logging before exit >>>>>> - No LogConfiguration::finalize() >>>>>> - No IdealGraphPrinter::clean_up() >>>>>> >>>>>> The first three have now been added at the appropriate point. >>>>>> VerifyBefore exit was the main omission. The compiler team (i.e. >>>>>> Vladimir K.) indicated they'd also like the XML logging. And the >>>>>> LogConfiguration::finalize while possibly not essential avoids >>>>>> any doubt as to whether buffered log output may get lost. >>>>>> >>>>>> The IdealGraphPrinter::cleanup was deemed unnecessary due to the >>>>>> fact the process is being blown away anyway. >>>>>> >>>>>> The bug report contains a lot of details on the exit sequences >>>>>> including a side-by-side comparison in the attached pdf, showing >>>>>> the relative positioning of each action and that the correct >>>>>> order has been maintained. >>>>>> >>>>>> The vm_exit() code affects a number of "abrupt" exit paths in the >>>>>> VM, not just JVM_Halt, and this is discussed in the bug report as >>>>>> well. In short the addition of the missing actions should not >>>>>> cause any issues. >>>>>> >>>>>> Testing: >>>>>> ?- some manual checking of exit paths and whether new code was >>>>>> executed >>>>>> ?- all hotspot/jtreg/gc tests with -XX:+VerifyBeforeExit added >>>>>> ?- mach5 tiers 1-3 >>>>>> >>>>>> Thanks, >>>>>> David >>>>> >>> From per.liden at oracle.com Mon May 6 21:19:06 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 6 May 2019 23:19:06 +0200 Subject: RFR: 8223392: Add missing BitMap comments for JDK-8222986 In-Reply-To: <2fa037b0-9da8-9c55-dfa3-5247e69192f4@oracle.com> References: <2fa037b0-9da8-9c55-dfa3-5247e69192f4@oracle.com> Message-ID: Looks good! /Per On 05/06/2019 01:14 PM, Stefan Karlsson wrote: > Hi all, > > Please review this small patch to add comments that should have been > pushed with JDK-8222986. > > http://cr.openjdk.java.net/~stefank/8223392/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8223392 > > Thanks, > StefanK From david.holmes at oracle.com Tue May 7 01:22:33 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 7 May 2019 11:22:33 +1000 Subject: RFR (S): 8222534: VerifyBeforeExit is not honored when System.exit is called In-Reply-To: <993e50e0-1d40-9080-828b-1926e4c5b0be@oracle.com> References: <94327eae-0553-a346-bc4f-e0ff8ffa7ce5@oracle.com> <3bf1af77-83d3-04b4-20b5-6950de1d5e5c@oracle.com> <4cb4ab9b-4ed9-ea7f-5823-baa4c06ded59@oracle.com> <993e50e0-1d40-9080-828b-1926e4c5b0be@oracle.com> Message-ID: <1a67b558-8b33-6f5a-4b17-d33f1923dd39@oracle.com> On 7/05/2019 6:06 am, coleen.phillimore at oracle.com wrote: > I looked at v3. Oops - sorry about the typo on the URL. > I suppose there's more to learn about the exit paths, > but this solves the problem and looks good. Thanks. I fixed a typo in the new comment. But will push this now. David ----- > Thanks, > Coleen > > On 5/4/19 2:09 AM, David Holmes wrote: >> Updated webrev: http://cr.openjdk.java.net/~dholmes/8222534/webrev.v2/ >> >> The historic setting of the thread state to _thread_in_vm is moved >> ahead of the taking of the heap_lock. That logic has been there since >> "exit at a safepoint" was introduced by JDK-4526887, and there's >> nothing to tell you how we might get there in a different state. To be >> safe I've left it and added a comment. >> >> Thanks, >> David >> >> On 4/05/2019 9:45 am, David Holmes wrote: >>> Hi Coleen, >>> >>> On 4/05/2019 12:56 am, coleen.phillimore at oracle.com wrote: >>>> On 4/30/19 11:42 PM, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> On 1/05/2019 7:59 am, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>> David, Thank you for the writeup of the exit paths. >>>>>> >>>>>> The reason I added this test with JDK-9074355 is because taking >>>>>> the Heap_lock in destroy_vm prevented a crash in VerifyBeforeExit. >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/2019/8074355.06/webrev/test/hotspot/jtreg/runtime/Shutdown/ShutdownTest.java.html >>>>>> >>>>>> >>>>>> I wonder if you need to take the Heap_lock in the VM_Exit path as >>>>>> well. >>>>> >>>>> Yes you are right. Sorry I was focusing on the wrong aspect of that >>>>> discussion. I've updated the v2 webrev in place as java.cpp is now >>>>> back in it. I will also update the exit path document to show the >>>>> taking of the Heap_lock. >>>>> >>>>> http://cr.openjdk.java.net/~dholmes/8222534/webrev.v2/ >>>>> >>>>> Re-testing in mach5 underway - though it probably won't be testing >>>>> VerifyBeforeExit. >>>> >>>> I thought this change would enable VerifyBeforeExit with all our >>>> testing because it's trueInDebug and now on the exit path? >>> >>> You are right - I forgot about trueInDebug. >>> >>>>> >>>>> I'm assuming, based on the fact the destroy_JavaVM path doesn't >>>>> hang, that taking the Heap_lock can't succeed until there are no GC >>>>> safepoint ops queued, and conversely once taken no GC safepoint ops >>>>> will queue (or if they do they won't block trying to take the heap >>>>> lock!)? >>>>> >>>> I believe this is the effect. >>>> >>>> I'm having trouble with control flow.?? In destroy_vm() the >>>> Heap_lock is taken after that JavaThread is removed from the thread >>>> list, so we have a _no_safepoint_check_flag.?? In this place, from >>>> debugging the thread is on the threads list, so safepoint checking >>>> is ok. >>>> >>>> http://cr.openjdk.java.net/~dholmes/8222534/webrev.v2/src/hotspot/share/runtime/java.cpp.frames.html >>>> >>> >>> Not only okay but essential - you will get deadlocks if you try to >>> take without safepoint check (been there done that :) ). And yes this >>> is just a normal live JavaThread executing normally so it has to >>> check safepoints. >>> >>>> ? 536???? VM_Exit op(code); >>>> >>>> Can this line be after the Heap_lock acquisition or does the >>>> Heap_lock make this operation wait until GC is done to queue? ie >>>> it's this line, and not this one that we're blocking GC for: >>>> >>>> ? 548???? VMThread::execute(&op); >>> >>> We need the heap_lock before line #548 - which never returns. The >>> declaration of the VM_Exit op and the taking of the heap lock can >>> occur in either order. >>> >>>> >>>> Also, aside. >>>> >>>> ? 546???? if (thread->is_Java_thread()) >>>> ? 547 ((JavaThread*)thread)->set_thread_state(_thread_in_vm); >>>> >>>> Not your change but this is surprising.? I wonder why this is? >>> >>> VMThread::execute (and subsequent code) will expect it ... oh! Shoot! >>> So will trying to take the heap_lock :( I need to move that higher >>> up. I'm assuming that some of the paths to vm_exit may not have the >>> thread "in_vm" - or at least at some point in time there was such a >>> path. I'll do some archaeology on that. >>> >>> Thanks Coleen! >>> >>> David >>> >>>> >>>>> This bug has turned out to be far more complex than originally >>>>> anticipated :) Seems there are numerous reasons why various actions >>>>> are not on the vm_exit() path! I only wish someone had documented >>>>> why they were missing in the first place. So I added a comment >>>>> about the xtty logging problem in java.cpp (now that it's back in >>>>> the change). >>>>> >>>> >>>> Thank you for all the comments.? This code is full of land mines >>>> without them. >>>> >>>> Looks good aside from questions. >>>> >>>> Coleen >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Coleen >>>>>> >>>>>> On 4/29/19 11:54 PM, David Holmes wrote: >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222534 >>>>>>> Webrev: http://cr.openjdk.java.net/~dholmes/8222534/webrev/ >>>>>>> >>>>>>> Stefan noticed that VerifyBeforeExit was not honoured when a Java >>>>>>> application terminates via System.exit. >>>>>>> >>>>>>> Examination of the exit code sequences revealed four differences >>>>>>> between an exit due to the last non-daemon thread terminating >>>>>>> (handled via jni_DestroyJavaVM) and a call to System.exit() >>>>>>> (handled via JVM_Halt()). There are four missing actions on the >>>>>>> System.exit() path: >>>>>>> >>>>>>> - No processing of VerifyBeforeExit >>>>>>> - No XML logging before exit >>>>>>> - No LogConfiguration::finalize() >>>>>>> - No IdealGraphPrinter::clean_up() >>>>>>> >>>>>>> The first three have now been added at the appropriate point. >>>>>>> VerifyBefore exit was the main omission. The compiler team (i.e. >>>>>>> Vladimir K.) indicated they'd also like the XML logging. And the >>>>>>> LogConfiguration::finalize while possibly not essential avoids >>>>>>> any doubt as to whether buffered log output may get lost. >>>>>>> >>>>>>> The IdealGraphPrinter::cleanup was deemed unnecessary due to the >>>>>>> fact the process is being blown away anyway. >>>>>>> >>>>>>> The bug report contains a lot of details on the exit sequences >>>>>>> including a side-by-side comparison in the attached pdf, showing >>>>>>> the relative positioning of each action and that the correct >>>>>>> order has been maintained. >>>>>>> >>>>>>> The vm_exit() code affects a number of "abrupt" exit paths in the >>>>>>> VM, not just JVM_Halt, and this is discussed in the bug report as >>>>>>> well. In short the addition of the missing actions should not >>>>>>> cause any issues. >>>>>>> >>>>>>> Testing: >>>>>>> ?- some manual checking of exit paths and whether new code was >>>>>>> executed >>>>>>> ?- all hotspot/jtreg/gc tests with -XX:+VerifyBeforeExit added >>>>>>> ?- mach5 tiers 1-3 >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>> >>>> > From richard.reingruber at sap.com Tue May 7 06:29:06 2019 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Tue, 7 May 2019 06:29:06 +0000 Subject: Should ~ThreadInVMForHandshake() call handle_special_runtime_exit_condition() ? Message-ID: // Repost adding hotspot-runtime-dev at openjdk.java.net Hi, there's an execution path, where a java thread T transitions from _thread_in_Java to _thread_in_vm and back again using an instance of ThreadInVMForHandshake without checking has_special_runtime_exit_condition() and calling handle_special_runtime_exit_condition() if true. I would consider this a bug. Would you agree? What about changing transition_back() like this? diff -r 61d0e96a6b2d src/hotspot/share/runtime/interfaceSupport.inline.hpp --- a/src/hotspot/share/runtime/interfaceSupport.inline.hpp Thu May 02 15:46:34 2019 -0700 +++ b/src/hotspot/share/runtime/interfaceSupport.inline.hpp Mon May 06 14:30:59 2019 +0200 @@ -137,6 +137,11 @@ SafepointMechanism::block_if_requested(_thread); _thread->set_thread_state(_original_state); + + if ((_original_state == _thread_in_Java || _original_state == _thread_in_native) && + _thread->has_special_runtime_exit_condition()) { + _thread->handle_special_runtime_exit_condition(!_thread->is_at_poll_safepoint()); + } } public: Without that patch an issue could be that thread T continues executing bytecodes after it was suspended by a JVMTI agent like this: - Handshake operation H is executed for T - T calls ThreadSafepointState::handle_polling_page_exception() - T arrives in HandshakeState::process_self_inner() - T transitions from _thread_in_Java to _thread_in_vm - but too late: the VM thread already claimed H - T calls _semaphore.wait_with_safepoint_check() - T transitions from _thread_in_vm to _thread_blocked - The VM thread completes H and calls _semaphore.signal() - Before T can transition back to _thread_in_vm, the VM thread schedules another safepoint and executes VM_ThreadSuspend on behalf of a JVMTI agent that wants to suspend T - After the safepoint T transitions back to _thread_in_vm and then to _thread_in_Java. - T continues executing an undefined number of bytecodes ... Cheers, Richard. From robbin.ehn at oracle.com Tue May 7 12:06:48 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 7 May 2019 14:06:48 +0200 Subject: Should ~ThreadInVMForHandshake() call handle_special_runtime_exit_condition() ? In-Reply-To: References: Message-ID: <40dc6132-f590-229d-8ddb-e4eb05ec3689@oracle.com> Hi Richard, I believe you are correct. Thanks, Robbin On 5/7/19 8:29 AM, Reingruber, Richard wrote: > // Repost adding hotspot-runtime-dev at openjdk.java.net > > Hi, > > there's an execution path, where a java thread T transitions from _thread_in_Java to > _thread_in_vm and back again using an instance of ThreadInVMForHandshake without checking > has_special_runtime_exit_condition() and calling handle_special_runtime_exit_condition() > if true. > > I would consider this a bug. Would you agree? > > What about changing transition_back() like this? > > diff -r 61d0e96a6b2d src/hotspot/share/runtime/interfaceSupport.inline.hpp > --- a/src/hotspot/share/runtime/interfaceSupport.inline.hpp Thu May 02 15:46:34 2019 -0700 > +++ b/src/hotspot/share/runtime/interfaceSupport.inline.hpp Mon May 06 14:30:59 2019 +0200 > @@ -137,6 +137,11 @@ > SafepointMechanism::block_if_requested(_thread); > > _thread->set_thread_state(_original_state); > + > + if ((_original_state == _thread_in_Java || _original_state == _thread_in_native) && > + _thread->has_special_runtime_exit_condition()) { > + _thread->handle_special_runtime_exit_condition(!_thread->is_at_poll_safepoint()); > + } > } > > public: > > Without that patch an issue could be that thread T continues executing bytecodes after it was > suspended by a JVMTI agent like this: > > - Handshake operation H is executed for T > - T calls ThreadSafepointState::handle_polling_page_exception() > - T arrives in HandshakeState::process_self_inner() > - T transitions from _thread_in_Java to _thread_in_vm > - but too late: the VM thread already claimed H > - T calls _semaphore.wait_with_safepoint_check() > - T transitions from _thread_in_vm to _thread_blocked > - The VM thread completes H and calls _semaphore.signal() > - Before T can transition back to _thread_in_vm, the VM thread schedules another safepoint and > executes VM_ThreadSuspend on behalf of a JVMTI agent that wants to suspend T > - After the safepoint T transitions back to _thread_in_vm and then to _thread_in_Java. > - T continues executing an undefined number of bytecodes ... > > Cheers, Richard. > From matthias.baesken at sap.com Tue May 7 14:38:25 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 7 May 2019 14:38:25 +0000 Subject: RFR: 8223438: add VirtualizationInformation JFR event Message-ID: Hello, please review the following change . It adds a simple VirtualizationInformation event to JFR . The addition to JFR has been previously proposed by Erik when we discussed the enhancement of hs_error file output with virtualization related information . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8223438 http://cr.openjdk.java.net/~mbaesken/webrevs/8223438.1/ Thanks, Matthias From coleen.phillimore at oracle.com Tue May 7 14:48:21 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 7 May 2019 10:48:21 -0400 Subject: RFR (S) 8223391: Unsynchronized iteration of ClassLoaderDataGraph Message-ID: <7507c7ea-cff8-e865-27a3-178a6313adf4@oracle.com> Summary: lock in G1 before clear_claimed_marks See bug for details: open webrev at http://cr.openjdk.java.net/~coleenp/2019/8223391.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8223391 Thanks, Coleen Ran|mach5 hs-tier5-gc,hs-tier6-gc,hs-tier7-gc,hs-tier8-gc,hs-tier1,hs-tier2,hs-tier3|| | From richard.reingruber at sap.com Tue May 7 14:58:03 2019 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Tue, 7 May 2019 14:58:03 +0000 Subject: Should ~ThreadInVMForHandshake() call handle_special_runtime_exit_condition() ? In-Reply-To: <40dc6132-f590-229d-8ddb-e4eb05ec3689@oracle.com> References: <40dc6132-f590-229d-8ddb-e4eb05ec3689@oracle.com> Message-ID: Hi Robbin, thanks for your feedback. I'll prepare a webrev and create a bug... Cheers, Richard. -----Original Message----- From: Robbin Ehn Sent: Dienstag, 7. Mai 2019 14:07 To: Reingruber, Richard ; hotspot-runtime-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: Should ~ThreadInVMForHandshake() call handle_special_runtime_exit_condition() ? Hi Richard, I believe you are correct. Thanks, Robbin On 5/7/19 8:29 AM, Reingruber, Richard wrote: > // Repost adding hotspot-runtime-dev at openjdk.java.net > > Hi, > > there's an execution path, where a java thread T transitions from _thread_in_Java to > _thread_in_vm and back again using an instance of ThreadInVMForHandshake without checking > has_special_runtime_exit_condition() and calling handle_special_runtime_exit_condition() > if true. > > I would consider this a bug. Would you agree? > > What about changing transition_back() like this? > > diff -r 61d0e96a6b2d src/hotspot/share/runtime/interfaceSupport.inline.hpp > --- a/src/hotspot/share/runtime/interfaceSupport.inline.hpp Thu May 02 15:46:34 2019 -0700 > +++ b/src/hotspot/share/runtime/interfaceSupport.inline.hpp Mon May 06 14:30:59 2019 +0200 > @@ -137,6 +137,11 @@ > SafepointMechanism::block_if_requested(_thread); > > _thread->set_thread_state(_original_state); > + > + if ((_original_state == _thread_in_Java || _original_state == _thread_in_native) && > + _thread->has_special_runtime_exit_condition()) { > + _thread->handle_special_runtime_exit_condition(!_thread->is_at_poll_safepoint()); > + } > } > > public: > > Without that patch an issue could be that thread T continues executing bytecodes after it was > suspended by a JVMTI agent like this: > > - Handshake operation H is executed for T > - T calls ThreadSafepointState::handle_polling_page_exception() > - T arrives in HandshakeState::process_self_inner() > - T transitions from _thread_in_Java to _thread_in_vm > - but too late: the VM thread already claimed H > - T calls _semaphore.wait_with_safepoint_check() > - T transitions from _thread_in_vm to _thread_blocked > - The VM thread completes H and calls _semaphore.signal() > - Before T can transition back to _thread_in_vm, the VM thread schedules another safepoint and > executes VM_ThreadSuspend on behalf of a JVMTI agent that wants to suspend T > - After the safepoint T transitions back to _thread_in_vm and then to _thread_in_Java. > - T continues executing an undefined number of bytecodes ... > > Cheers, Richard. > From robbin.ehn at oracle.com Tue May 7 15:16:10 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 7 May 2019 17:16:10 +0200 Subject: Should ~ThreadInVMForHandshake() call handle_special_runtime_exit_condition() ? In-Reply-To: References: <40dc6132-f590-229d-8ddb-e4eb05ec3689@oracle.com> Message-ID: Hi Richard, >> + if ((_original_state == _thread_in_Java || _original_state == _thread_in_native) && >> + _thread->has_special_runtime_exit_condition()) { >> + _thread->handle_special_runtime_exit_condition(!_thread->is_at_poll_safepoint()); >> + } You need to verify that async exception check is correct. If we are returning to native it should not be delivered AFAIK. Thanks, Robbin >> } >> >> public: >> >> Without that patch an issue could be that thread T continues executing bytecodes after it was >> suspended by a JVMTI agent like this: >> >> - Handshake operation H is executed for T >> - T calls ThreadSafepointState::handle_polling_page_exception() >> - T arrives in HandshakeState::process_self_inner() >> - T transitions from _thread_in_Java to _thread_in_vm >> - but too late: the VM thread already claimed H >> - T calls _semaphore.wait_with_safepoint_check() >> - T transitions from _thread_in_vm to _thread_blocked >> - The VM thread completes H and calls _semaphore.signal() >> - Before T can transition back to _thread_in_vm, the VM thread schedules another safepoint and >> executes VM_ThreadSuspend on behalf of a JVMTI agent that wants to suspend T >> - After the safepoint T transitions back to _thread_in_vm and then to _thread_in_Java. >> - T continues executing an undefined number of bytecodes ... >> >> Cheers, Richard. >> From harold.seigel at oracle.com Tue May 7 15:24:29 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Tue, 7 May 2019 11:24:29 -0400 Subject: RFR (S) 8223391: Unsynchronized iteration of ClassLoaderDataGraph In-Reply-To: <7507c7ea-cff8-e865-27a3-178a6313adf4@oracle.com> References: <7507c7ea-cff8-e865-27a3-178a6313adf4@oracle.com> Message-ID: <1a3bae2f-52e4-0175-6c25-4376d6db4585@oracle.com> Hi Coleen, Looks good! Harold On 5/7/2019 10:48 AM, coleen.phillimore at oracle.com wrote: > Summary: lock in G1 before clear_claimed_marks > > See bug for details: > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8223391.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8223391 > > Thanks, > Coleen > > Ran|mach5 > hs-tier5-gc,hs-tier6-gc,hs-tier7-gc,hs-tier8-gc,hs-tier1,hs-tier2,hs-tier3|| > | From coleen.phillimore at oracle.com Tue May 7 15:36:17 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 7 May 2019 11:36:17 -0400 Subject: RFR: 8223136: Move compressed oops functions to CompressedOops class In-Reply-To: References: <61cb41e8-fcd5-845f-e57f-7a2d46c0c995@oracle.com> <612339e6-e693-c1c9-51f6-9316aa90874b@oracle.com> Message-ID: <6f674d7f-b0ac-38d4-3b70-8a9e683e8022@oracle.com> On 5/2/19 12:44 PM, Stefan Karlsson wrote: > The big patch has been split up into smaller patches: > ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/01.compressed/ Not a small patch, but this looks great.? I really like the change to move compressed oops out of universe. > ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/02.verifyOption/ Good too. > ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/03.isGCActiveMark/ > Ok. > ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/04.oopRecorder/ Ok. > ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/05.memAllocator/ Ok, seems unrelated though. > ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/06.oopFactory/ Not sure why you have this.? oopFactory.hpp still includes universe.hpp which I thought was the purpose of moving the function bodies to the cpp file. > ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/07.oopsHierarchy/ Seems unrelated but sure.?? Can you make all of set_obj() in the cpp file?? For some reason gdb is stepping through this lately. 1201??? ? oop mirror???????????? = java_lang_reflect_Method::clazz(method_mirror); (gdb) n 100??? ? oopDesc* obj()? const volatile????? { return _o; } (gdb) 90??? ? void raw_set_obj(const void* p)???? { _o = (oopDesc*)p; } (gdb) 97??? ??? if (CheckUnhandledOops) unregister_oop(); (gdb) 1202??? ? int slot?????????????? = java_lang_reflect_Method::slot(method_mirror); > > ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/08.fixIncludes/ Looks good.? universe.hpp is now not included by hpp files and redistributed to cpp files that need it.? Unsettling how many files need it. Coleen > > All patches together: > ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/all/ > > Thanks, > StefanK > > On 2019-05-02 16:17, Stefan Karlsson wrote: >> On 2019-05-02 16:12, coleen.phillimore at oracle.com wrote: >>> >>> Hi Stefan, This seems fine but I'd really like to have the #include >>> universe.hpp part of the patch broken out, as much as possible. >> >> OK. Thanks for the feedback. Let me work on that and get back to you >> with a few separate patches. >> >> Thanks, >> StefanK >> >>> >>> Thanks, >>> Coleen >>> >>> On 5/2/19 8:44 AM, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> Rebased on top of latest changes (jdk/jdk @ edd709e64ea1): >>>> ?http://cr.openjdk.java.net/~stefank/8223136/webrev.02/ >>>> >>>> Thanks, >>>> StefanK >>>> >>>> >>>> On 2019-04-30 10:58, Stefan Karlsson wrote: >>>>> Hi all, >>>>> >>>>> Please review this patch to move the rest of the compressed oops >>>>> functions and variables over to CompressedOops. >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01 >>>>> https://bugs.openjdk.java.net/browse/JDK-8223136 >>>>> >>>>> In 'JDK-8199946: Move load/store and encode/decode out of oopDesc' >>>>> the decoding and encoding of compressed oops were moved into the >>>>> namespace named CompressedOops. >>>>> >>>>> There infrastructure used by these functions were left in >>>>> Universe. This patch moves rest of the functions and variables >>>>> over to CompressedOops. I decided to convert the CompressedOops >>>>> namespace into a proper AllStatic class, to avoid any potential >>>>> problems with VMStructs. >>>>> >>>>> I also moved the corresponding functionality for compressed klass >>>>> pointers into a new class named CompressedKlassPointers. >>>>> >>>>> While doing this change I decided to cleanup the includes >>>>> regarding compressed oops, and universe.hpp, where most of the >>>>> code was moved from. Therefore, the patch is touching a large >>>>> number of files. A lot of the files contain updated header >>>>> includes and simple renames. If you want to fast-forward through >>>>> those, these are the main files where code related to compressed >>>>> oops actually moved: >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/universe.cpp.udiff.html >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/universe.hpp.udiff.html >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/compressedOops.hpp.html >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/compressedOops.inline.hpp.udiff.html >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/klass.cpp.udiff.html >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/klass.hpp.udiff.html >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/klass.inline.hpp.udiff.html >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/oop.cpp.udiff.html >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/oop.hpp.udiff.html >>>>> >>>>> >>>>> To get cleaner includes I did some minor restructuring to other >>>>> files. I can do these changes a small preparation patches, but >>>>> would like to get feedback on the overall patch first. >>>>> >>>>> Move flag checking out of hpp file, to stop propagation of >>>>> globals.hpp to all places where compressedOops.hpp is included: >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.cpp.udiff.html >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.hpp.udiff.html >>>>> >>>>> >>>>> Extract VerifyOption out of universe.hpp: >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/verifyOption.hpp.html >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/verifyOption.hpp.html >>>>> >>>>> >>>>> Moves a usage of CompressedOops to the cpp file: >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/opto/matcher.cpp.udiff.html >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/opto/matcher.hpp.udiff.html >>>>> >>>>> >>>>> Move Universe usage out of hpp files >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/memAllocator.hpp.udiff.html >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/memAllocator.cpp.udiff.html >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/isGCActiveMark.hpp.udiff.html >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/isGCActiveMark.cpp.html >>>>> >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.cpp.udiff.html >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.hpp.udiff.html >>>>> >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/code/oopRecorder.hpp.udiff.html >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/code/oopRecorder.inline.hpp.html >>>>> >>>>> >>>>> I've tried to update all platforms, but would appreciate >>>>> verification from platform maintainers that the changes don't >>>>> break the build. >>>>> >>>>> I've also left some of the old names in JVMCI, to not disturb >>>>> ongoing changes in that area. >>>>> >>>>> Thanks, >>>>> StefanK >>> >> > From lois.foltan at oracle.com Tue May 7 15:51:13 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 7 May 2019 11:51:13 -0400 Subject: RFR (S) 8223391: Unsynchronized iteration of ClassLoaderDataGraph In-Reply-To: <1a3bae2f-52e4-0175-6c25-4376d6db4585@oracle.com> References: <7507c7ea-cff8-e865-27a3-178a6313adf4@oracle.com> <1a3bae2f-52e4-0175-6c25-4376d6db4585@oracle.com> Message-ID: <1ffdc2a7-1841-2e54-86fa-4cf34d1e924e@oracle.com> +1. Lois On 5/7/2019 11:24 AM, Harold Seigel wrote: > Hi Coleen, > > Looks good! > > Harold > > On 5/7/2019 10:48 AM, coleen.phillimore at oracle.com wrote: >> Summary: lock in G1 before clear_claimed_marks >> >> See bug for details: >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8223391.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8223391 >> >> Thanks, >> Coleen >> >> Ran|mach5 >> hs-tier5-gc,hs-tier6-gc,hs-tier7-gc,hs-tier8-gc,hs-tier1,hs-tier2,hs-tier3|| >> | From stefan.karlsson at oracle.com Tue May 7 18:02:15 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 7 May 2019 20:02:15 +0200 Subject: RFR: 8223136: Move compressed oops functions to CompressedOops class In-Reply-To: <6f674d7f-b0ac-38d4-3b70-8a9e683e8022@oracle.com> References: <61cb41e8-fcd5-845f-e57f-7a2d46c0c995@oracle.com> <612339e6-e693-c1c9-51f6-9316aa90874b@oracle.com> <6f674d7f-b0ac-38d4-3b70-8a9e683e8022@oracle.com> Message-ID: <325c4923-1f39-fcfb-685c-8cf77b165540@oracle.com> Thanks for reviewing! Inlined: On 2019-05-07 17:36, coleen.phillimore at oracle.com wrote: > > > On 5/2/19 12:44 PM, Stefan Karlsson wrote: >> The big patch has been split up into smaller patches: >> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/01.compressed/ > > Not a small patch, but this looks great.? I really like the change to > move compressed oops out of universe. >> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/02.verifyOption/ > > Good too. >> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/03.isGCActiveMark/ >> > > Ok. >> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/04.oopRecorder/ > > Ok. >> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/05.memAllocator/ > > Ok, seems unrelated though. It moves the usage of Universe::heap() to the cpp file. So, unrelated to the CompressedOops patch, but related to the universe.hpp include cleanups. > >> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/06.oopFactory/ > > Not sure why you have this.? oopFactory.hpp still includes > universe.hpp which I thought was the purpose of moving the function > bodies to the cpp file. When splitting the big patch into smaller patches I didn't want to mess around with the includes, and I deferred the removal of the include to the last patch. This way there's less risk that these smaller changes cause any compilation breakages. > >> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/07.oopsHierarchy/ >> > > Seems unrelated but sure. I added oopsHierarchy.hpp to one of the header files and didn't want globals.hpp to spread through to other header files. To minimize this change, I propose that we instead do the following: diff --git a/src/hotspot/share/oops/oopsHierarchy.hpp b/src/hotspot/share/oops/oopsHierarchy.hpp --- a/src/hotspot/share/oops/oopsHierarchy.hpp +++ b/src/hotspot/share/oops/oopsHierarchy.hpp @@ -27,7 +27,6 @@ ?#include "metaprogramming/integralConstant.hpp" ?#include "metaprogramming/primitiveConversions.hpp" -#include "runtime/globals.hpp" ?#include "utilities/globalDefinitions.hpp" ?// OBJECT hierarchy @@ -75,6 +74,8 @@ ?class PromotedObject; ?class oopDesc; +extern bool CheckUnhandledOops; + ?class oop { ?? oopDesc* _o; > ? Can you make all of set_obj() in the cpp file?? For some reason gdb > is stepping through this lately. > > 1201??? ? oop mirror???????????? = > java_lang_reflect_Method::clazz(method_mirror); > (gdb) n > 100??? ? oopDesc* obj()? const volatile????? { return _o; } > (gdb) > 90??? ? void raw_set_obj(const void* p)???? { _o = (oopDesc*)p; } > (gdb) > 97??? ??? if (CheckUnhandledOops) unregister_oop(); > (gdb) > 1202??? ? int slot?????????????? = > java_lang_reflect_Method::slot(method_mirror); I talked to Coleen about this, and we agreed to leave this for now. > >> >> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/08.fixIncludes/ > > Looks good.? universe.hpp is now not included by hpp files and > redistributed to cpp files that need it.? Unsettling how many files > need it. Right. There might be further opportunities to split universe.hpp. One common pattern that requires univese.hpp is Universe::heap()->some_function(). All those places require includes of both universe.hpp and collectedHeap.hpp. There might be a clean way to change that, so that we only need one include ... Thanks. > > Coleen >> >> All patches together: >> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/all/ >> >> Thanks, >> StefanK >> >> On 2019-05-02 16:17, Stefan Karlsson wrote: >>> On 2019-05-02 16:12, coleen.phillimore at oracle.com wrote: >>>> >>>> Hi Stefan, This seems fine but I'd really like to have the #include >>>> universe.hpp part of the patch broken out, as much as possible. >>> >>> OK. Thanks for the feedback. Let me work on that and get back to you >>> with a few separate patches. >>> >>> Thanks, >>> StefanK >>> >>>> >>>> Thanks, >>>> Coleen >>>> >>>> On 5/2/19 8:44 AM, Stefan Karlsson wrote: >>>>> Hi all, >>>>> >>>>> Rebased on top of latest changes (jdk/jdk @ edd709e64ea1): >>>>> ?http://cr.openjdk.java.net/~stefank/8223136/webrev.02/ >>>>> >>>>> Thanks, >>>>> StefanK >>>>> >>>>> >>>>> On 2019-04-30 10:58, Stefan Karlsson wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review this patch to move the rest of the compressed oops >>>>>> functions and variables over to CompressedOops. >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8223136 >>>>>> >>>>>> In 'JDK-8199946: Move load/store and encode/decode out of >>>>>> oopDesc' the decoding and encoding of compressed oops were moved >>>>>> into the namespace named CompressedOops. >>>>>> >>>>>> There infrastructure used by these functions were left in >>>>>> Universe. This patch moves rest of the functions and variables >>>>>> over to CompressedOops. I decided to convert the CompressedOops >>>>>> namespace into a proper AllStatic class, to avoid any potential >>>>>> problems with VMStructs. >>>>>> >>>>>> I also moved the corresponding functionality for compressed klass >>>>>> pointers into a new class named CompressedKlassPointers. >>>>>> >>>>>> While doing this change I decided to cleanup the includes >>>>>> regarding compressed oops, and universe.hpp, where most of the >>>>>> code was moved from. Therefore, the patch is touching a large >>>>>> number of files. A lot of the files contain updated header >>>>>> includes and simple renames. If you want to fast-forward through >>>>>> those, these are the main files where code related to compressed >>>>>> oops actually moved: >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/universe.cpp.udiff.html >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/universe.hpp.udiff.html >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/compressedOops.hpp.html >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/compressedOops.inline.hpp.udiff.html >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/klass.cpp.udiff.html >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/klass.hpp.udiff.html >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/klass.inline.hpp.udiff.html >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/oop.cpp.udiff.html >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/oop.hpp.udiff.html >>>>>> >>>>>> >>>>>> To get cleaner includes I did some minor restructuring to other >>>>>> files. I can do these changes a small preparation patches, but >>>>>> would like to get feedback on the overall patch first. >>>>>> >>>>>> Move flag checking out of hpp file, to stop propagation of >>>>>> globals.hpp to all places where compressedOops.hpp is included: >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.cpp.udiff.html >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.hpp.udiff.html >>>>>> >>>>>> >>>>>> Extract VerifyOption out of universe.hpp: >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/verifyOption.hpp.html >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/verifyOption.hpp.html >>>>>> >>>>>> >>>>>> Moves a usage of CompressedOops to the cpp file: >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/opto/matcher.cpp.udiff.html >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/opto/matcher.hpp.udiff.html >>>>>> >>>>>> >>>>>> Move Universe usage out of hpp files >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/memAllocator.hpp.udiff.html >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/memAllocator.cpp.udiff.html >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/isGCActiveMark.hpp.udiff.html >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/isGCActiveMark.cpp.html >>>>>> >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.cpp.udiff.html >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.hpp.udiff.html >>>>>> >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/code/oopRecorder.hpp.udiff.html >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/code/oopRecorder.inline.hpp.html >>>>>> >>>>>> >>>>>> I've tried to update all platforms, but would appreciate >>>>>> verification from platform maintainers that the changes don't >>>>>> break the build. >>>>>> >>>>>> I've also left some of the old names in JVMCI, to not disturb >>>>>> ongoing changes in that area. >>>>>> >>>>>> Thanks, >>>>>> StefanK >>>> >>> >> > From coleen.phillimore at oracle.com Tue May 7 18:27:57 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 7 May 2019 14:27:57 -0400 Subject: RFR: 8223136: Move compressed oops functions to CompressedOops class In-Reply-To: <325c4923-1f39-fcfb-685c-8cf77b165540@oracle.com> References: <61cb41e8-fcd5-845f-e57f-7a2d46c0c995@oracle.com> <612339e6-e693-c1c9-51f6-9316aa90874b@oracle.com> <6f674d7f-b0ac-38d4-3b70-8a9e683e8022@oracle.com> <325c4923-1f39-fcfb-685c-8cf77b165540@oracle.com> Message-ID: On 5/7/19 2:02 PM, Stefan Karlsson wrote: > Thanks for reviewing! > > Inlined: > > On 2019-05-07 17:36, coleen.phillimore at oracle.com wrote: >> >> >> On 5/2/19 12:44 PM, Stefan Karlsson wrote: >>> The big patch has been split up into smaller patches: >>> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/01.compressed/ >> >> Not a small patch, but this looks great.? I really like the change to >> move compressed oops out of universe. >>> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/02.verifyOption/ >>> >> >> Good too. >>> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/03.isGCActiveMark/ >>> >> >> Ok. >>> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/04.oopRecorder/ >> >> Ok. >>> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/05.memAllocator/ >>> >> >> Ok, seems unrelated though. > > It moves the usage of Universe::heap() to the cpp file. So, unrelated > to the CompressedOops patch, but related to the universe.hpp include > cleanups. > >> >>> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/06.oopFactory/ >> >> Not sure why you have this.? oopFactory.hpp still includes >> universe.hpp which I thought was the purpose of moving the function >> bodies to the cpp file. > > When splitting the big patch into smaller patches I didn't want to > mess around with the includes, and I deferred the removal of the > include to the last patch. This way there's less risk that these > smaller changes cause any compilation breakages. Ok, I see. > >> >>> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/07.oopsHierarchy/ >>> >> >> Seems unrelated but sure. > > I added oopsHierarchy.hpp to one of the header files and didn't want > globals.hpp to spread through to other header files. To minimize this > change, I propose that we instead do the following: > > diff --git a/src/hotspot/share/oops/oopsHierarchy.hpp > b/src/hotspot/share/oops/oopsHierarchy.hpp > --- a/src/hotspot/share/oops/oopsHierarchy.hpp > +++ b/src/hotspot/share/oops/oopsHierarchy.hpp > @@ -27,7 +27,6 @@ > > ?#include "metaprogramming/integralConstant.hpp" > ?#include "metaprogramming/primitiveConversions.hpp" > -#include "runtime/globals.hpp" > ?#include "utilities/globalDefinitions.hpp" > > ?// OBJECT hierarchy > @@ -75,6 +74,8 @@ > ?class PromotedObject; > ?class oopDesc; > > +extern bool CheckUnhandledOops; > + > ?class oop { > ?? oopDesc* _o; > Not ideal, but ok.? What you had might not hurt performance of fastdebug, but you'd have to measure it.? This can be done some other time. > >> ? Can you make all of set_obj() in the cpp file?? For some reason gdb >> is stepping through this lately. >> >> 1201??? ? oop mirror???????????? = >> java_lang_reflect_Method::clazz(method_mirror); >> (gdb) n >> 100??? ? oopDesc* obj()? const volatile????? { return _o; } >> (gdb) >> 90??? ? void raw_set_obj(const void* p)???? { _o = (oopDesc*)p; } >> (gdb) >> 97??? ??? if (CheckUnhandledOops) unregister_oop(); >> (gdb) >> 1202??? ? int slot?????????????? = >> java_lang_reflect_Method::slot(method_mirror); > > I talked to Coleen about this, and we agreed to leave this for now. > >> >>> >>> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/08.fixIncludes/ >> >> Looks good.? universe.hpp is now not included by hpp files and >> redistributed to cpp files that need it.? Unsettling how many files >> need it. > > Right. There might be further opportunities to split universe.hpp. One > common pattern that requires univese.hpp is > Universe::heap()->some_function(). All those places require includes > of both universe.hpp and collectedHeap.hpp. There might be a clean way > to change that, so that we only need one include ... I agree. thanks for doing this cleanup. Coleen > > Thanks. > >> >> Coleen >>> >>> All patches together: >>> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/all/ >>> >>> Thanks, >>> StefanK >>> >>> On 2019-05-02 16:17, Stefan Karlsson wrote: >>>> On 2019-05-02 16:12, coleen.phillimore at oracle.com wrote: >>>>> >>>>> Hi Stefan, This seems fine but I'd really like to have the >>>>> #include universe.hpp part of the patch broken out, as much as >>>>> possible. >>>> >>>> OK. Thanks for the feedback. Let me work on that and get back to >>>> you with a few separate patches. >>>> >>>> Thanks, >>>> StefanK >>>> >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 5/2/19 8:44 AM, Stefan Karlsson wrote: >>>>>> Hi all, >>>>>> >>>>>> Rebased on top of latest changes (jdk/jdk @ edd709e64ea1): >>>>>> ?http://cr.openjdk.java.net/~stefank/8223136/webrev.02/ >>>>>> >>>>>> Thanks, >>>>>> StefanK >>>>>> >>>>>> >>>>>> On 2019-04-30 10:58, Stefan Karlsson wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review this patch to move the rest of the compressed oops >>>>>>> functions and variables over to CompressedOops. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01 >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223136 >>>>>>> >>>>>>> In 'JDK-8199946: Move load/store and encode/decode out of >>>>>>> oopDesc' the decoding and encoding of compressed oops were moved >>>>>>> into the namespace named CompressedOops. >>>>>>> >>>>>>> There infrastructure used by these functions were left in >>>>>>> Universe. This patch moves rest of the functions and variables >>>>>>> over to CompressedOops. I decided to convert the CompressedOops >>>>>>> namespace into a proper AllStatic class, to avoid any potential >>>>>>> problems with VMStructs. >>>>>>> >>>>>>> I also moved the corresponding functionality for compressed >>>>>>> klass pointers into a new class named CompressedKlassPointers. >>>>>>> >>>>>>> While doing this change I decided to cleanup the includes >>>>>>> regarding compressed oops, and universe.hpp, where most of the >>>>>>> code was moved from. Therefore, the patch is touching a large >>>>>>> number of files. A lot of the files contain updated header >>>>>>> includes and simple renames. If you want to fast-forward through >>>>>>> those, these are the main files where code related to compressed >>>>>>> oops actually moved: >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/universe.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/universe.hpp.udiff.html >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/compressedOops.hpp.html >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/compressedOops.inline.hpp.udiff.html >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/klass.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/klass.hpp.udiff.html >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/klass.inline.hpp.udiff.html >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/oop.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/oop.hpp.udiff.html >>>>>>> >>>>>>> >>>>>>> To get cleaner includes I did some minor restructuring to other >>>>>>> files. I can do these changes a small preparation patches, but >>>>>>> would like to get feedback on the overall patch first. >>>>>>> >>>>>>> Move flag checking out of hpp file, to stop propagation of >>>>>>> globals.hpp to all places where compressedOops.hpp is included: >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.hpp.udiff.html >>>>>>> >>>>>>> >>>>>>> Extract VerifyOption out of universe.hpp: >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/verifyOption.hpp.html >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/verifyOption.hpp.html >>>>>>> >>>>>>> >>>>>>> Moves a usage of CompressedOops to the cpp file: >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/opto/matcher.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/opto/matcher.hpp.udiff.html >>>>>>> >>>>>>> >>>>>>> Move Universe usage out of hpp files >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/memAllocator.hpp.udiff.html >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/memAllocator.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/isGCActiveMark.hpp.udiff.html >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/isGCActiveMark.cpp.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.hpp.udiff.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/code/oopRecorder.hpp.udiff.html >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/code/oopRecorder.inline.hpp.html >>>>>>> >>>>>>> >>>>>>> I've tried to update all platforms, but would appreciate >>>>>>> verification from platform maintainers that the changes don't >>>>>>> break the build. >>>>>>> >>>>>>> I've also left some of the old names in JVMCI, to not disturb >>>>>>> ongoing changes in that area. >>>>>>> >>>>>>> Thanks, >>>>>>> StefanK >>>>> >>>> >>> >> > From ekaterina.pavlova at oracle.com Tue May 7 18:48:16 2019 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Tue, 7 May 2019 11:48:16 -0700 Subject: RFR(T) 8223414: ProblemList java/lang/ref/ReachabilityFenceTest.java when running in Graal as JIT mode Message-ID: Hi all, Please review trivial change which adds java/lang/ref/ReachabilityFenceTest.java in Graal problem list. java/lang/ref/ReachabilityFenceTest.java regularly fails when running in Graal as JIT mode. Vladimir I. provided detailed explanations (see JDK-8146090) why this test could fail with Graal. It seems reasonable to disable this tests from running with Graal till we have libgraal. JBS: https://bugs.openjdk.java.net/browse/JDK-8223414 webrev: http://cr.openjdk.java.net/~epavlova//8223414/webrev.00/index.html thanks, -katya From coleen.phillimore at oracle.com Tue May 7 18:58:18 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 7 May 2019 14:58:18 -0400 Subject: RFR (S) 8223391: Unsynchronized iteration of ClassLoaderDataGraph In-Reply-To: <1ffdc2a7-1841-2e54-86fa-4cf34d1e924e@oracle.com> References: <7507c7ea-cff8-e865-27a3-178a6313adf4@oracle.com> <1a3bae2f-52e4-0175-6c25-4376d6db4585@oracle.com> <1ffdc2a7-1841-2e54-86fa-4cf34d1e924e@oracle.com> Message-ID: Thank you, Harold and Lois! Coleen On 5/7/19 11:51 AM, Lois Foltan wrote: > +1. > Lois > > On 5/7/2019 11:24 AM, Harold Seigel wrote: >> Hi Coleen, >> >> Looks good! >> >> Harold >> >> On 5/7/2019 10:48 AM, coleen.phillimore at oracle.com wrote: >>> Summary: lock in G1 before clear_claimed_marks >>> >>> See bug for details: >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2019/8223391.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8223391 >>> >>> Thanks, >>> Coleen >>> >>> Ran|mach5 >>> hs-tier5-gc,hs-tier6-gc,hs-tier7-gc,hs-tier8-gc,hs-tier1,hs-tier2,hs-tier3|| >>> | > From stefan.karlsson at oracle.com Tue May 7 19:28:05 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 7 May 2019 21:28:05 +0200 Subject: RFR: 8223136: Move compressed oops functions to CompressedOops class In-Reply-To: References: <61cb41e8-fcd5-845f-e57f-7a2d46c0c995@oracle.com> <612339e6-e693-c1c9-51f6-9316aa90874b@oracle.com> <6f674d7f-b0ac-38d4-3b70-8a9e683e8022@oracle.com> <325c4923-1f39-fcfb-685c-8cf77b165540@oracle.com> Message-ID: <7ac5ee51-9e71-45c6-3a72-4cb54ba9c688@oracle.com> These are the latest patches (on jdk/jdk @ 61049e91eae5): ?http://cr.openjdk.java.net/~stefank/8223136/webrev.04/01.compressed/ ?http://cr.openjdk.java.net/~stefank/8223136/webrev.04/02.verifyOption/ ?http://cr.openjdk.java.net/~stefank/8223136/webrev.04/03.isGCActiveMark/ ?http://cr.openjdk.java.net/~stefank/8223136/webrev.04/04.oopRecorder/ ?http://cr.openjdk.java.net/~stefank/8223136/webrev.04/05.memAllocator/ ?http://cr.openjdk.java.net/~stefank/8223136/webrev.04/06.oopFactory/ ?http://cr.openjdk.java.net/~stefank/8223136/webrev.04/07.fixIncludes/ ?http://cr.openjdk.java.net/~stefank/8223136/webrev.04/all/ I folded the oopsHierarchy change below into the fixIncludes patch. I also found that I hadn't updated all ppc files, so that's fixed as well. This compiles locally on Linux x64. I'll also test that it still works on the platforms we build on. Thanks, StefanK On 2019-05-07 20:27, coleen.phillimore at oracle.com wrote: > > > On 5/7/19 2:02 PM, Stefan Karlsson wrote: >> Thanks for reviewing! >> >> Inlined: >> >> On 2019-05-07 17:36, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 5/2/19 12:44 PM, Stefan Karlsson wrote: >>>> The big patch has been split up into smaller patches: >>>> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/01.compressed/ >>> >>> Not a small patch, but this looks great.? I really like the change >>> to move compressed oops out of universe. >>>> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/02.verifyOption/ >>>> >>> >>> Good too. >>>> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/03.isGCActiveMark/ >>>> >>> >>> Ok. >>>> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/04.oopRecorder/ >>>> >>> >>> Ok. >>>> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/05.memAllocator/ >>>> >>> >>> Ok, seems unrelated though. >> >> It moves the usage of Universe::heap() to the cpp file. So, unrelated >> to the CompressedOops patch, but related to the universe.hpp include >> cleanups. >> >>> >>>> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/06.oopFactory/ >>> >>> Not sure why you have this.? oopFactory.hpp still includes >>> universe.hpp which I thought was the purpose of moving the function >>> bodies to the cpp file. >> >> When splitting the big patch into smaller patches I didn't want to >> mess around with the includes, and I deferred the removal of the >> include to the last patch. This way there's less risk that these >> smaller changes cause any compilation breakages. > > Ok, I see. >> >>> >>>> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/07.oopsHierarchy/ >>>> >>> >>> Seems unrelated but sure. >> >> I added oopsHierarchy.hpp to one of the header files and didn't want >> globals.hpp to spread through to other header files. To minimize this >> change, I propose that we instead do the following: >> >> diff --git a/src/hotspot/share/oops/oopsHierarchy.hpp >> b/src/hotspot/share/oops/oopsHierarchy.hpp >> --- a/src/hotspot/share/oops/oopsHierarchy.hpp >> +++ b/src/hotspot/share/oops/oopsHierarchy.hpp >> @@ -27,7 +27,6 @@ >> >> ?#include "metaprogramming/integralConstant.hpp" >> ?#include "metaprogramming/primitiveConversions.hpp" >> -#include "runtime/globals.hpp" >> ?#include "utilities/globalDefinitions.hpp" >> >> ?// OBJECT hierarchy >> @@ -75,6 +74,8 @@ >> ?class PromotedObject; >> ?class oopDesc; >> >> +extern bool CheckUnhandledOops; >> + >> ?class oop { >> ?? oopDesc* _o; >> > > Not ideal, but ok.? What you had might not hurt performance of > fastdebug, but you'd have to measure it.? This can be done some other > time. >> >>> ? Can you make all of set_obj() in the cpp file?? For some reason >>> gdb is stepping through this lately. >>> >>> 1201??? ? oop mirror???????????? = >>> java_lang_reflect_Method::clazz(method_mirror); >>> (gdb) n >>> 100??? ? oopDesc* obj()? const volatile????? { return _o; } >>> (gdb) >>> 90??? ? void raw_set_obj(const void* p)???? { _o = (oopDesc*)p; } >>> (gdb) >>> 97??? ??? if (CheckUnhandledOops) unregister_oop(); >>> (gdb) >>> 1202??? ? int slot?????????????? = >>> java_lang_reflect_Method::slot(method_mirror); >> >> I talked to Coleen about this, and we agreed to leave this for now. >> >>> >>>> >>>> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/08.fixIncludes/ >>>> >>> >>> Looks good.? universe.hpp is now not included by hpp files and >>> redistributed to cpp files that need it.? Unsettling how many files >>> need it. >> >> Right. There might be further opportunities to split universe.hpp. >> One common pattern that requires univese.hpp is >> Universe::heap()->some_function(). All those places require includes >> of both universe.hpp and collectedHeap.hpp. There might be a clean >> way to change that, so that we only need one include ... > > I agree. > > thanks for doing this cleanup. > Coleen >> >> Thanks. >> >>> >>> Coleen >>>> >>>> All patches together: >>>> ?https://cr.openjdk.java.net/~stefank/8223136/webrev.03/all/ >>>> >>>> Thanks, >>>> StefanK >>>> >>>> On 2019-05-02 16:17, Stefan Karlsson wrote: >>>>> On 2019-05-02 16:12, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>> Hi Stefan, This seems fine but I'd really like to have the >>>>>> #include universe.hpp part of the patch broken out, as much as >>>>>> possible. >>>>> >>>>> OK. Thanks for the feedback. Let me work on that and get back to >>>>> you with a few separate patches. >>>>> >>>>> Thanks, >>>>> StefanK >>>>> >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> On 5/2/19 8:44 AM, Stefan Karlsson wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Rebased on top of latest changes (jdk/jdk @ edd709e64ea1): >>>>>>> ?http://cr.openjdk.java.net/~stefank/8223136/webrev.02/ >>>>>>> >>>>>>> Thanks, >>>>>>> StefanK >>>>>>> >>>>>>> >>>>>>> On 2019-04-30 10:58, Stefan Karlsson wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review this patch to move the rest of the compressed >>>>>>>> oops functions and variables over to CompressedOops. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01 >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223136 >>>>>>>> >>>>>>>> In 'JDK-8199946: Move load/store and encode/decode out of >>>>>>>> oopDesc' the decoding and encoding of compressed oops were >>>>>>>> moved into the namespace named CompressedOops. >>>>>>>> >>>>>>>> There infrastructure used by these functions were left in >>>>>>>> Universe. This patch moves rest of the functions and variables >>>>>>>> over to CompressedOops. I decided to convert the CompressedOops >>>>>>>> namespace into a proper AllStatic class, to avoid any potential >>>>>>>> problems with VMStructs. >>>>>>>> >>>>>>>> I also moved the corresponding functionality for compressed >>>>>>>> klass pointers into a new class named CompressedKlassPointers. >>>>>>>> >>>>>>>> While doing this change I decided to cleanup the includes >>>>>>>> regarding compressed oops, and universe.hpp, where most of the >>>>>>>> code was moved from. Therefore, the patch is touching a large >>>>>>>> number of files. A lot of the files contain updated header >>>>>>>> includes and simple renames. If you want to fast-forward >>>>>>>> through those, these are the main files where code related to >>>>>>>> compressed oops actually moved: >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/universe.cpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/universe.hpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/compressedOops.hpp.html >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/compressedOops.inline.hpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/klass.cpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/klass.hpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/klass.inline.hpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/oop.cpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/oops/oop.hpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> To get cleaner includes I did some minor restructuring to other >>>>>>>> files. I can do these changes a small preparation patches, but >>>>>>>> would like to get feedback on the overall patch first. >>>>>>>> >>>>>>>> Move flag checking out of hpp file, to stop propagation of >>>>>>>> globals.hpp to all places where compressedOops.hpp is included: >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.cpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.hpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> Extract VerifyOption out of universe.hpp: >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/verifyOption.hpp.html >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/verifyOption.hpp.html >>>>>>>> >>>>>>>> >>>>>>>> Moves a usage of CompressedOops to the cpp file: >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/opto/matcher.cpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/opto/matcher.hpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> Move Universe usage out of hpp files >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/memAllocator.hpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/memAllocator.cpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/isGCActiveMark.hpp.udiff.html >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/gc/shared/isGCActiveMark.cpp.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.cpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/memory/oopFactory.hpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/code/oopRecorder.hpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~stefank/8223136/webrev.01/src/hotspot/share/code/oopRecorder.inline.hpp.html >>>>>>>> >>>>>>>> >>>>>>>> I've tried to update all platforms, but would appreciate >>>>>>>> verification from platform maintainers that the changes don't >>>>>>>> break the build. >>>>>>>> >>>>>>>> I've also left some of the old names in JVMCI, to not disturb >>>>>>>> ongoing changes in that area. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> StefanK >>>>>> >>>>> >>>> >>> >> > From vladimir.kozlov at oracle.com Tue May 7 21:14:31 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 7 May 2019 14:14:31 -0700 Subject: RFR(T) 8223414: ProblemList java/lang/ref/ReachabilityFenceTest.java when running in Graal as JIT mode In-Reply-To: References: Message-ID: Looks good. Thanks, Vladimir On 5/7/19 11:48 AM, Ekaterina Pavlova wrote: > Hi all, > > Please review trivial change which adds java/lang/ref/ReachabilityFenceTest.java in Graal problem list. > java/lang/ref/ReachabilityFenceTest.java regularly fails when running in Graal as JIT mode. > Vladimir I. provided detailed explanations (see JDK-8146090) why this test could fail with Graal. > It seems reasonable to disable this tests from running with Graal till we have libgraal. > > ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8223414 > ?webrev: http://cr.openjdk.java.net/~epavlova//8223414/webrev.00/index.html > > thanks, > -katya From boris.ulasevich at bell-sw.com Wed May 8 08:17:47 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Wed, 8 May 2019 11:17:47 +0300 Subject: RFR (S) 8223472: volatile long field corruption on x86_32 Message-ID: Hi all, Please review a simple change to fix long field store atomicity for 32-bit x86 interpreter. http://bugs.openjdk.java.net/browse/JDK-8223472 http://cr.openjdk.java.net/~bulasevich/8223472/webrev.00 thanks, Boris From shade at redhat.com Wed May 8 08:22:10 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 8 May 2019 10:22:10 +0200 Subject: RFR (S) 8223472: volatile long field corruption on x86_32 In-Reply-To: References: Message-ID: On 5/8/19 10:17 AM, Boris Ulasevich wrote: > Please review a simple change to fix long field store atomicity for 32-bit x86 interpreter. > > http://bugs.openjdk.java.net/browse/JDK-8223472 > http://cr.openjdk.java.net/~bulasevich/8223472/webrev.00 Whoa. Patch looks good. -Aleksey From shade at redhat.com Wed May 8 08:28:13 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 8 May 2019 10:28:13 +0200 Subject: RFR (S) 8223472: volatile long field corruption on x86_32 In-Reply-To: References: Message-ID: On 5/8/19 10:22 AM, Aleksey Shipilev wrote: > On 5/8/19 10:17 AM, Boris Ulasevich wrote: >> Please review a simple change to fix long field store atomicity for 32-bit x86 interpreter. >> >> http://bugs.openjdk.java.net/browse/JDK-8223472 >> http://cr.openjdk.java.net/~bulasevich/8223472/webrev.00 > > Whoa. Patch looks good. Nit: Webrev is against 12u. I am sure the patch applies to jdk/jdk, check that you are planning to push there? -Aleksey From boris.ulasevich at bell-sw.com Wed May 8 08:43:36 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Wed, 8 May 2019 11:43:36 +0300 Subject: RFR (S) 8223472: volatile long field corruption on x86_32 In-Reply-To: References: Message-ID: Thanks! Yes, patch applies cleanly to jdk-jdk. We are going to apply patch there, and then backport it to jdk12. On 08.05.2019 11:28, Aleksey Shipilev wrote: > On 5/8/19 10:22 AM, Aleksey Shipilev wrote: >> On 5/8/19 10:17 AM, Boris Ulasevich wrote: >>> Please review a simple change to fix long field store atomicity for 32-bit x86 interpreter. >>> >>> http://bugs.openjdk.java.net/browse/JDK-8223472 >>> http://cr.openjdk.java.net/~bulasevich/8223472/webrev.00 >> >> Whoa. Patch looks good. > > Nit: Webrev is against 12u. I am sure the patch applies to jdk/jdk, check that you are planning to > push there? > > -Aleksey From erik.osterlund at oracle.com Wed May 8 09:07:20 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 8 May 2019 11:07:20 +0200 Subject: RFR (S) 8223472: volatile long field corruption on x86_32 In-Reply-To: References: Message-ID: <70af2f86-898d-0821-49fe-15071481f2f7@oracle.com> Hi Boris, Thank you for fixing this. Looks good to me. /Erik On 2019-05-08 10:17, Boris Ulasevich wrote: > Hi all, > > Please review a simple change to fix long field store atomicity for > 32-bit x86 interpreter. > > http://bugs.openjdk.java.net/browse/JDK-8223472 > http://cr.openjdk.java.net/~bulasevich/8223472/webrev.00 > > thanks, > Boris From Pengfei.Li at arm.com Wed May 8 10:15:21 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Wed, 8 May 2019 10:15:21 +0000 Subject: RFR(T): 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled Message-ID: Hi, Could anyone help review this patch (tiny change on 75 test files)? Webrev: http://cr.openjdk.java.net/~pli/rfr/8223427/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8223427 JVMCI compiler supports only a few OpenJDK GCs (only Serial, Parallel, ParallelOld and G1). In current jtreg cases, when Graal is enabled, other GC test cases are skipped except Shenandoah. We should add "!vm.graal.enabled" together with the "@requires vm.gc.Shenandoah" annotation in gc test cases to skip Shenandoah as well. -- Thanks, Pengfei From thomas.schatzl at oracle.com Wed May 8 11:11:03 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 08 May 2019 13:11:03 +0200 Subject: RFR (S) 8223391: Unsynchronized iteration of ClassLoaderDataGraph In-Reply-To: <7507c7ea-cff8-e865-27a3-178a6313adf4@oracle.com> References: <7507c7ea-cff8-e865-27a3-178a6313adf4@oracle.com> Message-ID: Hi, On Tue, 2019-05-07 at 10:48 -0400, coleen.phillimore at oracle.com wrote: > Summary: lock in G1 before clear_claimed_marks > > See bug for details: > > open webrev at > http://cr.openjdk.java.net/~coleenp/2019/8223391.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8223391 > > Thanks, > Coleen > > Ran|mach5 > hs-tier5-gc,hs-tier6-gc,hs-tier7-gc,hs-tier8-gc,hs-tier1,hs-tier2,hs- > tier3|| > > looks good. Thomas From shade at redhat.com Wed May 8 11:16:23 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 8 May 2019 13:16:23 +0200 Subject: RFR(T): 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled In-Reply-To: References: Message-ID: On 5/8/19 12:15 PM, Pengfei Li (Arm Technology China) wrote: > Could anyone help review this patch (tiny change on 75 test files)? > > Webrev: http://cr.openjdk.java.net/~pli/rfr/8223427/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8223427 Looks good. We already have a few tests that do "@requires vm.gc.Shenandoah & !vm.graal.enabled". -Aleksey From coleen.phillimore at oracle.com Wed May 8 11:17:26 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 8 May 2019 07:17:26 -0400 Subject: RFR (S) 8223391: Unsynchronized iteration of ClassLoaderDataGraph In-Reply-To: References: <7507c7ea-cff8-e865-27a3-178a6313adf4@oracle.com> Message-ID: <255eb4be-9b52-f4b2-68d7-1da1ebeb2a8b@oracle.com> Thanks Thomas! Coleen On 5/8/19 7:11 AM, Thomas Schatzl wrote: > Hi, > > On Tue, 2019-05-07 at 10:48 -0400, coleen.phillimore at oracle.com wrote: >> Summary: lock in G1 before clear_claimed_marks >> >> See bug for details: >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8223391.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8223391 >> >> Thanks, >> Coleen >> >> Ran|mach5 >> hs-tier5-gc,hs-tier6-gc,hs-tier7-gc,hs-tier8-gc,hs-tier1,hs-tier2,hs- >> tier3|| > looks good. > > Thomas > > From david.holmes at oracle.com Wed May 8 12:01:34 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 8 May 2019 22:01:34 +1000 Subject: RFR (S) 8223472: volatile long field corruption on x86_32 In-Reply-To: <70af2f86-898d-0821-49fe-15071481f2f7@oracle.com> References: <70af2f86-898d-0821-49fe-15071481f2f7@oracle.com> Message-ID: <18ea25be-f480-9c45-352c-e49d39316b3b@oracle.com> I would very much like an explanation of how this lack of MO_RELAXED causes a lack of _atomicity_! What has "MO" got to do with that? And why would a volatile access be "relaxed" or "unordered"? This is not making any sense to me at all. Thanks, David On 8/05/2019 7:07 pm, Erik ?sterlund wrote: > Hi Boris, > > Thank you for fixing this. Looks good to me. > > /Erik > > On 2019-05-08 10:17, Boris Ulasevich wrote: >> Hi all, >> >> Please review a simple change to fix long field store atomicity for >> 32-bit x86 interpreter. >> >> http://bugs.openjdk.java.net/browse/JDK-8223472 >> http://cr.openjdk.java.net/~bulasevich/8223472/webrev.00 >> >> thanks, >> Boris > From erik.osterlund at oracle.com Wed May 8 12:12:16 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 8 May 2019 14:12:16 +0200 Subject: RFR (S) 8223472: volatile long field corruption on x86_32 In-Reply-To: <18ea25be-f480-9c45-352c-e49d39316b3b@oracle.com> References: <70af2f86-898d-0821-49fe-15071481f2f7@oracle.com> <18ea25be-f480-9c45-352c-e49d39316b3b@oracle.com> Message-ID: <2c7db7f2-8e50-ab20-6b4a-d5d364b22773@oracle.com> Hi David, The name "relaxed" comes from std::memory_order_release, which implies atomicity. From accessDecorators.hpp: "MO_RELAXED is equivalent to JMM opaque." From JMM opaque definition on Doug Lea's website: "If Opaque (or any stronger) mode is used for all accesses, then reads of all types, including long and double, are guaranteed not to mix the bits of multiple writes." (i.e. atomicity) In the implementation of the access for x86 (_32) BarrierSetAssembler::store_at, the backend looks at MO_RELAXED and uses that to determine if the access should be atomic. So it is quite intentional that a relaxed access is indeed atomic. /Erik On 2019-05-08 14:01, David Holmes wrote: > I would very much like an explanation of how this lack of MO_RELAXED > causes a lack of _atomicity_! What has "MO" got to do with that? And > why would a volatile access be "relaxed" or "unordered"? > > This is not making any sense to me at all. > > Thanks, > David > > On 8/05/2019 7:07 pm, Erik ?sterlund wrote: >> Hi Boris, >> >> Thank you for fixing this. Looks good to me. >> >> /Erik >> >> On 2019-05-08 10:17, Boris Ulasevich wrote: >>> Hi all, >>> >>> Please review a simple change to fix long field store atomicity for >>> 32-bit x86 interpreter. >>> >>> http://bugs.openjdk.java.net/browse/JDK-8223472 >>> http://cr.openjdk.java.net/~bulasevich/8223472/webrev.00 >>> >>> thanks, >>> Boris >> From coleen.phillimore at oracle.com Wed May 8 12:16:12 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 8 May 2019 08:16:12 -0400 Subject: RFR: 8222841: Incorrect static call stub interactions with class unloading In-Reply-To: <6f615499-6f79-ce41-d835-d64e0741a3be@oracle.com> References: <067fc16e-3104-4e61-b558-9cd4864f079f@oracle.com> <1ca35306-6be8-61ec-127f-196367d94899@oracle.com> <6f615499-6f79-ce41-d835-d64e0741a3be@oracle.com> Message-ID: On 5/2/19 4:55 AM, Erik ?sterlund wrote: > Hi Coleen, > > Thank you for the review. > > On 2019-04-23 23:32, coleen.phillimore at oracle.com wrote: >> >> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp.frames.html >> >> >> Can you mention in a comment that incoming rbx is the method? > > Fixed. Thank you! > >> You can't do a JRT_LEAF function from here, can you to some >> Method::is_alive() function?? Or even a straight up call ?? This >> doesn't seem that it should care about the extra overhead of the call >> instruction.? The assembly code looks correct but yuck not more >> assembly code. > > I'm not sure I know how I feel about that. I would have to save and > restore all registers then to go into the runtime just to check if the > method is alive. Would you be okay with keeping the assembly variant > instead until I find a better solution to this problem? (I'm on it) Yes, this is fine with me.? Had to register not liking more assembly. > >> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/src/hotspot/share/code/compiledMethod.cpp.frames.html >> >> >> 578 case relocInfo::static_stub_type: { >> 579 is_in_static_stub = true; >> 580 break; >> 581 } >> 582 >> 583 case relocInfo::metadata_type: { >> 584 if (!is_in_static_stub) { >> 585 continue; >> 586 } >> >> >> This was mystifying to me.? Can you put a comment that after >> static_stub_type relocations are generated, the next metadata >> relocation contains the address that is patched at runtime, so this >> is the metadata that can be stale and should be cleared by unloading. > > Sure, I updated the comments, and added a better description about > what is going on here. > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8222841/webrev.01/ > > Incremental: > http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00_01/ Looks good! Coleen > > Thanks, > /Erik > >> The clean_ic_stubs() name is my fault.? I didn't know what they were >> and just wanted this code out of my way. >> >> Thank you for explaining how redefinition is broken by this.? I >> didn't know these metadata_reloc guys were patched at runtime. >> >> Thanks, >> Coleen >> >> >> >> On 4/23/19 4:41 AM, Erik ?sterlund wrote: >>> Hi, >>> >>> Static call stubs are cleared in debug builds before an assert >>> checking for dead metadata. This is done in the function >>> "clean_ic_stubs()" (which does not clean ICStubs... but >>> static/optimized virtual call stubs for calling c2i adapters from >>> compiled code...) The reason is that the static call stub has >>> metadata, and it complains about dead metadata being left after >>> inline cache cleaning of is_alive nmethods. >>> >>> ...except class redefinition looks at this metadata to determine if >>> there is old metadata in subsequent safepoints, and they could have >>> been unloaded then. Ouch. So maybe we shouldn't squelch that assert >>> in debug builds, because it actually shows there is a real problem. >>> >>> ...and with concurrent class unloading (ZGC and seemingly soon >>> Shenandoah), we can't just clear the call stub of a concurrently >>> running JavaThread; they can racingly call in to them before they >>> get cleared, and then get stuck in an infinite loop, because >>> clearing also involves updating the branch target of the static call >>> stub to a self-loop. Or call a dead method, which also seems like a >>> scary scenario. >>> >>> All things considered, clearing static call stubs when unloading the >>> code cache seems like a bad idea. >>> >>> My proposal is the following: >>> 1) Make sure that code cache unloading *always* clears out the >>> metadata part (but not the branch part) of static call stubs, so >>> that subsequent operations such as class redefinition will not blow >>> up when looking at the embedded metadata, but it won't get stuck in >>> infinite loops with concurrent code cache unloading. >>> 2) Make a c2i entry barrier for concurrently unloading GCs that will >>> reresolve the call when calling into a stale static call stub (iff >>> method is NULL or dead). >>> 3) Relax MT-safety asserts to allow the previous medatada to be >>> concurrently unloading when setting the new target. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8222841 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/ >>> >>> Thanks, >>> /Erik >> > From boris.ulasevich at bell-sw.com Wed May 8 12:17:26 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Wed, 8 May 2019 15:17:26 +0300 Subject: RFR (S) 8223472: volatile long field corruption on x86_32 In-Reply-To: <18ea25be-f480-9c45-352c-e49d39316b3b@oracle.com> References: <70af2f86-898d-0821-49fe-15071481f2f7@oracle.com> <18ea25be-f480-9c45-352c-e49d39316b3b@oracle.com> Message-ID: <96d9839b-7edb-f05f-3aa3-b71dceb86f7b@bell-sw.com> Hi David, There is a good Memory Ordering Decorators decription in accessDecorators.hpp, see quote below. The example of how MO_RELAXED is transformed to machine instructions can be seen in barrierSetAssembler_x86.cpp src/hotspot/share/oops/accessDecorators.hpp =========================================== // == Memory Ordering Decorators == // The memory ordering decorators can be described in the following way: // === Decorator Rules === // The different types of memory ordering guarantees have a strict order of strength. // Explicitly specifying the stronger ordering implies that the guarantees of the weaker // property holds too. The names come from the C++11 atomic operations, and typically // have a JMM equivalent property. // The equivalence may be viewed like this: // MO_UNORDERED is equivalent to JMM plain. // MO_VOLATILE has no equivalence in JMM, because it's a C++ thing. // MO_RELAXED is equivalent to JMM opaque. // MO_ACQUIRE is equivalent to JMM acquire. // MO_RELEASE is equivalent to JMM release. // MO_SEQ_CST is equivalent to JMM volatile. // // === Stores === // * MO_UNORDERED (Default): No guarantees. // - The compiler and hardware are free to reorder aggressively. And they will. // * MO_VOLATILE: Volatile stores (in the C++ sense). // - The stores are not reordered by the compiler (but possibly the HW) w.r.t. other // volatile accesses in program order (but possibly non-volatile accesses). // * MO_RELAXED: Relaxed atomic stores. // - The stores are atomic. // - Guarantees from volatile stores hold. // * MO_RELEASE: Releasing stores. // - The releasing store will make its preceding memory accesses observable to memory accesses // subsequent to an acquiring load observing this releasing store. // - Guarantees from relaxed stores hold. // * MO_SEQ_CST: Sequentially consistent stores. // - The stores are observed in the same order by MO_SEQ_CST loads on other processors // - Preceding loads and stores in program order are not reordered with subsequent loads and stores in program order. // - Guarantees from releasing stores hold. // === Loads === // * MO_UNORDERED (Default): No guarantees // - The compiler and hardware are free to reorder aggressively. And they will. // * MO_VOLATILE: Volatile loads (in the C++ sense). // - The loads are not reordered by the compiler (but possibly the HW) w.r.t. other // volatile accesses in program order (but possibly non-volatile accesses). // * MO_RELAXED: Relaxed atomic loads. // - The loads are atomic. // - Guarantees from volatile loads hold. // * MO_ACQUIRE: Acquiring loads. // - An acquiring load will make subsequent memory accesses observe the memory accesses // preceding the releasing store that the acquiring load observed. // - Guarantees from relaxed loads hold. // * MO_SEQ_CST: Sequentially consistent loads. // - These loads observe MO_SEQ_CST stores in the same order on other processors // - Preceding loads and stores in program order are not reordered with subsequent loads and stores in program order. // - Guarantees from acquiring loads hold. On 08.05.2019 15:01, David Holmes wrote: > I would very much like an explanation of how this lack of MO_RELAXED > causes a lack of _atomicity_! What has "MO" got to do with that? And why > would a volatile access be "relaxed" or "unordered"? > > This is not making any sense to me at all. > > Thanks, > David > > On 8/05/2019 7:07 pm, Erik ?sterlund wrote: >> Hi Boris, >> >> Thank you for fixing this. Looks good to me. >> >> /Erik >> >> On 2019-05-08 10:17, Boris Ulasevich wrote: >>> Hi all, >>> >>> Please review a simple change to fix long field store atomicity for >>> 32-bit x86 interpreter. >>> >>> http://bugs.openjdk.java.net/browse/JDK-8223472 >>> http://cr.openjdk.java.net/~bulasevich/8223472/webrev.00 >>> >>> thanks, >>> Boris >> From erik.osterlund at oracle.com Wed May 8 12:20:15 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 8 May 2019 14:20:15 +0200 Subject: RFR: 8222841: Incorrect static call stub interactions with class unloading In-Reply-To: References: <067fc16e-3104-4e61-b558-9cd4864f079f@oracle.com> <1ca35306-6be8-61ec-127f-196367d94899@oracle.com> <6f615499-6f79-ce41-d835-d64e0741a3be@oracle.com> Message-ID: <04c23dad-67b2-f4eb-7d6f-6f24d57bbd5b@oracle.com> Hi Coleen, Thanks for the review! /Erik On 2019-05-08 14:16, coleen.phillimore at oracle.com wrote: > > > On 5/2/19 4:55 AM, Erik ?sterlund wrote: >> Hi Coleen, >> >> Thank you for the review. >> >> On 2019-04-23 23:32, coleen.phillimore at oracle.com wrote: >>> >>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp.frames.html >>> >>> >>> Can you mention in a comment that incoming rbx is the method? >> >> Fixed. > > Thank you! >> >>> You can't do a JRT_LEAF function from here, can you to some >>> Method::is_alive() function?? Or even a straight up call ?? This >>> doesn't seem that it should care about the extra overhead of the >>> call instruction.? The assembly code looks correct but yuck not more >>> assembly code. >> >> I'm not sure I know how I feel about that. I would have to save and >> restore all registers then to go into the runtime just to check if >> the method is alive. Would you be okay with keeping the assembly >> variant instead until I find a better solution to this problem? (I'm >> on it) > > Yes, this is fine with me.? Had to register not liking more assembly. >> >>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/src/hotspot/share/code/compiledMethod.cpp.frames.html >>> >>> >>> 578 case relocInfo::static_stub_type: { >>> 579 is_in_static_stub = true; >>> 580 break; >>> 581 } >>> 582 >>> 583 case relocInfo::metadata_type: { >>> 584 if (!is_in_static_stub) { >>> 585 continue; >>> 586 } >>> >>> >>> This was mystifying to me.? Can you put a comment that after >>> static_stub_type relocations are generated, the next metadata >>> relocation contains the address that is patched at runtime, so this >>> is the metadata that can be stale and should be cleared by unloading. >> >> Sure, I updated the comments, and added a better description about >> what is going on here. >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.01/ >> >> Incremental: >> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00_01/ > > Looks good! > Coleen >> >> Thanks, >> /Erik >> >>> The clean_ic_stubs() name is my fault. I didn't know what they were >>> and just wanted this code out of my way. >>> >>> Thank you for explaining how redefinition is broken by this. I >>> didn't know these metadata_reloc guys were patched at runtime. >>> >>> Thanks, >>> Coleen >>> >>> >>> >>> On 4/23/19 4:41 AM, Erik ?sterlund wrote: >>>> Hi, >>>> >>>> Static call stubs are cleared in debug builds before an assert >>>> checking for dead metadata. This is done in the function >>>> "clean_ic_stubs()" (which does not clean ICStubs... but >>>> static/optimized virtual call stubs for calling c2i adapters from >>>> compiled code...) The reason is that the static call stub has >>>> metadata, and it complains about dead metadata being left after >>>> inline cache cleaning of is_alive nmethods. >>>> >>>> ...except class redefinition looks at this metadata to determine if >>>> there is old metadata in subsequent safepoints, and they could have >>>> been unloaded then. Ouch. So maybe we shouldn't squelch that assert >>>> in debug builds, because it actually shows there is a real problem. >>>> >>>> ...and with concurrent class unloading (ZGC and seemingly soon >>>> Shenandoah), we can't just clear the call stub of a concurrently >>>> running JavaThread; they can racingly call in to them before they >>>> get cleared, and then get stuck in an infinite loop, because >>>> clearing also involves updating the branch target of the static >>>> call stub to a self-loop. Or call a dead method, which also seems >>>> like a scary scenario. >>>> >>>> All things considered, clearing static call stubs when unloading >>>> the code cache seems like a bad idea. >>>> >>>> My proposal is the following: >>>> 1) Make sure that code cache unloading *always* clears out the >>>> metadata part (but not the branch part) of static call stubs, so >>>> that subsequent operations such as class redefinition will not blow >>>> up when looking at the embedded metadata, but it won't get stuck in >>>> infinite loops with concurrent code cache unloading. >>>> 2) Make a c2i entry barrier for concurrently unloading GCs that >>>> will reresolve the call when calling into a stale static call stub >>>> (iff method is NULL or dead). >>>> 3) Relax MT-safety asserts to allow the previous medatada to be >>>> concurrently unloading when setting the new target. >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8222841 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/ >>>> >>>> Thanks, >>>> /Erik >>> >> > From matthias.baesken at sap.com Wed May 8 12:57:01 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 8 May 2019 12:57:01 +0000 Subject: 8222720: Provide extended VMWare/vSphere virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: References: <44b9455e-9642-729d-6ef4-64603bdf278e@oracle.com> Message-ID: Ping - any reviews / opinions ? Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Dienstag, 30. April 2019 09:23 > To: Robbin Ehn ; 'hotspot-dev at openjdk.java.net' > > Subject: RE: 8222720: Provide extended VMWare/vSphere virtualization > related info in the hs_error file on linux/windows x86_64 > > Hello Robbin, some of the info is indeed already available on the guest (e.g. > processorMHz ). > Some of the info is about the host so we do not have it currently . > > > This is what the vsphere-guest-ha-monitoring-sdk-65-programming- > guide.pdf has to say about the metrics info : > > Host - metrics : "information about the current hypervisor and hardware the > virtual machine is running on" > Description about the different info parts : > > host.cpu.processorMHz ? nominal processor speed. Other metrics, such as > vm.cpu.used below, are normalized to this speed. > host.cpu.coresPerPkg ? actual cores per socket, not including hyperthreads. > Useful for determining cache effects and other aspects of socket sharing. > Information is also available with CPUID instruction. > Note that vSphere does not implement virtual hyperthreads. > host.cpu.packages ? number of CPU sockets on the host (non-default). > host.cpu.cores ? number of cores on the host across all sockets, not including > hyperthreads (non-default). > host.cpu.threads ? number of logical CPUs on the host across all sockets, > including hyperthreads (non-default). > host.dmi.product ? ?product? field in the host SMBIOS data (non-default). > host.dmi.vendor ? ?vendor? field in the host SMBIOS data (non-default). > > ( so the host.dmi product/vendor info might not be available depending on > the VMWare configuration ) > > > Best regards, Matthias > > > > -----Original Message----- > > From: Robbin Ehn > > Sent: Dienstag, 30. April 2019 09:04 > > To: Baesken, Matthias ; 'hotspot- > > dev at openjdk.java.net' > > Subject: Re: 8222720: Provide extended VMWare/vSphere virtualization > > related info in the hs_error file on linux/windows x86_64 > > > > Hi Matthias, > > > > If the guest env. we are running in have correct values, what can the host > > values be used for in a hs_err context? > > > > Thanks, Robbin > > > > On 2019-04-29 13:02, Baesken, Matthias wrote: > > > Hello, > > > please review the following enhancement to the VMWare/vSphere > > virtualization related info in the hs_error file on linux/windows x86_64 . > > > > > > In case the guest library from VMWare SDK 6.0 (or higher) is present > > (libvmGuestLib) or the open-vm-tools guest library is present > > > (libguestlib), we add the host and initial and current resource related > > metrics information to the hs_err file . > > > The resource info (current and first) is taken twice to see diffs over the > VM > > runtime. > > > > > > Example output for host and resource information : > > > host: > > > ------ > > > host.cpu.processorMHz = 2194 > > > host.cpu.coresPerPkg = 10 > > > host.cpu.packages = 4 > > > host.cpu.cores = 40 > > > host.cpu.threads = 80 > > > host.dmi.product = UCSC-C460-M4 > > > host.dmi.vendor = Cisco Systems Inc > > > > > > resource: > > > ---------- > > > vm.cpu.reserved = 0 > > > vm.cpu.limit = -1 > > > vm.cpu.used = 2290006442390 > > > vm.cpu.contention.cpu = 1436489771 > > > vm.cpu.contention.mem = 0 > > > vm.numa.local = 16775168 > > > vm.numa.remote = 0 > > > guest.mem.reserved = 0 > > > guest.mem.limit = 3221225456 > > > guest.mem.mapped = 16775168 > > > guest.mem.consumed = 16699172 > > > guest.mem.swapped = 0 > > > guest.mem.ballooned = 0 > > > guest.mem.swapIn = 0 > > > guest.mem.swapOut = 0 > > > ovhd.mem.swapped = 0 > > > ovhd.mem.swapIn = 0 > > > ovhd.mem.swapOut = 0 > > > > > > > > > (details on the metrics meaning can be found in the VMWare SDK > > programming guide > > > > > > https://code.vmware.com/docs/6629/guest-and-ha-application- > > monitoring-sdk-programming-guide/ > > > > > > see the subsections of "Tools for Extended Guest Statistics" ) > > > > > > > > > bug/webrev : > > > > > > https://bugs.openjdk.java.net/browse/JDK-8222720 > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8222720.1/ > > > > > > > > > Thanks, Matthias > > > From robbin.ehn at oracle.com Wed May 8 13:27:55 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 8 May 2019 15:27:55 +0200 Subject: 8222720: Provide extended VMWare/vSphere virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: References: <44b9455e-9642-729d-6ef4-64603bdf278e@oracle.com> Message-ID: Hi Matthias, Is there a problem with using os::dll_load ? Since we have these things for other proprietary hosts I guess this is fine also. Code seems okay, except above. Thanks, Robbin On 2019-05-08 14:57, Baesken, Matthias wrote: > Ping - any reviews / opinions ? > > Best regards, Matthias > > > >> -----Original Message----- >> From: Baesken, Matthias >> Sent: Dienstag, 30. April 2019 09:23 >> To: Robbin Ehn ; 'hotspot-dev at openjdk.java.net' >> >> Subject: RE: 8222720: Provide extended VMWare/vSphere virtualization >> related info in the hs_error file on linux/windows x86_64 >> >> Hello Robbin, some of the info is indeed already available on the guest (e.g. >> processorMHz ). >> Some of the info is about the host so we do not have it currently . >> >> >> This is what the vsphere-guest-ha-monitoring-sdk-65-programming- >> guide.pdf has to say about the metrics info : >> >> Host - metrics : "information about the current hypervisor and hardware the >> virtual machine is running on" >> Description about the different info parts : >> >> host.cpu.processorMHz ? nominal processor speed. Other metrics, such as >> vm.cpu.used below, are normalized to this speed. >> host.cpu.coresPerPkg ? actual cores per socket, not including hyperthreads. >> Useful for determining cache effects and other aspects of socket sharing. >> Information is also available with CPUID instruction. >> Note that vSphere does not implement virtual hyperthreads. >> host.cpu.packages ? number of CPU sockets on the host (non-default). >> host.cpu.cores ? number of cores on the host across all sockets, not including >> hyperthreads (non-default). >> host.cpu.threads ? number of logical CPUs on the host across all sockets, >> including hyperthreads (non-default). >> host.dmi.product ? ?product? field in the host SMBIOS data (non-default). >> host.dmi.vendor ? ?vendor? field in the host SMBIOS data (non-default). >> >> ( so the host.dmi product/vendor info might not be available depending on >> the VMWare configuration ) >> >> >> Best regards, Matthias >> >> >>> -----Original Message----- >>> From: Robbin Ehn >>> Sent: Dienstag, 30. April 2019 09:04 >>> To: Baesken, Matthias ; 'hotspot- >>> dev at openjdk.java.net' >>> Subject: Re: 8222720: Provide extended VMWare/vSphere virtualization >>> related info in the hs_error file on linux/windows x86_64 >>> >>> Hi Matthias, >>> >>> If the guest env. we are running in have correct values, what can the host >>> values be used for in a hs_err context? >>> >>> Thanks, Robbin >>> >>> On 2019-04-29 13:02, Baesken, Matthias wrote: >>>> Hello, >>>> please review the following enhancement to the VMWare/vSphere >>> virtualization related info in the hs_error file on linux/windows x86_64 . >>>> >>>> In case the guest library from VMWare SDK 6.0 (or higher) is present >>> (libvmGuestLib) or the open-vm-tools guest library is present >>>> (libguestlib), we add the host and initial and current resource related >>> metrics information to the hs_err file . >>>> The resource info (current and first) is taken twice to see diffs over the >> VM >>> runtime. >>>> >>>> Example output for host and resource information : >>>> host: >>>> ------ >>>> host.cpu.processorMHz = 2194 >>>> host.cpu.coresPerPkg = 10 >>>> host.cpu.packages = 4 >>>> host.cpu.cores = 40 >>>> host.cpu.threads = 80 >>>> host.dmi.product = UCSC-C460-M4 >>>> host.dmi.vendor = Cisco Systems Inc >>>> >>>> resource: >>>> ---------- >>>> vm.cpu.reserved = 0 >>>> vm.cpu.limit = -1 >>>> vm.cpu.used = 2290006442390 >>>> vm.cpu.contention.cpu = 1436489771 >>>> vm.cpu.contention.mem = 0 >>>> vm.numa.local = 16775168 >>>> vm.numa.remote = 0 >>>> guest.mem.reserved = 0 >>>> guest.mem.limit = 3221225456 >>>> guest.mem.mapped = 16775168 >>>> guest.mem.consumed = 16699172 >>>> guest.mem.swapped = 0 >>>> guest.mem.ballooned = 0 >>>> guest.mem.swapIn = 0 >>>> guest.mem.swapOut = 0 >>>> ovhd.mem.swapped = 0 >>>> ovhd.mem.swapIn = 0 >>>> ovhd.mem.swapOut = 0 >>>> >>>> >>>> (details on the metrics meaning can be found in the VMWare SDK >>> programming guide >>>> >>>> https://code.vmware.com/docs/6629/guest-and-ha-application- >>> monitoring-sdk-programming-guide/ >>>> >>>> see the subsections of "Tools for Extended Guest Statistics" ) >>>> >>>> >>>> bug/webrev : >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8222720 >>>> >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8222720.1/ >>>> >>>> >>>> Thanks, Matthias >>>> From coleen.phillimore at oracle.com Wed May 8 13:56:02 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 8 May 2019 09:56:02 -0400 Subject: RFR (S) 8223472: volatile long field corruption on x86_32 In-Reply-To: References: Message-ID: <12028291-5388-d87d-65cd-25e2e3f1b0bd@oracle.com> I just had a look at this and it looks unsettlingly random without a short comment why MO_RELAXED is needed for long and not the others. Is it because on 32 bits, double is two words that have to be atomically stored?? Would a volatile double have the same problem? I see getfield_or_static has the MO_RELAXED and a comment, so that's good.? I don't need to see a new version if you add a *short* comment like this. Thanks, Coleen On 5/8/19 4:17 AM, Boris Ulasevich wrote: > Hi all, > > Please review a simple change to fix long field store atomicity for > 32-bit x86 interpreter. > > http://bugs.openjdk.java.net/browse/JDK-8223472 > http://cr.openjdk.java.net/~bulasevich/8223472/webrev.00 > > thanks, > Boris From richard.reingruber at sap.com Wed May 8 14:19:32 2019 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Wed, 8 May 2019 14:19:32 +0000 Subject: Should ~ThreadInVMForHandshake() call handle_special_runtime_exit_condition() ? In-Reply-To: References: <40dc6132-f590-229d-8ddb-e4eb05ec3689@oracle.com> Message-ID: Hi Robbin, > >> + if ((_original_state == _thread_in_Java || _original_state == _thread_in_native) && > >> + _thread->has_special_runtime_exit_condition()) { > >> + _thread->handle_special_runtime_exit_condition(!_thread->is_at_poll_safepoint()); > >> + } > > You need to verify that async exception check is correct. > If we are returning to native it should not be delivered AFAIK. You're right. I guess ThreadInVMForHandshake::transition_back() should do the same as SafepointSynchronize::block(). I'll come back with an webrev tomorrow after nightly testing. Thanks, Richard. -----Original Message----- From: Robbin Ehn Sent: Dienstag, 7. Mai 2019 17:16 To: Reingruber, Richard ; hotspot-runtime-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: Should ~ThreadInVMForHandshake() call handle_special_runtime_exit_condition() ? Hi Richard, >> + if ((_original_state == _thread_in_Java || _original_state == _thread_in_native) && >> + _thread->has_special_runtime_exit_condition()) { >> + _thread->handle_special_runtime_exit_condition(!_thread->is_at_poll_safepoint()); >> + } You need to verify that async exception check is correct. If we are returning to native it should not be delivered AFAIK. Thanks, Robbin >> } >> >> public: >> >> Without that patch an issue could be that thread T continues executing bytecodes after it was >> suspended by a JVMTI agent like this: >> >> - Handshake operation H is executed for T >> - T calls ThreadSafepointState::handle_polling_page_exception() >> - T arrives in HandshakeState::process_self_inner() >> - T transitions from _thread_in_Java to _thread_in_vm >> - but too late: the VM thread already claimed H >> - T calls _semaphore.wait_with_safepoint_check() >> - T transitions from _thread_in_vm to _thread_blocked >> - The VM thread completes H and calls _semaphore.signal() >> - Before T can transition back to _thread_in_vm, the VM thread schedules another safepoint and >> executes VM_ThreadSuspend on behalf of a JVMTI agent that wants to suspend T >> - After the safepoint T transitions back to _thread_in_vm and then to _thread_in_Java. >> - T continues executing an undefined number of bytecodes ... >> >> Cheers, Richard. >> From matthias.baesken at sap.com Wed May 8 14:24:20 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 8 May 2019 14:24:20 +0000 Subject: RFR [XS] : 8223574: add more thread-related system settings info to hs_error file on AIX Message-ID: Hello , please review this small AIX related change . It adds to the hs_error file on AIX the maximum number of threads within a process. ( The previous change https://bugs.openjdk.java.net/browse/JDK-8204598 added already more thread-related system settings info to the hs_error file on Linux. On AIX I want to enhance the output too . ) Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8223574 http://cr.openjdk.java.net/~mbaesken/webrevs/8223574.0/ Thanks, Matthias From matthias.baesken at sap.com Wed May 8 14:46:56 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 8 May 2019 14:46:56 +0000 Subject: 8222720: Provide extended VMWare/vSphere virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: References: <44b9455e-9642-729d-6ef4-64603bdf278e@oracle.com> Message-ID: Hi Robbin, I'll try to use os::dll_load . At a lot of places in HS dlopen is used , seems os::dll_load is not so popular . Usually the function is called with a char ebuf[1024]; as the second argument . Would this really work for all file systems (with very long paths) I wonder ? Best regards, Matthias > > Is there a problem with using os::dll_load ? > > Since we have these things for other proprietary hosts I guess this is fine > also. Code seems okay, except above. > > Thanks, Robbin > > On 2019-05-08 14:57, Baesken, Matthias wrote: > > Ping - any reviews / opinions ? > > > > Best regards, Matthias > > > > > > > >> -----Original Message----- > >> From: Baesken, Matthias > >> Sent: Dienstag, 30. April 2019 09:23 > >> To: Robbin Ehn ; 'hotspot- > dev at openjdk.java.net' > >> > >> Subject: RE: 8222720: Provide extended VMWare/vSphere virtualization > >> related info in the hs_error file on linux/windows x86_64 > >> > >> Hello Robbin, some of the info is indeed already available on the guest > (e.g. > >> processorMHz ). > >> Some of the info is about the host so we do not have it currently . > >> > >> > >> This is what the vsphere-guest-ha-monitoring-sdk-65-programming- > >> guide.pdf has to say about the metrics info : > >> > >> Host - metrics : "information about the current hypervisor and hardware > the > >> virtual machine is running on" > >> Description about the different info parts : > >> > >> host.cpu.processorMHz ? nominal processor speed. Other metrics, such > as > >> vm.cpu.used below, are normalized to this speed. > >> host.cpu.coresPerPkg ? actual cores per socket, not including > hyperthreads. > >> Useful for determining cache effects and other aspects of socket sharing. > >> Information is also available with CPUID instruction. > >> Note that vSphere does not implement virtual hyperthreads. > >> host.cpu.packages ? number of CPU sockets on the host (non-default). > >> host.cpu.cores ? number of cores on the host across all sockets, not > including > >> hyperthreads (non-default). > >> host.cpu.threads ? number of logical CPUs on the host across all sockets, > >> including hyperthreads (non-default). > >> host.dmi.product ? ?product? field in the host SMBIOS data (non-default). > >> host.dmi.vendor ? ?vendor? field in the host SMBIOS data (non-default). > >> > >> ( so the host.dmi product/vendor info might not be available depending > on > >> the VMWare configuration ) > >> > >> > >> Best regards, Matthias > >> > >> > >>> -----Original Message----- > >>> From: Robbin Ehn > >>> Sent: Dienstag, 30. April 2019 09:04 > >>> To: Baesken, Matthias ; 'hotspot- > >>> dev at openjdk.java.net' > >>> Subject: Re: 8222720: Provide extended VMWare/vSphere virtualization > >>> related info in the hs_error file on linux/windows x86_64 > >>> > >>> Hi Matthias, > >>> > >>> If the guest env. we are running in have correct values, what can the > host > >>> values be used for in a hs_err context? > >>> > >>> Thanks, Robbin > >>> > >>> On 2019-04-29 13:02, Baesken, Matthias wrote: > >>>> Hello, > >>>> please review the following enhancement to the VMWare/vSphere > >>> virtualization related info in the hs_error file on linux/windows x86_64 . > >>>> > >>>> In case the guest library from VMWare SDK 6.0 (or higher) is present > >>> (libvmGuestLib) or the open-vm-tools guest library is present > >>>> (libguestlib), we add the host and initial and current resource related > >>> metrics information to the hs_err file . > >>>> The resource info (current and first) is taken twice to see diffs over the > >> VM > >>> runtime. > >>>> > >>>> Example output for host and resource information : > >>>> host: > >>>> ------ > >>>> host.cpu.processorMHz = 2194 > >>>> host.cpu.coresPerPkg = 10 > >>>> host.cpu.packages = 4 > >>>> host.cpu.cores = 40 > >>>> host.cpu.threads = 80 > >>>> host.dmi.product = UCSC-C460-M4 > >>>> host.dmi.vendor = Cisco Systems Inc > >>>> > >>>> resource: > >>>> ---------- > >>>> vm.cpu.reserved = 0 > >>>> vm.cpu.limit = -1 > >>>> vm.cpu.used = 2290006442390 > >>>> vm.cpu.contention.cpu = 1436489771 > >>>> vm.cpu.contention.mem = 0 > >>>> vm.numa.local = 16775168 > >>>> vm.numa.remote = 0 > >>>> guest.mem.reserved = 0 > >>>> guest.mem.limit = 3221225456 > >>>> guest.mem.mapped = 16775168 > >>>> guest.mem.consumed = 16699172 > >>>> guest.mem.swapped = 0 > >>>> guest.mem.ballooned = 0 > >>>> guest.mem.swapIn = 0 > >>>> guest.mem.swapOut = 0 > >>>> ovhd.mem.swapped = 0 > >>>> ovhd.mem.swapIn = 0 > >>>> ovhd.mem.swapOut = 0 > >>>> > >>>> > >>>> (details on the metrics meaning can be found in the VMWare SDK > >>> programming guide > >>>> > >>>> https://code.vmware.com/docs/6629/guest-and-ha-application- > >>> monitoring-sdk-programming-guide/ > >>>> > >>>> see the subsections of "Tools for Extended Guest Statistics" ) > >>>> > >>>> > >>>> bug/webrev : > >>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8222720 > >>>> > >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8222720.1/ > >>>> > >>>> > >>>> Thanks, Matthias > >>>> From erik.gahlin at oracle.com Wed May 8 16:54:34 2019 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Wed, 8 May 2019 18:54:34 +0200 Subject: RFR: 8223438: add VirtualizationInformation JFR event In-Reply-To: References: Message-ID: <5CD309CA.40808@oracle.com> Hello, Looks good, but do we really need to allocate the name every time an event is emitted in jfrPeriodic.cpp? It will not matter much from a performance perspective, but the code would look cleaner if we would have. EventVirtualizationInformation event; event.set_name(JfrOSInterface::virtualization_name()); event.commit(); Thanks Erik > Hello, please review the following change . > > It adds a simple VirtualizationInformation event to JFR . > > The addition to JFR has been previously proposed by Erik when we > discussed the enhancement of hs_error file output with virtualization > related information . > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8223438 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8223438.1/ > > > Thanks, Matthias > From david.holmes at oracle.com Wed May 8 22:27:03 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 9 May 2019 08:27:03 +1000 Subject: RFR (S) 8223472: volatile long field corruption on x86_32 In-Reply-To: <2c7db7f2-8e50-ab20-6b4a-d5d364b22773@oracle.com> References: <70af2f86-898d-0821-49fe-15071481f2f7@oracle.com> <18ea25be-f480-9c45-352c-e49d39316b3b@oracle.com> <2c7db7f2-8e50-ab20-6b4a-d5d364b22773@oracle.com> Message-ID: Thanks Erik and Boris for your replies and fixing my ignorance. I surely knew this at some time: http://gee.cs.oswego.edu/dl/html/j9mm.html David On 8/05/2019 10:12 pm, Erik ?sterlund wrote: > Hi David, > > The name "relaxed" comes from std::memory_order_release, which implies > atomicity. > > From accessDecorators.hpp: > "MO_RELAXED is equivalent to JMM opaque." > > From JMM opaque definition on Doug Lea's website: > "If Opaque (or any stronger) mode is used for all accesses, then reads > of all types, including long and double, are guaranteed not to mix the > bits of multiple writes." (i.e. atomicity) > > In the implementation of the access for x86 (_32) > BarrierSetAssembler::store_at, the backend looks at MO_RELAXED and uses > that to determine if the access should be atomic. > So it is quite intentional that a relaxed access is indeed atomic. > > /Erik > > On 2019-05-08 14:01, David Holmes wrote: >> I would very much like an explanation of how this lack of MO_RELAXED >> causes a lack of _atomicity_! What has "MO" got to do with that? And >> why would a volatile access be "relaxed" or "unordered"? >> >> This is not making any sense to me at all. >> >> Thanks, >> David >> >> On 8/05/2019 7:07 pm, Erik ?sterlund wrote: >>> Hi Boris, >>> >>> Thank you for fixing this. Looks good to me. >>> >>> /Erik >>> >>> On 2019-05-08 10:17, Boris Ulasevich wrote: >>>> Hi all, >>>> >>>> Please review a simple change to fix long field store atomicity for >>>> 32-bit x86 interpreter. >>>> >>>> http://bugs.openjdk.java.net/browse/JDK-8223472 >>>> http://cr.openjdk.java.net/~bulasevich/8223472/webrev.00 >>>> >>>> thanks, >>>> Boris >>> > From david.holmes at oracle.com Thu May 9 05:25:25 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 9 May 2019 15:25:25 +1000 Subject: 8222720: Provide extended VMWare/vSphere virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: References: Message-ID: Hi Matthias, On 29/04/2019 9:02 pm, Baesken, Matthias wrote: > Hello, > please review the following enhancement to the VMWare/vSphere virtualization related info in the hs_error file on linux/windows x86_64 . > > In case the guest library from VMWare SDK 6.0 (or higher) is present (libvmGuestLib) or the open-vm-tools guest library is present > (libguestlib), we add the host and initial and current resource related metrics information to the hs_err file . > The resource info (current and first) is taken twice to see diffs over the VM runtime. > > Example output for host and resource information : > host: > ------ > host.cpu.processorMHz = 2194 > host.cpu.coresPerPkg = 10 > host.cpu.packages = 4 > host.cpu.cores = 40 > host.cpu.threads = 80 > host.dmi.product = UCSC-C460-M4 > host.dmi.vendor = Cisco Systems Inc > > resource: > ---------- > vm.cpu.reserved = 0 > vm.cpu.limit = -1 > vm.cpu.used = 2290006442390 > vm.cpu.contention.cpu = 1436489771 > vm.cpu.contention.mem = 0 > vm.numa.local = 16775168 > vm.numa.remote = 0 > guest.mem.reserved = 0 > guest.mem.limit = 3221225456 > guest.mem.mapped = 16775168 > guest.mem.consumed = 16699172 > guest.mem.swapped = 0 > guest.mem.ballooned = 0 > guest.mem.swapIn = 0 > guest.mem.swapOut = 0 > ovhd.mem.swapped = 0 > ovhd.mem.swapIn = 0 > ovhd.mem.swapOut = 0 > > > (details on the metrics meaning can be found in the VMWare SDK programming guide > > https://code.vmware.com/docs/6629/guest-and-ha-application-monitoring-sdk-programming-guide/ > > see the subsections of "Tools for Extended Guest Statistics" ) > > > bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8222720 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8222720.1/ You've defined "shared" files but this is only usable on Windows and Linux (and then x86 only). I think this would be a lot cleaner if vmwareSupport.cpp** was written using os::dl_lookup as Robbin suggested so that there is no platform specific code at all in there and so truly shared. You also don't need the ifdefs in vm_version_x86.cpp - after-all if you've already detected running under VMWare then the calls to initialize() and print_virtualization_info() should be unconditional (and just no-ops if the underlying support was not there). BTW initialize() doesn't need to return a boolean as it's not being checked. The copyright headers in the new files should only have the year 2019 - also I would have expected you to use a SAP copyright. **Not sure about the validity of using "vmware" in the name of files or classes either due to its trademark status. Thanks, David ----- > > Thanks, Matthias > From Pengfei.Li at arm.com Thu May 9 05:34:03 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Thu, 9 May 2019 05:34:03 +0000 Subject: RFR(T): 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled In-Reply-To: References: Message-ID: Thanks Aleksey. Is it required to have another reviewer for this change? -- Thanks, Pengfei > > Could anyone help review this patch (tiny change on 75 test files)? > > > > Webrev: http://cr.openjdk.java.net/~pli/rfr/8223427/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8223427 > > Looks good. > > We already have a few tests that do "@requires vm.gc.Shenandoah > & !vm.graal.enabled". > > -Aleksey From matthias.baesken at sap.com Thu May 9 07:02:56 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 9 May 2019 07:02:56 +0000 Subject: RFR: 8223438: add VirtualizationInformation JFR event In-Reply-To: <5CD309CA.40808@oracle.com> References: <5CD309CA.40808@oracle.com> Message-ID: Hi Erik, the virtualization names are a set of fix names , so I think we can do what you suggest . I just "borrowed" a bit from the code above ... TRACE_REQUEST_FUNC(OSInformation) { ResourceMark rm; char* os_name = NEW_RESOURCE_ARRAY(char, 2048); JfrOSInterface::os_version(&os_name); EventOSInformation event; event.set_osVersion(os_name); event.commit(); } ... where a ResourceMark + allocation is used (but in jfrOSInterface I wonder about the second allocation in string.stream.as_string , do we really need two here ? int JfrOSInterface::JfrOSInterfaceImpl::os_version(char** os_version) const { assert(os_version != NULL, "os_version pointer is NULL!"); stringStream os_ver_info; os::print_os_info_brief(&os_ver_info); *os_version = os_ver_info.as_string(); <--- second alloc Best regards, Matthias From: Erik Gahlin Sent: Mittwoch, 8. Mai 2019 18:55 To: Baesken, Matthias ; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR: 8223438: add VirtualizationInformation JFR event Hello, Looks good, but do we really need to allocate the name every time an event is emitted in jfrPeriodic.cpp? It will not matter much from a performance perspective, but the code would look cleaner if we would have. EventVirtualizationInformation event; event.set_name(JfrOSInterface::virtualization_name()); event.commit(); Thanks Erik Hello, please review the following change . It adds a simple VirtualizationInformation event to JFR . The addition to JFR has been previously proposed by Erik when we discussed the enhancement of hs_error file output with virtualization related information . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8223438 http://cr.openjdk.java.net/~mbaesken/webrevs/8223438.1/ Thanks, Matthias From shade at redhat.com Thu May 9 07:29:57 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 9 May 2019 09:29:57 +0200 Subject: RFR(T): 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled In-Reply-To: References: Message-ID: <29c11b50-5d85-a68b-573d-2e5116c4a2da@redhat.com> Seeing that it is trivial and only affects Shenandoah tests, I'd say one review is enough. Do you need a sponsor to push? -Aleksey On 5/9/19 7:34 AM, Pengfei Li (Arm Technology China) wrote: > Thanks Aleksey. Is it required to have another reviewer for this change? > > -- > Thanks, > Pengfei > >>> Could anyone help review this patch (tiny change on 75 test files)? >>> >>> Webrev: http://cr.openjdk.java.net/~pli/rfr/8223427/webrev.00/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8223427 From Pengfei.Li at arm.com Thu May 9 07:33:24 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Thu, 9 May 2019 07:33:24 +0000 Subject: RFR(T): 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled In-Reply-To: <29c11b50-5d85-a68b-573d-2e5116c4a2da@redhat.com> References: <29c11b50-5d85-a68b-573d-2e5116c4a2da@redhat.com> Message-ID: Hi Aleksey, > Seeing that it is trivial and only affects Shenandoah tests, I'd say one review is > enough. > > Do you need a sponsor to push? Yes, I would be happy if you could help to push. -- Thanks, Pengfei From matthias.baesken at sap.com Thu May 9 08:04:28 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 9 May 2019 08:04:28 +0000 Subject: RFR: 8223438: add VirtualizationInformation JFR event In-Reply-To: References: <5CD309CA.40808@oracle.com> Message-ID: Hello, here is the next webrev with adjusted coding following your suggestion : http://cr.openjdk.java.net/~mbaesken/webrevs/8223438.2/ Best regards, Matthias From: Baesken, Matthias Sent: Donnerstag, 9. Mai 2019 09:03 To: Erik Gahlin ; 'hotspot-dev at openjdk.java.net' Subject: RE: RFR: 8223438: add VirtualizationInformation JFR event Hi Erik, the virtualization names are a set of fix names , so I think we can do what you suggest . I just "borrowed" a bit from the code above ... TRACE_REQUEST_FUNC(OSInformation) { ResourceMark rm; char* os_name = NEW_RESOURCE_ARRAY(char, 2048); JfrOSInterface::os_version(&os_name); EventOSInformation event; event.set_osVersion(os_name); event.commit(); } ... where a ResourceMark + allocation is used (but in jfrOSInterface I wonder about the second allocation in string.stream.as_string , do we really need two here ? int JfrOSInterface::JfrOSInterfaceImpl::os_version(char** os_version) const { assert(os_version != NULL, "os_version pointer is NULL!"); stringStream os_ver_info; os::print_os_info_brief(&os_ver_info); *os_version = os_ver_info.as_string(); <--- second alloc Best regards, Matthias From: Erik Gahlin > Sent: Mittwoch, 8. Mai 2019 18:55 To: Baesken, Matthias >; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR: 8223438: add VirtualizationInformation JFR event Hello, Looks good, but do we really need to allocate the name every time an event is emitted in jfrPeriodic.cpp? It will not matter much from a performance perspective, but the code would look cleaner if we would have. EventVirtualizationInformation event; event.set_name(JfrOSInterface::virtualization_name()); event.commit(); Thanks Erik Hello, please review the following change . It adds a simple VirtualizationInformation event to JFR . The addition to JFR has been previously proposed by Erik when we discussed the enhancement of hs_error file output with virtualization related information . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8223438 http://cr.openjdk.java.net/~mbaesken/webrevs/8223438.1/ Thanks, Matthias From shade at redhat.com Thu May 9 08:09:08 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 9 May 2019 10:09:08 +0200 Subject: RFR(T): 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled In-Reply-To: References: <29c11b50-5d85-a68b-573d-2e5116c4a2da@redhat.com> Message-ID: On 5/9/19 9:33 AM, Pengfei Li (Arm Technology China) wrote: > Hi Aleksey, > >> Seeing that it is trivial and only affects Shenandoah tests, I'd say one review is >> enough. >> >> Do you need a sponsor to push? > > Yes, I would be happy if you could help to push. There: http://hg.openjdk.java.net/jdk/jdk/rev/206afa6372ae -Aleksey From matthias.baesken at sap.com Thu May 9 08:13:10 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 9 May 2019 08:13:10 +0000 Subject: 8222720: Provide extended VMWare/vSphere virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: References: Message-ID: Hi David, thanks for the feedback . I'll provide an updated webrev . > **Not sure about the validity of using "vmware" in the name of files or > classes either due to its trademark status. Well , we have a lot of technology names in file-names (AIX and Windows come to mind) . But to be on the safe side, I think I'll choose a more generic name . Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Donnerstag, 9. Mai 2019 07:25 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Subject: Re: 8222720: Provide extended VMWare/vSphere virtualization > related info in the hs_error file on linux/windows x86_64 > > Hi Matthias, > > On 29/04/2019 9:02 pm, Baesken, Matthias wrote: > > Hello, > > please review the following enhancement to the VMWare/vSphere > virtualization related info in the hs_error file on linux/windows x86_64 . > > > > In case the guest library from VMWare SDK 6.0 (or higher) is present > (libvmGuestLib) or the open-vm-tools guest library is present > > (libguestlib), we add the host and initial and current resource related > metrics information to the hs_err file . > > The resource info (current and first) is taken twice to see diffs over the VM > runtime. > > > > Example output for host and resource information : > > host: > > ------ > > host.cpu.processorMHz = 2194 > > host.cpu.coresPerPkg = 10 > > host.cpu.packages = 4 > > host.cpu.cores = 40 > > host.cpu.threads = 80 > > host.dmi.product = UCSC-C460-M4 > > host.dmi.vendor = Cisco Systems Inc > > > > resource: > > ---------- > > vm.cpu.reserved = 0 > > vm.cpu.limit = -1 > > vm.cpu.used = 2290006442390 > > vm.cpu.contention.cpu = 1436489771 > > vm.cpu.contention.mem = 0 > > vm.numa.local = 16775168 > > vm.numa.remote = 0 > > guest.mem.reserved = 0 > > guest.mem.limit = 3221225456 > > guest.mem.mapped = 16775168 > > guest.mem.consumed = 16699172 > > guest.mem.swapped = 0 > > guest.mem.ballooned = 0 > > guest.mem.swapIn = 0 > > guest.mem.swapOut = 0 > > ovhd.mem.swapped = 0 > > ovhd.mem.swapIn = 0 > > ovhd.mem.swapOut = 0 > > > > > > (details on the metrics meaning can be found in the VMWare SDK > programming guide > > > > https://code.vmware.com/docs/6629/guest-and-ha-application- > monitoring-sdk-programming-guide/ > > > > see the subsections of "Tools for Extended Guest Statistics" ) > > > > > > bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8222720 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8222720.1/ > > You've defined "shared" files but this is only usable on Windows and > Linux (and then x86 only). I think this would be a lot cleaner if > vmwareSupport.cpp** was written using os::dl_lookup as Robbin suggested > so that there is no platform specific code at all in there and so truly > shared. You also don't need the ifdefs in vm_version_x86.cpp - after-all > if you've already detected running under VMWare then the calls to > initialize() and print_virtualization_info() should be unconditional > (and just no-ops if the underlying support was not there). > > BTW initialize() doesn't need to return a boolean as it's not being checked. > > The copyright headers in the new files should only have the year 2019 - > also I would have expected you to use a SAP copyright. > > **Not sure about the validity of using "vmware" in the name of files or > classes either due to its trademark status. > > Thanks, > David > ----- > > > > > > > Thanks, Matthias > > From leo.korinth at oracle.com Thu May 9 08:58:30 2019 From: leo.korinth at oracle.com (Leo Korinth) Date: Thu, 9 May 2019 10:58:30 +0200 Subject: RFR: 8223136: Move compressed oops functions to CompressedOops class In-Reply-To: <7ac5ee51-9e71-45c6-3a72-4cb54ba9c688@oracle.com> References: <61cb41e8-fcd5-845f-e57f-7a2d46c0c995@oracle.com> <612339e6-e693-c1c9-51f6-9316aa90874b@oracle.com> <6f674d7f-b0ac-38d4-3b70-8a9e683e8022@oracle.com> <325c4923-1f39-fcfb-685c-8cf77b165540@oracle.com> <7ac5ee51-9e71-45c6-3a72-4cb54ba9c688@oracle.com> Message-ID: <96493d43-344f-7eeb-9101-7b2713f9c8c0@oracle.com> Hi Stefan. Really nice cleanup. Smaller Universe and the code reads much better. [src/hotspot/share/code/oopRecorder.inline.hpp] lacks include guards. [src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp] [src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp] fix #include order. src/hotspot/share/compiler/oopMap.cpp - // equal to Universe::narrow_oop_base when a narrow oop + // equal to CompressedOops::base(() when a narrow oop (extra start parenthesis in comment) Change looks great and no new webrev is needed for me. Thanks, Leo On 07/05/2019 21:28, Stefan Karlsson wrote: > These are the latest patches (on jdk/jdk @ 61049e91eae5): > ?http://cr.openjdk.java.net/~stefank/8223136/webrev.04/01.compressed/ > ?http://cr.openjdk.java.net/~stefank/8223136/webrev.04/02.verifyOption/ > ?http://cr.openjdk.java.net/~stefank/8223136/webrev.04/03.isGCActiveMark/ > ?http://cr.openjdk.java.net/~stefank/8223136/webrev.04/04.oopRecorder/ > ?http://cr.openjdk.java.net/~stefank/8223136/webrev.04/05.memAllocator/ > ?http://cr.openjdk.java.net/~stefank/8223136/webrev.04/06.oopFactory/ > ?http://cr.openjdk.java.net/~stefank/8223136/webrev.04/07.fixIncludes/ > ?http://cr.openjdk.java.net/~stefank/8223136/webrev.04/all/ > > I folded the oopsHierarchy change below into the fixIncludes patch. I > also found that I hadn't updated all ppc files, so that's fixed as well. > > This compiles locally on Linux x64. I'll also test that it still works > on the platforms we build on. > > Thanks, > StefanK From stefan.karlsson at oracle.com Thu May 9 10:03:15 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 9 May 2019 12:03:15 +0200 Subject: RFR: 8223136: Move compressed oops functions to CompressedOops class In-Reply-To: <96493d43-344f-7eeb-9101-7b2713f9c8c0@oracle.com> References: <61cb41e8-fcd5-845f-e57f-7a2d46c0c995@oracle.com> <612339e6-e693-c1c9-51f6-9316aa90874b@oracle.com> <6f674d7f-b0ac-38d4-3b70-8a9e683e8022@oracle.com> <325c4923-1f39-fcfb-685c-8cf77b165540@oracle.com> <7ac5ee51-9e71-45c6-3a72-4cb54ba9c688@oracle.com> <96493d43-344f-7eeb-9101-7b2713f9c8c0@oracle.com> Message-ID: <910848d4-5c43-bf99-518e-e743d1c09b4d@oracle.com> Thanks, Leo! I'll fix this changes, run through testing, and then push this. Thanks, StefanK On 2019-05-09 10:58, Leo Korinth wrote: > Hi Stefan. > > Really nice cleanup. Smaller Universe and the code reads much better. > > [src/hotspot/share/code/oopRecorder.inline.hpp] > lacks include guards. > > [src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp] > [src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp] > fix #include order. > > > src/hotspot/share/compiler/oopMap.cpp > -??????? // equal to Universe::narrow_oop_base when a narrow oop > +??????? // equal to CompressedOops::base(() when a narrow oop > (extra start parenthesis in comment) > > Change looks great and no new webrev is needed for me. > > Thanks, > Leo > > > On 07/05/2019 21:28, Stefan Karlsson wrote: >> These are the latest patches (on jdk/jdk @ 61049e91eae5): >> ??http://cr.openjdk.java.net/~stefank/8223136/webrev.04/01.compressed/ >> ??http://cr.openjdk.java.net/~stefank/8223136/webrev.04/02.verifyOption/ >> ??http://cr.openjdk.java.net/~stefank/8223136/webrev.04/03.isGCActiveMark/ >> >> ??http://cr.openjdk.java.net/~stefank/8223136/webrev.04/04.oopRecorder/ >> ??http://cr.openjdk.java.net/~stefank/8223136/webrev.04/05.memAllocator/ >> ??http://cr.openjdk.java.net/~stefank/8223136/webrev.04/06.oopFactory/ >> ??http://cr.openjdk.java.net/~stefank/8223136/webrev.04/07.fixIncludes/ >> ??http://cr.openjdk.java.net/~stefank/8223136/webrev.04/all/ >> >> I folded the oopsHierarchy change below into the fixIncludes patch. I >> also found that I hadn't updated all ppc files, so that's fixed as well. >> >> This compiles locally on Linux x64. I'll also test that it still works >> on the platforms we build on. >> >> Thanks, >> StefanK > From sgehwolf at redhat.com Thu May 9 12:39:18 2019 From: sgehwolf at redhat.com (sgehwolf at redhat.com) Date: Thu, 09 May 2019 14:39:18 +0200 Subject: [PING] [8u] RFR: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization In-Reply-To: References: Message-ID: <34336f93b6c53942ccf522de449c550bae30d546.camel@redhat.com> Ping? On Fri, 2019-05-03 at 18:35 +0200, Severin Gehwolf wrote: > Hi, > > Could I please get reviews for this 8u backport of an optimization fix > pertaining to the hotspot copy of fdlibm? Historically, > sharedRuntimeTrans.cpp and sharedRuntimeTrig.cpp have been compiled > with optimization turned off on x86/x86_64. As JDK-8210416 will be > backported to JDK 8u fixing optimization for fdlibm itself, so should > be the hotspot copy in OpenJDK 8u. The build system for hotspot in JDK > 8u is very different, so the original fix for JDK 12 doesn't apply. > It's a complete rewrite. Please see this webrev which shows the > prerequisite patch. It adds the FDLIBM_CFLAGS logic: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/jdk8/02/ > > It also fixes a bug on ppc64{,le} where optimization is being turned on > in hotspot (-O3), but not providing the -ffp-contract=off flag (or > older equivalent). > > Before (on ppc64le): > /bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. -I/home/openjdk/jdk8u/hotspot/src/share/vm/prims -I/home/openjdk/jdk8u/hotspot/src/share/vm -I/home/openjdk/jdk8u/hotspot/src/share/vm/precompiled -I/home/openjdk/jdk8u/hotspot/src/cpu/ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os_cpu/linux_ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os/linux/vm -I/home/openjdk/jdk8u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.212-b04\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"openjdk\"" -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3 -g -D_LP64=1 -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8 -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -std=gnu++98 -c -MMD -MP -MF ../generated/dependencies/sharedRuntimeTrig.o.d -fpch-deps -o sharedRuntimeTrig.o /home/openjdk/jdk8u/hotspot/src/share/vm/runtime/sharedRuntimeTrig.cpp > After (on ppc64le; Note -ffp-contract=off flag): > /bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. -I/home/openjdk/jdk8u/hotspot/src/share/vm/prims -I/home/openjdk/jdk8u/hotspot/src/share/vm -I/home/openjdk/jdk8u/hotspot/src/share/vm/precompiled -I/home/openjdk/jdk8u/hotspot/src/cpu/ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os_cpu/linux_ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os/linux/vm -I/home/openjdk/jdk8u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.212-b04\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"openjdk\"" -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3 -ffp-contract=off -D_LP64=1 -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8 -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -std=gnu++98 -c -MMD -MP -MF ../generated/dependencies/sharedRuntimeTrig.o.d -fpch-deps -o sharedRuntimeTrig.o /home/openjdk/jdk8u/hotspot/src/share/vm/runtime/sharedRuntimeTrig.cpp > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210425 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/jdk8/02/webrev > > Testing: Builds on x86_64 (server/Zero). Manual inspection of compile > log of sharedRuntimeTrans.cpp/sharedRuntimeTrig.cpp. Same for ppc64le. > Note that we've been using this patch downstream for a while now. We > haven't seen any issues so far. > > Thanks, > Severin From david.griffiths at gmail.com Thu May 9 14:17:07 2019 From: david.griffiths at gmail.com (David Griffiths) Date: Thu, 9 May 2019 15:17:07 +0100 Subject: [13] RFR (M): 8223213: Implement fast class initialization checks on x86-64 Message-ID: Interestingly I have just come across this thread after hitting the same problem myself. In my case I had code in a static initializer specifically designed to make sure a method is JIT compiled (long story). I reduced it down to this test: public class Regression { static { System.out.println("start of loop"); for (int i = 0; i < 10000000; i++) { check(); } System.out.println("end of loop"); } public static void check() { } public static void main(String[] args) { System.out.println("in main"); } } which takes about 5 secs now compared to 0.07 secs user before. Cheers, David From aph at redhat.com Thu May 9 14:59:53 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 9 May 2019 15:59:53 +0100 Subject: AArch64 build is broken Message-ID: <1d622d0e-b2e9-7086-0087-24bd9f2c83f9@redhat.com> I'm testing this patch: diff -r 77e95181b5d6 src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Thu May 09 07:33:28 2019 -0700 +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Thu May 09 10:58:02 2019 -0400 @@ -27,6 +27,7 @@ #define CPU_AARCH64_MACROASSEMBLER_AARCH64_HPP #include "asm/assembler.hpp" +#include "oops/compressedOops.hpp" // MacroAssembler extends Assembler by frequently used macros. // @@ -85,10 +86,10 @@ public: MacroAssembler(CodeBuffer* code) : Assembler(code) { use_XOR_for_compressed_class_base - = (operand_valid_for_logical_immediate(false /*is32*/, - (uint64_t)Universe::narrow_klass_base()) - && ((uint64_t)Universe::narrow_klass_base() - > (1UL << log2_intptr(Universe::narrow_klass_range())))); + = operand_valid_for_logical_immediate + (/*is32*/false, (uint64_t)CompressedKlassPointers::base()) + && ((uint64_t)CompressedKlassPointers::base() + > (1UL << log2_intptr(CompressedKlassPointers::range()))); } // These routines should emit JVMTI PopFrame and ForceEarlyReturn handling code. -- 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 stuart.monteith at linaro.org Thu May 9 16:06:56 2019 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Thu, 9 May 2019 17:06:56 +0100 Subject: AArch64 build is broken In-Reply-To: <1d622d0e-b2e9-7086-0087-24bd9f2c83f9@redhat.com> References: <1d622d0e-b2e9-7086-0087-24bd9f2c83f9@redhat.com> Message-ID: I see this was triggered by 8223136 - I didn't catch the CI build at 2pm 14:05 BST today. You patch builds and runs for me, and looks consistent with 8223136. On Thu, 9 May 2019 at 16:10, Andrew Haley wrote: > > I'm testing this patch: > > diff -r 77e95181b5d6 src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp > --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Thu May 09 07:33:28 2019 -0700 > +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Thu May 09 10:58:02 2019 -0400 > @@ -27,6 +27,7 @@ > #define CPU_AARCH64_MACROASSEMBLER_AARCH64_HPP > > #include "asm/assembler.hpp" > +#include "oops/compressedOops.hpp" > > // MacroAssembler extends Assembler by frequently used macros. > // > @@ -85,10 +86,10 @@ > public: > MacroAssembler(CodeBuffer* code) : Assembler(code) { > use_XOR_for_compressed_class_base > - = (operand_valid_for_logical_immediate(false /*is32*/, > - (uint64_t)Universe::narrow_klass_base()) > - && ((uint64_t)Universe::narrow_klass_base() > - > (1UL << log2_intptr(Universe::narrow_klass_range())))); > + = operand_valid_for_logical_immediate > + (/*is32*/false, (uint64_t)CompressedKlassPointers::base()) > + && ((uint64_t)CompressedKlassPointers::base() > + > (1UL << log2_intptr(CompressedKlassPointers::range()))); > } > > // These routines should emit JVMTI PopFrame and ForceEarlyReturn handling code. > > -- > 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 Thu May 9 16:11:15 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 9 May 2019 18:11:15 +0200 Subject: AArch64 build is broken In-Reply-To: <1d622d0e-b2e9-7086-0087-24bd9f2c83f9@redhat.com> References: <1d622d0e-b2e9-7086-0087-24bd9f2c83f9@redhat.com> Message-ID: <3d9a2d89-fc38-aa03-a440-4d5736c5c02d@oracle.com> Looks good. StefanK On 2019-05-09 16:59, Andrew Haley wrote: > I'm testing this patch: > > diff -r 77e95181b5d6 src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp > --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Thu May 09 07:33:28 2019 -0700 > +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Thu May 09 10:58:02 2019 -0400 > @@ -27,6 +27,7 @@ > #define CPU_AARCH64_MACROASSEMBLER_AARCH64_HPP > > #include "asm/assembler.hpp" > +#include "oops/compressedOops.hpp" > > // MacroAssembler extends Assembler by frequently used macros. > // > @@ -85,10 +86,10 @@ > public: > MacroAssembler(CodeBuffer* code) : Assembler(code) { > use_XOR_for_compressed_class_base > - = (operand_valid_for_logical_immediate(false /*is32*/, > - (uint64_t)Universe::narrow_klass_base()) > - && ((uint64_t)Universe::narrow_klass_base() > - > (1UL << log2_intptr(Universe::narrow_klass_range())))); > + = operand_valid_for_logical_immediate > + (/*is32*/false, (uint64_t)CompressedKlassPointers::base()) > + && ((uint64_t)CompressedKlassPointers::base() > + > (1UL << log2_intptr(CompressedKlassPointers::range()))); > } > > // These routines should emit JVMTI PopFrame and ForceEarlyReturn handling code. > From stefan.karlsson at oracle.com Thu May 9 16:20:37 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 9 May 2019 18:20:37 +0200 Subject: AArch64 build is broken In-Reply-To: <1d622d0e-b2e9-7086-0087-24bd9f2c83f9@redhat.com> References: <1d622d0e-b2e9-7086-0087-24bd9f2c83f9@redhat.com> Message-ID: I searched for references to Universe::narrow and also found a reference in the PPC code: diff --git a/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp b/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp --- a/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp +++ b/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp @@ -36,6 +36,7 @@ ?#include "gc/shared/barrierSet.hpp" ?#include "gc/shared/cardTableBarrierSet.hpp" ?#include "nativeInst_ppc.hpp" +#include "oops/compressedOops.hpp" ?#include "oops/objArrayKlass.hpp" ?#include "runtime/frame.inline.hpp" ?#include "runtime/safepointMechanism.inline.hpp" @@ -1237,7 +1238,7 @@ ?? int disp_value = addr->disp(); ?? bool needs_patching = (patch_code != lir_patch_none); ?? bool compress_oop = (type == T_ARRAY || type == T_OBJECT) && UseCompressedOops && !wide && -????????????????????? Universe::narrow_oop_mode() != Universe::UnscaledNarrowOop; +????????????????????? CompressedOops::mode() != Universe::UnscaledNarrowOop; ?? bool load_disp = addr->index()->is_illegal() && !Assembler::is_simm16(disp_value); ?? bool use_R29 = compress_oop && load_disp; // Avoid register conflict, also do null check before killing R29. ?? // Null check for large offsets in LIRGenerator::do_StoreField. I created a bug entry for this: https://bugs.openjdk.java.net/browse/JDK-8223637 StefanK On 2019-05-09 16:59, Andrew Haley wrote: > I'm testing this patch: > > diff -r 77e95181b5d6 src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp > --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Thu May 09 07:33:28 2019 -0700 > +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Thu May 09 10:58:02 2019 -0400 > @@ -27,6 +27,7 @@ > #define CPU_AARCH64_MACROASSEMBLER_AARCH64_HPP > > #include "asm/assembler.hpp" > +#include "oops/compressedOops.hpp" > > // MacroAssembler extends Assembler by frequently used macros. > // > @@ -85,10 +86,10 @@ > public: > MacroAssembler(CodeBuffer* code) : Assembler(code) { > use_XOR_for_compressed_class_base > - = (operand_valid_for_logical_immediate(false /*is32*/, > - (uint64_t)Universe::narrow_klass_base()) > - && ((uint64_t)Universe::narrow_klass_base() > - > (1UL << log2_intptr(Universe::narrow_klass_range())))); > + = operand_valid_for_logical_immediate > + (/*is32*/false, (uint64_t)CompressedKlassPointers::base()) > + && ((uint64_t)CompressedKlassPointers::base() > + > (1UL << log2_intptr(CompressedKlassPointers::range()))); > } > > // These routines should emit JVMTI PopFrame and ForceEarlyReturn handling code. > From chuchao333 at gmail.com Thu May 9 16:43:00 2019 From: chuchao333 at gmail.com (chao chu) Date: Thu, 9 May 2019 12:43:00 -0400 Subject: Very long (nearly 10s, abnormal) "Choose CSet" time in a young collection Message-ID: Hi, We got a weird issue in our prod environment that we observed a nearly 10s "Choose CSet" time in a young GC (it's GCLocker initiated though, not sure if this is relevant), while the related "start choosing cset..." and "finish choosing cset..." log lines happened in the same milli-sec, which just doesn't make much sense. Looking at the related G1 code, all related happened in this `finalize_cset` function: http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot /file/c16cc0cdcce5/src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp#l1949 the reported value in the "Choose CSet" is simply the sum of these two: phase_times()->record_young_cset_choice_time_ms((young_end_time_sec - young_start_time_sec) * 1000.0); ... phase_times()->record_non_young_cset_choice_time_ms((non_young_end_time_sec - non_young_start_time_sec) * 1000.0); possibly the jvm process got stuck for some reason before the `double non_young_end_time_sec = os::elapsedTime();` ? ergo_verbose5(ErgoCSetConstruction, "finish choosing CSet", ergo_format_region("eden") ergo_format_region("survivors") ergo_format_region("old") ergo_format_ms("predicted pause time") ergo_format_ms("target pause time"), eden_region_length, survivor_region_length, old_cset_region_length(), predicted_pause_time_ms, target_pause_time_ms); double non_young_end_time_sec = os::elapsedTime(); phase_times()->record_non_young_cset_choice_time_ms((non_young_end_time_sec - non_young_start_time_sec) * 1000.0); evacuation_info.set_collectionset_regions(cset_region_length()); } >From your experience, what could be the causes for the stuck? any particular os/host level metrics we should check? (only saw this once and couldn't re-produce it). Many thanks in advance, any insights are welcome :) The sample gc log sections below (due to our firm's policy, I couldn't post the gc log directly to public, sorry about that): [Other: 9698.8 ms] [Choose CSet: *9677.5 ms*] [Ref Proc: 0.3 ms] [Ref Enq: 0.0 ms] [Free CSet: 0.3 ms] [Eden: 18G(18G)->0B(352M) Survivors: 1232M->1280M Heap: 26.5G(32G)->8175.2M(32G)] [Times: user=5 sys=0.09, real=10.55 secs] Regards, -- ChuChao From lutz.schmidt at sap.com Thu May 9 16:46:08 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Thu, 9 May 2019 16:46:08 +0000 Subject: AArch64 build is broken In-Reply-To: References: <1d622d0e-b2e9-7086-0087-24bd9f2c83f9@redhat.com> Message-ID: <9477FCF9-0B0A-4E38-BF7A-B43CA31D82B0@sap.com> S390 is affected as well. C1_LIRAssembler_s390.cpp is missing universe.hpp. Checking other platforms... Regards, Lutz ?On 09.05.19, 18:20, "hotspot-dev on behalf of Stefan Karlsson" wrote: I searched for references to Universe::narrow and also found a reference in the PPC code: diff --git a/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp b/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp --- a/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp +++ b/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp @@ -36,6 +36,7 @@ #include "gc/shared/barrierSet.hpp" #include "gc/shared/cardTableBarrierSet.hpp" #include "nativeInst_ppc.hpp" +#include "oops/compressedOops.hpp" #include "oops/objArrayKlass.hpp" #include "runtime/frame.inline.hpp" #include "runtime/safepointMechanism.inline.hpp" @@ -1237,7 +1238,7 @@ int disp_value = addr->disp(); bool needs_patching = (patch_code != lir_patch_none); bool compress_oop = (type == T_ARRAY || type == T_OBJECT) && UseCompressedOops && !wide && - Universe::narrow_oop_mode() != Universe::UnscaledNarrowOop; + CompressedOops::mode() != Universe::UnscaledNarrowOop; bool load_disp = addr->index()->is_illegal() && !Assembler::is_simm16(disp_value); bool use_R29 = compress_oop && load_disp; // Avoid register conflict, also do null check before killing R29. // Null check for large offsets in LIRGenerator::do_StoreField. I created a bug entry for this: https://bugs.openjdk.java.net/browse/JDK-8223637 StefanK On 2019-05-09 16:59, Andrew Haley wrote: > I'm testing this patch: > > diff -r 77e95181b5d6 src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp > --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Thu May 09 07:33:28 2019 -0700 > +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Thu May 09 10:58:02 2019 -0400 > @@ -27,6 +27,7 @@ > #define CPU_AARCH64_MACROASSEMBLER_AARCH64_HPP > > #include "asm/assembler.hpp" > +#include "oops/compressedOops.hpp" > > // MacroAssembler extends Assembler by frequently used macros. > // > @@ -85,10 +86,10 @@ > public: > MacroAssembler(CodeBuffer* code) : Assembler(code) { > use_XOR_for_compressed_class_base > - = (operand_valid_for_logical_immediate(false /*is32*/, > - (uint64_t)Universe::narrow_klass_base()) > - && ((uint64_t)Universe::narrow_klass_base() > - > (1UL << log2_intptr(Universe::narrow_klass_range())))); > + = operand_valid_for_logical_immediate > + (/*is32*/false, (uint64_t)CompressedKlassPointers::base()) > + && ((uint64_t)CompressedKlassPointers::base() > + > (1UL << log2_intptr(CompressedKlassPointers::range()))); > } > > // These routines should emit JVMTI PopFrame and ForceEarlyReturn handling code. > From stuart.monteith at linaro.org Thu May 9 16:52:25 2019 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Thu, 9 May 2019 17:52:25 +0100 Subject: AArch64 build is broken In-Reply-To: <3d9a2d89-fc38-aa03-a440-4d5736c5c02d@oracle.com> References: <1d622d0e-b2e9-7086-0087-24bd9f2c83f9@redhat.com> <3d9a2d89-fc38-aa03-a440-4d5736c5c02d@oracle.com> Message-ID: Ah, building with debug, I get the following: home/stuart.monteith/repos/jdk-mm/src/hotspot/cpu/aarch64/compiledIC_aot_aarch64.cpp: In member function ?virtual void CompiledPltStaticCall::set_to_interpreted(const methodHandle&, address)?: /home/stuart.monteith/repos/jdk-mm/src/hotspot/cpu/aarch64/compiledIC_aot_aarch64.cpp:58:34: error: ?Universe? has not been declared assert(destination == (address)Universe::non_oop_word() ^ /home/stuart.monteith/repos/jdk-mm/src/hotspot/share/utilities/debug.hpp:55:9: note: in definition of macro ?vmassert? if (!(p)) { \ ^ /home/stuart.monteith/repos/jdk-mm/src/hotspot/cpu/aarch64/compiledIC_aot_aarch64.cpp:58:3: note: in expansion of macro ?assert? assert(destination == (address)Universe::non_oop_word() ^~~~~~ On Thu, 9 May 2019 at 17:21, Stefan Karlsson wrote: > > Looks good. > > StefanK > > On 2019-05-09 16:59, Andrew Haley wrote: > > I'm testing this patch: > > > > diff -r 77e95181b5d6 src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp > > --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Thu May 09 07:33:28 2019 -0700 > > +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Thu May 09 10:58:02 2019 -0400 > > @@ -27,6 +27,7 @@ > > #define CPU_AARCH64_MACROASSEMBLER_AARCH64_HPP > > > > #include "asm/assembler.hpp" > > +#include "oops/compressedOops.hpp" > > > > // MacroAssembler extends Assembler by frequently used macros. > > // > > @@ -85,10 +86,10 @@ > > public: > > MacroAssembler(CodeBuffer* code) : Assembler(code) { > > use_XOR_for_compressed_class_base > > - = (operand_valid_for_logical_immediate(false /*is32*/, > > - (uint64_t)Universe::narrow_klass_base()) > > - && ((uint64_t)Universe::narrow_klass_base() > > - > (1UL << log2_intptr(Universe::narrow_klass_range())))); > > + = operand_valid_for_logical_immediate > > + (/*is32*/false, (uint64_t)CompressedKlassPointers::base()) > > + && ((uint64_t)CompressedKlassPointers::base() > > + > (1UL << log2_intptr(CompressedKlassPointers::range()))); > > } > > > > // These routines should emit JVMTI PopFrame and ForceEarlyReturn handling code. > > > From aph at redhat.com Thu May 9 16:59:24 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 9 May 2019 17:59:24 +0100 Subject: 8223645: AArch64 build broken by fix for 8223136 In-Reply-To: <3d9a2d89-fc38-aa03-a440-4d5736c5c02d@oracle.com> References: <1d622d0e-b2e9-7086-0087-24bd9f2c83f9@redhat.com> <3d9a2d89-fc38-aa03-a440-4d5736c5c02d@oracle.com> Message-ID: On 5/9/19 5:11 PM, Stefan Karlsson wrote: > Looks good. Thanks, pushed this: http://cr.openjdk.java.net/~aph/8223645/ -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From lutz.schmidt at sap.com Thu May 9 17:00:15 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Thu, 9 May 2019 17:00:15 +0000 Subject: AArch64 build is broken In-Reply-To: <9477FCF9-0B0A-4E38-BF7A-B43CA31D82B0@sap.com> References: <1d622d0e-b2e9-7086-0087-24bd9f2c83f9@redhat.com> <9477FCF9-0B0A-4E38-BF7A-B43CA31D82B0@sap.com> Message-ID: <8D07E853-04A7-4D87-8BCC-1F6171FD1C23@sap.com> What I found so far: Occurences of Universe::non_oop_word() of Universe::heap() with no #include "memory/universe.hpp" in file: c1_LIRAssembler_ppc.cpp c1_LIRAssembler_s390.cpp compiledIC_aot_aarch64.cpp c1_LIRAssembler_sparc.cpp sharedRuntime_x86_64.cpp Don't build with precompiled headers! And try debug build! Regards, Lutz ?On 09.05.19, 18:46, "hotspot-dev on behalf of Schmidt, Lutz" wrote: S390 is affected as well. C1_LIRAssembler_s390.cpp is missing universe.hpp. Checking other platforms... Regards, Lutz On 09.05.19, 18:20, "hotspot-dev on behalf of Stefan Karlsson" wrote: I searched for references to Universe::narrow and also found a reference in the PPC code: diff --git a/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp b/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp --- a/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp +++ b/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp @@ -36,6 +36,7 @@ #include "gc/shared/barrierSet.hpp" #include "gc/shared/cardTableBarrierSet.hpp" #include "nativeInst_ppc.hpp" +#include "oops/compressedOops.hpp" #include "oops/objArrayKlass.hpp" #include "runtime/frame.inline.hpp" #include "runtime/safepointMechanism.inline.hpp" @@ -1237,7 +1238,7 @@ int disp_value = addr->disp(); bool needs_patching = (patch_code != lir_patch_none); bool compress_oop = (type == T_ARRAY || type == T_OBJECT) && UseCompressedOops && !wide && - Universe::narrow_oop_mode() != Universe::UnscaledNarrowOop; + CompressedOops::mode() != Universe::UnscaledNarrowOop; bool load_disp = addr->index()->is_illegal() && !Assembler::is_simm16(disp_value); bool use_R29 = compress_oop && load_disp; // Avoid register conflict, also do null check before killing R29. // Null check for large offsets in LIRGenerator::do_StoreField. I created a bug entry for this: https://bugs.openjdk.java.net/browse/JDK-8223637 StefanK On 2019-05-09 16:59, Andrew Haley wrote: > I'm testing this patch: > > diff -r 77e95181b5d6 src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp > --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Thu May 09 07:33:28 2019 -0700 > +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Thu May 09 10:58:02 2019 -0400 > @@ -27,6 +27,7 @@ > #define CPU_AARCH64_MACROASSEMBLER_AARCH64_HPP > > #include "asm/assembler.hpp" > +#include "oops/compressedOops.hpp" > > // MacroAssembler extends Assembler by frequently used macros. > // > @@ -85,10 +86,10 @@ > public: > MacroAssembler(CodeBuffer* code) : Assembler(code) { > use_XOR_for_compressed_class_base > - = (operand_valid_for_logical_immediate(false /*is32*/, > - (uint64_t)Universe::narrow_klass_base()) > - && ((uint64_t)Universe::narrow_klass_base() > - > (1UL << log2_intptr(Universe::narrow_klass_range())))); > + = operand_valid_for_logical_immediate > + (/*is32*/false, (uint64_t)CompressedKlassPointers::base()) > + && ((uint64_t)CompressedKlassPointers::base() > + > (1UL << log2_intptr(CompressedKlassPointers::range()))); > } > > // These routines should emit JVMTI PopFrame and ForceEarlyReturn handling code. > From stefan.karlsson at oracle.com Thu May 9 17:46:16 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 9 May 2019 19:46:16 +0200 Subject: AArch64 build is broken In-Reply-To: <8D07E853-04A7-4D87-8BCC-1F6171FD1C23@sap.com> References: <1d622d0e-b2e9-7086-0087-24bd9f2c83f9@redhat.com> <9477FCF9-0B0A-4E38-BF7A-B43CA31D82B0@sap.com> <8D07E853-04A7-4D87-8BCC-1F6171FD1C23@sap.com> Message-ID: <534fc8ff-cb0b-551a-667e-e049bebe5646@oracle.com> Thanks, I searched for Universe:: and missing includes to universe.hpp. I also added an updated version of the patch to fix the PPC problem below: http://cr.openjdk.java.net/~stefank/8223637/webrev.01/ I'll run this patch through the platforms we test, but I don't have a setup to test the changes for ppc, s390, or aarch64, so I would appreciate if someone could take this for a spin. Thanks and sorry for breaking these platforms. StefanK On 2019-05-09 19:00, Schmidt, Lutz wrote: > What I found so far: > Occurences of Universe::non_oop_word() of Universe::heap() with no #include "memory/universe.hpp" in file: > > c1_LIRAssembler_ppc.cpp > c1_LIRAssembler_s390.cpp > compiledIC_aot_aarch64.cpp > c1_LIRAssembler_sparc.cpp > sharedRuntime_x86_64.cpp > > Don't build with precompiled headers! And try debug build! > > Regards, > Lutz > > > ?On 09.05.19, 18:46, "hotspot-dev on behalf of Schmidt, Lutz" wrote: > > S390 is affected as well. C1_LIRAssembler_s390.cpp is missing universe.hpp. > Checking other platforms... > > Regards, > Lutz > > On 09.05.19, 18:20, "hotspot-dev on behalf of Stefan Karlsson" wrote: > > I searched for references to Universe::narrow and also found a reference > in the PPC code: > > diff --git a/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp > b/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp > --- a/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp > +++ b/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp > @@ -36,6 +36,7 @@ > #include "gc/shared/barrierSet.hpp" > #include "gc/shared/cardTableBarrierSet.hpp" > #include "nativeInst_ppc.hpp" > +#include "oops/compressedOops.hpp" > #include "oops/objArrayKlass.hpp" > #include "runtime/frame.inline.hpp" > #include "runtime/safepointMechanism.inline.hpp" > @@ -1237,7 +1238,7 @@ > int disp_value = addr->disp(); > bool needs_patching = (patch_code != lir_patch_none); > bool compress_oop = (type == T_ARRAY || type == T_OBJECT) && > UseCompressedOops && !wide && > - Universe::narrow_oop_mode() != > Universe::UnscaledNarrowOop; > + CompressedOops::mode() != > Universe::UnscaledNarrowOop; > bool load_disp = addr->index()->is_illegal() && > !Assembler::is_simm16(disp_value); > bool use_R29 = compress_oop && load_disp; // Avoid register > conflict, also do null check before killing R29. > // Null check for large offsets in LIRGenerator::do_StoreField. > > I created a bug entry for this: > https://bugs.openjdk.java.net/browse/JDK-8223637 > > StefanK > > On 2019-05-09 16:59, Andrew Haley wrote: > > I'm testing this patch: > > > > diff -r 77e95181b5d6 src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp > > --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Thu May 09 07:33:28 2019 -0700 > > +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Thu May 09 10:58:02 2019 -0400 > > @@ -27,6 +27,7 @@ > > #define CPU_AARCH64_MACROASSEMBLER_AARCH64_HPP > > > > #include "asm/assembler.hpp" > > +#include "oops/compressedOops.hpp" > > > > // MacroAssembler extends Assembler by frequently used macros. > > // > > @@ -85,10 +86,10 @@ > > public: > > MacroAssembler(CodeBuffer* code) : Assembler(code) { > > use_XOR_for_compressed_class_base > > - = (operand_valid_for_logical_immediate(false /*is32*/, > > - (uint64_t)Universe::narrow_klass_base()) > > - && ((uint64_t)Universe::narrow_klass_base() > > - > (1UL << log2_intptr(Universe::narrow_klass_range())))); > > + = operand_valid_for_logical_immediate > > + (/*is32*/false, (uint64_t)CompressedKlassPointers::base()) > > + && ((uint64_t)CompressedKlassPointers::base() > > + > (1UL << log2_intptr(CompressedKlassPointers::range()))); > > } > > > > // These routines should emit JVMTI PopFrame and ForceEarlyReturn handling code. > > > > > > > From thomas.schatzl at oracle.com Thu May 9 17:47:29 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 09 May 2019 19:47:29 +0200 Subject: Very long (nearly 10s, abnormal) "Choose CSet" time in a young collection In-Reply-To: References: Message-ID: Hi, On Thu, 2019-05-09 at 12:43 -0400, chao chu wrote: > Hi, > We got a weird issue in our prod environment that we observed a > nearly 10s "Choose CSet" time in a young GC (it's GCLocker initiated > though, not sure if this is relevant), while the related "start > choosing cset..." and "finish choosing cset..." log lines happened in > the same milli-sec, which just doesn't make much sense. > > Looking at the related G1 code, all related happened in this > `finalize_cset` function: > http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot > /file/c16cc0cdcce5/src/share/vm/gc_implementation/g1/g1CollectorPolic > y.cpp#l1949 > > the reported value in the "Choose CSet" is simply the sum of these > two: > [...] > > From your experience, what could be the causes for the stuck? any > particular os/host level metrics we should check? (only saw this once > and couldn't re-produce it). Many thanks in advance, any insights are > welcome :) > > > The sample gc log sections below (due to our firm's policy, I > couldn't post > the gc log directly to public, sorry about that): > > > [Other: 9698.8 ms] > [Choose CSet: *9677.5 ms*] > [Ref Proc: 0.3 ms] > [Ref Enq: 0.0 ms] > [Free CSet: 0.3 ms] > [Eden: 18G(18G)->0B(352M) Survivors: 1232M->1280M Heap: > 26.5G(32G)->8175.2M(32G)] > [Times: user=5 sys=0.09, real=10.55 secs] ^^--- there seems to be something cut here for user time statistic Since you mentioned that this has been a one-off event, and given your heap size it is unlikely that this phase would take that long on its own. The cause may be one of the known causes for such unexpected pauses: - swapping/memory issues on the machine, stalling the java process and basically everything else at that time. - the kernel trying to coalesce small pages into huge pages "transparently". - the VM trying to write out the log to disk during very high I/O activity of another process on the same machine, blocking for a long time. On the other hand sys time seems very low in this case, so I may be wrong. I would start with something like vmstat (on Linux) to show i/o and memory activity. (Blatantly taken from https://docs.oracle.com/en/java/javase/11/gctuning/garbage-first-garbage-collector-tuning.html#GUID-8D9B2530-E370-4B8B-8ADD-A43674FC6658 :) ) Thanks, Thomas From lutz.schmidt at sap.com Thu May 9 17:59:19 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Thu, 9 May 2019 17:59:19 +0000 Subject: AArch64 build is broken In-Reply-To: <534fc8ff-cb0b-551a-667e-e049bebe5646@oracle.com> References: <1d622d0e-b2e9-7086-0087-24bd9f2c83f9@redhat.com> <9477FCF9-0B0A-4E38-BF7A-B43CA31D82B0@sap.com> <8D07E853-04A7-4D87-8BCC-1F6171FD1C23@sap.com> <534fc8ff-cb0b-551a-667e-e049bebe5646@oracle.com> Message-ID: <564DDB0E-01F3-4DDF-8C78-CCE704FFDEC2@sap.com> Hi Stefan, the change looks good. I'm not a reviewer, though. What happened to compiledIC_aot_aarch64.cpp? Did you find that file not to need the #include? Re. Testing: It's too late now for SAP's nightly builds and tests. They start between 6pm and 8pm (UTC). I will run some builds tomorrow (Friday), during the day, at least on ppc, ppcle, and s390. I'll post the results as they come in. Thanks, Lutz ?On 09.05.19, 19:46, "Stefan Karlsson" wrote: Thanks, I searched for Universe:: and missing includes to universe.hpp. I also added an updated version of the patch to fix the PPC problem below: http://cr.openjdk.java.net/~stefank/8223637/webrev.01/ I'll run this patch through the platforms we test, but I don't have a setup to test the changes for ppc, s390, or aarch64, so I would appreciate if someone could take this for a spin. Thanks and sorry for breaking these platforms. StefanK On 2019-05-09 19:00, Schmidt, Lutz wrote: > What I found so far: > Occurences of Universe::non_oop_word() of Universe::heap() with no #include "memory/universe.hpp" in file: > > c1_LIRAssembler_ppc.cpp > c1_LIRAssembler_s390.cpp > compiledIC_aot_aarch64.cpp > c1_LIRAssembler_sparc.cpp > sharedRuntime_x86_64.cpp > > Don't build with precompiled headers! And try debug build! > > Regards, > Lutz > > > On 09.05.19, 18:46, "hotspot-dev on behalf of Schmidt, Lutz" wrote: > > S390 is affected as well. C1_LIRAssembler_s390.cpp is missing universe.hpp. > Checking other platforms... > > Regards, > Lutz > > On 09.05.19, 18:20, "hotspot-dev on behalf of Stefan Karlsson" wrote: > > I searched for references to Universe::narrow and also found a reference > in the PPC code: > > diff --git a/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp > b/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp > --- a/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp > +++ b/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp > @@ -36,6 +36,7 @@ > #include "gc/shared/barrierSet.hpp" > #include "gc/shared/cardTableBarrierSet.hpp" > #include "nativeInst_ppc.hpp" > +#include "oops/compressedOops.hpp" > #include "oops/objArrayKlass.hpp" > #include "runtime/frame.inline.hpp" > #include "runtime/safepointMechanism.inline.hpp" > @@ -1237,7 +1238,7 @@ > int disp_value = addr->disp(); > bool needs_patching = (patch_code != lir_patch_none); > bool compress_oop = (type == T_ARRAY || type == T_OBJECT) && > UseCompressedOops && !wide && > - Universe::narrow_oop_mode() != > Universe::UnscaledNarrowOop; > + CompressedOops::mode() != > Universe::UnscaledNarrowOop; > bool load_disp = addr->index()->is_illegal() && > !Assembler::is_simm16(disp_value); > bool use_R29 = compress_oop && load_disp; // Avoid register > conflict, also do null check before killing R29. > // Null check for large offsets in LIRGenerator::do_StoreField. > > I created a bug entry for this: > https://bugs.openjdk.java.net/browse/JDK-8223637 > > StefanK > > On 2019-05-09 16:59, Andrew Haley wrote: > > I'm testing this patch: > > > > diff -r 77e95181b5d6 src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp > > --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Thu May 09 07:33:28 2019 -0700 > > +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Thu May 09 10:58:02 2019 -0400 > > @@ -27,6 +27,7 @@ > > #define CPU_AARCH64_MACROASSEMBLER_AARCH64_HPP > > > > #include "asm/assembler.hpp" > > +#include "oops/compressedOops.hpp" > > > > // MacroAssembler extends Assembler by frequently used macros. > > // > > @@ -85,10 +86,10 @@ > > public: > > MacroAssembler(CodeBuffer* code) : Assembler(code) { > > use_XOR_for_compressed_class_base > > - = (operand_valid_for_logical_immediate(false /*is32*/, > > - (uint64_t)Universe::narrow_klass_base()) > > - && ((uint64_t)Universe::narrow_klass_base() > > - > (1UL << log2_intptr(Universe::narrow_klass_range())))); > > + = operand_valid_for_logical_immediate > > + (/*is32*/false, (uint64_t)CompressedKlassPointers::base()) > > + && ((uint64_t)CompressedKlassPointers::base() > > + > (1UL << log2_intptr(CompressedKlassPointers::range()))); > > } > > > > // These routines should emit JVMTI PopFrame and ForceEarlyReturn handling code. > > > > > > > From stefan.karlsson at oracle.com Thu May 9 18:03:35 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 9 May 2019 20:03:35 +0200 Subject: AArch64 build is broken In-Reply-To: <564DDB0E-01F3-4DDF-8C78-CCE704FFDEC2@sap.com> References: <1d622d0e-b2e9-7086-0087-24bd9f2c83f9@redhat.com> <9477FCF9-0B0A-4E38-BF7A-B43CA31D82B0@sap.com> <8D07E853-04A7-4D87-8BCC-1F6171FD1C23@sap.com> <534fc8ff-cb0b-551a-667e-e049bebe5646@oracle.com> <564DDB0E-01F3-4DDF-8C78-CCE704FFDEC2@sap.com> Message-ID: <63b431bf-7b7e-7ae0-47f0-49cb4151f84f@oracle.com> Hi Lutz, On 2019-05-09 19:59, Schmidt, Lutz wrote: > Hi Stefan, > > the change looks good. I'm not a reviewer, though. Thanks. > > What happened to compiledIC_aot_aarch64.cpp? Did you find that file not to need the #include? Andrew already fixed that with JDK-8223645. > > Re. Testing: It's too late now for SAP's nightly builds and tests. They start between 6pm and 8pm (UTC). I will run some builds tomorrow (Friday), during the day, at least on ppc, ppcle, and s390. I'll post the results as they come in. OK. Thanks. StefanK > > Thanks, > Lutz > > ?On 09.05.19, 19:46, "Stefan Karlsson" wrote: > > Thanks, > > I searched for Universe:: and missing includes to universe.hpp. I also > added an updated version of the patch to fix the PPC problem below: > http://cr.openjdk.java.net/~stefank/8223637/webrev.01/ > > I'll run this patch through the platforms we test, but I don't have a > setup to test the changes for ppc, s390, or aarch64, so I would > appreciate if someone could take this for a spin. > > Thanks and sorry for breaking these platforms. > > StefanK > > On 2019-05-09 19:00, Schmidt, Lutz wrote: > > What I found so far: > > Occurences of Universe::non_oop_word() of Universe::heap() with no #include "memory/universe.hpp" in file: > > > > c1_LIRAssembler_ppc.cpp > > c1_LIRAssembler_s390.cpp > > compiledIC_aot_aarch64.cpp > > c1_LIRAssembler_sparc.cpp > > sharedRuntime_x86_64.cpp > > > > Don't build with precompiled headers! And try debug build! > > > > Regards, > > Lutz > > > > > > On 09.05.19, 18:46, "hotspot-dev on behalf of Schmidt, Lutz" wrote: > > > > S390 is affected as well. C1_LIRAssembler_s390.cpp is missing universe.hpp. > > Checking other platforms... > > > > Regards, > > Lutz > > > > On 09.05.19, 18:20, "hotspot-dev on behalf of Stefan Karlsson" wrote: > > > > I searched for references to Universe::narrow and also found a reference > > in the PPC code: > > > > diff --git a/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp > > b/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp > > --- a/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp > > +++ b/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp > > @@ -36,6 +36,7 @@ > > #include "gc/shared/barrierSet.hpp" > > #include "gc/shared/cardTableBarrierSet.hpp" > > #include "nativeInst_ppc.hpp" > > +#include "oops/compressedOops.hpp" > > #include "oops/objArrayKlass.hpp" > > #include "runtime/frame.inline.hpp" > > #include "runtime/safepointMechanism.inline.hpp" > > @@ -1237,7 +1238,7 @@ > > int disp_value = addr->disp(); > > bool needs_patching = (patch_code != lir_patch_none); > > bool compress_oop = (type == T_ARRAY || type == T_OBJECT) && > > UseCompressedOops && !wide && > > - Universe::narrow_oop_mode() != > > Universe::UnscaledNarrowOop; > > + CompressedOops::mode() != > > Universe::UnscaledNarrowOop; > > bool load_disp = addr->index()->is_illegal() && > > !Assembler::is_simm16(disp_value); > > bool use_R29 = compress_oop && load_disp; // Avoid register > > conflict, also do null check before killing R29. > > // Null check for large offsets in LIRGenerator::do_StoreField. > > > > I created a bug entry for this: > > https://bugs.openjdk.java.net/browse/JDK-8223637 > > > > StefanK > > > > On 2019-05-09 16:59, Andrew Haley wrote: > > > I'm testing this patch: > > > > > > diff -r 77e95181b5d6 src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp > > > --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Thu May 09 07:33:28 2019 -0700 > > > +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp Thu May 09 10:58:02 2019 -0400 > > > @@ -27,6 +27,7 @@ > > > #define CPU_AARCH64_MACROASSEMBLER_AARCH64_HPP > > > > > > #include "asm/assembler.hpp" > > > +#include "oops/compressedOops.hpp" > > > > > > // MacroAssembler extends Assembler by frequently used macros. > > > // > > > @@ -85,10 +86,10 @@ > > > public: > > > MacroAssembler(CodeBuffer* code) : Assembler(code) { > > > use_XOR_for_compressed_class_base > > > - = (operand_valid_for_logical_immediate(false /*is32*/, > > > - (uint64_t)Universe::narrow_klass_base()) > > > - && ((uint64_t)Universe::narrow_klass_base() > > > - > (1UL << log2_intptr(Universe::narrow_klass_range())))); > > > + = operand_valid_for_logical_immediate > > > + (/*is32*/false, (uint64_t)CompressedKlassPointers::base()) > > > + && ((uint64_t)CompressedKlassPointers::base() > > > + > (1UL << log2_intptr(CompressedKlassPointers::range()))); > > > } > > > > > > // These routines should emit JVMTI PopFrame and ForceEarlyReturn handling code. > > > > > > > > > > > > > > > > From chuchao333 at gmail.com Thu May 9 18:04:49 2019 From: chuchao333 at gmail.com (chao chu) Date: Thu, 9 May 2019 14:04:49 -0400 Subject: Very long (nearly 10s, abnormal) "Choose CSet" time in a young collection In-Reply-To: References: Message-ID: Hi Thomas, Thanks for your reply. The 'user' part is 5.00 for completeness :) Yes, weeks ago we identified that we also got impacted by linux THP which caused like 90+ seconds in sys time in a full GC. But this one looks different as you mentioned, the sys time is very low. I saw two things we want to understand here: 1. the 5s 'user' time was spent where? 2. the other 5s (real - user) might be possibly due to the host was heavy loaded and the jvm got no CPU time during that? Regards, On Thu, May 9, 2019 at 1:48 PM Thomas Schatzl wrote: > Hi, > > On Thu, 2019-05-09 at 12:43 -0400, chao chu wrote: > > Hi, > > We got a weird issue in our prod environment that we observed a > > nearly 10s "Choose CSet" time in a young GC (it's GCLocker initiated > > though, not sure if this is relevant), while the related "start > > choosing cset..." and "finish choosing cset..." log lines happened in > > the same milli-sec, which just doesn't make much sense. > > > > Looking at the related G1 code, all related happened in this > > `finalize_cset` function: > > http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot > > /file/c16cc0cdcce5/src/share/vm/gc_implementation/g1/g1CollectorPolic > > y.cpp#l1949 > > > > the reported value in the "Choose CSet" is simply the sum of these > > two: > > > [...] > > > > From your experience, what could be the causes for the stuck? any > > particular os/host level metrics we should check? (only saw this once > > and couldn't re-produce it). Many thanks in advance, any insights are > > welcome :) > > > > > > The sample gc log sections below (due to our firm's policy, I > > couldn't post > > the gc log directly to public, sorry about that): > > > > > > [Other: 9698.8 ms] > > [Choose CSet: *9677.5 ms*] > > [Ref Proc: 0.3 ms] > > [Ref Enq: 0.0 ms] > > [Free CSet: 0.3 ms] > > [Eden: 18G(18G)->0B(352M) Survivors: 1232M->1280M Heap: > > 26.5G(32G)->8175.2M(32G)] > > [Times: user=5 sys=0.09, real=10.55 secs] > > ^^--- there seems to be something cut here for user time > statistic > > Since you mentioned that this has been a one-off event, and given your > heap size it is unlikely that this phase would take that long on its > own. The cause may be one of the known causes for such unexpected > pauses: > > - swapping/memory issues on the machine, stalling the java process and > basically everything else at that time. > > - the kernel trying to coalesce small pages into huge pages > "transparently". > > - the VM trying to write out the log to disk during very high I/O > activity of another process on the same machine, blocking for a long > time. > > On the other hand sys time seems very low in this case, so I may be > wrong. > > I would start with something like vmstat (on Linux) to show i/o and > memory activity. > > (Blatantly taken from > > https://docs.oracle.com/en/java/javase/11/gctuning/garbage-first-garbage-collector-tuning.html#GUID-8D9B2530-E370-4B8B-8ADD-A43674FC6658 > :) ) > > Thanks, > Thomas > > > -- ChuChao From erik.osterlund at oracle.com Thu May 9 22:33:48 2019 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Fri, 10 May 2019 00:33:48 +0200 Subject: RFR: 8222841: Incorrect static call stub interactions with class unloading In-Reply-To: <04c23dad-67b2-f4eb-7d6f-6f24d57bbd5b@oracle.com> References: <067fc16e-3104-4e61-b558-9cd4864f079f@oracle.com> <1ca35306-6be8-61ec-127f-196367d94899@oracle.com> <6f615499-6f79-ce41-d835-d64e0741a3be@oracle.com> <04c23dad-67b2-f4eb-7d6f-6f24d57bbd5b@oracle.com> Message-ID: Any more takers? I know you want this stuff. /Erik > On 8 May 2019, at 14:20, Erik ?sterlund wrote: > > Hi Coleen, > > Thanks for the review! > > /Erik > >> On 2019-05-08 14:16, coleen.phillimore at oracle.com wrote: >> >> >>> On 5/2/19 4:55 AM, Erik ?sterlund wrote: >>> Hi Coleen, >>> >>> Thank you for the review. >>> >>>> On 2019-04-23 23:32, coleen.phillimore at oracle.com wrote: >>>> >>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp.frames.html >>>> >>>> Can you mention in a comment that incoming rbx is the method? >>> >>> Fixed. >> >> Thank you! >>> >>>> You can't do a JRT_LEAF function from here, can you to some Method::is_alive() function? Or even a straight up call ? This doesn't seem that it should care about the extra overhead of the call instruction. The assembly code looks correct but yuck not more assembly code. >>> >>> I'm not sure I know how I feel about that. I would have to save and restore all registers then to go into the runtime just to check if the method is alive. Would you be okay with keeping the assembly variant instead until I find a better solution to this problem? (I'm on it) >> >> Yes, this is fine with me. Had to register not liking more assembly. >>> >>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/src/hotspot/share/code/compiledMethod.cpp.frames.html >>>> >>>> 578 case relocInfo::static_stub_type: { >>>> 579 is_in_static_stub = true; >>>> 580 break; >>>> 581 } >>>> 582 >>>> 583 case relocInfo::metadata_type: { >>>> 584 if (!is_in_static_stub) { >>>> 585 continue; >>>> 586 } >>>> >>>> >>>> This was mystifying to me. Can you put a comment that after static_stub_type relocations are generated, the next metadata relocation contains the address that is patched at runtime, so this is the metadata that can be stale and should be cleared by unloading. >>> >>> Sure, I updated the comments, and added a better description about what is going on here. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.01/ >>> >>> Incremental: >>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00_01/ >> >> Looks good! >> Coleen >>> >>> Thanks, >>> /Erik >>> >>>> The clean_ic_stubs() name is my fault. I didn't know what they were and just wanted this code out of my way. >>>> >>>> Thank you for explaining how redefinition is broken by this. I didn't know these metadata_reloc guys were patched at runtime. >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>>> >>>>> On 4/23/19 4:41 AM, Erik ?sterlund wrote: >>>>> Hi, >>>>> >>>>> Static call stubs are cleared in debug builds before an assert checking for dead metadata. This is done in the function "clean_ic_stubs()" (which does not clean ICStubs... but static/optimized virtual call stubs for calling c2i adapters from compiled code...) The reason is that the static call stub has metadata, and it complains about dead metadata being left after inline cache cleaning of is_alive nmethods. >>>>> >>>>> ...except class redefinition looks at this metadata to determine if there is old metadata in subsequent safepoints, and they could have been unloaded then. Ouch. So maybe we shouldn't squelch that assert in debug builds, because it actually shows there is a real problem. >>>>> >>>>> ...and with concurrent class unloading (ZGC and seemingly soon Shenandoah), we can't just clear the call stub of a concurrently running JavaThread; they can racingly call in to them before they get cleared, and then get stuck in an infinite loop, because clearing also involves updating the branch target of the static call stub to a self-loop. Or call a dead method, which also seems like a scary scenario. >>>>> >>>>> All things considered, clearing static call stubs when unloading the code cache seems like a bad idea. >>>>> >>>>> My proposal is the following: >>>>> 1) Make sure that code cache unloading *always* clears out the metadata part (but not the branch part) of static call stubs, so that subsequent operations such as class redefinition will not blow up when looking at the embedded metadata, but it won't get stuck in infinite loops with concurrent code cache unloading. >>>>> 2) Make a c2i entry barrier for concurrently unloading GCs that will reresolve the call when calling into a stale static call stub (iff method is NULL or dead). >>>>> 3) Relax MT-safety asserts to allow the previous medatada to be concurrently unloading when setting the new target. >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8222841 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/ >>>>> >>>>> Thanks, >>>>> /Erik >>>> >>> >> > From vladimir.kozlov at oracle.com Thu May 9 23:56:28 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 9 May 2019 16:56:28 -0700 Subject: RFR: 8222841: Incorrect static call stub interactions with class unloading In-Reply-To: References: <067fc16e-3104-4e61-b558-9cd4864f079f@oracle.com> <1ca35306-6be8-61ec-127f-196367d94899@oracle.com> <6f615499-6f79-ce41-d835-d64e0741a3be@oracle.com> <04c23dad-67b2-f4eb-7d6f-6f24d57bbd5b@oracle.com> Message-ID: Hi Erik, I general looks good to me. One comment: rtmp register seems unused in load_method_holder_cld() What testing you did? There are no link to testing results in RFE. Thanks, Vladimir On 5/9/19 3:33 PM, Erik Osterlund wrote: > Any more takers? I know you want this stuff. > > /Erik > >> On 8 May 2019, at 14:20, Erik ?sterlund wrote: >> >> Hi Coleen, >> >> Thanks for the review! >> >> /Erik >> >>> On 2019-05-08 14:16, coleen.phillimore at oracle.com wrote: >>> >>> >>>> On 5/2/19 4:55 AM, Erik ?sterlund wrote: >>>> Hi Coleen, >>>> >>>> Thank you for the review. >>>> >>>>> On 2019-04-23 23:32, coleen.phillimore at oracle.com wrote: >>>>> >>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp.frames.html >>>>> >>>>> Can you mention in a comment that incoming rbx is the method? >>>> >>>> Fixed. >>> >>> Thank you! >>>> >>>>> You can't do a JRT_LEAF function from here, can you to some Method::is_alive() function? Or even a straight up call ? This doesn't seem that it should care about the extra overhead of the call instruction. The assembly code looks correct but yuck not more assembly code. >>>> >>>> I'm not sure I know how I feel about that. I would have to save and restore all registers then to go into the runtime just to check if the method is alive. Would you be okay with keeping the assembly variant instead until I find a better solution to this problem? (I'm on it) >>> >>> Yes, this is fine with me. Had to register not liking more assembly. >>>> >>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/src/hotspot/share/code/compiledMethod.cpp.frames.html >>>>> >>>>> 578 case relocInfo::static_stub_type: { >>>>> 579 is_in_static_stub = true; >>>>> 580 break; >>>>> 581 } >>>>> 582 >>>>> 583 case relocInfo::metadata_type: { >>>>> 584 if (!is_in_static_stub) { >>>>> 585 continue; >>>>> 586 } >>>>> >>>>> >>>>> This was mystifying to me. Can you put a comment that after static_stub_type relocations are generated, the next metadata relocation contains the address that is patched at runtime, so this is the metadata that can be stale and should be cleared by unloading. >>>> >>>> Sure, I updated the comments, and added a better description about what is going on here. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.01/ >>>> >>>> Incremental: >>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00_01/ >>> >>> Looks good! >>> Coleen >>>> >>>> Thanks, >>>> /Erik >>>> >>>>> The clean_ic_stubs() name is my fault. I didn't know what they were and just wanted this code out of my way. >>>>> >>>>> Thank you for explaining how redefinition is broken by this. I didn't know these metadata_reloc guys were patched at runtime. >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>>>> >>>>>> On 4/23/19 4:41 AM, Erik ?sterlund wrote: >>>>>> Hi, >>>>>> >>>>>> Static call stubs are cleared in debug builds before an assert checking for dead metadata. This is done in the function "clean_ic_stubs()" (which does not clean ICStubs... but static/optimized virtual call stubs for calling c2i adapters from compiled code...) The reason is that the static call stub has metadata, and it complains about dead metadata being left after inline cache cleaning of is_alive nmethods. >>>>>> >>>>>> ...except class redefinition looks at this metadata to determine if there is old metadata in subsequent safepoints, and they could have been unloaded then. Ouch. So maybe we shouldn't squelch that assert in debug builds, because it actually shows there is a real problem. >>>>>> >>>>>> ...and with concurrent class unloading (ZGC and seemingly soon Shenandoah), we can't just clear the call stub of a concurrently running JavaThread; they can racingly call in to them before they get cleared, and then get stuck in an infinite loop, because clearing also involves updating the branch target of the static call stub to a self-loop. Or call a dead method, which also seems like a scary scenario. >>>>>> >>>>>> All things considered, clearing static call stubs when unloading the code cache seems like a bad idea. >>>>>> >>>>>> My proposal is the following: >>>>>> 1) Make sure that code cache unloading *always* clears out the metadata part (but not the branch part) of static call stubs, so that subsequent operations such as class redefinition will not blow up when looking at the embedded metadata, but it won't get stuck in infinite loops with concurrent code cache unloading. >>>>>> 2) Make a c2i entry barrier for concurrently unloading GCs that will reresolve the call when calling into a stale static call stub (iff method is NULL or dead). >>>>>> 3) Relax MT-safety asserts to allow the previous medatada to be concurrently unloading when setting the new target. >>>>>> >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8222841 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> /Erik >>>>> >>>> >>> >> > From vladimir.kozlov at oracle.com Thu May 9 23:57:54 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 9 May 2019 16:57:54 -0700 Subject: RFR: 8222841: Incorrect static call stub interactions with class unloading In-Reply-To: References: <067fc16e-3104-4e61-b558-9cd4864f079f@oracle.com> <1ca35306-6be8-61ec-127f-196367d94899@oracle.com> <6f615499-6f79-ce41-d835-d64e0741a3be@oracle.com> <04c23dad-67b2-f4eb-7d6f-6f24d57bbd5b@oracle.com> Message-ID: <7158cc5e-95ea-80b8-bfe2-4ebb8004d9a7@oracle.com> On 5/9/19 4:56 PM, Vladimir Kozlov wrote: > Hi Erik, > > I general looks good to me. One comment: 'In general' ;) > > rtmp register seems unused in load_method_holder_cld() > > What testing you did? There are no link to testing results in RFE. > > Thanks, > Vladimir > > On 5/9/19 3:33 PM, Erik Osterlund wrote: >> Any more takers? I know you want this stuff. >> >> /Erik >> >>> On 8 May 2019, at 14:20, Erik ?sterlund wrote: >>> >>> Hi Coleen, >>> >>> Thanks for the review! >>> >>> /Erik >>> >>>> On 2019-05-08 14:16, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>>> On 5/2/19 4:55 AM, Erik ?sterlund wrote: >>>>> Hi Coleen, >>>>> >>>>> Thank you for the review. >>>>> >>>>>> On 2019-04-23 23:32, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp.frames.html >>>>>> >>>>>> >>>>>> Can you mention in a comment that incoming rbx is the method? >>>>> >>>>> Fixed. >>>> >>>> Thank you! >>>>> >>>>>> You can't do a JRT_LEAF function from here, can you to some Method::is_alive() function?? Or >>>>>> even a straight up call ?? This doesn't seem that it should care about the extra overhead of >>>>>> the call instruction.? The assembly code looks correct but yuck not more assembly code. >>>>> >>>>> I'm not sure I know how I feel about that. I would have to save and restore all registers then >>>>> to go into the runtime just to check if the method is alive. Would you be okay with keeping the >>>>> assembly variant instead until I find a better solution to this problem? (I'm on it) >>>> >>>> Yes, this is fine with me.? Had to register not liking more assembly. >>>>> >>>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/src/hotspot/share/code/compiledMethod.cpp.frames.html >>>>>> >>>>>> >>>>>> 578 case relocInfo::static_stub_type: { >>>>>> 579 is_in_static_stub = true; >>>>>> 580 break; >>>>>> 581 } >>>>>> 582 >>>>>> 583 case relocInfo::metadata_type: { >>>>>> 584 if (!is_in_static_stub) { >>>>>> 585 continue; >>>>>> 586 } >>>>>> >>>>>> >>>>>> This was mystifying to me.? Can you put a comment that after static_stub_type relocations are >>>>>> generated, the next metadata relocation contains the address that is patched at runtime, so >>>>>> this is the metadata that can be stale and should be cleared by unloading. >>>>> >>>>> Sure, I updated the comments, and added a better description about what is going on here. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.01/ >>>>> >>>>> Incremental: >>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00_01/ >>>> >>>> Looks good! >>>> Coleen >>>>> >>>>> Thanks, >>>>> /Erik >>>>> >>>>>> The clean_ic_stubs() name is my fault. I didn't know what they were and just wanted this code >>>>>> out of my way. >>>>>> >>>>>> Thank you for explaining how redefinition is broken by this. I didn't know these >>>>>> metadata_reloc guys were patched at runtime. >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> >>>>>> >>>>>>> On 4/23/19 4:41 AM, Erik ?sterlund wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Static call stubs are cleared in debug builds before an assert checking for dead metadata. >>>>>>> This is done in the function "clean_ic_stubs()" (which does not clean ICStubs... but >>>>>>> static/optimized virtual call stubs for calling c2i adapters from compiled code...) The >>>>>>> reason is that the static call stub has metadata, and it complains about dead metadata being >>>>>>> left after inline cache cleaning of is_alive nmethods. >>>>>>> >>>>>>> ...except class redefinition looks at this metadata to determine if there is old metadata in >>>>>>> subsequent safepoints, and they could have been unloaded then. Ouch. So maybe we shouldn't >>>>>>> squelch that assert in debug builds, because it actually shows there is a real problem. >>>>>>> >>>>>>> ...and with concurrent class unloading (ZGC and seemingly soon Shenandoah), we can't just >>>>>>> clear the call stub of a concurrently running JavaThread; they can racingly call in to them >>>>>>> before they get cleared, and then get stuck in an infinite loop, because clearing also >>>>>>> involves updating the branch target of the static call stub to a self-loop. Or call a dead >>>>>>> method, which also seems like a scary scenario. >>>>>>> >>>>>>> All things considered, clearing static call stubs when unloading the code cache seems like a >>>>>>> bad idea. >>>>>>> >>>>>>> My proposal is the following: >>>>>>> 1) Make sure that code cache unloading *always* clears out the metadata part (but not the >>>>>>> branch part) of static call stubs, so that subsequent operations such as class redefinition >>>>>>> will not blow up when looking at the embedded metadata, but it won't get stuck in infinite >>>>>>> loops with concurrent code cache unloading. >>>>>>> 2) Make a c2i entry barrier for concurrently unloading GCs that will reresolve the call when >>>>>>> calling into a stale static call stub (iff method is NULL or dead). >>>>>>> 3) Relax MT-safety asserts to allow the previous medatada to be concurrently unloading when >>>>>>> setting the new target. >>>>>>> >>>>>>> Bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8222841 >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> /Erik >>>>>> >>>>> >>>> >>> >> From aeubanks at google.com Fri May 10 02:05:58 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Thu, 9 May 2019 19:05:58 -0700 Subject: [RFR]: 8223668: Clang on Linux build broken Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8223668 Webrev: http://cr.openjdk.java.net/~aeubanks/8223668/webrev.00/ Currently the clang build on Linux is broken. $ clang --version clang version 4.0.1-10 (tags/RELEASE_401/final) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin With "bash configure --with-toolchain-type=clang" we get the following errors: jdk/jdk/src/hotspot/os/linux/osContainer_linux.cpp:470:22: error: conversion from string literal to 'char *' is deprecated [-Werror,-Wc++11-compat-deprecated-writable-strings] char* format = "%s " JULONG_FORMAT; Fix is to use "const char *" instead of "char *". jdk/jdk/build/hotspot/variant-server/libjvm/gtest/libjvm.so: undefined reference to `objArrayOopDesc::obj_at(int) const' clang: error: linker command failed with exit code 1 (use -v to see invocation) Fix is to add missing import to src/hotspot/share/jvmci/jvmciCompiler.cpp From david.holmes at oracle.com Fri May 10 02:14:42 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 May 2019 12:14:42 +1000 Subject: RFR: 8223186: HotSpot compile warnings from GCC 9 In-Reply-To: References: Message-ID: <960ff595-3001-ce41-6a90-3904b9cd0b20@oracle.com> Hi Yasumasa, This all looks fine to me. Thanks, David On 2/05/2019 12:03 pm, Yasumasa Suenaga wrote: > Hi all, > > Please review this change: > > ? JBS: https://bugs.openjdk.java.net/browse/JDK-8223186 > ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8223186/webrev.00/ > > > I saw following warnings when I compiled HotSpot with GCC 9 on Fedora 30 > due to -Wwrite-strings, -Wstringop-truncation and -Wclass-memaccess. > I filed all warnings to JBS. > > > Thanks, > > Yasumasa From david.holmes at oracle.com Fri May 10 02:17:25 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 May 2019 12:17:25 +1000 Subject: [RFR]: 8223668: Clang on Linux build broken In-Reply-To: References: Message-ID: <91c33874-7c10-2aa0-eb03-55628c4b8856@oracle.com> Hi Arthur, On 10/05/2019 12:05 pm, Arthur Eubanks wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8223668 > Webrev: http://cr.openjdk.java.net/~aeubanks/8223668/webrev.00/ > > Currently the clang build on Linux is broken. > > $ clang --version > clang version 4.0.1-10 (tags/RELEASE_401/final) > Target: x86_64-pc-linux-gnu > Thread model: posix > InstalledDir: /usr/bin > > With "bash configure --with-toolchain-type=clang" we get the following > errors: > > > jdk/jdk/src/hotspot/os/linux/osContainer_linux.cpp:470:22: error: > conversion from string literal to 'char *' is deprecated > [-Werror,-Wc++11-compat-deprecated-writable-strings] > char* format = "%s " JULONG_FORMAT; > > Fix is to use "const char *" instead of "char *". I just updated the bug report - this is already being handled by JDK-8223186: HotSpot compile warnings from GCC 9. > jdk/jdk/build/hotspot/variant-server/libjvm/gtest/libjvm.so: undefined > reference to `objArrayOopDesc::obj_at(int) const' > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > Fix is to add missing import to src/hotspot/share/jvmci/jvmciCompiler.cpp That has also already been fixed: 8223639: [JVMCI] jvmciCompiler.cpp needs to include "oops/objArrayOop.inline.hpp"" Cheers, David From yasuenag at gmail.com Fri May 10 02:19:36 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 10 May 2019 11:19:36 +0900 Subject: RFR: 8223186: HotSpot compile warnings from GCC 9 In-Reply-To: <960ff595-3001-ce41-6a90-3904b9cd0b20@oracle.com> References: <960ff595-3001-ce41-6a90-3904b9cd0b20@oracle.com> Message-ID: Thanks David! I'm waiting for second reviewer. Yasumasa 2019?5?10?(?) 11:14 David Holmes : > > Hi Yasumasa, > > This all looks fine to me. > > Thanks, > David > > On 2/05/2019 12:03 pm, Yasumasa Suenaga wrote: > > Hi all, > > > > Please review this change: > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8223186 > > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8223186/webrev.00/ > > > > > > I saw following warnings when I compiled HotSpot with GCC 9 on Fedora 30 > > due to -Wwrite-strings, -Wstringop-truncation and -Wclass-memaccess. > > I filed all warnings to JBS. > > > > > > Thanks, > > > > Yasumasa From aeubanks at google.com Fri May 10 02:33:25 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Thu, 9 May 2019 19:33:25 -0700 Subject: [RFR]: 8223668: Clang on Linux build broken In-Reply-To: <91c33874-7c10-2aa0-eb03-55628c4b8856@oracle.com> References: <91c33874-7c10-2aa0-eb03-55628c4b8856@oracle.com> Message-ID: Ah, please ignore this RFR then. *From: *David Holmes *Date: *Thu, May 9, 2019 at 7:17 PM *To: *Arthur Eubanks, Hi Arthur, > > On 10/05/2019 12:05 pm, Arthur Eubanks wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223668 > > Webrev: http://cr.openjdk.java.net/~aeubanks/8223668/webrev.00/ > > > > Currently the clang build on Linux is broken. > > > > $ clang --version > > clang version 4.0.1-10 (tags/RELEASE_401/final) > > Target: x86_64-pc-linux-gnu > > Thread model: posix > > InstalledDir: /usr/bin > > > > With "bash configure --with-toolchain-type=clang" we get the following > > errors: > > > > > > jdk/jdk/src/hotspot/os/linux/osContainer_linux.cpp:470:22: error: > > conversion from string literal to 'char *' is deprecated > > [-Werror,-Wc++11-compat-deprecated-writable-strings] > > char* format = "%s " JULONG_FORMAT; > > > > Fix is to use "const char *" instead of "char *". > > I just updated the bug report - this is already being handled by > JDK-8223186: HotSpot compile warnings from GCC 9. > > > jdk/jdk/build/hotspot/variant-server/libjvm/gtest/libjvm.so: undefined > > reference to `objArrayOopDesc::obj_at(int) const' > > clang: error: linker command failed with exit code 1 (use -v to see > > invocation) > > > > Fix is to add missing import to src/hotspot/share/jvmci/jvmciCompiler.cpp > > That has also already been fixed: > > 8223639: [JVMCI] jvmciCompiler.cpp needs to include > "oops/objArrayOop.inline.hpp"" > > Cheers, > David > From matthias.baesken at sap.com Fri May 10 06:21:51 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 10 May 2019 06:21:51 +0000 Subject: 8222720: Provide extended VMWare/vSphere virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: References: Message-ID: Hello, here is an updated version : http://cr.openjdk.java.net/~mbaesken/webrevs/8222720.2/ I switched to os::dll_load / os::dll_lookup . Also removed the VMWare related names ( now the name is "VirtualizationSupport" ). Best regards, Matthias > > Hi David, thanks for the feedback . I'll provide an updated webrev . > > > **Not sure about the validity of using "vmware" in the name of files or > > classes either due to its trademark status. > > Well , we have a lot of technology names in file-names (AIX and Windows > come to mind) . > > But to be on the safe side, I think I'll choose a more generic name . > > > Best regards, Matthias > From shade at redhat.com Fri May 10 06:41:42 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 10 May 2019 08:41:42 +0200 Subject: RFR (T) 8223676: Minimal VM build failure after 8223136 (Move compressed oops functions to CompressedOops class) Message-ID: <0581e42b-f043-24b4-e261-f90932217dc5@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8223676 Please review the trivial build fix: diff -r 293d45e5108b src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp --- a/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp Fri May 10 06:31:09 2019 +0100 +++ b/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp Fri May 10 08:40:18 2019 +0200 @@ -40,4 +40,5 @@ #include "logging/log.hpp" #include "memory/resourceArea.hpp" +#include "memory/universe.hpp" #include "oops/compiledICHolder.hpp" #include "runtime/safepointMechanism.hpp" Testing: Linux x86_64 minimal build -- Thanks, -Aleksey From david.holmes at oracle.com Fri May 10 06:42:27 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 May 2019 16:42:27 +1000 Subject: 8222720: Provide extended VMWare/vSphere virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: References: Message-ID: <06d00a9c-497b-44de-f834-a0314bd0bf39@oracle.com> Hi Matthias, On 10/05/2019 4:21 pm, Baesken, Matthias wrote: > Hello, here is an updated version : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8222720.2/ > > I switched to os::dll_load / os::dll_lookup . > Also removed the VMWare related names ( now the name is "VirtualizationSupport" ). Thanks! src/hotspot/cpu/x86/vm_version_x86.cpp No ifdefs needed. src/hotspot/share/utilities/virtualizationSupport.cpp 47 #if defined(__linux) The common form of this is: #ifdef LINUX 62 if (GuestLib_StatGet && GuestLib_StatFree) { Style nit: avoid implicit booleans - test against NULL. --- Otherwise seems fine. Thanks, David ----- > Best regards, Matthias > > >> >> Hi David, thanks for the feedback . I'll provide an updated webrev . >> >>> **Not sure about the validity of using "vmware" in the name of files or >>> classes either due to its trademark status. >> >> Well , we have a lot of technology names in file-names (AIX and Windows >> come to mind) . >> >> But to be on the safe side, I think I'll choose a more generic name . >> >> >> Best regards, Matthias >> > From shade at redhat.com Fri May 10 06:45:37 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 10 May 2019 08:45:37 +0200 Subject: RFR (T) 8223675: arm32 build failure after 8223136 (Move compressed oops functions to CompressedOops class Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8223675 Please review the trivial build fix: diff -r f1a8b2447250 src/hotspot/cpu/arm/c1_CodeStubs_arm.cpp --- a/src/hotspot/cpu/arm/c1_CodeStubs_arm.cpp Fri May 10 08:40:10 2019 +0200 +++ b/src/hotspot/cpu/arm/c1_CodeStubs_arm.cpp Fri May 10 08:45:18 2019 +0200 @@ -30,4 +30,5 @@ #include "c1/c1_MacroAssembler.hpp" #include "c1/c1_Runtime1.hpp" +#include "memory/universe.hpp" #include "nativeInst_arm.hpp" #include "runtime/sharedRuntime.hpp" diff -r f1a8b2447250 src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp --- a/src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp Fri May 10 08:40:10 2019 +0200 +++ b/src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp Fri May 10 08:45:18 2019 +0200 @@ -35,4 +35,5 @@ #include "gc/shared/cardTableBarrierSet.hpp" #include "gc/shared/collectedHeap.hpp" +#include "memory/universe.hpp" #include "nativeInst_arm.hpp" #include "oops/objArrayKlass.hpp" diff -r f1a8b2447250 src/hotspot/os_cpu/linux_arm/thread_linux_arm.cpp --- a/src/hotspot/os_cpu/linux_arm/thread_linux_arm.cpp Fri May 10 08:40:10 2019 +0200 +++ b/src/hotspot/os_cpu/linux_arm/thread_linux_arm.cpp Fri May 10 08:45:18 2019 +0200 @@ -29,4 +29,5 @@ #include "gc/shared/collectedHeap.hpp" #include "memory/metaspaceShared.hpp" +#include "memory/universe.hpp" #include "runtime/frame.inline.hpp" Testing: Linux arm32 cross-compilation build -- Thanks, -Aleksey From goetz.lindenmaier at sap.com Fri May 10 06:47:17 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 10 May 2019 06:47:17 +0000 Subject: RFR [XS] : 8223574: add more thread-related system settings info to hs_error file on AIX In-Reply-To: References: Message-ID: Hi Matthias, Thanks for doing this change, I think the information will help to analyze out-of-threads situations. Why do you use three calls to print this one line? I would prefer a single call to st->print_cr(). Eventually you could change the "load average" code similarly. After pushing, could you please update the bug with what new printout you added and a short explanation of it's meaning/purpose? Don't' need to see a new webrev. Thanks and best regards, Goetz. > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Wednesday, May 8, 2019 4:24 PM > To: 'hotspot-dev at openjdk.java.net' > Subject: RFR [XS] : 8223574: add more thread-related system settings info to > hs_error file on AIX > > Hello , please review this small AIX related change . > It adds to the hs_error file on AIX the maximum number of threads within > a process. > > ( The previous change > > https://bugs.openjdk.java.net/browse/JDK-8204598 > > added already more thread-related system settings info to the hs_error file > on Linux. > On AIX I want to enhance the output too . ) > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8223574 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8223574.0/ > > > > Thanks, Matthias From thomas.schatzl at oracle.com Fri May 10 07:33:21 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 10 May 2019 09:33:21 +0200 Subject: Very long (nearly 10s, abnormal) "Choose CSet" time in a young collection In-Reply-To: References: Message-ID: <7c04eb15c1c64da07e847897f51c81f52dfa4a10.camel@oracle.com> Hi, On Thu, 2019-05-09 at 14:04 -0400, chao chu wrote: > Hi Thomas, > > Thanks for your reply. The 'user' part is 5.00 for completeness :) > > Yes, weeks ago we identified that we also got impacted by linux THP > which caused like 90+ seconds in sys time in a full GC. But this one > looks different as you mentioned, the sys time is very low. > > I saw two things we want to understand here: > > 1. the 5s 'user' time was spent where? I can't tell without at least that complete log entry. The log output should be pretty complete and tell you. Note that user time is total CPU time for all threads scheduled on cores during the measurement duration, not wallclock time. So it depends on the amount of parallelism and number of threads used what this means. You can't just subtract real - user and get a useful result unless under very narrow conditions. > 2. the other 5s (real - user) might be possibly due to the host was > heavy loaded and the jvm got no CPU time during that? See above. As suggested earlier I would monitor I/O and memory activity. E.g. I/O stalls during flushing the output buffers could create such an output. Try to route the log output onto a different disk (ramdisk if acceptable; I think even in jdk8u there are options to limit log size and do automatic log rotation) than the same disk used for other processes potentially doing very heavy I/O. Thanks, Thomas From david.holmes at oracle.com Fri May 10 07:34:55 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 May 2019 17:34:55 +1000 Subject: RFR (T) 8223676: Minimal VM build failure after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <0581e42b-f043-24b4-e261-f90932217dc5@redhat.com> References: <0581e42b-f043-24b4-e261-f90932217dc5@redhat.com> Message-ID: Looks good and trivial. Thanks, David On 10/05/2019 4:41 pm, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8223676 > > Please review the trivial build fix: > > diff -r 293d45e5108b src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp > --- a/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp Fri May 10 06:31:09 2019 +0100 > +++ b/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp Fri May 10 08:40:18 2019 +0200 > @@ -40,4 +40,5 @@ > #include "logging/log.hpp" > #include "memory/resourceArea.hpp" > +#include "memory/universe.hpp" > #include "oops/compiledICHolder.hpp" > #include "runtime/safepointMechanism.hpp" > > Testing: Linux x86_64 minimal build > From david.holmes at oracle.com Fri May 10 07:39:44 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 May 2019 17:39:44 +1000 Subject: RFR (T) 8223675: arm32 build failure after 8223136 (Move compressed oops functions to CompressedOops class In-Reply-To: References: Message-ID: <2ad1e8d0-7ea8-67b4-0940-4c572f4846ec@oracle.com> Hi Aleksey, I'm a bit perplexed as to how 8223136 caused this as it didn't remove any includes of universe.hpp from anywhere ??? But if it fixes it then LGTM. Cheers, David On 10/05/2019 4:45 pm, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8223675 > > Please review the trivial build fix: > > diff -r f1a8b2447250 src/hotspot/cpu/arm/c1_CodeStubs_arm.cpp > --- a/src/hotspot/cpu/arm/c1_CodeStubs_arm.cpp Fri May 10 08:40:10 2019 +0200 > +++ b/src/hotspot/cpu/arm/c1_CodeStubs_arm.cpp Fri May 10 08:45:18 2019 +0200 > @@ -30,4 +30,5 @@ > #include "c1/c1_MacroAssembler.hpp" > #include "c1/c1_Runtime1.hpp" > +#include "memory/universe.hpp" > #include "nativeInst_arm.hpp" > #include "runtime/sharedRuntime.hpp" > diff -r f1a8b2447250 src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp > --- a/src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp Fri May 10 08:40:10 2019 +0200 > +++ b/src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp Fri May 10 08:45:18 2019 +0200 > @@ -35,4 +35,5 @@ > #include "gc/shared/cardTableBarrierSet.hpp" > #include "gc/shared/collectedHeap.hpp" > +#include "memory/universe.hpp" > #include "nativeInst_arm.hpp" > #include "oops/objArrayKlass.hpp" > diff -r f1a8b2447250 src/hotspot/os_cpu/linux_arm/thread_linux_arm.cpp > --- a/src/hotspot/os_cpu/linux_arm/thread_linux_arm.cpp Fri May 10 08:40:10 2019 +0200 > +++ b/src/hotspot/os_cpu/linux_arm/thread_linux_arm.cpp Fri May 10 08:45:18 2019 +0200 > @@ -29,4 +29,5 @@ > #include "gc/shared/collectedHeap.hpp" > #include "memory/metaspaceShared.hpp" > +#include "memory/universe.hpp" > #include "runtime/frame.inline.hpp" > > Testing: Linux arm32 cross-compilation build > From shade at redhat.com Fri May 10 07:57:47 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 10 May 2019 09:57:47 +0200 Subject: RFR (T) 8223675: arm32 build failure after 8223136 (Move compressed oops functions to CompressedOops class In-Reply-To: <2ad1e8d0-7ea8-67b4-0940-4c572f4846ec@oracle.com> References: <2ad1e8d0-7ea8-67b4-0940-4c572f4846ec@oracle.com> Message-ID: <81d58ba7-c6c1-81d8-4221-37cdec7a02a2@redhat.com> On 5/10/19 9:39 AM, David Holmes wrote: > I'm a bit perplexed as to how 8223136 caused this as it didn't remove any includes of > universe.hpp from anywhere ??? Yeah. Life is short, so if compilation unit wants the identifier, let's give it! Pushed. -Aleksey From shade at redhat.com Fri May 10 07:58:08 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 10 May 2019 09:58:08 +0200 Subject: RFR (T) 8223676: Minimal VM build failure after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: References: <0581e42b-f043-24b4-e261-f90932217dc5@redhat.com> Message-ID: <754d6225-9561-604e-1652-c5e1c9b7bfb2@redhat.com> On 5/10/19 9:34 AM, David Holmes wrote: > Looks good and trivial. Thanks, pushed. -Aleksey From shade at redhat.com Fri May 10 08:27:18 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 10 May 2019 10:27:18 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8223637 Fix: http://cr.openjdk.java.net/~shade/8223637/webrev.01/ This is hopefully the last build fix to make my CI stop screaming at me. Maybe SAP folks would like to confirm this fixes builds for them? If I am not responding later, feel free to reassign and push the fix without me. Testing: cross-compile without PCH to Linux ppc64 and s390x -- Thanks, -Aleksey From stefan.karlsson at oracle.com Fri May 10 08:33:12 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 10 May 2019 10:33:12 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: References: Message-ID: <8c345341-cef0-df3c-4b83-43bb46d0a2c9@oracle.com> Looks good. FYI: We created a patch to fix this and the other platforms yesterday: https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-May/037998.html When you're done with your patching, I'll see if anything is left to push from that patch. Thanks, StefanK On 2019-05-10 10:27, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8223637 > > Fix: > http://cr.openjdk.java.net/~shade/8223637/webrev.01/ > > This is hopefully the last build fix to make my CI stop screaming at me. Maybe SAP folks would like > to confirm this fixes builds for them? If I am not responding later, feel free to reassign and push > the fix without me. > > Testing: cross-compile without PCH to Linux ppc64 and s390x > From lutz.schmidt at sap.com Fri May 10 09:08:09 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 10 May 2019 09:08:09 +0000 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <8c345341-cef0-df3c-4b83-43bb46d0a2c9@oracle.com> References: <8c345341-cef0-df3c-4b83-43bb46d0a2c9@oracle.com> Message-ID: Hi all, I'm currently collecting the changes required in addition to http://cr.openjdk.java.net/~stefank/8223637/webrev.01/ @shade: your fixes are necessary, but not sufficient. I would suggest we make Stefan's patch a superset of yours and push that. Is that ok for you? Stay tuned, I see light at the end! Lutz ?On 10.05.19, 10:33, "hotspot-dev on behalf of Stefan Karlsson" wrote: Looks good. FYI: We created a patch to fix this and the other platforms yesterday: https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-May/037998.html When you're done with your patching, I'll see if anything is left to push from that patch. Thanks, StefanK On 2019-05-10 10:27, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8223637 > > Fix: > http://cr.openjdk.java.net/~shade/8223637/webrev.01/ > > This is hopefully the last build fix to make my CI stop screaming at me. Maybe SAP folks would like > to confirm this fixes builds for them? If I am not responding later, feel free to reassign and push > the fix without me. > > Testing: cross-compile without PCH to Linux ppc64 and s390x > From matthias.baesken at sap.com Fri May 10 09:08:21 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 10 May 2019 09:08:21 +0000 Subject: 8222720: Provide extended VMWare/vSphere virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: <06d00a9c-497b-44de-f834-a0314bd0bf39@oracle.com> References: <06d00a9c-497b-44de-f834-a0314bd0bf39@oracle.com> Message-ID: Hi David, I removed / adjusted the ifdefs and added checks != NULL : http://cr.openjdk.java.net/~mbaesken/webrevs/8222720.3/ (not sure however about VMWARE Fusion on Mac, have no access to it ) Regards, Matthias > > Hi Matthias, > > On 10/05/2019 4:21 pm, Baesken, Matthias wrote: > > Hello, here is an updated version : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8222720.2/ > > > > I switched to os::dll_load / os::dll_lookup . > > Also removed the VMWare related names ( now the name is > "VirtualizationSupport" ). > > Thanks! > > src/hotspot/cpu/x86/vm_version_x86.cpp > > No ifdefs needed. > > src/hotspot/share/utilities/virtualizationSupport.cpp > > 47 #if defined(__linux) > > The common form of this is: > > #ifdef LINUX > > 62 if (GuestLib_StatGet && GuestLib_StatFree) { > > Style nit: avoid implicit booleans - test against NULL. > > --- > > Otherwise seems fine. > > Thanks, > David > ----- > > > Best regards, Matthias > > > > > >> > >> Hi David, thanks for the feedback . I'll provide an updated webrev . > >> > >>> **Not sure about the validity of using "vmware" in the name of files or > >>> classes either due to its trademark status. > >> > >> Well , we have a lot of technology names in file-names (AIX and > Windows > >> come to mind) . > >> > >> But to be on the safe side, I think I'll choose a more generic name . > >> > >> > >> Best regards, Matthias > >> > > From lutz.schmidt at sap.com Fri May 10 10:09:26 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 10 May 2019 10:09:26 +0000 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: References: <8c345341-cef0-df3c-4b83-43bb46d0a2c9@oracle.com> Message-ID: OK, builds ran fine. No tests so far, except for a "java -version". Platforms: linuxaarch64, linuxpp64le, linuxx86_64, linuxs390x, rs6000_64 Variants: fastdebug, release Linuxppc64 is still pending, my server is loaded with other stuff as well. As linuxppc64le went through smoothly, I do not expect issues to pop up. These changes need to be on top of Stefan's patch: --------------- 8< ---------------------- diff -r b0fbe518d143 src/hotspot/cpu/ppc/macroAssembler_ppc.cpp --- a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp Fri May 10 09:41:14 2019 +0200 +++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp Fri May 10 11:25:34 2019 +0200 @@ -32,7 +32,6 @@ #include "interpreter/interpreter.hpp" #include "memory/resourceArea.hpp" #include "nativeInst_ppc.hpp" -#include "oops/compressedOops.hpp" #include "prims/methodHandles.hpp" #include "runtime/biasedLocking.hpp" #include "runtime/icache.hpp" diff -r b0fbe518d143 src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp --- a/src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp Fri May 10 09:41:14 2019 +0200 +++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp Fri May 10 11:25:34 2019 +0200 @@ -33,6 +33,7 @@ #include "gc/shared/barrierSet.hpp" #include "gc/shared/barrierSetAssembler.hpp" #include "oops/accessDecorators.hpp" +#include "oops/compressedOops.hpp" #include "runtime/safepointMechanism.hpp" inline bool MacroAssembler::is_ld_largeoffset(address a) { diff -r b0fbe518d143 src/hotspot/share/adlc/main.cpp --- a/src/hotspot/share/adlc/main.cpp Fri May 10 09:41:14 2019 +0200 +++ b/src/hotspot/share/adlc/main.cpp Fri May 10 11:25:34 2019 +0200 @@ -217,6 +217,7 @@ AD.addInclude(AD._CPP_file, "code/vmreg.inline.hpp"); AD.addInclude(AD._CPP_file, "gc/shared/collectedHeap.inline.hpp"); AD.addInclude(AD._CPP_file, "oops/compiledICHolder.hpp"); + AD.addInclude(AD._CPP_file, "oops/compressedOops.hpp"); AD.addInclude(AD._CPP_file, "oops/markOop.hpp"); AD.addInclude(AD._CPP_file, "oops/method.hpp"); AD.addInclude(AD._CPP_file, "oops/oop.inline.hpp"); @@ -243,6 +244,7 @@ AD.addInclude(AD._CPP_CLONE_file, "adfiles", get_basename(AD._HPP_file._name)); AD.addInclude(AD._CPP_EXPAND_file, "precompiled.hpp"); AD.addInclude(AD._CPP_EXPAND_file, "adfiles", get_basename(AD._HPP_file._name)); + AD.addInclude(AD._CPP_EXPAND_file, "oops/compressedOops.hpp"); AD.addInclude(AD._CPP_FORMAT_file, "precompiled.hpp"); AD.addInclude(AD._CPP_FORMAT_file, "adfiles", get_basename(AD._HPP_file._name)); AD.addInclude(AD._CPP_GEN_file, "precompiled.hpp"); @@ -257,6 +259,7 @@ AD.addInclude(AD._CPP_PIPELINE_file, "adfiles", get_basename(AD._HPP_file._name)); AD.addInclude(AD._DFA_file, "precompiled.hpp"); AD.addInclude(AD._DFA_file, "adfiles", get_basename(AD._HPP_file._name)); + AD.addInclude(AD._DFA_file, "oops/compressedOops.hpp"); AD.addInclude(AD._DFA_file, "opto/cfgnode.hpp"); // Use PROB_MAX in predicate. AD.addInclude(AD._DFA_file, "opto/intrinsicnode.hpp"); AD.addInclude(AD._DFA_file, "opto/matcher.hpp"); ----------- >8 ---------------------- @Stefan, would you please proceed, extend and eventually push the patch? Thanks, Lutz ?On 10.05.19, 11:08, "Schmidt, Lutz" wrote: Hi all, I'm currently collecting the changes required in addition to http://cr.openjdk.java.net/~stefank/8223637/webrev.01/ @shade: your fixes are necessary, but not sufficient. I would suggest we make Stefan's patch a superset of yours and push that. Is that ok for you? Stay tuned, I see light at the end! Lutz On 10.05.19, 10:33, "hotspot-dev on behalf of Stefan Karlsson" wrote: Looks good. FYI: We created a patch to fix this and the other platforms yesterday: https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-May/037998.html When you're done with your patching, I'll see if anything is left to push from that patch. Thanks, StefanK On 2019-05-10 10:27, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8223637 > > Fix: > http://cr.openjdk.java.net/~shade/8223637/webrev.01/ > > This is hopefully the last build fix to make my CI stop screaming at me. Maybe SAP folks would like > to confirm this fixes builds for them? If I am not responding later, feel free to reassign and push > the fix without me. > > Testing: cross-compile without PCH to Linux ppc64 and s390x > From matthias.baesken at sap.com Fri May 10 10:15:29 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 10 May 2019 10:15:29 +0000 Subject: RFR [XS] : 8223574: add more thread-related system settings info to hs_error file on AIX In-Reply-To: References: Message-ID: Hello, Martin pointed out the same to me , here is the updated webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8223574.1/ Martin, my I add you as reviewer too ? Thanks ,Matthias > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Freitag, 10. Mai 2019 08:47 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Subject: RE: RFR [XS] : 8223574: add more thread-related system settings info > to hs_error file on AIX > > Hi Matthias, > > Thanks for doing this change, I think the information will help > to analyze out-of-threads situations. > > Why do you use three calls to print this one line? > I would prefer a single call to st->print_cr(). > Eventually you could change the "load average" code similarly. > > After pushing, could you please update the bug with what > new printout you added and a short explanation of it's > meaning/purpose? > > Don't' need to see a new webrev. > > Thanks and best regards, > Goetz. > > > -----Original Message----- > > From: hotspot-dev On Behalf > Of > > Baesken, Matthias > > Sent: Wednesday, May 8, 2019 4:24 PM > > To: 'hotspot-dev at openjdk.java.net' > > Subject: RFR [XS] : 8223574: add more thread-related system settings info > to > > hs_error file on AIX > > > > Hello , please review this small AIX related change . > > It adds to the hs_error file on AIX the maximum number of threads > within > > a process. > > > > ( The previous change > > > > https://bugs.openjdk.java.net/browse/JDK-8204598 > > > > added already more thread-related system settings info to the hs_error > file > > on Linux. > > On AIX I want to enhance the output too . ) > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8223574 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8223574.0/ > > > > > > > > Thanks, Matthias From martin.doerr at sap.com Fri May 10 10:17:10 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 10 May 2019 10:17:10 +0000 Subject: RFR [XS] : 8223574: add more thread-related system settings info to hs_error file on AIX In-Reply-To: References: Message-ID: Hi Matthias, yes. Looks good. Best regards, Martin -----Original Message----- From: Baesken, Matthias Sent: Freitag, 10. Mai 2019 12:15 To: Lindenmaier, Goetz ; 'hotspot-dev at openjdk.java.net' Cc: Doerr, Martin Subject: RE: RFR [XS] : 8223574: add more thread-related system settings info to hs_error file on AIX Hello, Martin pointed out the same to me , here is the updated webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8223574.1/ Martin, my I add you as reviewer too ? Thanks ,Matthias > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Freitag, 10. Mai 2019 08:47 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Subject: RE: RFR [XS] : 8223574: add more thread-related system settings info > to hs_error file on AIX > > Hi Matthias, > > Thanks for doing this change, I think the information will help > to analyze out-of-threads situations. > > Why do you use three calls to print this one line? > I would prefer a single call to st->print_cr(). > Eventually you could change the "load average" code similarly. > > After pushing, could you please update the bug with what > new printout you added and a short explanation of it's > meaning/purpose? > > Don't' need to see a new webrev. > > Thanks and best regards, > Goetz. > > > -----Original Message----- > > From: hotspot-dev On Behalf > Of > > Baesken, Matthias > > Sent: Wednesday, May 8, 2019 4:24 PM > > To: 'hotspot-dev at openjdk.java.net' > > Subject: RFR [XS] : 8223574: add more thread-related system settings info > to > > hs_error file on AIX > > > > Hello , please review this small AIX related change . > > It adds to the hs_error file on AIX the maximum number of threads > within > > a process. > > > > ( The previous change > > > > https://bugs.openjdk.java.net/browse/JDK-8204598 > > > > added already more thread-related system settings info to the hs_error > file > > on Linux. > > On AIX I want to enhance the output too . ) > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8223574 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8223574.0/ > > > > > > > > Thanks, Matthias From aoqi at loongson.cn Fri May 10 10:33:54 2019 From: aoqi at loongson.cn (Ao Qi) Date: Fri, 10 May 2019 18:33:54 +0800 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: References: <8c345341-cef0-df3c-4b83-43bb46d0a2c9@oracle.com> Message-ID: On Fri, May 10, 2019 at 6:09 PM Schmidt, Lutz wrote: > > OK, builds ran fine. No tests so far, except for a "java -version". > > Platforms: linuxaarch64, linuxpp64le, linuxx86_64, linuxs390x, rs6000_64 > Variants: fastdebug, release > > Linuxppc64 is still pending, my server is loaded with other stuff as well. As linuxppc64le went through smoothly, I do not expect issues to pop up. > > These changes need to be on top of Stefan's patch: > --------------- 8< ---------------------- > diff -r b0fbe518d143 src/hotspot/cpu/ppc/macroAssembler_ppc.cpp > --- a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp Fri May 10 09:41:14 2019 +0200 > +++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp Fri May 10 11:25:34 2019 +0200 > @@ -32,7 +32,6 @@ > #include "interpreter/interpreter.hpp" > #include "memory/resourceArea.hpp" > #include "nativeInst_ppc.hpp" > -#include "oops/compressedOops.hpp" > #include "prims/methodHandles.hpp" > #include "runtime/biasedLocking.hpp" > #include "runtime/icache.hpp" > diff -r b0fbe518d143 src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp > --- a/src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp Fri May 10 09:41:14 2019 +0200 > +++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp Fri May 10 11:25:34 2019 +0200 > @@ -33,6 +33,7 @@ > #include "gc/shared/barrierSet.hpp" > #include "gc/shared/barrierSetAssembler.hpp" > #include "oops/accessDecorators.hpp" > +#include "oops/compressedOops.hpp" > #include "runtime/safepointMechanism.hpp" > > inline bool MacroAssembler::is_ld_largeoffset(address a) { > diff -r b0fbe518d143 src/hotspot/share/adlc/main.cpp > --- a/src/hotspot/share/adlc/main.cpp Fri May 10 09:41:14 2019 +0200 > +++ b/src/hotspot/share/adlc/main.cpp Fri May 10 11:25:34 2019 +0200 > @@ -217,6 +217,7 @@ > AD.addInclude(AD._CPP_file, "code/vmreg.inline.hpp"); > AD.addInclude(AD._CPP_file, "gc/shared/collectedHeap.inline.hpp"); > AD.addInclude(AD._CPP_file, "oops/compiledICHolder.hpp"); > + AD.addInclude(AD._CPP_file, "oops/compressedOops.hpp"); > AD.addInclude(AD._CPP_file, "oops/markOop.hpp"); > AD.addInclude(AD._CPP_file, "oops/method.hpp"); > AD.addInclude(AD._CPP_file, "oops/oop.inline.hpp"); > @@ -243,6 +244,7 @@ > AD.addInclude(AD._CPP_CLONE_file, "adfiles", get_basename(AD._HPP_file._name)); > AD.addInclude(AD._CPP_EXPAND_file, "precompiled.hpp"); > AD.addInclude(AD._CPP_EXPAND_file, "adfiles", get_basename(AD._HPP_file._name)); > + AD.addInclude(AD._CPP_EXPAND_file, "oops/compressedOops.hpp"); > AD.addInclude(AD._CPP_FORMAT_file, "precompiled.hpp"); > AD.addInclude(AD._CPP_FORMAT_file, "adfiles", get_basename(AD._HPP_file._name)); > AD.addInclude(AD._CPP_GEN_file, "precompiled.hpp"); > @@ -257,6 +259,7 @@ > AD.addInclude(AD._CPP_PIPELINE_file, "adfiles", get_basename(AD._HPP_file._name)); > AD.addInclude(AD._DFA_file, "precompiled.hpp"); > AD.addInclude(AD._DFA_file, "adfiles", get_basename(AD._HPP_file._name)); > + AD.addInclude(AD._DFA_file, "oops/compressedOops.hpp"); > AD.addInclude(AD._DFA_file, "opto/cfgnode.hpp"); // Use PROB_MAX in predicate. > AD.addInclude(AD._DFA_file, "opto/intrinsicnode.hpp"); > AD.addInclude(AD._DFA_file, "opto/matcher.hpp"); > ----------- >8 ---------------------- Hi Lutz, I filed JDK-8223653 and I am testing the fix. I guess your patch would also fix JDK-8223653. Thanks, Ao Qi > > @Stefan, would you please proceed, extend and eventually push the patch? > > Thanks, > Lutz > > > ?On 10.05.19, 11:08, "Schmidt, Lutz" wrote: > > Hi all, > > I'm currently collecting the changes required in addition to http://cr.openjdk.java.net/~stefank/8223637/webrev.01/ > > @shade: your fixes are necessary, but not sufficient. I would suggest we make Stefan's patch a superset of yours and push that. Is that ok for you? > > Stay tuned, I see light at the end! > Lutz > > On 10.05.19, 10:33, "hotspot-dev on behalf of Stefan Karlsson" wrote: > > Looks good. > > FYI: We created a patch to fix this and the other platforms yesterday: > https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-May/037998.html > > When you're done with your patching, I'll see if anything is left to > push from that patch. > > Thanks, > StefanK > > On 2019-05-10 10:27, Aleksey Shipilev wrote: > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8223637 > > > > Fix: > > http://cr.openjdk.java.net/~shade/8223637/webrev.01/ > > > > This is hopefully the last build fix to make my CI stop screaming at me. Maybe SAP folks would like > > to confirm this fixes builds for them? If I am not responding later, feel free to reassign and push > > the fix without me. > > > > Testing: cross-compile without PCH to Linux ppc64 and s390x > > > > > > From lutz.schmidt at sap.com Fri May 10 10:42:39 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 10 May 2019 10:42:39 +0000 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: References: <8c345341-cef0-df3c-4b83-43bb46d0a2c9@oracle.com> Message-ID: <3FBF7968-0A80-4F54-B4F3-F19CC8E2D410@sap.com> Hi Ao Qi, the error pattern you documented in JDK-8223653 matches the one I saw in ppc builds (AIX and Linux). So yes, I strongly believe my patch will help your build as well. Regards, Lutz ?On 10.05.19, 12:33, "Ao Qi" wrote: On Fri, May 10, 2019 at 6:09 PM Schmidt, Lutz wrote: > > OK, builds ran fine. No tests so far, except for a "java -version". > > Platforms: linuxaarch64, linuxpp64le, linuxx86_64, linuxs390x, rs6000_64 > Variants: fastdebug, release > > Linuxppc64 is still pending, my server is loaded with other stuff as well. As linuxppc64le went through smoothly, I do not expect issues to pop up. > > These changes need to be on top of Stefan's patch: > --------------- 8< ---------------------- > diff -r b0fbe518d143 src/hotspot/cpu/ppc/macroAssembler_ppc.cpp > --- a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp Fri May 10 09:41:14 2019 +0200 > +++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp Fri May 10 11:25:34 2019 +0200 > @@ -32,7 +32,6 @@ > #include "interpreter/interpreter.hpp" > #include "memory/resourceArea.hpp" > #include "nativeInst_ppc.hpp" > -#include "oops/compressedOops.hpp" > #include "prims/methodHandles.hpp" > #include "runtime/biasedLocking.hpp" > #include "runtime/icache.hpp" > diff -r b0fbe518d143 src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp > --- a/src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp Fri May 10 09:41:14 2019 +0200 > +++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp Fri May 10 11:25:34 2019 +0200 > @@ -33,6 +33,7 @@ > #include "gc/shared/barrierSet.hpp" > #include "gc/shared/barrierSetAssembler.hpp" > #include "oops/accessDecorators.hpp" > +#include "oops/compressedOops.hpp" > #include "runtime/safepointMechanism.hpp" > > inline bool MacroAssembler::is_ld_largeoffset(address a) { > diff -r b0fbe518d143 src/hotspot/share/adlc/main.cpp > --- a/src/hotspot/share/adlc/main.cpp Fri May 10 09:41:14 2019 +0200 > +++ b/src/hotspot/share/adlc/main.cpp Fri May 10 11:25:34 2019 +0200 > @@ -217,6 +217,7 @@ > AD.addInclude(AD._CPP_file, "code/vmreg.inline.hpp"); > AD.addInclude(AD._CPP_file, "gc/shared/collectedHeap.inline.hpp"); > AD.addInclude(AD._CPP_file, "oops/compiledICHolder.hpp"); > + AD.addInclude(AD._CPP_file, "oops/compressedOops.hpp"); > AD.addInclude(AD._CPP_file, "oops/markOop.hpp"); > AD.addInclude(AD._CPP_file, "oops/method.hpp"); > AD.addInclude(AD._CPP_file, "oops/oop.inline.hpp"); > @@ -243,6 +244,7 @@ > AD.addInclude(AD._CPP_CLONE_file, "adfiles", get_basename(AD._HPP_file._name)); > AD.addInclude(AD._CPP_EXPAND_file, "precompiled.hpp"); > AD.addInclude(AD._CPP_EXPAND_file, "adfiles", get_basename(AD._HPP_file._name)); > + AD.addInclude(AD._CPP_EXPAND_file, "oops/compressedOops.hpp"); > AD.addInclude(AD._CPP_FORMAT_file, "precompiled.hpp"); > AD.addInclude(AD._CPP_FORMAT_file, "adfiles", get_basename(AD._HPP_file._name)); > AD.addInclude(AD._CPP_GEN_file, "precompiled.hpp"); > @@ -257,6 +259,7 @@ > AD.addInclude(AD._CPP_PIPELINE_file, "adfiles", get_basename(AD._HPP_file._name)); > AD.addInclude(AD._DFA_file, "precompiled.hpp"); > AD.addInclude(AD._DFA_file, "adfiles", get_basename(AD._HPP_file._name)); > + AD.addInclude(AD._DFA_file, "oops/compressedOops.hpp"); > AD.addInclude(AD._DFA_file, "opto/cfgnode.hpp"); // Use PROB_MAX in predicate. > AD.addInclude(AD._DFA_file, "opto/intrinsicnode.hpp"); > AD.addInclude(AD._DFA_file, "opto/matcher.hpp"); > ----------- >8 ---------------------- Hi Lutz, I filed JDK-8223653 and I am testing the fix. I guess your patch would also fix JDK-8223653. Thanks, Ao Qi > > @Stefan, would you please proceed, extend and eventually push the patch? > > Thanks, > Lutz > > > On 10.05.19, 11:08, "Schmidt, Lutz" wrote: > > Hi all, > > I'm currently collecting the changes required in addition to http://cr.openjdk.java.net/~stefank/8223637/webrev.01/ > > @shade: your fixes are necessary, but not sufficient. I would suggest we make Stefan's patch a superset of yours and push that. Is that ok for you? > > Stay tuned, I see light at the end! > Lutz > > On 10.05.19, 10:33, "hotspot-dev on behalf of Stefan Karlsson" wrote: > > Looks good. > > FYI: We created a patch to fix this and the other platforms yesterday: > https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-May/037998.html > > When you're done with your patching, I'll see if anything is left to > push from that patch. > > Thanks, > StefanK > > On 2019-05-10 10:27, Aleksey Shipilev wrote: > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8223637 > > > > Fix: > > http://cr.openjdk.java.net/~shade/8223637/webrev.01/ > > > > This is hopefully the last build fix to make my CI stop screaming at me. Maybe SAP folks would like > > to confirm this fixes builds for them? If I am not responding later, feel free to reassign and push > > the fix without me. > > > > Testing: cross-compile without PCH to Linux ppc64 and s390x > > > > > > From glaubitz at physik.fu-berlin.de Fri May 10 11:01:22 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 10 May 2019 13:01:22 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: References: Message-ID: <6de9c394-131c-2f81-6a21-70ca72285bd3@physik.fu-berlin.de> Hi! On 5/10/19 10:27 AM, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8223637 > > Fix: > http://cr.openjdk.java.net/~shade/8223637/webrev.01/ This affects linux-sparc (native Hotspot), too. Applying a similar fix doesn't work so far: glaubitz at gcc202:~/jdk$ hg diff diff -r 45bbef01a6ae src/hotspot/cpu/sparc/c1_LIRAssembler_sparc.cpp --- a/src/hotspot/cpu/sparc/c1_LIRAssembler_sparc.cpp Fri May 10 09:56:20 2019 +0200 +++ b/src/hotspot/cpu/sparc/c1_LIRAssembler_sparc.cpp Fri May 10 13:59:13 2019 +0300 @@ -34,7 +34,9 @@ #include "gc/shared/barrierSet.hpp" #include "gc/shared/cardTableBarrierSet.hpp" #include "gc/shared/collectedHeap.hpp" +#include "memory/universe.hpp" #include "nativeInst_sparc.hpp" +#include "oops/compressedOops.hpp" #include "oops/objArrayKlass.hpp" #include "runtime/frame.inline.hpp" #include "runtime/interfaceSupport.inline.hpp" diff -r 45bbef01a6ae src/hotspot/cpu/sparc/macroAssembler_sparc.inline.hpp --- a/src/hotspot/cpu/sparc/macroAssembler_sparc.inline.hpp Fri May 10 09:56:20 2019 +0200 +++ b/src/hotspot/cpu/sparc/macroAssembler_sparc.inline.hpp Fri May 10 13:59:13 2019 +0300 @@ -28,6 +28,7 @@ #include "asm/assembler.inline.hpp" #include "asm/macroAssembler.hpp" #include "asm/codeBuffer.hpp" +#include "oops/compressedOops.hpp" #include "code/codeCache.hpp" inline bool Address::is_simm13(int offset) { return Assembler::is_simm13(disp() + offset); } glaubitz at gcc202:~/jdk$ Still fails with: === Output from failing command(s) repeated here === /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc.o:\n" * For target hotspot_variant-server_libjvm_objs_ad_sparc.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc.o.log || true) | /usr/bin/head -n 12 In file included from ad_sparc.cpp:29: ad_sparc.hpp: In member function ?virtual int encodeHeapOopNode::ins_avoid_back_to_back() const?: ad_sparc.hpp:7247:66: error: ?CompressedOops? has not been declared ad_sparc.hpp: In constructor ?encodeHeapOopNode::encodeHeapOopNode()?: ad_sparc.hpp:7252:76: error: ?CompressedOops? has not been declared if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi /usr/bin/printf "\n* All command lines available in /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs.\n" * All command lines available in /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs. /usr/bin/printf "=== End of repeated output ===\n" === End of repeated output === Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From lutz.schmidt at sap.com Fri May 10 11:07:49 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 10 May 2019 11:07:49 +0000 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <6de9c394-131c-2f81-6a21-70ca72285bd3@physik.fu-berlin.de> References: <6de9c394-131c-2f81-6a21-70ca72285bd3@physik.fu-berlin.de> Message-ID: Hi, you may want to try the additional changes I suggested in my response at 12:09pm (CET). Regards, Lutz ?On 10.05.19, 13:01, "hotspot-dev on behalf of John Paul Adrian Glaubitz" wrote: Hi! On 5/10/19 10:27 AM, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8223637 > > Fix: > http://cr.openjdk.java.net/~shade/8223637/webrev.01/ This affects linux-sparc (native Hotspot), too. Applying a similar fix doesn't work so far: glaubitz at gcc202:~/jdk$ hg diff diff -r 45bbef01a6ae src/hotspot/cpu/sparc/c1_LIRAssembler_sparc.cpp --- a/src/hotspot/cpu/sparc/c1_LIRAssembler_sparc.cpp Fri May 10 09:56:20 2019 +0200 +++ b/src/hotspot/cpu/sparc/c1_LIRAssembler_sparc.cpp Fri May 10 13:59:13 2019 +0300 @@ -34,7 +34,9 @@ #include "gc/shared/barrierSet.hpp" #include "gc/shared/cardTableBarrierSet.hpp" #include "gc/shared/collectedHeap.hpp" +#include "memory/universe.hpp" #include "nativeInst_sparc.hpp" +#include "oops/compressedOops.hpp" #include "oops/objArrayKlass.hpp" #include "runtime/frame.inline.hpp" #include "runtime/interfaceSupport.inline.hpp" diff -r 45bbef01a6ae src/hotspot/cpu/sparc/macroAssembler_sparc.inline.hpp --- a/src/hotspot/cpu/sparc/macroAssembler_sparc.inline.hpp Fri May 10 09:56:20 2019 +0200 +++ b/src/hotspot/cpu/sparc/macroAssembler_sparc.inline.hpp Fri May 10 13:59:13 2019 +0300 @@ -28,6 +28,7 @@ #include "asm/assembler.inline.hpp" #include "asm/macroAssembler.hpp" #include "asm/codeBuffer.hpp" +#include "oops/compressedOops.hpp" #include "code/codeCache.hpp" inline bool Address::is_simm13(int offset) { return Assembler::is_simm13(disp() + offset); } glaubitz at gcc202:~/jdk$ Still fails with: === Output from failing command(s) repeated here === /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc.o:\n" * For target hotspot_variant-server_libjvm_objs_ad_sparc.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc.o.log || true) | /usr/bin/head -n 12 In file included from ad_sparc.cpp:29: ad_sparc.hpp: In member function ?virtual int encodeHeapOopNode::ins_avoid_back_to_back() const?: ad_sparc.hpp:7247:66: error: ?CompressedOops? has not been declared ad_sparc.hpp: In constructor ?encodeHeapOopNode::encodeHeapOopNode()?: ad_sparc.hpp:7252:76: error: ?CompressedOops? has not been declared if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi /usr/bin/printf "\n* All command lines available in /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs.\n" * All command lines available in /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs. /usr/bin/printf "=== End of repeated output ===\n" === End of repeated output === Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Fri May 10 11:16:16 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 10 May 2019 13:16:16 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: References: <6de9c394-131c-2f81-6a21-70ca72285bd3@physik.fu-berlin.de> Message-ID: <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> Hi! On 5/10/19 1:07 PM, Schmidt, Lutz wrote: > you may want to try the additional changes I suggested in my response at 12:09pm (CET). Okay, I now have: diff -r 45bbef01a6ae src/hotspot/cpu/sparc/c1_CodeStubs_sparc.cpp --- a/src/hotspot/cpu/sparc/c1_CodeStubs_sparc.cpp Fri May 10 09:56:20 2019 +0200 +++ b/src/hotspot/cpu/sparc/c1_CodeStubs_sparc.cpp Fri May 10 14:13:29 2019 +0300 @@ -29,6 +29,7 @@ #include "c1/c1_LIRAssembler.hpp" #include "c1/c1_MacroAssembler.hpp" #include "c1/c1_Runtime1.hpp" +#include "memory/universe.hpp" #include "nativeInst_sparc.hpp" #include "runtime/sharedRuntime.hpp" #include "utilities/macros.hpp" diff -r 45bbef01a6ae src/hotspot/cpu/sparc/c1_LIRAssembler_sparc.cpp --- a/src/hotspot/cpu/sparc/c1_LIRAssembler_sparc.cpp Fri May 10 09:56:20 2019 +0200 +++ b/src/hotspot/cpu/sparc/c1_LIRAssembler_sparc.cpp Fri May 10 14:13:29 2019 +0300 @@ -34,6 +34,7 @@ #include "gc/shared/barrierSet.hpp" #include "gc/shared/cardTableBarrierSet.hpp" #include "gc/shared/collectedHeap.hpp" +#include "memory/universe.hpp" #include "nativeInst_sparc.hpp" #include "oops/objArrayKlass.hpp" #include "runtime/frame.inline.hpp" diff -r 45bbef01a6ae src/hotspot/cpu/sparc/macroAssembler_sparc.inline.hpp --- a/src/hotspot/cpu/sparc/macroAssembler_sparc.inline.hpp Fri May 10 09:56:20 2019 +0200 +++ b/src/hotspot/cpu/sparc/macroAssembler_sparc.inline.hpp Fri May 10 14:13:29 2019 +0300 @@ -29,6 +29,7 @@ #include "asm/macroAssembler.hpp" #include "asm/codeBuffer.hpp" #include "code/codeCache.hpp" +#include "oops/compressedOops.hpp" inline bool Address::is_simm13(int offset) { return Assembler::is_simm13(disp() + offset); } diff -r 45bbef01a6ae src/hotspot/os_cpu/linux_sparc/thread_linux_sparc.cpp --- a/src/hotspot/os_cpu/linux_sparc/thread_linux_sparc.cpp Fri May 10 09:56:20 2019 +0200 +++ b/src/hotspot/os_cpu/linux_sparc/thread_linux_sparc.cpp Fri May 10 14:13:29 2019 +0300 @@ -24,6 +24,7 @@ #include "precompiled.hpp" #include "memory/metaspaceShared.hpp" +#include "memory/universe.hpp" #include "runtime/frame.inline.hpp" #include "runtime/thread.inline.hpp" diff -r 45bbef01a6ae src/hotspot/share/adlc/main.cpp --- a/src/hotspot/share/adlc/main.cpp Fri May 10 09:56:20 2019 +0200 +++ b/src/hotspot/share/adlc/main.cpp Fri May 10 14:13:29 2019 +0300 @@ -217,6 +217,7 @@ AD.addInclude(AD._CPP_file, "code/vmreg.inline.hpp"); AD.addInclude(AD._CPP_file, "gc/shared/collectedHeap.inline.hpp"); AD.addInclude(AD._CPP_file, "oops/compiledICHolder.hpp"); + AD.addInclude(AD._CPP_file, "oops/compressedOops.hpp"); AD.addInclude(AD._CPP_file, "oops/markOop.hpp"); AD.addInclude(AD._CPP_file, "oops/method.hpp"); AD.addInclude(AD._CPP_file, "oops/oop.inline.hpp"); @@ -239,6 +240,7 @@ AD.addInclude(AD._HPP_file, "opto/regalloc.hpp"); AD.addInclude(AD._HPP_file, "opto/subnode.hpp"); AD.addInclude(AD._HPP_file, "opto/vectornode.hpp"); + AD.addInclude(AD._CPP_EXPAND_file, "oops/compressedOops.hpp"); AD.addInclude(AD._CPP_CLONE_file, "precompiled.hpp"); AD.addInclude(AD._CPP_CLONE_file, "adfiles", get_basename(AD._HPP_file._name)); AD.addInclude(AD._CPP_EXPAND_file, "precompiled.hpp"); @@ -257,6 +259,7 @@ AD.addInclude(AD._CPP_PIPELINE_file, "adfiles", get_basename(AD._HPP_file._name)); AD.addInclude(AD._DFA_file, "precompiled.hpp"); AD.addInclude(AD._DFA_file, "adfiles", get_basename(AD._HPP_file._name)); + AD.addInclude(AD._DFA_file, "oops/compressedOops.hpp"); AD.addInclude(AD._DFA_file, "opto/cfgnode.hpp"); // Use PROB_MAX in predicate. AD.addInclude(AD._DFA_file, "opto/intrinsicnode.hpp"); AD.addInclude(AD._DFA_file, "opto/matcher.hpp"); glaubitz at gcc202:~/jdk$ But I still get: make[3]: *** [lib/CompileJvm.gmk:177: /home/glaubitz/jdk/build/linux-sparcv9-server-release/hotspot/variant-server/libjvm/objs/ad_sparc_expand.o] Error 1 make[3]: *** Waiting for unfinished jobs.... /bin/sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$//' -e 's/^[ ]*//' -e '/^$/ d' -e 's/$/ :/' /home/glaubitz/jdk/build/linux-sparcv9-server-release/hotspot/variant-server/libjvm/objs/annotations.d > /home/glaubitz/jdk/build/linux-sparcv9-server-release/hotspot/variant-server/libjvm/objs/annotations.d.targets In file included from ad_sparc.cpp:29: ad_sparc.hpp: In member function ?virtual int encodeHeapOopNode::ins_avoid_back_to_back() const?: ad_sparc.hpp:7247:66: error: ?CompressedOops? has not been declared ad_sparc.hpp: In constructor ?encodeHeapOopNode::encodeHeapOopNode()?: ad_sparc.hpp:7252:76: error: ?CompressedOops? has not been declared /bin/sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$//' -e 's/^[ ]*//' -e '/^$/ d' -e 's/$/ :/' /home/glaubitz/jdk/build/linux-sparcv9-server-release/hotspot/variant-server/libjvm/objs/arena.d > /home/glaubitz/jdk/build/linux-sparcv9-server-release/hotspot/variant-server/libjvm/objs/arena.d.targets /bin/sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$//' -e 's/^[ ]*//' -e '/^$/ d' -e 's/$/ :/' /home/glaubitz/jdk/build/linux-sparcv9-server-release/hotspot/variant-server/libjvm/objs/accessBackend.d > /home/glaubitz/jdk/build/linux-sparcv9-server-release/hotspot/variant-server/libjvm/objs/accessBackend.d.targets In file included from ad_sparc_pipeline.cpp:28: ad_sparc.hpp: In member function ?virtual int encodeHeapOopNode::ins_avoid_back_to_back() const?: ad_sparc.hpp:7247:66: error: ?CompressedOops? has not been declared ad_sparc.hpp: In constructor ?encodeHeapOopNode::encodeHeapOopNode()?: ad_sparc.hpp:7252:76: error: ?CompressedOops? has not been declared Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Fri May 10 11:23:26 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 10 May 2019 13:23:26 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> References: <6de9c394-131c-2f81-6a21-70ca72285bd3@physik.fu-berlin.de> <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> Message-ID: On 5/10/19 1:16 PM, John Paul Adrian Glaubitz wrote: > But I still get: > > make[3]: *** [lib/CompileJvm.gmk:177: /home/glaubitz/jdk/build/linux-sparcv9-server-release/hotspot/variant-server/libjvm/objs/ad_sparc_expand.o] Error 1 > make[3]: *** Waiting for unfinished jobs.... > /bin/sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$//' -e 's/^[ ]*//' -e '/^$/ d' -e 's/$/ :/' /home/glaubitz/jdk/build/linux-sparcv9-server-release/hotspot/variant-server/libjvm/objs/annotations.d > /home/glaubitz/jdk/build/linux-sparcv9-server-release/hotspot/variant-server/libjvm/objs/annotations.d.targets > In file included from ad_sparc.cpp:29: > ad_sparc.hpp: In member function ?virtual int encodeHeapOopNode::ins_avoid_back_to_back() const?: > ad_sparc.hpp:7247:66: error: ?CompressedOops? has not been declared > ad_sparc.hpp: In constructor ?encodeHeapOopNode::encodeHeapOopNode()?: > ad_sparc.hpp:7252:76: error: ?CompressedOops? has not been declared > /bin/sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$//' -e 's/^[ ]*//' -e '/^$/ d' -e 's/$/ :/' /home/glaubitz/jdk/build/linux-sparcv9-server-release/hotspot/variant-server/libjvm/objs/arena.d > /home/glaubitz/jdk/build/linux-sparcv9-server-release/hotspot/variant-server/libjvm/objs/arena.d.targets > /bin/sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$//' -e 's/^[ ]*//' -e '/^$/ d' -e 's/$/ :/' /home/glaubitz/jdk/build/linux-sparcv9-server-release/hotspot/variant-server/libjvm/objs/accessBackend.d > /home/glaubitz/jdk/build/linux-sparcv9-server-release/hotspot/variant-server/libjvm/objs/accessBackend.d.targets > In file included from ad_sparc_pipeline.cpp:28: > ad_sparc.hpp: In member function ?virtual int encodeHeapOopNode::ins_avoid_back_to_back() const?: > ad_sparc.hpp:7247:66: error: ?CompressedOops? has not been declared > ad_sparc.hpp: In constructor ?encodeHeapOopNode::encodeHeapOopNode()?: > ad_sparc.hpp:7252:76: error: ?CompressedOops? has not been declared If we can't figure it out now, I will try to debug it over the weekend. I'm a bit lazy today as it's already Friday :). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From stefan.karlsson at oracle.com Fri May 10 11:23:35 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 10 May 2019 13:23:35 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> References: <6de9c394-131c-2f81-6a21-70ca72285bd3@physik.fu-berlin.de> <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> Message-ID: <57268061-c441-214f-83fd-baf5dfec3869@oracle.com> On 2019-05-10 13:16, John Paul Adrian Glaubitz wrote: > Hi! > > On 5/10/19 1:07 PM, Schmidt, Lutz wrote: >> you may want to try the additional changes I suggested in my response at 12:09pm (CET). > Okay, I now have: > > diff -r 45bbef01a6ae src/hotspot/cpu/sparc/c1_CodeStubs_sparc.cpp > --- a/src/hotspot/cpu/sparc/c1_CodeStubs_sparc.cpp Fri May 10 09:56:20 2019 +0200 > +++ b/src/hotspot/cpu/sparc/c1_CodeStubs_sparc.cpp Fri May 10 14:13:29 2019 +0300 > @@ -29,6 +29,7 @@ > #include "c1/c1_LIRAssembler.hpp" > #include "c1/c1_MacroAssembler.hpp" > #include "c1/c1_Runtime1.hpp" > +#include "memory/universe.hpp" > #include "nativeInst_sparc.hpp" > #include "runtime/sharedRuntime.hpp" > #include "utilities/macros.hpp" > diff -r 45bbef01a6ae src/hotspot/cpu/sparc/c1_LIRAssembler_sparc.cpp > --- a/src/hotspot/cpu/sparc/c1_LIRAssembler_sparc.cpp Fri May 10 09:56:20 2019 +0200 > +++ b/src/hotspot/cpu/sparc/c1_LIRAssembler_sparc.cpp Fri May 10 14:13:29 2019 +0300 > @@ -34,6 +34,7 @@ > #include "gc/shared/barrierSet.hpp" > #include "gc/shared/cardTableBarrierSet.hpp" > #include "gc/shared/collectedHeap.hpp" > +#include "memory/universe.hpp" > #include "nativeInst_sparc.hpp" > #include "oops/objArrayKlass.hpp" > #include "runtime/frame.inline.hpp" > diff -r 45bbef01a6ae src/hotspot/cpu/sparc/macroAssembler_sparc.inline.hpp > --- a/src/hotspot/cpu/sparc/macroAssembler_sparc.inline.hpp Fri May 10 09:56:20 2019 +0200 > +++ b/src/hotspot/cpu/sparc/macroAssembler_sparc.inline.hpp Fri May 10 14:13:29 2019 +0300 > @@ -29,6 +29,7 @@ > #include "asm/macroAssembler.hpp" > #include "asm/codeBuffer.hpp" > #include "code/codeCache.hpp" > +#include "oops/compressedOops.hpp" > > inline bool Address::is_simm13(int offset) { return Assembler::is_simm13(disp() + offset); } > > diff -r 45bbef01a6ae src/hotspot/os_cpu/linux_sparc/thread_linux_sparc.cpp > --- a/src/hotspot/os_cpu/linux_sparc/thread_linux_sparc.cpp Fri May 10 09:56:20 2019 +0200 > +++ b/src/hotspot/os_cpu/linux_sparc/thread_linux_sparc.cpp Fri May 10 14:13:29 2019 +0300 > @@ -24,6 +24,7 @@ > > #include "precompiled.hpp" > #include "memory/metaspaceShared.hpp" > +#include "memory/universe.hpp" > #include "runtime/frame.inline.hpp" > #include "runtime/thread.inline.hpp" > > diff -r 45bbef01a6ae src/hotspot/share/adlc/main.cpp > --- a/src/hotspot/share/adlc/main.cpp Fri May 10 09:56:20 2019 +0200 > +++ b/src/hotspot/share/adlc/main.cpp Fri May 10 14:13:29 2019 +0300 > @@ -217,6 +217,7 @@ > AD.addInclude(AD._CPP_file, "code/vmreg.inline.hpp"); > AD.addInclude(AD._CPP_file, "gc/shared/collectedHeap.inline.hpp"); > AD.addInclude(AD._CPP_file, "oops/compiledICHolder.hpp"); > + AD.addInclude(AD._CPP_file, "oops/compressedOops.hpp"); > AD.addInclude(AD._CPP_file, "oops/markOop.hpp"); > AD.addInclude(AD._CPP_file, "oops/method.hpp"); > AD.addInclude(AD._CPP_file, "oops/oop.inline.hpp"); > @@ -239,6 +240,7 @@ > AD.addInclude(AD._HPP_file, "opto/regalloc.hpp"); > AD.addInclude(AD._HPP_file, "opto/subnode.hpp"); > AD.addInclude(AD._HPP_file, "opto/vectornode.hpp"); > + AD.addInclude(AD._CPP_EXPAND_file, "oops/compressedOops.hpp"); > AD.addInclude(AD._CPP_CLONE_file, "precompiled.hpp"); > AD.addInclude(AD._CPP_CLONE_file, "adfiles", get_basename(AD._HPP_file._name)); > AD.addInclude(AD._CPP_EXPAND_file, "precompiled.hpp"); > @@ -257,6 +259,7 @@ > AD.addInclude(AD._CPP_PIPELINE_file, "adfiles", get_basename(AD._HPP_file._name)); > AD.addInclude(AD._DFA_file, "precompiled.hpp"); > AD.addInclude(AD._DFA_file, "adfiles", get_basename(AD._HPP_file._name)); > + AD.addInclude(AD._DFA_file, "oops/compressedOops.hpp"); > AD.addInclude(AD._DFA_file, "opto/cfgnode.hpp"); // Use PROB_MAX in predicate. > AD.addInclude(AD._DFA_file, "opto/intrinsicnode.hpp"); > AD.addInclude(AD._DFA_file, "opto/matcher.hpp"); > glaubitz at gcc202:~/jdk$ > > But I still get: > > make[3]: *** [lib/CompileJvm.gmk:177: /home/glaubitz/jdk/build/linux-sparcv9-server-release/hotspot/variant-server/libjvm/objs/ad_sparc_expand.o] Error 1 > make[3]: *** Waiting for unfinished jobs.... > /bin/sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$//' -e 's/^[ ]*//' -e '/^$/ d' -e 's/$/ :/' /home/glaubitz/jdk/build/linux-sparcv9-server-release/hotspot/variant-server/libjvm/objs/annotations.d > /home/glaubitz/jdk/build/linux-sparcv9-server-release/hotspot/variant-server/libjvm/objs/annotations.d.targets > In file included from ad_sparc.cpp:29: > ad_sparc.hpp: In member function ?virtual int encodeHeapOopNode::ins_avoid_back_to_back() const?: > ad_sparc.hpp:7247:66: error: ?CompressedOops? has not been declared > ad_sparc.hpp: In constructor ?encodeHeapOopNode::encodeHeapOopNode()?: > ad_sparc.hpp:7252:76: error: ?CompressedOops? has not been declared > /bin/sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$//' -e 's/^[ ]*//' -e '/^$/ d' -e 's/$/ :/' /home/glaubitz/jdk/build/linux-sparcv9-server-release/hotspot/variant-server/libjvm/objs/arena.d > /home/glaubitz/jdk/build/linux-sparcv9-server-release/hotspot/variant-server/libjvm/objs/arena.d.targets > /bin/sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$//' -e 's/^[ ]*//' -e '/^$/ d' -e 's/$/ :/' /home/glaubitz/jdk/build/linux-sparcv9-server-release/hotspot/variant-server/libjvm/objs/accessBackend.d > /home/glaubitz/jdk/build/linux-sparcv9-server-release/hotspot/variant-server/libjvm/objs/accessBackend.d.targets > In file included from ad_sparc_pipeline.cpp:28: > ad_sparc.hpp: In member function ?virtual int encodeHeapOopNode::ins_avoid_back_to_back() const?: > ad_sparc.hpp:7247:66: error: ?CompressedOops? has not been declared > ad_sparc.hpp: In constructor ?encodeHeapOopNode::encodeHeapOopNode()?: > ad_sparc.hpp:7252:76: error: ?CompressedOops? has not been declared Do you need a line for the AD.__HPP_file ? AD.addInclude(AD._HPP_file, "oops/compressedOops.hpp"); StefanK > > Adrian > From glaubitz at physik.fu-berlin.de Fri May 10 11:31:49 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 10 May 2019 13:31:49 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <57268061-c441-214f-83fd-baf5dfec3869@oracle.com> References: <6de9c394-131c-2f81-6a21-70ca72285bd3@physik.fu-berlin.de> <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> <57268061-c441-214f-83fd-baf5dfec3869@oracle.com> Message-ID: On 5/10/19 1:23 PM, Stefan Karlsson wrote: > Do you need a line for the AD.__HPP_file ? > > ?? AD.addInclude(AD._HPP_file, "oops/compressedOops.hpp"); Yes, getting further now: === Output from failing command(s) repeated here === /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc.o:\n" * For target hotspot_variant-server_libjvm_objs_ad_sparc.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc.o.log || true) | /usr/bin/head -n 12 In file included from ad_sparc.hpp:32, from ad_sparc.cpp:29: /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:23: error: ?oop? has not been declared static bool is_null(oop v) { return v == NULL; } ^~~ /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:23: error: ?narrowOop? has not been declared static bool is_null(narrowOop v) { return v == 0; } ^~~~~~~~~ /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:15: error: ?static bool CompressedOops::is_null(int)? cannot be overloaded with ?static bool CompressedOops::is_null(int)? static bool is_null(narrowOop v) { return v == 0; } ^~~~~~~ /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:15: note: previous declaration ?static bool CompressedOops::is_null(int)? if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi ... (rest of output omitted) /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc_clone.o:\n" * For target hotspot_variant-server_libjvm_objs_ad_sparc_clone.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_clone.o.log || true) | /usr/bin/head -n 12 In file included from ad_sparc.hpp:32, from ad_sparc_clone.cpp:28: /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:23: error: ?oop? has not been declared static bool is_null(oop v) { return v == NULL; } ^~~ /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:23: error: ?narrowOop? has not been declared static bool is_null(narrowOop v) { return v == 0; } ^~~~~~~~~ /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:15: error: ?static bool CompressedOops::is_null(int)? cannot be overloaded with ?static bool CompressedOops::is_null(int)? static bool is_null(narrowOop v) { return v == 0; } ^~~~~~~ /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:15: note: previous declaration ?static bool CompressedOops::is_null(int)? if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_clone.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi ... (rest of output omitted) /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc_expand.o:\n" * For target hotspot_variant-server_libjvm_objs_ad_sparc_expand.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_expand.o.log || true) | /usr/bin/head -n 12 In file included from ad_sparc_expand.cpp:27: /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:23: error: ?oop? has not been declared static bool is_null(oop v) { return v == NULL; } ^~~ /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:23: error: ?narrowOop? has not been declared static bool is_null(narrowOop v) { return v == 0; } ^~~~~~~~~ /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:15: error: ?static bool CompressedOops::is_null(int)? cannot be overloaded with ?static bool CompressedOops::is_null(int)? static bool is_null(narrowOop v) { return v == 0; } ^~~~~~~ /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:15: note: previous declaration ?static bool CompressedOops::is_null(int)? static bool is_null(oop v) { return v == NULL; } if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_expand.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi ... (rest of output omitted) /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc_format.o:\n" * For target hotspot_variant-server_libjvm_objs_ad_sparc_format.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_format.o.log || true) | /usr/bin/head -n 12 In file included from ad_sparc.hpp:32, from ad_sparc_format.cpp:28: /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:23: error: ?oop? has not been declared static bool is_null(oop v) { return v == NULL; } ^~~ /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:23: error: ?narrowOop? has not been declared static bool is_null(narrowOop v) { return v == 0; } ^~~~~~~~~ /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:15: error: ?static bool CompressedOops::is_null(int)? cannot be overloaded with ?static bool CompressedOops::is_null(int)? static bool is_null(narrowOop v) { return v == 0; } ^~~~~~~ /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:15: note: previous declaration ?static bool CompressedOops::is_null(int)? if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_format.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi ... (rest of output omitted) /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc_gen.o:\n" * For target hotspot_variant-server_libjvm_objs_ad_sparc_gen.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_gen.o.log || true) | /usr/bin/head -n 12 In file included from ad_sparc.hpp:32, from ad_sparc_gen.cpp:28: /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:23: error: ?oop? has not been declared static bool is_null(oop v) { return v == NULL; } ^~~ /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:23: error: ?narrowOop? has not been declared static bool is_null(narrowOop v) { return v == 0; } ^~~~~~~~~ /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:15: error: ?static bool CompressedOops::is_null(int)? cannot be overloaded with ?static bool CompressedOops::is_null(int)? static bool is_null(narrowOop v) { return v == 0; } ^~~~~~~ /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:15: note: previous declaration ?static bool CompressedOops::is_null(int)? if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_gen.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi ... (rest of output omitted) /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc_misc.o:\n" * For target hotspot_variant-server_libjvm_objs_ad_sparc_misc.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_misc.o.log || true) | /usr/bin/head -n 12 In file included from ad_sparc.hpp:32, from ad_sparc_misc.cpp:28: /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:23: error: ?oop? has not been declared static bool is_null(oop v) { return v == NULL; } ^~~ /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:23: error: ?narrowOop? has not been declared static bool is_null(narrowOop v) { return v == 0; } ^~~~~~~~~ /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:15: error: ?static bool CompressedOops::is_null(int)? cannot be overloaded with ?static bool CompressedOops::is_null(int)? static bool is_null(narrowOop v) { return v == 0; } ^~~~~~~ /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:15: note: previous declaration ?static bool CompressedOops::is_null(int)? if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_misc.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi ... (rest of output omitted) /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc_peephole.o:\n" * For target hotspot_variant-server_libjvm_objs_ad_sparc_peephole.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_peephole.o.log || true) | /usr/bin/head -n 12 In file included from ad_sparc.hpp:32, from ad_sparc_peephole.cpp:28: /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:23: error: ?oop? has not been declared static bool is_null(oop v) { return v == NULL; } ^~~ /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:23: error: ?narrowOop? has not been declared static bool is_null(narrowOop v) { return v == 0; } ^~~~~~~~~ /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:15: error: ?static bool CompressedOops::is_null(int)? cannot be overloaded with ?static bool CompressedOops::is_null(int)? static bool is_null(narrowOop v) { return v == 0; } ^~~~~~~ /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:15: note: previous declaration ?static bool CompressedOops::is_null(int)? if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_peephole.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi ... (rest of output omitted) /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc_pipeline.o:\n" * For target hotspot_variant-server_libjvm_objs_ad_sparc_pipeline.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_pipeline.o.log || true) | /usr/bin/head -n 12 In file included from ad_sparc.hpp:32, from ad_sparc_pipeline.cpp:28: /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:23: error: ?oop? has not been declared static bool is_null(oop v) { return v == NULL; } ^~~ /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:23: error: ?narrowOop? has not been declared static bool is_null(narrowOop v) { return v == 0; } ^~~~~~~~~ /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:15: error: ?static bool CompressedOops::is_null(int)? cannot be overloaded with ?static bool CompressedOops::is_null(int)? static bool is_null(narrowOop v) { return v == 0; } ^~~~~~~ /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:15: note: previous declaration ?static bool CompressedOops::is_null(int)? if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_pipeline.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi ... (rest of output omitted) /usr/bin/printf "\n* All command lines available in /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs.\n" * All command lines available in /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs. /usr/bin/printf "=== End of repeated output ===\n" === End of repeated output === -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From stefan.karlsson at oracle.com Fri May 10 11:34:27 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 10 May 2019 13:34:27 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: References: <6de9c394-131c-2f81-6a21-70ca72285bd3@physik.fu-berlin.de> <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> <57268061-c441-214f-83fd-baf5dfec3869@oracle.com> Message-ID: On 2019-05-10 13:31, John Paul Adrian Glaubitz wrote: > On 5/10/19 1:23 PM, Stefan Karlsson wrote: >> Do you need a line for the AD.__HPP_file ? >> >> ?? AD.addInclude(AD._HPP_file, "oops/compressedOops.hpp"); > > Yes, getting further now: This needs an: #include "oops/oopsHierarchy.hpp" in compressedOops.hpp StefanK > > === Output from failing command(s) repeated here === > /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc.o:\n" > * For target hotspot_variant-server_libjvm_objs_ad_sparc.o: > (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc.o.log || true) | /usr/bin/head -n 12 > In file included from ad_sparc.hpp:32, > from ad_sparc.cpp:29: > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:23: error: ?oop? has not been declared > static bool is_null(oop v) { return v == NULL; } > ^~~ > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:23: error: ?narrowOop? has not been declared > static bool is_null(narrowOop v) { return v == 0; } > ^~~~~~~~~ > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:15: error: ?static bool CompressedOops::is_null(int)? cannot be overloaded with ?static bool CompressedOops::is_null(int)? > static bool is_null(narrowOop v) { return v == 0; } > ^~~~~~~ > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:15: note: previous declaration ?static bool CompressedOops::is_null(int)? > if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi > ... (rest of output omitted) > /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc_clone.o:\n" > * For target hotspot_variant-server_libjvm_objs_ad_sparc_clone.o: > (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_clone.o.log || true) | /usr/bin/head -n 12 > In file included from ad_sparc.hpp:32, > from ad_sparc_clone.cpp:28: > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:23: error: ?oop? has not been declared > static bool is_null(oop v) { return v == NULL; } > ^~~ > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:23: error: ?narrowOop? has not been declared > static bool is_null(narrowOop v) { return v == 0; } > ^~~~~~~~~ > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:15: error: ?static bool CompressedOops::is_null(int)? cannot be overloaded with ?static bool CompressedOops::is_null(int)? > static bool is_null(narrowOop v) { return v == 0; } > ^~~~~~~ > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:15: note: previous declaration ?static bool CompressedOops::is_null(int)? > if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_clone.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi > ... (rest of output omitted) > /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc_expand.o:\n" > * For target hotspot_variant-server_libjvm_objs_ad_sparc_expand.o: > (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_expand.o.log || true) | /usr/bin/head -n 12 > In file included from ad_sparc_expand.cpp:27: > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:23: error: ?oop? has not been declared > static bool is_null(oop v) { return v == NULL; } > ^~~ > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:23: error: ?narrowOop? has not been declared > static bool is_null(narrowOop v) { return v == 0; } > ^~~~~~~~~ > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:15: error: ?static bool CompressedOops::is_null(int)? cannot be overloaded with ?static bool CompressedOops::is_null(int)? > static bool is_null(narrowOop v) { return v == 0; } > ^~~~~~~ > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:15: note: previous declaration ?static bool CompressedOops::is_null(int)? > static bool is_null(oop v) { return v == NULL; } > if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_expand.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi > ... (rest of output omitted) > /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc_format.o:\n" > * For target hotspot_variant-server_libjvm_objs_ad_sparc_format.o: > (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_format.o.log || true) | /usr/bin/head -n 12 > In file included from ad_sparc.hpp:32, > from ad_sparc_format.cpp:28: > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:23: error: ?oop? has not been declared > static bool is_null(oop v) { return v == NULL; } > ^~~ > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:23: error: ?narrowOop? has not been declared > static bool is_null(narrowOop v) { return v == 0; } > ^~~~~~~~~ > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:15: error: ?static bool CompressedOops::is_null(int)? cannot be overloaded with ?static bool CompressedOops::is_null(int)? > static bool is_null(narrowOop v) { return v == 0; } > ^~~~~~~ > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:15: note: previous declaration ?static bool CompressedOops::is_null(int)? > if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_format.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi > ... (rest of output omitted) > /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc_gen.o:\n" > * For target hotspot_variant-server_libjvm_objs_ad_sparc_gen.o: > (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_gen.o.log || true) | /usr/bin/head -n 12 > In file included from ad_sparc.hpp:32, > from ad_sparc_gen.cpp:28: > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:23: error: ?oop? has not been declared > static bool is_null(oop v) { return v == NULL; } > ^~~ > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:23: error: ?narrowOop? has not been declared > static bool is_null(narrowOop v) { return v == 0; } > ^~~~~~~~~ > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:15: error: ?static bool CompressedOops::is_null(int)? cannot be overloaded with ?static bool CompressedOops::is_null(int)? > static bool is_null(narrowOop v) { return v == 0; } > ^~~~~~~ > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:15: note: previous declaration ?static bool CompressedOops::is_null(int)? > if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_gen.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi > ... (rest of output omitted) > /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc_misc.o:\n" > * For target hotspot_variant-server_libjvm_objs_ad_sparc_misc.o: > (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_misc.o.log || true) | /usr/bin/head -n 12 > In file included from ad_sparc.hpp:32, > from ad_sparc_misc.cpp:28: > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:23: error: ?oop? has not been declared > static bool is_null(oop v) { return v == NULL; } > ^~~ > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:23: error: ?narrowOop? has not been declared > static bool is_null(narrowOop v) { return v == 0; } > ^~~~~~~~~ > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:15: error: ?static bool CompressedOops::is_null(int)? cannot be overloaded with ?static bool CompressedOops::is_null(int)? > static bool is_null(narrowOop v) { return v == 0; } > ^~~~~~~ > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:15: note: previous declaration ?static bool CompressedOops::is_null(int)? > if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_misc.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi > ... (rest of output omitted) > /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc_peephole.o:\n" > * For target hotspot_variant-server_libjvm_objs_ad_sparc_peephole.o: > (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_peephole.o.log || true) | /usr/bin/head -n 12 > In file included from ad_sparc.hpp:32, > from ad_sparc_peephole.cpp:28: > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:23: error: ?oop? has not been declared > static bool is_null(oop v) { return v == NULL; } > ^~~ > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:23: error: ?narrowOop? has not been declared > static bool is_null(narrowOop v) { return v == 0; } > ^~~~~~~~~ > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:15: error: ?static bool CompressedOops::is_null(int)? cannot be overloaded with ?static bool CompressedOops::is_null(int)? > static bool is_null(narrowOop v) { return v == 0; } > ^~~~~~~ > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:15: note: previous declaration ?static bool CompressedOops::is_null(int)? > if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_peephole.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi > ... (rest of output omitted) > /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc_pipeline.o:\n" > * For target hotspot_variant-server_libjvm_objs_ad_sparc_pipeline.o: > (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_pipeline.o.log || true) | /usr/bin/head -n 12 > In file included from ad_sparc.hpp:32, > from ad_sparc_pipeline.cpp:28: > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:23: error: ?oop? has not been declared > static bool is_null(oop v) { return v == NULL; } > ^~~ > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:23: error: ?narrowOop? has not been declared > static bool is_null(narrowOop v) { return v == 0; } > ^~~~~~~~~ > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:108:15: error: ?static bool CompressedOops::is_null(int)? cannot be overloaded with ?static bool CompressedOops::is_null(int)? > static bool is_null(narrowOop v) { return v == 0; } > ^~~~~~~ > /home/glaubitz/jdk/src/hotspot/share/oops/compressedOops.hpp:107:15: note: previous declaration ?static bool CompressedOops::is_null(int)? > if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_pipeline.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi > ... (rest of output omitted) > /usr/bin/printf "\n* All command lines available in /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs.\n" > > * All command lines available in /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs. > /usr/bin/printf "=== End of repeated output ===\n" > === End of repeated output === > > From glaubitz at physik.fu-berlin.de Fri May 10 11:47:54 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 10 May 2019 13:47:54 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: References: <6de9c394-131c-2f81-6a21-70ca72285bd3@physik.fu-berlin.de> <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> <57268061-c441-214f-83fd-baf5dfec3869@oracle.com> Message-ID: <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> Hi! On 5/10/19 1:34 PM, Stefan Karlsson wrote: >> Yes, getting further now: > > This needs an: > #include "oops/oopsHierarchy.hpp" in compressedOops.hpp The following patch works. Not sure whether there are any redundant #includes now but I think the best is to wait for the other related fixes to be merged and then push something to fix linux-sparc. But if you want to include linux-sparc in your fix as well, please go ahead. glaubitz at gcc202:~/jdk$ hg diff diff -r 45bbef01a6ae src/hotspot/cpu/sparc/c1_CodeStubs_sparc.cpp --- a/src/hotspot/cpu/sparc/c1_CodeStubs_sparc.cpp Fri May 10 09:56:20 2019 +0200 +++ b/src/hotspot/cpu/sparc/c1_CodeStubs_sparc.cpp Fri May 10 14:41:37 2019 +0300 @@ -29,6 +29,7 @@ #include "c1/c1_LIRAssembler.hpp" #include "c1/c1_MacroAssembler.hpp" #include "c1/c1_Runtime1.hpp" +#include "memory/universe.hpp" #include "nativeInst_sparc.hpp" #include "runtime/sharedRuntime.hpp" #include "utilities/macros.hpp" diff -r 45bbef01a6ae src/hotspot/cpu/sparc/c1_LIRAssembler_sparc.cpp --- a/src/hotspot/cpu/sparc/c1_LIRAssembler_sparc.cpp Fri May 10 09:56:20 2019 +0200 +++ b/src/hotspot/cpu/sparc/c1_LIRAssembler_sparc.cpp Fri May 10 14:41:37 2019 +0300 @@ -34,6 +34,7 @@ #include "gc/shared/barrierSet.hpp" #include "gc/shared/cardTableBarrierSet.hpp" #include "gc/shared/collectedHeap.hpp" +#include "memory/universe.hpp" #include "nativeInst_sparc.hpp" #include "oops/objArrayKlass.hpp" #include "runtime/frame.inline.hpp" diff -r 45bbef01a6ae src/hotspot/cpu/sparc/macroAssembler_sparc.inline.hpp --- a/src/hotspot/cpu/sparc/macroAssembler_sparc.inline.hpp Fri May 10 09:56:20 2019 +0200 +++ b/src/hotspot/cpu/sparc/macroAssembler_sparc.inline.hpp Fri May 10 14:41:37 2019 +0300 @@ -29,6 +29,7 @@ #include "asm/macroAssembler.hpp" #include "asm/codeBuffer.hpp" #include "code/codeCache.hpp" +#include "oops/compressedOops.hpp" inline bool Address::is_simm13(int offset) { return Assembler::is_simm13(disp() + offset); } diff -r 45bbef01a6ae src/hotspot/os_cpu/linux_sparc/thread_linux_sparc.cpp --- a/src/hotspot/os_cpu/linux_sparc/thread_linux_sparc.cpp Fri May 10 09:56:20 2019 +0200 +++ b/src/hotspot/os_cpu/linux_sparc/thread_linux_sparc.cpp Fri May 10 14:41:37 2019 +0300 @@ -24,6 +24,7 @@ #include "precompiled.hpp" #include "memory/metaspaceShared.hpp" +#include "memory/universe.hpp" #include "runtime/frame.inline.hpp" #include "runtime/thread.inline.hpp" diff -r 45bbef01a6ae src/hotspot/share/adlc/main.cpp --- a/src/hotspot/share/adlc/main.cpp Fri May 10 09:56:20 2019 +0200 +++ b/src/hotspot/share/adlc/main.cpp Fri May 10 14:41:37 2019 +0300 @@ -217,6 +217,7 @@ AD.addInclude(AD._CPP_file, "code/vmreg.inline.hpp"); AD.addInclude(AD._CPP_file, "gc/shared/collectedHeap.inline.hpp"); AD.addInclude(AD._CPP_file, "oops/compiledICHolder.hpp"); + AD.addInclude(AD._CPP_file, "oops/compressedOops.hpp"); AD.addInclude(AD._CPP_file, "oops/markOop.hpp"); AD.addInclude(AD._CPP_file, "oops/method.hpp"); AD.addInclude(AD._CPP_file, "oops/oop.inline.hpp"); @@ -233,12 +234,14 @@ AD.addInclude(AD._CPP_file, "runtime/stubRoutines.hpp"); AD.addInclude(AD._CPP_file, "utilities/growableArray.hpp"); AD.addInclude(AD._HPP_file, "memory/allocation.hpp"); + AD.addInclude(AD._HPP_file, "oops/compressedOops.hpp"); AD.addInclude(AD._HPP_file, "code/nativeInst.hpp"); AD.addInclude(AD._HPP_file, "opto/machnode.hpp"); AD.addInclude(AD._HPP_file, "opto/node.hpp"); AD.addInclude(AD._HPP_file, "opto/regalloc.hpp"); AD.addInclude(AD._HPP_file, "opto/subnode.hpp"); AD.addInclude(AD._HPP_file, "opto/vectornode.hpp"); + AD.addInclude(AD._CPP_EXPAND_file, "oops/compressedOops.hpp"); AD.addInclude(AD._CPP_CLONE_file, "precompiled.hpp"); AD.addInclude(AD._CPP_CLONE_file, "adfiles", get_basename(AD._HPP_file._name)); AD.addInclude(AD._CPP_EXPAND_file, "precompiled.hpp"); @@ -257,6 +260,7 @@ AD.addInclude(AD._CPP_PIPELINE_file, "adfiles", get_basename(AD._HPP_file._name)); AD.addInclude(AD._DFA_file, "precompiled.hpp"); AD.addInclude(AD._DFA_file, "adfiles", get_basename(AD._HPP_file._name)); + AD.addInclude(AD._DFA_file, "oops/compressedOops.hpp"); AD.addInclude(AD._DFA_file, "opto/cfgnode.hpp"); // Use PROB_MAX in predicate. AD.addInclude(AD._DFA_file, "opto/intrinsicnode.hpp"); AD.addInclude(AD._DFA_file, "opto/matcher.hpp"); diff -r 45bbef01a6ae src/hotspot/share/oops/compressedOops.hpp --- a/src/hotspot/share/oops/compressedOops.hpp Fri May 10 09:56:20 2019 +0200 +++ b/src/hotspot/share/oops/compressedOops.hpp Fri May 10 14:41:37 2019 +0300 @@ -26,6 +26,7 @@ #define SHARE_OOPS_COMPRESSEDOOPS_HPP #include "memory/allocation.hpp" +#include "oops/oopsHierarchy.hpp" #include "utilities/globalDefinitions.hpp" class outputStream; glaubitz at gcc202:~/jdk$ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From erik.gahlin at oracle.com Fri May 10 13:14:53 2019 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Fri, 10 May 2019 15:14:53 +0200 Subject: RFR: 8223438: add VirtualizationInformation JFR event In-Reply-To: References: <5CD309CA.40808@oracle.com> Message-ID: <5CD5794D.20304@oracle.com> Looks good. Erik > Hello, here is the next webrev with adjusted coding following your > suggestion : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8223438.2/ > > > Best regards, Matthias > > *From:*Baesken, Matthias > *Sent:* Donnerstag, 9. Mai 2019 09:03 > *To:* Erik Gahlin ; > 'hotspot-dev at openjdk.java.net' > *Subject:* RE: RFR: 8223438: add VirtualizationInformation JFR event > > Hi Erik, the virtualization names are a set of fix names , so I > think we can do what you suggest . > > I just ?borrowed? a bit from the code above ? > > TRACE_REQUEST_FUNC(OSInformation) { > > ResourceMark rm; > > char* os_name = NEW_RESOURCE_ARRAY(char, 2048); > > JfrOSInterface::os_version(&os_name); > > EventOSInformation event; > > event.set_osVersion(os_name); > > event.commit(); > > } > > ? where a ResourceMark + allocation is used (but in jfrOSInterface > I wonder about the second allocation in string.stream.as_string , > do we really need two here ? > > int JfrOSInterface::JfrOSInterfaceImpl::os_version(char** os_version) > const { > > assert(os_version != NULL, "os_version pointer is NULL!"); > > stringStream os_ver_info; > > os::print_os_info_brief(&os_ver_info); > > *os_version = os_ver_info.as_string(); <--- second alloc > > Best regards, Matthias > > *From:*Erik Gahlin > > *Sent:* Mittwoch, 8. Mai 2019 18:55 > *To:* Baesken, Matthias >; 'hotspot-dev at openjdk.java.net' > > > *Subject:* Re: RFR: 8223438: add VirtualizationInformation JFR event > > Hello, > > Looks good, but do we really need to allocate the name every time an > event is emitted in jfrPeriodic.cpp? > > It will not matter much from a performance perspective, but the code > would look cleaner if we would have. > > EventVirtualizationInformation event; > event.set_name(JfrOSInterface::virtualization_name()); > event.commit(); > > Thanks > Erik > > Hello, please review the following change . > > It adds a simple VirtualizationInformation event to JFR . > > The addition to JFR has been previously proposed by Erik when > we discussed the enhancement of hs_error file output with > virtualization related information . > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8223438 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8223438.1/ > > > Thanks, Matthias > From david.holmes at oracle.com Fri May 10 13:41:05 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 May 2019 23:41:05 +1000 Subject: 8222720: Provide extended VMWare/vSphere virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: References: <06d00a9c-497b-44de-f834-a0314bd0bf39@oracle.com> Message-ID: <7a05ab9f-5688-7197-e1eb-3c697c41bc75@oracle.com> On 10/05/2019 7:08 pm, Baesken, Matthias wrote: > Hi David, I removed / adjusted the ifdefs and added checks != NULL : > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8222720.3/ Looks good. > > (not sure however about VMWARE Fusion on Mac, have no access to it ) No idea either. Thanks, David > Regards, Matthias > >> >> Hi Matthias, >> >> On 10/05/2019 4:21 pm, Baesken, Matthias wrote: >>> Hello, here is an updated version : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8222720.2/ >>> >>> I switched to os::dll_load / os::dll_lookup . >>> Also removed the VMWare related names ( now the name is >> "VirtualizationSupport" ). >> >> Thanks! >> >> src/hotspot/cpu/x86/vm_version_x86.cpp >> >> No ifdefs needed. >> >> src/hotspot/share/utilities/virtualizationSupport.cpp >> >> 47 #if defined(__linux) >> >> The common form of this is: >> >> #ifdef LINUX >> >> 62 if (GuestLib_StatGet && GuestLib_StatFree) { >> >> Style nit: avoid implicit booleans - test against NULL. >> >> --- >> >> Otherwise seems fine. >> >> Thanks, >> David >> ----- >> >>> Best regards, Matthias >>> >>> >>>> >>>> Hi David, thanks for the feedback . I'll provide an updated webrev . >>>> >>>>> **Not sure about the validity of using "vmware" in the name of files or >>>>> classes either due to its trademark status. >>>> >>>> Well , we have a lot of technology names in file-names (AIX and >> Windows >>>> come to mind) . >>>> >>>> But to be on the safe side, I think I'll choose a more generic name . >>>> >>>> >>>> Best regards, Matthias >>>> >>> From lutz.schmidt at sap.com Fri May 10 14:18:29 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 10 May 2019 14:18:29 +0000 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> References: <6de9c394-131c-2f81-6a21-70ca72285bd3@physik.fu-berlin.de> <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> <57268061-c441-214f-83fd-baf5dfec3869@oracle.com> <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> Message-ID: <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> Hi, anyone taking care of this issue? Stefan? Thanks, Lutz ?On 10.05.19, 13:47, "John Paul Adrian Glaubitz" wrote: Hi! On 5/10/19 1:34 PM, Stefan Karlsson wrote: >> Yes, getting further now: > > This needs an: > #include "oops/oopsHierarchy.hpp" in compressedOops.hpp The following patch works. Not sure whether there are any redundant #includes now but I think the best is to wait for the other related fixes to be merged and then push something to fix linux-sparc. But if you want to include linux-sparc in your fix as well, please go ahead. glaubitz at gcc202:~/jdk$ hg diff diff -r 45bbef01a6ae src/hotspot/cpu/sparc/c1_CodeStubs_sparc.cpp --- a/src/hotspot/cpu/sparc/c1_CodeStubs_sparc.cpp Fri May 10 09:56:20 2019 +0200 +++ b/src/hotspot/cpu/sparc/c1_CodeStubs_sparc.cpp Fri May 10 14:41:37 2019 +0300 @@ -29,6 +29,7 @@ #include "c1/c1_LIRAssembler.hpp" #include "c1/c1_MacroAssembler.hpp" #include "c1/c1_Runtime1.hpp" +#include "memory/universe.hpp" #include "nativeInst_sparc.hpp" #include "runtime/sharedRuntime.hpp" #include "utilities/macros.hpp" diff -r 45bbef01a6ae src/hotspot/cpu/sparc/c1_LIRAssembler_sparc.cpp --- a/src/hotspot/cpu/sparc/c1_LIRAssembler_sparc.cpp Fri May 10 09:56:20 2019 +0200 +++ b/src/hotspot/cpu/sparc/c1_LIRAssembler_sparc.cpp Fri May 10 14:41:37 2019 +0300 @@ -34,6 +34,7 @@ #include "gc/shared/barrierSet.hpp" #include "gc/shared/cardTableBarrierSet.hpp" #include "gc/shared/collectedHeap.hpp" +#include "memory/universe.hpp" #include "nativeInst_sparc.hpp" #include "oops/objArrayKlass.hpp" #include "runtime/frame.inline.hpp" diff -r 45bbef01a6ae src/hotspot/cpu/sparc/macroAssembler_sparc.inline.hpp --- a/src/hotspot/cpu/sparc/macroAssembler_sparc.inline.hpp Fri May 10 09:56:20 2019 +0200 +++ b/src/hotspot/cpu/sparc/macroAssembler_sparc.inline.hpp Fri May 10 14:41:37 2019 +0300 @@ -29,6 +29,7 @@ #include "asm/macroAssembler.hpp" #include "asm/codeBuffer.hpp" #include "code/codeCache.hpp" +#include "oops/compressedOops.hpp" inline bool Address::is_simm13(int offset) { return Assembler::is_simm13(disp() + offset); } diff -r 45bbef01a6ae src/hotspot/os_cpu/linux_sparc/thread_linux_sparc.cpp --- a/src/hotspot/os_cpu/linux_sparc/thread_linux_sparc.cpp Fri May 10 09:56:20 2019 +0200 +++ b/src/hotspot/os_cpu/linux_sparc/thread_linux_sparc.cpp Fri May 10 14:41:37 2019 +0300 @@ -24,6 +24,7 @@ #include "precompiled.hpp" #include "memory/metaspaceShared.hpp" +#include "memory/universe.hpp" #include "runtime/frame.inline.hpp" #include "runtime/thread.inline.hpp" diff -r 45bbef01a6ae src/hotspot/share/adlc/main.cpp --- a/src/hotspot/share/adlc/main.cpp Fri May 10 09:56:20 2019 +0200 +++ b/src/hotspot/share/adlc/main.cpp Fri May 10 14:41:37 2019 +0300 @@ -217,6 +217,7 @@ AD.addInclude(AD._CPP_file, "code/vmreg.inline.hpp"); AD.addInclude(AD._CPP_file, "gc/shared/collectedHeap.inline.hpp"); AD.addInclude(AD._CPP_file, "oops/compiledICHolder.hpp"); + AD.addInclude(AD._CPP_file, "oops/compressedOops.hpp"); AD.addInclude(AD._CPP_file, "oops/markOop.hpp"); AD.addInclude(AD._CPP_file, "oops/method.hpp"); AD.addInclude(AD._CPP_file, "oops/oop.inline.hpp"); @@ -233,12 +234,14 @@ AD.addInclude(AD._CPP_file, "runtime/stubRoutines.hpp"); AD.addInclude(AD._CPP_file, "utilities/growableArray.hpp"); AD.addInclude(AD._HPP_file, "memory/allocation.hpp"); + AD.addInclude(AD._HPP_file, "oops/compressedOops.hpp"); AD.addInclude(AD._HPP_file, "code/nativeInst.hpp"); AD.addInclude(AD._HPP_file, "opto/machnode.hpp"); AD.addInclude(AD._HPP_file, "opto/node.hpp"); AD.addInclude(AD._HPP_file, "opto/regalloc.hpp"); AD.addInclude(AD._HPP_file, "opto/subnode.hpp"); AD.addInclude(AD._HPP_file, "opto/vectornode.hpp"); + AD.addInclude(AD._CPP_EXPAND_file, "oops/compressedOops.hpp"); AD.addInclude(AD._CPP_CLONE_file, "precompiled.hpp"); AD.addInclude(AD._CPP_CLONE_file, "adfiles", get_basename(AD._HPP_file._name)); AD.addInclude(AD._CPP_EXPAND_file, "precompiled.hpp"); @@ -257,6 +260,7 @@ AD.addInclude(AD._CPP_PIPELINE_file, "adfiles", get_basename(AD._HPP_file._name)); AD.addInclude(AD._DFA_file, "precompiled.hpp"); AD.addInclude(AD._DFA_file, "adfiles", get_basename(AD._HPP_file._name)); + AD.addInclude(AD._DFA_file, "oops/compressedOops.hpp"); AD.addInclude(AD._DFA_file, "opto/cfgnode.hpp"); // Use PROB_MAX in predicate. AD.addInclude(AD._DFA_file, "opto/intrinsicnode.hpp"); AD.addInclude(AD._DFA_file, "opto/matcher.hpp"); diff -r 45bbef01a6ae src/hotspot/share/oops/compressedOops.hpp --- a/src/hotspot/share/oops/compressedOops.hpp Fri May 10 09:56:20 2019 +0200 +++ b/src/hotspot/share/oops/compressedOops.hpp Fri May 10 14:41:37 2019 +0300 @@ -26,6 +26,7 @@ #define SHARE_OOPS_COMPRESSEDOOPS_HPP #include "memory/allocation.hpp" +#include "oops/oopsHierarchy.hpp" #include "utilities/globalDefinitions.hpp" class outputStream; glaubitz at gcc202:~/jdk$ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Fri May 10 14:31:25 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 10 May 2019 16:31:25 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> References: <6de9c394-131c-2f81-6a21-70ca72285bd3@physik.fu-berlin.de> <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> <57268061-c441-214f-83fd-baf5dfec3869@oracle.com> <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> Message-ID: <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> Hi Lutz! On 5/10/19 4:18 PM, Schmidt, Lutz wrote: > anyone taking care of this issue? Stefan? I can take of this myself as I also have commit access. I would just wait for the other fixes to be merged first to avoid any conflicts. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From lutz.schmidt at sap.com Fri May 10 14:36:53 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 10 May 2019 14:36:53 +0000 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> References: <6de9c394-131c-2f81-6a21-70ca72285bd3@physik.fu-berlin.de> <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> <57268061-c441-214f-83fd-baf5dfec3869@oracle.com> <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> Message-ID: Why wait? The changes discussed in this thread are sufficient to fix all platforms - at least as far as we know. Waiting too long means we lose the weekend for testing. Regards, Lutz ?On 10.05.19, 16:31, "John Paul Adrian Glaubitz" wrote: Hi Lutz! On 5/10/19 4:18 PM, Schmidt, Lutz wrote: > anyone taking care of this issue? Stefan? I can take of this myself as I also have commit access. I would just wait for the other fixes to be merged first to avoid any conflicts. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From stefan.karlsson at oracle.com Fri May 10 14:40:31 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 10 May 2019 16:40:31 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> References: <6de9c394-131c-2f81-6a21-70ca72285bd3@physik.fu-berlin.de> <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> <57268061-c441-214f-83fd-baf5dfec3869@oracle.com> <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> Message-ID: <8ba2afaf-d40a-d072-01ca-81716f6f5570@oracle.com> Hi Adrian and Lutz, It's not obvious to me exactly what changes you both ran with. Did you run with these changes: http://cr.openjdk.java.net/~stefank/8223637/webrev.01/ plus the changes listed in this thread? If you prepare a webrev with all the changes you ran with, I can review it. Thanks, StefanK On 2019-05-10 16:31, John Paul Adrian Glaubitz wrote: > Hi Lutz! > > On 5/10/19 4:18 PM, Schmidt, Lutz wrote: >> anyone taking care of this issue? Stefan? > I can take of this myself as I also have commit access. > > I would just wait for the other fixes to be merged first to avoid > any conflicts. > > Adrian > From glaubitz at physik.fu-berlin.de Fri May 10 14:47:37 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 10 May 2019 16:47:37 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: References: <6de9c394-131c-2f81-6a21-70ca72285bd3@physik.fu-berlin.de> <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> <57268061-c441-214f-83fd-baf5dfec3869@oracle.com> <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> Message-ID: On 5/10/19 4:36 PM, Schmidt, Lutz wrote: > Why wait? > The changes discussed in this thread are sufficient to fix all platforms - at least as far as we know. Waiting too long means we lose the weekend for testing. Do you want me to send an updated patch for JDK-8223637 to include the fixes necessary for SPARC? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From lutz.schmidt at sap.com Fri May 10 15:13:05 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 10 May 2019 15:13:05 +0000 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: References: <6de9c394-131c-2f81-6a21-70ca72285bd3@physik.fu-berlin.de> <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> <57268061-c441-214f-83fd-baf5dfec3869@oracle.com> <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> Message-ID: Hi Adrian, it would be great if you could create a consolidated patch, based on http://cr.openjdk.java.net/~stefank/8223637/webrev.01/ plus your SPARC fixes plus what I found necessary: --------------- 8< ---------------------- diff -r b0fbe518d143 src/hotspot/cpu/ppc/macroAssembler_ppc.cpp --- a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp Fri May 10 09:41:14 2019 +0200 +++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp Fri May 10 11:25:34 2019 +0200 @@ -32,7 +32,6 @@ #include "interpreter/interpreter.hpp" #include "memory/resourceArea.hpp" #include "nativeInst_ppc.hpp" -#include "oops/compressedOops.hpp" #include "prims/methodHandles.hpp" #include "runtime/biasedLocking.hpp" #include "runtime/icache.hpp" diff -r b0fbe518d143 src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp --- a/src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp Fri May 10 09:41:14 2019 +0200 +++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp Fri May 10 11:25:34 2019 +0200 @@ -33,6 +33,7 @@ #include "gc/shared/barrierSet.hpp" #include "gc/shared/barrierSetAssembler.hpp" #include "oops/accessDecorators.hpp" +#include "oops/compressedOops.hpp" #include "runtime/safepointMechanism.hpp" inline bool MacroAssembler::is_ld_largeoffset(address a) { diff -r b0fbe518d143 src/hotspot/share/adlc/main.cpp --- a/src/hotspot/share/adlc/main.cpp Fri May 10 09:41:14 2019 +0200 +++ b/src/hotspot/share/adlc/main.cpp Fri May 10 11:25:34 2019 +0200 @@ -217,6 +217,7 @@ AD.addInclude(AD._CPP_file, "code/vmreg.inline.hpp"); AD.addInclude(AD._CPP_file, "gc/shared/collectedHeap.inline.hpp"); AD.addInclude(AD._CPP_file, "oops/compiledICHolder.hpp"); + AD.addInclude(AD._CPP_file, "oops/compressedOops.hpp"); AD.addInclude(AD._CPP_file, "oops/markOop.hpp"); AD.addInclude(AD._CPP_file, "oops/method.hpp"); AD.addInclude(AD._CPP_file, "oops/oop.inline.hpp"); @@ -243,6 +244,7 @@ AD.addInclude(AD._CPP_CLONE_file, "adfiles", get_basename(AD._HPP_file._name)); AD.addInclude(AD._CPP_EXPAND_file, "precompiled.hpp"); AD.addInclude(AD._CPP_EXPAND_file, "adfiles", get_basename(AD._HPP_file._name)); + AD.addInclude(AD._CPP_EXPAND_file, "oops/compressedOops.hpp"); AD.addInclude(AD._CPP_FORMAT_file, "precompiled.hpp"); AD.addInclude(AD._CPP_FORMAT_file, "adfiles", get_basename(AD._HPP_file._name)); AD.addInclude(AD._CPP_GEN_file, "precompiled.hpp"); @@ -257,6 +259,7 @@ AD.addInclude(AD._CPP_PIPELINE_file, "adfiles", get_basename(AD._HPP_file._name)); AD.addInclude(AD._DFA_file, "precompiled.hpp"); AD.addInclude(AD._DFA_file, "adfiles", get_basename(AD._HPP_file._name)); + AD.addInclude(AD._DFA_file, "oops/compressedOops.hpp"); AD.addInclude(AD._DFA_file, "opto/cfgnode.hpp"); // Use PROB_MAX in predicate. AD.addInclude(AD._DFA_file, "opto/intrinsicnode.hpp"); AD.addInclude(AD._DFA_file, "opto/matcher.hpp"); ----------- >8 ---------------------- Thanks, Lutz ?On 10.05.19, 16:47, "John Paul Adrian Glaubitz" wrote: On 5/10/19 4:36 PM, Schmidt, Lutz wrote: > Why wait? > The changes discussed in this thread are sufficient to fix all platforms - at least as far as we know. Waiting too long means we lose the weekend for testing. Do you want me to send an updated patch for JDK-8223637 to include the fixes necessary for SPARC? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From shade at redhat.com Fri May 10 15:20:39 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 10 May 2019 17:20:39 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: References: <8c345341-cef0-df3c-4b83-43bb46d0a2c9@oracle.com> Message-ID: <3e5f4e78-3818-0bbc-12ff-12df7ac1764f@redhat.com> On 5/10/19 11:08 AM, Schmidt, Lutz wrote: > Hi all, > > I'm currently collecting the changes required in addition to http://cr.openjdk.java.net/~stefank/8223637/webrev.01/ > > @shade: your fixes are necessary, but not sufficient. I would suggest we make Stefan's patch a superset of yours and push that. Is that ok for you? Yes, sure, please reassign the bug as you see fit. I was under impression my fix was sufficient, but it is clearly not. I had pushed patches to unbreak minimal VM and arm32 this morning, and my CI now complains only about ppc64 and s390x. -Aleksey From aeubanks at google.com Fri May 10 15:28:22 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Fri, 10 May 2019 08:28:22 -0700 Subject: RFR: 8223186: HotSpot compile warnings from GCC 9 In-Reply-To: References: <960ff595-3001-ce41-6a90-3904b9cd0b20@oracle.com> Message-ID: Looks good to me. This also fixes the Clang build on Linux. Thanks! *From: *Yasumasa Suenaga *Date: *Thu, May 9, 2019 at 7:20 PM *To: *David Holmes *Cc: *HotSpot Open Source Developers Thanks David! > I'm waiting for second reviewer. > > > Yasumasa > > 2019?5?10?(?) 11:14 David Holmes : > > > > Hi Yasumasa, > > > > This all looks fine to me. > > > > Thanks, > > David > > > > On 2/05/2019 12:03 pm, Yasumasa Suenaga wrote: > > > Hi all, > > > > > > Please review this change: > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8223186 > > > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8223186/webrev.00/ > > > > > > > > > I saw following warnings when I compiled HotSpot with GCC 9 on Fedora > 30 > > > due to -Wwrite-strings, -Wstringop-truncation and -Wclass-memaccess. > > > I filed all warnings to JBS. > > > > > > > > > Thanks, > > > > > > Yasumasa > From glaubitz at physik.fu-berlin.de Fri May 10 15:30:05 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 10 May 2019 17:30:05 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: References: <6de9c394-131c-2f81-6a21-70ca72285bd3@physik.fu-berlin.de> <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> <57268061-c441-214f-83fd-baf5dfec3869@oracle.com> <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> Message-ID: <6cf7d02e-98c5-b0a3-349c-12834ed9dd6b@physik.fu-berlin.de> Hi! On 5/10/19 5:13 PM, Schmidt, Lutz wrote: > it would be great if you could create a consolidated patch, based on http://cr.openjdk.java.net/~stefank/8223637/webrev.01/ Sure, will do. I won't be able to do it today, but I will do it tomorrow. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From lutz.schmidt at sap.com Fri May 10 15:36:20 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 10 May 2019 15:36:20 +0000 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <6cf7d02e-98c5-b0a3-349c-12834ed9dd6b@physik.fu-berlin.de> References: <6de9c394-131c-2f81-6a21-70ca72285bd3@physik.fu-berlin.de> <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> <57268061-c441-214f-83fd-baf5dfec3869@oracle.com> <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> <6cf7d02e-98c5-b0a3-349c-12834ed9dd6b@physik.fu-berlin.de> Message-ID: <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> OK. I will try to set aside some time tomorrow to run a few builds and some quick tests, mainly verifying ppc and s390. The rest should be covered by the submit repo. Will post the results as they become available. Please note: I'm not a reviewer. We will need someone else to unleash the patch. So long, Lutz ?On 10.05.19, 17:30, "John Paul Adrian Glaubitz" wrote: Hi! On 5/10/19 5:13 PM, Schmidt, Lutz wrote: > it would be great if you could create a consolidated patch, based on http://cr.openjdk.java.net/~stefank/8223637/webrev.01/ Sure, will do. I won't be able to do it today, but I will do it tomorrow. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Fri May 10 15:42:10 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 10 May 2019 17:42:10 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> References: <6de9c394-131c-2f81-6a21-70ca72285bd3@physik.fu-berlin.de> <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> <57268061-c441-214f-83fd-baf5dfec3869@oracle.com> <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> <6cf7d02e-98c5-b0a3-349c-12834ed9dd6b@physik.fu-berlin.de> <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> Message-ID: On 5/10/19 5:36 PM, Schmidt, Lutz wrote: > OK. > I will try to set aside some time tomorrow to run a few builds and some quick tests, mainly verifying ppc and s390. The rest should be covered by the submit repo. Will post the results as they become available. > Please note: I'm not a reviewer. We will need someone else to unleash the patch. FWIW, through Debian, I have access to porterboxes for all architectures officially and unofficially supported by OpenJDK, including POWER8 and S390. So I can test all changes myself. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From stefan.karlsson at oracle.com Fri May 10 15:58:07 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 10 May 2019 17:58:07 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> References: <6de9c394-131c-2f81-6a21-70ca72285bd3@physik.fu-berlin.de> <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> <57268061-c441-214f-83fd-baf5dfec3869@oracle.com> <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> <6cf7d02e-98c5-b0a3-349c-12834ed9dd6b@physik.fu-berlin.de> <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> Message-ID: <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> I took all you patches and merged them with my patch: http://cr.openjdk.java.net/~stefank/8223637/webrev.02/ There were two includes added to the sparc files that I don't see why they would be needed. Either they were unnecessarily added, or some other file needs the include. I also created a version that removes those two lines: http://cr.openjdk.java.net/~stefank/8223637/webrev.03.delta http://cr.openjdk.java.net/~stefank/8223637/webrev.03 Will run webrev.03 through our testing. StefanK On 2019-05-10 17:36, Schmidt, Lutz wrote: > OK. > I will try to set aside some time tomorrow to run a few builds and some quick tests, mainly verifying ppc and s390. The rest should be covered by the submit repo. Will post the results as they become available. > Please note: I'm not a reviewer. We will need someone else to unleash the patch. > So long, > Lutz > > ?On 10.05.19, 17:30, "John Paul Adrian Glaubitz" wrote: > > Hi! > > On 5/10/19 5:13 PM, Schmidt, Lutz wrote: > > it would be great if you could create a consolidated patch, based on http://cr.openjdk.java.net/~stefank/8223637/webrev.01/ > Sure, will do. I won't be able to do it today, but I will do it > tomorrow. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > From stefan.karlsson at oracle.com Fri May 10 16:02:20 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 10 May 2019 18:02:20 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> References: <6de9c394-131c-2f81-6a21-70ca72285bd3@physik.fu-berlin.de> <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> <57268061-c441-214f-83fd-baf5dfec3869@oracle.com> <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> <6cf7d02e-98c5-b0a3-349c-12834ed9dd6b@physik.fu-berlin.de> <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> Message-ID: .. and with latest changes pulled in: http://cr.openjdk.java.net/~stefank/8223637/webrev.04 StefanK On 2019-05-10 17:58, Stefan Karlsson wrote: > I took all you patches and merged them with my patch: > http://cr.openjdk.java.net/~stefank/8223637/webrev.02/ > > There were two includes added to the sparc files that I don't see why > they would be needed. Either they were unnecessarily added, or some > other file needs the include. > > I also created a version that removes those two lines: > http://cr.openjdk.java.net/~stefank/8223637/webrev.03.delta > http://cr.openjdk.java.net/~stefank/8223637/webrev.03 > > Will run webrev.03 through our testing. > > StefanK > > On 2019-05-10 17:36, Schmidt, Lutz wrote: >> OK. >> I will try to set aside some time tomorrow to run a few builds and >> some quick tests, mainly verifying ppc and s390. The rest should be >> covered by the submit repo. Will post the results as they become >> available. >> Please note: I'm not a reviewer. We will need someone else to unleash >> the patch. >> So long, >> Lutz >> >> ?On 10.05.19, 17:30, "John Paul Adrian Glaubitz" >> wrote: >> >> ???? Hi! >> ???? On 5/10/19 5:13 PM, Schmidt, Lutz wrote: >> ???? > it would be great if you could create a consolidated patch, >> based on http://cr.openjdk.java.net/~stefank/8223637/webrev.01/ >> ???? Sure, will do. I won't be able to do it today, but I will do it >> ???? tomorrow. >> ???? Adrian >> ???? -- >> ????? .''`.? John Paul Adrian Glaubitz >> ???? : :' :? Debian Developer - glaubitz at debian.org >> ???? `. `'?? Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de >> ?????? `-??? GPG: 62FF 8A75 84E0 2956 9546? 0006 7426 3B37 F5B5 F913 >> From glaubitz at physik.fu-berlin.de Fri May 10 16:03:37 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 10 May 2019 18:03:37 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> References: <6de9c394-131c-2f81-6a21-70ca72285bd3@physik.fu-berlin.de> <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> <57268061-c441-214f-83fd-baf5dfec3869@oracle.com> <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> <6cf7d02e-98c5-b0a3-349c-12834ed9dd6b@physik.fu-berlin.de> <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> Message-ID: <6233a55b-1dc4-5457-9337-37ae5323e2ad@physik.fu-berlin.de> On 5/10/19 5:58 PM, Stefan Karlsson wrote: > I took all you patches and merged them with my patch: > http://cr.openjdk.java.net/~stefank/8223637/webrev.02/ > > There were two includes added to the sparc files that I don't see why they would be needed. Either they were unnecessarily added, or some other file needs the include. > > I also created a version that removes those two lines: > http://cr.openjdk.java.net/~stefank/8223637/webrev.03.delta > http://cr.openjdk.java.net/~stefank/8223637/webrev.03 > > Will run webrev.03 through our testing. The patch doesn't apply, could you rebase? glaubitz at gcc202:~/jdk$ hg import http://cr.openjdk.java.net/~stefank/8223637/webrev.03/open.patch applying http://cr.openjdk.java.net/~stefank/8223637/webrev.03/open.patch patching file src/hotspot/cpu/arm/c1_CodeStubs_arm.cpp Hunk #1 FAILED at 28 1 out of 1 hunks FAILED -- saving rejects to file src/hotspot/cpu/arm/c1_CodeStubs_arm.cpp.rej patching file src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp Hunk #1 FAILED at 33 1 out of 1 hunks FAILED -- saving rejects to file src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp.rej patching file src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp Hunk #1 FAILED at 38 1 out of 1 hunks FAILED -- saving rejects to file src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp.rej patching file src/hotspot/os_cpu/linux_arm/thread_linux_arm.cpp Hunk #1 FAILED at 27 1 out of 1 hunks FAILED -- saving rejects to file src/hotspot/os_cpu/linux_arm/thread_linux_arm.cpp.rej abort: patch failed to apply glaubitz at gcc202:~/jdk$ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Fri May 10 16:20:34 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 10 May 2019 18:20:34 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: References: <6de9c394-131c-2f81-6a21-70ca72285bd3@physik.fu-berlin.de> <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> <57268061-c441-214f-83fd-baf5dfec3869@oracle.com> <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> <6cf7d02e-98c5-b0a3-349c-12834ed9dd6b@physik.fu-berlin.de> <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> Message-ID: On 5/10/19 6:02 PM, Stefan Karlsson wrote: > .. and with latest changes pulled in: > http://cr.openjdk.java.net/~stefank/8223637/webrev.04 Testing this now. Just a second. -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Fri May 10 16:35:39 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 10 May 2019 18:35:39 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: References: <6de9c394-131c-2f81-6a21-70ca72285bd3@physik.fu-berlin.de> <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> <57268061-c441-214f-83fd-baf5dfec3869@oracle.com> <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> <6cf7d02e-98c5-b0a3-349c-12834ed9dd6b@physik.fu-berlin.de> <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> Message-ID: <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> On 5/10/19 6:20 PM, John Paul Adrian Glaubitz wrote: > On 5/10/19 6:02 PM, Stefan Karlsson wrote: >> .. and with latest changes pulled in: >> http://cr.openjdk.java.net/~stefank/8223637/webrev.04 > Testing this now. Just a second. This fixes the bug for me on linux-sparc. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Fri May 10 16:36:23 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 10 May 2019 18:36:23 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> References: <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> <57268061-c441-214f-83fd-baf5dfec3869@oracle.com> <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> <6cf7d02e-98c5-b0a3-349c-12834ed9dd6b@physik.fu-berlin.de> <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> Message-ID: <00b8336a-af4f-7a37-b524-009885e0fcf3@physik.fu-berlin.de> On 5/10/19 6:35 PM, John Paul Adrian Glaubitz wrote: > On 5/10/19 6:20 PM, John Paul Adrian Glaubitz wrote: >> On 5/10/19 6:02 PM, Stefan Karlsson wrote: >>> .. and with latest changes pulled in: >>> http://cr.openjdk.java.net/~stefank/8223637/webrev.04 >> Testing this now. Just a second. > > This fixes the bug for me on linux-sparc. Feel free to add: Tested-By: glaubitz if you like. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From stefan.karlsson at oracle.com Fri May 10 17:05:50 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 10 May 2019 19:05:50 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <00b8336a-af4f-7a37-b524-009885e0fcf3@physik.fu-berlin.de> References: <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> <57268061-c441-214f-83fd-baf5dfec3869@oracle.com> <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> <6cf7d02e-98c5-b0a3-349c-12834ed9dd6b@physik.fu-berlin.de> <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> <00b8336a-af4f-7a37-b524-009885e0fcf3@physik.fu-berlin.de> Message-ID: Our platforms still builds with this. Lutz, does this patch work for your platforms? Thanks, StefanK On 2019-05-10 18:36, John Paul Adrian Glaubitz wrote: > On 5/10/19 6:35 PM, John Paul Adrian Glaubitz wrote: >> On 5/10/19 6:20 PM, John Paul Adrian Glaubitz wrote: >>> On 5/10/19 6:02 PM, Stefan Karlsson wrote: >>>> .. and with latest changes pulled in: >>>> http://cr.openjdk.java.net/~stefank/8223637/webrev.04 >>> Testing this now. Just a second. >> This fixes the bug for me on linux-sparc. > Feel free to add: > > Tested-By: glaubitz > > if you like. > > Adrian > From lutz.schmidt at sap.com Fri May 10 20:44:13 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 10 May 2019 20:44:13 +0000 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: References: <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> <57268061-c441-214f-83fd-baf5dfec3869@oracle.com> <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> <6cf7d02e-98c5-b0a3-349c-12834ed9dd6b@physik.fu-berlin.de> <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> <00b8336a-af4f-7a37-b524-009885e0fcf3@physik.fu-berlin.de> Message-ID: <12626D50-4BC8-4B06-8F6C-19731C07027E@sap.com> Sorry, I was offline the last few hours. A first glimpse at webrev.04 is promising. I will start makes on Saturday am and some testing afterwards. Right now it makes no sense. Our servers are notoriously overloaded overnight. Cheers, Lutz ?On 10.05.19, 19:05, "Stefan Karlsson" wrote: Our platforms still builds with this. Lutz, does this patch work for your platforms? Thanks, StefanK On 2019-05-10 18:36, John Paul Adrian Glaubitz wrote: > On 5/10/19 6:35 PM, John Paul Adrian Glaubitz wrote: >> On 5/10/19 6:20 PM, John Paul Adrian Glaubitz wrote: >>> On 5/10/19 6:02 PM, Stefan Karlsson wrote: >>>> .. and with latest changes pulled in: >>>> http://cr.openjdk.java.net/~stefank/8223637/webrev.04 >>> Testing this now. Just a second. >> This fixes the bug for me on linux-sparc. > Feel free to add: > > Tested-By: glaubitz > > if you like. > > Adrian > From glaubitz at physik.fu-berlin.de Fri May 10 21:58:23 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 10 May 2019 23:58:23 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <12626D50-4BC8-4B06-8F6C-19731C07027E@sap.com> References: <1c912bc9-4a65-0ec0-189c-448382a27539@physik.fu-berlin.de> <57268061-c441-214f-83fd-baf5dfec3869@oracle.com> <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> <6cf7d02e-98c5-b0a3-349c-12834ed9dd6b@physik.fu-berlin.de> <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> <00b8336a-af4f-7a37-b524-009885e0fcf3@physik.fu-berlin.de> <12626D50-4BC8-4B06-8F6C-19731C07027E@sap.com> Message-ID: > On May 10, 2019, at 10:44 PM, Schmidt, Lutz wrote: > > Sorry, > I was offline the last few hours. A first glimpse at webrev.04 is promising. I will start makes on Saturday am and some testing afterwards. Right now it makes no sense. Our servers are notoriously overloaded overnight. You could use the gcc compile farm for ppc64, at least. And I can use the POWER and S390 machines available in Debian for testing. Those machines are fast and usually not much in use. Adrian From kim.barrett at oracle.com Sat May 11 00:13:42 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 10 May 2019 20:13:42 -0400 Subject: RFR: 8160539: Stack frame scanning acquires DerivedPointerTableGC_lock mutex Message-ID: <7CC6F888-B3C8-40EB-B2A6-02F4C169617B@oracle.com> Please review this change in the representation of the derived pointer table. It was a GrowableArray of pointers to derived pointer entries, protected by the DerivedPoitnerTableGC_lock. It is changed to a LockFreeStack of such entries. Running specjbb2015 with an instrumented VM found occasional contention for that lock; roughly half of the attempts to lock it found it already held by another thread. Comparing averages for G1 Thread Roots times for specjbb2015 before and after the change, average was reduced by 8% (1ms), max by 16% (11.5ms), and total by 8% (27ms). Since the code involved is largely GC-agnostic, other collectors (except Serial) should see similar improvements. DerivedPointerTable::update_pointers() showed no significant change; it only takes about 0.1ms with or without the change of representation. CR: https://bugs.openjdk.java.net/browse/JDK-8160539 Webrev: http://cr.openjdk.java.net/~kbarrett/8160539/open.00/ Testing: mach5 tier1-5, plus the above mentioned specjbb2015 performance testing. From vladimir.kozlov at oracle.com Sat May 11 00:27:32 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 10 May 2019 17:27:32 -0700 Subject: RFR: 8160539: Stack frame scanning acquires DerivedPointerTableGC_lock mutex In-Reply-To: <7CC6F888-B3C8-40EB-B2A6-02F4C169617B@oracle.com> References: <7CC6F888-B3C8-40EB-B2A6-02F4C169617B@oracle.com> Message-ID: <3fe96a0d-7c52-ec87-53f9-0d6a597d352f@oracle.com> LGTM. Thanks, Vladimir On 5/10/19 5:13 PM, Kim Barrett wrote: > Please review this change in the representation of the derived pointer table. > It was a GrowableArray of pointers to derived pointer entries, protected by > the DerivedPoitnerTableGC_lock. It is changed to a LockFreeStack of such > entries. > > Running specjbb2015 with an instrumented VM found occasional contention for > that lock; roughly half of the attempts to lock it found it already held by > another thread. Comparing averages for G1 Thread Roots times for specjbb2015 > before and after the change, average was reduced by 8% (1ms), max by 16% > (11.5ms), and total by 8% (27ms). Since the code involved is largely > GC-agnostic, other collectors (except Serial) should see similar improvements. > > DerivedPointerTable::update_pointers() showed no significant change; it only > takes about 0.1ms with or without the change of representation. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8160539 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8160539/open.00/ > > Testing: > mach5 tier1-5, plus the above mentioned specjbb2015 performance testing. > > From kim.barrett at oracle.com Sat May 11 02:48:27 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 10 May 2019 22:48:27 -0400 Subject: RFR: 8160539: Stack frame scanning acquires DerivedPointerTableGC_lock mutex In-Reply-To: <3fe96a0d-7c52-ec87-53f9-0d6a597d352f@oracle.com> References: <7CC6F888-B3C8-40EB-B2A6-02F4C169617B@oracle.com> <3fe96a0d-7c52-ec87-53f9-0d6a597d352f@oracle.com> Message-ID: > On May 10, 2019, at 8:27 PM, Vladimir Kozlov wrote: > > LGTM. > > Thanks, > Vladimir Thanks! From glaubitz at physik.fu-berlin.de Sat May 11 06:19:36 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Sat, 11 May 2019 08:19:36 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <12626D50-4BC8-4B06-8F6C-19731C07027E@sap.com> References: <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> <6cf7d02e-98c5-b0a3-349c-12834ed9dd6b@physik.fu-berlin.de> <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> <00b8336a-af4f-7a37-b524-009885e0fcf3@physik.fu-berlin.de> <12626D50-4BC8-4B06-8F6C-19731C07027E@sap.com> Message-ID: <58b27f04-3817-9d16-1dfb-8f7177ee456e@physik.fu-berlin.de> On 5/10/19 10:44 PM, Schmidt, Lutz wrote: > Sorry, > I was offline the last few hours. A first glimpse at webrev.04 is promising. > I will start makes on Saturday am and some testing afterwards. Right now it > makes no sense. Our servers are notoriously overloaded overnight. I'm preparing the test builds now. Checking out the repository with mercurial takes longer than the actual builds :O. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From lutz.schmidt at sap.com Sat May 11 11:04:15 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Sat, 11 May 2019 11:04:15 +0000 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <58b27f04-3817-9d16-1dfb-8f7177ee456e@physik.fu-berlin.de> References: <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> <6cf7d02e-98c5-b0a3-349c-12834ed9dd6b@physik.fu-berlin.de> <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> <00b8336a-af4f-7a37-b524-009885e0fcf3@physik.fu-berlin.de> <12626D50-4BC8-4B06-8F6C-19731C07027E@sap.com> <58b27f04-3817-9d16-1dfb-8f7177ee456e@physik.fu-berlin.de> Message-ID: Hi, my test builds ran fine. I tested linuxppc64 (fastdebug only, machine overloaded) linuxppcle (fastdebug, release) rs6000_64 (AIX) (fastdebug, release) linuxs390x (fastdebug, release) linuxaarch64 (fastdebug, release) all based on Stefan's webrev.04. I would regards this patch as ready to push. Regards, Lutz ?On 11.05.19, 08:19, "John Paul Adrian Glaubitz" wrote: On 5/10/19 10:44 PM, Schmidt, Lutz wrote: > Sorry, > I was offline the last few hours. A first glimpse at webrev.04 is promising. > I will start makes on Saturday am and some testing afterwards. Right now it > makes no sense. Our servers are notoriously overloaded overnight. I'm preparing the test builds now. Checking out the repository with mercurial takes longer than the actual builds :O. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From stefan.karlsson at oracle.com Sat May 11 11:05:52 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Sat, 11 May 2019 13:05:52 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: References: <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> <6cf7d02e-98c5-b0a3-349c-12834ed9dd6b@physik.fu-berlin.de> <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> <00b8336a-af4f-7a37-b524-009885e0fcf3@physik.fu-berlin.de> <12626D50-4BC8-4B06-8F6C-19731C07027E@sap.com> <58b27f04-3817-9d16-1dfb-8f7177ee456e@physik.fu-berlin.de> Message-ID: <44d6e805-c66e-9078-241a-6920b4cdc876@oracle.com> Thanks, I'll put myself as the Reviewer and all of us on Contributed-by. Thanks, StefanK On 2019-05-11 13:04, Schmidt, Lutz wrote: > Hi, > my test builds ran fine. I tested > linuxppc64 (fastdebug only, machine overloaded) > linuxppcle (fastdebug, release) > rs6000_64 (AIX) (fastdebug, release) > linuxs390x (fastdebug, release) > linuxaarch64 (fastdebug, release) > > all based on Stefan's webrev.04. I would regards this patch as ready to push. > > Regards, > Lutz > > > ?On 11.05.19, 08:19, "John Paul Adrian Glaubitz" wrote: > > On 5/10/19 10:44 PM, Schmidt, Lutz wrote: > > Sorry, > > I was offline the last few hours. A first glimpse at webrev.04 is promising. > > I will start makes on Saturday am and some testing afterwards. Right now it > > makes no sense. Our servers are notoriously overloaded overnight. > > I'm preparing the test builds now. Checking out the repository with mercurial > takes longer than the actual builds :O. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > From lutz.schmidt at sap.com Sat May 11 11:07:59 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Sat, 11 May 2019 11:07:59 +0000 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <44d6e805-c66e-9078-241a-6920b4cdc876@oracle.com> References: <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> <6cf7d02e-98c5-b0a3-349c-12834ed9dd6b@physik.fu-berlin.de> <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> <00b8336a-af4f-7a37-b524-009885e0fcf3@physik.fu-berlin.de> <12626D50-4BC8-4B06-8F6C-19731C07027E@sap.com> <58b27f04-3817-9d16-1dfb-8f7177ee456e@physik.fu-berlin.de> <44d6e805-c66e-9078-241a-6920b4cdc876@oracle.com> Message-ID: <6D24B05A-7EAF-4DB6-8A0E-62F4F6BCF408@sap.com> Agreed. ?On 11.05.19, 13:05, "Stefan Karlsson" wrote: Thanks, I'll put myself as the Reviewer and all of us on Contributed-by. Thanks, StefanK On 2019-05-11 13:04, Schmidt, Lutz wrote: > Hi, > my test builds ran fine. I tested > linuxppc64 (fastdebug only, machine overloaded) > linuxppcle (fastdebug, release) > rs6000_64 (AIX) (fastdebug, release) > linuxs390x (fastdebug, release) > linuxaarch64 (fastdebug, release) > > all based on Stefan's webrev.04. I would regards this patch as ready to push. > > Regards, > Lutz > > > On 11.05.19, 08:19, "John Paul Adrian Glaubitz" wrote: > > On 5/10/19 10:44 PM, Schmidt, Lutz wrote: > > Sorry, > > I was offline the last few hours. A first glimpse at webrev.04 is promising. > > I will start makes on Saturday am and some testing afterwards. Right now it > > makes no sense. Our servers are notoriously overloaded overnight. > > I'm preparing the test builds now. Checking out the repository with mercurial > takes longer than the actual builds :O. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > From glaubitz at physik.fu-berlin.de Sat May 11 11:38:55 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Sat, 11 May 2019 13:38:55 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: References: <4d1796ae-4c6a-1daf-a82f-b545af8fbb97@physik.fu-berlin.de> <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> <6cf7d02e-98c5-b0a3-349c-12834ed9dd6b@physik.fu-berlin.de> <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> <00b8336a-af4f-7a37-b524-009885e0fcf3@physik.fu-berlin.de> <12626D50-4BC8-4B06-8F6C-19731C07027E@sap.com> <58b27f04-3817-9d16-1dfb-8f7177ee456e@physik.fu-berlin.de> Message-ID: <8b32026c-ccd1-dffa-e555-4fa38f85d842@physik.fu-berlin.de> On 5/11/19 1:04 PM, Schmidt, Lutz wrote: > Hi, > my test builds ran fine. I tested > linuxppc64 (fastdebug only, machine overloaded) > linuxppcle (fastdebug, release) > rs6000_64 (AIX) (fastdebug, release) > linuxs390x (fastdebug, release) > linuxaarch64 (fastdebug, release) > > all based on Stefan's webrev.04. I would regards this patch as ready to push. I noticed that not all the includes you added are necessary for SPARC and I would apply for PPC64 and S390 as well. I'll run a quick test. Also, I think the bug should be renamed to include SPARC. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Sat May 11 11:57:59 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Sat, 11 May 2019 13:57:59 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <8b32026c-ccd1-dffa-e555-4fa38f85d842@physik.fu-berlin.de> References: <5DBD2BCF-9E41-4CAD-B14C-767B28ED7364@sap.com> <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> <6cf7d02e-98c5-b0a3-349c-12834ed9dd6b@physik.fu-berlin.de> <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> <00b8336a-af4f-7a37-b524-009885e0fcf3@physik.fu-berlin.de> <12626D50-4BC8-4B06-8F6C-19731C07027E@sap.com> <58b27f04-3817-9d16-1dfb-8f7177ee456e@physik.fu-berlin.de> <8b32026c-ccd1-dffa-e555-4fa38f85d842@physik.fu-berlin.de> Message-ID: <0e6ad2bd-5b4b-4850-62fc-b1ff7ea23df4@physik.fu-berlin.de> On 5/11/19 1:38 PM, John Paul Adrian Glaubitz wrote: > I noticed that not all the includes you added are necessary for > SPARC and I would apply for PPC64 and S390 as well. assume*, not apply, sorry. But it seems for PPC64 the includes are necessary. I cannot test S390 at the moment as the filesystem on Debian's S390 porterbox is full and I can't check the JDK repo. > Also, I think the bug should be renamed to include SPARC. For Linux SPARC, it builds fine for me with, so the hunks which include the memory/universe.hpp header the thread SPARC-specific source files is not necessary. glaubitz at gcc202:~/jdk$ hg diff |cat diff -r 351da897f409 src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp --- a/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp Fri May 10 15:34:17 2019 +0100 +++ b/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp Sat May 11 14:47:50 2019 +0300 @@ -35,7 +35,9 @@ #include "gc/shared/collectedHeap.hpp" #include "gc/shared/barrierSet.hpp" #include "gc/shared/cardTableBarrierSet.hpp" +#include "memory/universe.hpp" #include "nativeInst_ppc.hpp" +#include "oops/compressedOops.hpp" #include "oops/objArrayKlass.hpp" #include "runtime/frame.inline.hpp" #include "runtime/safepointMechanism.inline.hpp" @@ -1237,7 +1239,7 @@ int disp_value = addr->disp(); bool needs_patching = (patch_code != lir_patch_none); bool compress_oop = (type == T_ARRAY || type == T_OBJECT) && UseCompressedOops && !wide && - Universe::narrow_oop_mode() != Universe::UnscaledNarrowOop; + CompressedOops::mode() != CompressedOops::UnscaledNarrowOop; bool load_disp = addr->index()->is_illegal() && !Assembler::is_simm16(disp_value); bool use_R29 = compress_oop && load_disp; // Avoid register conflict, also do null check before killing R29. // Null check for large offsets in LIRGenerator::do_StoreField. diff -r 351da897f409 src/hotspot/cpu/ppc/macroAssembler_ppc.cpp --- a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp Fri May 10 15:34:17 2019 +0100 +++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp Sat May 11 14:47:50 2019 +0300 @@ -32,7 +32,6 @@ #include "interpreter/interpreter.hpp" #include "memory/resourceArea.hpp" #include "nativeInst_ppc.hpp" -#include "oops/compressedOops.hpp" #include "prims/methodHandles.hpp" #include "runtime/biasedLocking.hpp" #include "runtime/icache.hpp" diff -r 351da897f409 src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp --- a/src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp Fri May 10 15:34:17 2019 +0100 +++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp Sat May 11 14:47:50 2019 +0300 @@ -33,6 +33,7 @@ #include "gc/shared/barrierSet.hpp" #include "gc/shared/barrierSetAssembler.hpp" #include "oops/accessDecorators.hpp" +#include "oops/compressedOops.hpp" #include "runtime/safepointMechanism.hpp" inline bool MacroAssembler::is_ld_largeoffset(address a) { diff -r 351da897f409 src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp --- a/src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp Fri May 10 15:34:17 2019 +0100 +++ b/src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp Sat May 11 14:47:50 2019 +0300 @@ -35,6 +35,7 @@ #include "gc/shared/collectedHeap.hpp" #include "gc/shared/barrierSet.hpp" #include "gc/shared/cardTableBarrierSet.hpp" +#include "memory/universe.hpp" #include "nativeInst_s390.hpp" #include "oops/objArrayKlass.hpp" #include "runtime/frame.inline.hpp" diff -r 351da897f409 src/hotspot/os/solaris/os_solaris.cpp --- a/src/hotspot/os/solaris/os_solaris.cpp Fri May 10 15:34:17 2019 +0100 +++ b/src/hotspot/os/solaris/os_solaris.cpp Sat May 11 14:47:50 2019 +0300 @@ -36,6 +36,7 @@ #include "logging/logStream.hpp" #include "memory/allocation.inline.hpp" #include "memory/filemap.hpp" +#include "memory/universe.hpp" #include "oops/oop.inline.hpp" #include "os_share_solaris.hpp" #include "os_solaris.inline.hpp" diff -r 351da897f409 src/hotspot/share/adlc/main.cpp --- a/src/hotspot/share/adlc/main.cpp Fri May 10 15:34:17 2019 +0100 +++ b/src/hotspot/share/adlc/main.cpp Sat May 11 14:47:50 2019 +0300 @@ -217,6 +217,7 @@ AD.addInclude(AD._CPP_file, "code/vmreg.inline.hpp"); AD.addInclude(AD._CPP_file, "gc/shared/collectedHeap.inline.hpp"); AD.addInclude(AD._CPP_file, "oops/compiledICHolder.hpp"); + AD.addInclude(AD._CPP_file, "oops/compressedOops.hpp"); AD.addInclude(AD._CPP_file, "oops/markOop.hpp"); AD.addInclude(AD._CPP_file, "oops/method.hpp"); AD.addInclude(AD._CPP_file, "oops/oop.inline.hpp"); @@ -233,6 +234,7 @@ AD.addInclude(AD._CPP_file, "runtime/stubRoutines.hpp"); AD.addInclude(AD._CPP_file, "utilities/growableArray.hpp"); AD.addInclude(AD._HPP_file, "memory/allocation.hpp"); + AD.addInclude(AD._HPP_file, "oops/compressedOops.hpp"); AD.addInclude(AD._HPP_file, "code/nativeInst.hpp"); AD.addInclude(AD._HPP_file, "opto/machnode.hpp"); AD.addInclude(AD._HPP_file, "opto/node.hpp"); @@ -243,6 +245,7 @@ AD.addInclude(AD._CPP_CLONE_file, "adfiles", get_basename(AD._HPP_file._name)); AD.addInclude(AD._CPP_EXPAND_file, "precompiled.hpp"); AD.addInclude(AD._CPP_EXPAND_file, "adfiles", get_basename(AD._HPP_file._name)); + AD.addInclude(AD._CPP_EXPAND_file, "oops/compressedOops.hpp"); AD.addInclude(AD._CPP_FORMAT_file, "precompiled.hpp"); AD.addInclude(AD._CPP_FORMAT_file, "adfiles", get_basename(AD._HPP_file._name)); AD.addInclude(AD._CPP_GEN_file, "precompiled.hpp"); @@ -257,6 +260,7 @@ AD.addInclude(AD._CPP_PIPELINE_file, "adfiles", get_basename(AD._HPP_file._name)); AD.addInclude(AD._DFA_file, "precompiled.hpp"); AD.addInclude(AD._DFA_file, "adfiles", get_basename(AD._HPP_file._name)); + AD.addInclude(AD._DFA_file, "oops/compressedOops.hpp"); AD.addInclude(AD._DFA_file, "opto/cfgnode.hpp"); // Use PROB_MAX in predicate. AD.addInclude(AD._DFA_file, "opto/intrinsicnode.hpp"); AD.addInclude(AD._DFA_file, "opto/matcher.hpp"); diff -r 351da897f409 src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp Fri May 10 15:34:17 2019 +0100 +++ b/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp Sat May 11 14:47:50 2019 +0300 @@ -39,6 +39,7 @@ #include "memory/allocation.inline.hpp" #include "memory/iterator.hpp" #include "memory/resourceArea.hpp" +#include "memory/universe.hpp" #include "runtime/thread.hpp" #include "services/management.hpp" diff -r 351da897f409 src/hotspot/share/memory/filemap.cpp --- a/src/hotspot/share/memory/filemap.cpp Fri May 10 15:34:17 2019 +0100 +++ b/src/hotspot/share/memory/filemap.cpp Sat May 11 14:47:50 2019 +0300 @@ -41,6 +41,7 @@ #include "memory/metaspaceClosure.hpp" #include "memory/metaspaceShared.hpp" #include "memory/oopFactory.hpp" +#include "memory/universe.hpp" #include "oops/compressedOops.inline.hpp" #include "oops/objArrayOop.hpp" #include "oops/oop.inline.hpp" diff -r 351da897f409 src/hotspot/share/oops/compressedOops.hpp --- a/src/hotspot/share/oops/compressedOops.hpp Fri May 10 15:34:17 2019 +0100 +++ b/src/hotspot/share/oops/compressedOops.hpp Sat May 11 14:47:50 2019 +0300 @@ -26,6 +26,7 @@ #define SHARE_OOPS_COMPRESSEDOOPS_HPP #include "memory/allocation.hpp" +#include "oops/oopsHierarchy.hpp" #include "utilities/globalDefinitions.hpp" class outputStream; diff -r 351da897f409 src/hotspot/share/runtime/deoptimization.cpp --- a/src/hotspot/share/runtime/deoptimization.cpp Fri May 10 15:34:17 2019 +0100 +++ b/src/hotspot/share/runtime/deoptimization.cpp Sat May 11 14:47:50 2019 +0300 @@ -37,6 +37,7 @@ #include "memory/allocation.inline.hpp" #include "memory/oopFactory.hpp" #include "memory/resourceArea.hpp" +#include "memory/universe.hpp" #include "oops/constantPool.hpp" #include "oops/method.hpp" #include "oops/objArrayKlass.hpp" glaubitz at gcc202:~/jdk$ I could also test Solaris-SPARC, but that would take a tad longer as I would have to go through the process of setting up the build environment on my Solaris LDOM first. But then we would know whether the additional include in src/hotspot/os/solaris/os_solaris.cpp is necessary. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From stefan.karlsson at oracle.com Sat May 11 13:32:23 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Sat, 11 May 2019 15:32:23 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <0e6ad2bd-5b4b-4850-62fc-b1ff7ea23df4@physik.fu-berlin.de> References: <648f58be-0501-698d-4f93-ffbaee968670@physik.fu-berlin.de> <6cf7d02e-98c5-b0a3-349c-12834ed9dd6b@physik.fu-berlin.de> <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> <00b8336a-af4f-7a37-b524-009885e0fcf3@physik.fu-berlin.de> <12626D50-4BC8-4B06-8F6C-19731C07027E@sap.com> <58b27f04-3817-9d16-1dfb-8f7177ee456e@physik.fu-berlin.de> <8b32026c-ccd1-dffa-e555-4fa38f85d842@physik.fu-berlin.de> <0e6ad2bd-5b4b-4850-62fc-b1ff7ea23df4@physik.fu-berlin.de> Message-ID: On 2019-05-11 13:57, John Paul Adrian Glaubitz wrote: > On 5/11/19 1:38 PM, John Paul Adrian Glaubitz wrote: >> I noticed that not all the includes you added are necessary for >> SPARC and I would apply for PPC64 and S390 as well. > assume*, not apply, sorry. But it seems for PPC64 the includes are > necessary. I cannot test S390 at the moment as the filesystem on > Debian's S390 porterbox is full and I can't check the JDK repo. > >> Also, I think the bug should be renamed to include SPARC. The bug was originally named "Fix build breakage after 8223136" and intended to add all missing includes. I've reverted that name, so that we don't get caught in the details about the name of the bug. I think webrev.04 is good enough, and it fixes all breakages we know of. Can we push this now and deal with any further problems in a new RFE? Thanks, StefanK > For Linux SPARC, it builds fine for me with, so the hunks which include > the memory/universe.hpp header the thread SPARC-specific source files > is not necessary. > > glaubitz at gcc202:~/jdk$ hg diff |cat > diff -r 351da897f409 src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp > --- a/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp Fri May 10 15:34:17 2019 +0100 > +++ b/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp Sat May 11 14:47:50 2019 +0300 > @@ -35,7 +35,9 @@ > #include "gc/shared/collectedHeap.hpp" > #include "gc/shared/barrierSet.hpp" > #include "gc/shared/cardTableBarrierSet.hpp" > +#include "memory/universe.hpp" > #include "nativeInst_ppc.hpp" > +#include "oops/compressedOops.hpp" > #include "oops/objArrayKlass.hpp" > #include "runtime/frame.inline.hpp" > #include "runtime/safepointMechanism.inline.hpp" > @@ -1237,7 +1239,7 @@ > int disp_value = addr->disp(); > bool needs_patching = (patch_code != lir_patch_none); > bool compress_oop = (type == T_ARRAY || type == T_OBJECT) && UseCompressedOops && !wide && > - Universe::narrow_oop_mode() != Universe::UnscaledNarrowOop; > + CompressedOops::mode() != CompressedOops::UnscaledNarrowOop; > bool load_disp = addr->index()->is_illegal() && !Assembler::is_simm16(disp_value); > bool use_R29 = compress_oop && load_disp; // Avoid register conflict, also do null check before killing R29. > // Null check for large offsets in LIRGenerator::do_StoreField. > diff -r 351da897f409 src/hotspot/cpu/ppc/macroAssembler_ppc.cpp > --- a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp Fri May 10 15:34:17 2019 +0100 > +++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp Sat May 11 14:47:50 2019 +0300 > @@ -32,7 +32,6 @@ > #include "interpreter/interpreter.hpp" > #include "memory/resourceArea.hpp" > #include "nativeInst_ppc.hpp" > -#include "oops/compressedOops.hpp" > #include "prims/methodHandles.hpp" > #include "runtime/biasedLocking.hpp" > #include "runtime/icache.hpp" > diff -r 351da897f409 src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp > --- a/src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp Fri May 10 15:34:17 2019 +0100 > +++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp Sat May 11 14:47:50 2019 +0300 > @@ -33,6 +33,7 @@ > #include "gc/shared/barrierSet.hpp" > #include "gc/shared/barrierSetAssembler.hpp" > #include "oops/accessDecorators.hpp" > +#include "oops/compressedOops.hpp" > #include "runtime/safepointMechanism.hpp" > > inline bool MacroAssembler::is_ld_largeoffset(address a) { > diff -r 351da897f409 src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp > --- a/src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp Fri May 10 15:34:17 2019 +0100 > +++ b/src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp Sat May 11 14:47:50 2019 +0300 > @@ -35,6 +35,7 @@ > #include "gc/shared/collectedHeap.hpp" > #include "gc/shared/barrierSet.hpp" > #include "gc/shared/cardTableBarrierSet.hpp" > +#include "memory/universe.hpp" > #include "nativeInst_s390.hpp" > #include "oops/objArrayKlass.hpp" > #include "runtime/frame.inline.hpp" > diff -r 351da897f409 src/hotspot/os/solaris/os_solaris.cpp > --- a/src/hotspot/os/solaris/os_solaris.cpp Fri May 10 15:34:17 2019 +0100 > +++ b/src/hotspot/os/solaris/os_solaris.cpp Sat May 11 14:47:50 2019 +0300 > @@ -36,6 +36,7 @@ > #include "logging/logStream.hpp" > #include "memory/allocation.inline.hpp" > #include "memory/filemap.hpp" > +#include "memory/universe.hpp" > #include "oops/oop.inline.hpp" > #include "os_share_solaris.hpp" > #include "os_solaris.inline.hpp" > diff -r 351da897f409 src/hotspot/share/adlc/main.cpp > --- a/src/hotspot/share/adlc/main.cpp Fri May 10 15:34:17 2019 +0100 > +++ b/src/hotspot/share/adlc/main.cpp Sat May 11 14:47:50 2019 +0300 > @@ -217,6 +217,7 @@ > AD.addInclude(AD._CPP_file, "code/vmreg.inline.hpp"); > AD.addInclude(AD._CPP_file, "gc/shared/collectedHeap.inline.hpp"); > AD.addInclude(AD._CPP_file, "oops/compiledICHolder.hpp"); > + AD.addInclude(AD._CPP_file, "oops/compressedOops.hpp"); > AD.addInclude(AD._CPP_file, "oops/markOop.hpp"); > AD.addInclude(AD._CPP_file, "oops/method.hpp"); > AD.addInclude(AD._CPP_file, "oops/oop.inline.hpp"); > @@ -233,6 +234,7 @@ > AD.addInclude(AD._CPP_file, "runtime/stubRoutines.hpp"); > AD.addInclude(AD._CPP_file, "utilities/growableArray.hpp"); > AD.addInclude(AD._HPP_file, "memory/allocation.hpp"); > + AD.addInclude(AD._HPP_file, "oops/compressedOops.hpp"); > AD.addInclude(AD._HPP_file, "code/nativeInst.hpp"); > AD.addInclude(AD._HPP_file, "opto/machnode.hpp"); > AD.addInclude(AD._HPP_file, "opto/node.hpp"); > @@ -243,6 +245,7 @@ > AD.addInclude(AD._CPP_CLONE_file, "adfiles", get_basename(AD._HPP_file._name)); > AD.addInclude(AD._CPP_EXPAND_file, "precompiled.hpp"); > AD.addInclude(AD._CPP_EXPAND_file, "adfiles", get_basename(AD._HPP_file._name)); > + AD.addInclude(AD._CPP_EXPAND_file, "oops/compressedOops.hpp"); > AD.addInclude(AD._CPP_FORMAT_file, "precompiled.hpp"); > AD.addInclude(AD._CPP_FORMAT_file, "adfiles", get_basename(AD._HPP_file._name)); > AD.addInclude(AD._CPP_GEN_file, "precompiled.hpp"); > @@ -257,6 +260,7 @@ > AD.addInclude(AD._CPP_PIPELINE_file, "adfiles", get_basename(AD._HPP_file._name)); > AD.addInclude(AD._DFA_file, "precompiled.hpp"); > AD.addInclude(AD._DFA_file, "adfiles", get_basename(AD._HPP_file._name)); > + AD.addInclude(AD._DFA_file, "oops/compressedOops.hpp"); > AD.addInclude(AD._DFA_file, "opto/cfgnode.hpp"); // Use PROB_MAX in predicate. > AD.addInclude(AD._DFA_file, "opto/intrinsicnode.hpp"); > AD.addInclude(AD._DFA_file, "opto/matcher.hpp"); > diff -r 351da897f409 src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp Fri May 10 15:34:17 2019 +0100 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp Sat May 11 14:47:50 2019 +0300 > @@ -39,6 +39,7 @@ > #include "memory/allocation.inline.hpp" > #include "memory/iterator.hpp" > #include "memory/resourceArea.hpp" > +#include "memory/universe.hpp" > #include "runtime/thread.hpp" > #include "services/management.hpp" > > diff -r 351da897f409 src/hotspot/share/memory/filemap.cpp > --- a/src/hotspot/share/memory/filemap.cpp Fri May 10 15:34:17 2019 +0100 > +++ b/src/hotspot/share/memory/filemap.cpp Sat May 11 14:47:50 2019 +0300 > @@ -41,6 +41,7 @@ > #include "memory/metaspaceClosure.hpp" > #include "memory/metaspaceShared.hpp" > #include "memory/oopFactory.hpp" > +#include "memory/universe.hpp" > #include "oops/compressedOops.inline.hpp" > #include "oops/objArrayOop.hpp" > #include "oops/oop.inline.hpp" > diff -r 351da897f409 src/hotspot/share/oops/compressedOops.hpp > --- a/src/hotspot/share/oops/compressedOops.hpp Fri May 10 15:34:17 2019 +0100 > +++ b/src/hotspot/share/oops/compressedOops.hpp Sat May 11 14:47:50 2019 +0300 > @@ -26,6 +26,7 @@ > #define SHARE_OOPS_COMPRESSEDOOPS_HPP > > #include "memory/allocation.hpp" > +#include "oops/oopsHierarchy.hpp" > #include "utilities/globalDefinitions.hpp" > > class outputStream; > diff -r 351da897f409 src/hotspot/share/runtime/deoptimization.cpp > --- a/src/hotspot/share/runtime/deoptimization.cpp Fri May 10 15:34:17 2019 +0100 > +++ b/src/hotspot/share/runtime/deoptimization.cpp Sat May 11 14:47:50 2019 +0300 > @@ -37,6 +37,7 @@ > #include "memory/allocation.inline.hpp" > #include "memory/oopFactory.hpp" > #include "memory/resourceArea.hpp" > +#include "memory/universe.hpp" > #include "oops/constantPool.hpp" > #include "oops/method.hpp" > #include "oops/objArrayKlass.hpp" > glaubitz at gcc202:~/jdk$ > > I could also test Solaris-SPARC, but that would take a tad longer as I would > have to go through the process of setting up the build environment on my Solaris > LDOM first. But then we would know whether the additional include in > src/hotspot/os/solaris/os_solaris.cpp is necessary. > > Adrian > From glaubitz at physik.fu-berlin.de Sat May 11 13:35:41 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Sat, 11 May 2019 15:35:41 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: References: <6cf7d02e-98c5-b0a3-349c-12834ed9dd6b@physik.fu-berlin.de> <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> <00b8336a-af4f-7a37-b524-009885e0fcf3@physik.fu-berlin.de> <12626D50-4BC8-4B06-8F6C-19731C07027E@sap.com> <58b27f04-3817-9d16-1dfb-8f7177ee456e@physik.fu-berlin.de> <8b32026c-ccd1-dffa-e555-4fa38f85d842@physik.fu-berlin.de> <0e6ad2bd-5b4b-4850-62fc-b1ff7ea23df4@physik.fu-berlin.de> Message-ID: <4d9e84b9-29cc-d6e8-c39e-1573f5974179@physik.fu-berlin.de> On 5/11/19 3:32 PM, Stefan Karlsson wrote: > The bug was originally named "Fix build breakage after 8223136" and intended to add all missing includes. I've reverted that name, so that we don't get caught in the details about the name of the bug. I think webrev.04 is good enough, and it fixes all breakages we know of. Can we push this now and deal with any further problems in a new RFE? Well, you would be adding #includes for SPARC that aren't necessary. I can, of course, send another RFR to clean the change up again but since I already verified it to work, I think you can just remove the changes for SPARC (except for the Solaris one but that one seems arch-agnostic). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From stefan.karlsson at oracle.com Sat May 11 13:41:13 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Sat, 11 May 2019 15:41:13 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <4d9e84b9-29cc-d6e8-c39e-1573f5974179@physik.fu-berlin.de> References: <6cf7d02e-98c5-b0a3-349c-12834ed9dd6b@physik.fu-berlin.de> <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> <00b8336a-af4f-7a37-b524-009885e0fcf3@physik.fu-berlin.de> <12626D50-4BC8-4B06-8F6C-19731C07027E@sap.com> <58b27f04-3817-9d16-1dfb-8f7177ee456e@physik.fu-berlin.de> <8b32026c-ccd1-dffa-e555-4fa38f85d842@physik.fu-berlin.de> <0e6ad2bd-5b4b-4850-62fc-b1ff7ea23df4@physik.fu-berlin.de> <4d9e84b9-29cc-d6e8-c39e-1573f5974179@physik.fu-berlin.de> Message-ID: <2d7613e8-9fc7-cbb1-5295-7cb30431a8d3@oracle.com> On 2019-05-11 15:35, John Paul Adrian Glaubitz wrote: > On 5/11/19 3:32 PM, Stefan Karlsson wrote: >> The bug was originally named "Fix build breakage after 8223136" and intended to add all missing includes. I've reverted that name, so that we don't get caught in the details about the name of the bug. I think webrev.04 is good enough, and it fixes all breakages we know of. Can we push this now and deal with any further problems in a new RFE? > Well, you would be adding #includes for SPARC that aren't necessary. Please, show me exactly what you want to change, with a webrev based on top of the patch in webrev.04. Thanks, StefanK > > I can, of course, send another RFR to clean the change up again but > since I already verified it to work, I think you can just remove > the changes for SPARC (except for the Solaris one but that one seems > arch-agnostic). > > Adrian > From glaubitz at physik.fu-berlin.de Sat May 11 14:32:13 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Sat, 11 May 2019 16:32:13 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <2d7613e8-9fc7-cbb1-5295-7cb30431a8d3@oracle.com> References: <6cf7d02e-98c5-b0a3-349c-12834ed9dd6b@physik.fu-berlin.de> <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> <00b8336a-af4f-7a37-b524-009885e0fcf3@physik.fu-berlin.de> <12626D50-4BC8-4B06-8F6C-19731C07027E@sap.com> <58b27f04-3817-9d16-1dfb-8f7177ee456e@physik.fu-berlin.de> <8b32026c-ccd1-dffa-e555-4fa38f85d842@physik.fu-berlin.de> <0e6ad2bd-5b4b-4850-62fc-b1ff7ea23df4@physik.fu-berlin.de> <4d9e84b9-29cc-d6e8-c39e-1573f5974179@physik.fu-berlin.de> <2d7613e8-9fc7-cbb1-5295-7cb30431a8d3@oracle.com> Message-ID: On 5/11/19 3:41 PM, Stefan Karlsson wrote: >> Well, you would be adding #includes for SPARC that aren't necessary. > > Please, show me exactly what you want to change, with a webrev based on top of the patch in webrev.04. This works for me: http://cr.openjdk.java.net/~glaubitz/8223637/webrev.01/ Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From stefan.karlsson at oracle.com Mon May 13 08:21:57 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 13 May 2019 10:21:57 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: References: <6cf7d02e-98c5-b0a3-349c-12834ed9dd6b@physik.fu-berlin.de> <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> <00b8336a-af4f-7a37-b524-009885e0fcf3@physik.fu-berlin.de> <12626D50-4BC8-4B06-8F6C-19731C07027E@sap.com> <58b27f04-3817-9d16-1dfb-8f7177ee456e@physik.fu-berlin.de> <8b32026c-ccd1-dffa-e555-4fa38f85d842@physik.fu-berlin.de> <0e6ad2bd-5b4b-4850-62fc-b1ff7ea23df4@physik.fu-berlin.de> <4d9e84b9-29cc-d6e8-c39e-1573f5974179@physik.fu-berlin.de> <2d7613e8-9fc7-cbb1-5295-7cb30431a8d3@oracle.com> Message-ID: <145f8369-db31-a1bd-68a7-460f5b7b405c@oracle.com> On 2019-05-11 16:32, John Paul Adrian Glaubitz wrote: > On 5/11/19 3:41 PM, Stefan Karlsson wrote: >>> Well, you would be adding #includes for SPARC that aren't necessary. >> >> Please, show me exactly what you want to change, with a webrev based on top of the patch in webrev.04. > This works for me: http://cr.openjdk.java.net/~glaubitz/8223637/webrev.01/ Since you didn't base this patch on top of my patch, I had to go through all files to figure out what you changed. As far as I can see you also removed the universe.hpp include in c1_LIRAssembler_sparc.cpp, which uses Universe. This change would force me to unnecessarily retest the patch, and I don't want to do that. The other change I've found is thread_linux_sparc.cpp. I'm OK with that change, and it doesn't invalidate my or Lutz's testing. Patch with which only changes thread_linux_sparc.cpp. http://cr.openjdk.java.net/~stefank/8223637/webrev.05.delta/ http://cr.openjdk.java.net/~stefank/8223637/webrev.05/ StefanK > > Adrian > From boris.ulasevich at bell-sw.com Mon May 13 08:30:20 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Mon, 13 May 2019 11:30:20 +0300 Subject: RFR (S) 8223472: volatile long field corruption on x86_32 In-Reply-To: <12028291-5388-d87d-65cd-25e2e3f1b0bd@oracle.com> References: <12028291-5388-d87d-65cd-25e2e3f1b0bd@oracle.com> Message-ID: <91a3bf72-e778-829f-4928-1068d1f4a91a@bell-sw.com> Hi Coleen, I added short comment, thanks! And yes, from first look it seems that double load/store needs to be marked MO_RELAXED as well, but on x86 fstp/fld is atomic, so no extra flag is actually need. thank you, Boris On 08.05.2019 16:56, coleen.phillimore at oracle.com wrote: > > I just had a look at this and it looks unsettlingly random without a > short comment why MO_RELAXED is needed for long and not the others. Is > it because on 32 bits, double is two words that have to be atomically > stored?? Would a volatile double have the same problem? I see > getfield_or_static has the MO_RELAXED and a comment, so that's good.? I > don't need to see a new version if you add a *short* comment like this. > > Thanks, > Coleen > > > On 5/8/19 4:17 AM, Boris Ulasevich wrote: >> Hi all, >> >> Please review a simple change to fix long field store atomicity for >> 32-bit x86 interpreter. >> >> http://bugs.openjdk.java.net/browse/JDK-8223472 >> http://cr.openjdk.java.net/~bulasevich/8223472/webrev.00 >> >> thanks, >> Boris > From david.holmes at oracle.com Mon May 13 08:34:39 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 May 2019 18:34:39 +1000 Subject: RFR (S) 8223472: volatile long field corruption on x86_32 In-Reply-To: <91a3bf72-e778-829f-4928-1068d1f4a91a@bell-sw.com> References: <12028291-5388-d87d-65cd-25e2e3f1b0bd@oracle.com> <91a3bf72-e778-829f-4928-1068d1f4a91a@bell-sw.com> Message-ID: <3058c160-a098-00f7-96cb-34b12a032c62@oracle.com> On 13/05/2019 6:30 pm, Boris Ulasevich wrote: > Hi Coleen, > > I added short comment, thanks! And yes, from first look it seems that > double load/store needs to be marked MO_RELAXED as well, but on x86 > fstp/fld is atomic, so no extra flag is actually need. It may not actually be needed because of the underlying implementation but the requirement should still be captured with MO_RELAXED IMHO. Cheers, David > thank you, > Boris > > On 08.05.2019 16:56, coleen.phillimore at oracle.com wrote: >> >> I just had a look at this and it looks unsettlingly random without a >> short comment why MO_RELAXED is needed for long and not the others. Is >> it because on 32 bits, double is two words that have to be atomically >> stored?? Would a volatile double have the same problem? I see >> getfield_or_static has the MO_RELAXED and a comment, so that's good. >> I don't need to see a new version if you add a *short* comment like this. >> >> Thanks, >> Coleen >> >> >> On 5/8/19 4:17 AM, Boris Ulasevich wrote: >>> Hi all, >>> >>> Please review a simple change to fix long field store atomicity for >>> 32-bit x86 interpreter. >>> >>> http://bugs.openjdk.java.net/browse/JDK-8223472 >>> http://cr.openjdk.java.net/~bulasevich/8223472/webrev.00 >>> >>> thanks, >>> Boris >> From glaubitz at physik.fu-berlin.de Mon May 13 09:40:50 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 13 May 2019 11:40:50 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <145f8369-db31-a1bd-68a7-460f5b7b405c@oracle.com> References: <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> <00b8336a-af4f-7a37-b524-009885e0fcf3@physik.fu-berlin.de> <12626D50-4BC8-4B06-8F6C-19731C07027E@sap.com> <58b27f04-3817-9d16-1dfb-8f7177ee456e@physik.fu-berlin.de> <8b32026c-ccd1-dffa-e555-4fa38f85d842@physik.fu-berlin.de> <0e6ad2bd-5b4b-4850-62fc-b1ff7ea23df4@physik.fu-berlin.de> <4d9e84b9-29cc-d6e8-c39e-1573f5974179@physik.fu-berlin.de> <2d7613e8-9fc7-cbb1-5295-7cb30431a8d3@oracle.com> <145f8369-db31-a1bd-68a7-460f5b7b405c@oracle.com> Message-ID: <686a5cba-b492-c027-5758-5e110de9f063@physik.fu-berlin.de> On 5/13/19 10:21 AM, Stefan Karlsson wrote: > On 2019-05-11 16:32, John Paul Adrian Glaubitz wrote: > Since you didn't base this patch on top of my patch, I had to go through all files to figure out what you changed. Ah, you wanted to have a diff against your patch. I misunderstood you then. > As far as I can see you also removed the universe.hpp include in c1_LIRAssembler_sparc.cpp, which uses Universe. This change would force me to unnecessarily retest the patch, and I don't want to do that. Which targets does your test include? As I said before, I can test any Linux target (the s390x is free again) and I will be able to test Solaris soonish (need to set up the build environment first). The only thing I can't test is AIX because AIX isn't really available to anyone outside the enterprise world. > The other change I've found is thread_linux_sparc.cpp. I'm OK with that change, and it doesn't invalidate my or Lutz's testing. > > Patch with which only changes thread_linux_sparc.cpp. > ?http://cr.openjdk.java.net/~stefank/8223637/webrev.05.delta/ > ?http://cr.openjdk.java.net/~stefank/8223637/webrev.05/ Works for me on: - linux-sparc - linux-s390x - linux-x86_64 - linux-ppc64el - linux-ppc64 Also tested Zero on x86_64, ppc64el and s390x. Those were release builds. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From tobias.hartmann at oracle.com Mon May 13 09:58:53 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 13 May 2019 11:58:53 +0200 Subject: RFC: JWarmup precompile java hot methods at application startup In-Reply-To: References: Message-ID: <8cfbaa83-c50f-61c4-5336-5f30b3885d45@oracle.com> 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. 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? 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? graphKit.cpp - line 2832: please add a comment - line 2917: checks should be merged into one if and please add a comment 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"? symbolMatcher.cpp: - What is test_symbol_matcher() used for? 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? 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 Thanks, Tobias From lutz.schmidt at sap.com Mon May 13 10:03:02 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Mon, 13 May 2019 10:03:02 +0000 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <686a5cba-b492-c027-5758-5e110de9f063@physik.fu-berlin.de> References: <4CF731CD-2D11-4F30-AA68-D075FFBB2FD5@sap.com> <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> <00b8336a-af4f-7a37-b524-009885e0fcf3@physik.fu-berlin.de> <12626D50-4BC8-4B06-8F6C-19731C07027E@sap.com> <58b27f04-3817-9d16-1dfb-8f7177ee456e@physik.fu-berlin.de> <8b32026c-ccd1-dffa-e555-4fa38f85d842@physik.fu-berlin.de> <0e6ad2bd-5b4b-4850-62fc-b1ff7ea23df4@physik.fu-berlin.de> <4d9e84b9-29cc-d6e8-c39e-1573f5974179@physik.fu-berlin.de> <2d7613e8-9fc7-cbb1-5295-7cb30431a8d3@oracle.com> <145f8369-db31-a1bd-68a7-460f5b7b405c@oracle.com> <686a5cba-b492-c027-5758-5e110de9f063@physik.fu-berlin.de> Message-ID: <822F6BC7-DE24-416F-8502-B4C6B5681E7F@sap.com> Hi, on Saturday, I tested AIX with webrev.04, fastdebug and release builds. Both finished ok. Had no chance/time to run tests in excess of java -version. Webrev.05 differs from webrev.04 only for linux_sparc/thread_linux_sparc.cpp. I'm pretty sure this will not have any effect on the AIX builds. :-) We have restarted builds/tests with webrev.05 for some platforms, in particular AIX. We will post results as they become available. Regards, Lutz ?On 13.05.19, 11:40, "John Paul Adrian Glaubitz" wrote: On 5/13/19 10:21 AM, Stefan Karlsson wrote: > On 2019-05-11 16:32, John Paul Adrian Glaubitz wrote: > Since you didn't base this patch on top of my patch, I had to go through all files to figure out what you changed. Ah, you wanted to have a diff against your patch. I misunderstood you then. > As far as I can see you also removed the universe.hpp include in c1_LIRAssembler_sparc.cpp, which uses Universe. This change would force me to unnecessarily retest the patch, and I don't want to do that. Which targets does your test include? As I said before, I can test any Linux target (the s390x is free again) and I will be able to test Solaris soonish (need to set up the build environment first). The only thing I can't test is AIX because AIX isn't really available to anyone outside the enterprise world. > The other change I've found is thread_linux_sparc.cpp. I'm OK with that change, and it doesn't invalidate my or Lutz's testing. > > Patch with which only changes thread_linux_sparc.cpp. > http://cr.openjdk.java.net/~stefank/8223637/webrev.05.delta/ > http://cr.openjdk.java.net/~stefank/8223637/webrev.05/ Works for me on: - linux-sparc - linux-s390x - linux-x86_64 - linux-ppc64el - linux-ppc64 Also tested Zero on x86_64, ppc64el and s390x. Those were release builds. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From stefan.karlsson at oracle.com Mon May 13 10:08:21 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 13 May 2019 12:08:21 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <686a5cba-b492-c027-5758-5e110de9f063@physik.fu-berlin.de> References: <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> <00b8336a-af4f-7a37-b524-009885e0fcf3@physik.fu-berlin.de> <12626D50-4BC8-4B06-8F6C-19731C07027E@sap.com> <58b27f04-3817-9d16-1dfb-8f7177ee456e@physik.fu-berlin.de> <8b32026c-ccd1-dffa-e555-4fa38f85d842@physik.fu-berlin.de> <0e6ad2bd-5b4b-4850-62fc-b1ff7ea23df4@physik.fu-berlin.de> <4d9e84b9-29cc-d6e8-c39e-1573f5974179@physik.fu-berlin.de> <2d7613e8-9fc7-cbb1-5295-7cb30431a8d3@oracle.com> <145f8369-db31-a1bd-68a7-460f5b7b405c@oracle.com> <686a5cba-b492-c027-5758-5e110de9f063@physik.fu-berlin.de> Message-ID: On 2019-05-13 11:40, John Paul Adrian Glaubitz wrote: > On 5/13/19 10:21 AM, Stefan Karlsson wrote: >> On 2019-05-11 16:32, John Paul Adrian Glaubitz wrote: >> Since you didn't base this patch on top of my patch, I had to go through all files to figure out what you changed. > > Ah, you wanted to have a diff against your patch. I misunderstood you then. > >> As far as I can see you also removed the universe.hpp include in c1_LIRAssembler_sparc.cpp, which uses Universe. This change would force me to unnecessarily retest the patch, and I don't want to do that. > > Which targets does your test include? > > As I said before, I can test any Linux target (the s390x is free again) > and I will be able to test Solaris soonish (need to set up the build > environment first). Regarding sparc testing, I've tested Solaris Sparcv9 with fastdebug and release. > > The only thing I can't test is AIX because AIX isn't really available > to anyone outside the enterprise world. > >> The other change I've found is thread_linux_sparc.cpp. I'm OK with that change, and it doesn't invalidate my or Lutz's testing. >> >> Patch with which only changes thread_linux_sparc.cpp. >> ?http://cr.openjdk.java.net/~stefank/8223637/webrev.05.delta/ >> ?http://cr.openjdk.java.net/~stefank/8223637/webrev.05/ > > Works for me on: > > - linux-sparc > - linux-s390x > - linux-x86_64 > - linux-ppc64el > - linux-ppc64 > > Also tested Zero on x86_64, ppc64el and s390x. > > Those were release builds. Great. Then we're just waiting for Lutz to say go. Thanks, StefanK > > Adrian > From glaubitz at physik.fu-berlin.de Mon May 13 10:36:30 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 13 May 2019 12:36:30 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: References: <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> <00b8336a-af4f-7a37-b524-009885e0fcf3@physik.fu-berlin.de> <12626D50-4BC8-4B06-8F6C-19731C07027E@sap.com> <58b27f04-3817-9d16-1dfb-8f7177ee456e@physik.fu-berlin.de> <8b32026c-ccd1-dffa-e555-4fa38f85d842@physik.fu-berlin.de> <0e6ad2bd-5b4b-4850-62fc-b1ff7ea23df4@physik.fu-berlin.de> <4d9e84b9-29cc-d6e8-c39e-1573f5974179@physik.fu-berlin.de> <2d7613e8-9fc7-cbb1-5295-7cb30431a8d3@oracle.com> <145f8369-db31-a1bd-68a7-460f5b7b405c@oracle.com> <686a5cba-b492-c027-5758-5e110de9f063@physik.fu-berlin.de> Message-ID: On 5/13/19 12:08 PM, Stefan Karlsson wrote: >> As I said before, I can test any Linux target (the s390x is free again) >> and I will be able to test Solaris soonish (need to set up the build >> environment first). > > Regarding sparc testing, I've tested Solaris Sparcv9 with fastdebug and release. That reminds me: I should set up a build environment on my Solaris LDOM so I can test solaris-sparcv9 as well. I hope that Solaris 11.3 is still recent enough to build OpenJDK as I can't upgrade my T5240 to 11.4. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From erik.osterlund at oracle.com Mon May 13 12:54:46 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 13 May 2019 14:54:46 +0200 Subject: RFR: 8222841: Incorrect static call stub interactions with class unloading In-Reply-To: References: <067fc16e-3104-4e61-b558-9cd4864f079f@oracle.com> <1ca35306-6be8-61ec-127f-196367d94899@oracle.com> <6f615499-6f79-ce41-d835-d64e0741a3be@oracle.com> <04c23dad-67b2-f4eb-7d6f-6f24d57bbd5b@oracle.com> Message-ID: Hi Vladimir, Thanks for the review. I removed the unnecessary rtmp: http://cr.openjdk.java.net/~eosterlund/8222841/webrev.02/ Incremental: http://cr.openjdk.java.net/~eosterlund/8222841/webrev.01_02/ Testing: I ran hs-tier[1-6], and attached the rest results to the bug. I went through all failures to make sure I did not introduce any. Thanks, /Erik On 2019-05-10 01:56, Vladimir Kozlov wrote: > Hi Erik, > > I general looks good to me. One comment: > > rtmp register seems unused in load_method_holder_cld() > > What testing you did? There are no link to testing results in RFE. > > Thanks, > Vladimir > > On 5/9/19 3:33 PM, Erik Osterlund wrote: >> Any more takers? I know you want this stuff. >> >> /Erik >> >>> On 8 May 2019, at 14:20, Erik ?sterlund >>> wrote: >>> >>> Hi Coleen, >>> >>> Thanks for the review! >>> >>> /Erik >>> >>>> On 2019-05-08 14:16, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>>> On 5/2/19 4:55 AM, Erik ?sterlund wrote: >>>>> Hi Coleen, >>>>> >>>>> Thank you for the review. >>>>> >>>>>> On 2019-04-23 23:32, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp.frames.html >>>>>> >>>>>> >>>>>> Can you mention in a comment that incoming rbx is the method? >>>>> >>>>> Fixed. >>>> >>>> Thank you! >>>>> >>>>>> You can't do a JRT_LEAF function from here, can you to some >>>>>> Method::is_alive() function? Or even a straight up call ?? This >>>>>> doesn't seem that it should care about the extra overhead of the >>>>>> call instruction.? The assembly code looks correct but yuck not >>>>>> more assembly code. >>>>> >>>>> I'm not sure I know how I feel about that. I would have to save >>>>> and restore all registers then to go into the runtime just to >>>>> check if the method is alive. Would you be okay with keeping the >>>>> assembly variant instead until I find a better solution to this >>>>> problem? (I'm on it) >>>> >>>> Yes, this is fine with me.? Had to register not liking more assembly. >>>>> >>>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/src/hotspot/share/code/compiledMethod.cpp.frames.html >>>>>> >>>>>> >>>>>> 578 case relocInfo::static_stub_type: { >>>>>> 579 is_in_static_stub = true; >>>>>> 580 break; >>>>>> 581 } >>>>>> 582 >>>>>> 583 case relocInfo::metadata_type: { >>>>>> 584 if (!is_in_static_stub) { >>>>>> 585 continue; >>>>>> 586 } >>>>>> >>>>>> >>>>>> This was mystifying to me.? Can you put a comment that after >>>>>> static_stub_type relocations are generated, the next metadata >>>>>> relocation contains the address that is patched at runtime, so >>>>>> this is the metadata that can be stale and should be cleared by >>>>>> unloading. >>>>> >>>>> Sure, I updated the comments, and added a better description about >>>>> what is going on here. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.01/ >>>>> >>>>> Incremental: >>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00_01/ >>>> >>>> Looks good! >>>> Coleen >>>>> >>>>> Thanks, >>>>> /Erik >>>>> >>>>>> The clean_ic_stubs() name is my fault. I didn't know what they >>>>>> were and just wanted this code out of my way. >>>>>> >>>>>> Thank you for explaining how redefinition is broken by this. I >>>>>> didn't know these metadata_reloc guys were patched at runtime. >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> >>>>>> >>>>>>> On 4/23/19 4:41 AM, Erik ?sterlund wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Static call stubs are cleared in debug builds before an assert >>>>>>> checking for dead metadata. This is done in the function >>>>>>> "clean_ic_stubs()" (which does not clean ICStubs... but >>>>>>> static/optimized virtual call stubs for calling c2i adapters >>>>>>> from compiled code...) The reason is that the static call stub >>>>>>> has metadata, and it complains about dead metadata being left >>>>>>> after inline cache cleaning of is_alive nmethods. >>>>>>> >>>>>>> ...except class redefinition looks at this metadata to determine >>>>>>> if there is old metadata in subsequent safepoints, and they >>>>>>> could have been unloaded then. Ouch. So maybe we shouldn't >>>>>>> squelch that assert in debug builds, because it actually shows >>>>>>> there is a real problem. >>>>>>> >>>>>>> ...and with concurrent class unloading (ZGC and seemingly soon >>>>>>> Shenandoah), we can't just clear the call stub of a concurrently >>>>>>> running JavaThread; they can racingly call in to them before >>>>>>> they get cleared, and then get stuck in an infinite loop, >>>>>>> because clearing also involves updating the branch target of the >>>>>>> static call stub to a self-loop. Or call a dead method, which >>>>>>> also seems like a scary scenario. >>>>>>> >>>>>>> All things considered, clearing static call stubs when unloading >>>>>>> the code cache seems like a bad idea. >>>>>>> >>>>>>> My proposal is the following: >>>>>>> 1) Make sure that code cache unloading *always* clears out the >>>>>>> metadata part (but not the branch part) of static call stubs, so >>>>>>> that subsequent operations such as class redefinition will not >>>>>>> blow up when looking at the embedded metadata, but it won't get >>>>>>> stuck in infinite loops with concurrent code cache unloading. >>>>>>> 2) Make a c2i entry barrier for concurrently unloading GCs that >>>>>>> will reresolve the call when calling into a stale static call >>>>>>> stub (iff method is NULL or dead). >>>>>>> 3) Relax MT-safety asserts to allow the previous medatada to be >>>>>>> concurrently unloading when setting the new target. >>>>>>> >>>>>>> Bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8222841 >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> /Erik >>>>>> >>>>> >>>> >>> >> From lutz.schmidt at sap.com Mon May 13 12:59:03 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Mon, 13 May 2019 12:59:03 +0000 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: References: <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> <00b8336a-af4f-7a37-b524-009885e0fcf3@physik.fu-berlin.de> <12626D50-4BC8-4B06-8F6C-19731C07027E@sap.com> <58b27f04-3817-9d16-1dfb-8f7177ee456e@physik.fu-berlin.de> <8b32026c-ccd1-dffa-e555-4fa38f85d842@physik.fu-berlin.de> <0e6ad2bd-5b4b-4850-62fc-b1ff7ea23df4@physik.fu-berlin.de> <4d9e84b9-29cc-d6e8-c39e-1573f5974179@physik.fu-berlin.de> <2d7613e8-9fc7-cbb1-5295-7cb30431a8d3@oracle.com> <145f8369-db31-a1bd-68a7-460f5b7b405c@oracle.com> <686a5cba-b492-c027-5758-5e110de9f063@physik.fu-berlin.de> Message-ID: <9912FA08-D8A8-4B32-8E0F-E7598895E15B@sap.com> Go! Linuxppc, linuxppcle, linuxs390x, linuxx84_64, rs6000_64, sun_64 (Solaris_SPARC), all built as fastdebug and release, all green. Tests still running (will not finish in due time), no anomalies so far. Thanks, Lutz ?On 13.05.19, 12:08, "Stefan Karlsson" wrote: On 2019-05-13 11:40, John Paul Adrian Glaubitz wrote: > On 5/13/19 10:21 AM, Stefan Karlsson wrote: >> On 2019-05-11 16:32, John Paul Adrian Glaubitz wrote: >> Since you didn't base this patch on top of my patch, I had to go through all files to figure out what you changed. > > Ah, you wanted to have a diff against your patch. I misunderstood you then. > >> As far as I can see you also removed the universe.hpp include in c1_LIRAssembler_sparc.cpp, which uses Universe. This change would force me to unnecessarily retest the patch, and I don't want to do that. > > Which targets does your test include? > > As I said before, I can test any Linux target (the s390x is free again) > and I will be able to test Solaris soonish (need to set up the build > environment first). Regarding sparc testing, I've tested Solaris Sparcv9 with fastdebug and release. > > The only thing I can't test is AIX because AIX isn't really available > to anyone outside the enterprise world. > >> The other change I've found is thread_linux_sparc.cpp. I'm OK with that change, and it doesn't invalidate my or Lutz's testing. >> >> Patch with which only changes thread_linux_sparc.cpp. >> http://cr.openjdk.java.net/~stefank/8223637/webrev.05.delta/ >> http://cr.openjdk.java.net/~stefank/8223637/webrev.05/ > > Works for me on: > > - linux-sparc > - linux-s390x > - linux-x86_64 > - linux-ppc64el > - linux-ppc64 > > Also tested Zero on x86_64, ppc64el and s390x. > > Those were release builds. Great. Then we're just waiting for Lutz to say go. Thanks, StefanK > > Adrian > From boris.ulasevich at bell-sw.com Mon May 13 13:57:15 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Mon, 13 May 2019 16:57:15 +0300 Subject: RFR (S) 8223472: volatile long field corruption on x86_32 In-Reply-To: <3058c160-a098-00f7-96cb-34b12a032c62@oracle.com> References: <12028291-5388-d87d-65cd-25e2e3f1b0bd@oracle.com> <91a3bf72-e778-829f-4928-1068d1f4a91a@bell-sw.com> <3058c160-a098-00f7-96cb-34b12a032c62@oracle.com> Message-ID: <1296c2db-b8f6-5d9e-f01b-5c25129f585d@bell-sw.com> Ok. Here is the updated patch with MO_RELAXED access decorator for T_DOUBLE load/store: http://cr.openjdk.java.net/~bulasevich/8223472/webrev.02 thanks, Boris On 13.05.2019 11:34, David Holmes wrote: > On 13/05/2019 6:30 pm, Boris Ulasevich wrote: >> Hi Coleen, >> >> I added short comment, thanks! And yes, from first look it seems that >> double load/store needs to be marked MO_RELAXED as well, but on x86 >> fstp/fld is atomic, so no extra flag is actually need. > > It may not actually be needed because of the underlying implementation > but the requirement should still be captured with MO_RELAXED IMHO. > > Cheers, > David > >> thank you, >> Boris >> >> On 08.05.2019 16:56, coleen.phillimore at oracle.com wrote: >>> >>> I just had a look at this and it looks unsettlingly random without a >>> short comment why MO_RELAXED is needed for long and not the others. >>> Is it because on 32 bits, double is two words that have to be >>> atomically stored?? Would a volatile double have the same problem? I >>> see getfield_or_static has the MO_RELAXED and a comment, so that's >>> good. I don't need to see a new version if you add a *short* comment >>> like this. >>> >>> Thanks, >>> Coleen >>> >>> >>> On 5/8/19 4:17 AM, Boris Ulasevich wrote: >>>> Hi all, >>>> >>>> Please review a simple change to fix long field store atomicity for >>>> 32-bit x86 interpreter. >>>> >>>> http://bugs.openjdk.java.net/browse/JDK-8223472 >>>> http://cr.openjdk.java.net/~bulasevich/8223472/webrev.00 >>>> >>>> thanks, >>>> Boris >>> From coleen.phillimore at oracle.com Mon May 13 14:50:08 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 13 May 2019 10:50:08 -0400 Subject: RFR (S) 8223472: volatile long field corruption on x86_32 In-Reply-To: <1296c2db-b8f6-5d9e-f01b-5c25129f585d@bell-sw.com> References: <12028291-5388-d87d-65cd-25e2e3f1b0bd@oracle.com> <91a3bf72-e778-829f-4928-1068d1f4a91a@bell-sw.com> <3058c160-a098-00f7-96cb-34b12a032c62@oracle.com> <1296c2db-b8f6-5d9e-f01b-5c25129f585d@bell-sw.com> Message-ID: This looks good to me. Thanks, Coleen On 5/13/19 9:57 AM, Boris Ulasevich wrote: > Ok. Here is the updated patch with MO_RELAXED access decorator for > T_DOUBLE load/store: > http://cr.openjdk.java.net/~bulasevich/8223472/webrev.02 > > thanks, > Boris > > On 13.05.2019 11:34, David Holmes wrote: >> On 13/05/2019 6:30 pm, Boris Ulasevich wrote: >>> Hi Coleen, >>> >>> I added short comment, thanks! And yes, from first look it seems >>> that double load/store needs to be marked MO_RELAXED as well, but on >>> x86 fstp/fld is atomic, so no extra flag is actually need. >> >> It may not actually be needed because of the underlying >> implementation but the requirement should still be captured with >> MO_RELAXED IMHO. >> >> Cheers, >> David >> >>> thank you, >>> Boris >>> >>> On 08.05.2019 16:56, coleen.phillimore at oracle.com wrote: >>>> >>>> I just had a look at this and it looks unsettlingly random without >>>> a short comment why MO_RELAXED is needed for long and not the >>>> others. Is it because on 32 bits, double is two words that have to >>>> be atomically stored?? Would a volatile double have the same >>>> problem? I see getfield_or_static has the MO_RELAXED and a comment, >>>> so that's good. I don't need to see a new version if you add a >>>> *short* comment like this. >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>>> On 5/8/19 4:17 AM, Boris Ulasevich wrote: >>>>> Hi all, >>>>> >>>>> Please review a simple change to fix long field store atomicity >>>>> for 32-bit x86 interpreter. >>>>> >>>>> http://bugs.openjdk.java.net/browse/JDK-8223472 >>>>> http://cr.openjdk.java.net/~bulasevich/8223472/webrev.00 >>>>> >>>>> thanks, >>>>> Boris >>>> From shade at redhat.com Mon May 13 14:52:21 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 13 May 2019 16:52:21 +0200 Subject: RFR (S) 8223472: volatile long field corruption on x86_32 In-Reply-To: <1296c2db-b8f6-5d9e-f01b-5c25129f585d@bell-sw.com> References: <12028291-5388-d87d-65cd-25e2e3f1b0bd@oracle.com> <91a3bf72-e778-829f-4928-1068d1f4a91a@bell-sw.com> <3058c160-a098-00f7-96cb-34b12a032c62@oracle.com> <1296c2db-b8f6-5d9e-f01b-5c25129f585d@bell-sw.com> Message-ID: <654ed16f-d39d-ccf6-671d-784000ef56d0@redhat.com> On 5/13/19 3:57 PM, Boris Ulasevich wrote: > Ok. Here is the updated patch with MO_RELAXED access decorator for T_DOUBLE load/store: > http://cr.openjdk.java.net/~bulasevich/8223472/webrev.02 Still looks good. -Aleksey From derekw at marvell.com Mon May 13 15:52:00 2019 From: derekw at marvell.com (Derek White) Date: Mon, 13 May 2019 15:52:00 +0000 Subject: [EXT] Re: RFR: 8222841: Incorrect static call stub interactions with class unloading In-Reply-To: References: <067fc16e-3104-4e61-b558-9cd4864f079f@oracle.com> <1ca35306-6be8-61ec-127f-196367d94899@oracle.com> <6f615499-6f79-ce41-d835-d64e0741a3be@oracle.com> <04c23dad-67b2-f4eb-7d6f-6f24d57bbd5b@oracle.com> Message-ID: Hi Erik, I'm doing pseudo-triage, so haven't followed all of the details here, but: The fix seems x86 specific - not even any SPARC code, but the bug isn't marked x86. Is the bug x86 specific, or should other ports dig into this too? Thanks! - Derek > -----Original Message----- > From: hotspot-dev On Behalf Of > Erik ?sterlund > Sent: Monday, May 13, 2019 8:55 AM > To: Vladimir Kozlov ; hotspot- > dev at openjdk.java.net > Subject: [EXT] Re: RFR: 8222841: Incorrect static call stub interactions with > class unloading > > External Email > > ---------------------------------------------------------------------- > Hi Vladimir, > > Thanks for the review. > I removed the unnecessary rtmp: > http://cr.openjdk.java.net/~eosterlund/8222841/webrev.02/ > > Incremental: > http://cr.openjdk.java.net/~eosterlund/8222841/webrev.01_02/ > > Testing: I ran hs-tier[1-6], and attached the rest results to the bug. I went > through all failures to make sure I did not introduce any. > > Thanks, > /Erik > > > On 2019-05-10 01:56, Vladimir Kozlov wrote: > > Hi Erik, > > > > I general looks good to me. One comment: > > > > rtmp register seems unused in load_method_holder_cld() > > > > What testing you did? There are no link to testing results in RFE. > > > > Thanks, > > Vladimir > > > > On 5/9/19 3:33 PM, Erik Osterlund wrote: > >> Any more takers? I know you want this stuff. > >> > >> /Erik > >> > >>> On 8 May 2019, at 14:20, Erik ?sterlund > >>> wrote: > >>> > >>> Hi Coleen, > >>> > >>> Thanks for the review! > >>> > >>> /Erik > >>> > >>>> On 2019-05-08 14:16, coleen.phillimore at oracle.com wrote: > >>>> > >>>> > >>>>> On 5/2/19 4:55 AM, Erik ?sterlund wrote: > >>>>> Hi Coleen, > >>>>> > >>>>> Thank you for the review. > >>>>> > >>>>>> On 2019-04-23 23:32, coleen.phillimore at oracle.com wrote: > >>>>>> > >>>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/src/hots > >>>>>> pot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp.frames.html > >>>>>> > >>>>>> > >>>>>> Can you mention in a comment that incoming rbx is the method? > >>>>> > >>>>> Fixed. > >>>> > >>>> Thank you! > >>>>> > >>>>>> You can't do a JRT_LEAF function from here, can you to some > >>>>>> Method::is_alive() function? Or even a straight up call ?? This > >>>>>> doesn't seem that it should care about the extra overhead of the > >>>>>> call instruction.? The assembly code looks correct but yuck not > >>>>>> more assembly code. > >>>>> > >>>>> I'm not sure I know how I feel about that. I would have to save > >>>>> and restore all registers then to go into the runtime just to > >>>>> check if the method is alive. Would you be okay with keeping the > >>>>> assembly variant instead until I find a better solution to this > >>>>> problem? (I'm on it) > >>>> > >>>> Yes, this is fine with me.? Had to register not liking more assembly. > >>>>> > >>>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/src/hots > >>>>>> pot/share/code/compiledMethod.cpp.frames.html > >>>>>> > >>>>>> > >>>>>> 578 case relocInfo::static_stub_type: { > >>>>>> 579 is_in_static_stub = true; > >>>>>> 580 break; > >>>>>> 581 } > >>>>>> 582 > >>>>>> 583 case relocInfo::metadata_type: { > >>>>>> 584 if (!is_in_static_stub) { > >>>>>> 585 continue; > >>>>>> 586 } > >>>>>> > >>>>>> > >>>>>> This was mystifying to me.? Can you put a comment that after > >>>>>> static_stub_type relocations are generated, the next metadata > >>>>>> relocation contains the address that is patched at runtime, so > >>>>>> this is the metadata that can be stale and should be cleared by > >>>>>> unloading. > >>>>> > >>>>> Sure, I updated the comments, and added a better description about > >>>>> what is going on here. > >>>>> > >>>>> Webrev: > >>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.01/ > >>>>> > >>>>> Incremental: > >>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00_01/ > >>>> > >>>> Looks good! > >>>> Coleen > >>>>> > >>>>> Thanks, > >>>>> /Erik > >>>>> > >>>>>> The clean_ic_stubs() name is my fault. I didn't know what they > >>>>>> were and just wanted this code out of my way. > >>>>>> > >>>>>> Thank you for explaining how redefinition is broken by this. I > >>>>>> didn't know these metadata_reloc guys were patched at runtime. > >>>>>> > >>>>>> Thanks, > >>>>>> Coleen > >>>>>> > >>>>>> > >>>>>> > >>>>>>> On 4/23/19 4:41 AM, Erik ?sterlund wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> Static call stubs are cleared in debug builds before an assert > >>>>>>> checking for dead metadata. This is done in the function > >>>>>>> "clean_ic_stubs()" (which does not clean ICStubs... but > >>>>>>> static/optimized virtual call stubs for calling c2i adapters > >>>>>>> from compiled code...) The reason is that the static call stub > >>>>>>> has metadata, and it complains about dead metadata being left > >>>>>>> after inline cache cleaning of is_alive nmethods. > >>>>>>> > >>>>>>> ...except class redefinition looks at this metadata to determine > >>>>>>> if there is old metadata in subsequent safepoints, and they > >>>>>>> could have been unloaded then. Ouch. So maybe we shouldn't > >>>>>>> squelch that assert in debug builds, because it actually shows > >>>>>>> there is a real problem. > >>>>>>> > >>>>>>> ...and with concurrent class unloading (ZGC and seemingly soon > >>>>>>> Shenandoah), we can't just clear the call stub of a concurrently > >>>>>>> running JavaThread; they can racingly call in to them before > >>>>>>> they get cleared, and then get stuck in an infinite loop, > >>>>>>> because clearing also involves updating the branch target of the > >>>>>>> static call stub to a self-loop. Or call a dead method, which > >>>>>>> also seems like a scary scenario. > >>>>>>> > >>>>>>> All things considered, clearing static call stubs when unloading > >>>>>>> the code cache seems like a bad idea. > >>>>>>> > >>>>>>> My proposal is the following: > >>>>>>> 1) Make sure that code cache unloading *always* clears out the > >>>>>>> metadata part (but not the branch part) of static call stubs, so > >>>>>>> that subsequent operations such as class redefinition will not > >>>>>>> blow up when looking at the embedded metadata, but it won't get > >>>>>>> stuck in infinite loops with concurrent code cache unloading. > >>>>>>> 2) Make a c2i entry barrier for concurrently unloading GCs that > >>>>>>> will reresolve the call when calling into a stale static call > >>>>>>> stub (iff method is NULL or dead). > >>>>>>> 3) Relax MT-safety asserts to allow the previous medatada to be > >>>>>>> concurrently unloading when setting the new target. > >>>>>>> > >>>>>>> Bug: > >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8222841 > >>>>>>> > >>>>>>> Webrev: > >>>>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/ > >>>>>>> > >>>>>>> Thanks, > >>>>>>> /Erik > >>>>>> > >>>>> > >>>> > >>> > >> From vladimir.kozlov at oracle.com Mon May 13 16:14:33 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 13 May 2019 09:14:33 -0700 Subject: RFR: 8222841: Incorrect static call stub interactions with class unloading In-Reply-To: References: <067fc16e-3104-4e61-b558-9cd4864f079f@oracle.com> <1ca35306-6be8-61ec-127f-196367d94899@oracle.com> <6f615499-6f79-ce41-d835-d64e0741a3be@oracle.com> <04c23dad-67b2-f4eb-7d6f-6f24d57bbd5b@oracle.com> Message-ID: <7EF491C6-6E46-494C-A4B1-2A7188B1543C@oracle.com> Looks good. Thanks Vladimir > On May 13, 2019, at 5:54 AM, Erik ?sterlund wrote: > > Hi Vladimir, > > Thanks for the review. > I removed the unnecessary rtmp: > http://cr.openjdk.java.net/~eosterlund/8222841/webrev.02/ > > Incremental: > http://cr.openjdk.java.net/~eosterlund/8222841/webrev.01_02/ > > Testing: I ran hs-tier[1-6], and attached the rest results to the bug. I went through all failures to make sure I did not introduce any. > > Thanks, > /Erik > > >> On 2019-05-10 01:56, Vladimir Kozlov wrote: >> Hi Erik, >> >> I general looks good to me. One comment: >> >> rtmp register seems unused in load_method_holder_cld() >> >> What testing you did? There are no link to testing results in RFE. >> >> Thanks, >> Vladimir >> >>> On 5/9/19 3:33 PM, Erik Osterlund wrote: >>> Any more takers? I know you want this stuff. >>> >>> /Erik >>> >>>> On 8 May 2019, at 14:20, Erik ?sterlund wrote: >>>> >>>> Hi Coleen, >>>> >>>> Thanks for the review! >>>> >>>> /Erik >>>> >>>>> On 2019-05-08 14:16, coleen.phillimore at oracle.com wrote: >>>>> >>>>> >>>>>> On 5/2/19 4:55 AM, Erik ?sterlund wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> Thank you for the review. >>>>>> >>>>>>> On 2019-04-23 23:32, coleen.phillimore at oracle.com wrote: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp.frames.html >>>>>>> >>>>>>> Can you mention in a comment that incoming rbx is the method? >>>>>> >>>>>> Fixed. >>>>> >>>>> Thank you! >>>>>> >>>>>>> You can't do a JRT_LEAF function from here, can you to some Method::is_alive() function? Or even a straight up call ? This doesn't seem that it should care about the extra overhead of the call instruction. The assembly code looks correct but yuck not more assembly code. >>>>>> >>>>>> I'm not sure I know how I feel about that. I would have to save and restore all registers then to go into the runtime just to check if the method is alive. Would you be okay with keeping the assembly variant instead until I find a better solution to this problem? (I'm on it) >>>>> >>>>> Yes, this is fine with me. Had to register not liking more assembly. >>>>>> >>>>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/src/hotspot/share/code/compiledMethod.cpp.frames.html >>>>>>> >>>>>>> 578 case relocInfo::static_stub_type: { >>>>>>> 579 is_in_static_stub = true; >>>>>>> 580 break; >>>>>>> 581 } >>>>>>> 582 >>>>>>> 583 case relocInfo::metadata_type: { >>>>>>> 584 if (!is_in_static_stub) { >>>>>>> 585 continue; >>>>>>> 586 } >>>>>>> >>>>>>> >>>>>>> This was mystifying to me. Can you put a comment that after static_stub_type relocations are generated, the next metadata relocation contains the address that is patched at runtime, so this is the metadata that can be stale and should be cleared by unloading. >>>>>> >>>>>> Sure, I updated the comments, and added a better description about what is going on here. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.01/ >>>>>> >>>>>> Incremental: >>>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00_01/ >>>>> >>>>> Looks good! >>>>> Coleen >>>>>> >>>>>> Thanks, >>>>>> /Erik >>>>>> >>>>>>> The clean_ic_stubs() name is my fault. I didn't know what they were and just wanted this code out of my way. >>>>>>> >>>>>>> Thank you for explaining how redefinition is broken by this. I didn't know these metadata_reloc guys were patched at runtime. >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 4/23/19 4:41 AM, Erik ?sterlund wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Static call stubs are cleared in debug builds before an assert checking for dead metadata. This is done in the function "clean_ic_stubs()" (which does not clean ICStubs... but static/optimized virtual call stubs for calling c2i adapters from compiled code...) The reason is that the static call stub has metadata, and it complains about dead metadata being left after inline cache cleaning of is_alive nmethods. >>>>>>>> >>>>>>>> ...except class redefinition looks at this metadata to determine if there is old metadata in subsequent safepoints, and they could have been unloaded then. Ouch. So maybe we shouldn't squelch that assert in debug builds, because it actually shows there is a real problem. >>>>>>>> >>>>>>>> ...and with concurrent class unloading (ZGC and seemingly soon Shenandoah), we can't just clear the call stub of a concurrently running JavaThread; they can racingly call in to them before they get cleared, and then get stuck in an infinite loop, because clearing also involves updating the branch target of the static call stub to a self-loop. Or call a dead method, which also seems like a scary scenario. >>>>>>>> >>>>>>>> All things considered, clearing static call stubs when unloading the code cache seems like a bad idea. >>>>>>>> >>>>>>>> My proposal is the following: >>>>>>>> 1) Make sure that code cache unloading *always* clears out the metadata part (but not the branch part) of static call stubs, so that subsequent operations such as class redefinition will not blow up when looking at the embedded metadata, but it won't get stuck in infinite loops with concurrent code cache unloading. >>>>>>>> 2) Make a c2i entry barrier for concurrently unloading GCs that will reresolve the call when calling into a stale static call stub (iff method is NULL or dead). >>>>>>>> 3) Relax MT-safety asserts to allow the previous medatada to be concurrently unloading when setting the new target. >>>>>>>> >>>>>>>> Bug: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8222841 >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> /Erik >>>>>>> >>>>>> >>>>> >>>> >>> > From erik.osterlund at oracle.com Mon May 13 17:39:55 2019 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Mon, 13 May 2019 19:39:55 +0200 Subject: RFR: 8222841: Incorrect static call stub interactions with class unloading In-Reply-To: <7EF491C6-6E46-494C-A4B1-2A7188B1543C@oracle.com> References: <067fc16e-3104-4e61-b558-9cd4864f079f@oracle.com> <1ca35306-6be8-61ec-127f-196367d94899@oracle.com> <6f615499-6f79-ce41-d835-d64e0741a3be@oracle.com> <04c23dad-67b2-f4eb-7d6f-6f24d57bbd5b@oracle.com> <7EF491C6-6E46-494C-A4B1-2A7188B1543C@oracle.com> Message-ID: <57B1A604-ADB6-4494-B0A6-C5E30C7BB532@oracle.com> Hi Vladimir, Thanks for the review. /Erik > On 13 May 2019, at 18:14, Vladimir Kozlov wrote: > > Looks good. > > Thanks > Vladimir > >> On May 13, 2019, at 5:54 AM, Erik ?sterlund wrote: >> >> Hi Vladimir, >> >> Thanks for the review. >> I removed the unnecessary rtmp: >> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.02/ >> >> Incremental: >> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.01_02/ >> >> Testing: I ran hs-tier[1-6], and attached the rest results to the bug. I went through all failures to make sure I did not introduce any. >> >> Thanks, >> /Erik >> >> >>> On 2019-05-10 01:56, Vladimir Kozlov wrote: >>> Hi Erik, >>> >>> I general looks good to me. One comment: >>> >>> rtmp register seems unused in load_method_holder_cld() >>> >>> What testing you did? There are no link to testing results in RFE. >>> >>> Thanks, >>> Vladimir >>> >>>> On 5/9/19 3:33 PM, Erik Osterlund wrote: >>>> Any more takers? I know you want this stuff. >>>> >>>> /Erik >>>> >>>>> On 8 May 2019, at 14:20, Erik ?sterlund wrote: >>>>> >>>>> Hi Coleen, >>>>> >>>>> Thanks for the review! >>>>> >>>>> /Erik >>>>> >>>>>> On 2019-05-08 14:16, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>> >>>>>>> On 5/2/19 4:55 AM, Erik ?sterlund wrote: >>>>>>> Hi Coleen, >>>>>>> >>>>>>> Thank you for the review. >>>>>>> >>>>>>>> On 2019-04-23 23:32, coleen.phillimore at oracle.com wrote: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp.frames.html >>>>>>>> >>>>>>>> Can you mention in a comment that incoming rbx is the method? >>>>>>> >>>>>>> Fixed. >>>>>> >>>>>> Thank you! >>>>>>> >>>>>>>> You can't do a JRT_LEAF function from here, can you to some Method::is_alive() function? Or even a straight up call ? This doesn't seem that it should care about the extra overhead of the call instruction. The assembly code looks correct but yuck not more assembly code. >>>>>>> >>>>>>> I'm not sure I know how I feel about that. I would have to save and restore all registers then to go into the runtime just to check if the method is alive. Would you be okay with keeping the assembly variant instead until I find a better solution to this problem? (I'm on it) >>>>>> >>>>>> Yes, this is fine with me. Had to register not liking more assembly. >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/src/hotspot/share/code/compiledMethod.cpp.frames.html >>>>>>>> >>>>>>>> 578 case relocInfo::static_stub_type: { >>>>>>>> 579 is_in_static_stub = true; >>>>>>>> 580 break; >>>>>>>> 581 } >>>>>>>> 582 >>>>>>>> 583 case relocInfo::metadata_type: { >>>>>>>> 584 if (!is_in_static_stub) { >>>>>>>> 585 continue; >>>>>>>> 586 } >>>>>>>> >>>>>>>> >>>>>>>> This was mystifying to me. Can you put a comment that after static_stub_type relocations are generated, the next metadata relocation contains the address that is patched at runtime, so this is the metadata that can be stale and should be cleared by unloading. >>>>>>> >>>>>>> Sure, I updated the comments, and added a better description about what is going on here. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.01/ >>>>>>> >>>>>>> Incremental: >>>>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00_01/ >>>>>> >>>>>> Looks good! >>>>>> Coleen >>>>>>> >>>>>>> Thanks, >>>>>>> /Erik >>>>>>> >>>>>>>> The clean_ic_stubs() name is my fault. I didn't know what they were and just wanted this code out of my way. >>>>>>>> >>>>>>>> Thank you for explaining how redefinition is broken by this. I didn't know these metadata_reloc guys were patched at runtime. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 4/23/19 4:41 AM, Erik ?sterlund wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Static call stubs are cleared in debug builds before an assert checking for dead metadata. This is done in the function "clean_ic_stubs()" (which does not clean ICStubs... but static/optimized virtual call stubs for calling c2i adapters from compiled code...) The reason is that the static call stub has metadata, and it complains about dead metadata being left after inline cache cleaning of is_alive nmethods. >>>>>>>>> >>>>>>>>> ...except class redefinition looks at this metadata to determine if there is old metadata in subsequent safepoints, and they could have been unloaded then. Ouch. So maybe we shouldn't squelch that assert in debug builds, because it actually shows there is a real problem. >>>>>>>>> >>>>>>>>> ...and with concurrent class unloading (ZGC and seemingly soon Shenandoah), we can't just clear the call stub of a concurrently running JavaThread; they can racingly call in to them before they get cleared, and then get stuck in an infinite loop, because clearing also involves updating the branch target of the static call stub to a self-loop. Or call a dead method, which also seems like a scary scenario. >>>>>>>>> >>>>>>>>> All things considered, clearing static call stubs when unloading the code cache seems like a bad idea. >>>>>>>>> >>>>>>>>> My proposal is the following: >>>>>>>>> 1) Make sure that code cache unloading *always* clears out the metadata part (but not the branch part) of static call stubs, so that subsequent operations such as class redefinition will not blow up when looking at the embedded metadata, but it won't get stuck in infinite loops with concurrent code cache unloading. >>>>>>>>> 2) Make a c2i entry barrier for concurrently unloading GCs that will reresolve the call when calling into a stale static call stub (iff method is NULL or dead). >>>>>>>>> 3) Relax MT-safety asserts to allow the previous medatada to be concurrently unloading when setting the new target. >>>>>>>>> >>>>>>>>> Bug: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8222841 >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~eosterlund/8222841/webrev.00/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> /Erik >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > From erik.osterlund at oracle.com Mon May 13 17:40:20 2019 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Mon, 13 May 2019 19:40:20 +0200 Subject: RFR (S) 8223472: volatile long field corruption on x86_32 In-Reply-To: <1296c2db-b8f6-5d9e-f01b-5c25129f585d@bell-sw.com> References: <12028291-5388-d87d-65cd-25e2e3f1b0bd@oracle.com> <91a3bf72-e778-829f-4928-1068d1f4a91a@bell-sw.com> <3058c160-a098-00f7-96cb-34b12a032c62@oracle.com> <1296c2db-b8f6-5d9e-f01b-5c25129f585d@bell-sw.com> Message-ID: <5EF749E9-DA89-4224-BD13-BEA958C6F969@oracle.com> Still good. /Erik > On 13 May 2019, at 15:57, Boris Ulasevich wrote: > > Ok. Here is the updated patch with MO_RELAXED access decorator for T_DOUBLE load/store: > http://cr.openjdk.java.net/~bulasevich/8223472/webrev.02 > > thanks, > Boris > >> On 13.05.2019 11:34, David Holmes wrote: >>> On 13/05/2019 6:30 pm, Boris Ulasevich wrote: >>> Hi Coleen, >>> >>> I added short comment, thanks! And yes, from first look it seems that double load/store needs to be marked MO_RELAXED as well, but on x86 fstp/fld is atomic, so no extra flag is actually need. >> It may not actually be needed because of the underlying implementation but the requirement should still be captured with MO_RELAXED IMHO. >> Cheers, >> David >>> thank you, >>> Boris >>> >>>> On 08.05.2019 16:56, coleen.phillimore at oracle.com wrote: >>>> >>>> I just had a look at this and it looks unsettlingly random without a short comment why MO_RELAXED is needed for long and not the others. Is it because on 32 bits, double is two words that have to be atomically stored? Would a volatile double have the same problem? I see getfield_or_static has the MO_RELAXED and a comment, so that's good. I don't need to see a new version if you add a *short* comment like this. >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>>>> On 5/8/19 4:17 AM, Boris Ulasevich wrote: >>>>> Hi all, >>>>> >>>>> Please review a simple change to fix long field store atomicity for 32-bit x86 interpreter. >>>>> >>>>> http://bugs.openjdk.java.net/browse/JDK-8223472 >>>>> http://cr.openjdk.java.net/~bulasevich/8223472/webrev.00 >>>>> >>>>> thanks, >>>>> Boris >>>> From lutz.schmidt at sap.com Mon May 13 19:46:56 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Mon, 13 May 2019 19:46:56 +0000 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: <9912FA08-D8A8-4B32-8E0F-E7598895E15B@sap.com> References: <857294bd-4b27-0d83-3a7c-49cbda586649@oracle.com> <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> <00b8336a-af4f-7a37-b524-009885e0fcf3@physik.fu-berlin.de> <12626D50-4BC8-4B06-8F6C-19731C07027E@sap.com> <58b27f04-3817-9d16-1dfb-8f7177ee456e@physik.fu-berlin.de> <8b32026c-ccd1-dffa-e555-4fa38f85d842@physik.fu-berlin.de> <0e6ad2bd-5b4b-4850-62fc-b1ff7ea23df4@physik.fu-berlin.de> <4d9e84b9-29cc-d6e8-c39e-1573f5974179@physik.fu-berlin.de> <2d7613e8-9fc7-cbb1-5295-7cb30431a8d3@oracle.com> <145f8369-db31-a1bd-68a7-460f5b7b405c@oracle.com> <686a5cba-b492-c027-5758-5e110de9f063@physik.fu-berlin.de> <9912FA08-D8A8-4B32-8E0F-E7598895E15B@sap.com> Message-ID: Hi, when exactly are you planning to push this change? Are there still any obstacles? The pure jdk/jdk repo as of 19:33 (UTC) does not yet contain the required fixes for linuxs390x and linuxppc64. I stopped after trying to build those two. Thanks, Lutz ?On 13.05.19, 14:59, "Schmidt, Lutz" wrote: Go! Linuxppc, linuxppcle, linuxs390x, linuxx84_64, rs6000_64, sun_64 (Solaris_SPARC), all built as fastdebug and release, all green. Tests still running (will not finish in due time), no anomalies so far. Thanks, Lutz On 13.05.19, 12:08, "Stefan Karlsson" wrote: On 2019-05-13 11:40, John Paul Adrian Glaubitz wrote: > On 5/13/19 10:21 AM, Stefan Karlsson wrote: >> On 2019-05-11 16:32, John Paul Adrian Glaubitz wrote: >> Since you didn't base this patch on top of my patch, I had to go through all files to figure out what you changed. > > Ah, you wanted to have a diff against your patch. I misunderstood you then. > >> As far as I can see you also removed the universe.hpp include in c1_LIRAssembler_sparc.cpp, which uses Universe. This change would force me to unnecessarily retest the patch, and I don't want to do that. > > Which targets does your test include? > > As I said before, I can test any Linux target (the s390x is free again) > and I will be able to test Solaris soonish (need to set up the build > environment first). Regarding sparc testing, I've tested Solaris Sparcv9 with fastdebug and release. > > The only thing I can't test is AIX because AIX isn't really available > to anyone outside the enterprise world. > >> The other change I've found is thread_linux_sparc.cpp. I'm OK with that change, and it doesn't invalidate my or Lutz's testing. >> >> Patch with which only changes thread_linux_sparc.cpp. >> http://cr.openjdk.java.net/~stefank/8223637/webrev.05.delta/ >> http://cr.openjdk.java.net/~stefank/8223637/webrev.05/ > > Works for me on: > > - linux-sparc > - linux-s390x > - linux-x86_64 > - linux-ppc64el > - linux-ppc64 > > Also tested Zero on x86_64, ppc64el and s390x. > > Those were release builds. Great. Then we're just waiting for Lutz to say go. Thanks, StefanK > > Adrian > From stefan.karlsson at oracle.com Mon May 13 20:33:22 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 13 May 2019 22:33:22 +0200 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: References: <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> <00b8336a-af4f-7a37-b524-009885e0fcf3@physik.fu-berlin.de> <12626D50-4BC8-4B06-8F6C-19731C07027E@sap.com> <58b27f04-3817-9d16-1dfb-8f7177ee456e@physik.fu-berlin.de> <8b32026c-ccd1-dffa-e555-4fa38f85d842@physik.fu-berlin.de> <0e6ad2bd-5b4b-4850-62fc-b1ff7ea23df4@physik.fu-berlin.de> <4d9e84b9-29cc-d6e8-c39e-1573f5974179@physik.fu-berlin.de> <2d7613e8-9fc7-cbb1-5295-7cb30431a8d3@oracle.com> <145f8369-db31-a1bd-68a7-460f5b7b405c@oracle.com> <686a5cba-b492-c027-5758-5e110de9f063@physik.fu-berlin.de> <9912FA08-D8A8-4B32-8E0F-E7598895E15B@sap.com> Message-ID: The patch has now been pushed to jdk/jdk: http://hg.openjdk.java.net/jdk/jdk/rev/1b03400e5a8f Thanks, StefanK On 2019-05-13 21:46, Schmidt, Lutz wrote: > Hi, > > when exactly are you planning to push this change? Are there still any obstacles? > > The pure jdk/jdk repo as of 19:33 (UTC) does not yet contain the required fixes for linuxs390x and linuxppc64. I stopped after trying to build those two. > > Thanks, > Lutz > > > > ?On 13.05.19, 14:59, "Schmidt, Lutz" wrote: > > Go! > > Linuxppc, linuxppcle, linuxs390x, linuxx84_64, rs6000_64, sun_64 (Solaris_SPARC), all built as fastdebug and release, all green. > > Tests still running (will not finish in due time), no anomalies so far. > > Thanks, > Lutz > > > On 13.05.19, 12:08, "Stefan Karlsson" wrote: > > On 2019-05-13 11:40, John Paul Adrian Glaubitz wrote: > > On 5/13/19 10:21 AM, Stefan Karlsson wrote: > >> On 2019-05-11 16:32, John Paul Adrian Glaubitz wrote: > >> Since you didn't base this patch on top of my patch, I had to go through all files to figure out what you changed. > > > > Ah, you wanted to have a diff against your patch. I misunderstood you then. > > > >> As far as I can see you also removed the universe.hpp include in c1_LIRAssembler_sparc.cpp, which uses Universe. This change would force me to unnecessarily retest the patch, and I don't want to do that. > > > > Which targets does your test include? > > > > As I said before, I can test any Linux target (the s390x is free again) > > and I will be able to test Solaris soonish (need to set up the build > > environment first). > > Regarding sparc testing, I've tested Solaris Sparcv9 with fastdebug and > release. > > > > > The only thing I can't test is AIX because AIX isn't really available > > to anyone outside the enterprise world. > > > >> The other change I've found is thread_linux_sparc.cpp. I'm OK with that change, and it doesn't invalidate my or Lutz's testing. > >> > >> Patch with which only changes thread_linux_sparc.cpp. > >> http://cr.openjdk.java.net/~stefank/8223637/webrev.05.delta/ > >> http://cr.openjdk.java.net/~stefank/8223637/webrev.05/ > > > > Works for me on: > > > > - linux-sparc > > - linux-s390x > > - linux-x86_64 > > - linux-ppc64el > > - linux-ppc64 > > > > Also tested Zero on x86_64, ppc64el and s390x. > > > > Those were release builds. > > Great. Then we're just waiting for Lutz to say go. > > Thanks, > StefanK > > > > > Adrian > > > > > > From igor.ignatyev at oracle.com Mon May 13 21:31:41 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 13 May 2019 14:31:41 -0700 Subject: RFR(M/S) : 8222154 : upgrade gtest to 1.8.1 In-Reply-To: <0C5E424C-C68B-48E9-B47F-16A9270D21D2@oracle.com> References: <0C5E424C-C68B-48E9-B47F-16A9270D21D2@oracle.com> Message-ID: @all, can I get a couple LGTMs? @Robin, I've created 8222414 to bring gmock, will send webrev out for review after this one is integrated. Thanks, -- Igor > On Apr 10, 2019, at 11:10 AM, Igor Ignatyev wrote: > > Hi Robin, > > that's a very good suggestion, I myself missed gmock functionality several times, so yes I agree we need to get it available as well. doing that, however, will be a bit more effort and disturbance that just upgrading gtest, and as I'm planning to backport this patch into 11u, I'd prefer to bring gmock by a separate RFE. > > -- Igor > >> On Apr 10, 2019, at 7:02 AM, Robin Westberg > wrote: >> >> Hi Igor, >> >>> On 10 Apr 2019, at 02:17, Igor Ignatyev > wrote: >>> >>> http://cr.openjdk.java.net/~iignatyev//8222154/webrev.00/index.html >>>> 6852 lines changed: 5104 ins; 742 del; 1006 mod; >>> >>> Hi all, >>> >>> could you please review the patch which upgrades google test framework used by JDK from v1.7 to v1.8.1? >>> >>> as this might break builds on other platforms, I'd strongly encourage platform maintainers to check if their native compilers are happy w/ upgraded version of gtest. I'm planning to wait for a week so everyone has enough time to test that, please let me know if you need more time. >>> >>> for the sake of reviewers, I'm publishing the webrevs for small changes done on top of gtest v1.8.1. and as w/ gtest v1.7, we aren't bringing parts of gtest which aren't essential (make, docs, project files, etc). >> >> Just a question / suggestion, would it be possible to include the contents of the googlemock folder as well? Back in the days of gtest 1.7 it used to be a separate project, but as of 1.8 it is a part of gtest. I?d argue it's an essential part of gtest, I?m missing that functionality every time I write a test. :) >> >> Best regards, >> Robin >> >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8222154 >>> testing: tier1 >>> webrevs: >>> - reverting 8196997[1]: http://cr.openjdk.java.net/~iignatyev//8222154/-8196997/webrev.00/index.html >>>> 2 lines changed: 0 ins; 2 del; 0 mod; 1 >>> >>> - changes to make solaris studio happy: http://cr.openjdk.java.net/~iignatyev//8222154/ss/webrev.00/index.html >>>> 6 lines changed: 4 ins; 0 del; 2 mod; >>> >>> - the whole webrev: http://cr.openjdk.java.net/~iignatyev//8222154/webrev.00/index.html >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8196997 >>> >>> Thanks, >>> -- Igor > From david.holmes at oracle.com Mon May 13 21:49:41 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 May 2019 07:49:41 +1000 Subject: RFR (S) 8223472: volatile long field corruption on x86_32 In-Reply-To: <1296c2db-b8f6-5d9e-f01b-5c25129f585d@bell-sw.com> References: <12028291-5388-d87d-65cd-25e2e3f1b0bd@oracle.com> <91a3bf72-e778-829f-4928-1068d1f4a91a@bell-sw.com> <3058c160-a098-00f7-96cb-34b12a032c62@oracle.com> <1296c2db-b8f6-5d9e-f01b-5c25129f585d@bell-sw.com> Message-ID: Thanks. LGTM too. David On 13/05/2019 11:57 pm, Boris Ulasevich wrote: > Ok. Here is the updated patch with MO_RELAXED access decorator for > T_DOUBLE load/store: > http://cr.openjdk.java.net/~bulasevich/8223472/webrev.02 > > thanks, > Boris > > On 13.05.2019 11:34, David Holmes wrote: >> On 13/05/2019 6:30 pm, Boris Ulasevich wrote: >>> Hi Coleen, >>> >>> I added short comment, thanks! And yes, from first look it seems that >>> double load/store needs to be marked MO_RELAXED as well, but on x86 >>> fstp/fld is atomic, so no extra flag is actually need. >> >> It may not actually be needed because of the underlying implementation >> but the requirement should still be captured with MO_RELAXED IMHO. >> >> Cheers, >> David >> >>> thank you, >>> Boris >>> >>> On 08.05.2019 16:56, coleen.phillimore at oracle.com wrote: >>>> >>>> I just had a look at this and it looks unsettlingly random without a >>>> short comment why MO_RELAXED is needed for long and not the others. >>>> Is it because on 32 bits, double is two words that have to be >>>> atomically stored?? Would a volatile double have the same problem? I >>>> see getfield_or_static has the MO_RELAXED and a comment, so that's >>>> good. I don't need to see a new version if you add a *short* comment >>>> like this. >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>>> On 5/8/19 4:17 AM, Boris Ulasevich wrote: >>>>> Hi all, >>>>> >>>>> Please review a simple change to fix long field store atomicity for >>>>> 32-bit x86 interpreter. >>>>> >>>>> http://bugs.openjdk.java.net/browse/JDK-8223472 >>>>> http://cr.openjdk.java.net/~bulasevich/8223472/webrev.00 >>>>> >>>>> thanks, >>>>> Boris >>>> From andrewluotechnologies at outlook.com Tue May 14 00:21:29 2019 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Tue, 14 May 2019 00:21:29 +0000 Subject: [PATCH] Fix some assignments of string literals to non-const char* Message-ID: I've been trying to get the JDK to compile with the new /permissive- switch in VS2017 (https://devblogs.microsoft.com/cppblog/permissive-switch/) however there have been a few issues in various parts of the code. There are a few issues in the hotspot code where we attempt to assign string literals to char* (non-const) variables (unnecessarily). I took some time to fix some of these and attached a patch. Let me know if you have any comments/feedback. c:/Users/Andrew/Documents/mercurial/openjdk/jdk/test/hotspot/gtest/gtestMain.cpp(234): error C2440: 'initializing': cannot convert from 'const char [19]' to 'char *' c:/Users/Andrew/Documents/mercurial/openjdk/jdk/test/hotspot/gtest/gtestMain.cpp(234): note: Conversion from string literal loses const qualifier (see /Zc:strictStrings) c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/attachListener_windows.cpp(152): error C2664: 'AttachOperation::AttachOperation(AttachOperation &&)': cannot convert argument 1 from 'const char [9]' to 'char *' c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/attachListener_windows.cpp(152): note: Conversion from string literal loses const qualifier (see /Zc:strictStrings) c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/os_windows.cpp(204): error C2440: 'initializing': cannot convert from 'const char [5]' to 'char *' c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/os_windows.cpp(204): note: Conversion from string literal loses const qualifier (see /Zc:strictStrings) c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/os_windows.cpp(2214): error C2440: 'initializing': ... Thanks, -Andrew -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jdkcomformance1.txt URL: From boris.ulasevich at bell-sw.com Tue May 14 04:40:56 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Tue, 14 May 2019 07:40:56 +0300 Subject: RFR (S) 8223472: volatile long field corruption on x86_32 In-Reply-To: References: <12028291-5388-d87d-65cd-25e2e3f1b0bd@oracle.com> <91a3bf72-e778-829f-4928-1068d1f4a91a@bell-sw.com> <3058c160-a098-00f7-96cb-34b12a032c62@oracle.com> <1296c2db-b8f6-5d9e-f01b-5c25129f585d@bell-sw.com> Message-ID: <24f3b5df-5fc6-01c9-4da0-c197a3f9c86b@bell-sw.com> Thank you! 14.05.2019 0:49, David Holmes: > Thanks. LGTM too. > > David > > On 13/05/2019 11:57 pm, Boris Ulasevich wrote: >> Ok. Here is the updated patch with MO_RELAXED access decorator for >> T_DOUBLE load/store: >> http://cr.openjdk.java.net/~bulasevich/8223472/webrev.02 >> >> thanks, >> Boris >> >> On 13.05.2019 11:34, David Holmes wrote: >>> On 13/05/2019 6:30 pm, Boris Ulasevich wrote: >>>> Hi Coleen, >>>> >>>> I added short comment, thanks! And yes, from first look it seems >>>> that double load/store needs to be marked MO_RELAXED as well, but >>>> on x86 fstp/fld is atomic, so no extra flag is actually need. >>> >>> It may not actually be needed because of the underlying >>> implementation but the requirement should still be captured with >>> MO_RELAXED IMHO. >>> >>> Cheers, >>> David >>> >>>> thank you, >>>> Boris >>>> >>>> On 08.05.2019 16:56, coleen.phillimore at oracle.com wrote: >>>>> >>>>> I just had a look at this and it looks unsettlingly random without >>>>> a short comment why MO_RELAXED is needed for long and not the >>>>> others. Is it because on 32 bits, double is two words that have to >>>>> be atomically stored?? Would a volatile double have the same >>>>> problem? I see getfield_or_static has the MO_RELAXED and a >>>>> comment, so that's good. I don't need to see a new version if you >>>>> add a *short* comment like this. >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>>>> On 5/8/19 4:17 AM, Boris Ulasevich wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review a simple change to fix long field store atomicity >>>>>> for 32-bit x86 interpreter. >>>>>> >>>>>> http://bugs.openjdk.java.net/browse/JDK-8223472 >>>>>> http://cr.openjdk.java.net/~bulasevich/8223472/webrev.00 >>>>>> >>>>>> thanks, >>>>>> Boris >>>>> From david.holmes at oracle.com Tue May 14 04:42:27 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 May 2019 14:42:27 +1000 Subject: [PATCH] Fix some assignments of string literals to non-const char* In-Reply-To: References: Message-ID: <7af793d6-b6b7-55e3-0301-1a61acb509ed@oracle.com> Hi Andrew, Thanks for the report and patch. We just had something very similar go through for gcc 9 on non-Windows. :) Interesting gcc didn't complain about the code in attachListener.hpp. I've filed: https://bugs.openjdk.java.net/browse/JDK-8223810 and I will sponsor this for you. I've posted a webrev here: http://cr.openjdk.java.net/~dholmes/8223810/webrev/ and am running the patch through our build. Thanks, David On 14/05/2019 10:21 am, Andrew Luo wrote: > I've been trying to get the JDK to compile with the new /permissive- switch in VS2017 (https://devblogs.microsoft.com/cppblog/permissive-switch/) however there have been a few issues in various parts of the code. There are a few issues in the hotspot code where we attempt to assign string literals to char* (non-const) variables (unnecessarily). I took some time to fix some of these and attached a patch. Let me know if you have any comments/feedback. > > c:/Users/Andrew/Documents/mercurial/openjdk/jdk/test/hotspot/gtest/gtestMain.cpp(234): error C2440: 'initializing': cannot convert from 'const char [19]' to 'char *' > c:/Users/Andrew/Documents/mercurial/openjdk/jdk/test/hotspot/gtest/gtestMain.cpp(234): note: Conversion from string literal loses const qualifier (see /Zc:strictStrings) > c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/attachListener_windows.cpp(152): error C2664: 'AttachOperation::AttachOperation(AttachOperation &&)': cannot convert argument 1 from 'const char [9]' to 'char *' > c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/attachListener_windows.cpp(152): note: Conversion from string literal loses const qualifier (see /Zc:strictStrings) > c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/os_windows.cpp(204): error C2440: 'initializing': cannot convert from 'const char [5]' to 'char *' > c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/os_windows.cpp(204): note: Conversion from string literal loses const qualifier (see /Zc:strictStrings) > c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/os_windows.cpp(2214): error C2440: 'initializing': ... > > Thanks, > > -Andrew > From boris.ulasevich at bell-sw.com Tue May 14 04:45:53 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Tue, 14 May 2019 07:45:53 +0300 Subject: RFR: 8222825: ARM32 SIGILL issue on single core CPU (not supported PLDW instruction) Message-ID: <1695e37a-e9bd-364a-68ef-e357d9b8a939@bell-sw.com> Hi all, Please review the fix for SIGILL that happens on ARM32 CPU without Multiprocessing Extensions support (this applies to single-core arm32 processors, which are not very common this days). With the fix we check PLDW instruction availability on JVM start-up to correct further instructions generation. https://bugs.openjdk.java.net/browse/JDK-8222825 http://cr.openjdk.java.net/~bulasevich/8222825/webrev.03.jdk-jdk thanks, Boris From david.holmes at oracle.com Tue May 14 05:00:10 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 May 2019 15:00:10 +1000 Subject: RFR: 8222825: ARM32 SIGILL issue on single core CPU (not supported PLDW instruction) In-Reply-To: <1695e37a-e9bd-364a-68ef-e357d9b8a939@bell-sw.com> References: <1695e37a-e9bd-364a-68ef-e357d9b8a939@bell-sw.com> Message-ID: <71276d27-7183-fb8f-c58c-ddff4a528b25@oracle.com> Hi Boris, I was wondering what had happened to this one :) Looks good! I can sponsor for you. Thanks, David On 14/05/2019 2:45 pm, Boris Ulasevich wrote: > Hi all, > > Please review the fix for SIGILL that happens on ARM32 CPU without > Multiprocessing Extensions support (this applies to single-core arm32 > processors, which are not very common this days). With the fix we check > PLDW instruction availability on JVM start-up to correct further > instructions generation. > > https://bugs.openjdk.java.net/browse/JDK-8222825 > http://cr.openjdk.java.net/~bulasevich/8222825/webrev.03.jdk-jdk > > thanks, > Boris From boris.ulasevich at bell-sw.com Tue May 14 06:04:08 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Tue, 14 May 2019 09:04:08 +0300 Subject: RFR: 8222825: ARM32 SIGILL issue on single core CPU (not supported PLDW instruction) In-Reply-To: <71276d27-7183-fb8f-c58c-ddff4a528b25@oracle.com> References: <1695e37a-e9bd-364a-68ef-e357d9b8a939@bell-sw.com> <71276d27-7183-fb8f-c58c-ddff4a528b25@oracle.com> Message-ID: <105f00fe-b9f6-58ce-00e2-345f4cfd9d8f@bell-sw.com> Hi David, ? It took a time to test the change :) ? Yes, please. Thank you! Boris 14.05.2019 8:00, David Holmes ?????: > Hi Boris, > > I was wondering what had happened to this one :) > > Looks good! I can sponsor for you. > > Thanks, > David > > On 14/05/2019 2:45 pm, Boris Ulasevich wrote: >> Hi all, >> >> Please review the fix for SIGILL that happens on ARM32 CPU without >> Multiprocessing Extensions support (this applies to single-core arm32 >> processors, which are not very common this days). With the fix we >> check PLDW instruction availability on JVM start-up to correct >> further instructions generation. >> >> https://bugs.openjdk.java.net/browse/JDK-8222825 >> http://cr.openjdk.java.net/~bulasevich/8222825/webrev.03.jdk-jdk >> >> thanks, >> Boris From dean.long at oracle.com Tue May 14 06:28:52 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 13 May 2019 23:28:52 -0700 Subject: RFR: 8222825: ARM32 SIGILL issue on single core CPU (not supported PLDW instruction) In-Reply-To: <105f00fe-b9f6-58ce-00e2-345f4cfd9d8f@bell-sw.com> References: <1695e37a-e9bd-364a-68ef-e357d9b8a939@bell-sw.com> <71276d27-7183-fb8f-c58c-ddff4a528b25@oracle.com> <105f00fe-b9f6-58ce-00e2-345f4cfd9d8f@bell-sw.com> Message-ID: This looks good.? In arm.ad, you could use two rules and a predicate, so that the PrintOptoAssembly output is correct. dl On 5/13/19 11:04 PM, Boris Ulasevich wrote: > Hi David, > > ? It took a time to test the change :) > ? Yes, please. Thank you! > > Boris > > 14.05.2019 8:00, David Holmes ?????: >> Hi Boris, >> >> I was wondering what had happened to this one :) >> >> Looks good! I can sponsor for you. >> >> Thanks, >> David >> >> On 14/05/2019 2:45 pm, Boris Ulasevich wrote: >>> Hi all, >>> >>> Please review the fix for SIGILL that happens on ARM32 CPU without >>> Multiprocessing Extensions support (this applies to single-core >>> arm32 processors, which are not very common this days). With the fix >>> we check PLDW instruction availability on JVM start-up to correct >>> further instructions generation. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8222825 >>> http://cr.openjdk.java.net/~bulasevich/8222825/webrev.03.jdk-jdk >>> >>> thanks, >>> Boris > > From lutz.schmidt at sap.com Tue May 14 06:32:04 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Tue, 14 May 2019 06:32:04 +0000 Subject: RFR (XS) 8223637: PPC64 and S390X build failures after 8223136 (Move compressed oops functions to CompressedOops class) In-Reply-To: References: <473b90d1-0a37-7757-e696-bce849c1c55f@physik.fu-berlin.de> <00b8336a-af4f-7a37-b524-009885e0fcf3@physik.fu-berlin.de> <12626D50-4BC8-4B06-8F6C-19731C07027E@sap.com> <58b27f04-3817-9d16-1dfb-8f7177ee456e@physik.fu-berlin.de> <8b32026c-ccd1-dffa-e555-4fa38f85d842@physik.fu-berlin.de> <0e6ad2bd-5b4b-4850-62fc-b1ff7ea23df4@physik.fu-berlin.de> <4d9e84b9-29cc-d6e8-c39e-1573f5974179@physik.fu-berlin.de> <2d7613e8-9fc7-cbb1-5295-7cb30431a8d3@oracle.com> <145f8369-db31-a1bd-68a7-460f5b7b405c@oracle.com> <686a5cba-b492-c027-5758-5e110de9f063@physik.fu-berlin.de> <9912FA08-D8A8-4B32-8E0F-E7598895E15B@sap.com> Message-ID: <3530DFE6-F1E3-41DF-B9DA-BA013CBD9874@sap.com> Thank you, Stefan! Lutz ?On 13.05.19, 22:33, "Stefan Karlsson" wrote: The patch has now been pushed to jdk/jdk: http://hg.openjdk.java.net/jdk/jdk/rev/1b03400e5a8f Thanks, StefanK On 2019-05-13 21:46, Schmidt, Lutz wrote: > Hi, > > when exactly are you planning to push this change? Are there still any obstacles? > > The pure jdk/jdk repo as of 19:33 (UTC) does not yet contain the required fixes for linuxs390x and linuxppc64. I stopped after trying to build those two. > > Thanks, > Lutz > > > > On 13.05.19, 14:59, "Schmidt, Lutz" wrote: > > Go! > > Linuxppc, linuxppcle, linuxs390x, linuxx84_64, rs6000_64, sun_64 (Solaris_SPARC), all built as fastdebug and release, all green. > > Tests still running (will not finish in due time), no anomalies so far. > > Thanks, > Lutz > > > On 13.05.19, 12:08, "Stefan Karlsson" wrote: > > On 2019-05-13 11:40, John Paul Adrian Glaubitz wrote: > > On 5/13/19 10:21 AM, Stefan Karlsson wrote: > >> On 2019-05-11 16:32, John Paul Adrian Glaubitz wrote: > >> Since you didn't base this patch on top of my patch, I had to go through all files to figure out what you changed. > > > > Ah, you wanted to have a diff against your patch. I misunderstood you then. > > > >> As far as I can see you also removed the universe.hpp include in c1_LIRAssembler_sparc.cpp, which uses Universe. This change would force me to unnecessarily retest the patch, and I don't want to do that. > > > > Which targets does your test include? > > > > As I said before, I can test any Linux target (the s390x is free again) > > and I will be able to test Solaris soonish (need to set up the build > > environment first). > > Regarding sparc testing, I've tested Solaris Sparcv9 with fastdebug and > release. > > > > > The only thing I can't test is AIX because AIX isn't really available > > to anyone outside the enterprise world. > > > >> The other change I've found is thread_linux_sparc.cpp. I'm OK with that change, and it doesn't invalidate my or Lutz's testing. > >> > >> Patch with which only changes thread_linux_sparc.cpp. > >> http://cr.openjdk.java.net/~stefank/8223637/webrev.05.delta/ > >> http://cr.openjdk.java.net/~stefank/8223637/webrev.05/ > > > > Works for me on: > > > > - linux-sparc > > - linux-s390x > > - linux-x86_64 > > - linux-ppc64el > > - linux-ppc64 > > > > Also tested Zero on x86_64, ppc64el and s390x. > > > > Those were release builds. > > Great. Then we're just waiting for Lutz to say go. > > Thanks, > StefanK > > > > > Adrian > > > > > > From thomas.stuefe at gmail.com Tue May 14 07:12:09 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 14 May 2019 09:12:09 +0200 Subject: [PATCH] Fix some assignments of string literals to non-const char* In-Reply-To: <7af793d6-b6b7-55e3-0301-1a61acb509ed@oracle.com> References: <7af793d6-b6b7-55e3-0301-1a61acb509ed@oracle.com> Message-ID: This looks fine. Cheers, Thomas On Tue, May 14, 2019 at 6:45 AM David Holmes wrote: > Hi Andrew, > > Thanks for the report and patch. We just had something very similar go > through for gcc 9 on non-Windows. :) Interesting gcc didn't complain > about the code in attachListener.hpp. > > I've filed: > > https://bugs.openjdk.java.net/browse/JDK-8223810 > > and I will sponsor this for you. I've posted a webrev here: > > http://cr.openjdk.java.net/~dholmes/8223810/webrev/ > > and am running the patch through our build. > > Thanks, > David > > On 14/05/2019 10:21 am, Andrew Luo wrote: > > I've been trying to get the JDK to compile with the new /permissive- > switch in VS2017 ( > https://devblogs.microsoft.com/cppblog/permissive-switch/) however there > have been a few issues in various parts of the code. There are a few > issues in the hotspot code where we attempt to assign string literals to > char* (non-const) variables (unnecessarily). I took some time to fix some > of these and attached a patch. Let me know if you have any > comments/feedback. > > > > > c:/Users/Andrew/Documents/mercurial/openjdk/jdk/test/hotspot/gtest/gtestMain.cpp(234): > error C2440: 'initializing': cannot convert from 'const char [19]' to 'char > *' > > > c:/Users/Andrew/Documents/mercurial/openjdk/jdk/test/hotspot/gtest/gtestMain.cpp(234): > note: Conversion from string literal loses const qualifier (see > /Zc:strictStrings) > > > c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/attachListener_windows.cpp(152): > error C2664: 'AttachOperation::AttachOperation(AttachOperation &&)': cannot > convert argument 1 from 'const char [9]' to 'char *' > > > c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/attachListener_windows.cpp(152): > note: Conversion from string literal loses const qualifier (see > /Zc:strictStrings) > > > c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/os_windows.cpp(204): > error C2440: 'initializing': cannot convert from 'const char [5]' to 'char > *' > > > c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/os_windows.cpp(204): > note: Conversion from string literal loses const qualifier (see > /Zc:strictStrings) > > > c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/os_windows.cpp(2214): > error C2440: 'initializing': ... > > > > Thanks, > > > > -Andrew > > > From david.holmes at oracle.com Tue May 14 07:49:22 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 May 2019 17:49:22 +1000 Subject: [PATCH] Fix some assignments of string literals to non-const char* In-Reply-To: References: <7af793d6-b6b7-55e3-0301-1a61acb509ed@oracle.com> Message-ID: <79bcd948-b100-0c13-63c8-4f56c67c940f@oracle.com> Thanks Thomas. My testing passed so I'll push this in the morning. David ----- On 14/05/2019 5:12 pm, Thomas St?fe wrote: > This looks fine. > > Cheers, Thomas > > On Tue, May 14, 2019 at 6:45 AM David Holmes > wrote: > > Hi Andrew, > > Thanks for the report and patch. We just had something very similar go > through for gcc 9 on non-Windows. :) Interesting gcc didn't complain > about the code in attachListener.hpp. > > I've filed: > > https://bugs.openjdk.java.net/browse/JDK-8223810 > > and I will sponsor this for you. I've posted a webrev here: > > http://cr.openjdk.java.net/~dholmes/8223810/webrev/ > > and am running the patch through our build. > > Thanks, > David > > On 14/05/2019 10:21 am, Andrew Luo wrote: > > I've been trying to get the JDK to compile with the new > /permissive- switch in VS2017 > (https://devblogs.microsoft.com/cppblog/permissive-switch/) however > there have been a few issues in various parts of the code.? There > are a few issues in the hotspot code where we attempt to assign > string literals to char* (non-const) variables (unnecessarily).? I > took some time to fix some of these and attached a patch.? Let me > know if you have any comments/feedback. > > > > > c:/Users/Andrew/Documents/mercurial/openjdk/jdk/test/hotspot/gtest/gtestMain.cpp(234): > error C2440: 'initializing': cannot convert from 'const char [19]' > to 'char *' > > > c:/Users/Andrew/Documents/mercurial/openjdk/jdk/test/hotspot/gtest/gtestMain.cpp(234): > note: Conversion from string literal loses const qualifier (see > /Zc:strictStrings) > > > c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/attachListener_windows.cpp(152): > error C2664: 'AttachOperation::AttachOperation(AttachOperation &&)': > cannot convert argument 1 from 'const char [9]' to 'char *' > > > c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/attachListener_windows.cpp(152): > note: Conversion from string literal loses const qualifier (see > /Zc:strictStrings) > > > c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/os_windows.cpp(204): > error C2440: 'initializing': cannot convert from 'const char [5]' to > 'char *' > > > c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/os_windows.cpp(204): > note: Conversion from string literal loses const qualifier (see > /Zc:strictStrings) > > > c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/os_windows.cpp(2214): > error C2440: 'initializing': ... > > > > Thanks, > > > > -Andrew > > > From matthias.baesken at sap.com Tue May 14 08:01:30 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 14 May 2019 08:01:30 +0000 Subject: RFR: 8223438: add VirtualizationInformation JFR event In-Reply-To: <5CD5794D.20304@oracle.com> References: <5CD309CA.40808@oracle.com> <5CD5794D.20304@oracle.com> Message-ID: Thanks Erik , good to hear ! May I get a second review ? Best regards, Matthias From: Erik Gahlin Sent: Freitag, 10. Mai 2019 15:15 To: Baesken, Matthias ; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR: 8223438: add VirtualizationInformation JFR event Looks good. Erik Hello, here is the next webrev with adjusted coding following your suggestion : http://cr.openjdk.java.net/~mbaesken/webrevs/8223438.2/ Best regards, Matthias From: Baesken, Matthias Sent: Donnerstag, 9. Mai 2019 09:03 To: Erik Gahlin ; 'hotspot-dev at openjdk.java.net' Subject: RE: RFR: 8223438: add VirtualizationInformation JFR event Hi Erik, the virtualization names are a set of fix names , so I think we can do what you suggest . I just "borrowed" a bit from the code above ... TRACE_REQUEST_FUNC(OSInformation) { ResourceMark rm; char* os_name = NEW_RESOURCE_ARRAY(char, 2048); JfrOSInterface::os_version(&os_name); EventOSInformation event; event.set_osVersion(os_name); event.commit(); } ... where a ResourceMark + allocation is used (but in jfrOSInterface I wonder about the second allocation in string.stream.as_string , do we really need two here ? int JfrOSInterface::JfrOSInterfaceImpl::os_version(char** os_version) const { assert(os_version != NULL, "os_version pointer is NULL!"); stringStream os_ver_info; os::print_os_info_brief(&os_ver_info); *os_version = os_ver_info.as_string(); <--- second alloc Best regards, Matthias From: Erik Gahlin > Sent: Mittwoch, 8. Mai 2019 18:55 To: Baesken, Matthias >; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR: 8223438: add VirtualizationInformation JFR event Hello, Looks good, but do we really need to allocate the name every time an event is emitted in jfrPeriodic.cpp? It will not matter much from a performance perspective, but the code would look cleaner if we would have. EventVirtualizationInformation event; event.set_name(JfrOSInterface::virtualization_name()); event.commit(); Thanks Erik Hello, please review the following change . It adds a simple VirtualizationInformation event to JFR . The addition to JFR has been previously proposed by Erik when we discussed the enhancement of hs_error file output with virtualization related information . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8223438 http://cr.openjdk.java.net/~mbaesken/webrevs/8223438.1/ Thanks, Matthias From matthias.baesken at sap.com Tue May 14 08:03:46 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 14 May 2019 08:03:46 +0000 Subject: 8222720: Provide extended VMWare/vSphere virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: <7a05ab9f-5688-7197-e1eb-3c697c41bc75@oracle.com> References: <06d00a9c-497b-44de-f834-a0314bd0bf39@oracle.com> <7a05ab9f-5688-7197-e1eb-3c697c41bc75@oracle.com> Message-ID: Hi David, thanks for the review ! Robbin, my I add you as reviewer too ? Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Freitag, 10. Mai 2019 15:41 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Subject: Re: 8222720: Provide extended VMWare/vSphere virtualization > related info in the hs_error file on linux/windows x86_64 > > On 10/05/2019 7:08 pm, Baesken, Matthias wrote: > > Hi David, I removed / adjusted the ifdefs and added checks != NULL : > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8222720.3/ > > Looks good. > > > > > (not sure however about VMWARE Fusion on Mac, have no access to it ) > > No idea either. > > Thanks, > David > > > Regards, Matthias > > > >> > >> Hi Matthias, > >> > >> On 10/05/2019 4:21 pm, Baesken, Matthias wrote: > >>> Hello, here is an updated version : > >>> > >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8222720.2/ > >>> > >>> I switched to os::dll_load / os::dll_lookup . > >>> Also removed the VMWare related names ( now the name is > >> "VirtualizationSupport" ). > >> > >> Thanks! > >> > >> src/hotspot/cpu/x86/vm_version_x86.cpp > >> > >> No ifdefs needed. > >> > >> src/hotspot/share/utilities/virtualizationSupport.cpp > >> > >> 47 #if defined(__linux) > >> > >> The common form of this is: > >> > >> #ifdef LINUX > >> > >> 62 if (GuestLib_StatGet && GuestLib_StatFree) { > >> > >> Style nit: avoid implicit booleans - test against NULL. > >> > >> --- > >> > >> Otherwise seems fine. > >> > >> Thanks, > >> David > >> ----- > >> > >>> Best regards, Matthias > >>> > >>> > >>>> > >>>> Hi David, thanks for the feedback . I'll provide an updated webrev . > >>>> > >>>>> **Not sure about the validity of using "vmware" in the name of files > or > >>>>> classes either due to its trademark status. > >>>> > >>>> Well , we have a lot of technology names in file-names (AIX and > >> Windows > >>>> come to mind) . > >>>> > >>>> But to be on the safe side, I think I'll choose a more generic name . > >>>> > >>>> > >>>> Best regards, Matthias > >>>> > >>> From robbin.ehn at oracle.com Tue May 14 09:08:54 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 14 May 2019 11:08:54 +0200 Subject: 8222720: Provide extended VMWare/vSphere virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: References: <06d00a9c-497b-44de-f834-a0314bd0bf39@oracle.com> <7a05ab9f-5688-7197-e1eb-3c697c41bc75@oracle.com> Message-ID: <20f7a612-9696-f379-d586-0b935c2d1823@oracle.com> Hi Matthias, On 2019-05-14 10:03, Baesken, Matthias wrote: > Hi David, thanks for the review ! > > Robbin, my I add you as reviewer too ? Yes, thanks for fixing. /Robbin > > > Best regards, Matthias > > > >> -----Original Message----- >> From: David Holmes >> Sent: Freitag, 10. Mai 2019 15:41 >> To: Baesken, Matthias ; 'hotspot- >> dev at openjdk.java.net' >> Subject: Re: 8222720: Provide extended VMWare/vSphere virtualization >> related info in the hs_error file on linux/windows x86_64 >> >> On 10/05/2019 7:08 pm, Baesken, Matthias wrote: >>> Hi David, I removed / adjusted the ifdefs and added checks != NULL : >>> >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8222720.3/ >> >> Looks good. >> >>> >>> (not sure however about VMWARE Fusion on Mac, have no access to it ) >> >> No idea either. >> >> Thanks, >> David >> >>> Regards, Matthias >>> >>>> >>>> Hi Matthias, >>>> >>>> On 10/05/2019 4:21 pm, Baesken, Matthias wrote: >>>>> Hello, here is an updated version : >>>>> >>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8222720.2/ >>>>> >>>>> I switched to os::dll_load / os::dll_lookup . >>>>> Also removed the VMWare related names ( now the name is >>>> "VirtualizationSupport" ). >>>> >>>> Thanks! >>>> >>>> src/hotspot/cpu/x86/vm_version_x86.cpp >>>> >>>> No ifdefs needed. >>>> >>>> src/hotspot/share/utilities/virtualizationSupport.cpp >>>> >>>> 47 #if defined(__linux) >>>> >>>> The common form of this is: >>>> >>>> #ifdef LINUX >>>> >>>> 62 if (GuestLib_StatGet && GuestLib_StatFree) { >>>> >>>> Style nit: avoid implicit booleans - test against NULL. >>>> >>>> --- >>>> >>>> Otherwise seems fine. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> Best regards, Matthias >>>>> >>>>> >>>>>> >>>>>> Hi David, thanks for the feedback . I'll provide an updated webrev . >>>>>> >>>>>>> **Not sure about the validity of using "vmware" in the name of files >> or >>>>>>> classes either due to its trademark status. >>>>>> >>>>>> Well , we have a lot of technology names in file-names (AIX and >>>> Windows >>>>>> come to mind) . >>>>>> >>>>>> But to be on the safe side, I think I'll choose a more generic name . >>>>>> >>>>>> >>>>>> Best regards, Matthias >>>>>> >>>>> From david.holmes at oracle.com Tue May 14 09:44:06 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 May 2019 19:44:06 +1000 Subject: [13] RFR (M): 8223213: Implement fast class initialization checks on x86-64 In-Reply-To: <85a4a478-9200-87f2-c966-49af21f687c2@oracle.com> References: <85a4a478-9200-87f2-c966-49af21f687c2@oracle.com> Message-ID: <3e1ceae0-f7a9-e2e6-2b06-59a22540550d@oracle.com> Hi Vladimir, I'll be very happy to see this go in - though I do wish we had more platform coverage than just x86_64. Hopefully the other archs will jump on-board with this as well. I was initially confused by the UseFastClassInitChecks flag as I couldn't really see why you would want to turn it off (other than perhaps during testing) but I see that it is really used (as you explained to Vladimir K.) to exclude the new code for platforms which have not implemented it. Though I'm still not sure that we shouldn't have something to detect it being turned on at runtime on platforms that don't support it (it will likely crash quickly but still ...). Keep wondering if there is a better way to handle this aspect of the change ... I can't comment on the actual interpreter and compiler changes - sorry. This will need re-basing now that JDK-8219974 has been backed out. Thanks, David On 2/05/2019 9:17 am, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8223213/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8223213 > > (It's a followup RFR on a earlier RFC [1].) > > Recent changes severely affected how static initializers are executed > and for long-running initializers it manifested as a severe slowdown. > As an example, it led to a 3x slowdown on some Clojure applications > (JDK-8219233 [2]). The root cause is that until a class is fully > initialized, every invocation of static method on it goes through method > resolution. > > Proposed fix introduces fast class initialization barriers for C1, C2, > and template interpreter on x86-64. I did some experiments with > cross-platform approaches, but haven't got satisfactory results. > > On other platforms, behavior stays (mostly) intact. (I had to revert > some changes introduced by JDK-8219492 [3], since the assumptions they > rely on about accesses inside a class don't hold in all cases.) > > The barrier is as simple as: > ?? if (holder->is_not_initialized() && > ?????? !holder->is_reentrant_initialization(current_thread)) { > ???? // trigger call site re-resolution and block there > ?? } > > There are 3 places where barriers are added: > ? * in template interpreter for invokestatic bytecode; > ? * at nmethod verified entry point (for normal compilations); > ? * c2i adapters; > > For template interperter, there's additional check added into > TemplateTable::resolve_cache_and_index which calls into > InterpreterRuntime::resolve_from_cache when fast path checks fail. > > In case of nmethods, the barrier is put before frame construction, so > existing compiler runtime routines can be reused > (SharedRuntime::get_handle_wrong_method_stub()). > > Also, C2 has a guard on entry (Parse::clinit_deopt()) which triggers > nmethod recompilation once the class is fully initialized. > > OSR compilations don't need a barrier. > > Correspondence between barriers and transitions they cover: > ? (1) from interpreter (barrier on caller side) > ?????? * all transitions: interpreter, compiled (i2c), native, aot, ... > > ? (2) from compiled (barrier on callee side) > ?????? to compiled, to native (barrier in native wrapper on entry) > > ? (3) c2i bypasses both barriers (interpreter and compiled) and > requires a dedicated barrier in c2i > > ? (4) to Graal/AOT code: > ??????? from interpreter: covered by interpreter barrier > ??????? from compiled: call site patching is disabled, leading to > repeated call site resolution until method holder is fully initialized > (original behavior). > > Performance experiments with clojure [2] demonstrated that the fix > almost completely recuperates the regression: > > ? (1) always reresolve (w/o the fix):??? ~12,0s ( 1x) > ? (2) C1/C2 barriers only:??????????????? ~3,8s (~3x) > ? (3) int/C1/C2 barriers:???????????????? ~3,2s (-20%) > -------- > ? (4) barriers disabled for invokestatic? ~3,2s > > I deliberately tried to keep the patch backport-friendly for 8u/11u/12u > and refrained from using newer features like nmethod barriers introduced > recently. The fix can be refactored later specifically for 13 as a > followup change. > > Testing: clojure startup, tier1-5 > > Thanks! > > Best regards, > Vladimir Ivanov > > [1] > https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-April/037760.html > [2] https://bugs.openjdk.java.net/browse/JDK-8219233 > [3] https://bugs.openjdk.java.net/browse/JDK-8219492 From david.holmes at oracle.com Tue May 14 12:17:51 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 May 2019 22:17:51 +1000 Subject: [13] RFR (M): 8223213: Implement fast class initialization checks on x86-64 In-Reply-To: <3e1ceae0-f7a9-e2e6-2b06-59a22540550d@oracle.com> References: <85a4a478-9200-87f2-c966-49af21f687c2@oracle.com> <3e1ceae0-f7a9-e2e6-2b06-59a22540550d@oracle.com> Message-ID: Forgot to mention that your new test doesn't look like it will play nicely when run with Graal enabled, so you may need to split up into different @test sections and add "@requires !vm.graal.enabled" to exclude graal. David On 14/05/2019 7:44 pm, David Holmes wrote: > Hi Vladimir, > > I'll be very happy to see this go in - though I do wish we had more > platform coverage than just x86_64. Hopefully the other archs will jump > on-board with this as well. > > I was initially confused by the UseFastClassInitChecks flag as I > couldn't really see why you would want to turn it off (other than > perhaps during testing) but I see that it is really used (as you > explained to Vladimir K.) to exclude the new code for platforms which > have not implemented it. Though I'm still not sure that we shouldn't > have something to detect it being turned on at runtime on platforms that > don't support it (it will likely crash quickly but still ...). Keep > wondering if there is a better way to handle this aspect of the change ... > > I can't comment on the actual interpreter and compiler changes - sorry. > > This will need re-basing now that JDK-8219974 has been backed out. > > Thanks, > David > > On 2/05/2019 9:17 am, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8223213/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8223213 >> >> (It's a followup RFR on a earlier RFC [1].) >> >> Recent changes severely affected how static initializers are executed >> and for long-running initializers it manifested as a severe slowdown. >> As an example, it led to a 3x slowdown on some Clojure applications >> (JDK-8219233 [2]). The root cause is that until a class is fully >> initialized, every invocation of static method on it goes through >> method resolution. >> >> Proposed fix introduces fast class initialization barriers for C1, C2, >> and template interpreter on x86-64. I did some experiments with >> cross-platform approaches, but haven't got satisfactory results. >> >> On other platforms, behavior stays (mostly) intact. (I had to revert >> some changes introduced by JDK-8219492 [3], since the assumptions they >> rely on about accesses inside a class don't hold in all cases.) >> >> The barrier is as simple as: >> ??? if (holder->is_not_initialized() && >> ??????? !holder->is_reentrant_initialization(current_thread)) { >> ????? // trigger call site re-resolution and block there >> ??? } >> >> There are 3 places where barriers are added: >> ?? * in template interpreter for invokestatic bytecode; >> ?? * at nmethod verified entry point (for normal compilations); >> ?? * c2i adapters; >> >> For template interperter, there's additional check added into >> TemplateTable::resolve_cache_and_index which calls into >> InterpreterRuntime::resolve_from_cache when fast path checks fail. >> >> In case of nmethods, the barrier is put before frame construction, so >> existing compiler runtime routines can be reused >> (SharedRuntime::get_handle_wrong_method_stub()). >> >> Also, C2 has a guard on entry (Parse::clinit_deopt()) which triggers >> nmethod recompilation once the class is fully initialized. >> >> OSR compilations don't need a barrier. >> >> Correspondence between barriers and transitions they cover: >> ?? (1) from interpreter (barrier on caller side) >> ??????? * all transitions: interpreter, compiled (i2c), native, aot, ... >> >> ?? (2) from compiled (barrier on callee side) >> ??????? to compiled, to native (barrier in native wrapper on entry) >> >> ?? (3) c2i bypasses both barriers (interpreter and compiled) and >> requires a dedicated barrier in c2i >> >> ?? (4) to Graal/AOT code: >> ???????? from interpreter: covered by interpreter barrier >> ???????? from compiled: call site patching is disabled, leading to >> repeated call site resolution until method holder is fully initialized >> (original behavior). >> >> Performance experiments with clojure [2] demonstrated that the fix >> almost completely recuperates the regression: >> >> ?? (1) always reresolve (w/o the fix):??? ~12,0s ( 1x) >> ?? (2) C1/C2 barriers only:??????????????? ~3,8s (~3x) >> ?? (3) int/C1/C2 barriers:???????????????? ~3,2s (-20%) >> -------- >> ?? (4) barriers disabled for invokestatic? ~3,2s >> >> I deliberately tried to keep the patch backport-friendly for >> 8u/11u/12u and refrained from using newer features like nmethod >> barriers introduced recently. The fix can be refactored later >> specifically for 13 as a followup change. >> >> Testing: clojure startup, tier1-5 >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov >> >> [1] >> https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-April/037760.html >> >> [2] https://bugs.openjdk.java.net/browse/JDK-8219233 >> [3] https://bugs.openjdk.java.net/browse/JDK-8219492 From thomas.schatzl at oracle.com Tue May 14 13:09:50 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 14 May 2019 15:09:50 +0200 Subject: RFR: 8160539: Stack frame scanning acquires DerivedPointerTableGC_lock mutex In-Reply-To: <7CC6F888-B3C8-40EB-B2A6-02F4C169617B@oracle.com> References: <7CC6F888-B3C8-40EB-B2A6-02F4C169617B@oracle.com> Message-ID: <4e9c9aa5b4aff975d9bff9a444c05029ed2ae66c.camel@oracle.com> Hi Kim, On Fri, 2019-05-10 at 20:13 -0400, Kim Barrett wrote: > Please review this change in the representation of the derived > pointer table. It was a GrowableArray of pointers to derived pointer > entries, protected by the DerivedPoitnerTableGC_lock. It is changed > to a LockFreeStack of such entries. > > Running specjbb2015 with an instrumented VM found occasional > contention for that lock; roughly half of the attempts to lock it > found it already held by another thread. Comparing averages for G1 > Thread Roots times for specjbb2015 before and after the change, > average was reduced by 8% (1ms), max by 16% (11.5ms), and total by 8% > (27ms). Since the code involved is largely GC-agnostic, other > collectors (except Serial) should see similar improvements. > > DerivedPointerTable::update_pointers() showed no significant change; > it only takes about 0.1ms with or without the change of > representation. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8160539 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8160539/open.00/ > > Testing: > mach5 tier1-5, plus the above mentioned specjbb2015 performance > testing. > looks good. Thomas From boris.ulasevich at bell-sw.com Tue May 14 15:39:12 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Tue, 14 May 2019 18:39:12 +0300 Subject: RFR (S) 8220656 : ARM32: -XX:MaxVectorSize=16 makes SIGILL Message-ID: Hi all, Please review a simple change to prevent VLD1/VST1 instructions generation on ARM32 processor without SIMD support. The change overrides MaxVectorSize option set up by user to a value acceptable by the hardware. https://bugs.openjdk.java.net/browse/JDK-8220656 http://cr.openjdk.java.net/~bulasevich/8220656/webrev.01/ thanks, Boris From yumin.qi at gmail.com Tue May 14 18:26:02 2019 From: yumin.qi at gmail.com (yumin qi) Date: Tue, 14 May 2019 11:26:02 -0700 Subject: RFC: JWarmup precompile java hot methods at application startup In-Reply-To: <8cfbaa83-c50f-61c4-5336-5f30b3885d45@oracle.com> References: <8cfbaa83-c50f-61c4-5336-5f30b3885d45@oracle.com> Message-ID: 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 jesper.wilhelmsson at oracle.com Tue May 14 20:25:03 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 14 May 2019 22:25:03 +0200 Subject: RFR: JDK-8223917 - Problemlist compiler/ciReplay/TestServerVM.java Message-ID: <39C5A668-60EE-4D36-ADDF-70CDA57C0E56@oracle.com> Hi, Please review this small change to problemlist compiler/ciReplay/TestServerVM.java that is consistently failing in tier 3 (and intermittently in tier 2). Bug: https://bugs.openjdk.java.net/browse/JDK-8223917 Diff: diff --git a/test/hotspot/jtreg/ProblemList.txt b/test/hotspot/jtreg/ProblemList.txt --- a/test/hotspot/jtreg/ProblemList.txt +++ b/test/hotspot/jtreg/ProblemList.txt @@ -41,6 +41,7 @@ # :hotspot_compiler compiler/ciReplay/TestSAServer.java 8029528 generic-all +compiler/ciReplay/TestServerVM.java 8223885 generic-all compiler/codecache/stress/OverloadCompileQueueTest.java 8166554 generic-all compiler/codegen/Test6896617.java 8193479 generic-all compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java 8140405 generic-all Thanks, /Jesper From kim.barrett at oracle.com Tue May 14 20:28:06 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 14 May 2019 16:28:06 -0400 Subject: RFR: JDK-8223917 - Problemlist compiler/ciReplay/TestServerVM.java In-Reply-To: <39C5A668-60EE-4D36-ADDF-70CDA57C0E56@oracle.com> References: <39C5A668-60EE-4D36-ADDF-70CDA57C0E56@oracle.com> Message-ID: On May 14, 2019, at 4:25 PM, jesper.wilhelmsson at oracle.com wrote: > > Hi, > > Please review this small change to problemlist compiler/ciReplay/TestServerVM.java that is consistently failing in tier 3 (and intermittently in tier 2). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223917 > Diff: > > diff --git a/test/hotspot/jtreg/ProblemList.txt b/test/hotspot/jtreg/ProblemList.txt > --- a/test/hotspot/jtreg/ProblemList.txt > +++ b/test/hotspot/jtreg/ProblemList.txt > @@ -41,6 +41,7 @@ > # :hotspot_compiler > > compiler/ciReplay/TestSAServer.java 8029528 generic-all > +compiler/ciReplay/TestServerVM.java 8223885 generic-all > compiler/codecache/stress/OverloadCompileQueueTest.java 8166554 generic-all > compiler/codegen/Test6896617.java 8193479 generic-all > compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java 8140405 generic-all > > > Thanks, > /Jesper > Looks good. From mikael.vidstedt at oracle.com Tue May 14 20:28:11 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 14 May 2019 13:28:11 -0700 Subject: RFR: JDK-8223917 - Problemlist compiler/ciReplay/TestServerVM.java In-Reply-To: <39C5A668-60EE-4D36-ADDF-70CDA57C0E56@oracle.com> References: <39C5A668-60EE-4D36-ADDF-70CDA57C0E56@oracle.com> Message-ID: Looks good. Cheers, Mikael > On May 14, 2019, at 1:25 PM, jesper.wilhelmsson at oracle.com wrote: > > Hi, > > Please review this small change to problemlist compiler/ciReplay/TestServerVM.java that is consistently failing in tier 3 (and intermittently in tier 2). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223917 > Diff: > > diff --git a/test/hotspot/jtreg/ProblemList.txt b/test/hotspot/jtreg/ProblemList.txt > --- a/test/hotspot/jtreg/ProblemList.txt > +++ b/test/hotspot/jtreg/ProblemList.txt > @@ -41,6 +41,7 @@ > # :hotspot_compiler > > compiler/ciReplay/TestSAServer.java 8029528 generic-all > +compiler/ciReplay/TestServerVM.java 8223885 generic-all > compiler/codecache/stress/OverloadCompileQueueTest.java 8166554 generic-all > compiler/codegen/Test6896617.java 8193479 generic-all > compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java 8140405 generic-all > > > Thanks, > /Jesper > From jesper.wilhelmsson at oracle.com Tue May 14 20:29:40 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 14 May 2019 22:29:40 +0200 Subject: RFR: JDK-8223917 - Problemlist compiler/ciReplay/TestServerVM.java In-Reply-To: References: <39C5A668-60EE-4D36-ADDF-70CDA57C0E56@oracle.com> Message-ID: Thanks Kim! /Jesper > On 14 May 2019, at 22:28, Kim Barrett wrote: > > On May 14, 2019, at 4:25 PM, jesper.wilhelmsson at oracle.com wrote: >> >> Hi, >> >> Please review this small change to problemlist compiler/ciReplay/TestServerVM.java that is consistently failing in tier 3 (and intermittently in tier 2). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223917 >> Diff: >> >> diff --git a/test/hotspot/jtreg/ProblemList.txt b/test/hotspot/jtreg/ProblemList.txt >> --- a/test/hotspot/jtreg/ProblemList.txt >> +++ b/test/hotspot/jtreg/ProblemList.txt >> @@ -41,6 +41,7 @@ >> # :hotspot_compiler >> >> compiler/ciReplay/TestSAServer.java 8029528 generic-all >> +compiler/ciReplay/TestServerVM.java 8223885 generic-all >> compiler/codecache/stress/OverloadCompileQueueTest.java 8166554 generic-all >> compiler/codegen/Test6896617.java 8193479 generic-all >> compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java 8140405 generic-all >> >> >> Thanks, >> /Jesper >> > > Looks good. > From jesper.wilhelmsson at oracle.com Tue May 14 20:29:59 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 14 May 2019 22:29:59 +0200 Subject: RFR: JDK-8223917 - Problemlist compiler/ciReplay/TestServerVM.java In-Reply-To: References: <39C5A668-60EE-4D36-ADDF-70CDA57C0E56@oracle.com> Message-ID: <5FAD17B3-6D60-4262-8D82-C0D8EDEBA733@oracle.com> Thanks Mikael, /Jesper > On 14 May 2019, at 22:28, Mikael Vidstedt wrote: > > > Looks good. > > Cheers, > Mikael > >> On May 14, 2019, at 1:25 PM, jesper.wilhelmsson at oracle.com wrote: >> >> Hi, >> >> Please review this small change to problemlist compiler/ciReplay/TestServerVM.java that is consistently failing in tier 3 (and intermittently in tier 2). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223917 >> Diff: >> >> diff --git a/test/hotspot/jtreg/ProblemList.txt b/test/hotspot/jtreg/ProblemList.txt >> --- a/test/hotspot/jtreg/ProblemList.txt >> +++ b/test/hotspot/jtreg/ProblemList.txt >> @@ -41,6 +41,7 @@ >> # :hotspot_compiler >> >> compiler/ciReplay/TestSAServer.java 8029528 generic-all >> +compiler/ciReplay/TestServerVM.java 8223885 generic-all >> compiler/codecache/stress/OverloadCompileQueueTest.java 8166554 generic-all >> compiler/codegen/Test6896617.java 8193479 generic-all >> compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java 8140405 generic-all >> >> >> Thanks, >> /Jesper >> > From dean.long at oracle.com Tue May 14 20:48:12 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 14 May 2019 13:48:12 -0700 Subject: RFR (S) 8220656 : ARM32: -XX:MaxVectorSize=16 makes SIGILL In-Reply-To: References: Message-ID: <2b472d5c-e7ee-3fae-9b80-a0562a5e97ff@oracle.com> Looks fine, but you might want to print a warning if you override the user's choice. dl On 5/14/19 8:39 AM, Boris Ulasevich wrote: > Hi all, > > Please review a simple change to prevent VLD1/VST1 instructions > generation on ARM32 processor without SIMD support. The change > overrides MaxVectorSize option set up by user to a value acceptable by > the hardware. > > https://bugs.openjdk.java.net/browse/JDK-8220656 > http://cr.openjdk.java.net/~bulasevich/8220656/webrev.01/ > > thanks, > Boris From vladimir.kozlov at oracle.com Tue May 14 20:54:41 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 May 2019 13:54:41 -0700 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <2ddfbcbd-4dff-4b86-ba0b-d5920b80e7ec@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <9dc5704c-7f87-e231-f3cc-7508c1a6d75c@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> Message-ID: <59f2ec26-9945-3547-ada9-69b84928edbc@oracle.com> 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. My main concern is new swap code complicates reliable arraycopy code for very corner case. And you implemented it only for x64 anyway. 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 david.holmes at oracle.com Wed May 15 00:42:02 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 May 2019 10:42:02 +1000 Subject: [PATCH] Fix some assignments of string literals to non-const char* In-Reply-To: <79bcd948-b100-0c13-63c8-4f56c67c940f@oracle.com> References: <7af793d6-b6b7-55e3-0301-1a61acb509ed@oracle.com> <79bcd948-b100-0c13-63c8-4f56c67c940f@oracle.com> Message-ID: Pushed: Changeset: f67269c129f9 Author: dholmes Date: 2019-05-14 20:29 -0400 URL: http://hg.openjdk.java.net/jdk/jdk/rev/f67269c129f9 8223810: HotSpot compile warnings from VS2017 Reviewed-by: dholmes, stuefe Contributed-by: Andrew Luo ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/services/attachListener.hpp ! test/hotspot/gtest/gtestMain.cpp David On 14/05/2019 5:49 pm, David Holmes wrote: > Thanks Thomas. My testing passed so I'll push this in the morning. > > David > ----- > > On 14/05/2019 5:12 pm, Thomas St?fe wrote: >> This looks fine. >> >> Cheers, Thomas >> >> On Tue, May 14, 2019 at 6:45 AM David Holmes > > wrote: >> >> ??? Hi Andrew, >> >> ??? Thanks for the report and patch. We just had something very >> similar go >> ??? through for gcc 9 on non-Windows. :) Interesting gcc didn't complain >> ??? about the code in attachListener.hpp. >> >> ??? I've filed: >> >> ??? https://bugs.openjdk.java.net/browse/JDK-8223810 >> >> ??? and I will sponsor this for you. I've posted a webrev here: >> >> ??? http://cr.openjdk.java.net/~dholmes/8223810/webrev/ >> >> ??? and am running the patch through our build. >> >> ??? Thanks, >> ??? David >> >> ??? On 14/05/2019 10:21 am, Andrew Luo wrote: >> ???? > I've been trying to get the JDK to compile with the new >> ??? /permissive- switch in VS2017 >> ??? (https://devblogs.microsoft.com/cppblog/permissive-switch/) however >> ??? there have been a few issues in various parts of the code.? There >> ??? are a few issues in the hotspot code where we attempt to assign >> ??? string literals to char* (non-const) variables (unnecessarily).? I >> ??? took some time to fix some of these and attached a patch.? Let me >> ??? know if you have any comments/feedback. >> ???? > >> ???? > >> >> c:/Users/Andrew/Documents/mercurial/openjdk/jdk/test/hotspot/gtest/gtestMain.cpp(234): >> >> ??? error C2440: 'initializing': cannot convert from 'const char [19]' >> ??? to 'char *' >> ???? > >> >> c:/Users/Andrew/Documents/mercurial/openjdk/jdk/test/hotspot/gtest/gtestMain.cpp(234): >> >> ??? note: Conversion from string literal loses const qualifier (see >> ??? /Zc:strictStrings) >> ???? > >> >> c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/attachListener_windows.cpp(152): >> >> ??? error C2664: 'AttachOperation::AttachOperation(AttachOperation &&)': >> ??? cannot convert argument 1 from 'const char [9]' to 'char *' >> ???? > >> >> c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/attachListener_windows.cpp(152): >> >> ??? note: Conversion from string literal loses const qualifier (see >> ??? /Zc:strictStrings) >> ???? > >> >> c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/os_windows.cpp(204): >> >> ??? error C2440: 'initializing': cannot convert from 'const char [5]' to >> ??? 'char *' >> ???? > >> >> c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/os_windows.cpp(204): >> >> ??? note: Conversion from string literal loses const qualifier (see >> ??? /Zc:strictStrings) >> ???? > >> >> c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/os_windows.cpp(2214): >> >> ??? error C2440: 'initializing': ... >> ???? > >> ???? > Thanks, >> ???? > >> ???? > -Andrew >> ???? > >> From david.holmes at oracle.com Wed May 15 01:16:25 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 May 2019 11:16:25 +1000 Subject: RFR (S) 8220656 : ARM32: -XX:MaxVectorSize=16 makes SIGILL In-Reply-To: <2b472d5c-e7ee-3fae-9b80-a0562a5e97ff@oracle.com> References: <2b472d5c-e7ee-3fae-9b80-a0562a5e97ff@oracle.com> Message-ID: <213d552c-8b84-c269-463d-f354d65a48bd@oracle.com> On 15/05/2019 6:48 am, dean.long at oracle.com wrote: > Looks fine, but you might want to print a warning if you override the > user's choice. I would normally agree, but in this case the following code will already silently overwrite the user's choice in some cases: 281 if (MaxVectorSize > 16) { 282 FLAG_SET_DEFAULT(MaxVectorSize, 8); 283 } and I find it odd that it drops it back to 8 rather than taking the upper-limit of 16. To me the first problem here is that MaxVectorSize should be a pd_global so each platform can just set the right default to begin with, and set a correct allowed range for that platform. In fact with a constraint function it could even incorporate the has_simd() check. But that's getting a bit beyond the current fix. I can't see any non-convoluted way to print a warning under all the right circumstances, so I'll leave it to Boris to decide what to do here. I don't think a warning is essential. Cheers, David > dl > > On 5/14/19 8:39 AM, Boris Ulasevich wrote: >> Hi all, >> >> Please review a simple change to prevent VLD1/VST1 instructions >> generation on ARM32 processor without SIMD support. The change >> overrides MaxVectorSize option set up by user to a value acceptable by >> the hardware. >> >> https://bugs.openjdk.java.net/browse/JDK-8220656 >> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.01/ >> >> thanks, >> Boris > From tobias.hartmann at oracle.com Wed May 15 09:23:05 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 15 May 2019 11:23:05 +0200 Subject: [13] RFR(S): 8223885: hs_err and replay file may contain garbage when overwriting existing file Message-ID: Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8223885 http://cr.openjdk.java.net/~thartmann/8223885/webrev.00/ With the fix for JDK-8221738 we now overwrite existing hs_err and replay files without truncating the file. This may lead to garbage at the end of the file if the newly written data requires less space. Similar to ciEnv::dump_replay_data() and ciEnv::dump_inline_data(), we should open the file with O_TRUNC to ensure it's properly truncated to zero size. Thanks, Tobias From thomas.stuefe at gmail.com Wed May 15 09:31:56 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 15 May 2019 11:31:56 +0200 Subject: [13] RFR(S): 8223885: hs_err and replay file may contain garbage when overwriting existing file In-Reply-To: References: Message-ID: Hi Tobias, Looks good and trivial. Sorry for breaking replay. Thanks, Thomas On Wed, May 15, 2019, 11:23 Tobias Hartmann wrote: > Hi, > > please review the following patch: > https://bugs.openjdk.java.net/browse/JDK-8223885 > http://cr.openjdk.java.net/~thartmann/8223885/webrev.00/ > > With the fix for JDK-8221738 we now overwrite existing hs_err and replay > files without truncating > the file. This may lead to garbage at the end of the file if the newly > written data requires less > space. Similar to ciEnv::dump_replay_data() and ciEnv::dump_inline_data(), > we should open the file > with O_TRUNC to ensure it's properly truncated to zero size. > > Thanks, > Tobias > From tobias.hartmann at oracle.com Wed May 15 09:43:08 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 15 May 2019 11:43:08 +0200 Subject: [13] RFR(S): 8223885: hs_err and replay file may contain garbage when overwriting existing file In-Reply-To: References: Message-ID: <0d40a41e-f6dc-6016-8ca7-44ffc15e7f3b@oracle.com> Hi Thomas, thanks for the review! Best regards, Tobias On 15.05.19 11:31, Thomas St?fe wrote: > Hi Tobias, > > Looks good and trivial. Sorry for breaking replay. > > Thanks, Thomas > > On Wed, May 15, 2019, 11:23 Tobias Hartmann > wrote: > > Hi, > > please review the following patch: > https://bugs.openjdk.java.net/browse/JDK-8223885 > http://cr.openjdk.java.net/~thartmann/8223885/webrev.00/ > > With the fix for JDK-8221738 we now overwrite existing hs_err and replay files without truncating > the file. This may lead to garbage at the end of the file if the newly written data requires less > space. Similar to ciEnv::dump_replay_data() and ciEnv::dump_inline_data(), we should open the file > with O_TRUNC to ensure it's properly truncated to zero size. > > Thanks, > Tobias > From david.holmes at oracle.com Wed May 15 09:53:26 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 May 2019 19:53:26 +1000 Subject: [13] RFR(S): 8223885: hs_err and replay file may contain garbage when overwriting existing file In-Reply-To: References: Message-ID: <8df29a34-ffb2-25d4-1799-2487910ea772@oracle.com> Looks good! Thanks for recognising the problem. Always some unintended consequence to every fix :( Cheers, David On 15/05/2019 7:23 pm, Tobias Hartmann wrote: > Hi, > > please review the following patch: > https://bugs.openjdk.java.net/browse/JDK-8223885 > http://cr.openjdk.java.net/~thartmann/8223885/webrev.00/ > > With the fix for JDK-8221738 we now overwrite existing hs_err and replay files without truncating > the file. This may lead to garbage at the end of the file if the newly written data requires less > space. Similar to ciEnv::dump_replay_data() and ciEnv::dump_inline_data(), we should open the file > with O_TRUNC to ensure it's properly truncated to zero size. > > Thanks, > Tobias > From tobias.hartmann at oracle.com Wed May 15 10:15:55 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 15 May 2019 12:15:55 +0200 Subject: [13] RFR(S): 8223885: hs_err and replay file may contain garbage when overwriting existing file In-Reply-To: <8df29a34-ffb2-25d4-1799-2487910ea772@oracle.com> References: <8df29a34-ffb2-25d4-1799-2487910ea772@oracle.com> Message-ID: <0ad69f12-6532-8010-2573-1f8e9c8aaa0b@oracle.com> Thanks David! Best regards, Tobias On 15.05.19 11:53, David Holmes wrote: > Looks good! Thanks for recognising the problem. Always some unintended consequence to every fix :( > > Cheers, > David > > On 15/05/2019 7:23 pm, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> https://bugs.openjdk.java.net/browse/JDK-8223885 >> http://cr.openjdk.java.net/~thartmann/8223885/webrev.00/ >> >> With the fix for JDK-8221738 we now overwrite existing hs_err and replay files without truncating >> the file. This may lead to garbage at the end of the file if the newly written data requires less >> space. Similar to ciEnv::dump_replay_data() and ciEnv::dump_inline_data(), we should open the file >> with O_TRUNC to ensure it's properly truncated to zero size. >> >> Thanks, >> Tobias >> From boris.ulasevich at bell-sw.com Wed May 15 11:02:28 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Wed, 15 May 2019 14:02:28 +0300 Subject: RFR (S) 8220656 : ARM32: -XX:MaxVectorSize=16 makes SIGILL In-Reply-To: <213d552c-8b84-c269-463d-f354d65a48bd@oracle.com> References: <2b472d5c-e7ee-3fae-9b80-a0562a5e97ff@oracle.com> <213d552c-8b84-c269-463d-f354d65a48bd@oracle.com> Message-ID: Hi David, Thanks for review! I added a warning and fixed the drop back value: http://cr.openjdk.java.net/~bulasevich/8220656/webrev.02 regards, Boris On 15.05.2019 4:16, David Holmes wrote: > On 15/05/2019 6:48 am, dean.long at oracle.com wrote: >> Looks fine, but you might want to print a warning if you override the >> user's choice. > > I would normally agree, but in this case the following code will already > silently overwrite the user's choice in some cases: > > ?281?? if (MaxVectorSize > 16) { > ?282???? FLAG_SET_DEFAULT(MaxVectorSize, 8); > ?283?? } > > and I find it odd that it drops it back to 8 rather than taking the > upper-limit of 16. > > To me the first problem here is that MaxVectorSize should be a pd_global > so each platform can just set the right default to begin with, and set a > correct allowed range for that platform. In fact with a constraint > function it could even incorporate the has_simd() check. But that's > getting a bit beyond the current fix. > > I can't see any non-convoluted way to print a warning under all the > right circumstances, so I'll leave it to Boris to decide what to do > here. I don't think a warning is essential. > > Cheers, > David > >> dl >> >> On 5/14/19 8:39 AM, Boris Ulasevich wrote: >>> Hi all, >>> >>> Please review a simple change to prevent VLD1/VST1 instructions >>> generation on ARM32 processor without SIMD support. The change >>> overrides MaxVectorSize option set up by user to a value acceptable >>> by the hardware. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8220656 >>> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.01/ >>> >>> thanks, >>> Boris >> From david.holmes at oracle.com Wed May 15 12:39:29 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 May 2019 22:39:29 +1000 Subject: RFR (S) 8220656 : ARM32: -XX:MaxVectorSize=16 makes SIGILL In-Reply-To: References: <2b472d5c-e7ee-3fae-9b80-a0562a5e97ff@oracle.com> <213d552c-8b84-c269-463d-f354d65a48bd@oracle.com> Message-ID: <923ae7d2-5de0-b65b-250d-2fa3d493d649@oracle.com> Hi Boris, On 15/05/2019 9:02 pm, Boris Ulasevich wrote: > Hi David, > > Thanks for review! I added a warning and fixed the drop back value: > http://cr.openjdk.java.net/~bulasevich/8220656/webrev.02 With that change this code is pointless: 274 if (FLAG_IS_DEFAULT(MaxVectorSize)) { 275 // FLAG_SET_DEFAULT(MaxVectorSize, has_simd() ? 16 : 8); 276 // SIMD/NEON can use 16, but default is 8 because currently 277 // larger than 8 will disable instruction scheduling 278 FLAG_SET_DEFAULT(MaxVectorSize, 8); 279 } as it will be handled by your new code. Thanks, David > regards, > Boris > > On 15.05.2019 4:16, David Holmes wrote: >> On 15/05/2019 6:48 am, dean.long at oracle.com wrote: >>> Looks fine, but you might want to print a warning if you override the >>> user's choice. >> >> I would normally agree, but in this case the following code will >> already silently overwrite the user's choice in some cases: >> >> ??281?? if (MaxVectorSize > 16) { >> ??282???? FLAG_SET_DEFAULT(MaxVectorSize, 8); >> ??283?? } >> >> and I find it odd that it drops it back to 8 rather than taking the >> upper-limit of 16. >> >> To me the first problem here is that MaxVectorSize should be a >> pd_global so each platform can just set the right default to begin >> with, and set a correct allowed range for that platform. In fact with >> a constraint function it could even incorporate the has_simd() check. >> But that's getting a bit beyond the current fix. >> >> I can't see any non-convoluted way to print a warning under all the >> right circumstances, so I'll leave it to Boris to decide what to do >> here. I don't think a warning is essential. >> >> Cheers, >> David >> >>> dl >>> >>> On 5/14/19 8:39 AM, Boris Ulasevich wrote: >>>> Hi all, >>>> >>>> Please review a simple change to prevent VLD1/VST1 instructions >>>> generation on ARM32 processor without SIMD support. The change >>>> overrides MaxVectorSize option set up by user to a value acceptable >>>> by the hardware. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8220656 >>>> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.01/ >>>> >>>> thanks, >>>> Boris >>> From boris.ulasevich at bell-sw.com Wed May 15 13:13:44 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Wed, 15 May 2019 16:13:44 +0300 Subject: RFR (S) 8220656 : ARM32: -XX:MaxVectorSize=16 makes SIGILL In-Reply-To: <923ae7d2-5de0-b65b-250d-2fa3d493d649@oracle.com> References: <2b472d5c-e7ee-3fae-9b80-a0562a5e97ff@oracle.com> <213d552c-8b84-c269-463d-f354d65a48bd@oracle.com> <923ae7d2-5de0-b65b-250d-2fa3d493d649@oracle.com> Message-ID: <7f22f026-d238-c880-7d6d-5b0e3382b2fb@bell-sw.com> Hi David, On 15.05.2019 15:39, David Holmes wrote: > Hi Boris, > > On 15/05/2019 9:02 pm, Boris Ulasevich wrote: >> Hi David, >> >> Thanks for review! I added a warning and fixed the drop back value: >> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.02 > > With that change this code is pointless: > > ?274?? if (FLAG_IS_DEFAULT(MaxVectorSize)) { > ?275???? // FLAG_SET_DEFAULT(MaxVectorSize, has_simd() ? 16 : 8); > ?276???? // SIMD/NEON can use 16, but default is 8 because currently > ?277???? // larger than 8 will disable instruction scheduling > ?278???? FLAG_SET_DEFAULT(MaxVectorSize, 8); > ?279?? } > > as it will be handled by your new code. This code sets MaxVectorSize=8 when no -XX:MaxVectorSize option is specified while the new code sets 8/16 when the specified size is too big. I think these two blocks of code live together quite well :) > Thanks, > David > >> regards, >> Boris >> >> On 15.05.2019 4:16, David Holmes wrote: >>> On 15/05/2019 6:48 am, dean.long at oracle.com wrote: >>>> Looks fine, but you might want to print a warning if you override >>>> the user's choice. >>> >>> I would normally agree, but in this case the following code will >>> already silently overwrite the user's choice in some cases: >>> >>> ??281?? if (MaxVectorSize > 16) { >>> ??282???? FLAG_SET_DEFAULT(MaxVectorSize, 8); >>> ??283?? } >>> >>> and I find it odd that it drops it back to 8 rather than taking the >>> upper-limit of 16. >>> >>> To me the first problem here is that MaxVectorSize should be a >>> pd_global so each platform can just set the right default to begin >>> with, and set a correct allowed range for that platform. In fact with >>> a constraint function it could even incorporate the has_simd() check. >>> But that's getting a bit beyond the current fix. >>> >>> I can't see any non-convoluted way to print a warning under all the >>> right circumstances, so I'll leave it to Boris to decide what to do >>> here. I don't think a warning is essential. >>> >>> Cheers, >>> David >>> >>>> dl >>>> >>>> On 5/14/19 8:39 AM, Boris Ulasevich wrote: >>>>> Hi all, >>>>> >>>>> Please review a simple change to prevent VLD1/VST1 instructions >>>>> generation on ARM32 processor without SIMD support. The change >>>>> overrides MaxVectorSize option set up by user to a value acceptable >>>>> by the hardware. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8220656 >>>>> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.01/ >>>>> >>>>> thanks, >>>>> Boris >>>> From coleen.phillimore at oracle.com Wed May 15 13:46:43 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 May 2019 09:46:43 -0400 Subject: RFR (S) 8223585: vmTestbase/runtime/pcl/* get SEGV in MetadataOnStackClosure::do_metadata(Metadata*)+0x0 Message-ID: <6703941c-87cb-fa0b-59fa-400baae99148@oracle.com> Summary: adjust old method table by only one thread. Entries were removed from the redefinition old method table by G1 by multiple threads at a safepoint, so didn't take the CodeCache_lock. Moved the removal to nmethod->flush().? The bug is confidential because there's a confidential comment not marked confidential but we'll open it up once that's fixed. Passed redefinition tests in repository with "VM_OPTIONS=-Xcomp -XX:TieredStopAtLevel=1", including the PCL tests that in the oracle closed repo. Also ran hs-tier1-3. open webrev at http://cr.openjdk.java.net/~coleenp/2019/8223585.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8223585 Thanks, Coleen From christoph.langer at sap.com Wed May 15 13:47:19 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 15 May 2019 13:47:19 +0000 Subject: RFR: 8223438: add VirtualizationInformation JFR event In-Reply-To: References: <5CD309CA.40808@oracle.com> <5CD5794D.20304@oracle.com> Message-ID: Hi Matthias, the change looks good to me. In src/hotspot/cpu/ppc/vm_version_ppc.cpp, the correct SAP copyright header entry would be: * Copyright (c) 2012, 2019 SAP SE. All rights reserved. ...without comma after 2019. Should look like in src/hotspot/cpu/ppc/vm_version_ppc.hpp. Can you please fix that when pushing? Also, in src/hotspot/cpu/ppc/vm_version_ppc.cpp, line 393, the call to perfstat_partition_total: Is 1 the success return code and if it returns 1, one can assume that PowerVM virtualization is available? If you can confirm that, it's fine ?? Best regards Christoph > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Dienstag, 14. Mai 2019 10:02 > To: Erik Gahlin ; 'hotspot-dev at openjdk.java.net' > > Subject: RE: RFR: 8223438: add VirtualizationInformation JFR event > > Thanks Erik , good to hear ! > May I get a second review ? > > Best regards, Matthias > > > From: Erik Gahlin > Sent: Freitag, 10. Mai 2019 15:15 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Subject: Re: RFR: 8223438: add VirtualizationInformation JFR event > > Looks good. > > Erik > > Hello, here is the next webrev with adjusted coding following your > suggestion : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8223438.2/ jdk.java.net/%7Embaesken/webrevs/8223438.2/> > > > Best regards, Matthias > > > From: Baesken, Matthias > Sent: Donnerstag, 9. Mai 2019 09:03 > To: Erik Gahlin ; > 'hotspot-dev at openjdk.java.net' > > Subject: RE: RFR: 8223438: add VirtualizationInformation JFR event > > Hi Erik, the virtualization names are a set of fix names , so I think we can do > what you suggest . > > I just "borrowed" a bit from the code above ... > > TRACE_REQUEST_FUNC(OSInformation) { > ResourceMark rm; > char* os_name = NEW_RESOURCE_ARRAY(char, 2048); > JfrOSInterface::os_version(&os_name); > EventOSInformation event; > event.set_osVersion(os_name); > event.commit(); > } > > ... where a ResourceMark + allocation is used (but in jfrOSInterface I > wonder about the second allocation in string.stream.as_string , do we really > need two here ? > > int JfrOSInterface::JfrOSInterfaceImpl::os_version(char** os_version) const > { > assert(os_version != NULL, "os_version pointer is NULL!"); > stringStream os_ver_info; > os::print_os_info_brief(&os_ver_info); > *os_version = os_ver_info.as_string(); <--- second alloc > > Best regards, Matthias > > > > From: Erik Gahlin > > Sent: Mittwoch, 8. Mai 2019 18:55 > To: Baesken, Matthias > >; > 'hotspot-dev at openjdk.java.net' > > > Subject: Re: RFR: 8223438: add VirtualizationInformation JFR event > > Hello, > > Looks good, but do we really need to allocate the name every time an event > is emitted in jfrPeriodic.cpp? > > It will not matter much from a performance perspective, but the code would > look cleaner if we would have. > > EventVirtualizationInformation event; > event.set_name(JfrOSInterface::virtualization_name()); > event.commit(); > > Thanks > Erik > Hello, please review the following change . > It adds a simple VirtualizationInformation event to JFR . > > The addition to JFR has been previously proposed by Erik when we > discussed the enhancement of hs_error file output with virtualization > related information . > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8223438 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8223438.1/ jdk.java.net/%7Embaesken/webrevs/8223438.1/> > > > Thanks, Matthias > From rahul.v.raghavan at oracle.com Wed May 15 14:46:32 2019 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Wed, 15 May 2019 20:16:32 +0530 Subject: [13] RFR: 8213416: Replace some enums with static const members in hotspot/compiler Message-ID: <1f7afc19-0756-33f8-54f5-2438ed5da886@oracle.com> Hi, Request help review and finalize fix for 8213416. - http://cr.openjdk.java.net/~rraghavan/8213416/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8213416 The requirement is to solve "enumeral and non-enumeral type in conditional expression" warnings triggered with -Wextra enabled for gcc on hotspot. (hotspot/compiler part is handled in this 8213416 task and hotspot/runtime in 8223400) The same warning is generated for ternary operator statements like- (x ? int_val : enum_val). e.g.: comp_level = TieredCompilation ? TieredStopAtLevel : CompLevel_highest_tier; Understood from comments that the following type typecast solution proposed earlier was not accepted. - comp_level = TieredCompilation ? TieredStopAtLevel : CompLevel_highest_tier; + comp_level = TieredCompilation ? TieredStopAtLevel : (int) CompLevel_highest_tier; and then proposed solution was to rewrite those enums to be static const members. Tried changes based on the comments info from JBS. Extracts of related JBS comments- - ".... it's just a simple code refactoring. " - "David H. only complained about NO_HASH which we can fix. We can also fix CompLevel_highest_tier usage - should use CompLevel type everywhere. But I would not touch Op_RegFlags - I don't want to complicate its construction and we have a lot of places where Op_ are used as uint. I would only fix places where it is used as int to make sure it is used as uint everywhere." Reported enums in question for hotspot/compiler 1) NO_HASH 2) CompLevel_highest_tier 3) Op_RegFlags 4) _lh_array_tag_obj_value, _lh_instance_slow_path_bit 1) NO_HASH tried [open/src/hotspot/share/opto/node.hpp] - enum { NO_HASH = 0 }; + static const uint NO_HASH = 0; 2) CompLevel_highest_tier Only one warning in process_compile() [open/src/hotspot/share/ci/ciReplay.cpp] comp_level = TieredCompilation ? TieredStopAtLevel : CompLevel_highest_tier; Following type changes tried did not help - - int comp_level = parse_int(comp_level_label); + CompLevel comp_level = parse_int(comp_level_label); ..... - comp_level = TieredCompilation ? TieredStopAtLevel : CompLevel_highest_tier; + comp_level = TieredCompilation ? (CompLevel) TieredStopAtLevel : CompLevel_highest_tier; The warning is with only ternary operator usage in this location. So tried simple code refactoring like following and got no more warnings! Is this okay? - comp_level = TieredCompilation ? TieredStopAtLevel : CompLevel_highest_tier; + if (TieredCompilation) { + comp_level = TieredStopAtLevel; + } else { + comp_level = CompLevel_highest_tier; + } 3) Op_RegFlags Warnings only for 'virtual uint MachNode::ideal_reg() const' ../open/src/hotspot/share/opto/machnode.hpp: In member function 'virtual uint MachNode::ideal_reg() const': ../open/src/hotspot/share/opto/machnode.hpp:304:95: warning: enumeral and non-enumeral type in conditional expression [-Wextra] virtual uint ideal_reg() const { const Type *t = _opnds[0]->type(); return t == TypeInt::CC ? Op_RegFlags : t->ideal_reg(); } ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Op_RegFlags is returned as uint itself here. How to modify code to solve warning? Again since the issue is with only ternary operator usage in only one location, can we go for simple code refactoring like following? - virtual uint ideal_reg() const { const Type *t = _opnds[0]->type(); return t == TypeInt::CC ? Op_RegFlags : t->ideal_reg(); } + virtual uint ideal_reg() const { + const Type *t = _opnds[0]->type(); + if (t == TypeInt::CC) { + return Op_RegFlags; + } else { + return t->ideal_reg(); + } + } 4) _lh_array_tag_obj_value, _lh_instance_slow_path_bit - warnings locations - (i) ../open/src/hotspot/share/oops/klass.cpp: In static member function 'static jint Klass::array_layout_helper(BasicType)': ../open/src/hotspot/share/oops/klass.cpp:212:23: warning: enumeral and non-enumeral type in conditional expression [-Wextra] int tag = isobj ? _lh_array_tag_obj_value : _lh_array_tag_type_value; (ii) ../open/src/hotspot/cpu/x86/c1_Runtime1_x86.cpp: In static member function 'static OopMapSet* Runtime1::generate_code_for(Runtime1::StubID, StubAssembler*)': ../open/src/hotspot/cpu/x86/c1_Runtime1_x86.cpp:1126:22: warning: enumeral and non-enumeral type in conditional expression [-Wextra] int tag = ((id == new_type_array_id) ~~~~~~~~~~~~~~~~~~~~~~~~~ ? Klass::_lh_array_tag_type_value ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ : Klass::_lh_array_tag_obj_value); (iii) ../open/src/hotspot/share/oops/klass.hpp: In static member function 'static jint Klass::instance_layout_helper(jint, bool)': ../open/src/hotspot/share/oops/klass.hpp:422:28: warning: enumeral and non-enumeral type in conditional expression [-Wextra] | (slow_path_flag ? _lh_instance_slow_path_bit : 0); ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Following changes fixed the warnings! (using static const int instead of unnamed enum) [open/src/hotspot/share/oops/klass.cpp] .......... // Unpacking layout_helper: - enum { - _lh_neutral_value = 0, // neutral non-array non-instance value - _lh_instance_slow_path_bit = 0x01, - _lh_log2_element_size_shift = BitsPerByte*0, - _lh_log2_element_size_mask = BitsPerLong-1, - _lh_element_type_shift = BitsPerByte*1, - _lh_element_type_mask = right_n_bits(BitsPerByte), // shifted mask - _lh_header_size_shift = BitsPerByte*2, - _lh_header_size_mask = right_n_bits(BitsPerByte), // shifted mask - _lh_array_tag_bits = 2, - _lh_array_tag_shift = BitsPerInt - _lh_array_tag_bits, - _lh_array_tag_obj_value = ~0x01 // 0x80000000 >> 30 - }; + static const int _lh_neutral_value = 0; // neutral non-array non-instance value + static const int _lh_instance_slow_path_bit = 0x01; + static const int _lh_log2_element_size_shift = BitsPerByte*0; + static const int _lh_log2_element_size_mask = BitsPerLong-1; + static const int _lh_element_type_shift = BitsPerByte*1; + static const int _lh_element_type_mask = right_n_bits(BitsPerByte); // shifted mask + static const int _lh_header_size_shift = BitsPerByte*2; + static const int _lh_header_size_mask = right_n_bits(BitsPerByte); // shifted mask + static const int _lh_array_tag_bits = 2; + static const int _lh_array_tag_shift = BitsPerInt - _lh_array_tag_bits; + static const int _lh_array_tag_obj_value = ~0x01; // 0x80000000 >> 30 ....... - http://cr.openjdk.java.net/~rraghavan/8213416/webrev.00/ Understood the affected code locations details from the old sample patch attachment of related JDK-8211073 # https://bugs.openjdk.java.net/secure/attachment/79387/hotspot-disable-wextra.diff Also confirmed no similar warnings in hotspot/compiler with -Wextra, no issues with build with this proposed webrev.00 Thanks, Rahul From matthias.baesken at sap.com Wed May 15 15:39:40 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 15 May 2019 15:39:40 +0000 Subject: RFR: 8223438: add VirtualizationInformation JFR event In-Reply-To: References: <5CD309CA.40808@oracle.com> <5CD5794D.20304@oracle.com> Message-ID: Hi Christoph, the man page of perfstat_partition_total says : Return Values Upon successful completion, the number of structures filled is returned. If unsuccessful, a value of -1 is returned and the errno global variable is set. I call with 1 structure to fill , see ; 392 perfstat_partition_total_t pinfo; 393 rc = perfstat_partition_total(NULL, &pinfo, sizeof(perfstat_partition_total_t), 1); So I think this is fine . Do you have any concerns ? Best regards, Matthias > -----Original Message----- > From: Langer, Christoph > Sent: Mittwoch, 15. Mai 2019 15:47 > To: Baesken, Matthias ; Erik Gahlin > ; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: RE: RFR: 8223438: add VirtualizationInformation JFR event > > Hi Matthias, > > the change looks good to me. > > In src/hotspot/cpu/ppc/vm_version_ppc.cpp, the correct SAP copyright > header entry would be: > * Copyright (c) 2012, 2019 SAP SE. All rights reserved. > ...without comma after 2019. Should look like in > src/hotspot/cpu/ppc/vm_version_ppc.hpp. Can you please fix that when > pushing? > > Also, in src/hotspot/cpu/ppc/vm_version_ppc.cpp, line 393, the call to > perfstat_partition_total: Is 1 the success return code and if it returns 1, one > can assume that PowerVM virtualization is available? If you can confirm that, > it's fine ?? > > Best regards > Christoph > > > -----Original Message----- > > From: hotspot-dev On Behalf > Of > > Baesken, Matthias > > Sent: Dienstag, 14. Mai 2019 10:02 > > To: Erik Gahlin ; 'hotspot-dev at openjdk.java.net' > > > > Subject: RE: RFR: 8223438: add VirtualizationInformation JFR event > > > > Thanks Erik , good to hear ! > > May I get a second review ? > > > > Best regards, Matthias > > > > > > From: Erik Gahlin > > Sent: Freitag, 10. Mai 2019 15:15 > > To: Baesken, Matthias ; 'hotspot- > > dev at openjdk.java.net' > > Subject: Re: RFR: 8223438: add VirtualizationInformation JFR event > > > > Looks good. > > > > Erik > > > > Hello, here is the next webrev with adjusted coding following your > > suggestion : > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8223438.2/ > jdk.java.net/%7Embaesken/webrevs/8223438.2/> > > > > > > Best regards, Matthias > > > > > > From: Baesken, Matthias > > Sent: Donnerstag, 9. Mai 2019 09:03 > > To: Erik Gahlin ; > > 'hotspot-dev at openjdk.java.net' > > dev at openjdk.java.net> > > Subject: RE: RFR: 8223438: add VirtualizationInformation JFR event > > > > Hi Erik, the virtualization names are a set of fix names , so I think we can > do > > what you suggest . > > > > I just "borrowed" a bit from the code above ... > > > > TRACE_REQUEST_FUNC(OSInformation) { > > ResourceMark rm; > > char* os_name = NEW_RESOURCE_ARRAY(char, 2048); > > JfrOSInterface::os_version(&os_name); > > EventOSInformation event; > > event.set_osVersion(os_name); > > event.commit(); > > } > > > > ... where a ResourceMark + allocation is used (but in jfrOSInterface I > > wonder about the second allocation in string.stream.as_string , do we > really > > need two here ? > > > > int JfrOSInterface::JfrOSInterfaceImpl::os_version(char** os_version) > const > > { > > assert(os_version != NULL, "os_version pointer is NULL!"); > > stringStream os_ver_info; > > os::print_os_info_brief(&os_ver_info); > > *os_version = os_ver_info.as_string(); <--- second alloc > > > > Best regards, Matthias > > > > > > > > From: Erik Gahlin > > > > Sent: Mittwoch, 8. Mai 2019 18:55 > > To: Baesken, Matthias > > >; > > 'hotspot-dev at openjdk.java.net' > > dev at openjdk.java.net>> > > Subject: Re: RFR: 8223438: add VirtualizationInformation JFR event > > > > Hello, > > > > Looks good, but do we really need to allocate the name every time an > event > > is emitted in jfrPeriodic.cpp? > > > > It will not matter much from a performance perspective, but the code > would > > look cleaner if we would have. > > > > EventVirtualizationInformation event; > > event.set_name(JfrOSInterface::virtualization_name()); > > event.commit(); > > > > Thanks > > Erik > > Hello, please review the following change . > > It adds a simple VirtualizationInformation event to JFR . > > > > The addition to JFR has been previously proposed by Erik when we > > discussed the enhancement of hs_error file output with virtualization > > related information . > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8223438 > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8223438.1/ > jdk.java.net/%7Embaesken/webrevs/8223438.1/> > > > > > > Thanks, Matthias > > From christoph.langer at sap.com Wed May 15 15:41:41 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 15 May 2019 15:41:41 +0000 Subject: RFR: 8223438: add VirtualizationInformation JFR event In-Reply-To: References: <5CD309CA.40808@oracle.com> <5CD5794D.20304@oracle.com> Message-ID: Hi Matthias, thanks for the explanation. Looks good to me. Best regards Christoph > -----Original Message----- > From: Baesken, Matthias > Sent: Mittwoch, 15. Mai 2019 17:40 > To: Langer, Christoph ; Erik Gahlin > ; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: RE: RFR: 8223438: add VirtualizationInformation JFR event > > Hi Christoph, the man page of perfstat_partition_total says : > > Return Values > > Upon successful completion, the number of structures filled is returned. > If unsuccessful, a value of -1 is returned and the errno global variable is set. > > I call with 1 structure to fill , see ; > > 392 perfstat_partition_total_t pinfo; > 393 rc = perfstat_partition_total(NULL, &pinfo, > sizeof(perfstat_partition_total_t), 1); > > > So I think this is fine . Do you have any concerns ? > > Best regards, Matthias > > > > > -----Original Message----- > > From: Langer, Christoph > > Sent: Mittwoch, 15. Mai 2019 15:47 > > To: Baesken, Matthias ; Erik Gahlin > > ; 'hotspot-dev at openjdk.java.net' > dev at openjdk.java.net> > > Subject: RE: RFR: 8223438: add VirtualizationInformation JFR event > > > > Hi Matthias, > > > > the change looks good to me. > > > > In src/hotspot/cpu/ppc/vm_version_ppc.cpp, the correct SAP copyright > > header entry would be: > > * Copyright (c) 2012, 2019 SAP SE. All rights reserved. > > ...without comma after 2019. Should look like in > > src/hotspot/cpu/ppc/vm_version_ppc.hpp. Can you please fix that when > > pushing? > > > > Also, in src/hotspot/cpu/ppc/vm_version_ppc.cpp, line 393, the call to > > perfstat_partition_total: Is 1 the success return code and if it returns 1, one > > can assume that PowerVM virtualization is available? If you can confirm > that, > > it's fine ?? > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: hotspot-dev On Behalf > > Of > > > Baesken, Matthias > > > Sent: Dienstag, 14. Mai 2019 10:02 > > > To: Erik Gahlin ; 'hotspot- > dev at openjdk.java.net' > > > > > > Subject: RE: RFR: 8223438: add VirtualizationInformation JFR event > > > > > > Thanks Erik , good to hear ! > > > May I get a second review ? > > > > > > Best regards, Matthias > > > > > > > > > From: Erik Gahlin > > > Sent: Freitag, 10. Mai 2019 15:15 > > > To: Baesken, Matthias ; 'hotspot- > > > dev at openjdk.java.net' > > > Subject: Re: RFR: 8223438: add VirtualizationInformation JFR event > > > > > > Looks good. > > > > > > Erik > > > > > > Hello, here is the next webrev with adjusted coding following your > > > suggestion : > > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8223438.2/ > > jdk.java.net/%7Embaesken/webrevs/8223438.2/> > > > > > > > > > Best regards, Matthias > > > > > > > > > From: Baesken, Matthias > > > Sent: Donnerstag, 9. Mai 2019 09:03 > > > To: Erik Gahlin > ; > > > 'hotspot-dev at openjdk.java.net dev at openjdk.java.net>' > > > > dev at openjdk.java.net> > > > Subject: RE: RFR: 8223438: add VirtualizationInformation JFR event > > > > > > Hi Erik, the virtualization names are a set of fix names , so I think we > can > > do > > > what you suggest . > > > > > > I just "borrowed" a bit from the code above ... > > > > > > TRACE_REQUEST_FUNC(OSInformation) { > > > ResourceMark rm; > > > char* os_name = NEW_RESOURCE_ARRAY(char, 2048); > > > JfrOSInterface::os_version(&os_name); > > > EventOSInformation event; > > > event.set_osVersion(os_name); > > > event.commit(); > > > } > > > > > > ... where a ResourceMark + allocation is used (but in jfrOSInterface I > > > wonder about the second allocation in string.stream.as_string , do we > > really > > > need two here ? > > > > > > int JfrOSInterface::JfrOSInterfaceImpl::os_version(char** os_version) > > const > > > { > > > assert(os_version != NULL, "os_version pointer is NULL!"); > > > stringStream os_ver_info; > > > os::print_os_info_brief(&os_ver_info); > > > *os_version = os_ver_info.as_string(); <--- second alloc > > > > > > Best regards, Matthias > > > > > > > > > > > > From: Erik Gahlin > > > > > > Sent: Mittwoch, 8. Mai 2019 18:55 > > > To: Baesken, Matthias > > > >; > > > 'hotspot-dev at openjdk.java.net dev at openjdk.java.net>' > > > > dev at openjdk.java.net>> > > > Subject: Re: RFR: 8223438: add VirtualizationInformation JFR event > > > > > > Hello, > > > > > > Looks good, but do we really need to allocate the name every time an > > event > > > is emitted in jfrPeriodic.cpp? > > > > > > It will not matter much from a performance perspective, but the code > > would > > > look cleaner if we would have. > > > > > > EventVirtualizationInformation event; > > > event.set_name(JfrOSInterface::virtualization_name()); > > > event.commit(); > > > > > > Thanks > > > Erik > > > Hello, please review the following change . > > > It adds a simple VirtualizationInformation event to JFR . > > > > > > The addition to JFR has been previously proposed by Erik when we > > > discussed the enhancement of hs_error file output with virtualization > > > related information . > > > > > > Bug/webrev : > > > > > > https://bugs.openjdk.java.net/browse/JDK-8223438 > > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8223438.1/ > > jdk.java.net/%7Embaesken/webrevs/8223438.1/> > > > > > > > > > Thanks, Matthias > > > From vladimir.kozlov at oracle.com Wed May 15 16:31:59 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 May 2019 09:31:59 -0700 Subject: [13] RFR: 8213416: Replace some enums with static const members in hotspot/compiler In-Reply-To: <1f7afc19-0756-33f8-54f5-2438ed5da886@oracle.com> References: <1f7afc19-0756-33f8-54f5-2438ed5da886@oracle.com> Message-ID: <8f18e15d-cae8-58eb-b4a1-870ca6ffaf15@oracle.com> Hi Rahul, Comments are inlined below. On 5/15/19 7:46 AM, Rahul Raghavan wrote: > Hi, > > Request help review and finalize fix for 8213416. > > - http://cr.openjdk.java.net/~rraghavan/8213416/webrev.00/ > > https://bugs.openjdk.java.net/browse/JDK-8213416 > > The requirement is to solve > ? "enumeral and non-enumeral type in conditional expression" warnings > ? triggered with -Wextra enabled for gcc on hotspot. > > (hotspot/compiler part is handled in this 8213416 task > and hotspot/runtime in 8223400) > > The same warning is generated for ternary operator statements like- > ? (x ? int_val : enum_val). > e.g.: > comp_level = TieredCompilation ? TieredStopAtLevel : CompLevel_highest_tier; > > > Understood from comments that the following type typecast solution proposed earlier was not accepted. > - comp_level = TieredCompilation ? TieredStopAtLevel : CompLevel_highest_tier; > + comp_level = TieredCompilation ? TieredStopAtLevel : (int) CompLevel_highest_tier; > and then proposed solution was to rewrite those enums to be static const members. > > > Tried changes based on the comments info from JBS. > Extracts of related JBS comments- > - ".... it's just a simple code refactoring. " > - "David H. only complained about NO_HASH which we can fix. > We can also fix CompLevel_highest_tier usage - should use CompLevel type everywhere. > But I would not touch Op_RegFlags - > ? I don't want to complicate its construction and > ? we have a lot of places where Op_ are used as uint. > ? I would only fix places where it is used as int to make sure it is used as uint everywhere." > > Reported enums in question for hotspot/compiler > 1) NO_HASH > 2) CompLevel_highest_tier > 3) Op_RegFlags > 4) _lh_array_tag_obj_value, _lh_instance_slow_path_bit > > > > 1) NO_HASH > tried [open/src/hotspot/share/opto/node.hpp] > -? enum { NO_HASH = 0 }; > +? static const uint NO_HASH = 0; > Okay. > > > 2) CompLevel_highest_tier > Only one warning in process_compile() > [open/src/hotspot/share/ci/ciReplay.cpp] > comp_level = TieredCompilation ? TieredStopAtLevel : CompLevel_highest_tier; > > Following type changes tried did not help - > -??? int comp_level = parse_int(comp_level_label); > +??? CompLevel comp_level = parse_int(comp_level_label); > ..... > -????? comp_level = TieredCompilation ? TieredStopAtLevel : CompLevel_highest_tier; > +????? comp_level = TieredCompilation ? (CompLevel) TieredStopAtLevel : CompLevel_highest_tier; > Thank you for explaining that it did not work. > > The warning is with only ternary operator usage in this location. > So tried simple code refactoring like following and got no more warnings! > Is this okay? > -????? comp_level = TieredCompilation ? TieredStopAtLevel : CompLevel_highest_tier; > +????? if (TieredCompilation) { > +??????? comp_level = TieredStopAtLevel; > +????? } else { > +??????? comp_level = CompLevel_highest_tier > +????? } > Good. > > > 3) Op_RegFlags > Warnings only for 'virtual uint MachNode::ideal_reg() const' > > ../open/src/hotspot/share/opto/machnode.hpp: In member function 'virtual uint MachNode::ideal_reg() const': > ../open/src/hotspot/share/opto/machnode.hpp:304:95: warning: enumeral and non-enumeral type in conditional expression > [-Wextra] > ?? virtual uint ideal_reg() const { const Type *t = _opnds[0]->type(); return t == TypeInt::CC ? Op_RegFlags : > t->ideal_reg(); } > > ????? ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Op_RegFlags is returned as uint itself here. > How to modify code to solve warning? > Again since the issue is with only ternary operator usage in only one location, can we go for simple code refactoring > like following? > > -? virtual uint ideal_reg() const { const Type *t = _opnds[0]->type(); return t == TypeInt::CC ? Op_RegFlags : > t->ideal_reg(); } > +? virtual uint ideal_reg() const { > +??? const Type *t = _opnds[0]->type(); > +??? if (t == TypeInt::CC) { > +????? return Op_RegFlags; > +??? } else { > +????? return t->ideal_reg(); > +??? } > +? } > Good. I agree. > > > 4) _lh_array_tag_obj_value, _lh_instance_slow_path_bit - > warnings locations - > > (i) ../open/src/hotspot/share/oops/klass.cpp: In static member function 'static jint > Klass::array_layout_helper(BasicType)': > ../open/src/hotspot/share/oops/klass.cpp:212:23: warning: enumeral and non-enumeral type in conditional expression > [-Wextra] > ?? int? tag?? =? isobj ? _lh_array_tag_obj_value : _lh_array_tag_type_value; > > (ii) ../open/src/hotspot/cpu/x86/c1_Runtime1_x86.cpp: In static member function 'static OopMapSet* > Runtime1::generate_code_for(Runtime1::StubID, StubAssembler*)': > ../open/src/hotspot/cpu/x86/c1_Runtime1_x86.cpp:1126:22: warning: enumeral and non-enumeral type in conditional > expression [-Wextra] > ?????????? int tag = ((id == new_type_array_id) > ????????????????????? ~~~~~~~~~~~~~~~~~~~~~~~~~ > ????????????????????? ? Klass::_lh_array_tag_type_value > ????????????????????? ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ????????????????????? : Klass::_lh_array_tag_obj_value); > > (iii) ../open/src/hotspot/share/oops/klass.hpp: In static member function 'static jint > Klass::instance_layout_helper(jint, bool)': > ../open/src/hotspot/share/oops/klass.hpp:422:28: warning: enumeral and non-enumeral type in conditional expression > [-Wextra] > ?????? |??? (slow_path_flag ? _lh_instance_slow_path_bit : 0); > ???????????? ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Following changes fixed the warnings! > (using static const int instead of unnamed enum) > [open/src/hotspot/share/oops/klass.cpp] > .......... > ?? // Unpacking layout_helper: > -? enum { > -??? _lh_neutral_value?????????? = 0,? // neutral non-array non-instance value > -??? _lh_instance_slow_path_bit? = 0x01, > -??? _lh_log2_element_size_shift = BitsPerByte*0, > -??? _lh_log2_element_size_mask? = BitsPerLong-1, > -??? _lh_element_type_shift????? = BitsPerByte*1, > -??? _lh_element_type_mask?????? = right_n_bits(BitsPerByte),? // shifted mask > -??? _lh_header_size_shift?????? = BitsPerByte*2, > -??? _lh_header_size_mask??????? = right_n_bits(BitsPerByte),? // shifted mask > -??? _lh_array_tag_bits????????? = 2, > -??? _lh_array_tag_shift???????? = BitsPerInt - _lh_array_tag_bits, > -??? _lh_array_tag_obj_value???? = ~0x01?? // 0x80000000 >> 30 > -? }; > +? static const int _lh_neutral_value?????????? = 0;? // neutral non-array non-instance value > +? static const int _lh_instance_slow_path_bit? = 0x01; > +? static const int _lh_log2_element_size_shift = BitsPerByte*0; > +? static const int _lh_log2_element_size_mask? = BitsPerLong-1; > +? static const int _lh_element_type_shift????? = BitsPerByte*1; > +? static const int _lh_element_type_mask?????? = right_n_bits(BitsPerByte);? // shifted mask > +? static const int _lh_header_size_shift?????? = BitsPerByte*2; > +? static const int _lh_header_size_mask??????? = right_n_bits(BitsPerByte);? // shifted mask > +? static const int _lh_array_tag_bits????????? = 2; > +? static const int _lh_array_tag_shift???????? = BitsPerInt - _lh_array_tag_bits; > +? static const int _lh_array_tag_obj_value???? = ~0x01;?? // 0x80000000 >> 30 > ....... > I am okay with it but Runtime group should agree too - it is their code. > > > - http://cr.openjdk.java.net/~rraghavan/8213416/webrev.00/ > > Understood the affected code locations details from the old sample patch attachment of related JDK-8211073 > # https://bugs.openjdk.java.net/secure/attachment/79387/hotspot-disable-wextra.diff > Also confirmed no similar warnings in hotspot/compiler with -Wextra, > no issues with build with this proposed webrev.00 Good. Thanks, Vladimir > > > Thanks, > Rahul From vladimir.kozlov at oracle.com Wed May 15 16:34:13 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 May 2019 09:34:13 -0700 Subject: RFR (S) 8223585: vmTestbase/runtime/pcl/* get SEGV in MetadataOnStackClosure::do_metadata(Metadata*)+0x0 In-Reply-To: <6703941c-87cb-fa0b-59fa-400baae99148@oracle.com> References: <6703941c-87cb-fa0b-59fa-400baae99148@oracle.com> Message-ID: <3062a50e-9da4-9272-247a-6467d70fd841@oracle.com> Looks good. Thanks, Vladimir On 5/15/19 6:46 AM, coleen.phillimore at oracle.com wrote: > Summary: adjust old method table by only one thread. > > Entries were removed from the redefinition old method table by G1 by multiple threads at a safepoint, so didn't take the > CodeCache_lock. Moved the removal to nmethod->flush().? The bug is confidential because there's a confidential comment > not marked confidential but we'll open it up once that's fixed. > > Passed redefinition tests in repository with "VM_OPTIONS=-Xcomp -XX:TieredStopAtLevel=1", including the PCL tests that > in the oracle closed repo. > > Also ran hs-tier1-3. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8223585.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8223585 > > Thanks, > Coleen From jcbeyler at google.com Wed May 15 17:04:05 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 15 May 2019 10:04:05 -0700 Subject: RFR (S) 8223585: vmTestbase/runtime/pcl/* get SEGV in MetadataOnStackClosure::do_metadata(Metadata*)+0x0 In-Reply-To: <3062a50e-9da4-9272-247a-6467d70fd841@oracle.com> References: <6703941c-87cb-fa0b-59fa-400baae99148@oracle.com> <3062a50e-9da4-9272-247a-6467d70fd841@oracle.com> Message-ID: Hi Coleen, Looks good to me (not an official reviewer), Jc *From: *Vladimir Kozlov *Date: *Wed, May 15, 2019 at 9:34 AM *To: * , hotspot-dev developers, serviceability-dev at openjdk.java.net Looks good. > > Thanks, > Vladimir > > On 5/15/19 6:46 AM, coleen.phillimore at oracle.com wrote: > > Summary: adjust old method table by only one thread. > > > > Entries were removed from the redefinition old method table by G1 by > multiple threads at a safepoint, so didn't take the > > CodeCache_lock. Moved the removal to nmethod->flush(). The bug is > confidential because there's a confidential comment > > not marked confidential but we'll open it up once that's fixed. > > > > Passed redefinition tests in repository with "VM_OPTIONS=-Xcomp > -XX:TieredStopAtLevel=1", including the PCL tests that > > in the oracle closed repo. > > > > Also ran hs-tier1-3. > > > > open webrev at > http://cr.openjdk.java.net/~coleenp/2019/8223585.01/webrev > > bug link https://bugs.openjdk.java.net/browse/JDK-8223585 > > > > Thanks, > > Coleen > -- Thanks, Jc From dean.long at oracle.com Wed May 15 17:54:05 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 15 May 2019 10:54:05 -0700 Subject: RFR (S) 8220656 : ARM32: -XX:MaxVectorSize=16 makes SIGILL In-Reply-To: <7f22f026-d238-c880-7d6d-5b0e3382b2fb@bell-sw.com> References: <2b472d5c-e7ee-3fae-9b80-a0562a5e97ff@oracle.com> <213d552c-8b84-c269-463d-f354d65a48bd@oracle.com> <923ae7d2-5de0-b65b-250d-2fa3d493d649@oracle.com> <7f22f026-d238-c880-7d6d-5b0e3382b2fb@bell-sw.com> Message-ID: <16fd4043-5642-1ff9-496d-e94af181d906@oracle.com> On 5/15/19 6:13 AM, Boris Ulasevich wrote: > Hi David, > > On 15.05.2019 15:39, David Holmes wrote: >> Hi Boris, >> >> On 15/05/2019 9:02 pm, Boris Ulasevich wrote: >>> Hi David, >>> >>> Thanks for review! I added a warning and fixed the drop back value: >>> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.02 >> >> With that change this code is pointless: >> >> ??274?? if (FLAG_IS_DEFAULT(MaxVectorSize)) { >> ??275???? // FLAG_SET_DEFAULT(MaxVectorSize, has_simd() ? 16 : 8); >> ??276???? // SIMD/NEON can use 16, but default is 8 because currently >> ??277???? // larger than 8 will disable instruction scheduling >> ??278???? FLAG_SET_DEFAULT(MaxVectorSize, 8); >> ??279?? } >> >> as it will be handled by your new code. > > This code sets MaxVectorSize=8 when no -XX:MaxVectorSize option is > specified while the new code sets 8/16 when the specified size is too > big. I think these two blocks of code live together quite well :) > Assuming the default arm32 value doesn't trigger the warning, then only a user override should trigger the warning, so it looks good to me. dl >> Thanks, >> David >> >>> regards, >>> Boris >>> >>> On 15.05.2019 4:16, David Holmes wrote: >>>> On 15/05/2019 6:48 am, dean.long at oracle.com wrote: >>>>> Looks fine, but you might want to print a warning if you override >>>>> the user's choice. >>>> >>>> I would normally agree, but in this case the following code will >>>> already silently overwrite the user's choice in some cases: >>>> >>>> ??281?? if (MaxVectorSize > 16) { >>>> ??282???? FLAG_SET_DEFAULT(MaxVectorSize, 8); >>>> ??283?? } >>>> >>>> and I find it odd that it drops it back to 8 rather than taking the >>>> upper-limit of 16. >>>> >>>> To me the first problem here is that MaxVectorSize should be a >>>> pd_global so each platform can just set the right default to begin >>>> with, and set a correct allowed range for that platform. In fact >>>> with a constraint function it could even incorporate the has_simd() >>>> check. But that's getting a bit beyond the current fix. >>>> >>>> I can't see any non-convoluted way to print a warning under all the >>>> right circumstances, so I'll leave it to Boris to decide what to do >>>> here. I don't think a warning is essential. >>>> >>>> Cheers, >>>> David >>>> >>>>> dl >>>>> >>>>> On 5/14/19 8:39 AM, Boris Ulasevich wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review a simple change to prevent VLD1/VST1 instructions >>>>>> generation on ARM32 processor without SIMD support. The change >>>>>> overrides MaxVectorSize option set up by user to a value >>>>>> acceptable by the hardware. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8220656 >>>>>> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.01/ >>>>>> >>>>>> thanks, >>>>>> Boris >>>>> From coleen.phillimore at oracle.com Wed May 15 18:51:55 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 May 2019 14:51:55 -0400 Subject: RFR (S) 8223585: vmTestbase/runtime/pcl/* get SEGV in MetadataOnStackClosure::do_metadata(Metadata*)+0x0 In-Reply-To: References: <6703941c-87cb-fa0b-59fa-400baae99148@oracle.com> <3062a50e-9da4-9272-247a-6467d70fd841@oracle.com> Message-ID: <841fe30a-4aa7-2f2c-5ca3-3354dd907a09@oracle.com> Thanks JC! Coleen On 5/15/19 1:04 PM, Jean Christophe Beyler wrote: > Hi Coleen, > > Looks good to me (not an official reviewer), > Jc > > *From: *Vladimir Kozlov > > *Date: *Wed, May 15, 2019 at 9:34 AM > *To: * >, hotspot-dev developers, > serviceability-dev at openjdk.java.net > > > Looks good. > > Thanks, > Vladimir > > On 5/15/19 6:46 AM, coleen.phillimore at oracle.com > wrote: > > Summary: adjust old method table by only one thread. > > > > Entries were removed from the redefinition old method table by > G1 by multiple threads at a safepoint, so didn't take the > > CodeCache_lock. Moved the removal to nmethod->flush().? The bug > is confidential because there's a confidential comment > > not marked confidential but we'll open it up once that's fixed. > > > > Passed redefinition tests in repository with "VM_OPTIONS=-Xcomp > -XX:TieredStopAtLevel=1", including the PCL tests that > > in the oracle closed repo. > > > > Also ran hs-tier1-3. > > > > open webrev at > http://cr.openjdk.java.net/~coleenp/2019/8223585.01/webrev > > bug link https://bugs.openjdk.java.net/browse/JDK-8223585 > > > > Thanks, > > Coleen > > > > -- > > Thanks, > Jc From coleen.phillimore at oracle.com Wed May 15 18:51:41 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 May 2019 14:51:41 -0400 Subject: RFR (S) 8223585: vmTestbase/runtime/pcl/* get SEGV in MetadataOnStackClosure::do_metadata(Metadata*)+0x0 In-Reply-To: <3062a50e-9da4-9272-247a-6467d70fd841@oracle.com> References: <6703941c-87cb-fa0b-59fa-400baae99148@oracle.com> <3062a50e-9da4-9272-247a-6467d70fd841@oracle.com> Message-ID: <191f9a4d-2503-ecae-fab9-50b1515cdf74@oracle.com> Thanks Vladimir! Coleen On 5/15/19 12:34 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 5/15/19 6:46 AM, coleen.phillimore at oracle.com wrote: >> Summary: adjust old method table by only one thread. >> >> Entries were removed from the redefinition old method table by G1 by >> multiple threads at a safepoint, so didn't take the CodeCache_lock. >> Moved the removal to nmethod->flush().? The bug is confidential >> because there's a confidential comment not marked confidential but >> we'll open it up once that's fixed. >> >> Passed redefinition tests in repository with "VM_OPTIONS=-Xcomp >> -XX:TieredStopAtLevel=1", including the PCL tests that in the oracle >> closed repo. >> >> Also ran hs-tier1-3. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8223585.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8223585 >> >> Thanks, >> Coleen From hohensee at amazon.com Wed May 15 20:42:51 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 15 May 2019 20:42:51 +0000 Subject: [PING] [8u] RFR: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization In-Reply-To: <34336f93b6c53942ccf522de449c550bae30d546.camel@redhat.com> References: <34336f93b6c53942ccf522de449c550bae30d546.camel@redhat.com> Message-ID: <2474115F-1A08-4C22-A267-0FA93FA29A09@amazon.com> Looks good. Paul ?On 5/9/19, 5:39 AM, "hotspot-dev on behalf of sgehwolf at redhat.com" wrote: Ping? On Fri, 2019-05-03 at 18:35 +0200, Severin Gehwolf wrote: > Hi, > > Could I please get reviews for this 8u backport of an optimization fix > pertaining to the hotspot copy of fdlibm? Historically, > sharedRuntimeTrans.cpp and sharedRuntimeTrig.cpp have been compiled > with optimization turned off on x86/x86_64. As JDK-8210416 will be > backported to JDK 8u fixing optimization for fdlibm itself, so should > be the hotspot copy in OpenJDK 8u. The build system for hotspot in JDK > 8u is very different, so the original fix for JDK 12 doesn't apply. > It's a complete rewrite. Please see this webrev which shows the > prerequisite patch. It adds the FDLIBM_CFLAGS logic: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/jdk8/02/ > > It also fixes a bug on ppc64{,le} where optimization is being turned on > in hotspot (-O3), but not providing the -ffp-contract=off flag (or > older equivalent). > > Before (on ppc64le): > /bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. -I/home/openjdk/jdk8u/hotspot/src/share/vm/prims -I/home/openjdk/jdk8u/hotspot/src/share/vm -I/home/openjdk/jdk8u/hotspot/src/share/vm/precompiled -I/home/openjdk/jdk8u/hotspot/src/cpu/ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os_cpu/linux_ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os/linux/vm -I/home/openjdk/jdk8u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.212-b04\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"openjdk\"" -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3 -g -D_LP64=1 -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8 -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -std=gnu++98 -c -MMD -MP -MF ../generated/dependencies/sharedRuntimeTrig.o.d -fpch-deps -o sharedRuntimeTrig.o /home/openjdk/jdk8u/hotspot/src/share/vm/runtime/sharedRuntimeTrig.cpp > After (on ppc64le; Note -ffp-contract=off flag): > /bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I. -I/home/openjdk/jdk8u/hotspot/src/share/vm/prims -I/home/openjdk/jdk8u/hotspot/src/share/vm -I/home/openjdk/jdk8u/hotspot/src/share/vm/precompiled -I/home/openjdk/jdk8u/hotspot/src/cpu/ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os_cpu/linux_ppc/vm -I/home/openjdk/jdk8u/hotspot/src/os/linux/vm -I/home/openjdk/jdk8u/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.212-b04\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"openjdk\"" -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64 -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3 -ffp-contract=off -D_LP64=1 -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8 -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -std=gnu++98 -c -MMD -MP -MF ../generated/dependencies/sharedRuntimeTrig.o.d -fpch-deps -o sharedRuntimeTrig.o /home/openjdk/jdk8u/hotspot/src/share/vm/runtime/sharedRuntimeTrig.cpp > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210425 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/jdk8/02/webrev > > Testing: Builds on x86_64 (server/Zero). Manual inspection of compile > log of sharedRuntimeTrans.cpp/sharedRuntimeTrig.cpp. Same for ppc64le. > Note that we've been using this patch downstream for a while now. We > haven't seen any issues so far. > > Thanks, > Severin From david.holmes at oracle.com Thu May 16 02:21:31 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 May 2019 12:21:31 +1000 Subject: [13] RFR(S): 8223885: hs_err and replay file may contain garbage when overwriting existing file In-Reply-To: <0ad69f12-6532-8010-2573-1f8e9c8aaa0b@oracle.com> References: <8df29a34-ffb2-25d4-1799-2487910ea772@oracle.com> <0ad69f12-6532-8010-2573-1f8e9c8aaa0b@oracle.com> Message-ID: <20f51d37-54e1-d7dd-69af-deb62b88c2f9@oracle.com> Hi Tobias, Thinking more on this problem I think we need to back out JDK-8221738 and redo it so that it only affects the error file. It was never discussed that it would also impact the replay file, and such a change was not part of the CSR. I will file a bug for that. But I'm also a bit perplexed about the current bug and how it arose. The issue is that we overwrote an existing replay file with a shorter version and so got garbage at the end. When that file was read back the garbage caused the problem. But how did we come to write a replay file that already existed? Was this not named in a process-unique way? Further, before the change by JDK-8221738 the fact the file existed meant we would have written it to a different location - in which case how would the code that ends up reading the file know to get it from the other location given it would have found the old file in the original location? Thanks, David ----- On 15/05/2019 8:15 pm, Tobias Hartmann wrote: > Thanks David! > > Best regards, > Tobias > > On 15.05.19 11:53, David Holmes wrote: >> Looks good! Thanks for recognising the problem. Always some unintended consequence to every fix :( >> >> Cheers, >> David >> >> On 15/05/2019 7:23 pm, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch: >>> https://bugs.openjdk.java.net/browse/JDK-8223885 >>> http://cr.openjdk.java.net/~thartmann/8223885/webrev.00/ >>> >>> With the fix for JDK-8221738 we now overwrite existing hs_err and replay files without truncating >>> the file. This may lead to garbage at the end of the file if the newly written data requires less >>> space. Similar to ciEnv::dump_replay_data() and ciEnv::dump_inline_data(), we should open the file >>> with O_TRUNC to ensure it's properly truncated to zero size. >>> >>> Thanks, >>> Tobias >>> From igor.ignatyev at oracle.com Thu May 16 02:37:57 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 15 May 2019 19:37:57 -0700 Subject: RFR(M/S) : 8222154 : upgrade gtest to 1.8.1 In-Reply-To: References: <0C5E424C-C68B-48E9-B47F-16A9270D21D2@oracle.com> Message-ID: <82F35B23-DA77-4470-8A0A-67AFEE6A3522@oracle.com> ping > On May 13, 2019, at 2:31 PM, Igor Ignatyev wrote: > > @all, can I get a couple LGTMs? > > > @Robin, I've created 8222414 to bring gmock, will send webrev out for review after this one is integrated. > > Thanks, > -- Igor > >> On Apr 10, 2019, at 11:10 AM, Igor Ignatyev > wrote: >> >> Hi Robin, >> >> that's a very good suggestion, I myself missed gmock functionality several times, so yes I agree we need to get it available as well. doing that, however, will be a bit more effort and disturbance that just upgrading gtest, and as I'm planning to backport this patch into 11u, I'd prefer to bring gmock by a separate RFE. >> >> -- Igor >> >>> On Apr 10, 2019, at 7:02 AM, Robin Westberg > wrote: >>> >>> Hi Igor, >>> >>>> On 10 Apr 2019, at 02:17, Igor Ignatyev > wrote: >>>> >>>> http://cr.openjdk.java.net/~iignatyev//8222154/webrev.00/index.html >>>>> 6852 lines changed: 5104 ins; 742 del; 1006 mod; >>>> >>>> Hi all, >>>> >>>> could you please review the patch which upgrades google test framework used by JDK from v1.7 to v1.8.1? >>>> >>>> as this might break builds on other platforms, I'd strongly encourage platform maintainers to check if their native compilers are happy w/ upgraded version of gtest. I'm planning to wait for a week so everyone has enough time to test that, please let me know if you need more time. >>>> >>>> for the sake of reviewers, I'm publishing the webrevs for small changes done on top of gtest v1.8.1. and as w/ gtest v1.7, we aren't bringing parts of gtest which aren't essential (make, docs, project files, etc). >>> >>> Just a question / suggestion, would it be possible to include the contents of the googlemock folder as well? Back in the days of gtest 1.7 it used to be a separate project, but as of 1.8 it is a part of gtest. I?d argue it's an essential part of gtest, I?m missing that functionality every time I write a test. :) >>> >>> Best regards, >>> Robin >>> >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8222154 >>>> testing: tier1 >>>> webrevs: >>>> - reverting 8196997[1]: http://cr.openjdk.java.net/~iignatyev//8222154/-8196997/webrev.00/index.html >>>>> 2 lines changed: 0 ins; 2 del; 0 mod; 1 >>>> >>>> - changes to make solaris studio happy: http://cr.openjdk.java.net/~iignatyev//8222154/ss/webrev.00/index.html >>>>> 6 lines changed: 4 ins; 0 del; 2 mod; >>>> >>>> - the whole webrev: http://cr.openjdk.java.net/~iignatyev//8222154/webrev.00/index.html >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8196997 >>>> >>>> Thanks, >>>> -- Igor >> > From jesper.wilhelmsson at oracle.com Thu May 16 03:04:06 2019 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 16 May 2019 05:04:06 +0200 Subject: RFR(M/S) : 8222154 : upgrade gtest to 1.8.1 In-Reply-To: <82F35B23-DA77-4470-8A0A-67AFEE6A3522@oracle.com> References: <0C5E424C-C68B-48E9-B47F-16A9270D21D2@oracle.com> <82F35B23-DA77-4470-8A0A-67AFEE6A3522@oracle.com> Message-ID: <8C611409-A4C1-49D6-88F0-33D986A3DB73@oracle.com> LGTM /Jesper > 16 maj 2019 kl. 04:37 skrev Igor Ignatyev : > > ping > >> On May 13, 2019, at 2:31 PM, Igor Ignatyev wrote: >> >> @all, can I get a couple LGTMs? >> >> >> @Robin, I've created 8222414 to bring gmock, will send webrev out for review after this one is integrated. >> >> Thanks, >> -- Igor >> >>> On Apr 10, 2019, at 11:10 AM, Igor Ignatyev > wrote: >>> >>> Hi Robin, >>> >>> that's a very good suggestion, I myself missed gmock functionality several times, so yes I agree we need to get it available as well. doing that, however, will be a bit more effort and disturbance that just upgrading gtest, and as I'm planning to backport this patch into 11u, I'd prefer to bring gmock by a separate RFE. >>> >>> -- Igor >>> >>>> On Apr 10, 2019, at 7:02 AM, Robin Westberg > wrote: >>>> >>>> Hi Igor, >>>> >>>>> On 10 Apr 2019, at 02:17, Igor Ignatyev > wrote: >>>>> >>>>> http://cr.openjdk.java.net/~iignatyev//8222154/webrev.00/index.html >>>>>> 6852 lines changed: 5104 ins; 742 del; 1006 mod; >>>>> >>>>> Hi all, >>>>> >>>>> could you please review the patch which upgrades google test framework used by JDK from v1.7 to v1.8.1? >>>>> >>>>> as this might break builds on other platforms, I'd strongly encourage platform maintainers to check if their native compilers are happy w/ upgraded version of gtest. I'm planning to wait for a week so everyone has enough time to test that, please let me know if you need more time. >>>>> >>>>> for the sake of reviewers, I'm publishing the webrevs for small changes done on top of gtest v1.8.1. and as w/ gtest v1.7, we aren't bringing parts of gtest which aren't essential (make, docs, project files, etc). >>>> >>>> Just a question / suggestion, would it be possible to include the contents of the googlemock folder as well? Back in the days of gtest 1.7 it used to be a separate project, but as of 1.8 it is a part of gtest. I?d argue it's an essential part of gtest, I?m missing that functionality every time I write a test. :) >>>> >>>> Best regards, >>>> Robin >>>> >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8222154 >>>>> testing: tier1 >>>>> webrevs: >>>>> - reverting 8196997[1]: http://cr.openjdk.java.net/~iignatyev//8222154/-8196997/webrev.00/index.html >>>>>> 2 lines changed: 0 ins; 2 del; 0 mod; 1 >>>>> >>>>> - changes to make solaris studio happy: http://cr.openjdk.java.net/~iignatyev//8222154/ss/webrev.00/index.html >>>>>> 6 lines changed: 4 ins; 0 del; 2 mod; >>>>> >>>>> - the whole webrev: http://cr.openjdk.java.net/~iignatyev//8222154/webrev.00/index.html >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8196997 >>>>> >>>>> Thanks, >>>>> -- Igor >>> >> > From serguei.spitsyn at oracle.com Thu May 16 03:49:58 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 May 2019 20:49:58 -0700 Subject: RFR (S) 8223585: vmTestbase/runtime/pcl/* get SEGV in MetadataOnStackClosure::do_metadata(Metadata*)+0x0 In-Reply-To: References: <6703941c-87cb-fa0b-59fa-400baae99148@oracle.com> <3062a50e-9da4-9272-247a-6467d70fd841@oracle.com> Message-ID: <32475696-92c5-2451-0025-f829ae04af84@oracle.com> Hi Coleen, Looks good to me. Thanks, Serguei On 5/15/19 10:04, Jean Christophe Beyler wrote: > Hi Coleen, > > Looks good to me (not an official reviewer), > Jc > > *From: *Vladimir Kozlov > *Date: *Wed, May 15, 2019 at 9:34 AM > *To: * , hotspot-dev developers, > serviceability-dev at openjdk.java.net > > Looks good. >> Thanks, >> Vladimir >> >> On 5/15/19 6:46 AM, coleen.phillimore at oracle.com wrote: >>> Summary: adjust old method table by only one thread. >>> >>> Entries were removed from the redefinition old method table by G1 by >> multiple threads at a safepoint, so didn't take the >>> CodeCache_lock. Moved the removal to nmethod->flush(). The bug is >> confidential because there's a confidential comment >>> not marked confidential but we'll open it up once that's fixed. >>> >>> Passed redefinition tests in repository with "VM_OPTIONS=-Xcomp >> -XX:TieredStopAtLevel=1", including the PCL tests that >>> in the oracle closed repo. >>> >>> Also ran hs-tier1-3. >>> >>> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8223585.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8223585 >>> >>> Thanks, >>> Coleen > From thomas.stuefe at gmail.com Thu May 16 05:22:16 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 16 May 2019 07:22:16 +0200 Subject: [13] RFR(S): 8223885: hs_err and replay file may contain garbage when overwriting existing file In-Reply-To: <20f51d37-54e1-d7dd-69af-deb62b88c2f9@oracle.com> References: <8df29a34-ffb2-25d4-1799-2487910ea772@oracle.com> <0ad69f12-6532-8010-2573-1f8e9c8aaa0b@oracle.com> <20f51d37-54e1-d7dd-69af-deb62b88c2f9@oracle.com> Message-ID: Again, sorry for that. I found that CDT (I use Eclipse CDT) call hierarchy was lying to me and did not show the second call to prepate_log_file in VMError::report_and_die(), so I missed the fact that this affects compiler replay files. I am upset by this, since CDT is my main work tool nowadays. Also confusing is that the submit tests went thru fine. So I guess the replay compiler test is not part of the submit test suite. I will redo this fix. ..Thomas On Thu, May 16, 2019 at 4:21 AM David Holmes wrote: > Hi Tobias, > > Thinking more on this problem I think we need to back out JDK-8221738 > and redo it so that it only affects the error file. It was never > discussed that it would also impact the replay file, and such a change > was not part of the CSR. I will file a bug for that. > > But I'm also a bit perplexed about the current bug and how it arose. The > issue is that we overwrote an existing replay file with a shorter > version and so got garbage at the end. When that file was read back the > garbage caused the problem. But how did we come to write a replay file > that already existed? Was this not named in a process-unique way? > Further, before the change by JDK-8221738 the fact the file existed > meant we would have written it to a different location - in which case > how would the code that ends up reading the file know to get it from the > other location given it would have found the old file in the original > location? > > Thanks, > David > ----- > > On 15/05/2019 8:15 pm, Tobias Hartmann wrote: > > Thanks David! > > > > Best regards, > > Tobias > > > > On 15.05.19 11:53, David Holmes wrote: > >> Looks good! Thanks for recognising the problem. Always some unintended > consequence to every fix :( > >> > >> Cheers, > >> David > >> > >> On 15/05/2019 7:23 pm, Tobias Hartmann wrote: > >>> Hi, > >>> > >>> please review the following patch: > >>> https://bugs.openjdk.java.net/browse/JDK-8223885 > >>> http://cr.openjdk.java.net/~thartmann/8223885/webrev.00/ > >>> > >>> With the fix for JDK-8221738 we now overwrite existing hs_err and > replay files without truncating > >>> the file. This may lead to garbage at the end of the file if the newly > written data requires less > >>> space. Similar to ciEnv::dump_replay_data() and > ciEnv::dump_inline_data(), we should open the file > >>> with O_TRUNC to ensure it's properly truncated to zero size. > >>> > >>> Thanks, > >>> Tobias > >>> > From andrewluotechnologies at outlook.com Thu May 16 05:29:22 2019 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Thu, 16 May 2019 05:29:22 +0000 Subject: [PATCH] Fix some assignments of string literals to non-const char* In-Reply-To: References: <7af793d6-b6b7-55e3-0301-1a61acb509ed@oracle.com> <79bcd948-b100-0c13-63c8-4f56c67c940f@oracle.com> Message-ID: Awesome, thanks for your reviews and help getting this in. -----Original Message----- From: David Holmes Sent: Tuesday, May 14, 2019 5:42 PM To: Andrew Luo Cc: hotspot-dev developers Subject: Re: [PATCH] Fix some assignments of string literals to non-const char* Pushed: Changeset: f67269c129f9 Author: dholmes Date: 2019-05-14 20:29 -0400 URL: http://hg.openjdk.java.net/jdk/jdk/rev/f67269c129f9 8223810: HotSpot compile warnings from VS2017 Reviewed-by: dholmes, stuefe Contributed-by: Andrew Luo ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/services/attachListener.hpp ! test/hotspot/gtest/gtestMain.cpp David On 14/05/2019 5:49 pm, David Holmes wrote: > Thanks Thomas. My testing passed so I'll push this in the morning. > > David > ----- > > On 14/05/2019 5:12 pm, Thomas St?fe wrote: >> This looks fine. >> >> Cheers, Thomas >> >> On Tue, May 14, 2019 at 6:45 AM David Holmes > > wrote: >> >> ??? Hi Andrew, >> >> ??? Thanks for the report and patch. We just had something very >> similar go >> ??? through for gcc 9 on non-Windows. :) Interesting gcc didn't >> complain >> ??? about the code in attachListener.hpp. >> >> ??? I've filed: >> >> ??? https://bugs.openjdk.java.net/browse/JDK-8223810 >> >> ??? and I will sponsor this for you. I've posted a webrev here: >> >> ??? http://cr.openjdk.java.net/~dholmes/8223810/webrev/ >> >> ??? and am running the patch through our build. >> >> ??? Thanks, >> ??? David >> >> ??? On 14/05/2019 10:21 am, Andrew Luo wrote: >> ???? > I've been trying to get the JDK to compile with the new >> ??? /permissive- switch in VS2017 >> ??? (https://devblogs.microsoft.com/cppblog/permissive-switch/) >> however >> ??? there have been a few issues in various parts of the code.? There >> ??? are a few issues in the hotspot code where we attempt to assign >> ??? string literals to char* (non-const) variables (unnecessarily).? >> I >> ??? took some time to fix some of these and attached a patch.? Let me >> ??? know if you have any comments/feedback. >> ???? > >> ???? > >> >> c:/Users/Andrew/Documents/mercurial/openjdk/jdk/test/hotspot/gtest/gtestMain.cpp(234): >> >> ??? error C2440: 'initializing': cannot convert from 'const char [19]' >> ??? to 'char *' >> ???? > >> >> c:/Users/Andrew/Documents/mercurial/openjdk/jdk/test/hotspot/gtest/gtestMain.cpp(234): >> >> ??? note: Conversion from string literal loses const qualifier (see >> ??? /Zc:strictStrings) >> ???? > >> >> c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/attachListener_windows.cpp(152): >> >> ??? error C2664: 'AttachOperation::AttachOperation(AttachOperation &&)': >> ??? cannot convert argument 1 from 'const char [9]' to 'char *' >> ???? > >> >> c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/attachListener_windows.cpp(152): >> >> ??? note: Conversion from string literal loses const qualifier (see >> ??? /Zc:strictStrings) >> ???? > >> >> c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/os_windows.cpp(204): >> >> ??? error C2440: 'initializing': cannot convert from 'const char [5]' >> to >> ??? 'char *' >> ???? > >> >> c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/os_windows.cpp(204): >> >> ??? note: Conversion from string literal loses const qualifier (see >> ??? /Zc:strictStrings) >> ???? > >> >> c:/Users/Andrew/Documents/mercurial/openjdk/jdk/src/hotspot/os/windows/os_windows.cpp(2214): >> >> ??? error C2440: 'initializing': ... >> ???? > >> ???? > Thanks, >> ???? > >> ???? > -Andrew >> ???? > >> From david.holmes at oracle.com Thu May 16 05:43:42 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 May 2019 15:43:42 +1000 Subject: [13] RFR: 8213416: Replace some enums with static const members in hotspot/compiler In-Reply-To: <1f7afc19-0756-33f8-54f5-2438ed5da886@oracle.com> References: <1f7afc19-0756-33f8-54f5-2438ed5da886@oracle.com> Message-ID: <55bac532-4df7-d3a3-6b87-90f21e228aab@oracle.com> This all seems like unnecessary churn to me - is any of this code actually wrong? can we not just disable this particular warning? is there any point using "static const" when we should be aiming to use C++11 constexpr in the (not too distant?) future? Converting from enums to unrelated ints seems a big step backwards in software engineering terms. :( Cheers, David ----- On 16/05/2019 12:46 am, Rahul Raghavan wrote: > Hi, > > Request help review and finalize fix for 8213416. > > - http://cr.openjdk.java.net/~rraghavan/8213416/webrev.00/ > > https://bugs.openjdk.java.net/browse/JDK-8213416 > > The requirement is to solve > ? "enumeral and non-enumeral type in conditional expression" warnings > ? triggered with -Wextra enabled for gcc on hotspot. > > (hotspot/compiler part is handled in this 8213416 task > and hotspot/runtime in 8223400) > > The same warning is generated for ternary operator statements like- > ? (x ? int_val : enum_val). > e.g.: > comp_level = TieredCompilation ? TieredStopAtLevel : > CompLevel_highest_tier; > > > Understood from comments that the following type typecast solution > proposed earlier was not accepted. > - comp_level = TieredCompilation ? TieredStopAtLevel : > CompLevel_highest_tier; > + comp_level = TieredCompilation ? TieredStopAtLevel : (int) > CompLevel_highest_tier; > and then proposed solution was to rewrite those enums to be static const > members. > > > Tried changes based on the comments info from JBS. > Extracts of related JBS comments- > - ".... it's just a simple code refactoring. " > - "David H. only complained about NO_HASH which we can fix. > We can also fix CompLevel_highest_tier usage - should use CompLevel type > everywhere. > But I would not touch Op_RegFlags - > ? I don't want to complicate its construction and > ? we have a lot of places where Op_ are used as uint. > ? I would only fix places where it is used as int to make sure it is > used as uint everywhere." > > > > Reported enums in question for hotspot/compiler > 1) NO_HASH > 2) CompLevel_highest_tier > 3) Op_RegFlags > 4) _lh_array_tag_obj_value, _lh_instance_slow_path_bit > > > > 1) NO_HASH > tried [open/src/hotspot/share/opto/node.hpp] > -? enum { NO_HASH = 0 }; > +? static const uint NO_HASH = 0; > > > > 2) CompLevel_highest_tier > Only one warning in process_compile() > [open/src/hotspot/share/ci/ciReplay.cpp] > comp_level = TieredCompilation ? TieredStopAtLevel : > CompLevel_highest_tier; > > Following type changes tried did not help - > -??? int comp_level = parse_int(comp_level_label); > +??? CompLevel comp_level = parse_int(comp_level_label); > ..... > -????? comp_level = TieredCompilation ? TieredStopAtLevel : > CompLevel_highest_tier; > +????? comp_level = TieredCompilation ? (CompLevel) TieredStopAtLevel : > CompLevel_highest_tier; > > > The warning is with only ternary operator usage in this location. > So tried simple code refactoring like following and got no more warnings! > Is this okay? > -????? comp_level = TieredCompilation ? TieredStopAtLevel : > CompLevel_highest_tier; > +????? if (TieredCompilation) { > +??????? comp_level = TieredStopAtLevel; > +????? } else { > +??????? comp_level = CompLevel_highest_tier; > +????? } > > > > 3) Op_RegFlags > Warnings only for 'virtual uint MachNode::ideal_reg() const' > > ../open/src/hotspot/share/opto/machnode.hpp: In member function 'virtual > uint MachNode::ideal_reg() const': > ../open/src/hotspot/share/opto/machnode.hpp:304:95: warning: enumeral > and non-enumeral type in conditional expression [-Wextra] > ?? virtual uint ideal_reg() const { const Type *t = _opnds[0]->type(); > return t == TypeInt::CC ? Op_RegFlags : t->ideal_reg(); } > > ????? ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Op_RegFlags is returned as uint itself here. > How to modify code to solve warning? > Again since the issue is with only ternary operator usage in only one > location, can we go for simple code refactoring like following? > > -? virtual uint ideal_reg() const { const Type *t = _opnds[0]->type(); > return t == TypeInt::CC ? Op_RegFlags : t->ideal_reg(); } > +? virtual uint ideal_reg() const { > +??? const Type *t = _opnds[0]->type(); > +??? if (t == TypeInt::CC) { > +????? return Op_RegFlags; > +??? } else { > +????? return t->ideal_reg(); > +??? } > +? } > > > > 4) _lh_array_tag_obj_value, _lh_instance_slow_path_bit - > warnings locations - > > (i) ../open/src/hotspot/share/oops/klass.cpp: In static member function > 'static jint Klass::array_layout_helper(BasicType)': > ../open/src/hotspot/share/oops/klass.cpp:212:23: warning: enumeral and > non-enumeral type in conditional expression [-Wextra] > ?? int? tag?? =? isobj ? _lh_array_tag_obj_value : > _lh_array_tag_type_value; > > (ii) ../open/src/hotspot/cpu/x86/c1_Runtime1_x86.cpp: In static member > function 'static OopMapSet* > Runtime1::generate_code_for(Runtime1::StubID, StubAssembler*)': > ../open/src/hotspot/cpu/x86/c1_Runtime1_x86.cpp:1126:22: warning: > enumeral and non-enumeral type in conditional expression [-Wextra] > ?????????? int tag = ((id == new_type_array_id) > ????????????????????? ~~~~~~~~~~~~~~~~~~~~~~~~~ > ????????????????????? ? Klass::_lh_array_tag_type_value > ????????????????????? ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ????????????????????? : Klass::_lh_array_tag_obj_value); > > (iii) ../open/src/hotspot/share/oops/klass.hpp: In static member > function 'static jint Klass::instance_layout_helper(jint, bool)': > ../open/src/hotspot/share/oops/klass.hpp:422:28: warning: enumeral and > non-enumeral type in conditional expression [-Wextra] > ?????? |??? (slow_path_flag ? _lh_instance_slow_path_bit : 0); > ???????????? ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Following changes fixed the warnings! > (using static const int instead of unnamed enum) > [open/src/hotspot/share/oops/klass.cpp] > .......... > ?? // Unpacking layout_helper: > -? enum { > -??? _lh_neutral_value?????????? = 0,? // neutral non-array non-instance > value > -??? _lh_instance_slow_path_bit? = 0x01, > -??? _lh_log2_element_size_shift = BitsPerByte*0, > -??? _lh_log2_element_size_mask? = BitsPerLong-1, > -??? _lh_element_type_shift????? = BitsPerByte*1, > -??? _lh_element_type_mask?????? = right_n_bits(BitsPerByte),? // > shifted mask > -??? _lh_header_size_shift?????? = BitsPerByte*2, > -??? _lh_header_size_mask??????? = right_n_bits(BitsPerByte),? // > shifted mask > -??? _lh_array_tag_bits????????? = 2, > -??? _lh_array_tag_shift???????? = BitsPerInt - _lh_array_tag_bits, > -??? _lh_array_tag_obj_value???? = ~0x01?? // 0x80000000 >> 30 > -? }; > +? static const int _lh_neutral_value?????????? = 0;? // neutral > non-array non-instance value > +? static const int _lh_instance_slow_path_bit? = 0x01; > +? static const int _lh_log2_element_size_shift = BitsPerByte*0; > +? static const int _lh_log2_element_size_mask? = BitsPerLong-1; > +? static const int _lh_element_type_shift????? = BitsPerByte*1; > +? static const int _lh_element_type_mask?????? = > right_n_bits(BitsPerByte);? // shifted mask > +? static const int _lh_header_size_shift?????? = BitsPerByte*2; > +? static const int _lh_header_size_mask??????? = > right_n_bits(BitsPerByte);? // shifted mask > +? static const int _lh_array_tag_bits????????? = 2; > +? static const int _lh_array_tag_shift???????? = BitsPerInt - > _lh_array_tag_bits; > +? static const int _lh_array_tag_obj_value???? = ~0x01;?? // 0x80000000 > >> 30 > ....... > > > > - http://cr.openjdk.java.net/~rraghavan/8213416/webrev.00/ > > Understood the affected code locations details from the old sample patch > attachment of related JDK-8211073 > # > https://bugs.openjdk.java.net/secure/attachment/79387/hotspot-disable-wextra.diff > > Also confirmed no similar warnings in hotspot/compiler with -Wextra, > no issues with build with this proposed webrev.00 > > > Thanks, > Rahul From rahul.v.raghavan at oracle.com Thu May 16 06:33:04 2019 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Thu, 16 May 2019 12:03:04 +0530 Subject: [13] RFR: 8213416: Replace some enums with static const members in hotspot/compiler In-Reply-To: <8f18e15d-cae8-58eb-b4a1-870ca6ffaf15@oracle.com> References: <1f7afc19-0756-33f8-54f5-2438ed5da886@oracle.com> <8f18e15d-cae8-58eb-b4a1-870ca6ffaf15@oracle.com> Message-ID: <62869e18-3deb-435d-1ce8-7726866d79eb@oracle.com> Hi, Thank you Vladimir for review comments. >> 4) _lh_array_tag_obj_value, _lh_instance_slow_path_bit - >> [open/src/hotspot/share/oops/klass.cpp] >> .......... > > I am okay with it but Runtime group should agree too - it is their code. > Yes, I missed that it is Runtime code. Please note plan is to handle only the hotspot/compiler part of the requirement changes in JDK-8213416. As per earlier JBS comments new JDK-8223400 was created to cover the requirements in hotspot/runtime. So may I suggest moving the above runtime change requirement details to JDK-822340; and use only the balance changes, as in below updated webrev, here for 8213416. - http://cr.openjdk.java.net/~rraghavan/8213416/webrev.01/ Thanks, Rahul From tobias.hartmann at oracle.com Thu May 16 06:54:01 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 16 May 2019 08:54:01 +0200 Subject: [13] RFR(S): 8223885: hs_err and replay file may contain garbage when overwriting existing file In-Reply-To: <20f51d37-54e1-d7dd-69af-deb62b88c2f9@oracle.com> References: <8df29a34-ffb2-25d4-1799-2487910ea772@oracle.com> <0ad69f12-6532-8010-2573-1f8e9c8aaa0b@oracle.com> <20f51d37-54e1-d7dd-69af-deb62b88c2f9@oracle.com> Message-ID: Hi David, On 16.05.19 04:21, David Holmes wrote: > Thinking more on this problem I think we need to back out JDK-8221738 and redo it so that it only > affects the error file. It was never discussed that it would also impact the replay file, and such a > change was not part of the CSR. I will file a bug for that. Okay, that's reasonable. > But I'm also a bit perplexed about the current bug and how it arose. The issue is that we overwrote > an existing replay file with a shorter version and so got garbage at the end. When that file was > read back the garbage caused the problem. But how did we come to write a replay file that already > existed? Was this not named in a process-unique way? No, the test triggers multiple JVM crashes and sets the same replay file name for all of them via the -XX:ReplayDataFile command line option: http://hg.openjdk.java.net/jdk/jdk/file/eedc3db527ac/test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java#l48 Although the file is deleted after each run/crash, the operating system might not yet have removed it from the disk (even when enabling the waitForCondition() on all platforms): http://hg.openjdk.java.net/jdk/jdk/file/eedc3db527ac/test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java#l115 As a result, we overwrite parts of the file when the next VM instance crashes (calling Thread.sleep fixes the issue). > Further, before the change by JDK-8221738 the > fact the file existed meant we would have written it to a different location - in which case how > would the code that ends up reading the file know to get it from the other location given it would > have found the old file in the original location? Yes, that worked by accident. In this case, the test was just happily reading the old file. So if we go back to not overwriting existing replay files, we need to fix the test. There are other known problems with these replay tests (see JDK-8029528). Best regards, Tobias From tobias.hartmann at oracle.com Thu May 16 06:54:05 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 16 May 2019 08:54:05 +0200 Subject: [13] RFR(S): 8223885: hs_err and replay file may contain garbage when overwriting existing file In-Reply-To: References: <8df29a34-ffb2-25d4-1799-2487910ea772@oracle.com> <0ad69f12-6532-8010-2573-1f8e9c8aaa0b@oracle.com> <20f51d37-54e1-d7dd-69af-deb62b88c2f9@oracle.com> Message-ID: Hi Thomas, On 16.05.19 07:22, Thomas St?fe wrote: > Again, sorry for that. > > I found that CDT (I use Eclipse CDT) call hierarchy was lying to me and did not show the second call > to prepate_log_file in VMError::report_and_die(), so I missed the fact that this affects compiler > replay files. I am upset by this, since CDT is my main work tool nowadays. I've recently switched from Eclipse to CLion which seems to be much better at code analysis and also shows both usages in the call hierarchy. > Also confusing is that the submit tests went thru fine. So I guess the replay compiler test is not > part of the submit test suite. Yes, unfortunately it's not executed at tier1. Best regards, Tobias From david.holmes at oracle.com Thu May 16 07:19:51 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 May 2019 17:19:51 +1000 Subject: RFR (S) 8220656 : ARM32: -XX:MaxVectorSize=16 makes SIGILL In-Reply-To: <7f22f026-d238-c880-7d6d-5b0e3382b2fb@bell-sw.com> References: <2b472d5c-e7ee-3fae-9b80-a0562a5e97ff@oracle.com> <213d552c-8b84-c269-463d-f354d65a48bd@oracle.com> <923ae7d2-5de0-b65b-250d-2fa3d493d649@oracle.com> <7f22f026-d238-c880-7d6d-5b0e3382b2fb@bell-sw.com> Message-ID: Hi Boris, On 15/05/2019 11:13 pm, Boris Ulasevich wrote: > Hi David, > > On 15.05.2019 15:39, David Holmes wrote: >> Hi Boris, >> >> On 15/05/2019 9:02 pm, Boris Ulasevich wrote: >>> Hi David, >>> >>> Thanks for review! I added a warning and fixed the drop back value: >>> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.02 >> >> With that change this code is pointless: >> >> ??274?? if (FLAG_IS_DEFAULT(MaxVectorSize)) { >> ??275???? // FLAG_SET_DEFAULT(MaxVectorSize, has_simd() ? 16 : 8); >> ??276???? // SIMD/NEON can use 16, but default is 8 because currently >> ??277???? // larger than 8 will disable instruction scheduling >> ??278???? FLAG_SET_DEFAULT(MaxVectorSize, 8); >> ??279?? } >> >> as it will be handled by your new code. > > This code sets MaxVectorSize=8 when no -XX:MaxVectorSize option is > specified while the new code sets 8/16 when the specified size is too > big. I think these two blocks of code live together quite well :) The default value is also too big (64) so your code would handle this case anyway. But as Dean notes the warning should only be issued when the user explicitly sets the value. So I think your change is better applied as an else clause to the existing code: if (FLAG_IS_DEFAULT(MaxVectorSize)) { // FLAG_SET_DEFAULT(MaxVectorSize, has_simd() ? 16 : 8); // SIMD/NEON can use 16, but default is 8 because currently // larger than 8 will disable instruction scheduling FLAG_SET_DEFAULT(MaxVectorSize, 8); ! } else { + int max_vector_size = has_simd() ? 16 : 8; + if (MaxVectorSize > max_vector_size) { + warning("MaxVectorSize must be at most %i on this platform", max_vector_size); + FLAG_SET_DEFAULT(MaxVectorSize, max_vector_size); + } + } Thanks, David >> Thanks, >> David >> >>> regards, >>> Boris >>> >>> On 15.05.2019 4:16, David Holmes wrote: >>>> On 15/05/2019 6:48 am, dean.long at oracle.com wrote: >>>>> Looks fine, but you might want to print a warning if you override >>>>> the user's choice. >>>> >>>> I would normally agree, but in this case the following code will >>>> already silently overwrite the user's choice in some cases: >>>> >>>> ??281?? if (MaxVectorSize > 16) { >>>> ??282???? FLAG_SET_DEFAULT(MaxVectorSize, 8); >>>> ??283?? } >>>> >>>> and I find it odd that it drops it back to 8 rather than taking the >>>> upper-limit of 16. >>>> >>>> To me the first problem here is that MaxVectorSize should be a >>>> pd_global so each platform can just set the right default to begin >>>> with, and set a correct allowed range for that platform. In fact >>>> with a constraint function it could even incorporate the has_simd() >>>> check. But that's getting a bit beyond the current fix. >>>> >>>> I can't see any non-convoluted way to print a warning under all the >>>> right circumstances, so I'll leave it to Boris to decide what to do >>>> here. I don't think a warning is essential. >>>> >>>> Cheers, >>>> David >>>> >>>>> dl >>>>> >>>>> On 5/14/19 8:39 AM, Boris Ulasevich wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review a simple change to prevent VLD1/VST1 instructions >>>>>> generation on ARM32 processor without SIMD support. The change >>>>>> overrides MaxVectorSize option set up by user to a value >>>>>> acceptable by the hardware. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8220656 >>>>>> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.01/ >>>>>> >>>>>> thanks, >>>>>> Boris >>>>> From robin.westberg at oracle.com Thu May 16 07:39:32 2019 From: robin.westberg at oracle.com (Robin Westberg) Date: Thu, 16 May 2019 09:39:32 +0200 Subject: RFR(M/S) : 8222154 : upgrade gtest to 1.8.1 In-Reply-To: References: <0C5E424C-C68B-48E9-B47F-16A9270D21D2@oracle.com> Message-ID: <1FF7DC5F-DD5A-407C-AB52-66741D596931@oracle.com> Hi Igor, > On 13 May 2019, at 23:31, Igor Ignatyev wrote: > > @all, can I get a couple LGTMs? Looks fine to me! > @Robin, I've created 8222414 to bring gmock, will send webrev out for review after this one is integrated. Great, thanks! Best regards, Robin (not a Reviewer) > > Thanks, > -- Igor > >> On Apr 10, 2019, at 11:10 AM, Igor Ignatyev > wrote: >> >> Hi Robin, >> >> that's a very good suggestion, I myself missed gmock functionality several times, so yes I agree we need to get it available as well. doing that, however, will be a bit more effort and disturbance that just upgrading gtest, and as I'm planning to backport this patch into 11u, I'd prefer to bring gmock by a separate RFE. >> >> -- Igor >> >>> On Apr 10, 2019, at 7:02 AM, Robin Westberg > wrote: >>> >>> Hi Igor, >>> >>>> On 10 Apr 2019, at 02:17, Igor Ignatyev > wrote: >>>> >>>> http://cr.openjdk.java.net/~iignatyev//8222154/webrev.00/index.html >>>>> 6852 lines changed: 5104 ins; 742 del; 1006 mod; >>>> >>>> Hi all, >>>> >>>> could you please review the patch which upgrades google test framework used by JDK from v1.7 to v1.8.1? >>>> >>>> as this might break builds on other platforms, I'd strongly encourage platform maintainers to check if their native compilers are happy w/ upgraded version of gtest. I'm planning to wait for a week so everyone has enough time to test that, please let me know if you need more time. >>>> >>>> for the sake of reviewers, I'm publishing the webrevs for small changes done on top of gtest v1.8.1. and as w/ gtest v1.7, we aren't bringing parts of gtest which aren't essential (make, docs, project files, etc). >>> >>> Just a question / suggestion, would it be possible to include the contents of the googlemock folder as well? Back in the days of gtest 1.7 it used to be a separate project, but as of 1.8 it is a part of gtest. I?d argue it's an essential part of gtest, I?m missing that functionality every time I write a test. :) >>> >>> Best regards, >>> Robin >>> >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8222154 >>>> testing: tier1 >>>> webrevs: >>>> - reverting 8196997[1]: http://cr.openjdk.java.net/~iignatyev//8222154/-8196997/webrev.00/index.html >>>>> 2 lines changed: 0 ins; 2 del; 0 mod; 1 >>>> >>>> - changes to make solaris studio happy: http://cr.openjdk.java.net/~iignatyev//8222154/ss/webrev.00/index.html >>>>> 6 lines changed: 4 ins; 0 del; 2 mod; >>>> >>>> - the whole webrev: http://cr.openjdk.java.net/~iignatyev//8222154/webrev.00/index.html >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8196997 >>>> >>>> Thanks, >>>> -- Igor >> > From thomas.stuefe at gmail.com Thu May 16 08:18:53 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 16 May 2019 10:18:53 +0200 Subject: [13] RFR(S): 8223885: hs_err and replay file may contain garbage when overwriting existing file In-Reply-To: References: <8df29a34-ffb2-25d4-1799-2487910ea772@oracle.com> <0ad69f12-6532-8010-2573-1f8e9c8aaa0b@oracle.com> <20f51d37-54e1-d7dd-69af-deb62b88c2f9@oracle.com> Message-ID: On Thu, May 16, 2019 at 8:54 AM Tobias Hartmann wrote: > Hi Thomas, > > On 16.05.19 07:22, Thomas St?fe wrote: > > Again, sorry for that. > > > > I found that CDT (I use Eclipse CDT) call hierarchy was lying to me and > did not show the second call > > to prepate_log_file in VMError::report_and_die(), so I missed the fact > that this affects compiler > > replay files. I am upset by this, since CDT is my main work tool > nowadays. > > I've recently switched from Eclipse to CLion which seems to be much better > at code analysis and also > shows both usages in the call hierarchy. > A colleague just showed me that tree nodes of the call tree pointing inside the same function are merged. Now I am relieved a bit. The problem was in front of the screen :) Yes, I hear good things about CLion. How is speed for you? Last time I tested opening a call hierarchy took a lot of time, with the frames basically trickling in. In CDT call hierarchy is instantaneous. > > > Also confusing is that the submit tests went thru fine. So I guess the > replay compiler test is not > > part of the submit test suite. > > Yes, unfortunately it's not executed at tier1. > > Best regards, > Tobias > Cheers, Thomas From boris.ulasevich at bell-sw.com Thu May 16 08:37:46 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Thu, 16 May 2019 11:37:46 +0300 Subject: RFR (S) 8220656 : ARM32: -XX:MaxVectorSize=16 makes SIGILL In-Reply-To: References: <2b472d5c-e7ee-3fae-9b80-a0562a5e97ff@oracle.com> <213d552c-8b84-c269-463d-f354d65a48bd@oracle.com> <923ae7d2-5de0-b65b-250d-2fa3d493d649@oracle.com> <7f22f026-d238-c880-7d6d-5b0e3382b2fb@bell-sw.com> Message-ID: <0012993b-f786-5e74-fffb-bbf1ce554338@bell-sw.com> > The default value is also too big (64) so your code would handle this > case anyway. On 16.05.2019 10:19, David Holmes wrote: > Hi Boris, > > On 15/05/2019 11:13 pm, Boris Ulasevich wrote: >> Hi David, >> >> On 15.05.2019 15:39, David Holmes wrote: >>> Hi Boris, >>> >>> On 15/05/2019 9:02 pm, Boris Ulasevich wrote: >>>> Hi David, >>>> >>>> Thanks for review! I added a warning and fixed the drop back value: >>>> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.02 >>> >>> With that change this code is pointless: >>> >>> ??274?? if (FLAG_IS_DEFAULT(MaxVectorSize)) { >>> ??275???? // FLAG_SET_DEFAULT(MaxVectorSize, has_simd() ? 16 : 8); >>> ??276???? // SIMD/NEON can use 16, but default is 8 because currently >>> ??277???? // larger than 8 will disable instruction scheduling >>> ??278???? FLAG_SET_DEFAULT(MaxVectorSize, 8); >>> ??279?? } >>> >>> as it will be handled by your new code. >> >> This code sets MaxVectorSize=8 when no -XX:MaxVectorSize option is >> specified while the new code sets 8/16 when the specified size is too >> big. I think these two blocks of code live together quite well :) > > The default value is also too big (64) so your code would handle this > case anyway. But as Dean notes the warning should only be issued when > the user explicitly sets the value. I see. I like your proposal. It is just more reasonable code. Thanks to you and Dean! http://cr.openjdk.java.net/~bulasevich/8220656/webrev.03 > So I think your change is better > applied as an else clause to the existing code: > > ?if (FLAG_IS_DEFAULT(MaxVectorSize)) { > ?? // FLAG_SET_DEFAULT(MaxVectorSize, has_simd() ? 16 : 8); > ?? // SIMD/NEON can use 16, but default is 8 because currently > ?? // larger than 8 will disable instruction scheduling > ?? FLAG_SET_DEFAULT(MaxVectorSize, 8); > ! } else { > +?? int max_vector_size = has_simd() ? 16 : 8; > +?? if (MaxVectorSize > max_vector_size) { > +???? warning("MaxVectorSize must be at most %i on this platform", > max_vector_size); > +???? FLAG_SET_DEFAULT(MaxVectorSize, max_vector_size); > +?? } > + } > > Thanks, > David > > >>> Thanks, >>> David >>> >>>> regards, >>>> Boris >>>> >>>> On 15.05.2019 4:16, David Holmes wrote: >>>>> On 15/05/2019 6:48 am, dean.long at oracle.com wrote: >>>>>> Looks fine, but you might want to print a warning if you override >>>>>> the user's choice. >>>>> >>>>> I would normally agree, but in this case the following code will >>>>> already silently overwrite the user's choice in some cases: >>>>> >>>>> ??281?? if (MaxVectorSize > 16) { >>>>> ??282???? FLAG_SET_DEFAULT(MaxVectorSize, 8); >>>>> ??283?? } >>>>> >>>>> and I find it odd that it drops it back to 8 rather than taking the >>>>> upper-limit of 16. >>>>> >>>>> To me the first problem here is that MaxVectorSize should be a >>>>> pd_global so each platform can just set the right default to begin >>>>> with, and set a correct allowed range for that platform. In fact >>>>> with a constraint function it could even incorporate the has_simd() >>>>> check. But that's getting a bit beyond the current fix. >>>>> >>>>> I can't see any non-convoluted way to print a warning under all the >>>>> right circumstances, so I'll leave it to Boris to decide what to do >>>>> here. I don't think a warning is essential. >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> dl >>>>>> >>>>>> On 5/14/19 8:39 AM, Boris Ulasevich wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review a simple change to prevent VLD1/VST1 instructions >>>>>>> generation on ARM32 processor without SIMD support. The change >>>>>>> overrides MaxVectorSize option set up by user to a value >>>>>>> acceptable by the hardware. >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8220656 >>>>>>> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.01/ >>>>>>> >>>>>>> thanks, >>>>>>> Boris >>>>>> From david.holmes at oracle.com Thu May 16 09:00:11 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 May 2019 19:00:11 +1000 Subject: RFR: 8222825: ARM32 SIGILL issue on single core CPU (not supported PLDW instruction) In-Reply-To: References: <1695e37a-e9bd-364a-68ef-e357d9b8a939@bell-sw.com> <71276d27-7183-fb8f-c58c-ddff4a528b25@oracle.com> <105f00fe-b9f6-58ce-00e2-345f4cfd9d8f@bell-sw.com> Message-ID: <38fc2c86-5e7c-550c-fa45-91720dab39b0@oracle.com> Hi Boris, Waiting to see if you have any response to Dean's suggestion before I push this for you. David On 14/05/2019 4:28 pm, dean.long at oracle.com wrote: > This looks good.? In arm.ad, you could use two rules and a predicate, so > that the PrintOptoAssembly output is correct. > > dl > > On 5/13/19 11:04 PM, Boris Ulasevich wrote: >> Hi David, >> >> ? It took a time to test the change :) >> ? Yes, please. Thank you! >> >> Boris >> >> 14.05.2019 8:00, David Holmes ?????: >>> Hi Boris, >>> >>> I was wondering what had happened to this one :) >>> >>> Looks good! I can sponsor for you. >>> >>> Thanks, >>> David >>> >>> On 14/05/2019 2:45 pm, Boris Ulasevich wrote: >>>> Hi all, >>>> >>>> Please review the fix for SIGILL that happens on ARM32 CPU without >>>> Multiprocessing Extensions support (this applies to single-core >>>> arm32 processors, which are not very common this days). With the fix >>>> we check PLDW instruction availability on JVM start-up to correct >>>> further instructions generation. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8222825 >>>> http://cr.openjdk.java.net/~bulasevich/8222825/webrev.03.jdk-jdk >>>> >>>> thanks, >>>> Boris >> >> > From david.holmes at oracle.com Thu May 16 09:27:45 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 May 2019 19:27:45 +1000 Subject: RFR (S) 8220656 : ARM32: -XX:MaxVectorSize=16 makes SIGILL In-Reply-To: <0012993b-f786-5e74-fffb-bbf1ce554338@bell-sw.com> References: <2b472d5c-e7ee-3fae-9b80-a0562a5e97ff@oracle.com> <213d552c-8b84-c269-463d-f354d65a48bd@oracle.com> <923ae7d2-5de0-b65b-250d-2fa3d493d649@oracle.com> <7f22f026-d238-c880-7d6d-5b0e3382b2fb@bell-sw.com> <0012993b-f786-5e74-fffb-bbf1ce554338@bell-sw.com> Message-ID: <654e8704-877f-b282-1edd-26ddf1a77a2d@oracle.com> Hi Boris, Just a note that your webrevs should be against the mainline code, not incremental from your previous proposed patch. (Though you can also provide an incremental webrev if you desire.) Thanks, David On 16/05/2019 6:37 pm, Boris Ulasevich wrote: > > The default value is also too big (64) so your code would handle this > > case anyway. > > > On 16.05.2019 10:19, David Holmes wrote: >> Hi Boris, >> >> On 15/05/2019 11:13 pm, Boris Ulasevich wrote: >>> Hi David, >>> >>> On 15.05.2019 15:39, David Holmes wrote: >>>> Hi Boris, >>>> >>>> On 15/05/2019 9:02 pm, Boris Ulasevich wrote: >>>>> Hi David, >>>>> >>>>> Thanks for review! I added a warning and fixed the drop back value: >>>>> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.02 >>>> >>>> With that change this code is pointless: >>>> >>>> ??274?? if (FLAG_IS_DEFAULT(MaxVectorSize)) { >>>> ??275???? // FLAG_SET_DEFAULT(MaxVectorSize, has_simd() ? 16 : 8); >>>> ??276???? // SIMD/NEON can use 16, but default is 8 because currently >>>> ??277???? // larger than 8 will disable instruction scheduling >>>> ??278???? FLAG_SET_DEFAULT(MaxVectorSize, 8); >>>> ??279?? } >>>> >>>> as it will be handled by your new code. >>> >>> This code sets MaxVectorSize=8 when no -XX:MaxVectorSize option is >>> specified while the new code sets 8/16 when the specified size is too >>> big. I think these two blocks of code live together quite well :) >> >> The default value is also too big (64) so your code would handle this >> case anyway. But as Dean notes the warning should only be issued when >> the user explicitly sets the value. > > I see. I like your proposal. It is just more reasonable code. > Thanks to you and Dean! > > http://cr.openjdk.java.net/~bulasevich/8220656/webrev.03 > >> So I think your change is better applied as an else clause to the >> existing code: >> >> ??if (FLAG_IS_DEFAULT(MaxVectorSize)) { >> ??? // FLAG_SET_DEFAULT(MaxVectorSize, has_simd() ? 16 : 8); >> ??? // SIMD/NEON can use 16, but default is 8 because currently >> ??? // larger than 8 will disable instruction scheduling >> ??? FLAG_SET_DEFAULT(MaxVectorSize, 8); >> ! } else { >> +?? int max_vector_size = has_simd() ? 16 : 8; >> +?? if (MaxVectorSize > max_vector_size) { >> +???? warning("MaxVectorSize must be at most %i on this platform", >> max_vector_size); >> +???? FLAG_SET_DEFAULT(MaxVectorSize, max_vector_size); >> +?? } >> + } >> >> Thanks, >> David >> >> >>>> Thanks, >>>> David >>>> >>>>> regards, >>>>> Boris >>>>> >>>>> On 15.05.2019 4:16, David Holmes wrote: >>>>>> On 15/05/2019 6:48 am, dean.long at oracle.com wrote: >>>>>>> Looks fine, but you might want to print a warning if you override >>>>>>> the user's choice. >>>>>> >>>>>> I would normally agree, but in this case the following code will >>>>>> already silently overwrite the user's choice in some cases: >>>>>> >>>>>> ??281?? if (MaxVectorSize > 16) { >>>>>> ??282???? FLAG_SET_DEFAULT(MaxVectorSize, 8); >>>>>> ??283?? } >>>>>> >>>>>> and I find it odd that it drops it back to 8 rather than taking >>>>>> the upper-limit of 16. >>>>>> >>>>>> To me the first problem here is that MaxVectorSize should be a >>>>>> pd_global so each platform can just set the right default to begin >>>>>> with, and set a correct allowed range for that platform. In fact >>>>>> with a constraint function it could even incorporate the >>>>>> has_simd() check. But that's getting a bit beyond the current fix. >>>>>> >>>>>> I can't see any non-convoluted way to print a warning under all >>>>>> the right circumstances, so I'll leave it to Boris to decide what >>>>>> to do here. I don't think a warning is essential. >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>>> dl >>>>>>> >>>>>>> On 5/14/19 8:39 AM, Boris Ulasevich wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review a simple change to prevent VLD1/VST1 instructions >>>>>>>> generation on ARM32 processor without SIMD support. The change >>>>>>>> overrides MaxVectorSize option set up by user to a value >>>>>>>> acceptable by the hardware. >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8220656 >>>>>>>> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.01/ >>>>>>>> >>>>>>>> thanks, >>>>>>>> Boris >>>>>>> From rahul.v.raghavan at oracle.com Thu May 16 09:56:57 2019 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Thu, 16 May 2019 15:26:57 +0530 Subject: [13] RFR: 8213416: Replace some enums with static const members in hotspot/compiler In-Reply-To: <55bac532-4df7-d3a3-6b87-90f21e228aab@oracle.com> References: <1f7afc19-0756-33f8-54f5-2438ed5da886@oracle.com> <55bac532-4df7-d3a3-6b87-90f21e228aab@oracle.com> Message-ID: <9263192b-4f10-b470-7b56-64295319bd4d@oracle.com> Hi, Thank you David for review comments. I will kindly request help from Magnus to reply for the main questions. Sharing some notes, related links - - 8211073: Remove -Wno-extra from Hotspot https://bugs.openjdk.java.net/browse/JDK-8211073 - Discussions in earlier thread - https://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034314.html So understood -Wextra do help in catching valid/useful warnings also, but along with some too strict ones like "enumeral and non-enumeral type in conditional expression" type warnings. Extracts from 8211073 JBS comments from Magnus regarding the 'enum-warning' - "... If you think that gcc is a bit too picky here, I agree. It's not obvious per se that the added casts improve the code. However, this is the price we need to pay to be able to enable -Wextra, and *that* is something that is likely to improve the code." Thanks, Rahul On 16/05/19 11:13 AM, David Holmes wrote: > This all seems like unnecessary churn to me - is any of this code > actually wrong? can we not just disable this particular warning? is > there any point using "static const" when we should be aiming to use > C++11 constexpr in the (not too distant?) future? > > Converting from enums to unrelated ints seems a big step backwards in > software engineering terms. :( > > Cheers, > David > ----- > From shade at redhat.com Thu May 16 11:01:28 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 16 May 2019 13:01:28 +0200 Subject: RFR (XS) 8224033: os::snprintf should be used in virtualizationSupport.cpp Message-ID: <60913fe2-f2d1-41c7-5253-8e6aa6a35ec1@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8224033 Fix: diff -r 382101e97784 src/hotspot/share/utilities/virtualizationSupport.cpp --- a/src/hotspot/share/utilities/virtualizationSupport.cpp Thu May 16 10:52:36 2019 +0200 +++ b/src/hotspot/share/utilities/virtualizationSupport.cpp Thu May 16 13:00:35 2019 +0200 @@ -66,5 +66,5 @@ if (sg_error == VMGUESTLIB_ERROR_SUCCESS) { has_resource_information = true; - snprintf(extended_resource_info_at_startup, sizeof(extended_resource_info_at_startup), "%s", result_info); + os::snprintf(extended_resource_info_at_startup, sizeof(extended_resource_info_at_startup), "%s", result_info); GuestLib_StatFree(result_info, result_size); } @@ -72,5 +72,5 @@ if (sg_error == VMGUESTLIB_ERROR_SUCCESS) { has_host_information = true; - snprintf(host_information, sizeof(host_information), "%s", result_info); + os::snprintf(host_information, sizeof(host_information), "%s", result_info); GuestLib_StatFree(result_info, result_size); } os::snprintf should be used in new code because -Wformat does not check raw snprintf (see JDK-8198918). It also fixes Windows build failure without PCH. Can run more tests on-demand, but I think it is trivial, so I only made the builds. Testing: {Linux, Windows} x86_64 fastdebug builds; -- Thanks, -Aleksey From coleen.phillimore at oracle.com Thu May 16 11:41:28 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 16 May 2019 07:41:28 -0400 Subject: RFR (S) 8223585: vmTestbase/runtime/pcl/* get SEGV in MetadataOnStackClosure::do_metadata(Metadata*)+0x0 In-Reply-To: <32475696-92c5-2451-0025-f829ae04af84@oracle.com> References: <6703941c-87cb-fa0b-59fa-400baae99148@oracle.com> <3062a50e-9da4-9272-247a-6467d70fd841@oracle.com> <32475696-92c5-2451-0025-f829ae04af84@oracle.com> Message-ID: <6287ce6d-3cd0-b369-352c-563b99de5e6c@oracle.com> Thanks Serguei! Coleen On 5/15/19 11:49 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > Looks good to me. > > Thanks, > Serguei > > > On 5/15/19 10:04, Jean Christophe Beyler wrote: >> Hi Coleen, >> >> Looks good to me (not an official reviewer), >> Jc >> >> *From: *Vladimir Kozlov >> *Date: *Wed, May 15, 2019 at 9:34 AM >> *To: * , hotspot-dev developers, >> serviceability-dev at openjdk.java.net >> >> Looks good. >>> Thanks, >>> Vladimir >>> >>> On 5/15/19 6:46 AM, coleen.phillimore at oracle.com wrote: >>>> Summary: adjust old method table by only one thread. >>>> >>>> Entries were removed from the redefinition old method table by G1 by >>> multiple threads at a safepoint, so didn't take the >>>> CodeCache_lock. Moved the removal to nmethod->flush().? The bug is >>> confidential because there's a confidential comment >>>> not marked confidential but we'll open it up once that's fixed. >>>> >>>> Passed redefinition tests in repository with "VM_OPTIONS=-Xcomp >>> -XX:TieredStopAtLevel=1", including the PCL tests that >>>> in the oracle closed repo. >>>> >>>> Also ran hs-tier1-3. >>>> >>>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2019/8223585.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8223585 >>>> >>>> Thanks, >>>> Coleen >> > From matthias.baesken at sap.com Thu May 16 11:44:09 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 16 May 2019 11:44:09 +0000 Subject: RFR (XS) 8224033: os::snprintf should be used in virtualizationSupport.cpp Message-ID: Hi Aleksey , thanks for the fix, I think os::snprintf is the way to go . ( not a Reviewer however ) However , with VS2017 the windows x86_64 build works as well with PCH disabled . So it seems to me that it is not (only) a PCH related issue . I think it might be related to the Visual studio version used (we use VS2017 ) ; I did not see your VS version in the bug . But anyway, os::snprintf sounds good to me ! Best regards, Matthias > Message: 5 > Date: Thu, 16 May 2019 13:01:28 +0200 > From: Aleksey Shipilev > To: "hotspot-dev at openjdk.java.net" > Subject: RFR (XS) 8224033: os::snprintf should be used in > virtualizationSupport.cpp > Message-ID: <60913fe2-f2d1-41c7-5253-8e6aa6a35ec1 at redhat.com> > Content-Type: text/plain; charset=utf-8 > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8224033 > > Fix: > > diff -r 382101e97784 src/hotspot/share/utilities/virtualizationSupport.cpp > --- a/src/hotspot/share/utilities/virtualizationSupport.cpp Thu May 16 > 10:52:36 2019 +0200 > +++ b/src/hotspot/share/utilities/virtualizationSupport.cpp Thu May 16 > 13:00:35 2019 +0200 > @@ -66,5 +66,5 @@ > if (sg_error == VMGUESTLIB_ERROR_SUCCESS) { > has_resource_information = true; > - snprintf(extended_resource_info_at_startup, > sizeof(extended_resource_info_at_startup), "%s", > result_info); > + os::snprintf(extended_resource_info_at_startup, > sizeof(extended_resource_info_at_startup), > "%s", result_info); > GuestLib_StatFree(result_info, result_size); > } > @@ -72,5 +72,5 @@ > if (sg_error == VMGUESTLIB_ERROR_SUCCESS) { > has_host_information = true; > - snprintf(host_information, sizeof(host_information), "%s", result_info); > + os::snprintf(host_information, sizeof(host_information), "%s", > result_info); > GuestLib_StatFree(result_info, result_size); > } > > > os::snprintf should be used in new code because -Wformat does not check > raw snprintf (see > JDK-8198918). It also fixes Windows build failure without PCH. Can run more > tests on-demand, but I > think it is trivial, so I only made the builds. > > Testing: {Linux, Windows} x86_64 fastdebug builds; From shade at redhat.com Thu May 16 11:49:00 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 16 May 2019 13:49:00 +0200 Subject: RFR (XS) 8224033: os::snprintf should be used in virtualizationSupport.cpp In-Reply-To: References: Message-ID: <31a0b135-416d-d375-028e-ae9d610928ff@redhat.com> On 5/16/19 1:44 PM, Baesken, Matthias wrote: > However , with VS2017 the windows x86_64 build works as well with PCH disabled . So it seems > to me that it is not (only) a PCH related issue . Yes, it is. I believe we get the header included transitively with PCH from somewhere. No biggie, using os::sprintf needs os.hpp, which is already included. My CI builds with old VS 2013, which is problematic sometimes, but it also finds legit problems like this one. -Aleksey From david.holmes at oracle.com Thu May 16 12:24:31 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 May 2019 22:24:31 +1000 Subject: RFR (S) 8220656 : ARM32: -XX:MaxVectorSize=16 makes SIGILL In-Reply-To: <654e8704-877f-b282-1edd-26ddf1a77a2d@oracle.com> References: <2b472d5c-e7ee-3fae-9b80-a0562a5e97ff@oracle.com> <213d552c-8b84-c269-463d-f354d65a48bd@oracle.com> <923ae7d2-5de0-b65b-250d-2fa3d493d649@oracle.com> <7f22f026-d238-c880-7d6d-5b0e3382b2fb@bell-sw.com> <0012993b-f786-5e74-fffb-bbf1ce554338@bell-sw.com> <654e8704-877f-b282-1edd-26ddf1a77a2d@oracle.com> Message-ID: <8cf763c1-cee7-dc5b-0ee1-316cb275448a@oracle.com> My apologies Boris your webrev is correct. David On 16/05/2019 7:27 pm, David Holmes wrote: > Hi Boris, > > Just a note that your webrevs should be against the mainline code, not > incremental from your previous proposed patch. (Though you can also > provide an incremental webrev if you desire.) > > Thanks, > David > > On 16/05/2019 6:37 pm, Boris Ulasevich wrote: >> ?> The default value is also too big (64) so your code would handle this >> ?> case anyway. >> >> >> On 16.05.2019 10:19, David Holmes wrote: >>> Hi Boris, >>> >>> On 15/05/2019 11:13 pm, Boris Ulasevich wrote: >>>> Hi David, >>>> >>>> On 15.05.2019 15:39, David Holmes wrote: >>>>> Hi Boris, >>>>> >>>>> On 15/05/2019 9:02 pm, Boris Ulasevich wrote: >>>>>> Hi David, >>>>>> >>>>>> Thanks for review! I added a warning and fixed the drop back value: >>>>>> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.02 >>>>> >>>>> With that change this code is pointless: >>>>> >>>>> ??274?? if (FLAG_IS_DEFAULT(MaxVectorSize)) { >>>>> ??275???? // FLAG_SET_DEFAULT(MaxVectorSize, has_simd() ? 16 : 8); >>>>> ??276???? // SIMD/NEON can use 16, but default is 8 because currently >>>>> ??277???? // larger than 8 will disable instruction scheduling >>>>> ??278???? FLAG_SET_DEFAULT(MaxVectorSize, 8); >>>>> ??279?? } >>>>> >>>>> as it will be handled by your new code. >>>> >>>> This code sets MaxVectorSize=8 when no -XX:MaxVectorSize option is >>>> specified while the new code sets 8/16 when the specified size is >>>> too big. I think these two blocks of code live together quite well :) >>> >>> The default value is also too big (64) so your code would handle this >>> case anyway. But as Dean notes the warning should only be issued when >>> the user explicitly sets the value. >> >> I see. I like your proposal. It is just more reasonable code. >> Thanks to you and Dean! >> >> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.03 >> >>> So I think your change is better applied as an else clause to the >>> existing code: >>> >>> ??if (FLAG_IS_DEFAULT(MaxVectorSize)) { >>> ??? // FLAG_SET_DEFAULT(MaxVectorSize, has_simd() ? 16 : 8); >>> ??? // SIMD/NEON can use 16, but default is 8 because currently >>> ??? // larger than 8 will disable instruction scheduling >>> ??? FLAG_SET_DEFAULT(MaxVectorSize, 8); >>> ! } else { >>> +?? int max_vector_size = has_simd() ? 16 : 8; >>> +?? if (MaxVectorSize > max_vector_size) { >>> +???? warning("MaxVectorSize must be at most %i on this platform", >>> max_vector_size); >>> +???? FLAG_SET_DEFAULT(MaxVectorSize, max_vector_size); >>> +?? } >>> + } >>> >>> Thanks, >>> David >>> >>> >>>>> Thanks, >>>>> David >>>>> >>>>>> regards, >>>>>> Boris >>>>>> >>>>>> On 15.05.2019 4:16, David Holmes wrote: >>>>>>> On 15/05/2019 6:48 am, dean.long at oracle.com wrote: >>>>>>>> Looks fine, but you might want to print a warning if you >>>>>>>> override the user's choice. >>>>>>> >>>>>>> I would normally agree, but in this case the following code will >>>>>>> already silently overwrite the user's choice in some cases: >>>>>>> >>>>>>> ??281?? if (MaxVectorSize > 16) { >>>>>>> ??282???? FLAG_SET_DEFAULT(MaxVectorSize, 8); >>>>>>> ??283?? } >>>>>>> >>>>>>> and I find it odd that it drops it back to 8 rather than taking >>>>>>> the upper-limit of 16. >>>>>>> >>>>>>> To me the first problem here is that MaxVectorSize should be a >>>>>>> pd_global so each platform can just set the right default to >>>>>>> begin with, and set a correct allowed range for that platform. In >>>>>>> fact with a constraint function it could even incorporate the >>>>>>> has_simd() check. But that's getting a bit beyond the current fix. >>>>>>> >>>>>>> I can't see any non-convoluted way to print a warning under all >>>>>>> the right circumstances, so I'll leave it to Boris to decide what >>>>>>> to do here. I don't think a warning is essential. >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>>> dl >>>>>>>> >>>>>>>> On 5/14/19 8:39 AM, Boris Ulasevich wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Please review a simple change to prevent VLD1/VST1 instructions >>>>>>>>> generation on ARM32 processor without SIMD support. The change >>>>>>>>> overrides MaxVectorSize option set up by user to a value >>>>>>>>> acceptable by the hardware. >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8220656 >>>>>>>>> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.01/ >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> Boris >>>>>>>> From boris.ulasevich at bell-sw.com Thu May 16 12:37:46 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Thu, 16 May 2019 15:37:46 +0300 Subject: RFR: 8222825: ARM32 SIGILL issue on single core CPU (not supported PLDW instruction) In-Reply-To: <38fc2c86-5e7c-550c-fa45-91720dab39b0@oracle.com> References: <1695e37a-e9bd-364a-68ef-e357d9b8a939@bell-sw.com> <71276d27-7183-fb8f-c58c-ddff4a528b25@oracle.com> <105f00fe-b9f6-58ce-00e2-345f4cfd9d8f@bell-sw.com> <38fc2c86-5e7c-550c-fa45-91720dab39b0@oracle.com> Message-ID: Hi David, Dean, Yes. Thanks for waiting. I think two arm.ad rules are definitely better than one with incorrect print. Now arm.ad looks very similar to the state before removing obsolete AssumeMP option: http://cr.openjdk.java.net/~bulasevich/8222825/webrev.04.jdk-jdk thanks, Boris On 16.05.2019 12:00, David Holmes wrote: > Hi Boris, > > Waiting to see if you have any response to Dean's suggestion before I > push this for you. > > David > > On 14/05/2019 4:28 pm, dean.long at oracle.com wrote: >> This looks good.? In arm.ad, you could use two rules and a predicate, >> so that the PrintOptoAssembly output is correct. >> >> dl >> >> On 5/13/19 11:04 PM, Boris Ulasevich wrote: >>> Hi David, >>> >>> ? It took a time to test the change :) >>> ? Yes, please. Thank you! >>> >>> Boris >>> >>> 14.05.2019 8:00, David Holmes ?????: >>>> Hi Boris, >>>> >>>> I was wondering what had happened to this one :) >>>> >>>> Looks good! I can sponsor for you. >>>> >>>> Thanks, >>>> David >>>> >>>> On 14/05/2019 2:45 pm, Boris Ulasevich wrote: >>>>> Hi all, >>>>> >>>>> Please review the fix for SIGILL that happens on ARM32 CPU without >>>>> Multiprocessing Extensions support (this applies to single-core >>>>> arm32 processors, which are not very common this days). With the >>>>> fix we check PLDW instruction availability on JVM start-up to >>>>> correct further instructions generation. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8222825 >>>>> http://cr.openjdk.java.net/~bulasevich/8222825/webrev.03.jdk-jdk >>>>> >>>>> thanks, >>>>> Boris >>> >>> >> From david.holmes at oracle.com Thu May 16 12:44:13 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 May 2019 22:44:13 +1000 Subject: RFR: 8222825: ARM32 SIGILL issue on single core CPU (not supported PLDW instruction) In-Reply-To: References: <1695e37a-e9bd-364a-68ef-e357d9b8a939@bell-sw.com> <71276d27-7183-fb8f-c58c-ddff4a528b25@oracle.com> <105f00fe-b9f6-58ce-00e2-345f4cfd9d8f@bell-sw.com> <38fc2c86-5e7c-550c-fa45-91720dab39b0@oracle.com> Message-ID: Hi Boris, On 16/05/2019 10:37 pm, Boris Ulasevich wrote: > Hi David, Dean, > > Yes. Thanks for waiting. I think two arm.ad rules are definitely better > than one with incorrect print. Now arm.ad looks very similar to the > state before removing obsolete AssumeMP option: > > http://cr.openjdk.java.net/~bulasevich/8222825/webrev.04.jdk-jdk ad files are not really my area but this seems okay. One query in src/hotspot/cpu/arm/assembler_arm_32.hpp: ! assert(!VM_Version::is_initialized() || I'm surprised this can be called before VM_Version is initialized. I presume you encountered an assertion failure without this - what was the call sequence that led here? Thanks, David > thanks, > Boris > > On 16.05.2019 12:00, David Holmes wrote: >> Hi Boris, >> >> Waiting to see if you have any response to Dean's suggestion before I >> push this for you. >> >> David >> >> On 14/05/2019 4:28 pm, dean.long at oracle.com wrote: >>> This looks good.? In arm.ad, you could use two rules and a predicate, >>> so that the PrintOptoAssembly output is correct. >>> >>> dl >>> >>> On 5/13/19 11:04 PM, Boris Ulasevich wrote: >>>> Hi David, >>>> >>>> ? It took a time to test the change :) >>>> ? Yes, please. Thank you! >>>> >>>> Boris >>>> >>>> 14.05.2019 8:00, David Holmes ?????: >>>>> Hi Boris, >>>>> >>>>> I was wondering what had happened to this one :) >>>>> >>>>> Looks good! I can sponsor for you. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 14/05/2019 2:45 pm, Boris Ulasevich wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review the fix for SIGILL that happens on ARM32 CPU without >>>>>> Multiprocessing Extensions support (this applies to single-core >>>>>> arm32 processors, which are not very common this days). With the >>>>>> fix we check PLDW instruction availability on JVM start-up to >>>>>> correct further instructions generation. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8222825 >>>>>> http://cr.openjdk.java.net/~bulasevich/8222825/webrev.03.jdk-jdk >>>>>> >>>>>> thanks, >>>>>> Boris >>>> >>>> >>> From boris.ulasevich at bell-sw.com Thu May 16 12:55:00 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Thu, 16 May 2019 15:55:00 +0300 Subject: RFR: 8222825: ARM32 SIGILL issue on single core CPU (not supported PLDW instruction) In-Reply-To: References: <1695e37a-e9bd-364a-68ef-e357d9b8a939@bell-sw.com> <71276d27-7183-fb8f-c58c-ddff4a528b25@oracle.com> <105f00fe-b9f6-58ce-00e2-345f4cfd9d8f@bell-sw.com> <38fc2c86-5e7c-550c-fa45-91720dab39b0@oracle.com> Message-ID: <0e4a5145-6721-7791-9f88-467aa056493c@bell-sw.com> On 16.05.2019 15:44, David Holmes wrote: > Hi Boris, > > On 16/05/2019 10:37 pm, Boris Ulasevich wrote: >> Hi David, Dean, >> >> Yes. Thanks for waiting. I think two arm.ad rules are definitely >> better than one with incorrect print. Now arm.ad looks very similar to >> the state before removing obsolete AssumeMP option: >> >> http://cr.openjdk.java.net/~bulasevich/8222825/webrev.04.jdk-jdk > > ad files are not really my area but this seems okay. > > One query in src/hotspot/cpu/arm/assembler_arm_32.hpp: > > !???? assert(!VM_Version::is_initialized() || > > I'm surprised this can be called before VM_Version is initialized. I > presume you encountered an assertion failure without this - what was the > call sequence that led here? pldw is similar to vcnt in this aspect: - before vm initialization pldw is used in generated stub to check if we will get SIGILL or not. This time it is correct to generate the instruction. - after vm initialization we already checked the things and know hardware capabilities, so this time we should not use instructions not supported by hardware Call sequence is VM_Version::initialize -> check_mp_ext. > Thanks, > David > >> thanks, >> Boris >> >> On 16.05.2019 12:00, David Holmes wrote: >>> Hi Boris, >>> >>> Waiting to see if you have any response to Dean's suggestion before I >>> push this for you. >>> >>> David >>> >>> On 14/05/2019 4:28 pm, dean.long at oracle.com wrote: >>>> This looks good.? In arm.ad, you could use two rules and a >>>> predicate, so that the PrintOptoAssembly output is correct. >>>> >>>> dl >>>> >>>> On 5/13/19 11:04 PM, Boris Ulasevich wrote: >>>>> Hi David, >>>>> >>>>> ? It took a time to test the change :) >>>>> ? Yes, please. Thank you! >>>>> >>>>> Boris >>>>> >>>>> 14.05.2019 8:00, David Holmes ?????: >>>>>> Hi Boris, >>>>>> >>>>>> I was wondering what had happened to this one :) >>>>>> >>>>>> Looks good! I can sponsor for you. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 14/05/2019 2:45 pm, Boris Ulasevich wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review the fix for SIGILL that happens on ARM32 CPU >>>>>>> without Multiprocessing Extensions support (this applies to >>>>>>> single-core arm32 processors, which are not very common this >>>>>>> days). With the fix we check PLDW instruction availability on JVM >>>>>>> start-up to correct further instructions generation. >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8222825 >>>>>>> http://cr.openjdk.java.net/~bulasevich/8222825/webrev.03.jdk-jdk >>>>>>> >>>>>>> thanks, >>>>>>> Boris >>>>> >>>>> >>>> From thomas.stuefe at gmail.com Thu May 16 13:10:47 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 16 May 2019 15:10:47 +0200 Subject: RFR (XS) 8224033: os::snprintf should be used in virtualizationSupport.cpp In-Reply-To: <60913fe2-f2d1-41c7-5253-8e6aa6a35ec1@redhat.com> References: <60913fe2-f2d1-41c7-5253-8e6aa6a35ec1@redhat.com> Message-ID: Looks fine. ..Thomas On Thu, May 16, 2019 at 1:02 PM Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8224033 > > Fix: > > diff -r 382101e97784 src/hotspot/share/utilities/virtualizationSupport.cpp > --- a/src/hotspot/share/utilities/virtualizationSupport.cpp Thu May 16 > 10:52:36 2019 +0200 > +++ b/src/hotspot/share/utilities/virtualizationSupport.cpp Thu May 16 > 13:00:35 2019 +0200 > @@ -66,5 +66,5 @@ > if (sg_error == VMGUESTLIB_ERROR_SUCCESS) { > has_resource_information = true; > - snprintf(extended_resource_info_at_startup, > sizeof(extended_resource_info_at_startup), "%s", > result_info); > + os::snprintf(extended_resource_info_at_startup, > sizeof(extended_resource_info_at_startup), > "%s", result_info); > GuestLib_StatFree(result_info, result_size); > } > @@ -72,5 +72,5 @@ > if (sg_error == VMGUESTLIB_ERROR_SUCCESS) { > has_host_information = true; > - snprintf(host_information, sizeof(host_information), "%s", > result_info); > + os::snprintf(host_information, sizeof(host_information), "%s", > result_info); > GuestLib_StatFree(result_info, result_size); > } > > > os::snprintf should be used in new code because -Wformat does not check > raw snprintf (see > JDK-8198918). It also fixes Windows build failure without PCH. Can run > more tests on-demand, but I > think it is trivial, so I only made the builds. > > Testing: {Linux, Windows} x86_64 fastdebug builds; > -- > Thanks, > -Aleksey > > From shade at redhat.com Thu May 16 17:24:01 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 16 May 2019 19:24:01 +0200 Subject: RFR (XS) 8224033: os::snprintf should be used in virtualizationSupport.cpp In-Reply-To: References: <60913fe2-f2d1-41c7-5253-8e6aa6a35ec1@redhat.com> Message-ID: Thanks, I am going to push this soon under triviality rules. -Aleksey On 5/16/19 3:10 PM, Thomas St?fe wrote: > Looks fine. > > ..Thomas > > On Thu, May 16, 2019 at 1:02 PM Aleksey Shipilev > wrote: > > Bug: > ? https://bugs.openjdk.java.net/browse/JDK-8224033 > > Fix: > > diff -r 382101e97784 src/hotspot/share/utilities/virtualizationSupport.cpp > --- a/src/hotspot/share/utilities/virtualizationSupport.cpp? ? ?Thu May 16 10:52:36 2019 +0200 > +++ b/src/hotspot/share/utilities/virtualizationSupport.cpp? ? ?Thu May 16 13:00:35 2019 +0200 > @@ -66,5 +66,5 @@ > ? ? ?if (sg_error == VMGUESTLIB_ERROR_SUCCESS) { > ? ? ? ?has_resource_information = true; > -? ? ? snprintf(extended_resource_info_at_startup, sizeof(extended_resource_info_at_startup), "%s", > result_info); > +? ? ? os::snprintf(extended_resource_info_at_startup, sizeof(extended_resource_info_at_startup), > "%s", result_info); > ? ? ? ?GuestLib_StatFree(result_info, result_size); > ? ? ?} > @@ -72,5 +72,5 @@ > ? ? ?if (sg_error == VMGUESTLIB_ERROR_SUCCESS) { > ? ? ? ?has_host_information = true; > -? ? ? snprintf(host_information, sizeof(host_information), "%s", result_info); > +? ? ? os::snprintf(host_information, sizeof(host_information), "%s", result_info); > ? ? ? ?GuestLib_StatFree(result_info, result_size); > ? ? ?} > > > os::snprintf should be used in new code because -Wformat does not check raw snprintf (see > JDK-8198918). It also fixes Windows build failure without PCH. Can run more tests on-demand, but I > think it is trivial, so I only made the builds. > > Testing: {Linux, Windows} x86_64 fastdebug builds; > -- > Thanks, > -Aleksey > -- Thanks, -Aleksey Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander From shade at redhat.com Thu May 16 19:34:27 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 16 May 2019 21:34:27 +0200 Subject: RFR (XS) 8224033: os::snprintf should be used in virtualizationSupport.cpp In-Reply-To: References: <60913fe2-f2d1-41c7-5253-8e6aa6a35ec1@redhat.com> Message-ID: <7abec16f-8e78-d0cb-5d58-1684416e58fc@redhat.com> On 5/16/19 7:24 PM, Aleksey Shipilev wrote: > Thanks, I am going to push this soon under triviality rules. jdk-submit returned clean anyway. Pushed. -Aleksey From david.holmes at oracle.com Thu May 16 21:48:11 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 May 2019 07:48:11 +1000 Subject: RFR: 8222825: ARM32 SIGILL issue on single core CPU (not supported PLDW instruction) In-Reply-To: <0e4a5145-6721-7791-9f88-467aa056493c@bell-sw.com> References: <1695e37a-e9bd-364a-68ef-e357d9b8a939@bell-sw.com> <71276d27-7183-fb8f-c58c-ddff4a528b25@oracle.com> <105f00fe-b9f6-58ce-00e2-345f4cfd9d8f@bell-sw.com> <38fc2c86-5e7c-550c-fa45-91720dab39b0@oracle.com> <0e4a5145-6721-7791-9f88-467aa056493c@bell-sw.com> Message-ID: <66382392-f969-abd9-4341-89cf4ef49535@oracle.com> On 16/05/2019 10:55 pm, Boris Ulasevich wrote: > > > On 16.05.2019 15:44, David Holmes wrote: >> Hi Boris, >> >> On 16/05/2019 10:37 pm, Boris Ulasevich wrote: >>> Hi David, Dean, >>> >>> Yes. Thanks for waiting. I think two arm.ad rules are definitely >>> better than one with incorrect print. Now arm.ad looks very similar >>> to the state before removing obsolete AssumeMP option: >>> >>> http://cr.openjdk.java.net/~bulasevich/8222825/webrev.04.jdk-jdk >> >> ad files are not really my area but this seems okay. >> >> One query in src/hotspot/cpu/arm/assembler_arm_32.hpp: >> >> !???? assert(!VM_Version::is_initialized() || >> >> I'm surprised this can be called before VM_Version is initialized. I >> presume you encountered an assertion failure without this - what was >> the call sequence that led here? > > pldw is similar to vcnt in this aspect: > - before vm initialization pldw is used in generated stub to check if we > will get SIGILL or not. This time it is correct to generate the > instruction. Doh! Of course. Thanks for clarifying. David > - after vm initialization we already checked the things and know > hardware capabilities, so this time we should not use instructions not > supported by hardware > > Call sequence is VM_Version::initialize -> check_mp_ext. > >> Thanks, >> David >> >>> thanks, >>> Boris >>> >>> On 16.05.2019 12:00, David Holmes wrote: >>>> Hi Boris, >>>> >>>> Waiting to see if you have any response to Dean's suggestion before >>>> I push this for you. >>>> >>>> David >>>> >>>> On 14/05/2019 4:28 pm, dean.long at oracle.com wrote: >>>>> This looks good.? In arm.ad, you could use two rules and a >>>>> predicate, so that the PrintOptoAssembly output is correct. >>>>> >>>>> dl >>>>> >>>>> On 5/13/19 11:04 PM, Boris Ulasevich wrote: >>>>>> Hi David, >>>>>> >>>>>> ? It took a time to test the change :) >>>>>> ? Yes, please. Thank you! >>>>>> >>>>>> Boris >>>>>> >>>>>> 14.05.2019 8:00, David Holmes ?????: >>>>>>> Hi Boris, >>>>>>> >>>>>>> I was wondering what had happened to this one :) >>>>>>> >>>>>>> Looks good! I can sponsor for you. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 14/05/2019 2:45 pm, Boris Ulasevich wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review the fix for SIGILL that happens on ARM32 CPU >>>>>>>> without Multiprocessing Extensions support (this applies to >>>>>>>> single-core arm32 processors, which are not very common this >>>>>>>> days). With the fix we check PLDW instruction availability on >>>>>>>> JVM start-up to correct further instructions generation. >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8222825 >>>>>>>> http://cr.openjdk.java.net/~bulasevich/8222825/webrev.03.jdk-jdk >>>>>>>> >>>>>>>> thanks, >>>>>>>> Boris >>>>>> >>>>>> >>>>> From dean.long at oracle.com Thu May 16 22:16:48 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 16 May 2019 15:16:48 -0700 Subject: RFR: 8222825: ARM32 SIGILL issue on single core CPU (not supported PLDW instruction) In-Reply-To: References: <1695e37a-e9bd-364a-68ef-e357d9b8a939@bell-sw.com> <71276d27-7183-fb8f-c58c-ddff4a528b25@oracle.com> <105f00fe-b9f6-58ce-00e2-345f4cfd9d8f@bell-sw.com> <38fc2c86-5e7c-550c-fa45-91720dab39b0@oracle.com> Message-ID: <73a988f7-2c5b-b6a2-791c-8bf9f08f97ab@oracle.com> Looks good. dl On 5/16/19 5:37 AM, Boris Ulasevich wrote: > Hi David, Dean, > > Yes. Thanks for waiting. I think two arm.ad rules are definitely > better than one with incorrect print. Now arm.ad looks very similar to > the state before removing obsolete AssumeMP option: > > http://cr.openjdk.java.net/~bulasevich/8222825/webrev.04.jdk-jdk > > thanks, > Boris > > On 16.05.2019 12:00, David Holmes wrote: >> Hi Boris, >> >> Waiting to see if you have any response to Dean's suggestion before I >> push this for you. >> >> David >> >> On 14/05/2019 4:28 pm, dean.long at oracle.com wrote: >>> This looks good.? In arm.ad, you could use two rules and a >>> predicate, so that the PrintOptoAssembly output is correct. >>> >>> dl >>> >>> On 5/13/19 11:04 PM, Boris Ulasevich wrote: >>>> Hi David, >>>> >>>> ? It took a time to test the change :) >>>> ? Yes, please. Thank you! >>>> >>>> Boris >>>> >>>> 14.05.2019 8:00, David Holmes ?????: >>>>> Hi Boris, >>>>> >>>>> I was wondering what had happened to this one :) >>>>> >>>>> Looks good! I can sponsor for you. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 14/05/2019 2:45 pm, Boris Ulasevich wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review the fix for SIGILL that happens on ARM32 CPU >>>>>> without Multiprocessing Extensions support (this applies to >>>>>> single-core arm32 processors, which are not very common this >>>>>> days). With the fix we check PLDW instruction availability on JVM >>>>>> start-up to correct further instructions generation. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8222825 >>>>>> http://cr.openjdk.java.net/~bulasevich/8222825/webrev.03.jdk-jdk >>>>>> >>>>>> thanks, >>>>>> Boris >>>> >>>> >>> From david.holmes at oracle.com Thu May 16 22:46:27 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 May 2019 08:46:27 +1000 Subject: RFR: 8222825: ARM32 SIGILL issue on single core CPU (not supported PLDW instruction) In-Reply-To: <73a988f7-2c5b-b6a2-791c-8bf9f08f97ab@oracle.com> References: <1695e37a-e9bd-364a-68ef-e357d9b8a939@bell-sw.com> <71276d27-7183-fb8f-c58c-ddff4a528b25@oracle.com> <105f00fe-b9f6-58ce-00e2-345f4cfd9d8f@bell-sw.com> <38fc2c86-5e7c-550c-fa45-91720dab39b0@oracle.com> <73a988f7-2c5b-b6a2-791c-8bf9f08f97ab@oracle.com> Message-ID: Changes pushed. David On 17/05/2019 8:16 am, dean.long at oracle.com wrote: > Looks good. > > dl > > On 5/16/19 5:37 AM, Boris Ulasevich wrote: >> Hi David, Dean, >> >> Yes. Thanks for waiting. I think two arm.ad rules are definitely >> better than one with incorrect print. Now arm.ad looks very similar to >> the state before removing obsolete AssumeMP option: >> >> http://cr.openjdk.java.net/~bulasevich/8222825/webrev.04.jdk-jdk >> >> thanks, >> Boris >> >> On 16.05.2019 12:00, David Holmes wrote: >>> Hi Boris, >>> >>> Waiting to see if you have any response to Dean's suggestion before I >>> push this for you. >>> >>> David >>> >>> On 14/05/2019 4:28 pm, dean.long at oracle.com wrote: >>>> This looks good.? In arm.ad, you could use two rules and a >>>> predicate, so that the PrintOptoAssembly output is correct. >>>> >>>> dl >>>> >>>> On 5/13/19 11:04 PM, Boris Ulasevich wrote: >>>>> Hi David, >>>>> >>>>> ? It took a time to test the change :) >>>>> ? Yes, please. Thank you! >>>>> >>>>> Boris >>>>> >>>>> 14.05.2019 8:00, David Holmes ?????: >>>>>> Hi Boris, >>>>>> >>>>>> I was wondering what had happened to this one :) >>>>>> >>>>>> Looks good! I can sponsor for you. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 14/05/2019 2:45 pm, Boris Ulasevich wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review the fix for SIGILL that happens on ARM32 CPU >>>>>>> without Multiprocessing Extensions support (this applies to >>>>>>> single-core arm32 processors, which are not very common this >>>>>>> days). With the fix we check PLDW instruction availability on JVM >>>>>>> start-up to correct further instructions generation. >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8222825 >>>>>>> http://cr.openjdk.java.net/~bulasevich/8222825/webrev.03.jdk-jdk >>>>>>> >>>>>>> thanks, >>>>>>> Boris >>>>> >>>>> >>>> > From dean.long at oracle.com Fri May 17 06:34:48 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 16 May 2019 23:34:48 -0700 Subject: RFR (S) 8220656 : ARM32: -XX:MaxVectorSize=16 makes SIGILL In-Reply-To: <8cf763c1-cee7-dc5b-0ee1-316cb275448a@oracle.com> References: <2b472d5c-e7ee-3fae-9b80-a0562a5e97ff@oracle.com> <213d552c-8b84-c269-463d-f354d65a48bd@oracle.com> <923ae7d2-5de0-b65b-250d-2fa3d493d649@oracle.com> <7f22f026-d238-c880-7d6d-5b0e3382b2fb@bell-sw.com> <0012993b-f786-5e74-fffb-bbf1ce554338@bell-sw.com> <654e8704-877f-b282-1edd-26ddf1a77a2d@oracle.com> <8cf763c1-cee7-dc5b-0ee1-316cb275448a@oracle.com> Message-ID: <2a2523ca-9643-51a3-7003-6e8293c0c604@oracle.com> Looks good to me too. dl On 5/16/19 5:24 AM, David Holmes wrote: > My apologies Boris your webrev is correct. > > David > > On 16/05/2019 7:27 pm, David Holmes wrote: >> Hi Boris, >> >> Just a note that your webrevs should be against the mainline code, >> not incremental from your previous proposed patch. (Though you can >> also provide an incremental webrev if you desire.) >> >> Thanks, >> David >> >> On 16/05/2019 6:37 pm, Boris Ulasevich wrote: >>> ?> The default value is also too big (64) so your code would handle >>> this >>> ?> case anyway. >>> >>> >>> On 16.05.2019 10:19, David Holmes wrote: >>>> Hi Boris, >>>> >>>> On 15/05/2019 11:13 pm, Boris Ulasevich wrote: >>>>> Hi David, >>>>> >>>>> On 15.05.2019 15:39, David Holmes wrote: >>>>>> Hi Boris, >>>>>> >>>>>> On 15/05/2019 9:02 pm, Boris Ulasevich wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> Thanks for review! I added a warning and fixed the drop back value: >>>>>>> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.02 >>>>>> >>>>>> With that change this code is pointless: >>>>>> >>>>>> ??274?? if (FLAG_IS_DEFAULT(MaxVectorSize)) { >>>>>> ??275???? // FLAG_SET_DEFAULT(MaxVectorSize, has_simd() ? 16 : 8); >>>>>> ??276???? // SIMD/NEON can use 16, but default is 8 because >>>>>> currently >>>>>> ??277???? // larger than 8 will disable instruction scheduling >>>>>> ??278???? FLAG_SET_DEFAULT(MaxVectorSize, 8); >>>>>> ??279?? } >>>>>> >>>>>> as it will be handled by your new code. >>>>> >>>>> This code sets MaxVectorSize=8 when no -XX:MaxVectorSize option is >>>>> specified while the new code sets 8/16 when the specified size is >>>>> too big. I think these two blocks of code live together quite well :) >>>> >>>> The default value is also too big (64) so your code would handle >>>> this case anyway. But as Dean notes the warning should only be >>>> issued when the user explicitly sets the value. >>> >>> I see. I like your proposal. It is just more reasonable code. >>> Thanks to you and Dean! >>> >>> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.03 >>> >>>> So I think your change is better applied as an else clause to the >>>> existing code: >>>> >>>> ??if (FLAG_IS_DEFAULT(MaxVectorSize)) { >>>> ??? // FLAG_SET_DEFAULT(MaxVectorSize, has_simd() ? 16 : 8); >>>> ??? // SIMD/NEON can use 16, but default is 8 because currently >>>> ??? // larger than 8 will disable instruction scheduling >>>> ??? FLAG_SET_DEFAULT(MaxVectorSize, 8); >>>> ! } else { >>>> +?? int max_vector_size = has_simd() ? 16 : 8; >>>> +?? if (MaxVectorSize > max_vector_size) { >>>> +???? warning("MaxVectorSize must be at most %i on this platform", >>>> max_vector_size); >>>> +???? FLAG_SET_DEFAULT(MaxVectorSize, max_vector_size); >>>> +?? } >>>> + } >>>> >>>> Thanks, >>>> David >>>> >>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> regards, >>>>>>> Boris >>>>>>> >>>>>>> On 15.05.2019 4:16, David Holmes wrote: >>>>>>>> On 15/05/2019 6:48 am, dean.long at oracle.com wrote: >>>>>>>>> Looks fine, but you might want to print a warning if you >>>>>>>>> override the user's choice. >>>>>>>> >>>>>>>> I would normally agree, but in this case the following code >>>>>>>> will already silently overwrite the user's choice in some cases: >>>>>>>> >>>>>>>> ??281?? if (MaxVectorSize > 16) { >>>>>>>> ??282???? FLAG_SET_DEFAULT(MaxVectorSize, 8); >>>>>>>> ??283?? } >>>>>>>> >>>>>>>> and I find it odd that it drops it back to 8 rather than taking >>>>>>>> the upper-limit of 16. >>>>>>>> >>>>>>>> To me the first problem here is that MaxVectorSize should be a >>>>>>>> pd_global so each platform can just set the right default to >>>>>>>> begin with, and set a correct allowed range for that platform. >>>>>>>> In fact with a constraint function it could even incorporate >>>>>>>> the has_simd() check. But that's getting a bit beyond the >>>>>>>> current fix. >>>>>>>> >>>>>>>> I can't see any non-convoluted way to print a warning under all >>>>>>>> the right circumstances, so I'll leave it to Boris to decide >>>>>>>> what to do here. I don't think a warning is essential. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> David >>>>>>>> >>>>>>>>> dl >>>>>>>>> >>>>>>>>> On 5/14/19 8:39 AM, Boris Ulasevich wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Please review a simple change to prevent VLD1/VST1 >>>>>>>>>> instructions generation on ARM32 processor without SIMD >>>>>>>>>> support. The change overrides MaxVectorSize option set up by >>>>>>>>>> user to a value acceptable by the hardware. >>>>>>>>>> >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8220656 >>>>>>>>>> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.01/ >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> Boris >>>>>>>>> From david.holmes at oracle.com Fri May 17 07:02:31 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 May 2019 17:02:31 +1000 Subject: RFR (S) 8220656 : ARM32: -XX:MaxVectorSize=16 makes SIGILL In-Reply-To: <2a2523ca-9643-51a3-7003-6e8293c0c604@oracle.com> References: <2b472d5c-e7ee-3fae-9b80-a0562a5e97ff@oracle.com> <213d552c-8b84-c269-463d-f354d65a48bd@oracle.com> <923ae7d2-5de0-b65b-250d-2fa3d493d649@oracle.com> <7f22f026-d238-c880-7d6d-5b0e3382b2fb@bell-sw.com> <0012993b-f786-5e74-fffb-bbf1ce554338@bell-sw.com> <654e8704-877f-b282-1edd-26ddf1a77a2d@oracle.com> <8cf763c1-cee7-dc5b-0ee1-316cb275448a@oracle.com> <2a2523ca-9643-51a3-7003-6e8293c0c604@oracle.com> Message-ID: Thanks Dean. Changes pushed. David On 17/05/2019 4:34 pm, dean.long at oracle.com wrote: > Looks good to me too. > > dl > > On 5/16/19 5:24 AM, David Holmes wrote: >> My apologies Boris your webrev is correct. >> >> David >> >> On 16/05/2019 7:27 pm, David Holmes wrote: >>> Hi Boris, >>> >>> Just a note that your webrevs should be against the mainline code, >>> not incremental from your previous proposed patch. (Though you can >>> also provide an incremental webrev if you desire.) >>> >>> Thanks, >>> David >>> >>> On 16/05/2019 6:37 pm, Boris Ulasevich wrote: >>>> ?> The default value is also too big (64) so your code would handle >>>> this >>>> ?> case anyway. >>>> >>>> >>>> On 16.05.2019 10:19, David Holmes wrote: >>>>> Hi Boris, >>>>> >>>>> On 15/05/2019 11:13 pm, Boris Ulasevich wrote: >>>>>> Hi David, >>>>>> >>>>>> On 15.05.2019 15:39, David Holmes wrote: >>>>>>> Hi Boris, >>>>>>> >>>>>>> On 15/05/2019 9:02 pm, Boris Ulasevich wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Thanks for review! I added a warning and fixed the drop back value: >>>>>>>> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.02 >>>>>>> >>>>>>> With that change this code is pointless: >>>>>>> >>>>>>> ??274?? if (FLAG_IS_DEFAULT(MaxVectorSize)) { >>>>>>> ??275???? // FLAG_SET_DEFAULT(MaxVectorSize, has_simd() ? 16 : 8); >>>>>>> ??276???? // SIMD/NEON can use 16, but default is 8 because >>>>>>> currently >>>>>>> ??277???? // larger than 8 will disable instruction scheduling >>>>>>> ??278???? FLAG_SET_DEFAULT(MaxVectorSize, 8); >>>>>>> ??279?? } >>>>>>> >>>>>>> as it will be handled by your new code. >>>>>> >>>>>> This code sets MaxVectorSize=8 when no -XX:MaxVectorSize option is >>>>>> specified while the new code sets 8/16 when the specified size is >>>>>> too big. I think these two blocks of code live together quite well :) >>>>> >>>>> The default value is also too big (64) so your code would handle >>>>> this case anyway. But as Dean notes the warning should only be >>>>> issued when the user explicitly sets the value. >>>> >>>> I see. I like your proposal. It is just more reasonable code. >>>> Thanks to you and Dean! >>>> >>>> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.03 >>>> >>>>> So I think your change is better applied as an else clause to the >>>>> existing code: >>>>> >>>>> ??if (FLAG_IS_DEFAULT(MaxVectorSize)) { >>>>> ??? // FLAG_SET_DEFAULT(MaxVectorSize, has_simd() ? 16 : 8); >>>>> ??? // SIMD/NEON can use 16, but default is 8 because currently >>>>> ??? // larger than 8 will disable instruction scheduling >>>>> ??? FLAG_SET_DEFAULT(MaxVectorSize, 8); >>>>> ! } else { >>>>> +?? int max_vector_size = has_simd() ? 16 : 8; >>>>> +?? if (MaxVectorSize > max_vector_size) { >>>>> +???? warning("MaxVectorSize must be at most %i on this platform", >>>>> max_vector_size); >>>>> +???? FLAG_SET_DEFAULT(MaxVectorSize, max_vector_size); >>>>> +?? } >>>>> + } >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> regards, >>>>>>>> Boris >>>>>>>> >>>>>>>> On 15.05.2019 4:16, David Holmes wrote: >>>>>>>>> On 15/05/2019 6:48 am, dean.long at oracle.com wrote: >>>>>>>>>> Looks fine, but you might want to print a warning if you >>>>>>>>>> override the user's choice. >>>>>>>>> >>>>>>>>> I would normally agree, but in this case the following code >>>>>>>>> will already silently overwrite the user's choice in some cases: >>>>>>>>> >>>>>>>>> ??281?? if (MaxVectorSize > 16) { >>>>>>>>> ??282???? FLAG_SET_DEFAULT(MaxVectorSize, 8); >>>>>>>>> ??283?? } >>>>>>>>> >>>>>>>>> and I find it odd that it drops it back to 8 rather than taking >>>>>>>>> the upper-limit of 16. >>>>>>>>> >>>>>>>>> To me the first problem here is that MaxVectorSize should be a >>>>>>>>> pd_global so each platform can just set the right default to >>>>>>>>> begin with, and set a correct allowed range for that platform. >>>>>>>>> In fact with a constraint function it could even incorporate >>>>>>>>> the has_simd() check. But that's getting a bit beyond the >>>>>>>>> current fix. >>>>>>>>> >>>>>>>>> I can't see any non-convoluted way to print a warning under all >>>>>>>>> the right circumstances, so I'll leave it to Boris to decide >>>>>>>>> what to do here. I don't think a warning is essential. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> dl >>>>>>>>>> >>>>>>>>>> On 5/14/19 8:39 AM, Boris Ulasevich wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> Please review a simple change to prevent VLD1/VST1 >>>>>>>>>>> instructions generation on ARM32 processor without SIMD >>>>>>>>>>> support. The change overrides MaxVectorSize option set up by >>>>>>>>>>> user to a value acceptable by the hardware. >>>>>>>>>>> >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8220656 >>>>>>>>>>> http://cr.openjdk.java.net/~bulasevich/8220656/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> thanks, >>>>>>>>>>> Boris >>>>>>>>>> > From boris.ulasevich at bell-sw.com Fri May 17 08:05:21 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Fri, 17 May 2019 11:05:21 +0300 Subject: RFR: 8222825: ARM32 SIGILL issue on single core CPU (not supported PLDW instruction) In-Reply-To: References: <1695e37a-e9bd-364a-68ef-e357d9b8a939@bell-sw.com> <71276d27-7183-fb8f-c58c-ddff4a528b25@oracle.com> <105f00fe-b9f6-58ce-00e2-345f4cfd9d8f@bell-sw.com> <38fc2c86-5e7c-550c-fa45-91720dab39b0@oracle.com> <73a988f7-2c5b-b6a2-791c-8bf9f08f97ab@oracle.com> Message-ID: Thank you! On 17.05.2019 1:46, David Holmes wrote: > Changes pushed. > > David > > On 17/05/2019 8:16 am, dean.long at oracle.com wrote: >> Looks good. >> >> dl >> >> On 5/16/19 5:37 AM, Boris Ulasevich wrote: >>> Hi David, Dean, >>> >>> Yes. Thanks for waiting. I think two arm.ad rules are definitely >>> better than one with incorrect print. Now arm.ad looks very similar >>> to the state before removing obsolete AssumeMP option: >>> >>> http://cr.openjdk.java.net/~bulasevich/8222825/webrev.04.jdk-jdk >>> >>> thanks, >>> Boris >>> >>> On 16.05.2019 12:00, David Holmes wrote: >>>> Hi Boris, >>>> >>>> Waiting to see if you have any response to Dean's suggestion before >>>> I push this for you. >>>> >>>> David >>>> >>>> On 14/05/2019 4:28 pm, dean.long at oracle.com wrote: >>>>> This looks good.? In arm.ad, you could use two rules and a >>>>> predicate, so that the PrintOptoAssembly output is correct. >>>>> >>>>> dl >>>>> >>>>> On 5/13/19 11:04 PM, Boris Ulasevich wrote: >>>>>> Hi David, >>>>>> >>>>>> ? It took a time to test the change :) >>>>>> ? Yes, please. Thank you! >>>>>> >>>>>> Boris >>>>>> >>>>>> 14.05.2019 8:00, David Holmes ?????: >>>>>>> Hi Boris, >>>>>>> >>>>>>> I was wondering what had happened to this one :) >>>>>>> >>>>>>> Looks good! I can sponsor for you. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 14/05/2019 2:45 pm, Boris Ulasevich wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review the fix for SIGILL that happens on ARM32 CPU >>>>>>>> without Multiprocessing Extensions support (this applies to >>>>>>>> single-core arm32 processors, which are not very common this >>>>>>>> days). With the fix we check PLDW instruction availability on >>>>>>>> JVM start-up to correct further instructions generation. >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8222825 >>>>>>>> http://cr.openjdk.java.net/~bulasevich/8222825/webrev.03.jdk-jdk >>>>>>>> >>>>>>>> thanks, >>>>>>>> Boris >>>>>> >>>>>> >>>>> >> From daniel.smith at oracle.com Fri May 17 16:00:25 2019 From: daniel.smith at oracle.com (Dan Smith) Date: Fri, 17 May 2019 10:00:25 -0600 Subject: 2019 JVM Language Summit In-Reply-To: References: Message-ID: Reminder: if you'd like to give a talk, please submit your proposal ASAP. Deadline is in one week. > On Apr 23, 2019, at 3:08 PM, Dan Smith wrote: > > CALL FOR SPEAKERS -- JVM LANGUAGE SUMMIT, JULY 29-31, 2019 > > We are pleased to announce the 2019 JVM Language Summit to be held at Oracle?s Santa Clara campus on July 29-31, 2019. Registration is now open for all attendees. Speaker submissions will be accepted through May 24. > > The JVM Language Summit is an open technical collaboration among language designers, compiler writers, tool builders, runtime engineers, and VM architects. We will share our experiences as creators of both the JVM and programming languages for the JVM. We also welcome non-JVM developers of similar technologies to attend or speak on their runtime, VM, or language of choice. > > Presentations will be recorded and made available to the public. > > This event is being organized by language and JVM engineers -- no marketers involved! So bring your slide rules and be prepared for some seriously geeky discussions. > > The Summit will be immediately followed by the OpenJDK Committers' Workshop, August 1-2. This year, the Workshop is a separate event with its own registration process. > > Please review additional details at http://jvmlangsummit.com. > > To register: > register.jvmlangsummit.com > > For further information: > jvmlangsummit.com > > Questions: > inquire2019 at jvmlangsummit.com > From dean.long at oracle.com Fri May 17 20:00:48 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 17 May 2019 13:00:48 -0700 Subject: PING: RFR(m): 8220762: Rework EventLog message string handling and provide VM.events command In-Reply-To: References: Message-ID: <1b6d54a4-1561-33a1-d9f7-1f54a952550c@oracle.com> Hi Thomas.? Have you considered breaking this up into three parts: variable-sized, jmd, and removing templates?? It seems like they can all be done independently. dl On 5/17/19 9:44 AM, Thomas St?fe wrote: > Hi all, > > This is a retry - I posted the original RFR in March but got no reaction so > far. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220762 > cr: > http://cr.openjdk.java.net/~stuefe/webrevs/8220762--rewrite-eventlog-system/webrev.00/webrev/ > > The Eventlog system keeps an array of events which almost completely > consist of variable sized string messages. > > The message buffer consists of fixed-sized records with a fixed-sized char > array for those messages. This is not a good fit. Mostly, those buffers are > too large and we waste space. Then, occasionally a message text is too > large and we truncate. To avoid truncation, stopgap solutions have been > added in the past (e.g. JDK-8204551) which would just increase the array > size, therefore avoiding truncation (for now) but increasing memory waste. > > A better solution would be to hold the strings in var-length buffers. We do > not want strdup since that is too expensive and events may be written in > situations where C heap is flaky. > > So we developed a solution where the strings live outside the event records > in a FIFO buffer of variable length strings - each string just uses exactly > as much memory as needed, and truncation is not a problem anymore. This > allows us also to increase the number of event records held. > > In addition, we added an explicit jcmd to display events (VM.events) - > right now the only way to display events is via hs-err file or VM.info, > which is really cumbersome. The command has a number of options, e.g. it > allows to filter for one log only or to show entries in reverse order. > > Example output of VM.events: > http://cr.openjdk.java.net/~stuefe/webrevs/8220762--rewrite-eventlog-system/vm.events-example-output.txt > > ------ > > Note that this is not a simple addition, but a rewrite (not a very big one, > the event log system is not huge). The coding complexity is simplified by > this patch which I think makes it more maintainable. I did this by > abandoning the templatized event record idea in favor of a simple record > structure. The old solution allowed event logs to define their own record > structure, but in practice this was a feature almost never used. So IMHO it > makes sense to un-templatize this and reap the benefits of much simpler > coding. > > If you guys think this is not a worthwhile contribution I'll stop hawking > it. But I think it makes sense. > > jdk-submit tests went through, and I saw no issues in our nightlies. > > Thanks & Best Regards, Thomas > > (Not sure which mailing lists this would go to - obviously hs-runtime, but > gc log and compiler log are affected too - feel free to redirect) From thomas.stuefe at gmail.com Sat May 18 05:41:52 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 18 May 2019 07:41:52 +0200 Subject: PING: RFR(m): 8220762: Rework EventLog message string handling and provide VM.events command In-Reply-To: <1b6d54a4-1561-33a1-d9f7-1f54a952550c@oracle.com> References: <1b6d54a4-1561-33a1-d9f7-1f54a952550c@oracle.com> Message-ID: Thank you Dean. I can easily remove the jcmd addition from the patch and do it later, but that would not really remove much since it is tiny. Splitting the var sized part from the code simplification will be more complicated. I have to think this through. Let?s first see if there is any interest in this improvement. Cheers, thomas On Fri 17. May 2019 at 22:00, wrote: > Hi Thomas. Have you considered breaking this up into three parts: > variable-sized, jmd, and removing templates? It seems like they can all > be done independently. > > dl > > > On 5/17/19 9:44 AM, Thomas St?fe wrote: > > Hi all, > > > > This is a retry - I posted the original RFR in March but got no reaction > so > > far. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220762 > > cr: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8220762--rewrite-eventlog-system/webrev.00/webrev/ > > > > The Eventlog system keeps an array of events which almost completely > > consist of variable sized string messages. > > > > The message buffer consists of fixed-sized records with a fixed-sized > char > > array for those messages. This is not a good fit. Mostly, those buffers > are > > too large and we waste space. Then, occasionally a message text is too > > large and we truncate. To avoid truncation, stopgap solutions have been > > added in the past (e.g. JDK-8204551) which would just increase the array > > size, therefore avoiding truncation (for now) but increasing memory > waste. > > > > A better solution would be to hold the strings in var-length buffers. We > do > > not want strdup since that is too expensive and events may be written in > > situations where C heap is flaky. > > > > So we developed a solution where the strings live outside the event > records > > in a FIFO buffer of variable length strings - each string just uses > exactly > > as much memory as needed, and truncation is not a problem anymore. This > > allows us also to increase the number of event records held. > > > > In addition, we added an explicit jcmd to display events (VM.events) - > > right now the only way to display events is via hs-err file or VM.info, > > which is really cumbersome. The command has a number of options, e.g. it > > allows to filter for one log only or to show entries in reverse order. > > > > Example output of VM.events: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8220762--rewrite-eventlog-system/vm.events-example-output.txt > > > > ------ > > > > Note that this is not a simple addition, but a rewrite (not a very big > one, > > the event log system is not huge). The coding complexity is simplified by > > this patch which I think makes it more maintainable. I did this by > > abandoning the templatized event record idea in favor of a simple record > > structure. The old solution allowed event logs to define their own record > > structure, but in practice this was a feature almost never used. So IMHO > it > > makes sense to un-templatize this and reap the benefits of much simpler > > coding. > > > > If you guys think this is not a worthwhile contribution I'll stop hawking > > it. But I think it makes sense. > > > > jdk-submit tests went through, and I saw no issues in our nightlies. > > > > Thanks & Best Regards, Thomas > > > > (Not sure which mailing lists this would go to - obviously hs-runtime, > but > > gc log and compiler log are affected too - feel free to redirect) > > From shade at redhat.com Sat May 18 10:44:48 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Sat, 18 May 2019 12:44:48 +0200 Subject: RFR (XS) 8224170: Build failures after JDK-8207812 (Implement Dynamic CDS Archive) Message-ID: <927a44c0-f401-5da0-e517-ad02e886c004@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8224170 Bad format specifier for size_t blows up on x86_32 (and I imagine on other 32-bit platforms). Fix: diff -r 13507abf416c -r b2273edd75aa src/hotspot/share/memory/dynamicArchive.cpp --- a/src/hotspot/share/memory/dynamicArchive.cpp Sat May 18 15:42:21 2019 +0900 +++ b/src/hotspot/share/memory/dynamicArchive.cpp Sat May 18 12:43:09 2019 +0200 @@ -511,7 +511,7 @@ size_t used = size_t(top - bottom) + _other_region_used_bytes; int diff = int(estimate) - int(used); - log_info(cds)("%s estimate = %lu used = %lu; diff = %d bytes", which, estimate, used, diff); + log_info(cds)("%s estimate = " SIZE_FORMAT " used = " SIZE_FORMAT "; diff = %d bytes", which, estimate, used, diff); assert(diff >= 0, "Estimate is too small"); _last_verified_top = top; Testing: Linux x86_64, x86_32 builds; Linux x86_32 tier1 -- Thanks, -Aleksey From thomas.stuefe at gmail.com Sat May 18 11:12:06 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 18 May 2019 13:12:06 +0200 Subject: RFR (XS) 8224170: Build failures after JDK-8207812 (Implement Dynamic CDS Archive) In-Reply-To: <927a44c0-f401-5da0-e517-ad02e886c004@redhat.com> References: <927a44c0-f401-5da0-e517-ad02e886c004@redhat.com> Message-ID: Looks fine and trivial. .. Thomas On Sat, May 18, 2019, 12:45 Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8224170 > > Bad format specifier for size_t blows up on x86_32 (and I imagine on other > 32-bit platforms). > > Fix: > > diff -r 13507abf416c -r b2273edd75aa > src/hotspot/share/memory/dynamicArchive.cpp > --- a/src/hotspot/share/memory/dynamicArchive.cpp Sat May 18 > 15:42:21 2019 +0900 > +++ b/src/hotspot/share/memory/dynamicArchive.cpp Sat May 18 > 12:43:09 2019 +0200 > @@ -511,7 +511,7 @@ > size_t used = size_t(top - bottom) + _other_region_used_bytes; > int diff = int(estimate) - int(used); > > - log_info(cds)("%s estimate = %lu used = %lu; diff = %d bytes", which, > estimate, used, diff); > + log_info(cds)("%s estimate = " SIZE_FORMAT " used = " SIZE_FORMAT "; > diff = %d bytes", which, > estimate, used, diff); > assert(diff >= 0, "Estimate is too small"); > > _last_verified_top = top; > > Testing: Linux x86_64, x86_32 builds; Linux x86_32 tier1 > > -- > Thanks, > -Aleksey > > From vladimir.kozlov at oracle.com Sat May 18 16:32:55 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 18 May 2019 09:32:55 -0700 Subject: RFR (XS) 8224170: Build failures after JDK-8207812 (Implement Dynamic CDS Archive) In-Reply-To: <927a44c0-f401-5da0-e517-ad02e886c004@redhat.com> References: <927a44c0-f401-5da0-e517-ad02e886c004@redhat.com> Message-ID: <4542a740-2d02-eac9-9a54-890f7bc1c3c7@oracle.com> Good. Should we also fix next line?: int diff = int(estimate) - int(used); as int diff = int(estimate - used); Thanks, Vladimir On 5/18/19 3:44 AM, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8224170 > > Bad format specifier for size_t blows up on x86_32 (and I imagine on other 32-bit platforms). > > Fix: > > diff -r 13507abf416c -r b2273edd75aa src/hotspot/share/memory/dynamicArchive.cpp > --- a/src/hotspot/share/memory/dynamicArchive.cpp Sat May 18 15:42:21 2019 +0900 > +++ b/src/hotspot/share/memory/dynamicArchive.cpp Sat May 18 12:43:09 2019 +0200 > @@ -511,7 +511,7 @@ > size_t used = size_t(top - bottom) + _other_region_used_bytes; > int diff = int(estimate) - int(used); > > - log_info(cds)("%s estimate = %lu used = %lu; diff = %d bytes", which, estimate, used, diff); > + log_info(cds)("%s estimate = " SIZE_FORMAT " used = " SIZE_FORMAT "; diff = %d bytes", which, > estimate, used, diff); > assert(diff >= 0, "Estimate is too small"); > > _last_verified_top = top; > > Testing: Linux x86_64, x86_32 builds; Linux x86_32 tier1 > From shade at redhat.com Sat May 18 16:48:38 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Sat, 18 May 2019 18:48:38 +0200 Subject: RFR (XS) 8224170: Build failures after JDK-8207812 (Implement Dynamic CDS Archive) In-Reply-To: <4542a740-2d02-eac9-9a54-890f7bc1c3c7@oracle.com> References: <927a44c0-f401-5da0-e517-ad02e886c004@redhat.com> <4542a740-2d02-eac9-9a54-890f7bc1c3c7@oracle.com> Message-ID: On 5/18/19 6:32 PM, Vladimir Kozlov wrote: > Good. Thanks, I am going to push this under triviality rules. > Should we also fix next line?: > > int diff = int(estimate) - int(used); > > as > > int diff = int(estimate - used); I think this would be incorrect: size_t underflow if "estimate < used"? I'd rather make such a change in a in follow up (and well-tested) patch. -Aleksey From vladimir.kozlov at oracle.com Sat May 18 18:45:02 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 18 May 2019 11:45:02 -0700 Subject: RFR (XS) 8224170: Build failures after JDK-8207812 (Implement Dynamic CDS Archive) In-Reply-To: References: <927a44c0-f401-5da0-e517-ad02e886c004@redhat.com> <4542a740-2d02-eac9-9a54-890f7bc1c3c7@oracle.com> Message-ID: Okay. Thanks Vladimir > On May 18, 2019, at 9:48 AM, Aleksey Shipilev wrote: > >> On 5/18/19 6:32 PM, Vladimir Kozlov wrote: >> Good. > > Thanks, I am going to push this under triviality rules. > >> Should we also fix next line?: >> >> int diff = int(estimate) - int(used); >> >> as >> >> int diff = int(estimate - used); > > I think this would be incorrect: size_t underflow if "estimate < used"? I'd rather make such a > change in a in follow up (and well-tested) patch. > > -Aleksey > From yumin.qi at gmail.com Sun May 19 17:28:43 2019 From: yumin.qi at gmail.com (yumin qi) Date: Sun, 19 May 2019 10:28:43 -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, 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 stefan.karlsson at oracle.com Mon May 20 10:56:16 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 20 May 2019 12:56:16 +0200 Subject: RFR: 8224201: Simplify JVM flag macro expansions Message-ID: Hi all, Please review this patch to simplify how we generate the different parts of the JVM flags code. https://cr.openjdk.java.net/~stefank/8224201/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8224201 Notable parts of the patch: - Introduces a ALL_FLAGS macro, used to expand code for all flags. - Uses the ALL_FLAGS where appropriate. - Constraints list didn't expand JVMCI flags. Fixed by using ALL_FLAGS. - Moved _globals.hpp generated declarations to be expanded in globals.hpp. - Unified FLAG_MEMBER and FLAG_MEMBER_WITH_TYPE into FLAG_MEMBER_ENUM and change names accordingly. This change makes it easier to do future changes to the JVM flags handling code. For example: "JDK-8224203Remove need to specify type when using FLAG_SET macros" Compiled on tier1 platforms. Thanks, StefanK From stefan.karlsson at oracle.com Mon May 20 11:12:07 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 20 May 2019 13:12:07 +0200 Subject: RFR: 8224203: Remove need to specify type when using FLAG_SET macros Message-ID: Hi all, Please review this patch to remove the need to specify type when using the FLAG_SET macros. https://cr.openjdk.java.net/~stefank/8224203/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8224203 This patch builds on top of the changes in: ?"8224201: Simplify JVM flag macro expansions" ?https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-May/038184.html global_extensions.hpp contains the actual change to JVM flag setters. It expands one inline function per flag. For example: inline JVMFlag::Error Flag_G1HeapRegionSize_set(size_t value, JVMFlag::Flags origin) { ?? return JVMFlagEx::size_tAtPut(Flag_G1HeapRegionSize_enum, value, origin); } The rest of the files contain removal of the type arguments. For example: -??? FLAG_SET_ERGO(size_t, G1HeapRegionSize, GrainBytes); +??? FLAG_SET_ERGO(G1HeapRegionSize, GrainBytes); Compiles on all tier1 platforms. Thanks, StefanK From matthias.baesken at sap.com Mon May 20 15:08:19 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 20 May 2019 15:08:19 +0000 Subject: RFR: 8224221: add memprotect calls to event log Message-ID: Hello, please review this small changeset . 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 memory protection events to the current set or events added by calling Events::log . (we had this for a long time in our proprietary VM and would like to have it in Open JDK too ) Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8224221 http://cr.openjdk.java.net/~mbaesken/webrevs/8224221.0/ Thanks, Matthias From robbin.ehn at oracle.com Mon May 20 17:53:39 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 20 May 2019 19:53:39 +0200 Subject: RFR: 8224201: Simplify JVM flag macro expansions In-Reply-To: References: Message-ID: Hi Stefan, Thanks for fixing! /Robbin On 2019-05-20 12:56, Stefan Karlsson wrote: > Hi all, > > Please review this patch to simplify how we generate the different parts of the > JVM flags code. > > https://cr.openjdk.java.net/~stefank/8224201/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8224201 > > Notable parts of the patch: > - Introduces a ALL_FLAGS macro, used to expand code for all flags. > - Uses the ALL_FLAGS where appropriate. > - Constraints list didn't expand JVMCI flags. Fixed by using ALL_FLAGS. > - Moved _globals.hpp generated declarations to be expanded in > globals.hpp. > - Unified FLAG_MEMBER and FLAG_MEMBER_WITH_TYPE into FLAG_MEMBER_ENUM and change > names accordingly. > > This change makes it easier to do future changes to the JVM flags handling code. > For example: "JDK-8224203Remove need to specify type when using FLAG_SET macros" > > Compiled on tier1 platforms. > > Thanks, > StefanK > From robbin.ehn at oracle.com Mon May 20 17:54:08 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 20 May 2019 19:54:08 +0200 Subject: RFR: 8224203: Remove need to specify type when using FLAG_SET macros In-Reply-To: References: Message-ID: <65036072-7312-8474-3d6e-46d39cba94f3@oracle.com> Hi Stefan, Thanks for fixing this also! /Robbin On 2019-05-20 13:12, Stefan Karlsson wrote: > Hi all, > > Please review this patch to remove the need to specify type when using the > FLAG_SET macros. > > https://cr.openjdk.java.net/~stefank/8224203/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8224203 > > This patch builds on top of the changes in: > ?"8224201: Simplify JVM flag macro expansions" > ?https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-May/038184.html > > global_extensions.hpp contains the actual change to JVM flag setters. It expands > one inline function per flag. For example: > inline JVMFlag::Error Flag_G1HeapRegionSize_set(size_t value, JVMFlag::Flags > origin) { > ?? return JVMFlagEx::size_tAtPut(Flag_G1HeapRegionSize_enum, value, origin); > } > > The rest of the files contain removal of the type arguments. > > For example: > -??? FLAG_SET_ERGO(size_t, G1HeapRegionSize, GrainBytes); > +??? FLAG_SET_ERGO(G1HeapRegionSize, GrainBytes); > > Compiles on all tier1 platforms. > > Thanks, > StefanK From rahul.v.raghavan at oracle.com Mon May 20 18:16:10 2019 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Mon, 20 May 2019 23:46:10 +0530 Subject: [13] RFR: 8213416: Replace some enums with static const members in hotspot/compiler In-Reply-To: <62869e18-3deb-435d-1ce8-7726866d79eb@oracle.com> References: <1f7afc19-0756-33f8-54f5-2438ed5da886@oracle.com> <8f18e15d-cae8-58eb-b4a1-870ca6ffaf15@oracle.com> <62869e18-3deb-435d-1ce8-7726866d79eb@oracle.com> Message-ID: <8b22fc8b-af06-31a2-4033-4984ac4fcb5d@oracle.com> Hi, With reference to below email thread, request help to confirm next steps for JDK-8213416. So may I go ahead with webrev changes related to hotspot/compiler for 8213416 ? - http://cr.openjdk.java.net/~rraghavan/8213416/webrev.01/ (also will add similar hotspot/runtime related details in JBS comments for JDK-8223400) Thanks, Rahul On 16/05/19 3:26 PM, Rahul Raghavan wrote:> Hi, > > Thank you David for review comments. > > I will kindly request help from Magnus to reply for the main questions. > > > Sharing some notes, related links - > - 8211073: Remove -Wno-extra from Hotspot > https://bugs.openjdk.java.net/browse/JDK-8211073 > - Discussions in earlier thread - > https://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034314.html > > > So understood -Wextra do help in catching valid/useful warnings also, > but along with some too strict ones like "enumeral and non-enumeral type > in conditional expression" type warnings. > > Extracts from 8211073 JBS comments from Magnus regarding the > 'enum-warning' - > "... If you think that gcc is a bit too picky here, I agree. It's not > obvious per se that the added casts improve the code. However, this is > the price we need to pay to be able to enable -Wextra, and *that* is > something that is likely to improve the code." > > > Thanks, > Rahul > > On 16/05/19 11:13 AM, David Holmes wrote: >> This all seems like unnecessary churn to me - is any of this code >> actually wrong? can we not just disable this particular warning? is >> there any point using "static const" when we should be aiming to use >> C++11 constexpr in the (not too distant?) future? >> >> Converting from enums to unrelated ints seems a big step backwards in >> software engineering terms. :( >> >> Cheers, >> David >> ----- >> On 16/05/19 12:03 PM, Rahul Raghavan wrote: > Hi, > > Thank you Vladimir for review comments. > >>> 4) _lh_array_tag_obj_value, _lh_instance_slow_path_bit - >>> [open/src/hotspot/share/oops/klass.cpp] >>> .......... >> >> I am okay with it but Runtime group should agree too - it is their code. >> > Yes, I missed that it is Runtime code. > > Please note plan is to handle only the hotspot/compiler part of the > requirement changes in JDK-8213416. > As per earlier JBS comments new JDK-8223400 was created to cover the > requirements in hotspot/runtime. > So may I suggest moving the above runtime change requirement details to > JDK-822340; > and use only the balance changes, as in below updated webrev, here for > 8213416. > > - http://cr.openjdk.java.net/~rraghavan/8213416/webrev.01/ > > > Thanks, > Rahul From vladimir.kozlov at oracle.com Tue May 21 00:43:08 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 20 May 2019 17:43:08 -0700 Subject: RFR: 8224201: Simplify JVM flag macro expansions In-Reply-To: References: Message-ID: <547d84ea-0e48-2a22-cd08-1d0c13cc8abe@oracle.com> Very nice clean up. Thanks, Vladimir PS: I assume tier1 build without PCH. On 5/20/19 3:56 AM, Stefan Karlsson wrote: > Hi all, > > Please review this patch to simplify how we generate the different parts of the JVM flags code. > > https://cr.openjdk.java.net/~stefank/8224201/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8224201 > > Notable parts of the patch: > - Introduces a ALL_FLAGS macro, used to expand code for all flags. > - Uses the ALL_FLAGS where appropriate. > - Constraints list didn't expand JVMCI flags. Fixed by using ALL_FLAGS. > - Moved _globals.hpp generated declarations to be expanded in globals.hpp. > - Unified FLAG_MEMBER and FLAG_MEMBER_WITH_TYPE into FLAG_MEMBER_ENUM and change names accordingly. > > This change makes it easier to do future changes to the JVM flags handling code. For example: "JDK-8224203Remove need to > specify type when using FLAG_SET macros" > > Compiled on tier1 platforms. > > Thanks, > StefanK > From thomas.stuefe at gmail.com Tue May 21 04:47:36 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 21 May 2019 06:47:36 +0200 Subject: RFR: 8224201: Simplify JVM flag macro expansions In-Reply-To: References: Message-ID: Hi Stefan, this is a nice cleanup! Looks good to my naked eye. I would probably compare a precompiled globals.cpp from before your patch and after it and check the diffs. Non-PCH builds too, as Vladimir suggested. Maybe also with some features switched off, e.g. jvmci. If all tests well I do not need another webrev. Cheers, Thomas On Mon, May 20, 2019 at 12:56 PM Stefan Karlsson wrote: > Hi all, > > Please review this patch to simplify how we generate the different parts > of the JVM flags code. > > https://cr.openjdk.java.net/~stefank/8224201/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8224201 > > Notable parts of the patch: > - Introduces a ALL_FLAGS macro, used to expand code for all flags. > - Uses the ALL_FLAGS where appropriate. > - Constraints list didn't expand JVMCI flags. Fixed by using ALL_FLAGS. > - Moved _globals.hpp generated declarations to be expanded > in globals.hpp. > - Unified FLAG_MEMBER and FLAG_MEMBER_WITH_TYPE into FLAG_MEMBER_ENUM > and change names accordingly. > > This change makes it easier to do future changes to the JVM flags > handling code. For example: "JDK-8224203Remove need to specify type when > using FLAG_SET macros" > > Compiled on tier1 platforms. > > Thanks, > StefanK > > From david.holmes at oracle.com Tue May 21 05:26:50 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 May 2019 15:26:50 +1000 Subject: RFR: 8224221: add memprotect calls to event log In-Reply-To: References: Message-ID: <7cf56a2b-5da9-d351-3590-ad9114446b7c@oracle.com> Hi Matthias, On 21/05/2019 1:08 am, Baesken, Matthias wrote: > Hello, please review this small changeset . > > 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 memory protection events to the current set or events added by calling Events::log . > (we had this for a long time in our proprietary VM and would like to have it in Open JDK too ) So extra events will now be generated so you doubled the size of the buffer - any info on how this impacts the events that may get captured? How often do mprotect events happen? Might we always see 20 mprotect events and nothing else of interest? Just wondering (I never use this event stuff myself). > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8224221 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224221.0/ Nit: "with protections %d" doesn't read right to me as "protection" is not a noun. How about "with protection modes %d" or "with protection bits %d"? (It would be nice if you could print a symbolic representation of the bits rather than just the raw value - and %x may be better than %d for the raw value.) --- src/hotspot/os/bsd/os_bsd.cpp The log event should be using bottom and bottom+size for its range. You didn't log these additional ::mprotect calls: 1936 if (::mprotect(addr, size, prot) == 0) { 2020 return ::mprotect(addr, size, PROT_NONE) == 0; --- src/hotspot/os/linux/os_linux.cpp The log event should be using bottom and bottom+size for its range. --- src/hotspot/os/solaris/os_solaris.cpp There is no "size" variable, it's called "bytes". It's odd that the Solaris polling_page routines call mprotect directly rather than solaris_mprotect. That gave you the opportunity to be more specific about logging those events on Solaris, but the other platforms miss out. Overall the use of mprotect/_mprotect/guard_memory is a bit of a mess. :( --- src/hotspot/share/runtime/thread.cpp jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) { + eventlog_init(); You've made eventlog_init() the very first thing we now do in VM initialization which raises a number of issues for me: - is everything it does actually safe to do with ZERO other VM initialization having occurred? I don't see how as it uses a Mutex when constructing EventLogBase and mutex initialization has not yet occurred! - we will always initialize the Event logs because we won't yet have processed the parameters that may turn of LogEvents. I think the initialization placement needs re-examination. When does the first mprotect call occur? I'd take a guess it would be for the guard pages of the main thread when it attaches. Thanks, David ---- > > Thanks, Matthias > From stefan.karlsson at oracle.com Tue May 21 08:48:16 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 21 May 2019 10:48:16 +0200 Subject: RFR: 8224201: Simplify JVM flag macro expansions In-Reply-To: References: Message-ID: Hi Robbin, Thanks for taking a look at this. Can I consider this reviewed by you? StefanK On 2019-05-20 19:53, Robbin Ehn wrote: > Hi Stefan, > > Thanks for fixing! > > /Robbin > > On 2019-05-20 12:56, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to simplify how we generate the different >> parts of the JVM flags code. >> >> https://cr.openjdk.java.net/~stefank/8224201/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8224201 >> >> Notable parts of the patch: >> - Introduces a ALL_FLAGS macro, used to expand code for all flags. >> - Uses the ALL_FLAGS where appropriate. >> - Constraints list didn't expand JVMCI flags. Fixed by using ALL_FLAGS. >> - Moved _globals.hpp generated declarations to be expanded >> in globals.hpp. >> - Unified FLAG_MEMBER and FLAG_MEMBER_WITH_TYPE into FLAG_MEMBER_ENUM >> and change names accordingly. >> >> This change makes it easier to do future changes to the JVM flags >> handling code. For example: "JDK-8224203Remove need to specify type >> when using FLAG_SET macros" >> >> Compiled on tier1 platforms. >> >> Thanks, >> StefanK >> From robbin.ehn at oracle.com Tue May 21 08:52:45 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 21 May 2019 10:52:45 +0200 Subject: RFR: 8224201: Simplify JVM flag macro expansions In-Reply-To: References: Message-ID: <44025e71-a50e-62d4-8c53-c65a4bfc280f@oracle.com> Yes and the follow-up, 8224203! /Robbin On 2019-05-21 10:48, Stefan Karlsson wrote: > Hi Robbin, > > Thanks for taking a look at this. Can I consider this reviewed by you? > > StefanK > > On 2019-05-20 19:53, Robbin Ehn wrote: >> Hi Stefan, >> >> Thanks for fixing! >> >> /Robbin >> >> On 2019-05-20 12:56, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review this patch to simplify how we generate the different parts of >>> the JVM flags code. >>> >>> https://cr.openjdk.java.net/~stefank/8224201/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8224201 >>> >>> Notable parts of the patch: >>> - Introduces a ALL_FLAGS macro, used to expand code for all flags. >>> - Uses the ALL_FLAGS where appropriate. >>> - Constraints list didn't expand JVMCI flags. Fixed by using ALL_FLAGS. >>> - Moved _globals.hpp generated declarations to be expanded in >>> globals.hpp. >>> - Unified FLAG_MEMBER and FLAG_MEMBER_WITH_TYPE into FLAG_MEMBER_ENUM and >>> change names accordingly. >>> >>> This change makes it easier to do future changes to the JVM flags handling >>> code. For example: "JDK-8224203Remove need to specify type when using >>> FLAG_SET macros" >>> >>> Compiled on tier1 platforms. >>> >>> Thanks, >>> StefanK >>> From stefan.karlsson at oracle.com Tue May 21 09:20:28 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 21 May 2019 11:20:28 +0200 Subject: RFR: 8224201: Simplify JVM flag macro expansions In-Reply-To: References: Message-ID: Hi Thomas, On 2019-05-21 06:47, Thomas St?fe wrote: > Hi Stefan, > > this is a nice cleanup! Thanks! > > Looks good to my naked eye. > > I would probably compare a precompiled globals.cpp from before your > patch and after it and check the diffs. I assume that you meant preprocessed and not precompiled here. I compared the the output from gcc -E, and the difference I see is the expected move of the JVMCI flag definitions. > > Non-PCH builds too, as Vladimir suggested. I always run with non-PCH locally, but our build infrastructure uses PCH by default. I reran with non-PCH and found no problems. Maybe also with some features > switched off, e.g. jvmci. Tested building with -jvmci locally, and it worked. I checked the gcc -E output for globals.cpp, and the JVMCI flags are removed as expected. I tried to build without COMPILER2, but that is broken even without my patches. > > If all tests well I do not need another webrev. Thanks! StefanK > > Cheers, Thomas > > On Mon, May 20, 2019 at 12:56 PM Stefan Karlsson > > wrote: > > Hi all, > > Please review this patch to simplify how we generate the different > parts > of the JVM flags code. > > https://cr.openjdk.java.net/~stefank/8224201/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8224201 > > Notable parts of the patch: > - Introduces a ALL_FLAGS macro, used to expand code for all flags. > - Uses the ALL_FLAGS where appropriate. > - Constraints list didn't expand JVMCI flags. Fixed by using ALL_FLAGS. > - Moved _globals.hpp generated declarations to be expanded > in globals.hpp. > - Unified FLAG_MEMBER and FLAG_MEMBER_WITH_TYPE into FLAG_MEMBER_ENUM > and change names accordingly. > > This change makes it easier to do future changes to the JVM flags > handling code. For example: "JDK-8224203Remove need to specify type > when > using FLAG_SET macros" > > Compiled on tier1 platforms. > > Thanks, > StefanK > From stefan.karlsson at oracle.com Tue May 21 09:18:47 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 21 May 2019 11:18:47 +0200 Subject: RFR: 8224201: Simplify JVM flag macro expansions In-Reply-To: <547d84ea-0e48-2a22-cd08-1d0c13cc8abe@oracle.com> References: <547d84ea-0e48-2a22-cd08-1d0c13cc8abe@oracle.com> Message-ID: <4a3d0459-004e-5e7b-686b-cb99d5ffa5ee@oracle.com> Thanks for reviewing! I reran tier1 builds without PCH and encountered no problems. StefanK On 2019-05-21 02:43, Vladimir Kozlov wrote: > Very nice clean up. > > Thanks, > Vladimir > > PS: I assume tier1 build without PCH. > > On 5/20/19 3:56 AM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to simplify how we generate the different >> parts of the JVM flags code. >> >> https://cr.openjdk.java.net/~stefank/8224201/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8224201 >> >> Notable parts of the patch: >> - Introduces a ALL_FLAGS macro, used to expand code for all flags. >> - Uses the ALL_FLAGS where appropriate. >> - Constraints list didn't expand JVMCI flags. Fixed by using ALL_FLAGS. >> - Moved _globals.hpp generated declarations to be expanded >> in globals.hpp. >> - Unified FLAG_MEMBER and FLAG_MEMBER_WITH_TYPE into FLAG_MEMBER_ENUM >> and change names accordingly. >> >> This change makes it easier to do future changes to the JVM flags >> handling code. For example: "JDK-8224203Remove need to specify type >> when using FLAG_SET macros" >> >> Compiled on tier1 platforms. >> >> Thanks, >> StefanK >> From stefan.karlsson at oracle.com Tue May 21 09:21:05 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 21 May 2019 11:21:05 +0200 Subject: RFR: 8224203: Remove need to specify type when using FLAG_SET macros In-Reply-To: <65036072-7312-8474-3d6e-46d39cba94f3@oracle.com> References: <65036072-7312-8474-3d6e-46d39cba94f3@oracle.com> Message-ID: Thanks for reviewing! StefanK On 2019-05-20 19:54, Robbin Ehn wrote: > Hi Stefan, > > Thanks for fixing this also! > > /Robbin > > On 2019-05-20 13:12, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to remove the need to specify type when using >> the FLAG_SET macros. >> >> https://cr.openjdk.java.net/~stefank/8224203/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8224203 >> >> This patch builds on top of the changes in: >> ??"8224201: Simplify JVM flag macro expansions" >> ??https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-May/038184.html >> >> >> global_extensions.hpp contains the actual change to JVM flag setters. >> It expands one inline function per flag. For example: >> inline JVMFlag::Error Flag_G1HeapRegionSize_set(size_t value, >> JVMFlag::Flags origin) { >> ??? return JVMFlagEx::size_tAtPut(Flag_G1HeapRegionSize_enum, value, >> origin); >> } >> >> The rest of the files contain removal of the type arguments. >> >> For example: >> -??? FLAG_SET_ERGO(size_t, G1HeapRegionSize, GrainBytes); >> +??? FLAG_SET_ERGO(G1HeapRegionSize, GrainBytes); >> >> Compiles on all tier1 platforms. >> >> Thanks, >> StefanK From thomas.stuefe at gmail.com Tue May 21 09:22:24 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 21 May 2019 11:22:24 +0200 Subject: RFR: 8224201: Simplify JVM flag macro expansions In-Reply-To: References: Message-ID: Hi Stefan, On Tue, May 21, 2019 at 11:20 AM Stefan Karlsson wrote: > Hi Thomas, > > > > I would probably compare a precompiled globals.cpp from before your > > patch and after it and check the diffs. > > I assume that you meant preprocessed and not precompiled here. I > compared the the output from gcc -E, and the difference I see is the > expected move of the JVMCI flag definitions. > Yes, that is what I meant, sorry for the confusion, and thanks for checking. Cheers, Thomas > > From thomas.schatzl at oracle.com Tue May 21 10:41:40 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 21 May 2019 12:41:40 +0200 Subject: RFR: 8224201: Simplify JVM flag macro expansions In-Reply-To: References: Message-ID: Hi, On Mon, 2019-05-20 at 12:56 +0200, Stefan Karlsson wrote: > Hi all, > > Please review this patch to simplify how we generate the different > parts of the JVM flags code. > > https://cr.openjdk.java.net/~stefank/8224201/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8224201 > > Notable parts of the patch: > - Introduces a ALL_FLAGS macro, used to expand code for all flags. > - Uses the ALL_FLAGS where appropriate. > - Constraints list didn't expand JVMCI flags. Fixed by using > ALL_FLAGS. > - Moved _globals.hpp generated declarations to be > expanded > in globals.hpp. > - Unified FLAG_MEMBER and FLAG_MEMBER_WITH_TYPE into > FLAG_MEMBER_ENUM > and change names accordingly. > > This change makes it easier to do future changes to the JVM flags > handling code. For example: "JDK-8224203Remove need to specify type > when using FLAG_SET macros" although I saw that you already have quite a few reviewers after working through it: looks good. Very nice cleanup. Thanks, Thomas From stefan.karlsson at oracle.com Tue May 21 11:05:46 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 21 May 2019 13:05:46 +0200 Subject: RFR: 8224201: Simplify JVM flag macro expansions In-Reply-To: References: Message-ID: <127819f3-1e67-128b-fc7f-9d199bcb594d@oracle.com> Thanks for the review, Thomas. StefanK On 2019-05-21 12:41, Thomas Schatzl wrote: > Hi, > > On Mon, 2019-05-20 at 12:56 +0200, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to simplify how we generate the different >> parts of the JVM flags code. >> >> https://cr.openjdk.java.net/~stefank/8224201/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8224201 >> >> Notable parts of the patch: >> - Introduces a ALL_FLAGS macro, used to expand code for all flags. >> - Uses the ALL_FLAGS where appropriate. >> - Constraints list didn't expand JVMCI flags. Fixed by using >> ALL_FLAGS. >> - Moved _globals.hpp generated declarations to be >> expanded >> in globals.hpp. >> - Unified FLAG_MEMBER and FLAG_MEMBER_WITH_TYPE into >> FLAG_MEMBER_ENUM >> and change names accordingly. >> >> This change makes it easier to do future changes to the JVM flags >> handling code. For example: "JDK-8224203Remove need to specify type >> when using FLAG_SET macros" > > although I saw that you already have quite a few reviewers after > working through it: looks good. Very nice cleanup. > > Thanks, > Thomas > > From matthias.baesken at sap.com Tue May 21 11:24:05 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 21 May 2019 11:24:05 +0000 Subject: RFR: 8224221: add memprotect calls to event log In-Reply-To: <7cf56a2b-5da9-d351-3590-ad9114446b7c@oracle.com> References: <7cf56a2b-5da9-d351-3590-ad9114446b7c@oracle.com> Message-ID: Hello David, thanks for your comments. I see no "flooding" of the event log, of course a few more events occur but not just mprotect events are seen . Example : Events (20 events): Event: 0.289 Thread 0x00007fdb501c4800 Thread added: 0x00007fdb501c4800 Event: 0.289 Protecting memory [0x00007fdb4f0ba000,0x00007fdb4f0be000] with protection modes 0 Event: 0.290 Executing VM operation: EnableBiasedLocking Event: 0.291 Executing VM operation: EnableBiasedLocking done Event: 0.291 loading class jdk/internal/vm/PostVMInitHook Event: 0.291 loading class jdk/internal/vm/PostVMInitHook done Event: 0.298 loading class Loop Event: 0.298 loading class Loop done Event: 0.303 loading class jdk/internal/loader/URLClassPath$FileLoader Event: 0.303 loading class jdk/internal/loader/URLClassPath$FileLoader done Event: 0.307 loading class jdk/internal/loader/URLClassPath$FileLoader$1 Event: 0.308 loading class jdk/internal/loader/URLClassPath$FileLoader$1 done Event: 0.314 Thread 0x00007fdb501ce000 Thread added: 0x00007fdb501ce000 Event: 0.314 Protecting memory [0x00007fdb4eeb8000,0x00007fdb4eebc000] with protection modes 0 Event: 0.315 Executing VM operation: RevokeBias Event: 0.315 Executing VM operation: RevokeBias done Event: 5.357 Thread 0x0000000000a05000 Thread exited: 0x0000000000a05000 Event: 10.357 Thread 0x000000000094b000 Thread exited: 0x000000000094b000 Event: 97.213 Thread 0x000000000094b000 Thread added: 0x000000000094b000 Event: 97.213 Protecting memory [0x00007fdb4f2bc000,0x00007fdb4f2c0000] with protection modes 0 Regarding the event init - routines : I had a bit of trouble with the order of inits + usages , so I changed back to the original coding ; then I had to add checks to events.hpp / cpp so that I do not log to a yet uninitialized event infrastructure in early startup but I think the added checks are good to have . I adjusted the "small nit" regarding output - good point . Regarding the missing logs in os_bsd.cpp you mentioned : I think they are bsd only and I have no machine here to test - should I still add them and hope that it works ? Fixed the solaris issue. New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8224221.2/ Best regards, Matthias > > On 21/05/2019 1:08 am, Baesken, Matthias wrote: > > Hello, please review this small changeset . > > > > 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 memory protection events to the current set or events > added by calling Events::log . > > (we had this for a long time in our proprietary VM and would like to have > it in Open JDK too ) > > So extra events will now be generated so you doubled the size of the > buffer - any info on how this impacts the events that may get captured? > How often do mprotect events happen? Might we always see 20 mprotect > events and nothing else of interest? Just wondering (I never use this > event stuff myself). > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8224221 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224221.0/ > > Nit: "with protections %d" doesn't read right to me as "protection" is > not a noun. How about "with protection modes %d" or "with protection > bits %d"? (It would be nice if you could print a symbolic representation > of the bits rather than just the raw value - and %x may be better than > %d for the raw value.) > > --- > > src/hotspot/os/bsd/os_bsd.cpp > > The log event should be using bottom and bottom+size for its range. > > You didn't log these additional ::mprotect calls: > > 1936 if (::mprotect(addr, size, prot) == 0) { > 2020 return ::mprotect(addr, size, PROT_NONE) == 0; > > --- > > src/hotspot/os/linux/os_linux.cpp > > The log event should be using bottom and bottom+size for its range. > > --- > > src/hotspot/os/solaris/os_solaris.cpp > > There is no "size" variable, it's called "bytes". > > It's odd that the Solaris polling_page routines call mprotect directly > rather than solaris_mprotect. That gave you the opportunity to be more > specific about logging those events on Solaris, but the other platforms > miss out. Overall the use of mprotect/_mprotect/guard_memory is a > bit of a mess. :( > > --- > > src/hotspot/share/runtime/thread.cpp > > jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) { > + eventlog_init(); > > You've made eventlog_init() the very first thing we now do in VM > initialization which raises a number of issues for me: > > - is everything it does actually safe to do with ZERO other VM > initialization having occurred? I don't see how as it uses a Mutex when > constructing EventLogBase and mutex initialization has not yet occurred! > > - we will always initialize the Event logs because we won't yet have > processed the parameters that may turn of LogEvents. > > I think the initialization placement needs re-examination. When does the > first mprotect call occur? I'd take a guess it would be for the guard > pages of the main thread when it attaches. > From coleen.phillimore at oracle.com Tue May 21 12:02:11 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 21 May 2019 08:02:11 -0400 Subject: RFR: 8224201: Simplify JVM flag macro expansions In-Reply-To: <127819f3-1e67-128b-fc7f-9d199bcb594d@oracle.com> References: <127819f3-1e67-128b-fc7f-9d199bcb594d@oracle.com> Message-ID: <11d88ab3-5b95-7dcc-74ea-2573d3ccd6d9@oracle.com> I didn't do a full review, but do we still need globals_ext.hpp ? Can this set of macros for ALL_FLAGS be put in globals_shared.hpp also??? It would be nice for globals.hpp to be mostly the flag list rather than seeing these macros. I think we can still build aarch64 and zero locally. thanks, Coleen On 5/21/19 7:05 AM, Stefan Karlsson wrote: > Thanks for the review, Thomas. > > StefanK > > On 2019-05-21 12:41, Thomas Schatzl wrote: >> Hi, >> >> On Mon, 2019-05-20 at 12:56 +0200, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review this patch to simplify how we generate the different >>> parts of the JVM flags code. >>> >>> https://cr.openjdk.java.net/~stefank/8224201/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8224201 >>> >>> Notable parts of the patch: >>> - Introduces a ALL_FLAGS macro, used to expand code for all flags. >>> - Uses the ALL_FLAGS where appropriate. >>> - Constraints list didn't expand JVMCI flags. Fixed by using >>> ALL_FLAGS. >>> - Moved _globals.hpp generated declarations to be >>> expanded >>> in globals.hpp. >>> - Unified FLAG_MEMBER and FLAG_MEMBER_WITH_TYPE into >>> FLAG_MEMBER_ENUM >>> and change names accordingly. >>> >>> This change makes it easier to do future changes to the JVM flags >>> handling code. For example: "JDK-8224203Remove need to specify type >>> when using FLAG_SET macros" >> >> ?? although I saw that you already have quite a few reviewers after >> working through it: looks good. Very nice cleanup. >> >> Thanks, >> ?? Thomas >> >> From per.liden at oracle.com Tue May 21 12:04:25 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 21 May 2019 14:04:25 +0200 Subject: RFR: 8224203: Remove need to specify type when using FLAG_SET macros In-Reply-To: References: Message-ID: <488299f5-1189-e233-0fb3-7cadeb6b60a3@oracle.com> Looks good to me. Nice cleanup! /Per On 5/20/19 1:12 PM, Stefan Karlsson wrote: > Hi all, > > Please review this patch to remove the need to specify type when using > the FLAG_SET macros. > > https://cr.openjdk.java.net/~stefank/8224203/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8224203 > > This patch builds on top of the changes in: > ?"8224201: Simplify JVM flag macro expansions" > ?https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-May/038184.html > > global_extensions.hpp contains the actual change to JVM flag setters. It > expands one inline function per flag. For example: > inline JVMFlag::Error Flag_G1HeapRegionSize_set(size_t value, > JVMFlag::Flags origin) { > ?? return JVMFlagEx::size_tAtPut(Flag_G1HeapRegionSize_enum, value, > origin); > } > > The rest of the files contain removal of the type arguments. > > For example: > -??? FLAG_SET_ERGO(size_t, G1HeapRegionSize, GrainBytes); > +??? FLAG_SET_ERGO(G1HeapRegionSize, GrainBytes); > > Compiles on all tier1 platforms. > > Thanks, > StefanK From coleen.phillimore at oracle.com Tue May 21 12:11:09 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 21 May 2019 08:11:09 -0400 Subject: RFR: 8224203: Remove need to specify type when using FLAG_SET macros In-Reply-To: <488299f5-1189-e233-0fb3-7cadeb6b60a3@oracle.com> References: <488299f5-1189-e233-0fb3-7cadeb6b60a3@oracle.com> Message-ID: <2a5cd68d-34ba-e1f2-c0cf-2eee023bb5e2@oracle.com> +1 coleen On 5/21/19 8:04 AM, Per Liden wrote: > Looks good to me. Nice cleanup! > > /Per > > On 5/20/19 1:12 PM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to remove the need to specify type when >> using the FLAG_SET macros. >> >> https://cr.openjdk.java.net/~stefank/8224203/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8224203 >> >> This patch builds on top of the changes in: >> ??"8224201: Simplify JVM flag macro expansions" >> ??https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-May/038184.html >> >> >> global_extensions.hpp contains the actual change to JVM flag setters. >> It expands one inline function per flag. For example: >> inline JVMFlag::Error Flag_G1HeapRegionSize_set(size_t value, >> JVMFlag::Flags origin) { >> ??? return JVMFlagEx::size_tAtPut(Flag_G1HeapRegionSize_enum, value, >> origin); >> } >> >> The rest of the files contain removal of the type arguments. >> >> For example: >> -??? FLAG_SET_ERGO(size_t, G1HeapRegionSize, GrainBytes); >> +??? FLAG_SET_ERGO(G1HeapRegionSize, GrainBytes); >> >> Compiles on all tier1 platforms. >> >> Thanks, >> StefanK From stefan.karlsson at oracle.com Tue May 21 13:11:35 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 21 May 2019 15:11:35 +0200 Subject: RFR: 8224201: Simplify JVM flag macro expansions In-Reply-To: <11d88ab3-5b95-7dcc-74ea-2573d3ccd6d9@oracle.com> References: <127819f3-1e67-128b-fc7f-9d199bcb594d@oracle.com> <11d88ab3-5b95-7dcc-74ea-2573d3ccd6d9@oracle.com> Message-ID: <6f3b8136-340a-9143-8ddc-736fbf036046@oracle.com> On 2019-05-21 14:02, coleen.phillimore at oracle.com wrote: > > I didn't do a full review, but do we still need globals_ext.hpp ? We don't need this anymore, and I would be happy to get rid of that file. Anyone else in the community that needs it? Maybe create a new RFE about removing it? > > Can this set of macros for ALL_FLAGS be put in globals_shared.hpp > also??? It would be nice for globals.hpp to be mostly the flag list > rather than seeing these macros. Sure: http://cr.openjdk.java.net/~stefank/8224201/webrev.02.delta/ http://cr.openjdk.java.net/~stefank/8224201/webrev.02/ On the other hand, you can't really use ALL_FLAGS without also including globals.hpp, and we still need the DECLARE_* parts, so I'm not sure how much you gain by doing this. > > I think we can still build aarch64 and zero locally. I've built aarch64 with release and fastdebug. Zero with fastdebug seems to have some kind of unrelated problems. Thanks, StefanK > > thanks, > Coleen > > On 5/21/19 7:05 AM, Stefan Karlsson wrote: >> Thanks for the review, Thomas. >> >> StefanK >> >> On 2019-05-21 12:41, Thomas Schatzl wrote: >>> Hi, >>> >>> On Mon, 2019-05-20 at 12:56 +0200, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> Please review this patch to simplify how we generate the different >>>> parts of the JVM flags code. >>>> >>>> https://cr.openjdk.java.net/~stefank/8224201/webrev.01/ >>>> https://bugs.openjdk.java.net/browse/JDK-8224201 >>>> >>>> Notable parts of the patch: >>>> - Introduces a ALL_FLAGS macro, used to expand code for all flags. >>>> - Uses the ALL_FLAGS where appropriate. >>>> - Constraints list didn't expand JVMCI flags. Fixed by using >>>> ALL_FLAGS. >>>> - Moved _globals.hpp generated declarations to be >>>> expanded >>>> in globals.hpp. >>>> - Unified FLAG_MEMBER and FLAG_MEMBER_WITH_TYPE into >>>> FLAG_MEMBER_ENUM >>>> and change names accordingly. >>>> >>>> This change makes it easier to do future changes to the JVM flags >>>> handling code. For example: "JDK-8224203Remove need to specify type >>>> when using FLAG_SET macros" >>> >>> ?? although I saw that you already have quite a few reviewers after >>> working through it: looks good. Very nice cleanup. >>> >>> Thanks, >>> ?? Thomas >>> >>> > From stefan.karlsson at oracle.com Tue May 21 13:11:57 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 21 May 2019 15:11:57 +0200 Subject: RFR: 8224203: Remove need to specify type when using FLAG_SET macros In-Reply-To: <488299f5-1189-e233-0fb3-7cadeb6b60a3@oracle.com> References: <488299f5-1189-e233-0fb3-7cadeb6b60a3@oracle.com> Message-ID: <69fe8e4a-0575-1b01-d867-09c298306541@oracle.com> Thanks, Per. StefanK On 2019-05-21 14:04, Per Liden wrote: > Looks good to me. Nice cleanup! > > /Per > > On 5/20/19 1:12 PM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to remove the need to specify type when using >> the FLAG_SET macros. >> >> https://cr.openjdk.java.net/~stefank/8224203/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8224203 >> >> This patch builds on top of the changes in: >> ??"8224201: Simplify JVM flag macro expansions" >> ??https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-May/038184.html >> >> >> global_extensions.hpp contains the actual change to JVM flag setters. >> It expands one inline function per flag. For example: >> inline JVMFlag::Error Flag_G1HeapRegionSize_set(size_t value, >> JVMFlag::Flags origin) { >> ??? return JVMFlagEx::size_tAtPut(Flag_G1HeapRegionSize_enum, value, >> origin); >> } >> >> The rest of the files contain removal of the type arguments. >> >> For example: >> -??? FLAG_SET_ERGO(size_t, G1HeapRegionSize, GrainBytes); >> +??? FLAG_SET_ERGO(G1HeapRegionSize, GrainBytes); >> >> Compiles on all tier1 platforms. >> >> Thanks, >> StefanK From stefan.karlsson at oracle.com Tue May 21 13:12:08 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 21 May 2019 15:12:08 +0200 Subject: RFR: 8224203: Remove need to specify type when using FLAG_SET macros In-Reply-To: <2a5cd68d-34ba-e1f2-c0cf-2eee023bb5e2@oracle.com> References: <488299f5-1189-e233-0fb3-7cadeb6b60a3@oracle.com> <2a5cd68d-34ba-e1f2-c0cf-2eee023bb5e2@oracle.com> Message-ID: Thanks, Coleen. StefanK On 2019-05-21 14:11, coleen.phillimore at oracle.com wrote: > +1 > coleen > > On 5/21/19 8:04 AM, Per Liden wrote: >> Looks good to me. Nice cleanup! >> >> /Per >> >> On 5/20/19 1:12 PM, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review this patch to remove the need to specify type when >>> using the FLAG_SET macros. >>> >>> https://cr.openjdk.java.net/~stefank/8224203/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8224203 >>> >>> This patch builds on top of the changes in: >>> ??"8224201: Simplify JVM flag macro expansions" >>> ??https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-May/038184.html >>> >>> >>> global_extensions.hpp contains the actual change to JVM flag setters. >>> It expands one inline function per flag. For example: >>> inline JVMFlag::Error Flag_G1HeapRegionSize_set(size_t value, >>> JVMFlag::Flags origin) { >>> ??? return JVMFlagEx::size_tAtPut(Flag_G1HeapRegionSize_enum, value, >>> origin); >>> } >>> >>> The rest of the files contain removal of the type arguments. >>> >>> For example: >>> -??? FLAG_SET_ERGO(size_t, G1HeapRegionSize, GrainBytes); >>> +??? FLAG_SET_ERGO(G1HeapRegionSize, GrainBytes); >>> >>> Compiles on all tier1 platforms. >>> >>> Thanks, >>> StefanK > From thomas.stuefe at gmail.com Tue May 21 13:47:22 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 21 May 2019 15:47:22 +0200 Subject: RFR(xs): 8224487: outputStream should not be copyable Message-ID: Hi all, may I please have a review for this small fix. With JDK-8224193 (not yet pushed) I saw a number of crashes which were caused by code handing around copies of outputStream objects but copy semantics are not implemented. This fix forbids copying for outputStream and its descendants and fixes the few places where that happened. Bug: https://bugs.openjdk.java.net/browse/JDK-8224487 cr: http://cr.openjdk.java.net/~stuefe/webrevs/8224487-make-streams-not-copyable/webrev.00/webrev/ Note: In event log coding, I removed the convenience function stringStream FormatStringLogMessage::stream(). This makes the (very few) call sites slightly more verbose but I have open for RFR a cleanup of the event log system (see JDK-8220762, https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-May/034349.html) which will simplify and cleanup this coding anyway. Thank you, Thomas From coleen.phillimore at oracle.com Tue May 21 14:17:45 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 21 May 2019 10:17:45 -0400 Subject: RFR: 8224201: Simplify JVM flag macro expansions In-Reply-To: <6f3b8136-340a-9143-8ddc-736fbf036046@oracle.com> References: <127819f3-1e67-128b-fc7f-9d199bcb594d@oracle.com> <11d88ab3-5b95-7dcc-74ea-2573d3ccd6d9@oracle.com> <6f3b8136-340a-9143-8ddc-736fbf036046@oracle.com> Message-ID: <9461ef7a-2806-96ec-df45-dc49601627c0@oracle.com> On 5/21/19 9:11 AM, Stefan Karlsson wrote: > On 2019-05-21 14:02, coleen.phillimore at oracle.com wrote: >> >> I didn't do a full review, but do we still need globals_ext.hpp ? > > We don't need this anymore, and I would be happy to get rid of that > file. Anyone else in the community that needs it? > > Maybe create a new RFE about removing it? Sure. > >> >> Can this set of macros for ALL_FLAGS be put in globals_shared.hpp >> also??? It would be nice for globals.hpp to be mostly the flag list >> rather than seeing these macros. > > Sure: > ?http://cr.openjdk.java.net/~stefank/8224201/webrev.02.delta/ > ?http://cr.openjdk.java.net/~stefank/8224201/webrev.02/ > > On the other hand, you can't really use ALL_FLAGS without also > including globals.hpp, and we still need the DECLARE_* parts, so I'm > not sure how much you gain by doing this. Thanks, this is better.? I don't have to see the ugly macros when I look in globals.hpp. Coleen > >> >> I think we can still build aarch64 and zero locally. > > I've built aarch64 with release and fastdebug. > > Zero with fastdebug seems to have some kind of unrelated problems. > > Thanks, > StefanK > >> >> thanks, >> Coleen >> >> On 5/21/19 7:05 AM, Stefan Karlsson wrote: >>> Thanks for the review, Thomas. >>> >>> StefanK >>> >>> On 2019-05-21 12:41, Thomas Schatzl wrote: >>>> Hi, >>>> >>>> On Mon, 2019-05-20 at 12:56 +0200, Stefan Karlsson wrote: >>>>> Hi all, >>>>> >>>>> Please review this patch to simplify how we generate the different >>>>> parts of the JVM flags code. >>>>> >>>>> https://cr.openjdk.java.net/~stefank/8224201/webrev.01/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8224201 >>>>> >>>>> Notable parts of the patch: >>>>> - Introduces a ALL_FLAGS macro, used to expand code for all flags. >>>>> - Uses the ALL_FLAGS where appropriate. >>>>> - Constraints list didn't expand JVMCI flags. Fixed by using >>>>> ALL_FLAGS. >>>>> - Moved _globals.hpp generated declarations to be >>>>> expanded >>>>> in globals.hpp. >>>>> - Unified FLAG_MEMBER and FLAG_MEMBER_WITH_TYPE into >>>>> FLAG_MEMBER_ENUM >>>>> and change names accordingly. >>>>> >>>>> This change makes it easier to do future changes to the JVM flags >>>>> handling code. For example: "JDK-8224203Remove need to specify type >>>>> when using FLAG_SET macros" >>>> >>>> ?? although I saw that you already have quite a few reviewers after >>>> working through it: looks good. Very nice cleanup. >>>> >>>> Thanks, >>>> ?? Thomas >>>> >>>> >> From kim.barrett at oracle.com Tue May 21 15:56:53 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 21 May 2019 11:56:53 -0400 Subject: RFR(xs): 8224487: outputStream should not be copyable In-Reply-To: References: Message-ID: <119D1DC7-0C49-4BF9-8E1F-65205C9EEDB0@oracle.com> > On May 21, 2019, at 9:47 AM, Thomas St?fe wrote: > > Hi all, > may I please have a review for this small fix. With JDK-8224193 (not yet > pushed) I saw a number of crashes which were caused by code handing around > copies of outputStream objects but copy semantics are not implemented. > > This fix forbids copying for outputStream and its descendants and fixes the > few places where that happened. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224487 > cr: > http://cr.openjdk.java.net/~stuefe/webrevs/8224487-make-streams-not-copyable/webrev.00/webrev/ > > Note: In event log coding, I removed the convenience function stringStream > FormatStringLogMessage::stream(). This makes the (very few) call sites > slightly more verbose but I have open for RFR a cleanup of the event log > system (see JDK-8220762, > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-May/034349.html) > which will simplify and cleanup this coding anyway. > > Thank you, > > Thomas Generally nice. Just a couple of comments. ------------------------------------------------------------------------------ src/hotspot/share/utilities/ostream.hpp 46 outputStream(const outputStream&); Copy-assign should also be poisoned. Hopefully that won't find too many more problems. ------------------------------------------------------------------------------ src/hotspot/share/utilities/exceptions.hpp 189 static void log_exception(Handle exception, stringStream tempst); => 189 static void log_exception(Handle exception, const char* message); Why not change the stringStream parameter to be passed by const-ref rather than by value? That would avoid changing all the callers. ------------------------------------------------------------------------------ src/hotspot/share/utilities/events.hpp Removed from class FormatStringLogMessage 140 public: 141 // Wrap this buffer in a stringStream. 142 stringStream stream() { 143 return stringStream(this->_buf, this->size()); 144 } FormatStringLogMessage seems kind of pointless now. Maybe it should be eliminated? That could be a separate cleanup. ------------------------------------------------------------------------------ From thomas.stuefe at gmail.com Tue May 21 16:20:00 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 21 May 2019 18:20:00 +0200 Subject: RFR(xs): 8224487: outputStream should not be copyable In-Reply-To: <119D1DC7-0C49-4BF9-8E1F-65205C9EEDB0@oracle.com> References: <119D1DC7-0C49-4BF9-8E1F-65205C9EEDB0@oracle.com> Message-ID: Hi Kim, thanks for the review. Answers inline. On Tue, May 21, 2019 at 5:56 PM Kim Barrett wrote: > > On May 21, 2019, at 9:47 AM, Thomas St?fe > wrote: > > > > Hi all, > > may I please have a review for this small fix. With JDK-8224193 (not yet > > pushed) I saw a number of crashes which were caused by code handing > around > > copies of outputStream objects but copy semantics are not implemented. > > > > This fix forbids copying for outputStream and its descendants and fixes > the > > few places where that happened. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224487 > > cr: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8224487-make-streams-not-copyable/webrev.00/webrev/ > > > > Note: In event log coding, I removed the convenience function > stringStream > > FormatStringLogMessage::stream(). This makes the (very few) call sites > > slightly more verbose but I have open for RFR a cleanup of the event log > > system (see JDK-8220762, > > > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-May/034349.html > ) > > which will simplify and cleanup this coding anyway. > > > > Thank you, > > > > Thomas > > Generally nice. Just a couple of comments. > > > ------------------------------------------------------------------------------ > src/hotspot/share/utilities/ostream.hpp > 46 outputStream(const outputStream&); > > Copy-assign should also be poisoned. Hopefully that won't find too > many more problems. > > Good point! Will do that. I do not expect many surprises. > > ------------------------------------------------------------------------------ > src/hotspot/share/utilities/exceptions.hpp > 189 static void log_exception(Handle exception, stringStream tempst); > => > 189 static void log_exception(Handle exception, const char* message); > > Why not change the stringStream parameter to be passed by const-ref > rather than by value? That would avoid changing all the callers. > > Because handing the whole stream object down to log_exception was overkill anyway. All it wants is to print a text message, so I just give it that and live with a slightly larger patch diff. Also, I am not a big fan of references but that is just me. I usually prefer to see at the call site if I hand in value or reference without looking up the prototype. > > ------------------------------------------------------------------------------ > src/hotspot/share/utilities/events.hpp > Removed from class FormatStringLogMessage > 140 public: > 141 // Wrap this buffer in a stringStream. > 142 stringStream stream() { > 143 return stringStream(this->_buf, this->size()); > 144 } > > FormatStringLogMessage seems kind of pointless now. Maybe it should > be eliminated? That could be a separate cleanup. > > Yes. As I wrote, I have a larger patch under review which changes all that code anyway. If I just remove FormatStringMessage I must publish the ctor of the parent class, FormatMessage, and that was just that one step too far for this patch. > > ------------------------------------------------------------------------------ > > Thank you! Will post an updated webrev. Cheers, Thomas From vladimir.x.ivanov at oracle.com Tue May 21 17:33:18 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 21 May 2019 20:33:18 +0300 Subject: [13] RFR (M): 8223213: Implement fast class initialization checks on x86-64 In-Reply-To: References: <85a4a478-9200-87f2-c966-49af21f687c2@oracle.com> <3e1ceae0-f7a9-e2e6-2b06-59a22540550d@oracle.com> Message-ID: <3d9c0897-0275-c341-fe33-5f0b6c94f253@oracle.com> Thanks for the feedback, David! Updated webrev: http://cr.openjdk.java.net/~vlivanov/8223213/webrev.01/ Some responses inline: > Forgot to mention that your new test doesn't look like it will play > nicely when run with Graal enabled, so you may need to split up into > different @test sections and add "@requires !vm.graal.enabled" to > exclude graal. What kind of problem when running with Graal do you have in mind? I double-checked that the test passes with Graal enabled. >> I'll be very happy to see this go in - though I do wish we had more >> platform coverage than just x86_64. Hopefully the other archs will >> jump on-board with this as well. Yes, fully agree with you. It should be pretty straightforward for maintainers to mirror x86-specific changes for their architectures. >> I was initially confused by the UseFastClassInitChecks flag as I >> couldn't really see why you would want to turn it off (other than >> perhaps during testing) but I see that it is really used (as you >> explained to Vladimir K.) to exclude the new code for platforms which >> have not implemented it. Though I'm still not sure that we shouldn't >> have something to detect it being turned on at runtime on platforms >> that don't support it (it will likely crash quickly but still ...). >> Keep wondering if there is a better way to handle this aspect of the >> change ... I deliberately made the flag develop, so it's possible to change it from command-line only in debug builds. I could introduce additional platform-specific validation, but it doesn't look worth the effort for such narrow case (and there are other develop flags which guard broken functionality). >> I can't comment on the actual interpreter and compiler changes - sorry. No problem, I'll wait for more reviews from Runtime team. >> This will need re-basing now that JDK-8219974 has been backed out. Done. Best regards, Vladimir Ivanov >> On 2/05/2019 9:17 am, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8223213/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8223213 >>> >>> (It's a followup RFR on a earlier RFC [1].) >>> >>> Recent changes severely affected how static initializers are executed >>> and for long-running initializers it manifested as a severe slowdown. >>> As an example, it led to a 3x slowdown on some Clojure applications >>> (JDK-8219233 [2]). The root cause is that until a class is fully >>> initialized, every invocation of static method on it goes through >>> method resolution. >>> >>> Proposed fix introduces fast class initialization barriers for C1, >>> C2, and template interpreter on x86-64. I did some experiments with >>> cross-platform approaches, but haven't got satisfactory results. >>> >>> On other platforms, behavior stays (mostly) intact. (I had to revert >>> some changes introduced by JDK-8219492 [3], since the assumptions >>> they rely on about accesses inside a class don't hold in all cases.) >>> >>> The barrier is as simple as: >>> ??? if (holder->is_not_initialized() && >>> ??????? !holder->is_reentrant_initialization(current_thread)) { >>> ????? // trigger call site re-resolution and block there >>> ??? } >>> >>> There are 3 places where barriers are added: >>> ?? * in template interpreter for invokestatic bytecode; >>> ?? * at nmethod verified entry point (for normal compilations); >>> ?? * c2i adapters; >>> >>> For template interperter, there's additional check added into >>> TemplateTable::resolve_cache_and_index which calls into >>> InterpreterRuntime::resolve_from_cache when fast path checks fail. >>> >>> In case of nmethods, the barrier is put before frame construction, so >>> existing compiler runtime routines can be reused >>> (SharedRuntime::get_handle_wrong_method_stub()). >>> >>> Also, C2 has a guard on entry (Parse::clinit_deopt()) which triggers >>> nmethod recompilation once the class is fully initialized. >>> >>> OSR compilations don't need a barrier. >>> >>> Correspondence between barriers and transitions they cover: >>> ?? (1) from interpreter (barrier on caller side) >>> ??????? * all transitions: interpreter, compiled (i2c), native, aot, ... >>> >>> ?? (2) from compiled (barrier on callee side) >>> ??????? to compiled, to native (barrier in native wrapper on entry) >>> >>> ?? (3) c2i bypasses both barriers (interpreter and compiled) and >>> requires a dedicated barrier in c2i >>> >>> ?? (4) to Graal/AOT code: >>> ???????? from interpreter: covered by interpreter barrier >>> ???????? from compiled: call site patching is disabled, leading to >>> repeated call site resolution until method holder is fully >>> initialized (original behavior). >>> >>> Performance experiments with clojure [2] demonstrated that the fix >>> almost completely recuperates the regression: >>> >>> ?? (1) always reresolve (w/o the fix):??? ~12,0s ( 1x) >>> ?? (2) C1/C2 barriers only:??????????????? ~3,8s (~3x) >>> ?? (3) int/C1/C2 barriers:???????????????? ~3,2s (-20%) >>> -------- >>> ?? (4) barriers disabled for invokestatic? ~3,2s >>> >>> I deliberately tried to keep the patch backport-friendly for >>> 8u/11u/12u and refrained from using newer features like nmethod >>> barriers introduced recently. The fix can be refactored later >>> specifically for 13 as a followup change. >>> >>> Testing: clojure startup, tier1-5 >>> >>> Thanks! >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] >>> https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-April/037760.html >>> >>> [2] https://bugs.openjdk.java.net/browse/JDK-8219233 >>> [3] https://bugs.openjdk.java.net/browse/JDK-8219492 From thomas.stuefe at gmail.com Tue May 21 17:54:41 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 21 May 2019 19:54:41 +0200 Subject: RFR(xs): 8224487: outputStream should not be copyable In-Reply-To: References: Message-ID: New Webrev, with Kim's feedback worked in (poisoning copy assignment too, but no issues came up) and an additional bug fix: delta: http://cr.openjdk.java.net/~stuefe/webrevs/8224487-make-streams-not-copyable/webrev_delta.01/webrev/ full: http://cr.openjdk.java.net/~stuefe/webrevs/8224487-make-streams-not-copyable/webrev.01/webrev/ Thanks, Thomas On Tue, May 21, 2019 at 3:47 PM Thomas St?fe wrote: > Hi all, > may I please have a review for this small fix. With JDK-8224193 (not yet > pushed) I saw a number of crashes which were caused by code handing around > copies of outputStream objects but copy semantics are not implemented. > > This fix forbids copying for outputStream and its descendants and fixes > the few places where that happened. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224487 > cr: > http://cr.openjdk.java.net/~stuefe/webrevs/8224487-make-streams-not-copyable/webrev.00/webrev/ > > Note: In event log coding, I removed the convenience function stringStream > FormatStringLogMessage::stream(). This makes the (very few) call sites > slightly more verbose but I have open for RFR a cleanup of the event log > system (see JDK-8220762, > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-May/034349.html) > which will simplify and cleanup this coding anyway. > > Thank you, > > Thomas > > From kim.barrett at oracle.com Tue May 21 18:23:15 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 21 May 2019 14:23:15 -0400 Subject: RFR(xs): 8224487: outputStream should not be copyable In-Reply-To: References: <119D1DC7-0C49-4BF9-8E1F-65205C9EEDB0@oracle.com> Message-ID: > On May 21, 2019, at 12:20 PM, Thomas St?fe wrote: > src/hotspot/share/utilities/exceptions.hpp > 189 static void log_exception(Handle exception, stringStream tempst); > => > 189 static void log_exception(Handle exception, const char* message); > > Why not change the stringStream parameter to be passed by const-ref > rather than by value? That would avoid changing all the callers. > > > Because handing the whole stream object down to log_exception was overkill anyway. All it wants is to print a text message, so I just give it that and live with a slightly larger patch diff. > > Also, I am not a big fan of references but that is just me. I usually prefer to see at the call site if I hand in value or reference without looking up the prototype. [Oops, I missed the bug introduced into log_exception by webrev.00; I was focused on the question of the parameter change.] I disagree, for a number of reasons, but mostly because passing by const-ref is completely normal for C++. One doesn't need to look at the prototype to determine value vs const-ref passing, because from the caller's POV it doesn't matter. > src/hotspot/share/utilities/events.hpp > Removed from class FormatStringLogMessage > 140 public: > 141 // Wrap this buffer in a stringStream. > 142 stringStream stream() { > 143 return stringStream(this->_buf, this->size()); > 144 } > > FormatStringLogMessage seems kind of pointless now. Maybe it should > be eliminated? That could be a separate cleanup. > > > Yes. As I wrote, I have a larger patch under review which changes all that code anyway. > > If I just remove FormatStringMessage I must publish the ctor of the parent class, FormatMessage, and that was just that one step too far for this patch. I suspected as much; thanks for confirming. From thomas.stuefe at gmail.com Tue May 21 18:28:32 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 21 May 2019 20:28:32 +0200 Subject: RFR(xs): 8224487: outputStream should not be copyable In-Reply-To: References: <119D1DC7-0C49-4BF9-8E1F-65205C9EEDB0@oracle.com> Message-ID: On Tue, May 21, 2019 at 8:23 PM Kim Barrett wrote: > > On May 21, 2019, at 12:20 PM, Thomas St?fe > wrote: > > src/hotspot/share/utilities/exceptions.hpp > > 189 static void log_exception(Handle exception, stringStream tempst); > > => > > 189 static void log_exception(Handle exception, const char* message); > > > > Why not change the stringStream parameter to be passed by const-ref > > rather than by value? That would avoid changing all the callers. > > > > > > Because handing the whole stream object down to log_exception was > overkill anyway. All it wants is to print a text message, so I just give it > that and live with a slightly larger patch diff. > > > > Also, I am not a big fan of references but that is just me. I usually > prefer to see at the call site if I hand in value or reference without > looking up the prototype. > > [Oops, I missed the bug introduced into log_exception by webrev.00; I > was focused on the question of the parameter change.] > > Yes me too :( Shouldn't have renamed that thing in the first place. Thanks to jdk-submit tests I still got that. > I disagree, for a number of reasons, but mostly because passing by > const-ref is completely normal for C++. One doesn't need to look at > the prototype to determine value vs const-ref passing, because from > the caller's POV it doesn't matter. > > Okay, I see your point. Are you still okay with this version? My original reasoning still holds - a const char* is sufficient at this place, log_exception does not need to take the whole stringStream. > > src/hotspot/share/utilities/events.hpp > > Removed from class FormatStringLogMessage > > 140 public: > > 141 // Wrap this buffer in a stringStream. > > 142 stringStream stream() { > > 143 return stringStream(this->_buf, this->size()); > > 144 } > > > > FormatStringLogMessage seems kind of pointless now. Maybe it should > > be eliminated? That could be a separate cleanup. > > > > > > Yes. As I wrote, I have a larger patch under review which changes all > that code anyway. > > > > If I just remove FormatStringMessage I must publish the ctor of the > parent class, FormatMessage, and that was just that one step too far for > this patch. > > I suspected as much; thanks for confirming. > > From gerard.ziemski at oracle.com Tue May 21 18:50:00 2019 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Tue, 21 May 2019 13:50:00 -0500 Subject: RFR: 8224201: Simplify JVM flag macro expansions In-Reply-To: References: Message-ID: Very, very nice. If you haven't checked in yet (according to the bug you haven't), could we bump up the INITIAL_RANGES_SIZE to 512 (to avoid having to grow the range list at startup - the list of flags grew beyond the initial size) since we're modifying the jvmFlagRangeList.cpp anyhow? (no need for webrev) Did you run the TestOptionsWithRanges.java test? cheers On 5/20/19 5:56 AM, Stefan Karlsson wrote: > Hi all, > > Please review this patch to simplify how we generate the different > parts of the JVM flags code. > > https://cr.openjdk.java.net/~stefank/8224201/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8224201 > > Notable parts of the patch: > - Introduces a ALL_FLAGS macro, used to expand code for all flags. > - Uses the ALL_FLAGS where appropriate. > - Constraints list didn't expand JVMCI flags. Fixed by using ALL_FLAGS. > - Moved _globals.hpp generated declarations to be expanded > in globals.hpp. > - Unified FLAG_MEMBER and FLAG_MEMBER_WITH_TYPE into FLAG_MEMBER_ENUM > and change names accordingly. > > This change makes it easier to do future changes to the JVM flags > handling code. For example: "JDK-8224203Remove need to specify type > when using FLAG_SET macros" > > Compiled on tier1 platforms. > > Thanks, > StefanK > > From stefan.karlsson at oracle.com Tue May 21 19:16:56 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 21 May 2019 21:16:56 +0200 Subject: RFR: 8224201: Simplify JVM flag macro expansions In-Reply-To: References: Message-ID: On 2019-05-21 20:50, gerard ziemski wrote: > Very, very nice. Thanks! > > If you haven't checked in yet (according to the bug you haven't), I don't intend to push this today, so there's still time to review. :) > could we bump up the INITIAL_RANGES_SIZE to 512 (to avoid having to > grow the range list at startup - the list of flags grew beyond the > initial size) since we're modifying the jvmFlagRangeList.cpp anyhow? > (no need for webrev) That seems unrelated to my changes, and therefore warrants a separate RFE, IMHO. It shouldn't be a big deal to get such a change reviewed and pushed. > Did you run the TestOptionsWithRanges.java test? It passes when run locally. Thanks, StefanK > > > cheers > > On 5/20/19 5:56 AM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to simplify how we generate the different >> parts of the JVM flags code. >> >> https://cr.openjdk.java.net/~stefank/8224201/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8224201 >> >> Notable parts of the patch: >> - Introduces a ALL_FLAGS macro, used to expand code for all flags. >> - Uses the ALL_FLAGS where appropriate. >> - Constraints list didn't expand JVMCI flags. Fixed by using ALL_FLAGS. >> - Moved _globals.hpp generated declarations to be >> expanded in globals.hpp. >> - Unified FLAG_MEMBER and FLAG_MEMBER_WITH_TYPE into FLAG_MEMBER_ENUM >> and change names accordingly. >> >> This change makes it easier to do future changes to the JVM flags >> handling code. For example: "JDK-8224203Remove need to specify type >> when using FLAG_SET macros" >> >> Compiled on tier1 platforms. >> >> Thanks, >> StefanK >> >> > From gerard.ziemski at oracle.com Tue May 21 19:19:47 2019 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Tue, 21 May 2019 14:19:47 -0500 Subject: RFR: 8224201: Simplify JVM flag macro expansions In-Reply-To: References: Message-ID: <00a050d2-3df1-e905-8c39-76015c3d7473@oracle.com> On 5/21/19 2:16 PM, Stefan Karlsson wrote: >> >> If you haven't checked in yet (according to the bug you haven't), > > I don't intend to push this today, so there's still time to review. :) Oh yes, it's (r)eviewed! Thanks! From kim.barrett at oracle.com Tue May 21 19:29:25 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 21 May 2019 15:29:25 -0400 Subject: RFR(xs): 8224487: outputStream should not be copyable In-Reply-To: References: <119D1DC7-0C49-4BF9-8E1F-65205C9EEDB0@oracle.com> Message-ID: > On May 21, 2019, at 2:28 PM, Thomas St?fe wrote: > > > > On Tue, May 21, 2019 at 8:23 PM Kim Barrett wrote: > > On May 21, 2019, at 12:20 PM, Thomas St?fe wrote: > > src/hotspot/share/utilities/exceptions.hpp > > 189 static void log_exception(Handle exception, stringStream tempst); > > => > > 189 static void log_exception(Handle exception, const char* message); > > > > Why not change the stringStream parameter to be passed by const-ref > > rather than by value? That would avoid changing all the callers. > > > > > > Because handing the whole stream object down to log_exception was overkill anyway. All it wants is to print a text message, so I just give it that and live with a slightly larger patch diff. > > > > Also, I am not a big fan of references but that is just me. I usually prefer to see at the call site if I hand in value or reference without looking up the prototype. > > [Oops, I missed the bug introduced into log_exception by webrev.00; I > was focused on the question of the parameter change.] > > > Yes me too :( Shouldn't have renamed that thing in the first place. Thanks to jdk-submit tests I still got that. > > I disagree, for a number of reasons, but mostly because passing by > const-ref is completely normal for C++. One doesn't need to look at > the prototype to determine value vs const-ref passing, because from > the caller's POV it doesn't matter. > > > Okay, I see your point. > > Are you still okay with this version? My original reasoning still holds - a const char* is sufficient at this place, log_exception does not need to take the whole stringStream. > After thinking about it some more, yes, though not *precisely* for that reason. Rather, it seems a bit odd that there should be any knowledge of stringStream in this API. So... > delta: http://cr.openjdk.java.net/~stuefe/webrevs/8224487-make-streams-not-copyable/webrev_delta.01/webrev/ > full: http://cr.openjdk.java.net/~stuefe/webrevs/8224487-make-streams-not-copyable/webrev.01/webrev/ > Looks good. From coleen.phillimore at oracle.com Tue May 21 19:36:50 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 21 May 2019 15:36:50 -0400 Subject: RFR(xs): 8224487: outputStream should not be copyable In-Reply-To: References: <119D1DC7-0C49-4BF9-8E1F-65205C9EEDB0@oracle.com> Message-ID: <22beaaf5-5553-ad1c-385a-a05ed5b5c71d@oracle.com> Thomas, This change looks good to me. thanks, Coleen On 5/21/19 3:29 PM, Kim Barrett wrote: >> On May 21, 2019, at 2:28 PM, Thomas St?fe wrote: >> >> >> >> On Tue, May 21, 2019 at 8:23 PM Kim Barrett wrote: >>> On May 21, 2019, at 12:20 PM, Thomas St?fe wrote: >>> src/hotspot/share/utilities/exceptions.hpp >>> 189 static void log_exception(Handle exception, stringStream tempst); >>> => >>> 189 static void log_exception(Handle exception, const char* message); >>> >>> Why not change the stringStream parameter to be passed by const-ref >>> rather than by value? That would avoid changing all the callers. >>> >>> >>> Because handing the whole stream object down to log_exception was overkill anyway. All it wants is to print a text message, so I just give it that and live with a slightly larger patch diff. >>> >>> Also, I am not a big fan of references but that is just me. I usually prefer to see at the call site if I hand in value or reference without looking up the prototype. >> [Oops, I missed the bug introduced into log_exception by webrev.00; I >> was focused on the question of the parameter change.] >> >> >> Yes me too :( Shouldn't have renamed that thing in the first place. Thanks to jdk-submit tests I still got that. >> >> I disagree, for a number of reasons, but mostly because passing by >> const-ref is completely normal for C++. One doesn't need to look at >> the prototype to determine value vs const-ref passing, because from >> the caller's POV it doesn't matter. >> >> >> Okay, I see your point. >> >> Are you still okay with this version? My original reasoning still holds - a const char* is sufficient at this place, log_exception does not need to take the whole stringStream. >> > After thinking about it some more, yes, though not *precisely* for that reason. > Rather, it seems a bit odd that there should be any knowledge of stringStream > in this API. So... > >> delta: http://cr.openjdk.java.net/~stuefe/webrevs/8224487-make-streams-not-copyable/webrev_delta.01/webrev/ >> full: http://cr.openjdk.java.net/~stuefe/webrevs/8224487-make-streams-not-copyable/webrev.01/webrev/ >> > Looks good. > From thomas.stuefe at gmail.com Tue May 21 19:46:35 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 21 May 2019 21:46:35 +0200 Subject: RFR(xs): 8224487: outputStream should not be copyable In-Reply-To: References: <119D1DC7-0C49-4BF9-8E1F-65205C9EEDB0@oracle.com> Message-ID: On Tue 21. May 2019 at 21:29, Kim Barrett wrote: > > On May 21, 2019, at 2:28 PM, Thomas St?fe > wrote: > > > > > > > > On Tue, May 21, 2019 at 8:23 PM Kim Barrett > wrote: > > > On May 21, 2019, at 12:20 PM, Thomas St?fe > wrote: > > > src/hotspot/share/utilities/exceptions.hpp > > > 189 static void log_exception(Handle exception, stringStream > tempst); > > > => > > > 189 static void log_exception(Handle exception, const char* > message); > > > > > > Why not change the stringStream parameter to be passed by const-ref > > > rather than by value? That would avoid changing all the callers. > > > > > > > > > Because handing the whole stream object down to log_exception was > overkill anyway. All it wants is to print a text message, so I just give it > that and live with a slightly larger patch diff. > > > > > > Also, I am not a big fan of references but that is just me. I usually > prefer to see at the call site if I hand in value or reference without > looking up the prototype. > > > > [Oops, I missed the bug introduced into log_exception by webrev.00; I > > was focused on the question of the parameter change.] > > > > > > Yes me too :( Shouldn't have renamed that thing in the first place. > Thanks to jdk-submit tests I still got that. > > > > I disagree, for a number of reasons, but mostly because passing by > > const-ref is completely normal for C++. One doesn't need to look at > > the prototype to determine value vs const-ref passing, because from > > the caller's POV it doesn't matter. > > > > > > Okay, I see your point. > > > > Are you still okay with this version? My original reasoning still holds > - a const char* is sufficient at this place, log_exception does not need to > take the whole stringStream. > > > > After thinking about it some more, yes, though not *precisely* for that > reason. > Rather, it seems a bit odd that there should be any knowledge of > stringStream > in this API. So... That is what I meant too. I try to limit ?knowledge? about things where it is not needed to keep the code flexible. > > > delta: > http://cr.openjdk.java.net/~stuefe/webrevs/8224487-make-streams-not-copyable/webrev_delta.01/webrev/ > > full: > http://cr.openjdk.java.net/~stuefe/webrevs/8224487-make-streams-not-copyable/webrev.01/webrev/ > > > > Looks good. > Great thanks! ..thomas > > From shade at redhat.com Tue May 21 20:06:40 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 21 May 2019 22:06:40 +0200 Subject: RFR (S) 8224522: Shenandoah should apply barriers on deoptimization Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8224522 Fix: http://cr.openjdk.java.net/~shade/8224522/webrev.01/ Shenandoah, like ZGC, needs to make sure that the oops that are in deoptimized frames are passed through the barriers. Otherwise deoptimization might sneak bad oops into into Java heap. This is a very rare, hard to replicate, but still fatal error. The fix copies what ZGC code already does. Since Shenandoah also runs with compressed oops, we need to take care of "narrowoop" path as well. I made the oop/narrowoop as close as possible style-wise. Testing: hotspot_gc_shenandoah; build with -shenandoahgc; jdk-submit (running) -- Thanks, -Aleksey From rkennke at redhat.com Tue May 21 20:20:29 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 May 2019 22:20:29 +0200 Subject: RFR (S) 8224522: Shenandoah should apply barriers on deoptimization In-Reply-To: References: Message-ID: <745a0845-9031-1502-2a3c-4b628ca8757b@redhat.com> It looks good to me. It probably warrants a proper GC interface. But let's fix the bug first. I was thinking what kind of GC interface would be appropriate. It really is a load from an off-heap address plus a load-barrier, so maybe NativeAccess<>::load() with appropriate decorators would cover it? Let's discuss this in a follow-up though. Thanks, Roman > Bug: > https://bugs.openjdk.java.net/browse/JDK-8224522 > > Fix: > http://cr.openjdk.java.net/~shade/8224522/webrev.01/ > > Shenandoah, like ZGC, needs to make sure that the oops that are in deoptimized frames are passed > through the barriers. Otherwise deoptimization might sneak bad oops into into Java heap. This is a > very rare, hard to replicate, but still fatal error. The fix copies what ZGC code already does. > Since Shenandoah also runs with compressed oops, we need to take care of "narrowoop" path as well. I > made the oop/narrowoop as close as possible style-wise. > > Testing: hotspot_gc_shenandoah; build with -shenandoahgc; jdk-submit (running) > From david.holmes at oracle.com Tue May 21 22:34:59 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 May 2019 08:34:59 +1000 Subject: [13] RFR (M): 8223213: Implement fast class initialization checks on x86-64 In-Reply-To: <3d9c0897-0275-c341-fe33-5f0b6c94f253@oracle.com> References: <85a4a478-9200-87f2-c966-49af21f687c2@oracle.com> <3e1ceae0-f7a9-e2e6-2b06-59a22540550d@oracle.com> <3d9c0897-0275-c341-fe33-5f0b6c94f253@oracle.com> Message-ID: Hi Vladimir, On 22/05/2019 3:33 am, Vladimir Ivanov wrote: > Thanks for the feedback, David! > > Updated webrev: > ? http://cr.openjdk.java.net/~vlivanov/8223213/webrev.01/ > > Some responses inline: >> Forgot to mention that your new test doesn't look like it will play >> nicely when run with Graal enabled, so you may need to split up into >> different @test sections and add "@requires !vm.graal.enabled" to >> exclude graal. > > What kind of problem when running with Graal do you have in mind? > > I double-checked that the test passes with Graal enabled. Your various @run lines are trying to execute in different compilation modes: -Xint, C1 only, C2 only, plus various permutations. If you take those command-lines and then add all the Graal flags to it then you are no longer testing any of the things you wanted to test. At best you test Graal 7 times - which is pointless. At worst you may find some variations will timeout when Graal is applied. For that matter an Xcomp run will also negate your intentions. Cheers, David ----- >>> I'll be very happy to see this go in - though I do wish we had more >>> platform coverage than just x86_64. Hopefully the other archs will >>> jump on-board with this as well. > > Yes, fully agree with you. It should be pretty straightforward for > maintainers to mirror x86-specific changes for their architectures. > >>> I was initially confused by the UseFastClassInitChecks flag as I >>> couldn't really see why you would want to turn it off (other than >>> perhaps during testing) but I see that it is really used (as you >>> explained to Vladimir K.) to exclude the new code for platforms which >>> have not implemented it. Though I'm still not sure that we shouldn't >>> have something to detect it being turned on at runtime on platforms >>> that don't support it (it will likely crash quickly but still ...). >>> Keep wondering if there is a better way to handle this aspect of the >>> change ... > > I deliberately made the flag develop, so it's possible to change it from > command-line only in debug builds. I could introduce additional > platform-specific validation, but it doesn't look worth the effort for > such narrow case (and there are other develop flags which guard broken > functionality). > >>> I can't comment on the actual interpreter and compiler changes - sorry. > > No problem, I'll wait for more reviews from Runtime team. > >>> This will need re-basing now that JDK-8219974 has been backed out. > > Done. > > Best regards, > Vladimir Ivanov > >>> On 2/05/2019 9:17 am, Vladimir Ivanov wrote: >>>> http://cr.openjdk.java.net/~vlivanov/8223213/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8223213 >>>> >>>> (It's a followup RFR on a earlier RFC [1].) >>>> >>>> Recent changes severely affected how static initializers are >>>> executed and for long-running initializers it manifested as a severe >>>> slowdown. >>>> As an example, it led to a 3x slowdown on some Clojure applications >>>> (JDK-8219233 [2]). The root cause is that until a class is fully >>>> initialized, every invocation of static method on it goes through >>>> method resolution. >>>> >>>> Proposed fix introduces fast class initialization barriers for C1, >>>> C2, and template interpreter on x86-64. I did some experiments with >>>> cross-platform approaches, but haven't got satisfactory results. >>>> >>>> On other platforms, behavior stays (mostly) intact. (I had to revert >>>> some changes introduced by JDK-8219492 [3], since the assumptions >>>> they rely on about accesses inside a class don't hold in all cases.) >>>> >>>> The barrier is as simple as: >>>> ??? if (holder->is_not_initialized() && >>>> ??????? !holder->is_reentrant_initialization(current_thread)) { >>>> ????? // trigger call site re-resolution and block there >>>> ??? } >>>> >>>> There are 3 places where barriers are added: >>>> ?? * in template interpreter for invokestatic bytecode; >>>> ?? * at nmethod verified entry point (for normal compilations); >>>> ?? * c2i adapters; >>>> >>>> For template interperter, there's additional check added into >>>> TemplateTable::resolve_cache_and_index which calls into >>>> InterpreterRuntime::resolve_from_cache when fast path checks fail. >>>> >>>> In case of nmethods, the barrier is put before frame construction, >>>> so existing compiler runtime routines can be reused >>>> (SharedRuntime::get_handle_wrong_method_stub()). >>>> >>>> Also, C2 has a guard on entry (Parse::clinit_deopt()) which triggers >>>> nmethod recompilation once the class is fully initialized. >>>> >>>> OSR compilations don't need a barrier. >>>> >>>> Correspondence between barriers and transitions they cover: >>>> ?? (1) from interpreter (barrier on caller side) >>>> ??????? * all transitions: interpreter, compiled (i2c), native, aot, >>>> ... >>>> >>>> ?? (2) from compiled (barrier on callee side) >>>> ??????? to compiled, to native (barrier in native wrapper on entry) >>>> >>>> ?? (3) c2i bypasses both barriers (interpreter and compiled) and >>>> requires a dedicated barrier in c2i >>>> >>>> ?? (4) to Graal/AOT code: >>>> ???????? from interpreter: covered by interpreter barrier >>>> ???????? from compiled: call site patching is disabled, leading to >>>> repeated call site resolution until method holder is fully >>>> initialized (original behavior). >>>> >>>> Performance experiments with clojure [2] demonstrated that the fix >>>> almost completely recuperates the regression: >>>> >>>> ?? (1) always reresolve (w/o the fix):??? ~12,0s ( 1x) >>>> ?? (2) C1/C2 barriers only:??????????????? ~3,8s (~3x) >>>> ?? (3) int/C1/C2 barriers:???????????????? ~3,2s (-20%) >>>> -------- >>>> ?? (4) barriers disabled for invokestatic? ~3,2s >>>> >>>> I deliberately tried to keep the patch backport-friendly for >>>> 8u/11u/12u and refrained from using newer features like nmethod >>>> barriers introduced recently. The fix can be refactored later >>>> specifically for 13 as a followup change. >>>> >>>> Testing: clojure startup, tier1-5 >>>> >>>> Thanks! >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] >>>> https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-April/037760.html >>>> >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8219233 >>>> [3] https://bugs.openjdk.java.net/browse/JDK-8219492 From thomas.stuefe at gmail.com Wed May 22 05:05:56 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 22 May 2019 07:05:56 +0200 Subject: RFR(xs): 8224487: outputStream should not be copyable In-Reply-To: <22beaaf5-5553-ad1c-385a-a05ed5b5c71d@oracle.com> References: <119D1DC7-0C49-4BF9-8E1F-65205C9EEDB0@oracle.com> <22beaaf5-5553-ad1c-385a-a05ed5b5c71d@oracle.com> Message-ID: Thank you Coleen! On Tue, May 21, 2019 at 9:37 PM wrote: > > Thomas, This change looks good to me. > thanks, > Coleen > > On 5/21/19 3:29 PM, Kim Barrett wrote: > >> On May 21, 2019, at 2:28 PM, Thomas St?fe > wrote: > >> > >> > >> > >> On Tue, May 21, 2019 at 8:23 PM Kim Barrett > wrote: > >>> On May 21, 2019, at 12:20 PM, Thomas St?fe > wrote: > >>> src/hotspot/share/utilities/exceptions.hpp > >>> 189 static void log_exception(Handle exception, stringStream > tempst); > >>> => > >>> 189 static void log_exception(Handle exception, const char* > message); > >>> > >>> Why not change the stringStream parameter to be passed by const-ref > >>> rather than by value? That would avoid changing all the callers. > >>> > >>> > >>> Because handing the whole stream object down to log_exception was > overkill anyway. All it wants is to print a text message, so I just give it > that and live with a slightly larger patch diff. > >>> > >>> Also, I am not a big fan of references but that is just me. I usually > prefer to see at the call site if I hand in value or reference without > looking up the prototype. > >> [Oops, I missed the bug introduced into log_exception by webrev.00; I > >> was focused on the question of the parameter change.] > >> > >> > >> Yes me too :( Shouldn't have renamed that thing in the first place. > Thanks to jdk-submit tests I still got that. > >> > >> I disagree, for a number of reasons, but mostly because passing by > >> const-ref is completely normal for C++. One doesn't need to look at > >> the prototype to determine value vs const-ref passing, because from > >> the caller's POV it doesn't matter. > >> > >> > >> Okay, I see your point. > >> > >> Are you still okay with this version? My original reasoning still holds > - a const char* is sufficient at this place, log_exception does not need to > take the whole stringStream. > >> > > After thinking about it some more, yes, though not *precisely* for that > reason. > > Rather, it seems a bit odd that there should be any knowledge of > stringStream > > in this API. So... > > > >> delta: > http://cr.openjdk.java.net/~stuefe/webrevs/8224487-make-streams-not-copyable/webrev_delta.01/webrev/ > >> full: > http://cr.openjdk.java.net/~stuefe/webrevs/8224487-make-streams-not-copyable/webrev.01/webrev/ > >> > > Looks good. > > > > From christoph.langer at sap.com Wed May 22 06:47:02 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 22 May 2019 06:47:02 +0000 Subject: RFR(XS): 8224573: Fix windows build after JDK-8221507 Message-ID: Hi, please review this build fix for Windows: Bug: https://bugs.openjdk.java.net/browse/JDK-8224573 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8224573.0/ Thanks Christoph > -----Original Message----- > From: hotspot-jfr-dev On > Behalf Of Langer, Christoph > Sent: Dienstag, 21. Mai 2019 22:02 > To: Ken Dobson > Cc: hotspot-jfr-dev at openjdk.java.net > Subject: [CAUTION] Build error on Windows after 8221507: Implement JFR > Events for Shenandoah > > Hi Ken, > > after you pushed JDK-8221507, I see build errors on Windows (enabled > warnings as errors): > > shenandoahHeapRegion.cpp > .../jdk/src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp(687) > : error C2220: warning treated as error - no 'object' file generated > .../jdk/src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp(687) > : warning C4267: 'argument': conversion from 'size_t' to 'unsigned int', > possible loss of data > ... (rest of output omitted) > * For target hotspot_variant- > server_libjvm_objs_shenandoahJfrSupport.obj: > shenandoahJfrSupport.cpp > .../jdk/src/hotspot/share/gc/shenandoah/shenandoahJfrSupport.cpp(60): > error C2220: warning treated as error - no 'object' file generated > .../jdk/src/hotspot/share/gc/shenandoah/shenandoahJfrSupport.cpp(60): > warning C4267: 'argument': conversion from 'size_t' to 'unsigned int', possible > loss of data > ... (rest of output omitted) > > I don't know if the fix is to simply add a cast to unsigned int. Can you please > check and repair? > > Thanks > Christoph > > > > -----Original Message----- > > From: jmc-dev On Behalf Of Ken > > Dobson > > Sent: Dienstag, 14. Mai 2019 23:19 > > To: Erik Gahlin > > Cc: hotspot-jfr-dev at openjdk.java.net; mikhailo.seledtsov at oracle.com; > jmc- > > dev at openjdk.java.net > > Subject: Re: RFR 8221507: Implement JFR Events for Shenandoah > > > > Thank you for the review again. > > > > Yes, not sure regarding backporting plans but I imagine it will be in the > > future so seemed best to avoid anything that cause issues such as Set.of(). > > > > I also think the naming of the jfr's is fine as it's stored in a folder > > named after the test which was easily found now that I'm aware that the > > jfrs are already dumped. > > > > I believe I've addressed the rest of your recommended changes to the > tests, > > let me know if I've covered everything. > > > > http://cr.openjdk.java.net/~kdobson/eventswithtests/webrev/ > > > > Thanks, > > > > Ken Dobson > > > > On Sun, May 12, 2019 at 8:28 PM Erik Gahlin > wrote: > > > > > Thanks for fixing! > > > > > > Product code looks good, but I think tests could be improved. > > > > > > There is no need to call dump in a final clause. > > > > > > Events.fromRecording(...) will dump the file into the jtreg scratch > > > directory ( "recording-1-pid-xxx.jfr") by default. I think this is > > > sufficient since there is only one recording per test. If you think the > > > name is cryptic, consider adding another method to Event.fromRecording > > that > > > takes an additional parameter that becomes a suffix, i.e > > > "recording-1-pid-xxx-test-heap-region-info.jfr" > > > > > > try (Recording r = new recording()) { > > > r.enable(EVENT_NAME); > > > r.start(); > > > r.stop() > > > List events = Events.fromRecording(r); > > > Events.hasEvents(events); > > > for (RecordedEvent event : events) { > > > Events.assertField(event, "index").notEqual(-1); > > > Events.assertField(event, "used").atMost(1024*1024L); > > > String state = Events.assertField(event, "state").getValue(); > > > GCHelper.assertShenandoahHeapRegionState(state)); > > > } > > > > > > The name of the field in metadata.xml is "state", but the tests looks for > > > "type". That seems incorrect. > > > > > > GCHelper: > > > > > > public static assertShenandoahHeapRegionState(String state) { > > > if (!shenandoahHeapRegionStates.contains(state)) { > > > throw new AssertionError("Unknown state '"+ state +"', valid heap > > > region states are " + shenandoahHeapRegionStates); > > > } > > > > > > I assume you don't use Set.of("Empty Uncommitted" , ... , "Trash") > > > because you want to backport to JDK 8. > > > > > > Thanks > > > Erik > > > > > > Thanks everyone for their reviews. I've added tests similar to the tests > > > for the G1 events as well as addressed the changes that Erik > > recommended. > > > > > > Here is the new webrev: > > > > > > http://cr.openjdk.java.net/~kdobson/shenandoaheventswithtests/webrev/ > > > > > > Please let me know if there's anything else that should be addressed. > > > > > > Thanks, > > > > > > Ken Dobson > > > > > > On Mon, May 6, 2019 at 11:38 AM > > wrote: > > > > > >> > > >> > > >> On 5/4/19 2:16 PM, Erik Gahlin wrote: > > >> > On 2019-05-04 00:19, mikhailo.seledtsov at oracle.com wrote: > > >> >> Hi, > > >> >> > > >> >> If possible and feasible, could you please implement tests for new > > >> >> events? > > >> >> > > >> >> Please place the tests under test/jdk/jdk/jfr/event/gc/. Perhaps > > >> >> create a "shenandoah" subfolder. > > >> >> > > >> >> If the events are too hard to test or not feasible, please add the > > >> >> event names to > > >> >> test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java, > to > > >> >> the hardToTestEvents set. Consider commenting why it is too hard to > > >> >> test. > > >> > > > >> > If events are are marked experimental, tests are ignored by > > >> > TestLookForUntestedEvents. java, so we should not add them to the > > >> > hardToTestEvents set. That may help them pass under the radar once > > the > > >> > experimental attribute is removed. > > >> Thank you. If the events are "experimental" this approach makes sense. > > >> Once the experimental status is removed, the > > >> TestLookForUntestedEvents.java should be able to notice if the event is > > >> not covered by tests. > > >> > That said, tests never hurts, even if they are experimental. I think > > >> > test/jdk/jdk/jfr/event/gc/detailed would be a good place > > >> +1 > > >> > > >> Thank you, > > >> Misha > > >> > > > >> > Erik > > >> > > > >> >> > > >> >> Also, please make sure to run all jfr tests under test/jdk/jdk/jfr/ > > >> >> prior to integration. > > >> >> > > >> >> > > >> >> Best regards, > > >> >> > > >> >> Misha > > >> >> > > >> >> > > >> >> > > >> >> On 5/3/19 7:44 AM, Ken Dobson wrote: > > >> >>> Hi all, > > >> >>> > > >> >>> Please review this patch that adds support for two new JFR events > > >> >>> ShenandoahHeapRegionStateChange and > > ShenandoahHeapRegionInformation. > > >> >>> > > >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221507 > > >> >>> Webrev: http://cr.openjdk.java.net/~kdobson/53476/webrev/ > > >> >>> > > >> >>> The Shenandoah team has also reviewed this patch and approved it > > >> >>> from their > > >> >>> end. > > >> >>> > > >> >>> Thanks, > > >> >>> > > >> >>> Ken Dobson > > >> >> > > >> > > > >> > > >> > > > From shade at redhat.com Wed May 22 06:54:21 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 May 2019 08:54:21 +0200 Subject: RFR(XS): 8224573: Fix windows build after JDK-8221507 In-Reply-To: References: Message-ID: <5e059d76-63e3-cafc-eea1-eac0371a5193@redhat.com> On 5/22/19 8:47 AM, Langer, Christoph wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8224573 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8224573.0/ Argh. Casting to unsigned is fine for now. The patch is good and trivial. I would really like to see the types in events match those passed in to event, if possible. Ken, please see to rectify that in the follow up patch? -Aleksey From thomas.stuefe at gmail.com Wed May 22 06:59:12 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 22 May 2019 08:59:12 +0200 Subject: RFR(XS): 8224573: Fix windows build after JDK-8221507 In-Reply-To: References: Message-ID: Looks okay. 32bit should be enough for number of regions I think. If I am not mistaken, they have a min region size of 256K, so this covers a heap of ~1000 tb? ..Thomas On Wed, May 22, 2019 at 8:47 AM Langer, Christoph wrote: > Hi, > > please review this build fix for Windows: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224573 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8224573.0/ > > Thanks > Christoph > > > > > -----Original Message----- > > From: hotspot-jfr-dev On > > Behalf Of Langer, Christoph > > Sent: Dienstag, 21. Mai 2019 22:02 > > To: Ken Dobson > > Cc: hotspot-jfr-dev at openjdk.java.net > > Subject: [CAUTION] Build error on Windows after 8221507: Implement JFR > > Events for Shenandoah > > > > Hi Ken, > > > > after you pushed JDK-8221507, I see build errors on Windows (enabled > > warnings as errors): > > > > shenandoahHeapRegion.cpp > > .../jdk/src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp(687) > > : error C2220: warning treated as error - no 'object' file generated > > .../jdk/src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp(687) > > : warning C4267: 'argument': conversion from 'size_t' to 'unsigned int', > > possible loss of data > > ... (rest of output omitted) > > * For target hotspot_variant- > > server_libjvm_objs_shenandoahJfrSupport.obj: > > shenandoahJfrSupport.cpp > > .../jdk/src/hotspot/share/gc/shenandoah/shenandoahJfrSupport.cpp(60): > > error C2220: warning treated as error - no 'object' file generated > > .../jdk/src/hotspot/share/gc/shenandoah/shenandoahJfrSupport.cpp(60): > > warning C4267: 'argument': conversion from 'size_t' to 'unsigned int', > possible > > loss of data > > ... (rest of output omitted) > > > > I don't know if the fix is to simply add a cast to unsigned int. Can you > please > > check and repair? > > > > Thanks > > Christoph > > > > > > > -----Original Message----- > > > From: jmc-dev On Behalf Of Ken > > > Dobson > > > Sent: Dienstag, 14. Mai 2019 23:19 > > > To: Erik Gahlin > > > Cc: hotspot-jfr-dev at openjdk.java.net; mikhailo.seledtsov at oracle.com; > > jmc- > > > dev at openjdk.java.net > > > Subject: Re: RFR 8221507: Implement JFR Events for Shenandoah > > > > > > Thank you for the review again. > > > > > > Yes, not sure regarding backporting plans but I imagine it will be in > the > > > future so seemed best to avoid anything that cause issues such as > Set.of(). > > > > > > I also think the naming of the jfr's is fine as it's stored in a folder > > > named after the test which was easily found now that I'm aware that the > > > jfrs are already dumped. > > > > > > I believe I've addressed the rest of your recommended changes to the > > tests, > > > let me know if I've covered everything. > > > > > > http://cr.openjdk.java.net/~kdobson/eventswithtests/webrev/ > > > > > > Thanks, > > > > > > Ken Dobson > > > > > > On Sun, May 12, 2019 at 8:28 PM Erik Gahlin > > wrote: > > > > > > > Thanks for fixing! > > > > > > > > Product code looks good, but I think tests could be improved. > > > > > > > > There is no need to call dump in a final clause. > > > > > > > > Events.fromRecording(...) will dump the file into the jtreg scratch > > > > directory ( "recording-1-pid-xxx.jfr") by default. I think this is > > > > sufficient since there is only one recording per test. If you think > the > > > > name is cryptic, consider adding another method to > Event.fromRecording > > > that > > > > takes an additional parameter that becomes a suffix, i.e > > > > "recording-1-pid-xxx-test-heap-region-info.jfr" > > > > > > > > try (Recording r = new recording()) { > > > > r.enable(EVENT_NAME); > > > > r.start(); > > > > r.stop() > > > > List events = Events.fromRecording(r); > > > > Events.hasEvents(events); > > > > for (RecordedEvent event : events) { > > > > Events.assertField(event, "index").notEqual(-1); > > > > Events.assertField(event, "used").atMost(1024*1024L); > > > > String state = Events.assertField(event, "state").getValue(); > > > > GCHelper.assertShenandoahHeapRegionState(state)); > > > > } > > > > > > > > The name of the field in metadata.xml is "state", but the tests > looks for > > > > "type". That seems incorrect. > > > > > > > > GCHelper: > > > > > > > > public static assertShenandoahHeapRegionState(String state) { > > > > if (!shenandoahHeapRegionStates.contains(state)) { > > > > throw new AssertionError("Unknown state '"+ state +"', valid heap > > > > region states are " + shenandoahHeapRegionStates); > > > > } > > > > > > > > I assume you don't use Set.of("Empty Uncommitted" , ... , "Trash") > > > > because you want to backport to JDK 8. > > > > > > > > Thanks > > > > Erik > > > > > > > > Thanks everyone for their reviews. I've added tests similar to the > tests > > > > for the G1 events as well as addressed the changes that Erik > > > recommended. > > > > > > > > Here is the new webrev: > > > > > > > > > http://cr.openjdk.java.net/~kdobson/shenandoaheventswithtests/webrev/ > > > > > > > > Please let me know if there's anything else that should be addressed. > > > > > > > > Thanks, > > > > > > > > Ken Dobson > > > > > > > > On Mon, May 6, 2019 at 11:38 AM > > > wrote: > > > > > > > >> > > > >> > > > >> On 5/4/19 2:16 PM, Erik Gahlin wrote: > > > >> > On 2019-05-04 00:19, mikhailo.seledtsov at oracle.com wrote: > > > >> >> Hi, > > > >> >> > > > >> >> If possible and feasible, could you please implement tests for > new > > > >> >> events? > > > >> >> > > > >> >> Please place the tests under test/jdk/jdk/jfr/event/gc/. Perhaps > > > >> >> create a "shenandoah" subfolder. > > > >> >> > > > >> >> If the events are too hard to test or not feasible, please add > the > > > >> >> event names to > > > >> >> test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java, > > to > > > >> >> the hardToTestEvents set. Consider commenting why it is too hard > to > > > >> >> test. > > > >> > > > > >> > If events are are marked experimental, tests are ignored by > > > >> > TestLookForUntestedEvents. java, so we should not add them to the > > > >> > hardToTestEvents set. That may help them pass under the radar once > > > the > > > >> > experimental attribute is removed. > > > >> Thank you. If the events are "experimental" this approach makes > sense. > > > >> Once the experimental status is removed, the > > > >> TestLookForUntestedEvents.java should be able to notice if the > event is > > > >> not covered by tests. > > > >> > That said, tests never hurts, even if they are experimental. I > think > > > >> > test/jdk/jdk/jfr/event/gc/detailed would be a good place > > > >> +1 > > > >> > > > >> Thank you, > > > >> Misha > > > >> > > > > >> > Erik > > > >> > > > > >> >> > > > >> >> Also, please make sure to run all jfr tests under > test/jdk/jdk/jfr/ > > > >> >> prior to integration. > > > >> >> > > > >> >> > > > >> >> Best regards, > > > >> >> > > > >> >> Misha > > > >> >> > > > >> >> > > > >> >> > > > >> >> On 5/3/19 7:44 AM, Ken Dobson wrote: > > > >> >>> Hi all, > > > >> >>> > > > >> >>> Please review this patch that adds support for two new JFR > events > > > >> >>> ShenandoahHeapRegionStateChange and > > > ShenandoahHeapRegionInformation. > > > >> >>> > > > >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221507 > > > >> >>> Webrev: http://cr.openjdk.java.net/~kdobson/53476/webrev/ > > > >> >>> > > > >> >>> The Shenandoah team has also reviewed this patch and approved it > > > >> >>> from their > > > >> >>> end. > > > >> >>> > > > >> >>> Thanks, > > > >> >>> > > > >> >>> Ken Dobson > > > >> >> > > > >> > > > > >> > > > >> > > > > > From shade at redhat.com Wed May 22 07:02:51 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 May 2019 09:02:51 +0200 Subject: RFR(XS): 8224573: Fix windows build after JDK-8221507 In-Reply-To: References: Message-ID: <576c1f88-ba2b-82cc-c604-ebbb0416ca30@redhat.com> On 5/22/19 8:59 AM, Thomas St?fe wrote: > 32bit should be enough for number of regions I think. If I am not mistaken, > they have a min region size of 256K, so this covers a heap of ~1000 tb? Yes, u4 should be enough. That would require some light metadata refactoring and testing, so I am fine with doing that in a separate follow-up fix. -Aleksey From david.holmes at oracle.com Wed May 22 07:10:27 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 May 2019 17:10:27 +1000 Subject: RFR: 8224221: add memprotect calls to event log In-Reply-To: References: <7cf56a2b-5da9-d351-3590-ad9114446b7c@oracle.com> Message-ID: <062231d2-7721-31e6-ca38-5d725cc61b59@oracle.com> Hi Matthias, On 21/05/2019 9:24 pm, Baesken, Matthias wrote: > Hello David, thanks for your comments. > > I see no "flooding" of the event log, of course a few more events occur but not just mprotect events are seen . That's good to know. > Regarding the event init - routines : > I had a bit of trouble with the order of inits + usages , so I changed back to the original coding ; > then I had to add checks to events.hpp / cpp so that I do not log to a yet uninitialized event infrastructure in early startup but I think the added checks are good to have . It should be easy enough to determine where the first mprotect call happens and so determine where in the init sequence event_init() needs to go. Now it still may be that it can't go there because of other initialization dependencies, and so your initialization guards are still needed, but I'd rather we understood the initialization dependencies fully. > I adjusted the "small nit" regarding output - good point . Thanks for fixing. > Regarding the missing logs in os_bsd.cpp you mentioned : > I think they are bsd only and I have no machine here to test - should I still add them and hope that it works ? Yes please. To me it's better to find out later that there is a problem than to omit it, as there is no way to recognize that it has in fact been omitted. > > Fixed the solaris issue. Thanks, David ----- > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224221.2/ > > > > Best regards, Matthias > >> >> On 21/05/2019 1:08 am, Baesken, Matthias wrote: >>> Hello, please review this small changeset . >>> >>> 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 memory protection events to the current set or events >> added by calling Events::log . >>> (we had this for a long time in our proprietary VM and would like to have >> it in Open JDK too ) >> >> So extra events will now be generated so you doubled the size of the >> buffer - any info on how this impacts the events that may get captured? >> How often do mprotect events happen? Might we always see 20 mprotect >> events and nothing else of interest? Just wondering (I never use this >> event stuff myself). >> >>> Bug/webrev : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8224221 >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8224221.0/ >> >> Nit: "with protections %d" doesn't read right to me as "protection" is >> not a noun. How about "with protection modes %d" or "with protection >> bits %d"? (It would be nice if you could print a symbolic representation >> of the bits rather than just the raw value - and %x may be better than >> %d for the raw value.) >> >> --- >> >> src/hotspot/os/bsd/os_bsd.cpp >> >> The log event should be using bottom and bottom+size for its range. >> >> You didn't log these additional ::mprotect calls: >> >> 1936 if (::mprotect(addr, size, prot) == 0) { >> 2020 return ::mprotect(addr, size, PROT_NONE) == 0; >> >> --- >> >> src/hotspot/os/linux/os_linux.cpp >> >> The log event should be using bottom and bottom+size for its range. >> >> --- >> >> src/hotspot/os/solaris/os_solaris.cpp >> >> There is no "size" variable, it's called "bytes". >> >> It's odd that the Solaris polling_page routines call mprotect directly >> rather than solaris_mprotect. That gave you the opportunity to be more >> specific about logging those events on Solaris, but the other platforms >> miss out. Overall the use of mprotect/_mprotect/guard_memory is a >> bit of a mess. :( >> >> --- >> >> src/hotspot/share/runtime/thread.cpp >> >> jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) { >> + eventlog_init(); >> >> You've made eventlog_init() the very first thing we now do in VM >> initialization which raises a number of issues for me: >> >> - is everything it does actually safe to do with ZERO other VM >> initialization having occurred? I don't see how as it uses a Mutex when >> constructing EventLogBase and mutex initialization has not yet occurred! >> >> - we will always initialize the Event logs because we won't yet have >> processed the parameters that may turn of LogEvents. >> >> I think the initialization placement needs re-examination. When does the >> first mprotect call occur? I'd take a guess it would be for the guard >> pages of the main thread when it attaches. >> > From christoph.langer at sap.com Wed May 22 07:17:00 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 22 May 2019 07:17:00 +0000 Subject: RFR(XS): 8224573: Fix windows build after JDK-8221507 In-Reply-To: <576c1f88-ba2b-82cc-c604-ebbb0416ca30@redhat.com> References: <576c1f88-ba2b-82cc-c604-ebbb0416ca30@redhat.com> Message-ID: OK, thanks guys. Will push after my builds are done. > -----Original Message----- > From: Aleksey Shipilev > Sent: Mittwoch, 22. Mai 2019 09:03 > To: Thomas St?fe ; Langer, Christoph > > Cc: hotspot-jfr-dev at openjdk.java.net; Ken Dobson > ; hotspot-dev at openjdk.java.net > Subject: Re: RFR(XS): 8224573: Fix windows build after JDK-8221507 > > On 5/22/19 8:59 AM, Thomas St?fe wrote: > > 32bit should be enough for number of regions I think. If I am not mistaken, > > they have a min region size of 256K, so this covers a heap of ~1000 tb? > > Yes, u4 should be enough. That would require some light metadata > refactoring and testing, so I am > fine with doing that in a separate follow-up fix. > > -Aleksey From shade at redhat.com Wed May 22 07:40:26 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 May 2019 09:40:26 +0200 Subject: RFR (S) 8224522: Shenandoah should apply barriers on deoptimization In-Reply-To: References: Message-ID: <2301c8d8-f7dc-1d7d-cf9a-3e20bdf1a079@redhat.com> On 5/21/19 10:06 PM, Aleksey Shipilev wrote: > Fix: > http://cr.openjdk.java.net/~shade/8224522/webrev.01/ jdk-submit came clean. I am going to push it today. -- Thanks, -Aleksey From stefan.karlsson at oracle.com Wed May 22 11:46:02 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 22 May 2019 13:46:02 +0200 Subject: RFC: 8224599: Remove globals_ext.hpp Message-ID: <32401252-77fc-0c34-c7e6-7b97e11e6487@oracle.com> Hi all, Is anyone using globals_ext.hpp? If not, I propose that we remove it and clean up the code using it. http://cr.openjdk.java.net/~stefank/8224599/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8224599 Since globals_ext.hpp pulled in jvmFlag.hpp, I had to fix some includes and forward declarations. Thanks, StefanK From stefan.karlsson at oracle.com Wed May 22 11:58:27 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 22 May 2019 13:58:27 +0200 Subject: RFC: 8224599: Remove globals_ext.hpp In-Reply-To: <32401252-77fc-0c34-c7e6-7b97e11e6487@oracle.com> References: <32401252-77fc-0c34-c7e6-7b97e11e6487@oracle.com> Message-ID: <1a2b5561-15ed-1cb1-da00-c42de7b9b4c5@oracle.com> I realized that some of the globals_ext code had been placed in os_ext.hpp and not only in globals_ext.hpp. If it's appropriate, I've included it in this RFC: http://cr.openjdk.java.net/~stefank/8224599/webrev.02.delta/ http://cr.openjdk.java.net/~stefank/8224599/webrev.02/ If not, I can send out a new RFC for that part. Thanks, StefanK On 2019-05-22 13:46, Stefan Karlsson wrote: > Hi all, > > Is anyone using globals_ext.hpp? If not, I propose that we remove it and > clean up the code using it. > > http://cr.openjdk.java.net/~stefank/8224599/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8224599 > > Since globals_ext.hpp pulled in jvmFlag.hpp, I had to fix some includes > and forward declarations. > > Thanks, > StefanK From coleen.phillimore at oracle.com Wed May 22 12:04:01 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 22 May 2019 08:04:01 -0400 Subject: RFC: 8224599: Remove globals_ext.hpp In-Reply-To: <1a2b5561-15ed-1cb1-da00-c42de7b9b4c5@oracle.com> References: <32401252-77fc-0c34-c7e6-7b97e11e6487@oracle.com> <1a2b5561-15ed-1cb1-da00-c42de7b9b4c5@oracle.com> Message-ID: On 5/22/19 7:58 AM, Stefan Karlsson wrote: > I realized that some of the globals_ext code had been placed in > os_ext.hpp and not only in globals_ext.hpp. > > If it's appropriate, I've included it in this RFC: > ?http://cr.openjdk.java.net/~stefank/8224599/webrev.02.delta/ > ?http://cr.openjdk.java.net/~stefank/8224599/webrev.02/ > > If not, I can send out a new RFC for that part. I think combined looks fine.? It's not large.? It's a nice cleanup if the OpenJDK world doesn't use it. Coleen > > Thanks, > StefanK > > On 2019-05-22 13:46, Stefan Karlsson wrote: >> Hi all, >> >> Is anyone using globals_ext.hpp? If not, I propose that we remove it >> and clean up the code using it. >> >> http://cr.openjdk.java.net/~stefank/8224599/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8224599 >> >> Since globals_ext.hpp pulled in jvmFlag.hpp, I had to fix some >> includes and forward declarations. >> >> Thanks, >> StefanK From shade at redhat.com Wed May 22 14:39:27 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 May 2019 16:39:27 +0200 Subject: RFR (S) 8224522: Shenandoah should apply barriers on deoptimization In-Reply-To: <2301c8d8-f7dc-1d7d-cf9a-3e20bdf1a079@redhat.com> References: <2301c8d8-f7dc-1d7d-cf9a-3e20bdf1a079@redhat.com> Message-ID: On 5/22/19 9:40 AM, Aleksey Shipilev wrote: > On 5/21/19 10:06 PM, Aleksey Shipilev wrote: >> Fix: >> http://cr.openjdk.java.net/~shade/8224522/webrev.01/ > > jdk-submit came clean. I am going to push it today. Ah no, I have only one reviewer yet (rkennke), and this is a shared code change. I'd like somebody else to take a look as well. -Aleksey From matthias.baesken at sap.com Wed May 22 14:54:09 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 22 May 2019 14:54:09 +0000 Subject: RFR: 8224221: add memprotect calls to event log In-Reply-To: <062231d2-7721-31e6-ca38-5d725cc61b59@oracle.com> References: <7cf56a2b-5da9-d351-3590-ad9114446b7c@oracle.com> <062231d2-7721-31e6-ca38-5d725cc61b59@oracle.com> Message-ID: Hi David , I added the missing bsd-related Events::log calls . Additionally I added calls to bool os::guard_memory(char* addr, size_t bytes) and bool os::unguard_memory(char* addr, size_t bytes) on Windows . Regarding the event log initialization - I think it is better to keep the init where it is for now , moving it in front of other inits just leads to asserts and crashes so I think it is out of scope of the CR to redo the whole init process . New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8224221.3/ Best regards, Matthias > Hi Matthias, > > On 21/05/2019 9:24 pm, Baesken, Matthias wrote: > > Hello David, thanks for your comments. > > > > I see no "flooding" of the event log, of course a few more events occur > but not just mprotect events are seen . > > That's good to know. > > > Regarding the event init - routines : > > I had a bit of trouble with the order of inits + usages , so I changed back to > the original coding ; > > then I had to add checks to events.hpp / cpp so that I do not log to a > yet uninitialized event infrastructure in early startup but I think the added > checks are good to have . > > It should be easy enough to determine where the first mprotect call > happens and so determine where in the init sequence event_init() needs > to go. Now it still may be that it can't go there because of other > initialization dependencies, and so your initialization guards are still > needed, but I'd rather we understood the initialization dependencies fully. > > > I adjusted the "small nit" regarding output - good point . > > Thanks for fixing. > > > Regarding the missing logs in os_bsd.cpp you mentioned : > > I think they are bsd only and I have no machine here to test - should I still > add them and hope that it works ? > > Yes please. To me it's better to find out later that there is a problem > than to omit it, as there is no way to recognize that it has in fact > been omitted. > From vladimir.kozlov at oracle.com Wed May 22 14:55:29 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 May 2019 07:55:29 -0700 Subject: RFC: 8224599: Remove globals_ext.hpp In-Reply-To: <1a2b5561-15ed-1cb1-da00-c42de7b9b4c5@oracle.com> References: <32401252-77fc-0c34-c7e6-7b97e11e6487@oracle.com> <1a2b5561-15ed-1cb1-da00-c42de7b9b4c5@oracle.com> Message-ID: I think we should clean up all places. I vote for v02. Thanks, Vladimir On 5/22/19 4:58 AM, Stefan Karlsson wrote: > I realized that some of the globals_ext code had been placed in os_ext.hpp and not only in globals_ext.hpp. > > If it's appropriate, I've included it in this RFC: > ?http://cr.openjdk.java.net/~stefank/8224599/webrev.02.delta/ > ?http://cr.openjdk.java.net/~stefank/8224599/webrev.02/ > > If not, I can send out a new RFC for that part. > > Thanks, > StefanK > > On 2019-05-22 13:46, Stefan Karlsson wrote: >> Hi all, >> >> Is anyone using globals_ext.hpp? If not, I propose that we remove it and clean up the code using it. >> >> http://cr.openjdk.java.net/~stefank/8224599/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8224599 >> >> Since globals_ext.hpp pulled in jvmFlag.hpp, I had to fix some includes and forward declarations. >> >> Thanks, >> StefanK From gerard.ziemski at oracle.com Wed May 22 15:07:19 2019 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Wed, 22 May 2019 10:07:19 -0500 Subject: RFC: 8224599: Remove globals_ext.hpp In-Reply-To: <1a2b5561-15ed-1cb1-da00-c42de7b9b4c5@oracle.com> References: <32401252-77fc-0c34-c7e6-7b97e11e6487@oracle.com> <1a2b5561-15ed-1cb1-da00-c42de7b9b4c5@oracle.com> Message-ID: <00cf5fb9-0408-e8d8-d97a-e0d05def7dd7@oracle.com> Looks good. Thank you for cleaning this up. cheers On 5/22/19 6:58 AM, Stefan Karlsson wrote: > I realized that some of the globals_ext code had been placed in > os_ext.hpp and not only in globals_ext.hpp. > > If it's appropriate, I've included it in this RFC: > ?http://cr.openjdk.java.net/~stefank/8224599/webrev.02.delta/ > ?http://cr.openjdk.java.net/~stefank/8224599/webrev.02/ > > If not, I can send out a new RFC for that part. > > Thanks, > StefanK > > On 2019-05-22 13:46, Stefan Karlsson wrote: >> Hi all, >> >> Is anyone using globals_ext.hpp? If not, I propose that we remove it >> and clean up the code using it. >> >> http://cr.openjdk.java.net/~stefank/8224599/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8224599 >> >> Since globals_ext.hpp pulled in jvmFlag.hpp, I had to fix some >> includes and forward declarations. >> >> Thanks, >> StefanK > From vladimir.x.ivanov at oracle.com Wed May 22 16:58:21 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 22 May 2019 19:58:21 +0300 Subject: [13] RFR (M): 8223213: Implement fast class initialization checks on x86-64 In-Reply-To: References: <85a4a478-9200-87f2-c966-49af21f687c2@oracle.com> <3e1ceae0-f7a9-e2e6-2b06-59a22540550d@oracle.com> <3d9c0897-0275-c341-fe33-5f0b6c94f253@oracle.com> Message-ID: <42a8fc79-9497-b2eb-8dd9-a56e4ed85255@oracle.com> >>> Forgot to mention that your new test doesn't look like it will play >>> nicely when run with Graal enabled, so you may need to split up into >>> different @test sections and add "@requires !vm.graal.enabled" to >>> exclude graal. >> >> What kind of problem when running with Graal do you have in mind? >> >> I double-checked that the test passes with Graal enabled. > > Your various @run lines are trying to execute in different compilation > modes: -Xint, C1 only, C2 only, plus various permutations. If you take > those command-lines and then add all the Graal flags to it then you are > no longer testing any of the things you wanted to test. At best you test > Graal 7 times - which is pointless. At worst you may find some > variations will timeout when Graal is applied. The test explicitly checks class initialization invariants and specifies execution modes to stress different scenarios. It doesn't explicitly specify C2: it just runs with -XX:-TieredCompilation and Graal is used if it is set as top-tier compiler. For other modes (interpreter & C1), whether C2 or Graal are used is irrelevant. But I take your point: -XX:-TieredCompilation is much slower with Graal and doesn't test the logic as intended (no relevant compiled code generated). So I'll add "@requires !vm.graal.enabled" as you suggest. (Will update the webrev in-place.) > For that matter an Xcomp run will also negate your intentions. With -Xcomp it works as intended except pre-warmup phase, but there's a dedicated -Xint run mode which covers that. So I don't think it's necessary to exclude the test when -Xcomp is specified. Best regards, Vladimir Ivanov >>>> I'll be very happy to see this go in - though I do wish we had more >>>> platform coverage than just x86_64. Hopefully the other archs will >>>> jump on-board with this as well. >> >> Yes, fully agree with you. It should be pretty straightforward for >> maintainers to mirror x86-specific changes for their architectures. >> >>>> I was initially confused by the UseFastClassInitChecks flag as I >>>> couldn't really see why you would want to turn it off (other than >>>> perhaps during testing) but I see that it is really used (as you >>>> explained to Vladimir K.) to exclude the new code for platforms >>>> which have not implemented it. Though I'm still not sure that we >>>> shouldn't have something to detect it being turned on at runtime on >>>> platforms that don't support it (it will likely crash quickly but >>>> still ...). Keep wondering if there is a better way to handle this >>>> aspect of the change ... >> >> I deliberately made the flag develop, so it's possible to change it >> from command-line only in debug builds. I could introduce additional >> platform-specific validation, but it doesn't look worth the effort for >> such narrow case (and there are other develop flags which guard broken >> functionality). >> >>>> I can't comment on the actual interpreter and compiler changes - sorry. >> >> No problem, I'll wait for more reviews from Runtime team. >> >>>> This will need re-basing now that JDK-8219974 has been backed out. >> >> Done. >> >> Best regards, >> Vladimir Ivanov >> >>>> On 2/05/2019 9:17 am, Vladimir Ivanov wrote: >>>>> http://cr.openjdk.java.net/~vlivanov/8223213/webrev.00/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8223213 >>>>> >>>>> (It's a followup RFR on a earlier RFC [1].) >>>>> >>>>> Recent changes severely affected how static initializers are >>>>> executed and for long-running initializers it manifested as a >>>>> severe slowdown. >>>>> As an example, it led to a 3x slowdown on some Clojure applications >>>>> (JDK-8219233 [2]). The root cause is that until a class is fully >>>>> initialized, every invocation of static method on it goes through >>>>> method resolution. >>>>> >>>>> Proposed fix introduces fast class initialization barriers for C1, >>>>> C2, and template interpreter on x86-64. I did some experiments with >>>>> cross-platform approaches, but haven't got satisfactory results. >>>>> >>>>> On other platforms, behavior stays (mostly) intact. (I had to >>>>> revert some changes introduced by JDK-8219492 [3], since the >>>>> assumptions they rely on about accesses inside a class don't hold >>>>> in all cases.) >>>>> >>>>> The barrier is as simple as: >>>>> ??? if (holder->is_not_initialized() && >>>>> ??????? !holder->is_reentrant_initialization(current_thread)) { >>>>> ????? // trigger call site re-resolution and block there >>>>> ??? } >>>>> >>>>> There are 3 places where barriers are added: >>>>> ?? * in template interpreter for invokestatic bytecode; >>>>> ?? * at nmethod verified entry point (for normal compilations); >>>>> ?? * c2i adapters; >>>>> >>>>> For template interperter, there's additional check added into >>>>> TemplateTable::resolve_cache_and_index which calls into >>>>> InterpreterRuntime::resolve_from_cache when fast path checks fail. >>>>> >>>>> In case of nmethods, the barrier is put before frame construction, >>>>> so existing compiler runtime routines can be reused >>>>> (SharedRuntime::get_handle_wrong_method_stub()). >>>>> >>>>> Also, C2 has a guard on entry (Parse::clinit_deopt()) which >>>>> triggers nmethod recompilation once the class is fully initialized. >>>>> >>>>> OSR compilations don't need a barrier. >>>>> >>>>> Correspondence between barriers and transitions they cover: >>>>> ?? (1) from interpreter (barrier on caller side) >>>>> ??????? * all transitions: interpreter, compiled (i2c), native, >>>>> aot, ... >>>>> >>>>> ?? (2) from compiled (barrier on callee side) >>>>> ??????? to compiled, to native (barrier in native wrapper on entry) >>>>> >>>>> ?? (3) c2i bypasses both barriers (interpreter and compiled) and >>>>> requires a dedicated barrier in c2i >>>>> >>>>> ?? (4) to Graal/AOT code: >>>>> ???????? from interpreter: covered by interpreter barrier >>>>> ???????? from compiled: call site patching is disabled, leading to >>>>> repeated call site resolution until method holder is fully >>>>> initialized (original behavior). >>>>> >>>>> Performance experiments with clojure [2] demonstrated that the fix >>>>> almost completely recuperates the regression: >>>>> >>>>> ?? (1) always reresolve (w/o the fix):??? ~12,0s ( 1x) >>>>> ?? (2) C1/C2 barriers only:??????????????? ~3,8s (~3x) >>>>> ?? (3) int/C1/C2 barriers:???????????????? ~3,2s (-20%) >>>>> -------- >>>>> ?? (4) barriers disabled for invokestatic? ~3,2s >>>>> >>>>> I deliberately tried to keep the patch backport-friendly for >>>>> 8u/11u/12u and refrained from using newer features like nmethod >>>>> barriers introduced recently. The fix can be refactored later >>>>> specifically for 13 as a followup change. >>>>> >>>>> Testing: clojure startup, tier1-5 >>>>> >>>>> Thanks! >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> [1] >>>>> https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-April/037760.html >>>>> >>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8219233 >>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8219492 From zgu at redhat.com Wed May 22 18:42:58 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 22 May 2019 14:42:58 -0400 Subject: RFR (S) 8224522: Shenandoah should apply barriers on deoptimization In-Reply-To: References: <2301c8d8-f7dc-1d7d-cf9a-3e20bdf1a079@redhat.com> Message-ID: Looks good. -Zhengyu On 5/22/19 10:39 AM, Aleksey Shipilev wrote: > On 5/22/19 9:40 AM, Aleksey Shipilev wrote: >> On 5/21/19 10:06 PM, Aleksey Shipilev wrote: >>> Fix: >>> http://cr.openjdk.java.net/~shade/8224522/webrev.01/ >> >> jdk-submit came clean. I am going to push it today. > > Ah no, I have only one reviewer yet (rkennke), and this is a shared code change. I'd like somebody > else to take a look as well. > > -Aleksey > From shade at redhat.com Wed May 22 20:19:38 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 May 2019 22:19:38 +0200 Subject: RFR (S) 8224522: Shenandoah should apply barriers on deoptimization In-Reply-To: References: <2301c8d8-f7dc-1d7d-cf9a-3e20bdf1a079@redhat.com> Message-ID: Thanks, pushed. -Aleksey On 5/22/19 8:42 PM, Zhengyu Gu wrote: > Looks good. > > -Zhengyu > > On 5/22/19 10:39 AM, Aleksey Shipilev wrote: >> On 5/22/19 9:40 AM, Aleksey Shipilev wrote: >>> On 5/21/19 10:06 PM, Aleksey Shipilev wrote: >>>> Fix: >>>> ?? http://cr.openjdk.java.net/~shade/8224522/webrev.01/ >>> >>> jdk-submit came clean. I am going to push it today. >> >> Ah no, I have only one reviewer yet (rkennke), and this is a shared code change. I'd like somebody >> else to take a look as well. From david.holmes at oracle.com Wed May 22 22:29:53 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 May 2019 08:29:53 +1000 Subject: RFR: 8224221: add memprotect calls to event log In-Reply-To: References: <7cf56a2b-5da9-d351-3590-ad9114446b7c@oracle.com> <062231d2-7721-31e6-ca38-5d725cc61b59@oracle.com> Message-ID: <8690a635-a878-32f9-e106-6d2c0d3493c2@oracle.com> On 23/05/2019 12:54 am, Baesken, Matthias wrote: > Hi David , > I added the missing bsd-related Events::log calls . Thanks. > Additionally I added calls to > bool os::guard_memory(char* addr, size_t bytes) > and > bool os::unguard_memory(char* addr, size_t bytes) > > on Windows . This is starting to look a bit inconsistent. If you want to log VirtualProtect calls then there are more of them than just in guard_memory and unguard_memory. So I'm unclear on the intent here - is it to log all "memory protection" actions or only to log those that pertain to specific semantic actions? On linux we have a split between use of mprotect and use of mmap and this change only logs mprotect on Linux; but those same semantics actions e.g. pd_commit_memory, on Windows use VirtualProtect. > Regarding the event log initialization - I think it is better to keep the init where it is for now , moving it in front of other inits just leads to asserts and crashes > so I think it is out of scope of the CR to redo the whole init process . I'm not asking you to do that. I'm asking you to determine what init dependencies your change actually has. If you keep the init where it is you may miss logging some early mprotect usages (of course there's no guarantee you can log them all if the init dependencies can't be resolved) David ----- > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224221.3/ > > > Best regards, Matthias > > > >> Hi Matthias, >> >> On 21/05/2019 9:24 pm, Baesken, Matthias wrote: >>> Hello David, thanks for your comments. >>> >>> I see no "flooding" of the event log, of course a few more events occur >> but not just mprotect events are seen . >> >> That's good to know. >> >>> Regarding the event init - routines : >>> I had a bit of trouble with the order of inits + usages , so I changed back to >> the original coding ; >>> then I had to add checks to events.hpp / cpp so that I do not log to a >> yet uninitialized event infrastructure in early startup but I think the added >> checks are good to have . >> >> It should be easy enough to determine where the first mprotect call >> happens and so determine where in the init sequence event_init() needs >> to go. Now it still may be that it can't go there because of other >> initialization dependencies, and so your initialization guards are still >> needed, but I'd rather we understood the initialization dependencies fully. >> >>> I adjusted the "small nit" regarding output - good point . >> >> Thanks for fixing. >> >>> Regarding the missing logs in os_bsd.cpp you mentioned : >>> I think they are bsd only and I have no machine here to test - should I still >> add them and hope that it works ? >> >> Yes please. To me it's better to find out later that there is a problem >> than to omit it, as there is no way to recognize that it has in fact >> been omitted. >> > From thomas.stuefe at gmail.com Thu May 23 00:36:41 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 23 May 2019 02:36:41 +0200 Subject: RFR: CSR: 8224601: Provide VM.events diagnostic command In-Reply-To: References: Message-ID: (Redirected to hs-dev as requested). On Wed 22. May 2019 at 13:50, Thomas St?fe wrote: > Hi all, > > could I please have opinions and a reviewer for the following CSR: > > https://bugs.openjdk.java.net/browse/JDK-8224601 > > which aims to add a dedicated "VM.events" command to jcmd to print out VM > event logs. > > Thanks, Thomas > From david.holmes at oracle.com Thu May 23 01:13:35 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 May 2019 11:13:35 +1000 Subject: RFR: CSR: 8224601: Provide VM.events diagnostic command In-Reply-To: References: Message-ID: <6d817632-e7de-3e43-c1f8-585b3a48be43@oracle.com> Hi Thomas, This seems quite a reasonable request to me. I've added myself as a reviewer of the CSR request. David On 23/05/2019 10:36 am, Thomas St?fe wrote: > (Redirected to hs-dev as requested). > > On Wed 22. May 2019 at 13:50, Thomas St?fe wrote: > >> Hi all, >> >> could I please have opinions and a reviewer for the following CSR: >> >> https://bugs.openjdk.java.net/browse/JDK-8224601 >> >> which aims to add a dedicated "VM.events" command to jcmd to print out VM >> event logs. >> >> Thanks, Thomas >> From thomas.stuefe at gmail.com Thu May 23 02:52:01 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 23 May 2019 04:52:01 +0200 Subject: RFR: CSR: 8224601: Provide VM.events diagnostic command In-Reply-To: <6d817632-e7de-3e43-c1f8-585b3a48be43@oracle.com> References: <6d817632-e7de-3e43-c1f8-585b3a48be43@oracle.com> Message-ID: Thank you David! On Thu 23. May 2019 at 03:13, David Holmes wrote: > Hi Thomas, > > This seems quite a reasonable request to me. I've added myself as a > reviewer of the CSR request. > > David > > On 23/05/2019 10:36 am, Thomas St?fe wrote: > > (Redirected to hs-dev as requested). > > > > On Wed 22. May 2019 at 13:50, Thomas St?fe > wrote: > > > >> Hi all, > >> > >> could I please have opinions and a reviewer for the following CSR: > >> > >> https://bugs.openjdk.java.net/browse/JDK-8224601 > >> > >> which aims to add a dedicated "VM.events" command to jcmd to print out > VM > >> event logs. > >> > >> Thanks, Thomas > >> > From igor.ignatyev at oracle.com Thu May 23 05:20:05 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 22 May 2019 22:20:05 -0700 Subject: RFR(L/XS) : 8222414 : bring googlemock v1.8.1 Message-ID: <179E2496-5149-4521-896D-01E3B216A48F@oracle.com> http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 > 21638 lines changed: 21628 ins; 0 del; 10 mod; Hi all, could you please review this patch which makes mocking framework from google test available for hotspot tests? JBS: https://bugs.openjdk.java.net/browse/JDK-8222414 testing: tier1 webrevs: - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.00 > 21605 lines changed: 21605 ins; 0 del; 0 mod; * moves gtest from test/fmw/gtest to test/fmw/gtest/googletest; * adds only required (w/o build-aux, docs, make, msvc, scripts, tests directories and make related files) source of gmock to test/fmw/gtest/googlemock; - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.0-1 > 33 lines changed: 23 ins; 0 del; 10 mod; * makes necessary changes in makefiles * calls gmock framework init function * works around the conflict b/w :testing::internal::Log function defined by gmock and Log macro defined by hotspot - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 > 21638 lines changed: 21628 ins; 0 del; 10 mod; all the changes together thanks, -- Igor From matthias.baesken at sap.com Thu May 23 07:45:15 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 23 May 2019 07:45:15 +0000 Subject: RFR: 8224221: add memprotect calls to event log In-Reply-To: <8690a635-a878-32f9-e106-6d2c0d3493c2@oracle.com> References: <7cf56a2b-5da9-d351-3590-ad9114446b7c@oracle.com> <062231d2-7721-31e6-ca38-5d725cc61b59@oracle.com> <8690a635-a878-32f9-e106-6d2c0d3493c2@oracle.com> Message-ID: Hi David , > > Additionally I added calls to > > bool os::guard_memory(char* addr, size_t bytes) > > and > > bool os::unguard_memory(char* addr, size_t bytes) > > > > on Windows . > > This is starting to look a bit inconsistent. If you want to log > VirtualProtect calls then there are more of them than just in > guard_memory and unguard_memory. So I'm unclear on the intent here - is > it to log all "memory protection" actions or only to log those that > pertain to specific semantic actions? My Intention was to cover Windows as well, however it looks like there are more VirtualProtect calls (9) in os_windows.cpp than mprotects in os_linux.cpp (just 1 in linux_mprotect). But maybe it is better to omit VirtualProtect / os_windows in this patch , no problem. What do you think ? > On linux we have a split between > use of mprotect and use of mmap and this change only logs mprotect on > Linux; but those same semantics actions e.g. pd_commit_memory, on > Windows use VirtualProtect. > > > Regarding the event log initialization - I think it is better to keep the init > where it is for now , moving it in front of other inits just leads to asserts and > crashes > > so I think it is out of scope of the CR to redo the whole init process . > > I'm not asking you to do that. I'm asking you to determine what init > dependencies your change actually has. If you keep the init where it is > you may miss logging some early mprotect usages (of course there's no > guarantee you can log them all if the init dependencies can't be resolved) > Yes , if I keep the eventlog_init() where it is, I miss a few early mprotect calls . I observed this in our tests . However when moving forward eventlog_init like I did in the first rev. ( http://cr.openjdk.java.net/~mbaesken/webrevs/8224221.0/src/hotspot/share/runtime/thread.cpp.frames.html ) , I run into " assert(os::mutex_init_done()) failed: Too early! " Mutex_init is done in os::init_2 , which is called from Threads::create_vm() { ... 3740 // Initialize the os module after parsing the args 3741 jint os_init_2_result = os::init_2(); 3742 if (os_init_2_result != JNI_OK) return os_init_2_result; ... } So I could place eventlog_init() after os::init_2 instead of the start of Threads::create_vm . 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) ? With the current coding you have deoptimization related logging across both ( Deoptimization events, and general Events) which looks a bit strange to me , example (see the DEOPT ... in the general Event log) : Deoptimization events (20 events): Event: 143.015 Thread 0x00007fffa4588800 Uncommon trap: reason=profile_predicate action=maybe_recompile pc=0x00007fff75354f08 method=sun.java2d.marlin.DHelpers$PolyStack.popAll(Lsun/java2d/marlin/DPathConsumer2D;)V @ 71 c2 Event: 143.661 Thread 0x00007fffa4588800 Uncommon trap: reason=predicate action=maybe_recompile pc=0x00007fff753be9b0 method=sun.font.ExtendedTextSourceLabel.createCharinfo()[F @ 306 c2 Event: 145.350 Thread 0x00007fffa4586800 Uncommon trap: reason=profile_predicate action=maybe_recompile pc=0x00007fff753f363c method=sun.font.ExtendedTextSourceLabel.createCharinfo()[F @ 306 c2 Event: 145.353 Thread 0x00007fffa4586800 Uncommon trap: reason=profile_predicate action=maybe_recompile pc=0x00007fff753f363c method=sun.font.ExtendedTextSourceLabel.createCharinfo()[F @ 306 c2 Event: 145.357 Thread 0x00007fffa4586800 Uncommon trap: reason=profile_predicate action=maybe_recompile pc=0x00007fff753f363c method=sun.font.ExtendedTextSourceLabel.createCharinfo()[F @ 306 c2 Event: 145.359 Thread 0x00007fffa4586800 Uncommon trap: reason=profile_predicate action=maybe_recompile pc=0x00007fff753f363c method=sun.font.ExtendedTextSourceLabel.createCharinfo()[F @ 306 c2 Event: 147.403 Thread 0x00007fffa4021000 Uncommon trap: reason=unstable_if action=reinterpret pc=0x00007fff751d8e44 method=sun.util.calendar.BaseCalendar$Date.hit(I)Z @ 5 c2 Event: 147.403 Thread 0x00007fffa4021000 Uncommon trap: reason=unstable_if action=reinterpret pc=0x00007fff7531a80c method=java.util.GregorianCalendar.getWeekNumber(JJ)I @ 48 c2 Event: 147.403 Thread 0x00007fffa4021000 Uncommon trap: reason=unstable_if action=reinterpret pc=0x00007fff752c76b4 method=java.util.Calendar.setTimeInMillis(J)V @ 6 c2 Event: 147.404 Thread 0x00007fffa4021000 Uncommon trap: reason=unstable_if action=reinterpret pc=0x00007fff750de4c4 method=java.util.GregorianCalendar.getWeekNumber(JJ)I @ 48 c2 Event: 156.024 Thread 0x00007fffa43fe000 Uncommon trap: reason=unstable_if action=reinterpret pc=0x00007fff752455e8 method=java.lang.Double.compare(DD)I @ 3 c2 Event: 158.698 Thread 0x00007fffa4586800 Uncommon trap: reason=unstable_if action=reinterpret pc=0x00007fff754e1bc8 method=java.util.HashMap.removeNode(ILjava/lang/Object;Ljava/lang/Object;ZZ)Ljava/util/HashMap$Node; @ 89 c2 Event: 175.768 Thread 0x00007fffa43fe000 Uncommon trap: reason=speculate_null_assert action=make_not_entrant pc=0x00007fff74f08890 method=sun.util.locale.LocaleObjectCache.cleanStaleEntries()V @ 12 c2 Event: 176.402 Thread 0x00007fffa43fe000 Uncommon trap: reason=unstable_if action=reinterpret pc=0x00007fff75523338 method=com.crystaldecisions.reports.dataengine.DataContext.fetchGroupPath(I)Lcom/crystaldecisions/reports/common/GroupPath; @ 35 c2 Event: 176.412 Thread 0x00007fffa43fe000 Uncommon trap: reason=range_check action=make_not_entrant pc=0x00007fff754409dc method=sun.font.ExtendedTextSourceLabel.createCharinfo()[F @ 338 c2 Event: 176.439 Thread 0x00007fffa43fe000 Uncommon trap: reason=unstable_if action=reinterpret pc=0x00007fff7550c0ec method=com.crystaldecisions.reports.dataengine.DataProcessor2.getGroupLevelFromCurrentDataPosition()I @ 17 c2 Event: 176.694 Thread 0x00007fffa43fe000 Uncommon trap: reason=profile_predicate action=maybe_recompile pc=0x00007fff7543826c method=java.awt.geom.Path2D$Double.append(Ljava/awt/geom/PathIterator;Z)V @ 11 c2 Event: 176.694 Thread 0x00007fffa43fe000 Uncommon trap: reason=profile_predicate action=maybe_recompile pc=0x00007fff7543826c method=java.awt.geom.Path2D$Double.append(Ljava/awt/geom/PathIterator;Z)V @ 11 c2 Event: 176.698 Thread 0x00007fffa43fe000 Uncommon trap: reason=profile_predicate action=maybe_recompile pc=0x00007fff7543826c method=java.awt.geom.Path2D$Double.append(Ljava/awt/geom/PathIterator;Z)V @ 11 c2 Event: 176.698 Thread 0x00007fffa43fe000 Uncommon trap: reason=profile_predicate action=maybe_recompile pc=0x00007fff7543826c method=java.awt.geom.Path2D$Double.append(Ljava/awt/geom/PathIterator;Z)V @ 11 c2 ...... Events (20 events): Event: 176.694 Thread 0x00007fffa43fe000 DEOPT UNPACKING pc=0x00007fff4c80236c sp=0x00007ffe82b9c000 mode 2 Event: 176.694 Thread 0x00007fffa43fe000 Uncommon trap: trap_request=0xffffffbe fr.pc=0x00007fff7543826c relative=0x000000000000166c Event: 176.694 Thread 0x00007fffa43fe000 DEOPT PACKING pc=0x00007fff7543826c sp=0x00007ffe82b9c1a0 Event: 176.694 Thread 0x00007fffa43fe000 Create unroll information: #vframes=1 pc=0x00007fff7543826c sp=0x00007ffe82b9c1a0 Event: 176.694 Thread 0x00007fffa43fe000 DEOPT UNPACKING pc=0x00007fff4c80236c sp=0x00007ffe82b9c000 mode 2 Event: 176.698 Thread 0x00007fffa43fe000 Uncommon trap: trap_request=0xffffffbe fr.pc=0x00007fff7543826c relative=0x000000000000166c Event: 176.698 Thread 0x00007fffa43fe000 DEOPT PACKING pc=0x00007fff7543826c sp=0x00007ffe82b9bf60 Event: 176.698 Thread 0x00007fffa43fe000 Create unroll information: #vframes=1 pc=0x00007fff7543826c sp=0x00007ffe82b9bf60 Event: 176.698 Thread 0x00007fffa43fe000 DEOPT UNPACKING pc=0x00007fff4c80236c sp=0x00007ffe82b9bdc0 mode 2 Event: 176.698 Thread 0x00007fffa43fe000 Uncommon trap: trap_request=0xffffffbe fr.pc=0x00007fff7543826c relative=0x000000000000166c Event: 176.698 Thread 0x00007fffa43fe000 DEOPT PACKING pc=0x00007fff7543826c sp=0x00007ffe82b9bf80 Event: 176.698 Thread 0x00007fffa43fe000 Create unroll information: #vframes=1 pc=0x00007fff7543826c sp=0x00007ffe82b9bf80 Event: 176.698 Thread 0x00007fffa43fe000 DEOPT UNPACKING pc=0x00007fff4c80236c sp=0x00007ffe82b9bde0 mode 2 Event: 176.946 Executing VM operation: G1CollectForAllocation Event: 176.950 begin safepoint, id: 1171 Event: 177.081 end safepoint, id: 1171 Event: 177.081 Executing VM operation: G1CollectForAllocation done Event: 177.235 Executing VM operation: G1CollectForAllocation Event: 177.236 begin safepoint, id: 1173 Event: 177.408 Protecting memory [0x00007fffac240000,0x00007fffac250000] with protection modes 7 Best regards, Matthias From matthias.baesken at sap.com Thu May 23 08:04:17 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 23 May 2019 08:04:17 +0000 Subject: RFR: CSR: 8224601: Provide VM.events diagnostic command Message-ID: Hi Thomas, I think this is a good enhancement . ( not a Reviewer however ) Looking into the huge VM.info output is not very user friendly ( at least for me ). Best regards, Matthias > Date: Thu, 23 May 2019 02:36:41 +0200 > From: Thomas St?fe > To: HotSpot Open Source Developers > Subject: Re: RFR: CSR: 8224601: Provide VM.events diagnostic command > > (Redirected to hs-dev as requested). > > On Wed 22. May 2019 at 13:50, Thomas St?fe > wrote: > > > Hi all, > > > > could I please have opinions and a reviewer for the following CSR: > > > > https://bugs.openjdk.java.net/browse/JDK-8224601 > > > > which aims to add a dedicated "VM.events" command to jcmd to print out > VM > > event logs. > > > > Thanks, Thomas > > From thomas.stuefe at gmail.com Thu May 23 08:20:16 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 23 May 2019 10:20:16 +0200 Subject: RFR: CSR: 8224601: Provide VM.events diagnostic command In-Reply-To: References: Message-ID: Thank you! David already added himself as a Reviewer, and for a CSR it needs only one. Cheers Thomas On Thu, May 23, 2019 at 10:04 AM Baesken, Matthias wrote: > Hi Thomas, I think this is a good enhancement . > ( not a Reviewer however ) > > Looking into the huge VM.info output is not very user friendly ( at > least for me ). > > > Best regards, Matthias > > > > > Date: Thu, 23 May 2019 02:36:41 +0200 > > From: Thomas St?fe > > To: HotSpot Open Source Developers > > Subject: Re: RFR: CSR: 8224601: Provide VM.events diagnostic command > > > > (Redirected to hs-dev as requested). > > > > On Wed 22. May 2019 at 13:50, Thomas St?fe > > wrote: > > > > > Hi all, > > > > > > could I please have opinions and a reviewer for the following CSR: > > > > > > https://bugs.openjdk.java.net/browse/JDK-8224601 > > > > > > which aims to add a dedicated "VM.events" command to jcmd to print out > > VM > > > event logs. > > > > > > Thanks, Thomas > > > > > From david.holmes at oracle.com Thu May 23 09:53:00 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 May 2019 19:53:00 +1000 Subject: RFR: 8224221: add memprotect calls to event log In-Reply-To: References: <7cf56a2b-5da9-d351-3590-ad9114446b7c@oracle.com> <062231d2-7721-31e6-ca38-5d725cc61b59@oracle.com> <8690a635-a878-32f9-e106-6d2c0d3493c2@oracle.com> Message-ID: On 23/05/2019 5:45 pm, Baesken, Matthias wrote: > Hi David , > >>> Additionally I added calls to >>> bool os::guard_memory(char* addr, size_t bytes) >>> and >>> bool os::unguard_memory(char* addr, size_t bytes) >>> >>> on Windows . >> >> This is starting to look a bit inconsistent. If you want to log >> VirtualProtect calls then there are more of them than just in >> guard_memory and unguard_memory. So I'm unclear on the intent here - is >> it to log all "memory protection" actions or only to log those that >> pertain to specific semantic actions? > > My Intention was to cover Windows as well, however it looks like there are more VirtualProtect calls (9) in os_windows.cpp than mprotects in os_linux.cpp (just 1 in linux_mprotect). > But maybe it is better to omit VirtualProtect / os_windows in this patch , no problem. > What do you think ? I think you need to decide what this work is trying to log - is it "mprotect" calls or is it "memory protection" calls? Or something else. > >> On linux we have a split between >> use of mprotect and use of mmap and this change only logs mprotect on >> Linux; but those same semantics actions e.g. pd_commit_memory, on >> Windows use VirtualProtect. >> >>> Regarding the event log initialization - I think it is better to keep the init >> where it is for now , moving it in front of other inits just leads to asserts and >> crashes >>> so I think it is out of scope of the CR to redo the whole init process . >> >> I'm not asking you to do that. I'm asking you to determine what init >> dependencies your change actually has. If you keep the init where it is >> you may miss logging some early mprotect usages (of course there's no >> guarantee you can log them all if the init dependencies can't be resolved) >> > > Yes , if I keep the eventlog_init() where it is, I miss a few early mprotect calls . > I observed this in our tests . > > However when moving forward eventlog_init like I did in the first rev. ( http://cr.openjdk.java.net/~mbaesken/webrevs/8224221.0/src/hotspot/share/runtime/thread.cpp.frames.html ) , > I run into " assert(os::mutex_init_done()) failed: Too early! " > Mutex_init is done in os::init_2 , which is called from > > Threads::create_vm() { > ... > 3740 // Initialize the os module after parsing the args > 3741 jint os_init_2_result = os::init_2(); > 3742 if (os_init_2_result != JNI_OK) return os_init_2_result; > ... > } > > So I could place eventlog_init() after os::init_2 instead of the start of Threads::create_vm . I added an assert(false) in linux_mprotect to see where it is first called from (not 100% accurate as different flags may trigger other code paths) and found it was called from initialize_assert_poison() here: // Initialize the os module after parsing the args jint os_init_2_result = os::init_2(); if (os_init_2_result != JNI_OK) return os_init_2_result; #ifdef CAN_SHOW_REGISTERS_ON_ASSERT // Initialize assert poison page mechanism. if (ShowRegistersOnAssert) { initialize_assert_poison(); } #endif // CAN_SHOW_REGISTERS_ON_ASSERT So if you move your event_init to before the #ifdef it not only should work okay, but it also shouldn't normally miss any calls to mprotect. Obviously more extensive testing would be needed. > > 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. Cheers, David ----- > With the current coding you have deoptimization related logging across both ( Deoptimization events, and general Events) which looks a bit strange to me , example (see the DEOPT ... in the general Event log) : > > Deoptimization events (20 events): > Event: 143.015 Thread 0x00007fffa4588800 Uncommon trap: reason=profile_predicate action=maybe_recompile pc=0x00007fff75354f08 method=sun.java2d.marlin.DHelpers$PolyStack.popAll(Lsun/java2d/marlin/DPathConsumer2D;)V @ 71 c2 > Event: 143.661 Thread 0x00007fffa4588800 Uncommon trap: reason=predicate action=maybe_recompile pc=0x00007fff753be9b0 method=sun.font.ExtendedTextSourceLabel.createCharinfo()[F @ 306 c2 > Event: 145.350 Thread 0x00007fffa4586800 Uncommon trap: reason=profile_predicate action=maybe_recompile pc=0x00007fff753f363c method=sun.font.ExtendedTextSourceLabel.createCharinfo()[F @ 306 c2 > Event: 145.353 Thread 0x00007fffa4586800 Uncommon trap: reason=profile_predicate action=maybe_recompile pc=0x00007fff753f363c method=sun.font.ExtendedTextSourceLabel.createCharinfo()[F @ 306 c2 > Event: 145.357 Thread 0x00007fffa4586800 Uncommon trap: reason=profile_predicate action=maybe_recompile pc=0x00007fff753f363c method=sun.font.ExtendedTextSourceLabel.createCharinfo()[F @ 306 c2 > Event: 145.359 Thread 0x00007fffa4586800 Uncommon trap: reason=profile_predicate action=maybe_recompile pc=0x00007fff753f363c method=sun.font.ExtendedTextSourceLabel.createCharinfo()[F @ 306 c2 > Event: 147.403 Thread 0x00007fffa4021000 Uncommon trap: reason=unstable_if action=reinterpret pc=0x00007fff751d8e44 method=sun.util.calendar.BaseCalendar$Date.hit(I)Z @ 5 c2 > Event: 147.403 Thread 0x00007fffa4021000 Uncommon trap: reason=unstable_if action=reinterpret pc=0x00007fff7531a80c method=java.util.GregorianCalendar.getWeekNumber(JJ)I @ 48 c2 > Event: 147.403 Thread 0x00007fffa4021000 Uncommon trap: reason=unstable_if action=reinterpret pc=0x00007fff752c76b4 method=java.util.Calendar.setTimeInMillis(J)V @ 6 c2 > Event: 147.404 Thread 0x00007fffa4021000 Uncommon trap: reason=unstable_if action=reinterpret pc=0x00007fff750de4c4 method=java.util.GregorianCalendar.getWeekNumber(JJ)I @ 48 c2 > Event: 156.024 Thread 0x00007fffa43fe000 Uncommon trap: reason=unstable_if action=reinterpret pc=0x00007fff752455e8 method=java.lang.Double.compare(DD)I @ 3 c2 > Event: 158.698 Thread 0x00007fffa4586800 Uncommon trap: reason=unstable_if action=reinterpret pc=0x00007fff754e1bc8 method=java.util.HashMap.removeNode(ILjava/lang/Object;Ljava/lang/Object;ZZ)Ljava/util/HashMap$Node; @ 89 c2 > Event: 175.768 Thread 0x00007fffa43fe000 Uncommon trap: reason=speculate_null_assert action=make_not_entrant pc=0x00007fff74f08890 method=sun.util.locale.LocaleObjectCache.cleanStaleEntries()V @ 12 c2 > Event: 176.402 Thread 0x00007fffa43fe000 Uncommon trap: reason=unstable_if action=reinterpret pc=0x00007fff75523338 method=com.crystaldecisions.reports.dataengine.DataContext.fetchGroupPath(I)Lcom/crystaldecisions/reports/common/GroupPath; @ 35 c2 > Event: 176.412 Thread 0x00007fffa43fe000 Uncommon trap: reason=range_check action=make_not_entrant pc=0x00007fff754409dc method=sun.font.ExtendedTextSourceLabel.createCharinfo()[F @ 338 c2 > Event: 176.439 Thread 0x00007fffa43fe000 Uncommon trap: reason=unstable_if action=reinterpret pc=0x00007fff7550c0ec method=com.crystaldecisions.reports.dataengine.DataProcessor2.getGroupLevelFromCurrentDataPosition()I @ 17 c2 > Event: 176.694 Thread 0x00007fffa43fe000 Uncommon trap: reason=profile_predicate action=maybe_recompile pc=0x00007fff7543826c method=java.awt.geom.Path2D$Double.append(Ljava/awt/geom/PathIterator;Z)V @ 11 c2 > Event: 176.694 Thread 0x00007fffa43fe000 Uncommon trap: reason=profile_predicate action=maybe_recompile pc=0x00007fff7543826c method=java.awt.geom.Path2D$Double.append(Ljava/awt/geom/PathIterator;Z)V @ 11 c2 > Event: 176.698 Thread 0x00007fffa43fe000 Uncommon trap: reason=profile_predicate action=maybe_recompile pc=0x00007fff7543826c method=java.awt.geom.Path2D$Double.append(Ljava/awt/geom/PathIterator;Z)V @ 11 c2 > Event: 176.698 Thread 0x00007fffa43fe000 Uncommon trap: reason=profile_predicate action=maybe_recompile pc=0x00007fff7543826c method=java.awt.geom.Path2D$Double.append(Ljava/awt/geom/PathIterator;Z)V @ 11 c2 > > ...... > > Events (20 events): > Event: 176.694 Thread 0x00007fffa43fe000 DEOPT UNPACKING pc=0x00007fff4c80236c sp=0x00007ffe82b9c000 mode 2 > Event: 176.694 Thread 0x00007fffa43fe000 Uncommon trap: trap_request=0xffffffbe fr.pc=0x00007fff7543826c relative=0x000000000000166c > Event: 176.694 Thread 0x00007fffa43fe000 DEOPT PACKING pc=0x00007fff7543826c sp=0x00007ffe82b9c1a0 > Event: 176.694 Thread 0x00007fffa43fe000 Create unroll information: #vframes=1 pc=0x00007fff7543826c sp=0x00007ffe82b9c1a0 > Event: 176.694 Thread 0x00007fffa43fe000 DEOPT UNPACKING pc=0x00007fff4c80236c sp=0x00007ffe82b9c000 mode 2 > Event: 176.698 Thread 0x00007fffa43fe000 Uncommon trap: trap_request=0xffffffbe fr.pc=0x00007fff7543826c relative=0x000000000000166c > Event: 176.698 Thread 0x00007fffa43fe000 DEOPT PACKING pc=0x00007fff7543826c sp=0x00007ffe82b9bf60 > Event: 176.698 Thread 0x00007fffa43fe000 Create unroll information: #vframes=1 pc=0x00007fff7543826c sp=0x00007ffe82b9bf60 > Event: 176.698 Thread 0x00007fffa43fe000 DEOPT UNPACKING pc=0x00007fff4c80236c sp=0x00007ffe82b9bdc0 mode 2 > Event: 176.698 Thread 0x00007fffa43fe000 Uncommon trap: trap_request=0xffffffbe fr.pc=0x00007fff7543826c relative=0x000000000000166c > Event: 176.698 Thread 0x00007fffa43fe000 DEOPT PACKING pc=0x00007fff7543826c sp=0x00007ffe82b9bf80 > Event: 176.698 Thread 0x00007fffa43fe000 Create unroll information: #vframes=1 pc=0x00007fff7543826c sp=0x00007ffe82b9bf80 > Event: 176.698 Thread 0x00007fffa43fe000 DEOPT UNPACKING pc=0x00007fff4c80236c sp=0x00007ffe82b9bde0 mode 2 > Event: 176.946 Executing VM operation: G1CollectForAllocation > Event: 176.950 begin safepoint, id: 1171 > Event: 177.081 end safepoint, id: 1171 > Event: 177.081 Executing VM operation: G1CollectForAllocation done > Event: 177.235 Executing VM operation: G1CollectForAllocation > Event: 177.236 begin safepoint, id: 1173 > Event: 177.408 Protecting memory [0x00007fffac240000,0x00007fffac250000] with protection modes 7 > > > > Best regards, Matthias > > > > > From matthias.baesken at sap.com Thu May 23 11:16:43 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 23 May 2019 11:16:43 +0000 Subject: deoptimization.cpp Events::log / Events::log_deopt_message - was : RE: RFR: 8224221: add memprotect calls to event log Message-ID: 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 matthias.baesken at sap.com Thu May 23 13:25:46 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 23 May 2019 13:25:46 +0000 Subject: RFR: 8224221: add memprotect calls to event log In-Reply-To: References: <7cf56a2b-5da9-d351-3590-ad9114446b7c@oracle.com> <062231d2-7721-31e6-ca38-5d725cc61b59@oracle.com> <8690a635-a878-32f9-e106-6d2c0d3493c2@oracle.com> Message-ID: > >> > >> This is starting to look a bit inconsistent. If you want to log > >> VirtualProtect calls then there are more of them than just in > >> guard_memory and unguard_memory. So I'm unclear on the intent here - > is > >> it to log all "memory protection" actions or only to log those that > >> pertain to specific semantic actions? > > > > My Intention was to cover Windows as well, however it looks like there > are more VirtualProtect calls (9) in os_windows.cpp than mprotects in > os_linux.cpp (just 1 in linux_mprotect). > > But maybe it is better to omit VirtualProtect / os_windows in this patch , > no problem. > > What do you think ? > > I think you need to decide what this work is trying to log - is it > "mprotect" calls or is it "memory protection" calls? Or something else. Hi David, Let's concentrate on the mprotects ! http://cr.openjdk.java.net/~mbaesken/webrevs/8224221.4/ > > > > Yes , if I keep the eventlog_init() where it is, I miss a few early > mprotect calls . > > I observed this in our tests . > > > > However when moving forward eventlog_init like I did in the first rev. ( > http://cr.openjdk.java.net/~mbaesken/webrevs/8224221.0/src/hotspot/sha > re/runtime/thread.cpp.frames.html ) , > > I run into " assert(os::mutex_init_done()) failed: Too early! " > > Mutex_init is done in os::init_2 , which is called from > > > > Threads::create_vm() { > > ... > > 3740 // Initialize the os module after parsing the args > > 3741 jint os_init_2_result = os::init_2(); > > 3742 if (os_init_2_result != JNI_OK) return os_init_2_result; > > ... > > } > > > > So I could place eventlog_init() after os::init_2 instead of the start of > Threads::create_vm . > > I added an assert(false) in linux_mprotect to see where it is first > called from (not 100% accurate as different flags may trigger other code > paths) and found it was called from initialize_assert_poison() here: > > // Initialize the os module after parsing the args > jint os_init_2_result = os::init_2(); > if (os_init_2_result != JNI_OK) return os_init_2_result; > > #ifdef CAN_SHOW_REGISTERS_ON_ASSERT > // Initialize assert poison page mechanism. > if (ShowRegistersOnAssert) { > initialize_assert_poison(); > } > #endif // CAN_SHOW_REGISTERS_ON_ASSERT > > So if you move your event_init to before the #ifdef it not only should > work okay, but it also shouldn't normally miss any calls to mprotect. > Obviously more extensive testing would be needed. > Thanks for looking into it . Unfortunately this causes another assertion (shows up already in the fastdebug build when using the new JVM) . jdk/src/hotspot/share/runtime/thread.hpp:818), pid=53146, tid=53268 assert(current != __null) failed: Thread::current() called on detached thread V [libjvm.so+0x18d000f] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x2f V [libjvm.so+0xa7f051] report_vm_error(char const*, int, char const*, char const*, ...)+0x111 V [libjvm.so+0x136e04e] Monitor::lock_without_safepoint_check()+0x1be V [libjvm.so+0xaacf07] Events::log(Thread*, char const*, ...)+0xe7 V [libjvm.so+0x140c18b] linux_mprotect(char*, unsigned long, int)+0x12b V [libjvm.so+0xa84197] initialize_assert_poison()+0xc7 V [libjvm.so+0x1810322] Threads::create_vm(JavaVMInitArgs*, bool*)+0x2b2 V [libjvm.so+0xf07b59] JNI_CreateJavaVM+0x69 C [libjli.so+0x42b6] JavaMain+0x86 C [libjli.so+0x8319] ThreadJavaMain+0x9 Best regards, Matthias From erik.joelsson at oracle.com Thu May 23 13:57:27 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 23 May 2019 06:57:27 -0700 Subject: RFR(L/XS) : 8222414 : bring googlemock v1.8.1 In-Reply-To: <179E2496-5149-4521-896D-01E3B216A48F@oracle.com> References: <179E2496-5149-4521-896D-01E3B216A48F@oracle.com> Message-ID: Hello Igor, Build changes look ok, with a (very) minor style suggestion [1] (point 18). We try to avoid padding continuation line breaks, so I would appreciate if CompileGtest.gmk:68 could be indented just 4 extra spaces compared to line 67. If you want the file names to line up, it's acceptable to break after the := on 67. [1] http://openjdk.java.net/groups/build/doc/code-conventions.html /Erik On 2019-05-22 22:20, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >> 21638 lines changed: 21628 ins; 0 del; 10 mod; > Hi all, > > could you please review this patch which makes mocking framework from google test available for hotspot tests? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8222414 > testing: tier1 > webrevs: > - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.00 >> 21605 lines changed: 21605 ins; 0 del; 0 mod; > * moves gtest from test/fmw/gtest to test/fmw/gtest/googletest; > * adds only required (w/o build-aux, docs, make, msvc, scripts, tests directories and make related files) source of gmock to test/fmw/gtest/googlemock; > > - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.0-1 >> 33 lines changed: 23 ins; 0 del; 10 mod; > * makes necessary changes in makefiles > * calls gmock framework init function > * works around the conflict b/w :testing::internal::Log function defined by gmock and Log macro defined by hotspot > > - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >> 21638 lines changed: 21628 ins; 0 del; 10 mod; > all the changes together > > > thanks, > -- Igor From thomas.stuefe at gmail.com Thu May 23 19:51:46 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 23 May 2019 21:51:46 +0200 Subject: RFR(s): 8224600: Provide VM.events command Message-ID: 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 mikhailo.seledtsov at oracle.com Thu May 23 23:51:57 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Thu, 23 May 2019 16:51:57 -0700 Subject: RFR(T): 8224706: [TESTBUG] problem list failing JDK docker API tests Message-ID: <13825b14-6976-c60e-08e3-7d80f30896ff@oracle.com> Problem listing failing tests until the underlying issues are addressed JBS: https://bugs.openjdk.java.net/browse/JDK-8224706 Testing: ran the JDK docker API tests: jdk/internal/platform/docker - PASS ??? (and problem listed tests are not run) Change: --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -854,3 +854,11 @@ ?jdk/jfr/event/io/TestInstrumentation.java 8202142??? generic-all ?jdk/jfr/api/recording/event/TestPeriod.java 8215890??? generic-all + + +############################################################################ + +# jdk/internal/docker + +jdk/internal/platform/docker/TestDockerMemoryMetrics.java 8224506??? generic-all +jdk/internal/platform/docker/TestSystemMetrics.java 8224502??? generic-all Thank you, Misha From leonid.mesnik at oracle.com Fri May 24 00:01:50 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Thu, 23 May 2019 17:01:50 -0700 Subject: RFR(T): 8224706: [TESTBUG] problem list failing JDK docker API tests In-Reply-To: <13825b14-6976-c60e-08e3-7d80f30896ff@oracle.com> References: <13825b14-6976-c60e-08e3-7d80f30896ff@oracle.com> Message-ID: <12d33186-88b4-2daa-e27a-f15bff4cf2b1@oracle.com> Looks good. Leonid On 5/23/19 4:51 PM, mikhailo.seledtsov at oracle.com wrote: > Problem listing failing tests until the underlying issues are addressed > > JBS: https://bugs.openjdk.java.net/browse/JDK-8224706 > > Testing: ran the JDK docker API tests: jdk/internal/platform/docker - > PASS > > ??? (and problem listed tests are not run) > > Change: > > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -854,3 +854,11 @@ > > ?jdk/jfr/event/io/TestInstrumentation.java 8202142??? generic-all > ?jdk/jfr/api/recording/event/TestPeriod.java 8215890 generic-all > + > + > +############################################################################ > > + > +# jdk/internal/docker > + > +jdk/internal/platform/docker/TestDockerMemoryMetrics.java 8224506??? > generic-all > +jdk/internal/platform/docker/TestSystemMetrics.java 8224502 generic-all > > > Thank you, > > Misha > From jesper.wilhelmsson at oracle.com Fri May 24 00:11:33 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Fri, 24 May 2019 02:11:33 +0200 Subject: RFR: JDK-8224715 - ProblemList compiler/graalunit/HotspotJdk9Test.java Message-ID: Hi, Please review this small addition to the problemlist. The test is timing out frequently in tier 3. Bug: https://bugs.openjdk.java.net/browse/JDK-8224715 Diff: diff --git a/test/hotspot/jtreg/ProblemList-graal.txt b/test/hotspot/jtreg/ProblemList-graal.txt --- a/test/hotspot/jtreg/ProblemList-graal.txt +++ b/test/hotspot/jtreg/ProblemList-graal.txt @@ -38,6 +38,8 @@ compiler/compilercontrol/mixed/RandomValidCommandsTest.java 8181753 generic-all compiler/compilercontrol/mixed/RandomCommandsTest.java 8181753 generic-all +compiler/graalunit/HotspotJdk9Test.java 8224254 generic-all + compiler/jvmci/SecurityRestrictionsTest.java 8181837 generic-all compiler/unsafe/UnsafeGetConstantField.java 8181833 generic-all Thanks, /Jesper From mikael.vidstedt at oracle.com Fri May 24 00:17:38 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 23 May 2019 17:17:38 -0700 Subject: RFR: JDK-8224715 - ProblemList compiler/graalunit/HotspotJdk9Test.java In-Reply-To: References: Message-ID: <1C639532-CEBD-48FF-BA80-338F70C66C60@oracle.com> Looks good, thanks for doing this! Cheers, Mikael > On May 23, 2019, at 5:11 PM, jesper.wilhelmsson at oracle.com wrote: > > Hi, > > Please review this small addition to the problemlist. The test is timing out frequently in tier 3. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224715 > Diff: > > diff --git a/test/hotspot/jtreg/ProblemList-graal.txt b/test/hotspot/jtreg/ProblemList-graal.txt > --- a/test/hotspot/jtreg/ProblemList-graal.txt > +++ b/test/hotspot/jtreg/ProblemList-graal.txt > @@ -38,6 +38,8 @@ > compiler/compilercontrol/mixed/RandomValidCommandsTest.java 8181753 generic-all > compiler/compilercontrol/mixed/RandomCommandsTest.java 8181753 generic-all > > +compiler/graalunit/HotspotJdk9Test.java 8224254 generic-all > + > compiler/jvmci/SecurityRestrictionsTest.java 8181837 generic-all > > compiler/unsafe/UnsafeGetConstantField.java 8181833 generic-all > > > Thanks, > /Jesper > From jesper.wilhelmsson at oracle.com Fri May 24 01:18:50 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Fri, 24 May 2019 03:18:50 +0200 Subject: RFR: JDK-8224715 - ProblemList compiler/graalunit/HotspotJdk9Test.java In-Reply-To: <1C639532-CEBD-48FF-BA80-338F70C66C60@oracle.com> References: <1C639532-CEBD-48FF-BA80-338F70C66C60@oracle.com> Message-ID: <3D40F51D-7719-4195-B675-965925FA156B@oracle.com> Thanks for reviewing! /Jesper > On 24 May 2019, at 02:17, Mikael Vidstedt wrote: > > > Looks good, thanks for doing this! > > Cheers, > Mikael > >> On May 23, 2019, at 5:11 PM, jesper.wilhelmsson at oracle.com wrote: >> >> Hi, >> >> Please review this small addition to the problemlist. The test is timing out frequently in tier 3. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8224715 >> Diff: >> >> diff --git a/test/hotspot/jtreg/ProblemList-graal.txt b/test/hotspot/jtreg/ProblemList-graal.txt >> --- a/test/hotspot/jtreg/ProblemList-graal.txt >> +++ b/test/hotspot/jtreg/ProblemList-graal.txt >> @@ -38,6 +38,8 @@ >> compiler/compilercontrol/mixed/RandomValidCommandsTest.java 8181753 generic-all >> compiler/compilercontrol/mixed/RandomCommandsTest.java 8181753 generic-all >> >> +compiler/graalunit/HotspotJdk9Test.java 8224254 generic-all >> + >> compiler/jvmci/SecurityRestrictionsTest.java 8181837 generic-all >> >> compiler/unsafe/UnsafeGetConstantField.java 8181833 generic-all >> >> >> Thanks, >> /Jesper >> > From igor.ignatyev at oracle.com Fri May 24 02:07:48 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 23 May 2019 19:07:48 -0700 Subject: RFR(L/XS) : 8222414 : bring googlemock v1.8.1 In-Reply-To: References: <179E2496-5149-4521-896D-01E3B216A48F@oracle.com> Message-ID: <66A0B23F-22E3-4F6C-A55B-A16F09AEE557@oracle.com> Hi Erik, thanks for your review. I've updated CompileGtest.gmk as you advised[1], which gives [2]. -- Igor [1] > diff -r 3443e083223d make/hotspot/lib/CompileGtest.gmk > --- a/make/hotspot/lib/CompileGtest.gmk Thu May 23 19:03:32 2019 -0700 > +++ b/make/hotspot/lib/CompileGtest.gmk Thu May 23 19:04:09 2019 -0700 > @@ -64,8 +64,9 @@ > EXCLUDES := $(JVM_EXCLUDES), \ > EXCLUDE_FILES := gtestLauncher.cpp, \ > EXCLUDE_PATTERNS := $(JVM_EXCLUDE_PATTERNS), \ > - EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/googletest/src/gtest-all.cc \ > - $(GTEST_FRAMEWORK_SRC)/googlemock/src/gmock-all.cc, \ > + EXTRA_FILES := \ > + $(GTEST_FRAMEWORK_SRC)/googletest/src/gtest-all.cc \ > + $(GTEST_FRAMEWORK_SRC)/googlemock/src/gmock-all.cc, \ > EXTRA_OBJECT_FILES := $(filter-out %/operator_new$(OBJ_SUFFIX), \ > $(BUILD_LIBJVM_ALL_OBJS)), \ > CFLAGS := $(JVM_CFLAGS) \ [2] http://cr.openjdk.java.net/~iignatyev/8222414/webrev.1-2/ > On May 23, 2019, at 6:57 AM, Erik Joelsson wrote: > > Hello Igor, > > Build changes look ok, with a (very) minor style suggestion [1] (point 18). We try to avoid padding continuation line breaks, so I would appreciate if CompileGtest.gmk:68 could be indented just 4 extra spaces compared to line 67. If you want the file names to line up, it's acceptable to break after the := on 67. > > [1] http://openjdk.java.net/groups/build/doc/code-conventions.html > > /Erik > > On 2019-05-22 22:20, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >>> 21638 lines changed: 21628 ins; 0 del; 10 mod; >> Hi all, >> >> could you please review this patch which makes mocking framework from google test available for hotspot tests? >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8222414 >> testing: tier1 >> webrevs: >> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.00 >>> 21605 lines changed: 21605 ins; 0 del; 0 mod; >> * moves gtest from test/fmw/gtest to test/fmw/gtest/googletest; >> * adds only required (w/o build-aux, docs, make, msvc, scripts, tests directories and make related files) source of gmock to test/fmw/gtest/googlemock; >> >> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.0-1 >>> 33 lines changed: 23 ins; 0 del; 10 mod; >> * makes necessary changes in makefiles >> * calls gmock framework init function >> * works around the conflict b/w :testing::internal::Log function defined by gmock and Log macro defined by hotspot >> >> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >>> 21638 lines changed: 21628 ins; 0 del; 10 mod; >> all the changes together >> >> >> thanks, >> -- Igor From yumin.qi at gmail.com Fri May 24 03:50:06 2019 From: yumin.qi at gmail.com (yumin qi) Date: Thu, 23 May 2019 20:50:06 -0700 Subject: RFR(s): 8224600: Provide VM.events command In-Reply-To: References: Message-ID: HI, Thomas It looks good to me. One question of the test, could it be including test for 'max' = some number other than '-1'. (I am Not a Reviewer). Thanks Yumin On Thu, May 23, 2019 at 12:52 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 david.holmes at oracle.com Fri May 24 06:46:17 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 May 2019 16:46:17 +1000 Subject: RFR: 8224221: add memprotect calls to event log In-Reply-To: References: <7cf56a2b-5da9-d351-3590-ad9114446b7c@oracle.com> <062231d2-7721-31e6-ca38-5d725cc61b59@oracle.com> <8690a635-a878-32f9-e106-6d2c0d3493c2@oracle.com> Message-ID: Hi Matthias, On 23/05/2019 11:25 pm, Baesken, Matthias wrote: >>>> >>>> This is starting to look a bit inconsistent. If you want to log >>>> VirtualProtect calls then there are more of them than just in >>>> guard_memory and unguard_memory. So I'm unclear on the intent here - >> is >>>> it to log all "memory protection" actions or only to log those that >>>> pertain to specific semantic actions? >>> >>> My Intention was to cover Windows as well, however it looks like there >> are more VirtualProtect calls (9) in os_windows.cpp than mprotects in >> os_linux.cpp (just 1 in linux_mprotect). >>> But maybe it is better to omit VirtualProtect / os_windows in this patch , >> no problem. >>> What do you think ? >> >> I think you need to decide what this work is trying to log - is it >> "mprotect" calls or is it "memory protection" calls? Or something else. > > Hi David, > > Let's concentrate on the mprotects ! > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224221.4/ Okay so basically non-Windows support. Please make this clear in the bug report. Those changes seem fine. >>> >>> Yes , if I keep the eventlog_init() where it is, I miss a few early >> mprotect calls . >>> I observed this in our tests . >>> >>> However when moving forward eventlog_init like I did in the first rev. ( >> http://cr.openjdk.java.net/~mbaesken/webrevs/8224221.0/src/hotspot/sha >> re/runtime/thread.cpp.frames.html ) , >>> I run into " assert(os::mutex_init_done()) failed: Too early! " >>> Mutex_init is done in os::init_2 , which is called from >>> >>> Threads::create_vm() { >>> ... >>> 3740 // Initialize the os module after parsing the args >>> 3741 jint os_init_2_result = os::init_2(); >>> 3742 if (os_init_2_result != JNI_OK) return os_init_2_result; >>> ... >>> } >>> >>> So I could place eventlog_init() after os::init_2 instead of the start of >> Threads::create_vm . >> >> I added an assert(false) in linux_mprotect to see where it is first >> called from (not 100% accurate as different flags may trigger other code >> paths) and found it was called from initialize_assert_poison() here: >> >> // Initialize the os module after parsing the args >> jint os_init_2_result = os::init_2(); >> if (os_init_2_result != JNI_OK) return os_init_2_result; >> >> #ifdef CAN_SHOW_REGISTERS_ON_ASSERT >> // Initialize assert poison page mechanism. >> if (ShowRegistersOnAssert) { >> initialize_assert_poison(); >> } >> #endif // CAN_SHOW_REGISTERS_ON_ASSERT >> >> So if you move your event_init to before the #ifdef it not only should >> work okay, but it also shouldn't normally miss any calls to mprotect. >> Obviously more extensive testing would be needed. >> > > Thanks for looking into it . > Unfortunately this causes another assertion (shows up already in the fastdebug build when using the new JVM) . > > > jdk/src/hotspot/share/runtime/thread.hpp:818), pid=53146, tid=53268 > assert(current != __null) failed: Thread::current() called on detached thread Okay so that's a different problem: the event log uses a mutex and that needs an attached thread. So you can't use the event_log before the main thread has attached even if you've initialized the event log. So even if you keep the eventlog_init() where it is inside vm_init_globals(), there's a small risk you could still try to use the event log before the main thread attaches: // Initialize global data structures and create system classes in heap vm_init_globals(); #if INCLUDE_JVMCI if (JVMCICounterSize > 0) { JavaThread::_jvmci_old_thread_counters = NEW_C_HEAP_ARRAY(jlong, JVMCICounterSize, mtInternal); memset(JavaThread::_jvmci_old_thread_counters, 0, sizeof(jlong) * JVMCICounterSize); } else { JavaThread::_jvmci_old_thread_counters = NULL; } #endif // INCLUDE_JVMCI // Attach the main thread to this os thread JavaThread* main_thread = new JavaThread(); main_thread->set_thread_state(_thread_in_vm); main_thread->initialize_thread_current(); // must do this before set_active_handles main_thread->record_stack_base_and_size(); main_thread->register_thread_stack_with_NMT(); main_thread->set_active_handles(JNIHandleBlock::allocate_block()); if (!main_thread->set_as_starting_thread()) { vm_shutdown_during_initialization( "Failed necessary internal allocation. Out of swap space"); main_thread->smr_delete(); *canTryAgain = false; // don't let caller call JNI_CreateJavaVM again return JNI_ENOMEM; } // Enable guard page *after* os::create_main_thread(), otherwise it would // crash Linux VM, see notes in os_linux.cpp. main_thread->create_stack_guard_pages(); Fortunately the sequence of mprotect calls seems to be: - initialize_assert_poison() (if enabled and a debug build) - two via SafepointMechanism::initialize(); - main_thread->create_stack_guard_pages(); (around 10 calls in here) So it appears that currently leaving the eventlog_init() where it is, and ensuring you don't log before initialization, that things will work okay. I have some reservations about what may be possible if the main thread takes a lock etc before its guard pages have been set up - but I think that should be safe. There may also be an issue if we take the vm_exit path - but as of now there are no mprotect calls if we do that. David ----- > V [libjvm.so+0x18d000f] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x2f > V [libjvm.so+0xa7f051] report_vm_error(char const*, int, char const*, char const*, ...)+0x111 > V [libjvm.so+0x136e04e] Monitor::lock_without_safepoint_check()+0x1be > V [libjvm.so+0xaacf07] Events::log(Thread*, char const*, ...)+0xe7 > V [libjvm.so+0x140c18b] linux_mprotect(char*, unsigned long, int)+0x12b > V [libjvm.so+0xa84197] initialize_assert_poison()+0xc7 > V [libjvm.so+0x1810322] Threads::create_vm(JavaVMInitArgs*, bool*)+0x2b2 > V [libjvm.so+0xf07b59] JNI_CreateJavaVM+0x69 > C [libjli.so+0x42b6] JavaMain+0x86 > C [libjli.so+0x8319] ThreadJavaMain+0x9 > > Best regards, Matthias > From thomas.stuefe at gmail.com Fri May 24 06:53:08 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 24 May 2019 08:53:08 +0200 Subject: RFR(s): 8224600: Provide VM.events command In-Reply-To: References: Message-ID: Hi Yumin, On Fri, May 24, 2019 at 5:50 AM yumin qi wrote: > HI, Thomas > > It looks good to me. > Thank you! > One question of the test, could it be including test for 'max' = some > number other than '-1'. > Hmm, I'd rather not. This would require more intricate output parsing and make the test more complicated and brittle and increase test time while gaining not much: The point of this tests is to test that the command exist, that jcmd can attach, invoke the command and get some kind of reasonable reply without the VM to crash or hang. I usually test command variations only if they cover sufficiently different coding, e.g. use different locking mechanisms (see e.g. PrintMetaspaceDcmd.java). But here, I do not expect this code to change often so I think a regression test is not needed. In the future, should this parameter break, we can rethink this. > (I am Not a Reviewer). > Thanks anyway. Cheers, Thomas > > Thanks > Yumin > > On Thu, May 23, 2019 at 12:52 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 martin.doerr at sap.com Fri May 24 08:02:41 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 24 May 2019 08:02:41 +0000 Subject: RFR: 8224221: add memprotect calls to event log In-Reply-To: References: <7cf56a2b-5da9-d351-3590-ad9114446b7c@oracle.com> <062231d2-7721-31e6-ca38-5d725cc61b59@oracle.com> <8690a635-a878-32f9-e106-6d2c0d3493c2@oracle.com> Message-ID: Hi Matthias, webrev 4 looks good to me. Can you add an example (log message) to the bug, please? Best regards, Martin > -----Original Message----- > From: hotspot-dev On Behalf Of > David Holmes > Sent: Freitag, 24. Mai 2019 08:46 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Subject: Re: RFR: 8224221: add memprotect calls to event log > > Hi Matthias, > > On 23/05/2019 11:25 pm, Baesken, Matthias wrote: > >>>> > >>>> This is starting to look a bit inconsistent. If you want to log > >>>> VirtualProtect calls then there are more of them than just in > >>>> guard_memory and unguard_memory. So I'm unclear on the intent here > - > >> is > >>>> it to log all "memory protection" actions or only to log those that > >>>> pertain to specific semantic actions? > >>> > >>> My Intention was to cover Windows as well, however it looks like there > >> are more VirtualProtect calls (9) in os_windows.cpp than mprotects in > >> os_linux.cpp (just 1 in linux_mprotect). > >>> But maybe it is better to omit VirtualProtect / os_windows in this patch , > >> no problem. > >>> What do you think ? > >> > >> I think you need to decide what this work is trying to log - is it > >> "mprotect" calls or is it "memory protection" calls? Or something else. > > > > Hi David, > > > > Let's concentrate on the mprotects ! > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224221.4/ > > Okay so basically non-Windows support. Please make this clear in the bug > report. > > Those changes seem fine. > > >>> > >>> Yes , if I keep the eventlog_init() where it is, I miss a few early > >> mprotect calls . > >>> I observed this in our tests . > >>> > >>> However when moving forward eventlog_init like I did in the first rev. > ( > >> > http://cr.openjdk.java.net/~mbaesken/webrevs/8224221.0/src/hotspot/sha > >> re/runtime/thread.cpp.frames.html ) , > >>> I run into " assert(os::mutex_init_done()) failed: Too early! " > >>> Mutex_init is done in os::init_2 , which is called from > >>> > >>> Threads::create_vm() { > >>> ... > >>> 3740 // Initialize the os module after parsing the args > >>> 3741 jint os_init_2_result = os::init_2(); > >>> 3742 if (os_init_2_result != JNI_OK) return os_init_2_result; > >>> ... > >>> } > >>> > >>> So I could place eventlog_init() after os::init_2 instead of the start of > >> Threads::create_vm . > >> > >> I added an assert(false) in linux_mprotect to see where it is first > >> called from (not 100% accurate as different flags may trigger other code > >> paths) and found it was called from initialize_assert_poison() here: > >> > >> // Initialize the os module after parsing the args > >> jint os_init_2_result = os::init_2(); > >> if (os_init_2_result != JNI_OK) return os_init_2_result; > >> > >> #ifdef CAN_SHOW_REGISTERS_ON_ASSERT > >> // Initialize assert poison page mechanism. > >> if (ShowRegistersOnAssert) { > >> initialize_assert_poison(); > >> } > >> #endif // CAN_SHOW_REGISTERS_ON_ASSERT > >> > >> So if you move your event_init to before the #ifdef it not only should > >> work okay, but it also shouldn't normally miss any calls to mprotect. > >> Obviously more extensive testing would be needed. > >> > > > > Thanks for looking into it . > > Unfortunately this causes another assertion (shows up already in the > fastdebug build when using the new JVM) . > > > > > > jdk/src/hotspot/share/runtime/thread.hpp:818), pid=53146, tid=53268 > > assert(current != __null) failed: Thread::current() called on detached > thread > > Okay so that's a different problem: the event log uses a mutex and that > needs an attached thread. So you can't use the event_log before the main > thread has attached even if you've initialized the event log. So even if > you keep the eventlog_init() where it is inside vm_init_globals(), > there's a small risk you could still try to use the event log before the > main thread attaches: > > // Initialize global data structures and create system classes in heap > vm_init_globals(); > > #if INCLUDE_JVMCI > if (JVMCICounterSize > 0) { > JavaThread::_jvmci_old_thread_counters = NEW_C_HEAP_ARRAY(jlong, > JVMCICounterSize, mtInternal); > memset(JavaThread::_jvmci_old_thread_counters, 0, sizeof(jlong) * > JVMCICounterSize); > } else { > JavaThread::_jvmci_old_thread_counters = NULL; > } > #endif // INCLUDE_JVMCI > > // Attach the main thread to this os thread > JavaThread* main_thread = new JavaThread(); > main_thread->set_thread_state(_thread_in_vm); > main_thread->initialize_thread_current(); > // must do this before set_active_handles > main_thread->record_stack_base_and_size(); > main_thread->register_thread_stack_with_NMT(); > main_thread->set_active_handles(JNIHandleBlock::allocate_block()); > > if (!main_thread->set_as_starting_thread()) { > vm_shutdown_during_initialization( > "Failed necessary internal > allocation. Out of swap space"); > main_thread->smr_delete(); > *canTryAgain = false; // don't let caller call JNI_CreateJavaVM again > return JNI_ENOMEM; > } > > // Enable guard page *after* os::create_main_thread(), otherwise it would > // crash Linux VM, see notes in os_linux.cpp. > main_thread->create_stack_guard_pages(); > > Fortunately the sequence of mprotect calls seems to be: > - initialize_assert_poison() (if enabled and a debug build) > - two via SafepointMechanism::initialize(); > - main_thread->create_stack_guard_pages(); (around 10 calls in here) > > So it appears that currently leaving the eventlog_init() where it is, > and ensuring you don't log before initialization, that things will work > okay. I have some reservations about what may be possible if the main > thread takes a lock etc before its guard pages have been set up - but I > think that should be safe. There may also be an issue if we take the > vm_exit path - but as of now there are no mprotect calls if we do that. > > David > ----- > > > V [libjvm.so+0x18d000f] VMError::report_and_die(Thread*, void*, char > const*, int, char const*, char const*, __va_list_tag*)+0x2f > > V [libjvm.so+0xa7f051] report_vm_error(char const*, int, char const*, > char const*, ...)+0x111 > > V [libjvm.so+0x136e04e] Monitor::lock_without_safepoint_check()+0x1be > > V [libjvm.so+0xaacf07] Events::log(Thread*, char const*, ...)+0xe7 > > V [libjvm.so+0x140c18b] linux_mprotect(char*, unsigned long, int)+0x12b > > V [libjvm.so+0xa84197] initialize_assert_poison()+0xc7 > > V [libjvm.so+0x1810322] Threads::create_vm(JavaVMInitArgs*, > bool*)+0x2b2 > > V [libjvm.so+0xf07b59] JNI_CreateJavaVM+0x69 > > C [libjli.so+0x42b6] JavaMain+0x86 > > C [libjli.so+0x8319] ThreadJavaMain+0x9 > > > > Best regards, Matthias > > From matthias.baesken at sap.com Fri May 24 13:03:13 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 24 May 2019 13:03:13 +0000 Subject: RFR: 8224221: add memprotect calls to event log In-Reply-To: References: <7cf56a2b-5da9-d351-3590-ad9114446b7c@oracle.com> <062231d2-7721-31e6-ca38-5d725cc61b59@oracle.com> <8690a635-a878-32f9-e106-6d2c0d3493c2@oracle.com> Message-ID: Thanks for the review, I added an example event log entry to the bug . I also added a short info that the mprotect calls are added to the logs. Best regards, Matthias > -----Original Message----- > From: Doerr, Martin > Sent: Freitag, 24. Mai 2019 10:03 > To: David Holmes ; Baesken, Matthias > ; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: RE: RFR: 8224221: add memprotect calls to event log > > Hi Matthias, > > webrev 4 looks good to me. > Can you add an example (log message) to the bug, please? > > Best regards, > Martin > > > > -----Original Message----- > > From: hotspot-dev On Behalf > Of > > David Holmes > > Sent: Freitag, 24. Mai 2019 08:46 > > To: Baesken, Matthias ; 'hotspot- > > dev at openjdk.java.net' > > Subject: Re: RFR: 8224221: add memprotect calls to event log > > > > Hi Matthias, > > > > On 23/05/2019 11:25 pm, Baesken, Matthias wrote: > > >>>> > > >>>> This is starting to look a bit inconsistent. If you want to log > > >>>> VirtualProtect calls then there are more of them than just in > > >>>> guard_memory and unguard_memory. So I'm unclear on the intent > here > > - > > >> is > > >>>> it to log all "memory protection" actions or only to log those that > > >>>> pertain to specific semantic actions? > > >>> > > >>> My Intention was to cover Windows as well, however it looks like > there > > >> are more VirtualProtect calls (9) in os_windows.cpp than mprotects > in > > >> os_linux.cpp (just 1 in linux_mprotect). > > >>> But maybe it is better to omit VirtualProtect / os_windows in this > patch , > > >> no problem. > > >>> What do you think ? > > >> > > >> I think you need to decide what this work is trying to log - is it > > >> "mprotect" calls or is it "memory protection" calls? Or something else. > > > > > > Hi David, > > > > > > Let's concentrate on the mprotects ! > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224221.4/ > > > > Okay so basically non-Windows support. Please make this clear in the bug > > report. > > > > Those changes seem fine. > > > > >>> > > >>> Yes , if I keep the eventlog_init() where it is, I miss a few early > > >> mprotect calls . > > >>> I observed this in our tests . > > >>> > > >>> However when moving forward eventlog_init like I did in the first > rev. > > ( > > >> > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224221.0/src/hotspot/sha > > >> re/runtime/thread.cpp.frames.html ) , > > >>> I run into " assert(os::mutex_init_done()) failed: Too early! " > > >>> Mutex_init is done in os::init_2 , which is called from > > >>> > > >>> Threads::create_vm() { > > >>> ... > > >>> 3740 // Initialize the os module after parsing the args > > >>> 3741 jint os_init_2_result = os::init_2(); > > >>> 3742 if (os_init_2_result != JNI_OK) return os_init_2_result; > > >>> ... > > >>> } > > >>> > > >>> So I could place eventlog_init() after os::init_2 instead of the start > of > > >> Threads::create_vm . > > >> > > >> I added an assert(false) in linux_mprotect to see where it is first > > >> called from (not 100% accurate as different flags may trigger other code > > >> paths) and found it was called from initialize_assert_poison() here: > > >> > > >> // Initialize the os module after parsing the args > > >> jint os_init_2_result = os::init_2(); > > >> if (os_init_2_result != JNI_OK) return os_init_2_result; > > >> > > >> #ifdef CAN_SHOW_REGISTERS_ON_ASSERT > > >> // Initialize assert poison page mechanism. > > >> if (ShowRegistersOnAssert) { > > >> initialize_assert_poison(); > > >> } > > >> #endif // CAN_SHOW_REGISTERS_ON_ASSERT > > >> > > >> So if you move your event_init to before the #ifdef it not only should > > >> work okay, but it also shouldn't normally miss any calls to mprotect. > > >> Obviously more extensive testing would be needed. > > >> > > > > > > Thanks for looking into it . > > > Unfortunately this causes another assertion (shows up already in the > > fastdebug build when using the new JVM) . > > > > > > > > > jdk/src/hotspot/share/runtime/thread.hpp:818), pid=53146, tid=53268 > > > assert(current != __null) failed: Thread::current() called on detached > > thread > > > > Okay so that's a different problem: the event log uses a mutex and that > > needs an attached thread. So you can't use the event_log before the main > > thread has attached even if you've initialized the event log. So even if > > you keep the eventlog_init() where it is inside vm_init_globals(), > > there's a small risk you could still try to use the event log before the > > main thread attaches: > > > > // Initialize global data structures and create system classes in heap > > vm_init_globals(); > > > > #if INCLUDE_JVMCI > > if (JVMCICounterSize > 0) { > > JavaThread::_jvmci_old_thread_counters = NEW_C_HEAP_ARRAY(jlong, > > JVMCICounterSize, mtInternal); > > memset(JavaThread::_jvmci_old_thread_counters, 0, sizeof(jlong) * > > JVMCICounterSize); > > } else { > > JavaThread::_jvmci_old_thread_counters = NULL; > > } > > #endif // INCLUDE_JVMCI > > > > // Attach the main thread to this os thread > > JavaThread* main_thread = new JavaThread(); > > main_thread->set_thread_state(_thread_in_vm); > > main_thread->initialize_thread_current(); > > // must do this before set_active_handles > > main_thread->record_stack_base_and_size(); > > main_thread->register_thread_stack_with_NMT(); > > main_thread->set_active_handles(JNIHandleBlock::allocate_block()); > > > > if (!main_thread->set_as_starting_thread()) { > > vm_shutdown_during_initialization( > > "Failed necessary internal > > allocation. Out of swap space"); > > main_thread->smr_delete(); > > *canTryAgain = false; // don't let caller call JNI_CreateJavaVM again > > return JNI_ENOMEM; > > } > > > > // Enable guard page *after* os::create_main_thread(), otherwise it > would > > // crash Linux VM, see notes in os_linux.cpp. > > main_thread->create_stack_guard_pages(); > > > > Fortunately the sequence of mprotect calls seems to be: > > - initialize_assert_poison() (if enabled and a debug build) > > - two via SafepointMechanism::initialize(); > > - main_thread->create_stack_guard_pages(); (around 10 calls in here) > > > > So it appears that currently leaving the eventlog_init() where it is, > > and ensuring you don't log before initialization, that things will work > > okay. I have some reservations about what may be possible if the main > > thread takes a lock etc before its guard pages have been set up - but I > > think that should be safe. There may also be an issue if we take the > > vm_exit path - but as of now there are no mprotect calls if we do that. > > > > David > > ----- > > > > > V [libjvm.so+0x18d000f] VMError::report_and_die(Thread*, void*, char > > const*, int, char const*, char const*, __va_list_tag*)+0x2f > > > V [libjvm.so+0xa7f051] report_vm_error(char const*, int, char const*, > > char const*, ...)+0x111 > > > V [libjvm.so+0x136e04e] > Monitor::lock_without_safepoint_check()+0x1be > > > V [libjvm.so+0xaacf07] Events::log(Thread*, char const*, ...)+0xe7 > > > V [libjvm.so+0x140c18b] linux_mprotect(char*, unsigned long, > int)+0x12b > > > V [libjvm.so+0xa84197] initialize_assert_poison()+0xc7 > > > V [libjvm.so+0x1810322] Threads::create_vm(JavaVMInitArgs*, > > bool*)+0x2b2 > > > V [libjvm.so+0xf07b59] JNI_CreateJavaVM+0x69 > > > C [libjli.so+0x42b6] JavaMain+0x86 > > > C [libjli.so+0x8319] ThreadJavaMain+0x9 > > > > > > Best regards, Matthias > > > From erik.joelsson at oracle.com Fri May 24 15:28:50 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 24 May 2019 08:28:50 -0700 Subject: RFR(L/XS) : 8222414 : bring googlemock v1.8.1 In-Reply-To: <66A0B23F-22E3-4F6C-A55B-A16F09AEE557@oracle.com> References: <179E2496-5149-4521-896D-01E3B216A48F@oracle.com> <66A0B23F-22E3-4F6C-A55B-A16F09AEE557@oracle.com> Message-ID: Thanks, looks good! /Erik On 2019-05-23 19:07, Igor Ignatyev wrote: > Hi Erik, > > thanks for your review. I've updated CompileGtest.gmk as you advised[1], which gives [2]. > > -- Igor > > [1] >> diff -r 3443e083223d make/hotspot/lib/CompileGtest.gmk >> --- a/make/hotspot/lib/CompileGtest.gmk Thu May 23 19:03:32 2019 -0700 >> +++ b/make/hotspot/lib/CompileGtest.gmk Thu May 23 19:04:09 2019 -0700 >> @@ -64,8 +64,9 @@ >> EXCLUDES := $(JVM_EXCLUDES), \ >> EXCLUDE_FILES := gtestLauncher.cpp, \ >> EXCLUDE_PATTERNS := $(JVM_EXCLUDE_PATTERNS), \ >> - EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/googletest/src/gtest-all.cc \ >> - $(GTEST_FRAMEWORK_SRC)/googlemock/src/gmock-all.cc, \ >> + EXTRA_FILES := \ >> + $(GTEST_FRAMEWORK_SRC)/googletest/src/gtest-all.cc \ >> + $(GTEST_FRAMEWORK_SRC)/googlemock/src/gmock-all.cc, \ >> EXTRA_OBJECT_FILES := $(filter-out %/operator_new$(OBJ_SUFFIX), \ >> $(BUILD_LIBJVM_ALL_OBJS)), \ >> CFLAGS := $(JVM_CFLAGS) \ > [2] http://cr.openjdk.java.net/~iignatyev/8222414/webrev.1-2/ > >> On May 23, 2019, at 6:57 AM, Erik Joelsson wrote: >> >> Hello Igor, >> >> Build changes look ok, with a (very) minor style suggestion [1] (point 18). We try to avoid padding continuation line breaks, so I would appreciate if CompileGtest.gmk:68 could be indented just 4 extra spaces compared to line 67. If you want the file names to line up, it's acceptable to break after the := on 67. >> >> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html >> >> /Erik >> >> On 2019-05-22 22:20, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >>>> 21638 lines changed: 21628 ins; 0 del; 10 mod; >>> Hi all, >>> >>> could you please review this patch which makes mocking framework from google test available for hotspot tests? >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8222414 >>> testing: tier1 >>> webrevs: >>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.00 >>>> 21605 lines changed: 21605 ins; 0 del; 0 mod; >>> * moves gtest from test/fmw/gtest to test/fmw/gtest/googletest; >>> * adds only required (w/o build-aux, docs, make, msvc, scripts, tests directories and make related files) source of gmock to test/fmw/gtest/googlemock; >>> >>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.0-1 >>>> 33 lines changed: 23 ins; 0 del; 10 mod; >>> * makes necessary changes in makefiles >>> * calls gmock framework init function >>> * works around the conflict b/w :testing::internal::Log function defined by gmock and Log macro defined by hotspot >>> >>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >>>> 21638 lines changed: 21628 ins; 0 del; 10 mod; >>> all the changes together >>> >>> >>> thanks, >>> -- Igor From rahul.v.raghavan at oracle.com Fri May 24 20:17:08 2019 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Sat, 25 May 2019 01:47:08 +0530 Subject: [13] RFR: 8213416: Replace some enums with static const members in hotspot/compiler In-Reply-To: <8b22fc8b-af06-31a2-4033-4984ac4fcb5d@oracle.com> References: <1f7afc19-0756-33f8-54f5-2438ed5da886@oracle.com> <8f18e15d-cae8-58eb-b4a1-870ca6ffaf15@oracle.com> <62869e18-3deb-435d-1ce8-7726866d79eb@oracle.com> <8b22fc8b-af06-31a2-4033-4984ac4fcb5d@oracle.com> Message-ID: Hi, Request one more review approval for latest http://cr.openjdk.java.net/~rraghavan/8213416/webrev.01/ Thanks, Rahul On 20/05/19 11:46 PM, Rahul Raghavan wrote: > Hi, > > With reference to below email thread, request help to confirm next steps > for JDK-8213416. > > So may I go ahead with webrev changes related to hotspot/compiler for > 8213416 ? > - http://cr.openjdk.java.net/~rraghavan/8213416/webrev.01/ > > (also will add similar hotspot/runtime related details in JBS comments > for JDK-8223400) > > Thanks, > Rahul > > > > On 16/05/19 3:26 PM, Rahul Raghavan wrote:> Hi, > > > > Thank you David for review comments. > > I will kindly request help from Magnus to reply for the main questions. > > > > Sharing some notes, related links - > > - 8211073: Remove -Wno-extra from Hotspot > >????? https://bugs.openjdk.java.net/browse/JDK-8211073 > > - Discussions in earlier thread - > > > https://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034314.html > > > > So understood -Wextra do help in catching valid/useful warnings also, > > but along with some too strict ones like "enumeral and non-enumeral type > > in conditional expression" type warnings. > > > > Extracts from 8211073 JBS comments from Magnus regarding the > > 'enum-warning' - > > "... If you think that gcc is a bit too picky here, I agree. It's not > > obvious per se that the added casts improve the code. However, this is > > the price we need to pay to be able to enable -Wextra, and *that* is > > something that is likely to improve the code." > > > > > > Thanks, > > Rahul > > > > On 16/05/19 11:13 AM, David Holmes wrote: > >> This all seems like unnecessary churn to me - is any of this code > >> actually wrong? can we not just disable this particular warning? is > >> there any point using "static const" when we should be aiming to use > >> C++11 constexpr in the (not too distant?) future? > >> > >> Converting from enums to unrelated ints seems a big step backwards in > >> software engineering terms. :( > >> > >> Cheers, > >> David > >> ----- > >> > > > > On 16/05/19 12:03 PM, Rahul Raghavan wrote: >> Hi, >> >> Thank you Vladimir for review comments. >> >>>> 4) _lh_array_tag_obj_value, _lh_instance_slow_path_bit - >>>> [open/src/hotspot/share/oops/klass.cpp] >>>> .......... >>> >>> I am okay with it but Runtime group should agree too - it is their code. >>> >> Yes, I missed that it is Runtime code. >> >> Please note plan is to handle only the hotspot/compiler part of the >> requirement changes in JDK-8213416. >> As per earlier JBS comments new JDK-8223400 was created to cover the >> requirements in hotspot/runtime. >> So may I suggest moving the above runtime change requirement details >> to JDK-822340; >> and use only the balance changes, as in below updated webrev, here for >> 8213416. >> >> - http://cr.openjdk.java.net/~rraghavan/8213416/webrev.01/ >> >> >> Thanks, >> Rahul On 15/05/19 10:01 PM, Vladimir Kozlov wrote:> Hi Rahul, > > Comments are inlined below. > > On 5/15/19 7:46 AM, Rahul Raghavan wrote: >> Hi, >> >> Request help review and finalize fix for 8213416. >> >> - http://cr.openjdk.java.net/~rraghavan/8213416/webrev.00/ >> >> https://bugs.openjdk.java.net/browse/JDK-8213416 >> >> The requirement is to solve >> "enumeral and non-enumeral type in conditional expression" warnings >> triggered with -Wextra enabled for gcc on hotspot. >> >> (hotspot/compiler part is handled in this 8213416 task >> and hotspot/runtime in 8223400) >> >> The same warning is generated for ternary operator statements like- >> (x ? int_val : enum_val). >> e.g.: >> comp_level = TieredCompilation ? TieredStopAtLevel : >> CompLevel_highest_tier; >> >> >> Understood from comments that the following type typecast solution >> proposed earlier was not accepted. >> - comp_level = TieredCompilation ? TieredStopAtLevel : >> CompLevel_highest_tier; >> + comp_level = TieredCompilation ? TieredStopAtLevel : (int) >> CompLevel_highest_tier; >> and then proposed solution was to rewrite those enums to be static >> const members. >> >> >> Tried changes based on the comments info from JBS. >> Extracts of related JBS comments- >> - ".... it's just a simple code refactoring. " >> - "David H. only complained about NO_HASH which we can fix. >> We can also fix CompLevel_highest_tier usage - should use CompLevel >> type everywhere. >> But I would not touch Op_RegFlags - >> I don't want to complicate its construction and >> we have a lot of places where Op_ are used as uint. >> I would only fix places where it is used as int to make sure it is >> used as uint everywhere." >> >> Reported enums in question for hotspot/compiler >> 1) NO_HASH >> 2) CompLevel_highest_tier >> 3) Op_RegFlags >> 4) _lh_array_tag_obj_value, _lh_instance_slow_path_bit >> >> >> >> 1) NO_HASH >> tried [open/src/hotspot/share/opto/node.hpp] >> - enum { NO_HASH = 0 }; >> + static const uint NO_HASH = 0; >> > > Okay. > >> >> >> 2) CompLevel_highest_tier >> Only one warning in process_compile() >> [open/src/hotspot/share/ci/ciReplay.cpp] >> comp_level = TieredCompilation ? TieredStopAtLevel : >> CompLevel_highest_tier; >> >> Following type changes tried did not help - >> - int comp_level = parse_int(comp_level_label); >> + CompLevel comp_level = parse_int(comp_level_label); >> ..... >> - comp_level = TieredCompilation ? TieredStopAtLevel : >> CompLevel_highest_tier; >> + comp_level = TieredCompilation ? (CompLevel) TieredStopAtLevel >> : CompLevel_highest_tier; >> > > Thank you for explaining that it did not work. >> >> The warning is with only ternary operator usage in this location. >> So tried simple code refactoring like following and got no more warnings! >> Is this okay? >> - comp_level = TieredCompilation ? TieredStopAtLevel : >> CompLevel_highest_tier; >> + if (TieredCompilation) { >> + comp_level = TieredStopAtLevel; >> + } else { >> + comp_level = CompLevel_highest_tier > + } >> > > Good. > >> >> >> 3) Op_RegFlags >> Warnings only for 'virtual uint MachNode::ideal_reg() const' >> >> ../open/src/hotspot/share/opto/machnode.hpp: In member function >> 'virtual uint MachNode::ideal_reg() const': >> ../open/src/hotspot/share/opto/machnode.hpp:304:95: warning: enumeral >> and non-enumeral type in conditional expression [-Wextra] >> virtual uint ideal_reg() const { const Type *t = >> _opnds[0]->type(); return t == TypeInt::CC ? Op_RegFlags : >> t->ideal_reg(); } >> >> ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Op_RegFlags is returned as uint itself here. >> How to modify code to solve warning? >> Again since the issue is with only ternary operator usage in only one >> location, can we go for simple code refactoring like following? >> >> - virtual uint ideal_reg() const { const Type *t = _opnds[0]->type(); >> return t == TypeInt::CC ? Op_RegFlags : t->ideal_reg(); } >> + virtual uint ideal_reg() const { >> + const Type *t = _opnds[0]->type(); >> + if (t == TypeInt::CC) { >> + return Op_RegFlags; >> + } else { >> + return t->ideal_reg(); >> + } >> + } >> > > Good. I agree. > >> >> >> 4) _lh_array_tag_obj_value, _lh_instance_slow_path_bit - >> warnings locations - >> >> (i) ../open/src/hotspot/share/oops/klass.cpp: In static member >> function 'static jint Klass::array_layout_helper(BasicType)': >> ../open/src/hotspot/share/oops/klass.cpp:212:23: warning: enumeral and >> non-enumeral type in conditional expression [-Wextra] >> int tag = isobj ? _lh_array_tag_obj_value : >> _lh_array_tag_type_value; >> >> (ii) ../open/src/hotspot/cpu/x86/c1_Runtime1_x86.cpp: In static member >> function 'static OopMapSet* >> Runtime1::generate_code_for(Runtime1::StubID, StubAssembler*)': >> ../open/src/hotspot/cpu/x86/c1_Runtime1_x86.cpp:1126:22: warning: >> enumeral and non-enumeral type in conditional expression [-Wextra] >> int tag = ((id == new_type_array_id) >> ~~~~~~~~~~~~~~~~~~~~~~~~~ >> ? Klass::_lh_array_tag_type_value >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> : Klass::_lh_array_tag_obj_value); >> >> (iii) ../open/src/hotspot/share/oops/klass.hpp: In static member >> function 'static jint Klass::instance_layout_helper(jint, bool)': >> ../open/src/hotspot/share/oops/klass.hpp:422:28: warning: enumeral and >> non-enumeral type in conditional expression [-Wextra] >> | (slow_path_flag ? _lh_instance_slow_path_bit : 0); >> ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> Following changes fixed the warnings! >> (using static const int instead of unnamed enum) >> [open/src/hotspot/share/oops/klass.cpp] >> .......... >> // Unpacking layout_helper: >> - enum { >> - _lh_neutral_value = 0, // neutral non-array >> non-instance value >> - _lh_instance_slow_path_bit = 0x01, >> - _lh_log2_element_size_shift = BitsPerByte*0, >> - _lh_log2_element_size_mask = BitsPerLong-1, >> - _lh_element_type_shift = BitsPerByte*1, >> - _lh_element_type_mask = right_n_bits(BitsPerByte), // >> shifted mask >> - _lh_header_size_shift = BitsPerByte*2, >> - _lh_header_size_mask = right_n_bits(BitsPerByte), // >> shifted mask >> - _lh_array_tag_bits = 2, >> - _lh_array_tag_shift = BitsPerInt - _lh_array_tag_bits, >> - _lh_array_tag_obj_value = ~0x01 // 0x80000000 >> 30 >> - }; >> + static const int _lh_neutral_value = 0; // neutral >> non-array non-instance value >> + static const int _lh_instance_slow_path_bit = 0x01; >> + static const int _lh_log2_element_size_shift = BitsPerByte*0; >> + static const int _lh_log2_element_size_mask = BitsPerLong-1; >> + static const int _lh_element_type_shift = BitsPerByte*1; >> + static const int _lh_element_type_mask = >> right_n_bits(BitsPerByte); // shifted mask >> + static const int _lh_header_size_shift = BitsPerByte*2; >> + static const int _lh_header_size_mask = >> right_n_bits(BitsPerByte); // shifted mask >> + static const int _lh_array_tag_bits = 2; >> + static const int _lh_array_tag_shift = BitsPerInt - >> _lh_array_tag_bits; >> + static const int _lh_array_tag_obj_value = ~0x01; // >> 0x80000000 >> 30 >> ....... >> > > I am okay with it but Runtime group should agree too - it is their code. > >> >> >> - http://cr.openjdk.java.net/~rraghavan/8213416/webrev.00/ >> >> Understood the affected code locations details from the old sample >> patch attachment of related JDK-8211073 >> # >> https://bugs.openjdk.java.net/secure/attachment/79387/hotspot-disable-wextra.diff >> >> Also confirmed no similar warnings in hotspot/compiler with -Wextra, >> no issues with build with this proposed webrev.00 > > Good. > > Thanks, > Vladimir > >> >> >> Thanks, >> Rahul From igor.ignatyev at oracle.com Fri May 24 21:33:43 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 24 May 2019 14:33:43 -0700 Subject: RFR(L/XS) : 8222414 : bring googlemock v1.8.1 In-Reply-To: References: <179E2496-5149-4521-896D-01E3B216A48F@oracle.com> <66A0B23F-22E3-4F6C-A55B-A16F09AEE557@oracle.com> Message-ID: <439DEFFE-970A-439A-B7C8-3B8D4748041D@oracle.com> @Erik, Thanks! @hotspot (looking at Robin), can I get another review? -- Igor > On May 24, 2019, at 8:28 AM, Erik Joelsson wrote: > > Thanks, looks good! > > /Erik > > On 2019-05-23 19:07, Igor Ignatyev wrote: >> Hi Erik, >> >> thanks for your review. I've updated CompileGtest.gmk as you advised[1], which gives [2]. >> >> -- Igor >> >> [1] >>> diff -r 3443e083223d make/hotspot/lib/CompileGtest.gmk >>> --- a/make/hotspot/lib/CompileGtest.gmk Thu May 23 19:03:32 2019 -0700 >>> +++ b/make/hotspot/lib/CompileGtest.gmk Thu May 23 19:04:09 2019 -0700 >>> @@ -64,8 +64,9 @@ >>> EXCLUDES := $(JVM_EXCLUDES), \ >>> EXCLUDE_FILES := gtestLauncher.cpp, \ >>> EXCLUDE_PATTERNS := $(JVM_EXCLUDE_PATTERNS), \ >>> - EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/googletest/src/gtest-all.cc \ >>> - $(GTEST_FRAMEWORK_SRC)/googlemock/src/gmock-all.cc, \ >>> + EXTRA_FILES := \ >>> + $(GTEST_FRAMEWORK_SRC)/googletest/src/gtest-all.cc \ >>> + $(GTEST_FRAMEWORK_SRC)/googlemock/src/gmock-all.cc, \ >>> EXTRA_OBJECT_FILES := $(filter-out %/operator_new$(OBJ_SUFFIX), \ >>> $(BUILD_LIBJVM_ALL_OBJS)), \ >>> CFLAGS := $(JVM_CFLAGS) \ >> [2] http://cr.openjdk.java.net/~iignatyev/8222414/webrev.1-2/ >> >>> On May 23, 2019, at 6:57 AM, Erik Joelsson wrote: >>> >>> Hello Igor, >>> >>> Build changes look ok, with a (very) minor style suggestion [1] (point 18). We try to avoid padding continuation line breaks, so I would appreciate if CompileGtest.gmk:68 could be indented just 4 extra spaces compared to line 67. If you want the file names to line up, it's acceptable to break after the := on 67. >>> >>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html >>> >>> /Erik >>> >>> On 2019-05-22 22:20, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >>>>> 21638 lines changed: 21628 ins; 0 del; 10 mod; >>>> Hi all, >>>> >>>> could you please review this patch which makes mocking framework from google test available for hotspot tests? >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8222414 >>>> testing: tier1 >>>> webrevs: >>>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.00 >>>>> 21605 lines changed: 21605 ins; 0 del; 0 mod; >>>> * moves gtest from test/fmw/gtest to test/fmw/gtest/googletest; >>>> * adds only required (w/o build-aux, docs, make, msvc, scripts, tests directories and make related files) source of gmock to test/fmw/gtest/googlemock; >>>> >>>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.0-1 >>>>> 33 lines changed: 23 ins; 0 del; 10 mod; >>>> * makes necessary changes in makefiles >>>> * calls gmock framework init function >>>> * works around the conflict b/w :testing::internal::Log function defined by gmock and Log macro defined by hotspot >>>> >>>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >>>>> 21638 lines changed: 21628 ins; 0 del; 10 mod; >>>> all the changes together >>>> >>>> >>>> thanks, >>>> -- Igor From robin.westberg at oracle.com Mon May 27 07:54:56 2019 From: robin.westberg at oracle.com (Robin Westberg) Date: Mon, 27 May 2019 09:54:56 +0200 Subject: RFR(L/XS) : 8222414 : bring googlemock v1.8.1 In-Reply-To: <439DEFFE-970A-439A-B7C8-3B8D4748041D@oracle.com> References: <179E2496-5149-4521-896D-01E3B216A48F@oracle.com> <66A0B23F-22E3-4F6C-A55B-A16F09AEE557@oracle.com> <439DEFFE-970A-439A-B7C8-3B8D4748041D@oracle.com> Message-ID: Hi Igor, Looks good to me, I tried rewriting parts of an existing test to use gmock instead of a handcrafted mock, and things worked as expected! Best regards, Robin > On 24 May 2019, at 23:33, Igor Ignatyev wrote: > > @Erik, Thanks! > > @hotspot (looking at Robin), can I get another review? > > -- Igor > >> On May 24, 2019, at 8:28 AM, Erik Joelsson wrote: >> >> Thanks, looks good! >> >> /Erik >> >> On 2019-05-23 19:07, Igor Ignatyev wrote: >>> Hi Erik, >>> >>> thanks for your review. I've updated CompileGtest.gmk as you advised[1], which gives [2]. >>> >>> -- Igor >>> >>> [1] >>>> diff -r 3443e083223d make/hotspot/lib/CompileGtest.gmk >>>> --- a/make/hotspot/lib/CompileGtest.gmk Thu May 23 19:03:32 2019 -0700 >>>> +++ b/make/hotspot/lib/CompileGtest.gmk Thu May 23 19:04:09 2019 -0700 >>>> @@ -64,8 +64,9 @@ >>>> EXCLUDES := $(JVM_EXCLUDES), \ >>>> EXCLUDE_FILES := gtestLauncher.cpp, \ >>>> EXCLUDE_PATTERNS := $(JVM_EXCLUDE_PATTERNS), \ >>>> - EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/googletest/src/gtest-all.cc \ >>>> - $(GTEST_FRAMEWORK_SRC)/googlemock/src/gmock-all.cc, \ >>>> + EXTRA_FILES := \ >>>> + $(GTEST_FRAMEWORK_SRC)/googletest/src/gtest-all.cc \ >>>> + $(GTEST_FRAMEWORK_SRC)/googlemock/src/gmock-all.cc, \ >>>> EXTRA_OBJECT_FILES := $(filter-out %/operator_new$(OBJ_SUFFIX), \ >>>> $(BUILD_LIBJVM_ALL_OBJS)), \ >>>> CFLAGS := $(JVM_CFLAGS) \ >>> [2] http://cr.openjdk.java.net/~iignatyev/8222414/webrev.1-2/ >>> >>>> On May 23, 2019, at 6:57 AM, Erik Joelsson wrote: >>>> >>>> Hello Igor, >>>> >>>> Build changes look ok, with a (very) minor style suggestion [1] (point 18). We try to avoid padding continuation line breaks, so I would appreciate if CompileGtest.gmk:68 could be indented just 4 extra spaces compared to line 67. If you want the file names to line up, it's acceptable to break after the := on 67. >>>> >>>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html >>>> >>>> /Erik >>>> >>>> On 2019-05-22 22:20, Igor Ignatyev wrote: >>>>> http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >>>>>> 21638 lines changed: 21628 ins; 0 del; 10 mod; >>>>> Hi all, >>>>> >>>>> could you please review this patch which makes mocking framework from google test available for hotspot tests? >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8222414 >>>>> testing: tier1 >>>>> webrevs: >>>>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.00 >>>>>> 21605 lines changed: 21605 ins; 0 del; 0 mod; >>>>> * moves gtest from test/fmw/gtest to test/fmw/gtest/googletest; >>>>> * adds only required (w/o build-aux, docs, make, msvc, scripts, tests directories and make related files) source of gmock to test/fmw/gtest/googlemock; >>>>> >>>>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.0-1 >>>>>> 33 lines changed: 23 ins; 0 del; 10 mod; >>>>> * makes necessary changes in makefiles >>>>> * calls gmock framework init function >>>>> * works around the conflict b/w :testing::internal::Log function defined by gmock and Log macro defined by hotspot >>>>> >>>>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >>>>>> 21638 lines changed: 21628 ins; 0 del; 10 mod; >>>>> all the changes together >>>>> >>>>> >>>>> thanks, >>>>> -- Igor > From matthias.baesken at sap.com Mon May 27 08:28:49 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 27 May 2019 08:28:49 +0000 Subject: RFR: [XS] 8224750: Display thread once in Internal exceptions event log lines Message-ID: Hello, please review this small patch , it shortens the internal exceptions event log entries . Currently the internal exceptions-related event log - part in the hs_err file looks like this : Internal exceptions (20 events): Event: 9.075 Thread 0x000003ff7c971800 Exception (0x00000000d930ed40) thrown [/mydir/jdk/src/hotspot/share/oops/constantPool.cpp, line 777] for thread 0x000003ff7c971800 One can see that the thread is displayed ***twice*** in every line, once at the beginning : Event: 9.075 Thread 0x000003ff7c971800 and again at the end: for thread 0x000003ff7c971800 I think the thread- info should be displayed just once (saves a bit space and makes the output shorter). New output example : Event: 4.785 Thread 0x000003ff94a57800 Exception (0x00000000df139c28) thrown [/mydir/jdk/src/hotspot/share/prims/jni.cpp, line 598] Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8224750 http://cr.openjdk.java.net/~mbaesken/webrevs/8224750.0/ Thanks ,Matthias From tobias.hartmann at oracle.com Mon May 27 09:03:53 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 27 May 2019 11:03:53 +0200 Subject: [13] RFR: 8213416: Replace some enums with static const members in hotspot/compiler In-Reply-To: References: <1f7afc19-0756-33f8-54f5-2438ed5da886@oracle.com> <8f18e15d-cae8-58eb-b4a1-870ca6ffaf15@oracle.com> <62869e18-3deb-435d-1ce8-7726866d79eb@oracle.com> <8b22fc8b-af06-31a2-4033-4984ac4fcb5d@oracle.com> Message-ID: <20c8f52f-7a43-a658-77ad-40c8a3d74ff1@oracle.com> Hi Rahul, On 24.05.19 22:17, Rahul Raghavan wrote: > Request one more review approval for latest > http://cr.openjdk.java.net/~rraghavan/8213416/webrev.01/ Looks good to me. Best regards, Tobias From shade at redhat.com Mon May 27 10:36:41 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 27 May 2019 12:36:41 +0200 Subject: RFR (S) 8224796: C code is not compiled correctly due to undefined "i386" Message-ID: <02a4645e-102b-7f72-27ff-7c601d50f08c@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8224796 x86_32 tier1 tests time out (actually, fail) because of this. In short, recent change to compile C code with --std=c99 got "i386" undefined. Build system still sets "i586", and we should really use that. I don't want to regress stuff much by globally replacing i386->i586, so the new code handles *both* defines. This is what "handle both x86_64 and amd64" block in LinuxDebuggerLocal.c already does. I have not seen the failures on Mac due to ps_core.c, but it is better to be safe there as well. Fix: http://cr.openjdk.java.net/~shade/8224796/webrev.01/ Testing: {x86_64, x86_32} tier1; jdk-submit (running) -- Thanks, -Aleksey From david.holmes at oracle.com Mon May 27 11:21:58 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 May 2019 21:21:58 +1000 Subject: RFR (S) 8224796: C code is not compiled correctly due to undefined "i386" In-Reply-To: <02a4645e-102b-7f72-27ff-7c601d50f08c@redhat.com> References: <02a4645e-102b-7f72-27ff-7c601d50f08c@redhat.com> Message-ID: <64760841-ed2e-afc5-9d76-80feec62960d@oracle.com> Hi Aleksey, On 27/05/2019 8:36 pm, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8224796 > > x86_32 tier1 tests time out (actually, fail) because of this. > > In short, recent change to compile C code with --std=c99 got "i386" undefined. Build system still > sets "i586", and we should really use that. I don't want to regress stuff much by globally replacing > i386->i586, so the new code handles *both* defines. This is what "handle both x86_64 and amd64" > block in LinuxDebuggerLocal.c already does. I think the existing logic in that file is already quite confused. It should be using defines set by the build system only, to identify CPU etc, not compiler specific defines. So I really don't think we need to keep the i386 stuff in that file as it just adds to the confusion. But I won't fight you on it. > I have not seen the failures on Mac due to ps_core.c, but it is better to be safe there as well. There is no 32-bit macOS build AFAIK. Thanks, David > Fix: > http://cr.openjdk.java.net/~shade/8224796/webrev.01/ > > Testing: {x86_64, x86_32} tier1; jdk-submit (running) > From martin.doerr at sap.com Mon May 27 15:24:04 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 27 May 2019 15:24:04 +0000 Subject: [13] RFR (M): 8223213: Implement fast class initialization checks on x86-64 In-Reply-To: <42a8fc79-9497-b2eb-8dd9-a56e4ed85255@oracle.com> References: <85a4a478-9200-87f2-c966-49af21f687c2@oracle.com> <3e1ceae0-f7a9-e2e6-2b06-59a22540550d@oracle.com> <3d9c0897-0275-c341-fe33-5f0b6c94f253@oracle.com> <42a8fc79-9497-b2eb-8dd9-a56e4ed85255@oracle.com> Message-ID: Hi Vladimir, I've looked at your change an think it's good. Methods belonging to uninitialized classes are not inlined, so it looks fine to perform the check only at the nmethod entry. I'm not so familiar with JVMCI/AOT, so I haven't looked into this topic. Are these assertions safe? + assert(method()->needs_clinit_barrier(), "barrier not needed"); + assert(method()->holder()->is_being_initialized(), "barrier not needed"); Can it happen that initialization concurrently completes before they are evaluated? A small suggestion for x86 TemplateTable::invokeinterface: It'd be nice to replace load of interface klass by your new load_method_holder. Thanks for sharing performance numbers. Best regards, Martin From erik.helin at oracle.com Mon May 27 15:42:08 2019 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 27 May 2019 17:42:08 +0200 Subject: RFC: 8224599: Remove globals_ext.hpp In-Reply-To: <1a2b5561-15ed-1cb1-da00-c42de7b9b4c5@oracle.com> References: <32401252-77fc-0c34-c7e6-7b97e11e6487@oracle.com> <1a2b5561-15ed-1cb1-da00-c42de7b9b4c5@oracle.com> Message-ID: <0250e96f-a788-ccb6-a3b1-e64fa538400c@oracle.com> Hi Stefan, On 5/22/19 1:58 PM, Stefan Karlsson wrote: > I realized that some of the globals_ext code had been placed in > os_ext.hpp and not only in globals_ext.hpp. > > If it's appropriate, I've included it in this RFC: > ?http://cr.openjdk.java.net/~stefank/8224599/webrev.02.delta/ > ?http://cr.openjdk.java.net/~stefank/8224599/webrev.02/ v02 looks good to me as well, thanks for cleaning this up! Erik From shade at redhat.com Mon May 27 17:05:39 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 27 May 2019 19:05:39 +0200 Subject: RFR (S) 8224796: C code is not compiled correctly due to undefined "i386" In-Reply-To: <64760841-ed2e-afc5-9d76-80feec62960d@oracle.com> References: <02a4645e-102b-7f72-27ff-7c601d50f08c@redhat.com> <64760841-ed2e-afc5-9d76-80feec62960d@oracle.com> Message-ID: <866729db-80ad-7d11-d27d-e8e8be7f204d@redhat.com> On 5/27/19 1:21 PM, David Holmes wrote: > I think the existing logic in that file is already quite confused. It should be using defines set by > the build system only, to identify CPU etc, not compiler specific defines. So I really don't think > we need to keep the i386 stuff in that file as it just adds to the confusion. But I won't fight you > on it. Yeah, I was on the fence here too, but don't want to risk more regressions. The "ifs" were rewritten i586 to get the "proper" macro, and the i386 fallback block is just for additional safety. >> I have not seen the failures on Mac due to ps_core.c, but it is better to be safe there as well. > > There is no 32-bit macOS build AFAIK. I don't quite understand the comment here: do you suggest to remove that block, or? I am leaning on capturing i586 everywhere i386 was captured before. Thanks, -Aleksey From david.holmes at oracle.com Mon May 27 22:22:04 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 May 2019 08:22:04 +1000 Subject: RFR (S) 8224796: C code is not compiled correctly due to undefined "i386" In-Reply-To: <866729db-80ad-7d11-d27d-e8e8be7f204d@redhat.com> References: <02a4645e-102b-7f72-27ff-7c601d50f08c@redhat.com> <64760841-ed2e-afc5-9d76-80feec62960d@oracle.com> <866729db-80ad-7d11-d27d-e8e8be7f204d@redhat.com> Message-ID: <37308f7c-6db8-85eb-41f5-3528822d28cd@oracle.com> On 28/05/2019 3:05 am, Aleksey Shipilev wrote: > On 5/27/19 1:21 PM, David Holmes wrote: >> I think the existing logic in that file is already quite confused. It should be using defines set by >> the build system only, to identify CPU etc, not compiler specific defines. So I really don't think >> we need to keep the i386 stuff in that file as it just adds to the confusion. But I won't fight you >> on it. > > Yeah, I was on the fence here too, but don't want to risk more regressions. The "ifs" were rewritten > i586 to get the "proper" macro, and the i386 fallback block is just for additional safety. > >>> I have not seen the failures on Mac due to ps_core.c, but it is better to be safe there as well. >> >> There is no 32-bit macOS build AFAIK. > > I don't quite understand the comment here: do you suggest to remove that block, or? I am leaning on > capturing i586 everywhere i386 was captured before. That code is never built for 32-bit so neither i386 or i586 will ever be defined there. You can make the change but nothing will ever test it. Cheers, David > Thanks, > -Aleksey > From igor.ignatyev at oracle.com Tue May 28 02:47:13 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 27 May 2019 19:47:13 -0700 Subject: RFR(L/XS) : 8222414 : bring googlemock v1.8.1 In-Reply-To: References: <179E2496-5149-4521-896D-01E3B216A48F@oracle.com> <66A0B23F-22E3-4F6C-A55B-A16F09AEE557@oracle.com> <439DEFFE-970A-439A-B7C8-3B8D4748041D@oracle.com> Message-ID: <08CB35D2-CA5B-4AF7-B223-CC22DFCEF106@oracle.com> thanks Robin! pushed. -- Igor > On May 27, 2019, at 12:54 AM, Robin Westberg wrote: > > Hi Igor, > > Looks good to me, I tried rewriting parts of an existing test to use gmock instead of a handcrafted mock, and things worked as expected! > > Best regards, > Robin > >> On 24 May 2019, at 23:33, Igor Ignatyev wrote: >> >> @Erik, Thanks! >> >> @hotspot (looking at Robin), can I get another review? >> >> -- Igor >> >>> On May 24, 2019, at 8:28 AM, Erik Joelsson wrote: >>> >>> Thanks, looks good! >>> >>> /Erik >>> >>> On 2019-05-23 19:07, Igor Ignatyev wrote: >>>> Hi Erik, >>>> >>>> thanks for your review. I've updated CompileGtest.gmk as you advised[1], which gives [2]. >>>> >>>> -- Igor >>>> >>>> [1] >>>>> diff -r 3443e083223d make/hotspot/lib/CompileGtest.gmk >>>>> --- a/make/hotspot/lib/CompileGtest.gmk Thu May 23 19:03:32 2019 -0700 >>>>> +++ b/make/hotspot/lib/CompileGtest.gmk Thu May 23 19:04:09 2019 -0700 >>>>> @@ -64,8 +64,9 @@ >>>>> EXCLUDES := $(JVM_EXCLUDES), \ >>>>> EXCLUDE_FILES := gtestLauncher.cpp, \ >>>>> EXCLUDE_PATTERNS := $(JVM_EXCLUDE_PATTERNS), \ >>>>> - EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/googletest/src/gtest-all.cc \ >>>>> - $(GTEST_FRAMEWORK_SRC)/googlemock/src/gmock-all.cc, \ >>>>> + EXTRA_FILES := \ >>>>> + $(GTEST_FRAMEWORK_SRC)/googletest/src/gtest-all.cc \ >>>>> + $(GTEST_FRAMEWORK_SRC)/googlemock/src/gmock-all.cc, \ >>>>> EXTRA_OBJECT_FILES := $(filter-out %/operator_new$(OBJ_SUFFIX), \ >>>>> $(BUILD_LIBJVM_ALL_OBJS)), \ >>>>> CFLAGS := $(JVM_CFLAGS) \ >>>> [2] http://cr.openjdk.java.net/~iignatyev/8222414/webrev.1-2/ >>>> >>>>> On May 23, 2019, at 6:57 AM, Erik Joelsson wrote: >>>>> >>>>> Hello Igor, >>>>> >>>>> Build changes look ok, with a (very) minor style suggestion [1] (point 18). We try to avoid padding continuation line breaks, so I would appreciate if CompileGtest.gmk:68 could be indented just 4 extra spaces compared to line 67. If you want the file names to line up, it's acceptable to break after the := on 67. >>>>> >>>>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html >>>>> >>>>> /Erik >>>>> >>>>> On 2019-05-22 22:20, Igor Ignatyev wrote: >>>>>> http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >>>>>>> 21638 lines changed: 21628 ins; 0 del; 10 mod; >>>>>> Hi all, >>>>>> >>>>>> could you please review this patch which makes mocking framework from google test available for hotspot tests? >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8222414 >>>>>> testing: tier1 >>>>>> webrevs: >>>>>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.00 >>>>>>> 21605 lines changed: 21605 ins; 0 del; 0 mod; >>>>>> * moves gtest from test/fmw/gtest to test/fmw/gtest/googletest; >>>>>> * adds only required (w/o build-aux, docs, make, msvc, scripts, tests directories and make related files) source of gmock to test/fmw/gtest/googlemock; >>>>>> >>>>>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.0-1 >>>>>>> 33 lines changed: 23 ins; 0 del; 10 mod; >>>>>> * makes necessary changes in makefiles >>>>>> * calls gmock framework init function >>>>>> * works around the conflict b/w :testing::internal::Log function defined by gmock and Log macro defined by hotspot >>>>>> >>>>>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >>>>>>> 21638 lines changed: 21628 ins; 0 del; 10 mod; >>>>>> all the changes together >>>>>> >>>>>> >>>>>> thanks, >>>>>> -- Igor >> > From shade at redhat.com Tue May 28 07:39:43 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 28 May 2019 09:39:43 +0200 Subject: RFR (S) 8224796: C code is not compiled correctly due to undefined "i386" In-Reply-To: <02a4645e-102b-7f72-27ff-7c601d50f08c@redhat.com> References: <02a4645e-102b-7f72-27ff-7c601d50f08c@redhat.com> Message-ID: <5f452593-87d3-5039-051e-915ec76bf29c@redhat.com> On 5/27/19 12:36 PM, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8224796 > > x86_32 tier1 tests time out (actually, fail) because of this. > > In short, recent change to compile C code with --std=c99 got "i386" undefined. Build system still > sets "i586", and we should really use that. I don't want to regress stuff much by globally replacing > i386->i586, so the new code handles *both* defines. This is what "handle both x86_64 and amd64" > block in LinuxDebuggerLocal.c already does. > > I have not seen the failures on Mac due to ps_core.c, but it is better to be safe there as well. > > Fix: > http://cr.openjdk.java.net/~shade/8224796/webrev.01/ David had reviewed. More reviews, please? -- Thanks, -Aleksey From martin.doerr at sap.com Tue May 28 09:02:09 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 28 May 2019 09:02:09 +0000 Subject: RFR: [XS] 8224750: Display thread once in Internal exceptions event log lines In-Reply-To: References: Message-ID: Hi Matthias, looks good. Thanks, Martin > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Montag, 27. Mai 2019 10:29 > To: 'hotspot-dev at openjdk.java.net' > Subject: RFR: [XS] 8224750: Display thread once in Internal exceptions event > log lines > > Hello, please review this small patch , it shortens the internal exceptions > event log entries . > > > Currently the internal exceptions-related event log - part in the hs_err file > looks like this : > > Internal exceptions (20 events): > Event: 9.075 Thread 0x000003ff7c971800 Exception info/signature ....> (0x00000000d930ed40) > thrown [/mydir/jdk/src/hotspot/share/oops/constantPool.cpp, line 777] > for thread 0x000003ff7c971800 > > > One can see that the thread is displayed ***twice*** in every line, once at > the beginning : > Event: 9.075 Thread 0x000003ff7c971800 > > and again at the end: > for thread 0x000003ff7c971800 > > I think the thread- info should be displayed just once (saves a bit space and > makes the output shorter). > > New output example : > > Event: 4.785 Thread 0x000003ff94a57800 Exception 'java/lang/NoSuchFieldError'{0x00000000df139c28}> (0x00000000df139c28) > thrown [/mydir/jdk/src/hotspot/share/prims/jni.cpp, line 598] > > > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8224750 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224750.0/ > > > > Thanks ,Matthias From matthias.baesken at sap.com Tue May 28 09:55:35 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 28 May 2019 09:55:35 +0000 Subject: RFR: [XS] 8224750: Display thread once in Internal exceptions event log lines In-Reply-To: References: Message-ID: Thanks Martin ! Is a second review needed for the XS change, or 1 sufficient because it is XS ? Best regards, Matthias > -----Original Message----- > From: Doerr, Martin > Sent: Dienstag, 28. Mai 2019 11:02 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Subject: RE: RFR: [XS] 8224750: Display thread once in Internal exceptions > event log lines > > Hi Matthias, > > looks good. > > Thanks, > Martin > > > > -----Original Message----- > > From: hotspot-dev On Behalf > Of > > Baesken, Matthias > > Sent: Montag, 27. Mai 2019 10:29 > > To: 'hotspot-dev at openjdk.java.net' > > Subject: RFR: [XS] 8224750: Display thread once in Internal exceptions > event > > log lines > > > > Hello, please review this small patch , it shortens the internal exceptions > > event log entries . > > > > > > Currently the internal exceptions-related event log - part in the hs_err file > > looks like this : > > > > Internal exceptions (20 events): > > Event: 9.075 Thread 0x000003ff7c971800 Exception > info/signature ....> (0x00000000d930ed40) > > thrown [/mydir/jdk/src/hotspot/share/oops/constantPool.cpp, line 777] > > for thread 0x000003ff7c971800 > > > > > > One can see that the thread is displayed ***twice*** in every line, once at > > the beginning : > > Event: 9.075 Thread 0x000003ff7c971800 > > > > and again at the end: > > for thread 0x000003ff7c971800 > > > > I think the thread- info should be displayed just once (saves a bit space and > > makes the output shorter). > > > > New output example : > > > > Event: 4.785 Thread 0x000003ff94a57800 Exception > 'java/lang/NoSuchFieldError'{0x00000000df139c28}> (0x00000000df139c28) > > thrown [/mydir/jdk/src/hotspot/share/prims/jni.cpp, line 598] > > > > > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8224750 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224750.0/ > > > > > > > > Thanks ,Matthias From coleen.phillimore at oracle.com Tue May 28 10:10:26 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 28 May 2019 06:10:26 -0400 Subject: RFR: [XS] 8224750: Display thread once in Internal exceptions event log lines In-Reply-To: References: Message-ID: <1a9eee18-001d-0074-73f0-979fcd0a638a@oracle.com> +1 Thank you! Coleen On 5/28/19 5:55 AM, Baesken, Matthias wrote: > Thanks Martin ! > > Is a second review needed for the XS change, or 1 sufficient because it is XS ? > > Best regards, Matthias > > > >> -----Original Message----- >> From: Doerr, Martin >> Sent: Dienstag, 28. Mai 2019 11:02 >> To: Baesken, Matthias ; 'hotspot- >> dev at openjdk.java.net' >> Subject: RE: RFR: [XS] 8224750: Display thread once in Internal exceptions >> event log lines >> >> Hi Matthias, >> >> looks good. >> >> Thanks, >> Martin >> >> >>> -----Original Message----- >>> From: hotspot-dev On Behalf >> Of >>> Baesken, Matthias >>> Sent: Montag, 27. Mai 2019 10:29 >>> To: 'hotspot-dev at openjdk.java.net' >>> Subject: RFR: [XS] 8224750: Display thread once in Internal exceptions >> event >>> log lines >>> >>> Hello, please review this small patch , it shortens the internal exceptions >>> event log entries . >>> >>> >>> Currently the internal exceptions-related event log - part in the hs_err file >>> looks like this : >>> >>> Internal exceptions (20 events): >>> Event: 9.075 Thread 0x000003ff7c971800 Exception >> info/signature ....> (0x00000000d930ed40) >>> thrown [/mydir/jdk/src/hotspot/share/oops/constantPool.cpp, line 777] >>> for thread 0x000003ff7c971800 >>> >>> >>> One can see that the thread is displayed ***twice*** in every line, once at >>> the beginning : >>> Event: 9.075 Thread 0x000003ff7c971800 >>> >>> and again at the end: >>> for thread 0x000003ff7c971800 >>> >>> I think the thread- info should be displayed just once (saves a bit space and >>> makes the output shorter). >>> >>> New output example : >>> >>> Event: 4.785 Thread 0x000003ff94a57800 Exception >> 'java/lang/NoSuchFieldError'{0x00000000df139c28}> (0x00000000df139c28) >>> thrown [/mydir/jdk/src/hotspot/share/prims/jni.cpp, line 598] >>> >>> >>> >>> >>> Bug/webrev : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8224750 >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8224750.0/ >>> >>> >>> >>> Thanks ,Matthias From martin.doerr at sap.com Tue May 28 10:09:40 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 28 May 2019 10:09:40 +0000 Subject: RFR: [XS] 8224750: Display thread once in Internal exceptions event log lines In-Reply-To: References: Message-ID: Hi Matthias, I think the trivial rule can be applied. So you can push it if nobody else reviews it until tomorrow. Best regards, Martin > -----Original Message----- > From: Baesken, Matthias > Sent: Dienstag, 28. Mai 2019 11:56 > To: Doerr, Martin ; 'hotspot- > dev at openjdk.java.net' > Subject: RE: RFR: [XS] 8224750: Display thread once in Internal exceptions > event log lines > > Thanks Martin ! > > Is a second review needed for the XS change, or 1 sufficient because it is XS > ? > > Best regards, Matthias > > > > > -----Original Message----- > > From: Doerr, Martin > > Sent: Dienstag, 28. Mai 2019 11:02 > > To: Baesken, Matthias ; 'hotspot- > > dev at openjdk.java.net' > > Subject: RE: RFR: [XS] 8224750: Display thread once in Internal exceptions > > event log lines > > > > Hi Matthias, > > > > looks good. > > > > Thanks, > > Martin > > > > > > > -----Original Message----- > > > From: hotspot-dev On Behalf > > Of > > > Baesken, Matthias > > > Sent: Montag, 27. Mai 2019 10:29 > > > To: 'hotspot-dev at openjdk.java.net' > > > Subject: RFR: [XS] 8224750: Display thread once in Internal exceptions > > event > > > log lines > > > > > > Hello, please review this small patch , it shortens the internal exceptions > > > event log entries . > > > > > > > > > Currently the internal exceptions-related event log - part in the hs_err > file > > > looks like this : > > > > > > Internal exceptions (20 events): > > > Event: 9.075 Thread 0x000003ff7c971800 Exception related > > > info/signature ....> (0x00000000d930ed40) > > > thrown [/mydir/jdk/src/hotspot/share/oops/constantPool.cpp, line 777] > > > for thread 0x000003ff7c971800 > > > > > > > > > One can see that the thread is displayed ***twice*** in every line, once > at > > > the beginning : > > > Event: 9.075 Thread 0x000003ff7c971800 > > > > > > and again at the end: > > > for thread 0x000003ff7c971800 > > > > > > I think the thread- info should be displayed just once (saves a bit space > and > > > makes the output shorter). > > > > > > New output example : > > > > > > Event: 4.785 Thread 0x000003ff94a57800 Exception > > 'java/lang/NoSuchFieldError'{0x00000000df139c28}> > (0x00000000df139c28) > > > thrown [/mydir/jdk/src/hotspot/share/prims/jni.cpp, line 598] > > > > > > > > > > > > > > > Bug/webrev : > > > > > > https://bugs.openjdk.java.net/browse/JDK-8224750 > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224750.0/ > > > > > > > > > > > > Thanks ,Matthias From vladimir.x.ivanov at oracle.com Tue May 28 11:40:31 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 28 May 2019 14:40:31 +0300 Subject: [13] RFR (M): 8223213: Implement fast class initialization checks on x86-64 In-Reply-To: References: <85a4a478-9200-87f2-c966-49af21f687c2@oracle.com> <3e1ceae0-f7a9-e2e6-2b06-59a22540550d@oracle.com> <3d9c0897-0275-c341-fe33-5f0b6c94f253@oracle.com> <42a8fc79-9497-b2eb-8dd9-a56e4ed85255@oracle.com> Message-ID: Thanks, Martin. Updated webrev: http://cr.openjdk.java.net/~vlivanov/8223213/webrev.02/ > Are these assertions safe? > + assert(method()->needs_clinit_barrier(), "barrier not needed"); > + assert(method()->holder()->is_being_initialized(), "barrier not needed"); > Can it happen that initialization concurrently completes before they are evaluated? Good point. Even though ciInstanceKlass caches initialization state of the corresponding InstanceKlass, it seems there's a possibility that the state is updated during the compilation (see ciInstanceKlass::update_if_shared). I enhanced the asserts to check that initialization has been stated. > A small suggestion for x86 TemplateTable::invokeinterface: > It'd be nice to replace load of interface klass by your new load_method_holder. Agree. Updated. Best regards, Vladimir Ivanov From aph at redhat.com Tue May 28 13:20:17 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 May 2019 14:20:17 +0100 Subject: RFR: 8224880: AArch64: java/javac error with AllocatePrefetchDistance Message-ID: <49cbc64d-23a7-dbac-ab90-5b5e5fa81e67@redhat.com> The default AllocatePrefetchDistance is 3 * the dcache line size. http://hg.openjdk.java.net/jdk/jdk11/file/tip/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp#l132 If the cache line size is 256, we trip over an error at http://hg.openjdk.java.net/jdk/jdk11/file/tip/src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp#l93 This is because the prefetch distance is limited to 512. Webrev: http://cr.openjdk.java.net/~aph/8224880/ -- 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 adinn at redhat.com Tue May 28 13:27:08 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 28 May 2019 14:27:08 +0100 Subject: [aarch64-port-dev ] RFR: 8224880: AArch64: java/javac error with AllocatePrefetchDistance In-Reply-To: <49cbc64d-23a7-dbac-ab90-5b5e5fa81e67@redhat.com> References: <49cbc64d-23a7-dbac-ab90-5b5e5fa81e67@redhat.com> Message-ID: <6adc41dd-7241-fbde-4b50-810ec70e60b8@redhat.com> On 28/05/2019 14:20, Andrew Haley wrote: > The default AllocatePrefetchDistance is 3 * the dcache line size. > > http://hg.openjdk.java.net/jdk/jdk11/file/tip/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp#l132 > > If the cache line size is 256, we trip over an error at > > http://hg.openjdk.java.net/jdk/jdk11/file/tip/src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp#l93 > > This is because the prefetch distance is limited to 512. > > Webrev: http://cr.openjdk.java.net/~aph/8224880/ Yup, good to go and trivial too! (i.e doesn't need another review). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From martin.doerr at sap.com Tue May 28 14:03:44 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 28 May 2019 14:03:44 +0000 Subject: [13] RFR (M): 8223213: Implement fast class initialization checks on x86-64 In-Reply-To: References: <85a4a478-9200-87f2-c966-49af21f687c2@oracle.com> <3e1ceae0-f7a9-e2e6-2b06-59a22540550d@oracle.com> <3d9c0897-0275-c341-fe33-5f0b6c94f253@oracle.com> <42a8fc79-9497-b2eb-8dd9-a56e4ed85255@oracle.com> Message-ID: Hi Vladimir, thanks for the update. Looks good. Best regards, Martin > -----Original Message----- > From: Vladimir Ivanov > Sent: Dienstag, 28. Mai 2019 13:41 > To: Doerr, Martin ; hotspot compiler compiler-dev at openjdk.java.net>; hotspot-runtime-dev dev at openjdk.java.net>; hotspot-dev developers dev at openjdk.java.net> > Subject: Re: [13] RFR (M): 8223213: Implement fast class initialization checks > on x86-64 > > Thanks, Martin. > > Updated webrev: > http://cr.openjdk.java.net/~vlivanov/8223213/webrev.02/ > > > Are these assertions safe? > > + assert(method()->needs_clinit_barrier(), "barrier not needed"); > > + assert(method()->holder()->is_being_initialized(), "barrier not > needed"); > > Can it happen that initialization concurrently completes before they are > evaluated? > > Good point. Even though ciInstanceKlass caches initialization state of > the corresponding InstanceKlass, it seems there's a possibility that the > state is updated during the compilation (see > ciInstanceKlass::update_if_shared). I enhanced the asserts to check that > initialization has been stated. > > > A small suggestion for x86 TemplateTable::invokeinterface: > > It'd be nice to replace load of interface klass by your new > load_method_holder. > > Agree. Updated. > > Best regards, > Vladimir Ivanov From mikael.vidstedt at oracle.com Tue May 28 14:29:26 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 28 May 2019 07:29:26 -0700 Subject: RFR (S) 8224796: C code is not compiled correctly due to undefined "i386" In-Reply-To: <5f452593-87d3-5039-051e-915ec76bf29c@redhat.com> References: <02a4645e-102b-7f72-27ff-7c601d50f08c@redhat.com> <5f452593-87d3-5039-051e-915ec76bf29c@redhat.com> Message-ID: <0911F8E1-4883-4ECE-A676-8FF37B4FF5F3@oracle.com> Looks good. The if-define-to-code ratio in LinuxDebuggerLocal.c is impressively high, in a bad way. An enhancement to cover cleaning it up sure wouldn?t hurt. Cheers, Mikael > On May 28, 2019, at 12:39 AM, Aleksey Shipilev wrote: > > On 5/27/19 12:36 PM, Aleksey Shipilev wrote: >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8224796 >> >> x86_32 tier1 tests time out (actually, fail) because of this. >> >> In short, recent change to compile C code with --std=c99 got "i386" undefined. Build system still >> sets "i586", and we should really use that. I don't want to regress stuff much by globally replacing >> i386->i586, so the new code handles *both* defines. This is what "handle both x86_64 and amd64" >> block in LinuxDebuggerLocal.c already does. >> >> I have not seen the failures on Mac due to ps_core.c, but it is better to be safe there as well. >> >> Fix: >> http://cr.openjdk.java.net/~shade/8224796/webrev.01/ > > David had reviewed. More reviews, please? > > -- > Thanks, > -Aleksey > From vladimir.kozlov at oracle.com Tue May 28 17:32:16 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 May 2019 10:32:16 -0700 Subject: [13] RFR: 8213416: Replace some enums with static const members in hotspot/compiler In-Reply-To: <20c8f52f-7a43-a658-77ad-40c8a3d74ff1@oracle.com> References: <1f7afc19-0756-33f8-54f5-2438ed5da886@oracle.com> <8f18e15d-cae8-58eb-b4a1-870ca6ffaf15@oracle.com> <62869e18-3deb-435d-1ce8-7726866d79eb@oracle.com> <8b22fc8b-af06-31a2-4033-4984ac4fcb5d@oracle.com> <20c8f52f-7a43-a658-77ad-40c8a3d74ff1@oracle.com> Message-ID: <0A00046F-0454-4469-B348-B687B1B96989@oracle.com> Yes, I like this version of fix. Reviewed. Thanks Vladimir > On May 27, 2019, at 2:03 AM, Tobias Hartmann wrote: > > Hi Rahul, > >> On 24.05.19 22:17, Rahul Raghavan wrote: >> Request one more review approval for latest >> http://cr.openjdk.java.net/~rraghavan/8213416/webrev.01/ > > Looks good to me. > > Best regards, > Tobias From kim.barrett at oracle.com Tue May 28 18:10:22 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 28 May 2019 14:10:22 -0400 Subject: RFR: 8213415: BitMap::word_index_round_up overflow problems Message-ID: <24C2BDC9-AC35-4804-95C8-1B59747C1494@oracle.com> 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 shade at redhat.com Tue May 28 19:29:49 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 28 May 2019 21:29:49 +0200 Subject: RFR (S) 8224796: C code is not compiled correctly due to undefined "i386" In-Reply-To: <0911F8E1-4883-4ECE-A676-8FF37B4FF5F3@oracle.com> References: <02a4645e-102b-7f72-27ff-7c601d50f08c@redhat.com> <5f452593-87d3-5039-051e-915ec76bf29c@redhat.com> <0911F8E1-4883-4ECE-A676-8FF37B4FF5F3@oracle.com> Message-ID: <904816c0-0726-0a13-9fc8-7379b4a7abe3@redhat.com> On 5/28/19 4:29 PM, Mikael Vidstedt wrote: > Looks good. Thanks. > The if-define-to-code ratio in LinuxDebuggerLocal.c is impressively high, in a bad way. An > enhancement to cover cleaning it up sure wouldn?t hurt. I agree. -Aleksey From daniel.daugherty at oracle.com Tue May 28 20:32:02 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 28 May 2019 16:32:02 -0400 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <2ddfbcbd-4dff-4b86-ba0b-d5920b80e7ec@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <9dc5704c-7f87-e231-f3cc-7508c1a6d75c@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> Message-ID: <38eaa1b2-5fde-ca1d-0842-3d7f2b34e483@oracle.com> On 4/30/19 11: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/ General comment: - Way back on 2019.03.01 Andrew Haley asked about performance testing. ? I can't find a clear answer that says what performance testing was ? done, when and on which version of the patch. - Please double check copyright years on the files before you push; ? I spotted these (but I didn't check all of them): ??? src/hotspot/cpu/x86/assembler_x86.cpp ??? src/hotspot/share/opto/library_call.cpp - This is only a partial review. I didn't review non-Oracle platform ? or OS code. src/hotspot/share/runtime/stubRoutines.hpp ??? L371 - nit - please delete extra blank line src/hotspot/share/runtime/stubRoutines.cpp ??? No comments. src/hotspot/share/runtime/thread.hpp ??? No comments. src/hotspot/share/prims/unsafe.cpp ??? L160: ??? // been truncated and is now invalid ??????? nit - please add '.' to end the sentence (came from the original, moved code). 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? src/hotspot/cpu/sparc/stubGenerator_sparc.cpp ??? L5867: ??? UnsafeCopyMemory::create_table(8); ??????? Should the literal '8' be a defined value from somewhere? src/hotspot/cpu/x86/assembler_x86.cpp ??? L4191: ? NOT_LP64(assert(VM_Version::supports_sse2(), "")); ??? L4310: ? NOT_LP64(assert(VM_Version::supports_sse2(), "")); ??????? assert() string should not be empty. src/hotspot/cpu/x86/assembler_x86.hpp ??? No comments. src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ??? L3919: ??? UnsafeCopyMemory::create_table(8); ??????? Should the literal '8' be a defined value from somewhere? src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ??? L1505-08 - nit - indent is 2 spaces too much ??? L6232: ??? UnsafeCopyMemory::create_table(32); ??????? Should the literal '32' be a defined value from somewhere? ??? Note: This is a mind numbing amount of assembly code changes. ??????? It's hard to say that I've reviewed and truly understand ??????? all the changes. src/hotspot/cpu/x86/stubRoutines_x86.hpp ??? No comments. src/hotspot/os/windows/os_windows.cpp ??? L2565: ????? bool is_unsafe_arraycopy = (_thread_in_native || in_java) && UnsafeCopyMemory::contains_pc(pc); ??????? I'm not understanding the use of '_thread_in_native' as a flag ??????? instead of a comparator against thread->thread_state(). Should ??????? that part be this: ? ? ? ? ? ? thread->thread_state() == _thread_in_native ??????? That would match with how the 'in_java' var is set: ????????? L2457: ??? bool in_java = thread->thread_state() == _thread_in_Java; src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp ??? L280: nit - please delete extra blank line src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp ??? No comments. src/hotspot/os_cpu/solaris_sparc/os_solaris_sparc.cpp ??? No comments. src/hotspot/os_cpu/solaris_x86/os_solaris_x86.cpp ??? No comments. test/hotspot/jtreg/runtime/Unsafe/InternalErrorTest.java ??? L31:? * @library /test/lib ??? L32:? *?? @build sun.hotspot.WhiteBox ??????? Not sure why the '@build' is indented. ??? L42: import java.lang.reflect.Field; ??? L48: import java.lang.reflect.Method; ??????? L48 should be after L42. ??? L95: ??????????? } catch (InternalError e) { ??? L99: ????????????? } ??????? nit - L99 indent is 2 spaces off ???? L96: ??????????????? if (!e.getMessage().contains("fault occurred in a recent unsafe memory access")) { ??? L111: ??????????????? if (!e.getMessage().contains("fault occurred in a recent unsafe memory access")) { ??? L126: ??????????????? if (!e.getMessage().contains("fault occurred in a recent unsafe memory access")) { ??????? These literal strings should be replace by a single ??????? final string. ??? L102: ??????? Method m = InternalErrorTest.class.getMethod("test",MappedByteBuffer.class, Unsafe.class, long.class, long.class, int.class); ??? L117: ??????? m = InternalErrorTest.class.getMethod("test",MappedByteBuffer.class, Unsafe.class, long.class, long.class, int.class); ??????? nit - need space after '"test",' ??? L135: ??? public static void test(MappedByteBuffer buffer, Unsafe unsafe, long mapAddr, long allocMem, int type? ) { ??????? nit - extra spaces before ')' ??? L138: ??????????????? buffer.get(new byte[8]); ??? L141: ??????????????? unsafe.copySwapMemory(null, mapAddr + pageSize, new byte[4000], 16, 2000, 2); ??? L144: ??????????????? unsafe.copySwapMemory(null, mapAddr + pageSize, null, allocMem, 2000, 2); ??????? A short comment above each of these 'tests' would help the ??????? reader understand what you are testing. I think the only possible significant issue here is in src/hotspot/os/windows/os_windows.cpp above. I did not review these files: src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp src/hotspot/cpu/arm/stubGenerator_arm.cpp src/hotspot/cpu/ppc/stubGenerator_ppc.cpp src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp src/hotspot/os_cpu/linux_s390/os_linux_s390.cpp src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp Dan > > what changed > > 1) Unsafe Copy Memory regions, error exits are captured using > UnsafeCopyMemoryMark, UnsafeCopyMemory. > > 2) all Unsafe copy (intrinsic or native) ,uses array copy stub. > > 3) Unsafe copyswap x64 implementation extends arraycopy stub and used > as reliable exit(fast exit too)*. it is not implemented for other > platforms. > > *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 coleen.phillimore at oracle.com Tue May 28 21:24:52 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 28 May 2019 17:24:52 -0400 Subject: [13] RFR (M): 8223213: Implement fast class initialization checks on x86-64 In-Reply-To: References: <85a4a478-9200-87f2-c966-49af21f687c2@oracle.com> <3e1ceae0-f7a9-e2e6-2b06-59a22540550d@oracle.com> <3d9c0897-0275-c341-fe33-5f0b6c94f253@oracle.com> <42a8fc79-9497-b2eb-8dd9-a56e4ed85255@oracle.com> Message-ID: I reviewed mostly the interpreter and shared change.? As someone else commented, I don't like the addition of a develop flag because some platforms don't support class initialization barriers.? Isn't it normal to do this with the misnamed VM_Version, like adding VM_Version::supports_class_initialization_barriers() with x86 returning true until the other platforms false until they implement the feature.? Then there isn't another flag configuration to test (or not test). http://cr.openjdk.java.net/~vlivanov/8223213/webrev.02/src/hotspot/cpu/x86/interp_masm_x86.cpp.udiff.html I have to admit that the relationship between resolved bytecode in bytecode_1/bytecode_2 and which _f1/_f2 held the Method* was actually a surprise to me.? There's nothing structurally in cpCache other than reading the code that enforces this and it wasn't always a Method* in f2 for invokeinterface, for example, so it's sort of an accident. But this code is correct and I think as a follow up we should make load_invoke_cp_cache_entry() call load_resolved_method_at_index() too and have some assert in cpCache that this is true, or rewrite the cpCache completely. The code to do the initialization barrier in the interpreter looks good. Thanks, Coleen On 5/28/19 7:40 AM, Vladimir Ivanov wrote: > Thanks, Martin. > > Updated webrev: > ? http://cr.openjdk.java.net/~vlivanov/8223213/webrev.02/ > >> Are these assertions safe? >> +?? assert(method()->needs_clinit_barrier(), "barrier not needed"); >> +?? assert(method()->holder()->is_being_initialized(), "barrier not >> needed"); >> Can it happen that initialization concurrently completes before they >> are evaluated? > > Good point. Even though ciInstanceKlass caches initialization state of > the corresponding InstanceKlass, it seems there's a possibility that > the state is updated during the compilation (see > ciInstanceKlass::update_if_shared). I enhanced the asserts to check > that initialization has been stated. Ok, this makes sense. > >> A small suggestion for x86 TemplateTable::invokeinterface: >> It'd be nice to replace load of interface klass by your new >> load_method_holder. > > Agree. Updated. This is nice. > > Best regards, > Vladimir Ivanov From david.holmes at oracle.com Wed May 29 04:32:38 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 May 2019 14:32:38 +1000 Subject: RFR(L/XS) : 8222414 : bring googlemock v1.8.1 In-Reply-To: <08CB35D2-CA5B-4AF7-B223-CC22DFCEF106@oracle.com> References: <179E2496-5149-4521-896D-01E3B216A48F@oracle.com> <66A0B23F-22E3-4F6C-A55B-A16F09AEE557@oracle.com> <439DEFFE-970A-439A-B7C8-3B8D4748041D@oracle.com> <08CB35D2-CA5B-4AF7-B223-CC22DFCEF106@oracle.com> Message-ID: <18a4b4c6-9572-2adf-d795-d108eae8649b@oracle.com> Hi Igor, FYI this seems to have broken the arm32 build. I've filed: https://bugs.openjdk.java.net/browse/JDK-8224945 David On 28/05/2019 12:47 pm, Igor Ignatyev wrote: > thanks Robin! pushed. > -- Igor > >> On May 27, 2019, at 12:54 AM, Robin Westberg wrote: >> >> Hi Igor, >> >> Looks good to me, I tried rewriting parts of an existing test to use gmock instead of a handcrafted mock, and things worked as expected! >> >> Best regards, >> Robin >> >>> On 24 May 2019, at 23:33, Igor Ignatyev wrote: >>> >>> @Erik, Thanks! >>> >>> @hotspot (looking at Robin), can I get another review? >>> >>> -- Igor >>> >>>> On May 24, 2019, at 8:28 AM, Erik Joelsson wrote: >>>> >>>> Thanks, looks good! >>>> >>>> /Erik >>>> >>>> On 2019-05-23 19:07, Igor Ignatyev wrote: >>>>> Hi Erik, >>>>> >>>>> thanks for your review. I've updated CompileGtest.gmk as you advised[1], which gives [2]. >>>>> >>>>> -- Igor >>>>> >>>>> [1] >>>>>> diff -r 3443e083223d make/hotspot/lib/CompileGtest.gmk >>>>>> --- a/make/hotspot/lib/CompileGtest.gmk Thu May 23 19:03:32 2019 -0700 >>>>>> +++ b/make/hotspot/lib/CompileGtest.gmk Thu May 23 19:04:09 2019 -0700 >>>>>> @@ -64,8 +64,9 @@ >>>>>> EXCLUDES := $(JVM_EXCLUDES), \ >>>>>> EXCLUDE_FILES := gtestLauncher.cpp, \ >>>>>> EXCLUDE_PATTERNS := $(JVM_EXCLUDE_PATTERNS), \ >>>>>> - EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/googletest/src/gtest-all.cc \ >>>>>> - $(GTEST_FRAMEWORK_SRC)/googlemock/src/gmock-all.cc, \ >>>>>> + EXTRA_FILES := \ >>>>>> + $(GTEST_FRAMEWORK_SRC)/googletest/src/gtest-all.cc \ >>>>>> + $(GTEST_FRAMEWORK_SRC)/googlemock/src/gmock-all.cc, \ >>>>>> EXTRA_OBJECT_FILES := $(filter-out %/operator_new$(OBJ_SUFFIX), \ >>>>>> $(BUILD_LIBJVM_ALL_OBJS)), \ >>>>>> CFLAGS := $(JVM_CFLAGS) \ >>>>> [2] http://cr.openjdk.java.net/~iignatyev/8222414/webrev.1-2/ >>>>> >>>>>> On May 23, 2019, at 6:57 AM, Erik Joelsson wrote: >>>>>> >>>>>> Hello Igor, >>>>>> >>>>>> Build changes look ok, with a (very) minor style suggestion [1] (point 18). We try to avoid padding continuation line breaks, so I would appreciate if CompileGtest.gmk:68 could be indented just 4 extra spaces compared to line 67. If you want the file names to line up, it's acceptable to break after the := on 67. >>>>>> >>>>>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html >>>>>> >>>>>> /Erik >>>>>> >>>>>> On 2019-05-22 22:20, Igor Ignatyev wrote: >>>>>>> http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >>>>>>>> 21638 lines changed: 21628 ins; 0 del; 10 mod; >>>>>>> Hi all, >>>>>>> >>>>>>> could you please review this patch which makes mocking framework from google test available for hotspot tests? >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8222414 >>>>>>> testing: tier1 >>>>>>> webrevs: >>>>>>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.00 >>>>>>>> 21605 lines changed: 21605 ins; 0 del; 0 mod; >>>>>>> * moves gtest from test/fmw/gtest to test/fmw/gtest/googletest; >>>>>>> * adds only required (w/o build-aux, docs, make, msvc, scripts, tests directories and make related files) source of gmock to test/fmw/gtest/googlemock; >>>>>>> >>>>>>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.0-1 >>>>>>>> 33 lines changed: 23 ins; 0 del; 10 mod; >>>>>>> * makes necessary changes in makefiles >>>>>>> * calls gmock framework init function >>>>>>> * works around the conflict b/w :testing::internal::Log function defined by gmock and Log macro defined by hotspot >>>>>>> >>>>>>> - http://cr.openjdk.java.net/~iignatyev//8222414/webrev.01 >>>>>>>> 21638 lines changed: 21628 ins; 0 del; 10 mod; >>>>>>> all the changes together >>>>>>> >>>>>>> >>>>>>> thanks, >>>>>>> -- Igor >>> >> > From igor.ignatyev at oracle.com Wed May 29 07:10:30 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 29 May 2019 00:10:30 -0700 Subject: RFR(T/S) : 8224945 : googlemock update breaks the build of arm32 Message-ID: http://cr.openjdk.java.net/~iignatyev//8224945/webrev.00/index.html > 10 lines changed: 10 ins; 0 del; 0 mod; Hi all, could you please review this small and trivial patch which undefines R, F1 and F2 macros in unittest.hpp so they won't conflict w/ typenames used in gmock? testing: extensive build testing (which found JDK-8224949 -- an unrelated breakage on linux-x86) webrev: http://cr.openjdk.java.net/~iignatyev//8224945/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8224945 Thanks, -- Igor From david.holmes at oracle.com Wed May 29 07:35:24 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 May 2019 17:35:24 +1000 Subject: RFR(T/S) : 8224945 : googlemock update breaks the build of arm32 In-Reply-To: References: Message-ID: <08bbcfde-33c5-1f07-6597-9db588a09452@oracle.com> Hi Igor, This looks good to me. Thanks for fixing so promptly. David On 29/05/2019 5:10 pm, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8224945/webrev.00/index.html >> 10 lines changed: 10 ins; 0 del; 0 mod; > > > Hi all, > > could you please review this small and trivial patch which undefines R, F1 and F2 macros in unittest.hpp so they won't conflict w/ typenames used in gmock? > > testing: extensive build testing (which found JDK-8224949 -- an unrelated breakage on linux-x86) > webrev: http://cr.openjdk.java.net/~iignatyev//8224945/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8224945 > > Thanks, > -- Igor > From volker.simonis at gmail.com Wed May 29 08:23:21 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 29 May 2019 10:23:21 +0200 Subject: RFR(T/S) : 8224945 : googlemock update breaks the build of arm32 In-Reply-To: References: Message-ID: Hi Igor, thanks for considering ppc in your fix as well. Your changes are definitely required on ppc but I'm not sure if that's enough. I'm currently running a build to verify that. I'll let you know in an hour or so. Best regards, Volker On Wed, May 29, 2019 at 9:11 AM Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8224945/webrev.00/index.html > > 10 lines changed: 10 ins; 0 del; 0 mod; > > > Hi all, > > could you please review this small and trivial patch which undefines R, F1 and F2 macros in unittest.hpp so they won't conflict w/ typenames used in gmock? > > testing: extensive build testing (which found JDK-8224949 -- an unrelated breakage on linux-x86) > webrev: http://cr.openjdk.java.net/~iignatyev//8224945/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8224945 > > Thanks, > -- Igor From volker.simonis at gmail.com Wed May 29 08:54:14 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 29 May 2019 10:54:14 +0200 Subject: RFR(T/S) : 8224945 : googlemock update breaks the build of arm32 In-Reply-To: References: Message-ID: Looks good! With your change I can successfully build ppc64 platfroms again! Thanks and thumbs up from me! On Wed, May 29, 2019 at 10:23 AM Volker Simonis wrote: > > Hi Igor, > > thanks for considering ppc in your fix as well. > > Your changes are definitely required on ppc but I'm not sure if that's > enough. I'm currently running a build to verify that. I'll let you > know in an hour or so. > > Best regards, > Volker > > On Wed, May 29, 2019 at 9:11 AM Igor Ignatyev wrote: > > > > http://cr.openjdk.java.net/~iignatyev//8224945/webrev.00/index.html > > > 10 lines changed: 10 ins; 0 del; 0 mod; > > > > > > Hi all, > > > > could you please review this small and trivial patch which undefines R, F1 and F2 macros in unittest.hpp so they won't conflict w/ typenames used in gmock? > > > > testing: extensive build testing (which found JDK-8224949 -- an unrelated breakage on linux-x86) > > webrev: http://cr.openjdk.java.net/~iignatyev//8224945/webrev.00/index.html > > JBS: https://bugs.openjdk.java.net/browse/JDK-8224945 > > > > Thanks, > > -- Igor From aph at redhat.com Wed May 29 13:12:53 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 May 2019 14:12:53 +0100 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> Message-ID: <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> On 5/29/19 11:26 AM, Nick Gasson wrote: > Please review this set of fixes to building hotspot with GCC 8.3 or > Clang 7.0 on AArch64. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224851 > Webrev: http://cr.openjdk.java.net/~ngasson/8224851/webrev.0/ > > Ran jtreg with no new failures. Oh dear. Experience has shown me (and probably you, too) that this is one of the most error-prone parts of software development. Many very serious failures have been caused by trying to shut up compilers. These failures have even included major security breaches. With that, let's press on with a heavy heart... > > This first one is with GCC 8.3: > > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/frame_aarch64.cpp: In function 'void pf(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)': > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/frame_aarch64.cpp:775:35: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class RegisterMap' with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Werror=class-memaccess] > memcpy(reg_map, &map, sizeof map); > ^ > > RegisterMap is non-POD because its base class AllocatedObj has virtual > methods, so we need to use copy-assignment rather than memcpy. But > because we're allocating reg_map with os::malloc we ought to use > placement new to properly construct it first. But we can't do that > because RegisterMap inherits from StackObj which disallows new. So I > just put in some casts to void * to silence the warning. We can't do that. It seems to me that this must be Undefined Behaviour, and we must never attempt to cover up UB with casts. > I can't see where `pf' and `internal_pf' are used - perhaps they can be > called manually from the debugger? They're debugger commands. That's why they have external C linkage. > If no one uses them maybe they should be deleted? Perhaps so. We have the debugger command pfl() which does all the frame printing I find I ever need. > The remaining warnings / errors are with Clang 7.0. > > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/assembler_aarch64.hpp:279:22: error: & has lower precedence than ==; == will be evaluated first [-Werror,-Wparentheses] > assert_cond(bits & mask == mask); > ^~~~~~~~~~~~~~ > > To preserve the behaviour we should write `bits & (mask == mask)' but I > don't think this was what was intended so I changed it to > `(bits & mask) == mask'. That's right. It's supposed to check that the field being read from an instruction has already been set. > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp:44:25: error: redeclaration of using declaration > using MacroAssembler::call_VM_leaf_base; > ~~~~~~~~~~~~~~~~^ > > This using declaration appears twice in a row. OK. > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/aarch64.ad:13866:80: error: invalid suffix 'D' on floating constant > __ fcmps(as_FloatRegister(opnd_array(1)->reg(ra_,this,idx1)/* src1 */), 0.0D); > ^ > > The "d" or "D" suffix on floating point literals is not in C++98. I > believe it comes from an extension to C to support decimal floating > point? Anyway it's not necessary here. OK. > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp:429:66: error: implicit conversion of NULL constant to 'bool' [-Werror,-Wnull-conversion] > arithmetic_op_fpu(x->op(), reg, left.result(), right.result(), NULL); > ~~~~~~~~~~~~~~~~~ ^~~~ > false > > The NULL here is for the `bool is_strictfp' argument to > LIRGenerator::arithmetic_op_fpu. Changing it to `false' would preserve > the existing behaviour but it seems like it should be `x->is_strictfp()' > to match other platforms. OK, use x->is_strictfp(). I don't think that it can possibly make any difference on AArch64. > As a consequence of this we need to handle the lir_{div,mul}_scriptfp > opcodes in LIR_Assembler::arith_op, but these just fall through to the > non-strictfp variants so there should be no behaviour change. Yep. > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp:1074:24: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses] > if (is_unordered && op->cond() == lir_cond_equal > ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Added parenthesis to make this explicit. No behaviour change. OK. I don't quite get what this is for, but I guess it shuts the compiler up and is harmless. > /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.s:162:32: error: index must be a multiple of 8 in range [0, 32760]. > prfm pldl1keep, [s, #-256] > ^ > > The immediate offset in `prfm' gets zero-extended to 64-bits and then > left shifted three places so can only be unsigned. GNU as actually > assembles [s, #-256] the same as [s]: > > 0: f9800000 prfm pldl1keep, [x0] > > Seems like GNU as ought to report an error here instead. I've replaced > this with `prfum' which has a sign-extended offset. OK. > /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.hpp:43:39: error: cannot initialize a parameter of type 'char *' with an lvalue of type 'unsigned long' > return __sync_add_and_fetch(dest, add_value); > ^~~~~~~~~ > > If the add_and_fetch template is instantiated with I=integer and > D=pointer then we need an explicit cast here. Please don't. Please have a look at where this happens and fix the types there, as appropriate. What do other ports do? > /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:679:8: error: conflicting types for '_Copy_conjoint_jshorts_atomic' > void _Copy_conjoint_jshorts_atomic(jshort* from, jshort* to, size_t count) { > ^ > > This family of functions is declared with const `from' pointer but in > the definition it is non-const. Made it const everywhere. OK. > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp:177:13: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses] > if (p = strchr(buf, ':')) { > ~~^~~~~~~~~~~~~~~~~~ > > Put parentheses around the argument. No functional change. OK. > /home/nicgas01/jdk/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp:2684:17: error: shifting a negative signed value is undefined [-Werror,-Wshift-negative-value] > offset &= -1<<12; > ~~^ Oh FFS. :-) This is perfectly legal in GCC and probably clang as well. > Rewrote as ~((1<<12) - 1) which matches the masks used in the rest of > the function. Let's not. All we have to do to create a mask is is use -1u<<12. I would challenge anyone to figure out without using a pencil what the effect of &= ~(((1<<12)-1)<<12) might be. > /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:103:20: error: variable 'esp' is uninitialized when used here [-Werror,-Wuninitialized] > return (address) esp; > ^~~ > /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:101:21: note: initialize the variable 'esp' to silence this warning > register void *esp __asm__ (SPELL_REG_SP); > ^ > = nullptr > > We could silence the -Wuninitialized warning for this function, but that > doesn't help much because Clang then compiles > os::current_stack_pointer() into: > > 0000000000000000 <_ZN2os21current_stack_pointerEv>: > 0: d65f03c0 ret > > Whereas with GCC we get: > > 0000000000000250 <_ZN2os21current_stack_pointerEv>: > 250: 910003e0 mov x0, sp > 254: d65f03c0 ret > > Added some inline assembly to explicitly move sp into the result #ifdef > __clang__. Same with _get_previous_fp(). This is all looking extremely fragile. We'd need to look at what the usages of this code are and trace through. -- 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 kim.barrett at oracle.com Wed May 29 14:44:26 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 29 May 2019 10:44:26 -0400 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> Message-ID: <4C8CB20E-43E3-4A9C-B7FB-76715CC616F6@oracle.com> Not a review, just briefly jumping in because I noticed one thing to correct. > On May 29, 2019, at 9:12 AM, Andrew Haley wrote: > > On 5/29/19 11:26 AM, Nick Gasson wrote: > > Oh dear. Experience has shown me (and probably you, too) that this is > one of the most error-prone parts of software development. Many > very serious failures have been caused by trying to shut up > compilers. These failures have even included major security breaches. > > With that, let's press on with a heavy heart? +1 on all that. >> This first one is with GCC 8.3: >> >> /home/nicgas01/jdk/src/hotspot/cpu/aarch64/frame_aarch64.cpp: In function 'void pf(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)': >> /home/nicgas01/jdk/src/hotspot/cpu/aarch64/frame_aarch64.cpp:775:35: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class RegisterMap' with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Werror=class-memaccess] >> memcpy(reg_map, &map, sizeof map); >> ^ >> >> RegisterMap is non-POD because its base class AllocatedObj has virtual >> methods, so we need to use copy-assignment rather than memcpy. But >> because we're allocating reg_map with os::malloc we ought to use >> placement new to properly construct it first. But we can't do that >> because RegisterMap inherits from StackObj which disallows new. So I >> just put in some casts to void * to silence the warning. > > We can't do that. It seems to me that this must be Undefined > Behaviour, and we must never attempt to cover up UB with casts. I think the solution here is to use placement new, but explicitly qualified to actually get there, e.g. ::new (reg_map) RegisterMap(map); Using unqualified new will do the lookup in RegisterMap, find some declarations in StackObj (but not the one we want) and fail. This is a pretty common pattern. >> /home/nicgas01/jdk/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp:2684:17: error: shifting a negative signed value is undefined [-Werror,-Wshift-negative-value] >> offset &= -1<<12; >> ~~^ > > Oh FFS. :-) This is perfectly legal in GCC and probably clang as well. Yeah, I sometimes think we should disable -Wshift-negative-value. From vladimir.x.ivanov at oracle.com Wed May 29 16:20:57 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 29 May 2019 19:20:57 +0300 Subject: [13] RFR (M): 8223213: Implement fast class initialization checks on x86-64 In-Reply-To: References: <85a4a478-9200-87f2-c966-49af21f687c2@oracle.com> <3e1ceae0-f7a9-e2e6-2b06-59a22540550d@oracle.com> <3d9c0897-0275-c341-fe33-5f0b6c94f253@oracle.com> <42a8fc79-9497-b2eb-8dd9-a56e4ed85255@oracle.com> Message-ID: <956790f2-5230-fa65-ca0a-77aa106ef462@oracle.com> Thanks, Coleen. Updated webrev: http://cr.openjdk.java.net/~vlivanov/8223213/webrev.03 Incremental webrev: http://cr.openjdk.java.net/~vlivanov/8223213/webrev.03_02/ > I reviewed mostly the interpreter and shared change.? As someone else > commented, I don't like the addition of a develop flag because some > platforms don't support class initialization barriers.? Isn't it normal > to do this with the misnamed VM_Version, like adding > VM_Version::supports_class_initialization_barriers() with x86 returning > true until the other platforms false until they implement the feature. > Then there isn't another flag configuration to test (or not test). I like your suggestion. Didn't know VM_Version is used in such a way. Replaced UseFastClassInitChecks with VM_Version::supports_fast_class_init_checks(). > http://cr.openjdk.java.net/~vlivanov/8223213/webrev.02/src/hotspot/cpu/x86/interp_masm_x86.cpp.udiff.html > > > I have to admit that the relationship between resolved bytecode in > bytecode_1/bytecode_2 and which _f1/_f2 held the Method* was actually a > surprise to me.? There's nothing structurally in cpCache other than > reading the code that enforces this and it wasn't always a Method* in f2 > for invokeinterface, for example, so it's sort of an accident. > > But this code is correct and I think as a follow up we should make > load_invoke_cp_cache_entry() call load_resolved_method_at_index() too > and have some assert in cpCache that this is true, or rewrite the > cpCache completely. I went ahead and changed load_invoke_cp_cache_entry() to call load_resolved_method_at_index() (along with some other minor refactorings). If you have any ideas/suggestions about the assert, I can add it as well. Best regards, Vladimir Ivanov > The code to do the initialization barrier in the interpreter looks good. > > Thanks, > Coleen > > On 5/28/19 7:40 AM, Vladimir Ivanov wrote: >> Thanks, Martin. >> >> Updated webrev: >> ? http://cr.openjdk.java.net/~vlivanov/8223213/webrev.02/ >> >>> Are these assertions safe? >>> +?? assert(method()->needs_clinit_barrier(), "barrier not needed"); >>> +?? assert(method()->holder()->is_being_initialized(), "barrier not >>> needed"); >>> Can it happen that initialization concurrently completes before they >>> are evaluated? >> >> Good point. Even though ciInstanceKlass caches initialization state of >> the corresponding InstanceKlass, it seems there's a possibility that >> the state is updated during the compilation (see >> ciInstanceKlass::update_if_shared). I enhanced the asserts to check >> that initialization has been stated. > > Ok, this makes sense. >> >>> A small suggestion for x86 TemplateTable::invokeinterface: >>> It'd be nice to replace load of interface klass by your new >>> load_method_holder. >> >> Agree. Updated. > > This is nice. > > >> >> Best regards, >> Vladimir Ivanov > From kim.barrett at oracle.com Wed May 29 17:24:56 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 29 May 2019 13:24:56 -0400 Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses Message-ID: [I?m not completely sure where this RFR should be sent, but core-libs-dev and hotspot-dev seems likely to get reasonable coverage of those who might care.] Please review this change to the test library to add some "logging" output to tests that spawn a child process to perform the test and then analyze that child's output. We are seeing occasional timeouts in such tests whose cause is hard to pin down. It's not clear whether the excess time is in the child or instead some problem in the testing framework. The new logging output provides timestamps for (1) the start of output collection from the child, (2) the start of waiting for the child to terminate, and (3) the child's termination. This should be enough to determine whether the child is taking too long, and hint at where (e.g. termination or not). CR: https://bugs.openjdk.java.net/browse/JDK-8219149 Webrev: http://cr.openjdk.java.net/~kbarrett/8219149/open.00/ Testing: Local hs-tier1 and verified the expected logging output is present. mach5 tier1-3 to ensure there aren't any "obvious" unexpected problems caused by the new logging. (It seems unlikely, but...) From igor.ignatyev at oracle.com Wed May 29 18:55:15 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 29 May 2019 11:55:15 -0700 Subject: RFR(T/S) : 8224945 : googlemock update breaks the build of arm32 In-Reply-To: References: Message-ID: <6542B8D1-DEA8-4A1D-A52F-4C8A001229D0@oracle.com> Volker, David, thanks for review! pushed. -- Igor > On May 29, 2019, at 1:54 AM, Volker Simonis wrote: > > Looks good! With your change I can successfully build ppc64 platfroms again! > > Thanks and thumbs up from me! > > On Wed, May 29, 2019 at 10:23 AM Volker Simonis > wrote: >> >> Hi Igor, >> >> thanks for considering ppc in your fix as well. >> >> Your changes are definitely required on ppc but I'm not sure if that's >> enough. I'm currently running a build to verify that. I'll let you >> know in an hour or so. >> >> Best regards, >> Volker >> >> On Wed, May 29, 2019 at 9:11 AM Igor Ignatyev wrote: >>> >>> http://cr.openjdk.java.net/~iignatyev//8224945/webrev.00/index.html >>>> 10 lines changed: 10 ins; 0 del; 0 mod; >>> >>> >>> Hi all, >>> >>> could you please review this small and trivial patch which undefines R, F1 and F2 macros in unittest.hpp so they won't conflict w/ typenames used in gmock? >>> >>> testing: extensive build testing (which found JDK-8224949 -- an unrelated breakage on linux-x86) >>> webrev: http://cr.openjdk.java.net/~iignatyev//8224945/webrev.00/index.html >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8224945 >>> >>> Thanks, >>> -- Igor From coleen.phillimore at oracle.com Wed May 29 19:06:50 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 29 May 2019 15:06:50 -0400 Subject: [13] RFR (M): 8223213: Implement fast class initialization checks on x86-64 In-Reply-To: <956790f2-5230-fa65-ca0a-77aa106ef462@oracle.com> References: <85a4a478-9200-87f2-c966-49af21f687c2@oracle.com> <3e1ceae0-f7a9-e2e6-2b06-59a22540550d@oracle.com> <3d9c0897-0275-c341-fe33-5f0b6c94f253@oracle.com> <42a8fc79-9497-b2eb-8dd9-a56e4ed85255@oracle.com> <956790f2-5230-fa65-ca0a-77aa106ef462@oracle.com> Message-ID: Vladimir, This looks good to me. On 5/29/19 12:20 PM, Vladimir Ivanov wrote: > Thanks, Coleen. > > Updated webrev: > ? http://cr.openjdk.java.net/~vlivanov/8223213/webrev.03 > > Incremental webrev: > ? http://cr.openjdk.java.net/~vlivanov/8223213/webrev.03_02/ > >> I reviewed mostly the interpreter and shared change.? As someone else >> commented, I don't like the addition of a develop flag because some >> platforms don't support class initialization barriers.? Isn't it >> normal to do this with the misnamed VM_Version, like adding >> VM_Version::supports_class_initialization_barriers() with x86 >> returning true until the other platforms false until they implement >> the feature. Then there isn't another flag configuration to test (or >> not test). > > I like your suggestion. Didn't know VM_Version is used in such a way. > > Replaced UseFastClassInitChecks with > VM_Version::supports_fast_class_init_checks(). > >> http://cr.openjdk.java.net/~vlivanov/8223213/webrev.02/src/hotspot/cpu/x86/interp_masm_x86.cpp.udiff.html >> >> >> I have to admit that the relationship between resolved bytecode in >> bytecode_1/bytecode_2 and which _f1/_f2 held the Method* was actually >> a surprise to me.? There's nothing structurally in cpCache other than >> reading the code that enforces this and it wasn't always a Method* in >> f2 for invokeinterface, for example, so it's sort of an accident. >> >> But this code is correct and I think as a follow up we should make >> load_invoke_cp_cache_entry() call load_resolved_method_at_index() too >> and have some assert in cpCache that this is true, or rewrite the >> cpCache completely. > > I went ahead and changed load_invoke_cp_cache_entry() to call > load_resolved_method_at_index() (along with some other minor > refactorings). If you have any ideas/suggestions about the assert, I > can add it as well. I think the change to use load_resolved_method_at_index() is good because if someone moves things around, it'll now fail very quickly.? I think this is the right amount of refactoring. Thanks, Coleen > > Best regards, > Vladimir Ivanov > >> The code to do the initialization barrier in the interpreter looks good. >> >> Thanks, >> Coleen >> >> On 5/28/19 7:40 AM, Vladimir Ivanov wrote: >>> Thanks, Martin. >>> >>> Updated webrev: >>> ? http://cr.openjdk.java.net/~vlivanov/8223213/webrev.02/ >>> >>>> Are these assertions safe? >>>> +?? assert(method()->needs_clinit_barrier(), "barrier not needed"); >>>> +?? assert(method()->holder()->is_being_initialized(), "barrier not >>>> needed"); >>>> Can it happen that initialization concurrently completes before >>>> they are evaluated? >>> >>> Good point. Even though ciInstanceKlass caches initialization state >>> of the corresponding InstanceKlass, it seems there's a possibility >>> that the state is updated during the compilation (see >>> ciInstanceKlass::update_if_shared). I enhanced the asserts to check >>> that initialization has been stated. >> >> Ok, this makes sense. >>> >>>> A small suggestion for x86 TemplateTable::invokeinterface: >>>> It'd be nice to replace load of interface klass by your new >>>> load_method_holder. >>> >>> Agree. Updated. >> >> This is nice. >> >> >>> >>> Best regards, >>> Vladimir Ivanov >> From daniel.daugherty at oracle.com Wed May 29 19:39:54 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 29 May 2019 15:39:54 -0400 Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses In-Reply-To: References: Message-ID: <9939af70-d94e-6f70-f997-76a6ab20084a@oracle.com> On 5/29/19 1:24 PM, Kim Barrett wrote: > [I?m not completely sure where this RFR should be sent, but core-libs-dev > and hotspot-dev seems likely to get reasonable coverage of those who > might care.] > > Please review this change to the test library to add some "logging" > output to tests that spawn a child process to perform the test and > then analyze that child's output. We are seeing occasional timeouts > in such tests whose cause is hard to pin down. It's not clear whether > the excess time is in the child or instead some problem in the testing > framework. The new logging output provides timestamps for (1) the > start of output collection from the child, (2) the start of waiting > for the child to terminate, and (3) the child's termination. This > should be enough to determine whether the child is taking too long, > and hint at where (e.g. termination or not). > > CR: > https://bugs.openjdk.java.net/browse/JDK-8219149 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8219149/open.00/ test/lib/jdk/test/lib/process/OutputBuffer.java ??? Based on the Java doc, it looks like the timestamp portion ??? will look something like this:? '2011-12-03T10:15:30Z' ??? I like it. Since I've been chasing some of the timeout bugs ??? in the CI, I look forward to seeing the new output... Thumbs up. Dan > > Testing: > Local hs-tier1 and verified the expected logging output is present. > mach5 tier1-3 to ensure there aren't any "obvious" unexpected problems > caused by the new logging. (It seems unlikely, but...) > > From kim.barrett at oracle.com Wed May 29 19:53:17 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 29 May 2019 15:53:17 -0400 Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses In-Reply-To: <9939af70-d94e-6f70-f997-76a6ab20084a@oracle.com> References: <9939af70-d94e-6f70-f997-76a6ab20084a@oracle.com> Message-ID: <381D624B-DEE1-4E67-9142-FD34B716634B@oracle.com> > On May 29, 2019, at 3:39 PM, Daniel D. Daugherty wrote: > > On 5/29/19 1:24 PM, Kim Barrett wrote: >> [I?m not completely sure where this RFR should be sent, but core-libs-dev >> and hotspot-dev seems likely to get reasonable coverage of those who >> might care.] >> >> Please review this change to the test library to add some "logging" >> output to tests that spawn a child process to perform the test and >> then analyze that child's output. We are seeing occasional timeouts >> in such tests whose cause is hard to pin down. It's not clear whether >> the excess time is in the child or instead some problem in the testing >> framework. The new logging output provides timestamps for (1) the >> start of output collection from the child, (2) the start of waiting >> for the child to terminate, and (3) the child's termination. This >> should be enough to determine whether the child is taking too long, >> and hint at where (e.g. termination or not). >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8219149 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8219149/open.00/ > > test/lib/jdk/test/lib/process/OutputBuffer.java > Based on the Java doc, it looks like the timestamp portion > will look something like this: '2011-12-03T10:15:30Z? The timestamp includes trailing ?.microseconds? (at least, it looks like microseconds). > I like it. Since I've been chasing some of the timeout bugs > in the CI, I look forward to seeing the new output... > > Thumbs up. Thanks. From leonid.mesnik at oracle.com Wed May 29 21:56:33 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Wed, 29 May 2019 14:56:33 -0700 Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses In-Reply-To: References: Message-ID: Looks good. Leonid On 5/29/19 10:24 AM, Kim Barrett wrote: > [I?m not completely sure where this RFR should be sent, but core-libs-dev > and hotspot-dev seems likely to get reasonable coverage of those who > might care.] > > Please review this change to the test library to add some "logging" > output to tests that spawn a child process to perform the test and > then analyze that child's output. We are seeing occasional timeouts > in such tests whose cause is hard to pin down. It's not clear whether > the excess time is in the child or instead some problem in the testing > framework. The new logging output provides timestamps for (1) the > start of output collection from the child, (2) the start of waiting > for the child to terminate, and (3) the child's termination. This > should be enough to determine whether the child is taking too long, > and hint at where (e.g. termination or not). > > CR: > https://bugs.openjdk.java.net/browse/JDK-8219149 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8219149/open.00/ > > Testing: > Local hs-tier1 and verified the expected logging output is present. > mach5 tier1-3 to ensure there aren't any "obvious" unexpected problems > caused by the new logging. (It seems unlikely, but...) > > From kim.barrett at oracle.com Wed May 29 22:59:53 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 29 May 2019 18:59:53 -0400 Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses In-Reply-To: References: Message-ID: <72F8035F-A14C-4419-81BA-6FB38385CBFB@oracle.com> > On May 29, 2019, at 5:56 PM, Leonid Mesnik wrote: > > Looks good. Thanks. > > Leonid > > On 5/29/19 10:24 AM, Kim Barrett wrote: >> [I?m not completely sure where this RFR should be sent, but core-libs-dev >> and hotspot-dev seems likely to get reasonable coverage of those who >> might care.] >> >> Please review this change to the test library to add some "logging" >> output to tests that spawn a child process to perform the test and >> then analyze that child's output. We are seeing occasional timeouts >> in such tests whose cause is hard to pin down. It's not clear whether >> the excess time is in the child or instead some problem in the testing >> framework. The new logging output provides timestamps for (1) the >> start of output collection from the child, (2) the start of waiting >> for the child to terminate, and (3) the child's termination. This >> should be enough to determine whether the child is taking too long, >> and hint at where (e.g. termination or not). >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8219149 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8219149/open.00/ >> >> Testing: >> Local hs-tier1 and verified the expected logging output is present. >> mach5 tier1-3 to ensure there aren't any "obvious" unexpected problems >> caused by the new logging. (It seems unlikely, but...) From david.holmes at oracle.com Thu May 30 04:42:32 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 May 2019 14:42:32 +1000 Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses In-Reply-To: <1855dae9-e068-5e0a-e387-2133ae18fdc6@oracle.com> References: <1855dae9-e068-5e0a-e387-2133ae18fdc6@oracle.com> Message-ID: <6c572443-4217-4e0a-ff80-9f738c8ebc58@oracle.com> Adding back hotspot-dev. I don't think Kim saw this. David On 30/05/2019 4:04 am, Roger Riggs wrote: > Hi Kim, > > In the normal output less output is cleaner. > It would be more useful to have the Duration of the wait and end time of > the wait. > (It saves the reader doing subtraction of times). > > +????????? Instant start = Instant.now(); > +????????? boolean aborted = true; > +????????? try { > +????????????? int result = p.waitFor(); > +????????????? aborted = false; > +????????????? return result; > +????????? } finally { > +????????????? Duration dur = Duration.between(start, Instant.now()); > +????????????? if (aborted) { > +????????????????? logProgress("Waiting for completion FAILED after: " + > dur); > +????????????? } else { > +????????????????? logProgress("Waiting for completion finished after: " > + dur); > +????????????? } > +????????? } > > Or something like that. > > Roger > > > On 05/29/2019 01:24 PM, Kim Barrett wrote: >> [I?m not completely sure where this RFR should be sent, but core-libs-dev >> and hotspot-dev seems likely to get reasonable coverage of those who >> might care.] >> >> Please review this change to the test library to add some "logging" >> output to tests that spawn a child process to perform the test and >> then analyze that child's output.? We are seeing occasional timeouts >> in such tests whose cause is hard to pin down.? It's not clear whether >> the excess time is in the child or instead some problem in the testing >> framework.? The new logging output provides timestamps for (1) the >> start of output collection from the child, (2) the start of waiting >> for the child to terminate, and (3) the child's termination.? This >> should be enough to determine whether the child is taking too long, >> and hint at where (e.g. termination or not). >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8219149 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8219149/open.00/ >> >> Testing: >> Local hs-tier1 and verified the expected logging output is present. >> mach5 tier1-3 to ensure there aren't any "obvious" unexpected problems >> caused by the new logging.? (It seems unlikely, but...) >> >> > From david.holmes at oracle.com Thu May 30 06:48:00 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 May 2019 16:48:00 +1000 Subject: RFR(s): 8224600: Provide VM.events command In-Reply-To: References: Message-ID: 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? How does the user know what logs are available? // 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. The test should be checking all the variations to ensure if you ask for exceptions you only get exceptions etc. 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). Thanks, David ----- > 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 vladimir.x.ivanov at oracle.com Thu May 30 10:38:17 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 30 May 2019 13:38:17 +0300 Subject: [13] RFR (M): 8223213: Implement fast class initialization checks on x86-64 In-Reply-To: References: <85a4a478-9200-87f2-c966-49af21f687c2@oracle.com> <3e1ceae0-f7a9-e2e6-2b06-59a22540550d@oracle.com> <3d9c0897-0275-c341-fe33-5f0b6c94f253@oracle.com> <42a8fc79-9497-b2eb-8dd9-a56e4ed85255@oracle.com> <956790f2-5230-fa65-ca0a-77aa106ef462@oracle.com> Message-ID: <762bb879-63df-ed5e-c419-8c7c5544246c@oracle.com> Thanks for reviews, Vladimir, Claes, David, Martin, and Coleen! Best regards, Vladimir Ivanov On 29/05/2019 22:06, coleen.phillimore at oracle.com wrote: > > Vladimir, > > This looks good to me. > > On 5/29/19 12:20 PM, Vladimir Ivanov wrote: >> Thanks, Coleen. >> >> Updated webrev: >> ? http://cr.openjdk.java.net/~vlivanov/8223213/webrev.03 >> >> Incremental webrev: >> ? http://cr.openjdk.java.net/~vlivanov/8223213/webrev.03_02/ >> >>> I reviewed mostly the interpreter and shared change.? As someone else >>> commented, I don't like the addition of a develop flag because some >>> platforms don't support class initialization barriers.? Isn't it >>> normal to do this with the misnamed VM_Version, like adding >>> VM_Version::supports_class_initialization_barriers() with x86 >>> returning true until the other platforms false until they implement >>> the feature. Then there isn't another flag configuration to test (or >>> not test). >> >> I like your suggestion. Didn't know VM_Version is used in such a way. >> >> Replaced UseFastClassInitChecks with >> VM_Version::supports_fast_class_init_checks(). >> >>> http://cr.openjdk.java.net/~vlivanov/8223213/webrev.02/src/hotspot/cpu/x86/interp_masm_x86.cpp.udiff.html >>> >>> >>> I have to admit that the relationship between resolved bytecode in >>> bytecode_1/bytecode_2 and which _f1/_f2 held the Method* was actually >>> a surprise to me.? There's nothing structurally in cpCache other than >>> reading the code that enforces this and it wasn't always a Method* in >>> f2 for invokeinterface, for example, so it's sort of an accident. >>> >>> But this code is correct and I think as a follow up we should make >>> load_invoke_cp_cache_entry() call load_resolved_method_at_index() too >>> and have some assert in cpCache that this is true, or rewrite the >>> cpCache completely. >> >> I went ahead and changed load_invoke_cp_cache_entry() to call >> load_resolved_method_at_index() (along with some other minor >> refactorings). If you have any ideas/suggestions about the assert, I >> can add it as well. > > I think the change to use load_resolved_method_at_index() is good > because if someone moves things around, it'll now fail very quickly.? I > think this is the right amount of refactoring. > > Thanks, > Coleen >> >> Best regards, >> Vladimir Ivanov >> >>> The code to do the initialization barrier in the interpreter looks good. >>> >>> Thanks, >>> Coleen >>> >>> On 5/28/19 7:40 AM, Vladimir Ivanov wrote: >>>> Thanks, Martin. >>>> >>>> Updated webrev: >>>> ? http://cr.openjdk.java.net/~vlivanov/8223213/webrev.02/ >>>> >>>>> Are these assertions safe? >>>>> +?? assert(method()->needs_clinit_barrier(), "barrier not needed"); >>>>> +?? assert(method()->holder()->is_being_initialized(), "barrier not >>>>> needed"); >>>>> Can it happen that initialization concurrently completes before >>>>> they are evaluated? >>>> >>>> Good point. Even though ciInstanceKlass caches initialization state >>>> of the corresponding InstanceKlass, it seems there's a possibility >>>> that the state is updated during the compilation (see >>>> ciInstanceKlass::update_if_shared). I enhanced the asserts to check >>>> that initialization has been stated. >>> >>> Ok, this makes sense. >>>> >>>>> A small suggestion for x86 TemplateTable::invokeinterface: >>>>> It'd be nice to replace load of interface klass by your new >>>>> load_method_holder. >>>> >>>> Agree. Updated. >>> >>> This is nice. >>> >>> >>>> >>>> Best regards, >>>> Vladimir Ivanov >>> > From Roger.Riggs at oracle.com Thu May 30 19:58:15 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 30 May 2019 15:58:15 -0400 Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses In-Reply-To: <6c572443-4217-4e0a-ff80-9f738c8ebc58@oracle.com> References: <1855dae9-e068-5e0a-e387-2133ae18fdc6@oracle.com> <6c572443-4217-4e0a-ff80-9f738c8ebc58@oracle.com> Message-ID: <86115e1a-fca4-2129-0bb6-9d2dafecadf3@oracle.com> Hi Kim, To ensure you see some messages in the case of timeouts, it would be useful to call System.out.flush() after printing the message in logProcess(). I'm ok with the timestamps, as is, though the Duration might be useful in some cases. +1, Roger On 05/30/2019 12:42 AM, David Holmes wrote: > Adding back hotspot-dev. I don't think Kim saw this. > > David > > On 30/05/2019 4:04 am, Roger Riggs wrote: >> Hi Kim, >> >> In the normal output less output is cleaner. >> It would be more useful to have the Duration of the wait and end time >> of the wait. >> (It saves the reader doing subtraction of times). >> >> +????????? Instant start = Instant.now(); >> +????????? boolean aborted = true; >> +????????? try { >> +????????????? int result = p.waitFor(); >> +????????????? aborted = false; >> +????????????? return result; >> +????????? } finally { >> +????????????? Duration dur = Duration.between(start, Instant.now()); >> +????????????? if (aborted) { >> +????????????????? logProgress("Waiting for completion FAILED after: >> " + dur); >> +????????????? } else { >> +????????????????? logProgress("Waiting for completion finished >> after: " + dur); >> +????????????? } >> +????????? } >> >> Or something like that. >> >> Roger >> >> >> On 05/29/2019 01:24 PM, Kim Barrett wrote: >>> [I?m not completely sure where this RFR should be sent, but >>> core-libs-dev >>> and hotspot-dev seems likely to get reasonable coverage of those who >>> might care.] >>> >>> Please review this change to the test library to add some "logging" >>> output to tests that spawn a child process to perform the test and >>> then analyze that child's output.? We are seeing occasional timeouts >>> in such tests whose cause is hard to pin down.? It's not clear whether >>> the excess time is in the child or instead some problem in the testing >>> framework.? The new logging output provides timestamps for (1) the >>> start of output collection from the child, (2) the start of waiting >>> for the child to terminate, and (3) the child's termination. This >>> should be enough to determine whether the child is taking too long, >>> and hint at where (e.g. termination or not). >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8219149 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~kbarrett/8219149/open.00/ >>> >>> Testing: >>> Local hs-tier1 and verified the expected logging output is present. >>> mach5 tier1-3 to ensure there aren't any "obvious" unexpected problems >>> caused by the new logging.? (It seems unlikely, but...) >>> >>> >> From kim.barrett at oracle.com Thu May 30 20:02:56 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 30 May 2019 16:02:56 -0400 Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses In-Reply-To: <6c572443-4217-4e0a-ff80-9f738c8ebc58@oracle.com> References: <1855dae9-e068-5e0a-e387-2133ae18fdc6@oracle.com> <6c572443-4217-4e0a-ff80-9f738c8ebc58@oracle.com> Message-ID: <87386B38-4633-4164-AF27-E99FDF201A4D@oracle.com> > On May 30, 2019, at 12:42 AM, David Holmes wrote: > > Adding back hotspot-dev. I don't think Kim saw this. I did see it, though nearly missed, and not spotted until late evening. Thanks for making sure? > > David > > On 30/05/2019 4:04 am, Roger Riggs wrote: >> Hi Kim, >> In the normal output less output is cleaner. >> It would be more useful to have the Duration of the wait and end time of the wait. >> (It saves the reader doing subtraction of times). >> + Instant start = Instant.now(); >> + boolean aborted = true; >> + try { >> + int result = p.waitFor(); >> + aborted = false; >> + return result; >> + } finally { >> + Duration dur = Duration.between(start, Instant.now()); >> + if (aborted) { >> + logProgress("Waiting for completion FAILED after: " + dur); >> + } else { >> + logProgress("Waiting for completion finished after: " + dur); >> + } >> + } >> Or something like that. >> Roger >> On 05/29/2019 01:24 PM, Kim Barrett wrote: >>> [I?m not completely sure where this RFR should be sent, but core-libs-dev >>> and hotspot-dev seems likely to get reasonable coverage of those who >>> might care.] >>> >>> Please review this change to the test library to add some "logging" >>> output to tests that spawn a child process to perform the test and >>> then analyze that child's output. We are seeing occasional timeouts >>> in such tests whose cause is hard to pin down. It's not clear whether >>> the excess time is in the child or instead some problem in the testing >>> framework. The new logging output provides timestamps for (1) the >>> start of output collection from the child, (2) the start of waiting >>> for the child to terminate, and (3) the child's termination. This >>> should be enough to determine whether the child is taking too long, >>> and hint at where (e.g. termination or not). >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8219149 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~kbarrett/8219149/open.00/ >>> >>> Testing: >>> Local hs-tier1 and verified the expected logging output is present. >>> mach5 tier1-3 to ensure there aren't any "obvious" unexpected problems >>> caused by the new logging. (It seems unlikely, but...) From kim.barrett at oracle.com Thu May 30 21:04:16 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 30 May 2019 17:04:16 -0400 Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses In-Reply-To: <86115e1a-fca4-2129-0bb6-9d2dafecadf3@oracle.com> References: <1855dae9-e068-5e0a-e387-2133ae18fdc6@oracle.com> <6c572443-4217-4e0a-ff80-9f738c8ebc58@oracle.com> <86115e1a-fca4-2129-0bb6-9d2dafecadf3@oracle.com> Message-ID: <1CDB80A3-5DC3-4474-A5E8-8422523EE42C@oracle.com> > On May 30, 2019, at 3:58 PM, Roger Riggs wrote: > > Hi Kim, > > To ensure you see some messages in the case of timeouts, it would be > useful to call System.out.flush() after printing the message in logProcess(). Good idea; added. full: http://cr.openjdk.java.net/~kbarrett/8219149/open.01/ incr: http://cr.openjdk.java.net/~kbarrett/8219149/open.01.inc/ > I'm ok with the timestamps, as is, though the Duration might be useful in > some cases. As I discussed with Roger, I want to keep the change simple for now, as we're not yet sure where to expend effort looking deeper. I think comparing timestamps in just a few cases will tell us a lot (possibly that we're looking in entirely the wrong place, in which case we might just undo this change). From nick.gasson at arm.com Fri May 31 04:05:19 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Fri, 31 May 2019 12:05:19 +0800 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: <4C8CB20E-43E3-4A9C-B7FB-76715CC616F6@oracle.com> References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> <4C8CB20E-43E3-4A9C-B7FB-76715CC616F6@oracle.com> Message-ID: Hi Kim, Kim Barrett writes: > > I think the solution here is to use placement new, but explicitly qualified to actually get there, e.g. > > ::new (reg_map) RegisterMap(map); > > Using unqualified new will do the lookup in RegisterMap, find some declarations in StackObj (but not the one we want) and fail. > This is a pretty common pattern. > This works, thanks. Nick From nick.gasson at arm.com Fri May 31 04:11:44 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Fri, 31 May 2019 12:11:44 +0800 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> Message-ID: <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com> Hi Andrew, > > Oh dear. Experience has shown me (and probably you, too) that this is > one of the most error-prone parts of software development. Many > very serious failures have been caused by trying to shut up > compilers. These failures have even included major security breaches. > Fair enough. But I think several of these are worth fixing. > >> /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.hpp:43:39: error: cannot initialize a parameter of type 'char *' with an lvalue of type 'unsigned long' >> return __sync_add_and_fetch(dest, add_value); >> ^~~~~~~~~ >> >> If the add_and_fetch template is instantiated with I=integer and >> D=pointer then we need an explicit cast here. > > Please don't. Please have a look at where this happens and fix the > types there, as appropriate. What do other ports do? It's instantiated here: /home/nicgas01/jdk/src/hotspot/share/gc/g1/g1PageBasedVirtualSpace.cpp:259:34: note: in instantiation of function template specialization 'Atomic::add' requested here char* touch_addr = Atomic::add(actual_chunk_size, &_cur_addr) - actual_chunk_size; ^ We're adding an unsigned long to a char* which seems legitimate. The other ports except Arm32 and Zero use inline assembly so don't have problems with mismatched types. Zero uses __sync_fetch_and_add so would hit this too if it used G1. I'm not sure how to resolve this. We could add a specialisation of PlatformAdd for byte_size=8 and cast to (u)intptr_t? template<> struct Atomic::PlatformAdd<8> : Atomic::AddAndFetch > { template D add_and_fetch(I add_value, D volatile* dest, atomic_memory_order order) const { STATIC_ASSERT(8 == sizeof(I)); STATIC_ASSERT(8 == sizeof(D)); typedef typename Conditional::value, intptr_t, uintptr_t>::type PI; PI res = __sync_add_and_fetch(reinterpret_cast(dest), static_cast(add_value)); return reinterpret_cast(res); } } I think this is safe. > >> Rewrote as ~((1<<12) - 1) which matches the masks used in the rest of >> the function. > > Let's not. All we have to do to create a mask is is use -1u<<12. I > would challenge anyone to figure out without using a pencil what the > effect of &= ~(((1<<12)-1)<<12) might be. OK, I don't mind too much either way. > >> /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:103:20: error: variable 'esp' is uninitialized when used here [-Werror,-Wuninitialized] >> return (address) esp; >> ^~~ >> /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:101:21: note: initialize the variable 'esp' to silence this warning >> register void *esp __asm__ (SPELL_REG_SP); >> ^ >> = nullptr >> >> We could silence the -Wuninitialized warning for this function, but that >> doesn't help much because Clang then compiles >> os::current_stack_pointer() into: >> >> 0000000000000000 <_ZN2os21current_stack_pointerEv>: >> 0: d65f03c0 ret >> >> Whereas with GCC we get: >> >> 0000000000000250 <_ZN2os21current_stack_pointerEv>: >> 250: 910003e0 mov x0, sp >> 254: d65f03c0 ret >> >> Added some inline assembly to explicitly move sp into the result #ifdef >> __clang__. Same with _get_previous_fp(). > > This is all looking extremely fragile. We'd need to look at what the > usages of this code are and trace through. Yes, I agree this function seems quite fragile. What is the "current" stack pointer supposed to be? Is it the SP at the call site? That's what you get with current code on GCC -00 and -02, and with this patch on clang -O2. But clang -O0 gives SP - 16 because it creates a stack frame for os::current_stack_pointer(). On x86_64 with gcc -00 and clang -00 we get this: 0000000000000000 <_ZN2os21current_stack_pointerEv>: 0: 55 push %rbp 1: 48 89 e5 mov %rsp,%rbp 4: 48 89 e0 mov %rsp,%rax 7: 5d pop %rbp 8: c3 retq The result is RSP before the CALL instruction - 16. On -02 we get caller's RSP - 8 instead: 0000000000000000 <_ZN2os21current_stack_pointerEv>: 0: 48 89 e0 mov %rsp,%rax 3: c3 retq I'm also not sure our existing use of `__asm__ (SPELL_REG_SP)' is correct. The GCC manual [1] says "The only supported use for this feature is to specify registers for input and output operands when calling Extended asm" which we are not doing here. Excluding assertions and tests, the usages are in os::current_frame() and as the input to os::stack_shadow_pages_available(). In the first case the SP seems to already be inaccurate as it points into the frame of os::current_frame() but the FP used is for the caller. In the second case I think there is only a problem if the value returned by os::current_stack_pointer() is *above* the actual SP, as then we would believe there was sufficient stack space when there really wasn't. So if it's OK to return a value slightly below the caller's SP maybe we can use __builtin_frame_address(0)? Or perhaps __builtin_frame_address(0) + 16. We could also replace the single usage of _get_previous_fp() with __builtin_frame_address(1) and avoid trying to guess whether it will be inlined or not. Thanks, Nick [1] https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html From david.holmes at oracle.com Fri May 31 06:19:06 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 31 May 2019 16:19:06 +1000 Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses In-Reply-To: <1CDB80A3-5DC3-4474-A5E8-8422523EE42C@oracle.com> References: <1855dae9-e068-5e0a-e387-2133ae18fdc6@oracle.com> <6c572443-4217-4e0a-ff80-9f738c8ebc58@oracle.com> <86115e1a-fca4-2129-0bb6-9d2dafecadf3@oracle.com> <1CDB80A3-5DC3-4474-A5E8-8422523EE42C@oracle.com> Message-ID: <69c69972-e00a-0e02-2659-4ca2009a9b69@oracle.com> Hi Kim, This seems reasonable to me. Thanks, David On 31/05/2019 7:04 am, Kim Barrett wrote: >> On May 30, 2019, at 3:58 PM, Roger Riggs wrote: >> >> Hi Kim, >> >> To ensure you see some messages in the case of timeouts, it would be >> useful to call System.out.flush() after printing the message in logProcess(). > > Good idea; added. > > full: http://cr.openjdk.java.net/~kbarrett/8219149/open.01/ > incr: http://cr.openjdk.java.net/~kbarrett/8219149/open.01.inc/ > >> I'm ok with the timestamps, as is, though the Duration might be useful in >> some cases. > > As I discussed with Roger, I want to keep the change simple for now, > as we're not yet sure where to expend effort looking deeper. I think > comparing timestamps in just a few cases will tell us a lot (possibly > that we're looking in entirely the wrong place, in which case we might > just undo this change). > > From shade at redhat.com Fri May 31 08:25:13 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 31 May 2019 10:25:13 +0200 Subject: RFR (XS) 8225104: 32-bit build failures after JDK-8222252 Message-ID: <3ea1a3f3-ebb2-f004-9e36-5a8e5273a15f@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8225104 The new UseCompressedOops block has to be protected with _LP64, like all other blocks are. I think it is a trivial change, please review. Fix: http://cr.openjdk.java.net/~shade/8225104/webrev.01/ Testing: {x86_32, x86_64} builds -- Thanks, -Aleksey From rkennke at redhat.com Fri May 31 08:51:52 2019 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 31 May 2019 10:51:52 +0200 Subject: RFR (XS) 8225104: 32-bit build failures after JDK-8222252 In-Reply-To: <3ea1a3f3-ebb2-f004-9e36-5a8e5273a15f@redhat.com> References: <3ea1a3f3-ebb2-f004-9e36-5a8e5273a15f@redhat.com> Message-ID: <13b82d25-3138-a546-cc83-2f244c6920a5@redhat.com> Yes looks good and trivial. Thanks! Roman > Bug: > https://bugs.openjdk.java.net/browse/JDK-8225104 > > The new UseCompressedOops block has to be protected with _LP64, like all other blocks are. I think > it is a trivial change, please review. > > Fix: > http://cr.openjdk.java.net/~shade/8225104/webrev.01/ > > Testing: {x86_32, x86_64} builds > From david.holmes at oracle.com Fri May 31 09:32:12 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 31 May 2019 19:32:12 +1000 Subject: RFR (XS) 8225104: 32-bit build failures after JDK-8222252 In-Reply-To: <3ea1a3f3-ebb2-f004-9e36-5a8e5273a15f@redhat.com> References: <3ea1a3f3-ebb2-f004-9e36-5a8e5273a15f@redhat.com> Message-ID: <733bcf8e-861e-8b24-723a-b90283305940@oracle.com> On 31/05/2019 6:25 pm, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8225104 > > The new UseCompressedOops block has to be protected with _LP64, like all other blocks are. I think > it is a trivial change, please review. Why should that be? ./share/runtime/globals.hpp: lp64_product(bool, UseCompressedOops, false, \ ./share/runtime/globals.hpp: "lp64_product means flag is always constant in 32 bit VM") \ I don't see any ifdef around its use here: share/utilities/globalDefinitions.cpp cpu/x86/templateTable_x86.cpp ?? David ----- > Fix: > http://cr.openjdk.java.net/~shade/8225104/webrev.01/ > > Testing: {x86_32, x86_64} builds > From shade at redhat.com Fri May 31 09:45:59 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 31 May 2019 11:45:59 +0200 Subject: RFR (XS) 8225104: 32-bit build failures after JDK-8222252 In-Reply-To: <733bcf8e-861e-8b24-723a-b90283305940@oracle.com> References: <3ea1a3f3-ebb2-f004-9e36-5a8e5273a15f@redhat.com> <733bcf8e-861e-8b24-723a-b90283305940@oracle.com> Message-ID: <62259e02-4de7-35ec-b217-d713c150857d@redhat.com> On 5/31/19 11:32 AM, David Holmes wrote: > On 31/05/2019 6:25 pm, Aleksey Shipilev wrote: >> Bug: >> ?? https://bugs.openjdk.java.net/browse/JDK-8225104 >> >> The new UseCompressedOops block has to be protected with _LP64, like all other blocks are. I think >> it is a trivial change, please review. > > Why should that be? > > ./share/runtime/globals.hpp:? lp64_product(bool, UseCompressedOops, > false,????????????????????????????? \ > ./share/runtime/globals.hpp:????????? "lp64_product means flag is always constant in 32 bit > VM")??????? \ > > I don't see any ifdef around its use here: > > share/utilities/globalDefinitions.cpp > cpu/x86/templateTable_x86.cpp I believe the actual failure is down at: 1816 FLAG_SET_ERGO(UseCompressedOops, false); 1817 FLAG_SET_ERGO(UseCompressedClassPointers, false); And while we can protect those specifically, I see arguments.cpp just ifdefs the entire UseCompressedOops blocks in other instances. So, it seems consistent to do the same here. -Aleksey From roger.riggs at oracle.com Fri May 31 12:02:50 2019 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 31 May 2019 08:02:50 -0400 Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses In-Reply-To: <69c69972-e00a-0e02-2659-4ca2009a9b69@oracle.com> References: <1855dae9-e068-5e0a-e387-2133ae18fdc6@oracle.com> <6c572443-4217-4e0a-ff80-9f738c8ebc58@oracle.com> <86115e1a-fca4-2129-0bb6-9d2dafecadf3@oracle.com> <1CDB80A3-5DC3-4474-A5E8-8422523EE42C@oracle.com> <69c69972-e00a-0e02-2659-4ca2009a9b69@oracle.com> Message-ID: +1 On 5/31/19 2:19 AM, David Holmes wrote: > Hi Kim, > > This seems reasonable to me. > > Thanks, > David > > On 31/05/2019 7:04 am, Kim Barrett wrote: >>> On May 30, 2019, at 3:58 PM, Roger Riggs >>> wrote: >>> >>> Hi Kim, >>> >>> To ensure you see some messages in the case of timeouts, it would be >>> useful to call System.out.flush() after printing the message in >>> logProcess(). >> >> Good idea; added. >> >> full: http://cr.openjdk.java.net/~kbarrett/8219149/open.01/ >> incr: http://cr.openjdk.java.net/~kbarrett/8219149/open.01.inc/ >> >>> I'm ok with the timestamps, as is, though the Duration might be >>> useful in >>> some cases. >> >> As I discussed with Roger, I want to keep the change simple for now, >> as we're not yet sure where to expend effort looking deeper.? I think >> comparing timestamps in just a few cases will tell us a lot (possibly >> that we're looking in entirely the wrong place, in which case we might >> just undo this change). >> >> From bob.vandette at oracle.com Fri May 31 12:22:20 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 31 May 2019 08:22:20 -0400 Subject: RFR (XS) 8225104: 32-bit build failures after JDK-8222252 In-Reply-To: <62259e02-4de7-35ec-b217-d713c150857d@redhat.com> References: <3ea1a3f3-ebb2-f004-9e36-5a8e5273a15f@redhat.com> <733bcf8e-861e-8b24-723a-b90283305940@oracle.com> <62259e02-4de7-35ec-b217-d713c150857d@redhat.com> Message-ID: <46A81B0E-22D5-4586-9268-FEFF64B24FE3@oracle.com> Sorry for the 32-bit regression. The broader change looks ok to me since UseCompressedOops will never be true in 32-bit mode. Bob. > On May 31, 2019, at 5:45 AM, Aleksey Shipilev wrote: > > On 5/31/19 11:32 AM, David Holmes wrote: >> On 31/05/2019 6:25 pm, Aleksey Shipilev wrote: >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8225104 >>> >>> The new UseCompressedOops block has to be protected with _LP64, like all other blocks are. I think >>> it is a trivial change, please review. >> >> Why should that be? >> >> ./share/runtime/globals.hpp: lp64_product(bool, UseCompressedOops, >> false, \ >> ./share/runtime/globals.hpp: "lp64_product means flag is always constant in 32 bit >> VM") \ >> >> I don't see any ifdef around its use here: >> >> share/utilities/globalDefinitions.cpp >> cpu/x86/templateTable_x86.cpp > > I believe the actual failure is down at: > > 1816 FLAG_SET_ERGO(UseCompressedOops, false); > 1817 FLAG_SET_ERGO(UseCompressedClassPointers, false); > > And while we can protect those specifically, I see arguments.cpp just ifdefs the entire > UseCompressedOops blocks in other instances. So, it seems consistent to do the same here. > > -Aleksey > From daniel.daugherty at oracle.com Fri May 31 13:33:09 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 31 May 2019 09:33:09 -0400 Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses In-Reply-To: References: <1855dae9-e068-5e0a-e387-2133ae18fdc6@oracle.com> <6c572443-4217-4e0a-ff80-9f738c8ebc58@oracle.com> <86115e1a-fca4-2129-0bb6-9d2dafecadf3@oracle.com> <1CDB80A3-5DC3-4474-A5E8-8422523EE42C@oracle.com> <69c69972-e00a-0e02-2659-4ca2009a9b69@oracle.com> Message-ID: Thumbs up. Dan On 5/31/19 8:02 AM, Roger Riggs wrote: > +1 > > On 5/31/19 2:19 AM, David Holmes wrote: >> Hi Kim, >> >> This seems reasonable to me. >> >> Thanks, >> David >> >> On 31/05/2019 7:04 am, Kim Barrett wrote: >>>> On May 30, 2019, at 3:58 PM, Roger Riggs >>>> wrote: >>>> >>>> Hi Kim, >>>> >>>> To ensure you see some messages in the case of timeouts, it would be >>>> useful to call System.out.flush() after printing the message in >>>> logProcess(). >>> >>> Good idea; added. >>> >>> full: http://cr.openjdk.java.net/~kbarrett/8219149/open.01/ >>> incr: http://cr.openjdk.java.net/~kbarrett/8219149/open.01.inc/ >>> >>>> I'm ok with the timestamps, as is, though the Duration might be >>>> useful in >>>> some cases. >>> >>> As I discussed with Roger, I want to keep the change simple for now, >>> as we're not yet sure where to expend effort looking deeper. I think >>> comparing timestamps in just a few cases will tell us a lot (possibly >>> that we're looking in entirely the wrong place, in which case we might >>> just undo this change). >>> >>> > From david.holmes at oracle.com Fri May 31 13:41:26 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 31 May 2019 23:41:26 +1000 Subject: RFR (XS) 8225104: 32-bit build failures after JDK-8222252 In-Reply-To: <62259e02-4de7-35ec-b217-d713c150857d@redhat.com> References: <3ea1a3f3-ebb2-f004-9e36-5a8e5273a15f@redhat.com> <733bcf8e-861e-8b24-723a-b90283305940@oracle.com> <62259e02-4de7-35ec-b217-d713c150857d@redhat.com> Message-ID: <5190f26f-dda8-0113-b3cb-78e3b9618034@oracle.com> On 31/05/2019 7:45 pm, Aleksey Shipilev wrote: > On 5/31/19 11:32 AM, David Holmes wrote: >> On 31/05/2019 6:25 pm, Aleksey Shipilev wrote: >>> Bug: >>> ?? https://bugs.openjdk.java.net/browse/JDK-8225104 >>> >>> The new UseCompressedOops block has to be protected with _LP64, like all other blocks are. I think >>> it is a trivial change, please review. >> >> Why should that be? >> >> ./share/runtime/globals.hpp:? lp64_product(bool, UseCompressedOops, >> false,????????????????????????????? \ >> ./share/runtime/globals.hpp:????????? "lp64_product means flag is always constant in 32 bit >> VM")??????? \ >> >> I don't see any ifdef around its use here: >> >> share/utilities/globalDefinitions.cpp >> cpu/x86/templateTable_x86.cpp > > I believe the actual failure is down at: > > 1816 FLAG_SET_ERGO(UseCompressedOops, false); > 1817 FLAG_SET_ERGO(UseCompressedClassPointers, false); Interesting. I would have expected the compiler to ignore the entire block given the condition should be a compile-time constant of false. > And while we can protect those specifically, I see arguments.cpp just ifdefs the entire > UseCompressedOops blocks in other instances. So, it seems consistent to do the same here. Okay. Thanks for the additional info. David ----- > -Aleksey > From shade at redhat.com Fri May 31 15:41:14 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 31 May 2019 17:41:14 +0200 Subject: RFR (XS) 8225104: 32-bit build failures after JDK-8222252 In-Reply-To: <5190f26f-dda8-0113-b3cb-78e3b9618034@oracle.com> References: <3ea1a3f3-ebb2-f004-9e36-5a8e5273a15f@redhat.com> <733bcf8e-861e-8b24-723a-b90283305940@oracle.com> <62259e02-4de7-35ec-b217-d713c150857d@redhat.com> <5190f26f-dda8-0113-b3cb-78e3b9618034@oracle.com> Message-ID: <39ff57e7-82d2-a062-9d49-c1be6dad05a2@redhat.com> On 5/31/19 3:41 PM, David Holmes wrote: > On 31/05/2019 7:45 pm, Aleksey Shipilev wrote: >> I believe the actual failure is down at: >> >> 1816?????????? FLAG_SET_ERGO(UseCompressedOops, false); >> 1817?????????? FLAG_SET_ERGO(UseCompressedClassPointers, false); > > Interesting. I would have expected the compiler to ignore the entire block given the condition > should be a compile-time constant of false. Yeah, well. I think it does not even parse well when FLAG* is not defined for UseCompressedOops with x86_32. >> And while we can protect those specifically, I see arguments.cpp just ifdefs the entire >> UseCompressedOops blocks in other instances. So, it seems consistent to do the same here. > > Okay. Thanks for the additional info. Thanks, I shall push shortly to unbreak jdk/jdk. -Aleksey From jamsheed.c.m at oracle.com Fri May 31 17:04:31 2019 From: jamsheed.c.m at oracle.com (Jamsheed) Date: Fri, 31 May 2019 22:34:31 +0530 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <38eaa1b2-5fde-ca1d-0842-3d7f2b34e483@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <9dc5704c-7f87-e231-f3cc-7508c1a6d75c@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> Message-ID: <611e1925-5384-9c74-064a-da30ba523268@oracle.com> Hi Dan, Thanks for the review and the feedback, revised webrev (incremental from webrev.05) http://cr.openjdk.java.net/~jcm/8191278/webrev.06_1/ On 29/05/19 2:02 AM, Daniel D. Daugherty wrote: > On 4/30/19 11: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/ > > General comment: > > - Way back on 2019.03.01 Andrew Haley asked about performance testing. > ? I can't find a clear answer that says what performance testing was > ? done, when and on which version of the patch. it is not being done. i will do it once patch is finalized. > > - Please double check copyright years on the files before you push; > ? I spotted these (but I didn't check all of them): > ??? src/hotspot/cpu/x86/assembler_x86.cpp > ??? src/hotspot/share/opto/library_call.cpp Done. > > - This is only a partial review. I didn't review non-Oracle platform > ? or OS code. Ok. > > src/hotspot/share/runtime/stubRoutines.hpp > ??? L371 - nit - please delete extra blank line Done > > src/hotspot/share/runtime/stubRoutines.cpp > ??? No comments. > > src/hotspot/share/runtime/thread.hpp > ??? No comments. > > src/hotspot/share/prims/unsafe.cpp > ??? L160: ??? // been truncated and is now invalid > ??????? nit - please add '.' to end the sentence (came from the > original, moved code). Done. > > 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 ? > > > src/hotspot/cpu/sparc/stubGenerator_sparc.cpp > ??? L5867: ??? UnsafeCopyMemory::create_table(8); > ??????? Should the literal '8' be a defined value from somewhere? Done. used a new #define. > > src/hotspot/cpu/x86/assembler_x86.cpp > ??? L4191: ? NOT_LP64(assert(VM_Version::supports_sse2(), "")); > ??? L4310: ? NOT_LP64(assert(VM_Version::supports_sse2(), "")); > ??????? assert() string should not be empty. Done. > > src/hotspot/cpu/x86/assembler_x86.hpp > ??? No comments. > > src/hotspot/cpu/x86/stubGenerator_x86_32.cpp > ??? L3919: ??? UnsafeCopyMemory::create_table(8); > ??????? Should the literal '8' be a defined value from somewhere? Done used a new #define. > > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp > ??? L1505-08 - nit - indent is 2 spaces too much Done. > > ??? L6232: ??? UnsafeCopyMemory::create_table(32); > ??????? Should the literal '32' be a defined value from somewhere? Done used a new #define. > > ??? Note: This is a mind numbing amount of assembly code changes. > ??????? It's hard to say that I've reviewed and truly understand > ??????? all the changes. > > src/hotspot/cpu/x86/stubRoutines_x86.hpp > ??? No comments. > > src/hotspot/os/windows/os_windows.cpp > ??? L2565: ????? bool is_unsafe_arraycopy = (_thread_in_native || > in_java) && UnsafeCopyMemory::contains_pc(pc); > ??????? I'm not understanding the use of '_thread_in_native' as a flag > ??????? instead of a comparator against thread->thread_state(). Should > ??????? that part be this: > > ? ? ? ? ? ? thread->thread_state() == _thread_in_native > > ??????? That would match with how the 'in_java' var is set: > > ????????? L2457: ??? bool in_java = thread->thread_state() == > _thread_in_Java; Thanks for pointing this. Corrected. > > src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp > ??? L280: nit - please delete extra blank line Done. > > src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp > ??? No comments. > > src/hotspot/os_cpu/solaris_sparc/os_solaris_sparc.cpp > ??? No comments. > > src/hotspot/os_cpu/solaris_x86/os_solaris_x86.cpp > ??? No comments. > > test/hotspot/jtreg/runtime/Unsafe/InternalErrorTest.java > ??? L31:? * @library /test/lib > ??? L32:? *?? @build sun.hotspot.WhiteBox > ??????? Not sure why the '@build' is indented. > > ??? L42: import java.lang.reflect.Field; > ??? L48: import java.lang.reflect.Method; > ??????? L48 should be after L42. > > ??? L95: ??????????? } catch (InternalError e) { > ??? L99: ????????????? } > ??????? nit - L99 indent is 2 spaces off > > ???? L96: ??????????????? if (!e.getMessage().contains("fault occurred > in a recent unsafe memory access")) { > ??? L111: ??????????????? if (!e.getMessage().contains("fault occurred > in a recent unsafe memory access")) { > ??? L126: ??????????????? if (!e.getMessage().contains("fault occurred > in a recent unsafe memory access")) { > ??????? These literal strings should be replace by a single > ??????? final string. > > ??? L102: ??????? Method m = > InternalErrorTest.class.getMethod("test",MappedByteBuffer.class, > Unsafe.class, long.class, long.class, int.class); > ??? L117: ??????? m = > InternalErrorTest.class.getMethod("test",MappedByteBuffer.class, > Unsafe.class, long.class, long.class, int.class); > ??????? nit - need space after '"test",' > > ??? L135: ??? public static void test(MappedByteBuffer buffer, Unsafe > unsafe, long mapAddr, long allocMem, int type? ) { > ??????? nit - extra spaces before ')' > > ??? L138: ??????????????? buffer.get(new byte[8]); > ??? L141: ??????????????? unsafe.copySwapMemory(null, mapAddr + > pageSize, new byte[4000], 16, 2000, 2); > ??? L144: ??????????????? unsafe.copySwapMemory(null, mapAddr + > pageSize, null, allocMem, 2000, 2); > ??????? A short comment above each of these 'tests' would help the > ??????? reader understand what you are testing. Done. > > I think the only possible significant issue here is in > src/hotspot/os/windows/os_windows.cpp above. > > I did not review these files: > > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp > src/hotspot/cpu/arm/stubGenerator_arm.cpp > src/hotspot/cpu/ppc/stubGenerator_ppc.cpp > src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp > src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp > src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp > src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp > src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp > src/hotspot/os_cpu/linux_s390/os_linux_s390.cpp > src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp > src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp > > > Dan > [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); > >> >> what changed >> >> 1) Unsafe Copy Memory regions, error exits are captured using >> UnsafeCopyMemoryMark, UnsafeCopyMemory. >> >> 2) all Unsafe copy (intrinsic or native) ,uses array copy stub. >> >> 3) Unsafe copyswap x64 implementation extends arraycopy stub and used >> as reliable exit(fast exit too)*. it is not implemented for other >> platforms. >> >> *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 Fri May 31 17:04:47 2019 From: jamsheed.c.m at oracle.com (Jamsheed) Date: Fri, 31 May 2019 22:34:47 +0530 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <59f2ec26-9945-3547-ada9-69b84928edbc@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <9dc5704c-7f87-e231-f3cc-7508c1a6d75c@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> Message-ID: <0486af70-8345-f631-3a49-2d7bb5d0081b@oracle.com> 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 gnu.andrew at redhat.com Fri May 31 17:17:01 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 31 May 2019 18:17:01 +0100 Subject: RFR: [8u] 8202353: os::readdir should use readdir instead of readdir_r Message-ID: 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 kim.barrett at oracle.com Fri May 31 18:45:27 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 31 May 2019 14:45:27 -0400 Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses In-Reply-To: References: <1855dae9-e068-5e0a-e387-2133ae18fdc6@oracle.com> <6c572443-4217-4e0a-ff80-9f738c8ebc58@oracle.com> <86115e1a-fca4-2129-0bb6-9d2dafecadf3@oracle.com> <1CDB80A3-5DC3-4474-A5E8-8422523EE42C@oracle.com> <69c69972-e00a-0e02-2659-4ca2009a9b69@oracle.com> Message-ID: > On May 31, 2019, at 9:33 AM, Daniel D. Daugherty wrote: > > Thumbs up. > > Dan Thanks. > > > On 5/31/19 8:02 AM, Roger Riggs wrote: >> +1 >> >> On 5/31/19 2:19 AM, David Holmes wrote: >>> Hi Kim, >>> >>> This seems reasonable to me. >>> >>> Thanks, >>> David >>> >>> On 31/05/2019 7:04 am, Kim Barrett wrote: >>>>> On May 30, 2019, at 3:58 PM, Roger Riggs wrote: >>>>> >>>>> Hi Kim, >>>>> >>>>> To ensure you see some messages in the case of timeouts, it would be >>>>> useful to call System.out.flush() after printing the message in logProcess(). >>>> >>>> Good idea; added. >>>> >>>> full: http://cr.openjdk.java.net/~kbarrett/8219149/open.01/ >>>> incr: http://cr.openjdk.java.net/~kbarrett/8219149/open.01.inc/ >>>> >>>>> I'm ok with the timestamps, as is, though the Duration might be useful in >>>>> some cases. >>>> >>>> As I discussed with Roger, I want to keep the change simple for now, >>>> as we're not yet sure where to expend effort looking deeper. I think >>>> comparing timestamps in just a few cases will tell us a lot (possibly >>>> that we're looking in entirely the wrong place, in which case we might >>>> just undo this change). From kim.barrett at oracle.com Fri May 31 18:45:37 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 31 May 2019 14:45:37 -0400 Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses In-Reply-To: References: <1855dae9-e068-5e0a-e387-2133ae18fdc6@oracle.com> <6c572443-4217-4e0a-ff80-9f738c8ebc58@oracle.com> <86115e1a-fca4-2129-0bb6-9d2dafecadf3@oracle.com> <1CDB80A3-5DC3-4474-A5E8-8422523EE42C@oracle.com> <69c69972-e00a-0e02-2659-4ca2009a9b69@oracle.com> Message-ID: > On May 31, 2019, at 8:02 AM, Roger Riggs wrote: > > +1 Thanks. > > On 5/31/19 2:19 AM, David Holmes wrote: >> Hi Kim, >> >> This seems reasonable to me. >> >> Thanks, >> David >> >> On 31/05/2019 7:04 am, Kim Barrett wrote: >>>> On May 30, 2019, at 3:58 PM, Roger Riggs wrote: >>>> >>>> Hi Kim, >>>> >>>> To ensure you see some messages in the case of timeouts, it would be >>>> useful to call System.out.flush() after printing the message in logProcess(). >>> >>> Good idea; added. >>> >>> full: http://cr.openjdk.java.net/~kbarrett/8219149/open.01/ >>> incr: http://cr.openjdk.java.net/~kbarrett/8219149/open.01.inc/ >>> >>>> I'm ok with the timestamps, as is, though the Duration might be useful in >>>> some cases. >>> >>> As I discussed with Roger, I want to keep the change simple for now, >>> as we're not yet sure where to expend effort looking deeper. I think >>> comparing timestamps in just a few cases will tell us a lot (possibly >>> that we're looking in entirely the wrong place, in which case we might >>> just undo this change). From kim.barrett at oracle.com Fri May 31 18:45:49 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 31 May 2019 14:45:49 -0400 Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses In-Reply-To: <69c69972-e00a-0e02-2659-4ca2009a9b69@oracle.com> References: <1855dae9-e068-5e0a-e387-2133ae18fdc6@oracle.com> <6c572443-4217-4e0a-ff80-9f738c8ebc58@oracle.com> <86115e1a-fca4-2129-0bb6-9d2dafecadf3@oracle.com> <1CDB80A3-5DC3-4474-A5E8-8422523EE42C@oracle.com> <69c69972-e00a-0e02-2659-4ca2009a9b69@oracle.com> Message-ID: <03361DB4-E364-4532-A48D-952AD11BA37A@oracle.com> > On May 31, 2019, at 2:19 AM, David Holmes wrote: > > Hi Kim, > > This seems reasonable to me. > > Thanks, > David Thanks. > > On 31/05/2019 7:04 am, Kim Barrett wrote: >>> On May 30, 2019, at 3:58 PM, Roger Riggs wrote: >>> >>> Hi Kim, >>> >>> To ensure you see some messages in the case of timeouts, it would be >>> useful to call System.out.flush() after printing the message in logProcess(). >> Good idea; added. >> full: http://cr.openjdk.java.net/~kbarrett/8219149/open.01/ >> incr: http://cr.openjdk.java.net/~kbarrett/8219149/open.01.inc/ >>> I'm ok with the timestamps, as is, though the Duration might be useful in >>> some cases. >> As I discussed with Roger, I want to keep the change simple for now, >> as we're not yet sure where to expend effort looking deeper. I think >> comparing timestamps in just a few cases will tell us a lot (possibly >> that we're looking in entirely the wrong place, in which case we might >> just undo this change). From kim.barrett at oracle.com Fri May 31 20:46:38 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 31 May 2019 16:46:38 -0400 Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com> References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com> <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com> <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com> Message-ID: <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com> > On May 31, 2019, at 12:11 AM, Nick Gasson wrote: >>> /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.hpp:43:39: error: cannot initialize a parameter of type 'char *' with an lvalue of type 'unsigned long' >>> return __sync_add_and_fetch(dest, add_value); >>> ^~~~~~~~~ >>> >>> If the add_and_fetch template is instantiated with I=integer and >>> D=pointer then we need an explicit cast here. >> >> Please don't. Please have a look at where this happens and fix the >> types there, as appropriate. What do other ports do? > > It's instantiated here: > > /home/nicgas01/jdk/src/hotspot/share/gc/g1/g1PageBasedVirtualSpace.cpp:259:34: note: in instantiation of function template specialization 'Atomic::add' requested here > char* touch_addr = Atomic::add(actual_chunk_size, &_cur_addr) - actual_chunk_size; > ^ > > We're adding an unsigned long to a char* which seems legitimate. > > The other ports except Arm32 and Zero use inline assembly so don't have > problems with mismatched types. Zero uses __sync_fetch_and_add so would > hit this too if it used G1. > > I'm not sure how to resolve this. We could add a specialisation of > PlatformAdd for byte_size=8 and cast to (u)intptr_t? > > template<> > struct Atomic::PlatformAdd<8> > : Atomic::AddAndFetch > > { > template > D add_and_fetch(I add_value, D volatile* dest, atomic_memory_order order) const { > STATIC_ASSERT(8 == sizeof(I)); > STATIC_ASSERT(8 == sizeof(D)); > > typedef typename Conditional::value, intptr_t, uintptr_t>::type PI; > > PI res = __sync_add_and_fetch(reinterpret_cast(dest), > static_cast(add_value)); > return reinterpret_cast(res); > } > } > > I think this is safe. 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)); } } 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. The documentation also says "That is, they are not scaled by the size of the type to which the pointer points." Any needed scaling of add_value has already been done in the calling Atomic::AddImpl. From kim.barrett at oracle.com Fri May 31 21:02:10 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 31 May 2019 17:02:10 -0400 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: <176A09BD-F7A8-4565-8E14-658F380891B3@oracle.com> > On May 31, 2019, at 4:46 PM, Kim Barrett wrote: > >> On May 31, 2019, at 12:11 AM, Nick Gasson wrote: >> >> /home/nicgas01/jdk/src/hotspot/share/gc/g1/g1PageBasedVirtualSpace.cpp:259:34: note: in instantiation of function template specialization 'Atomic::add' requested here >> char* touch_addr = Atomic::add(actual_chunk_size, &_cur_addr) - actual_chunk_size; >> ^ > [?] > 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.) > > [?] > 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. Or don?t change the code at all here, and say that clang is not (currently) a supported compiler for this platform.