From david.holmes at oracle.com Mon Apr 1 02:17:04 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 1 Apr 2019 12:17:04 +1000 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: <82C212AE-CE8A-4B6A-A1A0-DD08B41A06A5@oracle.com> References: <82C212AE-CE8A-4B6A-A1A0-DD08B41A06A5@oracle.com> Message-ID: On 30/03/2019 1:16 am, Doug Simon wrote: > Hi Robbin, > >> From: Robbin Ehn >> >> Hi, >> >> 434 for (; JavaThread *thr = jtiwh.next(); ) { >> 435 if (thr!=thr_cur && thr->thread_state() == _thread_in_native) { >> 436 num_active++; >> 437 if (thr->is_Compiler_thread()) { >> 438 CompilerThread* ct = (CompilerThread*) thr; >> 439 if (ct->compiler() == NULL || !ct->compiler()->is_jvmci()) { >> 440 num_active_compiler_thread++; >> 441 } else { >> 442 // When using a Java based JVMCI compiler, it's possible >> 443 // for one compiler thread to grab a Java lock, enter >> 444 // HotSpot and go to sleep on the shutdown safepoint. >> 445 // Another JVMCI compiler thread can then attempt grab >> 446 // the lock and thus never make progress. >> 447 } >> 448 } >> 449 } >> 450 } >> >> We inc num_active on threads in native. >> If such thread is a compiler thread we also inc num_active_compiler_thread. >> JavaThread blocking on safepoint would be state blocked. >> JavaThread waiting on the 'Java lock' would also be blocked. >> >> Why are you not blocked when waiting on that contended Java lock ? > > This change was made primarily in the context of libgraal. > > It can happen that a JVMCI compiler thread acquires a lock in libgraal, enters HotSpot > and goes to sleep in the shutdown safepoint. Another JVMCI compiler thread then > attempts to acquire the same lock and goes to sleep in libgraal which from HotSpot?s > perspective is the _thread_in_native state. > > This is the original fix I had for this: > > CompilerThread* ct = (CompilerThread*) thr; > if (ct->compiler() == NULL || !ct->compiler()->is_jvmci() JVMCI_ONLY(|| !UseJVMCINativeLibrary)) { > num_active_compiler_thread++; > } else { > // When using a compiler in a JVMCI shared library, it's possible > // for one compiler thread to grab a lock in the shared library, > // enter HotSpot and go to sleep on the shutdown safepoint. Another > // JVMCI shared library compiler thread can then attempt to grab the > // lock and thus never make progress. > } > > which is probably the right one. I hadn?t realized that a JavaGraal > (as opposed to libgraal) JVMCI compiler thread blocked on a lock will be in > the blocked state, not in the _thread_in_native state. It depends on whether the thread is supposed to participate in safepoints and whether the lock is acquired with or without a safepoint check. I'm confused by the use of "shared library" in this context. If the VM is exiting and the thread holding the lock is blocked at the termination safepoint, then why would you expect another compiler thread blocked on that lock to make progress? This all sounds very odd to me. David ------ > > -Doug > From david.holmes at oracle.com Mon Apr 1 04:27:04 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 1 Apr 2019 14:27:04 +1000 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: <2a26715f-fa64-9de4-1071-b18d07c05511@redhat.com> References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <8b0f5b4c-0386-1440-6939-646daf36aa55@redhat.com> <24b4bb72-732e-0447-d1be-dd71507e7787@redhat.com> <945d9546-5195-ab33-0e20-57871c2f1ef9@oracle.com> <2a26715f-fa64-9de4-1071-b18d07c05511@redhat.com> Message-ID: <936d213e-9c75-6af4-a7f6-bab6a0f320bb@oracle.com> Hi Andrew, On 29/03/2019 8:40 pm, Andrew Dinn wrote: > Hi David, > > Thanks very much for reviewing this patch. > > On 29/03/2019 01:25, David Holmes wrote: >> This seems fine in general but I have a few queries on some details: >> >> src/hotspot/share/classfile/javaClasses.hpp >> >> ??? f(java_lang_Thread) \ >> +?? f(jdk_internal_misc_UnsafeConstants) \ >> ??? f(java_lang_ThreadGroup) \ >> >> Is there a reason this needs to be shoved in there? Similarly with >> src/hotspot/share/classfile/systemDictionary.hpp: >> >> ?? do_klass(Thread_klass, >> java_lang_Thread????????????????????????????????????? ) \ >> +?? do_klass(UnsafeConstants_klass, >> jdk_internal_misc_UnsafeConstants???????????????????? ) \ >> ??? do_klass(ThreadGroup_klass, >> java_lang_ThreadGroup???????????????????????????????? ) \ >> >> ? > > I'm not sure what you are asking here. Are you talking about the > positioning of these entries? If so then the reason for choosing those > positions was because they match the position of the corresponding class > initialization calls in the file thread.cpp. As to that choice ... see > below. Yes I'm asking about the positioning ... >> src/hotspot/share/runtime/thread.cpp >> >> ??? main_thread->set_threadObj(thread_object); >> + >> +?? // initialize the hardware-specific constants needed by Unsafe >> +?? initialize_class(vmSymbols::jdk_internal_misc_UnsafeConstants(), >> CHECK); >> +?? jdk_internal_misc_UnsafeConstants::set_unsafe_constants(); >> + >> ??? // Set thread status to running since main thread has >> ??? // been started and running. >> ??? java_lang_Thread::set_thread_status(thread_object, >> >> That seems a very odd place to insert the new initialization. I can't >> see any reason you'd need to split the Thread object initialization like >> that. ?? > > Well, yes, indeed :-). I was not sure where this init needed to go so I > simply put it in as early as I thought was safe. Clearly, it is an > interloper into intitialise_java_lang_classes() but I was not sure where > else was more appropriate. > > I don't think it matters too much where this init happens so long as it > is early enough to precede any clinit dependencies on Unsafe (see > below). I'm very happy to take advice on this (indeed I was hoping/ > expecting it would be brought up at review) and also on where the > entries in the headers would best be placed. > >> More generally exactly when do you need to initialize this new class by >> and how does the initialization order change before/after this fix? (I'm >> expecting only to see the new class inserted where needed without any >> other perturbations.) > > As I said, I put the class initialization in at this early point simply > to guarantee that the constants are available before Unsafe or any class > which might recursively initialize Unsafe could end up needing them. I > am sure they could move later and also earlier, although the latter > would probably not make any sense. The important thing is that they > don't really have any hard dependencies on other class inits apart, > perhaps, from 'magic' classes like Object, Class etc which need to exist > in order to init /any/ other class. I did some analysis of the class loading and initialization sequence and added my suggestions to bug report. In summary loading seems somewhat immaterial so I suggest: - javaClasses.hpp: Add UnsafeConstants at the end of BASIC_JAVA_CLASSES_DO_PART2 - systemDictionary.hpp: Add UnsafeConstants immediately before Unsafe Then for init: - thread.cpp: initialize UnsafeConstants immediately after j.l.Module It would be desirable to detect if we happen to execute the earlier (by accident) so I suggest adding a "not initialized" assertion prior to your code calling initialize_class. Actually that might be a useful addition to the initialize_class method, as if it fires it means we're not initializing in the expected order ... I'll run a little adding that ... Thanks, David P.S. This missing space in javaClasses.cpp was reported by Thomas but hasn't been fixed yet: 4026 }else { > I deliberately factored these constants out of Unsafe into a separate > all static class UnsafeConstants so as to decouple this init from any > current or future dependencies on Unsafe (and also to make them more > clearly visible). Since the fields only hold os/hw specific constants > they can be set any time after VM_Version/CPU-specific init and > OS-specific init has completed. > >> src/hotspot/share/classfile/vmSymbols.hpp >> >> +?? template(big_endian_name,?????????????????????????? "BIG_ENDIAN") >> ?????????????????????????? \ >> +?? template(use_unaligned_access_name, >> "UNALIGNED_ACCESS")??????????????????????? \ >> >> Nit: There's an extra space before "UNALIGNED... > > Thanks. Thomas Stuefe already spotted that and I have updated the webrev > in place to fix it. > >> src/java.base/share/classes/jdk/internal/misc/UnsafeConstants.java >> >> 31? * package-protected? ... >> >> s/protected/private/ > > Thanks, will correct it. > >> ?37? * The JVM injects values into all the static fields of this class >> ?... >> ?43? * hardware-specific constants installed by the JVM. >> >> I get this gist of this note but still found it rather difficult to >> intepret. There are I think two key points: >> >> 1. The fields must not be constant variables, hence the need for the >> static initialization block. >> 2. The true value of each field is injected by the VM. >> >> How about: >> >> * The JVM injects hardware-specific values into all the static fields >> * of this class during JVM initialization. The static initialization >> * block exists to prevent the fields from being considered constant >> * variables, so the field values will be not be compiled directly into >> * any class that uses them. > > Yes, I agree that is clearer. > >> 60????? * @implNote >> 61????? * The actual value for this field is injected by JVM. A static >> 62????? * initialization block is used to set the value here to >> 63????? * communicate that this static final field is not statically >> 64????? * foldable, and to avoid any possible circular dependency during >> 65????? * vm initialization. >> >> I think all you need for each field is just: >> >> * @implNote >> * The actual value for this field is injected by _the_ JVM. > > Yes, also better. > >> 85????? * flag whose value ... >> 92????? * flag whose value ... >> >> s/flag/Flag/ > > Thanks, will correct this. > > 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 thomas.stuefe at gmail.com Mon Apr 1 04:30:48 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 1 Apr 2019 06:30:48 +0200 Subject: RFR (XS) 8221725: AArch64 build failures after JDK-8221408 (Windows 32bit build build errors/warnings in hotspot) In-Reply-To: <593aa6a5-407d-4415-1d37-f304c4d4e6d5@redhat.com> References: <593aa6a5-407d-4415-1d37-f304c4d4e6d5@redhat.com> Message-ID: Hi Alexey, Sorry for breaking aarch64. Kim and me had discussions about this particular fix, see original rfr thread for 8221408. A better solution than adding the cast like you did might be to pull the offending enum value out and make it a uintx constant too. Or, I could revert my change and make it windows only. Or add a dummy value to the enum and cast that to uintptr, to force its size up. I think a good solution would be one that prevents such errors for other enum values and for other platforms as well. Your patch is fine, if you just want to fix your build now. ..thomas On Sun 31. Mar 2019 at 23:36, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8221725 > > Fix: > > diff -r f062188117ad src/hotspot/cpu/aarch64/aarch64.ad > --- a/src/hotspot/cpu/aarch64/aarch64.ad Sat Mar 30 21:29:37 2019 > +0100 > +++ b/src/hotspot/cpu/aarch64/aarch64.ad Sun Mar 31 23:30:41 2019 > +0200 > @@ -3443,11 +3443,11 @@ > // Check if the owner is self by comparing the value in the > // markOop of object (disp_hdr) with the stack pointer. > __ mov(rscratch1, sp); > __ sub(disp_hdr, disp_hdr, rscratch1); > - __ mov(tmp, (address) (~(os::vm_page_size()-1) | > markOopDesc::lock_mask_in_place)); > + __ mov(tmp, (address) (~(os::vm_page_size()-1) | > (uintptr_t)markOopDesc::lock_mask_in_place)); > // If condition is true we are cont and hence we can store 0 as the > // displaced header in the box, which indicates that it is a > recursive lock. > __ ands(tmp/*==0?*/, disp_hdr, tmp); // Sets flags for result > > The offending change pulled some enum constants out, which apparently made > enum representation much > smaller. Not sure if putting the constants back does not break Win32 build > again. So, instead, fix > it up in one place that blows up with build warning-as-error. The fix has > some level of ewwness, but > it seems to be the same as what bytecodeInterpreter.cpp is doing. The > alternative is to cast to > uintx, as macroAssembler_arm.cpp is doing. > > Testing: Linux aarch64 fastdebug build, ad-hoc tests > > -- > Thanks, > -Aleksey > > > From david.holmes at oracle.com Mon Apr 1 05:00:51 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 1 Apr 2019 15:00:51 +1000 Subject: RFR: 8221535: add steal tick related information to hs_error file [linux] In-Reply-To: References: <6e54431a-8e23-160a-5757-948f1041819e@oracle.com> Message-ID: Hi Matthias, On 29/03/2019 11:37 pm, Baesken, Matthias wrote: > Hello, new webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8221535.3/ > > changed the function to bool os::Linux::get_tick_information(cpu_ticks* > out, int which_logical_cpu = -1) Okay. > added memset? at beginning of get_tick_information Okay > removed the remaining vm_printf ?? from > src/hotspot/os/aix/os_perf_aix.cpp???? ?(at first I did not notice it > ?was ?there as well ). Okay > [ kept the struct? naming CPUPerfTicks??? ( I find plenty of such struct > name? styles ?in hotspot codebase ?).?? ] Agreed - no consistency and you're moving existing code so this is fine IMHO. >> > >>In case? we? are sure that we are always? on? 2.6.11+?? kernels, then indeed I can remove the? special handling. > >>I was sure? that? we are on 2.6+? but only 95%? sure that we are on? 2.6.11+?? . > >> > > I kept the? has_steal_ticks?? for now; in case someone? can? confirm > 2.6.11+??for jdk13? I would remove it . I can't comment on that. One nit in os_linux.cpp: + if((fh = fopen("/proc/stat", "r")) == NULL) { Need space after if Otherwise this all seems fine to me. Thanks, David > Best regards, Matthias > > *From:*Baesken, Matthias > *Sent:* Freitag, 29. M?rz 2019 11:02 > *To:* 'Thomas St?fe' > *Cc:* David Holmes ; hotspot-dev at openjdk.java.net > *Subject:* RE: RFR: 8221535: add steal tick related information to > hs_error file [linux] > > * I would completely remove this section: > * +#ifdef DEBUG_LINUX_PROC_STAT > * +? vm_fprintf(stderr, "[stat] read " > * > > Hi Thomas, > > There are no? vm_printf ??any more in > > http://cr.openjdk.java.net/~mbaesken/webrevs/8221535.2/src/hotspot/os/linux/os_linux.cpp.frames.html > > they have been removed? already. > > * Every item past the "idle" column in /proc/stat has a (admittedly > old) kernel version dependency. > * Why do you think it is important to communicate the existence of > "steal", > > In case? we? are sure that we are always? on? 2.6.11+?? kernels, then > indeed I can remove the? special handling. > > I was sure? that? we are on 2.6+? but only 95%? sure that we are on > 2.6.11+?? . > >>BTW, this has nothing to do with your change, but this whole desig seems inefficient: > >>In os_perf_linux.cpp - which is used e.g. from JFR - we call "os::Linux::get_tick_information" for every expected cpu, and so we parse /proc/stat n times for one reading. > > Sure this could/should ?be addressed ;? but in another change . > > Regards, Matthias > > *From:*Thomas St?fe > > *Sent:* Freitag, 29. M?rz 2019 09:44 > *To:* Baesken, Matthias > > *Cc:* David Holmes >; hotspot-dev at openjdk.java.net > > *Subject:* Re: RFR: 8221535: add steal tick related information to > hs_error file [linux] > > Hi Matthias, > > as usual, thanks for your patience and perseverance. Unfortunately you > touched a piece of coding which was not very pretty (IMHO) in the first > place, so there are a number of further remarks: > > - Return type: please use a simple bool value, not OSReturn. Keeps this > in line with all other OS functions. Plus I do not see us returning > anything else than OS_OK and OS_ERR anyway, and callers seem not to care > either. > > - Please use lowercase-underscore naming of the return struct, not camel > case. Again, like all other os functions around. I suggest a simple > "cpu_ticks". > > - Please change parameter order to get_tick_information and make the > default of "which_logical_cpu" -1. And add a small comment that -1 means > "all". > > // which_logical_cpu=-1 returns accumulated ticks for all cpus. > > bool os::Linux::get_tick_information(cpu_ticks* out, int > which_logical_cpu = -1) { > > - Please initialize the output structure to zero at the begin of the > function. Just a simple memset is sufficient. > > - I would rename "expected_tickinfo_count" to "required_tickinfo_count". > That clearly states that we have a number of values which are mandatory > but are prepared to handle optional values too. > > - I would completely remove this section: > > +#ifdef DEBUG_LINUX_PROC_STAT > > +? vm_fprintf(stderr, "[stat] read " > > +? ? ? ? ? UINT64_FORMAT " " UINT64_FORMAT " " UINT64_FORMAT " " > UINT64_FORMAT " " > > +? ? ? ? ? UINT64_FORMAT " " UINT64_FORMAT " " UINT64_FORMAT " " > UINT64_FORMAT " " UINT64_FORMAT " \n", > > +? ? ? ? ? userTicks, niceTicks, systemTicks, idleTicks, > > +? ? ? ? ? iowTicks, irqTicks, sirqTicks, stealTicks, guestNiceTicks); > > +#endif > > vm_fprintf is nowhere defined and will not build when activated. Seems > to be a relict. We call it only from here and from os_perf_aix.cpp. > Please remove it from os_aix.cpp too. > > - Backward compatibility: > > I do not see the value in "has_steal_ticks". See manpage for /proc: > http://man7.org/linux/man-pages/man5/proc.5.html > > Every item past the "idle" column in /proc/stat has a (admittedly old) > kernel version dependency. Why do you think it is important to > communicate the existence of "steal", but not of the items before > (introduced before Linux 2.6.11)? Seems arbitrary. > > I mean, lets do this either right or not at all. > > If done right, I would prefer my suggested solution which somehow maps > an INVALID value onto the output value. If you dislike my prior proposal > (value_t) you could just define a special value to mean INVALID. E.g. > #define INVALID_VALUE ((uint64_t)(0xFFFFFFFFFFFFFFFFUL)) or similar. > > Alternatively, we could decide to just not care. For values we do not > find we could report zero (code does that now already). You may report > "0" steals and not know if thats true or if the kernel is just too old > to tell you, but again, that is the case for other values too. > > ------ > > BTW, this has nothing to do with your change, but this whole desig seems > inefficient: > > In os_perf_linux.cpp - which is used e.g. from JFR - we call > "os::Linux::get_tick_information" for every expected cpu, and so we > parse /proc/stat n times for one reading. > > We could instead just have a function like > os::Linux::get_tick_information just return all information in one go. > Would be way easier. > > Cheers, Thomas > > On Fri, Mar 29, 2019 at 8:56 AM Baesken, Matthias > > wrote: > > Hi David ,? ?thanks? for? your comments . > > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8221535.2/ > > moved? os::CPUPerfTicks? ? to? ?os::Linux::CPUPerfTicks > removed DEBUG_LINUX_PROC_STAT? from os_linux.cpp > addressed the minor? comments > > > Best regards, Matthias > > > > -----Original Message----- > > From: David Holmes > > > Sent: Freitag, 29. M?rz 2019 06:07 > > To: Baesken, Matthias >; Thomas St?fe > > > > > Cc: hotspot-dev at openjdk.java.net > > > Subject: Re: RFR: 8221535: add steal tick related information to > hs_error file > > [linux] > > > > Hi Matthias, > > > > This generally seems okay. > > > > On 28/03/2019 2:50 am, Baesken, Matthias wrote: > > > Hello, here is a second webrev : > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8221535.1/ > > > > > > I? followed? Davids idea? to? use? the? os_perf coding . > > > For reusing? I? moved? os::Linux::get_tick_information > (former name > > get_total_ticks? , but it is now not only total? but also steal > )? ?into? os_linux . > > > The CPUPerfTicks? ?struct has been? enhanced? ?by? ? steal and > a boolean flag > > has_steal_ticks? . > > > > > >? ? 28 struct CPUPerfTicks { > > >? ? 29? ?uint64_t used; > > >? ? 30? ?uint64_t usedKernel; > > >? ? 31? ?uint64_t total; > > >? ? 32? ?uint64_t steal; > > >? ? 33? ?bool? ? ?has_steal_ticks; > > >? ? 34 }; > > > > Okay, but one minor nit: why put struct CPUPerfTicks in the os:: > > namespace with the code that uses it in the os::Linux namespace? > > > > A few other minor comments: > > > > src/hotspot/os/linux/os_linux.cpp > > > > +? ?if (-1 == which_logical_cpu) { > > > > hotspot style puts the variable first in a comparison against a > constant. > > > > + #ifdef DEBUG_LINUX_PROC_STAT > > > > This should either just be DEBUG code or else deleted. The vm_printfs > > would ideally be logging statements if that is possible. > > > > +? ?if (n > expected_tickinfo_count+3) { > > > > Spaces around + please. > > > > +? ? ? ?st->print_cr("Steal ticks from vm start: %llu", (long long > > unsigned) steal_ticks_difference); > > > > %llu should be UINT64_FORMAT. > > The cast should not be needed. > > > > Thanks, > > David > > ----- > > > > > > > > I found? the? "big API"? ?idea? a bit too much? for? just 2 > use cases? . > > > > > > > > > Best regards , Matthias > > > > From tobias.hartmann at oracle.com Mon Apr 1 06:49:05 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 1 Apr 2019 08:49:05 +0200 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <9dc5704c-7f87-e231-f3cc-7508c1a6d75c@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <571f3d72-a22a-3b52-2942-6408072e353f@oracle.com> <144af13e-33e2-2089-f8d2-902e94485eb1@oracle.com> <62ad6130-0498-5222-43c7-befa3cea9741@oracle.com> <9dc5704c-7f87-e231-f3cc-7508c1a6d75c@oracle.com> Message-ID: <718af50a-74b0-6417-55b5-9b8badcc1f4e@oracle.com> Hi Jamsheed, On 29.03.19 15:19, Jamsheed wrote: > http://cr.openjdk.java.net/~jcm/8191278/webrev.02/ > > 1) checks were made in StubRoutines unaligned arraycopy code range. Thanks for making these changes, looks good to me. > 2) tried to implement fastexit for x64(mac,linux,windows,solaris). others continue with old > implementation. What is the advantage of a fast exit over the old implementation? > 3) implementation like arm has auto increment mode for from and to addresses,? even aligning is done > this way. this may make to proceed with unaligned addresses. Okay, someone more familiar with the arm port should look at this. Best regards, Tobias From kim.barrett at oracle.com Mon Apr 1 06:59:45 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 1 Apr 2019 02:59:45 -0400 Subject: RFR: 8221102: Allow GC threads to participate in threads claiming protocol In-Reply-To: References: <38977DC6-957B-400A-8A19-1EA6977F4A2F@oracle.com> <43C7702A-C046-4E9A-9773-889E7741FBF1@oracle.com> <7571856a-5809-ab9d-c2be-5b6855be5c3c@redhat.com> <6fcffd19-a198-9ee5-46a5-dcbf3c3ed2a9@redhat.com> <204D8F46-0366-4764-8F1A-030CE2A560D7@oracle.com> Message-ID: <0713ED3E-BF5C-4624-B862-45370B02F93F@oracle.com> > On Mar 27, 2019, at 4:37 AM, Roman Kennke wrote: >>> Also, the resetting logic warrants a test, it is so rare, it will otherwise not get executed, but if it fails, it would be catastrophic. >> I was hoping the resetting code was simple enough to not require a >> test. I will see if I can come up with a sensible gtest. > > I guess the 'design' of the claiming protocol is just making almost everything not-obvious. I think for this reason alone I shall go ahead and work on limiting/eliminating its usage outside of thread.cpp anyway. Another function similar to possibly_parallel_threads_do that operated on all threads seems like it would be a good thing to have. Possibly stealing the existing name and renaming the old operation. I'd like the defer that to a followup RFE rather than as part of this bug fix. > If it's too hard to come up with a gtest, then go ahead with your proposed change. It turned out not to be *too* difficult to add a gtest. New webrevs: full: http://cr.openjdk.java.net/~kbarrett/8221102/open.01/ incr: http://cr.openjdk.java.net/~kbarrett/8221102/open.01.inc/ From doug.simon at oracle.com Mon Apr 1 06:59:42 2019 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 1 Apr 2019 08:59:42 +0200 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: References: <82C212AE-CE8A-4B6A-A1A0-DD08B41A06A5@oracle.com> Message-ID: > On 1 Apr 2019, at 04:17, David Holmes wrote: > > On 30/03/2019 1:16 am, Doug Simon wrote: >> Hi Robbin, >>> From: Robbin Ehn >>> >>> Hi, >>> >>> 434 for (; JavaThread *thr = jtiwh.next(); ) { >>> 435 if (thr!=thr_cur && thr->thread_state() == _thread_in_native) { >>> 436 num_active++; >>> 437 if (thr->is_Compiler_thread()) { >>> 438 CompilerThread* ct = (CompilerThread*) thr; >>> 439 if (ct->compiler() == NULL || !ct->compiler()->is_jvmci()) { >>> 440 num_active_compiler_thread++; >>> 441 } else { >>> 442 // When using a Java based JVMCI compiler, it's possible >>> 443 // for one compiler thread to grab a Java lock, enter >>> 444 // HotSpot and go to sleep on the shutdown safepoint. >>> 445 // Another JVMCI compiler thread can then attempt grab >>> 446 // the lock and thus never make progress. >>> 447 } >>> 448 } >>> 449 } >>> 450 } >>> >>> We inc num_active on threads in native. >>> If such thread is a compiler thread we also inc num_active_compiler_thread. >>> JavaThread blocking on safepoint would be state blocked. >>> JavaThread waiting on the 'Java lock' would also be blocked. >>> >>> Why are you not blocked when waiting on that contended Java lock ? >> This change was made primarily in the context of libgraal. >> It can happen that a JVMCI compiler thread acquires a lock in libgraal, enters HotSpot >> and goes to sleep in the shutdown safepoint. Another JVMCI compiler thread then >> attempts to acquire the same lock and goes to sleep in libgraal which from HotSpot?s >> perspective is the _thread_in_native state. >> This is the original fix I had for this: >> CompilerThread* ct = (CompilerThread*) thr; >> if (ct->compiler() == NULL || !ct->compiler()->is_jvmci() JVMCI_ONLY(|| !UseJVMCINativeLibrary)) { >> num_active_compiler_thread++; >> } else { >> // When using a compiler in a JVMCI shared library, it's possible >> // for one compiler thread to grab a lock in the shared library, >> // enter HotSpot and go to sleep on the shutdown safepoint. Another >> // JVMCI shared library compiler thread can then attempt to grab the >> // lock and thus never make progress. >> } >> which is probably the right one. I hadn?t realized that a JavaGraal >> (as opposed to libgraal) JVMCI compiler thread blocked on a lock will be in >> the blocked state, not in the _thread_in_native state. > > It depends on whether the thread is supposed to participate in safepoints and whether the lock is acquired with or without a safepoint check. The libgraal thread acquires the lock without a (HotSpot) safepoint check (note that SVM may have its own safepoint check but that safepoint implementation is disjoint from HotSpot?s). > I'm confused by the use of "shared library" in this context. If the VM is exiting and the thread holding the lock is blocked at the termination safepoint, then why would you expect another compiler thread blocked on that lock to make progress? I don?t expect it to make progress. However, there?s no way for HotSpot to know whether the other thread is blocked on a SVM lock or still progressing in SVM code. From HotSpot?s perspective, the thread is simply in the _thread_in_native state. > This all sounds very odd to me. Hopefully I could clarify things. The important thing to note is that code executing in SVM compiled code is just like any other native code. -Doug From david.holmes at oracle.com Mon Apr 1 07:06:32 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 1 Apr 2019 17:06:32 +1000 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: References: <82C212AE-CE8A-4B6A-A1A0-DD08B41A06A5@oracle.com> Message-ID: <6c7bec0e-8721-ffe7-7a86-ef66e8363e09@oracle.com> On 1/04/2019 4:59 pm, Doug Simon wrote: >> On 1 Apr 2019, at 04:17, David Holmes > > wrote: >> >> On 30/03/2019 1:16 am, Doug Simon wrote: >>> Hi Robbin, >>>> From: Robbin Ehn > >>>> >>>> Hi, >>>> >>>> ?434 ????for (; JavaThread *thr = jtiwh.next(); ) { >>>> ?435 ??????if (thr!=thr_cur && thr->thread_state() == >>>> _thread_in_native) { >>>> ?436 ????????num_active++; >>>> ?437 ????????if (thr->is_Compiler_thread()) { >>>> ?438 ??????????CompilerThread* ct = (CompilerThread*) thr; >>>> ?439 ??????????if (ct->compiler() == NULL || >>>> !ct->compiler()->is_jvmci()) { >>>> ?440 ????????????num_active_compiler_thread++; >>>> ?441 ??????????} else { >>>> ?442 ????????????// When using a Java based JVMCI compiler, it's >>>> possible >>>> ?443 ????????????// for one compiler thread to grab a Java lock, enter >>>> ?444 ????????????// HotSpot and go to sleep on the shutdown safepoint. >>>> ?445 ????????????// Another JVMCI compiler thread can then attempt grab >>>> ?446 ????????????// the lock and thus never make progress. >>>> ?447 ??????????} >>>> ?448 ????????} >>>> ?449 ??????} >>>> ?450 ????} >>>> >>>> We inc num_active on threads in native. >>>> If such thread is a compiler thread we also inc >>>> num_active_compiler_thread. >>>> JavaThread blocking on safepoint would be state blocked. >>>> JavaThread waiting on the 'Java lock' would also be blocked. >>>> >>>> Why are you not blocked when waiting on that contended Java lock ? >>> This change was made primarily in the context of libgraal. >>> It can happen that a JVMCI compiler thread acquires a lock in >>> libgraal, enters HotSpot >>> and goes to sleep in the shutdown safepoint. Another JVMCI compiler >>> thread then >>> attempts to acquire the same lock and goes to sleep in libgraal which >>> from HotSpot?s >>> perspective is the _thread_in_native state. >>> This is the original fix I had for this: >>> ??????????CompilerThread* ct = (CompilerThread*) thr; >>> ??????????if (ct->compiler() == NULL || !ct->compiler()->is_jvmci() >>> JVMCI_ONLY(|| !UseJVMCINativeLibrary)) { >>> ????????????num_active_compiler_thread++; >>> ??????????} else { >>> ????????????// When using a compiler in a JVMCI shared library, it's >>> possible >>> ????????????// for one compiler thread to grab a lock in the shared >>> library, >>> ????????????// enter HotSpot and go to sleep on the shutdown >>> safepoint. Another >>> ????????????// JVMCI shared library compiler thread can then attempt >>> to grab the >>> ????????????// lock and thus never make progress. >>> ??????????} >>> which is probably the right one. I hadn?t realized that a JavaGraal >>> (as opposed to libgraal) JVMCI compiler thread blocked on a lock will >>> be in >>> the blocked state, not in the _thread_in_native state. >> >> It depends on whether the thread is supposed to participate in >> safepoints and whether the lock is acquired with or without a >> safepoint check. > > The libgraal thread acquires the lock without a (HotSpot) safepoint > check (note that SVM may have its own safepoint check but that safepoint > implementation is disjoint from HotSpot?s). > >> I'm confused by the use of "shared library" in this context. If the VM >> is exiting and the thread holding the lock is blocked at the >> termination safepoint, then why would you expect another compiler >> thread blocked on that lock to make progress? > > I don?t expect it to make progress. However, there?s no way for HotSpot > to know whether the other thread is blocked on a SVM lock or still > progressing in SVM code. From HotSpot?s perspective, the thread is > simply in the _thread_in_native state. Okay. I misinterpreted the comment as implying that by taking the else path you could allow such a thread to make progress. Thanks, David ----- > >> This all sounds very odd to me. > > Hopefully I could clarify things. The important thing to note is that > code executing in SVM compiled code is just like any other native code. > > -Doug From jamsheed.c.m at oracle.com Mon Apr 1 07:12:54 2019 From: jamsheed.c.m at oracle.com (Jamsheed) Date: Mon, 1 Apr 2019 12:42:54 +0530 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <718af50a-74b0-6417-55b5-9b8badcc1f4e@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <571f3d72-a22a-3b52-2942-6408072e353f@oracle.com> <144af13e-33e2-2089-f8d2-902e94485eb1@oracle.com> <62ad6130-0498-5222-43c7-befa3cea9741@oracle.com> <9dc5704c-7f87-e231-f3cc-7508c1a6d75c@oracle.com> <718af50a-74b0-6417-55b5-9b8badcc1f4e@oracle.com> Message-ID: <742307c4-9dd0-4c5f-514b-e53fa3ac51a8@oracle.com> Hi Tobias, On 01/04/19 12:19 PM, Tobias Hartmann wrote: > Hi Jamsheed, > > On 29.03.19 15:19, Jamsheed wrote: >> http://cr.openjdk.java.net/~jcm/8191278/webrev.02/ >> >> 1) checks were made in StubRoutines unaligned arraycopy code range. > Thanks for making these changes, looks good to me. > >> 2) tried to implement fastexit for x64(mac,linux,windows,solaris). others continue with old >> implementation. > What is the advantage of a fast exit over the old implementation? Old implementation will have multiple exceptions and handling for bulk copy(depending for the size of copy). in fastexit case i exit arraycopy on first exception. Best regards, Jamsheed > >> 3) implementation like arm has auto increment mode for from and to addresses,? even aligning is done >> this way. this may make to proceed with unaligned addresses. > Okay, someone more familiar with the arm port should look at this. > > Best regards, > Tobias From david.holmes at oracle.com Mon Apr 1 07:15:36 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 1 Apr 2019 17:15:36 +1000 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: <936d213e-9c75-6af4-a7f6-bab6a0f320bb@oracle.com> References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <8b0f5b4c-0386-1440-6939-646daf36aa55@redhat.com> <24b4bb72-732e-0447-d1be-dd71507e7787@redhat.com> <945d9546-5195-ab33-0e20-57871c2f1ef9@oracle.com> <2a26715f-fa64-9de4-1071-b18d07c05511@redhat.com> <936d213e-9c75-6af4-a7f6-bab6a0f320bb@oracle.com> Message-ID: <21b14ecd-4b24-8601-4b07-50d7ac516493@oracle.com> Follow up ... On 1/04/2019 2:27 pm, David Holmes wrote: > Hi Andrew, > > On 29/03/2019 8:40 pm, Andrew Dinn wrote: >> Hi David, >> >> Thanks very much for reviewing this patch. >> >> On 29/03/2019 01:25, David Holmes wrote: >>> This seems fine in general but I have a few queries on some details: >>> >>> src/hotspot/share/classfile/javaClasses.hpp >>> >>> ???? f(java_lang_Thread) \ >>> +?? f(jdk_internal_misc_UnsafeConstants) \ >>> ???? f(java_lang_ThreadGroup) \ >>> >>> Is there a reason this needs to be shoved in there? Similarly with >>> src/hotspot/share/classfile/systemDictionary.hpp: >>> >>> ??? do_klass(Thread_klass, >>> java_lang_Thread????????????????????????????????????? ) \ >>> +?? do_klass(UnsafeConstants_klass, >>> jdk_internal_misc_UnsafeConstants???????????????????? ) \ >>> ???? do_klass(ThreadGroup_klass, >>> java_lang_ThreadGroup???????????????????????????????? ) \ >>> >>> ? >> >> I'm not sure what you are asking here. Are you talking about the >> positioning of these entries? If so then the reason for choosing those >> positions was because they match the position of the corresponding class >> initialization calls in the file thread.cpp. As to that choice ... see >> below. > > Yes I'm asking about the positioning ... > >>> src/hotspot/share/runtime/thread.cpp >>> >>> ???? main_thread->set_threadObj(thread_object); >>> + >>> +?? // initialize the hardware-specific constants needed by Unsafe >>> +?? initialize_class(vmSymbols::jdk_internal_misc_UnsafeConstants(), >>> CHECK); >>> +?? jdk_internal_misc_UnsafeConstants::set_unsafe_constants(); >>> + >>> ???? // Set thread status to running since main thread has >>> ???? // been started and running. >>> ???? java_lang_Thread::set_thread_status(thread_object, >>> >>> That seems a very odd place to insert the new initialization. I can't >>> see any reason you'd need to split the Thread object initialization like >>> that. ?? >> >> Well, yes, indeed :-). I was not sure where this init needed to go so I >> simply put it in as early as I thought was safe. Clearly, it is an >> interloper into intitialise_java_lang_classes() but I was not sure where >> else was more appropriate. >> >> I don't think it matters too much where this init happens so long as it >> is early enough to precede any clinit dependencies on Unsafe (see >> below). I'm very happy to take advice on this (indeed I was hoping/ >> expecting it would be brought up at review) and also on where the >> entries in the headers would best be placed. >> >>> More generally exactly when do you need to initialize this new class by >>> and how does the initialization order change before/after this fix? (I'm >>> expecting only to see the new class inserted where needed without any >>> other perturbations.) >> >> As I said, I put the class initialization in at this early point simply >> to guarantee that the constants are available before Unsafe or any class >> which might recursively initialize Unsafe could end up needing them. I >> am sure they could move later and also earlier, although the latter >> would probably not make any sense. The important thing is that they >> don't really have any hard dependencies on other class inits apart, >> perhaps, from 'magic' classes like Object, Class etc which need to exist >> in order to init /any/ other class. > > I did some analysis of the class loading and initialization sequence and > added my suggestions to bug report. In summary loading seems somewhat > immaterial so I suggest: > > - javaClasses.hpp: Add UnsafeConstants at the end of > BASIC_JAVA_CLASSES_DO_PART2 > - systemDictionary.hpp: Add UnsafeConstants immediately before Unsafe > > Then for init: > - thread.cpp: initialize UnsafeConstants immediately after j.l.Module > > It would be desirable to detect if we happen to execute the > earlier (by accident) so I suggest adding a "not initialized" assertion > prior to your code calling initialize_class. Actually that might be a > useful addition to the initialize_class method, as if it fires it means > we're not initializing in the expected order ... I'll run a little > adding that ... I meant to say "run a little test". Turns out you can't put the assertion in initialize_class as the initialization can vary for some of the exception classes (at least) depending on VM flags used (e.g. -Xrs, and I think certain logging options). Thanks, David > > Thanks, > David > > P.S. This missing space in javaClasses.cpp was reported by Thomas but > hasn't been fixed yet: > > 4026???? }else { > > >> I deliberately factored these constants out of Unsafe into a separate >> all static class UnsafeConstants so as to decouple this init from any >> current or future dependencies on Unsafe (and also to make them more >> clearly visible). Since the fields only hold os/hw specific constants >> they can be set any time after VM_Version/CPU-specific init and >> OS-specific init has completed. >> >>> src/hotspot/share/classfile/vmSymbols.hpp >>> >>> +?? template(big_endian_name,?????????????????????????? "BIG_ENDIAN") >>> ??????????????????????????? \ >>> +?? template(use_unaligned_access_name, >>> "UNALIGNED_ACCESS")??????????????????????? \ >>> >>> Nit: There's an extra space before "UNALIGNED... >> >> Thanks. Thomas Stuefe already spotted that and I have updated the webrev >> in place to fix it. >> >>> src/java.base/share/classes/jdk/internal/misc/UnsafeConstants.java >>> >>> 31? * package-protected? ... >>> >>> s/protected/private/ >> >> Thanks, will correct it. >> >>> ??37? * The JVM injects values into all the static fields of this class >>> ??... >>> ??43? * hardware-specific constants installed by the JVM. >>> >>> I get this gist of this note but still found it rather difficult to >>> intepret. There are I think two key points: >>> >>> 1. The fields must not be constant variables, hence the need for the >>> static initialization block. >>> 2. The true value of each field is injected by the VM. >>> >>> How about: >>> >>> * The JVM injects hardware-specific values into all the static fields >>> * of this class during JVM initialization. The static initialization >>> * block exists to prevent the fields from being considered constant >>> * variables, so the field values will be not be compiled directly into >>> * any class that uses them. >> >> Yes, I agree that is clearer. >> >>> 60????? * @implNote >>> 61????? * The actual value for this field is injected by JVM. A static >>> 62????? * initialization block is used to set the value here to >>> 63????? * communicate that this static final field is not statically >>> 64????? * foldable, and to avoid any possible circular dependency during >>> 65????? * vm initialization. >>> >>> I think all you need for each field is just: >>> >>> * @implNote >>> * The actual value for this field is injected by _the_ JVM. >> >> Yes, also better. >> >>> 85????? * flag whose value ... >>> 92????? * flag whose value ... >>> >>> s/flag/Flag/ >> >> Thanks, will correct this. >> >> 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 tobias.hartmann at oracle.com Mon Apr 1 07:19:44 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 1 Apr 2019 09:19:44 +0200 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <742307c4-9dd0-4c5f-514b-e53fa3ac51a8@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <571f3d72-a22a-3b52-2942-6408072e353f@oracle.com> <144af13e-33e2-2089-f8d2-902e94485eb1@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> Message-ID: <0cb7d5e3-5cf4-d89c-a622-bc31cdc34e81@oracle.com> On 01.04.19 09:12, Jamsheed wrote: > Old implementation will have multiple exceptions and handling for bulk copy(depending for the size > of copy). in fastexit case i exit arraycopy on first exception. Okay, thanks for the explanation. Best regards, Tobias From robbin.ehn at oracle.com Mon Apr 1 07:27:51 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 1 Apr 2019 09:27:51 +0200 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: <82C212AE-CE8A-4B6A-A1A0-DD08B41A06A5@oracle.com> References: <82C212AE-CE8A-4B6A-A1A0-DD08B41A06A5@oracle.com> Message-ID: <2c48b99a-f0a7-1541-7290-c77da9986df7@oracle.com> Hi Doug, > This change was made primarily in the context of libgraal. > > It can happen that a JVMCI compiler thread acquires a lock in libgraal, enters HotSpot > and goes to sleep in the shutdown safepoint. Another JVMCI compiler thread then > attempts to acquire the same lock and goes to sleep in libgraal which from HotSpot?s > perspective is the _thread_in_native state. Ok. > > This is the original fix I had for this: > > CompilerThread* ct = (CompilerThread*) thr; > if (ct->compiler() == NULL || !ct->compiler()->is_jvmci() JVMCI_ONLY(|| !UseJVMCINativeLibrary)) { > num_active_compiler_thread++; > } else { > // When using a compiler in a JVMCI shared library, it's possible > // for one compiler thread to grab a lock in the shared library, > // enter HotSpot and go to sleep on the shutdown safepoint. Another > // JVMCI shared library compiler thread can then attempt to grab the > // lock and thus never make progress. > } > > which is probably the right one. I hadn?t realized that a JavaGraal > (as opposed to libgraal) JVMCI compiler thread blocked on a lock will be in > the blocked state, not in the _thread_in_native state. Yes, makes more sense. Another thing is this HandleMark: JvmtiAgentThread::call_start_function() { + HandleMark hm(this); ThreadToNativeFromVM transition(this); Since a safepoint can happen at any time when you are in native, I don't see how using a Handle in native would be safe or correct. I'm guessing you are missing a HandleMark somewhere when you re-enter VM? Thanks, Robbin > > -Doug > From stefan.karlsson at oracle.com Mon Apr 1 07:34:06 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 1 Apr 2019 09:34:06 +0200 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: References: <4b759550-f185-724f-7139-9bab648a1966@oracle.com> Message-ID: <119335f1-acb7-fffc-f38a-e50a96b73b3c@oracle.com> On 2019-03-29 17:55, Vladimir Kozlov wrote: > Stefan, > > Do you have a test (and flags) which can allow me to measure effect of > this code on G1 remark pause? -Xlog:gc prints the remark times: [4,296s][info][gc ] GC(89) Pause Remark 4M->4M(28M) 36,412ms StefanK > > Thanks, > Vladimir > > On 3/29/19 12:36 AM, Stefan Karlsson wrote: >> On 2019-03-29 03:07, Vladimir Kozlov wrote: >>> Hi Stefan, >>> >>> I collected some data on MetadataHandleBlock. >>> >>> First, do_unloading() code is executed only when >>> class_unloading_occurred is 'true' - it is rare case. It should not >>> affect normal G1 remark pause. >> >> It's only rare for applications that don't do dynamic class loading >> and unloading. The applications that do, will be affected. >> >>> >>> Second, I run a test with -Xcomp. I got about 10,000 compilations by >>> Graal and next data at the end of execution: >>> >>> max_blocks = 232 >>> max_handles_per_block = 32 (since handles array has 32 elements) >>> max_total_alive_values = 4631 >> >> OK. Thanks for the info. >> >> StefanK >> >>> >>> Thanks, >>> Vladimir >>> >>> On 3/28/19 2:44 PM, Vladimir Kozlov wrote: >>>> Thank you, Stefan >>>> >>>> On 3/28/19 12:54 PM, Stefan Karlsson wrote: >>>>> Hi Vladimir, >>>>> >>>>> I started to check the GC code. >>>>> >>>>> ======================================================================== >>>>> >>>>> I see that you've added guarded includes in the middle of the >>>>> include list: >>>>> ?? #include "gc/shared/strongRootsScope.hpp" >>>>> ?? #include "gc/shared/weakProcessor.hpp" >>>>> + #if INCLUDE_JVMCI >>>>> + #include "jvmci/jvmci.hpp" >>>>> + #endif >>>>> ?? #include "oops/instanceRefKlass.hpp" >>>>> ?? #include "oops/oop.inline.hpp" >>>>> >>>>> The style we use is to put these conditional includes at the end of >>>>> the include lists. >>>> >>>> okay >>>> >>>>> >>>>> ======================================================================== >>>>> >>>>> Could you also change the following: >>>>> >>>>> + #if INCLUDE_JVMCI >>>>> +???? // Clean JVMCI metadata handles. >>>>> +???? JVMCI::do_unloading(is_alive_closure(), purged_class); >>>>> + #endif >>>>> >>>>> to: >>>>> +???? // Clean JVMCI metadata handles. >>>>> +???? JVMCI_ONLY(JVMCI::do_unloading(is_alive_closure(), >>>>> purged_class);) >>>>> >>>>> to get rid of some of the line noise in the GC files. >>>> >>>> okay >>>> >>>>> >>>>> ======================================================================== >>>>> >>>>> In the future we will need version of JVMCI::do_unloading that >>>>> supports concurrent cleaning for ZGC. >>>> >>>> Yes, we need to support concurrent cleaning in a future. >>>> >>>>> >>>>> ======================================================================== >>>>> >>>>> What's the performance impact for G1 remark pause with this serial >>>>> walk over the MetadataHandleBlock? >>>>> >>>>> 3275 void G1CollectedHeap::complete_cleaning(BoolObjectClosure* >>>>> is_alive, >>>>> 3276???????????????????????????????????????? bool >>>>> class_unloading_occurred) { >>>>> 3277?? uint num_workers = workers()->active_workers(); >>>>> 3278?? ParallelCleaningTask unlink_task(is_alive, num_workers, >>>>> class_unloading_occurred, false); >>>>> 3279?? workers()->run_task(&unlink_task); >>>>> 3280 #if INCLUDE_JVMCI >>>>> 3281?? // No parallel processing of JVMCI metadata handles for now. >>>>> 3282?? JVMCI::do_unloading(is_alive, class_unloading_occurred); >>>>> 3283 #endif >>>>> 3284 } >>>> >>>> There should not be impact if Graal is not used. Only cost of call >>>> (which most likely is inlined in product VM) and check: >>>> >>>> http://hg.openjdk.java.net/metropolis/dev/file/530fc1427d02/src/hotspot/share/jvmci/jvmciRuntime.cpp#l1237 >>>> >>>> >>>> If Graal is used it should not have big impact since these metadata >>>> has regular pattern (32 handles per array and array per >>>> MetadataHandleBlock block which are linked in list) and not large. >>>> If there will be noticeable impact - we will work on it as you >>>> suggested by using ParallelCleaningTask. >>>> >>>>> >>>>> ======================================================================== >>>>> >>>>> Did you consider adding it as a task for one of the worker threads >>>>> to execute in ParallelCleaningTask? >>>>> >>>>> See how other tasks are claimed by one worker: >>>>> void KlassCleaningTask::work() { >>>>> ?? ResourceMark rm; >>>>> >>>>> ?? // One worker will clean the subklass/sibling klass tree. >>>>> ?? if (claim_clean_klass_tree_task()) { >>>>> ???? Klass::clean_subklass_tree(); >>>>> ?? } >>>> >>>> These changes were ported from JDK8u based changes in graal-jvmci-8 >>>> and there are no ParallelCleaningTask in JDK8. >>>> >>>> Your suggestion is interesting and I agree that we should >>>> investigate it. >>>> >>>>> >>>>> ======================================================================== >>>>> >>>>> In MetadataHandleBlock::do_unloading: >>>>> >>>>> +??????? if (klass->class_loader_data()->is_unloading()) { >>>>> +????????? // This needs to be marked so that it's no longer scanned >>>>> +????????? // but can't be put on the free list yet. The >>>>> +????????? // ReferenceCleaner will set this to NULL and >>>>> +????????? // put it on the free list. >>>>> >>>>> I couldn't find the ReferenceCleaner in the patch or in the source. >>>>> Where can I find this code? >>>> >>>> I think it is typo (I will fix it) - it references new HandleCleaner >>>> class: >>>> >>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HandleCleaner.java.html >>>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Thanks, >>>>> StefanK >>>>> >>>>> On 2019-03-28 20:15, Vladimir Kozlov wrote: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8220623 >>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ >>>>>> >>>>>> Update JVMCI to support pre-compiled as shared library Graal. >>>>>> Using aoted Graal can offers benefits including: >>>>>> ?- fast startup >>>>>> ?- compile time similar to native JIt compilers (C2) >>>>>> ?- memory usage disjoint from the application Java heap >>>>>> ?- no profile pollution of JDK code used by the application >>>>>> >>>>>> This is JDK13 port of JVMCI changes done in graal-jvmci-8 [1] up >>>>>> to date. >>>>>> Changes were collected in Metropolis repo [2] and tested there. >>>>>> >>>>>> Changes we reviewed by Oracle Labs (authors of JVMCI and Graal) >>>>>> and our compiler group. >>>>>> Changes in shared code are guarded by #if INCLUDE_JVMCI and JVMCI >>>>>> flags. >>>>>> >>>>>> I ran tier1-tier8 (which includes HotSpot and JDK tests) and it >>>>>> was clean. In this set Graal was tested only in tier3. >>>>>> >>>>>> And I ran all hs-tier3-graal .. hs-tier8-graal Graal tests >>>>>> available in our system. Several issue were found which were >>>>>> present before these changes. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> [1] >>>>>> https://github.com/graalvm/graal-jvmci-8/commit/49ff2045fb603e35516a3a427d8023c00e1607af >>>>>> >>>>>> [2] http://hg.openjdk.java.net/metropolis/dev/ >>>>> From shade at redhat.com Mon Apr 1 08:03:32 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 1 Apr 2019 10:03:32 +0200 Subject: RFR (XS) 8221725: AArch64 build failures after JDK-8221408 (Windows 32bit build build errors/warnings in hotspot) In-Reply-To: References: <593aa6a5-407d-4415-1d37-f304c4d4e6d5@redhat.com> Message-ID: <15bbff7a-c6b3-2e80-38d2-5241a5ea2ee5@redhat.com> On 4/1/19 6:30 AM, Thomas St?fe wrote: > I think a good solution would be one that prevents such errors for other enum values and for other > platforms as well. Right, that feels like a cleaner solution, but it requires more work :) > Your patch is fine, if you just want to fix your build now.? Yes, I'll push this to unbreak aarch64 build. -Aleksey From aph at redhat.com Mon Apr 1 09:26:14 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 1 Apr 2019 10:26:14 +0100 Subject: [aarch64-port-dev ] RFR (XS) 8221725: AArch64 build failures after JDK-8221408 (Windows 32bit build build errors/warnings in hotspot) In-Reply-To: References: <593aa6a5-407d-4415-1d37-f304c4d4e6d5@redhat.com> Message-ID: <0de47dc3-0fab-71cd-1e58-a7636a727645@redhat.com> On 4/1/19 5:30 AM, Thomas St?fe wrote: > A better solution than adding the cast like you did might be to pull the > offending enum value out and make it a uintx constant too. Or, I could > revert my change and make it windows only. Or add a dummy value to the enum > and cast that to uintptr, to force its size up. > > I think a good solution would be one that prevents such errors for other > enum values and for other platforms as well. Yes, I agree. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Mon Apr 1 09:43:22 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 1 Apr 2019 11:43:22 +0200 Subject: RFR: 8221102: Allow GC threads to participate in threads claiming protocol In-Reply-To: <0713ED3E-BF5C-4624-B862-45370B02F93F@oracle.com> References: <38977DC6-957B-400A-8A19-1EA6977F4A2F@oracle.com> <43C7702A-C046-4E9A-9773-889E7741FBF1@oracle.com> <7571856a-5809-ab9d-c2be-5b6855be5c3c@redhat.com> <6fcffd19-a198-9ee5-46a5-dcbf3c3ed2a9@redhat.com> <204D8F46-0366-4764-8F1A-030CE2A560D7@oracle.com> <0713ED3E-BF5C-4624-B862-45370B02F93F@oracle.com> Message-ID: <2879b1da-cbbb-fbb5-a416-8a56c5f0f0bb@redhat.com> Hi Kim, >>>> Also, the resetting logic warrants a test, it is so rare, it will otherwise not get executed, but if it fails, it would be catastrophic. >>> I was hoping the resetting code was simple enough to not require a >>> test. I will see if I can come up with a sensible gtest. >> >> I guess the 'design' of the claiming protocol is just making almost everything not-obvious. I think for this reason alone I shall go ahead and work on limiting/eliminating its usage outside of thread.cpp anyway. > > Another function similar to possibly_parallel_threads_do that operated > on all threads seems like it would be a good thing to have. Possibly > stealing the existing name and renaming the old operation. I'd like > the defer that to a followup RFE rather than as part of this bug fix. Yes, let's do that. >> If it's too hard to come up with a gtest, then go ahead with your proposed change. > > It turned out not to be *too* difficult to add a gtest. New webrevs: > > full: http://cr.openjdk.java.net/~kbarrett/8221102/open.01/ > incr: http://cr.openjdk.java.net/~kbarrett/8221102/open.01.inc/ Great! Patch looks good to me! Thanks, Roman From doug.simon at oracle.com Mon Apr 1 11:05:43 2019 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 1 Apr 2019 13:05:43 +0200 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: <2c48b99a-f0a7-1541-7290-c77da9986df7@oracle.com> References: <82C212AE-CE8A-4B6A-A1A0-DD08B41A06A5@oracle.com> <2c48b99a-f0a7-1541-7290-c77da9986df7@oracle.com> Message-ID: > On 1 Apr 2019, at 09:27, Robbin Ehn wrote: > > Hi Doug, > >> This change was made primarily in the context of libgraal. >> It can happen that a JVMCI compiler thread acquires a lock in libgraal, enters HotSpot >> and goes to sleep in the shutdown safepoint. Another JVMCI compiler thread then >> attempts to acquire the same lock and goes to sleep in libgraal which from HotSpot?s >> perspective is the _thread_in_native state. > > Ok. > >> This is the original fix I had for this: >> CompilerThread* ct = (CompilerThread*) thr; >> if (ct->compiler() == NULL || !ct->compiler()->is_jvmci() JVMCI_ONLY(|| !UseJVMCINativeLibrary)) { >> num_active_compiler_thread++; >> } else { >> // When using a compiler in a JVMCI shared library, it's possible >> // for one compiler thread to grab a lock in the shared library, >> // enter HotSpot and go to sleep on the shutdown safepoint. Another >> // JVMCI shared library compiler thread can then attempt to grab the >> // lock and thus never make progress. >> } >> which is probably the right one. I hadn?t realized that a JavaGraal >> (as opposed to libgraal) JVMCI compiler thread blocked on a lock will be in >> the blocked state, not in the _thread_in_native state. > > Yes, makes more sense. > > Another thing is this HandleMark: > > JvmtiAgentThread::call_start_function() { > + HandleMark hm(this); > ThreadToNativeFromVM transition(this); > > Since a safepoint can happen at any time when you are in native, I don't see how using a Handle in native would be safe or correct. I'm guessing you are missing a HandleMark somewhere when you re-enter VM? Tom, can you recall why this HandleMark was added? Doe we run any JVMCI code on a JVMTI agent thread? -Doug From coleen.phillimore at oracle.com Mon Apr 1 13:28:52 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 1 Apr 2019 09:28:52 -0400 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: <24b4bb72-732e-0447-d1be-dd71507e7787@redhat.com> References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <8b0f5b4c-0386-1440-6939-646daf36aa55@redhat.com> <24b4bb72-732e-0447-d1be-dd71507e7787@redhat.com> Message-ID: <8ab058fe-886b-643f-f602-c27182d6f584@oracle.com> http://cr.openjdk.java.net/~adinn/8221477/webrev.02/src/hotspot/share/classfile/javaClasses.cpp.udiff.html I was sort of expecting you to use like UNSAFE_CONSTANTS_DO for the fields, so that you don't have to add more names to vmSymbols.hpp. And that's what the rest of the code does (except CompactStrings). I can sort of? understand that it's faster as static_fields_do, and you can check for unexpected fields. + jint _address_size; + jint _page_size; + jboolean _big_endian; + jboolean _use_unaligned_access; We've been trying to keep Java types out of the C++ code, and use the appropriate C++ types. + InstanceKlass::cast(SystemDictionary::UnsafeConstants_klass())->do_local_static_fields(&fixup); The cast is unnecessary.? UnsafeConstants_klass returns an InstanceKlass. http://cr.openjdk.java.net/~adinn/8221477/webrev.02/src/hotspot/share/classfile/vmSymbols.hpp.udiff.html I just don't like the field names here. :( Coleen On 3/28/19 12:56 PM, Andrew Dinn wrote: > On 28/03/2019 15:22, Thomas St?fe wrote: >> The second of those was actually intended to be iff. This is a common >> abbreviation used by English/US mathematicians and logicians to write >> 'if and only if' (it is also sometimes written as <=>). Since you didn't >> recognize it I guess I really need to write it out in full. >> >> >> Oh, don't worry on my account. I am not a native speaker nor a >> mathematician. You could leave iff and add [sic] to make everyone >> curious and start googling "iff" :) > I changed it nevertheless. It would be remiss to presume readers need be > conversant with elliptical, English logico-mathematical parlance (I'm > explaining this in as plain English as I can ... no, wait! ;-). > > Anyway, I addressed this and your other concerns in a new webrev. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8221477 > Webrev: http://cr.openjdk.java.net/~adinn/8221477/webrev.02 > > Input from a second reviewer would be welcome ... > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From christian.tornqvist at oracle.com Mon Apr 1 15:43:54 2019 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Mon, 1 Apr 2019 08:43:54 -0700 Subject: RFR: 8212627: [TESTBUG] runtime/CreateMirror/ArraysNewInstanceBug.java timed out Message-ID: <3D21BD8D-D6A3-442B-829C-C8221722FD04@oracle.com> Hi, Please review this small test fix for an issue where ArraysNewInstanceBug.java times out on certain Windows machines. The test uses a file URI to point to where to find a test class, this URI is supposed to be pointing to the local file system but the file URI uses the format of a network location (two instead of three forward slashes [1]). This causes network lookups on Windows and, depending on the network configuration, this might take some time and cause the test to timeout. Change has been tested by running the test in Mach 5 on Linux, Mac, Solaris and Windows. Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8212627/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8212627 Thanks, Christian [1] https://en.wikipedia.org/wiki/File_URI_scheme#How_many_slashes? From harold.seigel at oracle.com Mon Apr 1 15:48:55 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Mon, 1 Apr 2019 11:48:55 -0400 Subject: RFR: 8212627: [TESTBUG] runtime/CreateMirror/ArraysNewInstanceBug.java timed out In-Reply-To: <3D21BD8D-D6A3-442B-829C-C8221722FD04@oracle.com> References: <3D21BD8D-D6A3-442B-829C-C8221722FD04@oracle.com> Message-ID: <56919d96-dfe4-74dd-d6c5-8afa4dc319e8@oracle.com> Hi Christian, This looks good. Thanks, Harold On 4/1/2019 11:43 AM, Christian Tornqvist wrote: > Hi, > > Please review this small test fix for an issue where ArraysNewInstanceBug.java times out on certain Windows machines. The test uses a file URI to point to where to find a test class, this URI is supposed to be pointing to the local file system but the file URI uses the format of a network location (two instead of three forward slashes [1]). This causes network lookups on Windows and, depending on the network configuration, this might take some time and cause the test to timeout. > > Change has been tested by running the test in Mach 5 on Linux, Mac, Solaris and Windows. > > Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8212627/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8212627 > > Thanks, > Christian > > [1] https://en.wikipedia.org/wiki/File_URI_scheme#How_many_slashes? From daniel.daugherty at oracle.com Mon Apr 1 15:53:44 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 1 Apr 2019 11:53:44 -0400 Subject: RFR: 8212627: [TESTBUG] runtime/CreateMirror/ArraysNewInstanceBug.java timed out In-Reply-To: <3D21BD8D-D6A3-442B-829C-C8221722FD04@oracle.com> References: <3D21BD8D-D6A3-442B-829C-C8221722FD04@oracle.com> Message-ID: On 4/1/19 11:43 AM, Christian Tornqvist wrote: > Hi, > > Please review this small test fix for an issue where ArraysNewInstanceBug.java times out on certain Windows machines. The test uses a file URI to point to where to find a test class, this URI is supposed to be pointing to the local file system but the file URI uses the format of a network location (two instead of three forward slashes [1]). This causes network lookups on Windows and, depending on the network configuration, this might take some time and cause the test to timeout. > > Change has been tested by running the test in Mach 5 on Linux, Mac, Solaris and Windows. > > Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8212627/webrev.00/ test/hotspot/jtreg/runtime/CreateMirror/ArraysNewInstanceBug.java ??? I like the use of toURI() and toURL() rather than trying to ??? manually construct a URL that follows the rules. Thumbs up. Dan > Bug: https://bugs.openjdk.java.net/browse/JDK-8212627 > > Thanks, > Christian > > [1] https://en.wikipedia.org/wiki/File_URI_scheme#How_many_slashes? From coleen.phillimore at oracle.com Mon Apr 1 15:55:57 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 1 Apr 2019 11:55:57 -0400 Subject: RFR: 8212627: [TESTBUG] runtime/CreateMirror/ArraysNewInstanceBug.java timed out In-Reply-To: <56919d96-dfe4-74dd-d6c5-8afa4dc319e8@oracle.com> References: <3D21BD8D-D6A3-442B-829C-C8221722FD04@oracle.com> <56919d96-dfe4-74dd-d6c5-8afa4dc319e8@oracle.com> Message-ID: +1. Are there other tests like this?? Seems to look like something one would copy and paste. Thanks, Coleen On 4/1/19 11:48 AM, Harold Seigel wrote: > Hi Christian, > > This looks good. > > Thanks, Harold > > On 4/1/2019 11:43 AM, Christian Tornqvist wrote: >> Hi, >> >> Please review this small test fix for an issue where >> ArraysNewInstanceBug.java times out on certain Windows machines. The >> test uses a file URI to point to where to find a test class, this URI >> is supposed to be pointing to the local file system but the file URI >> uses the format of a network location (two instead of three forward >> slashes [1]). This causes network lookups on Windows and, depending >> on the network configuration, this might take some time and cause the >> test to timeout. >> >> Change has been tested by running the test in Mach 5 on Linux, Mac, >> Solaris and Windows. >> >> Webrev: >> http://cr.openjdk.java.net/~ctornqvi/webrev/8212627/webrev.00/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212627 >> >> >> Thanks, >> Christian >> >> [1] https://en.wikipedia.org/wiki/File_URI_scheme#How_many_slashes? >> From tom.rodriguez at oracle.com Mon Apr 1 17:01:08 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 1 Apr 2019 10:01:08 -0700 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: References: <82C212AE-CE8A-4B6A-A1A0-DD08B41A06A5@oracle.com> <2c48b99a-f0a7-1541-7290-c77da9986df7@oracle.com> Message-ID: <2b8d7d1e-ef05-7067-826f-cea5aac0028a@oracle.com> >> Since a safepoint can happen at any time when you are in native, I don't see how using a Handle in native would be safe or correct. I'm guessing you are missing a HandleMark somewhere when you re-enter VM? > > Tom, can you recall why this HandleMark was added? Doe we run any JVMCI code on a JVMTI agent thread? > > -Doug It's a leftover from the JNI self call logic I added early in libgraal development for testing. To ease testing and bringing up libgraal I'd added logic to let HotSpot call itself through JNI. This let me test and debug libgraal JVMCI changes without having a fully working libgraal. It required adding HandleMarks in a few places that had nothing to do with JVMCI because we were calling back into ourselves. I forgot to remove all of them when I removed the self call stuff. Basically the problem I saw was that the HandleMarkCleaner takes over the last HandleMark it finds in the current thread and will clean out it's contents in its own destructor, which is actually earlier than the HandleMark destructor. If you aren't careful about having a HandleMark close to where you call out of the JVM you could end up releasing a handle earlier than the HandleMark scoping would suggest. I convinced myself this isn't a problem in the current code but maybe I missed something. I can resurrect my assertion checking if someone thinks there might be a real bug lurking here. tom From christian.tornqvist at oracle.com Mon Apr 1 18:51:22 2019 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Mon, 1 Apr 2019 11:51:22 -0700 Subject: RFR: 8212627: [TESTBUG] runtime/CreateMirror/ArraysNewInstanceBug.java timed out In-Reply-To: References: <3D21BD8D-D6A3-442B-829C-C8221722FD04@oracle.com> <56919d96-dfe4-74dd-d6c5-8afa4dc319e8@oracle.com> Message-ID: <1360B920-6222-40D5-852F-974D31EA80D6@oracle.com> > On Apr 1, 2019, at 8:55 AM, coleen.phillimore at oracle.com wrote: > > +1. > Are there other tests like this? Seems to look like something one would copy and paste. I?m sure there are other tests with the similar issues, this only became obvious because it?s done 10000 times in one test. I can look through the other uses of file URI?s and file issues for the ones that might be affected by this. Thanks, Christian > Thanks, > Coleen > > On 4/1/19 11:48 AM, Harold Seigel wrote: >> Hi Christian, >> >> This looks good. >> >> Thanks, Harold >> >> On 4/1/2019 11:43 AM, Christian Tornqvist wrote: >>> Hi, >>> >>> Please review this small test fix for an issue where ArraysNewInstanceBug.java times out on certain Windows machines. The test uses a file URI to point to where to find a test class, this URI is supposed to be pointing to the local file system but the file URI uses the format of a network location (two instead of three forward slashes [1]). This causes network lookups on Windows and, depending on the network configuration, this might take some time and cause the test to timeout. >>> >>> Change has been tested by running the test in Mach 5 on Linux, Mac, Solaris and Windows. >>> >>> Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8212627/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212627 >>> >>> Thanks, >>> Christian >>> >>> [1] https://en.wikipedia.org/wiki/File_URI_scheme#How_many_slashes? > From kim.barrett at oracle.com Mon Apr 1 19:44:32 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 1 Apr 2019 15:44:32 -0400 Subject: RFR: 8221102: Allow GC threads to participate in threads claiming protocol In-Reply-To: <2879b1da-cbbb-fbb5-a416-8a56c5f0f0bb@redhat.com> References: <38977DC6-957B-400A-8A19-1EA6977F4A2F@oracle.com> <43C7702A-C046-4E9A-9773-889E7741FBF1@oracle.com> <7571856a-5809-ab9d-c2be-5b6855be5c3c@redhat.com> <6fcffd19-a198-9ee5-46a5-dcbf3c3ed2a9@redhat.com> <204D8F46-0366-4764-8F1A-030CE2A560D7@oracle.com> <0713ED3E-BF5C-4624-B862-45370B02F93F@oracle.com> <2879b1da-cbbb-fbb5-a416-8a56c5f0f0bb@redhat.com> Message-ID: > On Apr 1, 2019, at 5:43 AM, Roman Kennke wrote: > > Hi Kim, > >>>>> Also, the resetting logic warrants a test, it is so rare, it will otherwise not get executed, but if it fails, it would be catastrophic. >>>> I was hoping the resetting code was simple enough to not require a >>>> test. I will see if I can come up with a sensible gtest. >>> >>> I guess the 'design' of the claiming protocol is just making almost everything not-obvious. I think for this reason alone I shall go ahead and work on limiting/eliminating its usage outside of thread.cpp anyway. >> Another function similar to possibly_parallel_threads_do that operated >> on all threads seems like it would be a good thing to have. Possibly >> stealing the existing name and renaming the old operation. I'd like >> the defer that to a followup RFE rather than as part of this bug fix. > > Yes, let's do that. https://bugs.openjdk.java.net/browse/JDK-8221785 >>> If it's too hard to come up with a gtest, then go ahead with your proposed change. >> It turned out not to be *too* difficult to add a gtest. New webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8221102/open.01/ >> incr: http://cr.openjdk.java.net/~kbarrett/8221102/open.01.inc/ > > Great! Patch looks good to me! > > Thanks, > Roman Thanks. From matthias.baesken at sap.com Tue Apr 2 11:04:32 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 2 Apr 2019 11:04:32 +0000 Subject: RFR: 8221535: add steal tick related information to hs_error file [linux] In-Reply-To: References: <6e54431a-8e23-160a-5757-948f1041819e@oracle.com> Message-ID: Hi David , thanks for the review . New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8221535.4/ I added the blank after if you suggested and also adjusted the comments in bool os::Linux::get_tick_information slightly . May I add you as a reviewer ? > > I kept the has_steal_ticks for now; in case someone can confirm > > 2.6.11+ for jdk13 I would remove it . > > I can't comment on that. > It's a pity that we do not have such an info . However I found that we include here : http://hg.openjdk.java.net/jdk/jdk/file/69204b98dc3d/src/java.base/linux/native/libnio/fs/LinuxWatchService.c#l36 and this seems to be 2.6.13+ functionality : https://en.wikipedia.org/wiki/Inotify "August 29, 2005: Linux kernel version 2.6.13 released, containing merged inotify code" However it is not hotspot coding, so I am not 100% sure that we really can claim 2.6.13+ for the whole codebase . Best regards , Matthias > -----Original Message----- > From: David Holmes > Sent: Montag, 1. April 2019 07:01 > To: Baesken, Matthias ; Thomas St?fe > > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR: 8221535: add steal tick related information to hs_error file > [linux] > > Hi Matthias, > > On 29/03/2019 11:37 pm, Baesken, Matthias wrote: > > Hello, new webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8221535.3/ > > > > changed the function to bool os::Linux::get_tick_information(cpu_ticks* > > out, int which_logical_cpu = -1) > > Okay. > > > added memset? at beginning of get_tick_information > > Okay > > > removed the remaining vm_printf ?? from > > src/hotspot/os/aix/os_perf_aix.cpp???? ?(at first I did not notice it > > ?was ?there as well ). > > Okay > > > [ kept the struct? naming CPUPerfTicks??? ( I find plenty of such struct > > name? styles ?in hotspot codebase ?).?? ] > > Agreed - no consistency and you're moving existing code so this is fine > IMHO. > > >> > > > >>In case? we? are sure that we are always? on? 2.6.11+?? kernels, then indeed > I can remove the? special handling. > > > >>I was sure? that? we are on 2.6+? but only 95%? sure that we are > on? 2.6.11+?? . > > > >> > > > > I kept the? has_steal_ticks?? for now; in case someone? can? confirm > > 2.6.11+??for jdk13? I would remove it . > > I can't comment on that. > > One nit in os_linux.cpp: > > + if((fh = fopen("/proc/stat", "r")) == NULL) { > > Need space after if > > Otherwise this all seems fine to me. > > Thanks, > David > From sgehwolf at redhat.com Tue Apr 2 11:48:22 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 02 Apr 2019 13:48:22 +0200 Subject: [PING] RFR: 8217338: [Containers] Improve systemd slice memory limit support In-Reply-To: <226CB44C-7B3A-42E8-8385-4E85168DBA4E@oracle.com> References: <4a1ae4e0e3efd68818bfe868349972aa878de60b.camel@redhat.com> <9a911da4b2a4a8eff42c7c2f1a19c06f6521da8d.camel@redhat.com> <226CB44C-7B3A-42E8-8385-4E85168DBA4E@oracle.com> Message-ID: <254f53446176175689373b346c11aabc26d9b4b0.camel@redhat.com> Could I get a second review, please? Thanks, Severin On Thu, 2019-03-28 at 11:37 -0400, Bob Vandette wrote: > Sorry for the delay. The update looks good. > > Bob. > > > > On Mar 25, 2019, at 1:30 PM, Severin Gehwolf wrote: > > > > On Fri, 2019-03-22 at 14:25 -0400, Bob Vandette wrote: > > > Could you maybe combine subsystem_file_contents with subsystem_file_line_contents > > > by adding an additional argument? > > > > Done: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/05/webrev/ > > > > Thanks, > > Severin > > From adinn at redhat.com Tue Apr 2 14:51:28 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 2 Apr 2019 15:51:28 +0100 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: <8ab058fe-886b-643f-f602-c27182d6f584@oracle.com> References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <8b0f5b4c-0386-1440-6939-646daf36aa55@redhat.com> <24b4bb72-732e-0447-d1be-dd71507e7787@redhat.com> <8ab058fe-886b-643f-f602-c27182d6f584@oracle.com> Message-ID: <2dbe8e0b-a8b5-9129-db24-9ef761bf9741@redhat.com> Hi Colleen, thanks for looking at this. On 01/04/2019 14:28, coleen.phillimore at oracle.com wrote: > > http://cr.openjdk.java.net/~adinn/8221477/webrev.02/src/hotspot/share/classfile/javaClasses.cpp.udiff.html > > > I was sort of expecting you to use like UNSAFE_CONSTANTS_DO for the > fields, so that you don't have to add more names to vmSymbols.hpp. And > that's what the rest of the code does (except CompactStrings). I can > sort of? understand that it's faster as static_fields_do, and you can > check for unexpected fields. Well, I'm only following the model used for CompactStrings because what Vladimir (Kozlov) suggested it as a model to follow when reviewing JEP 352 (it was suggested as a way to initialize the fields I will need to size/align cache lines). I'm not especially attached to this way of doing it. That said, I understand what you say about this vs the alternative. Implementing an UNSAFE_CONSTANTS_DO macro would, on the plus side, avoid the need to add those extra symbols into vmSymbols.hpp but, on the flip side, would i) require repeated calls to InstanceKlass::find_local_field ii) check for expected fields but not detect unexpected fields Is there a reason to be especially concerned over extra field name symbols? I'll change to UNSAFE_CONSTANTS_DO if you want but I really like the fact that this way of doing it guarantees that /all/ fields are final, static and expected. > + jint _address_size; > + jint _page_size; > + jboolean _big_endian; > + jboolean _use_unaligned_access; > > We've been trying to keep Java types out of the C++ code, and use the > appropriate C++ types. Sure, I'll update this accordingly. > InstanceKlass::cast(SystemDictionary::UnsafeConstants_klass())->do_local_static_fields(&fixup); > The cast is unnecessary.? UnsafeConstants_klass returns an InstanceKlass. Ah, ok, I cut and pasted this from the equivalent code for String. Perhaps I should fix that as well. > http://cr.openjdk.java.net/~adinn/8221477/webrev.02/src/hotspot/share/classfile/vmSymbols.hpp.udiff.html > > > I just don't like the field names here. :( Well, sorry, but I have to ask do you mean the words or the format? If the words then is that the names on the left (address_size_name etc) or names on the right (ADDRESS_SIZE etc). n.b as regards upper case I chose ALL_CAPS because these are final static constant numeric fields and ... ... well, I am pleased you brought this up. There is a 'semi-lucid' rationale for the current names albeit one which I am not 100% happy with: I tried to retain the naming convention which is (sort-of) followed in Unsafe e.g. field ADDRESS_SIZE caches the value retrieved by native method addressSize0 and is exposed by public getter addressSize(). I hoped to define all the relevant constant fields in UnsafeConstants using names originally found in class Unsafe. The idea was then to delete the Unsafe fields and statically import the ones from UnsafeConstants into class Unsafe. That way I a simple mention of the imported constants in the getter or at other internal points where they were used would continue to work. That's fine for PAGE_SIZE, UNALIGNED_ACCESS and BE. Getter method pageSize() was always implemented as native with no cached value. So, the old native method can simply be redefined to return the value injected into UnsafeConstants. PAGE_SIZE is thus the conventional name for the static field. The value returned by unalignedAccess0 was cached in private field unalignedAccess (ah yes, camelCase :-/) and then exposed by public getter unalignedAccess(). So, once again importing a field in UnsafeConstants called UNALIGNED_ACCESS and returning this form the getter is uniform. Method isBigEndian0 was used to initialize a field called BE. So, I could have followed suit and called the field in UnsafeConstants BE and this would have worked. However, I though a longer, more explicit name for the UnsafeConstants field would be clearer and picked BIG_ENDIAN. However, I decided to leave the original field BE in Unsafe and simply initialize it from BIG_ENDIAN because it is used in many ternary expression (BE ? ... : ...) and changing it to use a longer name looked terribly messy. So, I admit the choice of BIG_ENDIAN is a little perverse and strictly this field ought to be called BE. However, that turned out to be somewhat moot as the plan was foiled by a further difficulty. I could not delete field Unsafe::ADDRESS_SIZE and import UnsafeConstants::ADDRESS_SIZE because the the field in Unsafe is public (what is worse, it is referenced from the JDK runtime even though public getter addressSize exists). So, the original idea of deleting the Unsafe fields and importing the UnsafeConstants equivalents under the same names was snookered from the get go. In consequence, I simply import class UnsafeConstants and reference the constants with an explicit classname qualifier. So, I accept this is far from perfect. If you have a preferred suggestion as to how to name the fields and getters in UnsafeConstants and/or Unsafe or just advice on how to revise/improve the choices I have made I'd be happy to hear it. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Tue Apr 2 15:12:15 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 2 Apr 2019 16:12:15 +0100 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: <21b14ecd-4b24-8601-4b07-50d7ac516493@oracle.com> References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <8b0f5b4c-0386-1440-6939-646daf36aa55@redhat.com> <24b4bb72-732e-0447-d1be-dd71507e7787@redhat.com> <945d9546-5195-ab33-0e20-57871c2f1ef9@oracle.com> <2a26715f-fa64-9de4-1071-b18d07c05511@redhat.com> <936d213e-9c75-6af4-a7f6-bab6a0f320bb@oracle.com> <21b14ecd-4b24-8601-4b07-50d7ac516493@oracle.com> Message-ID: Hi David, Thanks very much for investigating this and posting your recommendations. On 01/04/2019 08:15, David Holmes wrote: >> I did some analysis of the class loading and initialization sequence >> and added my suggestions to bug report. In summary loading seems >> somewhat immaterial so I suggest: >> >> - javaClasses.hpp: Add UnsafeConstants at the end of >> BASIC_JAVA_CLASSES_DO_PART2 >> - systemDictionary.hpp: Add UnsafeConstants immediately before Unsafe >> >> Then for init: >> - thread.cpp: initialize UnsafeConstants immediately after j.l.Module I have done all of the above. Also, in javaClasses.hpp to keep things uniform I moved the class decl for jdk_internal_misc_UnsafeConstants to follow that of class java_..._AbstractOwnableSynchronizer i.e. the class decl order matches the order of the do_klass statements. >> It would be desirable to detect if we happen to execute the >> earlier (by accident) so I suggest adding a "not initialized" >> assertion prior to your code calling initialize_class. Actually that >> might be a useful addition to the initialize_class method, as if it >> fires it means we're not initializing in the expected order ... I'll >> run a little adding that ... > > I meant to say "run a little test". Turns out you can't put the > assertion in initialize_class as the initialization can vary for some of > the exception classes (at least) depending on VM flags used (e.g. -Xrs, > and I think certain logging options). Ok, thanks. I have added the following immediately before calling initialize_class. #ifdef ASSERT InstanceKlass *k = SystemDictionary::UnsafeConstants_klass(); assert(k->is_not_initialized(), "UnsafeConstants should not already be initialized"); #endif . . . I'll wait for feedback from Coleen before sending an updated webrev. 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 vladimir.kozlov at oracle.com Tue Apr 2 20:41:38 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 2 Apr 2019 13:41:38 -0700 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: <119335f1-acb7-fffc-f38a-e50a96b73b3c@oracle.com> References: <4b759550-f185-724f-7139-9bab648a1966@oracle.com> <119335f1-acb7-fffc-f38a-e50a96b73b3c@oracle.com> Message-ID: <2d206374-cfeb-9b1b-2838-e4e0a774e89d@oracle.com> I ran Kitchensink with G1 and -Xmx8g. I observed that Remark pause times are not consistent even without Graal. To see effect I added time spent in JVMCI::do_unloading() to GC log (see below [3]). The result is < 1ms - it is less than 1% of a pause time. It will have even less effect since I moved JVMCI::do_unloading() from serial path to parallel worker thread as Stefan suggested. Stefan, are you satisfied with these changes now? Here is latest delta update which includes previous [1] delta and - use CompilerThreadStackSize * 2 for libgraal instead of exact value, - removed HandleMark added for debugging (reverted changes in jvmtiImpl.cpp), - added recent jvmci-8 changes to fix registration of native methods in libgraal (jvmciCompilerToVM.cpp) http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.05/ Thanks, Vladimir [1] http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.04/ [2] Original webrev http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ [3] Pauses times from Kitchensink (0.0ms means there were no unloaded classes, 'NNN alive' shows how many metadata references were processed): [1.083s][1554229160638ms][info ][gc,start ] GC(2) Pause Remark [1.085s][1554229160639ms][info ][gc ] GC(2) JVMCI::do_unloading(): 0 alive 0.000ms [1.099s][1554229160654ms][info ][gc ] GC(2) Pause Remark 28M->28M(108M) 16.123ms [3.097s][1554229162651ms][info ][gc,start ] GC(12) Pause Remark [3.114s][1554229162668ms][info ][gc ] GC(12) JVMCI::do_unloading(): 3471 alive 0.164ms [3.148s][1554229162702ms][info ][gc ] GC(12) Pause Remark 215M->213M(720M) 51.103ms [455.111s][1554229614666ms][info ][gc,phases,start] GC(1095) Phase 1: Mark live objects [455.455s][1554229615010ms][info ][gc ] GC(1095) JVMCI::do_unloading(): 4048 alive 0.821ms [455.456s][1554229615010ms][info ][gc,phases ] GC(1095) Phase 1: Mark live objects 344.107ms [848.932s][1554230008486ms][info ][gc,phases,start] GC(1860) Phase 1: Mark live objects [849.248s][1554230008803ms][info ][gc ] GC(1860) JVMCI::do_unloading(): 3266 alive 0.470ms [849.249s][1554230008803ms][info ][gc,phases ] GC(1860) Phase 1: Mark live objects 316.527ms [1163.778s][1554230323332ms][info ][gc,start ] GC(2627) Pause Remark [1163.932s][1554230323486ms][info ][gc ] GC(2627) JVMCI::do_unloading(): 3474 alive 0.642ms [1163.941s][1554230323496ms][info ][gc ] GC(2627) Pause Remark 2502M->2486M(4248M) 163.296ms [1242.587s][1554230402141ms][info ][gc,phases,start] GC(2734) Phase 1: Mark live objects [1242.899s][1554230402453ms][info ][gc ] GC(2734) JVMCI::do_unloading(): 3449 alive 0.570ms [1242.899s][1554230402453ms][info ][gc,phases ] GC(2734) Phase 1: Mark live objects 311.719ms [1364.164s][1554230523718ms][info ][gc,phases,start] GC(3023) Phase 1: Mark live objects [1364.613s][1554230524167ms][info ][gc ] GC(3023) JVMCI::do_unloading(): 3449 alive 0.000ms [1364.613s][1554230524167ms][info ][gc,phases ] GC(3023) Phase 1: Mark live objects 448.495ms [1425.222s][1554230584776ms][info ][gc,phases,start] GC(3151) Phase 1: Mark live objects [1425.587s][1554230585142ms][info ][gc ] GC(3151) JVMCI::do_unloading(): 3491 alive 0.882ms [1425.587s][1554230585142ms][info ][gc,phases ] GC(3151) Phase 1: Mark live objects 365.403ms [1456.401s][1554230615955ms][info ][gc,phases,start] GC(3223) Phase 1: Mark live objects [1456.769s][1554230616324ms][info ][gc ] GC(3223) JVMCI::do_unloading(): 3478 alive 0.616ms [1456.769s][1554230616324ms][info ][gc,phases ] GC(3223) Phase 1: Mark live objects 368.643ms [1806.139s][1554230965694ms][info ][gc,start ] GC(4014) Pause Remark [1806.161s][1554230965716ms][info ][gc ] GC(4014) JVMCI::do_unloading(): 3478 alive 0.000ms [1806.163s][1554230965717ms][info ][gc ] GC(4014) Pause Remark 1305M->1177M(2772M) 23.190ms On 4/1/19 12:34 AM, Stefan Karlsson wrote: > On 2019-03-29 17:55, Vladimir Kozlov wrote: >> Stefan, >> >> Do you have a test (and flags) which can allow me to measure effect of this code on G1 remark pause? > > > -Xlog:gc prints the remark times: > [4,296s][info][gc?????? ] GC(89) Pause Remark 4M->4M(28M) 36,412ms > > StefanK > >> >> Thanks, >> Vladimir >> >> On 3/29/19 12:36 AM, Stefan Karlsson wrote: >>> On 2019-03-29 03:07, Vladimir Kozlov wrote: >>>> Hi Stefan, >>>> >>>> I collected some data on MetadataHandleBlock. >>>> >>>> First, do_unloading() code is executed only when class_unloading_occurred is 'true' - it is rare case. It should not >>>> affect normal G1 remark pause. >>> >>> It's only rare for applications that don't do dynamic class loading and unloading. The applications that do, will be >>> affected. >>> >>>> >>>> Second, I run a test with -Xcomp. I got about 10,000 compilations by Graal and next data at the end of execution: >>>> >>>> max_blocks = 232 >>>> max_handles_per_block = 32 (since handles array has 32 elements) >>>> max_total_alive_values = 4631 >>> >>> OK. Thanks for the info. >>> >>> StefanK >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 3/28/19 2:44 PM, Vladimir Kozlov wrote: >>>>> Thank you, Stefan >>>>> >>>>> On 3/28/19 12:54 PM, Stefan Karlsson wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> I started to check the GC code. >>>>>> >>>>>> ======================================================================== >>>>>> I see that you've added guarded includes in the middle of the include list: >>>>>> ?? #include "gc/shared/strongRootsScope.hpp" >>>>>> ?? #include "gc/shared/weakProcessor.hpp" >>>>>> + #if INCLUDE_JVMCI >>>>>> + #include "jvmci/jvmci.hpp" >>>>>> + #endif >>>>>> ?? #include "oops/instanceRefKlass.hpp" >>>>>> ?? #include "oops/oop.inline.hpp" >>>>>> >>>>>> The style we use is to put these conditional includes at the end of the include lists. >>>>> >>>>> okay >>>>> >>>>>> >>>>>> ======================================================================== >>>>>> Could you also change the following: >>>>>> >>>>>> + #if INCLUDE_JVMCI >>>>>> +???? // Clean JVMCI metadata handles. >>>>>> +???? JVMCI::do_unloading(is_alive_closure(), purged_class); >>>>>> + #endif >>>>>> >>>>>> to: >>>>>> +???? // Clean JVMCI metadata handles. >>>>>> +???? JVMCI_ONLY(JVMCI::do_unloading(is_alive_closure(), purged_class);) >>>>>> >>>>>> to get rid of some of the line noise in the GC files. >>>>> >>>>> okay >>>>> >>>>>> >>>>>> ======================================================================== >>>>>> In the future we will need version of JVMCI::do_unloading that supports concurrent cleaning for ZGC. >>>>> >>>>> Yes, we need to support concurrent cleaning in a future. >>>>> >>>>>> >>>>>> ======================================================================== >>>>>> What's the performance impact for G1 remark pause with this serial walk over the MetadataHandleBlock? >>>>>> >>>>>> 3275 void G1CollectedHeap::complete_cleaning(BoolObjectClosure* is_alive, >>>>>> 3276???????????????????????????????????????? bool class_unloading_occurred) { >>>>>> 3277?? uint num_workers = workers()->active_workers(); >>>>>> 3278?? ParallelCleaningTask unlink_task(is_alive, num_workers, class_unloading_occurred, false); >>>>>> 3279?? workers()->run_task(&unlink_task); >>>>>> 3280 #if INCLUDE_JVMCI >>>>>> 3281?? // No parallel processing of JVMCI metadata handles for now. >>>>>> 3282?? JVMCI::do_unloading(is_alive, class_unloading_occurred); >>>>>> 3283 #endif >>>>>> 3284 } >>>>> >>>>> There should not be impact if Graal is not used. Only cost of call (which most likely is inlined in product VM) and >>>>> check: >>>>> >>>>> http://hg.openjdk.java.net/metropolis/dev/file/530fc1427d02/src/hotspot/share/jvmci/jvmciRuntime.cpp#l1237 >>>>> >>>>> If Graal is used it should not have big impact since these metadata has regular pattern (32 handles per array and >>>>> array per MetadataHandleBlock block which are linked in list) and not large. >>>>> If there will be noticeable impact - we will work on it as you suggested by using ParallelCleaningTask. >>>>> >>>>>> >>>>>> ======================================================================== >>>>>> Did you consider adding it as a task for one of the worker threads to execute in ParallelCleaningTask? >>>>>> >>>>>> See how other tasks are claimed by one worker: >>>>>> void KlassCleaningTask::work() { >>>>>> ?? ResourceMark rm; >>>>>> >>>>>> ?? // One worker will clean the subklass/sibling klass tree. >>>>>> ?? if (claim_clean_klass_tree_task()) { >>>>>> ???? Klass::clean_subklass_tree(); >>>>>> ?? } >>>>> >>>>> These changes were ported from JDK8u based changes in graal-jvmci-8 and there are no ParallelCleaningTask in JDK8. >>>>> >>>>> Your suggestion is interesting and I agree that we should investigate it. >>>>> >>>>>> >>>>>> ======================================================================== >>>>>> In MetadataHandleBlock::do_unloading: >>>>>> >>>>>> +??????? if (klass->class_loader_data()->is_unloading()) { >>>>>> +????????? // This needs to be marked so that it's no longer scanned >>>>>> +????????? // but can't be put on the free list yet. The >>>>>> +????????? // ReferenceCleaner will set this to NULL and >>>>>> +????????? // put it on the free list. >>>>>> >>>>>> I couldn't find the ReferenceCleaner in the patch or in the source. Where can I find this code? >>>>> >>>>> I think it is typo (I will fix it) - it references new HandleCleaner class: >>>>> >>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HandleCleaner.java.html >>>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> Thanks, >>>>>> StefanK >>>>>> >>>>>> On 2019-03-28 20:15, Vladimir Kozlov wrote: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8220623 >>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ >>>>>>> >>>>>>> Update JVMCI to support pre-compiled as shared library Graal. >>>>>>> Using aoted Graal can offers benefits including: >>>>>>> ?- fast startup >>>>>>> ?- compile time similar to native JIt compilers (C2) >>>>>>> ?- memory usage disjoint from the application Java heap >>>>>>> ?- no profile pollution of JDK code used by the application >>>>>>> >>>>>>> This is JDK13 port of JVMCI changes done in graal-jvmci-8 [1] up to date. >>>>>>> Changes were collected in Metropolis repo [2] and tested there. >>>>>>> >>>>>>> Changes we reviewed by Oracle Labs (authors of JVMCI and Graal) and our compiler group. >>>>>>> Changes in shared code are guarded by #if INCLUDE_JVMCI and JVMCI flags. >>>>>>> >>>>>>> I ran tier1-tier8 (which includes HotSpot and JDK tests) and it was clean. In this set Graal was tested only in >>>>>>> tier3. >>>>>>> >>>>>>> And I ran all hs-tier3-graal .. hs-tier8-graal Graal tests available in our system. Several issue were found >>>>>>> which were present before these changes. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> [1] https://github.com/graalvm/graal-jvmci-8/commit/49ff2045fb603e35516a3a427d8023c00e1607af >>>>>>> [2] http://hg.openjdk.java.net/metropolis/dev/ >>>>>> From erik.joelsson at oracle.com Tue Apr 2 21:39:52 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 2 Apr 2019 14:39:52 -0700 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC Message-ID: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> In JDK-8204551, exceptions.hpp started using THIS_FILE instead of __FILE__ to generate exception messages. This is causing the precompiled header to no longer provide any benefit on Linux/GCC. The problem is that the THIS_FILE macro is provided on the command line and is different for each compile unit. Because of this, it seems GCC invalidates the precompiled header completely. (On other platforms, the value of THIS_FILE is instead ignored). The goal of JDK-8204551 was to shorten the path to the file where an exception was raised to avoid truncation. This patch provides a different approach to achieve this, that also fixes the issue for other platforms and compilers. It also fixes the performance issue with precompiled headers. For Hotspot (at least for now), we stop setting -DTHIS_FILE on the compiler command line completely. Instead this macro is defined in macros.hpp, based on __FILE__ but with an offest. This offset is calculated in configure. For newer versions of GCC (8+) there is a new flag, -fmacro-prefix-map=, which can be used to rewrite the __FILE__ macro. Configure checks if this flag is available and uses it instead of the offset macro if possible. I only touched the one usage of THIS_FILE/__FILE__ in this patch. It's possible we should rewrite all references to __FILE__ to improve debug/error. Bug: https://bugs.openjdk.java.net/browse/JDK-8221851 Webrev: http://cr.openjdk.java.net/~erikj/8221851/webrev.01/index.html /Erik From kim.barrett at oracle.com Tue Apr 2 23:02:06 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 2 Apr 2019 19:02:06 -0400 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> Message-ID: <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> > On Apr 2, 2019, at 5:39 PM, Erik Joelsson wrote: > > In JDK-8204551, exceptions.hpp started using THIS_FILE instead of __FILE__ to generate exception messages. This is causing the precompiled header to no longer provide any benefit on Linux/GCC. The problem is that the THIS_FILE macro is provided on the command line and is different for each compile unit. Because of this, it seems GCC invalidates the precompiled header completely. (On other platforms, the value of THIS_FILE is instead ignored). > > The goal of JDK-8204551 was to shorten the path to the file where an exception was raised to avoid truncation. This patch provides a different approach to achieve this, that also fixes the issue for other platforms and compilers. It also fixes the performance issue with precompiled headers. > > For Hotspot (at least for now), we stop setting -DTHIS_FILE on the compiler command line completely. Instead this macro is defined in macros.hpp, based on __FILE__ but with an offest. This offset is calculated in configure. For newer versions of GCC (8+) there is a new flag, -fmacro-prefix-map=, which can be used to rewrite the __FILE__ macro. Configure checks if this flag is available and uses it instead of the offset macro if possible. > > I only touched the one usage of THIS_FILE/__FILE__ in this patch. It's possible we should rewrite all references to __FILE__ to improve debug/error. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221851 > > Webrev: http://cr.openjdk.java.net/~erikj/8221851/webrev.01/index.html > > /Erik Here's an alternative approach that seems simpler. Don't pass THIS_FILE to HotSpot code (or ignore it if that works). Instead add inline const char* this_file_helper(const char* s) { const char* result = strrchr(s, '/'); return (result == NULL) ? s : (result + 1); } and in the one place where HotSpot is using THIS_FILE (exceptions.hpp), instead use this_file_helper(__FILE__) (This assumes the path separator is '/', but there's probably a constant for that somewhere if it's needed.) (this_file_helper() is only needed to deal with the case where __FILE__ contains no path separators; that might not even be an issue, in which case it can be dropped and just add 1 to the strrchr result. Also not wedded to that name; this is more or less basename(3).) Empirically, gcc will optimize that all quite nicely. I don't know about other platforms, but the worst that happens is we take a small runtime hit when "throwing" an exception. This doesn't eliminate the full pathname string embedded in the executable, but I don't think the proposed FILE_MACRO_OFFSET will do that either. Those get fixed by -fmacro-prefix-map=. From kim.barrett at oracle.com Tue Apr 2 23:51:14 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 2 Apr 2019 19:51:14 -0400 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: <2d206374-cfeb-9b1b-2838-e4e0a774e89d@oracle.com> References: <4b759550-f185-724f-7139-9bab648a1966@oracle.com> <119335f1-acb7-fffc-f38a-e50a96b73b3c@oracle.com> <2d206374-cfeb-9b1b-2838-e4e0a774e89d@oracle.com> Message-ID: > On Apr 2, 2019, at 4:41 PM, Vladimir Kozlov wrote: > > I ran Kitchensink with G1 and -Xmx8g. I observed that Remark pause times are not consistent even without Graal. > To see effect I added time spent in JVMCI::do_unloading() to GC log (see below [3]). The result is < 1ms - it is less than 1% of a pause time. > > It will have even less effect since I moved JVMCI::do_unloading() from serial path to parallel worker thread as Stefan suggested. A few comments, while I'm still looking at this. ------------------------------------------------------------------------------ src/hotspot/share/gc/shared/parallelCleaning.cpp 213 JVMCI_ONLY(_jvmci_cleaning_task.work(_unloading_occurred);) I think putting the serial JVMCI cleaning task at the end of the ParallelCleaningTask can result in it being mostly run by itself, without any parallelism. I think it should be put up front, so the first thread in starts working on it right away, while later threads can pick up other work. That's assuming this is all needed. I see that the Java side of things is using WeakReference to do cleanup. I haven't figured out yet why this new kind of weak reference mechanism in the VM is required in addition to the Java WeakReference cleanup. Still working on that... ------------------------------------------------------------------------------ src/hotspot/share/gc/shared/parallelCleaning.cpp 194 #if INCLUDE_JVMCI 195 _jvmci_cleaning_task(is_alive), 196 #endif This could be made a bit less cluttered: JVMCI_ONLY(_jvmci_cleaning_task(is_alive) COMMA) ------------------------------------------------------------------------------ src/hotspot/share/runtime/jniHandles.cpp 192 #if INCLUDE_JVMCI 193 JVMCI::oops_do(f); 194 #endif I don't think that belongs here. ------------------------------------------------------------------------------ From kim.barrett at oracle.com Wed Apr 3 00:49:28 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 2 Apr 2019 20:49:28 -0400 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: References: <4b759550-f185-724f-7139-9bab648a1966@oracle.com> <119335f1-acb7-fffc-f38a-e50a96b73b3c@oracle.com> <2d206374-cfeb-9b1b-2838-e4e0a774e89d@oracle.com> Message-ID: > On Apr 2, 2019, at 7:51 PM, Kim Barrett wrote: > src/hotspot/share/runtime/jniHandles.cpp > 192 #if INCLUDE_JVMCI > 193 JVMCI::oops_do(f); > 194 #endif > > I don't think that belongs here. In addition to my thinking this is just out of place (we already removed the similar JVMTI piggybacking from JNIHandles::weak_oops_do, though it had other problems too), note that ZGC doesn?t call JNIHandles::oops_do at all (it uses the parallel oopstorage API), and probably the only reason some of the other collectors (particularly G) still do is because nobody has gotten around to making them use the parallel oopstorage API too. From vladimir.kozlov at oracle.com Wed Apr 3 01:37:59 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 2 Apr 2019 18:37:59 -0700 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: References: <4b759550-f185-724f-7139-9bab648a1966@oracle.com> <119335f1-acb7-fffc-f38a-e50a96b73b3c@oracle.com> <2d206374-cfeb-9b1b-2838-e4e0a774e89d@oracle.com> Message-ID: <14f3a526-eb3c-a23a-a1bc-198977086f08@oracle.com> On 4/2/19 4:51 PM, Kim Barrett wrote: >> On Apr 2, 2019, at 4:41 PM, Vladimir Kozlov wrote: >> >> I ran Kitchensink with G1 and -Xmx8g. I observed that Remark pause times are not consistent even without Graal. >> To see effect I added time spent in JVMCI::do_unloading() to GC log (see below [3]). The result is < 1ms - it is less than 1% of a pause time. >> >> It will have even less effect since I moved JVMCI::do_unloading() from serial path to parallel worker thread as Stefan suggested. > > A few comments, while I'm still looking at this. > > ------------------------------------------------------------------------------ > src/hotspot/share/gc/shared/parallelCleaning.cpp > 213 JVMCI_ONLY(_jvmci_cleaning_task.work(_unloading_occurred);) > > I think putting the serial JVMCI cleaning task at the end of the > ParallelCleaningTask can result in it being mostly run by itself, > without any parallelism. I think it should be put up front, so the > first thread in starts working on it right away, while later threads > can pick up other work. Should we really put it to the beginning? It takes < 1ms. May be other tasks are more expensive and should be run first as now. But I don't know what is strategy is used here: run short or long tasks first. If you think it is okay to move it - I will move it. > > That's assuming this is all needed. I see that the Java side of things > is using WeakReference to do cleanup. I haven't figured out yet why > this new kind of weak reference mechanism in the VM is required in > addition to the Java WeakReference cleanup. Still working on that... > > ------------------------------------------------------------------------------ > src/hotspot/share/gc/shared/parallelCleaning.cpp > 194 #if INCLUDE_JVMCI > 195 _jvmci_cleaning_task(is_alive), > 196 #endif > > This could be made a bit less cluttered: > > JVMCI_ONLY(_jvmci_cleaning_task(is_alive) COMMA) Yes, I will do this. I tried use JVMCI_ONLY with regular ',' and it failed. Thanks, Vladimir > > ------------------------------------------------------------------------------ > src/hotspot/share/runtime/jniHandles.cpp > 192 #if INCLUDE_JVMCI > 193 JVMCI::oops_do(f); > 194 #endif > > I don't think that belongs here. > > ------------------------------------------------------------------------------ > From vladimir.kozlov at oracle.com Wed Apr 3 01:39:41 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 2 Apr 2019 18:39:41 -0700 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: References: <4b759550-f185-724f-7139-9bab648a1966@oracle.com> <119335f1-acb7-fffc-f38a-e50a96b73b3c@oracle.com> <2d206374-cfeb-9b1b-2838-e4e0a774e89d@oracle.com> Message-ID: <718ce598-694d-d8be-0ee3-cd0057e830e5@oracle.com> On 4/2/19 5:49 PM, Kim Barrett wrote: >> On Apr 2, 2019, at 7:51 PM, Kim Barrett wrote: >> src/hotspot/share/runtime/jniHandles.cpp >> 192 #if INCLUDE_JVMCI >> 193 JVMCI::oops_do(f); >> 194 #endif >> >> I don't think that belongs here. > > In addition to my thinking this is just out of place (we already removed the similar JVMTI > piggybacking from JNIHandles::weak_oops_do, though it had other problems too), note > that ZGC doesn?t call JNIHandles::oops_do at all (it uses the parallel oopstorage API), and > probably the only reason some of the other collectors (particularly G) still do is because > nobody has gotten around to making them use the parallel oopstorage API too. > This is ported from JDK 8 changes. Please, give me suggestion where I should call it? Thanks, Vladimir From kim.barrett at oracle.com Wed Apr 3 02:33:09 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 2 Apr 2019 22:33:09 -0400 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: <14f3a526-eb3c-a23a-a1bc-198977086f08@oracle.com> References: <4b759550-f185-724f-7139-9bab648a1966@oracle.com> <119335f1-acb7-fffc-f38a-e50a96b73b3c@oracle.com> <2d206374-cfeb-9b1b-2838-e4e0a774e89d@oracle.com> <14f3a526-eb3c-a23a-a1bc-198977086f08@oracle.com> Message-ID: <1F02DF2C-16C5-4A90-A980-D1ACE387B5C0@oracle.com> > On Apr 2, 2019, at 9:37 PM, Vladimir Kozlov wrote: > > On 4/2/19 4:51 PM, Kim Barrett wrote: >>> On Apr 2, 2019, at 4:41 PM, Vladimir Kozlov wrote: >>> >>> I ran Kitchensink with G1 and -Xmx8g. I observed that Remark pause times are not consistent even without Graal. >>> To see effect I added time spent in JVMCI::do_unloading() to GC log (see below [3]). The result is < 1ms - it is less than 1% of a pause time. >>> >>> It will have even less effect since I moved JVMCI::do_unloading() from serial path to parallel worker thread as Stefan suggested. >> A few comments, while I'm still looking at this. >> ------------------------------------------------------------------------------ >> src/hotspot/share/gc/shared/parallelCleaning.cpp >> 213 JVMCI_ONLY(_jvmci_cleaning_task.work(_unloading_occurred);) >> I think putting the serial JVMCI cleaning task at the end of the >> ParallelCleaningTask can result in it being mostly run by itself, >> without any parallelism. I think it should be put up front, so the >> first thread in starts working on it right away, while later threads >> can pick up other work. > > Should we really put it to the beginning? It takes < 1ms. > May be other tasks are more expensive and should be run first as now. > But I don't know what is strategy is used here: run short or long tasks first. > If you think it is okay to move it - I will move it. The JVMCI cleaning task is (at least currently) a serial task. All of the others are parallelized, in the sense that each thread will take pieces of the first of those tasks until there aren't any left, and then move on to the next task. Putting the serial task at the end allows all the parallel work to be completed as one thread picks up that remaining serial piece, and then chugs along on its own while all the other threads are now idle. Putting the serial task first means all the other threads can be working through the parallelized work. The serial thread joins the others on the remaining parallel work when it's done, and if there isn't any then it's a good thing we started the serial work first, as it's the long pole. >> That's assuming this is all needed. I see that the Java side of things >> is using WeakReference to do cleanup. I haven't figured out yet why >> this new kind of weak reference mechanism in the VM is required in >> addition to the Java WeakReference cleanup. Still working on that... >> ------------------------------------------------------------------------------ >> src/hotspot/share/gc/shared/parallelCleaning.cpp >> 194 #if INCLUDE_JVMCI >> 195 _jvmci_cleaning_task(is_alive), >> 196 #endif >> This could be made a bit less cluttered: >> JVMCI_ONLY(_jvmci_cleaning_task(is_alive) COMMA) > > Yes, I will do this. I tried use JVMCI_ONLY with regular ',' and it failed. The COMMA macro is exactly for this sort of thing where one needs a deferred comma. It?s a relatively recent addition, and not used all that much yet. From stefan.karlsson at oracle.com Wed Apr 3 06:35:14 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 3 Apr 2019 08:35:14 +0200 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: <2d206374-cfeb-9b1b-2838-e4e0a774e89d@oracle.com> References: <4b759550-f185-724f-7139-9bab648a1966@oracle.com> <119335f1-acb7-fffc-f38a-e50a96b73b3c@oracle.com> <2d206374-cfeb-9b1b-2838-e4e0a774e89d@oracle.com> Message-ID: <8063fb37-f1b0-8b93-bbe8-4dbeeaa54959@oracle.com> On 2019-04-02 22:41, Vladimir Kozlov wrote: > I ran Kitchensink with G1 and -Xmx8g. I observed that Remark pause times > are not consistent even without Graal. > To see effect I added time spent in JVMCI::do_unloading() to GC log (see > below [3]). The result is < 1ms - it is less than 1% of a pause time. Kitchensink isn't really a benchmark, but a stress test. I sent you a private mail how to run these changes through our internal performance test setup. > > It will have even less effect since I moved JVMCI::do_unloading() from > serial path to parallel worker thread as Stefan suggested. > > Stefan, are you satisfied with these changes now? Yes, the clean-ups look good. Thanks for cleaning this up. Kim had some extra comments about a few more places where JVMCI_ONLY could be used. I also agree with him that JVMCI::oops_do should not be placed in JNIHandles::oops_do. I think you should put it where you put the AOTLoader::oops_do calls. Thanks, StefanK > > Here is latest delta update which includes previous [1] delta and > - use CompilerThreadStackSize * 2 for libgraal instead of exact value, > - removed HandleMark added for debugging (reverted changes in > jvmtiImpl.cpp), > - added recent jvmci-8 changes to fix registration of native methods in > libgraal (jvmciCompilerToVM.cpp) > > http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.05/ > > Thanks, > Vladimir > > [1] http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.04/ > [2] Original webrev http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ > [3] Pauses times from Kitchensink (0.0ms means there were no unloaded > classes, 'NNN alive' shows how many metadata references were processed): > > [1.083s][1554229160638ms][info ][gc,start???? ] GC(2) Pause Remark > [1.085s][1554229160639ms][info ][gc?????????? ] GC(2) > JVMCI::do_unloading(): 0 alive 0.000ms > [1.099s][1554229160654ms][info ][gc?????????? ] GC(2) Pause Remark > 28M->28M(108M) 16.123ms > > [3.097s][1554229162651ms][info ][gc,start???? ] GC(12) Pause Remark > [3.114s][1554229162668ms][info ][gc?????????? ] GC(12) > JVMCI::do_unloading(): 3471 alive 0.164ms > [3.148s][1554229162702ms][info ][gc?????????? ] GC(12) Pause Remark > 215M->213M(720M) 51.103ms > > [455.111s][1554229614666ms][info ][gc,phases,start] GC(1095) Phase 1: > Mark live objects > [455.455s][1554229615010ms][info ][gc???????????? ] GC(1095) > JVMCI::do_unloading(): 4048 alive 0.821ms > [455.456s][1554229615010ms][info ][gc,phases????? ] GC(1095) Phase 1: > Mark live objects 344.107ms > > [848.932s][1554230008486ms][info ][gc,phases,start] GC(1860) Phase 1: > Mark live objects > [849.248s][1554230008803ms][info ][gc???????????? ] GC(1860) > JVMCI::do_unloading(): 3266 alive 0.470ms > [849.249s][1554230008803ms][info ][gc,phases????? ] GC(1860) Phase 1: > Mark live objects 316.527ms > > [1163.778s][1554230323332ms][info ][gc,start?????? ] GC(2627) Pause Remark > [1163.932s][1554230323486ms][info ][gc???????????? ] GC(2627) > JVMCI::do_unloading(): 3474 alive 0.642ms > [1163.941s][1554230323496ms][info ][gc???????????? ] GC(2627) Pause > Remark 2502M->2486M(4248M) 163.296ms > > [1242.587s][1554230402141ms][info ][gc,phases,start] GC(2734) Phase 1: > Mark live objects > [1242.899s][1554230402453ms][info ][gc???????????? ] GC(2734) > JVMCI::do_unloading(): 3449 alive 0.570ms > [1242.899s][1554230402453ms][info ][gc,phases????? ] GC(2734) Phase 1: > Mark live objects 311.719ms > > [1364.164s][1554230523718ms][info ][gc,phases,start] GC(3023) Phase 1: > Mark live objects > [1364.613s][1554230524167ms][info ][gc???????????? ] GC(3023) > JVMCI::do_unloading(): 3449 alive 0.000ms > [1364.613s][1554230524167ms][info ][gc,phases????? ] GC(3023) Phase 1: > Mark live objects 448.495ms > > [1425.222s][1554230584776ms][info ][gc,phases,start] GC(3151) Phase 1: > Mark live objects > [1425.587s][1554230585142ms][info ][gc???????????? ] GC(3151) > JVMCI::do_unloading(): 3491 alive 0.882ms > [1425.587s][1554230585142ms][info ][gc,phases????? ] GC(3151) Phase 1: > Mark live objects 365.403ms > > [1456.401s][1554230615955ms][info ][gc,phases,start] GC(3223) Phase 1: > Mark live objects > [1456.769s][1554230616324ms][info ][gc???????????? ] GC(3223) > JVMCI::do_unloading(): 3478 alive 0.616ms > [1456.769s][1554230616324ms][info ][gc,phases????? ] GC(3223) Phase 1: > Mark live objects 368.643ms > > [1806.139s][1554230965694ms][info?? ][gc,start?????? ] GC(4014) Pause > Remark > [1806.161s][1554230965716ms][info?? ][gc???????????? ] GC(4014) > JVMCI::do_unloading(): 3478 alive 0.000ms > [1806.163s][1554230965717ms][info?? ][gc???????????? ] GC(4014) Pause > Remark 1305M->1177M(2772M) 23.190ms > > > > On 4/1/19 12:34 AM, Stefan Karlsson wrote: >> On 2019-03-29 17:55, Vladimir Kozlov wrote: >>> Stefan, >>> >>> Do you have a test (and flags) which can allow me to measure effect >>> of this code on G1 remark pause? >> >> >> -Xlog:gc prints the remark times: >> [4,296s][info][gc?????? ] GC(89) Pause Remark 4M->4M(28M) 36,412ms >> >> StefanK >> >>> >>> Thanks, >>> Vladimir >>> >>> On 3/29/19 12:36 AM, Stefan Karlsson wrote: >>>> On 2019-03-29 03:07, Vladimir Kozlov wrote: >>>>> Hi Stefan, >>>>> >>>>> I collected some data on MetadataHandleBlock. >>>>> >>>>> First, do_unloading() code is executed only when >>>>> class_unloading_occurred is 'true' - it is rare case. It should not >>>>> affect normal G1 remark pause. >>>> >>>> It's only rare for applications that don't do dynamic class loading >>>> and unloading. The applications that do, will be affected. >>>> >>>>> >>>>> Second, I run a test with -Xcomp. I got about 10,000 compilations >>>>> by Graal and next data at the end of execution: >>>>> >>>>> max_blocks = 232 >>>>> max_handles_per_block = 32 (since handles array has 32 elements) >>>>> max_total_alive_values = 4631 >>>> >>>> OK. Thanks for the info. >>>> >>>> StefanK >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 3/28/19 2:44 PM, Vladimir Kozlov wrote: >>>>>> Thank you, Stefan >>>>>> >>>>>> On 3/28/19 12:54 PM, Stefan Karlsson wrote: >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> I started to check the GC code. >>>>>>> >>>>>>> ======================================================================== >>>>>>> >>>>>>> I see that you've added guarded includes in the middle of the >>>>>>> include list: >>>>>>> ?? #include "gc/shared/strongRootsScope.hpp" >>>>>>> ?? #include "gc/shared/weakProcessor.hpp" >>>>>>> + #if INCLUDE_JVMCI >>>>>>> + #include "jvmci/jvmci.hpp" >>>>>>> + #endif >>>>>>> ?? #include "oops/instanceRefKlass.hpp" >>>>>>> ?? #include "oops/oop.inline.hpp" >>>>>>> >>>>>>> The style we use is to put these conditional includes at the end >>>>>>> of the include lists. >>>>>> >>>>>> okay >>>>>> >>>>>>> >>>>>>> ======================================================================== >>>>>>> >>>>>>> Could you also change the following: >>>>>>> >>>>>>> + #if INCLUDE_JVMCI >>>>>>> +???? // Clean JVMCI metadata handles. >>>>>>> +???? JVMCI::do_unloading(is_alive_closure(), purged_class); >>>>>>> + #endif >>>>>>> >>>>>>> to: >>>>>>> +???? // Clean JVMCI metadata handles. >>>>>>> +???? JVMCI_ONLY(JVMCI::do_unloading(is_alive_closure(), >>>>>>> purged_class);) >>>>>>> >>>>>>> to get rid of some of the line noise in the GC files. >>>>>> >>>>>> okay >>>>>> >>>>>>> >>>>>>> ======================================================================== >>>>>>> >>>>>>> In the future we will need version of JVMCI::do_unloading that >>>>>>> supports concurrent cleaning for ZGC. >>>>>> >>>>>> Yes, we need to support concurrent cleaning in a future. >>>>>> >>>>>>> >>>>>>> ======================================================================== >>>>>>> >>>>>>> What's the performance impact for G1 remark pause with this >>>>>>> serial walk over the MetadataHandleBlock? >>>>>>> >>>>>>> 3275 void G1CollectedHeap::complete_cleaning(BoolObjectClosure* >>>>>>> is_alive, >>>>>>> 3276???????????????????????????????????????? bool >>>>>>> class_unloading_occurred) { >>>>>>> 3277?? uint num_workers = workers()->active_workers(); >>>>>>> 3278?? ParallelCleaningTask unlink_task(is_alive, num_workers, >>>>>>> class_unloading_occurred, false); >>>>>>> 3279?? workers()->run_task(&unlink_task); >>>>>>> 3280 #if INCLUDE_JVMCI >>>>>>> 3281?? // No parallel processing of JVMCI metadata handles for now. >>>>>>> 3282?? JVMCI::do_unloading(is_alive, class_unloading_occurred); >>>>>>> 3283 #endif >>>>>>> 3284 } >>>>>> >>>>>> There should not be impact if Graal is not used. Only cost of call >>>>>> (which most likely is inlined in product VM) and check: >>>>>> >>>>>> http://hg.openjdk.java.net/metropolis/dev/file/530fc1427d02/src/hotspot/share/jvmci/jvmciRuntime.cpp#l1237 >>>>>> >>>>>> >>>>>> If Graal is used it should not have big impact since these >>>>>> metadata has regular pattern (32 handles per array and array per >>>>>> MetadataHandleBlock block which are linked in list) and not large. >>>>>> If there will be noticeable impact - we will work on it as you >>>>>> suggested by using ParallelCleaningTask. >>>>>> >>>>>>> >>>>>>> ======================================================================== >>>>>>> >>>>>>> Did you consider adding it as a task for one of the worker >>>>>>> threads to execute in ParallelCleaningTask? >>>>>>> >>>>>>> See how other tasks are claimed by one worker: >>>>>>> void KlassCleaningTask::work() { >>>>>>> ?? ResourceMark rm; >>>>>>> >>>>>>> ?? // One worker will clean the subklass/sibling klass tree. >>>>>>> ?? if (claim_clean_klass_tree_task()) { >>>>>>> ???? Klass::clean_subklass_tree(); >>>>>>> ?? } >>>>>> >>>>>> These changes were ported from JDK8u based changes in >>>>>> graal-jvmci-8 and there are no ParallelCleaningTask in JDK8. >>>>>> >>>>>> Your suggestion is interesting and I agree that we should >>>>>> investigate it. >>>>>> >>>>>>> >>>>>>> ======================================================================== >>>>>>> >>>>>>> In MetadataHandleBlock::do_unloading: >>>>>>> >>>>>>> +??????? if (klass->class_loader_data()->is_unloading()) { >>>>>>> +????????? // This needs to be marked so that it's no longer scanned >>>>>>> +????????? // but can't be put on the free list yet. The >>>>>>> +????????? // ReferenceCleaner will set this to NULL and >>>>>>> +????????? // put it on the free list. >>>>>>> >>>>>>> I couldn't find the ReferenceCleaner in the patch or in the >>>>>>> source. Where can I find this code? >>>>>> >>>>>> I think it is typo (I will fix it) - it references new >>>>>> HandleCleaner class: >>>>>> >>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HandleCleaner.java.html >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> StefanK >>>>>>> >>>>>>> On 2019-03-28 20:15, Vladimir Kozlov wrote: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8220623 >>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ >>>>>>>> >>>>>>>> Update JVMCI to support pre-compiled as shared library Graal. >>>>>>>> Using aoted Graal can offers benefits including: >>>>>>>> ?- fast startup >>>>>>>> ?- compile time similar to native JIt compilers (C2) >>>>>>>> ?- memory usage disjoint from the application Java heap >>>>>>>> ?- no profile pollution of JDK code used by the application >>>>>>>> >>>>>>>> This is JDK13 port of JVMCI changes done in graal-jvmci-8 [1] up >>>>>>>> to date. >>>>>>>> Changes were collected in Metropolis repo [2] and tested there. >>>>>>>> >>>>>>>> Changes we reviewed by Oracle Labs (authors of JVMCI and Graal) >>>>>>>> and our compiler group. >>>>>>>> Changes in shared code are guarded by #if INCLUDE_JVMCI and >>>>>>>> JVMCI flags. >>>>>>>> >>>>>>>> I ran tier1-tier8 (which includes HotSpot and JDK tests) and it >>>>>>>> was clean. In this set Graal was tested only in tier3. >>>>>>>> >>>>>>>> And I ran all hs-tier3-graal .. hs-tier8-graal Graal tests >>>>>>>> available in our system. Several issue were found which were >>>>>>>> present before these changes. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> [1] >>>>>>>> https://github.com/graalvm/graal-jvmci-8/commit/49ff2045fb603e35516a3a427d8023c00e1607af >>>>>>>> >>>>>>>> [2] http://hg.openjdk.java.net/metropolis/dev/ >>>>>>> From fanjinke51 at yeah.net Wed Apr 3 07:20:16 2019 From: fanjinke51 at yeah.net (Jinke Fan) Date: Wed, 3 Apr 2019 15:20:16 +0800 Subject: [PATCH]: Add Hygon Dhyana support Message-ID: <8f61e7c6-bdca-770a-4c30-cc24b0da0856@yeah.net> Hello All, This patch is used to support Hygon Dhyana x86 vendor id (HygonGenuine). As Hygon Dhyana CPU share most architecture feature same as AMD Family 17h, the patch adds Hygon CPU Vendor ID check to reuse AMD code paths. Background: Chengdu Haiguang IC Design Co., Ltd (Hygon) is a Joint Venture between AMD and Haiguang Information Technology Co.,Ltd., aims at providing high performance x86 processor for China server market. Its first generation processor codename is Dhyana, which originates from AMD technology and shares most of the architecture with AMD's family 17h, but with different CPU Vendor ID("HygonGenuine")/Family series number(Family 18h). The patch is based on the original repository: hg.openjdk.java.net/jdk/jdk changeset: 54384:cd3b7ad53265 tag: tip user: kvn date: Tue Apr 02 09:45:52 2019 -0700 summary: 8221782: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.jdk.vm.ci.services Please help me with the commit process. Thank you very much! *patch Webrev: https://fjkbo.github.io/openjdk/webrev/index.html The output of hg diff -g: diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp b/src/hotspot/cpu/x86/assembler_x86.cpp --- a/src/hotspot/cpu/x86/assembler_x86.cpp +++ b/src/hotspot/cpu/x86/assembler_x86.cpp @@ -3099,7 +3099,7 @@ } return; } - if (UseAddressNop && VM_Version::is_amd()) { + if (UseAddressNop && (VM_Version::is_amd() || VM_Version::is_hygon())) { // // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. // 1: 0x90 diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp @@ -340,6 +340,10 @@ return !is_amd_Barcelona(); } + if (is_hygon()) { + return true; + } + return false; } diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp b/src/hotspot/cpu/x86/vm_version_x86.cpp --- a/src/hotspot/cpu/x86/vm_version_x86.cpp +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp @@ -1165,7 +1165,7 @@ } } - if( is_amd() ) { // AMD cpus specific settings + if( is_amd() || is_hygon() ) { // AMD cpus specific settings if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { // Use it on new AMD cpus starting from Opteron. UseAddressNop = true; @@ -1239,8 +1239,8 @@ } #endif // COMPILER2 - // Some defaults for AMD family 17h - if ( cpu_family() == 0x17 ) { + // Some defaults for AMD family 17h || Hygon family 18h + if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { // On family 17h processors use XMM and UnalignedLoadStores for Array Copy if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp b/src/hotspot/cpu/x86/vm_version_x86.hpp --- a/src/hotspot/cpu/x86/vm_version_x86.hpp +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp @@ -495,13 +495,13 @@ result |= CPU_CX8; if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) result |= CPU_CMOV; - if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && + if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() || is_hygon()) && _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) result |= CPU_FXSR; // HT flag is set for multi-core processors also. if (threads_per_core() > 1) result |= CPU_HT; - if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && + if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() || is_hygon()) && _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) result |= CPU_MMX; if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) @@ -576,8 +576,8 @@ if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) result |= CPU_FMA; - // AMD features. - if (is_amd()) { + // AMD|Hygon features. + if (is_amd() || is_hygon()) { if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) result |= CPU_3DNOW_PREFETCH; @@ -711,6 +711,7 @@ static int cpu_family() { return _cpu;} static bool is_P6() { return cpu_family() >= 6; } static bool is_amd() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' + static bool is_hygon() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x6F677948; } // 'ogyH' static bool is_intel() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' static bool is_zx() { assert_is_initialized(); return (_cpuid_info.std_vendor_name_0 == 0x746e6543) || (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS ' static bool is_atom_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton @@ -734,7 +735,7 @@ if (!supports_topology || result == 0) { result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); } - } else if (is_amd()) { + } else if (is_amd() || is_hygon()) { result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); } else if (is_zx()) { bool supports_topology = supports_processor_topology(); @@ -770,7 +771,7 @@ intx result = 0; if (is_intel()) { result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); - } else if (is_amd()) { + } else if (is_amd() || is_hygon()) { result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; } else if (is_zx()) { result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); @@ -857,7 +858,7 @@ // AMD features static bool supports_3dnow_prefetch() { return (_features & CPU_3DNOW_PREFETCH) != 0; } - static bool supports_mmx_ext() { return is_amd() && _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } + static bool supports_mmx_ext() { return (is_amd()||is_hygon()) && _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } static bool supports_lzcnt() { return (_features & CPU_LZCNT) != 0; } static bool supports_sse4a() { return (_features & CPU_SSE4A) != 0; } @@ -870,7 +871,7 @@ } static bool supports_tscinv() { return supports_tscinv_bit() && - ( (is_amd() && !is_amd_Barcelona()) || + ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || is_intel_tsc_synched_at_init() ); } @@ -896,7 +897,7 @@ // Core - 256 / prefetchnta // It will be used only when AllocatePrefetchStyle > 0 - if (is_amd()) { // AMD + if (is_amd() || is_hygon()) { // AMD if (supports_sse2()) { return 256; // Opteron } else { *test I tested it with jtreg and found no regressions. Base Run? ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/hotspot/jtreg:tier1 1396 1396 0 0 >> jtreg:test/jdk:tier1 1867 1866 1 0 << >> jtreg:test/langtools:tier1 3920 3919 1 0 << jtreg:test/nashorn:tier1 0 0 0 0 jtreg:test/jaxp:tier1 0 0 0 0 ============================== TEST FAILURE And The result of after patching is the same as the before. ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/hotspot/jtreg:tier1 1396 1396 0 0 >> jtreg:test/jdk:tier1 1867 1866 1 0 << >> jtreg:test/langtools:tier1 3920 3919 1 0 << jtreg:test/nashorn:tier1 0 0 0 0 jtreg:test/jaxp:tier1 0 0 0 0 ============================== TEST FAILURE Is there anything incorrectly? Please let me know your comments. Best Regards! Fanjinke. From jcbeyler at google.com Tue Apr 2 16:59:11 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 2 Apr 2019 09:59:11 -0700 Subject: RFR (L) 8213501 : Deploy ExceptionJniWrapper for a few tests In-Reply-To: References: <45341168-e7e0-90d1-449f-210500882b8f@oracle.com> <55283958-de3d-07f2-51e3-ad34c5046a96@oracle.com> <31613f88-5f7d-938d-e9f6-69cdaf857268@oracle.com> <839301b7-c247-df3b-e485-283e8bb7388b@oracle.com> <95fe277d-ba6e-4fec-77aa-d1f1051751aa@oracle.com> <72bf2f4a-5bf7-98de-5f00-68485072923d@oracle.com> <25a50bc3-222c-a915-5517-37a2f9375c42@oracle.com> Message-ID: Hi all, Friendly ping on this one, I know I've used up quite a bit of time on it; my apologies again :) Jc On Tue, Mar 26, 2019 at 12:37 PM Jean Christophe Beyler wrote: > Hi all, > > My apologies again for this one. This has been a bit tricky to get in and > has fell off my priority list due to other issues/commitments but I'm back > to finishing this up and the next webrevs regarding this work :) > > Problem is that we change years so the copyrights changed on some of these > and there were a few problems with various architectures/build systems that > made the testing fail on the submit repo. > > So I offer two webrevs: > > - The incremental from the last LGTM stamped one: > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.06_07/ > > - The full webrev that cleaned up a few problems for windows and solaris > and now passes the submit repo: > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.07/ > > And again, my sincere apologies that it took me SO long to get back to > this but I had to work through the random submit repo failures and some of > them took time for me to debug (thanks Serguei for your help :-)), > Jc > > On Tue, Jan 22, 2019 at 6:03 PM Alex Menkov > wrote: > >> +1 >> >> --alex >> >> On 01/22/2019 10:29, JC Beyler wrote: >> > Thanks Paul! >> > >> > Anybody else for the review for version 6? >> > >> > Webrev: http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.06/ >> > >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8213501 >> > >> > >> > Thanks, >> > Jc >> > >> > On Tue, Jan 22, 2019 at 6:10 AM Hohensee, Paul > > > wrote: >> > >> > Lgtm :) >> > >> > Paul >> > >> > ?On 1/14/19, 7:46 AM, "hotspot-dev on behalf of JC Beyler" >> > > > on behalf of >> > jcbeyler at google.com > wrote: >> > >> > Hi all, >> > >> > Friendly ping on this one, I know that it has been a long >> > process with back >> > and forths, to which I apologize... >> > >> > But is there any way I could get a final LGTM for version 6? >> > >> > Webrev: >> http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.06/ >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8213501 >> > >> > Thanks! >> > Jc >> > >> > On Tue, Jan 8, 2019 at 10:05 AM JC Beyler > > > wrote: >> > >> > > Happy new year all! >> > > >> > > Could I get a final LGTM for version 6? >> > > >> > > Webrev: >> http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.06/ >> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213501 >> > > >> > > Thanks! >> > > Jc >> > > >> > > On Mon, Dec 17, 2018 at 8:43 AM JC Beyler >> > > wrote: >> > > >> > >> Hi all, >> > >> >> > >> I don't believe I got actual LGTM for this version: >> > >> >> > >> >> > >> Webrev: >> http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.06/ >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8213501 >> > >> >> > >> >> > >> It removed the namespaces and uses explicit static instead >> :) >> > >> >> > >> Thanks! >> > >> Jc >> > >> >> > >> On Wed, Dec 12, 2018 at 8:06 PM JC Beyler >> > > wrote: >> > >> >> > >>> So did I Alexey but with David & Serguei preferring static, >> > it seems >> > >>> more reasonable to go down their route :-) >> > >>> >> > >>> So here is the latest webrev with static instead of an >> > anonymous >> > >>> namespace: >> > >>> >> > >>> Webrev: >> http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.06/ >> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213501 >> > >>> >> > >>> Let me know what you think, can I get a webrev 06 review? >> > >>> >> > >>> Thanks! >> > >>> Jc >> > >>> >> > >>> On Wed, Dec 12, 2018 at 3:10 PM Alex Menkov >> > > >> > >>> wrote: >> > >>> >> > >>>> Hm.. >> > >>>> I considered unnamed namespaces "C++ style" (and static >> > globals as "C >> > >>>> style"). >> > >>>> Static globals were deprecated in C++ (but some time ago >> the >> > >>>> deprecation >> > >>>> was reverted). >> > >>>> >> > >>>> --alex >> > >>>> >> > >>>> On 12/12/2018 13:55, serguei.spitsyn at oracle.com >> > wrote: >> > >>>> > Agreed. >> > >>>> > >> > >>>> > Thanks, >> > >>>> > Serguei >> > >>>> > >> > >>>> > >> > >>>> > On 12/12/18 13:52, David Holmes wrote: >> > >>>> >> FWIW I think namespaces are overkill in all of this >> > test code and >> > >>>> just >> > >>>> >> obfuscates things - the declaration is easily missed. A >> > static >> > >>>> >> variable in a .cpp is clearly a global variable to the >> > file. >> > >>>> >> >> > >>>> >> Cheers, >> > >>>> >> David >> > >>>> >> >> > >>>> >> >> > >>>> >> >> > >>>> >> On 13/12/2018 5:37 am, serguei.spitsyn at oracle.com >> > wrote: >> > >>>> >>> Hi Jc, >> > >>>> >>> >> > >>>> >>> >> > >>>> >>> On 12/11/18 21:16, JC Beyler wrote: >> > >>>> >>>> Hi all, >> > >>>> >>>> >> > >>>> >>>> Here is the new webrev with the TEST.groups change. >> > Serguei, let >> > >>>> me >> > >>>> >>>> know if I convinced you with the static vs anonymous >> > namespaces or >> > >>>> >>>> if you'd still rather have a "static" for now :-) >> > >>>> >>> >> > >>>> >>> >> > >>>> >>> What do you think about this post? : >> > >>>> >>> >> > >>>> >> > >> https://stackoverflow.com/questions/11623451/static-vs-non-static-variables-in-namespace >> > >>>> >>> >> > >>>> >>> >> > >>>> >>>> >> > >>>> >>>> Webrev: >> > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.05/ >> > >>>> >>>> >> > >> > >>>> >>>> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8213501 >> > >>>> >>> >> > >>>> >>> The update looks fine. >> > >>>> >>> >> > >>>> >>> Thanks, >> > >>>> >>> Serguei >> > >>>> >>> >> > >>>> >>> >> > >>>> >>> Thanks, >> > >>>> >>> Serguei >> > >>>> >>> >> > >>>> >>>> >> > >>>> >>>> Thanks again for the reviews! >> > >>>> >>>> Jc >> > >>>> >>>> >> > >>>> >>>> On Mon, Dec 10, 2018 at 3:10 PM JC Beyler >> > >> > >>>> >>>> > > >> wrote: >> > >>>> >>>> >> > >>>> >>>> Hi Serguei, >> > >>>> >>>> >> > >>>> >>>> Yes basically it is equivalent :) I can put them >> > in but they >> > >>>> are >> > >>>> >>>> not required. The norm actually wanted to >> > deprecate it but then >> > >>>> >>>> remembered that C compatibility would require the >> > static >> > >>>> key-word >> > >>>> >>>> for this case [1] >> > >>>> >>>> >> > >>>> >>>> So, really, they are not required here and will >> > amount to the >> > >>>> same >> > >>>> >>>> thing: only that file can refer to them and you >> > cannot get to >> > >>>> them >> > >>>> >>>> without a globally available method to return a >> > pointer to them >> > >>>> >>>> (ie same as a static variable in C). >> > >>>> >>>> >> > >>>> >>>> I can put static if it makes it easier to see >> > but, by being in >> > >>>> an >> > >>>> >>>> anonymous namespace they are only available for >> > the file's >> > >>>> >>>> translation unit. For example: >> > >>>> >>>> >> > >>>> >>>> $ cat main.cpp >> > >>>> >>>> >> > >>>> >>>> int totally_global; >> > >>>> >>>> static int explictly_static; >> > >>>> >>>> >> > >>>> >>>> namespace { >> > >>>> >>>> int implicitly_static; >> > >>>> >>>> } >> > >>>> >>>> >> > >>>> >>>> void foo(); >> > >>>> >>>> int main() { >> > >>>> >>>> foo(); >> > >>>> >>>> } >> > >>>> >>>> >> > >>>> >>>> $ g++ -O3 main.cpp -c >> > >>>> >>>> $ nm main.o >> > >>>> >>>> U _GLOBAL_OFFSET_TABLE_ >> > >>>> >>>> 0000000000000000 T main >> > >>>> >>>> 0000000000000000 B totally_global >> > >>>> >>>> U _Z3foov >> > >>>> >>>> >> > >>>> >>>> As you can see, the static and anonymous >> > namespace variables >> > >>>> are >> > >>>> >>>> not in the file due to not being used. If you >> > were to use them, >> > >>>> >>>> you'd see them show up as something like: >> > >>>> >>>> 0000000000000008 b _ZL17explicitly_static >> > >>>> >>>> 0000000000000004 b >> > _ZN12_GLOBAL__N_117implicitly_staticE >> > >>>> >>>> >> > >>>> >>>> Where again, it shows that it is mangling the >> > names so that no >> > >>>> >>>> external usage can happen without tinkering. >> > >>>> >>>> >> > >>>> >>>> Hopefully that helps :-), >> > >>>> >>>> Jc >> > >>>> >>>> >> > >>>> >>>> [1] >> > >>>> >>>> >> > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1012 >> > >>>> >>>> >> > >>>> >>>> >> > >>>> >>>> On Mon, Dec 10, 2018 at 2:04 PM >> > serguei.spitsyn at oracle.com >> > >>>> >>>> > > > < >> > >>>> serguei.spitsyn at oracle.com > serguei.spitsyn at oracle.com> >> > >>>> >>>> > > >> wrote: >> > >>>> >>>> >> > >>>> >>>> Hi Jc, >> > >>>> >>>> >> > >>>> >>>> I had little experience with the C++ >> namespaces. >> > >>>> >>>> My understanding is that static in this >> > context should mean >> > >>>> >>>> internal linkage. >> > >>>> >>>> >> > >>>> >>>> Thanks, >> > >>>> >>>> Serguei >> > >>>> >>>> >> > >>>> >>>> >> > >>>> >>>> On 12/10/18 13:57, JC Beyler wrote: >> > >>>> >>>>> Hi Serguei, >> > >>>> >>>>> >> > >>>> >>>>> The variables and functions are in a >> > anonymous namespace; >> > >>>> my >> > >>>> >>>>> understanding of C++ is that this is >> > equivalent to >> > >>>> putting it >> > >>>> >>>>> as static.Hence, I didn't add them there. >> > Does that make >> > >>>> >>>>> sense? >> > >>>> >>>>> >> > >>>> >>>>> Thanks! >> > >>>> >>>>> Jc >> > >>>> >>>>> >> > >>>> >>>>> On Mon, Dec 10, 2018 at 1:33 PM >> > >>>> serguei.spitsyn at oracle.com > serguei.spitsyn at oracle.com> >> > >>>> >>>>> > > > >> > >>>> >>>>> > > >> > >>>> >>>>> > > >> wrote: >> > >>>> >>>>> >> > >>>> >>>>> Hi Jc, >> > >>>> >>>>> >> > >>>> >>>>> It looks good in general. >> > >>>> >>>>> One question though. >> > >>>> >>>>> >> > >>>> >>>>> >> > >>>> >> > >> http://cr.openjdk.java.net/%7Ejcbeyler/8213501/webrev.03a_04/test/hotspot/jtreg/vmTestbase/nsk/share/ExceptionCheckingJniEnv/exceptionjni001/exceptionjni001.cpp.html >> > >>>> >>>>> >> > >>>> >>>>> >> > >>>> >>>>> I wonder if the variables and functions >> > have to be >> > >>>> static. >> > >>>> >>>>> >> > >>>> >>>>> Thanks, >> > >>>> >>>>> Serguei >> > >>>> >>>>> >> > >>>> >>>>> >> > >>>> >>>>> On 12/5/18 11:36, JC Beyler wrote: >> > >>>> >>>>>> Hi all, >> > >>>> >>>>>> >> > >>>> >>>>>> My apologies to having to come back for >> > another >> > >>>> review >> > >>>> >>>>>> for this change: I ran into a snag when >> > trying to >> > >>>> pull >> > >>>> >>>>>> the latest changes compared to the base >> > I was working >> > >>>> >>>>>> on. I basically forgot that there was >> > an issue with >> > >>>> >>>>>> snprintf and that I had solved it via >> > JDK-8213622. >> > >>>> >>>>>> >> > >>>> >>>>>> Could I have a new review of this >> webrev: >> > >>>> >>>>>> Webrev: >> > >>>> >>>>>> >> http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.04/ >> > >>>> >>>>>> >> > >> > >>>> >>>>>> Bug: >> > >>>> https://bugs.openjdk.java.net/browse/JDK-8213501 >> > >>>> >>>>>> Incremental from the port of webrev.03 >> > that got >> > >>>> LGTMs: >> > >>>> >>>>>> >> > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.03a_04/ >> > >>>> >>>>>> >> > >> > >>>> >>>>>> >> > >>>> >>>>>> A few comments on this because it took >> > me a while to >> > >>>> get >> > >>>> >>>>>> things in a state I thought was good: >> > >>>> >>>>>> - I had to implement an itoa method, >> > do we have >> > >>>> >>>>>> something like that in the test base >> > (remember that >> > >>>> >>>>>> JDK-8213622 could not use sprintf due >> > to being in the >> > >>>> >>>>>> test code)? >> > >>>> >>>>>> >> > >>>> >>>>>> - The differences here compared to >> > the one you all >> > >>>> >>>>>> reviewed are: >> > >>>> >>>>>> - I found that adding to the >> > strlen/memcpy >> > >>>> error >> > >>>> >>>>>> prone and thought that I would try to >> > make it less >> > >>>> so. >> > >>>> >>>>>> If you want to compare, I extended the >> > strlen/memcpy >> > >>>> >>>>>> with the new format to show you if you >> > prefer [1] >> > >>>> >>>>>> - Note that the diff >> > between the "old >> > >>>> >>>>>> extended way from [1]" to the webrev.04 >> > can be found >> > >>>> >>>>>> in [2] >> > >>>> >>>>>> >> > >>>> >>>>>> - I added a test to test the >> > exception wrapper >> > >>>> in >> > >>>> >>>>>> tests :); I'm not sure it is deemed >> > useful or not but >> > >>>> >>>>>> helped me assure myself that I was not >> > doing things >> > >>>> >>>>>> wrong; you can find the base test file >> > here [3]; >> > >>>> should >> > >>>> >>>>>> we have this or not? (I know that >> > normally we don't >> > >>>> add >> > >>>> >>>>>> tests to vmTestbase but thought this >> > might be an >> > >>>> >>>>>> exception) >> > >>>> >>>>>> >> > >>>> >>>>>> Thanks for your help and my apologies >> > for the snag, >> > >>>> >>>>>> Jc >> > >>>> >>>>>> >> > >>>> >>>>>> [1]: >> > >>>> >>>>>> >> > >>>> >> > >> http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.03a/test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.cpp.udiff.html >> > >>>> >>>>>> >> > >>>> >>>>>> < >> > >>>> >> > >> http://cr.openjdk.java.net/%7Ejcbeyler/8213501/webrev.03a/test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.cpp.udiff.html >> > >> > >>>> >> > >>>> >>>>>> >> > >>>> >>>>>> [2]: >> > >>>> >>>>>> >> > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.03a_04 >> > >>>> >>>>>> >> > >> > >>>> >>>>>> [3] >> > >>>> >>>>>> >> > >>>> >> > >> http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.04/test/hotspot/jtreg/vmTestbase/nsk/share/ExceptionCheckingJniEnv/exceptionjni001/exceptionjni001.cpp.html >> > >>>> >>>>>> >> > >>>> >>>>>> < >> > >>>> >> > >> http://cr.openjdk.java.net/%7Ejcbeyler/8213501/webrev.04/test/hotspot/jtreg/vmTestbase/nsk/share/ExceptionCheckingJniEnv/exceptionjni001/exceptionjni001.cpp.html >> > >> > >>>> >> > >>>> >>>>>> >> > >>>> >>>>>> >> > >>>> >>>>>> On Mon, Dec 3, 2018 at 11:29 PM David >> > Holmes >> > >>>> >>>>>> > > >> > >>>> >>>>>> > > >> wrote: >> > >>>> >>>>>> >> > >>>> >>>>>> Looks fine to me. >> > >>>> >>>>>> >> > >>>> >>>>>> Thanks, >> > >>>> >>>>>> David >> > >>>> >>>>>> >> > >>>> >>>>>> On 4/12/2018 4:04 pm, JC Beyler >> wrote: >> > >>>> >>>>>> > Hi both, >> > >>>> >>>>>> > >> > >>>> >>>>>> > Thanks for the reviews! Since >> > Serguei did not >> > >>>> >>>>>> insist on get_basename, I >> > >>>> >>>>>> > went for get_dirname since the >> > method is a >> > >>>> local >> > >>>> >>>>>> static method and won't >> > >>>> >>>>>> > have its name start spreading, I >> > think it's ok >> > >>>> too. >> > >>>> >>>>>> > >> > >>>> >>>>>> > For the naming of the local >> > variable, the idea >> > >>>> >>>>>> initially was to use the >> > >>>> >>>>>> > same name as the local variable >> > for JNIEnv >> > >>>> already >> > >>>> >>>>>> used to reduce the >> > >>>> >>>>>> > code change. Since I'm now adding >> > the line >> > >>>> macro >> > >>>> >>>>>> at the end anyway, this >> > >>>> >>>>>> > does not matter anymore so I >> > converged all >> > >>>> local >> > >>>> >>>>>> variables to "jni". >> > >>>> >>>>>> > >> > >>>> >>>>>> > So, without further ado, here is >> > the new >> > >>>> version: >> > >>>> >>>>>> > Webrev: >> > >>>> >>>>>> >> http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.03/ >> > >>>> >>>>>> >> > >> > >>>> >>>>>> > Bug: >> > >>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213501 >> > >>>> >>>>>> > >> > >>>> >>>>>> > This passes the various tests >> > changed by the >> > >>>> >>>>>> webrev on my dev machine. >> > >>>> >>>>>> > >> > >>>> >>>>>> > Let me know what you think, >> > >>>> >>>>>> > Jc >> > >>>> >>>>>> > >> > >>>> >>>>>> > On Mon, Dec 3, 2018 at 8:40 PM >> > >>>> >>>>>> serguei.spitsyn at oracle.com >> > >> > >>>> >>>>>> > > > >> > >>>> >>>>>> > >> > > serguei.spitsyn at oracle.com> >> > >>>> >>>>>> > > >> >> > >>>> >>>>>> > > >> > >>>> >>>>>> > > > >> > >>>> >>>>>> > >> > > serguei.spitsyn at oracle.com> >> > >>>> >>>>>> > > >>> wrote: >> > >>>> >>>>>> > >> > >>>> >>>>>> > On 12/3/18 20:15, Chris >> > Plummer wrote: >> > >>>> >>>>>> > > Hi JC, >> > >>>> >>>>>> > > >> > >>>> >>>>>> > > Overall it looks good. A >> > few naming nits >> > >>>> >>>>>> thought: >> > >>>> >>>>>> > > >> > >>>> >>>>>> > > In bi01t001.cpp, why have >> > you declared >> > >>>> the >> > >>>> >>>>>> > ExceptionCheckingJniEnvPtr >> > >>>> >>>>>> > > using jni_env(jni). >> > Elsewhere you use >> > >>>> >>>>>> jni(jni_env) and rename the >> > >>>> >>>>>> > > method argument passed in >> > from jni to >> > >>>> >>>>>> jni_env. >> > >>>> >>>>>> > > >> > >>>> >>>>>> > > Related to this, I also >> > noticed in some >> > >>>> >>>>>> files that already are using >> > >>>> >>>>>> > > >> > ExceptionCheckingJniEnvPtr, such as >> > >>>> >>>>>> CharArrayCriticalLocker.cpp, you >> > >>>> >>>>>> > > delcared it as >> > env(jni_env). So that >> > >>>> means >> > >>>> >>>>>> there are 3 different >> > >>>> >>>>>> > names >> > >>>> >>>>>> > > you have used for the >> > >>>> >>>>>> ExceptionCheckingJniEnvPtr local >> > variable. >> > >>>> >>>>>> > They >> > >>>> >>>>>> > > should be consistent. >> > >>>> >>>>>> > > >> > >>>> >>>>>> > > Also, can you rename >> > get_basename() to >> > >>>> >>>>>> get_dirname()? I know Serguei >> > >>>> >>>>>> > > suggested get_basename() a >> > while back, >> > >>>> but >> > >>>> >>>>>> unless "basename" is >> > >>>> >>>>>> > > commonly used for this >> > purpose, I think >> > >>>> >>>>>> "dirname" is more self >> > >>>> >>>>>> > > explanatory. >> > >>>> >>>>>> > >> > >>>> >>>>>> > In general, I'm Okay with >> > get_dirname(). >> > >>>> >>>>>> > Just to mention dirname can >> > be both short >> > >>>> or >> > >>>> >>>>>> full, so it is a little >> > >>>> >>>>>> > confusing as well. >> > >>>> >>>>>> > It is the reason why the >> > get_basename() was >> > >>>> >>>>>> suggested. >> > >>>> >>>>>> > However, I do not insist on >> > get_basename() >> > >>>> nor >> > >>>> >>>>>> get_full_dirname(). :) >> > >>>> >>>>>> > >> > >>>> >>>>>> > Thanks, >> > >>>> >>>>>> > Serguei >> > >>>> >>>>>> > >> > >>>> >>>>>> > >> > >>>> >>>>>> > > thanks, >> > >>>> >>>>>> > > >> > >>>> >>>>>> > > Chris >> > >>>> >>>>>> > > >> > >>>> >>>>>> > > On 12/2/18 10:29 PM, David >> > Holmes wrote: >> > >>>> >>>>>> > >> Hi Jc, >> > >>>> >>>>>> > >> >> > >>>> >>>>>> > >> I've been lurking on this >> > one and have >> > >>>> had >> > >>>> >>>>>> a look through. I'm okay >> > >>>> >>>>>> > >> with the FatalError >> > approach for the >> > >>>> tests >> > >>>> >>>>>> - we don't expect >> > >>>> >>>>>> > anything >> > >>>> >>>>>> > >> to go wrong in a well >> > written test in a >> > >>>> >>>>>> correctly functioning VM. >> > >>>> >>>>>> > >> >> > >>>> >>>>>> > >> Thanks, >> > >>>> >>>>>> > >> David >> > >>>> >>>>>> > >> >> > >>>> >>>>>> > >> >> > >>>> >>>>>> > >> >> > >>>> >>>>>> > >> On 3/12/2018 3:24 pm, JC >> > Beyler wrote: >> > >>>> >>>>>> > >>> Hi all, >> > >>>> >>>>>> > >>> >> > >>>> >>>>>> > >>> Would someone on the GC >> > or runtime >> > >>>> team >> > >>>> >>>>>> be motivated to give >> > >>>> >>>>>> > this a >> > >>>> >>>>>> > >>> review? :) >> > >>>> >>>>>> > >>> >> > >>>> >>>>>> > >>> It would be much >> > appreciated! >> > >>>> >>>>>> > >>> >> > >>>> >>>>>> > >>> Webrev: >> > >>>> >>>>>> >> http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.02/ >> > >>>> >>>>>> >> > >> > >>>> >>>>>> > >>> Bug: >> > >>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213501 >> > >>>> >>>>>> > >>> >> > >>>> >>>>>> > >>> Thanks for your help, >> > >>>> >>>>>> > >>> Jc >> > >>>> >>>>>> > >>> >> > >>>> >>>>>> > >>> On Tue, Nov 27, 2018 at >> > 4:36 PM JC >> > >>>> Beyler >> > >>>> >>>>>> > > > > >> > >>>> > >> > >>>> >>>>>> > > > >> > >>>> >>>>>> > > >> >> > >>>> >>>>>> > >>> >> > >> > >>>> >>>>>> > > > >> > >>>> >>>>>> > > >> > >>>> >>>>>> > > >>>> wrote: >> > >>>> >>>>>> > >>> >> > >>>> >>>>>> > >>> Hi Chris, >> > >>>> >>>>>> > >>> >> > >>>> >>>>>> > >>> Yes I was waiting >> > for another >> > >>>> review >> > >>>> >>>>>> since you had explicitly >> > >>>> >>>>>> > >>> asked :) >> > >>>> >>>>>> > >>> >> > >>>> >>>>>> > >>> And sounds good that >> > when someone >> > >>>> >>>>>> from GC or runtime gives a >> > >>>> >>>>>> > >>> review, >> > >>>> >>>>>> > >>> I'll wait for your >> > full review on >> > >>>> the >> > >>>> >>>>>> webrev.02! >> > >>>> >>>>>> > >>> >> > >>>> >>>>>> > >>> Thanks again for >> > your help, >> > >>>> >>>>>> > >>> Jc >> > >>>> >>>>>> > >>> >> > >>>> >>>>>> > >>> >> > >>>> >>>>>> > >>> On Tue, Nov 27, 2018 >> > at 12:48 PM >> > >>>> >>>>>> Chris Plummer >> > >>>> >>>>>> > >>> >> > >> > >>>> >>>>>> > > > >> > >>>> >>>>>> > > >> > >>>> >>>>>> > > >> >> > >>>> >>>>>> > > chris.plummer at oracle.com >> > >> > >>>> >>>>>> > > > >> > >>>> >>>>>> > > >> > >>>> >>>>>> > > >>>> >> > >>>> >>>>>> > wrote: >> > >>>> >>>>>> > >>> >> > >>>> >>>>>> > >>> Hi JC, >> > >>>> >>>>>> > >>> >> > >>>> >>>>>> > >>> I think it would >> > be good to >> > >>>> get a >> > >>>> >>>>>> review from the gc or >> > >>>> >>>>>> > runtime >> > >>>> >>>>>> > >>> teams, since >> > this also affects >> > >>>> >>>>>> their tests. >> > >>>> >>>>>> > >>> >> > >>>> >>>>>> > >>> Also, once we >> > are settled on >> > >>>> this >> > >>>> >>>>>> FatalError approach, >> > >>>> >>>>>> > I still >> > >>>> >>>>>> > >>> need to give >> > your webrev-02 a >> > >>>> >>>>>> full review. I only >> > >>>> >>>>>> > skimmed over >> > >>>> >>>>>> > >>> parts of it (I >> > did look at all >> > >>>> >>>>>> the changes in webrevo-01). >> > >>>> >>>>>> > >>> >> > >>>> >>>>>> > >>> thanks, >> > >>>> >>>>>> > >>> >> > >>>> >>>>>> > >>> Chris >> > >>>> >>>>>> > >>> >> > >>>> >>>>>> > >>> On 11/27/18 >> 8:58 AM, >> > >>>> >>>>>> serguei.spitsyn at oracle.com >> > >> > >>>> >>>>>> > > > >> > >>>> >>>>>> > >> > > serguei.spitsyn at oracle.com> >> > >>>> >>>>>> > > >> >> > >>>> >>>>>> > >>> >> > > serguei.spitsyn at oracle.com> >> > >>>> >>>>>> > > > >> > >>>> >>>>>> > >> > > serguei.spitsyn at oracle.com> >> > >>>> >>>>>> > > >>> wrote: >> > >>>> >>>>>> > >>>> Hi Jc, >> > >>>> >>>>>> > >>>> >> > >>>> >>>>>> > >>>> I've already >> > reviewed this >> > >>>> too. >> > >>>> >>>>>> > >>>> >> > >>>> >>>>>> > >>>> Thanks, >> > >>>> >>>>>> > >>>> Serguei >> > >>>> >>>>>> > >>>> >> > >>>> >>>>>> > >>>> >> > >>>> >>>>>> > >>>> On 11/27/18 >> > 06:56, JC Beyler >> > >>>> >>>>>> wrote: >> > >>>> >>>>>> > >>>>> Thanks Chris, >> > >>>> >>>>>> > >>>>> >> > >>>> >>>>>> > >>>>> Anybody else motivated >> > to look at >> > >>>> this >> > >>>> >>>>>> and review it? :) >> > >>>> >>>>>> > >>>>> Jc >> > >>>> >>>>>> > >>>>> >> > >>>> >>>>>> > >>>>> On Mon, Nov >> > 26, 2018 at >> > >>>> 1:26 PM >> > >>>> >>>>>> Chris Plummer >> > >>>> >>>>>> > >>>>> >> > >> > >>>> >>>>>> > > > >> > >>>> >>>>>> > > chris.plummer at oracle.com >> > >> > >>>> >>>>>> > > >> >> > >>>> >>>>>> > > >> > >>>> >>>>>> > > > >> > >>>> >>>>>> > > chris.plummer at oracle.com >> > >> > >>>> >>>>>> > > >>>> >> > >>>> >>>>>> > >>>>> wrote: >> > >>>> >>>>>> > >>>>> >> > >>>> >>>>>> > >>>>> Hi JC, >> > >>>> >>>>>> > >>>>> >> > >>>> >>>>>> > >>>>> I'm ok with the >> > FatalError approach, >> > >>>> >>>>>> but would >> > >>>> >>>>>> > like to >> > >>>> >>>>>> > >>>>> hear opinions from >> > others also. >> > >>>> >>>>>> > >>>>> >> > >>>> >>>>>> > >>>>> thanks, >> > >>>> >>>>>> > >>>>> >> > >>>> >>>>>> > >>>>> Chris >> > >>>> >>>>>> > >>>>> >> > >>>> >>>>>> > >>>>> On 11/21/18 8:19 AM, >> > JC Beyler >> > >>>> wrote: >> > >>>> >>>>>> > >>>>>> Hi Chris, >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> Thanks >> > for taking the >> > >>>> time >> > >>>> >>>>>> to look at it and yes you >> > >>>> >>>>>> > >>>>>> have >> > raised exactly why >> > >>>> >>>>>> the webrev is between two >> > >>>> >>>>>> > >>>>>> worlds: >> > in cases where >> > >>>> a >> > >>>> >>>>>> fatal error on failure is >> > >>>> >>>>>> > >>>>>> wanted, >> > should we >> > >>>> simplify >> > >>>> >>>>>> the code to remove >> > >>>> >>>>>> > the return >> > >>>> >>>>>> > >>>>>> tests >> > since we do them >> > >>>> >>>>>> internally? Now that I've >> > >>>> >>>>>> > looked >> > >>>> >>>>>> > >>>>>> around >> > for non-fatal >> > >>>> >>>>>> cases, I think the answer >> > >>>> >>>>>> > is yes, >> > >>>> >>>>>> > >>>>>> it >> > simplifies the code >> > >>>> >>>>>> while maintaining the checks. >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> I looked >> > a bit and it >> > >>>> >>>>>> seems that I can't find >> > >>>> >>>>>> > easily a >> > >>>> >>>>>> > >>>>>> case >> > where the test >> > >>>> >>>>>> accepts a JNI failure to >> > >>>> >>>>>> > then move >> > >>>> >>>>>> > >>>>>> on. >> > Therefore, perhaps, >> > >>>> >>>>>> for now, the fail with a >> > >>>> >>>>>> > Fatal >> > >>>> >>>>>> > >>>>>> is enough >> > and we can >> > >>>> work >> > >>>> >>>>>> on the tests to clean >> > >>>> >>>>>> > them up? >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> That >> > means that this is >> > >>>> >>>>>> the new webrev with only >> > >>>> >>>>>> > Fatal >> > >>>> >>>>>> > >>>>>> and >> > cleans up the >> > >>>> tests so >> > >>>> >>>>>> that it is no longer in >> > >>>> >>>>>> > >>>>>> between >> > two worlds: >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> Webrev: >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> >> http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.02/ >> > >>>> >>>>>> >> > >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> >> > >> > >>>> >>>>>> > >>>>>> Bug: >> > >>>> >>>>>> > >> > >>>> https://bugs.openjdk.java.net/browse/JDK-8213501 >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> (This >> > passes testing >> > >>>> on my >> > >>>> >>>>>> dev machine for all the >> > >>>> >>>>>> > >>>>>> modified >> > tests) >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> with the >> > example you >> > >>>> >>>>>> provided, it now looks like: >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> >> > >>>> >> > >> http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp.frames.html >> > >>>> >>>>>> >> > >>>> >>>>>> < >> > >>>> >> > >> http://cr.openjdk.java.net/%7Ejcbeyler/8213501/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp.frames.html >> > >> > >>>> >> > >>>> >>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> < >> > >>>> >> > >> http://cr.openjdk.java.net/%7Ejcbeyler/8213501/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp.frames.html >> > >> > >>>> >> > >>>> >>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> Where it >> > does, to me at >> > >>>> >>>>>> least, seem cleaner and less >> > >>>> >>>>>> > >>>>>> "noisy". >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> Let me >> > know what you >> > >>>> think, >> > >>>> >>>>>> > >>>>>> Jc >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> On Tue, >> > Nov 20, 2018 at >> > >>>> >>>>>> 9:33 PM Chris Plummer >> > >>>> >>>>>> > >>>>>> < >> > >>>> chris.plummer at oracle.com > > >> > >>>> >>>>>> > > > >> > >>>> >>>>>> > > chris.plummer at oracle.com >> > >> > >>>> >>>>>> > > >> >> > >>>> >>>>>> > >>>>>> >> > >> > >>>> >>>>>> > > > >> > >>>> >>>>>> > > chris.plummer at oracle.com >> > >> > >>>> >>>>>> > > >>>> wrote: >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> Hi >> JC, >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> Sorry >> > about the >> > >>>> delay. >> > >>>> >>>>>> I had to go back an >> > >>>> >>>>>> > look at >> > >>>> >>>>>> > >>>>>> the >> > initial 8210842 >> > >>>> >>>>>> webrev and RFR thread to see >> > >>>> >>>>>> > >>>>>> what >> > this was >> > >>>> >>>>>> initially all about. >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> In >> > general the >> > >>>> changes >> > >>>> >>>>>> look good. >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> I >> > don't have a good >> > >>>> >>>>>> answer to your >> > >>>> >>>>>> > >>>>>> FatalError/NonFatalError >> > question. It >> > >>>> makes >> > >>>> >>>>>> > the code >> > >>>> >>>>>> > >>>>>> a lot >> > cleaner to >> > >>>> use >> > >>>> >>>>>> FatalError, but then it >> > >>>> >>>>>> > is a >> > >>>> >>>>>> > >>>>>> >> > behavior change, >> > >>>> and >> > >>>> >>>>>> you also need to deal with >> > >>>> >>>>>> > >>>>>> tests >> > that >> > >>>> >>>>>> intentionally induce errors (do >> > >>>> >>>>>> > you have >> > >>>> >>>>>> > >>>>>> an >> > example of >> > >>>> that). >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> In >> > any case, right >> > >>>> now >> > >>>> >>>>>> your webrev seems to be >> > >>>> >>>>>> > >>>>>> >> > between two worlds. >> > >>>> >>>>>> You are producing >> > >>>> >>>>>> > FatalError, >> > >>>> >>>>>> > >>>>>> but >> > still checking >> > >>>> >>>>>> results. Here's a good >> > >>>> >>>>>> > example: >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> >> > >>>> >> > >> http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp.frames.html >> > >>>> >>>>>> >> > >>>> >>>>>> < >> > >>>> >> > >> http://cr.openjdk.java.net/%7Ejcbeyler/8213501/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp.frames.html >> > >> > >>>> >> > >>>> >>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> < >> > >>>> >> > >> http://cr.openjdk.java.net/%7Ejcbeyler/8213501/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp.frames.html >> > >> > >>>> >> > >>>> >>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> I'm >> > not sure if >> > >>>> this >> > >>>> >>>>>> is just a temporary >> > >>>> >>>>>> > state until >> > >>>> >>>>>> > >>>>>> it >> > was decided >> > >>>> which >> > >>>> >>>>>> approach to take. >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> >> thanks, >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> Chris >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> On >> > 11/20/18 2:14 >> > >>>> PM, >> > >>>> >>>>>> JC Beyler wrote: >> > >>>> >>>>>> > >>>>>>> Hi >> all, >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> >> > Chris thought it >> > >>>> made >> > >>>> >>>>>> sense to have more >> > >>>> >>>>>> > eyes on >> > >>>> >>>>>> > >>>>>>> this >> > change than >> > >>>> just >> > >>>> >>>>>> serviceability as it will >> > >>>> >>>>>> > >>>>>>> >> > modify to tests >> > >>>> that >> > >>>> >>>>>> are not only >> > >>>> >>>>>> > serviceability >> > >>>> >>>>>> > >>>>>>> >> > tests so I've >> > >>>> moved >> > >>>> >>>>>> this to conversation >> > >>>> >>>>>> > here :) >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> For >> > convenience, >> > >>>> I've >> > >>>> >>>>>> copy-pasted the >> > >>>> >>>>>> > initial RFR: >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> >> > Could I have a >> > >>>> review >> > >>>> >>>>>> for the extension and >> > >>>> >>>>>> > usage >> > >>>> >>>>>> > >>>>>>> of >> the >> > >>>> >>>>>> ExceptionJniWrapper. This adds >> > lines and >> > >>>> >>>>>> > >>>>>>> >> > filenames to the >> > >>>> end >> > >>>> >>>>>> of the wrapper JNI >> > >>>> >>>>>> > methods, >> > >>>> >>>>>> > >>>>>>> adds >> > tracing, and >> > >>>> >>>>>> throws an error if need >> > >>>> >>>>>> > be. I've >> > >>>> >>>>>> > >>>>>>> >> > ported the gc/lock >> > >>>> >>>>>> files to use the new >> > >>>> >>>>>> > >>>>>>> >> > TRACE_JNI_CALL >> > >>>> add-on >> > >>>> >>>>>> and I've ported a few >> > >>>> >>>>>> > of the >> > >>>> >>>>>> > >>>>>>> >> > tests that were >> > >>>> >>>>>> already changed for the >> > >>>> >>>>>> > assignment >> > >>>> >>>>>> > >>>>>>> >> > webrev for >> > >>>> >>>>>> JDK-8212884. >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> >> Webrev: >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> >> http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.01 >> > >>>> >>>>>> >> > >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> >> > >> > >>>> >>>>>> > >>>>>>> Bug: >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213501 >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> For >> > illustration, >> > >>>> if >> > >>>> >>>>>> I force an error to the >> > >>>> >>>>>> > >>>>>>> >> > AP04/ap04t03 test >> > >>>> and >> > >>>> >>>>>> set the verbosity on, >> > >>>> >>>>>> > I get >> > >>>> >>>>>> > >>>>>>> >> > something like: >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> >> >> > Calling JNI >> > >>>> method >> > >>>> >>>>>> FindClass from >> > >>>> >>>>>> > >>>>>>> ap04t003.cpp:343 >> > >>>> >>>>>> > >>>>>>> >> >> > Calling with >> > >>>> these >> > >>>> >>>>>> parameter(s): >> > >>>> >>>>>> > >>>>>>> java/lang/Threadd >> > >>>> >>>>>> > >>>>>>> Wait >> > for thread >> > >>>> to >> > >>>> >>>>>> finish >> > >>>> >>>>>> > >>>>>>> << >> > Called JNI >> > >>>> method >> > >>>> >>>>>> FindClass from >> > >>>> >>>>>> > >>>>>>> ap04t003.cpp:343 >> > >>>> >>>>>> > >>>>>>> >> > Exception in >> > >>>> thread >> > >>>> >>>>>> "Thread-0" >> > >>>> >>>>>> > >>>>>>> >> > java.lang.NoClassDefFoundError: >> > >>>> >>>>>> > java/lang/Threadd >> > >>>> >>>>>> > >>>>>>> >> > at >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> >> > >>>> >> > >> nsk.jvmti.scenarios.allocation.AP04.ap04t003.runIterateOverHeap(Native >> > >>>> >>>>>> >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> >> Method) >> > >>>> >>>>>> > >>>>>>> >> > at >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> >> > >>>> >> > >> nsk.jvmti.scenarios.allocation.AP04.ap04t003HeapIterator.runIteration(ap04t003.java:140) >> > >>>> >> > >>>> >>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> >> > at >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> >> > >>>> >> > >> nsk.jvmti.scenarios.allocation.AP04.ap04t003Thread.run(ap04t003.java:201) >> > >>>> >>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> >> > Caused by: >> > >>>> >>>>>> java.lang.ClassNotFoundException: >> > >>>> >>>>>> > >>>>>>> >> > java.lang.Threadd >> > >>>> >>>>>> > >>>>>>> >> > at >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> >> > >>>> >> > >> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) >> > >>>> >> > >>>> >>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> >> > at >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> >> > >>>> >> > >> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) >> > >>>> >> > >>>> >>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> >> > at >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> >> > java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) >> > >>>> >>>>>> > >>>>>>> >> > ... 3 more >> > >>>> >>>>>> > >>>>>>> >> > FATAL ERROR in >> > >>>> native >> > >>>> >>>>>> method: JNI method >> > >>>> >>>>>> > FindClass >> > >>>> >>>>>> > >>>>>>> : >> > internal error >> > >>>> from >> > >>>> >>>>>> ap04t003.cpp:343 >> > >>>> >>>>>> > >>>>>>> >> > at >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> >> > >>>> >> > >> nsk.jvmti.scenarios.allocation.AP04.ap04t003.runIterateOverHeap(Native >> > >>>> >>>>>> >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> >> Method) >> > >>>> >>>>>> > >>>>>>> >> > at >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> >> > >>>> >> > >> nsk.jvmti.scenarios.allocation.AP04.ap04t003HeapIterator.runIteration(ap04t003.java:140) >> > >>>> >> > >>>> >>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> >> > at >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> >> > >>>> >> > >> nsk.jvmti.scenarios.allocation.AP04.ap04t003Thread.run(ap04t003.java:201) >> > >>>> >>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> >> > >>>> Questions/comments I >> > >>>> >>>>>> have about this are: >> > >>>> >>>>>> > >>>>>>> - >> > Do we want to >> > >>>> >>>>>> force fatal errors when a JNI >> > >>>> >>>>>> > >>>>>>> call >> > fails in >> > >>>> >>>>>> general? Most of these tests >> > >>>> >>>>>> > do the >> > >>>> >>>>>> > >>>>>>> >> > right thing and >> > >>>> test >> > >>>> >>>>>> the return of the JNI >> > >>>> >>>>>> > calls, >> > >>>> >>>>>> > >>>>>>> for >> > example: >> > >>>> >>>>>> > >>>>>>> >> > thrClass = >> > >>>> >>>>>> > >> jni->FindClass("java/lang/Threadd", >> > >>>> >>>>>> > >>>>>>> >> > TRACE_JNI_CALL); >> > >>>> >>>>>> > >>>>>>> >> > if (thrClass >> > >>>> == >> > >>>> >>>>>> NULL) { >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> but >> > now the >> > >>>> wrapper >> > >>>> >>>>>> actually would do a >> > >>>> >>>>>> > fatal if >> > >>>> >>>>>> > >>>>>>> the >> > FindClass call >> > >>>> >>>>>> would return a nullptr, >> > >>>> >>>>>> > so we >> > >>>> >>>>>> > >>>>>>> >> > could remove that >> > >>>> >>>>>> test altogether. What do you >> > >>>> >>>>>> > >>>>>>> think? >> > >>>> >>>>>> > >>>>>>> >> > - I prefer to >> > >>>> >>>>>> leave them as the tests then >> > >>>> >>>>>> > >>>>>>> >> > become closer to >> > >>>> what >> > >>>> >>>>>> real users would have in >> > >>>> >>>>>> > >>>>>>> >> > their code and is >> > >>>> the >> > >>>> >>>>>> "recommended" way of >> > >>>> >>>>>> > doing it >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> >> - The >> > >>>> alternative >> > >>>> >>>>>> is to use the >> > >>>> >>>>>> > NonFatalError I >> > >>>> >>>>>> > >>>>>>> >> > added which then >> > >>>> just >> > >>>> >>>>>> prints out that something >> > >>>> >>>>>> > >>>>>>> went >> > wrong, >> > >>>> letting >> > >>>> >>>>>> the test continue. Question >> > >>>> >>>>>> > >>>>>>> will >> > be what >> > >>>> should >> > >>>> >>>>>> be the default? The >> > >>>> >>>>>> > fatal or >> > >>>> >>>>>> > >>>>>>> the >> > non-fatal >> > >>>> error >> > >>>> >>>>>> handling? >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> On a >> > different >> > >>>> >>>>>> subject: >> > >>>> >>>>>> > >>>>>>> - >> > On the new >> > >>>> tests, >> > >>>> >>>>>> I've removed the >> > >>>> >>>>>> > >>>>>>> >> > NSK_JNI_VERIFY >> > >>>> since >> > >>>> >>>>>> the JNI wrapper >> > >>>> >>>>>> > handles the >> > >>>> >>>>>> > >>>>>>> >> > tracing and the >> > >>>> >>>>>> verify in almost the same >> > >>>> >>>>>> > way; only >> > >>>> >>>>>> > >>>>>>> >> > difference I can >> > >>>> >>>>>> really tell is that the >> > >>>> >>>>>> > complain >> > >>>> >>>>>> > >>>>>>> >> > method from NSK >> > >>>> has a >> > >>>> >>>>>> max complain before >> > >>>> >>>>>> > stopping >> > >>>> >>>>>> > >>>>>>> to >> > "complain"; I >> > >>>> have >> > >>>> >>>>>> not added that part >> > >>>> >>>>>> > of the >> > >>>> >>>>>> > >>>>>>> code >> > in this >> > >>>> webrev >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> Once >> > we decide on >> > >>>> >>>>>> these, I can continue on the >> > >>>> >>>>>> > >>>>>>> >> > files from >> > >>>> >>>>>> JDK-8212884 and then do both the >> > >>>> >>>>>> > >>>>>>> >> > assignment in an >> > >>>> if >> > >>>> >>>>>> extraction followed-by this >> > >>>> >>>>>> > >>>>>>> type >> > of webrev in >> > >>>> an >> > >>>> >>>>>> easier fashion. >> > >>>> >>>>>> > Depending on >> > >>>> >>>>>> > >>>>>>> >> > decisions here, >> > >>>> >>>>>> NSK*VERIFY can be deprecated as >> > >>>> >>>>>> > >>>>>>> well >> > as we go >> > >>>> forward. >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> >> Thanks! >> > >>>> >>>>>> > >>>>>>> Jc >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> On >> > Mon, Nov 19, >> > >>>> 2018 >> > >>>> >>>>>> at 11:34 AM Chris Plummer >> > >>>> >>>>>> > >>>>>>> < >> > >>>> chris.plummer at oracle.com > > >> > >>>> >>>>>> > > > >> > >>>> >>>>>> > > chris.plummer at oracle.com >> > >> > >>>> >>>>>> > > >> >> > >>>> >>>>>> > >>>>>>> >> > >> > >>>> >>>>>> > > > >> > >>>> >>>>>> > > chris.plummer at oracle.com >> > >> > >>>> >>>>>> > > >>>> wrote: >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> >> > On 11/19/18 >> > >>>> 10:07 >> > >>>> >>>>>> AM, JC Beyler wrote: >> > >>>> >>>>>> > >>>>>>>> >> > Hi all, >> > >>>> >>>>>> > >>>>>>>> >> > >>>> >>>>>> > >>>>>>>> >> > @David/Chris: >> > >>>> >>>>>> should I then push this >> > >>>> >>>>>> > RFR to >> > >>>> >>>>>> > >>>>>>>> >> > the hotspot >> > >>>> >>>>>> mailing or the runtime >> > >>>> >>>>>> > one? For >> > >>>> >>>>>> > >>>>>>>> >> > what it's >> > >>>> worth, >> > >>>> >>>>>> a lot of the tests >> > >>>> >>>>>> > under the >> > >>>> >>>>>> > >>>>>>>> >> > vmTestbase >> > >>>> are >> > >>>> >>>>>> jvmti so the review also >> > >>>> >>>>>> > >>>>>>>> >> > affects >> > >>>> >>>>>> serviceability; it just turns >> > >>>> >>>>>> > out I >> > >>>> >>>>>> > >>>>>>>> >> > started with >> > >>>> the >> > >>>> >>>>>> GC originally and >> > >>>> >>>>>> > then hit >> > >>>> >>>>>> > >>>>>>>> >> > some other >> > >>>> tests >> > >>>> >>>>>> I had touched via the >> > >>>> >>>>>> > >>>>>>>> >> > assignment >> > >>>> >>>>>> extraction. >> > >>>> >>>>>> > >>>>>>> >> > I think >> > >>>> hotspot >> > >>>> >>>>>> would be best. >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> >> > Chris >> > >>>> >>>>>> > >>>>>>>> >> > >>>> >>>>>> > >>>>>>>> >> > @Serguei: >> > >>>> Done >> > >>>> >>>>>> for the method >> > >>>> >>>>>> > renaming, for >> > >>>> >>>>>> > >>>>>>>> >> > the indent, >> > >>>> are >> > >>>> >>>>>> you talking about >> > >>>> >>>>>> > going from >> > >>>> >>>>>> > >>>>>>>> >> > the 8-indent >> > >>>> to >> > >>>> >>>>>> 4-indent? If so, would >> > >>>> >>>>>> > it not >> > >>>> >>>>>> > >>>>>>>> >> > just be >> > >>>> better >> > >>>> >>>>>> to do a new JBS bug and >> > >>>> >>>>>> > do the >> > >>>> >>>>>> > >>>>>>>> >> > whole files >> > >>>> in >> > >>>> >>>>>> one go? I ask because >> > >>>> >>>>>> > >>>>>>>> >> > otherwise, it >> > >>>> >>>>>> will look a bit weird to >> > >>>> >>>>>> > have >> > >>>> >>>>>> > >>>>>>>> >> > parts of the >> > >>>> >>>>>> file as 8-indent and others >> > >>>> >>>>>> > >>>>>>>> 4-indent? >> > >>>> >>>>>> > >>>>>>>> >> > >>>> >>>>>> > >>>>>>>> >> > Thanks for >> > >>>> >>>>>> looking at it! >> > >>>> >>>>>> > >>>>>>>> >> Jc >> > >>>> >>>>>> > >>>>>>>> >> > >>>> >>>>>> > >>>>>>>> >> > On Mon, Nov >> > >>>> 19, >> > >>>> >>>>>> 2018 at 1:25 AM >> > >>>> >>>>>> > >>>>>>>> >> > serguei.spitsyn at oracle.com >> > >>>> >>>>>> > > > >> > >>>> >>>>>> > > >> > >>>> >>>>>> > > >> >> > >>>> >>>>>> > >>>>>>>> > > >>>> serguei.spitsyn at oracle.com > serguei.spitsyn at oracle.com> >> > >>>> >>>>>> > > > >> > >>>> >>>>>> > >> > > serguei.spitsyn at oracle.com> >> > >>>> >>>>>> > > >>> >> > >>>> >>>>>> > >>>>>>>> >> > >> > >>>> >>>>>> > > > >> > >>>> >>>>>> > >> > > serguei.spitsyn at oracle.com> >> > >>>> >>>>>> > > >> >> > >>>> >>>>>> > >>>>>>>> > > >>>> serguei.spitsyn at oracle.com > serguei.spitsyn at oracle.com> >> > >>>> >>>>>> > > > >> > >>>> >>>>>> > >> > > serguei.spitsyn at oracle.com> >> > >>>> >>>>>> > > >>>> wrote: >> > >>>> >>>>>> > >>>>>>>> >> > >>>> >>>>>> > >>>>>>>> >> > Hi Jc, >> > >>>> >>>>>> > >>>>>>>> >> > >>>> >>>>>> > >>>>>>>> >> > We have >> > >>>> to >> > >>>> >>>>>> start this review >> > >>>> >>>>>> > anyway. :) >> > >>>> >>>>>> > >>>>>>>> >> > It looks >> > >>>> >>>>>> good to me in general. >> > >>>> >>>>>> > >>>>>>>> >> > Thank you >> > >>>> >>>>>> for your consistency in this >> > >>>> >>>>>> > >>>>>>>> >> > >>>> refactoring! >> > >>>> >>>>>> > >>>>>>>> >> > >>>> >>>>>> > >>>>>>>> >> > Some >> > >>>> minor >> > >>>> >>>>>> comments. >> > >>>> >>>>>> > >>>>>>>> >> > >>>> >>>>>> > >>>>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> >> > >>>> >> > >> http://cr.openjdk.java.net/%7Ejcbeyler/8213501/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.cpp.udiff.html >> > >>>> >>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> > >>>>>>>> >> > >>>> >>>>>> > >>>>>>>> >> > +static >> > >>>> >>>>>> const char* >> > >>>> >>>>>> > remove_folders(const >> > >>>> >>>>>> > >>>>>>>> >> > char* >> > >>>> >>>>>> fullname) { I'd suggest to >> > >>>> >>>>>> > rename >> > >>>> >>>>>> > >>>>>>>> >> > the >> > >>>> function >> > >>>> >>>>>> name to something >> > >>>> >>>>>> > traditional >> > >>>> >>>>>> > >>>>>>>> >> > like >> > >>>> >>>>>> get_basename. Otherwise, it >> > >>>> >>>>>> > sounds >> > >>>> >>>>>> > >>>>>>>> >> > like this >> > >>>> >>>>>> function has to really >> > >>>> >>>>>> > remove >> > >>>> >>>>>> > >>>>>>>> >> > folders. >> > >>>> :) >> > >>>> >>>>>> Also, all *Locker.cpp have >> > >>>> >>>>>> > >>>>>>>> >> > wrong >> > >>>> indent >> > >>>> >>>>>> in the bodies of if >> > >>>> >>>>>> > and while >> > >>>> >>>>>> > >>>>>>>> >> > >>>> statements. >> > >>>> >>>>>> Could this be fixed >> > >>>> >>>>>> > with the >> > >>>> >>>>>> > >>>>>>>> >> > >>>> refactoring? >> > >>>> >>>>>> I did not look on how >> > >>>> >>>>>> > this >> > >>>> >>>>>> > >>>>>>>> >> > impacts >> > >>>> the >> > >>>> >>>>>> tests other than >> > >>>> >>>>>> > >>>>>>>> >> > serviceability. >> > >>>> Thanks, >> > >>>> >>>>>> Serguei >> > >>>> >>>>>> > >>>>>>>> >> > >>>> >>>>>> > >>>>>>>> >> > >>>> >>>>>> > >>>>>>>> >> > On >> > >>>> 11/16/18 >> > >>>> >>>>>> 19:43, JC Beyler wrote: >> > >>>> >>>>>> > >>>>>>>>> >> > Hi all, >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> > Anybody >> > >>>> >>>>>> motivated to review this? :) >> > >>>> >>>>>> > >>>>>>>>> >> Jc >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> > On Wed, Nov >> > >>>> 7, >> > >>>> >>>>>> 2018 at 9:53 PM JC >> > >>>> >>>>>> > Beyler >> > >>>> >>>>>> > >>>>>>>>> >> > >> > >>>> >>>>>> > > > >> > >>>> >>>>>> > > > >> > >>>> >>>>>> > > >> >> > >>>> >>>>>> > >>>>>>>>> >> > >> > >>>> >>>>>> > > > >> > >>>> >>>>>> > > > >> > >>>> >>>>>> > > >>>> wrote: >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> > Hi all, >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> > Could I >> > >>>> have >> > >>>> >>>>>> a review for the >> > >>>> >>>>>> > >>>>>>>>> >> > extension >> > >>>> >>>>>> and usage of the >> > >>>> >>>>>> > >>>>>>>>> ExceptionJniWrapper. >> This >> > >>>> >>>>>> > adds lines >> > >>>> >>>>>> > >>>>>>>>> >> > and >> > >>>> >>>>>> filenames to the end of the >> > >>>> >>>>>> > >>>>>>>>> >> > wrapper >> > >>>> JNI >> > >>>> >>>>>> methods, adds >> > >>>> >>>>>> > tracing, >> > >>>> >>>>>> > >>>>>>>>> >> > and >> > >>>> throws >> > >>>> >>>>>> an error if need >> > >>>> >>>>>> > be. I've >> > >>>> >>>>>> > >>>>>>>>> >> > ported >> > >>>> the >> > >>>> >>>>>> gc/lock files to >> > >>>> >>>>>> > use the >> > >>>> >>>>>> > >>>>>>>>> >> > new >> > >>>> >>>>>> TRACE_JNI_CALL add-on and >> > >>>> >>>>>> > I've >> > >>>> >>>>>> > >>>>>>>>> >> > ported a >> > >>>> few >> > >>>> >>>>>> of the tests >> > >>>> >>>>>> > that were >> > >>>> >>>>>> > >>>>>>>>> >> > already >> > >>>> >>>>>> changed for the >> > >>>> >>>>>> > assignment >> > >>>> >>>>>> > >>>>>>>>> >> > webrev >> > >>>> for >> > >>>> >>>>>> JDK-8212884. >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> > Webrev: >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> >> http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.00/ >> > >>>> >>>>>> >> > >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> >> > >> > >>>> >>>>>> > >>>>>>>>> >> > Bug: >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213501 >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> > For >> > >>>> >>>>>> illustration, if I force >> > >>>> >>>>>> > an error >> > >>>> >>>>>> > >>>>>>>>> >> > to the >> > >>>> >>>>>> AP04/ap04t03 test and >> > >>>> >>>>>> > set the >> > >>>> >>>>>> > >>>>>>>>> >> > verbosity >> > >>>> >>>>>> on, I get something >> > >>>> >>>>>> > like: >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> > >> >> > >>>> Calling >> > >>>> >>>>>> JNI method >> > >>>> >>>>>> > FindClass from >> > >>>> >>>>>> > >>>>>>>>> ap04t003.cpp:343 >> > >>>> >>>>>> > >>>>>>>>> >> > >> >> > >>>> Calling >> > >>>> >>>>>> with these >> > >>>> >>>>>> > parameter(s): >> > >>>> >>>>>> > >>>>>>>>> java/lang/Threadd >> > >>>> >>>>>> > >>>>>>>>> >> > Wait for >> > >>>> >>>>>> thread to finish >> > >>>> >>>>>> > >>>>>>>>> >> > << Called >> > >>>> >>>>>> JNI method >> > >>>> >>>>>> > FindClass from >> > >>>> >>>>>> > >>>>>>>>> ap04t003.cpp:343 >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> Exception in >> > >>>> >>>>>> thread "Thread-0" >> > >>>> >>>>>> > >>>>>>>>> >> > java.lang.NoClassDefFoundError: >> > >>>> >>>>>> > >>>>>>>>> java/lang/Threadd >> > >>>> >>>>>> > >>>>>>>>> >> > at >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> >> > >>>> >> > >> nsk.jvmti.scenarios.allocation.AP04.ap04t003.runIterateOverHeap(Native >> > >>>> >>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> > Method) >> > >>>> >>>>>> > >>>>>>>>> >> > at >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> >> > >>>> >> > >> nsk.jvmti.scenarios.allocation.AP04.ap04t003HeapIterator.runIteration(ap04t003.java:140) >> > >>>> >> > >>>> >>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> > at >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> >> > >>>> >> > >> nsk.jvmti.scenarios.allocation.AP04.ap04t003Thread.run(ap04t003.java:201) >> > >>>> >>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> > Caused >> > >>>> by: >> > >>>> >>>>>> > >>>>>>>>> >> > java.lang.ClassNotFoundException: >> > >>>> >>>>>> > >>>>>>>>> java.lang.Threadd >> > >>>> >>>>>> > >>>>>>>>> >> > at >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> >> > >>>> >> > >> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) >> > >>>> >> > >>>> >>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> > at >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> >> > >>>> >> > >> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) >> > >>>> >> > >>>> >>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> > at >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> >> > java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) >> > >>>> >>>>>> > >>>>>>>>> >> > ... 3 >> > >>>> more >> > >>>> >>>>>> > >>>>>>>>> >> > FATAL >> > >>>> ERROR >> > >>>> >>>>>> in native method: JNI >> > >>>> >>>>>> > >>>>>>>>> >> > method >> > >>>> >>>>>> FindClass : internal error >> > >>>> >>>>>> > >>>>>>>>> >> > from >> > >>>> >>>>>> ap04t003.cpp:343 >> > >>>> >>>>>> > >>>>>>>>> >> > at >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> >> > >>>> >> > >> nsk.jvmti.scenarios.allocation.AP04.ap04t003.runIterateOverHeap(Native >> > >>>> >>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> > Method) >> > >>>> >>>>>> > >>>>>>>>> >> > at >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> >> > >>>> >> > >> nsk.jvmti.scenarios.allocation.AP04.ap04t003HeapIterator.runIteration(ap04t003.java:140) >> > >>>> >> > >>>> >>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> > at >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> >> > >>>> >> > >> nsk.jvmti.scenarios.allocation.AP04.ap04t003Thread.run(ap04t003.java:201) >> > >>>> >>>>>> >> > >>>> >>>>>> > >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >>>>>>>>> Questions/comments I >> > have about >> > >>>> >>>>>> > >>>>>>>>> this are: >> > >>>> >>>>>> > >>>>>>>>> >> > - Do we >> > >>>> >>>>>> want to force fatal >> > >>>> >>>>>> > errors >> > >>>> >>>>>> > >>>>>>>>> >> > when a >> > >>>> JNI >> > >>>> >>>>>> call fails in general? >> > >>>> >>>>>> > >>>>>>>>> >> > Most of >> > >>>> >>>>>> these tests do the right >> > >>>> >>>>>> > >>>>>>>>> >> > thing and >> > >>>> >>>>>> test the return of >> > >>>> >>>>>> > the JNI >> > >>>> >>>>>> > >>>>>>>>> >> > calls, >> > >>>> for >> > >>>> >>>>>> example: >> > >>>> >>>>>> > >>>>>>>>> >> > thrClass >> > >>>> = >> > >>>> >>>>>> > >>>>>>>>> >> > jni->FindClass("java/lang/Threadd", >> > >>>> >>>>>> > >>>>>>>>> TRACE_JNI_CALL); >> > >>>> >>>>>> > >>>>>>>>> >> > if >> > >>>> >>>>>> (thrClass == NULL) { >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> > but now >> > >>>> the >> > >>>> >>>>>> wrapper actually >> > >>>> >>>>>> > would do >> > >>>> >>>>>> > >>>>>>>>> >> > a fatal >> > >>>> if >> > >>>> >>>>>> the FindClass call >> > >>>> >>>>>> > would >> > >>>> >>>>>> > >>>>>>>>> >> > return a >> > >>>> >>>>>> nullptr, so we could >> > >>>> >>>>>> > remove >> > >>>> >>>>>> > >>>>>>>>> >> > that test >> > >>>> >>>>>> altogether. What do >> > >>>> >>>>>> > you >> > >>>> >>>>>> > >>>>>>>>> think? >> > >>>> >>>>>> > >>>>>>>>> >> > - I >> > >>>> >>>>>> prefer to leave them >> > >>>> >>>>>> > as the >> > >>>> >>>>>> > >>>>>>>>> >> > tests >> > >>>> then >> > >>>> >>>>>> become closer to >> > >>>> >>>>>> > what real >> > >>>> >>>>>> > >>>>>>>>> >> > users >> > >>>> would >> > >>>> >>>>>> have in their >> > >>>> >>>>>> > code and is >> > >>>> >>>>>> > >>>>>>>>> >> > the >> > >>>> >>>>>> "recommended" way of doing it >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> > - The >> > >>>> >>>>>> alternative is to >> > >>>> >>>>>> > use the >> > >>>> >>>>>> > >>>>>>>>> >> > NonFatalError I >> > >>>> added >> > >>>> >>>>>> which >> > >>>> >>>>>> > then just >> > >>>> >>>>>> > >>>>>>>>> >> > prints >> > >>>> out >> > >>>> >>>>>> that something >> > >>>> >>>>>> > went wrong, >> > >>>> >>>>>> > >>>>>>>>> >> > letting >> > >>>> the >> > >>>> >>>>>> test continue. >> > >>>> >>>>>> > Question >> > >>>> >>>>>> > >>>>>>>>> >> > will be >> > >>>> what >> > >>>> >>>>>> should be the >> > >>>> >>>>>> > default? >> > >>>> >>>>>> > >>>>>>>>> >> > The >> > >>>> fatal or >> > >>>> >>>>>> the non-fatal error >> > >>>> >>>>>> > >>>>>>>>> >> > handling? >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> > On a >> > >>>> >>>>>> different subject: >> > >>>> >>>>>> > >>>>>>>>> >> > - On >> > >>>> the >> > >>>> >>>>>> new tests, I've >> > >>>> >>>>>> > removed >> > >>>> >>>>>> > >>>>>>>>> >> > the >> > >>>> >>>>>> NSK_JNI_VERIFY since the JNI >> > >>>> >>>>>> > >>>>>>>>> >> > wrapper >> > >>>> >>>>>> handles the tracing >> > >>>> >>>>>> > and the >> > >>>> >>>>>> > >>>>>>>>> >> > verify in >> > >>>> >>>>>> almost the same >> > >>>> >>>>>> > way; only >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> difference I >> > >>>> >>>>>> can really tell >> > >>>> >>>>>> > is that >> > >>>> >>>>>> > >>>>>>>>> >> > the >> > >>>> complain >> > >>>> >>>>>> method from NSK >> > >>>> >>>>>> > has a >> > >>>> >>>>>> > >>>>>>>>> >> > max >> > >>>> complain >> > >>>> >>>>>> before stopping to >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> "complain"; >> > >>>> >>>>>> I have not added that >> > >>>> >>>>>> > >>>>>>>>> >> > part of >> > >>>> the >> > >>>> >>>>>> code in this webrev >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> > Once we >> > >>>> >>>>>> decide on these, I can >> > >>>> >>>>>> > >>>>>>>>> >> > continue >> > >>>> on >> > >>>> >>>>>> the files from >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> JDK-8212884 >> > >>>> >>>>>> and then do both the >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> assignment >> > >>>> >>>>>> in an if extraction >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> followed-by >> > >>>> >>>>>> this type of >> > >>>> >>>>>> > webrev in an >> > >>>> >>>>>> > >>>>>>>>> >> > easier >> > >>>> >>>>>> fashion. Depending on >> > >>>> >>>>>> > >>>>>>>>> >> > decisions >> > >>>> >>>>>> here, NSK*VERIFY can be >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> deprecated >> > >>>> >>>>>> as well as we go >> > >>>> >>>>>> > forward. >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> > Thank you >> > >>>> >>>>>> for the >> > >>>> >>>>>> > reviews/comments :) >> > >>>> >>>>>> > >>>>>>>>> >> > Jc >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> > >>>> >>>>>> > >>>>>>>>> >> -- >> > >>>> >>>>>> > >>>>>>>>> >> > Thanks, >> > >>>> >>>>>> > >>>>>>>>> >> Jc >> > >>>> >>>>>> > >>>>>>>> >> > >>>> >>>>>> > >>>>>>>> >> > >>>> >>>>>> > >>>>>>>> >> > >>>> >>>>>> > >>>>>>>> >> -- >> > >>>> >>>>>> > >>>>>>>> >> > Thanks, >> > >>>> >>>>>> > >>>>>>>> >> Jc >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> >> > >>>> >>>>>> > >>>>>>> -- >> > >>>> >>>>>> > >>>>>>> >> Thanks, >> > >>>> >>>>>> > >>>>>>> Jc >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> >> > >>>> >>>>>> > >>>>>> -- >> > >>>> >>>>>> > >>>>>> Thanks, >> > >>>> >>>>>> > >>>>>> Jc >> > >>>> >>>>>> > >>>>> >> > >>>> >>>>>> > >>>>> >> > >>>> >>>>>> > >>>>> >> > >>>> >>>>>> > >>>>> >> > >>>> >>>>>> > >>>>> -- >> > >>>> >>>>>> > >>>>> Thanks, >> > >>>> >>>>>> > >>>>> Jc >> > >>>> >>>>>> > >>>> >> > >>>> >>>>>> > >>> >> > >>>> >>>>>> > >>> >> > >>>> >>>>>> > >>> >> > >>>> >>>>>> > >>> -- >> > >>>> >>>>>> > >>> Thanks, >> > >>>> >>>>>> > >>> Jc >> > >>>> >>>>>> > >>> >> > >>>> >>>>>> > >>> >> > >>>> >>>>>> > >>> >> > >>>> >>>>>> > >>> -- >> > >>>> >>>>>> > >>> >> > >>>> >>>>>> > >>> Thanks, >> > >>>> >>>>>> > >>> Jc >> > >>>> >>>>>> > > >> > >>>> >>>>>> > > >> > >>>> >>>>>> > >> > >>>> >>>>>> > >> > >>>> >>>>>> > >> > >>>> >>>>>> > -- >> > >>>> >>>>>> > >> > >>>> >>>>>> > Thanks, >> > >>>> >>>>>> > Jc >> > >>>> >>>>>> >> > >>>> >>>>>> >> > >>>> >>>>>> >> > >>>> >>>>>> -- >> > >>>> >>>>>> Thanks, >> > >>>> >>>>>> Jc >> > >>>> >>>>> >> > >>>> >>>>> >> > >>>> >>>>> >> > >>>> >>>>> -- >> > >>>> >>>>> Thanks, >> > >>>> >>>>> Jc >> > >>>> >>>> >> > >>>> >>>> >> > >>>> >>>> >> > >>>> >>>> -- >> > >>>> >>>> Thanks, >> > >>>> >>>> Jc >> > >>>> >>>> >> > >>>> >>>> >> > >>>> >>>> >> > >>>> >>>> -- >> > >>>> >>>> >> > >>>> >>>> Thanks, >> > >>>> >>>> Jc >> > >>>> >>> >> > >>>> > >> > >>>> >> > >>> >> > >>> >> > >>> -- >> > >>> >> > >>> Thanks, >> > >>> Jc >> > >>> >> > >> >> > >> >> > >> -- >> > >> >> > >> Thanks, >> > >> Jc >> > >> >> > > >> > > >> > > -- >> > > >> > > Thanks, >> > > Jc >> > > >> > >> > >> > -- >> > >> > Thanks, >> > Jc >> > >> > >> > >> > >> > -- >> > >> > Thanks, >> > Jc >> > > > -- > > Thanks, > Jc > -- Thanks, Jc From erik.joelsson at oracle.com Wed Apr 3 13:51:14 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 3 Apr 2019 06:51:14 -0700 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> Message-ID: <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> Hello Kim, On 2019-04-02 16:02, Kim Barrett wrote: >> On Apr 2, 2019, at 5:39 PM, Erik Joelsson wrote: >> >> In JDK-8204551, exceptions.hpp started using THIS_FILE instead of __FILE__ to generate exception messages. This is causing the precompiled header to no longer provide any benefit on Linux/GCC. The problem is that the THIS_FILE macro is provided on the command line and is different for each compile unit. Because of this, it seems GCC invalidates the precompiled header completely. (On other platforms, the value of THIS_FILE is instead ignored). >> >> The goal of JDK-8204551 was to shorten the path to the file where an exception was raised to avoid truncation. This patch provides a different approach to achieve this, that also fixes the issue for other platforms and compilers. It also fixes the performance issue with precompiled headers. >> >> For Hotspot (at least for now), we stop setting -DTHIS_FILE on the compiler command line completely. Instead this macro is defined in macros.hpp, based on __FILE__ but with an offest. This offset is calculated in configure. For newer versions of GCC (8+) there is a new flag, -fmacro-prefix-map=, which can be used to rewrite the __FILE__ macro. Configure checks if this flag is available and uses it instead of the offset macro if possible. >> >> I only touched the one usage of THIS_FILE/__FILE__ in this patch. It's possible we should rewrite all references to __FILE__ to improve debug/error. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8221851 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8221851/webrev.01/index.html >> >> /Erik > Here's an alternative approach that seems simpler. Don't pass > THIS_FILE to HotSpot code (or ignore it if that works). Instead add > > inline const char* this_file_helper(const char* s) { > const char* result = strrchr(s, '/'); > return (result == NULL) ? s : (result + 1); > } > > and in the one place where HotSpot is using THIS_FILE > (exceptions.hpp), instead use > > this_file_helper(__FILE__) > > (This assumes the path separator is '/', but there's probably a > constant for that somewhere if it's needed.) > > (this_file_helper() is only needed to deal with the case where > __FILE__ contains no path separators; that might not even be an issue, > in which case it can be dropped and just add 1 to the strrchr result. > Also not wedded to that name; this is more or less basename(3).) > > Empirically, gcc will optimize that all quite nicely. I don't know > about other platforms, but the worst that happens is we take a small > runtime hit when "throwing" an exception. This kind of solution will also work. It's worth noting that your fix will work like basename and just print the filename (as the current state in hotspot does for exceptions if compiled with GCC). I think printing the complete relative path to the workspace root is an improvement over this, and I think the only reason it's currently printing just the filename is that that's what appeared available as an alternative. The issue with truncated paths is mostly happening on our internal Mach5 builds where the workspace root is usually located in an extremely deep path hierarchy. Additionally, I would like to replace all (or at least most) instances of __FILE__ with my new THIS_FILE, and I suspect some other places would be more performance sensitive. Do you see any problem with doing that substitution? > This doesn't eliminate the full pathname string embedded in the > executable, but I don't think the proposed FILE_MACRO_OFFSET will do > that either. Those get fixed by -fmacro-prefix-map=. Correct. While solving this universally would be nice, it wasn't the goal of this bug. The main goal was to get precompiled headers to work with GCC again. /Erik > From dms at samersoff.net Wed Apr 3 13:54:35 2019 From: dms at samersoff.net (Dmitry Samersoff) Date: Wed, 3 Apr 2019 16:54:35 +0300 Subject: [aarch64-port-dev ] RFR (XS) 8221725: AArch64 build failures after JDK-8221408 (Windows 32bit build build errors/warnings in hotspot) In-Reply-To: References: <593aa6a5-407d-4415-1d37-f304c4d4e6d5@redhat.com> Message-ID: Thomas, Just curiosity - did hotspot team consider to start using C++11 sometimes? e.g. (for this case) enum lock_mask_constants : uintptr_t { ... }; -Dmitry On 01.04.2019 7:30, Thomas St?fe wrote: > Hi Alexey, > > Sorry for breaking aarch64. > > Kim and me had discussions about this particular fix, see original rfr > thread for 8221408. > > A better solution than adding the cast like you did might be to pull the > offending enum value out and make it a uintx constant too. Or, I could > revert my change and make it windows only. Or add a dummy value to the enum > and cast that to uintptr, to force its size up. > > I think a good solution would be one that prevents such errors for other > enum values and for other platforms as well. > > Your patch is fine, if you just want to fix your build now. > > ..thomas > > On Sun 31. Mar 2019 at 23:36, Aleksey Shipilev wrote: > >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8221725 >> >> Fix: >> >> diff -r f062188117ad src/hotspot/cpu/aarch64/aarch64.ad >> --- a/src/hotspot/cpu/aarch64/aarch64.ad Sat Mar 30 21:29:37 2019 >> +0100 >> +++ b/src/hotspot/cpu/aarch64/aarch64.ad Sun Mar 31 23:30:41 2019 >> +0200 >> @@ -3443,11 +3443,11 @@ >> // Check if the owner is self by comparing the value in the >> // markOop of object (disp_hdr) with the stack pointer. >> __ mov(rscratch1, sp); >> __ sub(disp_hdr, disp_hdr, rscratch1); >> - __ mov(tmp, (address) (~(os::vm_page_size()-1) | >> markOopDesc::lock_mask_in_place)); >> + __ mov(tmp, (address) (~(os::vm_page_size()-1) | >> (uintptr_t)markOopDesc::lock_mask_in_place)); >> // If condition is true we are cont and hence we can store 0 as the >> // displaced header in the box, which indicates that it is a >> recursive lock. >> __ ands(tmp/*==0?*/, disp_hdr, tmp); // Sets flags for result >> >> The offending change pulled some enum constants out, which apparently made >> enum representation much >> smaller. Not sure if putting the constants back does not break Win32 build >> again. So, instead, fix >> it up in one place that blows up with build warning-as-error. The fix has >> some level of ewwness, but >> it seems to be the same as what bytecodeInterpreter.cpp is doing. The >> alternative is to cast to >> uintx, as macroAssembler_arm.cpp is doing. >> >> Testing: Linux aarch64 fastdebug build, ad-hoc tests >> >> -- >> Thanks, >> -Aleksey >> >> >> From thomas.stuefe at gmail.com Wed Apr 3 13:58:34 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 3 Apr 2019 15:58:34 +0200 Subject: [aarch64-port-dev ] RFR (XS) 8221725: AArch64 build failures after JDK-8221408 (Windows 32bit build build errors/warnings in hotspot) In-Reply-To: References: <593aa6a5-407d-4415-1d37-f304c4d4e6d5@redhat.com> Message-ID: Hi Dmitry, Kim would be in a better position to answer this, I'm not part of Oracle hotspot team. Cheers, Thomas On Wed, Apr 3, 2019 at 3:54 PM Dmitry Samersoff wrote: > Thomas, > > Just curiosity - > did hotspot team consider to start using C++11 sometimes? > > e.g. (for this case) > > enum lock_mask_constants : uintptr_t { ... }; > > -Dmitry > > On 01.04.2019 7:30, Thomas St?fe wrote: > > Hi Alexey, > > > > Sorry for breaking aarch64. > > > > Kim and me had discussions about this particular fix, see original rfr > > thread for 8221408. > > > > A better solution than adding the cast like you did might be to pull the > > offending enum value out and make it a uintx constant too. Or, I could > > revert my change and make it windows only. Or add a dummy value to the > enum > > and cast that to uintptr, to force its size up. > > > > I think a good solution would be one that prevents such errors for other > > enum values and for other platforms as well. > > > > Your patch is fine, if you just want to fix your build now. > > > > ..thomas > > > > On Sun 31. Mar 2019 at 23:36, Aleksey Shipilev wrote: > > > >> Bug: > >> https://bugs.openjdk.java.net/browse/JDK-8221725 > >> > >> Fix: > >> > >> diff -r f062188117ad src/hotspot/cpu/aarch64/aarch64.ad > >> --- a/src/hotspot/cpu/aarch64/aarch64.ad Sat Mar 30 21:29:37 > 2019 > >> +0100 > >> +++ b/src/hotspot/cpu/aarch64/aarch64.ad Sun Mar 31 23:30:41 > 2019 > >> +0200 > >> @@ -3443,11 +3443,11 @@ > >> // Check if the owner is self by comparing the value in the > >> // markOop of object (disp_hdr) with the stack pointer. > >> __ mov(rscratch1, sp); > >> __ sub(disp_hdr, disp_hdr, rscratch1); > >> - __ mov(tmp, (address) (~(os::vm_page_size()-1) | > >> markOopDesc::lock_mask_in_place)); > >> + __ mov(tmp, (address) (~(os::vm_page_size()-1) | > >> (uintptr_t)markOopDesc::lock_mask_in_place)); > >> // If condition is true we are cont and hence we can store 0 as the > >> // displaced header in the box, which indicates that it is a > >> recursive lock. > >> __ ands(tmp/*==0?*/, disp_hdr, tmp); // Sets flags for result > >> > >> The offending change pulled some enum constants out, which apparently > made > >> enum representation much > >> smaller. Not sure if putting the constants back does not break Win32 > build > >> again. So, instead, fix > >> it up in one place that blows up with build warning-as-error. The fix > has > >> some level of ewwness, but > >> it seems to be the same as what bytecodeInterpreter.cpp is doing. The > >> alternative is to cast to > >> uintx, as macroAssembler_arm.cpp is doing. > >> > >> Testing: Linux aarch64 fastdebug build, ad-hoc tests > >> > >> -- > >> Thanks, > >> -Aleksey > >> > >> > >> > From matthias.baesken at sap.com Wed Apr 3 14:43:31 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 3 Apr 2019 14:43:31 +0000 Subject: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: References: <98b6c488-a935-9b43-7382-5bfc732f0ac7@oracle.com> <2f68463c-be1c-9d34-6202-72613cb7438d@oracle.com> <2c61ef7c-91f0-9636-5567-eaf8bbff7c94@oracle.com> <30b2b3c5-38f7-8569-10cd-e781129b5da5@oracle.com> Message-ID: > 1. Why do we have/need os::::print_virtualization_info when we also > have VM_Version::print_platform_virtualization_info? > Hi David, I have to agree - we do not really need both . So I removed os::::print_virtualization_info and call VM_Version::print_platform_virtualization_info(st); at the places where the output is done. Regarding point 2. : I now just use print_platform_virtualization_info, print_detected_virtualization has been removed . print_platform_virtualization_info is doing the output (differs for vm_version_ s390 / ppc / x86_64 ) . The new webrev is simpler, with less methods : http://cr.openjdk.java.net/~mbaesken/webrevs/8219241.4/ Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Freitag, 29. M?rz 2019 01:16 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Cc: Doerr, Martin > Subject: Re: RFR: 8219241: Provide basic virtualization related info in the > hs_error file on linux/windows x86_64 > > Hi Matthias, > > I have two issues with this API: > > 1. Why do we have/need os::::print_virtualization_info when we also > have VM_Version::print_platform_virtualization_info? > > 2. I don't like the fact that the there are two ways to define the > platform specific information: > a) override VM_Version::print_platform_virtualization_info; or > b) hook into the get_detected_virtualization switch > > And IIUC code that uses (a) relies on the switch doing nothing > (NoVirtualization) and code that uses (b) relies on > print_platform_virtualization_info doing nothing! > > Why doesn't the default implementation of > VM_Version::print_platform_virtualization_info define the > get_detected_virtualization() switch logic, and do away with > Abstract_VM_Version::print_detected_virtualization? Code that wants to > print this info can just call > VM_Version::print_platform_virtualization_info(). > > Sorry but I just find the current proposal has too many methods and an > unclear structure. > > David From daniel.daugherty at oracle.com Wed Apr 3 15:08:57 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 3 Apr 2019 11:08:57 -0400 Subject: [aarch64-port-dev ] RFR (XS) 8221725: AArch64 build failures after JDK-8221408 (Windows 32bit build build errors/warnings in hotspot) In-Reply-To: References: <593aa6a5-407d-4415-1d37-f304c4d4e6d5@redhat.com> Message-ID: While there have been changes to make various C++11 compilers happy/happier, I'm not aware of a project to switch to C++11... However: ? JDK-8208089 JEP 347: Adopt C++14 Language Features in HotSpot ? https://bugs.openjdk.java.net/browse/JDK-8208089 should be interesting... Dan On 4/3/19 9:54 AM, Dmitry Samersoff wrote: > Thomas, > > Just curiosity - > did hotspot team consider to start using C++11 sometimes? > > e.g. (for this case) > > enum lock_mask_constants : uintptr_t { ... }; > > -Dmitry > > On 01.04.2019 7:30, Thomas St?fe wrote: >> Hi Alexey, >> >> Sorry for breaking aarch64. >> >> Kim and me had discussions about this particular fix, see original rfr >> thread for 8221408. >> >> A better solution than adding the cast like you did might be to pull the >> offending enum value out and make it a uintx constant too. Or, I could >> revert my change and make it windows only. Or add a dummy value to the enum >> and cast that to uintptr, to force its size up. >> >> I think a good solution would be one that prevents such errors for other >> enum values and for other platforms as well. >> >> Your patch is fine, if you just want to fix your build now. >> >> ..thomas >> >> On Sun 31. Mar 2019 at 23:36, Aleksey Shipilev wrote: >> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8221725 >>> >>> Fix: >>> >>> diff -r f062188117ad src/hotspot/cpu/aarch64/aarch64.ad >>> --- a/src/hotspot/cpu/aarch64/aarch64.ad Sat Mar 30 21:29:37 2019 >>> +0100 >>> +++ b/src/hotspot/cpu/aarch64/aarch64.ad Sun Mar 31 23:30:41 2019 >>> +0200 >>> @@ -3443,11 +3443,11 @@ >>> // Check if the owner is self by comparing the value in the >>> // markOop of object (disp_hdr) with the stack pointer. >>> __ mov(rscratch1, sp); >>> __ sub(disp_hdr, disp_hdr, rscratch1); >>> - __ mov(tmp, (address) (~(os::vm_page_size()-1) | >>> markOopDesc::lock_mask_in_place)); >>> + __ mov(tmp, (address) (~(os::vm_page_size()-1) | >>> (uintptr_t)markOopDesc::lock_mask_in_place)); >>> // If condition is true we are cont and hence we can store 0 as the >>> // displaced header in the box, which indicates that it is a >>> recursive lock. >>> __ ands(tmp/*==0?*/, disp_hdr, tmp); // Sets flags for result >>> >>> The offending change pulled some enum constants out, which apparently made >>> enum representation much >>> smaller. Not sure if putting the constants back does not break Win32 build >>> again. So, instead, fix >>> it up in one place that blows up with build warning-as-error. The fix has >>> some level of ewwness, but >>> it seems to be the same as what bytecodeInterpreter.cpp is doing. The >>> alternative is to cast to >>> uintx, as macroAssembler_arm.cpp is doing. >>> >>> Testing: Linux aarch64 fastdebug build, ad-hoc tests >>> >>> -- >>> Thanks, >>> -Aleksey >>> >>> >>> From vladimir.kozlov at oracle.com Wed Apr 3 16:54:19 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 3 Apr 2019 09:54:19 -0700 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: <8063fb37-f1b0-8b93-bbe8-4dbeeaa54959@oracle.com> References: <4b759550-f185-724f-7139-9bab648a1966@oracle.com> <119335f1-acb7-fffc-f38a-e50a96b73b3c@oracle.com> <2d206374-cfeb-9b1b-2838-e4e0a774e89d@oracle.com> <8063fb37-f1b0-8b93-bbe8-4dbeeaa54959@oracle.com> Message-ID: <17233985-18c7-305e-5556-fe2b38926b71@oracle.com> On 4/2/19 11:35 PM, Stefan Karlsson wrote: > On 2019-04-02 22:41, Vladimir Kozlov wrote: >> I ran Kitchensink with G1 and -Xmx8g. I observed that Remark pause times are not consistent even without Graal. >> To see effect I added time spent in JVMCI::do_unloading() to GC log (see below [3]). The result is < 1ms - it is less >> than 1% of a pause time. > > Kitchensink isn't really a benchmark, but a stress test. I sent you a private mail how to run these changes through our > internal performance test setup. Okay, I will run performance tests there too. > >> >> It will have even less effect since I moved JVMCI::do_unloading() from serial path to parallel worker thread as Stefan >> suggested. >> >> Stefan, are you satisfied with these changes now? > > Yes, the clean-ups look good. Thanks for cleaning this up. > > Kim had some extra comments about a few more places where JVMCI_ONLY could be used. > > I also agree with him that JVMCI::oops_do should not be placed in JNIHandles::oops_do. I think you should put it where > you put the AOTLoader::oops_do calls. Okay. Thanks, Vladimir > > Thanks, > StefanK > > >> >> Here is latest delta update which includes previous [1] delta and >> - use CompilerThreadStackSize * 2 for libgraal instead of exact value, >> - removed HandleMark added for debugging (reverted changes in jvmtiImpl.cpp), >> - added recent jvmci-8 changes to fix registration of native methods in libgraal (jvmciCompilerToVM.cpp) >> >> http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.05/ >> >> Thanks, >> Vladimir >> >> [1] http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.04/ >> [2] Original webrev http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ >> [3] Pauses times from Kitchensink (0.0ms means there were no unloaded classes, 'NNN alive' shows how many metadata >> references were processed): >> >> [1.083s][1554229160638ms][info ][gc,start???? ] GC(2) Pause Remark >> [1.085s][1554229160639ms][info ][gc?????????? ] GC(2) JVMCI::do_unloading(): 0 alive 0.000ms >> [1.099s][1554229160654ms][info ][gc?????????? ] GC(2) Pause Remark 28M->28M(108M) 16.123ms >> >> [3.097s][1554229162651ms][info ][gc,start???? ] GC(12) Pause Remark >> [3.114s][1554229162668ms][info ][gc?????????? ] GC(12) JVMCI::do_unloading(): 3471 alive 0.164ms >> [3.148s][1554229162702ms][info ][gc?????????? ] GC(12) Pause Remark 215M->213M(720M) 51.103ms >> >> [455.111s][1554229614666ms][info ][gc,phases,start] GC(1095) Phase 1: Mark live objects >> [455.455s][1554229615010ms][info ][gc???????????? ] GC(1095) JVMCI::do_unloading(): 4048 alive 0.821ms >> [455.456s][1554229615010ms][info ][gc,phases????? ] GC(1095) Phase 1: Mark live objects 344.107ms >> >> [848.932s][1554230008486ms][info ][gc,phases,start] GC(1860) Phase 1: Mark live objects >> [849.248s][1554230008803ms][info ][gc???????????? ] GC(1860) JVMCI::do_unloading(): 3266 alive 0.470ms >> [849.249s][1554230008803ms][info ][gc,phases????? ] GC(1860) Phase 1: Mark live objects 316.527ms >> >> [1163.778s][1554230323332ms][info ][gc,start?????? ] GC(2627) Pause Remark >> [1163.932s][1554230323486ms][info ][gc???????????? ] GC(2627) JVMCI::do_unloading(): 3474 alive 0.642ms >> [1163.941s][1554230323496ms][info ][gc???????????? ] GC(2627) Pause Remark 2502M->2486M(4248M) 163.296ms >> >> [1242.587s][1554230402141ms][info ][gc,phases,start] GC(2734) Phase 1: Mark live objects >> [1242.899s][1554230402453ms][info ][gc???????????? ] GC(2734) JVMCI::do_unloading(): 3449 alive 0.570ms >> [1242.899s][1554230402453ms][info ][gc,phases????? ] GC(2734) Phase 1: Mark live objects 311.719ms >> >> [1364.164s][1554230523718ms][info ][gc,phases,start] GC(3023) Phase 1: Mark live objects >> [1364.613s][1554230524167ms][info ][gc???????????? ] GC(3023) JVMCI::do_unloading(): 3449 alive 0.000ms >> [1364.613s][1554230524167ms][info ][gc,phases????? ] GC(3023) Phase 1: Mark live objects 448.495ms >> >> [1425.222s][1554230584776ms][info ][gc,phases,start] GC(3151) Phase 1: Mark live objects >> [1425.587s][1554230585142ms][info ][gc???????????? ] GC(3151) JVMCI::do_unloading(): 3491 alive 0.882ms >> [1425.587s][1554230585142ms][info ][gc,phases????? ] GC(3151) Phase 1: Mark live objects 365.403ms >> >> [1456.401s][1554230615955ms][info ][gc,phases,start] GC(3223) Phase 1: Mark live objects >> [1456.769s][1554230616324ms][info ][gc???????????? ] GC(3223) JVMCI::do_unloading(): 3478 alive 0.616ms >> [1456.769s][1554230616324ms][info ][gc,phases????? ] GC(3223) Phase 1: Mark live objects 368.643ms >> >> [1806.139s][1554230965694ms][info?? ][gc,start?????? ] GC(4014) Pause Remark >> [1806.161s][1554230965716ms][info?? ][gc???????????? ] GC(4014) JVMCI::do_unloading(): 3478 alive 0.000ms >> [1806.163s][1554230965717ms][info?? ][gc???????????? ] GC(4014) Pause Remark 1305M->1177M(2772M) 23.190ms >> >> >> >> On 4/1/19 12:34 AM, Stefan Karlsson wrote: >>> On 2019-03-29 17:55, Vladimir Kozlov wrote: >>>> Stefan, >>>> >>>> Do you have a test (and flags) which can allow me to measure effect of this code on G1 remark pause? >>> >>> >>> -Xlog:gc prints the remark times: >>> [4,296s][info][gc?????? ] GC(89) Pause Remark 4M->4M(28M) 36,412ms >>> >>> StefanK >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 3/29/19 12:36 AM, Stefan Karlsson wrote: >>>>> On 2019-03-29 03:07, Vladimir Kozlov wrote: >>>>>> Hi Stefan, >>>>>> >>>>>> I collected some data on MetadataHandleBlock. >>>>>> >>>>>> First, do_unloading() code is executed only when class_unloading_occurred is 'true' - it is rare case. It should >>>>>> not affect normal G1 remark pause. >>>>> >>>>> It's only rare for applications that don't do dynamic class loading and unloading. The applications that do, will >>>>> be affected. >>>>> >>>>>> >>>>>> Second, I run a test with -Xcomp. I got about 10,000 compilations by Graal and next data at the end of execution: >>>>>> >>>>>> max_blocks = 232 >>>>>> max_handles_per_block = 32 (since handles array has 32 elements) >>>>>> max_total_alive_values = 4631 >>>>> >>>>> OK. Thanks for the info. >>>>> >>>>> StefanK >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 3/28/19 2:44 PM, Vladimir Kozlov wrote: >>>>>>> Thank you, Stefan >>>>>>> >>>>>>> On 3/28/19 12:54 PM, Stefan Karlsson wrote: >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> I started to check the GC code. >>>>>>>> >>>>>>>> ======================================================================== >>>>>>>> I see that you've added guarded includes in the middle of the include list: >>>>>>>> ?? #include "gc/shared/strongRootsScope.hpp" >>>>>>>> ?? #include "gc/shared/weakProcessor.hpp" >>>>>>>> + #if INCLUDE_JVMCI >>>>>>>> + #include "jvmci/jvmci.hpp" >>>>>>>> + #endif >>>>>>>> ?? #include "oops/instanceRefKlass.hpp" >>>>>>>> ?? #include "oops/oop.inline.hpp" >>>>>>>> >>>>>>>> The style we use is to put these conditional includes at the end of the include lists. >>>>>>> >>>>>>> okay >>>>>>> >>>>>>>> >>>>>>>> ======================================================================== >>>>>>>> Could you also change the following: >>>>>>>> >>>>>>>> + #if INCLUDE_JVMCI >>>>>>>> +???? // Clean JVMCI metadata handles. >>>>>>>> +???? JVMCI::do_unloading(is_alive_closure(), purged_class); >>>>>>>> + #endif >>>>>>>> >>>>>>>> to: >>>>>>>> +???? // Clean JVMCI metadata handles. >>>>>>>> +???? JVMCI_ONLY(JVMCI::do_unloading(is_alive_closure(), purged_class);) >>>>>>>> >>>>>>>> to get rid of some of the line noise in the GC files. >>>>>>> >>>>>>> okay >>>>>>> >>>>>>>> >>>>>>>> ======================================================================== >>>>>>>> In the future we will need version of JVMCI::do_unloading that supports concurrent cleaning for ZGC. >>>>>>> >>>>>>> Yes, we need to support concurrent cleaning in a future. >>>>>>> >>>>>>>> >>>>>>>> ======================================================================== >>>>>>>> What's the performance impact for G1 remark pause with this serial walk over the MetadataHandleBlock? >>>>>>>> >>>>>>>> 3275 void G1CollectedHeap::complete_cleaning(BoolObjectClosure* is_alive, >>>>>>>> 3276???????????????????????????????????????? bool class_unloading_occurred) { >>>>>>>> 3277?? uint num_workers = workers()->active_workers(); >>>>>>>> 3278?? ParallelCleaningTask unlink_task(is_alive, num_workers, class_unloading_occurred, false); >>>>>>>> 3279?? workers()->run_task(&unlink_task); >>>>>>>> 3280 #if INCLUDE_JVMCI >>>>>>>> 3281?? // No parallel processing of JVMCI metadata handles for now. >>>>>>>> 3282?? JVMCI::do_unloading(is_alive, class_unloading_occurred); >>>>>>>> 3283 #endif >>>>>>>> 3284 } >>>>>>> >>>>>>> There should not be impact if Graal is not used. Only cost of call (which most likely is inlined in product VM) >>>>>>> and check: >>>>>>> >>>>>>> http://hg.openjdk.java.net/metropolis/dev/file/530fc1427d02/src/hotspot/share/jvmci/jvmciRuntime.cpp#l1237 >>>>>>> >>>>>>> If Graal is used it should not have big impact since these metadata has regular pattern (32 handles per array and >>>>>>> array per MetadataHandleBlock block which are linked in list) and not large. >>>>>>> If there will be noticeable impact - we will work on it as you suggested by using ParallelCleaningTask. >>>>>>> >>>>>>>> >>>>>>>> ======================================================================== >>>>>>>> Did you consider adding it as a task for one of the worker threads to execute in ParallelCleaningTask? >>>>>>>> >>>>>>>> See how other tasks are claimed by one worker: >>>>>>>> void KlassCleaningTask::work() { >>>>>>>> ?? ResourceMark rm; >>>>>>>> >>>>>>>> ?? // One worker will clean the subklass/sibling klass tree. >>>>>>>> ?? if (claim_clean_klass_tree_task()) { >>>>>>>> ???? Klass::clean_subklass_tree(); >>>>>>>> ?? } >>>>>>> >>>>>>> These changes were ported from JDK8u based changes in graal-jvmci-8 and there are no ParallelCleaningTask in JDK8. >>>>>>> >>>>>>> Your suggestion is interesting and I agree that we should investigate it. >>>>>>> >>>>>>>> >>>>>>>> ======================================================================== >>>>>>>> In MetadataHandleBlock::do_unloading: >>>>>>>> >>>>>>>> +??????? if (klass->class_loader_data()->is_unloading()) { >>>>>>>> +????????? // This needs to be marked so that it's no longer scanned >>>>>>>> +????????? // but can't be put on the free list yet. The >>>>>>>> +????????? // ReferenceCleaner will set this to NULL and >>>>>>>> +????????? // put it on the free list. >>>>>>>> >>>>>>>> I couldn't find the ReferenceCleaner in the patch or in the source. Where can I find this code? >>>>>>> >>>>>>> I think it is typo (I will fix it) - it references new HandleCleaner class: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HandleCleaner.java.html >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> StefanK >>>>>>>> >>>>>>>> On 2019-03-28 20:15, Vladimir Kozlov wrote: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8220623 >>>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ >>>>>>>>> >>>>>>>>> Update JVMCI to support pre-compiled as shared library Graal. >>>>>>>>> Using aoted Graal can offers benefits including: >>>>>>>>> ?- fast startup >>>>>>>>> ?- compile time similar to native JIt compilers (C2) >>>>>>>>> ?- memory usage disjoint from the application Java heap >>>>>>>>> ?- no profile pollution of JDK code used by the application >>>>>>>>> >>>>>>>>> This is JDK13 port of JVMCI changes done in graal-jvmci-8 [1] up to date. >>>>>>>>> Changes were collected in Metropolis repo [2] and tested there. >>>>>>>>> >>>>>>>>> Changes we reviewed by Oracle Labs (authors of JVMCI and Graal) and our compiler group. >>>>>>>>> Changes in shared code are guarded by #if INCLUDE_JVMCI and JVMCI flags. >>>>>>>>> >>>>>>>>> I ran tier1-tier8 (which includes HotSpot and JDK tests) and it was clean. In this set Graal was tested only in >>>>>>>>> tier3. >>>>>>>>> >>>>>>>>> And I ran all hs-tier3-graal .. hs-tier8-graal Graal tests available in our system. Several issue were found >>>>>>>>> which were present before these changes. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> [1] https://github.com/graalvm/graal-jvmci-8/commit/49ff2045fb603e35516a3a427d8023c00e1607af >>>>>>>>> [2] http://hg.openjdk.java.net/metropolis/dev/ >>>>>>>> From jamsheed.c.m at oracle.com Wed Apr 3 19:14:43 2019 From: jamsheed.c.m at oracle.com (Jamsheed) Date: Thu, 4 Apr 2019 00:44:43 +0530 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <742307c4-9dd0-4c5f-514b-e53fa3ac51a8@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <571f3d72-a22a-3b52-2942-6408072e353f@oracle.com> <144af13e-33e2-2089-f8d2-902e94485eb1@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> Message-ID: <7ce71707-967b-4748-f7e0-12c1743e939a@oracle.com> Hi Tobias, apologies for sending it again for review. http://cr.openjdk.java.net/~jcm/8191278/webrev.03/ made a few improvements to the code. 1) removed code range checks dependency on order of code generation. 2) made the exception/handling mechanism to easily scale on all ports. Best regards, Jamsheed On 01/04/19 12:42 PM, Jamsheed wrote: > On 29.03.19 15:19, Jamsheed wrote: >> http://cr.openjdk.java.net/~jcm/8191278/webrev.02/ From kim.barrett at oracle.com Wed Apr 3 23:34:14 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 3 Apr 2019 19:34:14 -0400 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> Message-ID: <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> > On Apr 3, 2019, at 9:51 AM, Erik Joelsson wrote: > On 2019-04-02 16:02, Kim Barrett wrote: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221851 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8221851/webrev.01/index.html >>> >>> /Erik >> Here's an alternative approach that seems simpler. [?] > > This kind of solution will also work. It's worth noting that your fix will work like basename and just print the filename (as the current state in hotspot does for exceptions if compiled with GCC). I think printing the complete relative path to the workspace root is an improvement over this, and I think the only reason it's currently printing just the filename is that that's what appeared available as an alternative. The issue with truncated paths is mostly happening on our internal Mach5 builds where the workspace root is usually located in an extremely deep path hierarchy. I disagree that it's mostly a problem on our internal Mach5 builds. There are paths in my development repos that exceed the clipped size in the examples in that bug, and I don't think I have a very deep hierarchy. Using a workspace-relative path in exception messages might be enough to still address JDK-8204551 though. > Additionally, I would like to replace all (or at least most) instances of __FILE__ with my new THIS_FILE, and I suspect some other places would be more performance sensitive. Do you see any problem with doing that substitution? Given that our build system is mostly unhappy with basename collisions (other than open/custom overrides), I don't think there's much of a usage problem with using a basename-like approach everywhere either. While researching what various platforms do in this area, I ran across a suggestion that debug builds should maybe use full paths and release builds use shortened paths. That seems like an interesting idea, though we still want short paths in the exceptions.hpp case. I tend to expect (modern) compilers to be pretty good at obvious optimizations, though admit I'm occasionally sadly disappointed. >> This doesn't eliminate the full pathname string embedded in the >> executable, but I don't think the proposed FILE_MACRO_OFFSET will do >> that either. Those get fixed by -fmacro-prefix-map=. > > Correct. While solving this universally would be nice, it wasn't the goal of this bug. The main goal was to get precompiled headers to work with GCC again. I agree that either approach does that. I looked at the webrev and it's a bunch of build system changes that I don't feel qualified to review, so I suggested an alternative that I understand. We each have our preferred tools. I don't object to the build-system-based approach, just can't give an actual thumbs-up. From coleen.phillimore at oracle.com Thu Apr 4 00:25:34 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 3 Apr 2019 20:25:34 -0400 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: <2dbe8e0b-a8b5-9129-db24-9ef761bf9741@redhat.com> References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <8b0f5b4c-0386-1440-6939-646daf36aa55@redhat.com> <24b4bb72-732e-0447-d1be-dd71507e7787@redhat.com> <8ab058fe-886b-643f-f602-c27182d6f584@oracle.com> <2dbe8e0b-a8b5-9129-db24-9ef761bf9741@redhat.com> Message-ID: <8f5a146f-6053-46fc-be91-2f1900a55852@oracle.com> Hi,? Sorry for the delayed reply. On 4/2/19 10:51 AM, Andrew Dinn wrote: > Hi Colleen, > > thanks for looking at this. > > On 01/04/2019 14:28, coleen.phillimore at oracle.com wrote: >> http://cr.openjdk.java.net/~adinn/8221477/webrev.02/src/hotspot/share/classfile/javaClasses.cpp.udiff.html >> >> >> I was sort of expecting you to use like UNSAFE_CONSTANTS_DO for the >> fields, so that you don't have to add more names to vmSymbols.hpp. And >> that's what the rest of the code does (except CompactStrings). I can >> sort of? understand that it's faster as static_fields_do, and you can >> check for unexpected fields. > Well, I'm only following the model used for CompactStrings because what > Vladimir (Kozlov) suggested it as a model to follow when reviewing JEP > 352 (it was suggested as a way to initialize the fields I will need to > size/align cache lines). I'm not especially attached to this way of > doing it. > > That said, I understand what you say about this vs the alternative. > Implementing an UNSAFE_CONSTANTS_DO macro would, on the plus side, avoid > the need to add those extra symbols into vmSymbols.hpp but, on the flip > side, would > > i) require repeated calls to InstanceKlass::find_local_field > ii) check for expected fields but not detect unexpected fields > > Is there a reason to be especially concerned over extra field name > symbols? I'll change to UNSAFE_CONSTANTS_DO if you want but I really > like the fact that this way of doing it guarantees that /all/ fields are > final, static and expected. Yes, I see the advantage to it.? I wish it were more compact but it's fine the way it you've written it. > >> + jint _address_size; >> + jint _page_size; >> + jboolean _big_endian; >> + jboolean _use_unaligned_access; >> >> We've been trying to keep Java types out of the C++ code, and use the >> appropriate C++ types. > Sure, I'll update this accordingly. > >> InstanceKlass::cast(SystemDictionary::UnsafeConstants_klass())->do_local_static_fields(&fixup); >> The cast is unnecessary.? UnsafeConstants_klass returns an InstanceKlass. > Ah, ok, I cut and pasted this from the equivalent code for String. > Perhaps I should fix that as well. Please, fix that one too.? I've had several passes removing InstanceKlass::cast()s but they keep sneaking in. > >> http://cr.openjdk.java.net/~adinn/8221477/webrev.02/src/hotspot/share/classfile/vmSymbols.hpp.udiff.html >> >> >> I just don't like the field names here. :( > Well, sorry, but I have to ask do you mean the words or the format? If > the words then is that the names on the left (address_size_name etc) or > names on the right (ADDRESS_SIZE etc). n.b as regards upper case I chose > ALL_CAPS because these are final static constant numeric fields and ... > > ... well, I am pleased you brought this up. There is a 'semi-lucid' > rationale for the current names albeit one which I am not 100% happy with: > > I tried to retain the naming convention which is (sort-of) followed in > Unsafe e.g. field ADDRESS_SIZE caches the value retrieved by native > method addressSize0 and is exposed by public getter addressSize(). I > hoped to define all the relevant constant fields in UnsafeConstants > using names originally found in class Unsafe. The idea was then to > delete the Unsafe fields and statically import the ones from > UnsafeConstants into class Unsafe. That way I a simple mention of the > imported constants in the getter or at other internal points where they > were used would continue to work. > > That's fine for PAGE_SIZE, UNALIGNED_ACCESS and BE. Getter method > pageSize() was always implemented as native with no cached value. So, > the old native method can simply be redefined to return the value > injected into UnsafeConstants. PAGE_SIZE is thus the conventional name > for the static field. > > The value returned by unalignedAccess0 was cached in private field > unalignedAccess (ah yes, camelCase :-/) and then exposed by public > getter unalignedAccess(). So, once again importing a field in > UnsafeConstants called UNALIGNED_ACCESS and returning this form the > getter is uniform. > > Method isBigEndian0 was used to initialize a field called BE. So, I > could have followed suit and called the field in UnsafeConstants BE and > this would have worked. However, I though a longer, more explicit name > for the UnsafeConstants field would be clearer and picked BIG_ENDIAN. > However, I decided to leave the original field BE in Unsafe and simply > initialize it from BIG_ENDIAN because it is used in many ternary > expression (BE ? ... : ...) and changing it to use a longer name looked > terribly messy. So, I admit the choice of BIG_ENDIAN is a little > perverse and strictly this field ought to be called BE. > > However, that turned out to be somewhat moot as the plan was foiled by a > further difficulty. I could not delete field Unsafe::ADDRESS_SIZE and > import UnsafeConstants::ADDRESS_SIZE because the the field in Unsafe is > public (what is worse, it is referenced from the JDK runtime even though > public getter addressSize exists). So, the original idea of deleting the > Unsafe fields and importing the UnsafeConstants equivalents under the > same names was snookered from the get go. In consequence, I simply > import class UnsafeConstants and reference the constants with an > explicit classname qualifier. > > So, I accept this is far from perfect. If you have a preferred > suggestion as to how to name the fields and getters in UnsafeConstants > and/or Unsafe or just advice on how to revise/improve the choices I have > made I'd be happy to hear it. Actually the field names are fine, I don't like that we have to add them to vmSymbols.hpp.? But that's how the code works. Thank you for the rationale of the naming though.? It makes sense. Coleen > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From david.holmes at oracle.com Thu Apr 4 01:15:35 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 4 Apr 2019 11:15:35 +1000 Subject: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: References: <98b6c488-a935-9b43-7382-5bfc732f0ac7@oracle.com> <2f68463c-be1c-9d34-6202-72613cb7438d@oracle.com> <2c61ef7c-91f0-9636-5567-eaf8bbff7c94@oracle.com> <30b2b3c5-38f7-8569-10cd-e781129b5da5@oracle.com> Message-ID: Hi Matthias, This is looking much better/simpler - thanks! My remaining query is why we need the OS specific checks and code in os-cpu files? Isn't this just cpu specific? Even if a particular OS doesn't support virtualization, won't the cpuid query simply report "no virtualization"? Thanks, David On 4/04/2019 12:43 am, Baesken, Matthias wrote: >> 1. Why do we have/need os::::print_virtualization_info when we also >> have VM_Version::print_platform_virtualization_info? >> > > Hi David, I have to agree - we do not really need both . > So I removed os::::print_virtualization_info and call VM_Version::print_platform_virtualization_info(st); at the places where the output is done. > > Regarding point 2. : > > I now just use print_platform_virtualization_info, print_detected_virtualization has been removed . > print_platform_virtualization_info is doing the output (differs for vm_version_ s390 / ppc / x86_64 ) . > > The new webrev is simpler, with less methods : > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8219241.4/ > > Best regards, Matthias > > >> -----Original Message----- >> From: David Holmes >> Sent: Freitag, 29. M?rz 2019 01:16 >> To: Baesken, Matthias ; 'hotspot- >> dev at openjdk.java.net' >> Cc: Doerr, Martin >> Subject: Re: RFR: 8219241: Provide basic virtualization related info in the >> hs_error file on linux/windows x86_64 >> >> Hi Matthias, >> >> I have two issues with this API: >> >> 1. Why do we have/need os::::print_virtualization_info when we also >> have VM_Version::print_platform_virtualization_info? >> >> 2. I don't like the fact that the there are two ways to define the >> platform specific information: >> a) override VM_Version::print_platform_virtualization_info; or >> b) hook into the get_detected_virtualization switch >> >> And IIUC code that uses (a) relies on the switch doing nothing >> (NoVirtualization) and code that uses (b) relies on >> print_platform_virtualization_info doing nothing! >> >> Why doesn't the default implementation of >> VM_Version::print_platform_virtualization_info define the >> get_detected_virtualization() switch logic, and do away with >> Abstract_VM_Version::print_detected_virtualization? Code that wants to >> print this info can just call >> VM_Version::print_platform_virtualization_info(). >> >> Sorry but I just find the current proposal has too many methods and an >> unclear structure. >> >> David > From david.holmes at oracle.com Thu Apr 4 01:28:38 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 4 Apr 2019 11:28:38 +1000 Subject: RFR: 8221535: add steal tick related information to hs_error file [linux] In-Reply-To: References: <6e54431a-8e23-160a-5757-948f1041819e@oracle.com> Message-ID: Hi Matthias, On 2/04/2019 9:04 pm, Baesken, Matthias wrote: > Hi David , thanks for the review . > > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8221535.4/ > > I added the blank after if you suggested and also adjusted the comments in bool os::Linux::get_tick_information slightly . > > May I add you as a reviewer ? Of course! Reviewed. >>> I kept the has_steal_ticks for now; in case someone can confirm >>> 2.6.11+ for jdk13 I would remove it . >> >> I can't comment on that. >> > > It's a pity that we do not have such an info . > > However I found that we include here : > > http://hg.openjdk.java.net/jdk/jdk/file/69204b98dc3d/src/java.base/linux/native/libnio/fs/LinuxWatchService.c#l36 > > and this seems to be 2.6.13+ functionality : > > https://en.wikipedia.org/wiki/Inotify > > "August 29, 2005: Linux kernel version 2.6.13 released, containing merged inotify code" > > However it is not hotspot coding, so I am not 100% sure that we really can claim 2.6.13+ for the whole codebase . As we no longer attempt to separate the VM from the JDK we implicitly acquire the minimum platform constraints of each other. So if the JDK already assumes 2.6.13+ then hotspot should be able to safely assume it too. We checked for inotify capability dynamically in JDK 6 because, in part, our build platform was Linux 2.4. But since JDK 7 we have assumed inotify is available at build time and runtime. So it seems to me that we can quite safely assume here that we are indeed on 2.6.13+ Thanks, David ----- > > Best regards , Matthias > > > > >> -----Original Message----- >> From: David Holmes >> Sent: Montag, 1. April 2019 07:01 >> To: Baesken, Matthias ; Thomas St?fe >> >> Cc: hotspot-dev at openjdk.java.net >> Subject: Re: RFR: 8221535: add steal tick related information to hs_error file >> [linux] >> >> Hi Matthias, >> >> On 29/03/2019 11:37 pm, Baesken, Matthias wrote: >>> Hello, new webrev : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8221535.3/ >>> >>> changed the function to bool os::Linux::get_tick_information(cpu_ticks* >>> out, int which_logical_cpu = -1) >> >> Okay. >> >>> added memset? at beginning of get_tick_information >> >> Okay >> >>> removed the remaining vm_printf ?? from >>> src/hotspot/os/aix/os_perf_aix.cpp???? ?(at first I did not notice it >>> ?was ?there as well ). >> >> Okay >> >>> [ kept the struct? naming CPUPerfTicks??? ( I find plenty of such struct >>> name? styles ?in hotspot codebase ?).?? ] >> >> Agreed - no consistency and you're moving existing code so this is fine >> IMHO. >> >>>> >>> >>>> In case? we? are sure that we are always? on? 2.6.11+?? kernels, then indeed >> I can remove the? special handling. >>> >>>> I was sure? that? we are on 2.6+? but only 95%? sure that we are >> on? 2.6.11+?? . >>> >>>> >>> >>> I kept the? has_steal_ticks?? for now; in case someone? can? confirm >>> 2.6.11+??for jdk13? I would remove it . >> >> I can't comment on that. >> >> One nit in os_linux.cpp: >> >> + if((fh = fopen("/proc/stat", "r")) == NULL) { >> >> Need space after if >> >> Otherwise this all seems fine to me. >> >> Thanks, >> David >> > From tobias.hartmann at oracle.com Thu Apr 4 07:00:26 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 4 Apr 2019 09:00:26 +0200 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <7ce71707-967b-4748-f7e0-12c1743e939a@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <571f3d72-a22a-3b52-2942-6408072e353f@oracle.com> <144af13e-33e2-2089-f8d2-902e94485eb1@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> Message-ID: <5ddacc0b-a534-d751-73fa-3e2af7a70065@oracle.com> Hi Jamsheed, this looks reasonable to me although the code is getting quite complicated to handle this edge case. Someone should review/test the aarch64/arm/ppc changes. Best regards, Tobias On 03.04.19 21:14, Jamsheed wrote: > Hi Tobias, > > apologies for sending it again for review. > > http://cr.openjdk.java.net/~jcm/8191278/webrev.03/ > > made a few improvements to the code. > > 1) removed code range checks dependency on order of code generation. > > 2) made the exception/handling mechanism to easily scale on all ports. > > Best regards, > > Jamsheed > > On 01/04/19 12:42 PM, Jamsheed wrote: >> On 29.03.19 15:19, Jamsheed wrote: >>> http://cr.openjdk.java.net/~jcm/8191278/webrev.02/ From vladimir.kozlov at oracle.com Thu Apr 4 07:22:27 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 4 Apr 2019 00:22:27 -0700 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: <17233985-18c7-305e-5556-fe2b38926b71@oracle.com> References: <4b759550-f185-724f-7139-9bab648a1966@oracle.com> <119335f1-acb7-fffc-f38a-e50a96b73b3c@oracle.com> <2d206374-cfeb-9b1b-2838-e4e0a774e89d@oracle.com> <8063fb37-f1b0-8b93-bbe8-4dbeeaa54959@oracle.com> <17233985-18c7-305e-5556-fe2b38926b71@oracle.com> Message-ID: <3514c74d-5f6a-61cc-ebea-b9564df61673@oracle.com> New delta: http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.06/ Full: http://cr.openjdk.java.net/~kvn/8220623/webrev.06/ New changes are based on Kim and Stefan suggestions: - Moved JVMCI::oops_do() from JNIHandles to places where it should be called. - Moved JVMCI cleanup task to the beginning of ParallelCleaningTask::work(). - Used JVMCI_ONLY macro with COMMA. - Disable JVMCI build on SPARC. We don't use it - neither Graal or AOT are built on SPARC. Disabling also helps to find missing JVMCI guards. I ran hs-tier1-3 testing - it passed (hs-tier3 includes graal testing). I started hs-tier4..8-graal testing. I will do performance testing next. Thanks, Vladimir On 4/3/19 9:54 AM, Vladimir Kozlov wrote: > On 4/2/19 11:35 PM, Stefan Karlsson wrote: >> On 2019-04-02 22:41, Vladimir Kozlov wrote: >>> I ran Kitchensink with G1 and -Xmx8g. I observed that Remark pause times are not consistent even without Graal. >>> To see effect I added time spent in JVMCI::do_unloading() to GC log (see below [3]). The result is < 1ms - it is less >>> than 1% of a pause time. >> >> Kitchensink isn't really a benchmark, but a stress test. I sent you a private mail how to run these changes through >> our internal performance test setup. > > Okay, I will run performance tests there too. > >> >>> >>> It will have even less effect since I moved JVMCI::do_unloading() from serial path to parallel worker thread as >>> Stefan suggested. >>> >>> Stefan, are you satisfied with these changes now? >> >> Yes, the clean-ups look good. Thanks for cleaning this up. >> >> Kim had some extra comments about a few more places where JVMCI_ONLY could be used. >> >> I also agree with him that JVMCI::oops_do should not be placed in JNIHandles::oops_do. I think you should put it where >> you put the AOTLoader::oops_do calls. > > Okay. > > Thanks, > Vladimir > >> >> Thanks, >> StefanK >> >> >>> >>> Here is latest delta update which includes previous [1] delta and >>> - use CompilerThreadStackSize * 2 for libgraal instead of exact value, >>> - removed HandleMark added for debugging (reverted changes in jvmtiImpl.cpp), >>> - added recent jvmci-8 changes to fix registration of native methods in libgraal (jvmciCompilerToVM.cpp) >>> >>> http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.05/ >>> >>> Thanks, >>> Vladimir >>> >>> [1] http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.04/ >>> [2] Original webrev http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ >>> [3] Pauses times from Kitchensink (0.0ms means there were no unloaded classes, 'NNN alive' shows how many metadata >>> references were processed): >>> >>> [1.083s][1554229160638ms][info ][gc,start???? ] GC(2) Pause Remark >>> [1.085s][1554229160639ms][info ][gc?????????? ] GC(2) JVMCI::do_unloading(): 0 alive 0.000ms >>> [1.099s][1554229160654ms][info ][gc?????????? ] GC(2) Pause Remark 28M->28M(108M) 16.123ms >>> >>> [3.097s][1554229162651ms][info ][gc,start???? ] GC(12) Pause Remark >>> [3.114s][1554229162668ms][info ][gc?????????? ] GC(12) JVMCI::do_unloading(): 3471 alive 0.164ms >>> [3.148s][1554229162702ms][info ][gc?????????? ] GC(12) Pause Remark 215M->213M(720M) 51.103ms >>> >>> [455.111s][1554229614666ms][info ][gc,phases,start] GC(1095) Phase 1: Mark live objects >>> [455.455s][1554229615010ms][info ][gc???????????? ] GC(1095) JVMCI::do_unloading(): 4048 alive 0.821ms >>> [455.456s][1554229615010ms][info ][gc,phases????? ] GC(1095) Phase 1: Mark live objects 344.107ms >>> >>> [848.932s][1554230008486ms][info ][gc,phases,start] GC(1860) Phase 1: Mark live objects >>> [849.248s][1554230008803ms][info ][gc???????????? ] GC(1860) JVMCI::do_unloading(): 3266 alive 0.470ms >>> [849.249s][1554230008803ms][info ][gc,phases????? ] GC(1860) Phase 1: Mark live objects 316.527ms >>> >>> [1163.778s][1554230323332ms][info ][gc,start?????? ] GC(2627) Pause Remark >>> [1163.932s][1554230323486ms][info ][gc???????????? ] GC(2627) JVMCI::do_unloading(): 3474 alive 0.642ms >>> [1163.941s][1554230323496ms][info ][gc???????????? ] GC(2627) Pause Remark 2502M->2486M(4248M) 163.296ms >>> >>> [1242.587s][1554230402141ms][info ][gc,phases,start] GC(2734) Phase 1: Mark live objects >>> [1242.899s][1554230402453ms][info ][gc???????????? ] GC(2734) JVMCI::do_unloading(): 3449 alive 0.570ms >>> [1242.899s][1554230402453ms][info ][gc,phases????? ] GC(2734) Phase 1: Mark live objects 311.719ms >>> >>> [1364.164s][1554230523718ms][info ][gc,phases,start] GC(3023) Phase 1: Mark live objects >>> [1364.613s][1554230524167ms][info ][gc???????????? ] GC(3023) JVMCI::do_unloading(): 3449 alive 0.000ms >>> [1364.613s][1554230524167ms][info ][gc,phases????? ] GC(3023) Phase 1: Mark live objects 448.495ms >>> >>> [1425.222s][1554230584776ms][info ][gc,phases,start] GC(3151) Phase 1: Mark live objects >>> [1425.587s][1554230585142ms][info ][gc???????????? ] GC(3151) JVMCI::do_unloading(): 3491 alive 0.882ms >>> [1425.587s][1554230585142ms][info ][gc,phases????? ] GC(3151) Phase 1: Mark live objects 365.403ms >>> >>> [1456.401s][1554230615955ms][info ][gc,phases,start] GC(3223) Phase 1: Mark live objects >>> [1456.769s][1554230616324ms][info ][gc???????????? ] GC(3223) JVMCI::do_unloading(): 3478 alive 0.616ms >>> [1456.769s][1554230616324ms][info ][gc,phases????? ] GC(3223) Phase 1: Mark live objects 368.643ms >>> >>> [1806.139s][1554230965694ms][info?? ][gc,start?????? ] GC(4014) Pause Remark >>> [1806.161s][1554230965716ms][info?? ][gc???????????? ] GC(4014) JVMCI::do_unloading(): 3478 alive 0.000ms >>> [1806.163s][1554230965717ms][info?? ][gc???????????? ] GC(4014) Pause Remark 1305M->1177M(2772M) 23.190ms >>> >>> >>> >>> On 4/1/19 12:34 AM, Stefan Karlsson wrote: >>>> On 2019-03-29 17:55, Vladimir Kozlov wrote: >>>>> Stefan, >>>>> >>>>> Do you have a test (and flags) which can allow me to measure effect of this code on G1 remark pause? >>>> >>>> >>>> -Xlog:gc prints the remark times: >>>> [4,296s][info][gc?????? ] GC(89) Pause Remark 4M->4M(28M) 36,412ms >>>> >>>> StefanK >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 3/29/19 12:36 AM, Stefan Karlsson wrote: >>>>>> On 2019-03-29 03:07, Vladimir Kozlov wrote: >>>>>>> Hi Stefan, >>>>>>> >>>>>>> I collected some data on MetadataHandleBlock. >>>>>>> >>>>>>> First, do_unloading() code is executed only when class_unloading_occurred is 'true' - it is rare case. It should >>>>>>> not affect normal G1 remark pause. >>>>>> >>>>>> It's only rare for applications that don't do dynamic class loading and unloading. The applications that do, will >>>>>> be affected. >>>>>> >>>>>>> >>>>>>> Second, I run a test with -Xcomp. I got about 10,000 compilations by Graal and next data at the end of execution: >>>>>>> >>>>>>> max_blocks = 232 >>>>>>> max_handles_per_block = 32 (since handles array has 32 elements) >>>>>>> max_total_alive_values = 4631 >>>>>> >>>>>> OK. Thanks for the info. >>>>>> >>>>>> StefanK >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 3/28/19 2:44 PM, Vladimir Kozlov wrote: >>>>>>>> Thank you, Stefan >>>>>>>> >>>>>>>> On 3/28/19 12:54 PM, Stefan Karlsson wrote: >>>>>>>>> Hi Vladimir, >>>>>>>>> >>>>>>>>> I started to check the GC code. >>>>>>>>> >>>>>>>>> ======================================================================== >>>>>>>>> I see that you've added guarded includes in the middle of the include list: >>>>>>>>> ?? #include "gc/shared/strongRootsScope.hpp" >>>>>>>>> ?? #include "gc/shared/weakProcessor.hpp" >>>>>>>>> + #if INCLUDE_JVMCI >>>>>>>>> + #include "jvmci/jvmci.hpp" >>>>>>>>> + #endif >>>>>>>>> ?? #include "oops/instanceRefKlass.hpp" >>>>>>>>> ?? #include "oops/oop.inline.hpp" >>>>>>>>> >>>>>>>>> The style we use is to put these conditional includes at the end of the include lists. >>>>>>>> >>>>>>>> okay >>>>>>>> >>>>>>>>> >>>>>>>>> ======================================================================== >>>>>>>>> Could you also change the following: >>>>>>>>> >>>>>>>>> + #if INCLUDE_JVMCI >>>>>>>>> +???? // Clean JVMCI metadata handles. >>>>>>>>> +???? JVMCI::do_unloading(is_alive_closure(), purged_class); >>>>>>>>> + #endif >>>>>>>>> >>>>>>>>> to: >>>>>>>>> +???? // Clean JVMCI metadata handles. >>>>>>>>> +???? JVMCI_ONLY(JVMCI::do_unloading(is_alive_closure(), purged_class);) >>>>>>>>> >>>>>>>>> to get rid of some of the line noise in the GC files. >>>>>>>> >>>>>>>> okay >>>>>>>> >>>>>>>>> >>>>>>>>> ======================================================================== >>>>>>>>> In the future we will need version of JVMCI::do_unloading that supports concurrent cleaning for ZGC. >>>>>>>> >>>>>>>> Yes, we need to support concurrent cleaning in a future. >>>>>>>> >>>>>>>>> >>>>>>>>> ======================================================================== >>>>>>>>> What's the performance impact for G1 remark pause with this serial walk over the MetadataHandleBlock? >>>>>>>>> >>>>>>>>> 3275 void G1CollectedHeap::complete_cleaning(BoolObjectClosure* is_alive, >>>>>>>>> 3276???????????????????????????????????????? bool class_unloading_occurred) { >>>>>>>>> 3277?? uint num_workers = workers()->active_workers(); >>>>>>>>> 3278?? ParallelCleaningTask unlink_task(is_alive, num_workers, class_unloading_occurred, false); >>>>>>>>> 3279?? workers()->run_task(&unlink_task); >>>>>>>>> 3280 #if INCLUDE_JVMCI >>>>>>>>> 3281?? // No parallel processing of JVMCI metadata handles for now. >>>>>>>>> 3282?? JVMCI::do_unloading(is_alive, class_unloading_occurred); >>>>>>>>> 3283 #endif >>>>>>>>> 3284 } >>>>>>>> >>>>>>>> There should not be impact if Graal is not used. Only cost of call (which most likely is inlined in product VM) >>>>>>>> and check: >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/metropolis/dev/file/530fc1427d02/src/hotspot/share/jvmci/jvmciRuntime.cpp#l1237 >>>>>>>> >>>>>>>> If Graal is used it should not have big impact since these metadata has regular pattern (32 handles per array >>>>>>>> and array per MetadataHandleBlock block which are linked in list) and not large. >>>>>>>> If there will be noticeable impact - we will work on it as you suggested by using ParallelCleaningTask. >>>>>>>> >>>>>>>>> >>>>>>>>> ======================================================================== >>>>>>>>> Did you consider adding it as a task for one of the worker threads to execute in ParallelCleaningTask? >>>>>>>>> >>>>>>>>> See how other tasks are claimed by one worker: >>>>>>>>> void KlassCleaningTask::work() { >>>>>>>>> ?? ResourceMark rm; >>>>>>>>> >>>>>>>>> ?? // One worker will clean the subklass/sibling klass tree. >>>>>>>>> ?? if (claim_clean_klass_tree_task()) { >>>>>>>>> ???? Klass::clean_subklass_tree(); >>>>>>>>> ?? } >>>>>>>> >>>>>>>> These changes were ported from JDK8u based changes in graal-jvmci-8 and there are no ParallelCleaningTask in JDK8. >>>>>>>> >>>>>>>> Your suggestion is interesting and I agree that we should investigate it. >>>>>>>> >>>>>>>>> >>>>>>>>> ======================================================================== >>>>>>>>> In MetadataHandleBlock::do_unloading: >>>>>>>>> >>>>>>>>> +??????? if (klass->class_loader_data()->is_unloading()) { >>>>>>>>> +????????? // This needs to be marked so that it's no longer scanned >>>>>>>>> +????????? // but can't be put on the free list yet. The >>>>>>>>> +????????? // ReferenceCleaner will set this to NULL and >>>>>>>>> +????????? // put it on the free list. >>>>>>>>> >>>>>>>>> I couldn't find the ReferenceCleaner in the patch or in the source. Where can I find this code? >>>>>>>> >>>>>>>> I think it is typo (I will fix it) - it references new HandleCleaner class: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HandleCleaner.java.html >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> StefanK >>>>>>>>> >>>>>>>>> On 2019-03-28 20:15, Vladimir Kozlov wrote: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8220623 >>>>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ >>>>>>>>>> >>>>>>>>>> Update JVMCI to support pre-compiled as shared library Graal. >>>>>>>>>> Using aoted Graal can offers benefits including: >>>>>>>>>> ?- fast startup >>>>>>>>>> ?- compile time similar to native JIt compilers (C2) >>>>>>>>>> ?- memory usage disjoint from the application Java heap >>>>>>>>>> ?- no profile pollution of JDK code used by the application >>>>>>>>>> >>>>>>>>>> This is JDK13 port of JVMCI changes done in graal-jvmci-8 [1] up to date. >>>>>>>>>> Changes were collected in Metropolis repo [2] and tested there. >>>>>>>>>> >>>>>>>>>> Changes we reviewed by Oracle Labs (authors of JVMCI and Graal) and our compiler group. >>>>>>>>>> Changes in shared code are guarded by #if INCLUDE_JVMCI and JVMCI flags. >>>>>>>>>> >>>>>>>>>> I ran tier1-tier8 (which includes HotSpot and JDK tests) and it was clean. In this set Graal was tested only >>>>>>>>>> in tier3. >>>>>>>>>> >>>>>>>>>> And I ran all hs-tier3-graal .. hs-tier8-graal Graal tests available in our system. Several issue were found >>>>>>>>>> which were present before these changes. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> [1] https://github.com/graalvm/graal-jvmci-8/commit/49ff2045fb603e35516a3a427d8023c00e1607af >>>>>>>>>> [2] http://hg.openjdk.java.net/metropolis/dev/ >>>>>>>>> From stefan.karlsson at oracle.com Thu Apr 4 08:10:59 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 4 Apr 2019 10:10:59 +0200 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: <3514c74d-5f6a-61cc-ebea-b9564df61673@oracle.com> References: <4b759550-f185-724f-7139-9bab648a1966@oracle.com> <119335f1-acb7-fffc-f38a-e50a96b73b3c@oracle.com> <2d206374-cfeb-9b1b-2838-e4e0a774e89d@oracle.com> <8063fb37-f1b0-8b93-bbe8-4dbeeaa54959@oracle.com> <17233985-18c7-305e-5556-fe2b38926b71@oracle.com> <3514c74d-5f6a-61cc-ebea-b9564df61673@oracle.com> Message-ID: GC delta looks good. Thanks, StefanK On 2019-04-04 09:22, Vladimir Kozlov wrote: > New delta: > http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.06/ > > Full: > http://cr.openjdk.java.net/~kvn/8220623/webrev.06/ > > New changes are based on Kim and Stefan suggestions: > > - Moved JVMCI::oops_do() from JNIHandles to places where it should be > called. > - Moved JVMCI cleanup task to the beginning of > ParallelCleaningTask::work(). > - Used JVMCI_ONLY macro with COMMA. > - Disable JVMCI build on SPARC. We don't use it - neither Graal or AOT > are built on SPARC. Disabling also helps to find missing JVMCI guards. > > I ran hs-tier1-3 testing - it passed (hs-tier3 includes graal testing). > I started hs-tier4..8-graal testing. > I will do performance testing next. > > Thanks, > Vladimir > > On 4/3/19 9:54 AM, Vladimir Kozlov wrote: >> On 4/2/19 11:35 PM, Stefan Karlsson wrote: >>> On 2019-04-02 22:41, Vladimir Kozlov wrote: >>>> I ran Kitchensink with G1 and -Xmx8g. I observed that Remark pause >>>> times are not consistent even without Graal. >>>> To see effect I added time spent in JVMCI::do_unloading() to GC log >>>> (see below [3]). The result is < 1ms - it is less than 1% of a pause >>>> time. >>> >>> Kitchensink isn't really a benchmark, but a stress test. I sent you a >>> private mail how to run these changes through our internal >>> performance test setup. >> >> Okay, I will run performance tests there too. >> >>> >>>> >>>> It will have even less effect since I moved JVMCI::do_unloading() >>>> from serial path to parallel worker thread as Stefan suggested. >>>> >>>> Stefan, are you satisfied with these changes now? >>> >>> Yes, the clean-ups look good. Thanks for cleaning this up. >>> >>> Kim had some extra comments about a few more places where JVMCI_ONLY >>> could be used. >>> >>> I also agree with him that JVMCI::oops_do should not be placed in >>> JNIHandles::oops_do. I think you should put it where you put the >>> AOTLoader::oops_do calls. >> >> Okay. >> >> Thanks, >> Vladimir >> >>> >>> Thanks, >>> StefanK >>> >>> >>>> >>>> Here is latest delta update which includes previous [1] delta and >>>> - use CompilerThreadStackSize * 2 for libgraal instead of exact value, >>>> - removed HandleMark added for debugging (reverted changes in >>>> jvmtiImpl.cpp), >>>> - added recent jvmci-8 changes to fix registration of native methods >>>> in libgraal (jvmciCompilerToVM.cpp) >>>> >>>> http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.05/ >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> [1] http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.04/ >>>> [2] Original webrev http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ >>>> [3] Pauses times from Kitchensink (0.0ms means there were no >>>> unloaded classes, 'NNN alive' shows how many metadata references >>>> were processed): >>>> >>>> [1.083s][1554229160638ms][info ][gc,start???? ] GC(2) Pause Remark >>>> [1.085s][1554229160639ms][info ][gc?????????? ] GC(2) >>>> JVMCI::do_unloading(): 0 alive 0.000ms >>>> [1.099s][1554229160654ms][info ][gc?????????? ] GC(2) Pause Remark >>>> 28M->28M(108M) 16.123ms >>>> >>>> [3.097s][1554229162651ms][info ][gc,start???? ] GC(12) Pause Remark >>>> [3.114s][1554229162668ms][info ][gc?????????? ] GC(12) >>>> JVMCI::do_unloading(): 3471 alive 0.164ms >>>> [3.148s][1554229162702ms][info ][gc?????????? ] GC(12) Pause Remark >>>> 215M->213M(720M) 51.103ms >>>> >>>> [455.111s][1554229614666ms][info ][gc,phases,start] GC(1095) Phase >>>> 1: Mark live objects >>>> [455.455s][1554229615010ms][info ][gc???????????? ] GC(1095) >>>> JVMCI::do_unloading(): 4048 alive 0.821ms >>>> [455.456s][1554229615010ms][info ][gc,phases????? ] GC(1095) Phase >>>> 1: Mark live objects 344.107ms >>>> >>>> [848.932s][1554230008486ms][info ][gc,phases,start] GC(1860) Phase >>>> 1: Mark live objects >>>> [849.248s][1554230008803ms][info ][gc???????????? ] GC(1860) >>>> JVMCI::do_unloading(): 3266 alive 0.470ms >>>> [849.249s][1554230008803ms][info ][gc,phases????? ] GC(1860) Phase >>>> 1: Mark live objects 316.527ms >>>> >>>> [1163.778s][1554230323332ms][info ][gc,start?????? ] GC(2627) Pause >>>> Remark >>>> [1163.932s][1554230323486ms][info ][gc???????????? ] GC(2627) >>>> JVMCI::do_unloading(): 3474 alive 0.642ms >>>> [1163.941s][1554230323496ms][info ][gc???????????? ] GC(2627) Pause >>>> Remark 2502M->2486M(4248M) 163.296ms >>>> >>>> [1242.587s][1554230402141ms][info ][gc,phases,start] GC(2734) Phase >>>> 1: Mark live objects >>>> [1242.899s][1554230402453ms][info ][gc???????????? ] GC(2734) >>>> JVMCI::do_unloading(): 3449 alive 0.570ms >>>> [1242.899s][1554230402453ms][info ][gc,phases????? ] GC(2734) Phase >>>> 1: Mark live objects 311.719ms >>>> >>>> [1364.164s][1554230523718ms][info ][gc,phases,start] GC(3023) Phase >>>> 1: Mark live objects >>>> [1364.613s][1554230524167ms][info ][gc???????????? ] GC(3023) >>>> JVMCI::do_unloading(): 3449 alive 0.000ms >>>> [1364.613s][1554230524167ms][info ][gc,phases????? ] GC(3023) Phase >>>> 1: Mark live objects 448.495ms >>>> >>>> [1425.222s][1554230584776ms][info ][gc,phases,start] GC(3151) Phase >>>> 1: Mark live objects >>>> [1425.587s][1554230585142ms][info ][gc???????????? ] GC(3151) >>>> JVMCI::do_unloading(): 3491 alive 0.882ms >>>> [1425.587s][1554230585142ms][info ][gc,phases????? ] GC(3151) Phase >>>> 1: Mark live objects 365.403ms >>>> >>>> [1456.401s][1554230615955ms][info ][gc,phases,start] GC(3223) Phase >>>> 1: Mark live objects >>>> [1456.769s][1554230616324ms][info ][gc???????????? ] GC(3223) >>>> JVMCI::do_unloading(): 3478 alive 0.616ms >>>> [1456.769s][1554230616324ms][info ][gc,phases????? ] GC(3223) Phase >>>> 1: Mark live objects 368.643ms >>>> >>>> [1806.139s][1554230965694ms][info?? ][gc,start?????? ] GC(4014) >>>> Pause Remark >>>> [1806.161s][1554230965716ms][info?? ][gc???????????? ] GC(4014) >>>> JVMCI::do_unloading(): 3478 alive 0.000ms >>>> [1806.163s][1554230965717ms][info?? ][gc???????????? ] GC(4014) >>>> Pause Remark 1305M->1177M(2772M) 23.190ms >>>> >>>> >>>> >>>> On 4/1/19 12:34 AM, Stefan Karlsson wrote: >>>>> On 2019-03-29 17:55, Vladimir Kozlov wrote: >>>>>> Stefan, >>>>>> >>>>>> Do you have a test (and flags) which can allow me to measure >>>>>> effect of this code on G1 remark pause? >>>>> >>>>> >>>>> -Xlog:gc prints the remark times: >>>>> [4,296s][info][gc?????? ] GC(89) Pause Remark 4M->4M(28M) 36,412ms >>>>> >>>>> StefanK >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 3/29/19 12:36 AM, Stefan Karlsson wrote: >>>>>>> On 2019-03-29 03:07, Vladimir Kozlov wrote: >>>>>>>> Hi Stefan, >>>>>>>> >>>>>>>> I collected some data on MetadataHandleBlock. >>>>>>>> >>>>>>>> First, do_unloading() code is executed only when >>>>>>>> class_unloading_occurred is 'true' - it is rare case. It should >>>>>>>> not affect normal G1 remark pause. >>>>>>> >>>>>>> It's only rare for applications that don't do dynamic class >>>>>>> loading and unloading. The applications that do, will be affected. >>>>>>> >>>>>>>> >>>>>>>> Second, I run a test with -Xcomp. I got about 10,000 >>>>>>>> compilations by Graal and next data at the end of execution: >>>>>>>> >>>>>>>> max_blocks = 232 >>>>>>>> max_handles_per_block = 32 (since handles array has 32 elements) >>>>>>>> max_total_alive_values = 4631 >>>>>>> >>>>>>> OK. Thanks for the info. >>>>>>> >>>>>>> StefanK >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 3/28/19 2:44 PM, Vladimir Kozlov wrote: >>>>>>>>> Thank you, Stefan >>>>>>>>> >>>>>>>>> On 3/28/19 12:54 PM, Stefan Karlsson wrote: >>>>>>>>>> Hi Vladimir, >>>>>>>>>> >>>>>>>>>> I started to check the GC code. >>>>>>>>>> >>>>>>>>>> ======================================================================== >>>>>>>>>> >>>>>>>>>> I see that you've added guarded includes in the middle of the >>>>>>>>>> include list: >>>>>>>>>> ?? #include "gc/shared/strongRootsScope.hpp" >>>>>>>>>> ?? #include "gc/shared/weakProcessor.hpp" >>>>>>>>>> + #if INCLUDE_JVMCI >>>>>>>>>> + #include "jvmci/jvmci.hpp" >>>>>>>>>> + #endif >>>>>>>>>> ?? #include "oops/instanceRefKlass.hpp" >>>>>>>>>> ?? #include "oops/oop.inline.hpp" >>>>>>>>>> >>>>>>>>>> The style we use is to put these conditional includes at the >>>>>>>>>> end of the include lists. >>>>>>>>> >>>>>>>>> okay >>>>>>>>> >>>>>>>>>> >>>>>>>>>> ======================================================================== >>>>>>>>>> >>>>>>>>>> Could you also change the following: >>>>>>>>>> >>>>>>>>>> + #if INCLUDE_JVMCI >>>>>>>>>> +???? // Clean JVMCI metadata handles. >>>>>>>>>> +???? JVMCI::do_unloading(is_alive_closure(), purged_class); >>>>>>>>>> + #endif >>>>>>>>>> >>>>>>>>>> to: >>>>>>>>>> +???? // Clean JVMCI metadata handles. >>>>>>>>>> +???? JVMCI_ONLY(JVMCI::do_unloading(is_alive_closure(), >>>>>>>>>> purged_class);) >>>>>>>>>> >>>>>>>>>> to get rid of some of the line noise in the GC files. >>>>>>>>> >>>>>>>>> okay >>>>>>>>> >>>>>>>>>> >>>>>>>>>> ======================================================================== >>>>>>>>>> >>>>>>>>>> In the future we will need version of JVMCI::do_unloading that >>>>>>>>>> supports concurrent cleaning for ZGC. >>>>>>>>> >>>>>>>>> Yes, we need to support concurrent cleaning in a future. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> ======================================================================== >>>>>>>>>> >>>>>>>>>> What's the performance impact for G1 remark pause with this >>>>>>>>>> serial walk over the MetadataHandleBlock? >>>>>>>>>> >>>>>>>>>> 3275 void >>>>>>>>>> G1CollectedHeap::complete_cleaning(BoolObjectClosure* is_alive, >>>>>>>>>> 3276???????????????????????????????????????? bool >>>>>>>>>> class_unloading_occurred) { >>>>>>>>>> 3277?? uint num_workers = workers()->active_workers(); >>>>>>>>>> 3278?? ParallelCleaningTask unlink_task(is_alive, num_workers, >>>>>>>>>> class_unloading_occurred, false); >>>>>>>>>> 3279?? workers()->run_task(&unlink_task); >>>>>>>>>> 3280 #if INCLUDE_JVMCI >>>>>>>>>> 3281?? // No parallel processing of JVMCI metadata handles for >>>>>>>>>> now. >>>>>>>>>> 3282?? JVMCI::do_unloading(is_alive, class_unloading_occurred); >>>>>>>>>> 3283 #endif >>>>>>>>>> 3284 } >>>>>>>>> >>>>>>>>> There should not be impact if Graal is not used. Only cost of >>>>>>>>> call (which most likely is inlined in product VM) and check: >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/metropolis/dev/file/530fc1427d02/src/hotspot/share/jvmci/jvmciRuntime.cpp#l1237 >>>>>>>>> >>>>>>>>> >>>>>>>>> If Graal is used it should not have big impact since these >>>>>>>>> metadata has regular pattern (32 handles per array and array >>>>>>>>> per MetadataHandleBlock block which are linked in list) and not >>>>>>>>> large. >>>>>>>>> If there will be noticeable impact - we will work on it as you >>>>>>>>> suggested by using ParallelCleaningTask. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> ======================================================================== >>>>>>>>>> >>>>>>>>>> Did you consider adding it as a task for one of the worker >>>>>>>>>> threads to execute in ParallelCleaningTask? >>>>>>>>>> >>>>>>>>>> See how other tasks are claimed by one worker: >>>>>>>>>> void KlassCleaningTask::work() { >>>>>>>>>> ?? ResourceMark rm; >>>>>>>>>> >>>>>>>>>> ?? // One worker will clean the subklass/sibling klass tree. >>>>>>>>>> ?? if (claim_clean_klass_tree_task()) { >>>>>>>>>> ???? Klass::clean_subklass_tree(); >>>>>>>>>> ?? } >>>>>>>>> >>>>>>>>> These changes were ported from JDK8u based changes in >>>>>>>>> graal-jvmci-8 and there are no ParallelCleaningTask in JDK8. >>>>>>>>> >>>>>>>>> Your suggestion is interesting and I agree that we should >>>>>>>>> investigate it. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> ======================================================================== >>>>>>>>>> >>>>>>>>>> In MetadataHandleBlock::do_unloading: >>>>>>>>>> >>>>>>>>>> +??????? if (klass->class_loader_data()->is_unloading()) { >>>>>>>>>> +????????? // This needs to be marked so that it's no longer >>>>>>>>>> scanned >>>>>>>>>> +????????? // but can't be put on the free list yet. The >>>>>>>>>> +????????? // ReferenceCleaner will set this to NULL and >>>>>>>>>> +????????? // put it on the free list. >>>>>>>>>> >>>>>>>>>> I couldn't find the ReferenceCleaner in the patch or in the >>>>>>>>>> source. Where can I find this code? >>>>>>>>> >>>>>>>>> I think it is typo (I will fix it) - it references new >>>>>>>>> HandleCleaner class: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HandleCleaner.java.html >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> StefanK >>>>>>>>>> >>>>>>>>>> On 2019-03-28 20:15, Vladimir Kozlov wrote: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8220623 >>>>>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ >>>>>>>>>>> >>>>>>>>>>> Update JVMCI to support pre-compiled as shared library Graal. >>>>>>>>>>> Using aoted Graal can offers benefits including: >>>>>>>>>>> ?- fast startup >>>>>>>>>>> ?- compile time similar to native JIt compilers (C2) >>>>>>>>>>> ?- memory usage disjoint from the application Java heap >>>>>>>>>>> ?- no profile pollution of JDK code used by the application >>>>>>>>>>> >>>>>>>>>>> This is JDK13 port of JVMCI changes done in graal-jvmci-8 [1] >>>>>>>>>>> up to date. >>>>>>>>>>> Changes were collected in Metropolis repo [2] and tested there. >>>>>>>>>>> >>>>>>>>>>> Changes we reviewed by Oracle Labs (authors of JVMCI and >>>>>>>>>>> Graal) and our compiler group. >>>>>>>>>>> Changes in shared code are guarded by #if INCLUDE_JVMCI and >>>>>>>>>>> JVMCI flags. >>>>>>>>>>> >>>>>>>>>>> I ran tier1-tier8 (which includes HotSpot and JDK tests) and >>>>>>>>>>> it was clean. In this set Graal was tested only in tier3. >>>>>>>>>>> >>>>>>>>>>> And I ran all hs-tier3-graal .. hs-tier8-graal Graal tests >>>>>>>>>>> available in our system. Several issue were found which were >>>>>>>>>>> present before these changes. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> [1] >>>>>>>>>>> https://github.com/graalvm/graal-jvmci-8/commit/49ff2045fb603e35516a3a427d8023c00e1607af >>>>>>>>>>> >>>>>>>>>>> [2] http://hg.openjdk.java.net/metropolis/dev/ >>>>>>>>>> From adinn at redhat.com Thu Apr 4 10:00:12 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 4 Apr 2019 11:00:12 +0100 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: <8f5a146f-6053-46fc-be91-2f1900a55852@oracle.com> References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <8b0f5b4c-0386-1440-6939-646daf36aa55@redhat.com> <24b4bb72-732e-0447-d1be-dd71507e7787@redhat.com> <8ab058fe-886b-643f-f602-c27182d6f584@oracle.com> <2dbe8e0b-a8b5-9129-db24-9ef761bf9741@redhat.com> <8f5a146f-6053-46fc-be91-2f1900a55852@oracle.com> Message-ID: Hi Coleen, Thanks for the follow-up reply. On 04/04/2019 01:25, coleen.phillimore at oracle.com wrote: > Yes, I see the advantage to it.? I wish it were more compact but it's > fine the way it you've written it. Ok, I'll keep this as is then. >>> The cast is unnecessary.? UnsafeConstants_klass returns an >>> InstanceKlass. >> Ah, ok, I cut and pasted this from the equivalent code for String. >> Perhaps I should fix that as well. > > Please, fix that one too.? I've had several passes removing > InstanceKlass::cast()s but they keep sneaking in. Sure, will do. > Actually the field names are fine, I don't like that we have to add them > to vmSymbols.hpp.? But that's how the code works. > > Thank you for the rationale of the naming though.? It makes sense. Well, thank you for asking me to provide an explanation as it has made me understand better and reconsider slightly the choices. If it is not the actual choice of names that concerns you then I think it would be an improvement if I tried harder to follow my original plan and statically import all the UnsafeConstants fields as replacements for the existing Unsafe ones (where present). I believe I can finesse the problem that Unsafe.ADDRESS_SIZE is public. So, that means: adding 'import static UnsafeConstants.*;' to Unsafe.java renaming UnsafeConstants.BIG_ENDIAN to UnsafeConstants.BE and removing the corresponding field Unsafe.BE finessing the public visibility of Unsafe.ADDRESS_SIZE by renaming UnsafeConstants.ADDRESS_SIZE to UnsafeConstants.ADDRESS_SIZE0 while retaining public field Unsafe.ADDRESS_SIZE but initializing it to UnsafeConstants.ADDRESS_SIZE0 The last change is to avoid a name clash from the 'import static ...' I'll post a follow-up linking to a new webrev which answers your comments and David's. regards, Andrew Dinn ----------- From matthias.baesken at sap.com Thu Apr 4 10:54:43 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 4 Apr 2019 10:54:43 +0000 Subject: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: References: <98b6c488-a935-9b43-7382-5bfc732f0ac7@oracle.com> <2f68463c-be1c-9d34-6202-72613cb7438d@oracle.com> <2c61ef7c-91f0-9636-5567-eaf8bbff7c94@oracle.com> <30b2b3c5-38f7-8569-10cd-e781129b5da5@oracle.com> Message-ID: > > My remaining query is why we need the OS specific checks and code in > os-cpu files? Isn't this just cpu specific? Even if a particular OS > doesn't support virtualization, won't the cpuid query simply report "no > virtualization"? > Hi David, if you are referring to these os-cpu files : src/hotspot/os_cpu/linux_x86/vm_version_linux_x86.cpp src/hotspot/os_cpu/windows_x86/vm_version_windows_x86.cpp we have different coding available because I am not aware of a cross OS API/coding to get the cpu id info. That?s why different coding for LINUX/Windows. Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Donnerstag, 4. April 2019 03:16 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Cc: Doerr, Martin > Subject: Re: RFR: 8219241: Provide basic virtualization related info in the > hs_error file on linux/windows x86_64 > > Hi Matthias, > > This is looking much better/simpler - thanks! > > My remaining query is why we need the OS specific checks and code in > os-cpu files? Isn't this just cpu specific? Even if a particular OS > doesn't support virtualization, won't the cpuid query simply report "no > virtualization"? > > Thanks, > David > > On 4/04/2019 12:43 am, Baesken, Matthias wrote: > >> 1. Why do we have/need os::::print_virtualization_info when we also > >> have VM_Version::print_platform_virtualization_info? > >> > > > > Hi David, I have to agree - we do not really need both . > > So I removed os::::print_virtualization_info and call > VM_Version::print_platform_virtualization_info(st); at the places where > the output is done. > > > > Regarding point 2. : > > > > I now just use print_platform_virtualization_info, > print_detected_virtualization has been removed . > > print_platform_virtualization_info is doing the output (differs for > vm_version_ s390 / ppc / x86_64 ) . > > > > The new webrev is simpler, with less methods : > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8219241.4/ > > > > Best regards, Matthias > > > > > >> -----Original Message----- > >> From: David Holmes > >> Sent: Freitag, 29. M?rz 2019 01:16 > >> To: Baesken, Matthias ; 'hotspot- > >> dev at openjdk.java.net' > >> Cc: Doerr, Martin > >> Subject: Re: RFR: 8219241: Provide basic virtualization related info in the > >> hs_error file on linux/windows x86_64 > >> > >> Hi Matthias, > >> > >> I have two issues with this API: > >> > >> 1. Why do we have/need os::::print_virtualization_info when we also > >> have VM_Version::print_platform_virtualization_info? > >> > >> 2. I don't like the fact that the there are two ways to define the > >> platform specific information: > >> a) override VM_Version::print_platform_virtualization_info; or > >> b) hook into the get_detected_virtualization switch > >> > >> And IIUC code that uses (a) relies on the switch doing nothing > >> (NoVirtualization) and code that uses (b) relies on > >> print_platform_virtualization_info doing nothing! > >> > >> Why doesn't the default implementation of > >> VM_Version::print_platform_virtualization_info define the > >> get_detected_virtualization() switch logic, and do away with > >> Abstract_VM_Version::print_detected_virtualization? Code that wants to > >> print this info can just call > >> VM_Version::print_platform_virtualization_info(). > >> > >> Sorry but I just find the current proposal has too many methods and an > >> unclear structure. > >> > >> David > > From david.holmes at oracle.com Thu Apr 4 11:17:34 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 4 Apr 2019 21:17:34 +1000 Subject: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: References: <98b6c488-a935-9b43-7382-5bfc732f0ac7@oracle.com> <2f68463c-be1c-9d34-6202-72613cb7438d@oracle.com> <2c61ef7c-91f0-9636-5567-eaf8bbff7c94@oracle.com> <30b2b3c5-38f7-8569-10cd-e781129b5da5@oracle.com> Message-ID: On 4/04/2019 8:54 pm, Baesken, Matthias wrote: >> >> My remaining query is why we need the OS specific checks and code in >> os-cpu files? Isn't this just cpu specific? Even if a particular OS >> doesn't support virtualization, won't the cpuid query simply report "no >> virtualization"? >> > > Hi David, if you are referring to these os-cpu files : > > src/hotspot/os_cpu/linux_x86/vm_version_linux_x86.cpp > src/hotspot/os_cpu/windows_x86/vm_version_windows_x86.cpp > > we have different coding available because I am not aware of a cross OS API/coding to get the cpu id info. > That?s why different coding for LINUX/Windows. ?? But there's nothing in those added functions that is Linux specific or Windows specific! The only difference is the mechanism for doing "inline assembly" and that's compiler specific. So this should just use compiler based ifdefs in vm_version_x86.cpp. Cheers, David > > Best regards, Matthias > > >> -----Original Message----- >> From: David Holmes >> Sent: Donnerstag, 4. April 2019 03:16 >> To: Baesken, Matthias ; 'hotspot- >> dev at openjdk.java.net' >> Cc: Doerr, Martin >> Subject: Re: RFR: 8219241: Provide basic virtualization related info in the >> hs_error file on linux/windows x86_64 >> >> Hi Matthias, >> >> This is looking much better/simpler - thanks! >> >> My remaining query is why we need the OS specific checks and code in >> os-cpu files? Isn't this just cpu specific? Even if a particular OS >> doesn't support virtualization, won't the cpuid query simply report "no >> virtualization"? >> >> Thanks, >> David >> >> On 4/04/2019 12:43 am, Baesken, Matthias wrote: >>>> 1. Why do we have/need os::::print_virtualization_info when we also >>>> have VM_Version::print_platform_virtualization_info? >>>> >>> >>> Hi David, I have to agree - we do not really need both . >>> So I removed os::::print_virtualization_info and call >> VM_Version::print_platform_virtualization_info(st); at the places where >> the output is done. >>> >>> Regarding point 2. : >>> >>> I now just use print_platform_virtualization_info, >> print_detected_virtualization has been removed . >>> print_platform_virtualization_info is doing the output (differs for >> vm_version_ s390 / ppc / x86_64 ) . >>> >>> The new webrev is simpler, with less methods : >>> >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8219241.4/ >>> >>> Best regards, Matthias >>> >>> >>>> -----Original Message----- >>>> From: David Holmes >>>> Sent: Freitag, 29. M?rz 2019 01:16 >>>> To: Baesken, Matthias ; 'hotspot- >>>> dev at openjdk.java.net' >>>> Cc: Doerr, Martin >>>> Subject: Re: RFR: 8219241: Provide basic virtualization related info in the >>>> hs_error file on linux/windows x86_64 >>>> >>>> Hi Matthias, >>>> >>>> I have two issues with this API: >>>> >>>> 1. Why do we have/need os::::print_virtualization_info when we also >>>> have VM_Version::print_platform_virtualization_info? >>>> >>>> 2. I don't like the fact that the there are two ways to define the >>>> platform specific information: >>>> a) override VM_Version::print_platform_virtualization_info; or >>>> b) hook into the get_detected_virtualization switch >>>> >>>> And IIUC code that uses (a) relies on the switch doing nothing >>>> (NoVirtualization) and code that uses (b) relies on >>>> print_platform_virtualization_info doing nothing! >>>> >>>> Why doesn't the default implementation of >>>> VM_Version::print_platform_virtualization_info define the >>>> get_detected_virtualization() switch logic, and do away with >>>> Abstract_VM_Version::print_detected_virtualization? Code that wants to >>>> print this info can just call >>>> VM_Version::print_platform_virtualization_info(). >>>> >>>> Sorry but I just find the current proposal has too many methods and an >>>> unclear structure. >>>> >>>> David >>> From goetz.lindenmaier at sap.com Thu Apr 4 11:53:42 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 4 Apr 2019 11:53:42 +0000 Subject: 8219918: ProblemList tests failing in SAP testing. In-Reply-To: References: <7c80c989-48cd-3689-36ff-cdc0f2ac6003@oracle.com> <50a7ad12-9d70-c838-1baa-5d0ee6337c85@oracle.com> Message-ID: Hi, this is still not pushed ... some bugs were fixed in the meantime. This leaves only the aix failures on the list. http://cr.openjdk.java.net/~goetz/wr19/8219918-problemList/03/ Best regards, Goetz. > -----Original Message----- > From: hotspot-dev On Behalf Of > Lindenmaier, Goetz > Sent: Freitag, 1. M?rz 2019 08:07 > To: hotspot-dev at openjdk.java.net > Subject: RE: 8219918: ProblemList tests failing in SAP testing. > > Hi, > > I changed this to only ProblemList hotspot tests. > Please review. > http://cr.openjdk.java.net/~goetz/wr19/8219918-problemList/02/ > > Best regards, > Goetz. > > > > -----Original Message----- > > From: Daniel D. Daugherty > > Sent: Thursday, February 28, 2019 4:48 PM > > To: Alan Bateman ; Lindenmaier, Goetz > > ; hotspot-dev at openjdk.java.net > > Subject: Re: 8219918: ProblemList tests failing in SAP testing. > > > > On 2/28/19 8:36 AM, Alan Bateman wrote: > > > On 28/02/2019 13:05, Lindenmaier, Goetz wrote: > > >> Hi, > > >> > > >> in our testing we see a few tests failing at least since the jdk 11 > > >> release. > > >> I opened bugs for these issues and would like to add them to > > >> the ProblemLists for now: > > >> > > >> http://cr.openjdk.java.net/~goetz/wr19/8219918-problemList/01/ > > >> > > >> I don't think any of these issues are critical. > > >> > > > > > > This excludes the the CopyAndMove.java test which is critical to > > > testing the Files.copy/move APIs. Can you start a discussion on > > > nio-dev with info about the test environment rather than excluding > > > this really important test. > > > > > > -Alan > > > > In the bug there is a mix of hotspot and jdk tests and this review > > request was only sent to hotspot-dev at ... I think trying to do this > > in one bug is not quite appropriate for review purposes. Perhaps > > an umbrella bug with subtasks? Dunno... > > > > Dan From matthias.baesken at sap.com Thu Apr 4 12:35:19 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 4 Apr 2019 12:35:19 +0000 Subject: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: References: <98b6c488-a935-9b43-7382-5bfc732f0ac7@oracle.com> <2f68463c-be1c-9d34-6202-72613cb7438d@oracle.com> <2c61ef7c-91f0-9636-5567-eaf8bbff7c94@oracle.com> <30b2b3c5-38f7-8569-10cd-e781129b5da5@oracle.com> Message-ID: > > On 4/04/2019 8:54 pm, Baesken, Matthias wrote: > >> > >> My remaining query is why we need the OS specific checks and code in > >> os-cpu files? Isn't this just cpu specific? Even if a particular OS > >> doesn't support virtualization, won't the cpuid query simply report "no > >> virtualization"? > >> > > > > Hi David, if you are referring to these os-cpu files : > > > > src/hotspot/os_cpu/linux_x86/vm_version_linux_x86.cpp > > src/hotspot/os_cpu/windows_x86/vm_version_windows_x86.cpp > > > > we have different coding available because I am not aware of a cross OS > API/coding to get the cpu id info. > > That?s why different coding for LINUX/Windows. > > ?? But there's nothing in those added functions that is Linux specific > or Windows specific! The only difference is the mechanism for doing > "inline assembly" and that's compiler specific. So this should just use > compiler based ifdefs in vm_version_x86.cpp. > Hi David, I see your point. But I thought we want to reduce the ifdefs and favor putting code into the os or os/cpu specific files . But it is true , from a technical point we could do using the compiler macros . Best regards, Matthias From erik.joelsson at oracle.com Thu Apr 4 13:36:49 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 4 Apr 2019 06:36:49 -0700 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> Message-ID: <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> Hello Kim, On 2019-04-03 16:34, Kim Barrett wrote: >> On Apr 3, 2019, at 9:51 AM, Erik Joelsson wrote: >> On 2019-04-02 16:02, Kim Barrett wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221851 >>>> >>>> Webrev: http://cr.openjdk.java.net/~erikj/8221851/webrev.01/index.html >>>> >>>> /Erik >>> Here's an alternative approach that seems simpler. [?] >> This kind of solution will also work. It's worth noting that your fix will work like basename and just print the filename (as the current state in hotspot does for exceptions if compiled with GCC). I think printing the complete relative path to the workspace root is an improvement over this, and I think the only reason it's currently printing just the filename is that that's what appeared available as an alternative. The issue with truncated paths is mostly happening on our internal Mach5 builds where the workspace root is usually located in an extremely deep path hierarchy. > I disagree that it's mostly a problem on our internal Mach5 builds. > There are paths in my development repos that exceed the clipped size > in the examples in that bug, and I don't think I have a very deep > hierarchy. Using a workspace-relative path in exception messages might > be enough to still address JDK-8204551 though. Right, even more reason to find a solution then. >> Additionally, I would like to replace all (or at least most) instances of __FILE__ with my new THIS_FILE, and I suspect some other places would be more performance sensitive. Do you see any problem with doing that substitution? > Given that our build system is mostly unhappy with basename collisions > (other than open/custom overrides), I don't think there's much of a > usage problem with using a basename-like approach everywhere either. It's also allowed, though perhaps not used, to override less specific files with more specific, as in OS specific file foo.cpp would override shared foo.cpp. I won't update the other references in this patch. I will see if anyone else thinks it's a good enough idea to give it a go. That kind of change would not affect the build, nor the full paths in binaries, just (hopefully) improve readability of error/log messages. > While researching what various platforms do in this area, I ran across > a suggestion that debug builds should maybe use full paths and release > builds use shortened paths. That seems like an interesting idea, though > we still want short paths in the exceptions.hpp case. If you really think this is worth it, I could implement it, but I would rather keep it the same if possible. > I tend to expect (modern) compilers to be pretty good at obvious > optimizations, though admit I'm occasionally sadly disappointed. > >>> This doesn't eliminate the full pathname string embedded in the >>> executable, but I don't think the proposed FILE_MACRO_OFFSET will do >>> that either. Those get fixed by -fmacro-prefix-map=. >> Correct. While solving this universally would be nice, it wasn't the goal of this bug. The main goal was to get precompiled headers to work with GCC again. > I agree that either approach does that. I looked at the webrev and > it's a bunch of build system changes that I don't feel qualified to > review, so I suggested an alternative that I understand. We each have > our preferred tools. I don't object to the build-system-based > approach, just can't give an actual thumbs-up. Right, and I appreciate the input! But could you at least review the hotspot part, so I can get someone else to review the build part? /Erik From aph at redhat.com Thu Apr 4 13:53:10 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 4 Apr 2019 14:53:10 +0100 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <5ddacc0b-a534-d751-73fa-3e2af7a70065@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <571f3d72-a22a-3b52-2942-6408072e353f@oracle.com> <144af13e-33e2-2089-f8d2-902e94485eb1@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> Message-ID: <8b4629d4-6b3a-0e29-82f8-760719c5daeb@redhat.com> On 4/4/19 8:00 AM, Tobias Hartmann 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? > Someone should review/test the aarch64/arm/ppc changes. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From jamsheed.c.m at oracle.com Thu Apr 4 14:33:32 2019 From: jamsheed.c.m at oracle.com (Jamsheed) Date: Thu, 4 Apr 2019 20:03:32 +0530 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <8b4629d4-6b3a-0e29-82f8-760719c5daeb@redhat.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <571f3d72-a22a-3b52-2942-6408072e353f@oracle.com> <144af13e-33e2-2089-f8d2-902e94485eb1@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> Message-ID: <23b32dbd-9264-92df-3add-8a7daa9f65e4@oracle.com> On 04/04/19 7:23 PM, Andrew Haley wrote: > On 4/4/19 8:00 AM, Tobias Hartmann 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? yes, agree. instead will is is_oop check to not to capture. Best regards, Jamsheed From adinn at redhat.com Thu Apr 4 15:19:08 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 4 Apr 2019 16:19:08 +0100 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> Message-ID: <49615c26-8ad8-ca99-a66f-d5884164d99f@redhat.com> New webrev is now available. Re-reviews welcome. JIRA: https://bugs.openjdk.java.net/browse/JDK-8221477 Webrev: http://cr.openjdk.java.net/~adinn/8221477/webrev.03 This version should address all comments from Thomas, David and Coleen. Testing Tier1 test passed. Submit test passed. 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 coleen.phillimore at oracle.com Thu Apr 4 18:20:46 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 4 Apr 2019 14:20:46 -0400 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <8b0f5b4c-0386-1440-6939-646daf36aa55@redhat.com> <24b4bb72-732e-0447-d1be-dd71507e7787@redhat.com> <8ab058fe-886b-643f-f602-c27182d6f584@oracle.com> <2dbe8e0b-a8b5-9129-db24-9ef761bf9741@redhat.com> <8f5a146f-6053-46fc-be91-2f1900a55852@oracle.com> Message-ID: On 4/4/19 6:00 AM, Andrew Dinn wrote: > Hi Coleen, > > Thanks for the follow-up reply. > > On 04/04/2019 01:25, coleen.phillimore at oracle.com wrote: >> Yes, I see the advantage to it.? I wish it were more compact but it's >> fine the way it you've written it. > Ok, I'll keep this as is then. > >>>> The cast is unnecessary.? UnsafeConstants_klass returns an >>>> InstanceKlass. >>> Ah, ok, I cut and pasted this from the equivalent code for String. >>> Perhaps I should fix that as well. >> Please, fix that one too.? I've had several passes removing >> InstanceKlass::cast()s but they keep sneaking in. > Sure, will do. > >> Actually the field names are fine, I don't like that we have to add them >> to vmSymbols.hpp.? But that's how the code works. >> >> Thank you for the rationale of the naming though.? It makes sense. > Well, thank you for asking me to provide an explanation as it has made > me understand better and reconsider slightly the choices. If it is not > the actual choice of names that concerns you then I think it would be an > improvement if I tried harder to follow my original plan and statically > import all the UnsafeConstants fields as replacements for the existing > Unsafe ones (where present). I believe I can finesse the problem that > Unsafe.ADDRESS_SIZE is public. So, that means: > > adding 'import static UnsafeConstants.*;' to Unsafe.java > > renaming UnsafeConstants.BIG_ENDIAN to UnsafeConstants.BE and removing > the corresponding field Unsafe.BE > > finessing the public visibility of Unsafe.ADDRESS_SIZE by renaming > UnsafeConstants.ADDRESS_SIZE to UnsafeConstants.ADDRESS_SIZE0 while > retaining public field Unsafe.ADDRESS_SIZE but initializing it to > UnsafeConstants.ADDRESS_SIZE0 > > The last change is to avoid a name clash from the 'import static ...' I see this now. This does look better. Coleen > > I'll post a follow-up linking to a new webrev which answers your > comments and David's. > > regards, > > > Andrew Dinn > ----------- > From coleen.phillimore at oracle.com Thu Apr 4 18:25:34 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 4 Apr 2019 14:25:34 -0400 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: <49615c26-8ad8-ca99-a66f-d5884164d99f@redhat.com> References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <49615c26-8ad8-ca99-a66f-d5884164d99f@redhat.com> Message-ID: This version looks good.? I think I like the do_static_fields implementation better now. Thanks, Coleen On 4/4/19 11:19 AM, Andrew Dinn wrote: > New webrev is now available. Re-reviews welcome. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8221477 > Webrev: http://cr.openjdk.java.net/~adinn/8221477/webrev.03 > > This version should address all comments from Thomas, David and Coleen. > > Testing > Tier1 test passed. > Submit test passed. > > 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 kim.barrett at oracle.com Thu Apr 4 20:49:27 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 4 Apr 2019 16:49:27 -0400 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: <3514c74d-5f6a-61cc-ebea-b9564df61673@oracle.com> References: <4b759550-f185-724f-7139-9bab648a1966@oracle.com> <119335f1-acb7-fffc-f38a-e50a96b73b3c@oracle.com> <2d206374-cfeb-9b1b-2838-e4e0a774e89d@oracle.com> <8063fb37-f1b0-8b93-bbe8-4dbeeaa54959@oracle.com> <17233985-18c7-305e-5556-fe2b38926b71@oracle.com> <3514c74d-5f6a-61cc-ebea-b9564df61673@oracle.com> Message-ID: > On Apr 4, 2019, at 3:22 AM, Vladimir Kozlov wrote: > > New delta: > http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.06/ > > Full: > http://cr.openjdk.java.net/~kvn/8220623/webrev.06/ > > New changes are based on Kim and Stefan suggestions: > > - Moved JVMCI::oops_do() from JNIHandles to places where it should be called. > - Moved JVMCI cleanup task to the beginning of ParallelCleaningTask::work(). > - Used JVMCI_ONLY macro with COMMA. > - Disable JVMCI build on SPARC. We don't use it - neither Graal or AOT are built on SPARC. Disabling also helps to find missing JVMCI guards. > > I ran hs-tier1-3 testing - it passed (hs-tier3 includes graal testing). > I started hs-tier4..8-graal testing. > I will do performance testing next. ------------------------------------------------------------------------------ src/hotspot/share/jvmci/jvmci.hpp There is this new header file, declaring the JVMCI class. But the implementation seems to all be in JVMCIRuntime.cpp. That's pretty atypical code organization in HotSpot. ------------------------------------------------------------------------------ src/hotspot/share/jvmci/jvmci.hpp 46 static JNIHandleBlock* _object_handles; We moved away from JNIHandleBlock for "globals" (JNI global handles, JNI global weak handles), replacing those uses with OopStorage, because JNIHandleBlock and the way it was being used for "globals" had various thread-safety issues. JNIHandleBlock was retained for use with local handles, where thread-safety isn't an issue for the most part. Trying to have a chain of blocks data structure that supported both usage models was deemed to impose undesirable overhead on one or the other (or both) use cases. So, how have those issues been addressed in the new uses introduced by JVMCI? Should JVMCI be using OopStorage rather than JNIHandleBlock? (Yes, it should.) Further searching, and JVMCI::is_global_handle is racy and can crash, just like JDK-8174790. ------------------------------------------------------------------------------ src/hotspot/share/jvmci/jvmci.hpp src/hotspot/share/jvmci/jvmciRuntime.cpp 1198 jobject JVMCI::make_global(Handle obj) { 1199 assert(_object_handles != NULL, "uninitialized"); 1200 MutexLocker ml(JVMCI_lock); 1201 return _object_handles->allocate_handle(obj()); 1202 } This is returning a new kind of "jobject" that JNI knows nothing about! Any sort of JNI handle checking (such as is enabled by -Xcheck:jni) will fail for one of these. It looks like JVMCI used to be using JNI directly, but there has been some decision to separate it into it's own near copy. Why? Maybe these pseudo-jobjects aren't supposed to ever be passed to a "normal" JNI function. If that's true, they should have a different type, and not be jobject at all. ------------------------------------------------------------------------------ src/hotspot/share/prims/jni.cpp 1321 Klass* klass = java_lang_Class::as_Klass(JNIHandles::resolve_non_null(clazz)); Pre-existing: why are we resolving clazz twice, here and a few lines away for the is_primitive check? ------------------------------------------------------------------------------ I've just started looking at the MetadataHandle stuff, and don't have any comments there yet. From kim.barrett at oracle.com Thu Apr 4 20:57:47 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 4 Apr 2019 16:57:47 -0400 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: <3514c74d-5f6a-61cc-ebea-b9564df61673@oracle.com> References: <4b759550-f185-724f-7139-9bab648a1966@oracle.com> <119335f1-acb7-fffc-f38a-e50a96b73b3c@oracle.com> <2d206374-cfeb-9b1b-2838-e4e0a774e89d@oracle.com> <8063fb37-f1b0-8b93-bbe8-4dbeeaa54959@oracle.com> <17233985-18c7-305e-5556-fe2b38926b71@oracle.com> <3514c74d-5f6a-61cc-ebea-b9564df61673@oracle.com> Message-ID: > On Apr 4, 2019, at 3:22 AM, Vladimir Kozlov wrote: > > New delta: > http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.06/ > > Full: > http://cr.openjdk.java.net/~kvn/8220623/webrev.06/ > > New changes are based on Kim and Stefan suggestions: > > - Moved JVMCI::oops_do() from JNIHandles to places where it should be called. > - Moved JVMCI cleanup task to the beginning of ParallelCleaningTask::work(). > - Used JVMCI_ONLY macro with COMMA. > - Disable JVMCI build on SPARC. We don't use it - neither Graal or AOT are built on SPARC. Disabling also helps to find missing JVMCI guards. > > I ran hs-tier1-3 testing - it passed (hs-tier3 includes graal testing). > I started hs-tier4..8-graal testing. > I will do performance testing next. ------------------------------------------------------------------------------ src/hotspot/share/jvmci/jvmciJavaClasses.hpp 28 #include "runtime/jniHandles.inline.hpp" .hpp files are not permitted to #include .inline.hpp files. We've fixed most violations (I think there are still a few lingering ones that have not yet been disentangled); please don't add new ones. ------------------------------------------------------------------------------ From kim.barrett at oracle.com Thu Apr 4 21:26:12 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 4 Apr 2019 17:26:12 -0400 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> Message-ID: <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> > On Apr 4, 2019, at 9:36 AM, Erik Joelsson wrote: > > Hello Kim, > > On 2019-04-03 16:34, Kim Barrett wrote: >>> On Apr 3, 2019, at 9:51 AM, Erik Joelsson wrote:Additionally, I would like to replace all (or at least most) instances of __FILE__ with my new THIS_FILE, and I suspect some other places would be more performance sensitive. Do you see any problem with doing that substitution? >> Given that our build system is mostly unhappy with basename collisions >> (other than open/custom overrides), I don't think there's much of a >> usage problem with using a basename-like approach everywhere either. > > It's also allowed, though perhaps not used, to override less specific files with more specific, as in OS specific file foo.cpp would override shared foo.cpp. I didn?t know that. I don?t think that feature is being used, though could be mistaken. > I won't update the other references in this patch. I will see if anyone else thinks it's a good enough idea to give it a go. That kind of change would not affect the build, nor the full paths in binaries, just (hopefully) improve readability of error/log messages. OK. >> While researching what various platforms do in this area, I ran across >> a suggestion that debug builds should maybe use full paths and release >> builds use shortened paths. That seems like an interesting idea, though >> we still want short paths in the exceptions.hpp case. > If you really think this is worth it, I could implement it, but I would rather keep it the same if possible. Not sure. The point would be to provide full paths in builds that developers are using, but not expose full paths in shipped binaries. But I don?t have a strong opinion. >>>> This doesn't eliminate the full pathname string embedded in the >>>> executable, but I don't think the proposed FILE_MACRO_OFFSET will do >>>> that either. Those get fixed by -fmacro-prefix-map=. >>> Correct. While solving this universally would be nice, it wasn't the goal of this bug. The main goal was to get precompiled headers to work with GCC again. >> I agree that either approach does that. I looked at the webrev and >> it's a bunch of build system changes that I don't feel qualified to >> review, so I suggested an alternative that I understand. We each have >> our preferred tools. I don't object to the build-system-based >> approach, just can't give an actual thumbs-up. > > Right, and I appreciate the input! But could you at least review the hotspot part, so I can get someone else to review the build part? OK, I can do that. ------------------------------------------------------------------------------ src/hotspot/share/utilities/macros.hpp 645 #if FILE_MACRO_OFFSET 646 #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET) 647 #else 648 #define THIS_FILE __FILE__ 649 #endif Is the "#if FILE_MACRO_OFFSET" an intentional test for 0, or is this an implicit test for "defined"? If the former, e.g. we're assuming it will always be defined but might have a 0 value, then I'd skip it and just unconditionally define THIS_FILE as (__FILE__ + FILE_MACRO_OFFSET). If the latter, some compilers will (with some warning levels or options, such as gcc -Wundef) complain about the (specified by the standard) implicit conversion to 0 for an unrecognized identifier in an #if expression, and an #ifdef should be used to protect against that. ------------------------------------------------------------------------------ From erik.joelsson at oracle.com Thu Apr 4 22:03:48 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 4 Apr 2019 15:03:48 -0700 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> Message-ID: <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> On 2019-04-04 14:26, Kim Barrett wrote: > > OK, I can do that. > > ------------------------------------------------------------------------------ > src/hotspot/share/utilities/macros.hpp > 645 #if FILE_MACRO_OFFSET > 646 #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET) > 647 #else > 648 #define THIS_FILE __FILE__ > 649 #endif > > Is the "#if FILE_MACRO_OFFSET" an intentional test for 0, or is this > an implicit test for "defined"? > > If the former, e.g. we're assuming it will always be defined but might > have a 0 value, then I'd skip it and just unconditionally define > THIS_FILE as (__FILE__ + FILE_MACRO_OFFSET). Right, that makes sense. I was sort of hedging for all possibilities here, but as the build logic is currently structured, it will always be defined, just sometimes 0. New webrev: http://cr.openjdk.java.net/~erikj/8221851/webrev.02/ /Erik > If the latter, some compilers will (with some warning levels or > options, such as gcc -Wundef) complain about the (specified by the > standard) implicit conversion to 0 for an unrecognized identifier in > an #if expression, and an #ifdef should be used to protect against > that. > > ------------------------------------------------------------------------------ > > From kim.barrett at oracle.com Thu Apr 4 22:17:51 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 4 Apr 2019 18:17:51 -0400 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> Message-ID: > On Apr 4, 2019, at 6:03 PM, Erik Joelsson wrote: > > > On 2019-04-04 14:26, Kim Barrett wrote: >> >> OK, I can do that. >> >> ------------------------------------------------------------------------------ >> src/hotspot/share/utilities/macros.hpp >> 645 #if FILE_MACRO_OFFSET >> 646 #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET) >> 647 #else >> 648 #define THIS_FILE __FILE__ >> 649 #endif >> >> Is the "#if FILE_MACRO_OFFSET" an intentional test for 0, or is this >> an implicit test for "defined"? >> >> If the former, e.g. we're assuming it will always be defined but might >> have a 0 value, then I'd skip it and just unconditionally define >> THIS_FILE as (__FILE__ + FILE_MACRO_OFFSET). > > Right, that makes sense. I was sort of hedging for all possibilities here, but as the build logic is currently structured, it will always be defined, just sometimes 0. > > New webrev: http://cr.openjdk.java.net/~erikj/8221851/webrev.02/ src/hotspot changes look good. From david.holmes at oracle.com Thu Apr 4 22:49:58 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 5 Apr 2019 08:49:58 +1000 Subject: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: References: <2f68463c-be1c-9d34-6202-72613cb7438d@oracle.com> <2c61ef7c-91f0-9636-5567-eaf8bbff7c94@oracle.com> <30b2b3c5-38f7-8569-10cd-e781129b5da5@oracle.com> Message-ID: <5a2f0358-d5e4-2fdc-5791-e6d45f9d5b02@oracle.com> On 4/04/2019 10:35 pm, Baesken, Matthias wrote: >> >> On 4/04/2019 8:54 pm, Baesken, Matthias wrote: >>>> >>>> My remaining query is why we need the OS specific checks and code in >>>> os-cpu files? Isn't this just cpu specific? Even if a particular OS >>>> doesn't support virtualization, won't the cpuid query simply report "no >>>> virtualization"? >>>> >>> >>> Hi David, if you are referring to these os-cpu files : >>> >>> src/hotspot/os_cpu/linux_x86/vm_version_linux_x86.cpp >>> src/hotspot/os_cpu/windows_x86/vm_version_windows_x86.cpp >>> >>> we have different coding available because I am not aware of a cross OS >> API/coding to get the cpu id info. >>> That?s why different coding for LINUX/Windows. >> >> ?? But there's nothing in those added functions that is Linux specific >> or Windows specific! The only difference is the mechanism for doing >> "inline assembly" and that's compiler specific. So this should just use >> compiler based ifdefs in vm_version_x86.cpp. >> > > Hi David, I see your point. But I thought we want to reduce the ifdefs and favor putting code into the os or os/cpu specific files . > But it is true , from a technical point we could do using the compiler macros . I favour putting os-specific code in os-specific files over OS ifdefs in shared files. But here we are talking about compiler-specific code that is also CPU specific (not os specific). So compiler ifdefs in the cpu files is the way to handle this. Thanks, David > Best regards, Matthias > > From erik.gahlin at oracle.com Thu Apr 4 23:21:58 2019 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Fri, 5 Apr 2019 01:21:58 +0200 Subject: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: <5a2f0358-d5e4-2fdc-5791-e6d45f9d5b02@oracle.com> References: <2f68463c-be1c-9d34-6202-72613cb7438d@oracle.com> <2c61ef7c-91f0-9636-5567-eaf8bbff7c94@oracle.com> <30b2b3c5-38f7-8569-10cd-e781129b5da5@oracle.com> <5a2f0358-d5e4-2fdc-5791-e6d45f9d5b02@oracle.com> Message-ID: <5CA69196.3000501@oracle.com> I haven't looked at the code closely., but we definitely want this information in JFR, as a separate RFE of course. Any API that will make it easy to access the information later as char* is appreciated, i.e. EventOSInformation event; event.set_virtualization(Virtualization::name()); event.commit(); Thanks Erik > On 4/04/2019 10:35 pm, Baesken, Matthias wrote: >>> >>> On 4/04/2019 8:54 pm, Baesken, Matthias wrote: >>>>> >>>>> My remaining query is why we need the OS specific checks and code in >>>>> os-cpu files? Isn't this just cpu specific? Even if a particular OS >>>>> doesn't support virtualization, won't the cpuid query simply >>>>> report "no >>>>> virtualization"? >>>>> >>>> >>>> Hi David, if you are referring to these os-cpu files : >>>> >>>> src/hotspot/os_cpu/linux_x86/vm_version_linux_x86.cpp >>>> src/hotspot/os_cpu/windows_x86/vm_version_windows_x86.cpp >>>> >>>> we have different coding available because I am not aware of a >>>> cross OS >>> API/coding to get the cpu id info. >>>> That?s why different coding for LINUX/Windows. >>> >>> ?? But there's nothing in those added functions that is Linux specific >>> or Windows specific! The only difference is the mechanism for doing >>> "inline assembly" and that's compiler specific. So this should just use >>> compiler based ifdefs in vm_version_x86.cpp. >>> >> >> Hi David, I see your point. But I thought we want to reduce the >> ifdefs and favor putting code into the os or os/cpu specific files . >> But it is true , from a technical point we could do using the >> compiler macros . > > I favour putting os-specific code in os-specific files over OS ifdefs > in shared files. But here we are talking about compiler-specific code > that is also CPU specific (not os specific). So compiler ifdefs in the > cpu files is the way to handle this. > > Thanks, > David > >> Best regards, Matthias >> From vladimir.kozlov at oracle.com Thu Apr 4 23:45:46 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 4 Apr 2019 16:45:46 -0700 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: References: <4b759550-f185-724f-7139-9bab648a1966@oracle.com> <119335f1-acb7-fffc-f38a-e50a96b73b3c@oracle.com> <2d206374-cfeb-9b1b-2838-e4e0a774e89d@oracle.com> <8063fb37-f1b0-8b93-bbe8-4dbeeaa54959@oracle.com> <17233985-18c7-305e-5556-fe2b38926b71@oracle.com> <3514c74d-5f6a-61cc-ebea-b9564df61673@oracle.com> Message-ID: Thank you, Kim I moved HotSpotJVMCI methods which call JNIHandles::resolve() to jvmciJavaClasses.cpp file so that I don't need to include jniHandles.inline.hpp into .hpp file. I will update changes when I address your other comments. Thanks, Vladimir On 4/4/19 1:57 PM, Kim Barrett wrote: >> On Apr 4, 2019, at 3:22 AM, Vladimir Kozlov wrote: >> >> New delta: >> http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.06/ >> >> Full: >> http://cr.openjdk.java.net/~kvn/8220623/webrev.06/ >> >> New changes are based on Kim and Stefan suggestions: >> >> - Moved JVMCI::oops_do() from JNIHandles to places where it should be called. >> - Moved JVMCI cleanup task to the beginning of ParallelCleaningTask::work(). >> - Used JVMCI_ONLY macro with COMMA. >> - Disable JVMCI build on SPARC. We don't use it - neither Graal or AOT are built on SPARC. Disabling also helps to find missing JVMCI guards. >> >> I ran hs-tier1-3 testing - it passed (hs-tier3 includes graal testing). >> I started hs-tier4..8-graal testing. >> I will do performance testing next. > > ------------------------------------------------------------------------------ > src/hotspot/share/jvmci/jvmciJavaClasses.hpp > 28 #include "runtime/jniHandles.inline.hpp" > > .hpp files are not permitted to #include .inline.hpp files. > > We've fixed most violations (I think there are still a few lingering > ones that have not yet been disentangled); please don't add new ones. > > ------------------------------------------------------------------------------ > From david.holmes at oracle.com Fri Apr 5 00:35:16 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 5 Apr 2019 10:35:16 +1000 Subject: 8219918: ProblemList tests failing in SAP testing. In-Reply-To: References: <7c80c989-48cd-3689-36ff-cdc0f2ac6003@oracle.com> <50a7ad12-9d70-c838-1baa-5d0ee6337c85@oracle.com> Message-ID: Hi Goetz, This seems fine. Thanks, David On 4/04/2019 9:53 pm, Lindenmaier, Goetz wrote: > Hi, > > this is still not pushed ... some bugs were fixed in the meantime. > This leaves only the aix failures on the list. > http://cr.openjdk.java.net/~goetz/wr19/8219918-problemList/03/ > > Best regards, > Goetz. > >> -----Original Message----- >> From: hotspot-dev On Behalf Of >> Lindenmaier, Goetz >> Sent: Freitag, 1. M?rz 2019 08:07 >> To: hotspot-dev at openjdk.java.net >> Subject: RE: 8219918: ProblemList tests failing in SAP testing. >> >> Hi, >> >> I changed this to only ProblemList hotspot tests. >> Please review. >> http://cr.openjdk.java.net/~goetz/wr19/8219918-problemList/02/ >> >> Best regards, >> Goetz. >> >> >>> -----Original Message----- >>> From: Daniel D. Daugherty >>> Sent: Thursday, February 28, 2019 4:48 PM >>> To: Alan Bateman ; Lindenmaier, Goetz >>> ; hotspot-dev at openjdk.java.net >>> Subject: Re: 8219918: ProblemList tests failing in SAP testing. >>> >>> On 2/28/19 8:36 AM, Alan Bateman wrote: >>>> On 28/02/2019 13:05, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> in our testing we see a few tests failing at least since the jdk 11 >>>>> release. >>>>> I opened bugs for these issues and would like to add them to >>>>> the ProblemLists for now: >>>>> >>>>> http://cr.openjdk.java.net/~goetz/wr19/8219918-problemList/01/ >>>>> >>>>> I don't think any of these issues are critical. >>>>> >>>> >>>> This excludes the the CopyAndMove.java test which is critical to >>>> testing the Files.copy/move APIs. Can you start a discussion on >>>> nio-dev with info about the test environment rather than excluding >>>> this really important test. >>>> >>>> -Alan >>> >>> In the bug there is a mix of hotspot and jdk tests and this review >>> request was only sent to hotspot-dev at ... I think trying to do this >>> in one bug is not quite appropriate for review purposes. Perhaps >>> an umbrella bug with subtasks? Dunno... >>> >>> Dan From david.holmes at oracle.com Fri Apr 5 03:54:10 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 5 Apr 2019 13:54:10 +1000 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: <49615c26-8ad8-ca99-a66f-d5884164d99f@redhat.com> References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <49615c26-8ad8-ca99-a66f-d5884164d99f@redhat.com> Message-ID: Hi Andrew, This all looks good to me - thanks for making the changes. Two nits: - BE was barely acceptable when used like a local variable, but now I think BIG_ENDIAN would be better. - If you don't use static import you can name the UnsafeConstants fields the obvious way without clashing with public fields in Unsafe. Feel free to ignore those nits. If you do make a change no need to see another webrev. Thanks, David On 5/04/2019 1:19 am, Andrew Dinn wrote: > New webrev is now available. Re-reviews welcome. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8221477 > Webrev: http://cr.openjdk.java.net/~adinn/8221477/webrev.03 > > This version should address all comments from Thomas, David and Coleen. > > Testing > Tier1 test passed. > Submit test passed. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From david.holmes at oracle.com Fri Apr 5 04:04:01 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 5 Apr 2019 14:04:01 +1000 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> Message-ID: <69018b42-7540-9222-a296-db28b99cdf91@oracle.com> Hi Erik, Build and hotspot changes seem okay. Thanks, David On 5/04/2019 8:03 am, Erik Joelsson wrote: > > On 2019-04-04 14:26, Kim Barrett wrote: >> >> OK, I can do that. >> >> ------------------------------------------------------------------------------ >> >> src/hotspot/share/utilities/macros.hpp >> ? 645 #if FILE_MACRO_OFFSET >> ? 646 #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET) >> ? 647 #else >> ? 648 #define THIS_FILE __FILE__ >> ? 649 #endif >> >> Is the "#if FILE_MACRO_OFFSET" an intentional test for 0, or is this >> an implicit test for "defined"? >> >> If the former, e.g. we're assuming it will always be defined but might >> have a 0 value, then I'd skip it and just unconditionally define >> THIS_FILE as (__FILE__ + FILE_MACRO_OFFSET). > > Right, that makes sense. I was sort of hedging for all possibilities > here, but as the build logic is currently structured, it will always be > defined, just sometimes 0. > > New webrev: http://cr.openjdk.java.net/~erikj/8221851/webrev.02/ > > /Erik > >> If the latter, some compilers will (with some warning levels or >> options, such as gcc -Wundef) complain about the (specified by the >> standard) implicit conversion to 0 for an unrecognized identifier in >> an #if expression, and an #ifdef should be used to protect against >> that. >> >> ------------------------------------------------------------------------------ >> >> >> From ioi.lam at oracle.com Fri Apr 5 04:41:04 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 4 Apr 2019 21:41:04 -0700 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: <69018b42-7540-9222-a296-db28b99cdf91@oracle.com> References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> <69018b42-7540-9222-a296-db28b99cdf91@oracle.com> Message-ID: <79a6f9dd-7f20-649c-a6c4-e6cf8f098130@oracle.com> #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET) This make me a little uneasy, as it could potential point past the end of the string. For safety, Is it possible to get some sort of assert to make sure that __FILE__ always has more than FILE_MACRO_OFFSET characters? Maybe we can add a static object in macros.hpp with a constructor that puts __FILE__ into a list, and then we can walk the list when the VM starts up? E.g. ??? ... ??? #ifdef ASSERT ??? static ThisFileChecker __this_file_checker(__FILE__); ??? #endif ??? #endif // SHARE_UTILITIES_MACROS_HPP Thanks - Ioi On 4/4/19 9:04 PM, David Holmes wrote: > Hi Erik, > > Build and hotspot changes seem okay. > > Thanks, > David > > On 5/04/2019 8:03 am, Erik Joelsson wrote: >> >> On 2019-04-04 14:26, Kim Barrett wrote: >>> >>> OK, I can do that. >>> >>> ------------------------------------------------------------------------------ >>> >>> src/hotspot/share/utilities/macros.hpp >>> ? 645 #if FILE_MACRO_OFFSET >>> ? 646 #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET) >>> ? 647 #else >>> ? 648 #define THIS_FILE __FILE__ >>> ? 649 #endif >>> >>> Is the "#if FILE_MACRO_OFFSET" an intentional test for 0, or is this >>> an implicit test for "defined"? >>> >>> If the former, e.g. we're assuming it will always be defined but might >>> have a 0 value, then I'd skip it and just unconditionally define >>> THIS_FILE as (__FILE__ + FILE_MACRO_OFFSET). >> >> Right, that makes sense. I was sort of hedging for all possibilities >> here, but as the build logic is currently structured, it will always >> be defined, just sometimes 0. >> >> New webrev: http://cr.openjdk.java.net/~erikj/8221851/webrev.02/ >> >> /Erik >> >>> If the latter, some compilers will (with some warning levels or >>> options, such as gcc -Wundef) complain about the (specified by the >>> standard) implicit conversion to 0 for an unrecognized identifier in >>> an #if expression, and an #ifdef should be used to protect against >>> that. >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> From david.holmes at oracle.com Fri Apr 5 05:08:06 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 5 Apr 2019 15:08:06 +1000 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: <79a6f9dd-7f20-649c-a6c4-e6cf8f098130@oracle.com> References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> <69018b42-7540-9222-a296-db28b99cdf91@oracle.com> <79a6f9dd-7f20-649c-a6c4-e6cf8f098130@oracle.com> Message-ID: <9c841ef7-4190-f5f8-fcfd-291c178a264d@oracle.com> Adding back build-dev On 5/04/2019 2:41 pm, Ioi Lam wrote: > #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET) > > This make me a little uneasy, as it could potential point past the end > of the string. The intent of course is that that is impossible: - _FILE_ is an absolute file path within the repo: /something/repo/file - FILE_MACRO_OFFSET gets you from / to the top-level repo directory leaving "file" so it has to be in bounds. > For safety, Is it possible to get some sort of assert to make sure that > __FILE__ always has more than FILE_MACRO_OFFSET characters? > > Maybe we can add a static object in macros.hpp with a constructor that > puts __FILE__ into a list, and then we can walk the list when the VM > starts up? E.g. > > ??? ... > > ??? #ifdef ASSERT > ??? static ThisFileChecker __this_file_checker(__FILE__); > ??? #endif > > ??? #endif // SHARE_UTILITIES_MACROS_HPP So basically you're not trusting the compiler and build system to be correct here. :) Would it suffice to put a static assert in a common header, like macros.hpp, that verifies the length of _FILE_ or is that not available statically? Cheers, David > > Thanks > - Ioi > > > On 4/4/19 9:04 PM, David Holmes wrote: >> Hi Erik, >> >> Build and hotspot changes seem okay. >> >> Thanks, >> David >> >> On 5/04/2019 8:03 am, Erik Joelsson wrote: >>> >>> On 2019-04-04 14:26, Kim Barrett wrote: >>>> >>>> OK, I can do that. >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> src/hotspot/share/utilities/macros.hpp >>>> ? 645 #if FILE_MACRO_OFFSET >>>> ? 646 #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET) >>>> ? 647 #else >>>> ? 648 #define THIS_FILE __FILE__ >>>> ? 649 #endif >>>> >>>> Is the "#if FILE_MACRO_OFFSET" an intentional test for 0, or is this >>>> an implicit test for "defined"? >>>> >>>> If the former, e.g. we're assuming it will always be defined but might >>>> have a 0 value, then I'd skip it and just unconditionally define >>>> THIS_FILE as (__FILE__ + FILE_MACRO_OFFSET). >>> >>> Right, that makes sense. I was sort of hedging for all possibilities >>> here, but as the build logic is currently structured, it will always >>> be defined, just sometimes 0. >>> >>> New webrev: http://cr.openjdk.java.net/~erikj/8221851/webrev.02/ >>> >>> /Erik >>> >>>> If the latter, some compilers will (with some warning levels or >>>> options, such as gcc -Wundef) complain about the (specified by the >>>> standard) implicit conversion to 0 for an unrecognized identifier in >>>> an #if expression, and an #ifdef should be used to protect against >>>> that. >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> > From ioi.lam at oracle.com Fri Apr 5 05:23:34 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 4 Apr 2019 22:23:34 -0700 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: <9c841ef7-4190-f5f8-fcfd-291c178a264d@oracle.com> References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> <69018b42-7540-9222-a296-db28b99cdf91@oracle.com> <79a6f9dd-7f20-649c-a6c4-e6cf8f098130@oracle.com> <9c841ef7-4190-f5f8-fcfd-291c178a264d@oracle.com> Message-ID: On 4/4/19 10:08 PM, David Holmes wrote: > Adding back build-dev > > On 5/04/2019 2:41 pm, Ioi Lam wrote: >> #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET) >> >> This make me a little uneasy, as it could potential point past the >> end of the string. > > The intent of course is that that is impossible: > - _FILE_ is an absolute file path within the repo: /something/repo/file > - FILE_MACRO_OFFSET gets you from / to the top-level repo directory > leaving "file" > > so it has to be in bounds. > >> For safety, Is it possible to get some sort of assert to make sure >> that __FILE__ always has more than FILE_MACRO_OFFSET characters? >> >> Maybe we can add a static object in macros.hpp with a constructor >> that puts __FILE__ into a list, and then we can walk the list when >> the VM starts up? E.g. >> >> ???? ... >> >> ???? #ifdef ASSERT >> ???? static ThisFileChecker __this_file_checker(__FILE__); >> ???? #endif >> >> ???? #endif // SHARE_UTILITIES_MACROS_HPP > > So basically you're not trusting the compiler and build system to be > correct here. :) I am sure the build system is correct ..... but it's complicated. BTW, we actually have generated sources that can live outside of the source repo. And with luck, their names can actually be shorter than FILE_MACRO_OFFSET. $ cd /tmp/mybld $ find . -name \*.cpp ./hotspot/variant-server/support/adlc/ad_x86_expand.cpp ./hotspot/variant-server/support/adlc/ad_x86_pipeline.cpp ./hotspot/variant-server/support/adlc/ad_x86_format.cpp ./hotspot/variant-server/support/adlc/dfa_x86.cpp ./hotspot/variant-server/support/adlc/ad_x86_misc.cpp ./hotspot/variant-server/support/adlc/ad_x86_gen.cpp ./hotspot/variant-server/support/adlc/ad_x86.cpp ./hotspot/variant-server/support/adlc/ad_x86_peephole.cpp ./hotspot/variant-server/support/adlc/ad_x86_clone.cpp ./hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp ./hotspot/variant-server/gensrc/adfiles/ad_x86_pipeline.cpp ./hotspot/variant-server/gensrc/adfiles/ad_x86_format.cpp ./hotspot/variant-server/gensrc/adfiles/dfa_x86.cpp ./hotspot/variant-server/gensrc/adfiles/ad_x86_misc.cpp ./hotspot/variant-server/gensrc/adfiles/ad_x86_gen.cpp ./hotspot/variant-server/gensrc/adfiles/ad_x86.cpp ./hotspot/variant-server/gensrc/adfiles/ad_x86_peephole.cpp ./hotspot/variant-server/gensrc/adfiles/ad_x86_clone.cpp ./hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp ./hotspot/variant-server/gensrc/jvmtifiles/bytecodeInterpreterWithChecks.cpp ./hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnterTrace.cpp > > Would it suffice to put a static assert in a common header, like > macros.hpp, that verifies the length of _FILE_ or is that not > available statically? > I don't know how a static assert would work. That's why I suggested the static object with a constructor. Thanks - Ioi > Cheers, > David > >> >> Thanks >> - Ioi >> >> >> On 4/4/19 9:04 PM, David Holmes wrote: >>> Hi Erik, >>> >>> Build and hotspot changes seem okay. >>> >>> Thanks, >>> David >>> >>> On 5/04/2019 8:03 am, Erik Joelsson wrote: >>>> >>>> On 2019-04-04 14:26, Kim Barrett wrote: >>>>> >>>>> OK, I can do that. >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> src/hotspot/share/utilities/macros.hpp >>>>> ? 645 #if FILE_MACRO_OFFSET >>>>> ? 646 #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET) >>>>> ? 647 #else >>>>> ? 648 #define THIS_FILE __FILE__ >>>>> ? 649 #endif >>>>> >>>>> Is the "#if FILE_MACRO_OFFSET" an intentional test for 0, or is this >>>>> an implicit test for "defined"? >>>>> >>>>> If the former, e.g. we're assuming it will always be defined but >>>>> might >>>>> have a 0 value, then I'd skip it and just unconditionally define >>>>> THIS_FILE as (__FILE__ + FILE_MACRO_OFFSET). >>>> >>>> Right, that makes sense. I was sort of hedging for all >>>> possibilities here, but as the build logic is currently structured, >>>> it will always be defined, just sometimes 0. >>>> >>>> New webrev: http://cr.openjdk.java.net/~erikj/8221851/webrev.02/ >>>> >>>> /Erik >>>> >>>>> If the latter, some compilers will (with some warning levels or >>>>> options, such as gcc -Wundef) complain about the (specified by the >>>>> standard) implicit conversion to 0 for an unrecognized identifier in >>>>> an #if expression, and an #ifdef should be used to protect against >>>>> that. >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> >> From goetz.lindenmaier at sap.com Fri Apr 5 05:41:35 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 5 Apr 2019 05:41:35 +0000 Subject: 8219918: ProblemList tests failing in SAP testing. In-Reply-To: References: <7c80c989-48cd-3689-36ff-cdc0f2ac6003@oracle.com> <50a7ad12-9d70-c838-1baa-5d0ee6337c85@oracle.com> Message-ID: Hi David, Thanks for the review! Goetz. > -----Original Message----- > From: David Holmes > Sent: Friday, April 5, 2019 2:35 AM > To: Lindenmaier, Goetz ; hotspot- > dev at openjdk.java.net > Subject: Re: 8219918: ProblemList tests failing in SAP testing. > > Hi Goetz, > > This seems fine. > > Thanks, > David > > On 4/04/2019 9:53 pm, Lindenmaier, Goetz wrote: > > Hi, > > > > this is still not pushed ... some bugs were fixed in the meantime. > > This leaves only the aix failures on the list. > > http://cr.openjdk.java.net/~goetz/wr19/8219918-problemList/03/ > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: hotspot-dev On Behalf > Of > >> Lindenmaier, Goetz > >> Sent: Freitag, 1. M?rz 2019 08:07 > >> To: hotspot-dev at openjdk.java.net > >> Subject: RE: 8219918: ProblemList tests failing in SAP testing. > >> > >> Hi, > >> > >> I changed this to only ProblemList hotspot tests. > >> Please review. > >> http://cr.openjdk.java.net/~goetz/wr19/8219918-problemList/02/ > >> > >> Best regards, > >> Goetz. > >> > >> > >>> -----Original Message----- > >>> From: Daniel D. Daugherty > >>> Sent: Thursday, February 28, 2019 4:48 PM > >>> To: Alan Bateman ; Lindenmaier, Goetz > >>> ; hotspot-dev at openjdk.java.net > >>> Subject: Re: 8219918: ProblemList tests failing in SAP testing. > >>> > >>> On 2/28/19 8:36 AM, Alan Bateman wrote: > >>>> On 28/02/2019 13:05, Lindenmaier, Goetz wrote: > >>>>> Hi, > >>>>> > >>>>> in our testing we see a few tests failing at least since the jdk 11 > >>>>> release. > >>>>> I opened bugs for these issues and would like to add them to > >>>>> the ProblemLists for now: > >>>>> > >>>>> http://cr.openjdk.java.net/~goetz/wr19/8219918-problemList/01/ > >>>>> > >>>>> I don't think any of these issues are critical. > >>>>> > >>>> > >>>> This excludes the the CopyAndMove.java test which is critical to > >>>> testing the Files.copy/move APIs. Can you start a discussion on > >>>> nio-dev with info about the test environment rather than excluding > >>>> this really important test. > >>>> > >>>> -Alan > >>> > >>> In the bug there is a mix of hotspot and jdk tests and this review > >>> request was only sent to hotspot-dev at ... I think trying to do this > >>> in one bug is not quite appropriate for review purposes. Perhaps > >>> an umbrella bug with subtasks? Dunno... > >>> > >>> Dan From david.holmes at oracle.com Fri Apr 5 05:58:18 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 5 Apr 2019 15:58:18 +1000 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> <69018b42-7540-9222-a296-db28b99cdf91@oracle.com> <79a6f9dd-7f20-649c-a6c4-e6cf8f098130@oracle.com> <9c841ef7-4190-f5f8-fcfd-291c178a264d@oracle.com> Message-ID: On 5/04/2019 3:23 pm, Ioi Lam wrote: > > > On 4/4/19 10:08 PM, David Holmes wrote: >> Adding back build-dev >> >> On 5/04/2019 2:41 pm, Ioi Lam wrote: >>> #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET) >>> >>> This make me a little uneasy, as it could potential point past the >>> end of the string. >> >> The intent of course is that that is impossible: >> - _FILE_ is an absolute file path within the repo: /something/repo/file >> - FILE_MACRO_OFFSET gets you from / to the top-level repo directory >> leaving "file" >> >> so it has to be in bounds. >> >>> For safety, Is it possible to get some sort of assert to make sure >>> that __FILE__ always has more than FILE_MACRO_OFFSET characters? >>> >>> Maybe we can add a static object in macros.hpp with a constructor >>> that puts __FILE__ into a list, and then we can walk the list when >>> the VM starts up? E.g. >>> >>> ???? ... >>> >>> ???? #ifdef ASSERT >>> ???? static ThisFileChecker __this_file_checker(__FILE__); >>> ???? #endif >>> >>> ???? #endif // SHARE_UTILITIES_MACROS_HPP >> >> So basically you're not trusting the compiler and build system to be >> correct here. :) > > I am sure the build system is correct ..... but it's complicated. > > BTW, we actually have generated sources that can live outside of the > source repo. And with luck, their names can actually be shorter than > FILE_MACRO_OFFSET. Excellent point! repo sources and generated sources need not be in the same tree, so you cannot use one "offset" to handle them both. David ----- > $ cd /tmp/mybld > $ find . -name \*.cpp > ./hotspot/variant-server/support/adlc/ad_x86_expand.cpp > ./hotspot/variant-server/support/adlc/ad_x86_pipeline.cpp > ./hotspot/variant-server/support/adlc/ad_x86_format.cpp > ./hotspot/variant-server/support/adlc/dfa_x86.cpp > ./hotspot/variant-server/support/adlc/ad_x86_misc.cpp > ./hotspot/variant-server/support/adlc/ad_x86_gen.cpp > ./hotspot/variant-server/support/adlc/ad_x86.cpp > ./hotspot/variant-server/support/adlc/ad_x86_peephole.cpp > ./hotspot/variant-server/support/adlc/ad_x86_clone.cpp > ./hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp > ./hotspot/variant-server/gensrc/adfiles/ad_x86_pipeline.cpp > ./hotspot/variant-server/gensrc/adfiles/ad_x86_format.cpp > ./hotspot/variant-server/gensrc/adfiles/dfa_x86.cpp > ./hotspot/variant-server/gensrc/adfiles/ad_x86_misc.cpp > ./hotspot/variant-server/gensrc/adfiles/ad_x86_gen.cpp > ./hotspot/variant-server/gensrc/adfiles/ad_x86.cpp > ./hotspot/variant-server/gensrc/adfiles/ad_x86_peephole.cpp > ./hotspot/variant-server/gensrc/adfiles/ad_x86_clone.cpp > ./hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp > ./hotspot/variant-server/gensrc/jvmtifiles/bytecodeInterpreterWithChecks.cpp > > ./hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnterTrace.cpp > >> >> Would it suffice to put a static assert in a common header, like >> macros.hpp, that verifies the length of _FILE_ or is that not >> available statically? >> > I don't know how a static assert would work. That's why I suggested the > static object with a constructor. > > Thanks > - Ioi > >> Cheers, >> David >> >>> >>> Thanks >>> - Ioi >>> >>> >>> On 4/4/19 9:04 PM, David Holmes wrote: >>>> Hi Erik, >>>> >>>> Build and hotspot changes seem okay. >>>> >>>> Thanks, >>>> David >>>> >>>> On 5/04/2019 8:03 am, Erik Joelsson wrote: >>>>> >>>>> On 2019-04-04 14:26, Kim Barrett wrote: >>>>>> >>>>>> OK, I can do that. >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> src/hotspot/share/utilities/macros.hpp >>>>>> ? 645 #if FILE_MACRO_OFFSET >>>>>> ? 646 #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET) >>>>>> ? 647 #else >>>>>> ? 648 #define THIS_FILE __FILE__ >>>>>> ? 649 #endif >>>>>> >>>>>> Is the "#if FILE_MACRO_OFFSET" an intentional test for 0, or is this >>>>>> an implicit test for "defined"? >>>>>> >>>>>> If the former, e.g. we're assuming it will always be defined but >>>>>> might >>>>>> have a 0 value, then I'd skip it and just unconditionally define >>>>>> THIS_FILE as (__FILE__ + FILE_MACRO_OFFSET). >>>>> >>>>> Right, that makes sense. I was sort of hedging for all >>>>> possibilities here, but as the build logic is currently structured, >>>>> it will always be defined, just sometimes 0. >>>>> >>>>> New webrev: http://cr.openjdk.java.net/~erikj/8221851/webrev.02/ >>>>> >>>>> /Erik >>>>> >>>>>> If the latter, some compilers will (with some warning levels or >>>>>> options, such as gcc -Wundef) complain about the (specified by the >>>>>> standard) implicit conversion to 0 for an unrecognized identifier in >>>>>> an #if expression, and an #ifdef should be used to protect against >>>>>> that. >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> >>> > From peter.levart at gmail.com Fri Apr 5 07:37:20 2019 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 5 Apr 2019 09:37:20 +0200 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: <49615c26-8ad8-ca99-a66f-d5884164d99f@redhat.com> References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <49615c26-8ad8-ca99-a66f-d5884164d99f@redhat.com> Message-ID: Hi Andrew, For a casual reader (like me) the comments in the UnsafeConstants for each field: ? 69????? * @implNote ? 70????? * The actual value for this field is injected by the JVM. ...make one wonder what is actually going on regarding the static initializer at the end of the class. Is it actually executed? Is it there just to silence the javac and prevent fields from becoming compile-time constants? Reading the patch further uncovers the secret: 3645?? // initialize the hardware-specific constants needed by Unsafe 3646 initialize_class(vmSymbols::jdk_internal_misc_UnsafeConstants(), CHECK); 3647?? jdk_internal_misc_UnsafeConstants::set_unsafe_constants(); If my understanding is correct, then the static initializer *is* executed and then the fields' values are overwritten with injected values. So perhaps it might be nice to write that down in the javadoc like: ? 69????? * @implNote ? 70????? * The actual value for this field is injected by the JVM immediately after the class initialization. Or something similar in the class-level javadoc. Just for the peace of mind of casual readers or perhaps someone that might later add a field to this class and try to initialize it in the static initializer, although I think this class is reserved for injected fields only... Regards, Peter On 4/4/19 5:19 PM, Andrew Dinn wrote: > New webrev is now available. Re-reviews welcome. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8221477 > Webrev: http://cr.openjdk.java.net/~adinn/8221477/webrev.03 > > This version should address all comments from Thomas, David and Coleen. > > Testing > Tier1 test passed. > Submit test passed. > > 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 thomas.stuefe at gmail.com Fri Apr 5 08:23:43 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 5 Apr 2019 10:23:43 +0200 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> <69018b42-7540-9222-a296-db28b99cdf91@oracle.com> <79a6f9dd-7f20-649c-a6c4-e6cf8f098130@oracle.com> <9c841ef7-4190-f5f8-fcfd-291c178a264d@oracle.com> Message-ID: Hi, sorry, just sniping in from the side. About the motivation: the original intent of Yasumasas patch was to reduce the length of the event log messages. I have a patch out there for RFR, since ~2 weeks or so, which largely solves this problem: https://bugs.openjdk.java.net/browse/JDK-8220762 The patch abolishes fixed-length string records in the event log in favor of variable length strings, and therefore uses the event log buffer much more efficiently. Truncation could still happen but is very unlikely. The patch is out since some time and has no reviews yet (Yasumasa agreed to review), I did not press it since we are all very busy. But, it would solve this problem, and maybe we do not need this fix at all. Unless we want a generic solution to problems like this. Cheers, Thomas On Fri, Apr 5, 2019 at 8:00 AM David Holmes wrote: > On 5/04/2019 3:23 pm, Ioi Lam wrote: > > > > > > On 4/4/19 10:08 PM, David Holmes wrote: > >> Adding back build-dev > >> > >> On 5/04/2019 2:41 pm, Ioi Lam wrote: > >>> #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET) > >>> > >>> This make me a little uneasy, as it could potential point past the > >>> end of the string. > >> > >> The intent of course is that that is impossible: > >> - _FILE_ is an absolute file path within the repo: /something/repo/file > >> - FILE_MACRO_OFFSET gets you from / to the top-level repo directory > >> leaving "file" > >> > >> so it has to be in bounds. > >> > >>> For safety, Is it possible to get some sort of assert to make sure > >>> that __FILE__ always has more than FILE_MACRO_OFFSET characters? > >>> > >>> Maybe we can add a static object in macros.hpp with a constructor > >>> that puts __FILE__ into a list, and then we can walk the list when > >>> the VM starts up? E.g. > >>> > >>> ... > >>> > >>> #ifdef ASSERT > >>> static ThisFileChecker __this_file_checker(__FILE__); > >>> #endif > >>> > >>> #endif // SHARE_UTILITIES_MACROS_HPP > >> > >> So basically you're not trusting the compiler and build system to be > >> correct here. :) > > > > I am sure the build system is correct ..... but it's complicated. > > > > BTW, we actually have generated sources that can live outside of the > > source repo. And with luck, their names can actually be shorter than > > FILE_MACRO_OFFSET. > > Excellent point! repo sources and generated sources need not be in the > same tree, so you cannot use one "offset" to handle them both. > > David > ----- > > > > $ cd /tmp/mybld > > $ find . -name \*.cpp > > ./hotspot/variant-server/support/adlc/ad_x86_expand.cpp > > ./hotspot/variant-server/support/adlc/ad_x86_pipeline.cpp > > ./hotspot/variant-server/support/adlc/ad_x86_format.cpp > > ./hotspot/variant-server/support/adlc/dfa_x86.cpp > > ./hotspot/variant-server/support/adlc/ad_x86_misc.cpp > > ./hotspot/variant-server/support/adlc/ad_x86_gen.cpp > > ./hotspot/variant-server/support/adlc/ad_x86.cpp > > ./hotspot/variant-server/support/adlc/ad_x86_peephole.cpp > > ./hotspot/variant-server/support/adlc/ad_x86_clone.cpp > > ./hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp > > ./hotspot/variant-server/gensrc/adfiles/ad_x86_pipeline.cpp > > ./hotspot/variant-server/gensrc/adfiles/ad_x86_format.cpp > > ./hotspot/variant-server/gensrc/adfiles/dfa_x86.cpp > > ./hotspot/variant-server/gensrc/adfiles/ad_x86_misc.cpp > > ./hotspot/variant-server/gensrc/adfiles/ad_x86_gen.cpp > > ./hotspot/variant-server/gensrc/adfiles/ad_x86.cpp > > ./hotspot/variant-server/gensrc/adfiles/ad_x86_peephole.cpp > > ./hotspot/variant-server/gensrc/adfiles/ad_x86_clone.cpp > > ./hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp > > > ./hotspot/variant-server/gensrc/jvmtifiles/bytecodeInterpreterWithChecks.cpp > > > > > ./hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnterTrace.cpp > > > >> > >> Would it suffice to put a static assert in a common header, like > >> macros.hpp, that verifies the length of _FILE_ or is that not > >> available statically? > >> > > I don't know how a static assert would work. That's why I suggested the > > static object with a constructor. > > > > Thanks > > - Ioi > > > >> Cheers, > >> David > >> > >>> > >>> Thanks > >>> - Ioi > >>> > >>> > >>> On 4/4/19 9:04 PM, David Holmes wrote: > >>>> Hi Erik, > >>>> > >>>> Build and hotspot changes seem okay. > >>>> > >>>> Thanks, > >>>> David > >>>> > >>>> On 5/04/2019 8:03 am, Erik Joelsson wrote: > >>>>> > >>>>> On 2019-04-04 14:26, Kim Barrett wrote: > >>>>>> > >>>>>> OK, I can do that. > >>>>>> > >>>>>> > ------------------------------------------------------------------------------ > > >>>>>> > >>>>>> src/hotspot/share/utilities/macros.hpp > >>>>>> 645 #if FILE_MACRO_OFFSET > >>>>>> 646 #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET) > >>>>>> 647 #else > >>>>>> 648 #define THIS_FILE __FILE__ > >>>>>> 649 #endif > >>>>>> > >>>>>> Is the "#if FILE_MACRO_OFFSET" an intentional test for 0, or is this > >>>>>> an implicit test for "defined"? > >>>>>> > >>>>>> If the former, e.g. we're assuming it will always be defined but > >>>>>> might > >>>>>> have a 0 value, then I'd skip it and just unconditionally define > >>>>>> THIS_FILE as (__FILE__ + FILE_MACRO_OFFSET). > >>>>> > >>>>> Right, that makes sense. I was sort of hedging for all > >>>>> possibilities here, but as the build logic is currently structured, > >>>>> it will always be defined, just sometimes 0. > >>>>> > >>>>> New webrev: http://cr.openjdk.java.net/~erikj/8221851/webrev.02/ > >>>>> > >>>>> /Erik > >>>>> > >>>>>> If the latter, some compilers will (with some warning levels or > >>>>>> options, such as gcc -Wundef) complain about the (specified by the > >>>>>> standard) implicit conversion to 0 for an unrecognized identifier in > >>>>>> an #if expression, and an #ifdef should be used to protect against > >>>>>> that. > >>>>>> > >>>>>> > ------------------------------------------------------------------------------ > > >>>>>> > >>>>>> > >>>>>> > >>> > > > From thomas.stuefe at gmail.com Fri Apr 5 08:25:57 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 5 Apr 2019 10:25:57 +0200 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> <69018b42-7540-9222-a296-db28b99cdf91@oracle.com> <79a6f9dd-7f20-649c-a6c4-e6cf8f098130@oracle.com> <9c841ef7-4190-f5f8-fcfd-291c178a264d@oracle.com> Message-ID: p.s.: Review is at hs-runtime-dev: https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-March/033150.html . On Fri, Apr 5, 2019 at 10:23 AM Thomas St?fe wrote: > Hi, > > sorry, just sniping in from the side. > > About the motivation: the original intent of Yasumasas patch was to reduce > the length of the event log messages. > > I have a patch out there for RFR, since ~2 weeks or so, which largely > solves this problem: > > https://bugs.openjdk.java.net/browse/JDK-8220762 > > The patch abolishes fixed-length string records in the event log in favor > of variable length strings, and therefore uses the event log buffer much > more efficiently. Truncation could still happen but is very unlikely. > > The patch is out since some time and has no reviews yet (Yasumasa agreed > to review), I did not press it since we are all very busy. But, it would > solve this problem, and maybe we do not need this fix at all. > > Unless we want a generic solution to problems like this. > > Cheers, Thomas > > > > > > On Fri, Apr 5, 2019 at 8:00 AM David Holmes > wrote: > >> On 5/04/2019 3:23 pm, Ioi Lam wrote: >> > >> > >> > On 4/4/19 10:08 PM, David Holmes wrote: >> >> Adding back build-dev >> >> >> >> On 5/04/2019 2:41 pm, Ioi Lam wrote: >> >>> #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET) >> >>> >> >>> This make me a little uneasy, as it could potential point past the >> >>> end of the string. >> >> >> >> The intent of course is that that is impossible: >> >> - _FILE_ is an absolute file path within the repo: /something/repo/file >> >> - FILE_MACRO_OFFSET gets you from / to the top-level repo directory >> >> leaving "file" >> >> >> >> so it has to be in bounds. >> >> >> >>> For safety, Is it possible to get some sort of assert to make sure >> >>> that __FILE__ always has more than FILE_MACRO_OFFSET characters? >> >>> >> >>> Maybe we can add a static object in macros.hpp with a constructor >> >>> that puts __FILE__ into a list, and then we can walk the list when >> >>> the VM starts up? E.g. >> >>> >> >>> ... >> >>> >> >>> #ifdef ASSERT >> >>> static ThisFileChecker __this_file_checker(__FILE__); >> >>> #endif >> >>> >> >>> #endif // SHARE_UTILITIES_MACROS_HPP >> >> >> >> So basically you're not trusting the compiler and build system to be >> >> correct here. :) >> > >> > I am sure the build system is correct ..... but it's complicated. >> > >> > BTW, we actually have generated sources that can live outside of the >> > source repo. And with luck, their names can actually be shorter than >> > FILE_MACRO_OFFSET. >> >> Excellent point! repo sources and generated sources need not be in the >> same tree, so you cannot use one "offset" to handle them both. >> >> David >> ----- >> >> >> > $ cd /tmp/mybld >> > $ find . -name \*.cpp >> > ./hotspot/variant-server/support/adlc/ad_x86_expand.cpp >> > ./hotspot/variant-server/support/adlc/ad_x86_pipeline.cpp >> > ./hotspot/variant-server/support/adlc/ad_x86_format.cpp >> > ./hotspot/variant-server/support/adlc/dfa_x86.cpp >> > ./hotspot/variant-server/support/adlc/ad_x86_misc.cpp >> > ./hotspot/variant-server/support/adlc/ad_x86_gen.cpp >> > ./hotspot/variant-server/support/adlc/ad_x86.cpp >> > ./hotspot/variant-server/support/adlc/ad_x86_peephole.cpp >> > ./hotspot/variant-server/support/adlc/ad_x86_clone.cpp >> > ./hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp >> > ./hotspot/variant-server/gensrc/adfiles/ad_x86_pipeline.cpp >> > ./hotspot/variant-server/gensrc/adfiles/ad_x86_format.cpp >> > ./hotspot/variant-server/gensrc/adfiles/dfa_x86.cpp >> > ./hotspot/variant-server/gensrc/adfiles/ad_x86_misc.cpp >> > ./hotspot/variant-server/gensrc/adfiles/ad_x86_gen.cpp >> > ./hotspot/variant-server/gensrc/adfiles/ad_x86.cpp >> > ./hotspot/variant-server/gensrc/adfiles/ad_x86_peephole.cpp >> > ./hotspot/variant-server/gensrc/adfiles/ad_x86_clone.cpp >> > ./hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp >> > >> ./hotspot/variant-server/gensrc/jvmtifiles/bytecodeInterpreterWithChecks.cpp >> >> > >> > ./hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnterTrace.cpp >> > >> >> >> >> Would it suffice to put a static assert in a common header, like >> >> macros.hpp, that verifies the length of _FILE_ or is that not >> >> available statically? >> >> >> > I don't know how a static assert would work. That's why I suggested the >> > static object with a constructor. >> > >> > Thanks >> > - Ioi >> > >> >> Cheers, >> >> David >> >> >> >>> >> >>> Thanks >> >>> - Ioi >> >>> >> >>> >> >>> On 4/4/19 9:04 PM, David Holmes wrote: >> >>>> Hi Erik, >> >>>> >> >>>> Build and hotspot changes seem okay. >> >>>> >> >>>> Thanks, >> >>>> David >> >>>> >> >>>> On 5/04/2019 8:03 am, Erik Joelsson wrote: >> >>>>> >> >>>>> On 2019-04-04 14:26, Kim Barrett wrote: >> >>>>>> >> >>>>>> OK, I can do that. >> >>>>>> >> >>>>>> >> ------------------------------------------------------------------------------ >> >> >>>>>> >> >>>>>> src/hotspot/share/utilities/macros.hpp >> >>>>>> 645 #if FILE_MACRO_OFFSET >> >>>>>> 646 #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET) >> >>>>>> 647 #else >> >>>>>> 648 #define THIS_FILE __FILE__ >> >>>>>> 649 #endif >> >>>>>> >> >>>>>> Is the "#if FILE_MACRO_OFFSET" an intentional test for 0, or is >> this >> >>>>>> an implicit test for "defined"? >> >>>>>> >> >>>>>> If the former, e.g. we're assuming it will always be defined but >> >>>>>> might >> >>>>>> have a 0 value, then I'd skip it and just unconditionally define >> >>>>>> THIS_FILE as (__FILE__ + FILE_MACRO_OFFSET). >> >>>>> >> >>>>> Right, that makes sense. I was sort of hedging for all >> >>>>> possibilities here, but as the build logic is currently structured, >> >>>>> it will always be defined, just sometimes 0. >> >>>>> >> >>>>> New webrev: http://cr.openjdk.java.net/~erikj/8221851/webrev.02/ >> >>>>> >> >>>>> /Erik >> >>>>> >> >>>>>> If the latter, some compilers will (with some warning levels or >> >>>>>> options, such as gcc -Wundef) complain about the (specified by the >> >>>>>> standard) implicit conversion to 0 for an unrecognized identifier >> in >> >>>>>> an #if expression, and an #ifdef should be used to protect against >> >>>>>> that. >> >>>>>> >> >>>>>> >> ------------------------------------------------------------------------------ >> >> >>>>>> >> >>>>>> >> >>>>>> >> >>> >> > >> > From matthias.baesken at sap.com Fri Apr 5 08:26:37 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 5 Apr 2019 08:26:37 +0000 Subject: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: <5a2f0358-d5e4-2fdc-5791-e6d45f9d5b02@oracle.com> References: <2f68463c-be1c-9d34-6202-72613cb7438d@oracle.com> <2c61ef7c-91f0-9636-5567-eaf8bbff7c94@oracle.com> <30b2b3c5-38f7-8569-10cd-e781129b5da5@oracle.com> <5a2f0358-d5e4-2fdc-5791-e6d45f9d5b02@oracle.com> Message-ID: > >So compiler ifdefs in the cpu files is the way to handle this. > Hello, I moved the coding from src/hotspot/os_cpu/linux_x86/vm_version_linux_x86.cpp src/hotspot/os_cpu/windows_x86/vm_version_windows_x86.cpp Into src/hotspot/cpu/x86/vm_version_x86.cpp and guarded it with the compiler macros : http://cr.openjdk.java.net/~mbaesken/webrevs/8219241.5/ Thanks, Matthias > -----Original Message----- > From: David Holmes > Sent: Freitag, 5. April 2019 00:50 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Cc: Doerr, Martin > Subject: Re: RFR: 8219241: Provide basic virtualization related info in the > hs_error file on linux/windows x86_64 > > On 4/04/2019 10:35 pm, Baesken, Matthias wrote: > >> > >> On 4/04/2019 8:54 pm, Baesken, Matthias wrote: > >>>> > >>>> My remaining query is why we need the OS specific checks and code in > >>>> os-cpu files? Isn't this just cpu specific? Even if a particular OS > >>>> doesn't support virtualization, won't the cpuid query simply report "no > >>>> virtualization"? > >>>> > >>> > >>> Hi David, if you are referring to these os-cpu files : > >>> > >>> src/hotspot/os_cpu/linux_x86/vm_version_linux_x86.cpp > >>> src/hotspot/os_cpu/windows_x86/vm_version_windows_x86.cpp > >>> > >>> we have different coding available because I am not aware of a cross > OS > >> API/coding to get the cpu id info. > >>> That?s why different coding for LINUX/Windows. > >> > >> ?? But there's nothing in those added functions that is Linux specific > >> or Windows specific! The only difference is the mechanism for doing > >> "inline assembly" and that's compiler specific. So this should just use > >> compiler based ifdefs in vm_version_x86.cpp. > >> > > > > Hi David, I see your point. But I thought we want to reduce the ifdefs and > favor putting code into the os or os/cpu specific files . > > But it is true , from a technical point we could do using the compiler macros > . > > I favour putting os-specific code in os-specific files over OS ifdefs in > shared files. But here we are talking about compiler-specific code that > is also CPU specific (not os specific). So compiler ifdefs in the cpu > files is the way to handle this. > > Thanks, > David > > > Best regards, Matthias > > > > From david.holmes at oracle.com Fri Apr 5 08:45:09 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 5 Apr 2019 18:45:09 +1000 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <49615c26-8ad8-ca99-a66f-d5884164d99f@redhat.com> Message-ID: Hi Peter, On 5/04/2019 5:37 pm, Peter Levart wrote: > Hi Andrew, > > For a casual reader (like me) the comments in the UnsafeConstants for > each field: > > ? 69????? * @implNote > ? 70????? * The actual value for this field is injected by the JVM. > > ...make one wonder what is actually going on regarding the static > initializer at the end of the class. Is it actually executed? Is it > there just to silence the javac and prevent fields from becoming > compile-time constants? That's what the earlier class comment is about: * @implNote * * The JVM injects hardware-specific values into all the static fields * of this class during JVM initialization. The static initialization * block exists to prevent the fields from being considered constant * variables, so the field values will be not be compiled directly into * any class that uses them. */ Cheers, David > Reading the patch further uncovers the secret: > > 3645?? // initialize the hardware-specific constants needed by Unsafe > 3646 initialize_class(vmSymbols::jdk_internal_misc_UnsafeConstants(), > CHECK); > 3647?? jdk_internal_misc_UnsafeConstants::set_unsafe_constants(); > > If my understanding is correct, then the static initializer *is* > executed and then the fields' values are overwritten with injected values. > > So perhaps it might be nice to write that down in the javadoc like: > > ? 69????? * @implNote > ? 70????? * The actual value for this field is injected by the JVM > immediately after the class initialization. > > Or something similar in the class-level javadoc. > > Just for the peace of mind of casual readers or perhaps someone that > might later add a field to this class and try to initialize it in the > static initializer, although I think this class is reserved for injected > fields only... > > Regards, Peter > > On 4/4/19 5:19 PM, Andrew Dinn wrote: >> New webrev is now available. Re-reviews welcome. >> >> JIRA:?? https://bugs.openjdk.java.net/browse/JDK-8221477 >> Webrev: http://cr.openjdk.java.net/~adinn/8221477/webrev.03 >> >> This version should address all comments from Thomas, David and Coleen. >> >> Testing >> Tier1 test passed. >> Submit test passed. >> >> regards, >> >> >> Andrew Dinn >> ----------- >> Senior Principal Software Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From adinn at redhat.com Fri Apr 5 08:48:15 2019 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 5 Apr 2019 09:48:15 +0100 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <49615c26-8ad8-ca99-a66f-d5884164d99f@redhat.com> Message-ID: Hi Peter, Thanks for the last-minute recommendation! On 05/04/2019 08:37, Peter Levart wrote: > For a casual reader (like me) the comments in the UnsafeConstants for > each field: > > ? 69????? * @implNote > ? 70????? * The actual value for this field is injected by the JVM. > > ...make one wonder what is actually going on regarding the static > initializer at the end of the class. Is it actually executed? Is it > there just to silence the javac and prevent fields from becoming > compile-time constants? Regarding the static initializer ... there is an explanatory implNote explaining the rationale for the static block in the class javadoc at the top of the file. I agree this could be improved by explaining that the block is executed and then its settings are overridden: * @implNote * * The JVM injects hardware-specific values into all the static fields * of this class during JVM initialization. The static initialization * block is executed when the class is initialized then JVM injection * updates the fields with the correct constants. The static block * is required to prevent the fields from being considered constant * variables, so the field values will be not be compiled directly into * any class that uses them. Regarding the field Javadoc ... I understand that an OpenJDK dev might want a correct and complete model for what exactly happens during init however that is rather a moot point as regards semantics of the value in the Java code. The nett effect is as the javadoc states -- the value is injected by the JVM and, per the text above, that value identifies the relevant hardware/os config parameter. So, I'll stop at expanding the class-level comment. > Just for the peace of mind of casual readers or perhaps someone that > might later add a field to this class and try to initialize it in the > static initializer, although I think this class is reserved for injected > fields only... Understood. I think the class-level comment already makes that latter detail explicit and the revised version gives enough warning to devs. I hope the above changes is acceptable. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Fri Apr 5 08:49:50 2019 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 5 Apr 2019 09:49:50 +0100 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <49615c26-8ad8-ca99-a66f-d5884164d99f@redhat.com> Message-ID: <9f1a1032-6739-5f15-ee39-9376bbaa4c20@redhat.com> HI David, On 05/04/2019 04:54, David Holmes wrote: > Hi Andrew, > > This all looks good to me - thanks for making the changes. Thank you for the corrections and improvements. > Two nits: > - BE was barely acceptable when used like a local variable, but now I > think BIG_ENDIAN would be better. > - If you don't use static import you can name the UnsafeConstants fields > the obvious way without clashing with public fields in Unsafe. > > Feel free to ignore those nits. If you do make a change no need to see > another webrev. Well, I changed BE to BIG_ENDIAN and it doesn't look as messy as I thought. So BIG_ENDIAN it is. However, omitting the static import requires UnsafeConstants.BIG_ENDIAN at multiple mentions. That does look too cluttered for comfortable reading. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From david.holmes at oracle.com Fri Apr 5 08:51:48 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 5 Apr 2019 18:51:48 +1000 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> <69018b42-7540-9222-a296-db28b99cdf91@oracle.com> <79a6f9dd-7f20-649c-a6c4-e6cf8f098130@oracle.com> <9c841ef7-4190-f5f8-fcfd-291c178a264d@oracle.com> Message-ID: <121cf2e9-6278-5703-8935-1a86ccd1f9f8@oracle.com> Hi Thomas, On 5/04/2019 6:23 pm, Thomas St?fe wrote: > Hi, > > sorry, just sniping in from the side. > > About the motivation: the original intent of Yasumasas patch was to > reduce the length of the event log messages. > > I have a patch out there for RFR, since ~2 weeks or so, which largely > solves this problem: > > https://bugs.openjdk.java.net/browse/JDK-8220762 > > The patch abolishes fixed-length string records in the event log in > favor of variable length strings, and therefore uses the event log > buffer much more efficiently. Truncation could still happen but is very > unlikely. > > The patch is out since some time and has no reviews yet (Yasumasa agreed > to review), I did not press it since we are all very busy. But, it would > solve this problem, and maybe we do not need this fix at all. It wouldn't solve the current problem - which is the invalidation of the precompiled header file. But after it is fixed we could regress Yasumasa's change which would fix the current problem. Cheers, David > Unless we want a generic solution to problems like this. > > Cheers, Thomas > > > > > > On Fri, Apr 5, 2019 at 8:00 AM David Holmes > wrote: > > On 5/04/2019 3:23 pm, Ioi Lam wrote: > > > > > > On 4/4/19 10:08 PM, David Holmes wrote: > >> Adding back build-dev > >> > >> On 5/04/2019 2:41 pm, Ioi Lam wrote: > >>> #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET) > >>> > >>> This make me a little uneasy, as it could potential point past the > >>> end of the string. > >> > >> The intent of course is that that is impossible: > >> - _FILE_ is an absolute file path within the repo: > /something/repo/file > >> - FILE_MACRO_OFFSET gets you from / to the top-level repo directory > >> leaving "file" > >> > >> so it has to be in bounds. > >> > >>> For safety, Is it possible to get some sort of assert to make sure > >>> that __FILE__ always has more than FILE_MACRO_OFFSET characters? > >>> > >>> Maybe we can add a static object in macros.hpp with a constructor > >>> that puts __FILE__ into a list, and then we can walk the list when > >>> the VM starts up? E.g. > >>> > >>> ???? ... > >>> > >>> ???? #ifdef ASSERT > >>> ???? static ThisFileChecker __this_file_checker(__FILE__); > >>> ???? #endif > >>> > >>> ???? #endif // SHARE_UTILITIES_MACROS_HPP > >> > >> So basically you're not trusting the compiler and build system > to be > >> correct here. :) > > > > I am sure the build system is correct ..... but it's complicated. > > > > BTW, we actually have generated sources that can live outside of the > > source repo. And with luck, their names can actually be shorter than > > FILE_MACRO_OFFSET. > > Excellent point! repo sources and generated sources need not be in the > same tree, so you cannot use one "offset" to handle them both. > > David > ----- > > > > $ cd /tmp/mybld > > $ find . -name \*.cpp > > ./hotspot/variant-server/support/adlc/ad_x86_expand.cpp > > ./hotspot/variant-server/support/adlc/ad_x86_pipeline.cpp > > ./hotspot/variant-server/support/adlc/ad_x86_format.cpp > > ./hotspot/variant-server/support/adlc/dfa_x86.cpp > > ./hotspot/variant-server/support/adlc/ad_x86_misc.cpp > > ./hotspot/variant-server/support/adlc/ad_x86_gen.cpp > > ./hotspot/variant-server/support/adlc/ad_x86.cpp > > ./hotspot/variant-server/support/adlc/ad_x86_peephole.cpp > > ./hotspot/variant-server/support/adlc/ad_x86_clone.cpp > > ./hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp > > ./hotspot/variant-server/gensrc/adfiles/ad_x86_pipeline.cpp > > ./hotspot/variant-server/gensrc/adfiles/ad_x86_format.cpp > > ./hotspot/variant-server/gensrc/adfiles/dfa_x86.cpp > > ./hotspot/variant-server/gensrc/adfiles/ad_x86_misc.cpp > > ./hotspot/variant-server/gensrc/adfiles/ad_x86_gen.cpp > > ./hotspot/variant-server/gensrc/adfiles/ad_x86.cpp > > ./hotspot/variant-server/gensrc/adfiles/ad_x86_peephole.cpp > > ./hotspot/variant-server/gensrc/adfiles/ad_x86_clone.cpp > > ./hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp > > > ./hotspot/variant-server/gensrc/jvmtifiles/bytecodeInterpreterWithChecks.cpp > > > > > ./hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnterTrace.cpp > > > >> > >> Would it suffice to put a static assert in a common header, like > >> macros.hpp, that verifies the length of _FILE_ or is that not > >> available statically? > >> > > I don't know how a static assert would work. That's why I > suggested the > > static object with a constructor. > > > > Thanks > > - Ioi > > > >> Cheers, > >> David > >> > >>> > >>> Thanks > >>> - Ioi > >>> > >>> > >>> On 4/4/19 9:04 PM, David Holmes wrote: > >>>> Hi Erik, > >>>> > >>>> Build and hotspot changes seem okay. > >>>> > >>>> Thanks, > >>>> David > >>>> > >>>> On 5/04/2019 8:03 am, Erik Joelsson wrote: > >>>>> > >>>>> On 2019-04-04 14:26, Kim Barrett wrote: > >>>>>> > >>>>>> OK, I can do that. > >>>>>> > >>>>>> > ------------------------------------------------------------------------------ > > >>>>>> > >>>>>> src/hotspot/share/utilities/macros.hpp > >>>>>> ? 645 #if FILE_MACRO_OFFSET > >>>>>> ? 646 #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET) > >>>>>> ? 647 #else > >>>>>> ? 648 #define THIS_FILE __FILE__ > >>>>>> ? 649 #endif > >>>>>> > >>>>>> Is the "#if FILE_MACRO_OFFSET" an intentional test for 0, or > is this > >>>>>> an implicit test for "defined"? > >>>>>> > >>>>>> If the former, e.g. we're assuming it will always be defined > but > >>>>>> might > >>>>>> have a 0 value, then I'd skip it and just unconditionally define > >>>>>> THIS_FILE as (__FILE__ + FILE_MACRO_OFFSET). > >>>>> > >>>>> Right, that makes sense. I was sort of hedging for all > >>>>> possibilities here, but as the build logic is currently > structured, > >>>>> it will always be defined, just sometimes 0. > >>>>> > >>>>> New webrev: http://cr.openjdk.java.net/~erikj/8221851/webrev.02/ > >>>>> > >>>>> /Erik > >>>>> > >>>>>> If the latter, some compilers will (with some warning levels or > >>>>>> options, such as gcc -Wundef) complain about the (specified > by the > >>>>>> standard) implicit conversion to 0 for an unrecognized > identifier in > >>>>>> an #if expression, and an #ifdef should be used to protect > against > >>>>>> that. > >>>>>> > >>>>>> > ------------------------------------------------------------------------------ > > >>>>>> > >>>>>> > >>>>>> > >>> > > > From adinn at redhat.com Fri Apr 5 08:55:59 2019 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 5 Apr 2019 09:55:59 +0100 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <49615c26-8ad8-ca99-a66f-d5884164d99f@redhat.com> Message-ID: <1e0a6c0a-d739-71ab-8721-ba51556f7c9e@redhat.com> On 04/04/2019 19:25, coleen.phillimore at oracle.com wrote: > > This version looks good.? I think I like the do_static_fields > implementation better now. ;-) Thanks for the 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 thomas.stuefe at gmail.com Fri Apr 5 09:18:16 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 5 Apr 2019 11:18:16 +0200 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: <121cf2e9-6278-5703-8935-1a86ccd1f9f8@oracle.com> References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> <69018b42-7540-9222-a296-db28b99cdf91@oracle.com> <79a6f9dd-7f20-649c-a6c4-e6cf8f098130@oracle.com> <9c841ef7-4190-f5f8-fcfd-291c178a264d@oracle.com> <121cf2e9-6278-5703-8935-1a86ccd1f9f8@oracle.com> Message-ID: On Fri, Apr 5, 2019 at 10:51 AM David Holmes wrote: > Hi Thomas, > > On 5/04/2019 6:23 pm, Thomas St?fe wrote: > > Hi, > > > > sorry, just sniping in from the side. > > > > About the motivation: the original intent of Yasumasas patch was to > > reduce the length of the event log messages. > > > > I have a patch out there for RFR, since ~2 weeks or so, which largely > > solves this problem: > > > > https://bugs.openjdk.java.net/browse/JDK-8220762 > > > > The patch abolishes fixed-length string records in the event log in > > favor of variable length strings, and therefore uses the event log > > buffer much more efficiently. Truncation could still happen but is very > > unlikely. > > > > The patch is out since some time and has no reviews yet (Yasumasa agreed > > to review), I did not press it since we are all very busy. But, it would > > solve this problem, and maybe we do not need this fix at all. > > It wouldn't solve the current problem - which is the invalidation of the > precompiled header file. But after it is fixed we could regress > Yasumasa's change which would fix the current problem. > > Cheers, > David > Thanks. Okay, I agree. In general, it would be useful to have a variant of __FILE__ which only contains the filename. ..Thomas > > > Unless we want a generic solution to problems like this. > > > > Cheers, Thomas > > > > > > > > > > > > On Fri, Apr 5, 2019 at 8:00 AM David Holmes > > wrote: > > > > On 5/04/2019 3:23 pm, Ioi Lam wrote: > > > > > > > > > On 4/4/19 10:08 PM, David Holmes wrote: > > >> Adding back build-dev > > >> > > >> On 5/04/2019 2:41 pm, Ioi Lam wrote: > > >>> #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET) > > >>> > > >>> This make me a little uneasy, as it could potential point past > the > > >>> end of the string. > > >> > > >> The intent of course is that that is impossible: > > >> - _FILE_ is an absolute file path within the repo: > > /something/repo/file > > >> - FILE_MACRO_OFFSET gets you from / to the top-level repo > directory > > >> leaving "file" > > >> > > >> so it has to be in bounds. > > >> > > >>> For safety, Is it possible to get some sort of assert to make > sure > > >>> that __FILE__ always has more than FILE_MACRO_OFFSET characters? > > >>> > > >>> Maybe we can add a static object in macros.hpp with a > constructor > > >>> that puts __FILE__ into a list, and then we can walk the list > when > > >>> the VM starts up? E.g. > > >>> > > >>> ... > > >>> > > >>> #ifdef ASSERT > > >>> static ThisFileChecker __this_file_checker(__FILE__); > > >>> #endif > > >>> > > >>> #endif // SHARE_UTILITIES_MACROS_HPP > > >> > > >> So basically you're not trusting the compiler and build system > > to be > > >> correct here. :) > > > > > > I am sure the build system is correct ..... but it's complicated. > > > > > > BTW, we actually have generated sources that can live outside of > the > > > source repo. And with luck, their names can actually be shorter > than > > > FILE_MACRO_OFFSET. > > > > Excellent point! repo sources and generated sources need not be in > the > > same tree, so you cannot use one "offset" to handle them both. > > > > David > > ----- > > > > > > > $ cd /tmp/mybld > > > $ find . -name \*.cpp > > > ./hotspot/variant-server/support/adlc/ad_x86_expand.cpp > > > ./hotspot/variant-server/support/adlc/ad_x86_pipeline.cpp > > > ./hotspot/variant-server/support/adlc/ad_x86_format.cpp > > > ./hotspot/variant-server/support/adlc/dfa_x86.cpp > > > ./hotspot/variant-server/support/adlc/ad_x86_misc.cpp > > > ./hotspot/variant-server/support/adlc/ad_x86_gen.cpp > > > ./hotspot/variant-server/support/adlc/ad_x86.cpp > > > ./hotspot/variant-server/support/adlc/ad_x86_peephole.cpp > > > ./hotspot/variant-server/support/adlc/ad_x86_clone.cpp > > > ./hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp > > > ./hotspot/variant-server/gensrc/adfiles/ad_x86_pipeline.cpp > > > ./hotspot/variant-server/gensrc/adfiles/ad_x86_format.cpp > > > ./hotspot/variant-server/gensrc/adfiles/dfa_x86.cpp > > > ./hotspot/variant-server/gensrc/adfiles/ad_x86_misc.cpp > > > ./hotspot/variant-server/gensrc/adfiles/ad_x86_gen.cpp > > > ./hotspot/variant-server/gensrc/adfiles/ad_x86.cpp > > > ./hotspot/variant-server/gensrc/adfiles/ad_x86_peephole.cpp > > > ./hotspot/variant-server/gensrc/adfiles/ad_x86_clone.cpp > > > ./hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp > > > > > > ./hotspot/variant-server/gensrc/jvmtifiles/bytecodeInterpreterWithChecks.cpp > > > > > > > > ./hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnterTrace.cpp > > > > > >> > > >> Would it suffice to put a static assert in a common header, like > > >> macros.hpp, that verifies the length of _FILE_ or is that not > > >> available statically? > > >> > > > I don't know how a static assert would work. That's why I > > suggested the > > > static object with a constructor. > > > > > > Thanks > > > - Ioi > > > > > >> Cheers, > > >> David > > >> > > >>> > > >>> Thanks > > >>> - Ioi > > >>> > > >>> > > >>> On 4/4/19 9:04 PM, David Holmes wrote: > > >>>> Hi Erik, > > >>>> > > >>>> Build and hotspot changes seem okay. > > >>>> > > >>>> Thanks, > > >>>> David > > >>>> > > >>>> On 5/04/2019 8:03 am, Erik Joelsson wrote: > > >>>>> > > >>>>> On 2019-04-04 14:26, Kim Barrett wrote: > > >>>>>> > > >>>>>> OK, I can do that. > > >>>>>> > > >>>>>> > > > ------------------------------------------------------------------------------ > > > > >>>>>> > > >>>>>> src/hotspot/share/utilities/macros.hpp > > >>>>>> 645 #if FILE_MACRO_OFFSET > > >>>>>> 646 #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET) > > >>>>>> 647 #else > > >>>>>> 648 #define THIS_FILE __FILE__ > > >>>>>> 649 #endif > > >>>>>> > > >>>>>> Is the "#if FILE_MACRO_OFFSET" an intentional test for 0, or > > is this > > >>>>>> an implicit test for "defined"? > > >>>>>> > > >>>>>> If the former, e.g. we're assuming it will always be defined > > but > > >>>>>> might > > >>>>>> have a 0 value, then I'd skip it and just unconditionally > define > > >>>>>> THIS_FILE as (__FILE__ + FILE_MACRO_OFFSET). > > >>>>> > > >>>>> Right, that makes sense. I was sort of hedging for all > > >>>>> possibilities here, but as the build logic is currently > > structured, > > >>>>> it will always be defined, just sometimes 0. > > >>>>> > > >>>>> New webrev: > http://cr.openjdk.java.net/~erikj/8221851/webrev.02/ > > >>>>> > > >>>>> /Erik > > >>>>> > > >>>>>> If the latter, some compilers will (with some warning levels > or > > >>>>>> options, such as gcc -Wundef) complain about the (specified > > by the > > >>>>>> standard) implicit conversion to 0 for an unrecognized > > identifier in > > >>>>>> an #if expression, and an #ifdef should be used to protect > > against > > >>>>>> that. > > >>>>>> > > >>>>>> > > > ------------------------------------------------------------------------------ > > > > >>>>>> > > >>>>>> > > >>>>>> > > >>> > > > > > > From thomas.stuefe at gmail.com Fri Apr 5 09:46:28 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 5 Apr 2019 11:46:28 +0200 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: <49615c26-8ad8-ca99-a66f-d5884164d99f@redhat.com> References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <49615c26-8ad8-ca99-a66f-d5884164d99f@redhat.com> Message-ID: Still looking good :) ..Thomas On Thu, Apr 4, 2019 at 5:19 PM Andrew Dinn wrote: > New webrev is now available. Re-reviews welcome. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8221477 > Webrev: http://cr.openjdk.java.net/~adinn/8221477/webrev.03 > > This version should address all comments from Thomas, David and Coleen. > > Testing > Tier1 test passed. > Submit test passed. > > 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 stefan.karlsson at oracle.com Fri Apr 5 12:24:41 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 5 Apr 2019 14:24:41 +0200 Subject: RFR: 8221393: ResolvedMethodTable too small for StackWalking applications Message-ID: <91b768e6-5938-a2be-2f81-e5237ed13a25@oracle.com> Hi all, Please review this patch to replace the hashtable in ResolvedMethodTable, with the ConcurrentHashTable (currently used by the StringTable and SymbolTable). http://cr.openjdk.java.net/~stefank/8221393/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8221393 This solves at least two scalability problems with the ResolvedMethodTable: 1) The old table had a fixed, small size that could cause the table to be overpopulated when StackWalking APIs were used. See the bug report. The new table automatically grows when it gets filled up. 2) The old table used locks for inserts, lookups, and cleanups. This could cause large performance degradations when multiple threads used the StackWalking APIs, or resolved MethodHandle constants. The new table uses lock-free inserts and lookups, and thereby scales much better. A stack walking micro benchmark (not yet pushed) shows this. Running with 8 threads, on my 16 core machine: java -XX:+UseG1GC -Xmx1g -Xms1g -jar benchmarks.jar -wi 0 -i 5 -p depth=4 -t 8 StackWalkBench.swClassNamesDefaultOpts Baseline: avgt 25 91777.142 ? 2760.507 ns/op Change: avgt 25 8149.368 ? 212.863 ns/op Note that a lot of the code to use the ConcurrentHashTable is copied from the StringTable and/or SymbolTable. There are unifications, and maybe simplifications that we can do as follow-up RFEs. There's an open question regarding the verification code in ResolvedMethodTable::finish_dead_counter(). It's a quadratic verification operation, and has the potential to take a long time. I left it in for testing, but I don't think we should have it always enabled. For the StringTable we have VerifyStringTableAtExit, to do verification before the JVM shuts down. Any suggestions on what to do for the ResolvedMethodTable? Tested with tier1-3, tier1-7 on Linux. Thanks, StefanK From peter.levart at gmail.com Fri Apr 5 12:52:10 2019 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 5 Apr 2019 14:52:10 +0200 Subject: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM In-Reply-To: References: <2fc62430-2e2e-9ee5-ccf1-f1cde5cea416@redhat.com> <49615c26-8ad8-ca99-a66f-d5884164d99f@redhat.com> Message-ID: <6887a4dc-928f-70bc-fa1d-36cd743ac6f5@gmail.com> On 4/5/19 10:48 AM, Andrew Dinn wrote: > Hi Peter, > > Regarding the static initializer ... there is an explanatory implNote > explaining the rationale for the static block in the class javadoc at > the top of the file. I agree this could be improved by explaining that > the block is executed and then its settings are overridden: > > * @implNote > * > * The JVM injects hardware-specific values into all the static fields > * of this class during JVM initialization. The static initialization > * block is executed when the class is initialized then JVM injection > * updates the fields with the correct constants. The static block > * is required to prevent the fields from being considered constant > * variables, so the field values will be not be compiled directly into > * any class that uses them. > > Regarding the field Javadoc ... I understand that an OpenJDK dev might > want a correct and complete model for what exactly happens during init > however that is rather a moot point as regards semantics of the value in > the Java code. The nett effect is as the javadoc states -- the value is > injected by the JVM and, per the text above, that value identifies the > relevant hardware/os config parameter. So, I'll stop at expanding the > class-level comment. > >> Just for the peace of mind of casual readers or perhaps someone that >> might later add a field to this class and try to initialize it in the >> static initializer, although I think this class is reserved for injected >> fields only... > Understood. I think the class-level comment already makes that latter > detail explicit and the revised version gives enough warning to devs. > > I hope the above changes is acceptable. It is precisely what I was thinking about. It's understood that the @implNote on fields is enough for the users of the UnsafeConstants class since the injection happens magically as "part of class initialization" for them. The only place where the timing of injection is observable from Java code is in the class initializer itself where the fields are set to default values and injection hasn't happened yet... Regards, Peter > 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 jamsheed.c.m at oracle.com Fri Apr 5 13:11:52 2019 From: jamsheed.c.m at oracle.com (Jamsheed) Date: Fri, 5 Apr 2019 18:41:52 +0530 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <8b4629d4-6b3a-0e29-82f8-760719c5daeb@redhat.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <571f3d72-a22a-3b52-2942-6408072e353f@oracle.com> <144af13e-33e2-2089-f8d2-902e94485eb1@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> Message-ID: <0ea5f1b5-1245-551b-90fd-7a63e8f15e92@oracle.com> Hi, 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/ test don't pass in aarch64 in any modes in the machine i tested. so disabled the test for aarch64. Best regards, Jamsheed From erik.joelsson at oracle.com Fri Apr 5 13:56:04 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 5 Apr 2019 06:56:04 -0700 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> <69018b42-7540-9222-a296-db28b99cdf91@oracle.com> <79a6f9dd-7f20-649c-a6c4-e6cf8f098130@oracle.com> <9c841ef7-4190-f5f8-fcfd-291c178a264d@oracle.com> Message-ID: On 2019-04-04 22:23, Ioi Lam wrote: > > > On 4/4/19 10:08 PM, David Holmes wrote: >> Adding back build-dev >> >> On 5/04/2019 2:41 pm, Ioi Lam wrote: >>> #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET) >>> >>> This make me a little uneasy, as it could potential point past the >>> end of the string. >> >> The intent of course is that that is impossible: >> - _FILE_ is an absolute file path within the repo: /something/repo/file >> - FILE_MACRO_OFFSET gets you from / to the top-level repo directory >> leaving "file" >> >> so it has to be in bounds. >> >>> For safety, Is it possible to get some sort of assert to make sure >>> that __FILE__ always has more than FILE_MACRO_OFFSET characters? >>> >>> Maybe we can add a static object in macros.hpp with a constructor >>> that puts __FILE__ into a list, and then we can walk the list when >>> the VM starts up? E.g. >>> >>> ???? ... >>> >>> ???? #ifdef ASSERT >>> ???? static ThisFileChecker __this_file_checker(__FILE__); >>> ???? #endif >>> >>> ???? #endif // SHARE_UTILITIES_MACROS_HPP >> >> So basically you're not trusting the compiler and build system to be >> correct here. :) > > I am sure the build system is correct ..... but it's complicated. > > BTW, we actually have generated sources that can live outside of the > source repo. And with luck, their names can actually be shorter than > FILE_MACRO_OFFSET. > That is a very good point, completely forgot about that case. I retract my current proposal. /Erik > $ cd /tmp/mybld > $ find . -name \*.cpp > ./hotspot/variant-server/support/adlc/ad_x86_expand.cpp > ./hotspot/variant-server/support/adlc/ad_x86_pipeline.cpp > ./hotspot/variant-server/support/adlc/ad_x86_format.cpp > ./hotspot/variant-server/support/adlc/dfa_x86.cpp > ./hotspot/variant-server/support/adlc/ad_x86_misc.cpp > ./hotspot/variant-server/support/adlc/ad_x86_gen.cpp > ./hotspot/variant-server/support/adlc/ad_x86.cpp > ./hotspot/variant-server/support/adlc/ad_x86_peephole.cpp > ./hotspot/variant-server/support/adlc/ad_x86_clone.cpp > ./hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp > ./hotspot/variant-server/gensrc/adfiles/ad_x86_pipeline.cpp > ./hotspot/variant-server/gensrc/adfiles/ad_x86_format.cpp > ./hotspot/variant-server/gensrc/adfiles/dfa_x86.cpp > ./hotspot/variant-server/gensrc/adfiles/ad_x86_misc.cpp > ./hotspot/variant-server/gensrc/adfiles/ad_x86_gen.cpp > ./hotspot/variant-server/gensrc/adfiles/ad_x86.cpp > ./hotspot/variant-server/gensrc/adfiles/ad_x86_peephole.cpp > ./hotspot/variant-server/gensrc/adfiles/ad_x86_clone.cpp > ./hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp > ./hotspot/variant-server/gensrc/jvmtifiles/bytecodeInterpreterWithChecks.cpp > > ./hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnterTrace.cpp > >> >> Would it suffice to put a static assert in a common header, like >> macros.hpp, that verifies the length of _FILE_ or is that not >> available statically? >> > I don't know how a static assert would work. That's why I suggested > the static object with a constructor. > > Thanks > - Ioi > >> Cheers, >> David >> >>> >>> Thanks >>> - Ioi >>> >>> >>> On 4/4/19 9:04 PM, David Holmes wrote: >>>> Hi Erik, >>>> >>>> Build and hotspot changes seem okay. >>>> >>>> Thanks, >>>> David >>>> >>>> On 5/04/2019 8:03 am, Erik Joelsson wrote: >>>>> >>>>> On 2019-04-04 14:26, Kim Barrett wrote: >>>>>> >>>>>> OK, I can do that. >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> src/hotspot/share/utilities/macros.hpp >>>>>> ? 645 #if FILE_MACRO_OFFSET >>>>>> ? 646 #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET) >>>>>> ? 647 #else >>>>>> ? 648 #define THIS_FILE __FILE__ >>>>>> ? 649 #endif >>>>>> >>>>>> Is the "#if FILE_MACRO_OFFSET" an intentional test for 0, or is this >>>>>> an implicit test for "defined"? >>>>>> >>>>>> If the former, e.g. we're assuming it will always be defined but >>>>>> might >>>>>> have a 0 value, then I'd skip it and just unconditionally define >>>>>> THIS_FILE as (__FILE__ + FILE_MACRO_OFFSET). >>>>> >>>>> Right, that makes sense. I was sort of hedging for all >>>>> possibilities here, but as the build logic is currently >>>>> structured, it will always be defined, just sometimes 0. >>>>> >>>>> New webrev: http://cr.openjdk.java.net/~erikj/8221851/webrev.02/ >>>>> >>>>> /Erik >>>>> >>>>>> If the latter, some compilers will (with some warning levels or >>>>>> options, such as gcc -Wundef) complain about the (specified by the >>>>>> standard) implicit conversion to 0 for an unrecognized identifier in >>>>>> an #if expression, and an #ifdef should be used to protect against >>>>>> that. >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> >>> > From shade at redhat.com Fri Apr 5 15:11:16 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 5 Apr 2019 17:11:16 +0200 Subject: RFR (XS) 8221917: serviceability/sa/TestPrintMdo.java fails on 32-bit platforms Message-ID: <5285d9b1-cebe-1411-7cd6-42b43e004193@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8221917 Fix: http://cr.openjdk.java.net/~shade/8221917/webrev.01/ The failure is caused by MDO change in 11 that broke SA a little. I am planning to backport it all the way down to 11u. See bug for details. Testing: - Linux x86_32 fastdebug: TestPrintMdo, entire serviceability, tier1 - Linux x86_64 fastdebug: TestPrintMdo, entire serviceability - jdk-submit (running) Thanks, -Aleksey From erik.joelsson at oracle.com Fri Apr 5 15:09:44 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 5 Apr 2019 08:09:44 -0700 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> <69018b42-7540-9222-a296-db28b99cdf91@oracle.com> <79a6f9dd-7f20-649c-a6c4-e6cf8f098130@oracle.com> <9c841ef7-4190-f5f8-fcfd-291c178a264d@oracle.com> Message-ID: <961ce204-40c9-9de9-8069-5f362497525a@oracle.com> Hello, On 2019-04-05 06:56, Erik Joelsson wrote: > > On 2019-04-04 22:23, Ioi Lam wrote: >> >> >> I am sure the build system is correct ..... but it's complicated. >> >> BTW, we actually have generated sources that can live outside of the >> source repo. And with luck, their names can actually be shorter than >> FILE_MACRO_OFFSET. >> > That is a very good point, completely forgot about that case. I > retract my current proposal. > I took a look at the currently generated files, and none of the objects created from those files currently contain any __FILE__ references. Even so, I still agree that we cannot simply use a general offset as I proposed. Instead, I have taken Kim's proposal and implemented THIS_FILE using the this_file_helper inline function he posted. New webrev: http://cr.openjdk.java.net/~erikj/8221851/webrev.03/ Not being very familiar with the Hotspot code base, I'm quite at a loss as to where to put this. I picked globalDefinitions.hpp, but please help direct me to the right place. Also, I'm not sure wrapping the inline function in a macro is the right construct either. Note that I tested this on Windows, and at least in our buildsystem (where we use forward slashes on the compiler command lines) __FILE__ contains forward slashes. So to make it clear. This patch now does the following: * Removes the setting of -DTHIS_FILE=... from all compilation units involved in building Hotspot. * Introduces THIS_FILE as a macro in Hotspot src which gets just the filename from the __FILE__ macro. * Changes the use of the __FILE__/THIS_FILE macro in exceptions.hpp to just always use the new THIS_FILE. * Introduces the use of -fmacro-file-map, when supported by the compiler, to rewrite __FILE__ to a path relative to the workspace root. The two main improvements from this are that precompiled headers should start working with GCC again and when building with GCC 8 or later, we get rid of absolute paths from our binaries. /Erik From vladimir.kozlov at oracle.com Fri Apr 5 15:22:26 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 5 Apr 2019 08:22:26 -0700 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: References: <4b759550-f185-724f-7139-9bab648a1966@oracle.com> <119335f1-acb7-fffc-f38a-e50a96b73b3c@oracle.com> <2d206374-cfeb-9b1b-2838-e4e0a774e89d@oracle.com> <8063fb37-f1b0-8b93-bbe8-4dbeeaa54959@oracle.com> <17233985-18c7-305e-5556-fe2b38926b71@oracle.com> <3514c74d-5f6a-61cc-ebea-b9564df61673@oracle.com> Message-ID: Thank you, Stefan Vladimir On 4/4/19 1:10 AM, Stefan Karlsson wrote: > GC delta looks good. > > Thanks, > StefanK > > On 2019-04-04 09:22, Vladimir Kozlov wrote: >> New delta: >> http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.06/ >> >> Full: >> http://cr.openjdk.java.net/~kvn/8220623/webrev.06/ >> >> New changes are based on Kim and Stefan suggestions: >> >> - Moved JVMCI::oops_do() from JNIHandles to places where it should be called. >> - Moved JVMCI cleanup task to the beginning of ParallelCleaningTask::work(). >> - Used JVMCI_ONLY macro with COMMA. >> - Disable JVMCI build on SPARC. We don't use it - neither Graal or AOT are built on SPARC. Disabling also helps to >> find missing JVMCI guards. >> >> I ran hs-tier1-3 testing - it passed (hs-tier3 includes graal testing). >> I started hs-tier4..8-graal testing. >> I will do performance testing next. >> >> Thanks, >> Vladimir >> >> On 4/3/19 9:54 AM, Vladimir Kozlov wrote: >>> On 4/2/19 11:35 PM, Stefan Karlsson wrote: >>>> On 2019-04-02 22:41, Vladimir Kozlov wrote: >>>>> I ran Kitchensink with G1 and -Xmx8g. I observed that Remark pause times are not consistent even without Graal. >>>>> To see effect I added time spent in JVMCI::do_unloading() to GC log (see below [3]). The result is < 1ms - it is >>>>> less than 1% of a pause time. >>>> >>>> Kitchensink isn't really a benchmark, but a stress test. I sent you a private mail how to run these changes through >>>> our internal performance test setup. >>> >>> Okay, I will run performance tests there too. >>> >>>> >>>>> >>>>> It will have even less effect since I moved JVMCI::do_unloading() from serial path to parallel worker thread as >>>>> Stefan suggested. >>>>> >>>>> Stefan, are you satisfied with these changes now? >>>> >>>> Yes, the clean-ups look good. Thanks for cleaning this up. >>>> >>>> Kim had some extra comments about a few more places where JVMCI_ONLY could be used. >>>> >>>> I also agree with him that JVMCI::oops_do should not be placed in JNIHandles::oops_do. I think you should put it >>>> where you put the AOTLoader::oops_do calls. >>> >>> Okay. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Thanks, >>>> StefanK >>>> >>>> >>>>> >>>>> Here is latest delta update which includes previous [1] delta and >>>>> - use CompilerThreadStackSize * 2 for libgraal instead of exact value, >>>>> - removed HandleMark added for debugging (reverted changes in jvmtiImpl.cpp), >>>>> - added recent jvmci-8 changes to fix registration of native methods in libgraal (jvmciCompilerToVM.cpp) >>>>> >>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.05/ >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> [1] http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.04/ >>>>> [2] Original webrev http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ >>>>> [3] Pauses times from Kitchensink (0.0ms means there were no unloaded classes, 'NNN alive' shows how many metadata >>>>> references were processed): >>>>> >>>>> [1.083s][1554229160638ms][info ][gc,start???? ] GC(2) Pause Remark >>>>> [1.085s][1554229160639ms][info ][gc?????????? ] GC(2) JVMCI::do_unloading(): 0 alive 0.000ms >>>>> [1.099s][1554229160654ms][info ][gc?????????? ] GC(2) Pause Remark 28M->28M(108M) 16.123ms >>>>> >>>>> [3.097s][1554229162651ms][info ][gc,start???? ] GC(12) Pause Remark >>>>> [3.114s][1554229162668ms][info ][gc?????????? ] GC(12) JVMCI::do_unloading(): 3471 alive 0.164ms >>>>> [3.148s][1554229162702ms][info ][gc?????????? ] GC(12) Pause Remark 215M->213M(720M) 51.103ms >>>>> >>>>> [455.111s][1554229614666ms][info ][gc,phases,start] GC(1095) Phase 1: Mark live objects >>>>> [455.455s][1554229615010ms][info ][gc???????????? ] GC(1095) JVMCI::do_unloading(): 4048 alive 0.821ms >>>>> [455.456s][1554229615010ms][info ][gc,phases????? ] GC(1095) Phase 1: Mark live objects 344.107ms >>>>> >>>>> [848.932s][1554230008486ms][info ][gc,phases,start] GC(1860) Phase 1: Mark live objects >>>>> [849.248s][1554230008803ms][info ][gc???????????? ] GC(1860) JVMCI::do_unloading(): 3266 alive 0.470ms >>>>> [849.249s][1554230008803ms][info ][gc,phases????? ] GC(1860) Phase 1: Mark live objects 316.527ms >>>>> >>>>> [1163.778s][1554230323332ms][info ][gc,start?????? ] GC(2627) Pause Remark >>>>> [1163.932s][1554230323486ms][info ][gc???????????? ] GC(2627) JVMCI::do_unloading(): 3474 alive 0.642ms >>>>> [1163.941s][1554230323496ms][info ][gc???????????? ] GC(2627) Pause Remark 2502M->2486M(4248M) 163.296ms >>>>> >>>>> [1242.587s][1554230402141ms][info ][gc,phases,start] GC(2734) Phase 1: Mark live objects >>>>> [1242.899s][1554230402453ms][info ][gc???????????? ] GC(2734) JVMCI::do_unloading(): 3449 alive 0.570ms >>>>> [1242.899s][1554230402453ms][info ][gc,phases????? ] GC(2734) Phase 1: Mark live objects 311.719ms >>>>> >>>>> [1364.164s][1554230523718ms][info ][gc,phases,start] GC(3023) Phase 1: Mark live objects >>>>> [1364.613s][1554230524167ms][info ][gc???????????? ] GC(3023) JVMCI::do_unloading(): 3449 alive 0.000ms >>>>> [1364.613s][1554230524167ms][info ][gc,phases????? ] GC(3023) Phase 1: Mark live objects 448.495ms >>>>> >>>>> [1425.222s][1554230584776ms][info ][gc,phases,start] GC(3151) Phase 1: Mark live objects >>>>> [1425.587s][1554230585142ms][info ][gc???????????? ] GC(3151) JVMCI::do_unloading(): 3491 alive 0.882ms >>>>> [1425.587s][1554230585142ms][info ][gc,phases????? ] GC(3151) Phase 1: Mark live objects 365.403ms >>>>> >>>>> [1456.401s][1554230615955ms][info ][gc,phases,start] GC(3223) Phase 1: Mark live objects >>>>> [1456.769s][1554230616324ms][info ][gc???????????? ] GC(3223) JVMCI::do_unloading(): 3478 alive 0.616ms >>>>> [1456.769s][1554230616324ms][info ][gc,phases????? ] GC(3223) Phase 1: Mark live objects 368.643ms >>>>> >>>>> [1806.139s][1554230965694ms][info?? ][gc,start?????? ] GC(4014) Pause Remark >>>>> [1806.161s][1554230965716ms][info?? ][gc???????????? ] GC(4014) JVMCI::do_unloading(): 3478 alive 0.000ms >>>>> [1806.163s][1554230965717ms][info?? ][gc???????????? ] GC(4014) Pause Remark 1305M->1177M(2772M) 23.190ms >>>>> >>>>> >>>>> >>>>> On 4/1/19 12:34 AM, Stefan Karlsson wrote: >>>>>> On 2019-03-29 17:55, Vladimir Kozlov wrote: >>>>>>> Stefan, >>>>>>> >>>>>>> Do you have a test (and flags) which can allow me to measure effect of this code on G1 remark pause? >>>>>> >>>>>> >>>>>> -Xlog:gc prints the remark times: >>>>>> [4,296s][info][gc?????? ] GC(89) Pause Remark 4M->4M(28M) 36,412ms >>>>>> >>>>>> StefanK >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 3/29/19 12:36 AM, Stefan Karlsson wrote: >>>>>>>> On 2019-03-29 03:07, Vladimir Kozlov wrote: >>>>>>>>> Hi Stefan, >>>>>>>>> >>>>>>>>> I collected some data on MetadataHandleBlock. >>>>>>>>> >>>>>>>>> First, do_unloading() code is executed only when class_unloading_occurred is 'true' - it is rare case. It >>>>>>>>> should not affect normal G1 remark pause. >>>>>>>> >>>>>>>> It's only rare for applications that don't do dynamic class loading and unloading. The applications that do, >>>>>>>> will be affected. >>>>>>>> >>>>>>>>> >>>>>>>>> Second, I run a test with -Xcomp. I got about 10,000 compilations by Graal and next data at the end of execution: >>>>>>>>> >>>>>>>>> max_blocks = 232 >>>>>>>>> max_handles_per_block = 32 (since handles array has 32 elements) >>>>>>>>> max_total_alive_values = 4631 >>>>>>>> >>>>>>>> OK. Thanks for the info. >>>>>>>> >>>>>>>> StefanK >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 3/28/19 2:44 PM, Vladimir Kozlov wrote: >>>>>>>>>> Thank you, Stefan >>>>>>>>>> >>>>>>>>>> On 3/28/19 12:54 PM, Stefan Karlsson wrote: >>>>>>>>>>> Hi Vladimir, >>>>>>>>>>> >>>>>>>>>>> I started to check the GC code. >>>>>>>>>>> >>>>>>>>>>> ======================================================================== >>>>>>>>>>> I see that you've added guarded includes in the middle of the include list: >>>>>>>>>>> ?? #include "gc/shared/strongRootsScope.hpp" >>>>>>>>>>> ?? #include "gc/shared/weakProcessor.hpp" >>>>>>>>>>> + #if INCLUDE_JVMCI >>>>>>>>>>> + #include "jvmci/jvmci.hpp" >>>>>>>>>>> + #endif >>>>>>>>>>> ?? #include "oops/instanceRefKlass.hpp" >>>>>>>>>>> ?? #include "oops/oop.inline.hpp" >>>>>>>>>>> >>>>>>>>>>> The style we use is to put these conditional includes at the end of the include lists. >>>>>>>>>> >>>>>>>>>> okay >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ======================================================================== >>>>>>>>>>> Could you also change the following: >>>>>>>>>>> >>>>>>>>>>> + #if INCLUDE_JVMCI >>>>>>>>>>> +???? // Clean JVMCI metadata handles. >>>>>>>>>>> +???? JVMCI::do_unloading(is_alive_closure(), purged_class); >>>>>>>>>>> + #endif >>>>>>>>>>> >>>>>>>>>>> to: >>>>>>>>>>> +???? // Clean JVMCI metadata handles. >>>>>>>>>>> +???? JVMCI_ONLY(JVMCI::do_unloading(is_alive_closure(), purged_class);) >>>>>>>>>>> >>>>>>>>>>> to get rid of some of the line noise in the GC files. >>>>>>>>>> >>>>>>>>>> okay >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ======================================================================== >>>>>>>>>>> In the future we will need version of JVMCI::do_unloading that supports concurrent cleaning for ZGC. >>>>>>>>>> >>>>>>>>>> Yes, we need to support concurrent cleaning in a future. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ======================================================================== >>>>>>>>>>> What's the performance impact for G1 remark pause with this serial walk over the MetadataHandleBlock? >>>>>>>>>>> >>>>>>>>>>> 3275 void G1CollectedHeap::complete_cleaning(BoolObjectClosure* is_alive, >>>>>>>>>>> 3276???????????????????????????????????????? bool class_unloading_occurred) { >>>>>>>>>>> 3277?? uint num_workers = workers()->active_workers(); >>>>>>>>>>> 3278?? ParallelCleaningTask unlink_task(is_alive, num_workers, class_unloading_occurred, false); >>>>>>>>>>> 3279?? workers()->run_task(&unlink_task); >>>>>>>>>>> 3280 #if INCLUDE_JVMCI >>>>>>>>>>> 3281?? // No parallel processing of JVMCI metadata handles for now. >>>>>>>>>>> 3282?? JVMCI::do_unloading(is_alive, class_unloading_occurred); >>>>>>>>>>> 3283 #endif >>>>>>>>>>> 3284 } >>>>>>>>>> >>>>>>>>>> There should not be impact if Graal is not used. Only cost of call (which most likely is inlined in product >>>>>>>>>> VM) and check: >>>>>>>>>> >>>>>>>>>> http://hg.openjdk.java.net/metropolis/dev/file/530fc1427d02/src/hotspot/share/jvmci/jvmciRuntime.cpp#l1237 >>>>>>>>>> >>>>>>>>>> If Graal is used it should not have big impact since these metadata has regular pattern (32 handles per array >>>>>>>>>> and array per MetadataHandleBlock block which are linked in list) and not large. >>>>>>>>>> If there will be noticeable impact - we will work on it as you suggested by using ParallelCleaningTask. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ======================================================================== >>>>>>>>>>> Did you consider adding it as a task for one of the worker threads to execute in ParallelCleaningTask? >>>>>>>>>>> >>>>>>>>>>> See how other tasks are claimed by one worker: >>>>>>>>>>> void KlassCleaningTask::work() { >>>>>>>>>>> ?? ResourceMark rm; >>>>>>>>>>> >>>>>>>>>>> ?? // One worker will clean the subklass/sibling klass tree. >>>>>>>>>>> ?? if (claim_clean_klass_tree_task()) { >>>>>>>>>>> ???? Klass::clean_subklass_tree(); >>>>>>>>>>> ?? } >>>>>>>>>> >>>>>>>>>> These changes were ported from JDK8u based changes in graal-jvmci-8 and there are no ParallelCleaningTask in >>>>>>>>>> JDK8. >>>>>>>>>> >>>>>>>>>> Your suggestion is interesting and I agree that we should investigate it. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ======================================================================== >>>>>>>>>>> In MetadataHandleBlock::do_unloading: >>>>>>>>>>> >>>>>>>>>>> +??????? if (klass->class_loader_data()->is_unloading()) { >>>>>>>>>>> +????????? // This needs to be marked so that it's no longer scanned >>>>>>>>>>> +????????? // but can't be put on the free list yet. The >>>>>>>>>>> +????????? // ReferenceCleaner will set this to NULL and >>>>>>>>>>> +????????? // put it on the free list. >>>>>>>>>>> >>>>>>>>>>> I couldn't find the ReferenceCleaner in the patch or in the source. Where can I find this code? >>>>>>>>>> >>>>>>>>>> I think it is typo (I will fix it) - it references new HandleCleaner class: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HandleCleaner.java.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> StefanK >>>>>>>>>>> >>>>>>>>>>> On 2019-03-28 20:15, Vladimir Kozlov wrote: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8220623 >>>>>>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ >>>>>>>>>>>> >>>>>>>>>>>> Update JVMCI to support pre-compiled as shared library Graal. >>>>>>>>>>>> Using aoted Graal can offers benefits including: >>>>>>>>>>>> ?- fast startup >>>>>>>>>>>> ?- compile time similar to native JIt compilers (C2) >>>>>>>>>>>> ?- memory usage disjoint from the application Java heap >>>>>>>>>>>> ?- no profile pollution of JDK code used by the application >>>>>>>>>>>> >>>>>>>>>>>> This is JDK13 port of JVMCI changes done in graal-jvmci-8 [1] up to date. >>>>>>>>>>>> Changes were collected in Metropolis repo [2] and tested there. >>>>>>>>>>>> >>>>>>>>>>>> Changes we reviewed by Oracle Labs (authors of JVMCI and Graal) and our compiler group. >>>>>>>>>>>> Changes in shared code are guarded by #if INCLUDE_JVMCI and JVMCI flags. >>>>>>>>>>>> >>>>>>>>>>>> I ran tier1-tier8 (which includes HotSpot and JDK tests) and it was clean. In this set Graal was tested only >>>>>>>>>>>> in tier3. >>>>>>>>>>>> >>>>>>>>>>>> And I ran all hs-tier3-graal .. hs-tier8-graal Graal tests available in our system. Several issue were found >>>>>>>>>>>> which were present before these changes. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>> [1] https://github.com/graalvm/graal-jvmci-8/commit/49ff2045fb603e35516a3a427d8023c00e1607af >>>>>>>>>>>> [2] http://hg.openjdk.java.net/metropolis/dev/ >>>>>>>>>>> From chris.plummer at oracle.com Fri Apr 5 17:31:01 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 5 Apr 2019 10:31:01 -0700 Subject: RFR (XS) 8221917: serviceability/sa/TestPrintMdo.java fails on 32-bit platforms In-Reply-To: <5285d9b1-cebe-1411-7cd6-42b43e004193@redhat.com> References: <5285d9b1-cebe-1411-7cd6-42b43e004193@redhat.com> Message-ID: Hi Aleksey, I looked at the changes to this file that were done in JDK-8204240 (which introduced the issue), and your fix seems correct. Thumbs up! thanks, Chris On 4/5/19 8:11 AM, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8221917 > > Fix: > http://cr.openjdk.java.net/~shade/8221917/webrev.01/ > > The failure is caused by MDO change in 11 that broke SA a little. I am planning to backport it all > the way down to 11u. See bug for details. > > Testing: > - Linux x86_32 fastdebug: TestPrintMdo, entire serviceability, tier1 > - Linux x86_64 fastdebug: TestPrintMdo, entire serviceability > - jdk-submit (running) > > Thanks, > -Aleksey > > From kim.barrett at oracle.com Fri Apr 5 22:46:00 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 5 Apr 2019 18:46:00 -0400 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: <961ce204-40c9-9de9-8069-5f362497525a@oracle.com> References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> <69018b42-7540-9222-a296-db28b99cdf91@oracle.com> <79a6f9dd-7f20-649c-a6c4-e6cf8f098130@oracle.com> <9c841ef7-4190-f5f8-fcfd-291c178a264d@oracle.com> <961ce204-40c9-9de9-8069-5f362497525a@oracle.com> Message-ID: <927E24E0-BD59-42C1-8FF9-957EF0E6D55E@oracle.com> > On Apr 5, 2019, at 11:09 AM, Erik Joelsson wrote: > So to make it clear. This patch now does the following: > > * Removes the setting of -DTHIS_FILE=... from all compilation units involved in building Hotspot. > > * Introduces THIS_FILE as a macro in Hotspot src which gets just the filename from the __FILE__ macro. > > * Changes the use of the __FILE__/THIS_FILE macro in exceptions.hpp to just always use the new THIS_FILE. > > * Introduces the use of -fmacro-file-map, when supported by the compiler, to rewrite __FILE__ to a path relative to the workspace root. > > The two main improvements from this are that precompiled headers should start working with GCC again and when building with GCC 8 or later, we get rid of absolute paths from our binaries. > > /Erik (I've only looked at the src/hotspot changes.) It's not clear there's a reason to put this_file_helper and THIS_FILE anywhere other than in exceptions.hpp. I don't think there's a (known) benefit to using it anywhere else. Using a trimmed __FILE__ doesn't eliminate the "absolute paths embedded in binaries" problem. For that we need -fmacro-file-map or the like (or perhaps give up on absolute paths in the build system, but those are pretty useful in the .cmdfile files at least). Assuming all that, consider instead putting this_file_helper in exceptions.hpp (perhaps with a better name?), don't bother with THIS_FILE, and define THREAD_AND_LOCATION as #define THREAD_AND_LOCATION THREAD, this_file_helper(__FILE__), __LINE__ From kim.barrett at oracle.com Fri Apr 5 23:56:15 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 5 Apr 2019 19:56:15 -0400 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: References: <4b759550-f185-724f-7139-9bab648a1966@oracle.com> <119335f1-acb7-fffc-f38a-e50a96b73b3c@oracle.com> <2d206374-cfeb-9b1b-2838-e4e0a774e89d@oracle.com> <8063fb37-f1b0-8b93-bbe8-4dbeeaa54959@oracle.com> <17233985-18c7-305e-5556-fe2b38926b71@oracle.com> <3514c74d-5f6a-61cc-ebea-b9564df61673@oracle.com> Message-ID: > On Apr 4, 2019, at 7:45 PM, Vladimir Kozlov wrote: > > Thank you, Kim > > I moved HotSpotJVMCI methods which call JNIHandles::resolve() to jvmciJavaClasses.cpp file so that I don't need to include jniHandles.inline.hpp into .hpp file. > > I will update changes when I address your other comments. Here are a few more comments. I really want to better understand the MetadataHandle stuff, but I don't think I will be able to seriously dig into it for a while. I'm not sanguine about what seems to be yet another weak reference mechanism. ------------------------------------------------------------------------------ src/hotspot/share/prims/jvmtiTagMap.cpp 3046 blk.set_kind(JVMTI_HEAP_REFERENCE_OTHER); 3047 Universe::oops_do(&blk); 3048 3049 #if INCLUDE_JVMCI 3050 blk.set_kind(JVMTI_HEAP_REFERENCE_OTHER); 3051 JVMCI::oops_do(&blk); 3052 if (blk.stopped()) { 3053 return false; 3054 } 3055 #endif (New code starts with line 3049.) There should probably be a blk.stopped() check after the call to Universe::oops_do. This seems like a pre-existing bug, made more apparent by the addition of the JVMCI code. ------------------------------------------------------------------------------ src/hotspot/share/classfile/classFileParser.cpp 5634 if (!is_internal()) { 5635 bool trace_class_loading = log_is_enabled(Info, class, load); 5636 #if INCLUDE_JVMCI 5637 bool trace_loading_cause = TraceClassLoadingCause != NULL && 5638 (strcmp(TraceClassLoadingCause, "*") == 0 || 5639 strstr(ik->external_name(), TraceClassLoadingCause) != NULL); 5640 trace_class_loading = trace_class_loading || trace_loading_cause; 5641 #endif 5642 if (trace_class_loading) { 5643 ResourceMark rm; 5644 const char* module_name = (module_entry->name() == NULL) ? UNNAMED_MODULE : module_entry->name()->as_C_string(); 5645 ik->print_class_load_logging(_loader_data, module_name, _stream); 5646 #if INCLUDE_JVMCI 5647 if (trace_loading_cause) { 5648 JavaThread::current()->print_stack_on(tty); 5649 } 5650 #endif This appears to be attempting to force a call to print_class_load_logging if either log_is_enabled(Info, class, load) is true or if TraceClassLoadingCause triggers it. But print_class_load_logging does nothing if that logging is not enabled, with the result that if it isn't enabled, but the tracing option matches, we'll get a mysterious stack trace printed and nothing else. I suspect that isn't the desired behavior. ------------------------------------------------------------------------------ src/hotspot/share/jvmci/jvmciRuntime.cpp 135 // The following instance variables are only used by the first block in a chain. 136 // Having two types of blocks complicates the code and the space overhead is negligible. 137 MetadataHandleBlock* _last; // Last block in use 138 intptr_t _free_list; // Handle free list 139 int _allocate_before_rebuild; // Number of blocks to allocate before rebuilding free list There seems to be exactly one MetadataHandleBlock chain, in _metadata_handles. So these instance variables could be static class variables. If there was more than one list, I think a better approach would have a MetadataHandleBlockList class that had those members and a pointer to the first block in the list. This code seems to have been pretty much copy-paste-modified from JNIHandleBlock, which has somewhat different requirements and usage pattern. ------------------------------------------------------------------------------ From vladimir.kozlov at oracle.com Sat Apr 6 00:58:34 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 5 Apr 2019 17:58:34 -0700 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: References: <4b759550-f185-724f-7139-9bab648a1966@oracle.com> <119335f1-acb7-fffc-f38a-e50a96b73b3c@oracle.com> <2d206374-cfeb-9b1b-2838-e4e0a774e89d@oracle.com> <8063fb37-f1b0-8b93-bbe8-4dbeeaa54959@oracle.com> <17233985-18c7-305e-5556-fe2b38926b71@oracle.com> <3514c74d-5f6a-61cc-ebea-b9564df61673@oracle.com> Message-ID: <66bedd54-769a-b6e7-1508-b5648e9c3e82@oracle.com> Thank you, Kim On 4/5/19 4:56 PM, Kim Barrett wrote: >> On Apr 4, 2019, at 7:45 PM, Vladimir Kozlov wrote: >> >> Thank you, Kim >> >> I moved HotSpotJVMCI methods which call JNIHandles::resolve() to jvmciJavaClasses.cpp file so that I don't need to include jniHandles.inline.hpp into .hpp file. >> >> I will update changes when I address your other comments. > > Here are a few more comments. > > I really want to better understand the MetadataHandle stuff, but I > don't think I will be able to seriously dig into it for a while. I'm > not sanguine about what seems to be yet another weak reference > mechanism. > > ------------------------------------------------------------------------------ > src/hotspot/share/prims/jvmtiTagMap.cpp > 3046 blk.set_kind(JVMTI_HEAP_REFERENCE_OTHER); > 3047 Universe::oops_do(&blk); > 3048 > 3049 #if INCLUDE_JVMCI > 3050 blk.set_kind(JVMTI_HEAP_REFERENCE_OTHER); > 3051 JVMCI::oops_do(&blk); > 3052 if (blk.stopped()) { > 3053 return false; > 3054 } > 3055 #endif > > (New code starts with line 3049.) > > There should probably be a blk.stopped() check after the call to > Universe::oops_do. This seems like a pre-existing bug, made more > apparent by the addition of the JVMCI code. Yes, I was also puzzled about that. I will add check. > > ------------------------------------------------------------------------------ > src/hotspot/share/classfile/classFileParser.cpp > 5634 if (!is_internal()) { > 5635 bool trace_class_loading = log_is_enabled(Info, class, load); > 5636 #if INCLUDE_JVMCI > 5637 bool trace_loading_cause = TraceClassLoadingCause != NULL && > 5638 (strcmp(TraceClassLoadingCause, "*") == 0 || > 5639 strstr(ik->external_name(), TraceClassLoadingCause) != NULL); > 5640 trace_class_loading = trace_class_loading || trace_loading_cause; > 5641 #endif > 5642 if (trace_class_loading) { > 5643 ResourceMark rm; > 5644 const char* module_name = (module_entry->name() == NULL) ? UNNAMED_MODULE : module_entry->name()->as_C_string(); > 5645 ik->print_class_load_logging(_loader_data, module_name, _stream); > 5646 #if INCLUDE_JVMCI > 5647 if (trace_loading_cause) { > 5648 JavaThread::current()->print_stack_on(tty); > 5649 } > 5650 #endif > > This appears to be attempting to force a call to > print_class_load_logging if either log_is_enabled(Info, class, load) > is true or if TraceClassLoadingCause triggers it. But > print_class_load_logging does nothing if that logging is not enabled, > with the result that if it isn't enabled, but the tracing option > matches, we'll get a mysterious stack trace printed and nothing else. > I suspect that isn't the desired behavior. I will fix it. > > ------------------------------------------------------------------------------ > src/hotspot/share/jvmci/jvmciRuntime.cpp > 135 // The following instance variables are only used by the first block in a chain. > 136 // Having two types of blocks complicates the code and the space overhead is negligible. > 137 MetadataHandleBlock* _last; // Last block in use > 138 intptr_t _free_list; // Handle free list > 139 int _allocate_before_rebuild; // Number of blocks to allocate before rebuilding free list > > There seems to be exactly one MetadataHandleBlock chain, in > _metadata_handles. So these instance variables could be static class > variables. Agree. > > If there was more than one list, I think a better approach would have > a MetadataHandleBlockList class that had those members and a pointer > to the first block in the list. This code seems to have been pretty > much copy-paste-modified from JNIHandleBlock, which has somewhat > different requirements and usage pattern. It is only one list. I don't want to complicate it. Thanks, Vladimir From david.holmes at oracle.com Sat Apr 6 03:55:19 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 6 Apr 2019 13:55:19 +1000 Subject: [PATCH]: Add Hygon Dhyana support In-Reply-To: <8f61e7c6-bdca-770a-4c30-cc24b0da0856@yeah.net> References: <8f61e7c6-bdca-770a-4c30-cc24b0da0856@yeah.net> Message-ID: <47e72897-330d-5164-788a-7d374913034c@oracle.com> Hi Fanjinke, Sorry for the delay in getting to this. I'll help sponsor this for you. I'll file a bug, import the patch and generate a webrev so that it can be reviewed more easily (the webrev on github can't be used as it must be hosted on an OpenJDK site for legal reasons). Cheers, David On 3/04/2019 5:20 pm, Jinke Fan wrote: > Hello All, > > This patch is used to support Hygon Dhyana x86 vendor id (HygonGenuine). > As Hygon Dhyana CPU share most architecture feature same as AMD Family > 17h, the patch adds Hygon CPU Vendor ID check to reuse AMD code paths. > > Background: > ??? Chengdu Haiguang IC Design Co., Ltd (Hygon) is a Joint Venture > ??? between AMD and Haiguang Information Technology Co.,Ltd., aims at > ??? providing high performance x86 processor for China server market. > ??? Its first generation processor codename is Dhyana, which > ??? originates from AMD technology and shares most of the > ??? architecture with AMD's family 17h, but with different CPU Vendor > ??? ID("HygonGenuine")/Family series number(Family 18h). > > The patch is based on the original repository: > hg.openjdk.java.net/jdk/jdk > > changeset:?? 54384:cd3b7ad53265 > tag:???????? tip > user:??????? kvn > date:??????? Tue Apr 02 09:45:52 2019 -0700 > summary:???? 8221782: [Graal] Module jdk.internal.vm.compiler.management > has not been granted accessClassInPackage.jdk.vm.ci.services > > Please help me with the commit process. > Thank you very much! > > *patch > Webrev: > https://fjkbo.github.io/openjdk/webrev/index.html > > The output of hg diff -g: > diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp > b/src/hotspot/cpu/x86/assembler_x86.cpp > --- a/src/hotspot/cpu/x86/assembler_x86.cpp > +++ b/src/hotspot/cpu/x86/assembler_x86.cpp > @@ -3099,7 +3099,7 @@ > ???? } > ???? return; > ?? } > -? if (UseAddressNop && VM_Version::is_amd()) { > +? if (UseAddressNop && (VM_Version::is_amd() || VM_Version::is_hygon())) { > ???? // > ???? // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. > ???? //? 1: 0x90 > diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp > b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp > --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp > +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp > @@ -340,6 +340,10 @@ > ???? return !is_amd_Barcelona(); > ?? } > > +? if (is_hygon()) { > +??? return true; > +? } > + > ?? return false; > ?} > > diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp > b/src/hotspot/cpu/x86/vm_version_x86.cpp > --- a/src/hotspot/cpu/x86/vm_version_x86.cpp > +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp > @@ -1165,7 +1165,7 @@ > ???? } > ?? } > > -? if( is_amd() ) { // AMD cpus specific settings > +? if( is_amd() || is_hygon() ) { // AMD cpus specific settings > ???? if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { > ?????? // Use it on new AMD cpus starting from Opteron. > ?????? UseAddressNop = true; > @@ -1239,8 +1239,8 @@ > ???? } > ?#endif // COMPILER2 > > -??? // Some defaults for AMD family 17h > -??? if ( cpu_family() == 0x17 ) { > +??? // Some defaults for AMD family 17h || Hygon family 18h > +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { > ?????? // On family 17h processors use XMM and UnalignedLoadStores for > Array Copy > ?????? if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { > ???????? FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); > diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp > b/src/hotspot/cpu/x86/vm_version_x86.hpp > --- a/src/hotspot/cpu/x86/vm_version_x86.hpp > +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp > @@ -495,13 +495,13 @@ > ?????? result |= CPU_CX8; > ???? if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) > ?????? result |= CPU_CMOV; > -??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && > +??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() || > is_hygon()) && > ???????? _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) > ?????? result |= CPU_FXSR; > ???? // HT flag is set for multi-core processors also. > ???? if (threads_per_core() > 1) > ?????? result |= CPU_HT; > -??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && > +??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() || > is_hygon()) && > ???????? _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) > ?????? result |= CPU_MMX; > ???? if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) > @@ -576,8 +576,8 @@ > ???? if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) > ?????? result |= CPU_FMA; > > -??? // AMD features. > -??? if (is_amd()) { > +??? // AMD|Hygon features. > +??? if (is_amd() || is_hygon()) { > ?????? if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || > ?????????? (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) > ???????? result |= CPU_3DNOW_PREFETCH; > @@ -711,6 +711,7 @@ > ?? static int? cpu_family()??????? { return _cpu;} > ?? static bool is_P6()???????????? { return cpu_family() >= 6; } > ?? static bool is_amd()??????????? { assert_is_initialized(); return > _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' > +? static bool is_hygon()????????? { assert_is_initialized(); return > _cpuid_info.std_vendor_name_0 == 0x6F677948; } // 'ogyH' > ?? static bool is_intel()????????? { assert_is_initialized(); return > _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' > ?? static bool is_zx()???????????? { assert_is_initialized(); return > (_cpuid_info.std_vendor_name_0 == 0x746e6543) || > (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS? ' > ?? static bool is_atom_family()??? { return ((cpu_family() == 0x06) && > ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) || > (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton > @@ -734,7 +735,7 @@ > ?????? if (!supports_topology || result == 0) { > ???????? result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); > ?????? } > -??? } else if (is_amd()) { > +??? } else if (is_amd() || is_hygon()) { > ?????? result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); > ???? } else if (is_zx()) { > ?????? bool supports_topology = supports_processor_topology(); > @@ -770,7 +771,7 @@ > ???? intx result = 0; > ???? if (is_intel()) { > ?????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); > -??? } else if (is_amd()) { > +??? } else if (is_amd() || is_hygon()) { > ?????? result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; > ???? } else if (is_zx()) { > ?????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); > @@ -857,7 +858,7 @@ > > ?? // AMD features > ?? static bool supports_3dnow_prefetch()??? { return (_features & > CPU_3DNOW_PREFETCH) != 0; } > -? static bool supports_mmx_ext()? { return is_amd() && > _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } > +? static bool supports_mmx_ext()? { return (is_amd()||is_hygon()) && > _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } > ?? static bool supports_lzcnt()??? { return (_features & CPU_LZCNT) != > 0; } > ?? static bool supports_sse4a()??? { return (_features & CPU_SSE4A) != > 0; } > > @@ -870,7 +871,7 @@ > ?? } > ?? static bool supports_tscinv() { > ???? return supports_tscinv_bit() && > -?????????? ( (is_amd() && !is_amd_Barcelona()) || > +?????????? ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || > ????????????? is_intel_tsc_synched_at_init() ); > ?? } > > @@ -896,7 +897,7 @@ > ???? // Core????? - 256 / prefetchnta > ???? // It will be used only when AllocatePrefetchStyle > 0 > > -??? if (is_amd()) { // AMD > +??? if (is_amd() || is_hygon()) { // AMD > ?????? if (supports_sse2()) { > ???????? return 256; // Opteron > ?????? } else { > > *test > I tested it with jtreg and found no regressions. > > Base Run? > ============================== > Test summary > ============================== > ?? TEST??????????????????????????????????? TOTAL? PASS? FAIL ERROR > ?? jtreg:test/hotspot/jtreg:tier1????????? 1396? 1396???? 0???? 0 >>> jtreg:test/jdk:tier1??????????????????? 1867? 1866???? 1???? 0 << >>> jtreg:test/langtools:tier1????????????? 3920? 3919???? 1???? 0 << > ?? jtreg:test/nashorn:tier1??????????????? 0???? 0???? 0???? 0 > ?? jtreg:test/jaxp:tier1?????????????????? 0???? 0???? 0???? 0 > ============================== > TEST FAILURE > > And The result of after patching is the same as the before. > ============================== > Test summary > ============================== > ?? TEST???????????????????????????????? TOTAL? PASS? FAIL ERROR > ?? jtreg:test/hotspot/jtreg:tier1?????? 1396? 1396???? 0???? 0 >>> jtreg:test/jdk:tier1???????????????? 1867? 1866???? 1???? 0 << >>> jtreg:test/langtools:tier1?????????? 3920? 3919???? 1???? 0 << > ?? jtreg:test/nashorn:tier1???????????? 0???? 0???? 0???? 0 > ?? jtreg:test/jaxp:tier1??????????????? 0???? 0???? 0???? 0 > ============================== > TEST FAILURE > > Is there anything incorrectly? > Please let me know your comments. > > Best Regards! > Fanjinke. > From david.holmes at oracle.com Sat Apr 6 04:18:31 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 6 Apr 2019 14:18:31 +1000 Subject: RFR (XS) 8221917: serviceability/sa/TestPrintMdo.java fails on 32-bit platforms In-Reply-To: References: <5285d9b1-cebe-1411-7cd6-42b43e004193@redhat.com> Message-ID: <51234bae-cbdb-e7e0-5486-04d88ad545bb@oracle.com> +1 Please update copyright year. Thanks, David On 6/04/2019 3:31 am, Chris Plummer wrote: > Hi Aleksey, > > I looked at the changes to this file that were done in JDK-8204240 > (which introduced the issue), and your fix seems correct. Thumbs up! > > thanks, > > Chris > > On 4/5/19 8:11 AM, Aleksey Shipilev wrote: >> Bug: >> ?? https://bugs.openjdk.java.net/browse/JDK-8221917 >> >> Fix: >> ?? http://cr.openjdk.java.net/~shade/8221917/webrev.01/ >> >> The failure is caused by MDO change in 11 that broke SA a little. I am >> planning to backport it all >> the way down to 11u. See bug for details. >> >> Testing: >> ?? - Linux x86_32 fastdebug: TestPrintMdo, entire serviceability, tier1 >> ?? - Linux x86_64 fastdebug: TestPrintMdo, entire serviceability >> ?? - jdk-submit (running) >> >> Thanks, >> -Aleksey >> >> > From shade at redhat.com Sat Apr 6 09:08:33 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Sat, 6 Apr 2019 11:08:33 +0200 Subject: RFR (XS) 8221917: serviceability/sa/TestPrintMdo.java fails on 32-bit platforms In-Reply-To: <51234bae-cbdb-e7e0-5486-04d88ad545bb@oracle.com> References: <5285d9b1-cebe-1411-7cd6-42b43e004193@redhat.com> <51234bae-cbdb-e7e0-5486-04d88ad545bb@oracle.com> Message-ID: On 4/6/19 6:18 AM, David Holmes wrote: > Please update copyright year. Thanks. I updated the copyright locally. -Aleksey From david.holmes at oracle.com Sat Apr 6 11:57:16 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 6 Apr 2019 21:57:16 +1000 Subject: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: References: <2c61ef7c-91f0-9636-5567-eaf8bbff7c94@oracle.com> <30b2b3c5-38f7-8569-10cd-e781129b5da5@oracle.com> <5a2f0358-d5e4-2fdc-5791-e6d45f9d5b02@oracle.com> Message-ID: Hi Matthias, On 5/04/2019 6:26 pm, Baesken, Matthias wrote: >> >> So compiler ifdefs in the cpu files is the way to handle this. >> > > Hello, I moved the coding from > > src/hotspot/os_cpu/linux_x86/vm_version_linux_x86.cpp > src/hotspot/os_cpu/windows_x86/vm_version_windows_x86.cpp > > > Into src/hotspot/cpu/x86/vm_version_x86.cpp and guarded it with the compiler macros : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8219241.5/ I'm not clear why we are still using os-guards as well? + #elif defined(__GNUC__) && defined(__linux__) + #if defined(_LP64) && (defined(__linux__) || defined(_WIN64)) won't this code still execute okay on Solaris/BSD/MacOS ? Thanks, David > Thanks, Matthias > > > >> -----Original Message----- >> From: David Holmes >> Sent: Freitag, 5. April 2019 00:50 >> To: Baesken, Matthias ; 'hotspot- >> dev at openjdk.java.net' >> Cc: Doerr, Martin >> Subject: Re: RFR: 8219241: Provide basic virtualization related info in the >> hs_error file on linux/windows x86_64 >> >> On 4/04/2019 10:35 pm, Baesken, Matthias wrote: >>>> >>>> On 4/04/2019 8:54 pm, Baesken, Matthias wrote: >>>>>> >>>>>> My remaining query is why we need the OS specific checks and code in >>>>>> os-cpu files? Isn't this just cpu specific? Even if a particular OS >>>>>> doesn't support virtualization, won't the cpuid query simply report "no >>>>>> virtualization"? >>>>>> >>>>> >>>>> Hi David, if you are referring to these os-cpu files : >>>>> >>>>> src/hotspot/os_cpu/linux_x86/vm_version_linux_x86.cpp >>>>> src/hotspot/os_cpu/windows_x86/vm_version_windows_x86.cpp >>>>> >>>>> we have different coding available because I am not aware of a cross >> OS >>>> API/coding to get the cpu id info. >>>>> That?s why different coding for LINUX/Windows. >>>> >>>> ?? But there's nothing in those added functions that is Linux specific >>>> or Windows specific! The only difference is the mechanism for doing >>>> "inline assembly" and that's compiler specific. So this should just use >>>> compiler based ifdefs in vm_version_x86.cpp. >>>> >>> >>> Hi David, I see your point. But I thought we want to reduce the ifdefs and >> favor putting code into the os or os/cpu specific files . >>> But it is true , from a technical point we could do using the compiler macros >> . >> >> I favour putting os-specific code in os-specific files over OS ifdefs in >> shared files. But here we are talking about compiler-specific code that >> is also CPU specific (not os specific). So compiler ifdefs in the cpu >> files is the way to handle this. >> >> Thanks, >> David >> >>> Best regards, Matthias >>> >>> From fanjinke51 at yeah.net Mon Apr 8 03:35:54 2019 From: fanjinke51 at yeah.net (Jinke Fan) Date: Mon, 8 Apr 2019 11:35:54 +0800 Subject: [PATCH]: Add Hygon Dhyana support In-Reply-To: <47e72897-330d-5164-788a-7d374913034c@oracle.com> References: <8f61e7c6-bdca-770a-4c30-cc24b0da0856@yeah.net> <47e72897-330d-5164-788a-7d374913034c@oracle.com> Message-ID: <95237cc6-703e-aad0-cf3a-0a58f56c5028@yeah.net> Hi David, Thank you for your help! Best Regards! Fanjinke. On 2019/4/6 11:55, David Holmes wrote: > Hi Fanjinke, > > Sorry for the delay in getting to this. I'll help sponsor this for you. > I'll file a bug, import the patch and generate a webrev so that it can > be reviewed more easily (the webrev on github can't be used as it must > be hosted on an OpenJDK site for legal reasons). > > Cheers, > David > > On 3/04/2019 5:20 pm, Jinke Fan wrote: >> Hello All, >> >> This patch is used to support Hygon Dhyana x86 vendor id (HygonGenuine). >> As Hygon Dhyana CPU share most architecture feature same as AMD Family >> 17h, the patch adds Hygon CPU Vendor ID check to reuse AMD code paths. >> >> Background: >> ???? Chengdu Haiguang IC Design Co., Ltd (Hygon) is a Joint Venture >> ???? between AMD and Haiguang Information Technology Co.,Ltd., aims at >> ???? providing high performance x86 processor for China server market. >> ???? Its first generation processor codename is Dhyana, which >> ???? originates from AMD technology and shares most of the >> ???? architecture with AMD's family 17h, but with different CPU Vendor >> ???? ID("HygonGenuine")/Family series number(Family 18h). >> >> The patch is based on the original repository: >> hg.openjdk.java.net/jdk/jdk >> >> changeset:?? 54384:cd3b7ad53265 >> tag:???????? tip >> user:??????? kvn >> date:??????? Tue Apr 02 09:45:52 2019 -0700 >> summary:???? 8221782: [Graal] Module >> jdk.internal.vm.compiler.management has not been granted >> accessClassInPackage.jdk.vm.ci.services >> >> Please help me with the commit process. >> Thank you very much! >> >> *patch >> Webrev: >> https://fjkbo.github.io/openjdk/webrev/index.html >> >> The output of hg diff -g: >> diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp >> b/src/hotspot/cpu/x86/assembler_x86.cpp >> --- a/src/hotspot/cpu/x86/assembler_x86.cpp >> +++ b/src/hotspot/cpu/x86/assembler_x86.cpp >> @@ -3099,7 +3099,7 @@ >> ????? } >> ????? return; >> ??? } >> -? if (UseAddressNop && VM_Version::is_amd()) { >> +? if (UseAddressNop && (VM_Version::is_amd() || >> VM_Version::is_hygon())) { >> ????? // >> ????? // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. >> ????? //? 1: 0x90 >> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> @@ -340,6 +340,10 @@ >> ????? return !is_amd_Barcelona(); >> ??? } >> >> +? if (is_hygon()) { >> +??? return true; >> +? } >> + >> ??? return false; >> ??} >> >> diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp >> b/src/hotspot/cpu/x86/vm_version_x86.cpp >> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp >> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >> @@ -1165,7 +1165,7 @@ >> ????? } >> ??? } >> >> -? if( is_amd() ) { // AMD cpus specific settings >> +? if( is_amd() || is_hygon() ) { // AMD cpus specific settings >> ????? if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { >> ??????? // Use it on new AMD cpus starting from Opteron. >> ??????? UseAddressNop = true; >> @@ -1239,8 +1239,8 @@ >> ????? } >> ??#endif // COMPILER2 >> >> -??? // Some defaults for AMD family 17h >> -??? if ( cpu_family() == 0x17 ) { >> +??? // Some defaults for AMD family 17h || Hygon family 18h >> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >> ??????? // On family 17h processors use XMM and UnalignedLoadStores >> for Array Copy >> ??????? if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >> ????????? FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >> diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp >> b/src/hotspot/cpu/x86/vm_version_x86.hpp >> --- a/src/hotspot/cpu/x86/vm_version_x86.hpp >> +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp >> @@ -495,13 +495,13 @@ >> ??????? result |= CPU_CX8; >> ????? if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) >> ??????? result |= CPU_CMOV; >> -??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && >> +??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() || >> is_hygon()) && >> ????????? _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) >> ??????? result |= CPU_FXSR; >> ????? // HT flag is set for multi-core processors also. >> ????? if (threads_per_core() > 1) >> ??????? result |= CPU_HT; >> -??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && >> +??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() || >> is_hygon()) && >> ????????? _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) >> ??????? result |= CPU_MMX; >> ????? if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) >> @@ -576,8 +576,8 @@ >> ????? if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >> ??????? result |= CPU_FMA; >> >> -??? // AMD features. >> -??? if (is_amd()) { >> +??? // AMD|Hygon features. >> +??? if (is_amd() || is_hygon()) { >> ??????? if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || >> ??????????? (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) >> ????????? result |= CPU_3DNOW_PREFETCH; >> @@ -711,6 +711,7 @@ >> ??? static int? cpu_family()??????? { return _cpu;} >> ??? static bool is_P6()???????????? { return cpu_family() >= 6; } >> ??? static bool is_amd()??????????? { assert_is_initialized(); return >> _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' >> +? static bool is_hygon()????????? { assert_is_initialized(); return >> _cpuid_info.std_vendor_name_0 == 0x6F677948; } // 'ogyH' >> ??? static bool is_intel()????????? { assert_is_initialized(); return >> _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' >> ??? static bool is_zx()???????????? { assert_is_initialized(); return >> (_cpuid_info.std_vendor_name_0 == 0x746e6543) || >> (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS? ' >> ??? static bool is_atom_family()??? { return ((cpu_family() == 0x06) >> && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) >> || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton >> @@ -734,7 +735,7 @@ >> ??????? if (!supports_topology || result == 0) { >> ????????? result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); >> ??????? } >> -??? } else if (is_amd()) { >> +??? } else if (is_amd() || is_hygon()) { >> ??????? result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); >> ????? } else if (is_zx()) { >> ??????? bool supports_topology = supports_processor_topology(); >> @@ -770,7 +771,7 @@ >> ????? intx result = 0; >> ????? if (is_intel()) { >> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >> -??? } else if (is_amd()) { >> +??? } else if (is_amd() || is_hygon()) { >> ??????? result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; >> ????? } else if (is_zx()) { >> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >> @@ -857,7 +858,7 @@ >> >> ??? // AMD features >> ??? static bool supports_3dnow_prefetch()??? { return (_features & >> CPU_3DNOW_PREFETCH) != 0; } >> -? static bool supports_mmx_ext()? { return is_amd() && >> _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >> +? static bool supports_mmx_ext()? { return (is_amd()||is_hygon()) && >> _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >> ??? static bool supports_lzcnt()??? { return (_features & CPU_LZCNT) >> != 0; } >> ??? static bool supports_sse4a()??? { return (_features & CPU_SSE4A) >> != 0; } >> >> @@ -870,7 +871,7 @@ >> ??? } >> ??? static bool supports_tscinv() { >> ????? return supports_tscinv_bit() && >> -?????????? ( (is_amd() && !is_amd_Barcelona()) || >> +?????????? ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || >> ?????????????? is_intel_tsc_synched_at_init() ); >> ??? } >> >> @@ -896,7 +897,7 @@ >> ????? // Core????? - 256 / prefetchnta >> ????? // It will be used only when AllocatePrefetchStyle > 0 >> >> -??? if (is_amd()) { // AMD >> +??? if (is_amd() || is_hygon()) { // AMD >> ??????? if (supports_sse2()) { >> ????????? return 256; // Opteron >> ??????? } else { >> >> *test >> I tested it with jtreg and found no regressions. >> >> Base Run? >> ============================== >> Test summary >> ============================== >> ??? TEST??????????????????????????????????? TOTAL? PASS? FAIL ERROR >> ??? jtreg:test/hotspot/jtreg:tier1????????? 1396? 1396???? 0???? 0 >>>> jtreg:test/jdk:tier1??????????????????? 1867? 1866???? 1???? 0 << >>>> jtreg:test/langtools:tier1????????????? 3920? 3919???? 1???? 0 << >> ??? jtreg:test/nashorn:tier1??????????????? 0???? 0???? 0???? 0 >> ??? jtreg:test/jaxp:tier1?????????????????? 0???? 0???? 0???? 0 >> ============================== >> TEST FAILURE >> >> And The result of after patching is the same as the before. >> ============================== >> Test summary >> ============================== >> ??? TEST???????????????????????????????? TOTAL? PASS? FAIL ERROR >> ??? jtreg:test/hotspot/jtreg:tier1?????? 1396? 1396???? 0???? 0 >>>> jtreg:test/jdk:tier1???????????????? 1867? 1866???? 1???? 0 << >>>> jtreg:test/langtools:tier1?????????? 3920? 3919???? 1???? 0 << >> ??? jtreg:test/nashorn:tier1???????????? 0???? 0???? 0???? 0 >> ??? jtreg:test/jaxp:tier1??????????????? 0???? 0???? 0???? 0 >> ============================== >> TEST FAILURE >> >> Is there anything incorrectly? >> Please let me know your comments. >> >> Best Regards! >> Fanjinke. >> > From david.holmes at oracle.com Mon Apr 8 05:20:44 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 8 Apr 2019 15:20:44 +1000 Subject: [PATCH]: Add Hygon Dhyana support In-Reply-To: <47e72897-330d-5164-788a-7d374913034c@oracle.com> References: <8f61e7c6-bdca-770a-4c30-cc24b0da0856@yeah.net> <47e72897-330d-5164-788a-7d374913034c@oracle.com> Message-ID: <4ab4aa2c-088b-79dd-1929-d2a1e1273f7a@oracle.com> Hi Fanjinke, Bug: https://bugs.openjdk.java.net/browse/JDK-8222090 webrev: http://cr.openjdk.java.net/~dholmes/8222090/webrev/ The changes seem okay to me as far as they go, but looking at where is_amd() is used do you want additional changes in: - VM_Version_Ext::cpu_family_description(void) - VM_Version_Ext::cpu_type_description(char* const buf, size_t buf_len) They will just return "Unknown x86" at present. Thanks, David ----- On 6/04/2019 1:55 pm, David Holmes wrote: > Hi Fanjinke, > > Sorry for the delay in getting to this. I'll help sponsor this for you. > I'll file a bug, import the patch and generate a webrev so that it can > be reviewed more easily (the webrev on github can't be used as it must > be hosted on an OpenJDK site for legal reasons). > > Cheers, > David > > On 3/04/2019 5:20 pm, Jinke Fan wrote: >> Hello All, >> >> This patch is used to support Hygon Dhyana x86 vendor id (HygonGenuine). >> As Hygon Dhyana CPU share most architecture feature same as AMD Family >> 17h, the patch adds Hygon CPU Vendor ID check to reuse AMD code paths. >> >> Background: >> ???? Chengdu Haiguang IC Design Co., Ltd (Hygon) is a Joint Venture >> ???? between AMD and Haiguang Information Technology Co.,Ltd., aims at >> ???? providing high performance x86 processor for China server market. >> ???? Its first generation processor codename is Dhyana, which >> ???? originates from AMD technology and shares most of the >> ???? architecture with AMD's family 17h, but with different CPU Vendor >> ???? ID("HygonGenuine")/Family series number(Family 18h). >> >> The patch is based on the original repository: >> hg.openjdk.java.net/jdk/jdk >> >> changeset:?? 54384:cd3b7ad53265 >> tag:???????? tip >> user:??????? kvn >> date:??????? Tue Apr 02 09:45:52 2019 -0700 >> summary:???? 8221782: [Graal] Module >> jdk.internal.vm.compiler.management has not been granted >> accessClassInPackage.jdk.vm.ci.services >> >> Please help me with the commit process. >> Thank you very much! >> >> *patch >> Webrev: >> https://fjkbo.github.io/openjdk/webrev/index.html >> >> The output of hg diff -g: >> diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp >> b/src/hotspot/cpu/x86/assembler_x86.cpp >> --- a/src/hotspot/cpu/x86/assembler_x86.cpp >> +++ b/src/hotspot/cpu/x86/assembler_x86.cpp >> @@ -3099,7 +3099,7 @@ >> ????? } >> ????? return; >> ??? } >> -? if (UseAddressNop && VM_Version::is_amd()) { >> +? if (UseAddressNop && (VM_Version::is_amd() || >> VM_Version::is_hygon())) { >> ????? // >> ????? // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. >> ????? //? 1: 0x90 >> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> @@ -340,6 +340,10 @@ >> ????? return !is_amd_Barcelona(); >> ??? } >> >> +? if (is_hygon()) { >> +??? return true; >> +? } >> + >> ??? return false; >> ??} >> >> diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp >> b/src/hotspot/cpu/x86/vm_version_x86.cpp >> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp >> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >> @@ -1165,7 +1165,7 @@ >> ????? } >> ??? } >> >> -? if( is_amd() ) { // AMD cpus specific settings >> +? if( is_amd() || is_hygon() ) { // AMD cpus specific settings >> ????? if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { >> ??????? // Use it on new AMD cpus starting from Opteron. >> ??????? UseAddressNop = true; >> @@ -1239,8 +1239,8 @@ >> ????? } >> ??#endif // COMPILER2 >> >> -??? // Some defaults for AMD family 17h >> -??? if ( cpu_family() == 0x17 ) { >> +??? // Some defaults for AMD family 17h || Hygon family 18h >> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >> ??????? // On family 17h processors use XMM and UnalignedLoadStores >> for Array Copy >> ??????? if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >> ????????? FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >> diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp >> b/src/hotspot/cpu/x86/vm_version_x86.hpp >> --- a/src/hotspot/cpu/x86/vm_version_x86.hpp >> +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp >> @@ -495,13 +495,13 @@ >> ??????? result |= CPU_CX8; >> ????? if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) >> ??????? result |= CPU_CMOV; >> -??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && >> +??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() || >> is_hygon()) && >> ????????? _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) >> ??????? result |= CPU_FXSR; >> ????? // HT flag is set for multi-core processors also. >> ????? if (threads_per_core() > 1) >> ??????? result |= CPU_HT; >> -??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && >> +??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() || >> is_hygon()) && >> ????????? _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) >> ??????? result |= CPU_MMX; >> ????? if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) >> @@ -576,8 +576,8 @@ >> ????? if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >> ??????? result |= CPU_FMA; >> >> -??? // AMD features. >> -??? if (is_amd()) { >> +??? // AMD|Hygon features. >> +??? if (is_amd() || is_hygon()) { >> ??????? if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || >> ??????????? (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) >> ????????? result |= CPU_3DNOW_PREFETCH; >> @@ -711,6 +711,7 @@ >> ??? static int? cpu_family()??????? { return _cpu;} >> ??? static bool is_P6()???????????? { return cpu_family() >= 6; } >> ??? static bool is_amd()??????????? { assert_is_initialized(); return >> _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' >> +? static bool is_hygon()????????? { assert_is_initialized(); return >> _cpuid_info.std_vendor_name_0 == 0x6F677948; } // 'ogyH' >> ??? static bool is_intel()????????? { assert_is_initialized(); return >> _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' >> ??? static bool is_zx()???????????? { assert_is_initialized(); return >> (_cpuid_info.std_vendor_name_0 == 0x746e6543) || >> (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS? ' >> ??? static bool is_atom_family()??? { return ((cpu_family() == 0x06) >> && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) >> || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton >> @@ -734,7 +735,7 @@ >> ??????? if (!supports_topology || result == 0) { >> ????????? result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); >> ??????? } >> -??? } else if (is_amd()) { >> +??? } else if (is_amd() || is_hygon()) { >> ??????? result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); >> ????? } else if (is_zx()) { >> ??????? bool supports_topology = supports_processor_topology(); >> @@ -770,7 +771,7 @@ >> ????? intx result = 0; >> ????? if (is_intel()) { >> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >> -??? } else if (is_amd()) { >> +??? } else if (is_amd() || is_hygon()) { >> ??????? result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; >> ????? } else if (is_zx()) { >> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >> @@ -857,7 +858,7 @@ >> >> ??? // AMD features >> ??? static bool supports_3dnow_prefetch()??? { return (_features & >> CPU_3DNOW_PREFETCH) != 0; } >> -? static bool supports_mmx_ext()? { return is_amd() && >> _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >> +? static bool supports_mmx_ext()? { return (is_amd()||is_hygon()) && >> _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >> ??? static bool supports_lzcnt()??? { return (_features & CPU_LZCNT) >> != 0; } >> ??? static bool supports_sse4a()??? { return (_features & CPU_SSE4A) >> != 0; } >> >> @@ -870,7 +871,7 @@ >> ??? } >> ??? static bool supports_tscinv() { >> ????? return supports_tscinv_bit() && >> -?????????? ( (is_amd() && !is_amd_Barcelona()) || >> +?????????? ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || >> ?????????????? is_intel_tsc_synched_at_init() ); >> ??? } >> >> @@ -896,7 +897,7 @@ >> ????? // Core????? - 256 / prefetchnta >> ????? // It will be used only when AllocatePrefetchStyle > 0 >> >> -??? if (is_amd()) { // AMD >> +??? if (is_amd() || is_hygon()) { // AMD >> ??????? if (supports_sse2()) { >> ????????? return 256; // Opteron >> ??????? } else { >> >> *test >> I tested it with jtreg and found no regressions. >> >> Base Run? >> ============================== >> Test summary >> ============================== >> ??? TEST??????????????????????????????????? TOTAL? PASS? FAIL ERROR >> ??? jtreg:test/hotspot/jtreg:tier1????????? 1396? 1396???? 0???? 0 >>>> jtreg:test/jdk:tier1??????????????????? 1867? 1866???? 1???? 0 << >>>> jtreg:test/langtools:tier1????????????? 3920? 3919???? 1???? 0 << >> ??? jtreg:test/nashorn:tier1??????????????? 0???? 0???? 0???? 0 >> ??? jtreg:test/jaxp:tier1?????????????????? 0???? 0???? 0???? 0 >> ============================== >> TEST FAILURE >> >> And The result of after patching is the same as the before. >> ============================== >> Test summary >> ============================== >> ??? TEST???????????????????????????????? TOTAL? PASS? FAIL ERROR >> ??? jtreg:test/hotspot/jtreg:tier1?????? 1396? 1396???? 0???? 0 >>>> jtreg:test/jdk:tier1???????????????? 1867? 1866???? 1???? 0 << >>>> jtreg:test/langtools:tier1?????????? 3920? 3919???? 1???? 0 << >> ??? jtreg:test/nashorn:tier1???????????? 0???? 0???? 0???? 0 >> ??? jtreg:test/jaxp:tier1??????????????? 0???? 0???? 0???? 0 >> ============================== >> TEST FAILURE >> >> Is there anything incorrectly? >> Please let me know your comments. >> >> Best Regards! >> Fanjinke. >> From stefan.karlsson at oracle.com Mon Apr 8 06:09:27 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 8 Apr 2019 08:09:27 +0200 Subject: RFR: 8221393: ResolvedMethodTable too small for StackWalking applications In-Reply-To: <91b768e6-5938-a2be-2f81-e5237ed13a25@oracle.com> References: <91b768e6-5938-a2be-2f81-e5237ed13a25@oracle.com> Message-ID: On 2019-04-05 14:24, Stefan Karlsson wrote: ... > A stack walking micro benchmark (not yet pushed) shows this. The RFE for the micro: https://bugs.openjdk.java.net/browse/JDK-8221623 StefanK From robbin.ehn at oracle.com Mon Apr 8 08:04:01 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 8 Apr 2019 10:04:01 +0200 Subject: RFR: 8221393: ResolvedMethodTable too small for StackWalking applications In-Reply-To: <91b768e6-5938-a2be-2f81-e5237ed13a25@oracle.com> References: <91b768e6-5938-a2be-2f81-e5237ed13a25@oracle.com> Message-ID: <27ac8c2e-a7f2-db26-d93f-6cb39df691bc@oracle.com> Hi Stefan, On 4/5/19 2:24 PM, Stefan Karlsson wrote: > Note that a lot of the code to use the ConcurrentHashTable is copied from the > StringTable and/or SymbolTable. There are unifications, and maybe > simplifications that we can do as follow-up RFEs. We should really do something about this. Looks fine, thanks Robbin. > > There's an open question regarding the verification code in > ResolvedMethodTable::finish_dead_counter(). It's a quadratic verification > operation, and has the potential to take a long time. I left it in for testing, > but I don't think we should have it always enabled. For the StringTable we have > VerifyStringTableAtExit, to do verification before the JVM shuts down. Any > suggestions on what to do for the ResolvedMethodTable? > > Tested with tier1-3, tier1-7 on Linux. > > Thanks, > StefanK From matthias.baesken at sap.com Mon Apr 8 08:07:47 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 8 Apr 2019 08:07:47 +0000 Subject: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: References: <2c61ef7c-91f0-9636-5567-eaf8bbff7c94@oracle.com> <30b2b3c5-38f7-8569-10cd-e781129b5da5@oracle.com> <5a2f0358-d5e4-2fdc-5791-e6d45f9d5b02@oracle.com> Message-ID: Hi David, > >> > >> So compiler ifdefs in the cpu files is the way to handle this. > >> > > > > Hello, I moved the coding from > > > > src/hotspot/os_cpu/linux_x86/vm_version_linux_x86.cpp > > src/hotspot/os_cpu/windows_x86/vm_version_windows_x86.cpp > > > > > > Into src/hotspot/cpu/x86/vm_version_x86.cpp and guarded it with the > compiler macros : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8219241.5/ > > I'm not clear why we are still using os-guards as well? > > + #elif defined(__GNUC__) && defined(__linux__) > > + #if defined(_LP64) && (defined(__linux__) || defined(_WIN64)) > > won't this code still execute okay on Solaris/BSD/MacOS ? > It executes okay on MacOS . Most likely it works also on Solaris x86, not sure ; only Solaris Sparc is in the list of Solaris build platforms supported in JDK13 : https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms I would prefer to keep the os-guards . Best regards, Matthias From fanjinke51 at yeah.net Mon Apr 8 09:48:03 2019 From: fanjinke51 at yeah.net (Jinke Fan) Date: Mon, 8 Apr 2019 17:48:03 +0800 Subject: [PATCH]: Add Hygon Dhyana support In-Reply-To: <4ab4aa2c-088b-79dd-1929-d2a1e1273f7a@oracle.com> References: <8f61e7c6-bdca-770a-4c30-cc24b0da0856@yeah.net> <47e72897-330d-5164-788a-7d374913034c@oracle.com> <4ab4aa2c-088b-79dd-1929-d2a1e1273f7a@oracle.com> Message-ID: Hi David, Thank you for you comments.I will add changes in: - VM_Version_Ext::cpu_family_description(void) - VM_Version_Ext::cpu_type_description(char* const buf, size_t buf_len) and update the patch soon. Best Regards! Fanjinke. On 2019/4/8 13:20, David Holmes wrote: > Hi Fanjinke, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222090 > webrev: http://cr.openjdk.java.net/~dholmes/8222090/webrev/ > > The changes seem okay to me as far as they go, but looking at where > is_amd() is used do you want additional changes in: > > - VM_Version_Ext::cpu_family_description(void) > - VM_Version_Ext::cpu_type_description(char* const buf, size_t buf_len) > > They will just return "Unknown x86" at present. > > Thanks, > David > ----- > > On 6/04/2019 1:55 pm, David Holmes wrote: >> Hi Fanjinke, >> >> Sorry for the delay in getting to this. I'll help sponsor this for >> you. I'll file a bug, import the patch and generate a webrev so that >> it can be reviewed more easily (the webrev on github can't be used as >> it must be hosted on an OpenJDK site for legal reasons). >> >> Cheers, >> David >> >> On 3/04/2019 5:20 pm, Jinke Fan wrote: >>> Hello All, >>> >>> This patch is used to support Hygon Dhyana x86 vendor id (HygonGenuine). >>> As Hygon Dhyana CPU share most architecture feature same as AMD >>> Family 17h, the patch adds Hygon CPU Vendor ID check to reuse AMD >>> code paths. >>> >>> Background: >>> ???? Chengdu Haiguang IC Design Co., Ltd (Hygon) is a Joint Venture >>> ???? between AMD and Haiguang Information Technology Co.,Ltd., aims at >>> ???? providing high performance x86 processor for China server market. >>> ???? Its first generation processor codename is Dhyana, which >>> ???? originates from AMD technology and shares most of the >>> ???? architecture with AMD's family 17h, but with different CPU Vendor >>> ???? ID("HygonGenuine")/Family series number(Family 18h). >>> >>> The patch is based on the original repository: >>> hg.openjdk.java.net/jdk/jdk >>> >>> changeset:?? 54384:cd3b7ad53265 >>> tag:???????? tip >>> user:??????? kvn >>> date:??????? Tue Apr 02 09:45:52 2019 -0700 >>> summary:???? 8221782: [Graal] Module >>> jdk.internal.vm.compiler.management has not been granted >>> accessClassInPackage.jdk.vm.ci.services >>> >>> Please help me with the commit process. >>> Thank you very much! >>> >>> *patch >>> Webrev: >>> https://fjkbo.github.io/openjdk/webrev/index.html >>> >>> The output of hg diff -g: >>> diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp >>> b/src/hotspot/cpu/x86/assembler_x86.cpp >>> --- a/src/hotspot/cpu/x86/assembler_x86.cpp >>> +++ b/src/hotspot/cpu/x86/assembler_x86.cpp >>> @@ -3099,7 +3099,7 @@ >>> ????? } >>> ????? return; >>> ??? } >>> -? if (UseAddressNop && VM_Version::is_amd()) { >>> +? if (UseAddressNop && (VM_Version::is_amd() || >>> VM_Version::is_hygon())) { >>> ????? // >>> ????? // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. >>> ????? //? 1: 0x90 >>> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>> b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>> @@ -340,6 +340,10 @@ >>> ????? return !is_amd_Barcelona(); >>> ??? } >>> >>> +? if (is_hygon()) { >>> +??? return true; >>> +? } >>> + >>> ??? return false; >>> ??} >>> >>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp >>> b/src/hotspot/cpu/x86/vm_version_x86.cpp >>> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp >>> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >>> @@ -1165,7 +1165,7 @@ >>> ????? } >>> ??? } >>> >>> -? if( is_amd() ) { // AMD cpus specific settings >>> +? if( is_amd() || is_hygon() ) { // AMD cpus specific settings >>> ????? if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { >>> ??????? // Use it on new AMD cpus starting from Opteron. >>> ??????? UseAddressNop = true; >>> @@ -1239,8 +1239,8 @@ >>> ????? } >>> ??#endif // COMPILER2 >>> >>> -??? // Some defaults for AMD family 17h >>> -??? if ( cpu_family() == 0x17 ) { >>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >>> ??????? // On family 17h processors use XMM and UnalignedLoadStores >>> for Array Copy >>> ??????? if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >>> ????????? FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp >>> b/src/hotspot/cpu/x86/vm_version_x86.hpp >>> --- a/src/hotspot/cpu/x86/vm_version_x86.hpp >>> +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp >>> @@ -495,13 +495,13 @@ >>> ??????? result |= CPU_CX8; >>> ????? if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) >>> ??????? result |= CPU_CMOV; >>> -??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && >>> +??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() || >>> is_hygon()) && >>> ????????? _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) >>> ??????? result |= CPU_FXSR; >>> ????? // HT flag is set for multi-core processors also. >>> ????? if (threads_per_core() > 1) >>> ??????? result |= CPU_HT; >>> -??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && >>> +??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() || >>> is_hygon()) && >>> ????????? _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) >>> ??????? result |= CPU_MMX; >>> ????? if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) >>> @@ -576,8 +576,8 @@ >>> ????? if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>> ??????? result |= CPU_FMA; >>> >>> -??? // AMD features. >>> -??? if (is_amd()) { >>> +??? // AMD|Hygon features. >>> +??? if (is_amd() || is_hygon()) { >>> ??????? if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || >>> ??????????? (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) >>> ????????? result |= CPU_3DNOW_PREFETCH; >>> @@ -711,6 +711,7 @@ >>> ??? static int? cpu_family()??????? { return _cpu;} >>> ??? static bool is_P6()???????????? { return cpu_family() >= 6; } >>> ??? static bool is_amd()??????????? { assert_is_initialized(); return >>> _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' >>> +? static bool is_hygon()????????? { assert_is_initialized(); return >>> _cpuid_info.std_vendor_name_0 == 0x6F677948; } // 'ogyH' >>> ??? static bool is_intel()????????? { assert_is_initialized(); return >>> _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' >>> ??? static bool is_zx()???????????? { assert_is_initialized(); return >>> (_cpuid_info.std_vendor_name_0 == 0x746e6543) || >>> (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS? ' >>> ??? static bool is_atom_family()??? { return ((cpu_family() == 0x06) >>> && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) >>> || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton >>> @@ -734,7 +735,7 @@ >>> ??????? if (!supports_topology || result == 0) { >>> ????????? result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); >>> ??????? } >>> -??? } else if (is_amd()) { >>> +??? } else if (is_amd() || is_hygon()) { >>> ??????? result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); >>> ????? } else if (is_zx()) { >>> ??????? bool supports_topology = supports_processor_topology(); >>> @@ -770,7 +771,7 @@ >>> ????? intx result = 0; >>> ????? if (is_intel()) { >>> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>> -??? } else if (is_amd()) { >>> +??? } else if (is_amd() || is_hygon()) { >>> ??????? result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; >>> ????? } else if (is_zx()) { >>> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>> @@ -857,7 +858,7 @@ >>> >>> ??? // AMD features >>> ??? static bool supports_3dnow_prefetch()??? { return (_features & >>> CPU_3DNOW_PREFETCH) != 0; } >>> -? static bool supports_mmx_ext()? { return is_amd() && >>> _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >>> +? static bool supports_mmx_ext()? { return (is_amd()||is_hygon()) && >>> _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >>> ??? static bool supports_lzcnt()??? { return (_features & CPU_LZCNT) >>> != 0; } >>> ??? static bool supports_sse4a()??? { return (_features & CPU_SSE4A) >>> != 0; } >>> >>> @@ -870,7 +871,7 @@ >>> ??? } >>> ??? static bool supports_tscinv() { >>> ????? return supports_tscinv_bit() && >>> -?????????? ( (is_amd() && !is_amd_Barcelona()) || >>> +?????????? ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || >>> ?????????????? is_intel_tsc_synched_at_init() ); >>> ??? } >>> >>> @@ -896,7 +897,7 @@ >>> ????? // Core????? - 256 / prefetchnta >>> ????? // It will be used only when AllocatePrefetchStyle > 0 >>> >>> -??? if (is_amd()) { // AMD >>> +??? if (is_amd() || is_hygon()) { // AMD >>> ??????? if (supports_sse2()) { >>> ????????? return 256; // Opteron >>> ??????? } else { >>> >>> *test >>> I tested it with jtreg and found no regressions. >>> >>> Base Run? >>> ============================== >>> Test summary >>> ============================== >>> ??? TEST??????????????????????????????????? TOTAL? PASS? FAIL ERROR >>> ??? jtreg:test/hotspot/jtreg:tier1????????? 1396? 1396???? 0???? 0 >>>>> jtreg:test/jdk:tier1??????????????????? 1867? 1866???? 1???? 0 << >>>>> jtreg:test/langtools:tier1????????????? 3920? 3919???? 1???? 0 << >>> ??? jtreg:test/nashorn:tier1??????????????? 0???? 0???? 0???? 0 >>> ??? jtreg:test/jaxp:tier1?????????????????? 0???? 0???? 0???? 0 >>> ============================== >>> TEST FAILURE >>> >>> And The result of after patching is the same as the before. >>> ============================== >>> Test summary >>> ============================== >>> ??? TEST???????????????????????????????? TOTAL? PASS? FAIL ERROR >>> ??? jtreg:test/hotspot/jtreg:tier1?????? 1396? 1396???? 0???? 0 >>>>> jtreg:test/jdk:tier1???????????????? 1867? 1866???? 1???? 0 << >>>>> jtreg:test/langtools:tier1?????????? 3920? 3919???? 1???? 0 << >>> ??? jtreg:test/nashorn:tier1???????????? 0???? 0???? 0???? 0 >>> ??? jtreg:test/jaxp:tier1??????????????? 0???? 0???? 0???? 0 >>> ============================== >>> TEST FAILURE >>> >>> Is there anything incorrectly? >>> Please let me know your comments. >>> >>> Best Regards! >>> Fanjinke. >>> > From goetz.lindenmaier at sap.com Mon Apr 8 10:53:12 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 8 Apr 2019 10:53:12 +0000 Subject: RFR: 8221535: add steal tick related information to hs_error file [linux] In-Reply-To: References: <6e54431a-8e23-160a-5757-948f1041819e@oracle.com> Message-ID: Hi Matthias, thanks for making this change. I think it really can help analyzing situations on virtualized hardware. I like that you document the dependency on kernel versions. I have one comment: + st->print_cr("Steal ticks from vm start: " UINT64_FORMAT, steal_ticks_difference); + st->print_cr("Steal ticks percentage from vm start:%7.3f", steal_ticks_perc); I think you want to say "since", not "from". Also, a space before the percentage would be nice, or did you use '7' to generate the space? Looks good otherwise. I don't need to see another webrev. Best regards, Goetz. > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Dienstag, 2. April 2019 13:05 > To: David Holmes ; Thomas St?fe > > Cc: hotspot-dev at openjdk.java.net > Subject: RE: RFR: 8221535: add steal tick related information to hs_error file > [linux] > > Hi David , thanks for the review . > > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8221535.4/ > > I added the blank after if you suggested and also adjusted the comments in > bool os::Linux::get_tick_information slightly . > > May I add you as a reviewer ? > > > > I kept the has_steal_ticks for now; in case someone can confirm > > > 2.6.11+ for jdk13 I would remove it . > > > > I can't comment on that. > > > > It's a pity that we do not have such an info . > > However I found that we include here : > > http://hg.openjdk.java.net/jdk/jdk/file/69204b98dc3d/src/java.base/linux/nati > ve/libnio/fs/LinuxWatchService.c#l36 > > and this seems to be 2.6.13+ functionality : > > https://en.wikipedia.org/wiki/Inotify > > "August 29, 2005: Linux kernel version 2.6.13 released, containing merged > inotify code" > > However it is not hotspot coding, so I am not 100% sure that we really can > claim 2.6.13+ for the whole codebase . > > > Best regards , Matthias > > > > > > -----Original Message----- > > From: David Holmes > > Sent: Montag, 1. April 2019 07:01 > > To: Baesken, Matthias ; Thomas St?fe > > > > Cc: hotspot-dev at openjdk.java.net > > Subject: Re: RFR: 8221535: add steal tick related information to hs_error file > > [linux] > > > > Hi Matthias, > > > > On 29/03/2019 11:37 pm, Baesken, Matthias wrote: > > > Hello, new webrev : > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8221535.3/ > > > > > > changed the function to bool os::Linux::get_tick_information(cpu_ticks* > > > out, int which_logical_cpu = -1) > > > > Okay. > > > > > added memset? at beginning of get_tick_information > > > > Okay > > > > > removed the remaining vm_printf ?? from > > > src/hotspot/os/aix/os_perf_aix.cpp???? ?(at first I did not notice it > > > ?was ?there as well ). > > > > Okay > > > > > [ kept the struct? naming CPUPerfTicks??? ( I find plenty of such struct > > > name? styles ?in hotspot codebase ?).?? ] > > > > Agreed - no consistency and you're moving existing code so this is fine > > IMHO. > > > > >> > > > > > >>In case? we? are sure that we are always? on? 2.6.11+?? kernels, then indeed > > I can remove the? special handling. > > > > > >>I was sure? that? we are on 2.6+? but only 95%? sure that we are > > on? 2.6.11+?? . > > > > > >> > > > > > > I kept the? has_steal_ticks?? for now; in case someone? can? confirm > > > 2.6.11+??for jdk13? I would remove it . > > > > I can't comment on that. > > > > One nit in os_linux.cpp: > > > > + if((fh = fopen("/proc/stat", "r")) == NULL) { > > > > Need space after if > > > > Otherwise this all seems fine to me. > > > > Thanks, > > David > > From tobias.hartmann at oracle.com Mon Apr 8 11:21:40 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 8 Apr 2019 13:21:40 +0200 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <0ea5f1b5-1245-551b-90fd-7a63e8f15e92@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <571f3d72-a22a-3b52-2942-6408072e353f@oracle.com> <144af13e-33e2-2089-f8d2-902e94485eb1@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> Message-ID: <4354a0db-8f50-4eb0-af63-cadd5dde7ae5@oracle.com> 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 nick.gasson at arm.com Mon Apr 8 11:22:45 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Mon, 8 Apr 2019 19:22:45 +0800 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <0ea5f1b5-1245-551b-90fd-7a63e8f15e92@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <571f3d72-a22a-3b52-2942-6408072e353f@oracle.com> <144af13e-33e2-2089-f8d2-902e94485eb1@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> Message-ID: <933540d0-2e72-fed7-3833-35724324e1e6@arm.com> Hi Jamsheed, On 05/04/2019 21:11, Jamsheed wrote: > > webrev: http://cr.openjdk.java.net/~jcm/8191278/webrev.04/ > > test don't pass in aarch64 in any modes in the machine i tested. so > disabled the test for aarch64. > What failure do you get? I just tried your patch on AArch64 now and it passes on my system (after removing the @requires line ;-). Nick From erik.joelsson at oracle.com Mon Apr 8 14:28:57 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 8 Apr 2019 07:28:57 -0700 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: <927E24E0-BD59-42C1-8FF9-957EF0E6D55E@oracle.com> References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> <69018b42-7540-9222-a296-db28b99cdf91@oracle.com> <79a6f9dd-7f20-649c-a6c4-e6cf8f098130@oracle.com> <9c841ef7-4190-f5f8-fcfd-291c178a264d@oracle.com> <961ce204-40c9-9de9-8069-5f362497525a@oracle.com> <927E24E0-BD59-42C1-8FF9-957EF0E6D55E@oracle.com> Message-ID: <9513296d-6e0f-6e41-517d-9253f9ea13f6@oracle.com> Hello, On 2019-04-05 15:46, Kim Barrett wrote: >> On Apr 5, 2019, at 11:09 AM, Erik Joelsson wrote: >> So to make it clear. This patch now does the following: >> >> * Removes the setting of -DTHIS_FILE=... from all compilation units involved in building Hotspot. >> >> * Introduces THIS_FILE as a macro in Hotspot src which gets just the filename from the __FILE__ macro. >> >> * Changes the use of the __FILE__/THIS_FILE macro in exceptions.hpp to just always use the new THIS_FILE. >> >> * Introduces the use of -fmacro-file-map, when supported by the compiler, to rewrite __FILE__ to a path relative to the workspace root. >> >> The two main improvements from this are that precompiled headers should start working with GCC again and when building with GCC 8 or later, we get rid of absolute paths from our binaries. >> >> /Erik > (I've only looked at the src/hotspot changes.) > > It's not clear there's a reason to put this_file_helper and THIS_FILE > anywhere other than in exceptions.hpp. I don't think there's a (known) > benefit to using it anywhere else. Using a trimmed __FILE__ doesn't > eliminate the "absolute paths embedded in binaries" problem. For that > we need -fmacro-file-map or the like (or perhaps give up on absolute > paths in the build system, but those are pretty useful in the .cmdfile > files at least). > > Assuming all that, consider instead putting this_file_helper in > exceptions.hpp (perhaps with a better name?), don't bother with > THIS_FILE, and define THREAD_AND_LOCATION as > > #define THREAD_AND_LOCATION THREAD, this_file_helper(__FILE__), __LINE__ > Moved to exceptions.hpp, renamed to "basename", and removed the THIS_FILE macro. Given that Kim will not be able to review this further, I'm now looking for another Hotspot reviewer. http://cr.openjdk.java.net/~erikj/8221851/webrev.04/ /Erik From tim.bell at oracle.com Mon Apr 8 16:43:37 2019 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 08 Apr 2019 09:43:37 -0700 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: <9513296d-6e0f-6e41-517d-9253f9ea13f6@oracle.com> References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> <69018b42-7540-9222-a296-db28b99cdf91@oracle.com> <79a6f9dd-7f20-649c-a6c4-e6cf8f098130@oracle.com> <9c841ef7-4190-f5f8-fcfd-291c178a264d@oracle.com> <961ce204-40c9-9de9-8069-5f362497525a@oracle.com> <927E24E0-BD59-42C1-8FF9-957EF0E6D55E@oracle.com> <9513296d-6e0f-6e41-517d-9253f9ea13f6@oracle.com> Message-ID: <5CAB7A39.6070905@oracle.com> On 04/08/19 07:28, Erik Joelsson wrote: > I'm now looking for another Hotspot reviewer. > > http://cr.openjdk.java.net/~erikj/8221851/webrev.04/ I'm not a Hotspot Reviewer, however the build changes look good FWIW. Tim > Hello, > > On 2019-04-05 15:46, Kim Barrett wrote: >>> On Apr 5, 2019, at 11:09 AM, Erik Joelsson >>> wrote: >>> So to make it clear. This patch now does the following: >>> >>> * Removes the setting of -DTHIS_FILE=... from all compilation units >>> involved in building Hotspot. >>> >>> * Introduces THIS_FILE as a macro in Hotspot src which gets just the >>> filename from the __FILE__ macro. >>> >>> * Changes the use of the __FILE__/THIS_FILE macro in exceptions.hpp >>> to just always use the new THIS_FILE. >>> >>> * Introduces the use of -fmacro-file-map, when supported by the >>> compiler, to rewrite __FILE__ to a path relative to the workspace root. >>> >>> The two main improvements from this are that precompiled headers >>> should start working with GCC again and when building with GCC 8 or >>> later, we get rid of absolute paths from our binaries. >>> >>> /Erik >> (I've only looked at the src/hotspot changes.) >> >> It's not clear there's a reason to put this_file_helper and THIS_FILE >> anywhere other than in exceptions.hpp. I don't think there's a (known) >> benefit to using it anywhere else. Using a trimmed __FILE__ doesn't >> eliminate the "absolute paths embedded in binaries" problem. For that >> we need -fmacro-file-map or the like (or perhaps give up on absolute >> paths in the build system, but those are pretty useful in the .cmdfile >> files at least). >> >> Assuming all that, consider instead putting this_file_helper in >> exceptions.hpp (perhaps with a better name?), don't bother with >> THIS_FILE, and define THREAD_AND_LOCATION as >> >> #define THREAD_AND_LOCATION THREAD, this_file_helper(__FILE__), __LINE__ >> > Moved to exceptions.hpp, renamed to "basename", and removed the > THIS_FILE macro. Given that Kim will not be able to review this further, > I'm now looking for another Hotspot reviewer. > > http://cr.openjdk.java.net/~erikj/8221851/webrev.04/ > > /Erik > From kim.barrett at oracle.com Mon Apr 8 18:40:06 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 8 Apr 2019 14:40:06 -0400 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: <9513296d-6e0f-6e41-517d-9253f9ea13f6@oracle.com> References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> <69018b42-7540-9222-a296-db28b99cdf91@oracle.com> <79a6f9dd-7f20-649c-a6c4-e6cf8f098130@oracle.com> <9c841ef7-4190-f5f8-fcfd-291c178a264d@oracle.com> <961ce204-40c9-9de9-8069-5f362497525a@oracle.com> <927E24E0-BD59-42C1-8FF9-957EF0E6D55E@oracle.com> <9513296d-6e0f-6e41-517d-9253f9ea13f6@oracle.com> Message-ID: <76DD7E45-E193-4F82-AE84-D58451863537@oracle.com> > On Apr 8, 2019, at 10:28 AM, Erik Joelsson wrote: > > Hello, > > On 2019-04-05 15:46, Kim Barrett wrote: >> Assuming all that, consider instead putting this_file_helper in >> exceptions.hpp (perhaps with a better name?), don't bother with >> THIS_FILE, and define THREAD_AND_LOCATION as >> >> #define THREAD_AND_LOCATION THREAD, this_file_helper(__FILE__), __LINE__ >> > Moved to exceptions.hpp, renamed to "basename", and removed the THIS_FILE macro. ?basename? might not count as a ?better name?, as it conflicts with a POSIX function, even though we don?t presently seem to be using that anywhere that I could find. From erik.joelsson at oracle.com Mon Apr 8 19:20:12 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 8 Apr 2019 12:20:12 -0700 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: <76DD7E45-E193-4F82-AE84-D58451863537@oracle.com> References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> <69018b42-7540-9222-a296-db28b99cdf91@oracle.com> <79a6f9dd-7f20-649c-a6c4-e6cf8f098130@oracle.com> <9c841ef7-4190-f5f8-fcfd-291c178a264d@oracle.com> <961ce204-40c9-9de9-8069-5f362497525a@oracle.com> <927E24E0-BD59-42C1-8FF9-957EF0E6D55E@oracle.com> <9513296d-6e0f-6e41-517d-9253f9ea13f6@oracle.com> <76DD7E45-E193-4F82-AE84-D58451863537@oracle.com> Message-ID: On 2019-04-08 11:40, Kim Barrett wrote: >> On Apr 8, 2019, at 10:28 AM, Erik Joelsson wrote: >> >> Hello, >> >> On 2019-04-05 15:46, Kim Barrett wrote: >>> Assuming all that, consider instead putting this_file_helper in >>> exceptions.hpp (perhaps with a better name?), don't bother with >>> THIS_FILE, and define THREAD_AND_LOCATION as >>> >>> #define THREAD_AND_LOCATION THREAD, this_file_helper(__FILE__), __LINE__ >>> >> Moved to exceptions.hpp, renamed to "basename", and removed the THIS_FILE macro. > ?basename? might not count as a ?better name?, as it conflicts with a POSIX function, > even though we don?t presently seem to be using that anywhere that I could find. > > How about "simple_basename" then? Or just prefix with an underscore? The idea is to keep it internal to the headerfile, but I'm not familiar with conventions in Hotspot to know how you usually prefix/namespace things as private. /Erik From hohensee at amazon.com Mon Apr 8 16:08:29 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 8 Apr 2019 16:08:29 +0000 Subject: RFR (L) 8213501 : Deploy ExceptionJniWrapper for a few tests In-Reply-To: References: <45341168-e7e0-90d1-449f-210500882b8f@oracle.com> <55283958-de3d-07f2-51e3-ad34c5046a96@oracle.com> <31613f88-5f7d-938d-e9f6-69cdaf857268@oracle.com> <839301b7-c247-df3b-e485-283e8bb7388b@oracle.com> <95fe277d-ba6e-4fec-77aa-d1f1051751aa@oracle.com> <72bf2f4a-5bf7-98de-5f00-68485072923d@oracle.com> <25a50bc3-222c-a915-5517-37a2f9375c42@oracle.com> Message-ID: Almost all copyright changes, plus a bit of code reorg, but no real implementation changes except in ExceptionCheckingJniEnv.cpp, which are fine. A quibble: I?d have left declarations located at first use instead of moving them up to the beginning of their methods, but I?m not doctrinaire, so they?re fine too. Paul From: Jean Christophe Beyler Date: Tuesday, April 2, 2019 at 10:00 AM To: Alex Menkov Cc: "Hohensee, Paul" , hotspot-dev Source Developers Subject: Re: RFR (L) 8213501 : Deploy ExceptionJniWrapper for a few tests Hi all, Friendly ping on this one, I know I've used up quite a bit of time on it; my apologies again :) Jc On Tue, Mar 26, 2019 at 12:37 PM Jean Christophe Beyler > wrote: Hi all, My apologies again for this one. This has been a bit tricky to get in and has fell off my priority list due to other issues/commitments but I'm back to finishing this up and the next webrevs regarding this work :) Problem is that we change years so the copyrights changed on some of these and there were a few problems with various architectures/build systems that made the testing fail on the submit repo. So I offer two webrevs: - The incremental from the last LGTM stamped one: http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.06_07/ - The full webrev that cleaned up a few problems for windows and solaris and now passes the submit repo: http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.07/ And again, my sincere apologies that it took me SO long to get back to this but I had to work through the random submit repo failures and some of them took time for me to debug (thanks Serguei for your help :-)), Jc On Tue, Jan 22, 2019 at 6:03 PM Alex Menkov > wrote: +1 --alex On 01/22/2019 10:29, JC Beyler wrote: > Thanks Paul! > > Anybody else for the review for version 6? > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.06/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213501 > > > Thanks, > Jc > > On Tue, Jan 22, 2019 at 6:10 AM Hohensee, Paul > >> wrote: > > Lgtm :) > > Paul > > On 1/14/19, 7:46 AM, "hotspot-dev on behalf of JC Beyler" > > > on behalf of > jcbeyler at google.com >> wrote: > > Hi all, > > Friendly ping on this one, I know that it has been a long > process with back > and forths, to which I apologize... > > But is there any way I could get a final LGTM for version 6? > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.06/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8213501 > > Thanks! > Jc > > On Tue, Jan 8, 2019 at 10:05 AM JC Beyler > >> wrote: > > > Happy new year all! > > > > Could I get a final LGTM for version 6? > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.06/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213501 > > > > Thanks! > > Jc > > > > On Mon, Dec 17, 2018 at 8:43 AM JC Beyler > >> wrote: > > > >> Hi all, > >> > >> I don't believe I got actual LGTM for this version: > >> > >> > >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.06/ > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8213501 > >> > >> > >> It removed the namespaces and uses explicit static instead :) > >> > >> Thanks! > >> Jc > >> > >> On Wed, Dec 12, 2018 at 8:06 PM JC Beyler > >> wrote: > >> > >>> So did I Alexey but with David & Serguei preferring static, > it seems > >>> more reasonable to go down their route :-) > >>> > >>> So here is the latest webrev with static instead of an > anonymous > >>> namespace: > >>> > >>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.06/ > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213501 > >>> > >>> Let me know what you think, can I get a webrev 06 review? > >>> > >>> Thanks! > >>> Jc > >>> > >>> On Wed, Dec 12, 2018 at 3:10 PM Alex Menkov > >> > >>> wrote: > >>> > >>>> Hm.. > >>>> I considered unnamed namespaces "C++ style" (and static > globals as "C > >>>> style"). > >>>> Static globals were deprecated in C++ (but some time ago the > >>>> deprecation > >>>> was reverted). > >>>> > >>>> --alex > >>>> > >>>> On 12/12/2018 13:55, serguei.spitsyn at oracle.com > > wrote: > >>>> > Agreed. > >>>> > > >>>> > Thanks, > >>>> > Serguei > >>>> > > >>>> > > >>>> > On 12/12/18 13:52, David Holmes wrote: > >>>> >> FWIW I think namespaces are overkill in all of this > test code and > >>>> just > >>>> >> obfuscates things - the declaration is easily missed. A > static > >>>> >> variable in a .cpp is clearly a global variable to the > file. > >>>> >> > >>>> >> Cheers, > >>>> >> David > >>>> >> > >>>> >> > >>>> >> > >>>> >> On 13/12/2018 5:37 am, serguei.spitsyn at oracle.com > > wrote: > >>>> >>> Hi Jc, > >>>> >>> > >>>> >>> > >>>> >>> On 12/11/18 21:16, JC Beyler wrote: > >>>> >>>> Hi all, > >>>> >>>> > >>>> >>>> Here is the new webrev with the TEST.groups change. > Serguei, let > >>>> me > >>>> >>>> know if I convinced you with the static vs anonymous > namespaces or > >>>> >>>> if you'd still rather have a "static" for now :-) > >>>> >>> > >>>> >>> > >>>> >>> What do you think about this post? : > >>>> >>> > >>>> > https://stackoverflow.com/questions/11623451/static-vs-non-static-variables-in-namespace > >>>> >>> > >>>> >>> > >>>> >>>> > >>>> >>>> Webrev: > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.05/ > >>>> >>>> > > >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213501 > >>>> >>> > >>>> >>> The update looks fine. > >>>> >>> > >>>> >>> Thanks, > >>>> >>> Serguei > >>>> >>> > >>>> >>> > >>>> >>> Thanks, > >>>> >>> Serguei > >>>> >>> > >>>> >>>> > >>>> >>>> Thanks again for the reviews! > >>>> >>>> Jc > >>>> >>>> > >>>> >>>> On Mon, Dec 10, 2018 at 3:10 PM JC Beyler > > > >>>> >>>> > >>> wrote: > >>>> >>>> > >>>> >>>> Hi Serguei, > >>>> >>>> > >>>> >>>> Yes basically it is equivalent :) I can put them > in but they > >>>> are > >>>> >>>> not required. The norm actually wanted to > deprecate it but then > >>>> >>>> remembered that C compatibility would require the > static > >>>> key-word > >>>> >>>> for this case [1] > >>>> >>>> > >>>> >>>> So, really, they are not required here and will > amount to the > >>>> same > >>>> >>>> thing: only that file can refer to them and you > cannot get to > >>>> them > >>>> >>>> without a globally available method to return a > pointer to them > >>>> >>>> (ie same as a static variable in C). > >>>> >>>> > >>>> >>>> I can put static if it makes it easier to see > but, by being in > >>>> an > >>>> >>>> anonymous namespace they are only available for > the file's > >>>> >>>> translation unit. For example: > >>>> >>>> > >>>> >>>> $ cat main.cpp > >>>> >>>> > >>>> >>>> int totally_global; > >>>> >>>> static int explictly_static; > >>>> >>>> > >>>> >>>> namespace { > >>>> >>>> int implicitly_static; > >>>> >>>> } > >>>> >>>> > >>>> >>>> void foo(); > >>>> >>>> int main() { > >>>> >>>> foo(); > >>>> >>>> } > >>>> >>>> > >>>> >>>> $ g++ -O3 main.cpp -c > >>>> >>>> $ nm main.o > >>>> >>>> U _GLOBAL_OFFSET_TABLE_ > >>>> >>>> 0000000000000000 T main > >>>> >>>> 0000000000000000 B totally_global > >>>> >>>> U _Z3foov > >>>> >>>> > >>>> >>>> As you can see, the static and anonymous > namespace variables > >>>> are > >>>> >>>> not in the file due to not being used. If you > were to use them, > >>>> >>>> you'd see them show up as something like: > >>>> >>>> 0000000000000008 b _ZL17explicitly_static > >>>> >>>> 0000000000000004 b > _ZN12_GLOBAL__N_117implicitly_staticE > >>>> >>>> > >>>> >>>> Where again, it shows that it is mangling the > names so that no > >>>> >>>> external usage can happen without tinkering. > >>>> >>>> > >>>> >>>> Hopefully that helps :-), > >>>> >>>> Jc > >>>> >>>> > >>>> >>>> [1] > >>>> >>>> > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1012 > >>>> >>>> > >>>> >>>> > >>>> >>>> On Mon, Dec 10, 2018 at 2:04 PM > serguei.spitsyn at oracle.com > > >>>> >>>> > >> < > >>>> serguei.spitsyn at oracle.com > > >>>> >>>> > >>> wrote: > >>>> >>>> > >>>> >>>> Hi Jc, > >>>> >>>> > >>>> >>>> I had little experience with the C++ namespaces. > >>>> >>>> My understanding is that static in this > context should mean > >>>> >>>> internal linkage. > >>>> >>>> > >>>> >>>> Thanks, > >>>> >>>> Serguei > >>>> >>>> > >>>> >>>> > >>>> >>>> On 12/10/18 13:57, JC Beyler wrote: > >>>> >>>>> Hi Serguei, > >>>> >>>>> > >>>> >>>>> The variables and functions are in a > anonymous namespace; > >>>> my > >>>> >>>>> understanding of C++ is that this is > equivalent to > >>>> putting it > >>>> >>>>> as static.Hence, I didn't add them there. > Does that make > >>>> >>>>> sense? > >>>> >>>>> > >>>> >>>>> Thanks! > >>>> >>>>> Jc > >>>> >>>>> > >>>> >>>>> On Mon, Dec 10, 2018 at 1:33 PM > >>>> serguei.spitsyn at oracle.com > > >>>> >>>>> > >> > >>>> >>>>> > > > >>>> >>>>> > >>> wrote: > >>>> >>>>> > >>>> >>>>> Hi Jc, > >>>> >>>>> > >>>> >>>>> It looks good in general. > >>>> >>>>> One question though. > >>>> >>>>> > >>>> >>>>> > >>>> > http://cr.openjdk.java.net/%7Ejcbeyler/8213501/webrev.03a_04/test/hotspot/jtreg/vmTestbase/nsk/share/ExceptionCheckingJniEnv/exceptionjni001/exceptionjni001.cpp.html > >>>> >>>>> > >>>> >>>>> > >>>> >>>>> I wonder if the variables and functions > have to be > >>>> static. > >>>> >>>>> > >>>> >>>>> Thanks, > >>>> >>>>> Serguei > >>>> >>>>> > >>>> >>>>> > >>>> >>>>> On 12/5/18 11:36, JC Beyler wrote: > >>>> >>>>>> Hi all, > >>>> >>>>>> > >>>> >>>>>> My apologies to having to come back for > another > >>>> review > >>>> >>>>>> for this change: I ran into a snag when > trying to > >>>> pull > >>>> >>>>>> the latest changes compared to the base > I was working > >>>> >>>>>> on. I basically forgot that there was > an issue with > >>>> >>>>>> snprintf and that I had solved it via > JDK-8213622. > >>>> >>>>>> > >>>> >>>>>> Could I have a new review of this webrev: > >>>> >>>>>> Webrev: > >>>> >>>>>> http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.04/ > >>>> >>>>>> > > >>>> >>>>>> Bug: > >>>> https://bugs.openjdk.java.net/browse/JDK-8213501 > >>>> >>>>>> Incremental from the port of webrev.03 > that got > >>>> LGTMs: > >>>> >>>>>> > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.03a_04/ > >>>> >>>>>> > > >>>> >>>>>> > >>>> >>>>>> A few comments on this because it took > me a while to > >>>> get > >>>> >>>>>> things in a state I thought was good: > >>>> >>>>>> - I had to implement an itoa method, > do we have > >>>> >>>>>> something like that in the test base > (remember that > >>>> >>>>>> JDK-8213622 could not use sprintf due > to being in the > >>>> >>>>>> test code)? > >>>> >>>>>> > >>>> >>>>>> - The differences here compared to > the one you all > >>>> >>>>>> reviewed are: > >>>> >>>>>> - I found that adding to the > strlen/memcpy > >>>> error > >>>> >>>>>> prone and thought that I would try to > make it less > >>>> so. > >>>> >>>>>> If you want to compare, I extended the > strlen/memcpy > >>>> >>>>>> with the new format to show you if you > prefer [1] > >>>> >>>>>> - Note that the diff > between the "old > >>>> >>>>>> extended way from [1]" to the webrev.04 > can be found > >>>> >>>>>> in [2] > >>>> >>>>>> > >>>> >>>>>> - I added a test to test the > exception wrapper > >>>> in > >>>> >>>>>> tests :); I'm not sure it is deemed > useful or not but > >>>> >>>>>> helped me assure myself that I was not > doing things > >>>> >>>>>> wrong; you can find the base test file > here [3]; > >>>> should > >>>> >>>>>> we have this or not? (I know that > normally we don't > >>>> add > >>>> >>>>>> tests to vmTestbase but thought this > might be an > >>>> >>>>>> exception) > >>>> >>>>>> > >>>> >>>>>> Thanks for your help and my apologies > for the snag, > >>>> >>>>>> Jc > >>>> >>>>>> > >>>> >>>>>> [1]: > >>>> >>>>>> > >>>> > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.03a/test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.cpp.udiff.html > >>>> >>>>>> > >>>> >>>>>> < > >>>> > http://cr.openjdk.java.net/%7Ejcbeyler/8213501/webrev.03a/test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.cpp.udiff.html> > >>>> > >>>> >>>>>> > >>>> >>>>>> [2]: > >>>> >>>>>> > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.03a_04 > >>>> >>>>>> > > >>>> >>>>>> [3] > >>>> >>>>>> > >>>> > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.04/test/hotspot/jtreg/vmTestbase/nsk/share/ExceptionCheckingJniEnv/exceptionjni001/exceptionjni001.cpp.html > >>>> >>>>>> > >>>> >>>>>> < > >>>> > http://cr.openjdk.java.net/%7Ejcbeyler/8213501/webrev.04/test/hotspot/jtreg/vmTestbase/nsk/share/ExceptionCheckingJniEnv/exceptionjni001/exceptionjni001.cpp.html> > >>>> > >>>> >>>>>> > >>>> >>>>>> > >>>> >>>>>> On Mon, Dec 3, 2018 at 11:29 PM David > Holmes > >>>> >>>>>> > > > >>>> >>>>>> > >>> wrote: > >>>> >>>>>> > >>>> >>>>>> Looks fine to me. > >>>> >>>>>> > >>>> >>>>>> Thanks, > >>>> >>>>>> David > >>>> >>>>>> > >>>> >>>>>> On 4/12/2018 4:04 pm, JC Beyler wrote: > >>>> >>>>>> > Hi both, > >>>> >>>>>> > > >>>> >>>>>> > Thanks for the reviews! Since > Serguei did not > >>>> >>>>>> insist on get_basename, I > >>>> >>>>>> > went for get_dirname since the > method is a > >>>> local > >>>> >>>>>> static method and won't > >>>> >>>>>> > have its name start spreading, I > think it's ok > >>>> too. > >>>> >>>>>> > > >>>> >>>>>> > For the naming of the local > variable, the idea > >>>> >>>>>> initially was to use the > >>>> >>>>>> > same name as the local variable > for JNIEnv > >>>> already > >>>> >>>>>> used to reduce the > >>>> >>>>>> > code change. Since I'm now adding > the line > >>>> macro > >>>> >>>>>> at the end anyway, this > >>>> >>>>>> > does not matter anymore so I > converged all > >>>> local > >>>> >>>>>> variables to "jni". > >>>> >>>>>> > > >>>> >>>>>> > So, without further ado, here is > the new > >>>> version: > >>>> >>>>>> > Webrev: > >>>> >>>>>> http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.03/ > >>>> >>>>>> > > >>>> >>>>>> > Bug: > >>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213501 > >>>> >>>>>> > > >>>> >>>>>> > This passes the various tests > changed by the > >>>> >>>>>> webrev on my dev machine. > >>>> >>>>>> > > >>>> >>>>>> > Let me know what you think, > >>>> >>>>>> > Jc > >>>> >>>>>> > > >>>> >>>>>> > On Mon, Dec 3, 2018 at 8:40 PM > >>>> >>>>>> serguei.spitsyn at oracle.com > > > >>>> >>>>>> > >> > >>>> >>>>>> > > > > >>>> >>>>>> > >>> > >>>> >>>>>> > > > >>>> >>>>>> > >> > >>>> >>>>>> > > > > >>>> >>>>>> > >>>> wrote: > >>>> >>>>>> > > >>>> >>>>>> > On 12/3/18 20:15, Chris > Plummer wrote: > >>>> >>>>>> > > Hi JC, > >>>> >>>>>> > > > >>>> >>>>>> > > Overall it looks good. A > few naming nits > >>>> >>>>>> thought: > >>>> >>>>>> > > > >>>> >>>>>> > > In bi01t001.cpp, why have > you declared > >>>> the > >>>> >>>>>> > ExceptionCheckingJniEnvPtr > >>>> >>>>>> > > using jni_env(jni). > Elsewhere you use > >>>> >>>>>> jni(jni_env) and rename the > >>>> >>>>>> > > method argument passed in > from jni to > >>>> >>>>>> jni_env. > >>>> >>>>>> > > > >>>> >>>>>> > > Related to this, I also > noticed in some > >>>> >>>>>> files that already are using > >>>> >>>>>> > > > ExceptionCheckingJniEnvPtr, such as > >>>> >>>>>> CharArrayCriticalLocker.cpp, you > >>>> >>>>>> > > delcared it as > env(jni_env). So that > >>>> means > >>>> >>>>>> there are 3 different > >>>> >>>>>> > names > >>>> >>>>>> > > you have used for the > >>>> >>>>>> ExceptionCheckingJniEnvPtr local > variable. > >>>> >>>>>> > They > >>>> >>>>>> > > should be consistent. > >>>> >>>>>> > > > >>>> >>>>>> > > Also, can you rename > get_basename() to > >>>> >>>>>> get_dirname()? I know Serguei > >>>> >>>>>> > > suggested get_basename() a > while back, > >>>> but > >>>> >>>>>> unless "basename" is > >>>> >>>>>> > > commonly used for this > purpose, I think > >>>> >>>>>> "dirname" is more self > >>>> >>>>>> > > explanatory. > >>>> >>>>>> > > >>>> >>>>>> > In general, I'm Okay with > get_dirname(). > >>>> >>>>>> > Just to mention dirname can > be both short > >>>> or > >>>> >>>>>> full, so it is a little > >>>> >>>>>> > confusing as well. > >>>> >>>>>> > It is the reason why the > get_basename() was > >>>> >>>>>> suggested. > >>>> >>>>>> > However, I do not insist on > get_basename() > >>>> nor > >>>> >>>>>> get_full_dirname(). :) > >>>> >>>>>> > > >>>> >>>>>> > Thanks, > >>>> >>>>>> > Serguei > >>>> >>>>>> > > >>>> >>>>>> > > >>>> >>>>>> > > thanks, > >>>> >>>>>> > > > >>>> >>>>>> > > Chris > >>>> >>>>>> > > > >>>> >>>>>> > > On 12/2/18 10:29 PM, David > Holmes wrote: > >>>> >>>>>> > >> Hi Jc, > >>>> >>>>>> > >> > >>>> >>>>>> > >> I've been lurking on this > one and have > >>>> had > >>>> >>>>>> a look through. I'm okay > >>>> >>>>>> > >> with the FatalError > approach for the > >>>> tests > >>>> >>>>>> - we don't expect > >>>> >>>>>> > anything > >>>> >>>>>> > >> to go wrong in a well > written test in a > >>>> >>>>>> correctly functioning VM. > >>>> >>>>>> > >> > >>>> >>>>>> > >> Thanks, > >>>> >>>>>> > >> David > >>>> >>>>>> > >> > >>>> >>>>>> > >> > >>>> >>>>>> > >> > >>>> >>>>>> > >> On 3/12/2018 3:24 pm, JC > Beyler wrote: > >>>> >>>>>> > >>> Hi all, > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> Would someone on the GC > or runtime > >>>> team > >>>> >>>>>> be motivated to give > >>>> >>>>>> > this a > >>>> >>>>>> > >>> review? :) > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> It would be much > appreciated! > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> Webrev: > >>>> >>>>>> http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.02/ > >>>> >>>>>> > > >>>> >>>>>> > >>> Bug: > >>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213501 > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> Thanks for your help, > >>>> >>>>>> > >>> Jc > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> On Tue, Nov 27, 2018 at > 4:36 PM JC > >>>> Beyler > >>>> >>>>>> > > > > > >>>> > > >>>> >>>>>> > > > > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> > > > >>>> >>>>>> > >> > >>>> >>>>>> > > > >>>> >>>>>> > >>>>> wrote: > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> Hi Chris, > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> Yes I was waiting > for another > >>>> review > >>>> >>>>>> since you had explicitly > >>>> >>>>>> > >>> asked :) > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> And sounds good that > when someone > >>>> >>>>>> from GC or runtime gives a > >>>> >>>>>> > >>> review, > >>>> >>>>>> > >>> I'll wait for your > full review on > >>>> the > >>>> >>>>>> webrev.02! > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> Thanks again for > your help, > >>>> >>>>>> > >>> Jc > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> On Tue, Nov 27, 2018 > at 12:48 PM > >>>> >>>>>> Chris Plummer > >>>> >>>>>> > >>> > > > >>>> >>>>>> > >> > >>>> >>>>>> > > > >>>> >>>>>> > >>> > >>>> >>>>>> > > > > >>>> >>>>>> > >> > >>>> >>>>>> > > > >>>> >>>>>> > >>>>> > >>>> >>>>>> > wrote: > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> Hi JC, > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> I think it would > be good to > >>>> get a > >>>> >>>>>> review from the gc or > >>>> >>>>>> > runtime > >>>> >>>>>> > >>> teams, since > this also affects > >>>> >>>>>> their tests. > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> Also, once we > are settled on > >>>> this > >>>> >>>>>> FatalError approach, > >>>> >>>>>> > I still > >>>> >>>>>> > >>> need to give > your webrev-02 a > >>>> >>>>>> full review. I only > >>>> >>>>>> > skimmed over > >>>> >>>>>> > >>> parts of it (I > did look at all > >>>> >>>>>> the changes in webrevo-01). > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> thanks, > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> Chris > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> On 11/27/18 8:58 AM, > >>>> >>>>>> serguei.spitsyn at oracle.com > > > >>>> >>>>>> > >> > >>>> >>>>>> > > > > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> > > > >>>> >>>>>> > >> > >>>> >>>>>> > > > > >>>> >>>>>> > >>>> wrote: > >>>> >>>>>> > >>>> Hi Jc, > >>>> >>>>>> > >>>> > >>>> >>>>>> > >>>> I've already > reviewed this > >>>> too. > >>>> >>>>>> > >>>> > >>>> >>>>>> > >>>> Thanks, > >>>> >>>>>> > >>>> Serguei > >>>> >>>>>> > >>>> > >>>> >>>>>> > >>>> > >>>> >>>>>> > >>>> On 11/27/18 > 06:56, JC Beyler > >>>> >>>>>> wrote: > >>>> >>>>>> > >>>>> Thanks Chris, > >>>> >>>>>> > >>>>> > >>>> >>>>>> > >>>>> Anybody else motivated > to look at > >>>> this > >>>> >>>>>> and review it? :) > >>>> >>>>>> > >>>>> Jc > >>>> >>>>>> > >>>>> > >>>> >>>>>> > >>>>> On Mon, Nov > 26, 2018 at > >>>> 1:26 PM > >>>> >>>>>> Chris Plummer > >>>> >>>>>> > >>>>> > > > >>>> >>>>>> > >> > >>>> >>>>>> > > > > >>>> >>>>>> > >>> > >>>> >>>>>> > > > >>>> >>>>>> > >> > >>>> >>>>>> > > > > >>>> >>>>>> > >>>>> > >>>> >>>>>> > >>>>> wrote: > >>>> >>>>>> > >>>>> > >>>> >>>>>> > >>>>> Hi JC, > >>>> >>>>>> > >>>>> > >>>> >>>>>> > >>>>> I'm ok with the > FatalError approach, > >>>> >>>>>> but would > >>>> >>>>>> > like to > >>>> >>>>>> > >>>>> hear opinions from > others also. > >>>> >>>>>> > >>>>> > >>>> >>>>>> > >>>>> thanks, > >>>> >>>>>> > >>>>> > >>>> >>>>>> > >>>>> Chris > >>>> >>>>>> > >>>>> > >>>> >>>>>> > >>>>> On 11/21/18 8:19 AM, > JC Beyler > >>>> wrote: > >>>> >>>>>> > >>>>>> Hi Chris, > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> Thanks > for taking the > >>>> time > >>>> >>>>>> to look at it and yes you > >>>> >>>>>> > >>>>>> have > raised exactly why > >>>> >>>>>> the webrev is between two > >>>> >>>>>> > >>>>>> worlds: > in cases where > >>>> a > >>>> >>>>>> fatal error on failure is > >>>> >>>>>> > >>>>>> wanted, > should we > >>>> simplify > >>>> >>>>>> the code to remove > >>>> >>>>>> > the return > >>>> >>>>>> > >>>>>> tests > since we do them > >>>> >>>>>> internally? Now that I've > >>>> >>>>>> > looked > >>>> >>>>>> > >>>>>> around > for non-fatal > >>>> >>>>>> cases, I think the answer > >>>> >>>>>> > is yes, > >>>> >>>>>> > >>>>>> it > simplifies the code > >>>> >>>>>> while maintaining the checks. > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> I looked > a bit and it > >>>> >>>>>> seems that I can't find > >>>> >>>>>> > easily a > >>>> >>>>>> > >>>>>> case > where the test > >>>> >>>>>> accepts a JNI failure to > >>>> >>>>>> > then move > >>>> >>>>>> > >>>>>> on. > Therefore, perhaps, > >>>> >>>>>> for now, the fail with a > >>>> >>>>>> > Fatal > >>>> >>>>>> > >>>>>> is enough > and we can > >>>> work > >>>> >>>>>> on the tests to clean > >>>> >>>>>> > them up? > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> That > means that this is > >>>> >>>>>> the new webrev with only > >>>> >>>>>> > Fatal > >>>> >>>>>> > >>>>>> and > cleans up the > >>>> tests so > >>>> >>>>>> that it is no longer in > >>>> >>>>>> > >>>>>> between > two worlds: > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> Webrev: > >>>> >>>>>> > >>>>>> > >>>> >>>>>> http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.02/ > >>>> >>>>>> > > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>>>> Bug: > >>>> >>>>>> > > >>>> https://bugs.openjdk.java.net/browse/JDK-8213501 > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> (This > passes testing > >>>> on my > >>>> >>>>>> dev machine for all the > >>>> >>>>>> > >>>>>> modified > tests) > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> with the > example you > >>>> >>>>>> provided, it now looks like: > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>> > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp.frames.html > >>>> >>>>>> > >>>> >>>>>> < > >>>> > http://cr.openjdk.java.net/%7Ejcbeyler/8213501/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp.frames.html> > >>>> > >>>> >>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > > >>>> >>>>>> < > >>>> > http://cr.openjdk.java.net/%7Ejcbeyler/8213501/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp.frames.html> > >>>> > >>>> >>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> Where it > does, to me at > >>>> >>>>>> least, seem cleaner and less > >>>> >>>>>> > >>>>>> "noisy". > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> Let me > know what you > >>>> think, > >>>> >>>>>> > >>>>>> Jc > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> On Tue, > Nov 20, 2018 at > >>>> >>>>>> 9:33 PM Chris Plummer > >>>> >>>>>> > >>>>>> < > >>>> chris.plummer at oracle.com > > >>>> >>>>>> > >> > >>>> >>>>>> > > > > >>>> >>>>>> > >>> > >>>> >>>>>> > >>>>>> > > > >>>> >>>>>> > >> > >>>> >>>>>> > > > > >>>> >>>>>> > >>>>> wrote: > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> Hi JC, > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> Sorry > about the > >>>> delay. > >>>> >>>>>> I had to go back an > >>>> >>>>>> > look at > >>>> >>>>>> > >>>>>> the > initial 8210842 > >>>> >>>>>> webrev and RFR thread to see > >>>> >>>>>> > >>>>>> what > this was > >>>> >>>>>> initially all about. > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> In > general the > >>>> changes > >>>> >>>>>> look good. > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> I > don't have a good > >>>> >>>>>> answer to your > >>>> >>>>>> > >>>>>> FatalError/NonFatalError > question. It > >>>> makes > >>>> >>>>>> > the code > >>>> >>>>>> > >>>>>> a lot > cleaner to > >>>> use > >>>> >>>>>> FatalError, but then it > >>>> >>>>>> > is a > >>>> >>>>>> > >>>>>> > behavior change, > >>>> and > >>>> >>>>>> you also need to deal with > >>>> >>>>>> > >>>>>> tests > that > >>>> >>>>>> intentionally induce errors (do > >>>> >>>>>> > you have > >>>> >>>>>> > >>>>>> an > example of > >>>> that). > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> In > any case, right > >>>> now > >>>> >>>>>> your webrev seems to be > >>>> >>>>>> > >>>>>> > between two worlds. > >>>> >>>>>> You are producing > >>>> >>>>>> > FatalError, > >>>> >>>>>> > >>>>>> but > still checking > >>>> >>>>>> results. Here's a good > >>>> >>>>>> > example: > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>> > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp.frames.html > >>>> >>>>>> > >>>> >>>>>> < > >>>> > http://cr.openjdk.java.net/%7Ejcbeyler/8213501/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp.frames.html> > >>>> > >>>> >>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > > >>>> >>>>>> < > >>>> > http://cr.openjdk.java.net/%7Ejcbeyler/8213501/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp.frames.html> > >>>> > >>>> >>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> I'm > not sure if > >>>> this > >>>> >>>>>> is just a temporary > >>>> >>>>>> > state until > >>>> >>>>>> > >>>>>> it > was decided > >>>> which > >>>> >>>>>> approach to take. > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> thanks, > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> Chris > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> On > 11/20/18 2:14 > >>>> PM, > >>>> >>>>>> JC Beyler wrote: > >>>> >>>>>> > >>>>>>> Hi all, > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> > Chris thought it > >>>> made > >>>> >>>>>> sense to have more > >>>> >>>>>> > eyes on > >>>> >>>>>> > >>>>>>> this > change than > >>>> just > >>>> >>>>>> serviceability as it will > >>>> >>>>>> > >>>>>>> > modify to tests > >>>> that > >>>> >>>>>> are not only > >>>> >>>>>> > serviceability > >>>> >>>>>> > >>>>>>> > tests so I've > >>>> moved > >>>> >>>>>> this to conversation > >>>> >>>>>> > here :) > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> For > convenience, > >>>> I've > >>>> >>>>>> copy-pasted the > >>>> >>>>>> > initial RFR: > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> > Could I have a > >>>> review > >>>> >>>>>> for the extension and > >>>> >>>>>> > usage > >>>> >>>>>> > >>>>>>> of the > >>>> >>>>>> ExceptionJniWrapper. This adds > lines and > >>>> >>>>>> > >>>>>>> > filenames to the > >>>> end > >>>> >>>>>> of the wrapper JNI > >>>> >>>>>> > methods, > >>>> >>>>>> > >>>>>>> adds > tracing, and > >>>> >>>>>> throws an error if need > >>>> >>>>>> > be. I've > >>>> >>>>>> > >>>>>>> > ported the gc/lock > >>>> >>>>>> files to use the new > >>>> >>>>>> > >>>>>>> > TRACE_JNI_CALL > >>>> add-on > >>>> >>>>>> and I've ported a few > >>>> >>>>>> > of the > >>>> >>>>>> > >>>>>>> > tests that were > >>>> >>>>>> already changed for the > >>>> >>>>>> > assignment > >>>> >>>>>> > >>>>>>> > webrev for > >>>> >>>>>> JDK-8212884. > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> Webrev: > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.01 > >>>> >>>>>> > > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>>>>> Bug: > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213501 > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> For > illustration, > >>>> if > >>>> >>>>>> I force an error to the > >>>> >>>>>> > >>>>>>> > AP04/ap04t03 test > >>>> and > >>>> >>>>>> set the verbosity on, > >>>> >>>>>> > I get > >>>> >>>>>> > >>>>>>> > something like: > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> >> > Calling JNI > >>>> method > >>>> >>>>>> FindClass from > >>>> >>>>>> > >>>>>>> ap04t003.cpp:343 > >>>> >>>>>> > >>>>>>> >> > Calling with > >>>> these > >>>> >>>>>> parameter(s): > >>>> >>>>>> > >>>>>>> java/lang/Threadd > >>>> >>>>>> > >>>>>>> Wait > for thread > >>>> to > >>>> >>>>>> finish > >>>> >>>>>> > >>>>>>> << > Called JNI > >>>> method > >>>> >>>>>> FindClass from > >>>> >>>>>> > >>>>>>> ap04t003.cpp:343 > >>>> >>>>>> > >>>>>>> > Exception in > >>>> thread > >>>> >>>>>> "Thread-0" > >>>> >>>>>> > >>>>>>> > java.lang.NoClassDefFoundError: > >>>> >>>>>> > java/lang/Threadd > >>>> >>>>>> > >>>>>>> > at > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>> > nsk.jvmti.scenarios.allocation.AP04.ap04t003.runIterateOverHeap(Native > >>>> >>>>>> > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> Method) > >>>> >>>>>> > >>>>>>> > at > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>> > nsk.jvmti.scenarios.allocation.AP04.ap04t003HeapIterator.runIteration(ap04t003.java:140) > >>>> > >>>> >>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> > at > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>> > nsk.jvmti.scenarios.allocation.AP04.ap04t003Thread.run(ap04t003.java:201) > >>>> >>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> > Caused by: > >>>> >>>>>> java.lang.ClassNotFoundException: > >>>> >>>>>> > >>>>>>> > java.lang.Threadd > >>>> >>>>>> > >>>>>>> > at > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>> > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) > >>>> > >>>> >>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> > at > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>> > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > >>>> > >>>> >>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> > at > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) > >>>> >>>>>> > >>>>>>> > ... 3 more > >>>> >>>>>> > >>>>>>> > FATAL ERROR in > >>>> native > >>>> >>>>>> method: JNI method > >>>> >>>>>> > FindClass > >>>> >>>>>> > >>>>>>> : > internal error > >>>> from > >>>> >>>>>> ap04t003.cpp:343 > >>>> >>>>>> > >>>>>>> > at > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>> > nsk.jvmti.scenarios.allocation.AP04.ap04t003.runIterateOverHeap(Native > >>>> >>>>>> > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> Method) > >>>> >>>>>> > >>>>>>> > at > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>> > nsk.jvmti.scenarios.allocation.AP04.ap04t003HeapIterator.runIteration(ap04t003.java:140) > >>>> > >>>> >>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> > at > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>> > nsk.jvmti.scenarios.allocation.AP04.ap04t003Thread.run(ap04t003.java:201) > >>>> >>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> > >>>> Questions/comments I > >>>> >>>>>> have about this are: > >>>> >>>>>> > >>>>>>> - > Do we want to > >>>> >>>>>> force fatal errors when a JNI > >>>> >>>>>> > >>>>>>> call > fails in > >>>> >>>>>> general? Most of these tests > >>>> >>>>>> > do the > >>>> >>>>>> > >>>>>>> > right thing and > >>>> test > >>>> >>>>>> the return of the JNI > >>>> >>>>>> > calls, > >>>> >>>>>> > >>>>>>> for > example: > >>>> >>>>>> > >>>>>>> > thrClass = > >>>> >>>>>> > jni->FindClass("java/lang/Threadd", > >>>> >>>>>> > >>>>>>> > TRACE_JNI_CALL); > >>>> >>>>>> > >>>>>>> > if (thrClass > >>>> == > >>>> >>>>>> NULL) { > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> but > now the > >>>> wrapper > >>>> >>>>>> actually would do a > >>>> >>>>>> > fatal if > >>>> >>>>>> > >>>>>>> the > FindClass call > >>>> >>>>>> would return a nullptr, > >>>> >>>>>> > so we > >>>> >>>>>> > >>>>>>> > could remove that > >>>> >>>>>> test altogether. What do you > >>>> >>>>>> > >>>>>>> think? > >>>> >>>>>> > >>>>>>> > - I prefer to > >>>> >>>>>> leave them as the tests then > >>>> >>>>>> > >>>>>>> > become closer to > >>>> what > >>>> >>>>>> real users would have in > >>>> >>>>>> > >>>>>>> > their code and is > >>>> the > >>>> >>>>>> "recommended" way of > >>>> >>>>>> > doing it > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> - The > >>>> alternative > >>>> >>>>>> is to use the > >>>> >>>>>> > NonFatalError I > >>>> >>>>>> > >>>>>>> > added which then > >>>> just > >>>> >>>>>> prints out that something > >>>> >>>>>> > >>>>>>> went > wrong, > >>>> letting > >>>> >>>>>> the test continue. Question > >>>> >>>>>> > >>>>>>> will > be what > >>>> should > >>>> >>>>>> be the default? The > >>>> >>>>>> > fatal or > >>>> >>>>>> > >>>>>>> the > non-fatal > >>>> error > >>>> >>>>>> handling? > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> On a > different > >>>> >>>>>> subject: > >>>> >>>>>> > >>>>>>> - > On the new > >>>> tests, > >>>> >>>>>> I've removed the > >>>> >>>>>> > >>>>>>> > NSK_JNI_VERIFY > >>>> since > >>>> >>>>>> the JNI wrapper > >>>> >>>>>> > handles the > >>>> >>>>>> > >>>>>>> > tracing and the > >>>> >>>>>> verify in almost the same > >>>> >>>>>> > way; only > >>>> >>>>>> > >>>>>>> > difference I can > >>>> >>>>>> really tell is that the > >>>> >>>>>> > complain > >>>> >>>>>> > >>>>>>> > method from NSK > >>>> has a > >>>> >>>>>> max complain before > >>>> >>>>>> > stopping > >>>> >>>>>> > >>>>>>> to > "complain"; I > >>>> have > >>>> >>>>>> not added that part > >>>> >>>>>> > of the > >>>> >>>>>> > >>>>>>> code > in this > >>>> webrev > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> Once > we decide on > >>>> >>>>>> these, I can continue on the > >>>> >>>>>> > >>>>>>> > files from > >>>> >>>>>> JDK-8212884 and then do both the > >>>> >>>>>> > >>>>>>> > assignment in an > >>>> if > >>>> >>>>>> extraction followed-by this > >>>> >>>>>> > >>>>>>> type > of webrev in > >>>> an > >>>> >>>>>> easier fashion. > >>>> >>>>>> > Depending on > >>>> >>>>>> > >>>>>>> > decisions here, > >>>> >>>>>> NSK*VERIFY can be deprecated as > >>>> >>>>>> > >>>>>>> well > as we go > >>>> forward. > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> Thanks! > >>>> >>>>>> > >>>>>>> Jc > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> On > Mon, Nov 19, > >>>> 2018 > >>>> >>>>>> at 11:34 AM Chris Plummer > >>>> >>>>>> > >>>>>>> < > >>>> chris.plummer at oracle.com > > >>>> >>>>>> > >> > >>>> >>>>>> > > > > >>>> >>>>>> > >>> > >>>> >>>>>> > >>>>>>> > > > >>>> >>>>>> > >> > >>>> >>>>>> > > > > >>>> >>>>>> > >>>>> wrote: > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> > On 11/19/18 > >>>> 10:07 > >>>> >>>>>> AM, JC Beyler wrote: > >>>> >>>>>> > >>>>>>>> > Hi all, > >>>> >>>>>> > >>>>>>>> > >>>> >>>>>> > >>>>>>>> > @David/Chris: > >>>> >>>>>> should I then push this > >>>> >>>>>> > RFR to > >>>> >>>>>> > >>>>>>>> > the hotspot > >>>> >>>>>> mailing or the runtime > >>>> >>>>>> > one? For > >>>> >>>>>> > >>>>>>>> > what it's > >>>> worth, > >>>> >>>>>> a lot of the tests > >>>> >>>>>> > under the > >>>> >>>>>> > >>>>>>>> > vmTestbase > >>>> are > >>>> >>>>>> jvmti so the review also > >>>> >>>>>> > >>>>>>>> > affects > >>>> >>>>>> serviceability; it just turns > >>>> >>>>>> > out I > >>>> >>>>>> > >>>>>>>> > started with > >>>> the > >>>> >>>>>> GC originally and > >>>> >>>>>> > then hit > >>>> >>>>>> > >>>>>>>> > some other > >>>> tests > >>>> >>>>>> I had touched via the > >>>> >>>>>> > >>>>>>>> > assignment > >>>> >>>>>> extraction. > >>>> >>>>>> > >>>>>>> > I think > >>>> hotspot > >>>> >>>>>> would be best. > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> > Chris > >>>> >>>>>> > >>>>>>>> > >>>> >>>>>> > >>>>>>>> > @Serguei: > >>>> Done > >>>> >>>>>> for the method > >>>> >>>>>> > renaming, for > >>>> >>>>>> > >>>>>>>> > the indent, > >>>> are > >>>> >>>>>> you talking about > >>>> >>>>>> > going from > >>>> >>>>>> > >>>>>>>> > the 8-indent > >>>> to > >>>> >>>>>> 4-indent? If so, would > >>>> >>>>>> > it not > >>>> >>>>>> > >>>>>>>> > just be > >>>> better > >>>> >>>>>> to do a new JBS bug and > >>>> >>>>>> > do the > >>>> >>>>>> > >>>>>>>> > whole files > >>>> in > >>>> >>>>>> one go? I ask because > >>>> >>>>>> > >>>>>>>> > otherwise, it > >>>> >>>>>> will look a bit weird to > >>>> >>>>>> > have > >>>> >>>>>> > >>>>>>>> > parts of the > >>>> >>>>>> file as 8-indent and others > >>>> >>>>>> > >>>>>>>> 4-indent? > >>>> >>>>>> > >>>>>>>> > >>>> >>>>>> > >>>>>>>> > Thanks for > >>>> >>>>>> looking at it! > >>>> >>>>>> > >>>>>>>> Jc > >>>> >>>>>> > >>>>>>>> > >>>> >>>>>> > >>>>>>>> > On Mon, Nov > >>>> 19, > >>>> >>>>>> 2018 at 1:25 AM > >>>> >>>>>> > >>>>>>>> > serguei.spitsyn at oracle.com > > >>>> >>>>>> > >> > >>>> >>>>>> > > > >>>> >>>>>> > >>> > >>>> >>>>>> > >>>>>>>> >>>> serguei.spitsyn at oracle.com > > >>>> >>>>>> > >> > >>>> >>>>>> > > > > >>>> >>>>>> > >>>> > >>>> >>>>>> > >>>>>>>> > > > >>>> >>>>>> > >> > >>>> >>>>>> > > > > >>>> >>>>>> > >>> > >>>> >>>>>> > >>>>>>>> >>>> serguei.spitsyn at oracle.com > > >>>> >>>>>> > >> > >>>> >>>>>> > > > > >>>> >>>>>> > >>>>> wrote: > >>>> >>>>>> > >>>>>>>> > >>>> >>>>>> > >>>>>>>> > Hi Jc, > >>>> >>>>>> > >>>>>>>> > >>>> >>>>>> > >>>>>>>> > We have > >>>> to > >>>> >>>>>> start this review > >>>> >>>>>> > anyway. :) > >>>> >>>>>> > >>>>>>>> > It looks > >>>> >>>>>> good to me in general. > >>>> >>>>>> > >>>>>>>> > Thank you > >>>> >>>>>> for your consistency in this > >>>> >>>>>> > >>>>>>>> > >>>> refactoring! > >>>> >>>>>> > >>>>>>>> > >>>> >>>>>> > >>>>>>>> > Some > >>>> minor > >>>> >>>>>> comments. > >>>> >>>>>> > >>>>>>>> > >>>> >>>>>> > >>>>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>> > http://cr.openjdk.java.net/%7Ejcbeyler/8213501/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.cpp.udiff.html > >>>> >>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>>>>>> > >>>> >>>>>> > >>>>>>>> > +static > >>>> >>>>>> const char* > >>>> >>>>>> > remove_folders(const > >>>> >>>>>> > >>>>>>>> > char* > >>>> >>>>>> fullname) { I'd suggest to > >>>> >>>>>> > rename > >>>> >>>>>> > >>>>>>>> > the > >>>> function > >>>> >>>>>> name to something > >>>> >>>>>> > traditional > >>>> >>>>>> > >>>>>>>> > like > >>>> >>>>>> get_basename. Otherwise, it > >>>> >>>>>> > sounds > >>>> >>>>>> > >>>>>>>> > like this > >>>> >>>>>> function has to really > >>>> >>>>>> > remove > >>>> >>>>>> > >>>>>>>> > folders. > >>>> :) > >>>> >>>>>> Also, all *Locker.cpp have > >>>> >>>>>> > >>>>>>>> > wrong > >>>> indent > >>>> >>>>>> in the bodies of if > >>>> >>>>>> > and while > >>>> >>>>>> > >>>>>>>> > >>>> statements. > >>>> >>>>>> Could this be fixed > >>>> >>>>>> > with the > >>>> >>>>>> > >>>>>>>> > >>>> refactoring? > >>>> >>>>>> I did not look on how > >>>> >>>>>> > this > >>>> >>>>>> > >>>>>>>> > impacts > >>>> the > >>>> >>>>>> tests other than > >>>> >>>>>> > >>>>>>>> > serviceability. > >>>> Thanks, > >>>> >>>>>> Serguei > >>>> >>>>>> > >>>>>>>> > >>>> >>>>>> > >>>>>>>> > >>>> >>>>>> > >>>>>>>> > On > >>>> 11/16/18 > >>>> >>>>>> 19:43, JC Beyler wrote: > >>>> >>>>>> > >>>>>>>>> > Hi all, > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > >>>>>>>>> > Anybody > >>>> >>>>>> motivated to review this? :) > >>>> >>>>>> > >>>>>>>>> Jc > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > >>>>>>>>> > On Wed, Nov > >>>> 7, > >>>> >>>>>> 2018 at 9:53 PM JC > >>>> >>>>>> > Beyler > >>>> >>>>>> > >>>>>>>>> > > > >>>> >>>>>> > >> > >>>> >>>>>> > > > > >>>> >>>>>> > >>> > >>>> >>>>>> > >>>>>>>>> > > > >>>> >>>>>> > >> > >>>> >>>>>> > > > > >>>> >>>>>> > >>>>> wrote: > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > >>>>>>>>> > Hi all, > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > >>>>>>>>> > Could I > >>>> have > >>>> >>>>>> a review for the > >>>> >>>>>> > >>>>>>>>> > extension > >>>> >>>>>> and usage of the > >>>> >>>>>> > >>>>>>>>> ExceptionJniWrapper. This > >>>> >>>>>> > adds lines > >>>> >>>>>> > >>>>>>>>> > and > >>>> >>>>>> filenames to the end of the > >>>> >>>>>> > >>>>>>>>> > wrapper > >>>> JNI > >>>> >>>>>> methods, adds > >>>> >>>>>> > tracing, > >>>> >>>>>> > >>>>>>>>> > and > >>>> throws > >>>> >>>>>> an error if need > >>>> >>>>>> > be. I've > >>>> >>>>>> > >>>>>>>>> > ported > >>>> the > >>>> >>>>>> gc/lock files to > >>>> >>>>>> > use the > >>>> >>>>>> > >>>>>>>>> > new > >>>> >>>>>> TRACE_JNI_CALL add-on and > >>>> >>>>>> > I've > >>>> >>>>>> > >>>>>>>>> > ported a > >>>> few > >>>> >>>>>> of the tests > >>>> >>>>>> > that were > >>>> >>>>>> > >>>>>>>>> > already > >>>> >>>>>> changed for the > >>>> >>>>>> > assignment > >>>> >>>>>> > >>>>>>>>> > webrev > >>>> for > >>>> >>>>>> JDK-8212884. > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > >>>>>>>>> > Webrev: > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.00/ > >>>> >>>>>> > > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>>>>>>> > Bug: > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213501 > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > >>>>>>>>> > For > >>>> >>>>>> illustration, if I force > >>>> >>>>>> > an error > >>>> >>>>>> > >>>>>>>>> > to the > >>>> >>>>>> AP04/ap04t03 test and > >>>> >>>>>> > set the > >>>> >>>>>> > >>>>>>>>> > verbosity > >>>> >>>>>> on, I get something > >>>> >>>>>> > like: > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > >>>>>>>>> > >> > >>>> Calling > >>>> >>>>>> JNI method > >>>> >>>>>> > FindClass from > >>>> >>>>>> > >>>>>>>>> ap04t003.cpp:343 > >>>> >>>>>> > >>>>>>>>> > >> > >>>> Calling > >>>> >>>>>> with these > >>>> >>>>>> > parameter(s): > >>>> >>>>>> > >>>>>>>>> java/lang/Threadd > >>>> >>>>>> > >>>>>>>>> > Wait for > >>>> >>>>>> thread to finish > >>>> >>>>>> > >>>>>>>>> > << Called > >>>> >>>>>> JNI method > >>>> >>>>>> > FindClass from > >>>> >>>>>> > >>>>>>>>> ap04t003.cpp:343 > >>>> >>>>>> > >>>>>>>>> > >>>> Exception in > >>>> >>>>>> thread "Thread-0" > >>>> >>>>>> > >>>>>>>>> > java.lang.NoClassDefFoundError: > >>>> >>>>>> > >>>>>>>>> java/lang/Threadd > >>>> >>>>>> > >>>>>>>>> > at > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>> > nsk.jvmti.scenarios.allocation.AP04.ap04t003.runIterateOverHeap(Native > >>>> >>>>>> > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > >>>>>>>>> > Method) > >>>> >>>>>> > >>>>>>>>> > at > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>> > nsk.jvmti.scenarios.allocation.AP04.ap04t003HeapIterator.runIteration(ap04t003.java:140) > >>>> > >>>> >>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > >>>>>>>>> > at > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>> > nsk.jvmti.scenarios.allocation.AP04.ap04t003Thread.run(ap04t003.java:201) > >>>> >>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > >>>>>>>>> > Caused > >>>> by: > >>>> >>>>>> > >>>>>>>>> > java.lang.ClassNotFoundException: > >>>> >>>>>> > >>>>>>>>> java.lang.Threadd > >>>> >>>>>> > >>>>>>>>> > at > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>> > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) > >>>> > >>>> >>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > >>>>>>>>> > at > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>> > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > >>>> > >>>> >>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > >>>>>>>>> > at > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > > >>>> >>>>>> > java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) > >>>> >>>>>> > >>>>>>>>> > ... 3 > >>>> more > >>>> >>>>>> > >>>>>>>>> > FATAL > >>>> ERROR > >>>> >>>>>> in native method: JNI > >>>> >>>>>> > >>>>>>>>> > method > >>>> >>>>>> FindClass : internal error > >>>> >>>>>> > >>>>>>>>> > from > >>>> >>>>>> ap04t003.cpp:343 > >>>> >>>>>> > >>>>>>>>> > at > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>> > nsk.jvmti.scenarios.allocation.AP04.ap04t003.runIterateOverHeap(Native > >>>> >>>>>> > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > >>>>>>>>> > Method) > >>>> >>>>>> > >>>>>>>>> > at > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>> > nsk.jvmti.scenarios.allocation.AP04.ap04t003HeapIterator.runIteration(ap04t003.java:140) > >>>> > >>>> >>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > >>>>>>>>> > at > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>> > nsk.jvmti.scenarios.allocation.AP04.ap04t003Thread.run(ap04t003.java:201) > >>>> >>>>>> > >>>> >>>>>> > > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > >>>>>>>>> Questions/comments I > have about > >>>> >>>>>> > >>>>>>>>> this are: > >>>> >>>>>> > >>>>>>>>> > - Do we > >>>> >>>>>> want to force fatal > >>>> >>>>>> > errors > >>>> >>>>>> > >>>>>>>>> > when a > >>>> JNI > >>>> >>>>>> call fails in general? > >>>> >>>>>> > >>>>>>>>> > Most of > >>>> >>>>>> these tests do the right > >>>> >>>>>> > >>>>>>>>> > thing and > >>>> >>>>>> test the return of > >>>> >>>>>> > the JNI > >>>> >>>>>> > >>>>>>>>> > calls, > >>>> for > >>>> >>>>>> example: > >>>> >>>>>> > >>>>>>>>> > thrClass > >>>> = > >>>> >>>>>> > >>>>>>>>> > jni->FindClass("java/lang/Threadd", > >>>> >>>>>> > >>>>>>>>> TRACE_JNI_CALL); > >>>> >>>>>> > >>>>>>>>> > if > >>>> >>>>>> (thrClass == NULL) { > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > >>>>>>>>> > but now > >>>> the > >>>> >>>>>> wrapper actually > >>>> >>>>>> > would do > >>>> >>>>>> > >>>>>>>>> > a fatal > >>>> if > >>>> >>>>>> the FindClass call > >>>> >>>>>> > would > >>>> >>>>>> > >>>>>>>>> > return a > >>>> >>>>>> nullptr, so we could > >>>> >>>>>> > remove > >>>> >>>>>> > >>>>>>>>> > that test > >>>> >>>>>> altogether. What do > >>>> >>>>>> > you > >>>> >>>>>> > >>>>>>>>> think? > >>>> >>>>>> > >>>>>>>>> > - I > >>>> >>>>>> prefer to leave them > >>>> >>>>>> > as the > >>>> >>>>>> > >>>>>>>>> > tests > >>>> then > >>>> >>>>>> become closer to > >>>> >>>>>> > what real > >>>> >>>>>> > >>>>>>>>> > users > >>>> would > >>>> >>>>>> have in their > >>>> >>>>>> > code and is > >>>> >>>>>> > >>>>>>>>> > the > >>>> >>>>>> "recommended" way of doing it > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > >>>>>>>>> > - The > >>>> >>>>>> alternative is to > >>>> >>>>>> > use the > >>>> >>>>>> > >>>>>>>>> > NonFatalError I > >>>> added > >>>> >>>>>> which > >>>> >>>>>> > then just > >>>> >>>>>> > >>>>>>>>> > prints > >>>> out > >>>> >>>>>> that something > >>>> >>>>>> > went wrong, > >>>> >>>>>> > >>>>>>>>> > letting > >>>> the > >>>> >>>>>> test continue. > >>>> >>>>>> > Question > >>>> >>>>>> > >>>>>>>>> > will be > >>>> what > >>>> >>>>>> should be the > >>>> >>>>>> > default? > >>>> >>>>>> > >>>>>>>>> > The > >>>> fatal or > >>>> >>>>>> the non-fatal error > >>>> >>>>>> > >>>>>>>>> > handling? > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > >>>>>>>>> > On a > >>>> >>>>>> different subject: > >>>> >>>>>> > >>>>>>>>> > - On > >>>> the > >>>> >>>>>> new tests, I've > >>>> >>>>>> > removed > >>>> >>>>>> > >>>>>>>>> > the > >>>> >>>>>> NSK_JNI_VERIFY since the JNI > >>>> >>>>>> > >>>>>>>>> > wrapper > >>>> >>>>>> handles the tracing > >>>> >>>>>> > and the > >>>> >>>>>> > >>>>>>>>> > verify in > >>>> >>>>>> almost the same > >>>> >>>>>> > way; only > >>>> >>>>>> > >>>>>>>>> > >>>> difference I > >>>> >>>>>> can really tell > >>>> >>>>>> > is that > >>>> >>>>>> > >>>>>>>>> > the > >>>> complain > >>>> >>>>>> method from NSK > >>>> >>>>>> > has a > >>>> >>>>>> > >>>>>>>>> > max > >>>> complain > >>>> >>>>>> before stopping to > >>>> >>>>>> > >>>>>>>>> > >>>> "complain"; > >>>> >>>>>> I have not added that > >>>> >>>>>> > >>>>>>>>> > part of > >>>> the > >>>> >>>>>> code in this webrev > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > >>>>>>>>> > Once we > >>>> >>>>>> decide on these, I can > >>>> >>>>>> > >>>>>>>>> > continue > >>>> on > >>>> >>>>>> the files from > >>>> >>>>>> > >>>>>>>>> > >>>> JDK-8212884 > >>>> >>>>>> and then do both the > >>>> >>>>>> > >>>>>>>>> > >>>> assignment > >>>> >>>>>> in an if extraction > >>>> >>>>>> > >>>>>>>>> > >>>> followed-by > >>>> >>>>>> this type of > >>>> >>>>>> > webrev in an > >>>> >>>>>> > >>>>>>>>> > easier > >>>> >>>>>> fashion. Depending on > >>>> >>>>>> > >>>>>>>>> > decisions > >>>> >>>>>> here, NSK*VERIFY can be > >>>> >>>>>> > >>>>>>>>> > >>>> deprecated > >>>> >>>>>> as well as we go > >>>> >>>>>> > forward. > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > >>>>>>>>> > Thank you > >>>> >>>>>> for the > >>>> >>>>>> > reviews/comments :) > >>>> >>>>>> > >>>>>>>>> > Jc > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > >>>>>>>>> > >>>> >>>>>> > >>>>>>>>> -- > >>>> >>>>>> > >>>>>>>>> > Thanks, > >>>> >>>>>> > >>>>>>>>> Jc > >>>> >>>>>> > >>>>>>>> > >>>> >>>>>> > >>>>>>>> > >>>> >>>>>> > >>>>>>>> > >>>> >>>>>> > >>>>>>>> -- > >>>> >>>>>> > >>>>>>>> > Thanks, > >>>> >>>>>> > >>>>>>>> Jc > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> > >>>> >>>>>> > >>>>>>> -- > >>>> >>>>>> > >>>>>>> Thanks, > >>>> >>>>>> > >>>>>>> Jc > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> > >>>> >>>>>> > >>>>>> -- > >>>> >>>>>> > >>>>>> Thanks, > >>>> >>>>>> > >>>>>> Jc > >>>> >>>>>> > >>>>> > >>>> >>>>>> > >>>>> > >>>> >>>>>> > >>>>> > >>>> >>>>>> > >>>>> > >>>> >>>>>> > >>>>> -- > >>>> >>>>>> > >>>>> Thanks, > >>>> >>>>>> > >>>>> Jc > >>>> >>>>>> > >>>> > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> -- > >>>> >>>>>> > >>> Thanks, > >>>> >>>>>> > >>> Jc > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> -- > >>>> >>>>>> > >>> > >>>> >>>>>> > >>> Thanks, > >>>> >>>>>> > >>> Jc > >>>> >>>>>> > > > >>>> >>>>>> > > > >>>> >>>>>> > > >>>> >>>>>> > > >>>> >>>>>> > > >>>> >>>>>> > -- > >>>> >>>>>> > > >>>> >>>>>> > Thanks, > >>>> >>>>>> > Jc > >>>> >>>>>> > >>>> >>>>>> > >>>> >>>>>> > >>>> >>>>>> -- > >>>> >>>>>> Thanks, > >>>> >>>>>> Jc > >>>> >>>>> > >>>> >>>>> > >>>> >>>>> > >>>> >>>>> -- > >>>> >>>>> Thanks, > >>>> >>>>> Jc > >>>> >>>> > >>>> >>>> > >>>> >>>> > >>>> >>>> -- > >>>> >>>> Thanks, > >>>> >>>> Jc > >>>> >>>> > >>>> >>>> > >>>> >>>> > >>>> >>>> -- > >>>> >>>> > >>>> >>>> Thanks, > >>>> >>>> Jc > >>>> >>> > >>>> > > >>>> > >>> > >>> > >>> -- > >>> > >>> Thanks, > >>> Jc > >>> > >> > >> > >> -- > >> > >> Thanks, > >> Jc > >> > > > > > > -- > > > > Thanks, > > Jc > > > > > -- > > Thanks, > Jc > > > > > -- > > Thanks, > Jc -- Thanks, Jc -- Thanks, Jc From david.holmes at oracle.com Mon Apr 8 21:54:55 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 9 Apr 2019 07:54:55 +1000 Subject: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: References: <30b2b3c5-38f7-8569-10cd-e781129b5da5@oracle.com> <5a2f0358-d5e4-2fdc-5791-e6d45f9d5b02@oracle.com> Message-ID: On 8/04/2019 6:07 pm, Baesken, Matthias wrote: > > Hi David, > >>>> >>>> So compiler ifdefs in the cpu files is the way to handle this. >>>> >>> >>> Hello, I moved the coding from >>> >>> src/hotspot/os_cpu/linux_x86/vm_version_linux_x86.cpp >>> src/hotspot/os_cpu/windows_x86/vm_version_windows_x86.cpp >>> >>> >>> Into src/hotspot/cpu/x86/vm_version_x86.cpp and guarded it with the >> compiler macros : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8219241.5/ >> >> I'm not clear why we are still using os-guards as well? >> >> + #elif defined(__GNUC__) && defined(__linux__) >> >> + #if defined(_LP64) && (defined(__linux__) || defined(_WIN64)) >> >> won't this code still execute okay on Solaris/BSD/MacOS ? >> > > It executes okay on MacOS . So why exclude it on Mac? > Most likely it works also on Solaris x86, not sure ; only Solaris Sparc is in the list of Solaris build platforms supported in JDK13 : > > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > > I would prefer to keep the os-guards . I don't agree with making code unnecessarily platform-specific. I think someone may want to extend this for 32-bit support as well. I'd like to hear other opinions. This latest version needs a second review anyway. Thanks, David > Best regards, Matthias > From erik.joelsson at oracle.com Mon Apr 8 22:08:51 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 8 Apr 2019 15:08:51 -0700 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> <69018b42-7540-9222-a296-db28b99cdf91@oracle.com> <79a6f9dd-7f20-649c-a6c4-e6cf8f098130@oracle.com> <9c841ef7-4190-f5f8-fcfd-291c178a264d@oracle.com> <961ce204-40c9-9de9-8069-5f362497525a@oracle.com> <927E24E0-BD59-42C1-8FF9-957EF0E6D55E@oracle.com> <9513296d-6e0f-6e41-517d-9253f9ea13f6@oracle.com> <76DD7E45-E193-4F82-AE84-D58451863537@oracle.com> Message-ID: <750be466-6342-dc7d-efaf-9c68259b1252@oracle.com> New webrev with "_simple_basename": http://cr.openjdk.java.net/~erikj/8221851/webrev.05/ /Erik On 2019-04-08 12:20, Erik Joelsson wrote: > On 2019-04-08 11:40, Kim Barrett wrote: >>> On Apr 8, 2019, at 10:28 AM, Erik Joelsson >>> wrote: >>> >>> Hello, >>> >>> On 2019-04-05 15:46, Kim Barrett wrote: >>>> Assuming all that, consider instead putting this_file_helper in >>>> exceptions.hpp (perhaps with a better name?), don't bother with >>>> THIS_FILE, and define THREAD_AND_LOCATION as >>>> >>>> #define THREAD_AND_LOCATION THREAD, this_file_helper(__FILE__), >>>> __LINE__ >>>> >>> Moved to exceptions.hpp, renamed to "basename", and removed the >>> THIS_FILE macro. >> ?basename? might not count as a ?better name?, as it conflicts with a >> POSIX function, >> even though we don?t presently seem to be using that anywhere that I >> could find. >> >> > How about "simple_basename" then? Or just prefix with an underscore? > The idea is to keep it internal to the headerfile, but I'm not > familiar with conventions in Hotspot to know how you usually > prefix/namespace things as private. > > /Erik > From david.holmes at oracle.com Mon Apr 8 22:27:13 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 9 Apr 2019 08:27:13 +1000 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: <750be466-6342-dc7d-efaf-9c68259b1252@oracle.com> References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> <69018b42-7540-9222-a296-db28b99cdf91@oracle.com> <79a6f9dd-7f20-649c-a6c4-e6cf8f098130@oracle.com> <9c841ef7-4190-f5f8-fcfd-291c178a264d@oracle.com> <961ce204-40c9-9de9-8069-5f362497525a@oracle.com> <927E24E0-BD59-42C1-8FF9-957EF0E6D55E@oracle.com> <9513296d-6e0f-6e41-517d-9253f9ea13f6@oracle.com> <76DD7E45-E193-4F82-AE84-D58451863537@oracle.com> <750be466-6342-dc7d-efaf-9c68259b1252@oracle.com> Message-ID: Hi Erik, On 9/04/2019 8:08 am, Erik Joelsson wrote: > New webrev with "_simple_basename": > http://cr.openjdk.java.net/~erikj/8221851/webrev.05/ Given the usage is typically of the form: Exceptions::_throw(THREAD_AND_LOCATION, e); which will expand to: Exceptions::_throw(THREAD, _simple_basename(__FILE__), __LINE__, e); what does the compiler actually generate for this at the call sites? I'm struggling with the addition of an inline function to a .hpp which we generally frown upon and have been working to remove. What affect does this have on code size? Thanks, David ----- > /Erik > > On 2019-04-08 12:20, Erik Joelsson wrote: >> On 2019-04-08 11:40, Kim Barrett wrote: >>>> On Apr 8, 2019, at 10:28 AM, Erik Joelsson >>>> wrote: >>>> >>>> Hello, >>>> >>>> On 2019-04-05 15:46, Kim Barrett wrote: >>>>> Assuming all that, consider instead putting this_file_helper in >>>>> exceptions.hpp (perhaps with a better name?), don't bother with >>>>> THIS_FILE, and define THREAD_AND_LOCATION as >>>>> >>>>> #define THREAD_AND_LOCATION THREAD, this_file_helper(__FILE__), >>>>> __LINE__ >>>>> >>>> Moved to exceptions.hpp, renamed to "basename", and removed the >>>> THIS_FILE macro. >>> ?basename? might not count as a ?better name?, as it conflicts with a >>> POSIX function, >>> even though we don?t presently seem to be using that anywhere that I >>> could find. >>> >>> >> How about "simple_basename" then? Or just prefix with an underscore? >> The idea is to keep it internal to the headerfile, but I'm not >> familiar with conventions in Hotspot to know how you usually >> prefix/namespace things as private. >> >> /Erik >> From fanjinke51 at yeah.net Tue Apr 9 03:17:56 2019 From: fanjinke51 at yeah.net (Jinke Fan) Date: Tue, 9 Apr 2019 11:17:56 +0800 Subject: [PATCH v2] JDK-8222090: Add Hygon Dhyana support Message-ID: <781ea4cd-f46f-71e6-5b85-5ea6a3b89a0d@yeah.net> Hi David, This patch is used to support Hygon Dhyana x86 vendor id (HygonGenuine). As Hygon Dhyana CPU share most architecture feature same as AMD Family 17h, the patch adds Hygon CPU Vendor ID check to reuse AMD code paths. The changes in patch v2 from David's comments, add changes in: - VM_Version_Ext::cpu_family_description(void) - VM_Version_Ext::cpu_type_description(char* const buf, size_t buf_len) Background: Chengdu Haiguang IC Design Co., Ltd (Hygon) is a Joint Venture between AMD and Haiguang Information Technology Co.,Ltd., aims at providing high performance x86 processor for China server market. Its first generation processor codename is Dhyana, which originates from AMD technology and shares most of the architecture with AMD's family 17h, but with different CPU Vendor ID("HygonGenuine")/Family series number(Family 18h). The patch is based on the original repository: hg.openjdk.java.net/jdk/jdk changeset: 54384:cd3b7ad53265 tag: tip user: kvn date: Tue Apr 02 09:45:52 2019 -0700 summary: 8221782: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.jdk.vm.ci.services Please help me with the commit process. Thank you very much! *patch The output of hg diff -g: diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp b/src/hotspot/cpu/x86/assembler_x86.cpp --- a/src/hotspot/cpu/x86/assembler_x86.cpp +++ b/src/hotspot/cpu/x86/assembler_x86.cpp @@ -3099,7 +3099,7 @@ } return; } - if (UseAddressNop && VM_Version::is_amd()) { + if (UseAddressNop && (VM_Version::is_amd() || VM_Version::is_hygon())) { // // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. // 1: 0x90 diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp @@ -262,6 +262,34 @@ int VM_Version_Ext::_no_of_cores = 0; int VM_Version_Ext::_no_of_packages = 0; +const char* const VM_Version_Ext::_family_id_hygon[] = { + "", + "", + "", + "", + "", + "", + "", + "", + "", + "", + "", + "", + "", + "", + "", + "", + "", + "", + "", + "", + "", + "", + "", + "", + "Dhyana" //family 18h +}; + void VM_Version_Ext::initialize(void) { ResourceMark rm; @@ -340,6 +368,10 @@ return !is_amd_Barcelona(); } + if (is_hygon()) { + return true; + } + return false; } @@ -397,7 +429,7 @@ } const char* VM_Version_Ext::cpu_family_description(void) { - int cpu_family_id = extended_cpu_family(); + uint32_t cpu_family_id = extended_cpu_family(); if (is_amd()) { return _family_id_amd[cpu_family_id]; } @@ -407,6 +439,11 @@ } return _family_id_intel[cpu_family_id]; } + if (is_hygon()) { + if (cpu_family_id < sizeof(_family_id_hygon)/sizeof(char *)) + return _family_id_hygon[cpu_family_id]; + } + return "Unknown x86"; } @@ -423,6 +460,9 @@ } else if (is_amd()) { cpu_type = "AMD"; x64 = cpu_is_em64t() ? " AMD64" : ""; + } else if (is_hygon()) { + cpu_type = "Hygon"; + x64 = cpu_is_em64t() ? " AMD64" : ""; } else { cpu_type = "Unknown x86"; x64 = cpu_is_em64t() ? " x86_64" : ""; diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.hpp b/src/hotspot/cpu/x86/vm_version_ext_x86.hpp --- a/src/hotspot/cpu/x86/vm_version_ext_x86.hpp +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.hpp @@ -37,6 +37,7 @@ static const char* const _family_id_intel[]; static const char* const _family_id_amd[]; + static const char* const _family_id_hygon[]; static const char* const _brand_id[]; static const char* const _model_id_pentium_pro[]; diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp b/src/hotspot/cpu/x86/vm_version_x86.cpp --- a/src/hotspot/cpu/x86/vm_version_x86.cpp +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp @@ -1165,7 +1165,7 @@ } } - if( is_amd() ) { // AMD cpus specific settings + if( is_amd() || is_hygon() ) { // AMD cpus specific settings if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { // Use it on new AMD cpus starting from Opteron. UseAddressNop = true; @@ -1239,8 +1239,8 @@ } #endif // COMPILER2 - // Some defaults for AMD family 17h - if ( cpu_family() == 0x17 ) { + // Some defaults for AMD family 17h || Hygon family 18h + if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { // On family 17h processors use XMM and UnalignedLoadStores for Array Copy if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp b/src/hotspot/cpu/x86/vm_version_x86.hpp --- a/src/hotspot/cpu/x86/vm_version_x86.hpp +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp @@ -495,13 +495,13 @@ result |= CPU_CX8; if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) result |= CPU_CMOV; - if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && + if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() || is_hygon()) && _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) result |= CPU_FXSR; // HT flag is set for multi-core processors also. if (threads_per_core() > 1) result |= CPU_HT; - if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && + if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() || is_hygon()) && _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) result |= CPU_MMX; if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) @@ -576,8 +576,8 @@ if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) result |= CPU_FMA; - // AMD features. - if (is_amd()) { + // AMD|Hygon features. + if (is_amd() || is_hygon()) { if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) result |= CPU_3DNOW_PREFETCH; @@ -711,6 +711,7 @@ static int cpu_family() { return _cpu;} static bool is_P6() { return cpu_family() >= 6; } static bool is_amd() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' + static bool is_hygon() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x6F677948; } // 'ogyH' static bool is_intel() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' static bool is_zx() { assert_is_initialized(); return (_cpuid_info.std_vendor_name_0 == 0x746e6543) || (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS ' static bool is_atom_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton @@ -734,7 +735,7 @@ if (!supports_topology || result == 0) { result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); } - } else if (is_amd()) { + } else if (is_amd() || is_hygon()) { result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); } else if (is_zx()) { bool supports_topology = supports_processor_topology(); @@ -770,7 +771,7 @@ intx result = 0; if (is_intel()) { result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); - } else if (is_amd()) { + } else if (is_amd() || is_hygon()) { result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; } else if (is_zx()) { result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); @@ -857,7 +858,7 @@ // AMD features static bool supports_3dnow_prefetch() { return (_features & CPU_3DNOW_PREFETCH) != 0; } - static bool supports_mmx_ext() { return is_amd() && _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } + static bool supports_mmx_ext() { return (is_amd()||is_hygon()) && _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } static bool supports_lzcnt() { return (_features & CPU_LZCNT) != 0; } static bool supports_sse4a() { return (_features & CPU_SSE4A) != 0; } @@ -870,7 +871,7 @@ } static bool supports_tscinv() { return supports_tscinv_bit() && - ( (is_amd() && !is_amd_Barcelona()) || + ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || is_intel_tsc_synched_at_init() ); } @@ -896,7 +897,7 @@ // Core - 256 / prefetchnta // It will be used only when AllocatePrefetchStyle > 0 - if (is_amd()) { // AMD + if (is_amd() || is_hygon()) { // AMD if (supports_sse2()) { return 256; // Opteron } else { *test I tested it with jtreg and found no regressions. Base Run? ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/hotspot/jtreg:tier1 1396 1396 0 0 >> jtreg:test/jdk:tier1 1867 1866 1 0 << >> jtreg:test/langtools:tier1 3920 3919 1 0 << jtreg:test/nashorn:tier1 0 0 0 0 jtreg:test/jaxp:tier1 0 0 0 0 ============================== TEST FAILURE And The result of after patching is the same as the before. ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/hotspot/jtreg:tier1 1396 1396 0 0 >> jtreg:test/jdk:tier1 1867 1866 1 0 << >> jtreg:test/langtools:tier1 3920 3919 1 0 << jtreg:test/nashorn:tier1 0 0 0 0 jtreg:test/jaxp:tier1 0 0 0 0 ============================== TEST FAILURE result of testcase TestCPUInformation.java ----------System.out:(15/1604)---------- Event: jdk.CPUInformation { startTime = 11:10:26.284 cpu = "Hygon Dhyana (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 SSE4A AMD64" description = "Brand: Hygon Dhyana Eng Sample , Vendor: HygonGenuine Family: Dhyana (0x18), Model: (0x0), Stepping: 0x2 Ext. family: 0x9, Ext. model: 0x0, Type: 0x0, Signature: 0x00900f02 Features: ebx: 0x06100800, ecx: 0x3cd83209, edx: 0x178bfbff Ext. features: eax: 0x00900f02, ebx: 0x60000000, ecx: 0x35c233ff, edx: 0x2fd3fbff Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, Intel Architecture MMX Technology, Fast Fl oat Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Hyper Threading, Streaming SIMD Extensions 3, MONITOR/MWAIT instructions, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, S treaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, MOVBE, Popcount instruction, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Core multi-processor leagacy mode, Advanced Bit Manipulations: LZCNT, SSE4A: MOVNTSS, MOVNTSD, EXTRQ, INSERTQ, Misaligned SSE mode, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC" sockets = 1 cores = 16 hwThreads = 16 } Is there anything incorrectly? Please let me know your comments. Best Regards! Fanjinke. From david.holmes at oracle.com Tue Apr 9 04:13:19 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 9 Apr 2019 14:13:19 +1000 Subject: [PATCH v2] JDK-8222090: Add Hygon Dhyana support In-Reply-To: <781ea4cd-f46f-71e6-5b85-5ea6a3b89a0d@yeah.net> References: <781ea4cd-f46f-71e6-5b85-5ea6a3b89a0d@yeah.net> Message-ID: Hi Fanjinke, On 9/04/2019 1:17 pm, Jinke Fan wrote: > Hi David, > > This patch is used to support Hygon Dhyana x86 vendor id (HygonGenuine). > As Hygon Dhyana CPU share most architecture feature same as AMD Family 17h, > the patch adds Hygon CPU Vendor ID check to reuse AMD code paths. > > The changes in patch v2 from David's comments, > add changes in: > - VM_Version_Ext::cpu_family_description(void) > - VM_Version_Ext::cpu_type_description(char* const buf, size_t buf_len) I don't understand why you did all the empty array setup to support this: + if (is_hygon()) { + if (cpu_family_id < sizeof(_family_id_hygon)/sizeof(char *)) + return _family_id_hygon[cpu_family_id]; + } instead of just doing: + if (is_hygon()) { + return "Dhyana"; // or Hygon or whatever is appropriate + } as you only have one cpu_family_id for Hygon ?? > + } else if (is_hygon()) { > + cpu_type = "Hygon"; > + x64 = cpu_is_em64t() ? " AMD64" : ""; Is cpu_is_em64t just an archaic way of asking is_64bit()? Thanks, David > Background: > ??? Chengdu Haiguang IC Design Co., Ltd (Hygon) is a Joint Venture > ??? between AMD and Haiguang Information Technology Co.,Ltd., aims at > ??? providing high performance x86 processor for China server market. > ??? Its first generation processor codename is Dhyana, which > ??? originates from AMD technology and shares most of the > ??? architecture with AMD's family 17h, but with different CPU Vendor > ??? ID("HygonGenuine")/Family series number(Family 18h). > > The patch is based on the original repository: > hg.openjdk.java.net/jdk/jdk > > changeset:?? 54384:cd3b7ad53265 > tag:???????? tip > user:??????? kvn > date:??????? Tue Apr 02 09:45:52 2019 -0700 > summary:???? 8221782: [Graal] Module jdk.internal.vm.compiler.management > has not been granted accessClassInPackage.jdk.vm.ci.services > > Please help me with the commit process. > Thank you very much! > > *patch > > The output of hg diff -g: > diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp > b/src/hotspot/cpu/x86/assembler_x86.cpp > --- a/src/hotspot/cpu/x86/assembler_x86.cpp > +++ b/src/hotspot/cpu/x86/assembler_x86.cpp > @@ -3099,7 +3099,7 @@ > ???? } > ???? return; > ?? } > -? if (UseAddressNop && VM_Version::is_amd()) { > +? if (UseAddressNop && (VM_Version::is_amd() || VM_Version::is_hygon())) { > ???? // > ???? // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. > ???? //? 1: 0x90 > diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp > b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp > --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp > +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp > @@ -262,6 +262,34 @@ > ?int VM_Version_Ext::_no_of_cores = 0; > ?int VM_Version_Ext::_no_of_packages = 0; > > +const char* const VM_Version_Ext::_family_id_hygon[] = { > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "Dhyana"???? //family 18h > +}; > + > ?void VM_Version_Ext::initialize(void) { > ?? ResourceMark rm; > > @@ -340,6 +368,10 @@ > ???? return !is_amd_Barcelona(); > ?? } > > +? if (is_hygon()) { > +??? return true; > +? } > + > ?? return false; > ?} > > @@ -397,7 +429,7 @@ > ?} > > ?const char* VM_Version_Ext::cpu_family_description(void) { > -? int cpu_family_id = extended_cpu_family(); > +? uint32_t cpu_family_id = extended_cpu_family(); > ?? if (is_amd()) { > ???? return _family_id_amd[cpu_family_id]; > ?? } > @@ -407,6 +439,11 @@ > ???? } > ???? return _family_id_intel[cpu_family_id]; > ?? } > +? if (is_hygon()) { > +??? if (cpu_family_id < sizeof(_family_id_hygon)/sizeof(char *)) > +????? return _family_id_hygon[cpu_family_id]; > +? } > + > ?? return "Unknown x86"; > ?} > > @@ -423,6 +460,9 @@ > ?? } else if (is_amd()) { > ???? cpu_type = "AMD"; > ???? x64 = cpu_is_em64t() ? " AMD64" : ""; > +? } else if (is_hygon()) { > +?????? cpu_type = "Hygon"; > +?????? x64 = cpu_is_em64t() ? " AMD64" : ""; > ?? } else { > ???? cpu_type = "Unknown x86"; > ???? x64 = cpu_is_em64t() ? " x86_64" : ""; > diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.hpp > b/src/hotspot/cpu/x86/vm_version_ext_x86.hpp > --- a/src/hotspot/cpu/x86/vm_version_ext_x86.hpp > +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.hpp > @@ -37,6 +37,7 @@ > > ?? static const char* const _family_id_intel[]; > ?? static const char* const _family_id_amd[]; > +? static const char* const _family_id_hygon[]; > ?? static const char* const _brand_id[]; > ?? static const char* const _model_id_pentium_pro[]; > > diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp > b/src/hotspot/cpu/x86/vm_version_x86.cpp > --- a/src/hotspot/cpu/x86/vm_version_x86.cpp > +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp > @@ -1165,7 +1165,7 @@ > ???? } > ?? } > > -? if( is_amd() ) { // AMD cpus specific settings > +? if( is_amd() || is_hygon() ) { // AMD cpus specific settings > ???? if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { > ?????? // Use it on new AMD cpus starting from Opteron. > ?????? UseAddressNop = true; > @@ -1239,8 +1239,8 @@ > ???? } > ?#endif // COMPILER2 > > -??? // Some defaults for AMD family 17h > -??? if ( cpu_family() == 0x17 ) { > +??? // Some defaults for AMD family 17h || Hygon family 18h > +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { > ?????? // On family 17h processors use XMM and UnalignedLoadStores for > Array Copy > ?????? if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { > ???????? FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); > diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp > b/src/hotspot/cpu/x86/vm_version_x86.hpp > --- a/src/hotspot/cpu/x86/vm_version_x86.hpp > +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp > @@ -495,13 +495,13 @@ > ?????? result |= CPU_CX8; > ???? if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) > ?????? result |= CPU_CMOV; > -??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && > +??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() || > is_hygon()) && > ???????? _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) > ?????? result |= CPU_FXSR; > ???? // HT flag is set for multi-core processors also. > ???? if (threads_per_core() > 1) > ?????? result |= CPU_HT; > -??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && > +??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() || > is_hygon()) && > ???????? _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) > ?????? result |= CPU_MMX; > ???? if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) > @@ -576,8 +576,8 @@ > ???? if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) > ?????? result |= CPU_FMA; > > -??? // AMD features. > -??? if (is_amd()) { > +??? // AMD|Hygon features. > +??? if (is_amd() || is_hygon()) { > ?????? if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || > ?????????? (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) > ???????? result |= CPU_3DNOW_PREFETCH; > @@ -711,6 +711,7 @@ > ?? static int? cpu_family()??????? { return _cpu;} > ?? static bool is_P6()???????????? { return cpu_family() >= 6; } > ?? static bool is_amd()??????????? { assert_is_initialized(); return > _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' > +? static bool is_hygon()????????? { assert_is_initialized(); return > _cpuid_info.std_vendor_name_0 == 0x6F677948; } // 'ogyH' > ?? static bool is_intel()????????? { assert_is_initialized(); return > _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' > ?? static bool is_zx()???????????? { assert_is_initialized(); return > (_cpuid_info.std_vendor_name_0 == 0x746e6543) || > (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS? ' > ?? static bool is_atom_family()??? { return ((cpu_family() == 0x06) && > ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) || > (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton > @@ -734,7 +735,7 @@ > ?????? if (!supports_topology || result == 0) { > ???????? result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); > ?????? } > -??? } else if (is_amd()) { > +??? } else if (is_amd() || is_hygon()) { > ?????? result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); > ???? } else if (is_zx()) { > ?????? bool supports_topology = supports_processor_topology(); > @@ -770,7 +771,7 @@ > ???? intx result = 0; > ???? if (is_intel()) { > ?????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); > -??? } else if (is_amd()) { > +??? } else if (is_amd() || is_hygon()) { > ?????? result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; > ???? } else if (is_zx()) { > ?????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); > @@ -857,7 +858,7 @@ > > ?? // AMD features > ?? static bool supports_3dnow_prefetch()??? { return (_features & > CPU_3DNOW_PREFETCH) != 0; } > -? static bool supports_mmx_ext()? { return is_amd() && > _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } > +? static bool supports_mmx_ext()? { return (is_amd()||is_hygon()) && > _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } > ?? static bool supports_lzcnt()??? { return (_features & CPU_LZCNT) != > 0; } > ?? static bool supports_sse4a()??? { return (_features & CPU_SSE4A) != > 0; } > > @@ -870,7 +871,7 @@ > ?? } > ?? static bool supports_tscinv() { > ???? return supports_tscinv_bit() && > -?????????? ( (is_amd() && !is_amd_Barcelona()) || > +?????????? ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || > ????????????? is_intel_tsc_synched_at_init() ); > ?? } > > @@ -896,7 +897,7 @@ > ???? // Core????? - 256 / prefetchnta > ???? // It will be used only when AllocatePrefetchStyle > 0 > > -??? if (is_amd()) { // AMD > +??? if (is_amd() || is_hygon()) { // AMD > ?????? if (supports_sse2()) { > ???????? return 256; // Opteron > ?????? } else { > > *test > I tested it with jtreg and found no regressions. > > Base Run? > ============================== > Test summary > ============================== > ?? TEST??????????????????????????????????? TOTAL? PASS? FAIL ERROR > ?? jtreg:test/hotspot/jtreg:tier1????????? 1396? 1396???? 0???? 0 >>> jtreg:test/jdk:tier1??????????????????? 1867? 1866???? 1???? 0 << >>> jtreg:test/langtools:tier1????????????? 3920? 3919???? 1???? 0 << > ?? jtreg:test/nashorn:tier1??????????????? 0???? 0???? 0???? 0 > ?? jtreg:test/jaxp:tier1?????????????????? 0???? 0???? 0???? 0 > ============================== > TEST FAILURE > > And The result of after patching is the same as the before. > ============================== > Test summary > ============================== > ?? TEST???????????????????????????????????? TOTAL? PASS? FAIL ERROR > ?? jtreg:test/hotspot/jtreg:tier1?????????? 1396? 1396???? 0???? 0 >>> jtreg:test/jdk:tier1???????????????????? 1867? 1866???? 1???? 0 << >>> jtreg:test/langtools:tier1?????????????? 3920? 3919???? 1???? 0 << > ?? jtreg:test/nashorn:tier1???????????????? 0???? 0???? 0???? 0 > ?? jtreg:test/jaxp:tier1??????????????????? 0???? 0???? 0???? 0 > ============================== > TEST FAILURE > > result of testcase TestCPUInformation.java > ----------System.out:(15/1604)---------- > Event: jdk.CPUInformation { > ? startTime = 11:10:26.284 > ? cpu = "Hygon Dhyana (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 SSE4A AMD64" > ? description = "Brand: Hygon Dhyana Eng Sample , Vendor: HygonGenuine > Family: Dhyana (0x18), Model: (0x0), Stepping: 0x2 > Ext. family: 0x9, Ext. model: 0x0, Type: 0x0, Signature: 0x00900f02 > Features: ebx: 0x06100800, ecx: 0x3cd83209, edx: 0x178bfbff > Ext. features: eax: 0x00900f02, ebx: 0x60000000, ecx: 0x35c233ff, edx: > 0x2fd3fbff > Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, > Page Size Extensions, Time Stamp Counter, Model Specific Registers, > Physical Address Extension, Machine Check Exceptions, CMPXCHG8B > Instruction, On-Chip APIC, Fast > ?System Call, Memory Type Range Registers, Page Global Enable, Machine > Check Architecture, Conditional Mov Instruction, Page Attribute Table, > 36-bit Page Size Extension, CLFLUSH Instruction, Intel Architecture MMX > Technology, Fast Fl > oat Point Save and Restore, Streaming SIMD extensions, Streaming SIMD > extensions 2, Hyper Threading, Streaming SIMD Extensions 3, > MONITOR/MWAIT instructions, Supplemental Streaming SIMD Extensions 3, > Fused Multiply-Add, CMPXCHG16B, S > treaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, MOVBE, > Popcount instruction, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction > support, Core multi-processor leagacy mode, Advanced Bit Manipulations: > LZCNT, SSE4A: MOVNTSS, > ?MOVNTSD, EXTRQ, INSERTQ, Misaligned SSE mode, SYSCALL/SYSRET, Execute > Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC" > ? sockets = 1 > ? cores = 16 > ? hwThreads = 16 > } > > Is there anything incorrectly? > Please let me know your comments. > > Best Regards! > Fanjinke. > From fanjinke51 at yeah.net Tue Apr 9 05:41:45 2019 From: fanjinke51 at yeah.net (Jinke Fan) Date: Tue, 9 Apr 2019 13:41:45 +0800 Subject: [PATCH v2] JDK-8222090: Add Hygon Dhyana support In-Reply-To: References: <781ea4cd-f46f-71e6-5b85-5ea6a3b89a0d@yeah.net> Message-ID: Hi David, Thank you for your comments. On 2019/4/9 12:13, David Holmes wrote: > Hi Fanjinke, > > On 9/04/2019 1:17 pm, Jinke Fan wrote: >> Hi David, >> >> This patch is used to support Hygon Dhyana x86 vendor id (HygonGenuine). >> As Hygon Dhyana CPU share most architecture feature same as AMD Family >> 17h, >> the patch adds Hygon CPU Vendor ID check to reuse AMD code paths. >> >> The changes in patch v2 from David's comments, >> add changes in: >> - VM_Version_Ext::cpu_family_description(void) >> - VM_Version_Ext::cpu_type_description(char* const buf, size_t buf_len) > > I don't understand why you did all the empty array setup to support this: > > +? if (is_hygon()) { > +??? if (cpu_family_id < sizeof(_family_id_hygon)/sizeof(char *)) > +????? return _family_id_hygon[cpu_family_id]; > +? } > > instead of just doing: > > +? if (is_hygon()) { > +????? return "Dhyana"; // or Hygon or whatever is appropriate > +? } > I will update the patch, change + if (is_hygon()) { + if (cpu_family_id < sizeof(_family_id_hygon)/sizeof(char *)) + return _family_id_hygon[cpu_family_id]; + } to + if (is_hygon()) { + return "Dhyana"; // or Hygon or whatever is appropriate + } > as you only have one cpu_family_id for Hygon ?? Hygon only have one cpu_family_id as so far,and it continue with amd's cpu_family_id. > > > +? } else if (is_hygon()) { > > +?????? cpu_type = "Hygon"; > > +?????? x64 = cpu_is_em64t() ? " AMD64" : ""; > > Is cpu_is_em64t just an archaic way of asking is_64bit()? cpu_is_em64t is not new. I reuse the VM_Version_Ext::cpu_is_em64t function which intet/amd used, it's also work well in Hygon cpu. Thanks again, Best Regards! Fanjinke > > Thanks, > David > > >> Background: >> ???? Chengdu Haiguang IC Design Co., Ltd (Hygon) is a Joint Venture >> ???? between AMD and Haiguang Information Technology Co.,Ltd., aims at >> ???? providing high performance x86 processor for China server market. >> ???? Its first generation processor codename is Dhyana, which >> ???? originates from AMD technology and shares most of the >> ???? architecture with AMD's family 17h, but with different CPU Vendor >> ???? ID("HygonGenuine")/Family series number(Family 18h). >> >> The patch is based on the original repository: >> hg.openjdk.java.net/jdk/jdk >> >> changeset:?? 54384:cd3b7ad53265 >> tag:???????? tip >> user:??????? kvn >> date:??????? Tue Apr 02 09:45:52 2019 -0700 >> summary:???? 8221782: [Graal] Module >> jdk.internal.vm.compiler.management has not been granted >> accessClassInPackage.jdk.vm.ci.services >> >> Please help me with the commit process. >> Thank you very much! >> >> *patch >> >> The output of hg diff -g: >> diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp >> b/src/hotspot/cpu/x86/assembler_x86.cpp >> --- a/src/hotspot/cpu/x86/assembler_x86.cpp >> +++ b/src/hotspot/cpu/x86/assembler_x86.cpp >> @@ -3099,7 +3099,7 @@ >> ????? } >> ????? return; >> ??? } >> -? if (UseAddressNop && VM_Version::is_amd()) { >> +? if (UseAddressNop && (VM_Version::is_amd() || >> VM_Version::is_hygon())) { >> ????? // >> ????? // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. >> ????? //? 1: 0x90 >> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> @@ -262,6 +262,34 @@ >> ??int VM_Version_Ext::_no_of_cores = 0; >> ??int VM_Version_Ext::_no_of_packages = 0; >> >> +const char* const VM_Version_Ext::_family_id_hygon[] = { >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "Dhyana"???? //family 18h >> +}; >> + >> ??void VM_Version_Ext::initialize(void) { >> ??? ResourceMark rm; >> >> @@ -340,6 +368,10 @@ >> ????? return !is_amd_Barcelona(); >> ??? } >> >> +? if (is_hygon()) { >> +??? return true; >> +? } >> + >> ??? return false; >> ??} >> >> @@ -397,7 +429,7 @@ >> ??} >> >> ??const char* VM_Version_Ext::cpu_family_description(void) { >> -? int cpu_family_id = extended_cpu_family(); >> +? uint32_t cpu_family_id = extended_cpu_family(); >> ??? if (is_amd()) { >> ????? return _family_id_amd[cpu_family_id]; >> ??? } >> @@ -407,6 +439,11 @@ >> ????? } >> ????? return _family_id_intel[cpu_family_id]; >> ??? } >> +? if (is_hygon()) { >> +??? if (cpu_family_id < sizeof(_family_id_hygon)/sizeof(char *)) >> +????? return _family_id_hygon[cpu_family_id]; >> +? } >> + >> ??? return "Unknown x86"; >> ??} >> >> @@ -423,6 +460,9 @@ >> ??? } else if (is_amd()) { >> ????? cpu_type = "AMD"; >> ????? x64 = cpu_is_em64t() ? " AMD64" : ""; >> +? } else if (is_hygon()) { >> +?????? cpu_type = "Hygon"; >> +?????? x64 = cpu_is_em64t() ? " AMD64" : ""; >> ??? } else { >> ????? cpu_type = "Unknown x86"; >> ????? x64 = cpu_is_em64t() ? " x86_64" : ""; >> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.hpp >> b/src/hotspot/cpu/x86/vm_version_ext_x86.hpp >> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.hpp >> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.hpp >> @@ -37,6 +37,7 @@ >> >> ??? static const char* const _family_id_intel[]; >> ??? static const char* const _family_id_amd[]; >> +? static const char* const _family_id_hygon[]; >> ??? static const char* const _brand_id[]; >> ??? static const char* const _model_id_pentium_pro[]; >> >> diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp >> b/src/hotspot/cpu/x86/vm_version_x86.cpp >> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp >> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >> @@ -1165,7 +1165,7 @@ >> ????? } >> ??? } >> >> -? if( is_amd() ) { // AMD cpus specific settings >> +? if( is_amd() || is_hygon() ) { // AMD cpus specific settings >> ????? if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { >> ??????? // Use it on new AMD cpus starting from Opteron. >> ??????? UseAddressNop = true; >> @@ -1239,8 +1239,8 @@ >> ????? } >> ??#endif // COMPILER2 >> >> -??? // Some defaults for AMD family 17h >> -??? if ( cpu_family() == 0x17 ) { >> +??? // Some defaults for AMD family 17h || Hygon family 18h >> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >> ??????? // On family 17h processors use XMM and UnalignedLoadStores >> for Array Copy >> ??????? if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >> ????????? FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >> diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp >> b/src/hotspot/cpu/x86/vm_version_x86.hpp >> --- a/src/hotspot/cpu/x86/vm_version_x86.hpp >> +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp >> @@ -495,13 +495,13 @@ >> ??????? result |= CPU_CX8; >> ????? if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) >> ??????? result |= CPU_CMOV; >> -??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && >> +??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() || >> is_hygon()) && >> ????????? _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) >> ??????? result |= CPU_FXSR; >> ????? // HT flag is set for multi-core processors also. >> ????? if (threads_per_core() > 1) >> ??????? result |= CPU_HT; >> -??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && >> +??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() || >> is_hygon()) && >> ????????? _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) >> ??????? result |= CPU_MMX; >> ????? if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) >> @@ -576,8 +576,8 @@ >> ????? if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >> ??????? result |= CPU_FMA; >> >> -??? // AMD features. >> -??? if (is_amd()) { >> +??? // AMD|Hygon features. >> +??? if (is_amd() || is_hygon()) { >> ??????? if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || >> ??????????? (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) >> ????????? result |= CPU_3DNOW_PREFETCH; >> @@ -711,6 +711,7 @@ >> ??? static int? cpu_family()??????? { return _cpu;} >> ??? static bool is_P6()???????????? { return cpu_family() >= 6; } >> ??? static bool is_amd()??????????? { assert_is_initialized(); return >> _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' >> +? static bool is_hygon()????????? { assert_is_initialized(); return >> _cpuid_info.std_vendor_name_0 == 0x6F677948; } // 'ogyH' >> ??? static bool is_intel()????????? { assert_is_initialized(); return >> _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' >> ??? static bool is_zx()???????????? { assert_is_initialized(); return >> (_cpuid_info.std_vendor_name_0 == 0x746e6543) || >> (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS? ' >> ??? static bool is_atom_family()??? { return ((cpu_family() == 0x06) >> && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) >> || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton >> @@ -734,7 +735,7 @@ >> ??????? if (!supports_topology || result == 0) { >> ????????? result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); >> ??????? } >> -??? } else if (is_amd()) { >> +??? } else if (is_amd() || is_hygon()) { >> ??????? result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); >> ????? } else if (is_zx()) { >> ??????? bool supports_topology = supports_processor_topology(); >> @@ -770,7 +771,7 @@ >> ????? intx result = 0; >> ????? if (is_intel()) { >> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >> -??? } else if (is_amd()) { >> +??? } else if (is_amd() || is_hygon()) { >> ??????? result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; >> ????? } else if (is_zx()) { >> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >> @@ -857,7 +858,7 @@ >> >> ??? // AMD features >> ??? static bool supports_3dnow_prefetch()??? { return (_features & >> CPU_3DNOW_PREFETCH) != 0; } >> -? static bool supports_mmx_ext()? { return is_amd() && >> _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >> +? static bool supports_mmx_ext()? { return (is_amd()||is_hygon()) && >> _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >> ??? static bool supports_lzcnt()??? { return (_features & CPU_LZCNT) >> != 0; } >> ??? static bool supports_sse4a()??? { return (_features & CPU_SSE4A) >> != 0; } >> >> @@ -870,7 +871,7 @@ >> ??? } >> ??? static bool supports_tscinv() { >> ????? return supports_tscinv_bit() && >> -?????????? ( (is_amd() && !is_amd_Barcelona()) || >> +?????????? ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || >> ?????????????? is_intel_tsc_synched_at_init() ); >> ??? } >> >> @@ -896,7 +897,7 @@ >> ????? // Core????? - 256 / prefetchnta >> ????? // It will be used only when AllocatePrefetchStyle > 0 >> >> -??? if (is_amd()) { // AMD >> +??? if (is_amd() || is_hygon()) { // AMD >> ??????? if (supports_sse2()) { >> ????????? return 256; // Opteron >> ??????? } else { >> >> *test >> I tested it with jtreg and found no regressions. >> >> Base Run? >> ============================== >> Test summary >> ============================== >> ??? TEST??????????????????????????????????? TOTAL? PASS? FAIL ERROR >> ??? jtreg:test/hotspot/jtreg:tier1????????? 1396? 1396???? 0???? 0 >>>> jtreg:test/jdk:tier1??????????????????? 1867? 1866???? 1???? 0 << >>>> jtreg:test/langtools:tier1????????????? 3920? 3919???? 1???? 0 << >> ??? jtreg:test/nashorn:tier1??????????????? 0???? 0???? 0???? 0 >> ??? jtreg:test/jaxp:tier1?????????????????? 0???? 0???? 0???? 0 >> ============================== >> TEST FAILURE >> >> And The result of after patching is the same as the before. >> ============================== >> Test summary >> ============================== >> ??? TEST???????????????????????????????????? TOTAL? PASS? FAIL ERROR >> ??? jtreg:test/hotspot/jtreg:tier1?????????? 1396? 1396???? 0???? 0 >>>> jtreg:test/jdk:tier1???????????????????? 1867? 1866???? 1???? 0 << >>>> jtreg:test/langtools:tier1?????????????? 3920? 3919???? 1???? 0 << >> ??? jtreg:test/nashorn:tier1???????????????? 0???? 0???? 0???? 0 >> ??? jtreg:test/jaxp:tier1??????????????????? 0???? 0???? 0???? 0 >> ============================== >> TEST FAILURE >> >> result of testcase TestCPUInformation.java >> ----------System.out:(15/1604)---------- >> Event: jdk.CPUInformation { >> ?? startTime = 11:10:26.284 >> ?? cpu = "Hygon Dhyana (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 SSE4A >> AMD64" >> ?? description = "Brand: Hygon Dhyana Eng Sample , Vendor: HygonGenuine >> Family: Dhyana (0x18), Model: (0x0), Stepping: 0x2 >> Ext. family: 0x9, Ext. model: 0x0, Type: 0x0, Signature: 0x00900f02 >> Features: ebx: 0x06100800, ecx: 0x3cd83209, edx: 0x178bfbff >> Ext. features: eax: 0x00900f02, ebx: 0x60000000, ecx: 0x35c233ff, edx: >> 0x2fd3fbff >> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, >> Page Size Extensions, Time Stamp Counter, Model Specific Registers, >> Physical Address Extension, Machine Check Exceptions, CMPXCHG8B >> Instruction, On-Chip APIC, Fast >> ??System Call, Memory Type Range Registers, Page Global Enable, >> Machine Check Architecture, Conditional Mov Instruction, Page >> Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, >> Intel Architecture MMX Technology, Fast Fl >> oat Point Save and Restore, Streaming SIMD extensions, Streaming SIMD >> extensions 2, Hyper Threading, Streaming SIMD Extensions 3, >> MONITOR/MWAIT instructions, Supplemental Streaming SIMD Extensions 3, >> Fused Multiply-Add, CMPXCHG16B, S >> treaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, MOVBE, >> Popcount instruction, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction >> support, Core multi-processor leagacy mode, Advanced Bit >> Manipulations: LZCNT, SSE4A: MOVNTSS, >> ??MOVNTSD, EXTRQ, INSERTQ, Misaligned SSE mode, SYSCALL/SYSRET, >> Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC" >> ?? sockets = 1 >> ?? cores = 16 >> ?? hwThreads = 16 >> } >> >> Is there anything incorrectly? >> Please let me know your comments. >> >> Best Regards! >> Fanjinke. >> > From yumin.qi at gmail.com Tue Apr 9 06:10:59 2019 From: yumin.qi at gmail.com (yumin qi) Date: Mon, 8 Apr 2019 23:10:59 -0700 Subject: RFC: JWarmup precompile java hot methods at application startup In-Reply-To: References: Message-ID: Hi, all Please check following link for second version: http://cr.openjdk.java.net/~minqi/8220692/webrev-02/ The changes are based on Tobias' and Alan's comments. 1) Add OS checking to enable JWarmUp run with Linux only. 2) created new module for jwarmup (jdk.jwarmup) make JWamUp instance singleton. Calling its functions has to go with the only instance. I moved JWarmUp.registerNatives to jvm.cpp instead, before it is a separate file src/java.base/share/native/libjava/JWarmUp.c. Now the file removed. One problem confused me is, with a new module jdk.jwarmup and all others kept as before, it is unable to find the native of JWarmUp.registerNatives though its native entry is still in libjava.so like before. (certainly changed calling convention according to new package name) Now the registerNatives is found when it looks up for native entry in lookupNative.cpp. I thought the class JWarmUp will be loaded by boot loader like Unsafe or WhiteBox, but I was wrong, it is loaded by app class loader so logic for obtaining its native entry put in both cases, boot loader and non boot loaders. 3) changed test cases to run with new jdk.jwarmup module. All test cases run on Linux only. Tests: passed all tests locally. Submit build failed in local due to a compilation error: /home//ws/submit/submit/build/linux-x86_64-server-slowdebug/support/gensrc/jdk.internal.vm.compiler/org/graalvm/compiler/replacements/arraycopy/PluginFactory_ArrayCopySnippets.java:35: error: cannot find symbol jdk.internal.vm.compiler.word.LocationIdentity result = org.graalvm.compiler.replacements.arraycopy.ArrayCopySnippets.getArrayLocation(arg0); ^ (I will double check that, it is not related to this change). Please give your comments. Thanks Yumin On Thu, Mar 14, 2019 at 10:59 PM yumin qi wrote: > Please review the patch for implementing JEP 8203832: > (*https://bugs.openjdk.java.net/browse/JDK-8203832 )* > > Bug: *https://bugs.openjdk.java.net/browse/JDK-8220692 * > Webrev: http://cr.openjdk.java.net/~minqi/8220692/webrev-01/ > > Summary: This patch implements the first version of JIT warmup to solve the java application peak time CPU contest between JIT compiler threads and regular application java threads. The CPU contest is avoided by pre-run to collect comilation data and precompile the hot java methods during application startup based on the pre-run collected data. > > The main flags (-XX:) used to control are: > CompilationWarmUpRecording: used for collecting compilation data. Result stored in a file set by flag CompilationWarmUpLogfile. > CompilationWarmUp: use collected data to precompile the methods recorded in above file. > CompilationWarmUpExclude: configure a file which contains the names to be excluded for precompile. > CompilationWarmUpRecordTime: control the warmup recording time. > CompilationWarmUpDeoptTime: time (from start) to deoptimize precomiled methods. > > 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. Also, it does not work with CDS since the data added to ConstantPool data structure. It also will be addressed in another separate bug followed. > > Test: Submitted to submit repo and passed all tests. > Newly added test suites: test/hotspot/jtreg/jwarmup include test cases for most of the use cases and issues. > > Thanks > Yumin > > From fanjinke51 at yeah.net Tue Apr 9 07:22:36 2019 From: fanjinke51 at yeah.net (Jinke Fan) Date: Tue, 9 Apr 2019 15:22:36 +0800 Subject: [PATCH v3] JDK-8222090: Add Hygon Dhyana support Message-ID: Hi David, Patch v3 from David's comments, - Don't use _family_id_hygon array that mostly empty. Patch v2 from David's comments, add changes in: - VM_Version_Ext::cpu_family_description(void) - VM_Version_Ext::cpu_type_description(char* const buf, size_t buf_len) This patch is used to support Hygon Dhyana x86 vendor id (HygonGenuine). As Hygon Dhyana CPU share most architecture feature same as AMD Family 17h,the patch adds Hygon CPU Vendor ID check to reuse AMD code paths. Background: Chengdu Haiguang IC Design Co., Ltd (Hygon) is a Joint Venture between AMD and Haiguang Information Technology Co.,Ltd., aims at providing high performance x86 processor for China server market. Its first generation processor codename is Dhyana, which originates from AMD technology and shares most of the architecture with AMD's family 17h, but with different CPU Vendor ID("HygonGenuine")/Family series number(Family 18h). The patch is based on the original repository: hg.openjdk.java.net/jdk/jdk changeset: 54384:cd3b7ad53265 tag: tip user: kvn date: Tue Apr 02 09:45:52 2019 -0700 summary: 8221782: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.jdk.vm.ci.services Please help me with the commit process. Thank you very much! *patch The output of hg diff -g: diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp b/src/hotspot/cpu/x86/assembler_x86.cpp --- a/src/hotspot/cpu/x86/assembler_x86.cpp +++ b/src/hotspot/cpu/x86/assembler_x86.cpp @@ -3099,7 +3099,7 @@ } return; } - if (UseAddressNop && VM_Version::is_amd()) { + if (UseAddressNop && (VM_Version::is_amd() || VM_Version::is_hygon())) { // // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. // 1: 0x90 diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp @@ -340,6 +340,10 @@ return !is_amd_Barcelona(); } + if (is_hygon()) { + return true; + } + return false; } @@ -407,6 +411,10 @@ } return _family_id_intel[cpu_family_id]; } + if (is_hygon()) { + return "Dhyana"; + } + return "Unknown x86"; } @@ -423,6 +431,9 @@ } else if (is_amd()) { cpu_type = "AMD"; x64 = cpu_is_em64t() ? " AMD64" : ""; + } else if (is_hygon()) { + cpu_type = "Hygon"; + x64 = cpu_is_em64t() ? " AMD64" : ""; } else { cpu_type = "Unknown x86"; x64 = cpu_is_em64t() ? " x86_64" : ""; diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp b/src/hotspot/cpu/x86/vm_version_x86.cpp --- a/src/hotspot/cpu/x86/vm_version_x86.cpp +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp @@ -1165,7 +1165,7 @@ } } - if( is_amd() ) { // AMD cpus specific settings + if( is_amd() || is_hygon() ) { // AMD cpus specific settings if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { // Use it on new AMD cpus starting from Opteron. UseAddressNop = true; @@ -1239,8 +1239,8 @@ } #endif // COMPILER2 - // Some defaults for AMD family 17h - if ( cpu_family() == 0x17 ) { + // Some defaults for AMD family 17h || Hygon family 18h + if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { // On family 17h processors use XMM and UnalignedLoadStores for Array Copy if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp b/src/hotspot/cpu/x86/vm_version_x86.hpp --- a/src/hotspot/cpu/x86/vm_version_x86.hpp +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp @@ -495,13 +495,13 @@ result |= CPU_CX8; if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) result |= CPU_CMOV; - if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && + if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() || is_hygon()) && _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) result |= CPU_FXSR; // HT flag is set for multi-core processors also. if (threads_per_core() > 1) result |= CPU_HT; - if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && + if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() || is_hygon()) && _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) result |= CPU_MMX; if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) @@ -576,8 +576,8 @@ if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) result |= CPU_FMA; - // AMD features. - if (is_amd()) { + // AMD|Hygon features. + if (is_amd() || is_hygon()) { if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) result |= CPU_3DNOW_PREFETCH; @@ -711,6 +711,7 @@ static int cpu_family() { return _cpu;} static bool is_P6() { return cpu_family() >= 6; } static bool is_amd() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' + static bool is_hygon() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x6F677948; } // 'ogyH' static bool is_intel() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' static bool is_zx() { assert_is_initialized(); return (_cpuid_info.std_vendor_name_0 == 0x746e6543) || (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS ' static bool is_atom_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton @@ -734,7 +735,7 @@ if (!supports_topology || result == 0) { result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); } - } else if (is_amd()) { + } else if (is_amd() || is_hygon()) { result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); } else if (is_zx()) { bool supports_topology = supports_processor_topology(); @@ -770,7 +771,7 @@ intx result = 0; if (is_intel()) { result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); - } else if (is_amd()) { + } else if (is_amd() || is_hygon()) { result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; } else if (is_zx()) { result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); @@ -857,7 +858,7 @@ // AMD features static bool supports_3dnow_prefetch() { return (_features & CPU_3DNOW_PREFETCH) != 0; } - static bool supports_mmx_ext() { return is_amd() && _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } + static bool supports_mmx_ext() { return (is_amd()||is_hygon()) && _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } static bool supports_lzcnt() { return (_features & CPU_LZCNT) != 0; } static bool supports_sse4a() { return (_features & CPU_SSE4A) != 0; } @@ -870,7 +871,7 @@ } static bool supports_tscinv() { return supports_tscinv_bit() && - ( (is_amd() && !is_amd_Barcelona()) || + ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || is_intel_tsc_synched_at_init() ); } @@ -896,7 +897,7 @@ // Core - 256 / prefetchnta // It will be used only when AllocatePrefetchStyle > 0 - if (is_amd()) { // AMD + if (is_amd() || is_hygon()) { // AMD if (supports_sse2()) { return 256; // Opteron } else { *test I tested it with jtreg and found no regressions. Base Run? ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/hotspot/jtreg:tier1 1396 1396 0 0 >> jtreg:test/jdk:tier1 1867 1866 1 0 << >> jtreg:test/langtools:tier1 3920 3919 1 0 << jtreg:test/nashorn:tier1 0 0 0 0 jtreg:test/jaxp:tier1 0 0 0 0 ============================== TEST FAILURE And The result of after patching is the same as the before. ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/hotspot/jtreg:tier1 1396 1396 0 0 >> jtreg:test/jdk:tier1 1867 1866 1 0 << >> jtreg:test/langtools:tier1 3919 3918 1 0 << jtreg:test/nashorn:tier1 0 0 0 0 jtreg:test/jaxp:tier1 0 0 0 0 ============================== TEST FAILURE result of testcase TestCPUInformation.java ----------System.out:(15/1604)---------- Event: jdk.CPUInformation { startTime = 15:00:29.209 cpu = "Hygon Dhyana (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 SSE4A AMD64" description = "Brand: Hygon Dhyana Eng Sample , Vendor: HygonGenuine Family: Dhyana (0x18), Model: (0x0), Stepping: 0x2 Ext. family: 0x9, Ext. model: 0x0, Type: 0x0, Signature: 0x00900f02 Features: ebx: 0x0f100800, ecx: 0x3cd83209, edx: 0x178bfbff Ext. features: eax: 0x00900f02, ebx: 0x60000000, ecx: 0x35c233ff, edx: 0x2fd3fbff Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, Intel Architecture MMX Technology, Fast Fl oat Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Hyper Threading, Streaming SIMD Extensions 3, MONITOR/MWAIT instructions, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, S treaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, MOVBE, Popcount instruction, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Core multi-processor leagacy mode, Advanced Bit Manipulations: LZCNT, SSE4A: MOVNTSS, MOVNTSD, EXTRQ, INSERTQ, Misaligned SSE mode, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC" sockets = 1 cores = 16 hwThreads = 16 } Is there anything incorrectly? Please let me know your comments. Best Regards! Fanjinke. From matthias.baesken at sap.com Tue Apr 9 07:40:15 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 9 Apr 2019 07:40:15 +0000 Subject: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] Message-ID: Hello, please review this small AIX related cleanup change . When recently looking into the os_perf coding , I noticed that we try to read (on AIX) cpu ticks related data from /proc/stat . However this will most likely fail, on the AIX machines I checked there is a /proc but no /proc/stat . (probably the AIX coding has been taken over from linux) The change cleans up the coding in os_perf_aix.cpp . ( there might be other ways to get the CPU ticks related info on AIX e.g. by using libperfstat or by using what has to offer, see https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.files/proc.htm , but this should be checked and maybe added with another change in case someone is interested ) Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8221915 http://cr.openjdk.java.net/~mbaesken/webrevs/8221915.0/ Thanks, Matthias From jamsheed.c.m at oracle.com Tue Apr 9 07:52:49 2019 From: jamsheed.c.m at oracle.com (Jamsheed) Date: Tue, 9 Apr 2019 13:22:49 +0530 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <933540d0-2e72-fed7-3833-35724324e1e6@arm.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <571f3d72-a22a-3b52-2942-6408072e353f@oracle.com> <144af13e-33e2-2089-f8d2-902e94485eb1@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> <933540d0-2e72-fed7-3833-35724324e1e6@arm.com> Message-ID: <3523c739-f202-7d9b-6bb2-266606a67ab7@oracle.com> Hi Nick, On 08/04/19 4:52 PM, Nick Gasson wrote: > Hi Jamsheed, > > On 05/04/2019 21:11, Jamsheed wrote: >> >> webrev: http://cr.openjdk.java.net/~jcm/8191278/webrev.04/ >> >> test don't pass in aarch64 in any modes in the machine i tested. so >> disabled the test for aarch64. >> > > What failure do you get? I just tried your patch on AArch64 now and it > passes on my system (after removing the @requires line ;-). Thank you for looking at this. i see it passing for all the modes now. not sure , what changed. used to get sigsegv(saying not mapped area) before. could be errors while using hardcoded nos in size. Best regards, Jamsheed > > > Nick > From sgehwolf at redhat.com Tue Apr 9 09:33:31 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 09 Apr 2019 11:33:31 +0200 Subject: [PING?] RFR: 8217338: [Containers] Improve systemd slice memory limit support In-Reply-To: <254f53446176175689373b346c11aabc26d9b4b0.camel@redhat.com> References: <4a1ae4e0e3efd68818bfe868349972aa878de60b.camel@redhat.com> <9a911da4b2a4a8eff42c7c2f1a19c06f6521da8d.camel@redhat.com> <226CB44C-7B3A-42E8-8385-4E85168DBA4E@oracle.com> <254f53446176175689373b346c11aabc26d9b4b0.camel@redhat.com> Message-ID: Hi, Could I get another reviewer for this, please? Bob Vandette already reviewed it. Thank you! Cheers, Severin On Tue, 2019-04-02 at 13:48 +0200, Severin Gehwolf wrote: > Could I get a second review, please? > > Thanks, > Severin > > On Thu, 2019-03-28 at 11:37 -0400, Bob Vandette wrote: > > Sorry for the delay. The update looks good. > > > > Bob. > > > > > > > On Mar 25, 2019, at 1:30 PM, Severin Gehwolf wrote: > > > > > > On Fri, 2019-03-22 at 14:25 -0400, Bob Vandette wrote: > > > > Could you maybe combine subsystem_file_contents with subsystem_file_line_contents > > > > by adding an additional argument? > > > > > > Done: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/05/webrev/ > > > > > > Thanks, > > > Severin > > > From christoph.langer at sap.com Tue Apr 9 09:55:58 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 9 Apr 2019 09:55:58 +0000 Subject: RFR (S): 8221979: Cleanups for building Windows resources Message-ID: Hi, during work on JDK-8221880 I spotted some opportunity for cleanup in Windows resource files and their handling in the build. The naming of variables used for customizing resource properties in the build system should be aligned between hotspot and JDK. This should be carefully reviewed by the build team (Erik). Maybe there are conflicts with some Oracle internal usage of variables... Furthermore some minor stuff: There are some indentation issues in the rc files. src/jdk.accessibility/windows/native/common/AccessBridgeStatusWindow.RC uses RC in capital letters as suffix, which is different to all other .rc files used. Bug: https://bugs.openjdk.java.net/browse/JDK-8221979 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8221979.0/ Thanks Christoph From martin.doerr at sap.com Tue Apr 9 09:56:30 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 9 Apr 2019 09:56:30 +0000 Subject: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: <5CA69196.3000501@oracle.com> References: <2f68463c-be1c-9d34-6202-72613cb7438d@oracle.com> <2c61ef7c-91f0-9636-5567-eaf8bbff7c94@oracle.com> <30b2b3c5-38f7-8569-10cd-e781129b5da5@oracle.com> <5a2f0358-d5e4-2fdc-5791-e6d45f9d5b02@oracle.com> <5CA69196.3000501@oracle.com> Message-ID: Hi everybody, I think it makes sense to have the cupid available on all x86 platforms. However, the current Windows version requires 64 bit because the ABI (calling convention) differs between 32 and 64 bit. The linux version should work on all x86 platforms which support this kind of inline assembler. So I suggest to make it compiler dependent: One version for Visual Studio with implementation for 64 bit and TODO for 32 bit. One version for other compilers which support such kind of inline assembler. Best regards, Martin -----Original Message----- From: hotspot-dev On Behalf Of Erik Gahlin Sent: Freitag, 5. April 2019 01:22 To: hotspot-dev at openjdk.java.net Subject: Re: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 I haven't looked at the code closely., but we definitely want this information in JFR, as a separate RFE of course. Any API that will make it easy to access the information later as char* is appreciated, i.e. EventOSInformation event; event.set_virtualization(Virtualization::name()); event.commit(); Thanks Erik > On 4/04/2019 10:35 pm, Baesken, Matthias wrote: >>> >>> On 4/04/2019 8:54 pm, Baesken, Matthias wrote: >>>>> >>>>> My remaining query is why we need the OS specific checks and code in >>>>> os-cpu files? Isn't this just cpu specific? Even if a particular OS >>>>> doesn't support virtualization, won't the cpuid query simply >>>>> report "no >>>>> virtualization"? >>>>> >>>> >>>> Hi David, if you are referring to these os-cpu files : >>>> >>>> src/hotspot/os_cpu/linux_x86/vm_version_linux_x86.cpp >>>> src/hotspot/os_cpu/windows_x86/vm_version_windows_x86.cpp >>>> >>>> we have different coding available because I am not aware of a >>>> cross OS >>> API/coding to get the cpu id info. >>>> That?s why different coding for LINUX/Windows. >>> >>> ?? But there's nothing in those added functions that is Linux specific >>> or Windows specific! The only difference is the mechanism for doing >>> "inline assembly" and that's compiler specific. So this should just use >>> compiler based ifdefs in vm_version_x86.cpp. >>> >> >> Hi David, I see your point. But I thought we want to reduce the >> ifdefs and favor putting code into the os or os/cpu specific files . >> But it is true , from a technical point we could do using the >> compiler macros . > > I favour putting os-specific code in os-specific files over OS ifdefs > in shared files. But here we are talking about compiler-specific code > that is also CPU specific (not os specific). So compiler ifdefs in the > cpu files is the way to handle this. > > Thanks, > David > >> Best regards, Matthias >> From martin.doerr at sap.com Tue Apr 9 10:22:37 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 9 Apr 2019 10:22:37 +0000 Subject: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] In-Reply-To: References: Message-ID: Hi Matthias, the purpose of this file is only to satisfy the build. JFR is not supported on AIX. I guess almost nothing of this file works. There are more things which could get removed. E.g. get_systemtype, get_jvm_ticks, etc. contain linux stuff. Best regards, Martin -----Original Message----- From: hotspot-dev On Behalf Of Baesken, Matthias Sent: Dienstag, 9. April 2019 09:40 To: 'hotspot-dev at openjdk.java.net' ; ppc-aix-port-dev at openjdk.java.net Cc: Simonis, Volker Subject: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] Hello, please review this small AIX related cleanup change . When recently looking into the os_perf coding , I noticed that we try to read (on AIX) cpu ticks related data from /proc/stat . However this will most likely fail, on the AIX machines I checked there is a /proc but no /proc/stat . (probably the AIX coding has been taken over from linux) The change cleans up the coding in os_perf_aix.cpp . ( there might be other ways to get the CPU ticks related info on AIX e.g. by using libperfstat or by using what has to offer, see https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.files/proc.htm , but this should be checked and maybe added with another change in case someone is interested ) Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8221915 http://cr.openjdk.java.net/~mbaesken/webrevs/8221915.0/ Thanks, Matthias From matthias.baesken at sap.com Tue Apr 9 11:22:35 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 9 Apr 2019 11:22:35 +0000 Subject: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] In-Reply-To: References: Message-ID: > E.g. get_systemtype, get_jvm_ticks, etc. contain linux stuff. Hi Martin, true the functions you mentioned can be removed/reduced as well : http://cr.openjdk.java.net/~mbaesken/webrevs/8221915.1/ Best regards, Matthias > -----Original Message----- > From: Doerr, Martin > Sent: Dienstag, 9. April 2019 12:23 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; ppc-aix-port- > dev at openjdk.java.net > Cc: Simonis, Volker > Subject: RE: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp > [aix] > > Hi Matthias, > > the purpose of this file is only to satisfy the build. JFR is not supported on > AIX. > I guess almost nothing of this file works. There are more things which could > get removed. > E.g. get_systemtype, get_jvm_ticks, etc. contain linux stuff. > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Dienstag, 9. April 2019 09:40 > To: 'hotspot-dev at openjdk.java.net' ; ppc- > aix-port-dev at openjdk.java.net > Cc: Simonis, Volker > Subject: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] > > Hello, please review this small AIX related cleanup change . > > When recently looking into the os_perf coding , I noticed that we try to > read (on AIX) cpu ticks related data from /proc/stat . > However this will most likely fail, on the AIX machines I checked there is a > /proc but no /proc/stat . > > (probably the AIX coding has been taken over from linux) > > The change cleans up the coding in os_perf_aix.cpp . > > ( there might be other ways to get the CPU ticks related info on AIX e.g. by > using libperfstat or by using what > has to offer, see > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm. > aix.files/proc.htm , but this should be checked and maybe added > with another change in case someone is interested ) > > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8221915 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8221915.0/ > > > Thanks, Matthias From Alan.Bateman at oracle.com Tue Apr 9 11:48:26 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 9 Apr 2019 12:48:26 +0100 Subject: RFC: JWarmup precompile java hot methods at application startup In-Reply-To: References: Message-ID: On 09/04/2019 07:10, yumin qi wrote: > > ? Now the registerNatives is found when it looks up for native entry > in lookupNative.cpp. I thought the class JWarmUp will be loaded by > boot loader like Unsafe or WhiteBox, but I was wrong, it is loaded by > app class loader so logic for obtaining its native entry put in both > cases, boot loader and non boot loaders. > make/common/Modules.gmk is where BOOT_MODULES is defined with the list of modules mapped to the boot loader. -Alan From matthias.baesken at sap.com Tue Apr 9 12:07:33 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 9 Apr 2019 12:07:33 +0000 Subject: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 Message-ID: Hi Martin, thanks for your comments. I added a TODO-comment about 32bit, and removed the linux-only ifdef from vm_version_x86.cpp : http://cr.openjdk.java.net/~mbaesken/webrevs/8219241.6/ Best regards, Matthias > > Hi everybody, > > I think it makes sense to have the cpuid available on all x86 platforms. > However, the current Windows version requires 64 bit because the ABI > (calling convention) differs between 32 and 64 bit. > The linux version should work on all x86 platforms which support this kind of > inline assembler. > > So I suggest to make it compiler dependent: > One version for Visual Studio with implementation for 64 bit and TODO for 32 > bit. > One version for other compilers which support such kind of inline assembler. > > Best regards, > Martin > > From matthias.baesken at sap.com Tue Apr 9 12:18:16 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 9 Apr 2019 12:18:16 +0000 Subject: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 Message-ID: Hi Erik , thanks for your comment and your interest in the topic . We already thought about bringing the virtualization info into JFR . Did you notice that we already included some virtualization related info for Linux on Power and Linux s390x ? ( 8219241 is still in review but hopefully soon in jdk/jdk ). ( In our proprietary JVM we have some more virtualization related info , for example AIX PowerVM metrics and VMWare/VSphere (extended) metrics information on Linux/Windows ; Probably some of this might make it over time into the Open JDK too ) Best regards, Matthias > > I haven't looked at the code closely., but we definitely want this > information in JFR, as a separate RFE of course. Any API that will make > it easy to access the information later as char* is appreciated, i.e. > > EventOSInformation event; > event.set_virtualization(Virtualization::name()); > event.commit(); > > Thanks > Erik > From david.holmes at oracle.com Tue Apr 9 12:59:28 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 9 Apr 2019 22:59:28 +1000 Subject: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: References: Message-ID: On 9/04/2019 10:07 pm, Baesken, Matthias wrote: > Hi Martin, thanks for your comments. > I added a TODO-comment about 32bit, and removed the linux-only ifdef from vm_version_x86.cpp : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8219241.6/ I can live with that. :) Thanks, David > Best regards, Matthias > > >> >> Hi everybody, >> >> I think it makes sense to have the cpuid available on all x86 platforms. >> However, the current Windows version requires 64 bit because the ABI >> (calling convention) differs between 32 and 64 bit. >> The linux version should work on all x86 platforms which support this kind of >> inline assembler. >> >> So I suggest to make it compiler dependent: >> One version for Visual Studio with implementation for 64 bit and TODO for 32 >> bit. >> One version for other compilers which support such kind of inline assembler. >> >> Best regards, >> Martin >> >> > From martin.doerr at sap.com Tue Apr 9 13:01:31 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 9 Apr 2019 13:01:31 +0000 Subject: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] In-Reply-To: References: Message-ID: Hi Matthias, looks good and trivial. Thanks, Martin -----Original Message----- From: Baesken, Matthias Sent: Dienstag, 9. April 2019 13:23 To: Doerr, Martin ; 'hotspot-dev at openjdk.java.net' ; ppc-aix-port-dev at openjdk.java.net Subject: RE: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] > E.g. get_systemtype, get_jvm_ticks, etc. contain linux stuff. Hi Martin, true the functions you mentioned can be removed/reduced as well : http://cr.openjdk.java.net/~mbaesken/webrevs/8221915.1/ Best regards, Matthias > -----Original Message----- > From: Doerr, Martin > Sent: Dienstag, 9. April 2019 12:23 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; ppc-aix-port- > dev at openjdk.java.net > Cc: Simonis, Volker > Subject: RE: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp > [aix] > > Hi Matthias, > > the purpose of this file is only to satisfy the build. JFR is not supported on > AIX. > I guess almost nothing of this file works. There are more things which could > get removed. > E.g. get_systemtype, get_jvm_ticks, etc. contain linux stuff. > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Dienstag, 9. April 2019 09:40 > To: 'hotspot-dev at openjdk.java.net' ; ppc- > aix-port-dev at openjdk.java.net > Cc: Simonis, Volker > Subject: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] > > Hello, please review this small AIX related cleanup change . > > When recently looking into the os_perf coding , I noticed that we try to > read (on AIX) cpu ticks related data from /proc/stat . > However this will most likely fail, on the AIX machines I checked there is a > /proc but no /proc/stat . > > (probably the AIX coding has been taken over from linux) > > The change cleans up the coding in os_perf_aix.cpp . > > ( there might be other ways to get the CPU ticks related info on AIX e.g. by > using libperfstat or by using what > has to offer, see > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm. > aix.files/proc.htm , but this should be checked and maybe added > with another change in case someone is interested ) > > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8221915 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8221915.0/ > > > Thanks, Matthias From matthias.baesken at sap.com Tue Apr 9 13:04:22 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 9 Apr 2019 13:04:22 +0000 Subject: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] In-Reply-To: References: Message-ID: Great , thanks for the review Martin ! Do I need a second review or does the "trivial rule" apply ? Btw., is there any interest on ppc-aix-port to get the os_perf related coding working on AIX (e.g. by using libperfstat) ? Best regards, Matthias > -----Original Message----- > From: Doerr, Martin > Sent: Dienstag, 9. April 2019 15:02 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; ppc-aix-port- > dev at openjdk.java.net > Subject: RE: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp > [aix] > > Hi Matthias, > > looks good and trivial. > > Thanks, > Martin > > > -----Original Message----- > From: Baesken, Matthias > Sent: Dienstag, 9. April 2019 13:23 > To: Doerr, Martin ; 'hotspot- > dev at openjdk.java.net' ; ppc-aix-port- > dev at openjdk.java.net > Subject: RE: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp > [aix] > > > > E.g. get_systemtype, get_jvm_ticks, etc. contain linux stuff. > > Hi Martin, true the functions you mentioned can be removed/reduced as > well : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8221915.1/ > > > > Best regards, Matthias > > > > -----Original Message----- > > From: Doerr, Martin > > Sent: Dienstag, 9. April 2019 12:23 > > To: Baesken, Matthias ; 'hotspot- > > dev at openjdk.java.net' ; ppc-aix-port- > > dev at openjdk.java.net > > Cc: Simonis, Volker > > Subject: RE: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp > > [aix] > > > > Hi Matthias, > > > > the purpose of this file is only to satisfy the build. JFR is not supported on > > AIX. > > I guess almost nothing of this file works. There are more things which could > > get removed. > > E.g. get_systemtype, get_jvm_ticks, etc. contain linux stuff. > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: hotspot-dev On Behalf > Of > > Baesken, Matthias > > Sent: Dienstag, 9. April 2019 09:40 > > To: 'hotspot-dev at openjdk.java.net' ; > ppc- > > aix-port-dev at openjdk.java.net > > Cc: Simonis, Volker > > Subject: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] > > > > Hello, please review this small AIX related cleanup change . > > > > When recently looking into the os_perf coding , I noticed that we try to > > read (on AIX) cpu ticks related data from /proc/stat . > > However this will most likely fail, on the AIX machines I checked there is a > > /proc but no /proc/stat . > > > > (probably the AIX coding has been taken over from linux) > > > > The change cleans up the coding in os_perf_aix.cpp . > > > > ( there might be other ways to get the CPU ticks related info on AIX e.g. by > > using libperfstat or by using what > > has to offer, see > > > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm. > > aix.files/proc.htm , but this should be checked and maybe added > > with another change in case someone is interested ) > > > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8221915 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8221915.0/ > > > > > > Thanks, Matthias From erik.joelsson at oracle.com Tue Apr 9 13:22:00 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 9 Apr 2019 06:22:00 -0700 Subject: RFR (S): 8221979: Cleanups for building Windows resources In-Reply-To: References: Message-ID: Hello, Looks ok to me. I assume you have inspected all affected files and made sure all attributes are the same pre and post this change? /Erik On 2019-04-09 02:55, Langer, Christoph wrote: > Hi, > > during work on JDK-8221880 I spotted some opportunity for cleanup in Windows resource files and their handling in the build. > > The naming of variables used for customizing resource properties in the build system should be aligned between hotspot and JDK. This should be carefully reviewed by the build team (Erik). Maybe there are conflicts with some Oracle internal usage of variables... > > Furthermore some minor stuff: > There are some indentation issues in the rc files. > src/jdk.accessibility/windows/native/common/AccessBridgeStatusWindow.RC uses RC in capital letters as suffix, which is different to all other .rc files used. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221979 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8221979.0/ > > Thanks > Christoph > From martin.doerr at sap.com Tue Apr 9 13:30:38 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 9 Apr 2019 13:30:38 +0000 Subject: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: References: Message-ID: Hi Matthias, > I can live with that. :) +1 Assuming __GNUC__ is defined on all x86 platforms we have except Windows. Best regards, Martin -----Original Message----- From: David Holmes Sent: Dienstag, 9. April 2019 14:59 To: Baesken, Matthias ; hotspot-dev at openjdk.java.net; Doerr, Martin Subject: Re: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 On 9/04/2019 10:07 pm, Baesken, Matthias wrote: > Hi Martin, thanks for your comments. > I added a TODO-comment about 32bit, and removed the linux-only ifdef from vm_version_x86.cpp : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8219241.6/ I can live with that. :) Thanks, David > Best regards, Matthias > > >> >> Hi everybody, >> >> I think it makes sense to have the cpuid available on all x86 platforms. >> However, the current Windows version requires 64 bit because the ABI >> (calling convention) differs between 32 and 64 bit. >> The linux version should work on all x86 platforms which support this kind of >> inline assembler. >> >> So I suggest to make it compiler dependent: >> One version for Visual Studio with implementation for 64 bit and TODO for 32 >> bit. >> One version for other compilers which support such kind of inline assembler. >> >> Best regards, >> Martin >> >> > From martin.doerr at sap.com Tue Apr 9 13:45:31 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 9 Apr 2019 13:45:31 +0000 Subject: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] In-Reply-To: References: Message-ID: > Do I need a second review or does the "trivial rule" apply ? You can push it tomorrow if there are no objections. Or if you get a 2nd review. > Btw., is there any interest on ppc-aix-port to get the os_perf related coding working on AIX (e.g. by using libperfstat) ? That's a good hint. We already have libperfstat which may be helpful for a useful implementation of os_perf_aix. Best regards, Martin -----Original Message----- From: Baesken, Matthias Sent: Dienstag, 9. April 2019 15:04 To: Doerr, Martin ; 'hotspot-dev at openjdk.java.net' ; ppc-aix-port-dev at openjdk.java.net Subject: RE: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] Great , thanks for the review Martin ! Do I need a second review or does the "trivial rule" apply ? Btw., is there any interest on ppc-aix-port to get the os_perf related coding working on AIX (e.g. by using libperfstat) ? Best regards, Matthias > -----Original Message----- > From: Doerr, Martin > Sent: Dienstag, 9. April 2019 15:02 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; ppc-aix-port- > dev at openjdk.java.net > Subject: RE: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp > [aix] > > Hi Matthias, > > looks good and trivial. > > Thanks, > Martin > > > -----Original Message----- > From: Baesken, Matthias > Sent: Dienstag, 9. April 2019 13:23 > To: Doerr, Martin ; 'hotspot- > dev at openjdk.java.net' ; ppc-aix-port- > dev at openjdk.java.net > Subject: RE: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp > [aix] > > > > E.g. get_systemtype, get_jvm_ticks, etc. contain linux stuff. > > Hi Martin, true the functions you mentioned can be removed/reduced as > well : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8221915.1/ > > > > Best regards, Matthias > > > > -----Original Message----- > > From: Doerr, Martin > > Sent: Dienstag, 9. April 2019 12:23 > > To: Baesken, Matthias ; 'hotspot- > > dev at openjdk.java.net' ; ppc-aix-port- > > dev at openjdk.java.net > > Cc: Simonis, Volker > > Subject: RE: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp > > [aix] > > > > Hi Matthias, > > > > the purpose of this file is only to satisfy the build. JFR is not supported on > > AIX. > > I guess almost nothing of this file works. There are more things which could > > get removed. > > E.g. get_systemtype, get_jvm_ticks, etc. contain linux stuff. > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: hotspot-dev On Behalf > Of > > Baesken, Matthias > > Sent: Dienstag, 9. April 2019 09:40 > > To: 'hotspot-dev at openjdk.java.net' ; > ppc- > > aix-port-dev at openjdk.java.net > > Cc: Simonis, Volker > > Subject: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] > > > > Hello, please review this small AIX related cleanup change . > > > > When recently looking into the os_perf coding , I noticed that we try to > > read (on AIX) cpu ticks related data from /proc/stat . > > However this will most likely fail, on the AIX machines I checked there is a > > /proc but no /proc/stat . > > > > (probably the AIX coding has been taken over from linux) > > > > The change cleans up the coding in os_perf_aix.cpp . > > > > ( there might be other ways to get the CPU ticks related info on AIX e.g. by > > using libperfstat or by using what > > has to offer, see > > > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm. > > aix.files/proc.htm , but this should be checked and maybe added > > with another change in case someone is interested ) > > > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8221915 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8221915.0/ > > > > > > Thanks, Matthias From erik.joelsson at oracle.com Tue Apr 9 13:55:15 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 9 Apr 2019 06:55:15 -0700 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <15601B10-9498-4A76-A4FC-3718B2B5132D@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> <69018b42-7540-9222-a296-db28b99cdf91@oracle.com> <79a6f9dd-7f20-649c-a6c4-e6cf8f098130@oracle.com> <9c841ef7-4190-f5f8-fcfd-291c178a264d@oracle.com> <961ce204-40c9-9de9-8069-5f362497525a@oracle.com> <927E24E0-BD59-42C1-8FF9-957EF0E6D55E@oracle.com> <9513296d-6e0f-6e41-517d-9253f9ea13f6@oracle.com> <76DD7E45-E193-4F82-AE84-D58451863537@oracle.com> <750be466-6342-dc7d-efaf-9c68259b1252@oracle.com> Message-ID: Hello, Here is a new webrev with an even simpler change: http://cr.openjdk.java.net/~erikj/8221851/webrev.06/ I decided to just remove the usage of THIS_FILE from exceptions.hpp since it did not work well. It currently does not work at all on Windows or Macosx builds. On Linux it invalidates the precompiled header, which is the main issue I'm trying to fix. As for the truncation issue, with the patch above, truncation will again happen on Solaris and Linux if compiled with GCC <8. However, as Thomas pointed out, there is already a review out for fixing the truncation problems for real. The reason I tried to pursue finding a solution with shortening of the __FILE__ path was that I thought it would be beneficial in more locations, but it now seems like more trouble than it's worth and not actually a feature anyone seem to want. I do not want to spend more time one this, I just want the precompiled header to start working again. Yes, this regresses the truncation issue somewhat, but I do not think a broken solution should be left in there. /Erik On 2019-04-08 15:27, David Holmes wrote: > Hi Erik, > > On 9/04/2019 8:08 am, Erik Joelsson wrote: >> New webrev with "_simple_basename": >> http://cr.openjdk.java.net/~erikj/8221851/webrev.05/ > > Given the usage is typically of the form: > > ?Exceptions::_throw(THREAD_AND_LOCATION, e); > > which will expand to: > > ?Exceptions::_throw(THREAD, _simple_basename(__FILE__), __LINE__, e); > > what does the compiler actually generate for this at the call sites? > I'm struggling with the addition of an inline function to a .hpp which > we generally frown upon and have been working to remove. > > What affect does this have on code size? > > Thanks, > David > ----- > >> /Erik >> >> On 2019-04-08 12:20, Erik Joelsson wrote: >>> On 2019-04-08 11:40, Kim Barrett wrote: >>>>> On Apr 8, 2019, at 10:28 AM, Erik Joelsson >>>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> On 2019-04-05 15:46, Kim Barrett wrote: >>>>>> Assuming all that, consider instead putting this_file_helper in >>>>>> exceptions.hpp (perhaps with a better name?), don't bother with >>>>>> THIS_FILE, and define THREAD_AND_LOCATION as >>>>>> >>>>>> #define THREAD_AND_LOCATION THREAD, this_file_helper(__FILE__), >>>>>> __LINE__ >>>>>> >>>>> Moved to exceptions.hpp, renamed to "basename", and removed the >>>>> THIS_FILE macro. >>>> ?basename? might not count as a ?better name?, as it conflicts with >>>> a POSIX function, >>>> even though we don?t presently seem to be using that anywhere that >>>> I could find. >>>> >>>> >>> How about "simple_basename" then? Or just prefix with an underscore? >>> The idea is to keep it internal to the headerfile, but I'm not >>> familiar with conventions in Hotspot to know how you usually >>> prefix/namespace things as private. >>> >>> /Erik >>> From coleen.phillimore at oracle.com Tue Apr 9 14:29:32 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 9 Apr 2019 10:29:32 -0400 Subject: RFR: 8221393: ResolvedMethodTable too small for StackWalking applications In-Reply-To: <91b768e6-5938-a2be-2f81-e5237ed13a25@oracle.com> References: <91b768e6-5938-a2be-2f81-e5237ed13a25@oracle.com> Message-ID: http://cr.openjdk.java.net/~stefank/8221393/webrev.01/src/hotspot/share/classfile/javaClasses.cpp.udiff.html + if (method->is_old()) { + // Replace method with redefined version + + method = holder->method_with_idnum(method->method_idnum()); + if (method == NULL) { + // Replace deleted method with NSME. + method = Universe::throw_no_such_method_error(); + } + } This code that came from resolvedMethodTable.cpp was just changed with https://bugs.openjdk.java.net/browse/JDK-8221992.? Can you use the new code here. But make sure this holder is the one of the new method selected: + holder->set_has_resolved_methods(); http://cr.openjdk.java.net/~stefank/8221393/webrev.01/test/hotspot/jtreg/runtime/testlibrary/ClassWithManyMethodsClassLoader.java.html 2 * Copyright (c) 2013, 2018, Oracle and/or its affiliates. All rights reserved. Copyright is wrong.?? Looks like a good utility class we can use. The rest looks great! On 4/5/19 8:24 AM, Stefan Karlsson wrote: > Hi all, > > Please review this patch to replace the hashtable in > ResolvedMethodTable, with the ConcurrentHashTable (currently used by > the StringTable and SymbolTable). > > http://cr.openjdk.java.net/~stefank/8221393/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8221393 > > This solves at least two scalability problems with the > ResolvedMethodTable: > > 1) The old table had a fixed, small size that could cause the table to > be overpopulated when StackWalking APIs were used. See the bug report. > The new table automatically grows when it gets filled up. > > 2) The old table used locks for inserts, lookups, and cleanups. This > could cause large performance degradations when multiple threads used > the StackWalking APIs, or resolved MethodHandle constants. The new > table uses lock-free inserts and lookups, and thereby scales much better. > > A stack walking micro benchmark (not yet pushed) shows this. > > Running with 8 threads, on my 16 core machine: > java -XX:+UseG1GC -Xmx1g -Xms1g -jar benchmarks.jar -wi 0 -i 5 -p > depth=4 -t 8 StackWalkBench.swClassNamesDefaultOpts > > Baseline: avgt 25 91777.142 ? 2760.507? ns/op > Change:?? avgt 25? 8149.368 ? 212.863?? ns/op > > Note that a lot of the code to use the ConcurrentHashTable is copied > from the StringTable and/or SymbolTable. There are unifications, and > maybe simplifications that we can do as follow-up RFEs. > I agree.? I'll file some RFEs unless you do it. > There's an open question regarding the verification code in > ResolvedMethodTable::finish_dead_counter(). It's a quadratic > verification operation, and has the potential to take a long time. I > left it in for testing, but I don't think we should have it always > enabled. For the StringTable we have VerifyStringTableAtExit, to do > verification before the JVM shuts down. Any suggestions on what to do > for the ResolvedMethodTable? > For the most part, RMT is pretty small unless stackwalk API is used.? I would take the verification out of GC, since we don't verify string table that way.? Since VerifyStringTableAtExit is diagnostic, we could remove it and make it VerifyConcurrentHashtablesAtExit.? I'm not sure how useful it is here.? Maybe we could VerifyConcurrentHashtables at full GCs instead? Thank you for making this change! Coleen > Tested with tier1-3, tier1-7 on Linux. > > Thanks, > StefanK From coleen.phillimore at oracle.com Tue Apr 9 15:11:28 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 9 Apr 2019 11:11:28 -0400 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> <69018b42-7540-9222-a296-db28b99cdf91@oracle.com> <79a6f9dd-7f20-649c-a6c4-e6cf8f098130@oracle.com> <9c841ef7-4190-f5f8-fcfd-291c178a264d@oracle.com> <961ce204-40c9-9de9-8069-5f362497525a@oracle.com> <927E24E0-BD59-42C1-8FF9-957EF0E6D55E@oracle.com> <9513296d-6e0f-6e41-517d-9253f9ea13f6@oracle.com> <76DD7E45-E193-4F82-AE84-D58451863537@oracle.com> <750be466-6342-dc7d-efaf-9c68259b1252@oracle.com> Message-ID: On 4/9/19 9:55 AM, Erik Joelsson wrote: > Hello, > > Here is a new webrev with an even simpler change: > > http://cr.openjdk.java.net/~erikj/8221851/webrev.06/ > > I decided to just remove the usage of THIS_FILE from exceptions.hpp > since it did not work well. It currently does not work at all on > Windows or Macosx builds. On Linux it invalidates the precompiled > header, which is the main issue I'm trying to fix. > > As for the truncation issue, with the patch above, truncation will > again happen on Solaris and Linux if compiled with GCC <8. However, as > Thomas pointed out, there is already a review out for fixing the > truncation problems for real. > > The reason I tried to pursue finding a solution with shortening of the > __FILE__ path was that I thought it would be beneficial in more > locations, but it now seems like more trouble than it's worth and not > actually a feature anyone seem to want. I do not want to spend more > time one this, I just want the precompiled header to start working > again. Yes, this regresses the truncation issue somewhat, but I do not > think a broken solution should be left in there. I reviewed the original change and it's too bad we have to have full pathnames in the log messages, but this seems to be for the best. Thanks, Coleen > > /Erik > > On 2019-04-08 15:27, David Holmes wrote: >> Hi Erik, >> >> On 9/04/2019 8:08 am, Erik Joelsson wrote: >>> New webrev with "_simple_basename": >>> http://cr.openjdk.java.net/~erikj/8221851/webrev.05/ >> >> Given the usage is typically of the form: >> >> ?Exceptions::_throw(THREAD_AND_LOCATION, e); >> >> which will expand to: >> >> ?Exceptions::_throw(THREAD, _simple_basename(__FILE__), __LINE__, e); >> >> what does the compiler actually generate for this at the call sites? >> I'm struggling with the addition of an inline function to a .hpp >> which we generally frown upon and have been working to remove. >> >> What affect does this have on code size? >> >> Thanks, >> David >> ----- >> >>> /Erik >>> >>> On 2019-04-08 12:20, Erik Joelsson wrote: >>>> On 2019-04-08 11:40, Kim Barrett wrote: >>>>>> On Apr 8, 2019, at 10:28 AM, Erik Joelsson >>>>>> wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> On 2019-04-05 15:46, Kim Barrett wrote: >>>>>>> Assuming all that, consider instead putting this_file_helper in >>>>>>> exceptions.hpp (perhaps with a better name?), don't bother with >>>>>>> THIS_FILE, and define THREAD_AND_LOCATION as >>>>>>> >>>>>>> #define THREAD_AND_LOCATION THREAD, this_file_helper(__FILE__), >>>>>>> __LINE__ >>>>>>> >>>>>> Moved to exceptions.hpp, renamed to "basename", and removed the >>>>>> THIS_FILE macro. >>>>> ?basename? might not count as a ?better name?, as it conflicts >>>>> with a POSIX function, >>>>> even though we don?t presently seem to be using that anywhere that >>>>> I could find. >>>>> >>>>> >>>> How about "simple_basename" then? Or just prefix with an >>>> underscore? The idea is to keep it internal to the headerfile, but >>>> I'm not familiar with conventions in Hotspot to know how you >>>> usually prefix/namespace things as private. >>>> >>>> /Erik >>>> From yumin.qi at gmail.com Tue Apr 9 17:36:57 2019 From: yumin.qi at gmail.com (yumin qi) Date: Tue, 9 Apr 2019 10:36:57 -0700 Subject: RFC: JWarmup precompile java hot methods at application startup In-Reply-To: References: Message-ID: Alan, Thanks! Updated in same link: http://cr.openjdk.java.net/~minqi/8220692/webrev-02/ Removed non-boot loader branch in nativeLookup.cpp. Added jdk.jwarmup to boot loader list in make/common/Modules.gmk. Tested again to make sure the new changes. Thanks Yumin On Tue, Apr 9, 2019 at 4:48 AM Alan Bateman wrote: > On 09/04/2019 07:10, yumin qi wrote: > > > > Now the registerNatives is found when it looks up for native entry > > in lookupNative.cpp. I thought the class JWarmUp will be loaded by > > boot loader like Unsafe or WhiteBox, but I was wrong, it is loaded by > > app class loader so logic for obtaining its native entry put in both > > cases, boot loader and non boot loaders. > > > make/common/Modules.gmk is where BOOT_MODULES is defined with the list > of modules mapped to the boot loader. > > -Alan > From jamsheed.c.m at oracle.com Tue Apr 9 18:13:54 2019 From: jamsheed.c.m at oracle.com (Jamsheed) Date: Tue, 9 Apr 2019 23:43:54 +0530 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <3523c739-f202-7d9b-6bb2-266606a67ab7@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <571f3d72-a22a-3b52-2942-6408072e353f@oracle.com> <144af13e-33e2-2089-f8d2-902e94485eb1@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> <933540d0-2e72-fed7-3833-35724324e1e6@arm.com> <3523c739-f202-7d9b-6bb2-266606a67ab7@oracle.com> Message-ID: Hi Nick, i could reproduce the sigsegv. was using slowdebug bits today morning, and so it didn't fail. code [1] is reason for the failure. Best regards, Jamsheed [1] ? void _Copy_conjoint_jlongs_atomic(jlong* from, jlong* to, size_t count) { ??? if (from > to) { ????? jlong *end = from + count; ????? while (from < end) ??????? os::atomic_copy64(from++, to++); ??? } ??? else if (from < to) { ????? jlong *end = from; ????? from += count - 1; ????? to?? += count - 1; ????? while (from >= end) ??????? os::atomic_copy64(from--, to--); ??? } ? } ? static void atomic_copy64(const volatile void *src, volatile void *dst) { ????? *(jlong *) dst = *(const jlong *) src; ?? } On 09/04/19 1:22 PM, Jamsheed wrote: > Hi Nick, > > On 08/04/19 4:52 PM, Nick Gasson wrote: >> Hi Jamsheed, >> >> On 05/04/2019 21:11, Jamsheed wrote: >>> >>> webrev: http://cr.openjdk.java.net/~jcm/8191278/webrev.04/ >>> >>> test don't pass in aarch64 in any modes in the machine i tested. so >>> disabled the test for aarch64. >>> >> >> What failure do you get? I just tried your patch on AArch64 now and >> it passes on my system (after removing the @requires line ;-). > Thank you for looking at this. > > i see it passing for all the modes now. not sure , what changed. > > used to get sigsegv(saying not mapped area) before. could be errors > while using hardcoded nos in size. > > Best regards, > > Jamsheed > >> >> >> Nick >> From coleen.phillimore at oracle.com Tue Apr 9 20:00:32 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 9 Apr 2019 16:00:32 -0400 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: <3514c74d-5f6a-61cc-ebea-b9564df61673@oracle.com> References: <4b759550-f185-724f-7139-9bab648a1966@oracle.com> <119335f1-acb7-fffc-f38a-e50a96b73b3c@oracle.com> <2d206374-cfeb-9b1b-2838-e4e0a774e89d@oracle.com> <8063fb37-f1b0-8b93-bbe8-4dbeeaa54959@oracle.com> <17233985-18c7-305e-5556-fe2b38926b71@oracle.com> <3514c74d-5f6a-61cc-ebea-b9564df61673@oracle.com> Message-ID: http://cr.openjdk.java.net/~kvn/8220623/webrev.06/src/hotspot/share/classfile/classFileParser.cpp.udiff.html It appears this change is to implement https://bugs.openjdk.java.net/browse/JDK-8193513 which we closed as WNF.? If you want this change, remove it from this giant patch and reopen and submit a separate patch for this bug. It shouldn't be conditional on JVMCI and should use the normal unified logging mechanism. http://cr.openjdk.java.net/~kvn/8220623/webrev.06/src/hotspot/share/runtime/thread.hpp.udiff.html *!_jlong__pending_failed_speculation;* We've been trying to remove and avoid java types in hotspot code and use the appropriate C++ types instead.? Can this be changed to int64_t?? 'long' is generally wrong though. I seem to remember there was code to deal with metadata in oops for redefinition, but I can't find it in this big patch.? I was going to look at that. Otherwise, I've reviewed the runtime code. Coleen On 4/4/19 3:22 AM, Vladimir Kozlov wrote: > New delta: > http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.06/ > > Full: > http://cr.openjdk.java.net/~kvn/8220623/webrev.06/ > > New changes are based on Kim and Stefan suggestions: > > - Moved JVMCI::oops_do() from JNIHandles to places where it should be > called. > - Moved JVMCI cleanup task to the beginning of > ParallelCleaningTask::work(). > - Used JVMCI_ONLY macro with COMMA. > - Disable JVMCI build on SPARC. We don't use it - neither Graal or AOT > are built on SPARC. Disabling also helps to find missing JVMCI guards. > > I ran hs-tier1-3 testing - it passed (hs-tier3 includes graal testing). > I started hs-tier4..8-graal testing. > I will do performance testing next. > > Thanks, > Vladimir > > On 4/3/19 9:54 AM, Vladimir Kozlov wrote: >> On 4/2/19 11:35 PM, Stefan Karlsson wrote: >>> On 2019-04-02 22:41, Vladimir Kozlov wrote: >>>> I ran Kitchensink with G1 and -Xmx8g. I observed that Remark pause >>>> times are not consistent even without Graal. >>>> To see effect I added time spent in JVMCI::do_unloading() to GC log >>>> (see below [3]). The result is < 1ms - it is less than 1% of a >>>> pause time. >>> >>> Kitchensink isn't really a benchmark, but a stress test. I sent you >>> a private mail how to run these changes through our internal >>> performance test setup. >> >> Okay, I will run performance tests there too. >> >>> >>>> >>>> It will have even less effect since I moved JVMCI::do_unloading() >>>> from serial path to parallel worker thread as Stefan suggested. >>>> >>>> Stefan, are you satisfied with these changes now? >>> >>> Yes, the clean-ups look good. Thanks for cleaning this up. >>> >>> Kim had some extra comments about a few more places where JVMCI_ONLY >>> could be used. >>> >>> I also agree with him that JVMCI::oops_do should not be placed in >>> JNIHandles::oops_do. I think you should put it where you put the >>> AOTLoader::oops_do calls. >> >> Okay. >> >> Thanks, >> Vladimir >> >>> >>> Thanks, >>> StefanK >>> >>> >>>> >>>> Here is latest delta update which includes previous [1] delta and >>>> - use CompilerThreadStackSize * 2 for libgraal instead of exact value, >>>> - removed HandleMark added for debugging (reverted changes in >>>> jvmtiImpl.cpp), >>>> - added recent jvmci-8 changes to fix registration of native >>>> methods in libgraal (jvmciCompilerToVM.cpp) >>>> >>>> http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.05/ >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> [1] http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.04/ >>>> [2] Original webrev http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ >>>> [3] Pauses times from Kitchensink (0.0ms means there were no >>>> unloaded classes, 'NNN alive' shows how many metadata references >>>> were processed): >>>> >>>> [1.083s][1554229160638ms][info ][gc,start???? ] GC(2) Pause Remark >>>> [1.085s][1554229160639ms][info ][gc?????????? ] GC(2) >>>> JVMCI::do_unloading(): 0 alive 0.000ms >>>> [1.099s][1554229160654ms][info ][gc?????????? ] GC(2) Pause Remark >>>> 28M->28M(108M) 16.123ms >>>> >>>> [3.097s][1554229162651ms][info ][gc,start???? ] GC(12) Pause Remark >>>> [3.114s][1554229162668ms][info ][gc?????????? ] GC(12) >>>> JVMCI::do_unloading(): 3471 alive 0.164ms >>>> [3.148s][1554229162702ms][info ][gc?????????? ] GC(12) Pause Remark >>>> 215M->213M(720M) 51.103ms >>>> >>>> [455.111s][1554229614666ms][info ][gc,phases,start] GC(1095) Phase >>>> 1: Mark live objects >>>> [455.455s][1554229615010ms][info ][gc???????????? ] GC(1095) >>>> JVMCI::do_unloading(): 4048 alive 0.821ms >>>> [455.456s][1554229615010ms][info ][gc,phases????? ] GC(1095) Phase >>>> 1: Mark live objects 344.107ms >>>> >>>> [848.932s][1554230008486ms][info ][gc,phases,start] GC(1860) Phase >>>> 1: Mark live objects >>>> [849.248s][1554230008803ms][info ][gc???????????? ] GC(1860) >>>> JVMCI::do_unloading(): 3266 alive 0.470ms >>>> [849.249s][1554230008803ms][info ][gc,phases????? ] GC(1860) Phase >>>> 1: Mark live objects 316.527ms >>>> >>>> [1163.778s][1554230323332ms][info ][gc,start?????? ] GC(2627) Pause >>>> Remark >>>> [1163.932s][1554230323486ms][info ][gc???????????? ] GC(2627) >>>> JVMCI::do_unloading(): 3474 alive 0.642ms >>>> [1163.941s][1554230323496ms][info ][gc???????????? ] GC(2627) Pause >>>> Remark 2502M->2486M(4248M) 163.296ms >>>> >>>> [1242.587s][1554230402141ms][info ][gc,phases,start] GC(2734) Phase >>>> 1: Mark live objects >>>> [1242.899s][1554230402453ms][info ][gc???????????? ] GC(2734) >>>> JVMCI::do_unloading(): 3449 alive 0.570ms >>>> [1242.899s][1554230402453ms][info ][gc,phases????? ] GC(2734) Phase >>>> 1: Mark live objects 311.719ms >>>> >>>> [1364.164s][1554230523718ms][info ][gc,phases,start] GC(3023) Phase >>>> 1: Mark live objects >>>> [1364.613s][1554230524167ms][info ][gc???????????? ] GC(3023) >>>> JVMCI::do_unloading(): 3449 alive 0.000ms >>>> [1364.613s][1554230524167ms][info ][gc,phases????? ] GC(3023) Phase >>>> 1: Mark live objects 448.495ms >>>> >>>> [1425.222s][1554230584776ms][info ][gc,phases,start] GC(3151) Phase >>>> 1: Mark live objects >>>> [1425.587s][1554230585142ms][info ][gc???????????? ] GC(3151) >>>> JVMCI::do_unloading(): 3491 alive 0.882ms >>>> [1425.587s][1554230585142ms][info ][gc,phases????? ] GC(3151) Phase >>>> 1: Mark live objects 365.403ms >>>> >>>> [1456.401s][1554230615955ms][info ][gc,phases,start] GC(3223) Phase >>>> 1: Mark live objects >>>> [1456.769s][1554230616324ms][info ][gc???????????? ] GC(3223) >>>> JVMCI::do_unloading(): 3478 alive 0.616ms >>>> [1456.769s][1554230616324ms][info ][gc,phases????? ] GC(3223) Phase >>>> 1: Mark live objects 368.643ms >>>> >>>> [1806.139s][1554230965694ms][info?? ][gc,start?????? ] GC(4014) >>>> Pause Remark >>>> [1806.161s][1554230965716ms][info?? ][gc???????????? ] GC(4014) >>>> JVMCI::do_unloading(): 3478 alive 0.000ms >>>> [1806.163s][1554230965717ms][info?? ][gc???????????? ] GC(4014) >>>> Pause Remark 1305M->1177M(2772M) 23.190ms >>>> >>>> >>>> >>>> On 4/1/19 12:34 AM, Stefan Karlsson wrote: >>>>> On 2019-03-29 17:55, Vladimir Kozlov wrote: >>>>>> Stefan, >>>>>> >>>>>> Do you have a test (and flags) which can allow me to measure >>>>>> effect of this code on G1 remark pause? >>>>> >>>>> >>>>> -Xlog:gc prints the remark times: >>>>> [4,296s][info][gc?????? ] GC(89) Pause Remark 4M->4M(28M) 36,412ms >>>>> >>>>> StefanK >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 3/29/19 12:36 AM, Stefan Karlsson wrote: >>>>>>> On 2019-03-29 03:07, Vladimir Kozlov wrote: >>>>>>>> Hi Stefan, >>>>>>>> >>>>>>>> I collected some data on MetadataHandleBlock. >>>>>>>> >>>>>>>> First, do_unloading() code is executed only when >>>>>>>> class_unloading_occurred is 'true' - it is rare case. It should >>>>>>>> not affect normal G1 remark pause. >>>>>>> >>>>>>> It's only rare for applications that don't do dynamic class >>>>>>> loading and unloading. The applications that do, will be affected. >>>>>>> >>>>>>>> >>>>>>>> Second, I run a test with -Xcomp. I got about 10,000 >>>>>>>> compilations by Graal and next data at the end of execution: >>>>>>>> >>>>>>>> max_blocks = 232 >>>>>>>> max_handles_per_block = 32 (since handles array has 32 elements) >>>>>>>> max_total_alive_values = 4631 >>>>>>> >>>>>>> OK. Thanks for the info. >>>>>>> >>>>>>> StefanK >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 3/28/19 2:44 PM, Vladimir Kozlov wrote: >>>>>>>>> Thank you, Stefan >>>>>>>>> >>>>>>>>> On 3/28/19 12:54 PM, Stefan Karlsson wrote: >>>>>>>>>> Hi Vladimir, >>>>>>>>>> >>>>>>>>>> I started to check the GC code. >>>>>>>>>> >>>>>>>>>> ======================================================================== >>>>>>>>>> >>>>>>>>>> I see that you've added guarded includes in the middle of the >>>>>>>>>> include list: >>>>>>>>>> ?? #include "gc/shared/strongRootsScope.hpp" >>>>>>>>>> ?? #include "gc/shared/weakProcessor.hpp" >>>>>>>>>> + #if INCLUDE_JVMCI >>>>>>>>>> + #include "jvmci/jvmci.hpp" >>>>>>>>>> + #endif >>>>>>>>>> ?? #include "oops/instanceRefKlass.hpp" >>>>>>>>>> ?? #include "oops/oop.inline.hpp" >>>>>>>>>> >>>>>>>>>> The style we use is to put these conditional includes at the >>>>>>>>>> end of the include lists. >>>>>>>>> >>>>>>>>> okay >>>>>>>>> >>>>>>>>>> >>>>>>>>>> ======================================================================== >>>>>>>>>> >>>>>>>>>> Could you also change the following: >>>>>>>>>> >>>>>>>>>> + #if INCLUDE_JVMCI >>>>>>>>>> +???? // Clean JVMCI metadata handles. >>>>>>>>>> +???? JVMCI::do_unloading(is_alive_closure(), purged_class); >>>>>>>>>> + #endif >>>>>>>>>> >>>>>>>>>> to: >>>>>>>>>> +???? // Clean JVMCI metadata handles. >>>>>>>>>> + JVMCI_ONLY(JVMCI::do_unloading(is_alive_closure(), >>>>>>>>>> purged_class);) >>>>>>>>>> >>>>>>>>>> to get rid of some of the line noise in the GC files. >>>>>>>>> >>>>>>>>> okay >>>>>>>>> >>>>>>>>>> >>>>>>>>>> ======================================================================== >>>>>>>>>> >>>>>>>>>> In the future we will need version of JVMCI::do_unloading >>>>>>>>>> that supports concurrent cleaning for ZGC. >>>>>>>>> >>>>>>>>> Yes, we need to support concurrent cleaning in a future. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> ======================================================================== >>>>>>>>>> >>>>>>>>>> What's the performance impact for G1 remark pause with this >>>>>>>>>> serial walk over the MetadataHandleBlock? >>>>>>>>>> >>>>>>>>>> 3275 void >>>>>>>>>> G1CollectedHeap::complete_cleaning(BoolObjectClosure* is_alive, >>>>>>>>>> 3276 bool class_unloading_occurred) { >>>>>>>>>> 3277?? uint num_workers = workers()->active_workers(); >>>>>>>>>> 3278?? ParallelCleaningTask unlink_task(is_alive, >>>>>>>>>> num_workers, class_unloading_occurred, false); >>>>>>>>>> 3279?? workers()->run_task(&unlink_task); >>>>>>>>>> 3280 #if INCLUDE_JVMCI >>>>>>>>>> 3281?? // No parallel processing of JVMCI metadata handles >>>>>>>>>> for now. >>>>>>>>>> 3282?? JVMCI::do_unloading(is_alive, class_unloading_occurred); >>>>>>>>>> 3283 #endif >>>>>>>>>> 3284 } >>>>>>>>> >>>>>>>>> There should not be impact if Graal is not used. Only cost of >>>>>>>>> call (which most likely is inlined in product VM) and check: >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/metropolis/dev/file/530fc1427d02/src/hotspot/share/jvmci/jvmciRuntime.cpp#l1237 >>>>>>>>> >>>>>>>>> >>>>>>>>> If Graal is used it should not have big impact since these >>>>>>>>> metadata has regular pattern (32 handles per array and array >>>>>>>>> per MetadataHandleBlock block which are linked in list) and >>>>>>>>> not large. >>>>>>>>> If there will be noticeable impact - we will work on it as you >>>>>>>>> suggested by using ParallelCleaningTask. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> ======================================================================== >>>>>>>>>> >>>>>>>>>> Did you consider adding it as a task for one of the worker >>>>>>>>>> threads to execute in ParallelCleaningTask? >>>>>>>>>> >>>>>>>>>> See how other tasks are claimed by one worker: >>>>>>>>>> void KlassCleaningTask::work() { >>>>>>>>>> ?? ResourceMark rm; >>>>>>>>>> >>>>>>>>>> ?? // One worker will clean the subklass/sibling klass tree. >>>>>>>>>> ?? if (claim_clean_klass_tree_task()) { >>>>>>>>>> ???? Klass::clean_subklass_tree(); >>>>>>>>>> ?? } >>>>>>>>> >>>>>>>>> These changes were ported from JDK8u based changes in >>>>>>>>> graal-jvmci-8 and there are no ParallelCleaningTask in JDK8. >>>>>>>>> >>>>>>>>> Your suggestion is interesting and I agree that we should >>>>>>>>> investigate it. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> ======================================================================== >>>>>>>>>> >>>>>>>>>> In MetadataHandleBlock::do_unloading: >>>>>>>>>> >>>>>>>>>> +??????? if (klass->class_loader_data()->is_unloading()) { >>>>>>>>>> +????????? // This needs to be marked so that it's no longer >>>>>>>>>> scanned >>>>>>>>>> +????????? // but can't be put on the free list yet. The >>>>>>>>>> +????????? // ReferenceCleaner will set this to NULL and >>>>>>>>>> +????????? // put it on the free list. >>>>>>>>>> >>>>>>>>>> I couldn't find the ReferenceCleaner in the patch or in the >>>>>>>>>> source. Where can I find this code? >>>>>>>>> >>>>>>>>> I think it is typo (I will fix it) - it references new >>>>>>>>> HandleCleaner class: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HandleCleaner.java.html >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> StefanK >>>>>>>>>> >>>>>>>>>> On 2019-03-28 20:15, Vladimir Kozlov wrote: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8220623 >>>>>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ >>>>>>>>>>> >>>>>>>>>>> Update JVMCI to support pre-compiled as shared library Graal. >>>>>>>>>>> Using aoted Graal can offers benefits including: >>>>>>>>>>> ?- fast startup >>>>>>>>>>> ?- compile time similar to native JIt compilers (C2) >>>>>>>>>>> ?- memory usage disjoint from the application Java heap >>>>>>>>>>> ?- no profile pollution of JDK code used by the application >>>>>>>>>>> >>>>>>>>>>> This is JDK13 port of JVMCI changes done in graal-jvmci-8 >>>>>>>>>>> [1] up to date. >>>>>>>>>>> Changes were collected in Metropolis repo [2] and tested there. >>>>>>>>>>> >>>>>>>>>>> Changes we reviewed by Oracle Labs (authors of JVMCI and >>>>>>>>>>> Graal) and our compiler group. >>>>>>>>>>> Changes in shared code are guarded by #if INCLUDE_JVMCI and >>>>>>>>>>> JVMCI flags. >>>>>>>>>>> >>>>>>>>>>> I ran tier1-tier8 (which includes HotSpot and JDK tests) and >>>>>>>>>>> it was clean. In this set Graal was tested only in tier3. >>>>>>>>>>> >>>>>>>>>>> And I ran all hs-tier3-graal .. hs-tier8-graal Graal tests >>>>>>>>>>> available in our system. Several issue were found which were >>>>>>>>>>> present before these changes. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> [1] >>>>>>>>>>> https://github.com/graalvm/graal-jvmci-8/commit/49ff2045fb603e35516a3a427d8023c00e1607af >>>>>>>>>>> [2] http://hg.openjdk.java.net/metropolis/dev/ >>>>>>>>>> From coleen.phillimore at oracle.com Tue Apr 9 20:36:28 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 9 Apr 2019 16:36:28 -0400 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: References: <4b759550-f185-724f-7139-9bab648a1966@oracle.com> <119335f1-acb7-fffc-f38a-e50a96b73b3c@oracle.com> <2d206374-cfeb-9b1b-2838-e4e0a774e89d@oracle.com> <8063fb37-f1b0-8b93-bbe8-4dbeeaa54959@oracle.com> <17233985-18c7-305e-5556-fe2b38926b71@oracle.com> <3514c74d-5f6a-61cc-ebea-b9564df61673@oracle.com> Message-ID: <63b8e1d2-3516-88f5-02ac-828dd15baf83@oracle.com> I think I missed graal-dev with this reply.? I have a few other comments. +void MetadataHandleBlock::do_unloading(BoolObjectClosure* is_alive) { We've removed the is_alive parameter from all do_unloading, and it appears unused here also. I don't know about this MetadataHandles block.?? It seems that it could be a concurrent hashtable with a WeakHandle<> if it's for jdk11 and beyond.? Kim might have mentioned this (I haven't read all the replies thoroughly) but JNIHandleBlock wasn't MT safe, and the new OopStorage is safe and scalable. + jmetadata allocate_handle(methodHandle handle) { return allocate_metadata_handle(handle()); } + jmetadata allocate_handle(constantPoolHandle handle) { return allocate_metadata_handle(handle()); } +CompLevel JVMCI::adjust_comp_level(methodHandle method, bool is_osr, CompLevel level, JavaThread* thread) { +JVMCIObject JVMCIEnv::new_StackTraceElement(methodHandle method, int bci, JVMCI_TRAPS) { +JVMCIObject JVMCIEnv::new_HotSpotNmethod(methodHandle method, const char* name, jboolean isDefault, jlong compileId, JVMCI_TRAPS) { Passing metadata Handles by copy will call the copy constructor and destructor for these parameters unnecessarily.? They should be passed as *const* references to avoid this. +class MetadataHandleBlock : public CHeapObj { There should be a better mt? for this.? mtCompiler seems appropriate here.? Depending on how many others of these, you could add an mtJVMCI. + if (TraceNMethodInstalls) { We've had Unified Logging in the sources for a long time now. New code should use UL rather than adding a TraceSomething option.?? I understand it's supposed to be shared with JDK8 code but it seems that you're forward porting what looks like old code into the repository. Coleen On 4/9/19 4:00 PM, coleen.phillimore at oracle.com wrote: > > http://cr.openjdk.java.net/~kvn/8220623/webrev.06/src/hotspot/share/classfile/classFileParser.cpp.udiff.html > > > It appears this change is to implement > https://bugs.openjdk.java.net/browse/JDK-8193513 which we closed as > WNF.? If you want this change, remove it from this giant patch and > reopen and submit a separate patch for this bug. > > It shouldn't be conditional on JVMCI and should use the normal unified > logging mechanism. > > http://cr.openjdk.java.net/~kvn/8220623/webrev.06/src/hotspot/share/runtime/thread.hpp.udiff.html > > > *!_jlong__pending_failed_speculation;* > > > We've been trying to remove and avoid java types in hotspot code and > use the appropriate C++ types instead.? Can this be changed to > int64_t?? 'long' is generally wrong though. > > I seem to remember there was code to deal with metadata in oops for > redefinition, but I can't find it in this big patch.? I was going to > look at that. > > Otherwise, I've reviewed the runtime code. > > Coleen > > On 4/4/19 3:22 AM, Vladimir Kozlov wrote: >> New delta: >> http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.06/ >> >> Full: >> http://cr.openjdk.java.net/~kvn/8220623/webrev.06/ >> >> New changes are based on Kim and Stefan suggestions: >> >> - Moved JVMCI::oops_do() from JNIHandles to places where it should be >> called. >> - Moved JVMCI cleanup task to the beginning of >> ParallelCleaningTask::work(). >> - Used JVMCI_ONLY macro with COMMA. >> - Disable JVMCI build on SPARC. We don't use it - neither Graal or >> AOT are built on SPARC. Disabling also helps to find missing JVMCI >> guards. >> >> I ran hs-tier1-3 testing - it passed (hs-tier3 includes graal testing). >> I started hs-tier4..8-graal testing. >> I will do performance testing next. >> >> Thanks, >> Vladimir >> >> On 4/3/19 9:54 AM, Vladimir Kozlov wrote: >>> On 4/2/19 11:35 PM, Stefan Karlsson wrote: >>>> On 2019-04-02 22:41, Vladimir Kozlov wrote: >>>>> I ran Kitchensink with G1 and -Xmx8g. I observed that Remark pause >>>>> times are not consistent even without Graal. >>>>> To see effect I added time spent in JVMCI::do_unloading() to GC >>>>> log (see below [3]). The result is < 1ms - it is less than 1% of a >>>>> pause time. >>>> >>>> Kitchensink isn't really a benchmark, but a stress test. I sent you >>>> a private mail how to run these changes through our internal >>>> performance test setup. >>> >>> Okay, I will run performance tests there too. >>> >>>> >>>>> >>>>> It will have even less effect since I moved JVMCI::do_unloading() >>>>> from serial path to parallel worker thread as Stefan suggested. >>>>> >>>>> Stefan, are you satisfied with these changes now? >>>> >>>> Yes, the clean-ups look good. Thanks for cleaning this up. >>>> >>>> Kim had some extra comments about a few more places where >>>> JVMCI_ONLY could be used. >>>> >>>> I also agree with him that JVMCI::oops_do should not be placed in >>>> JNIHandles::oops_do. I think you should put it where you put the >>>> AOTLoader::oops_do calls. >>> >>> Okay. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Thanks, >>>> StefanK >>>> >>>> >>>>> >>>>> Here is latest delta update which includes previous [1] delta and >>>>> - use CompilerThreadStackSize * 2 for libgraal instead of exact >>>>> value, >>>>> - removed HandleMark added for debugging (reverted changes in >>>>> jvmtiImpl.cpp), >>>>> - added recent jvmci-8 changes to fix registration of native >>>>> methods in libgraal (jvmciCompilerToVM.cpp) >>>>> >>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.05/ >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> [1] http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.04/ >>>>> [2] Original webrev >>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ >>>>> [3] Pauses times from Kitchensink (0.0ms means there were no >>>>> unloaded classes, 'NNN alive' shows how many metadata references >>>>> were processed): >>>>> >>>>> [1.083s][1554229160638ms][info ][gc,start???? ] GC(2) Pause Remark >>>>> [1.085s][1554229160639ms][info ][gc?????????? ] GC(2) >>>>> JVMCI::do_unloading(): 0 alive 0.000ms >>>>> [1.099s][1554229160654ms][info ][gc?????????? ] GC(2) Pause Remark >>>>> 28M->28M(108M) 16.123ms >>>>> >>>>> [3.097s][1554229162651ms][info ][gc,start???? ] GC(12) Pause Remark >>>>> [3.114s][1554229162668ms][info ][gc?????????? ] GC(12) >>>>> JVMCI::do_unloading(): 3471 alive 0.164ms >>>>> [3.148s][1554229162702ms][info ][gc?????????? ] GC(12) Pause >>>>> Remark 215M->213M(720M) 51.103ms >>>>> >>>>> [455.111s][1554229614666ms][info ][gc,phases,start] GC(1095) Phase >>>>> 1: Mark live objects >>>>> [455.455s][1554229615010ms][info ][gc???????????? ] GC(1095) >>>>> JVMCI::do_unloading(): 4048 alive 0.821ms >>>>> [455.456s][1554229615010ms][info ][gc,phases????? ] GC(1095) Phase >>>>> 1: Mark live objects 344.107ms >>>>> >>>>> [848.932s][1554230008486ms][info ][gc,phases,start] GC(1860) Phase >>>>> 1: Mark live objects >>>>> [849.248s][1554230008803ms][info ][gc???????????? ] GC(1860) >>>>> JVMCI::do_unloading(): 3266 alive 0.470ms >>>>> [849.249s][1554230008803ms][info ][gc,phases????? ] GC(1860) Phase >>>>> 1: Mark live objects 316.527ms >>>>> >>>>> [1163.778s][1554230323332ms][info ][gc,start?????? ] GC(2627) >>>>> Pause Remark >>>>> [1163.932s][1554230323486ms][info ][gc???????????? ] GC(2627) >>>>> JVMCI::do_unloading(): 3474 alive 0.642ms >>>>> [1163.941s][1554230323496ms][info ][gc???????????? ] GC(2627) >>>>> Pause Remark 2502M->2486M(4248M) 163.296ms >>>>> >>>>> [1242.587s][1554230402141ms][info ][gc,phases,start] GC(2734) >>>>> Phase 1: Mark live objects >>>>> [1242.899s][1554230402453ms][info ][gc???????????? ] GC(2734) >>>>> JVMCI::do_unloading(): 3449 alive 0.570ms >>>>> [1242.899s][1554230402453ms][info ][gc,phases????? ] GC(2734) >>>>> Phase 1: Mark live objects 311.719ms >>>>> >>>>> [1364.164s][1554230523718ms][info ][gc,phases,start] GC(3023) >>>>> Phase 1: Mark live objects >>>>> [1364.613s][1554230524167ms][info ][gc???????????? ] GC(3023) >>>>> JVMCI::do_unloading(): 3449 alive 0.000ms >>>>> [1364.613s][1554230524167ms][info ][gc,phases????? ] GC(3023) >>>>> Phase 1: Mark live objects 448.495ms >>>>> >>>>> [1425.222s][1554230584776ms][info ][gc,phases,start] GC(3151) >>>>> Phase 1: Mark live objects >>>>> [1425.587s][1554230585142ms][info ][gc???????????? ] GC(3151) >>>>> JVMCI::do_unloading(): 3491 alive 0.882ms >>>>> [1425.587s][1554230585142ms][info ][gc,phases????? ] GC(3151) >>>>> Phase 1: Mark live objects 365.403ms >>>>> >>>>> [1456.401s][1554230615955ms][info ][gc,phases,start] GC(3223) >>>>> Phase 1: Mark live objects >>>>> [1456.769s][1554230616324ms][info ][gc???????????? ] GC(3223) >>>>> JVMCI::do_unloading(): 3478 alive 0.616ms >>>>> [1456.769s][1554230616324ms][info ][gc,phases????? ] GC(3223) >>>>> Phase 1: Mark live objects 368.643ms >>>>> >>>>> [1806.139s][1554230965694ms][info?? ][gc,start?????? ] GC(4014) >>>>> Pause Remark >>>>> [1806.161s][1554230965716ms][info?? ][gc???????????? ] GC(4014) >>>>> JVMCI::do_unloading(): 3478 alive 0.000ms >>>>> [1806.163s][1554230965717ms][info?? ][gc???????????? ] GC(4014) >>>>> Pause Remark 1305M->1177M(2772M) 23.190ms >>>>> >>>>> >>>>> >>>>> On 4/1/19 12:34 AM, Stefan Karlsson wrote: >>>>>> On 2019-03-29 17:55, Vladimir Kozlov wrote: >>>>>>> Stefan, >>>>>>> >>>>>>> Do you have a test (and flags) which can allow me to measure >>>>>>> effect of this code on G1 remark pause? >>>>>> >>>>>> >>>>>> -Xlog:gc prints the remark times: >>>>>> [4,296s][info][gc?????? ] GC(89) Pause Remark 4M->4M(28M) 36,412ms >>>>>> >>>>>> StefanK >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 3/29/19 12:36 AM, Stefan Karlsson wrote: >>>>>>>> On 2019-03-29 03:07, Vladimir Kozlov wrote: >>>>>>>>> Hi Stefan, >>>>>>>>> >>>>>>>>> I collected some data on MetadataHandleBlock. >>>>>>>>> >>>>>>>>> First, do_unloading() code is executed only when >>>>>>>>> class_unloading_occurred is 'true' - it is rare case. It >>>>>>>>> should not affect normal G1 remark pause. >>>>>>>> >>>>>>>> It's only rare for applications that don't do dynamic class >>>>>>>> loading and unloading. The applications that do, will be affected. >>>>>>>> >>>>>>>>> >>>>>>>>> Second, I run a test with -Xcomp. I got about 10,000 >>>>>>>>> compilations by Graal and next data at the end of execution: >>>>>>>>> >>>>>>>>> max_blocks = 232 >>>>>>>>> max_handles_per_block = 32 (since handles array has 32 elements) >>>>>>>>> max_total_alive_values = 4631 >>>>>>>> >>>>>>>> OK. Thanks for the info. >>>>>>>> >>>>>>>> StefanK >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 3/28/19 2:44 PM, Vladimir Kozlov wrote: >>>>>>>>>> Thank you, Stefan >>>>>>>>>> >>>>>>>>>> On 3/28/19 12:54 PM, Stefan Karlsson wrote: >>>>>>>>>>> Hi Vladimir, >>>>>>>>>>> >>>>>>>>>>> I started to check the GC code. >>>>>>>>>>> >>>>>>>>>>> ======================================================================== >>>>>>>>>>> >>>>>>>>>>> I see that you've added guarded includes in the middle of >>>>>>>>>>> the include list: >>>>>>>>>>> ?? #include "gc/shared/strongRootsScope.hpp" >>>>>>>>>>> ?? #include "gc/shared/weakProcessor.hpp" >>>>>>>>>>> + #if INCLUDE_JVMCI >>>>>>>>>>> + #include "jvmci/jvmci.hpp" >>>>>>>>>>> + #endif >>>>>>>>>>> ?? #include "oops/instanceRefKlass.hpp" >>>>>>>>>>> ?? #include "oops/oop.inline.hpp" >>>>>>>>>>> >>>>>>>>>>> The style we use is to put these conditional includes at the >>>>>>>>>>> end of the include lists. >>>>>>>>>> >>>>>>>>>> okay >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ======================================================================== >>>>>>>>>>> >>>>>>>>>>> Could you also change the following: >>>>>>>>>>> >>>>>>>>>>> + #if INCLUDE_JVMCI >>>>>>>>>>> +???? // Clean JVMCI metadata handles. >>>>>>>>>>> +???? JVMCI::do_unloading(is_alive_closure(), purged_class); >>>>>>>>>>> + #endif >>>>>>>>>>> >>>>>>>>>>> to: >>>>>>>>>>> +???? // Clean JVMCI metadata handles. >>>>>>>>>>> + JVMCI_ONLY(JVMCI::do_unloading(is_alive_closure(), >>>>>>>>>>> purged_class);) >>>>>>>>>>> >>>>>>>>>>> to get rid of some of the line noise in the GC files. >>>>>>>>>> >>>>>>>>>> okay >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ======================================================================== >>>>>>>>>>> >>>>>>>>>>> In the future we will need version of JVMCI::do_unloading >>>>>>>>>>> that supports concurrent cleaning for ZGC. >>>>>>>>>> >>>>>>>>>> Yes, we need to support concurrent cleaning in a future. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ======================================================================== >>>>>>>>>>> >>>>>>>>>>> What's the performance impact for G1 remark pause with this >>>>>>>>>>> serial walk over the MetadataHandleBlock? >>>>>>>>>>> >>>>>>>>>>> 3275 void >>>>>>>>>>> G1CollectedHeap::complete_cleaning(BoolObjectClosure* is_alive, >>>>>>>>>>> 3276 bool class_unloading_occurred) { >>>>>>>>>>> 3277?? uint num_workers = workers()->active_workers(); >>>>>>>>>>> 3278?? ParallelCleaningTask unlink_task(is_alive, >>>>>>>>>>> num_workers, class_unloading_occurred, false); >>>>>>>>>>> 3279 workers()->run_task(&unlink_task); >>>>>>>>>>> 3280 #if INCLUDE_JVMCI >>>>>>>>>>> 3281?? // No parallel processing of JVMCI metadata handles >>>>>>>>>>> for now. >>>>>>>>>>> 3282?? JVMCI::do_unloading(is_alive, class_unloading_occurred); >>>>>>>>>>> 3283 #endif >>>>>>>>>>> 3284 } >>>>>>>>>> >>>>>>>>>> There should not be impact if Graal is not used. Only cost of >>>>>>>>>> call (which most likely is inlined in product VM) and check: >>>>>>>>>> >>>>>>>>>> http://hg.openjdk.java.net/metropolis/dev/file/530fc1427d02/src/hotspot/share/jvmci/jvmciRuntime.cpp#l1237 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If Graal is used it should not have big impact since these >>>>>>>>>> metadata has regular pattern (32 handles per array and array >>>>>>>>>> per MetadataHandleBlock block which are linked in list) and >>>>>>>>>> not large. >>>>>>>>>> If there will be noticeable impact - we will work on it as >>>>>>>>>> you suggested by using ParallelCleaningTask. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ======================================================================== >>>>>>>>>>> >>>>>>>>>>> Did you consider adding it as a task for one of the worker >>>>>>>>>>> threads to execute in ParallelCleaningTask? >>>>>>>>>>> >>>>>>>>>>> See how other tasks are claimed by one worker: >>>>>>>>>>> void KlassCleaningTask::work() { >>>>>>>>>>> ?? ResourceMark rm; >>>>>>>>>>> >>>>>>>>>>> ?? // One worker will clean the subklass/sibling klass tree. >>>>>>>>>>> ?? if (claim_clean_klass_tree_task()) { >>>>>>>>>>> ???? Klass::clean_subklass_tree(); >>>>>>>>>>> ?? } >>>>>>>>>> >>>>>>>>>> These changes were ported from JDK8u based changes in >>>>>>>>>> graal-jvmci-8 and there are no ParallelCleaningTask in JDK8. >>>>>>>>>> >>>>>>>>>> Your suggestion is interesting and I agree that we should >>>>>>>>>> investigate it. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ======================================================================== >>>>>>>>>>> >>>>>>>>>>> In MetadataHandleBlock::do_unloading: >>>>>>>>>>> >>>>>>>>>>> +??????? if (klass->class_loader_data()->is_unloading()) { >>>>>>>>>>> +????????? // This needs to be marked so that it's no longer >>>>>>>>>>> scanned >>>>>>>>>>> +????????? // but can't be put on the free list yet. The >>>>>>>>>>> +????????? // ReferenceCleaner will set this to NULL and >>>>>>>>>>> +????????? // put it on the free list. >>>>>>>>>>> >>>>>>>>>>> I couldn't find the ReferenceCleaner in the patch or in the >>>>>>>>>>> source. Where can I find this code? >>>>>>>>>> >>>>>>>>>> I think it is typo (I will fix it) - it references new >>>>>>>>>> HandleCleaner class: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HandleCleaner.java.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> StefanK >>>>>>>>>>> >>>>>>>>>>> On 2019-03-28 20:15, Vladimir Kozlov wrote: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8220623 >>>>>>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ >>>>>>>>>>>> >>>>>>>>>>>> Update JVMCI to support pre-compiled as shared library Graal. >>>>>>>>>>>> Using aoted Graal can offers benefits including: >>>>>>>>>>>> ?- fast startup >>>>>>>>>>>> ?- compile time similar to native JIt compilers (C2) >>>>>>>>>>>> ?- memory usage disjoint from the application Java heap >>>>>>>>>>>> ?- no profile pollution of JDK code used by the application >>>>>>>>>>>> >>>>>>>>>>>> This is JDK13 port of JVMCI changes done in graal-jvmci-8 >>>>>>>>>>>> [1] up to date. >>>>>>>>>>>> Changes were collected in Metropolis repo [2] and tested >>>>>>>>>>>> there. >>>>>>>>>>>> >>>>>>>>>>>> Changes we reviewed by Oracle Labs (authors of JVMCI and >>>>>>>>>>>> Graal) and our compiler group. >>>>>>>>>>>> Changes in shared code are guarded by #if INCLUDE_JVMCI and >>>>>>>>>>>> JVMCI flags. >>>>>>>>>>>> >>>>>>>>>>>> I ran tier1-tier8 (which includes HotSpot and JDK tests) >>>>>>>>>>>> and it was clean. In this set Graal was tested only in tier3. >>>>>>>>>>>> >>>>>>>>>>>> And I ran all hs-tier3-graal .. hs-tier8-graal Graal tests >>>>>>>>>>>> available in our system. Several issue were found which >>>>>>>>>>>> were present before these changes. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>> [1] >>>>>>>>>>>> https://github.com/graalvm/graal-jvmci-8/commit/49ff2045fb603e35516a3a427d8023c00e1607af >>>>>>>>>>>> [2] http://hg.openjdk.java.net/metropolis/dev/ >>>>>>>>>>> > From vladimir.kozlov at oracle.com Tue Apr 9 22:31:20 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 9 Apr 2019 15:31:20 -0700 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <4354a0db-8f50-4eb0-af63-cadd5dde7ae5@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <571f3d72-a22a-3b52-2942-6408072e353f@oracle.com> <144af13e-33e2-2089-f8d2-902e94485eb1@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> Message-ID: 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? 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? 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. Thanks, Vladimir 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 igor.ignatyev at oracle.com Wed Apr 10 00:17:55 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 9 Apr 2019 17:17:55 -0700 Subject: RFR(M/S) : 8222154 : upgrade gtest to 1.8.1 Message-ID: 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). 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 vladimir.kozlov at oracle.com Wed Apr 10 02:25:35 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 9 Apr 2019 19:25:35 -0700 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: <63b8e1d2-3516-88f5-02ac-828dd15baf83@oracle.com> References: <4b759550-f185-724f-7139-9bab648a1966@oracle.com> <119335f1-acb7-fffc-f38a-e50a96b73b3c@oracle.com> <2d206374-cfeb-9b1b-2838-e4e0a774e89d@oracle.com> <8063fb37-f1b0-8b93-bbe8-4dbeeaa54959@oracle.com> <17233985-18c7-305e-5556-fe2b38926b71@oracle.com> <3514c74d-5f6a-61cc-ebea-b9564df61673@oracle.com> <63b8e1d2-3516-88f5-02ac-828dd15baf83@oracle.com> Message-ID: <39774cdd-de9e-c878-4a5a-f6595a93859f@oracle.com> Thank you, Coleen On 4/9/19 1:36 PM, coleen.phillimore at oracle.com wrote: > > I think I missed graal-dev with this reply.? I have a few other comments. > > +void MetadataHandleBlock::do_unloading(BoolObjectClosure* is_alive) { > > > We've removed the is_alive parameter from all do_unloading, and it appears unused here also. Yes, I can remove it. > > I don't know about this MetadataHandles block.?? It seems that it could be a concurrent hashtable > with a WeakHandle<> if it's for jdk11 and beyond.? Kim might have mentioned this (I haven't read all > the replies thoroughly) but JNIHandleBlock wasn't MT safe, and the new OopStorage is safe and scalable. Yes, Kim also suggested OopStorage. I did not get into that part yet but I will definitely do. > > +? jmetadata allocate_handle(methodHandle handle)?????? { return allocate_metadata_handle(handle()); } > +? jmetadata allocate_handle(constantPoolHandle handle) { return allocate_metadata_handle(handle()); } > > +CompLevel JVMCI::adjust_comp_level(methodHandle method, bool is_osr, CompLevel level, JavaThread* > thread) { > > +JVMCIObject JVMCIEnv::new_StackTraceElement(methodHandle method, int bci, JVMCI_TRAPS) { > > +JVMCIObject JVMCIEnv::new_HotSpotNmethod(methodHandle method, const char* name, jboolean isDefault, > jlong compileId, JVMCI_TRAPS) { > > Passing metadata Handles by copy will call the copy constructor and destructor for these parameters > unnecessarily.? They should be passed as *const* references to avoid this. Okay. > > +class MetadataHandleBlock : public CHeapObj { > > > There should be a better mt? for this.? mtCompiler seems appropriate here.? Depending on how many > others of these, you could add an mtJVMCI. mtJVMCI is good suggestion. > > +??????????? if (TraceNMethodInstalls) { > > > We've had Unified Logging in the sources for a long time now. New code should use UL rather than > adding a TraceSomething option.?? I understand it's supposed to be shared with JDK8 code but it > seems that you're forward porting what looks like old code into the repository. Yes, we should use UL for this. Existing JIT code (ciEnv.cpp) still not using UL for this: http://hg.openjdk.java.net/jdk/jdk/file/f847a42ddc01/src/hotspot/share/ci/ciEnv.cpp#l1075 May be I should update it too ... > > Coleen > > > On 4/9/19 4:00 PM, coleen.phillimore at oracle.com wrote: >> >> http://cr.openjdk.java.net/~kvn/8220623/webrev.06/src/hotspot/share/classfile/classFileParser.cpp.udiff.html >> >> >> It appears this change is to implement https://bugs.openjdk.java.net/browse/JDK-8193513 which we >> closed as WNF.? If you want this change, remove it from this giant patch and reopen and submit a >> separate patch for this bug. Thank you for pointing it. I will do as you suggested. >> >> It shouldn't be conditional on JVMCI and should use the normal unified logging mechanism. Okay. >> >> http://cr.openjdk.java.net/~kvn/8220623/webrev.06/src/hotspot/share/runtime/thread.hpp.udiff.html >> >> *!_jlong__pending_failed_speculation;* >> >> >> We've been trying to remove and avoid java types in hotspot code and use the appropriate C++ types >> instead.? Can this be changed to int64_t?? 'long' is generally wrong though. This field should be java type since it is accessed from Java Graal: http://hg.openjdk.java.net/jdk/jdk/file/f847a42ddc01/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java#l401 >> >> I seem to remember there was code to deal with metadata in oops for redefinition, but I can't find >> it in this big patch.? I was going to look at that. May be it is MetadataHandleBlock::metadata_do() (in jvmciRuntime.cpp)? >> >> Otherwise, I've reviewed the runtime code. Thanks, Vladimir >> >> Coleen >> >> On 4/4/19 3:22 AM, Vladimir Kozlov wrote: >>> New delta: >>> http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.06/ >>> >>> Full: >>> http://cr.openjdk.java.net/~kvn/8220623/webrev.06/ >>> >>> New changes are based on Kim and Stefan suggestions: >>> >>> - Moved JVMCI::oops_do() from JNIHandles to places where it should be called. >>> - Moved JVMCI cleanup task to the beginning of ParallelCleaningTask::work(). >>> - Used JVMCI_ONLY macro with COMMA. >>> - Disable JVMCI build on SPARC. We don't use it - neither Graal or AOT are built on SPARC. >>> Disabling also helps to find missing JVMCI guards. >>> >>> I ran hs-tier1-3 testing - it passed (hs-tier3 includes graal testing). >>> I started hs-tier4..8-graal testing. >>> I will do performance testing next. >>> >>> Thanks, >>> Vladimir >>> >>> On 4/3/19 9:54 AM, Vladimir Kozlov wrote: >>>> On 4/2/19 11:35 PM, Stefan Karlsson wrote: >>>>> On 2019-04-02 22:41, Vladimir Kozlov wrote: >>>>>> I ran Kitchensink with G1 and -Xmx8g. I observed that Remark pause times are not consistent >>>>>> even without Graal. >>>>>> To see effect I added time spent in JVMCI::do_unloading() to GC log (see below [3]). The >>>>>> result is < 1ms - it is less than 1% of a pause time. >>>>> >>>>> Kitchensink isn't really a benchmark, but a stress test. I sent you a private mail how to run >>>>> these changes through our internal performance test setup. >>>> >>>> Okay, I will run performance tests there too. >>>> >>>>> >>>>>> >>>>>> It will have even less effect since I moved JVMCI::do_unloading() from serial path to parallel >>>>>> worker thread as Stefan suggested. >>>>>> >>>>>> Stefan, are you satisfied with these changes now? >>>>> >>>>> Yes, the clean-ups look good. Thanks for cleaning this up. >>>>> >>>>> Kim had some extra comments about a few more places where JVMCI_ONLY could be used. >>>>> >>>>> I also agree with him that JVMCI::oops_do should not be placed in JNIHandles::oops_do. I think >>>>> you should put it where you put the AOTLoader::oops_do calls. >>>> >>>> Okay. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Thanks, >>>>> StefanK >>>>> >>>>> >>>>>> >>>>>> Here is latest delta update which includes previous [1] delta and >>>>>> - use CompilerThreadStackSize * 2 for libgraal instead of exact value, >>>>>> - removed HandleMark added for debugging (reverted changes in jvmtiImpl.cpp), >>>>>> - added recent jvmci-8 changes to fix registration of native methods in libgraal >>>>>> (jvmciCompilerToVM.cpp) >>>>>> >>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.05/ >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> [1] http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.04/ >>>>>> [2] Original webrev http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ >>>>>> [3] Pauses times from Kitchensink (0.0ms means there were no unloaded classes, 'NNN alive' >>>>>> shows how many metadata references were processed): >>>>>> >>>>>> [1.083s][1554229160638ms][info ][gc,start???? ] GC(2) Pause Remark >>>>>> [1.085s][1554229160639ms][info ][gc?????????? ] GC(2) JVMCI::do_unloading(): 0 alive 0.000ms >>>>>> [1.099s][1554229160654ms][info ][gc?????????? ] GC(2) Pause Remark 28M->28M(108M) 16.123ms >>>>>> >>>>>> [3.097s][1554229162651ms][info ][gc,start???? ] GC(12) Pause Remark >>>>>> [3.114s][1554229162668ms][info ][gc?????????? ] GC(12) JVMCI::do_unloading(): 3471 alive 0.164ms >>>>>> [3.148s][1554229162702ms][info ][gc?????????? ] GC(12) Pause Remark 215M->213M(720M) 51.103ms >>>>>> >>>>>> [455.111s][1554229614666ms][info ][gc,phases,start] GC(1095) Phase 1: Mark live objects >>>>>> [455.455s][1554229615010ms][info ][gc???????????? ] GC(1095) JVMCI::do_unloading(): 4048 alive >>>>>> 0.821ms >>>>>> [455.456s][1554229615010ms][info ][gc,phases????? ] GC(1095) Phase 1: Mark live objects 344.107ms >>>>>> >>>>>> [848.932s][1554230008486ms][info ][gc,phases,start] GC(1860) Phase 1: Mark live objects >>>>>> [849.248s][1554230008803ms][info ][gc???????????? ] GC(1860) JVMCI::do_unloading(): 3266 alive >>>>>> 0.470ms >>>>>> [849.249s][1554230008803ms][info ][gc,phases????? ] GC(1860) Phase 1: Mark live objects 316.527ms >>>>>> >>>>>> [1163.778s][1554230323332ms][info ][gc,start?????? ] GC(2627) Pause Remark >>>>>> [1163.932s][1554230323486ms][info ][gc???????????? ] GC(2627) JVMCI::do_unloading(): 3474 >>>>>> alive 0.642ms >>>>>> [1163.941s][1554230323496ms][info ][gc???????????? ] GC(2627) Pause Remark 2502M->2486M(4248M) >>>>>> 163.296ms >>>>>> >>>>>> [1242.587s][1554230402141ms][info ][gc,phases,start] GC(2734) Phase 1: Mark live objects >>>>>> [1242.899s][1554230402453ms][info ][gc???????????? ] GC(2734) JVMCI::do_unloading(): 3449 >>>>>> alive 0.570ms >>>>>> [1242.899s][1554230402453ms][info ][gc,phases????? ] GC(2734) Phase 1: Mark live objects >>>>>> 311.719ms >>>>>> >>>>>> [1364.164s][1554230523718ms][info ][gc,phases,start] GC(3023) Phase 1: Mark live objects >>>>>> [1364.613s][1554230524167ms][info ][gc???????????? ] GC(3023) JVMCI::do_unloading(): 3449 >>>>>> alive 0.000ms >>>>>> [1364.613s][1554230524167ms][info ][gc,phases????? ] GC(3023) Phase 1: Mark live objects >>>>>> 448.495ms >>>>>> >>>>>> [1425.222s][1554230584776ms][info ][gc,phases,start] GC(3151) Phase 1: Mark live objects >>>>>> [1425.587s][1554230585142ms][info ][gc???????????? ] GC(3151) JVMCI::do_unloading(): 3491 >>>>>> alive 0.882ms >>>>>> [1425.587s][1554230585142ms][info ][gc,phases????? ] GC(3151) Phase 1: Mark live objects >>>>>> 365.403ms >>>>>> >>>>>> [1456.401s][1554230615955ms][info ][gc,phases,start] GC(3223) Phase 1: Mark live objects >>>>>> [1456.769s][1554230616324ms][info ][gc???????????? ] GC(3223) JVMCI::do_unloading(): 3478 >>>>>> alive 0.616ms >>>>>> [1456.769s][1554230616324ms][info ][gc,phases????? ] GC(3223) Phase 1: Mark live objects >>>>>> 368.643ms >>>>>> >>>>>> [1806.139s][1554230965694ms][info?? ][gc,start?????? ] GC(4014) Pause Remark >>>>>> [1806.161s][1554230965716ms][info?? ][gc???????????? ] GC(4014) JVMCI::do_unloading(): 3478 >>>>>> alive 0.000ms >>>>>> [1806.163s][1554230965717ms][info?? ][gc???????????? ] GC(4014) Pause Remark >>>>>> 1305M->1177M(2772M) 23.190ms >>>>>> >>>>>> >>>>>> >>>>>> On 4/1/19 12:34 AM, Stefan Karlsson wrote: >>>>>>> On 2019-03-29 17:55, Vladimir Kozlov wrote: >>>>>>>> Stefan, >>>>>>>> >>>>>>>> Do you have a test (and flags) which can allow me to measure effect of this code on G1 >>>>>>>> remark pause? >>>>>>> >>>>>>> >>>>>>> -Xlog:gc prints the remark times: >>>>>>> [4,296s][info][gc?????? ] GC(89) Pause Remark 4M->4M(28M) 36,412ms >>>>>>> >>>>>>> StefanK >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 3/29/19 12:36 AM, Stefan Karlsson wrote: >>>>>>>>> On 2019-03-29 03:07, Vladimir Kozlov wrote: >>>>>>>>>> Hi Stefan, >>>>>>>>>> >>>>>>>>>> I collected some data on MetadataHandleBlock. >>>>>>>>>> >>>>>>>>>> First, do_unloading() code is executed only when class_unloading_occurred is 'true' - it >>>>>>>>>> is rare case. It should not affect normal G1 remark pause. >>>>>>>>> >>>>>>>>> It's only rare for applications that don't do dynamic class loading and unloading. The >>>>>>>>> applications that do, will be affected. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Second, I run a test with -Xcomp. I got about 10,000 compilations by Graal and next data >>>>>>>>>> at the end of execution: >>>>>>>>>> >>>>>>>>>> max_blocks = 232 >>>>>>>>>> max_handles_per_block = 32 (since handles array has 32 elements) >>>>>>>>>> max_total_alive_values = 4631 >>>>>>>>> >>>>>>>>> OK. Thanks for the info. >>>>>>>>> >>>>>>>>> StefanK >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 3/28/19 2:44 PM, Vladimir Kozlov wrote: >>>>>>>>>>> Thank you, Stefan >>>>>>>>>>> >>>>>>>>>>> On 3/28/19 12:54 PM, Stefan Karlsson wrote: >>>>>>>>>>>> Hi Vladimir, >>>>>>>>>>>> >>>>>>>>>>>> I started to check the GC code. >>>>>>>>>>>> >>>>>>>>>>>> ======================================================================== >>>>>>>>>>>> I see that you've added guarded includes in the middle of the include list: >>>>>>>>>>>> ?? #include "gc/shared/strongRootsScope.hpp" >>>>>>>>>>>> ?? #include "gc/shared/weakProcessor.hpp" >>>>>>>>>>>> + #if INCLUDE_JVMCI >>>>>>>>>>>> + #include "jvmci/jvmci.hpp" >>>>>>>>>>>> + #endif >>>>>>>>>>>> ?? #include "oops/instanceRefKlass.hpp" >>>>>>>>>>>> ?? #include "oops/oop.inline.hpp" >>>>>>>>>>>> >>>>>>>>>>>> The style we use is to put these conditional includes at the end of the include lists. >>>>>>>>>>> >>>>>>>>>>> okay >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ======================================================================== >>>>>>>>>>>> Could you also change the following: >>>>>>>>>>>> >>>>>>>>>>>> + #if INCLUDE_JVMCI >>>>>>>>>>>> +???? // Clean JVMCI metadata handles. >>>>>>>>>>>> +???? JVMCI::do_unloading(is_alive_closure(), purged_class); >>>>>>>>>>>> + #endif >>>>>>>>>>>> >>>>>>>>>>>> to: >>>>>>>>>>>> +???? // Clean JVMCI metadata handles. >>>>>>>>>>>> + JVMCI_ONLY(JVMCI::do_unloading(is_alive_closure(), purged_class);) >>>>>>>>>>>> >>>>>>>>>>>> to get rid of some of the line noise in the GC files. >>>>>>>>>>> >>>>>>>>>>> okay >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ======================================================================== >>>>>>>>>>>> In the future we will need version of JVMCI::do_unloading that supports concurrent >>>>>>>>>>>> cleaning for ZGC. >>>>>>>>>>> >>>>>>>>>>> Yes, we need to support concurrent cleaning in a future. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ======================================================================== >>>>>>>>>>>> What's the performance impact for G1 remark pause with this serial walk over the >>>>>>>>>>>> MetadataHandleBlock? >>>>>>>>>>>> >>>>>>>>>>>> 3275 void G1CollectedHeap::complete_cleaning(BoolObjectClosure* is_alive, >>>>>>>>>>>> 3276 bool class_unloading_occurred) { >>>>>>>>>>>> 3277?? uint num_workers = workers()->active_workers(); >>>>>>>>>>>> 3278?? ParallelCleaningTask unlink_task(is_alive, num_workers, class_unloading_occurred, >>>>>>>>>>>> false); >>>>>>>>>>>> 3279 workers()->run_task(&unlink_task); >>>>>>>>>>>> 3280 #if INCLUDE_JVMCI >>>>>>>>>>>> 3281?? // No parallel processing of JVMCI metadata handles for now. >>>>>>>>>>>> 3282?? JVMCI::do_unloading(is_alive, class_unloading_occurred); >>>>>>>>>>>> 3283 #endif >>>>>>>>>>>> 3284 } >>>>>>>>>>> >>>>>>>>>>> There should not be impact if Graal is not used. Only cost of call (which most likely is >>>>>>>>>>> inlined in product VM) and check: >>>>>>>>>>> >>>>>>>>>>> http://hg.openjdk.java.net/metropolis/dev/file/530fc1427d02/src/hotspot/share/jvmci/jvmciRuntime.cpp#l1237 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> If Graal is used it should not have big impact since these metadata has regular pattern >>>>>>>>>>> (32 handles per array and array per MetadataHandleBlock block which are linked in list) >>>>>>>>>>> and not large. >>>>>>>>>>> If there will be noticeable impact - we will work on it as you suggested by using >>>>>>>>>>> ParallelCleaningTask. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ======================================================================== >>>>>>>>>>>> Did you consider adding it as a task for one of the worker threads to execute in >>>>>>>>>>>> ParallelCleaningTask? >>>>>>>>>>>> >>>>>>>>>>>> See how other tasks are claimed by one worker: >>>>>>>>>>>> void KlassCleaningTask::work() { >>>>>>>>>>>> ?? ResourceMark rm; >>>>>>>>>>>> >>>>>>>>>>>> ?? // One worker will clean the subklass/sibling klass tree. >>>>>>>>>>>> ?? if (claim_clean_klass_tree_task()) { >>>>>>>>>>>> ???? Klass::clean_subklass_tree(); >>>>>>>>>>>> ?? } >>>>>>>>>>> >>>>>>>>>>> These changes were ported from JDK8u based changes in graal-jvmci-8 and there are no >>>>>>>>>>> ParallelCleaningTask in JDK8. >>>>>>>>>>> >>>>>>>>>>> Your suggestion is interesting and I agree that we should investigate it. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ======================================================================== >>>>>>>>>>>> In MetadataHandleBlock::do_unloading: >>>>>>>>>>>> >>>>>>>>>>>> +??????? if (klass->class_loader_data()->is_unloading()) { >>>>>>>>>>>> +????????? // This needs to be marked so that it's no longer scanned >>>>>>>>>>>> +????????? // but can't be put on the free list yet. The >>>>>>>>>>>> +????????? // ReferenceCleaner will set this to NULL and >>>>>>>>>>>> +????????? // put it on the free list. >>>>>>>>>>>> >>>>>>>>>>>> I couldn't find the ReferenceCleaner in the patch or in the source. Where can I find >>>>>>>>>>>> this code? >>>>>>>>>>> >>>>>>>>>>> I think it is typo (I will fix it) - it references new HandleCleaner class: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HandleCleaner.java.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> StefanK >>>>>>>>>>>> >>>>>>>>>>>> On 2019-03-28 20:15, Vladimir Kozlov wrote: >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8220623 >>>>>>>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ >>>>>>>>>>>>> >>>>>>>>>>>>> Update JVMCI to support pre-compiled as shared library Graal. >>>>>>>>>>>>> Using aoted Graal can offers benefits including: >>>>>>>>>>>>> ?- fast startup >>>>>>>>>>>>> ?- compile time similar to native JIt compilers (C2) >>>>>>>>>>>>> ?- memory usage disjoint from the application Java heap >>>>>>>>>>>>> ?- no profile pollution of JDK code used by the application >>>>>>>>>>>>> >>>>>>>>>>>>> This is JDK13 port of JVMCI changes done in graal-jvmci-8 [1] up to date. >>>>>>>>>>>>> Changes were collected in Metropolis repo [2] and tested there. >>>>>>>>>>>>> >>>>>>>>>>>>> Changes we reviewed by Oracle Labs (authors of JVMCI and Graal) and our compiler group. >>>>>>>>>>>>> Changes in shared code are guarded by #if INCLUDE_JVMCI and JVMCI flags. >>>>>>>>>>>>> >>>>>>>>>>>>> I ran tier1-tier8 (which includes HotSpot and JDK tests) and it was clean. In this set >>>>>>>>>>>>> Graal was tested only in tier3. >>>>>>>>>>>>> >>>>>>>>>>>>> And I ran all hs-tier3-graal .. hs-tier8-graal Graal tests available in our system. >>>>>>>>>>>>> Several issue were found which were present before these changes. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Vladimir >>>>>>>>>>>>> >>>>>>>>>>>>> [1] >>>>>>>>>>>>> https://github.com/graalvm/graal-jvmci-8/commit/49ff2045fb603e35516a3a427d8023c00e1607af >>>>>>>>>>>>> [2] http://hg.openjdk.java.net/metropolis/dev/ >>>>>>>>>>>> >> > From jamsheed.c.m at oracle.com Wed Apr 10 03:08:28 2019 From: jamsheed.c.m at oracle.com (Jamsheed) Date: Wed, 10 Apr 2019 08:38:28 +0530 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <571f3d72-a22a-3b52-2942-6408072e353f@oracle.com> <144af13e-33e2-2089-f8d2-902e94485eb1@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> Message-ID: 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 Apr 10 04:55:31 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 10 Apr 2019 14:55:31 +1000 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> <69018b42-7540-9222-a296-db28b99cdf91@oracle.com> <79a6f9dd-7f20-649c-a6c4-e6cf8f098130@oracle.com> <9c841ef7-4190-f5f8-fcfd-291c178a264d@oracle.com> <961ce204-40c9-9de9-8069-5f362497525a@oracle.com> <927E24E0-BD59-42C1-8FF9-957EF0E6D55E@oracle.com> <9513296d-6e0f-6e41-517d-9253f9ea13f6@oracle.com> <76DD7E45-E193-4F82-AE84-D58451863537@oracle.com> <750be466-6342-dc7d-efaf-9c68259b1252@oracle.com> Message-ID: <168bcd5b-eca9-8e61-07cf-d2d2342755be@oracle.com> Hi Erik, On 9/04/2019 11:55 pm, Erik Joelsson wrote: > Hello, > > Here is a new webrev with an even simpler change: > > http://cr.openjdk.java.net/~erikj/8221851/webrev.06/ > > I decided to just remove the usage of THIS_FILE from exceptions.hpp > since it did not work well. It currently does not work at all on Windows > or Macosx builds. On Linux it invalidates the precompiled header, which > is the main issue I'm trying to fix. > > As for the truncation issue, with the patch above, truncation will again > happen on Solaris and Linux if compiled with GCC <8. However, as Thomas > pointed out, there is already a review out for fixing the truncation > problems for real. As JDK-8220762 is soon to be fixed I'm okay with this temporarily regressing JDK-8204551. I've cc'd Yasumasa so he knows. Thanks, David ----- > > The reason I tried to pursue finding a solution with shortening of the > __FILE__ path was that I thought it would be beneficial in more > locations, but it now seems like more trouble than it's worth and not > actually a feature anyone seem to want. I do not want to spend more time > one this, I just want the precompiled header to start working again. > Yes, this regresses the truncation issue somewhat, but I do not think a > broken solution should be left in there. > > /Erik > > On 2019-04-08 15:27, David Holmes wrote: >> Hi Erik, >> >> On 9/04/2019 8:08 am, Erik Joelsson wrote: >>> New webrev with "_simple_basename": >>> http://cr.openjdk.java.net/~erikj/8221851/webrev.05/ >> >> Given the usage is typically of the form: >> >> ?Exceptions::_throw(THREAD_AND_LOCATION, e); >> >> which will expand to: >> >> ?Exceptions::_throw(THREAD, _simple_basename(__FILE__), __LINE__, e); >> >> what does the compiler actually generate for this at the call sites? >> I'm struggling with the addition of an inline function to a .hpp which >> we generally frown upon and have been working to remove. >> >> What affect does this have on code size? >> >> Thanks, >> David >> ----- >> >>> /Erik >>> >>> On 2019-04-08 12:20, Erik Joelsson wrote: >>>> On 2019-04-08 11:40, Kim Barrett wrote: >>>>>> On Apr 8, 2019, at 10:28 AM, Erik Joelsson >>>>>> wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> On 2019-04-05 15:46, Kim Barrett wrote: >>>>>>> Assuming all that, consider instead putting this_file_helper in >>>>>>> exceptions.hpp (perhaps with a better name?), don't bother with >>>>>>> THIS_FILE, and define THREAD_AND_LOCATION as >>>>>>> >>>>>>> #define THREAD_AND_LOCATION THREAD, this_file_helper(__FILE__), >>>>>>> __LINE__ >>>>>>> >>>>>> Moved to exceptions.hpp, renamed to "basename", and removed the >>>>>> THIS_FILE macro. >>>>> ?basename? might not count as a ?better name?, as it conflicts with >>>>> a POSIX function, >>>>> even though we don?t presently seem to be using that anywhere that >>>>> I could find. >>>>> >>>>> >>>> How about "simple_basename" then? Or just prefix with an underscore? >>>> The idea is to keep it internal to the headerfile, but I'm not >>>> familiar with conventions in Hotspot to know how you usually >>>> prefix/namespace things as private. >>>> >>>> /Erik >>>> From jamsheed.c.m at oracle.com Wed Apr 10 05:31:49 2019 From: jamsheed.c.m at oracle.com (Jamsheed) Date: Wed, 10 Apr 2019 11:01:49 +0530 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <571f3d72-a22a-3b52-2942-6408072e353f@oracle.com> <144af13e-33e2-2089-f8d2-902e94485eb1@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> Message-ID: <57ab78e9-4a18-f47f-5a03-dfbf916722fd@oracle.com> Hi Vladimir, John Rose comments about this issue here. Adding a mechanism for more precisely mapping the locations of unsafe memory operations would be more complex (though doable). It would tend to reduce the optimization level of code which uses unsafe operations. Therefore, I think the present imprecise design is preferable. john.rose at Eng 2001-05-11 https://bugs.openjdk.java.net/browse/JDK-4454115 Best regards, Jamsheed On 10/04/19 4:01 AM, Vladimir Kozlov wrote: > 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. From david.holmes at oracle.com Wed Apr 10 05:30:19 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 10 Apr 2019 15:30:19 +1000 Subject: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: References: Message-ID: <58f17e54-2fc1-2822-eaf2-9a88711983b7@oracle.com> On 9/04/2019 11:30 pm, Doerr, Martin wrote: > Hi Matthias, > >> I can live with that. :) > +1 > Assuming __GNUC__ is defined on all x86 platforms we have except Windows. Good catch - probably not on OS X, but I removed it and things seem to work fine on OS X without it. I think there's also a missing: #include "runtime/vm_version.hpp" in os_linux.cpp. David > Best regards, > Martin > > > -----Original Message----- > From: David Holmes > Sent: Dienstag, 9. April 2019 14:59 > To: Baesken, Matthias ; hotspot-dev at openjdk.java.net; Doerr, Martin > Subject: Re: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 > > On 9/04/2019 10:07 pm, Baesken, Matthias wrote: >> Hi Martin, thanks for your comments. >> I added a TODO-comment about 32bit, and removed the linux-only ifdef from vm_version_x86.cpp : >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8219241.6/ > > I can live with that. :) > > Thanks, > David > >> Best regards, Matthias >> >> >>> >>> Hi everybody, >>> >>> I think it makes sense to have the cpuid available on all x86 platforms. >>> However, the current Windows version requires 64 bit because the ABI >>> (calling convention) differs between 32 and 64 bit. >>> The linux version should work on all x86 platforms which support this kind of >>> inline assembler. >>> >>> So I suggest to make it compiler dependent: >>> One version for Visual Studio with implementation for 64 bit and TODO for 32 >>> bit. >>> One version for other compilers which support such kind of inline assembler. >>> >>> Best regards, >>> Martin >>> >>> >> From yasuenag at gmail.com Wed Apr 10 06:05:36 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 10 Apr 2019 15:05:36 +0900 Subject: RFR: JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC In-Reply-To: <168bcd5b-eca9-8e61-07cf-d2d2342755be@oracle.com> References: <0a5c232b-2c3e-4ace-f3ef-f9c5700a5699@oracle.com> <0811de03-0450-286c-18de-6f3f24ef214c@oracle.com> <30B08752-9666-47A3-B1F8-D797698C0F38@oracle.com> <4e94a6aa-5823-c0dd-5a6d-d504aff8ead0@oracle.com> <1723AB21-5FBC-4C93-9C49-5211776C7209@oracle.com> <518b94f5-11c4-4d18-8b6b-4dcaf32b5239@oracle.com> <69018b42-7540-9222-a296-db28b99cdf91@oracle.com> <79a6f9dd-7f20-649c-a6c4-e6cf8f098130@oracle.com> <9c841ef7-4190-f5f8-fcfd-291c178a264d@oracle.com> <961ce204-40c9-9de9-8069-5f362497525a@oracle.com> <927E24E0-BD59-42C1-8FF9-957EF0E6D55E@oracle.com> <9513296d-6e0f-6e41-517d-9253f9ea13f6@oracle.com> <76DD7E45-E193-4F82-AE84-D58451863537@oracle.com> <750be466-6342-dc7d-efaf-9c68259b1252@oracle.com> <168bcd5b-eca9-8e61-07cf-d2d2342755be@oracle.com> Message-ID: 2019?4?10?(?) 13:55 David Holmes : > > Hi Erik, > > On 9/04/2019 11:55 pm, Erik Joelsson wrote: > > Hello, > > > > Here is a new webrev with an even simpler change: > > > > http://cr.openjdk.java.net/~erikj/8221851/webrev.06/ > > > > I decided to just remove the usage of THIS_FILE from exceptions.hpp > > since it did not work well. It currently does not work at all on Windows > > or Macosx builds. On Linux it invalidates the precompiled header, which > > is the main issue I'm trying to fix. > > > > As for the truncation issue, with the patch above, truncation will again > > happen on Solaris and Linux if compiled with GCC <8. However, as Thomas > > pointed out, there is already a review out for fixing the truncation > > problems for real. > > As JDK-8220762 is soon to be fixed I'm okay with this temporarily > regressing JDK-8204551. I've cc'd Yasumasa so he knows. I think webrev.06 is reasonable to me. In addition, 8220093 has been fixed in JDK 13, so OpenJDK binary for Linux (rovided by jdk.java.net at least) will be compiled with GCC 8. I guess the regression in 8221851 is minimal, and we can ignore it after 8220762. (I've reviewed 8220762 in hotspot-runtime-dev mailing list.) Thanks, Yasumasa > Thanks, > David > ----- > > > > > The reason I tried to pursue finding a solution with shortening of the > > __FILE__ path was that I thought it would be beneficial in more > > locations, but it now seems like more trouble than it's worth and not > > actually a feature anyone seem to want. I do not want to spend more time > > one this, I just want the precompiled header to start working again. > > Yes, this regresses the truncation issue somewhat, but I do not think a > > broken solution should be left in there. > > > > /Erik > > > > On 2019-04-08 15:27, David Holmes wrote: > >> Hi Erik, > >> > >> On 9/04/2019 8:08 am, Erik Joelsson wrote: > >>> New webrev with "_simple_basename": > >>> http://cr.openjdk.java.net/~erikj/8221851/webrev.05/ > >> > >> Given the usage is typically of the form: > >> > >> Exceptions::_throw(THREAD_AND_LOCATION, e); > >> > >> which will expand to: > >> > >> Exceptions::_throw(THREAD, _simple_basename(__FILE__), __LINE__, e); > >> > >> what does the compiler actually generate for this at the call sites? > >> I'm struggling with the addition of an inline function to a .hpp which > >> we generally frown upon and have been working to remove. > >> > >> What affect does this have on code size? > >> > >> Thanks, > >> David > >> ----- > >> > >>> /Erik > >>> > >>> On 2019-04-08 12:20, Erik Joelsson wrote: > >>>> On 2019-04-08 11:40, Kim Barrett wrote: > >>>>>> On Apr 8, 2019, at 10:28 AM, Erik Joelsson > >>>>>> wrote: > >>>>>> > >>>>>> Hello, > >>>>>> > >>>>>> On 2019-04-05 15:46, Kim Barrett wrote: > >>>>>>> Assuming all that, consider instead putting this_file_helper in > >>>>>>> exceptions.hpp (perhaps with a better name?), don't bother with > >>>>>>> THIS_FILE, and define THREAD_AND_LOCATION as > >>>>>>> > >>>>>>> #define THREAD_AND_LOCATION THREAD, this_file_helper(__FILE__), > >>>>>>> __LINE__ > >>>>>>> > >>>>>> Moved to exceptions.hpp, renamed to "basename", and removed the > >>>>>> THIS_FILE macro. > >>>>> ?basename? might not count as a ?better name?, as it conflicts with > >>>>> a POSIX function, > >>>>> even though we don?t presently seem to be using that anywhere that > >>>>> I could find. > >>>>> > >>>>> > >>>> How about "simple_basename" then? Or just prefix with an underscore? > >>>> The idea is to keep it internal to the headerfile, but I'm not > >>>> familiar with conventions in Hotspot to know how you usually > >>>> prefix/namespace things as private. > >>>> > >>>> /Erik > >>>> From matthias.baesken at sap.com Wed Apr 10 06:48:09 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 10 Apr 2019 06:48:09 +0000 Subject: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: <58f17e54-2fc1-2822-eaf2-9a88711983b7@oracle.com> References: <58f17e54-2fc1-2822-eaf2-9a88711983b7@oracle.com> Message-ID: Hi, clang sets __GNUC__ too . I'll add the #include "runtime/vm_version.hpp" inclusion, probably was indirectly included before . Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Mittwoch, 10. April 2019 07:30 > To: Doerr, Martin ; Baesken, Matthias > ; hotspot-dev at openjdk.java.net > Subject: Re: RFR: 8219241: Provide basic virtualization related info in the > hs_error file on linux/windows x86_64 > > On 9/04/2019 11:30 pm, Doerr, Martin wrote: > > Hi Matthias, > > > >> I can live with that. :) > > +1 > > Assuming __GNUC__ is defined on all x86 platforms we have except > Windows. > > Good catch - probably not on OS X, but I removed it and things seem to > work fine on OS X without it. > > I think there's also a missing: > > #include "runtime/vm_version.hpp" > > in os_linux.cpp. > > David > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: David Holmes > > Sent: Dienstag, 9. April 2019 14:59 > > To: Baesken, Matthias ; hotspot- > dev at openjdk.java.net; Doerr, Martin > > Subject: Re: RFR: 8219241: Provide basic virtualization related info in the > hs_error file on linux/windows x86_64 > > > > On 9/04/2019 10:07 pm, Baesken, Matthias wrote: > >> Hi Martin, thanks for your comments. > >> I added a TODO-comment about 32bit, and removed the linux-only ifdef > from vm_version_x86.cpp : > >> > >> http://cr.openjdk.java.net/~mbaesken/webrevs/8219241.6/ > > > > I can live with that. :) > > > > Thanks, > > David > > > >> Best regards, Matthias > >> > >> > >>> > >>> Hi everybody, > >>> > >>> I think it makes sense to have the cpuid available on all x86 platforms. > >>> However, the current Windows version requires 64 bit because the ABI > >>> (calling convention) differs between 32 and 64 bit. > >>> The linux version should work on all x86 platforms which support this > kind of > >>> inline assembler. > >>> > >>> So I suggest to make it compiler dependent: > >>> One version for Visual Studio with implementation for 64 bit and TODO > for 32 > >>> bit. > >>> One version for other compilers which support such kind of inline > assembler. > >>> > >>> Best regards, > >>> Martin > >>> > >>> > >> From david.holmes at oracle.com Wed Apr 10 07:33:16 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 10 Apr 2019 17:33:16 +1000 Subject: [PATCH v3] JDK-8222090: Add Hygon Dhyana support In-Reply-To: References: Message-ID: <8eb195a5-900d-6adb-3b10-fbef47c3dbff@oracle.com> Hi Fanjinke, This looks fine to me. I've updated the webrev at: http://cr.openjdk.java.net/~dholmes/8222090/webrev.v3/ We need a second reviewer before I push it. Thanks, David On 9/04/2019 5:22 pm, Jinke Fan wrote: > diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp > b/src/hotspot/cpu/x86/assembler_x86.cpp > --- a/src/hotspot/cpu/x86/assembler_x86.cpp > +++ b/src/hotspot/cpu/x86/assembler_x86.cpp > @@ -3099,7 +3099,7 @@ > ???? } > ???? return; > ?? } > -? if (UseAddressNop && VM_Version::is_amd()) { > +? if (UseAddressNop && (VM_Version::is_amd() || VM_Version::is_hygon())) { > ???? // > ???? // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. > ???? //? 1: 0x90 > diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp > b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp > --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp > +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp > @@ -340,6 +340,10 @@ > ???? return !is_amd_Barcelona(); > ?? } > > +? if (is_hygon()) { > +??? return true; > +? } > + > ?? return false; > ?} > > @@ -407,6 +411,10 @@ > ???? } > ???? return _family_id_intel[cpu_family_id]; > ?? } > +? if (is_hygon()) { > +????? return "Dhyana"; > +? } > + > ?? return "Unknown x86"; > ?} > > @@ -423,6 +431,9 @@ > ?? } else if (is_amd()) { > ???? cpu_type = "AMD"; > ???? x64 = cpu_is_em64t() ? " AMD64" : ""; > +? } else if (is_hygon()) { > +?????? cpu_type = "Hygon"; > +?????? x64 = cpu_is_em64t() ? " AMD64" : ""; > ?? } else { > ???? cpu_type = "Unknown x86"; > ???? x64 = cpu_is_em64t() ? " x86_64" : ""; > diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp > b/src/hotspot/cpu/x86/vm_version_x86.cpp > --- a/src/hotspot/cpu/x86/vm_version_x86.cpp > +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp > @@ -1165,7 +1165,7 @@ > ???? } > ?? } > > -? if( is_amd() ) { // AMD cpus specific settings > +? if( is_amd() || is_hygon() ) { // AMD cpus specific settings > ???? if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { > ?????? // Use it on new AMD cpus starting from Opteron. > ?????? UseAddressNop = true; > @@ -1239,8 +1239,8 @@ > ???? } > ?#endif // COMPILER2 > > -??? // Some defaults for AMD family 17h > -??? if ( cpu_family() == 0x17 ) { > +??? // Some defaults for AMD family 17h || Hygon family 18h > +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { > ?????? // On family 17h processors use XMM and UnalignedLoadStores for > Array Copy > ?????? if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { > ???????? FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); > diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp > b/src/hotspot/cpu/x86/vm_version_x86.hpp > --- a/src/hotspot/cpu/x86/vm_version_x86.hpp > +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp > @@ -495,13 +495,13 @@ > ?????? result |= CPU_CX8; > ???? if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) > ?????? result |= CPU_CMOV; > -??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && > +??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() || > is_hygon()) && > ???????? _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) > ?????? result |= CPU_FXSR; > ???? // HT flag is set for multi-core processors also. > ???? if (threads_per_core() > 1) > ?????? result |= CPU_HT; > -??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && > +??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() || > is_hygon()) && > ???????? _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) > ?????? result |= CPU_MMX; > ???? if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) > @@ -576,8 +576,8 @@ > ???? if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) > ?????? result |= CPU_FMA; > > -??? // AMD features. > -??? if (is_amd()) { > +??? // AMD|Hygon features. > +??? if (is_amd() || is_hygon()) { > ?????? if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || > ?????????? (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) > ???????? result |= CPU_3DNOW_PREFETCH; > @@ -711,6 +711,7 @@ > ?? static int? cpu_family()??????? { return _cpu;} > ?? static bool is_P6()???????????? { return cpu_family() >= 6; } > ?? static bool is_amd()??????????? { assert_is_initialized(); return > _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' > +? static bool is_hygon()????????? { assert_is_initialized(); return > _cpuid_info.std_vendor_name_0 == 0x6F677948; } // 'ogyH' > ?? static bool is_intel()????????? { assert_is_initialized(); return > _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' > ?? static bool is_zx()???????????? { assert_is_initialized(); return > (_cpuid_info.std_vendor_name_0 == 0x746e6543) || > (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS? ' > ?? static bool is_atom_family()??? { return ((cpu_family() == 0x06) && > ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) || > (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton > @@ -734,7 +735,7 @@ > ?????? if (!supports_topology || result == 0) { > ???????? result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); > ?????? } > -??? } else if (is_amd()) { > +??? } else if (is_amd() || is_hygon()) { > ?????? result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); > ???? } else if (is_zx()) { > ?????? bool supports_topology = supports_processor_topology(); > @@ -770,7 +771,7 @@ > ???? intx result = 0; > ???? if (is_intel()) { > ?????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); > -??? } else if (is_amd()) { > +??? } else if (is_amd() || is_hygon()) { > ?????? result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; > ???? } else if (is_zx()) { > ?????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); > @@ -857,7 +858,7 @@ > > ?? // AMD features > ?? static bool supports_3dnow_prefetch()??? { return (_features & > CPU_3DNOW_PREFETCH) != 0; } > -? static bool supports_mmx_ext()? { return is_amd() && > _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } > +? static bool supports_mmx_ext()? { return (is_amd()||is_hygon()) && > _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } > ?? static bool supports_lzcnt()??? { return (_features & CPU_LZCNT) != > 0; } > ?? static bool supports_sse4a()??? { return (_features & CPU_SSE4A) != > 0; } > > @@ -870,7 +871,7 @@ > ?? } > ?? static bool supports_tscinv() { > ???? return supports_tscinv_bit() && > -?????????? ( (is_amd() && !is_amd_Barcelona()) || > +?????????? ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || > ????????????? is_intel_tsc_synched_at_init() ); > ?? } > > @@ -896,7 +897,7 @@ > ???? // Core????? - 256 / prefetchnta > ???? // It will be used only when AllocatePrefetchStyle > 0 > > -??? if (is_amd()) { // AMD > +??? if (is_amd() || is_hygon()) { // AMD > ?????? if (supports_sse2()) { > ???????? return 256; // Opteron > ?????? } else { From fanjinke51 at yeah.net Wed Apr 10 08:00:40 2019 From: fanjinke51 at yeah.net (Jinke Fan) Date: Wed, 10 Apr 2019 16:00:40 +0800 Subject: [PATCH v3] JDK-8222090: Add Hygon Dhyana support In-Reply-To: <8eb195a5-900d-6adb-3b10-fbef47c3dbff@oracle.com> References: <8eb195a5-900d-6adb-3b10-fbef47c3dbff@oracle.com> Message-ID: <35225ad6-1dbd-fd83-0232-0f8609853b46@yeah.net> Hi David, Thanks for the review. Best Regards! Fanjinke On 2019/4/10 15:33, David Holmes wrote: > Hi Fanjinke, > > This looks fine to me. I've updated the webrev at: > > http://cr.openjdk.java.net/~dholmes/8222090/webrev.v3/ > > We need a second reviewer before I push it. > > Thanks, > David > > On 9/04/2019 5:22 pm, Jinke Fan wrote: >> diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp >> b/src/hotspot/cpu/x86/assembler_x86.cpp >> --- a/src/hotspot/cpu/x86/assembler_x86.cpp >> +++ b/src/hotspot/cpu/x86/assembler_x86.cpp >> @@ -3099,7 +3099,7 @@ >> ????? } >> ????? return; >> ??? } >> -? if (UseAddressNop && VM_Version::is_amd()) { >> +? if (UseAddressNop && (VM_Version::is_amd() || >> VM_Version::is_hygon())) { >> ????? // >> ????? // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. >> ????? //? 1: 0x90 >> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> @@ -340,6 +340,10 @@ >> ????? return !is_amd_Barcelona(); >> ??? } >> >> +? if (is_hygon()) { >> +??? return true; >> +? } >> + >> ??? return false; >> ??} >> >> @@ -407,6 +411,10 @@ >> ????? } >> ????? return _family_id_intel[cpu_family_id]; >> ??? } >> +? if (is_hygon()) { >> +????? return "Dhyana"; >> +? } >> + >> ??? return "Unknown x86"; >> ??} >> >> @@ -423,6 +431,9 @@ >> ??? } else if (is_amd()) { >> ????? cpu_type = "AMD"; >> ????? x64 = cpu_is_em64t() ? " AMD64" : ""; >> +? } else if (is_hygon()) { >> +?????? cpu_type = "Hygon"; >> +?????? x64 = cpu_is_em64t() ? " AMD64" : ""; >> ??? } else { >> ????? cpu_type = "Unknown x86"; >> ????? x64 = cpu_is_em64t() ? " x86_64" : ""; >> diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp >> b/src/hotspot/cpu/x86/vm_version_x86.cpp >> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp >> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >> @@ -1165,7 +1165,7 @@ >> ????? } >> ??? } >> >> -? if( is_amd() ) { // AMD cpus specific settings >> +? if( is_amd() || is_hygon() ) { // AMD cpus specific settings >> ????? if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { >> ??????? // Use it on new AMD cpus starting from Opteron. >> ??????? UseAddressNop = true; >> @@ -1239,8 +1239,8 @@ >> ????? } >> ??#endif // COMPILER2 >> >> -??? // Some defaults for AMD family 17h >> -??? if ( cpu_family() == 0x17 ) { >> +??? // Some defaults for AMD family 17h || Hygon family 18h >> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >> ??????? // On family 17h processors use XMM and UnalignedLoadStores >> for Array Copy >> ??????? if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >> ????????? FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >> diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp >> b/src/hotspot/cpu/x86/vm_version_x86.hpp >> --- a/src/hotspot/cpu/x86/vm_version_x86.hpp >> +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp >> @@ -495,13 +495,13 @@ >> ??????? result |= CPU_CX8; >> ????? if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) >> ??????? result |= CPU_CMOV; >> -??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && >> +??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() || >> is_hygon()) && >> ????????? _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) >> ??????? result |= CPU_FXSR; >> ????? // HT flag is set for multi-core processors also. >> ????? if (threads_per_core() > 1) >> ??????? result |= CPU_HT; >> -??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && >> +??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() || >> is_hygon()) && >> ????????? _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) >> ??????? result |= CPU_MMX; >> ????? if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) >> @@ -576,8 +576,8 @@ >> ????? if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >> ??????? result |= CPU_FMA; >> >> -??? // AMD features. >> -??? if (is_amd()) { >> +??? // AMD|Hygon features. >> +??? if (is_amd() || is_hygon()) { >> ??????? if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || >> ??????????? (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) >> ????????? result |= CPU_3DNOW_PREFETCH; >> @@ -711,6 +711,7 @@ >> ??? static int? cpu_family()??????? { return _cpu;} >> ??? static bool is_P6()???????????? { return cpu_family() >= 6; } >> ??? static bool is_amd()??????????? { assert_is_initialized(); return >> _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' >> +? static bool is_hygon()????????? { assert_is_initialized(); return >> _cpuid_info.std_vendor_name_0 == 0x6F677948; } // 'ogyH' >> ??? static bool is_intel()????????? { assert_is_initialized(); return >> _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' >> ??? static bool is_zx()???????????? { assert_is_initialized(); return >> (_cpuid_info.std_vendor_name_0 == 0x746e6543) || >> (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS? ' >> ??? static bool is_atom_family()??? { return ((cpu_family() == 0x06) >> && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) >> || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton >> @@ -734,7 +735,7 @@ >> ??????? if (!supports_topology || result == 0) { >> ????????? result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); >> ??????? } >> -??? } else if (is_amd()) { >> +??? } else if (is_amd() || is_hygon()) { >> ??????? result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); >> ????? } else if (is_zx()) { >> ??????? bool supports_topology = supports_processor_topology(); >> @@ -770,7 +771,7 @@ >> ????? intx result = 0; >> ????? if (is_intel()) { >> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >> -??? } else if (is_amd()) { >> +??? } else if (is_amd() || is_hygon()) { >> ??????? result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; >> ????? } else if (is_zx()) { >> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >> @@ -857,7 +858,7 @@ >> >> ??? // AMD features >> ??? static bool supports_3dnow_prefetch()??? { return (_features & >> CPU_3DNOW_PREFETCH) != 0; } >> -? static bool supports_mmx_ext()? { return is_amd() && >> _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >> +? static bool supports_mmx_ext()? { return (is_amd()||is_hygon()) && >> _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >> ??? static bool supports_lzcnt()??? { return (_features & CPU_LZCNT) >> != 0; } >> ??? static bool supports_sse4a()??? { return (_features & CPU_SSE4A) >> != 0; } >> >> @@ -870,7 +871,7 @@ >> ??? } >> ??? static bool supports_tscinv() { >> ????? return supports_tscinv_bit() && >> -?????????? ( (is_amd() && !is_amd_Barcelona()) || >> +?????????? ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || >> ?????????????? is_intel_tsc_synched_at_init() ); >> ??? } >> >> @@ -896,7 +897,7 @@ >> ????? // Core????? - 256 / prefetchnta >> ????? // It will be used only when AllocatePrefetchStyle > 0 >> >> -??? if (is_amd()) { // AMD >> +??? if (is_amd() || is_hygon()) { // AMD >> ??????? if (supports_sse2()) { >> ????????? return 256; // Opteron >> ??????? } else { > From christoph.langer at sap.com Wed Apr 10 12:21:00 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 10 Apr 2019 12:21:00 +0000 Subject: RFR (S): 8221979: Cleanups for building Windows resources In-Reply-To: References: Message-ID: Thanks, Erik. I already checked and will check carefully once again before pushing. /Christoph > -----Original Message----- > From: Erik Joelsson > Sent: Dienstag, 9. April 2019 15:22 > To: Langer, Christoph ; build- > dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev > > Subject: Re: RFR (S): 8221979: Cleanups for building Windows resources > > Hello, > > Looks ok to me. > > I assume you have inspected all affected files and made sure all > attributes are the same pre and post this change? > > /Erik > > On 2019-04-09 02:55, Langer, Christoph wrote: > > Hi, > > > > during work on JDK-8221880 I spotted some opportunity for cleanup in > Windows resource files and their handling in the build. > > > > The naming of variables used for customizing resource properties in the > build system should be aligned between hotspot and JDK. This should be > carefully reviewed by the build team (Erik). Maybe there are conflicts with > some Oracle internal usage of variables... > > > > Furthermore some minor stuff: > > There are some indentation issues in the rc files. > > > src/jdk.accessibility/windows/native/common/AccessBridgeStatusWindow.R > C uses RC in capital letters as suffix, which is different to all other .rc files > used. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221979 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8221979.0/ > > > > Thanks > > Christoph > > From coleen.phillimore at oracle.com Wed Apr 10 13:34:07 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 10 Apr 2019 09:34:07 -0400 Subject: [PATCH v3] JDK-8222090: Add Hygon Dhyana support In-Reply-To: <35225ad6-1dbd-fd83-0232-0f8609853b46@yeah.net> References: <8eb195a5-900d-6adb-3b10-fbef47c3dbff@oracle.com> <35225ad6-1dbd-fd83-0232-0f8609853b46@yeah.net> Message-ID: <0f915983-8e30-9ef7-1a55-3d9b26ee5a87@oracle.com> This seems okay but there's a lot of cpu specific code in os_linux.cpp.? I assume #ifdef AMD64 is true, and the printing is correct in an hs_err_pid file? Thanks, Coleen On 4/10/19 4:00 AM, Jinke Fan wrote: > Hi David, > ? Thanks for the review. > > Best Regards! > Fanjinke > > On 2019/4/10 15:33, David Holmes wrote: >> Hi Fanjinke, >> >> This looks fine to me. I've updated the webrev at: >> >> http://cr.openjdk.java.net/~dholmes/8222090/webrev.v3/ >> >> We need a second reviewer before I push it. >> >> Thanks, >> David >> >> On 9/04/2019 5:22 pm, Jinke Fan wrote: >>> diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp >>> b/src/hotspot/cpu/x86/assembler_x86.cpp >>> --- a/src/hotspot/cpu/x86/assembler_x86.cpp >>> +++ b/src/hotspot/cpu/x86/assembler_x86.cpp >>> @@ -3099,7 +3099,7 @@ >>> ????? } >>> ????? return; >>> ??? } >>> -? if (UseAddressNop && VM_Version::is_amd()) { >>> +? if (UseAddressNop && (VM_Version::is_amd() || >>> VM_Version::is_hygon())) { >>> ????? // >>> ????? // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. >>> ????? //? 1: 0x90 >>> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>> b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>> @@ -340,6 +340,10 @@ >>> ????? return !is_amd_Barcelona(); >>> ??? } >>> >>> +? if (is_hygon()) { >>> +??? return true; >>> +? } >>> + >>> ??? return false; >>> ??} >>> >>> @@ -407,6 +411,10 @@ >>> ????? } >>> ????? return _family_id_intel[cpu_family_id]; >>> ??? } >>> +? if (is_hygon()) { >>> +????? return "Dhyana"; >>> +? } >>> + >>> ??? return "Unknown x86"; >>> ??} >>> >>> @@ -423,6 +431,9 @@ >>> ??? } else if (is_amd()) { >>> ????? cpu_type = "AMD"; >>> ????? x64 = cpu_is_em64t() ? " AMD64" : ""; >>> +? } else if (is_hygon()) { >>> +?????? cpu_type = "Hygon"; >>> +?????? x64 = cpu_is_em64t() ? " AMD64" : ""; >>> ??? } else { >>> ????? cpu_type = "Unknown x86"; >>> ????? x64 = cpu_is_em64t() ? " x86_64" : ""; >>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp >>> b/src/hotspot/cpu/x86/vm_version_x86.cpp >>> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp >>> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >>> @@ -1165,7 +1165,7 @@ >>> ????? } >>> ??? } >>> >>> -? if( is_amd() ) { // AMD cpus specific settings >>> +? if( is_amd() || is_hygon() ) { // AMD cpus specific settings >>> ????? if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { >>> ??????? // Use it on new AMD cpus starting from Opteron. >>> ??????? UseAddressNop = true; >>> @@ -1239,8 +1239,8 @@ >>> ????? } >>> ??#endif // COMPILER2 >>> >>> -??? // Some defaults for AMD family 17h >>> -??? if ( cpu_family() == 0x17 ) { >>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >>> ??????? // On family 17h processors use XMM and UnalignedLoadStores >>> for Array Copy >>> ??????? if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >>> ????????? FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp >>> b/src/hotspot/cpu/x86/vm_version_x86.hpp >>> --- a/src/hotspot/cpu/x86/vm_version_x86.hpp >>> +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp >>> @@ -495,13 +495,13 @@ >>> ??????? result |= CPU_CX8; >>> ????? if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) >>> ??????? result |= CPU_CMOV; >>> -??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && >>> +??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() || >>> is_hygon()) && >>> ????????? _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) >>> ??????? result |= CPU_FXSR; >>> ????? // HT flag is set for multi-core processors also. >>> ????? if (threads_per_core() > 1) >>> ??????? result |= CPU_HT; >>> -??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && >>> +??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() || >>> is_hygon()) && >>> ????????? _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) >>> ??????? result |= CPU_MMX; >>> ????? if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) >>> @@ -576,8 +576,8 @@ >>> ????? if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>> ??????? result |= CPU_FMA; >>> >>> -??? // AMD features. >>> -??? if (is_amd()) { >>> +??? // AMD|Hygon features. >>> +??? if (is_amd() || is_hygon()) { >>> ??????? if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || >>> ??????????? (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) >>> ????????? result |= CPU_3DNOW_PREFETCH; >>> @@ -711,6 +711,7 @@ >>> ??? static int? cpu_family()??????? { return _cpu;} >>> ??? static bool is_P6()???????????? { return cpu_family() >= 6; } >>> ??? static bool is_amd()??????????? { assert_is_initialized(); >>> return _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' >>> +? static bool is_hygon()????????? { assert_is_initialized(); return >>> _cpuid_info.std_vendor_name_0 == 0x6F677948; } // 'ogyH' >>> ??? static bool is_intel()????????? { assert_is_initialized(); >>> return _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' >>> ??? static bool is_zx()???????????? { assert_is_initialized(); >>> return (_cpuid_info.std_vendor_name_0 == 0x746e6543) || >>> (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS? ' >>> ??? static bool is_atom_family()??? { return ((cpu_family() == 0x06) >>> && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) >>> || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton >>> @@ -734,7 +735,7 @@ >>> ??????? if (!supports_topology || result == 0) { >>> ????????? result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); >>> ??????? } >>> -??? } else if (is_amd()) { >>> +??? } else if (is_amd() || is_hygon()) { >>> ??????? result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); >>> ????? } else if (is_zx()) { >>> ??????? bool supports_topology = supports_processor_topology(); >>> @@ -770,7 +771,7 @@ >>> ????? intx result = 0; >>> ????? if (is_intel()) { >>> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>> -??? } else if (is_amd()) { >>> +??? } else if (is_amd() || is_hygon()) { >>> ??????? result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; >>> ????? } else if (is_zx()) { >>> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>> @@ -857,7 +858,7 @@ >>> >>> ??? // AMD features >>> ??? static bool supports_3dnow_prefetch()??? { return (_features & >>> CPU_3DNOW_PREFETCH) != 0; } >>> -? static bool supports_mmx_ext()? { return is_amd() && >>> _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >>> +? static bool supports_mmx_ext()? { return (is_amd()||is_hygon()) >>> && _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >>> ??? static bool supports_lzcnt()??? { return (_features & CPU_LZCNT) >>> != 0; } >>> ??? static bool supports_sse4a()??? { return (_features & CPU_SSE4A) >>> != 0; } >>> >>> @@ -870,7 +871,7 @@ >>> ??? } >>> ??? static bool supports_tscinv() { >>> ????? return supports_tscinv_bit() && >>> -?????????? ( (is_amd() && !is_amd_Barcelona()) || >>> +?????????? ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || >>> ?????????????? is_intel_tsc_synched_at_init() ); >>> ??? } >>> >>> @@ -896,7 +897,7 @@ >>> ????? // Core????? - 256 / prefetchnta >>> ????? // It will be used only when AllocatePrefetchStyle > 0 >>> >>> -??? if (is_amd()) { // AMD >>> +??? if (is_amd() || is_hygon()) { // AMD >>> ??????? if (supports_sse2()) { >>> ????????? return 256; // Opteron >>> ??????? } else { >> > From robin.westberg at oracle.com Wed Apr 10 14:02:37 2019 From: robin.westberg at oracle.com (Robin Westberg) Date: Wed, 10 Apr 2019 16:02:37 +0200 Subject: RFR(M/S) : 8222154 : upgrade gtest to 1.8.1 In-Reply-To: References: Message-ID: 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 robin.westberg at oracle.com Wed Apr 10 14:02:44 2019 From: robin.westberg at oracle.com (Robin Westberg) Date: Wed, 10 Apr 2019 16:02:44 +0200 Subject: [PATCH v3] JDK-8222090: Add Hygon Dhyana support In-Reply-To: <8eb195a5-900d-6adb-3b10-fbef47c3dbff@oracle.com> References: <8eb195a5-900d-6adb-3b10-fbef47c3dbff@oracle.com> Message-ID: <0BDEF291-433E-4133-B208-2678E251FA49@oracle.com> Hi David, > On 10 Apr 2019, at 09:33, David Holmes wrote: > > Hi Fanjinke, > > This looks fine to me. I've updated the webrev at: > > http://cr.openjdk.java.net/~dholmes/8222090/webrev.v3/ > > We need a second reviewer before I push it. This looks good to me. One very minor nit: vm_version_x86.hpp: 877 ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || All the other instances of this comparison has spaces around the ?||"s.. Best regards, Robin (not a Reviewer) > > Thanks, > David > > On 9/04/2019 5:22 pm, Jinke Fan wrote: >> diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp b/src/hotspot/cpu/x86/assembler_x86.cpp >> --- a/src/hotspot/cpu/x86/assembler_x86.cpp >> +++ b/src/hotspot/cpu/x86/assembler_x86.cpp >> @@ -3099,7 +3099,7 @@ >> } >> return; >> } >> - if (UseAddressNop && VM_Version::is_amd()) { >> + if (UseAddressNop && (VM_Version::is_amd() || VM_Version::is_hygon())) { >> // >> // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. >> // 1: 0x90 >> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> @@ -340,6 +340,10 @@ >> return !is_amd_Barcelona(); >> } >> + if (is_hygon()) { >> + return true; >> + } >> + >> return false; >> } >> @@ -407,6 +411,10 @@ >> } >> return _family_id_intel[cpu_family_id]; >> } >> + if (is_hygon()) { >> + return "Dhyana"; >> + } >> + >> return "Unknown x86"; >> } >> @@ -423,6 +431,9 @@ >> } else if (is_amd()) { >> cpu_type = "AMD"; >> x64 = cpu_is_em64t() ? " AMD64" : ""; >> + } else if (is_hygon()) { >> + cpu_type = "Hygon"; >> + x64 = cpu_is_em64t() ? " AMD64" : ""; >> } else { >> cpu_type = "Unknown x86"; >> x64 = cpu_is_em64t() ? " x86_64" : ""; >> diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp b/src/hotspot/cpu/x86/vm_version_x86.cpp >> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp >> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >> @@ -1165,7 +1165,7 @@ >> } >> } >> - if( is_amd() ) { // AMD cpus specific settings >> + if( is_amd() || is_hygon() ) { // AMD cpus specific settings >> if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { >> // Use it on new AMD cpus starting from Opteron. >> UseAddressNop = true; >> @@ -1239,8 +1239,8 @@ >> } >> #endif // COMPILER2 >> - // Some defaults for AMD family 17h >> - if ( cpu_family() == 0x17 ) { >> + // Some defaults for AMD family 17h || Hygon family 18h >> + if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >> // On family 17h processors use XMM and UnalignedLoadStores for Array Copy >> if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >> FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >> diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp b/src/hotspot/cpu/x86/vm_version_x86.hpp >> --- a/src/hotspot/cpu/x86/vm_version_x86.hpp >> +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp >> @@ -495,13 +495,13 @@ >> result |= CPU_CX8; >> if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) >> result |= CPU_CMOV; >> - if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && >> + if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() || is_hygon()) && >> _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) >> result |= CPU_FXSR; >> // HT flag is set for multi-core processors also. >> if (threads_per_core() > 1) >> result |= CPU_HT; >> - if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && >> + if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() || is_hygon()) && >> _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) >> result |= CPU_MMX; >> if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) >> @@ -576,8 +576,8 @@ >> if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >> result |= CPU_FMA; >> - // AMD features. >> - if (is_amd()) { >> + // AMD|Hygon features. >> + if (is_amd() || is_hygon()) { >> if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || >> (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) >> result |= CPU_3DNOW_PREFETCH; >> @@ -711,6 +711,7 @@ >> static int cpu_family() { return _cpu;} >> static bool is_P6() { return cpu_family() >= 6; } >> static bool is_amd() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' >> + static bool is_hygon() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x6F677948; } // 'ogyH' >> static bool is_intel() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' >> static bool is_zx() { assert_is_initialized(); return (_cpuid_info.std_vendor_name_0 == 0x746e6543) || (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS ' >> static bool is_atom_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton >> @@ -734,7 +735,7 @@ >> if (!supports_topology || result == 0) { >> result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); >> } >> - } else if (is_amd()) { >> + } else if (is_amd() || is_hygon()) { >> result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); >> } else if (is_zx()) { >> bool supports_topology = supports_processor_topology(); >> @@ -770,7 +771,7 @@ >> intx result = 0; >> if (is_intel()) { >> result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >> - } else if (is_amd()) { >> + } else if (is_amd() || is_hygon()) { >> result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; >> } else if (is_zx()) { >> result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >> @@ -857,7 +858,7 @@ >> // AMD features >> static bool supports_3dnow_prefetch() { return (_features & CPU_3DNOW_PREFETCH) != 0; } >> - static bool supports_mmx_ext() { return is_amd() && _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >> + static bool supports_mmx_ext() { return (is_amd()||is_hygon()) && _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >> static bool supports_lzcnt() { return (_features & CPU_LZCNT) != 0; } >> static bool supports_sse4a() { return (_features & CPU_SSE4A) != 0; } >> @@ -870,7 +871,7 @@ >> } >> static bool supports_tscinv() { >> return supports_tscinv_bit() && >> - ( (is_amd() && !is_amd_Barcelona()) || >> + ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || >> is_intel_tsc_synched_at_init() ); >> } >> @@ -896,7 +897,7 @@ >> // Core - 256 / prefetchnta >> // It will be used only when AllocatePrefetchStyle > 0 >> - if (is_amd()) { // AMD >> + if (is_amd() || is_hygon()) { // AMD >> if (supports_sse2()) { >> return 256; // Opteron >> } else { From vladimir.kozlov at oracle.com Wed Apr 10 16:33:39 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 10 Apr 2019 09:33:39 -0700 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <571f3d72-a22a-3b52-2942-6408072e353f@oracle.com> <144af13e-33e2-2089-f8d2-902e94485eb1@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> Message-ID: Okay, I see what you did. But it seems incomplete. You did not set continue_pc for some platforms. Why? 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. Thanks, Vladimir On 4/9/19 8:08 PM, Jamsheed wrote: > Hi Vladimir, > > Thank you for looking at this. > > On 10/04/19 4:01 AM, Vladimir Kozlov wrote: >> Hi Jamsheed, >> >> Instead of finding PC in stubs we should use something similar to GuardUnsafeAccess to set >> thread's doing_unsafe_access flag when we call copy stub for unsafe memory as you suggested first >> (in bug report). >> >> Interpreter set the flag for Unsafe.CopyMemory0() and Unsafe.copySwapMemory0(). C2 has intrinsic >> only for CopyMemory0(): >> >> http://hg.openjdk.java.net/jdk/jdk/file/6ad0281a654e/src/hotspot/share/opto/library_call.cpp#l4189 >> >> It only use unsafe_arraycopy stab: >> >> http://hg.openjdk.java.net/jdk/jdk/file/6ad0281a654e/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#l2434 >> >> >> Setting on it's entry and cleaning on exit Thread::_doing_unsafe_access field should be enough. >> Right? >> >> Or I am missing something? > > initially thought of implementing it that way[1], but as it is having both store and volatile > semantics went with this zero overhead solution. > > also, that doesn't provide me? continuation pc, which is required for fast exit for bulkaccess? or > even for graceful exit in platform like arm. > >> >> An other thing which bothering me is Harold's comment: >> >> "Unfortunately, "CompiledMethod* nm" gets set to NULL and so handle_unsafe_access() is not executed." >> >> Where/why nm is NULLed? > as we are in BufferBlob/RuntimeBlob(stub frame). >> >> Actually I think the whole code for "// BugId 4454115" is questionable since it replaces any crash >> (most likely not related to unsafe access) in compiled method which has at least one unsafe access >> with exception. May be we should use PcDesc to record unsafe instructions and compare with SEGV >> PC. But it is separate RFE. For this one we need to fix only Unsafe.CopyMemory0() C2 inrinsic. > > Right, Ok. > > Best regards, > > Jamsheed > >> >> Thanks, >> Vladimir >> > [1]http://cr.openjdk.java.net/~jcm/8191278/webrev.00/src/hotspot/share/opto/library_call.cpp.udiff.html >> On 4/8/19 4:21 AM, Tobias Hartmann wrote: >>> Hi Jamsheed, >>> >>> On 05.04.19 15:11, Jamsheed wrote: >>>> On 04/04/19 7:23 PM, Andrew Haley wrote: >>>>>> this looks reasonable to me although the code is getting quite complicated to handle this edge >>>>>> case. >>>>> Yeah, it really is. Can't we just assume that *any* fault in these stubs is >>>>> caused via Unsafe, and get rid of bool unsafe_copy_code_range? >>>> >>>> Thanks for the feedback Tobias, Andrew, removed unsafe_copy_code_range. >>>> >>>> webrev: http://cr.openjdk.java.net/~jcm/8191278/webrev.04/ >>> >>> I think what Andrew meant is basically to go with webrev.01: >>> http://cr.openjdk.java.net/~jcm/8191278/webrev.01/ >>> >>> Right? >>> >>> Thanks, >>> Tobias >>> From vladimir.kozlov at oracle.com Wed Apr 10 16:41:17 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 10 Apr 2019 09:41:17 -0700 Subject: [PATCH v3] JDK-8222090: Add Hygon Dhyana support In-Reply-To: <8eb195a5-900d-6adb-3b10-fbef47c3dbff@oracle.com> References: <8eb195a5-900d-6adb-3b10-fbef47c3dbff@oracle.com> Message-ID: <5edf2eea-93ee-aae5-fac5-db6d92cee9e2@oracle.com> Instead of repeated is_amd() || is_hygon() you can use is_amd_or_hygon() to be more clean. Next check should be explicit for CPU: + // Some defaults for AMD family 17h || Hygon family 18h + if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { --- + // Some defaults for AMD family 17h || Hygon family 18h + if ( (cpu_family() == 0x17) && is_amd() || (cpu_family() == 0x18) && is_hygon()) { Thanks, Vladimir On 4/10/19 12:33 AM, David Holmes wrote: > Hi Fanjinke, > > This looks fine to me. I've updated the webrev at: > > http://cr.openjdk.java.net/~dholmes/8222090/webrev.v3/ > > We need a second reviewer before I push it. > > Thanks, > David > > On 9/04/2019 5:22 pm, Jinke Fan wrote: >> diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp b/src/hotspot/cpu/x86/assembler_x86.cpp >> --- a/src/hotspot/cpu/x86/assembler_x86.cpp >> +++ b/src/hotspot/cpu/x86/assembler_x86.cpp >> @@ -3099,7 +3099,7 @@ >> ????? } >> ????? return; >> ??? } >> -? if (UseAddressNop && VM_Version::is_amd()) { >> +? if (UseAddressNop && (VM_Version::is_amd() || VM_Version::is_hygon())) { >> ????? // >> ????? // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. >> ????? //? 1: 0x90 >> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> @@ -340,6 +340,10 @@ >> ????? return !is_amd_Barcelona(); >> ??? } >> >> +? if (is_hygon()) { >> +??? return true; >> +? } >> + >> ??? return false; >> ??} >> >> @@ -407,6 +411,10 @@ >> ????? } >> ????? return _family_id_intel[cpu_family_id]; >> ??? } >> +? if (is_hygon()) { >> +????? return "Dhyana"; >> +? } >> + >> ??? return "Unknown x86"; >> ??} >> >> @@ -423,6 +431,9 @@ >> ??? } else if (is_amd()) { >> ????? cpu_type = "AMD"; >> ????? x64 = cpu_is_em64t() ? " AMD64" : ""; >> +? } else if (is_hygon()) { >> +?????? cpu_type = "Hygon"; >> +?????? x64 = cpu_is_em64t() ? " AMD64" : ""; >> ??? } else { >> ????? cpu_type = "Unknown x86"; >> ????? x64 = cpu_is_em64t() ? " x86_64" : ""; >> diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp b/src/hotspot/cpu/x86/vm_version_x86.cpp >> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp >> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >> @@ -1165,7 +1165,7 @@ >> ????? } >> ??? } >> >> -? if( is_amd() ) { // AMD cpus specific settings >> +? if( is_amd() || is_hygon() ) { // AMD cpus specific settings >> ????? if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { >> ??????? // Use it on new AMD cpus starting from Opteron. >> ??????? UseAddressNop = true; >> @@ -1239,8 +1239,8 @@ >> ????? } >> ??#endif // COMPILER2 >> >> -??? // Some defaults for AMD family 17h >> -??? if ( cpu_family() == 0x17 ) { >> +??? // Some defaults for AMD family 17h || Hygon family 18h >> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >> ??????? // On family 17h processors use XMM and UnalignedLoadStores for Array Copy >> ??????? if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >> ????????? FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >> diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp b/src/hotspot/cpu/x86/vm_version_x86.hpp >> --- a/src/hotspot/cpu/x86/vm_version_x86.hpp >> +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp >> @@ -495,13 +495,13 @@ >> ??????? result |= CPU_CX8; >> ????? if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) >> ??????? result |= CPU_CMOV; >> -??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && >> +??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() || is_hygon()) && >> ????????? _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) >> ??????? result |= CPU_FXSR; >> ????? // HT flag is set for multi-core processors also. >> ????? if (threads_per_core() > 1) >> ??????? result |= CPU_HT; >> -??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && >> +??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() || is_hygon()) && >> ????????? _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) >> ??????? result |= CPU_MMX; >> ????? if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) >> @@ -576,8 +576,8 @@ >> ????? if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >> ??????? result |= CPU_FMA; >> >> -??? // AMD features. >> -??? if (is_amd()) { >> +??? // AMD|Hygon features. >> +??? if (is_amd() || is_hygon()) { >> ??????? if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || >> ??????????? (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) >> ????????? result |= CPU_3DNOW_PREFETCH; >> @@ -711,6 +711,7 @@ >> ??? static int? cpu_family()??????? { return _cpu;} >> ??? static bool is_P6()???????????? { return cpu_family() >= 6; } >> ??? static bool is_amd()??????????? { assert_is_initialized(); return >> _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' >> +? static bool is_hygon()????????? { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 >> == 0x6F677948; } // 'ogyH' >> ??? static bool is_intel()????????? { assert_is_initialized(); return >> _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' >> ??? static bool is_zx()???????????? { assert_is_initialized(); return >> (_cpuid_info.std_vendor_name_0 == 0x746e6543) || (_cpuid_info.std_vendor_name_0 == 0x68532020); } >> // 'tneC'||'hS? ' >> ??? static bool is_atom_family()??? { return ((cpu_family() == 0x06) && ((extended_cpu_model() == >> 0x36) || (extended_cpu_model() == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont and >> Centerton >> @@ -734,7 +735,7 @@ >> ??????? if (!supports_topology || result == 0) { >> ????????? result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); >> ??????? } >> -??? } else if (is_amd()) { >> +??? } else if (is_amd() || is_hygon()) { >> ??????? result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); >> ????? } else if (is_zx()) { >> ??????? bool supports_topology = supports_processor_topology(); >> @@ -770,7 +771,7 @@ >> ????? intx result = 0; >> ????? if (is_intel()) { >> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >> -??? } else if (is_amd()) { >> +??? } else if (is_amd() || is_hygon()) { >> ??????? result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; >> ????? } else if (is_zx()) { >> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >> @@ -857,7 +858,7 @@ >> >> ??? // AMD features >> ??? static bool supports_3dnow_prefetch()??? { return (_features & CPU_3DNOW_PREFETCH) != 0; } >> -? static bool supports_mmx_ext()? { return is_amd() && _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != >> 0; } >> +? static bool supports_mmx_ext()? { return (is_amd()||is_hygon()) && >> _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >> ??? static bool supports_lzcnt()??? { return (_features & CPU_LZCNT) != 0; } >> ??? static bool supports_sse4a()??? { return (_features & CPU_SSE4A) != 0; } >> >> @@ -870,7 +871,7 @@ >> ??? } >> ??? static bool supports_tscinv() { >> ????? return supports_tscinv_bit() && >> -?????????? ( (is_amd() && !is_amd_Barcelona()) || >> +?????????? ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || >> ?????????????? is_intel_tsc_synched_at_init() ); >> ??? } >> >> @@ -896,7 +897,7 @@ >> ????? // Core????? - 256 / prefetchnta >> ????? // It will be used only when AllocatePrefetchStyle > 0 >> >> -??? if (is_amd()) { // AMD >> +??? if (is_amd() || is_hygon()) { // AMD >> ??????? if (supports_sse2()) { >> ????????? return 256; // Opteron >> ??????? } else { From vladimir.kozlov at oracle.com Wed Apr 10 16:48:24 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 10 Apr 2019 09:48:24 -0700 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <57ab78e9-4a18-f47f-5a03-dfbf916722fd@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <571f3d72-a22a-3b52-2942-6408072e353f@oracle.com> <144af13e-33e2-2089-f8d2-902e94485eb1@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> <57ab78e9-4a18-f47f-5a03-dfbf916722fd@oracle.com> Message-ID: <878a27e7-f0c9-a65d-ba36-667ab9eb2fca@oracle.com> Okay ;-) Vladimir On 4/9/19 10:31 PM, Jamsheed wrote: > Hi Vladimir, > > John Rose comments about this issue here. > > Adding a mechanism for more precisely mapping the locations of unsafe > memory operations would be more complex (though doable). It would tend > to reduce the optimization level of code which uses unsafe operations. > Therefore, I think the present imprecise design is preferable. > > john.rose at Eng 2001-05-11 > > https://bugs.openjdk.java.net/browse/JDK-4454115 > > Best regards, > > Jamsheed > > > On 10/04/19 4:01 AM, Vladimir Kozlov wrote: >> 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. From igor.ignatyev at oracle.com Wed Apr 10 18:10:44 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 10 Apr 2019 11:10:44 -0700 Subject: RFR(M/S) : 8222154 : upgrade gtest to 1.8.1 In-Reply-To: References: Message-ID: <0C5E424C-C68B-48E9-B47F-16A9270D21D2@oracle.com> 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 jamsheed.c.m at oracle.com Wed Apr 10 23:47:10 2019 From: jamsheed.c.m at oracle.com (Jamsheed) Date: Thu, 11 Apr 2019 05:17:10 +0530 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <571f3d72-a22a-3b52-2942-6408072e353f@oracle.com> <144af13e-33e2-2089-f8d2-902e94485eb1@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> Message-ID: <95af6958-6512-d894-2076-74f1b68e3dbe@oracle.com> 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 Thu Apr 11 01:08:09 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Apr 2019 11:08:09 +1000 Subject: [PATCH v3] JDK-8222090: Add Hygon Dhyana support In-Reply-To: <0f915983-8e30-9ef7-1a55-3d9b26ee5a87@oracle.com> References: <8eb195a5-900d-6adb-3b10-fbef47c3dbff@oracle.com> <35225ad6-1dbd-fd83-0232-0f8609853b46@yeah.net> <0f915983-8e30-9ef7-1a55-3d9b26ee5a87@oracle.com> Message-ID: Hi Coleen, On 10/04/2019 11:34 pm, coleen.phillimore at oracle.com wrote: > > This seems okay but there's a lot of cpu specific code in os_linux.cpp. > I assume #ifdef AMD64 is true, and the printing is correct in an > hs_err_pid file? AMD64 is set for all 64-bit x86 platforms (it is a historical relic that we still use AMD64) - from make/autoconf/platform.m4: elif test "x$OPENJDK_$1_CPU" = xx86_64; then HOTSPOT_$1_CPU_DEFINE=AMD64 These CPU-family related changes are at a lower level. The hs_err file will contain the information as updated in vm_version_x86.* Thanks, David ----- > Thanks, > Coleen > > On 4/10/19 4:00 AM, Jinke Fan wrote: >> Hi David, >> ? Thanks for the review. >> >> Best Regards! >> Fanjinke >> >> On 2019/4/10 15:33, David Holmes wrote: >>> Hi Fanjinke, >>> >>> This looks fine to me. I've updated the webrev at: >>> >>> http://cr.openjdk.java.net/~dholmes/8222090/webrev.v3/ >>> >>> We need a second reviewer before I push it. >>> >>> Thanks, >>> David >>> >>> On 9/04/2019 5:22 pm, Jinke Fan wrote: >>>> diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp >>>> b/src/hotspot/cpu/x86/assembler_x86.cpp >>>> --- a/src/hotspot/cpu/x86/assembler_x86.cpp >>>> +++ b/src/hotspot/cpu/x86/assembler_x86.cpp >>>> @@ -3099,7 +3099,7 @@ >>>> ????? } >>>> ????? return; >>>> ??? } >>>> -? if (UseAddressNop && VM_Version::is_amd()) { >>>> +? if (UseAddressNop && (VM_Version::is_amd() || >>>> VM_Version::is_hygon())) { >>>> ????? // >>>> ????? // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. >>>> ????? //? 1: 0x90 >>>> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>> b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>> @@ -340,6 +340,10 @@ >>>> ????? return !is_amd_Barcelona(); >>>> ??? } >>>> >>>> +? if (is_hygon()) { >>>> +??? return true; >>>> +? } >>>> + >>>> ??? return false; >>>> ??} >>>> >>>> @@ -407,6 +411,10 @@ >>>> ????? } >>>> ????? return _family_id_intel[cpu_family_id]; >>>> ??? } >>>> +? if (is_hygon()) { >>>> +????? return "Dhyana"; >>>> +? } >>>> + >>>> ??? return "Unknown x86"; >>>> ??} >>>> >>>> @@ -423,6 +431,9 @@ >>>> ??? } else if (is_amd()) { >>>> ????? cpu_type = "AMD"; >>>> ????? x64 = cpu_is_em64t() ? " AMD64" : ""; >>>> +? } else if (is_hygon()) { >>>> +?????? cpu_type = "Hygon"; >>>> +?????? x64 = cpu_is_em64t() ? " AMD64" : ""; >>>> ??? } else { >>>> ????? cpu_type = "Unknown x86"; >>>> ????? x64 = cpu_is_em64t() ? " x86_64" : ""; >>>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp >>>> b/src/hotspot/cpu/x86/vm_version_x86.cpp >>>> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp >>>> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >>>> @@ -1165,7 +1165,7 @@ >>>> ????? } >>>> ??? } >>>> >>>> -? if( is_amd() ) { // AMD cpus specific settings >>>> +? if( is_amd() || is_hygon() ) { // AMD cpus specific settings >>>> ????? if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { >>>> ??????? // Use it on new AMD cpus starting from Opteron. >>>> ??????? UseAddressNop = true; >>>> @@ -1239,8 +1239,8 @@ >>>> ????? } >>>> ??#endif // COMPILER2 >>>> >>>> -??? // Some defaults for AMD family 17h >>>> -??? if ( cpu_family() == 0x17 ) { >>>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>>> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >>>> ??????? // On family 17h processors use XMM and UnalignedLoadStores >>>> for Array Copy >>>> ??????? if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >>>> ????????? FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >>>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp >>>> b/src/hotspot/cpu/x86/vm_version_x86.hpp >>>> --- a/src/hotspot/cpu/x86/vm_version_x86.hpp >>>> +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp >>>> @@ -495,13 +495,13 @@ >>>> ??????? result |= CPU_CX8; >>>> ????? if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) >>>> ??????? result |= CPU_CMOV; >>>> -??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && >>>> +??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() || >>>> is_hygon()) && >>>> ????????? _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) >>>> ??????? result |= CPU_FXSR; >>>> ????? // HT flag is set for multi-core processors also. >>>> ????? if (threads_per_core() > 1) >>>> ??????? result |= CPU_HT; >>>> -??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && >>>> +??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() || >>>> is_hygon()) && >>>> ????????? _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) >>>> ??????? result |= CPU_MMX; >>>> ????? if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) >>>> @@ -576,8 +576,8 @@ >>>> ????? if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>> ??????? result |= CPU_FMA; >>>> >>>> -??? // AMD features. >>>> -??? if (is_amd()) { >>>> +??? // AMD|Hygon features. >>>> +??? if (is_amd() || is_hygon()) { >>>> ??????? if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || >>>> ??????????? (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) >>>> ????????? result |= CPU_3DNOW_PREFETCH; >>>> @@ -711,6 +711,7 @@ >>>> ??? static int? cpu_family()??????? { return _cpu;} >>>> ??? static bool is_P6()???????????? { return cpu_family() >= 6; } >>>> ??? static bool is_amd()??????????? { assert_is_initialized(); >>>> return _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' >>>> +? static bool is_hygon()????????? { assert_is_initialized(); return >>>> _cpuid_info.std_vendor_name_0 == 0x6F677948; } // 'ogyH' >>>> ??? static bool is_intel()????????? { assert_is_initialized(); >>>> return _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' >>>> ??? static bool is_zx()???????????? { assert_is_initialized(); >>>> return (_cpuid_info.std_vendor_name_0 == 0x746e6543) || >>>> (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS? ' >>>> ??? static bool is_atom_family()??? { return ((cpu_family() == 0x06) >>>> && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) >>>> || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton >>>> @@ -734,7 +735,7 @@ >>>> ??????? if (!supports_topology || result == 0) { >>>> ????????? result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); >>>> ??????? } >>>> -??? } else if (is_amd()) { >>>> +??? } else if (is_amd() || is_hygon()) { >>>> ??????? result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); >>>> ????? } else if (is_zx()) { >>>> ??????? bool supports_topology = supports_processor_topology(); >>>> @@ -770,7 +771,7 @@ >>>> ????? intx result = 0; >>>> ????? if (is_intel()) { >>>> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>>> -??? } else if (is_amd()) { >>>> +??? } else if (is_amd() || is_hygon()) { >>>> ??????? result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; >>>> ????? } else if (is_zx()) { >>>> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>>> @@ -857,7 +858,7 @@ >>>> >>>> ??? // AMD features >>>> ??? static bool supports_3dnow_prefetch()??? { return (_features & >>>> CPU_3DNOW_PREFETCH) != 0; } >>>> -? static bool supports_mmx_ext()? { return is_amd() && >>>> _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >>>> +? static bool supports_mmx_ext()? { return (is_amd()||is_hygon()) >>>> && _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >>>> ??? static bool supports_lzcnt()??? { return (_features & CPU_LZCNT) >>>> != 0; } >>>> ??? static bool supports_sse4a()??? { return (_features & CPU_SSE4A) >>>> != 0; } >>>> >>>> @@ -870,7 +871,7 @@ >>>> ??? } >>>> ??? static bool supports_tscinv() { >>>> ????? return supports_tscinv_bit() && >>>> -?????????? ( (is_amd() && !is_amd_Barcelona()) || >>>> +?????????? ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || >>>> ?????????????? is_intel_tsc_synched_at_init() ); >>>> ??? } >>>> >>>> @@ -896,7 +897,7 @@ >>>> ????? // Core????? - 256 / prefetchnta >>>> ????? // It will be used only when AllocatePrefetchStyle > 0 >>>> >>>> -??? if (is_amd()) { // AMD >>>> +??? if (is_amd() || is_hygon()) { // AMD >>>> ??????? if (supports_sse2()) { >>>> ????????? return 256; // Opteron >>>> ??????? } else { >>> >> > From david.holmes at oracle.com Thu Apr 11 01:08:53 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Apr 2019 11:08:53 +1000 Subject: [PATCH v3] JDK-8222090: Add Hygon Dhyana support In-Reply-To: <0BDEF291-433E-4133-B208-2678E251FA49@oracle.com> References: <8eb195a5-900d-6adb-3b10-fbef47c3dbff@oracle.com> <0BDEF291-433E-4133-B208-2678E251FA49@oracle.com> Message-ID: <297f0f5c-291a-7247-9b65-71c72f864b9f@oracle.com> Hi Robin, On 11/04/2019 12:02 am, Robin Westberg wrote: > Hi David, > >> On 10 Apr 2019, at 09:33, David Holmes wrote: >> >> Hi Fanjinke, >> >> This looks fine to me. I've updated the webrev at: >> >> http://cr.openjdk.java.net/~dholmes/8222090/webrev.v3/ >> >> We need a second reviewer before I push it. > > This looks good to me. One very minor nit: > > vm_version_x86.hpp: > 877 ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || Will fix. Thanks for looking at it. David ----- > All the other instances of this comparison has spaces around the ?||"s.. > > Best regards, > Robin (not a Reviewer) > >> >> Thanks, >> David >> >> On 9/04/2019 5:22 pm, Jinke Fan wrote: >>> diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp b/src/hotspot/cpu/x86/assembler_x86.cpp >>> --- a/src/hotspot/cpu/x86/assembler_x86.cpp >>> +++ b/src/hotspot/cpu/x86/assembler_x86.cpp >>> @@ -3099,7 +3099,7 @@ >>> } >>> return; >>> } >>> - if (UseAddressNop && VM_Version::is_amd()) { >>> + if (UseAddressNop && (VM_Version::is_amd() || VM_Version::is_hygon())) { >>> // >>> // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. >>> // 1: 0x90 >>> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>> @@ -340,6 +340,10 @@ >>> return !is_amd_Barcelona(); >>> } >>> + if (is_hygon()) { >>> + return true; >>> + } >>> + >>> return false; >>> } >>> @@ -407,6 +411,10 @@ >>> } >>> return _family_id_intel[cpu_family_id]; >>> } >>> + if (is_hygon()) { >>> + return "Dhyana"; >>> + } >>> + >>> return "Unknown x86"; >>> } >>> @@ -423,6 +431,9 @@ >>> } else if (is_amd()) { >>> cpu_type = "AMD"; >>> x64 = cpu_is_em64t() ? " AMD64" : ""; >>> + } else if (is_hygon()) { >>> + cpu_type = "Hygon"; >>> + x64 = cpu_is_em64t() ? " AMD64" : ""; >>> } else { >>> cpu_type = "Unknown x86"; >>> x64 = cpu_is_em64t() ? " x86_64" : ""; >>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp b/src/hotspot/cpu/x86/vm_version_x86.cpp >>> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp >>> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >>> @@ -1165,7 +1165,7 @@ >>> } >>> } >>> - if( is_amd() ) { // AMD cpus specific settings >>> + if( is_amd() || is_hygon() ) { // AMD cpus specific settings >>> if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { >>> // Use it on new AMD cpus starting from Opteron. >>> UseAddressNop = true; >>> @@ -1239,8 +1239,8 @@ >>> } >>> #endif // COMPILER2 >>> - // Some defaults for AMD family 17h >>> - if ( cpu_family() == 0x17 ) { >>> + // Some defaults for AMD family 17h || Hygon family 18h >>> + if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >>> // On family 17h processors use XMM and UnalignedLoadStores for Array Copy >>> if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >>> FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp b/src/hotspot/cpu/x86/vm_version_x86.hpp >>> --- a/src/hotspot/cpu/x86/vm_version_x86.hpp >>> +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp >>> @@ -495,13 +495,13 @@ >>> result |= CPU_CX8; >>> if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) >>> result |= CPU_CMOV; >>> - if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && >>> + if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() || is_hygon()) && >>> _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) >>> result |= CPU_FXSR; >>> // HT flag is set for multi-core processors also. >>> if (threads_per_core() > 1) >>> result |= CPU_HT; >>> - if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && >>> + if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() || is_hygon()) && >>> _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) >>> result |= CPU_MMX; >>> if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) >>> @@ -576,8 +576,8 @@ >>> if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>> result |= CPU_FMA; >>> - // AMD features. >>> - if (is_amd()) { >>> + // AMD|Hygon features. >>> + if (is_amd() || is_hygon()) { >>> if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || >>> (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) >>> result |= CPU_3DNOW_PREFETCH; >>> @@ -711,6 +711,7 @@ >>> static int cpu_family() { return _cpu;} >>> static bool is_P6() { return cpu_family() >= 6; } >>> static bool is_amd() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' >>> + static bool is_hygon() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x6F677948; } // 'ogyH' >>> static bool is_intel() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' >>> static bool is_zx() { assert_is_initialized(); return (_cpuid_info.std_vendor_name_0 == 0x746e6543) || (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS ' >>> static bool is_atom_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton >>> @@ -734,7 +735,7 @@ >>> if (!supports_topology || result == 0) { >>> result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); >>> } >>> - } else if (is_amd()) { >>> + } else if (is_amd() || is_hygon()) { >>> result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); >>> } else if (is_zx()) { >>> bool supports_topology = supports_processor_topology(); >>> @@ -770,7 +771,7 @@ >>> intx result = 0; >>> if (is_intel()) { >>> result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>> - } else if (is_amd()) { >>> + } else if (is_amd() || is_hygon()) { >>> result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; >>> } else if (is_zx()) { >>> result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>> @@ -857,7 +858,7 @@ >>> // AMD features >>> static bool supports_3dnow_prefetch() { return (_features & CPU_3DNOW_PREFETCH) != 0; } >>> - static bool supports_mmx_ext() { return is_amd() && _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >>> + static bool supports_mmx_ext() { return (is_amd()||is_hygon()) && _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >>> static bool supports_lzcnt() { return (_features & CPU_LZCNT) != 0; } >>> static bool supports_sse4a() { return (_features & CPU_SSE4A) != 0; } >>> @@ -870,7 +871,7 @@ >>> } >>> static bool supports_tscinv() { >>> return supports_tscinv_bit() && >>> - ( (is_amd() && !is_amd_Barcelona()) || >>> + ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || >>> is_intel_tsc_synched_at_init() ); >>> } >>> @@ -896,7 +897,7 @@ >>> // Core - 256 / prefetchnta >>> // It will be used only when AllocatePrefetchStyle > 0 >>> - if (is_amd()) { // AMD >>> + if (is_amd() || is_hygon()) { // AMD >>> if (supports_sse2()) { >>> return 256; // Opteron >>> } else { > From david.holmes at oracle.com Thu Apr 11 01:14:37 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Apr 2019 11:14:37 +1000 Subject: [PATCH v3] JDK-8222090: Add Hygon Dhyana support In-Reply-To: <5edf2eea-93ee-aae5-fac5-db6d92cee9e2@oracle.com> References: <8eb195a5-900d-6adb-3b10-fbef47c3dbff@oracle.com> <5edf2eea-93ee-aae5-fac5-db6d92cee9e2@oracle.com> Message-ID: Hi Vladimir, Thanks for taking look at this. On 11/04/2019 2:41 am, Vladimir Kozlov wrote: > Instead of repeated is_amd() || is_hygon() you can use is_amd_or_hygon() > to be more clean. That doesn't really scale if we get more "cousins" joining the AMD family. I prefer to see the explicit disjunction form. > Next check should be explicit for CPU: > > +??? // Some defaults for AMD family 17h || Hygon family 18h > +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { > > --- > > +??? // Some defaults for AMD family 17h || Hygon family 18h > +??? if ( (cpu_family() == 0x17) && is_amd() || (cpu_family() == 0x18) > && is_hygon()) { I'm wondering if that should just be an assertion? I would not expect it to be possible to have a family 0x17 that is not AMD and likewise for family 0x18 and Hygon. But then I don't know how these family ids get issued. ?? Thanks, David > Thanks, > Vladimir > > On 4/10/19 12:33 AM, David Holmes wrote: >> Hi Fanjinke, >> >> This looks fine to me. I've updated the webrev at: >> >> http://cr.openjdk.java.net/~dholmes/8222090/webrev.v3/ >> >> We need a second reviewer before I push it. >> >> Thanks, >> David >> >> On 9/04/2019 5:22 pm, Jinke Fan wrote: >>> diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp >>> b/src/hotspot/cpu/x86/assembler_x86.cpp >>> --- a/src/hotspot/cpu/x86/assembler_x86.cpp >>> +++ b/src/hotspot/cpu/x86/assembler_x86.cpp >>> @@ -3099,7 +3099,7 @@ >>> ????? } >>> ????? return; >>> ??? } >>> -? if (UseAddressNop && VM_Version::is_amd()) { >>> +? if (UseAddressNop && (VM_Version::is_amd() || >>> VM_Version::is_hygon())) { >>> ????? // >>> ????? // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. >>> ????? //? 1: 0x90 >>> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>> b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>> @@ -340,6 +340,10 @@ >>> ????? return !is_amd_Barcelona(); >>> ??? } >>> >>> +? if (is_hygon()) { >>> +??? return true; >>> +? } >>> + >>> ??? return false; >>> ??} >>> >>> @@ -407,6 +411,10 @@ >>> ????? } >>> ????? return _family_id_intel[cpu_family_id]; >>> ??? } >>> +? if (is_hygon()) { >>> +????? return "Dhyana"; >>> +? } >>> + >>> ??? return "Unknown x86"; >>> ??} >>> >>> @@ -423,6 +431,9 @@ >>> ??? } else if (is_amd()) { >>> ????? cpu_type = "AMD"; >>> ????? x64 = cpu_is_em64t() ? " AMD64" : ""; >>> +? } else if (is_hygon()) { >>> +?????? cpu_type = "Hygon"; >>> +?????? x64 = cpu_is_em64t() ? " AMD64" : ""; >>> ??? } else { >>> ????? cpu_type = "Unknown x86"; >>> ????? x64 = cpu_is_em64t() ? " x86_64" : ""; >>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp >>> b/src/hotspot/cpu/x86/vm_version_x86.cpp >>> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp >>> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >>> @@ -1165,7 +1165,7 @@ >>> ????? } >>> ??? } >>> >>> -? if( is_amd() ) { // AMD cpus specific settings >>> +? if( is_amd() || is_hygon() ) { // AMD cpus specific settings >>> ????? if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { >>> ??????? // Use it on new AMD cpus starting from Opteron. >>> ??????? UseAddressNop = true; >>> @@ -1239,8 +1239,8 @@ >>> ????? } >>> ??#endif // COMPILER2 >>> >>> -??? // Some defaults for AMD family 17h >>> -??? if ( cpu_family() == 0x17 ) { >>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >>> ??????? // On family 17h processors use XMM and UnalignedLoadStores >>> for Array Copy >>> ??????? if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >>> ????????? FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp >>> b/src/hotspot/cpu/x86/vm_version_x86.hpp >>> --- a/src/hotspot/cpu/x86/vm_version_x86.hpp >>> +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp >>> @@ -495,13 +495,13 @@ >>> ??????? result |= CPU_CX8; >>> ????? if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) >>> ??????? result |= CPU_CMOV; >>> -??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && >>> +??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() || >>> is_hygon()) && >>> ????????? _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) >>> ??????? result |= CPU_FXSR; >>> ????? // HT flag is set for multi-core processors also. >>> ????? if (threads_per_core() > 1) >>> ??????? result |= CPU_HT; >>> -??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && >>> +??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() || >>> is_hygon()) && >>> ????????? _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) >>> ??????? result |= CPU_MMX; >>> ????? if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) >>> @@ -576,8 +576,8 @@ >>> ????? if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>> ??????? result |= CPU_FMA; >>> >>> -??? // AMD features. >>> -??? if (is_amd()) { >>> +??? // AMD|Hygon features. >>> +??? if (is_amd() || is_hygon()) { >>> ??????? if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || >>> ??????????? (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) >>> ????????? result |= CPU_3DNOW_PREFETCH; >>> @@ -711,6 +711,7 @@ >>> ??? static int? cpu_family()??????? { return _cpu;} >>> ??? static bool is_P6()???????????? { return cpu_family() >= 6; } >>> ??? static bool is_amd()??????????? { assert_is_initialized(); return >>> _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' >>> +? static bool is_hygon()????????? { assert_is_initialized(); return >>> _cpuid_info.std_vendor_name_0 == 0x6F677948; } // 'ogyH' >>> ??? static bool is_intel()????????? { assert_is_initialized(); return >>> _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' >>> ??? static bool is_zx()???????????? { assert_is_initialized(); return >>> (_cpuid_info.std_vendor_name_0 == 0x746e6543) || >>> (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS? ' >>> ??? static bool is_atom_family()??? { return ((cpu_family() == 0x06) >>> && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) >>> || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton >>> @@ -734,7 +735,7 @@ >>> ??????? if (!supports_topology || result == 0) { >>> ????????? result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); >>> ??????? } >>> -??? } else if (is_amd()) { >>> +??? } else if (is_amd() || is_hygon()) { >>> ??????? result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); >>> ????? } else if (is_zx()) { >>> ??????? bool supports_topology = supports_processor_topology(); >>> @@ -770,7 +771,7 @@ >>> ????? intx result = 0; >>> ????? if (is_intel()) { >>> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>> -??? } else if (is_amd()) { >>> +??? } else if (is_amd() || is_hygon()) { >>> ??????? result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; >>> ????? } else if (is_zx()) { >>> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>> @@ -857,7 +858,7 @@ >>> >>> ??? // AMD features >>> ??? static bool supports_3dnow_prefetch()??? { return (_features & >>> CPU_3DNOW_PREFETCH) != 0; } >>> -? static bool supports_mmx_ext()? { return is_amd() && >>> _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >>> +? static bool supports_mmx_ext()? { return (is_amd()||is_hygon()) && >>> _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >>> ??? static bool supports_lzcnt()??? { return (_features & CPU_LZCNT) >>> != 0; } >>> ??? static bool supports_sse4a()??? { return (_features & CPU_SSE4A) >>> != 0; } >>> >>> @@ -870,7 +871,7 @@ >>> ??? } >>> ??? static bool supports_tscinv() { >>> ????? return supports_tscinv_bit() && >>> -?????????? ( (is_amd() && !is_amd_Barcelona()) || >>> +?????????? ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || >>> ?????????????? is_intel_tsc_synched_at_init() ); >>> ??? } >>> >>> @@ -896,7 +897,7 @@ >>> ????? // Core????? - 256 / prefetchnta >>> ????? // It will be used only when AllocatePrefetchStyle > 0 >>> >>> -??? if (is_amd()) { // AMD >>> +??? if (is_amd() || is_hygon()) { // AMD >>> ??????? if (supports_sse2()) { >>> ????????? return 256; // Opteron >>> ??????? } else { From vladimir.kozlov at oracle.com Thu Apr 11 02:48:09 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 10 Apr 2019 19:48:09 -0700 Subject: [PATCH v3] JDK-8222090: Add Hygon Dhyana support In-Reply-To: References: <8eb195a5-900d-6adb-3b10-fbef47c3dbff@oracle.com> <5edf2eea-93ee-aae5-fac5-db6d92cee9e2@oracle.com> Message-ID: On 4/10/19 6:14 PM, David Holmes wrote: > Hi Vladimir, > > Thanks for taking look at this. > > On 11/04/2019 2:41 am, Vladimir Kozlov wrote: >> Instead of repeated is_amd() || is_hygon() you can use is_amd_or_hygon() to be more clean. > > That doesn't really scale if we get more "cousins" joining the AMD family. I prefer to see the > explicit disjunction form. is_amd_family() ? If it was 2 or 3 cases I would agree with you. But you have 10 checks! > >> Next check should be explicit for CPU: >> >> +??? // Some defaults for AMD family 17h || Hygon family 18h >> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >> >> --- >> >> +??? // Some defaults for AMD family 17h || Hygon family 18h >> +??? if ( (cpu_family() == 0x17) && is_amd() || (cpu_family() == 0x18) && is_hygon()) { > > I'm wondering if that should just be an assertion? I would not expect it to be possible to have a > family 0x17 that is not AMD and likewise for family 0x18 and Hygon. But then I don't know how these > family ids get issued. ?? It is not clear what agreement AMD has with these companies. Any company (as AMD and Intel) may have own set of cpu_family ids and we can't assume that ids will not be reused. They have only 8 bits for ID. Thanks, Vladimir > > Thanks, > David > >> Thanks, >> Vladimir >> >> On 4/10/19 12:33 AM, David Holmes wrote: >>> Hi Fanjinke, >>> >>> This looks fine to me. I've updated the webrev at: >>> >>> http://cr.openjdk.java.net/~dholmes/8222090/webrev.v3/ >>> >>> We need a second reviewer before I push it. >>> >>> Thanks, >>> David >>> >>> On 9/04/2019 5:22 pm, Jinke Fan wrote: >>>> diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp b/src/hotspot/cpu/x86/assembler_x86.cpp >>>> --- a/src/hotspot/cpu/x86/assembler_x86.cpp >>>> +++ b/src/hotspot/cpu/x86/assembler_x86.cpp >>>> @@ -3099,7 +3099,7 @@ >>>> ????? } >>>> ????? return; >>>> ??? } >>>> -? if (UseAddressNop && VM_Version::is_amd()) { >>>> +? if (UseAddressNop && (VM_Version::is_amd() || VM_Version::is_hygon())) { >>>> ????? // >>>> ????? // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. >>>> ????? //? 1: 0x90 >>>> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>> b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>> @@ -340,6 +340,10 @@ >>>> ????? return !is_amd_Barcelona(); >>>> ??? } >>>> >>>> +? if (is_hygon()) { >>>> +??? return true; >>>> +? } >>>> + >>>> ??? return false; >>>> ??} >>>> >>>> @@ -407,6 +411,10 @@ >>>> ????? } >>>> ????? return _family_id_intel[cpu_family_id]; >>>> ??? } >>>> +? if (is_hygon()) { >>>> +????? return "Dhyana"; >>>> +? } >>>> + >>>> ??? return "Unknown x86"; >>>> ??} >>>> >>>> @@ -423,6 +431,9 @@ >>>> ??? } else if (is_amd()) { >>>> ????? cpu_type = "AMD"; >>>> ????? x64 = cpu_is_em64t() ? " AMD64" : ""; >>>> +? } else if (is_hygon()) { >>>> +?????? cpu_type = "Hygon"; >>>> +?????? x64 = cpu_is_em64t() ? " AMD64" : ""; >>>> ??? } else { >>>> ????? cpu_type = "Unknown x86"; >>>> ????? x64 = cpu_is_em64t() ? " x86_64" : ""; >>>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp b/src/hotspot/cpu/x86/vm_version_x86.cpp >>>> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp >>>> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >>>> @@ -1165,7 +1165,7 @@ >>>> ????? } >>>> ??? } >>>> >>>> -? if( is_amd() ) { // AMD cpus specific settings >>>> +? if( is_amd() || is_hygon() ) { // AMD cpus specific settings >>>> ????? if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { >>>> ??????? // Use it on new AMD cpus starting from Opteron. >>>> ??????? UseAddressNop = true; >>>> @@ -1239,8 +1239,8 @@ >>>> ????? } >>>> ??#endif // COMPILER2 >>>> >>>> -??? // Some defaults for AMD family 17h >>>> -??? if ( cpu_family() == 0x17 ) { >>>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>>> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >>>> ??????? // On family 17h processors use XMM and UnalignedLoadStores for Array Copy >>>> ??????? if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >>>> ????????? FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >>>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp b/src/hotspot/cpu/x86/vm_version_x86.hpp >>>> --- a/src/hotspot/cpu/x86/vm_version_x86.hpp >>>> +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp >>>> @@ -495,13 +495,13 @@ >>>> ??????? result |= CPU_CX8; >>>> ????? if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) >>>> ??????? result |= CPU_CMOV; >>>> -??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && >>>> +??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() || is_hygon()) && >>>> ????????? _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) >>>> ??????? result |= CPU_FXSR; >>>> ????? // HT flag is set for multi-core processors also. >>>> ????? if (threads_per_core() > 1) >>>> ??????? result |= CPU_HT; >>>> -??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && >>>> +??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() || is_hygon()) && >>>> ????????? _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) >>>> ??????? result |= CPU_MMX; >>>> ????? if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) >>>> @@ -576,8 +576,8 @@ >>>> ????? if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>> ??????? result |= CPU_FMA; >>>> >>>> -??? // AMD features. >>>> -??? if (is_amd()) { >>>> +??? // AMD|Hygon features. >>>> +??? if (is_amd() || is_hygon()) { >>>> ??????? if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || >>>> ??????????? (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) >>>> ????????? result |= CPU_3DNOW_PREFETCH; >>>> @@ -711,6 +711,7 @@ >>>> ??? static int? cpu_family()??????? { return _cpu;} >>>> ??? static bool is_P6()???????????? { return cpu_family() >= 6; } >>>> ??? static bool is_amd()??????????? { assert_is_initialized(); return >>>> _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' >>>> +? static bool is_hygon()????????? { assert_is_initialized(); return >>>> _cpuid_info.std_vendor_name_0 == 0x6F677948; } // 'ogyH' >>>> ??? static bool is_intel()????????? { assert_is_initialized(); return >>>> _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' >>>> ??? static bool is_zx()???????????? { assert_is_initialized(); return >>>> (_cpuid_info.std_vendor_name_0 == 0x746e6543) || (_cpuid_info.std_vendor_name_0 == 0x68532020); >>>> } // 'tneC'||'hS? ' >>>> ??? static bool is_atom_family()??? { return ((cpu_family() == 0x06) && ((extended_cpu_model() >>>> == 0x36) || (extended_cpu_model() == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont >>>> and Centerton >>>> @@ -734,7 +735,7 @@ >>>> ??????? if (!supports_topology || result == 0) { >>>> ????????? result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); >>>> ??????? } >>>> -??? } else if (is_amd()) { >>>> +??? } else if (is_amd() || is_hygon()) { >>>> ??????? result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); >>>> ????? } else if (is_zx()) { >>>> ??????? bool supports_topology = supports_processor_topology(); >>>> @@ -770,7 +771,7 @@ >>>> ????? intx result = 0; >>>> ????? if (is_intel()) { >>>> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>>> -??? } else if (is_amd()) { >>>> +??? } else if (is_amd() || is_hygon()) { >>>> ??????? result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; >>>> ????? } else if (is_zx()) { >>>> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>>> @@ -857,7 +858,7 @@ >>>> >>>> ??? // AMD features >>>> ??? static bool supports_3dnow_prefetch()??? { return (_features & CPU_3DNOW_PREFETCH) != 0; } >>>> -? static bool supports_mmx_ext()? { return is_amd() && _cpuid_info.ext_cpuid1_edx.bits.mmx_amd >>>> != 0; } >>>> +? static bool supports_mmx_ext()? { return (is_amd()||is_hygon()) && >>>> _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >>>> ??? static bool supports_lzcnt()??? { return (_features & CPU_LZCNT) != 0; } >>>> ??? static bool supports_sse4a()??? { return (_features & CPU_SSE4A) != 0; } >>>> >>>> @@ -870,7 +871,7 @@ >>>> ??? } >>>> ??? static bool supports_tscinv() { >>>> ????? return supports_tscinv_bit() && >>>> -?????????? ( (is_amd() && !is_amd_Barcelona()) || >>>> +?????????? ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || >>>> ?????????????? is_intel_tsc_synched_at_init() ); >>>> ??? } >>>> >>>> @@ -896,7 +897,7 @@ >>>> ????? // Core????? - 256 / prefetchnta >>>> ????? // It will be used only when AllocatePrefetchStyle > 0 >>>> >>>> -??? if (is_amd()) { // AMD >>>> +??? if (is_amd() || is_hygon()) { // AMD >>>> ??????? if (supports_sse2()) { >>>> ????????? return 256; // Opteron >>>> ??????? } else { From david.holmes at oracle.com Thu Apr 11 02:47:10 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Apr 2019 12:47:10 +1000 Subject: [PATCH v3] JDK-8222090: Add Hygon Dhyana support In-Reply-To: References: <8eb195a5-900d-6adb-3b10-fbef47c3dbff@oracle.com> <5edf2eea-93ee-aae5-fac5-db6d92cee9e2@oracle.com> Message-ID: On 11/04/2019 12:48 pm, Vladimir Kozlov wrote: > On 4/10/19 6:14 PM, David Holmes wrote: >> Hi Vladimir, >> >> Thanks for taking look at this. >> >> On 11/04/2019 2:41 am, Vladimir Kozlov wrote: >>> Instead of repeated is_amd() || is_hygon() you can use >>> is_amd_or_hygon() to be more clean. >> >> That doesn't really scale if we get more "cousins" joining the AMD >> family. I prefer to see the explicit disjunction form. > > is_amd_family() ? If it was 2 or 3 cases I would agree with you. But you > have 10 checks! is_amd_family() seems reasonable and scalable - thanks. > >> >>> Next check should be explicit for CPU: >>> >>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >>> >>> --- >>> >>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>> +??? if ( (cpu_family() == 0x17) && is_amd() || (cpu_family() == >>> 0x18) && is_hygon()) { >> >> I'm wondering if that should just be an assertion? I would not expect >> it to be possible to have a family 0x17 that is not AMD and likewise >> for family 0x18 and Hygon. But then I don't know how these family ids >> get issued. ?? > > It is not clear what agreement AMD has with these companies. Any company > (as AMD and Intel) may have own set of cpu_family ids and we can't > assume that ids will not be reused. They have only 8 bits for ID. Yes I dug a bit deeper and found for example that both Intel and AMD use 0xF - so it need not be unique and so we should check family id and vendor id. (Might need to re-examine existing code that only uses family id!) Thanks, David > Thanks, > Vladimir > >> >> Thanks, >> David >> >>> Thanks, >>> Vladimir >>> >>> On 4/10/19 12:33 AM, David Holmes wrote: >>>> Hi Fanjinke, >>>> >>>> This looks fine to me. I've updated the webrev at: >>>> >>>> http://cr.openjdk.java.net/~dholmes/8222090/webrev.v3/ >>>> >>>> We need a second reviewer before I push it. >>>> >>>> Thanks, >>>> David >>>> >>>> On 9/04/2019 5:22 pm, Jinke Fan wrote: >>>>> diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp >>>>> b/src/hotspot/cpu/x86/assembler_x86.cpp >>>>> --- a/src/hotspot/cpu/x86/assembler_x86.cpp >>>>> +++ b/src/hotspot/cpu/x86/assembler_x86.cpp >>>>> @@ -3099,7 +3099,7 @@ >>>>> ????? } >>>>> ????? return; >>>>> ??? } >>>>> -? if (UseAddressNop && VM_Version::is_amd()) { >>>>> +? if (UseAddressNop && (VM_Version::is_amd() || >>>>> VM_Version::is_hygon())) { >>>>> ????? // >>>>> ????? // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. >>>>> ????? //? 1: 0x90 >>>>> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>> b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>> @@ -340,6 +340,10 @@ >>>>> ????? return !is_amd_Barcelona(); >>>>> ??? } >>>>> >>>>> +? if (is_hygon()) { >>>>> +??? return true; >>>>> +? } >>>>> + >>>>> ??? return false; >>>>> ??} >>>>> >>>>> @@ -407,6 +411,10 @@ >>>>> ????? } >>>>> ????? return _family_id_intel[cpu_family_id]; >>>>> ??? } >>>>> +? if (is_hygon()) { >>>>> +????? return "Dhyana"; >>>>> +? } >>>>> + >>>>> ??? return "Unknown x86"; >>>>> ??} >>>>> >>>>> @@ -423,6 +431,9 @@ >>>>> ??? } else if (is_amd()) { >>>>> ????? cpu_type = "AMD"; >>>>> ????? x64 = cpu_is_em64t() ? " AMD64" : ""; >>>>> +? } else if (is_hygon()) { >>>>> +?????? cpu_type = "Hygon"; >>>>> +?????? x64 = cpu_is_em64t() ? " AMD64" : ""; >>>>> ??? } else { >>>>> ????? cpu_type = "Unknown x86"; >>>>> ????? x64 = cpu_is_em64t() ? " x86_64" : ""; >>>>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>> b/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>> @@ -1165,7 +1165,7 @@ >>>>> ????? } >>>>> ??? } >>>>> >>>>> -? if( is_amd() ) { // AMD cpus specific settings >>>>> +? if( is_amd() || is_hygon() ) { // AMD cpus specific settings >>>>> ????? if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { >>>>> ??????? // Use it on new AMD cpus starting from Opteron. >>>>> ??????? UseAddressNop = true; >>>>> @@ -1239,8 +1239,8 @@ >>>>> ????? } >>>>> ??#endif // COMPILER2 >>>>> >>>>> -??? // Some defaults for AMD family 17h >>>>> -??? if ( cpu_family() == 0x17 ) { >>>>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>>>> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >>>>> ??????? // On family 17h processors use XMM and UnalignedLoadStores >>>>> for Array Copy >>>>> ??????? if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >>>>> ????????? FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >>>>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>> b/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>> --- a/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>> +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>> @@ -495,13 +495,13 @@ >>>>> ??????? result |= CPU_CX8; >>>>> ????? if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) >>>>> ??????? result |= CPU_CMOV; >>>>> -??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && >>>>> +??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() || >>>>> is_hygon()) && >>>>> ????????? _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) >>>>> ??????? result |= CPU_FXSR; >>>>> ????? // HT flag is set for multi-core processors also. >>>>> ????? if (threads_per_core() > 1) >>>>> ??????? result |= CPU_HT; >>>>> -??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && >>>>> +??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() || >>>>> is_hygon()) && >>>>> ????????? _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) >>>>> ??????? result |= CPU_MMX; >>>>> ????? if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) >>>>> @@ -576,8 +576,8 @@ >>>>> ????? if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>> ??????? result |= CPU_FMA; >>>>> >>>>> -??? // AMD features. >>>>> -??? if (is_amd()) { >>>>> +??? // AMD|Hygon features. >>>>> +??? if (is_amd() || is_hygon()) { >>>>> ??????? if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || >>>>> ??????????? (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) >>>>> ????????? result |= CPU_3DNOW_PREFETCH; >>>>> @@ -711,6 +711,7 @@ >>>>> ??? static int? cpu_family()??????? { return _cpu;} >>>>> ??? static bool is_P6()???????????? { return cpu_family() >= 6; } >>>>> ??? static bool is_amd()??????????? { assert_is_initialized(); >>>>> return _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' >>>>> +? static bool is_hygon()????????? { assert_is_initialized(); >>>>> return _cpuid_info.std_vendor_name_0 == 0x6F677948; } // 'ogyH' >>>>> ??? static bool is_intel()????????? { assert_is_initialized(); >>>>> return _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' >>>>> ??? static bool is_zx()???????????? { assert_is_initialized(); >>>>> return (_cpuid_info.std_vendor_name_0 == 0x746e6543) || >>>>> (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS? ' >>>>> ??? static bool is_atom_family()??? { return ((cpu_family() == >>>>> 0x06) && ((extended_cpu_model() == 0x36) || (extended_cpu_model() >>>>> == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont and >>>>> Centerton >>>>> @@ -734,7 +735,7 @@ >>>>> ??????? if (!supports_topology || result == 0) { >>>>> ????????? result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + >>>>> 1); >>>>> ??????? } >>>>> -??? } else if (is_amd()) { >>>>> +??? } else if (is_amd() || is_hygon()) { >>>>> ??????? result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); >>>>> ????? } else if (is_zx()) { >>>>> ??????? bool supports_topology = supports_processor_topology(); >>>>> @@ -770,7 +771,7 @@ >>>>> ????? intx result = 0; >>>>> ????? if (is_intel()) { >>>>> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>>>> -??? } else if (is_amd()) { >>>>> +??? } else if (is_amd() || is_hygon()) { >>>>> ??????? result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; >>>>> ????? } else if (is_zx()) { >>>>> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>>>> @@ -857,7 +858,7 @@ >>>>> >>>>> ??? // AMD features >>>>> ??? static bool supports_3dnow_prefetch()??? { return (_features & >>>>> CPU_3DNOW_PREFETCH) != 0; } >>>>> -? static bool supports_mmx_ext()? { return is_amd() && >>>>> _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >>>>> +? static bool supports_mmx_ext()? { return (is_amd()||is_hygon()) >>>>> && _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >>>>> ??? static bool supports_lzcnt()??? { return (_features & >>>>> CPU_LZCNT) != 0; } >>>>> ??? static bool supports_sse4a()??? { return (_features & >>>>> CPU_SSE4A) != 0; } >>>>> >>>>> @@ -870,7 +871,7 @@ >>>>> ??? } >>>>> ??? static bool supports_tscinv() { >>>>> ????? return supports_tscinv_bit() && >>>>> -?????????? ( (is_amd() && !is_amd_Barcelona()) || >>>>> +?????????? ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || >>>>> ?????????????? is_intel_tsc_synched_at_init() ); >>>>> ??? } >>>>> >>>>> @@ -896,7 +897,7 @@ >>>>> ????? // Core????? - 256 / prefetchnta >>>>> ????? // It will be used only when AllocatePrefetchStyle > 0 >>>>> >>>>> -??? if (is_amd()) { // AMD >>>>> +??? if (is_amd() || is_hygon()) { // AMD >>>>> ??????? if (supports_sse2()) { >>>>> ????????? return 256; // Opteron >>>>> ??????? } else { From jcbeyler at google.com Thu Apr 11 01:18:26 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 10 Apr 2019 18:18:26 -0700 Subject: RFR (L) 8213501 : Deploy ExceptionJniWrapper for a few tests In-Reply-To: References: <45341168-e7e0-90d1-449f-210500882b8f@oracle.com> <55283958-de3d-07f2-51e3-ad34c5046a96@oracle.com> <31613f88-5f7d-938d-e9f6-69cdaf857268@oracle.com> <839301b7-c247-df3b-e485-283e8bb7388b@oracle.com> <95fe277d-ba6e-4fec-77aa-d1f1051751aa@oracle.com> <72bf2f4a-5bf7-98de-5f00-68485072923d@oracle.com> <25a50bc3-222c-a915-5517-37a2f9375c42@oracle.com> Message-ID: Hi Paul, Exactly :). Actually you are right, when trying to figure out build errors in windows/solaris, I moved declarations around. I've moved them back and the incremental is thus: http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.06_08/ And the full new version is: http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.08/ This has passed the submit repo (thanks serguei ;-)). Could I get another LGTM for this and then we can move forward ? :) Thanks for your help, Jc On Mon, Apr 8, 2019 at 9:11 AM Hohensee, Paul wrote: > Almost all copyright changes, plus a bit of code reorg, but no real > implementation changes except in ExceptionCheckingJniEnv.cpp, which are > fine. A quibble: I?d have left declarations located at first use instead of > moving them up to the beginning of their methods, but I?m not doctrinaire, > so they?re fine too. > > > > Paul > > > > *From: *Jean Christophe Beyler > *Date: *Tuesday, April 2, 2019 at 10:00 AM > *To: *Alex Menkov > *Cc: *"Hohensee, Paul" , hotspot-dev Source > Developers > *Subject: *Re: RFR (L) 8213501 : Deploy ExceptionJniWrapper for a few > tests > > > > Hi all, > > > > Friendly ping on this one, I know I've used up quite a bit of time on it; > my apologies again :) > > Jc > > > > On Tue, Mar 26, 2019 at 12:37 PM Jean Christophe Beyler < > jcbeyler at google.com> wrote: > > Hi all, > > > > My apologies again for this one. This has been a bit tricky to get in and > has fell off my priority list due to other issues/commitments but I'm back > to finishing this up and the next webrevs regarding this work :) > > > > Problem is that we change years so the copyrights changed on some of these > and there were a few problems with various architectures/build systems that > made the testing fail on the submit repo. > > > > So I offer two webrevs: > > > > - The incremental from the last LGTM stamped one: > > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.06_07/ > > > > - The full webrev that cleaned up a few problems for windows and solaris > and now passes the submit repo: > > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.07/ > > > > And again, my sincere apologies that it took me SO long to get back to > this but I had to work through the random submit repo failures and some of > them took time for me to debug (thanks Serguei for your help :-)), > > Jc > > > > On Tue, Jan 22, 2019 at 6:03 PM Alex Menkov > wrote: > > +1 > > --alex > > On 01/22/2019 10:29, JC Beyler wrote: > > Thanks Paul! > > > > Anybody else for the review for version 6? > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.06/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213501 > > > > > > Thanks, > > Jc > > > > On Tue, Jan 22, 2019 at 6:10 AM Hohensee, Paul > > wrote: > > > > Lgtm :) > > > > Paul > > > > On 1/14/19, 7:46 AM, "hotspot-dev on behalf of JC Beyler" > > > on behalf of > > jcbeyler at google.com > wrote: > > > > Hi all, > > > > Friendly ping on this one, I know that it has been a long > > process with back > > and forths, to which I apologize... > > > > But is there any way I could get a final LGTM for version 6? > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.06/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213501 > > > > Thanks! > > Jc > > > > On Tue, Jan 8, 2019 at 10:05 AM JC Beyler > > wrote: > > > > > Happy new year all! > > > > > > Could I get a final LGTM for version 6? > > > > > > Webrev: > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.06/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213501 > > > > > > Thanks! > > > Jc > > > > > > On Mon, Dec 17, 2018 at 8:43 AM JC Beyler > > > wrote: > > > > > >> Hi all, > > >> > > >> I don't believe I got actual LGTM for this version: > > >> > > >> > > >> Webrev: > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.06/ > > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8213501 > > >> > > >> > > >> It removed the namespaces and uses explicit static instead :) > > >> > > >> Thanks! > > >> Jc > > >> > > >> On Wed, Dec 12, 2018 at 8:06 PM JC Beyler > > > wrote: > > >> > > >>> So did I Alexey but with David & Serguei preferring static, > > it seems > > >>> more reasonable to go down their route :-) > > >>> > > >>> So here is the latest webrev with static instead of an > > anonymous > > >>> namespace: > > >>> > > >>> Webrev: > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.06/ > > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213501 > > >>> > > >>> Let me know what you think, can I get a webrev 06 review? > > >>> > > >>> Thanks! > > >>> Jc > > >>> > > >>> On Wed, Dec 12, 2018 at 3:10 PM Alex Menkov > > > > > >>> wrote: > > >>> > > >>>> Hm.. > > >>>> I considered unnamed namespaces "C++ style" (and static > > globals as "C > > >>>> style"). > > >>>> Static globals were deprecated in C++ (but some time ago > the > > >>>> deprecation > > >>>> was reverted). > > >>>> > > >>>> --alex > > >>>> > > >>>> On 12/12/2018 13:55, serguei.spitsyn at oracle.com > > wrote: > > >>>> > Agreed. > > >>>> > > > >>>> > Thanks, > > >>>> > Serguei > > >>>> > > > >>>> > > > >>>> > On 12/12/18 13:52, David Holmes wrote: > > >>>> >> FWIW I think namespaces are overkill in all of this > > test code and > > >>>> just > > >>>> >> obfuscates things - the declaration is easily missed. A > > static > > >>>> >> variable in a .cpp is clearly a global variable to the > > file. > > >>>> >> > > >>>> >> Cheers, > > >>>> >> David > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> On 13/12/2018 5:37 am, serguei.spitsyn at oracle.com > > wrote: > > >>>> >>> Hi Jc, > > >>>> >>> > > >>>> >>> > > >>>> >>> On 12/11/18 21:16, JC Beyler wrote: > > >>>> >>>> Hi all, > > >>>> >>>> > > >>>> >>>> Here is the new webrev with the TEST.groups change. > > Serguei, let > > >>>> me > > >>>> >>>> know if I convinced you with the static vs anonymous > > namespaces or > > >>>> >>>> if you'd still rather have a "static" for now :-) > > >>>> >>> > > >>>> >>> > > >>>> >>> What do you think about this post? : > > >>>> >>> > > >>>> > > > https://stackoverflow.com/questions/11623451/static-vs-non-static-variables-in-namespace > > >>>> >>> > > >>>> >>> > > >>>> >>>> > > >>>> >>>> Webrev: > > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.05/ > > >>>> >>>> > > > > >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213501 > > >>>> >>> > > >>>> >>> The update looks fine. > > >>>> >>> > > >>>> >>> Thanks, > > >>>> >>> Serguei > > >>>> >>> > > >>>> >>> > > >>>> >>> Thanks, > > >>>> >>> Serguei > > >>>> >>> > > >>>> >>>> > > >>>> >>>> Thanks again for the reviews! > > >>>> >>>> Jc > > >>>> >>>> > > >>>> >>>> On Mon, Dec 10, 2018 at 3:10 PM JC Beyler > > > > >>>> >>>> > >> wrote: > > >>>> >>>> > > >>>> >>>> Hi Serguei, > > >>>> >>>> > > >>>> >>>> Yes basically it is equivalent :) I can put them > > in but they > > >>>> are > > >>>> >>>> not required. The norm actually wanted to > > deprecate it but then > > >>>> >>>> remembered that C compatibility would require the > > static > > >>>> key-word > > >>>> >>>> for this case [1] > > >>>> >>>> > > >>>> >>>> So, really, they are not required here and will > > amount to the > > >>>> same > > >>>> >>>> thing: only that file can refer to them and you > > cannot get to > > >>>> them > > >>>> >>>> without a globally available method to return a > > pointer to them > > >>>> >>>> (ie same as a static variable in C). > > >>>> >>>> > > >>>> >>>> I can put static if it makes it easier to see > > but, by being in > > >>>> an > > >>>> >>>> anonymous namespace they are only available for > > the file's > > >>>> >>>> translation unit. For example: > > >>>> >>>> > > >>>> >>>> $ cat main.cpp > > >>>> >>>> > > >>>> >>>> int totally_global; > > >>>> >>>> static int explictly_static; > > >>>> >>>> > > >>>> >>>> namespace { > > >>>> >>>> int implicitly_static; > > >>>> >>>> } > > >>>> >>>> > > >>>> >>>> void foo(); > > >>>> >>>> int main() { > > >>>> >>>> foo(); > > >>>> >>>> } > > >>>> >>>> > > >>>> >>>> $ g++ -O3 main.cpp -c > > >>>> >>>> $ nm main.o > > >>>> >>>> U _GLOBAL_OFFSET_TABLE_ > > >>>> >>>> 0000000000000000 T main > > >>>> >>>> 0000000000000000 B totally_global > > >>>> >>>> U _Z3foov > > >>>> >>>> > > >>>> >>>> As you can see, the static and anonymous > > namespace variables > > >>>> are > > >>>> >>>> not in the file due to not being used. If you > > were to use them, > > >>>> >>>> you'd see them show up as something like: > > >>>> >>>> 0000000000000008 b _ZL17explicitly_static > > >>>> >>>> 0000000000000004 b > > _ZN12_GLOBAL__N_117implicitly_staticE > > >>>> >>>> > > >>>> >>>> Where again, it shows that it is mangling the > > names so that no > > >>>> >>>> external usage can happen without tinkering. > > >>>> >>>> > > >>>> >>>> Hopefully that helps :-), > > >>>> >>>> Jc > > >>>> >>>> > > >>>> >>>> [1] > > >>>> >>>> > > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1012 > > >>>> >>>> > > >>>> >>>> > > >>>> >>>> On Mon, Dec 10, 2018 at 2:04 PM > > serguei.spitsyn at oracle.com > > >>>> >>>> > > < > > >>>> serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com> > > >>>> >>>> > >> wrote: > > >>>> >>>> > > >>>> >>>> Hi Jc, > > >>>> >>>> > > >>>> >>>> I had little experience with the C++ > namespaces. > > >>>> >>>> My understanding is that static in this > > context should mean > > >>>> >>>> internal linkage. > > >>>> >>>> > > >>>> >>>> Thanks, > > >>>> >>>> Serguei > > >>>> >>>> > > >>>> >>>> > > >>>> >>>> On 12/10/18 13:57, JC Beyler wrote: > > >>>> >>>>> Hi Serguei, > > >>>> >>>>> > > >>>> >>>>> The variables and functions are in a > > anonymous namespace; > > >>>> my > > >>>> >>>>> understanding of C++ is that this is > > equivalent to > > >>>> putting it > > >>>> >>>>> as static.Hence, I didn't add them there. > > Does that make > > >>>> >>>>> sense? > > >>>> >>>>> > > >>>> >>>>> Thanks! > > >>>> >>>>> Jc > > >>>> >>>>> > > >>>> >>>>> On Mon, Dec 10, 2018 at 1:33 PM > > >>>> serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com> > > >>>> >>>>> > > > > >>>> >>>>> > > > >>>> >>>>> > >> wrote: > > >>>> >>>>> > > >>>> >>>>> Hi Jc, > > >>>> >>>>> > > >>>> >>>>> It looks good in general. > > >>>> >>>>> One question though. > > >>>> >>>>> > > >>>> >>>>> > > >>>> > > > http://cr.openjdk.java.net/%7Ejcbeyler/8213501/webrev.03a_04/test/hotspot/jtreg/vmTestbase/nsk/share/ExceptionCheckingJniEnv/exceptionjni001/exceptionjni001.cpp.html > > >>>> >>>>> > > >>>> >>>>> > > >>>> >>>>> I wonder if the variables and functions > > have to be > > >>>> static. > > >>>> >>>>> > > >>>> >>>>> Thanks, > > >>>> >>>>> Serguei > > >>>> >>>>> > > >>>> >>>>> > > >>>> >>>>> On 12/5/18 11:36, JC Beyler wrote: > > >>>> >>>>>> Hi all, > > >>>> >>>>>> > > >>>> >>>>>> My apologies to having to come back for > > another > > >>>> review > > >>>> >>>>>> for this change: I ran into a snag when > > trying to > > >>>> pull > > >>>> >>>>>> the latest changes compared to the base > > I was working > > >>>> >>>>>> on. I basically forgot that there was > > an issue with > > >>>> >>>>>> snprintf and that I had solved it via > > JDK-8213622. > > >>>> >>>>>> > > >>>> >>>>>> Could I have a new review of this > webrev: > > >>>> >>>>>> Webrev: > > >>>> >>>>>> > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.04/ > > >>>> >>>>>> > > > > >>>> >>>>>> Bug: > > >>>> https://bugs.openjdk.java.net/browse/JDK-8213501 > > >>>> >>>>>> Incremental from the port of webrev.03 > > that got > > >>>> LGTMs: > > >>>> >>>>>> > > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.03a_04/ > > >>>> >>>>>> > > > > >>>> >>>>>> > > >>>> >>>>>> A few comments on this because it took > > me a while to > > >>>> get > > >>>> >>>>>> things in a state I thought was good: > > >>>> >>>>>> - I had to implement an itoa method, > > do we have > > >>>> >>>>>> something like that in the test base > > (remember that > > >>>> >>>>>> JDK-8213622 could not use sprintf due > > to being in the > > >>>> >>>>>> test code)? > > >>>> >>>>>> > > >>>> >>>>>> - The differences here compared to > > the one you all > > >>>> >>>>>> reviewed are: > > >>>> >>>>>> - I found that adding to the > > strlen/memcpy > > >>>> error > > >>>> >>>>>> prone and thought that I would try to > > make it less > > >>>> so. > > >>>> >>>>>> If you want to compare, I extended the > > strlen/memcpy > > >>>> >>>>>> with the new format to show you if you > > prefer [1] > > >>>> >>>>>> - Note that the diff > > between the "old > > >>>> >>>>>> extended way from [1]" to the webrev.04 > > can be found > > >>>> >>>>>> in [2] > > >>>> >>>>>> > > >>>> >>>>>> - I added a test to test the > > exception wrapper > > >>>> in > > >>>> >>>>>> tests :); I'm not sure it is deemed > > useful or not but > > >>>> >>>>>> helped me assure myself that I was not > > doing things > > >>>> >>>>>> wrong; you can find the base test file > > here [3]; > > >>>> should > > >>>> >>>>>> we have this or not? (I know that > > normally we don't > > >>>> add > > >>>> >>>>>> tests to vmTestbase but thought this > > might be an > > >>>> >>>>>> exception) > > >>>> >>>>>> > > >>>> >>>>>> Thanks for your help and my apologies > > for the snag, > > >>>> >>>>>> Jc > > >>>> >>>>>> > > >>>> >>>>>> [1]: > > >>>> >>>>>> > > >>>> > > > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.03a/test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.cpp.udiff.html > > >>>> >>>>>> > > >>>> >>>>>> < > > >>>> > > > http://cr.openjdk.java.net/%7Ejcbeyler/8213501/webrev.03a/test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.cpp.udiff.html > > > > >>>> > > >>>> >>>>>> > > >>>> >>>>>> [2]: > > >>>> >>>>>> > > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.03a_04 > > >>>> >>>>>> > > > > >>>> >>>>>> [3] > > >>>> >>>>>> > > >>>> > > > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.04/test/hotspot/jtreg/vmTestbase/nsk/share/ExceptionCheckingJniEnv/exceptionjni001/exceptionjni001.cpp.html > > >>>> >>>>>> > > >>>> >>>>>> < > > >>>> > > > http://cr.openjdk.java.net/%7Ejcbeyler/8213501/webrev.04/test/hotspot/jtreg/vmTestbase/nsk/share/ExceptionCheckingJniEnv/exceptionjni001/exceptionjni001.cpp.html > > > > >>>> > > >>>> >>>>>> > > >>>> >>>>>> > > >>>> >>>>>> On Mon, Dec 3, 2018 at 11:29 PM David > > Holmes > > >>>> >>>>>> > > > >>>> >>>>>> > >> wrote: > > >>>> >>>>>> > > >>>> >>>>>> Looks fine to me. > > >>>> >>>>>> > > >>>> >>>>>> Thanks, > > >>>> >>>>>> David > > >>>> >>>>>> > > >>>> >>>>>> On 4/12/2018 4:04 pm, JC Beyler > wrote: > > >>>> >>>>>> > Hi both, > > >>>> >>>>>> > > > >>>> >>>>>> > Thanks for the reviews! Since > > Serguei did not > > >>>> >>>>>> insist on get_basename, I > > >>>> >>>>>> > went for get_dirname since the > > method is a > > >>>> local > > >>>> >>>>>> static method and won't > > >>>> >>>>>> > have its name start spreading, I > > think it's ok > > >>>> too. > > >>>> >>>>>> > > > >>>> >>>>>> > For the naming of the local > > variable, the idea > > >>>> >>>>>> initially was to use the > > >>>> >>>>>> > same name as the local variable > > for JNIEnv > > >>>> already > > >>>> >>>>>> used to reduce the > > >>>> >>>>>> > code change. Since I'm now adding > > the line > > >>>> macro > > >>>> >>>>>> at the end anyway, this > > >>>> >>>>>> > does not matter anymore so I > > converged all > > >>>> local > > >>>> >>>>>> variables to "jni". > > >>>> >>>>>> > > > >>>> >>>>>> > So, without further ado, here is > > the new > > >>>> version: > > >>>> >>>>>> > Webrev: > > >>>> >>>>>> > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.03/ > > >>>> >>>>>> > > > > >>>> >>>>>> > Bug: > > >>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213501 > > >>>> >>>>>> > > > >>>> >>>>>> > This passes the various tests > > changed by the > > >>>> >>>>>> webrev on my dev machine. > > >>>> >>>>>> > > > >>>> >>>>>> > Let me know what you think, > > >>>> >>>>>> > Jc > > >>>> >>>>>> > > > >>>> >>>>>> > On Mon, Dec 3, 2018 at 8:40 PM > > >>>> >>>>>> serguei.spitsyn at oracle.com > > > > >>>> >>>>>> > > > > >>>> >>>>>> > > > serguei.spitsyn at oracle.com> > > >>>> >>>>>> > >> > > >>>> >>>>>> > > > >>>> >>>>>> > > > > >>>> >>>>>> > > > serguei.spitsyn at oracle.com> > > >>>> >>>>>> > >>> wrote: > > >>>> >>>>>> > > > >>>> >>>>>> > On 12/3/18 20:15, Chris > > Plummer wrote: > > >>>> >>>>>> > > Hi JC, > > >>>> >>>>>> > > > > >>>> >>>>>> > > Overall it looks good. A > > few naming nits > > >>>> >>>>>> thought: > > >>>> >>>>>> > > > > >>>> >>>>>> > > In bi01t001.cpp, why have > > you declared > > >>>> the > > >>>> >>>>>> > ExceptionCheckingJniEnvPtr > > >>>> >>>>>> > > using jni_env(jni). > > Elsewhere you use > > >>>> >>>>>> jni(jni_env) and rename the > > >>>> >>>>>> > > method argument passed in > > from jni to > > >>>> >>>>>> jni_env. > > >>>> >>>>>> > > > > >>>> >>>>>> > > Related to this, I also > > noticed in some > > >>>> >>>>>> files that already are using > > >>>> >>>>>> > > > > ExceptionCheckingJniEnvPtr, such as > > >>>> >>>>>> CharArrayCriticalLocker.cpp, you > > >>>> >>>>>> > > delcared it as > > env(jni_env). So that > > >>>> means > > >>>> >>>>>> there are 3 different > > >>>> >>>>>> > names > > >>>> >>>>>> > > you have used for the > > >>>> >>>>>> ExceptionCheckingJniEnvPtr local > > variable. > > >>>> >>>>>> > They > > >>>> >>>>>> > > should be consistent. > > >>>> >>>>>> > > > > >>>> >>>>>> > > Also, can you rename > > get_basename() to > > >>>> >>>>>> get_dirname()? I know Serguei > > >>>> >>>>>> > > suggested get_basename() a > > while back, > > >>>> but > > >>>> >>>>>> unless "basename" is > > >>>> >>>>>> > > commonly used for this > > purpose, I think > > >>>> >>>>>> "dirname" is more self > > >>>> >>>>>> > > explanatory. > > >>>> >>>>>> > > > >>>> >>>>>> > In general, I'm Okay with > > get_dirname(). > > >>>> >>>>>> > Just to mention dirname can > > be both short > > >>>> or > > >>>> >>>>>> full, so it is a little > > >>>> >>>>>> > confusing as well. > > >>>> >>>>>> > It is the reason why the > > get_basename() was > > >>>> >>>>>> suggested. > > >>>> >>>>>> > However, I do not insist on > > get_basename() > > >>>> nor > > >>>> >>>>>> get_full_dirname(). :) > > >>>> >>>>>> > > > >>>> >>>>>> > Thanks, > > >>>> >>>>>> > Serguei > > >>>> >>>>>> > > > >>>> >>>>>> > > > >>>> >>>>>> > > thanks, > > >>>> >>>>>> > > > > >>>> >>>>>> > > Chris > > >>>> >>>>>> > > > > >>>> >>>>>> > > On 12/2/18 10:29 PM, David > > Holmes wrote: > > >>>> >>>>>> > >> Hi Jc, > > >>>> >>>>>> > >> > > >>>> >>>>>> > >> I've been lurking on this > > one and have > > >>>> had > > >>>> >>>>>> a look through. I'm okay > > >>>> >>>>>> > >> with the FatalError > > approach for the > > >>>> tests > > >>>> >>>>>> - we don't expect > > >>>> >>>>>> > anything > > >>>> >>>>>> > >> to go wrong in a well > > written test in a > > >>>> >>>>>> correctly functioning VM. > > >>>> >>>>>> > >> > > >>>> >>>>>> > >> Thanks, > > >>>> >>>>>> > >> David > > >>>> >>>>>> > >> > > >>>> >>>>>> > >> > > >>>> >>>>>> > >> > > >>>> >>>>>> > >> On 3/12/2018 3:24 pm, JC > > Beyler wrote: > > >>>> >>>>>> > >>> Hi all, > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>> Would someone on the GC > > or runtime > > >>>> team > > >>>> >>>>>> be motivated to give > > >>>> >>>>>> > this a > > >>>> >>>>>> > >>> review? :) > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>> It would be much > > appreciated! > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>> Webrev: > > >>>> >>>>>> > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.02/ > > >>>> >>>>>> > > > > >>>> >>>>>> > >>> Bug: > > >>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213501 > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>> Thanks for your help, > > >>>> >>>>>> > >>> Jc > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>> On Tue, Nov 27, 2018 at > > 4:36 PM JC > > >>>> Beyler > > >>>> >>>>>> > > > > >>>> > > > >>>> >>>>>> > > > > >>>> >>>>>> > >> > > >>>> >>>>>> > >>> > > > > >>>> >>>>>> > > > > >>>> >>>>>> > > > >>>> >>>>>> > >>>> wrote: > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>> Hi Chris, > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>> Yes I was waiting > > for another > > >>>> review > > >>>> >>>>>> since you had explicitly > > >>>> >>>>>> > >>> asked :) > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>> And sounds good that > > when someone > > >>>> >>>>>> from GC or runtime gives a > > >>>> >>>>>> > >>> review, > > >>>> >>>>>> > >>> I'll wait for your > > full review on > > >>>> the > > >>>> >>>>>> webrev.02! > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>> Thanks again for > > your help, > > >>>> >>>>>> > >>> Jc > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>> On Tue, Nov 27, 2018 > > at 12:48 PM > > >>>> >>>>>> Chris Plummer > > >>>> >>>>>> > >>> > > > > >>>> >>>>>> > > > > >>>> >>>>>> > > > >>>> >>>>>> > >> > > >>>> >>>>>> > > > > >>>> >>>>>> > > > > >>>> >>>>>> > > > >>>> >>>>>> > >>>> > > >>>> >>>>>> > wrote: > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>> Hi JC, > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>> I think it would > > be good to > > >>>> get a > > >>>> >>>>>> review from the gc or > > >>>> >>>>>> > runtime > > >>>> >>>>>> > >>> teams, since > > this also affects > > >>>> >>>>>> their tests. > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>> Also, once we > > are settled on > > >>>> this > > >>>> >>>>>> FatalError approach, > > >>>> >>>>>> > I still > > >>>> >>>>>> > >>> need to give > > your webrev-02 a > > >>>> >>>>>> full review. I only > > >>>> >>>>>> > skimmed over > > >>>> >>>>>> > >>> parts of it (I > > did look at all > > >>>> >>>>>> the changes in webrevo-01). > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>> thanks, > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>> Chris > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>> On 11/27/18 8:58 > AM, > > >>>> >>>>>> serguei.spitsyn at oracle.com > > > > >>>> >>>>>> > > > > >>>> >>>>>> > > > serguei.spitsyn at oracle.com> > > >>>> >>>>>> > >> > > >>>> >>>>>> > >>> > > serguei.spitsyn at oracle.com> > > >>>> >>>>>> > > > > >>>> >>>>>> > > > serguei.spitsyn at oracle.com> > > >>>> >>>>>> > >>> wrote: > > >>>> >>>>>> > >>>> Hi Jc, > > >>>> >>>>>> > >>>> > > >>>> >>>>>> > >>>> I've already > > reviewed this > > >>>> too. > > >>>> >>>>>> > >>>> > > >>>> >>>>>> > >>>> Thanks, > > >>>> >>>>>> > >>>> Serguei > > >>>> >>>>>> > >>>> > > >>>> >>>>>> > >>>> > > >>>> >>>>>> > >>>> On 11/27/18 > > 06:56, JC Beyler > > >>>> >>>>>> wrote: > > >>>> >>>>>> > >>>>> Thanks Chris, > > >>>> >>>>>> > >>>>> > > >>>> >>>>>> > >>>>> Anybody else motivated > > to look at > > >>>> this > > >>>> >>>>>> and review it? :) > > >>>> >>>>>> > >>>>> Jc > > >>>> >>>>>> > >>>>> > > >>>> >>>>>> > >>>>> On Mon, Nov > > 26, 2018 at > > >>>> 1:26 PM > > >>>> >>>>>> Chris Plummer > > >>>> >>>>>> > >>>>> > > > > >>>> >>>>>> > > > > >>>> >>>>>> > > > > >>>> >>>>>> > >> > > >>>> >>>>>> > > > >>>> >>>>>> > > > > >>>> >>>>>> > > > > >>>> >>>>>> > >>>> > > >>>> >>>>>> > >>>>> wrote: > > >>>> >>>>>> > >>>>> > > >>>> >>>>>> > >>>>> Hi JC, > > >>>> >>>>>> > >>>>> > > >>>> >>>>>> > >>>>> I'm ok with the > > FatalError approach, > > >>>> >>>>>> but would > > >>>> >>>>>> > like to > > >>>> >>>>>> > >>>>> hear opinions from > > others also. > > >>>> >>>>>> > >>>>> > > >>>> >>>>>> > >>>>> thanks, > > >>>> >>>>>> > >>>>> > > >>>> >>>>>> > >>>>> Chris > > >>>> >>>>>> > >>>>> > > >>>> >>>>>> > >>>>> On 11/21/18 8:19 AM, > > JC Beyler > > >>>> wrote: > > >>>> >>>>>> > >>>>>> Hi Chris, > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> Thanks > > for taking the > > >>>> time > > >>>> >>>>>> to look at it and yes you > > >>>> >>>>>> > >>>>>> have > > raised exactly why > > >>>> >>>>>> the webrev is between two > > >>>> >>>>>> > >>>>>> worlds: > > in cases where > > >>>> a > > >>>> >>>>>> fatal error on failure is > > >>>> >>>>>> > >>>>>> wanted, > > should we > > >>>> simplify > > >>>> >>>>>> the code to remove > > >>>> >>>>>> > the return > > >>>> >>>>>> > >>>>>> tests > > since we do them > > >>>> >>>>>> internally? Now that I've > > >>>> >>>>>> > looked > > >>>> >>>>>> > >>>>>> around > > for non-fatal > > >>>> >>>>>> cases, I think the answer > > >>>> >>>>>> > is yes, > > >>>> >>>>>> > >>>>>> it > > simplifies the code > > >>>> >>>>>> while maintaining the checks. > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> I looked > > a bit and it > > >>>> >>>>>> seems that I can't find > > >>>> >>>>>> > easily a > > >>>> >>>>>> > >>>>>> case > > where the test > > >>>> >>>>>> accepts a JNI failure to > > >>>> >>>>>> > then move > > >>>> >>>>>> > >>>>>> on. > > Therefore, perhaps, > > >>>> >>>>>> for now, the fail with a > > >>>> >>>>>> > Fatal > > >>>> >>>>>> > >>>>>> is enough > > and we can > > >>>> work > > >>>> >>>>>> on the tests to clean > > >>>> >>>>>> > them up? > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> That > > means that this is > > >>>> >>>>>> the new webrev with only > > >>>> >>>>>> > Fatal > > >>>> >>>>>> > >>>>>> and > > cleans up the > > >>>> tests so > > >>>> >>>>>> that it is no longer in > > >>>> >>>>>> > >>>>>> between > > two worlds: > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> Webrev: > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.02/ > > >>>> >>>>>> > > > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > > > > >>>> >>>>>> > >>>>>> Bug: > > >>>> >>>>>> > > > >>>> https://bugs.openjdk.java.net/browse/JDK-8213501 > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> (This > > passes testing > > >>>> on my > > >>>> >>>>>> dev machine for all the > > >>>> >>>>>> > >>>>>> modified > > tests) > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> with the > > example you > > >>>> >>>>>> provided, it now looks like: > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > > >>>> > > > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp.frames.html > > >>>> >>>>>> > > >>>> >>>>>> < > > >>>> > > > http://cr.openjdk.java.net/%7Ejcbeyler/8213501/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp.frames.html > > > > >>>> > > >>>> >>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> < > > >>>> > > > http://cr.openjdk.java.net/%7Ejcbeyler/8213501/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp.frames.html > > > > >>>> > > >>>> >>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> Where it > > does, to me at > > >>>> >>>>>> least, seem cleaner and less > > >>>> >>>>>> > >>>>>> "noisy". > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> Let me > > know what you > > >>>> think, > > >>>> >>>>>> > >>>>>> Jc > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> On Tue, > > Nov 20, 2018 at > > >>>> >>>>>> 9:33 PM Chris Plummer > > >>>> >>>>>> > >>>>>> < > > >>>> chris.plummer at oracle.com > > >>>> >>>>>> > > > > >>>> >>>>>> > > > > >>>> >>>>>> > >> > > >>>> >>>>>> > >>>>>> > > > > >>>> >>>>>> > > > > >>>> >>>>>> > > > > >>>> >>>>>> > >>>> wrote: > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> Hi JC, > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> Sorry > > about the > > >>>> delay. > > >>>> >>>>>> I had to go back an > > >>>> >>>>>> > look at > > >>>> >>>>>> > >>>>>> the > > initial 8210842 > > >>>> >>>>>> webrev and RFR thread to see > > >>>> >>>>>> > >>>>>> what > > this was > > >>>> >>>>>> initially all about. > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> In > > general the > > >>>> changes > > >>>> >>>>>> look good. > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> I > > don't have a good > > >>>> >>>>>> answer to your > > >>>> >>>>>> > >>>>>> FatalError/NonFatalError > > question. It > > >>>> makes > > >>>> >>>>>> > the code > > >>>> >>>>>> > >>>>>> a lot > > cleaner to > > >>>> use > > >>>> >>>>>> FatalError, but then it > > >>>> >>>>>> > is a > > >>>> >>>>>> > >>>>>> > > behavior change, > > >>>> and > > >>>> >>>>>> you also need to deal with > > >>>> >>>>>> > >>>>>> tests > > that > > >>>> >>>>>> intentionally induce errors (do > > >>>> >>>>>> > you have > > >>>> >>>>>> > >>>>>> an > > example of > > >>>> that). > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> In > > any case, right > > >>>> now > > >>>> >>>>>> your webrev seems to be > > >>>> >>>>>> > >>>>>> > > between two worlds. > > >>>> >>>>>> You are producing > > >>>> >>>>>> > FatalError, > > >>>> >>>>>> > >>>>>> but > > still checking > > >>>> >>>>>> results. Here's a good > > >>>> >>>>>> > example: > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > > >>>> > > > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp.frames.html > > >>>> >>>>>> > > >>>> >>>>>> < > > >>>> > > > http://cr.openjdk.java.net/%7Ejcbeyler/8213501/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp.frames.html > > > > >>>> > > >>>> >>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> < > > >>>> > > > http://cr.openjdk.java.net/%7Ejcbeyler/8213501/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp.frames.html > > > > >>>> > > >>>> >>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> I'm > > not sure if > > >>>> this > > >>>> >>>>>> is just a temporary > > >>>> >>>>>> > state until > > >>>> >>>>>> > >>>>>> it > > was decided > > >>>> which > > >>>> >>>>>> approach to take. > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> > thanks, > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> Chris > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> On > > 11/20/18 2:14 > > >>>> PM, > > >>>> >>>>>> JC Beyler wrote: > > >>>> >>>>>> > >>>>>>> Hi > all, > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> > > Chris thought it > > >>>> made > > >>>> >>>>>> sense to have more > > >>>> >>>>>> > eyes on > > >>>> >>>>>> > >>>>>>> this > > change than > > >>>> just > > >>>> >>>>>> serviceability as it will > > >>>> >>>>>> > >>>>>>> > > modify to tests > > >>>> that > > >>>> >>>>>> are not only > > >>>> >>>>>> > serviceability > > >>>> >>>>>> > >>>>>>> > > tests so I've > > >>>> moved > > >>>> >>>>>> this to conversation > > >>>> >>>>>> > here :) > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> For > > convenience, > > >>>> I've > > >>>> >>>>>> copy-pasted the > > >>>> >>>>>> > initial RFR: > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> > > Could I have a > > >>>> review > > >>>> >>>>>> for the extension and > > >>>> >>>>>> > usage > > >>>> >>>>>> > >>>>>>> of > the > > >>>> >>>>>> ExceptionJniWrapper. This adds > > lines and > > >>>> >>>>>> > >>>>>>> > > filenames to the > > >>>> end > > >>>> >>>>>> of the wrapper JNI > > >>>> >>>>>> > methods, > > >>>> >>>>>> > >>>>>>> adds > > tracing, and > > >>>> >>>>>> throws an error if need > > >>>> >>>>>> > be. I've > > >>>> >>>>>> > >>>>>>> > > ported the gc/lock > > >>>> >>>>>> files to use the new > > >>>> >>>>>> > >>>>>>> > > TRACE_JNI_CALL > > >>>> add-on > > >>>> >>>>>> and I've ported a few > > >>>> >>>>>> > of the > > >>>> >>>>>> > >>>>>>> > > tests that were > > >>>> >>>>>> already changed for the > > >>>> >>>>>> > assignment > > >>>> >>>>>> > >>>>>>> > > webrev for > > >>>> >>>>>> JDK-8212884. > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> > Webrev: > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.01 > > >>>> >>>>>> > > > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > > > > >>>> >>>>>> > >>>>>>> Bug: > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213501 > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> For > > illustration, > > >>>> if > > >>>> >>>>>> I force an error to the > > >>>> >>>>>> > >>>>>>> > > AP04/ap04t03 test > > >>>> and > > >>>> >>>>>> set the verbosity on, > > >>>> >>>>>> > I get > > >>>> >>>>>> > >>>>>>> > > something like: > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> >> > > Calling JNI > > >>>> method > > >>>> >>>>>> FindClass from > > >>>> >>>>>> > >>>>>>> ap04t003.cpp:343 > > >>>> >>>>>> > >>>>>>> >> > > Calling with > > >>>> these > > >>>> >>>>>> parameter(s): > > >>>> >>>>>> > >>>>>>> java/lang/Threadd > > >>>> >>>>>> > >>>>>>> Wait > > for thread > > >>>> to > > >>>> >>>>>> finish > > >>>> >>>>>> > >>>>>>> << > > Called JNI > > >>>> method > > >>>> >>>>>> FindClass from > > >>>> >>>>>> > >>>>>>> ap04t003.cpp:343 > > >>>> >>>>>> > >>>>>>> > > Exception in > > >>>> thread > > >>>> >>>>>> "Thread-0" > > >>>> >>>>>> > >>>>>>> > > java.lang.NoClassDefFoundError: > > >>>> >>>>>> > java/lang/Threadd > > >>>> >>>>>> > >>>>>>> > > at > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > > >>>> > > > nsk.jvmti.scenarios.allocation.AP04.ap04t003.runIterateOverHeap(Native > > >>>> >>>>>> > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> > Method) > > >>>> >>>>>> > >>>>>>> > > at > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > > >>>> > > > nsk.jvmti.scenarios.allocation.AP04.ap04t003HeapIterator.runIteration(ap04t003.java:140) > > >>>> > > >>>> >>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> > > at > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > > >>>> > > > nsk.jvmti.scenarios.allocation.AP04.ap04t003Thread.run(ap04t003.java:201) > > >>>> >>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> > > Caused by: > > >>>> >>>>>> java.lang.ClassNotFoundException: > > >>>> >>>>>> > >>>>>>> > > java.lang.Threadd > > >>>> >>>>>> > >>>>>>> > > at > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > > >>>> > > > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) > > >>>> > > >>>> >>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> > > at > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > > >>>> > > > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > > >>>> > > >>>> >>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> > > at > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > > java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) > > >>>> >>>>>> > >>>>>>> > > ... 3 more > > >>>> >>>>>> > >>>>>>> > > FATAL ERROR in > > >>>> native > > >>>> >>>>>> method: JNI method > > >>>> >>>>>> > FindClass > > >>>> >>>>>> > >>>>>>> : > > internal error > > >>>> from > > >>>> >>>>>> ap04t003.cpp:343 > > >>>> >>>>>> > >>>>>>> > > at > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > > >>>> > > > nsk.jvmti.scenarios.allocation.AP04.ap04t003.runIterateOverHeap(Native > > >>>> >>>>>> > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> > Method) > > >>>> >>>>>> > >>>>>>> > > at > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > > >>>> > > > nsk.jvmti.scenarios.allocation.AP04.ap04t003HeapIterator.runIteration(ap04t003.java:140) > > >>>> > > >>>> >>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> > > at > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > > >>>> > > > nsk.jvmti.scenarios.allocation.AP04.ap04t003Thread.run(ap04t003.java:201) > > >>>> >>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> > > >>>> Questions/comments I > > >>>> >>>>>> have about this are: > > >>>> >>>>>> > >>>>>>> - > > Do we want to > > >>>> >>>>>> force fatal errors when a JNI > > >>>> >>>>>> > >>>>>>> call > > fails in > > >>>> >>>>>> general? Most of these tests > > >>>> >>>>>> > do the > > >>>> >>>>>> > >>>>>>> > > right thing and > > >>>> test > > >>>> >>>>>> the return of the JNI > > >>>> >>>>>> > calls, > > >>>> >>>>>> > >>>>>>> for > > example: > > >>>> >>>>>> > >>>>>>> > > thrClass = > > >>>> >>>>>> > > jni->FindClass("java/lang/Threadd", > > >>>> >>>>>> > >>>>>>> > > TRACE_JNI_CALL); > > >>>> >>>>>> > >>>>>>> > > if (thrClass > > >>>> == > > >>>> >>>>>> NULL) { > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> but > > now the > > >>>> wrapper > > >>>> >>>>>> actually would do a > > >>>> >>>>>> > fatal if > > >>>> >>>>>> > >>>>>>> the > > FindClass call > > >>>> >>>>>> would return a nullptr, > > >>>> >>>>>> > so we > > >>>> >>>>>> > >>>>>>> > > could remove that > > >>>> >>>>>> test altogether. What do you > > >>>> >>>>>> > >>>>>>> think? > > >>>> >>>>>> > >>>>>>> > > - I prefer to > > >>>> >>>>>> leave them as the tests then > > >>>> >>>>>> > >>>>>>> > > become closer to > > >>>> what > > >>>> >>>>>> real users would have in > > >>>> >>>>>> > >>>>>>> > > their code and is > > >>>> the > > >>>> >>>>>> "recommended" way of > > >>>> >>>>>> > doing it > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> - > The > > >>>> alternative > > >>>> >>>>>> is to use the > > >>>> >>>>>> > NonFatalError I > > >>>> >>>>>> > >>>>>>> > > added which then > > >>>> just > > >>>> >>>>>> prints out that something > > >>>> >>>>>> > >>>>>>> went > > wrong, > > >>>> letting > > >>>> >>>>>> the test continue. Question > > >>>> >>>>>> > >>>>>>> will > > be what > > >>>> should > > >>>> >>>>>> be the default? The > > >>>> >>>>>> > fatal or > > >>>> >>>>>> > >>>>>>> the > > non-fatal > > >>>> error > > >>>> >>>>>> handling? > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> On a > > different > > >>>> >>>>>> subject: > > >>>> >>>>>> > >>>>>>> - > > On the new > > >>>> tests, > > >>>> >>>>>> I've removed the > > >>>> >>>>>> > >>>>>>> > > NSK_JNI_VERIFY > > >>>> since > > >>>> >>>>>> the JNI wrapper > > >>>> >>>>>> > handles the > > >>>> >>>>>> > >>>>>>> > > tracing and the > > >>>> >>>>>> verify in almost the same > > >>>> >>>>>> > way; only > > >>>> >>>>>> > >>>>>>> > > difference I can > > >>>> >>>>>> really tell is that the > > >>>> >>>>>> > complain > > >>>> >>>>>> > >>>>>>> > > method from NSK > > >>>> has a > > >>>> >>>>>> max complain before > > >>>> >>>>>> > stopping > > >>>> >>>>>> > >>>>>>> to > > "complain"; I > > >>>> have > > >>>> >>>>>> not added that part > > >>>> >>>>>> > of the > > >>>> >>>>>> > >>>>>>> code > > in this > > >>>> webrev > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> Once > > we decide on > > >>>> >>>>>> these, I can continue on the > > >>>> >>>>>> > >>>>>>> > > files from > > >>>> >>>>>> JDK-8212884 and then do both the > > >>>> >>>>>> > >>>>>>> > > assignment in an > > >>>> if > > >>>> >>>>>> extraction followed-by this > > >>>> >>>>>> > >>>>>>> type > > of webrev in > > >>>> an > > >>>> >>>>>> easier fashion. > > >>>> >>>>>> > Depending on > > >>>> >>>>>> > >>>>>>> > > decisions here, > > >>>> >>>>>> NSK*VERIFY can be deprecated as > > >>>> >>>>>> > >>>>>>> well > > as we go > > >>>> forward. > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> > Thanks! > > >>>> >>>>>> > >>>>>>> Jc > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> On > > Mon, Nov 19, > > >>>> 2018 > > >>>> >>>>>> at 11:34 AM Chris Plummer > > >>>> >>>>>> > >>>>>>> < > > >>>> chris.plummer at oracle.com > > >>>> >>>>>> > > > > >>>> >>>>>> > > > > >>>> >>>>>> > >> > > >>>> >>>>>> > >>>>>>> > > > > >>>> >>>>>> > > > > >>>> >>>>>> > > > > >>>> >>>>>> > >>>> wrote: > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> > > On 11/19/18 > > >>>> 10:07 > > >>>> >>>>>> AM, JC Beyler wrote: > > >>>> >>>>>> > >>>>>>>> > > Hi all, > > >>>> >>>>>> > >>>>>>>> > > >>>> >>>>>> > >>>>>>>> > > @David/Chris: > > >>>> >>>>>> should I then push this > > >>>> >>>>>> > RFR to > > >>>> >>>>>> > >>>>>>>> > > the hotspot > > >>>> >>>>>> mailing or the runtime > > >>>> >>>>>> > one? For > > >>>> >>>>>> > >>>>>>>> > > what it's > > >>>> worth, > > >>>> >>>>>> a lot of the tests > > >>>> >>>>>> > under the > > >>>> >>>>>> > >>>>>>>> > > vmTestbase > > >>>> are > > >>>> >>>>>> jvmti so the review also > > >>>> >>>>>> > >>>>>>>> > > affects > > >>>> >>>>>> serviceability; it just turns > > >>>> >>>>>> > out I > > >>>> >>>>>> > >>>>>>>> > > started with > > >>>> the > > >>>> >>>>>> GC originally and > > >>>> >>>>>> > then hit > > >>>> >>>>>> > >>>>>>>> > > some other > > >>>> tests > > >>>> >>>>>> I had touched via the > > >>>> >>>>>> > >>>>>>>> > > assignment > > >>>> >>>>>> extraction. > > >>>> >>>>>> > >>>>>>> > > I think > > >>>> hotspot > > >>>> >>>>>> would be best. > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> > > Chris > > >>>> >>>>>> > >>>>>>>> > > >>>> >>>>>> > >>>>>>>> > > @Serguei: > > >>>> Done > > >>>> >>>>>> for the method > > >>>> >>>>>> > renaming, for > > >>>> >>>>>> > >>>>>>>> > > the indent, > > >>>> are > > >>>> >>>>>> you talking about > > >>>> >>>>>> > going from > > >>>> >>>>>> > >>>>>>>> > > the 8-indent > > >>>> to > > >>>> >>>>>> 4-indent? If so, would > > >>>> >>>>>> > it not > > >>>> >>>>>> > >>>>>>>> > > just be > > >>>> better > > >>>> >>>>>> to do a new JBS bug and > > >>>> >>>>>> > do the > > >>>> >>>>>> > >>>>>>>> > > whole files > > >>>> in > > >>>> >>>>>> one go? I ask because > > >>>> >>>>>> > >>>>>>>> > > otherwise, it > > >>>> >>>>>> will look a bit weird to > > >>>> >>>>>> > have > > >>>> >>>>>> > >>>>>>>> > > parts of the > > >>>> >>>>>> file as 8-indent and others > > >>>> >>>>>> > >>>>>>>> 4-indent? > > >>>> >>>>>> > >>>>>>>> > > >>>> >>>>>> > >>>>>>>> > > Thanks for > > >>>> >>>>>> looking at it! > > >>>> >>>>>> > >>>>>>>> > Jc > > >>>> >>>>>> > >>>>>>>> > > >>>> >>>>>> > >>>>>>>> > > On Mon, Nov > > >>>> 19, > > >>>> >>>>>> 2018 at 1:25 AM > > >>>> >>>>>> > >>>>>>>> > > serguei.spitsyn at oracle.com > > >>>> >>>>>> > > > > >>>> >>>>>> > > > >>>> >>>>>> > >> > > >>>> >>>>>> > >>>>>>>> > >>>> serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com> > > >>>> >>>>>> > > > > >>>> >>>>>> > > > serguei.spitsyn at oracle.com> > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>>>>>>> > > > > >>>> >>>>>> > > > > >>>> >>>>>> > > > serguei.spitsyn at oracle.com> > > >>>> >>>>>> > >> > > >>>> >>>>>> > >>>>>>>> > >>>> serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com> > > >>>> >>>>>> > > > > >>>> >>>>>> > > > serguei.spitsyn at oracle.com> > > >>>> >>>>>> > >>>> wrote: > > >>>> >>>>>> > >>>>>>>> > > >>>> >>>>>> > >>>>>>>> > > Hi Jc, > > >>>> >>>>>> > >>>>>>>> > > >>>> >>>>>> > >>>>>>>> > > We have > > >>>> to > > >>>> >>>>>> start this review > > >>>> >>>>>> > anyway. :) > > >>>> >>>>>> > >>>>>>>> > > It looks > > >>>> >>>>>> good to me in general. > > >>>> >>>>>> > >>>>>>>> > > Thank you > > >>>> >>>>>> for your consistency in this > > >>>> >>>>>> > >>>>>>>> > > >>>> refactoring! > > >>>> >>>>>> > >>>>>>>> > > >>>> >>>>>> > >>>>>>>> > > Some > > >>>> minor > > >>>> >>>>>> comments. > > >>>> >>>>>> > >>>>>>>> > > >>>> >>>>>> > >>>>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > > >>>> > > > http://cr.openjdk.java.net/%7Ejcbeyler/8213501/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.cpp.udiff.html > > >>>> >>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > >>>>>>>> > > >>>> >>>>>> > >>>>>>>> > > +static > > >>>> >>>>>> const char* > > >>>> >>>>>> > remove_folders(const > > >>>> >>>>>> > >>>>>>>> > > char* > > >>>> >>>>>> fullname) { I'd suggest to > > >>>> >>>>>> > rename > > >>>> >>>>>> > >>>>>>>> > > the > > >>>> function > > >>>> >>>>>> name to something > > >>>> >>>>>> > traditional > > >>>> >>>>>> > >>>>>>>> > > like > > >>>> >>>>>> get_basename. Otherwise, it > > >>>> >>>>>> > sounds > > >>>> >>>>>> > >>>>>>>> > > like this > > >>>> >>>>>> function has to really > > >>>> >>>>>> > remove > > >>>> >>>>>> > >>>>>>>> > > folders. > > >>>> :) > > >>>> >>>>>> Also, all *Locker.cpp have > > >>>> >>>>>> > >>>>>>>> > > wrong > > >>>> indent > > >>>> >>>>>> in the bodies of if > > >>>> >>>>>> > and while > > >>>> >>>>>> > >>>>>>>> > > >>>> statements. > > >>>> >>>>>> Could this be fixed > > >>>> >>>>>> > with the > > >>>> >>>>>> > >>>>>>>> > > >>>> refactoring? > > >>>> >>>>>> I did not look on how > > >>>> >>>>>> > this > > >>>> >>>>>> > >>>>>>>> > > impacts > > >>>> the > > >>>> >>>>>> tests other than > > >>>> >>>>>> > >>>>>>>> > > serviceability. > > >>>> Thanks, > > >>>> >>>>>> Serguei > > >>>> >>>>>> > >>>>>>>> > > >>>> >>>>>> > >>>>>>>> > > >>>> >>>>>> > >>>>>>>> > > On > > >>>> 11/16/18 > > >>>> >>>>>> 19:43, JC Beyler wrote: > > >>>> >>>>>> > >>>>>>>>> > > Hi all, > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > >>>>>>>>> > > Anybody > > >>>> >>>>>> motivated to review this? :) > > >>>> >>>>>> > >>>>>>>>> > Jc > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > >>>>>>>>> > > On Wed, Nov > > >>>> 7, > > >>>> >>>>>> 2018 at 9:53 PM JC > > >>>> >>>>>> > Beyler > > >>>> >>>>>> > >>>>>>>>> > > > > >>>> >>>>>> > > > > >>>> >>>>>> > > > > >>>> >>>>>> > >> > > >>>> >>>>>> > >>>>>>>>> > > > > >>>> >>>>>> > > > > >>>> >>>>>> > > > > >>>> >>>>>> > >>>> wrote: > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > >>>>>>>>> > > Hi all, > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > >>>>>>>>> > > Could I > > >>>> have > > >>>> >>>>>> a review for the > > >>>> >>>>>> > >>>>>>>>> > > extension > > >>>> >>>>>> and usage of the > > >>>> >>>>>> > >>>>>>>>> ExceptionJniWrapper. > This > > >>>> >>>>>> > adds lines > > >>>> >>>>>> > >>>>>>>>> > > and > > >>>> >>>>>> filenames to the end of the > > >>>> >>>>>> > >>>>>>>>> > > wrapper > > >>>> JNI > > >>>> >>>>>> methods, adds > > >>>> >>>>>> > tracing, > > >>>> >>>>>> > >>>>>>>>> > > and > > >>>> throws > > >>>> >>>>>> an error if need > > >>>> >>>>>> > be. I've > > >>>> >>>>>> > >>>>>>>>> > > ported > > >>>> the > > >>>> >>>>>> gc/lock files to > > >>>> >>>>>> > use the > > >>>> >>>>>> > >>>>>>>>> > > new > > >>>> >>>>>> TRACE_JNI_CALL add-on and > > >>>> >>>>>> > I've > > >>>> >>>>>> > >>>>>>>>> > > ported a > > >>>> few > > >>>> >>>>>> of the tests > > >>>> >>>>>> > that were > > >>>> >>>>>> > >>>>>>>>> > > already > > >>>> >>>>>> changed for the > > >>>> >>>>>> > assignment > > >>>> >>>>>> > >>>>>>>>> > > webrev > > >>>> for > > >>>> >>>>>> JDK-8212884. > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > >>>>>>>>> > > Webrev: > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.00/ > > >>>> >>>>>> > > > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > > > > >>>> >>>>>> > >>>>>>>>> > > Bug: > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213501 > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > >>>>>>>>> > > For > > >>>> >>>>>> illustration, if I force > > >>>> >>>>>> > an error > > >>>> >>>>>> > >>>>>>>>> > > to the > > >>>> >>>>>> AP04/ap04t03 test and > > >>>> >>>>>> > set the > > >>>> >>>>>> > >>>>>>>>> > > verbosity > > >>>> >>>>>> on, I get something > > >>>> >>>>>> > like: > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > >>>>>>>>> > > >> > > >>>> Calling > > >>>> >>>>>> JNI method > > >>>> >>>>>> > FindClass from > > >>>> >>>>>> > >>>>>>>>> ap04t003.cpp:343 > > >>>> >>>>>> > >>>>>>>>> > > >> > > >>>> Calling > > >>>> >>>>>> with these > > >>>> >>>>>> > parameter(s): > > >>>> >>>>>> > >>>>>>>>> java/lang/Threadd > > >>>> >>>>>> > >>>>>>>>> > > Wait for > > >>>> >>>>>> thread to finish > > >>>> >>>>>> > >>>>>>>>> > > << Called > > >>>> >>>>>> JNI method > > >>>> >>>>>> > FindClass from > > >>>> >>>>>> > >>>>>>>>> ap04t003.cpp:343 > > >>>> >>>>>> > >>>>>>>>> > > >>>> Exception in > > >>>> >>>>>> thread "Thread-0" > > >>>> >>>>>> > >>>>>>>>> > > java.lang.NoClassDefFoundError: > > >>>> >>>>>> > >>>>>>>>> java/lang/Threadd > > >>>> >>>>>> > >>>>>>>>> > > at > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > > >>>> > > > nsk.jvmti.scenarios.allocation.AP04.ap04t003.runIterateOverHeap(Native > > >>>> >>>>>> > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > >>>>>>>>> > > Method) > > >>>> >>>>>> > >>>>>>>>> > > at > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > > >>>> > > > nsk.jvmti.scenarios.allocation.AP04.ap04t003HeapIterator.runIteration(ap04t003.java:140) > > >>>> > > >>>> >>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > >>>>>>>>> > > at > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > > >>>> > > > nsk.jvmti.scenarios.allocation.AP04.ap04t003Thread.run(ap04t003.java:201) > > >>>> >>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > >>>>>>>>> > > Caused > > >>>> by: > > >>>> >>>>>> > >>>>>>>>> > > java.lang.ClassNotFoundException: > > >>>> >>>>>> > >>>>>>>>> java.lang.Threadd > > >>>> >>>>>> > >>>>>>>>> > > at > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > > >>>> > > > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) > > >>>> > > >>>> >>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > >>>>>>>>> > > at > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > > >>>> > > > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > > >>>> > > >>>> >>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > >>>>>>>>> > > at > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > > java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) > > >>>> >>>>>> > >>>>>>>>> > > ... 3 > > >>>> more > > >>>> >>>>>> > >>>>>>>>> > > FATAL > > >>>> ERROR > > >>>> >>>>>> in native method: JNI > > >>>> >>>>>> > >>>>>>>>> > > method > > >>>> >>>>>> FindClass : internal error > > >>>> >>>>>> > >>>>>>>>> > > from > > >>>> >>>>>> ap04t003.cpp:343 > > >>>> >>>>>> > >>>>>>>>> > > at > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > > >>>> > > > nsk.jvmti.scenarios.allocation.AP04.ap04t003.runIterateOverHeap(Native > > >>>> >>>>>> > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > >>>>>>>>> > > Method) > > >>>> >>>>>> > >>>>>>>>> > > at > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > > >>>> > > > nsk.jvmti.scenarios.allocation.AP04.ap04t003HeapIterator.runIteration(ap04t003.java:140) > > >>>> > > >>>> >>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > >>>>>>>>> > > at > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > > >>>> > > > nsk.jvmti.scenarios.allocation.AP04.ap04t003Thread.run(ap04t003.java:201) > > >>>> >>>>>> > > >>>> >>>>>> > > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > >>>>>>>>> Questions/comments I > > have about > > >>>> >>>>>> > >>>>>>>>> this are: > > >>>> >>>>>> > >>>>>>>>> > > - Do we > > >>>> >>>>>> want to force fatal > > >>>> >>>>>> > errors > > >>>> >>>>>> > >>>>>>>>> > > when a > > >>>> JNI > > >>>> >>>>>> call fails in general? > > >>>> >>>>>> > >>>>>>>>> > > Most of > > >>>> >>>>>> these tests do the right > > >>>> >>>>>> > >>>>>>>>> > > thing and > > >>>> >>>>>> test the return of > > >>>> >>>>>> > the JNI > > >>>> >>>>>> > >>>>>>>>> > > calls, > > >>>> for > > >>>> >>>>>> example: > > >>>> >>>>>> > >>>>>>>>> > > thrClass > > >>>> = > > >>>> >>>>>> > >>>>>>>>> > > jni->FindClass("java/lang/Threadd", > > >>>> >>>>>> > >>>>>>>>> TRACE_JNI_CALL); > > >>>> >>>>>> > >>>>>>>>> > > if > > >>>> >>>>>> (thrClass == NULL) { > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > >>>>>>>>> > > but now > > >>>> the > > >>>> >>>>>> wrapper actually > > >>>> >>>>>> > would do > > >>>> >>>>>> > >>>>>>>>> > > a fatal > > >>>> if > > >>>> >>>>>> the FindClass call > > >>>> >>>>>> > would > > >>>> >>>>>> > >>>>>>>>> > > return a > > >>>> >>>>>> nullptr, so we could > > >>>> >>>>>> > remove > > >>>> >>>>>> > >>>>>>>>> > > that test > > >>>> >>>>>> altogether. What do > > >>>> >>>>>> > you > > >>>> >>>>>> > >>>>>>>>> think? > > >>>> >>>>>> > >>>>>>>>> > > - I > > >>>> >>>>>> prefer to leave them > > >>>> >>>>>> > as the > > >>>> >>>>>> > >>>>>>>>> > > tests > > >>>> then > > >>>> >>>>>> become closer to > > >>>> >>>>>> > what real > > >>>> >>>>>> > >>>>>>>>> > > users > > >>>> would > > >>>> >>>>>> have in their > > >>>> >>>>>> > code and is > > >>>> >>>>>> > >>>>>>>>> > > the > > >>>> >>>>>> "recommended" way of doing it > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > >>>>>>>>> > > - The > > >>>> >>>>>> alternative is to > > >>>> >>>>>> > use the > > >>>> >>>>>> > >>>>>>>>> > > NonFatalError I > > >>>> added > > >>>> >>>>>> which > > >>>> >>>>>> > then just > > >>>> >>>>>> > >>>>>>>>> > > prints > > >>>> out > > >>>> >>>>>> that something > > >>>> >>>>>> > went wrong, > > >>>> >>>>>> > >>>>>>>>> > > letting > > >>>> the > > >>>> >>>>>> test continue. > > >>>> >>>>>> > Question > > >>>> >>>>>> > >>>>>>>>> > > will be > > >>>> what > > >>>> >>>>>> should be the > > >>>> >>>>>> > default? > > >>>> >>>>>> > >>>>>>>>> > > The > > >>>> fatal or > > >>>> >>>>>> the non-fatal error > > >>>> >>>>>> > >>>>>>>>> > > handling? > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > >>>>>>>>> > > On a > > >>>> >>>>>> different subject: > > >>>> >>>>>> > >>>>>>>>> > > - On > > >>>> the > > >>>> >>>>>> new tests, I've > > >>>> >>>>>> > removed > > >>>> >>>>>> > >>>>>>>>> > > the > > >>>> >>>>>> NSK_JNI_VERIFY since the JNI > > >>>> >>>>>> > >>>>>>>>> > > wrapper > > >>>> >>>>>> handles the tracing > > >>>> >>>>>> > and the > > >>>> >>>>>> > >>>>>>>>> > > verify in > > >>>> >>>>>> almost the same > > >>>> >>>>>> > way; only > > >>>> >>>>>> > >>>>>>>>> > > >>>> difference I > > >>>> >>>>>> can really tell > > >>>> >>>>>> > is that > > >>>> >>>>>> > >>>>>>>>> > > the > > >>>> complain > > >>>> >>>>>> method from NSK > > >>>> >>>>>> > has a > > >>>> >>>>>> > >>>>>>>>> > > max > > >>>> complain > > >>>> >>>>>> before stopping to > > >>>> >>>>>> > >>>>>>>>> > > >>>> "complain"; > > >>>> >>>>>> I have not added that > > >>>> >>>>>> > >>>>>>>>> > > part of > > >>>> the > > >>>> >>>>>> code in this webrev > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > >>>>>>>>> > > Once we > > >>>> >>>>>> decide on these, I can > > >>>> >>>>>> > >>>>>>>>> > > continue > > >>>> on > > >>>> >>>>>> the files from > > >>>> >>>>>> > >>>>>>>>> > > >>>> JDK-8212884 > > >>>> >>>>>> and then do both the > > >>>> >>>>>> > >>>>>>>>> > > >>>> assignment > > >>>> >>>>>> in an if extraction > > >>>> >>>>>> > >>>>>>>>> > > >>>> followed-by > > >>>> >>>>>> this type of > > >>>> >>>>>> > webrev in an > > >>>> >>>>>> > >>>>>>>>> > > easier > > >>>> >>>>>> fashion. Depending on > > >>>> >>>>>> > >>>>>>>>> > > decisions > > >>>> >>>>>> here, NSK*VERIFY can be > > >>>> >>>>>> > >>>>>>>>> > > >>>> deprecated > > >>>> >>>>>> as well as we go > > >>>> >>>>>> > forward. > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > >>>>>>>>> > > Thank you > > >>>> >>>>>> for the > > >>>> >>>>>> > reviews/comments :) > > >>>> >>>>>> > >>>>>>>>> > > Jc > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > >>>>>>>>> > > >>>> >>>>>> > >>>>>>>>> > -- > > >>>> >>>>>> > >>>>>>>>> > > Thanks, > > >>>> >>>>>> > >>>>>>>>> > Jc > > >>>> >>>>>> > >>>>>>>> > > >>>> >>>>>> > >>>>>>>> > > >>>> >>>>>> > >>>>>>>> > > >>>> >>>>>> > >>>>>>>> > -- > > >>>> >>>>>> > >>>>>>>> > > Thanks, > > >>>> >>>>>> > >>>>>>>> > Jc > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> > > >>>> >>>>>> > >>>>>>> -- > > >>>> >>>>>> > >>>>>>> > Thanks, > > >>>> >>>>>> > >>>>>>> Jc > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> > > >>>> >>>>>> > >>>>>> -- > > >>>> >>>>>> > >>>>>> Thanks, > > >>>> >>>>>> > >>>>>> Jc > > >>>> >>>>>> > >>>>> > > >>>> >>>>>> > >>>>> > > >>>> >>>>>> > >>>>> > > >>>> >>>>>> > >>>>> > > >>>> >>>>>> > >>>>> -- > > >>>> >>>>>> > >>>>> Thanks, > > >>>> >>>>>> > >>>>> Jc > > >>>> >>>>>> > >>>> > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>> -- > > >>>> >>>>>> > >>> Thanks, > > >>>> >>>>>> > >>> Jc > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>> -- > > >>>> >>>>>> > >>> > > >>>> >>>>>> > >>> Thanks, > > >>>> >>>>>> > >>> Jc > > >>>> >>>>>> > > > > >>>> >>>>>> > > > > >>>> >>>>>> > > > >>>> >>>>>> > > > >>>> >>>>>> > > > >>>> >>>>>> > -- > > >>>> >>>>>> > > > >>>> >>>>>> > Thanks, > > >>>> >>>>>> > Jc > > >>>> >>>>>> > > >>>> >>>>>> > > >>>> >>>>>> > > >>>> >>>>>> -- > > >>>> >>>>>> Thanks, > > >>>> >>>>>> Jc > > >>>> >>>>> > > >>>> >>>>> > > >>>> >>>>> > > >>>> >>>>> -- > > >>>> >>>>> Thanks, > > >>>> >>>>> Jc > > >>>> >>>> > > >>>> >>>> > > >>>> >>>> > > >>>> >>>> -- > > >>>> >>>> Thanks, > > >>>> >>>> Jc > > >>>> >>>> > > >>>> >>>> > > >>>> >>>> > > >>>> >>>> -- > > >>>> >>>> > > >>>> >>>> Thanks, > > >>>> >>>> Jc > > >>>> >>> > > >>>> > > > >>>> > > >>> > > >>> > > >>> -- > > >>> > > >>> Thanks, > > >>> Jc > > >>> > > >> > > >> > > >> -- > > >> > > >> Thanks, > > >> Jc > > >> > > > > > > > > > -- > > > > > > Thanks, > > > Jc > > > > > > > > > -- > > > > Thanks, > > Jc > > > > > > > > > > -- > > > > Thanks, > > Jc > > > > > -- > > > > Thanks, > > Jc > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc From fanjinke51 at yeah.net Thu Apr 11 02:58:08 2019 From: fanjinke51 at yeah.net (Jinke Fan) Date: Thu, 11 Apr 2019 10:58:08 +0800 Subject: [PATCH v3] JDK-8222090: Add Hygon Dhyana support In-Reply-To: References: <8eb195a5-900d-6adb-3b10-fbef47c3dbff@oracle.com> <5edf2eea-93ee-aae5-fac5-db6d92cee9e2@oracle.com> Message-ID: <375b6491-3cd8-3756-ff49-3729214234ed@yeah.net> On 2019/4/11 10:48, Vladimir Kozlov wrote: > On 4/10/19 6:14 PM, David Holmes wrote: >> Hi Vladimir, >> >> Thanks for taking look at this. >> >> On 11/04/2019 2:41 am, Vladimir Kozlov wrote: >>> Instead of repeated is_amd() || is_hygon() you can use >>> is_amd_or_hygon() to be more clean. >> >> That doesn't really scale if we get more "cousins" joining the AMD >> family. I prefer to see the explicit disjunction form. > > is_amd_family() ? If it was 2 or 3 cases I would agree with you. But you > have 10 checks! > >> >>> Next check should be explicit for CPU: >>> >>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >>> >>> --- >>> >>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>> +??? if ( (cpu_family() == 0x17) && is_amd() || (cpu_family() == >>> 0x18) && is_hygon()) { >> >> I'm wondering if that should just be an assertion? I would not expect >> it to be possible to have a family 0x17 that is not AMD and likewise >> for family 0x18 and Hygon. But then I don't know how these family ids >> get issued. ?? > > It is not clear what agreement AMD has with these companies. Any company > (as AMD and Intel) may have own set of cpu_family ids and we can't > assume that ids will not be reused. They have only 8 bits for ID. Hygon has negotiated with AMD to make sure that only Hygon will use family 18h, so try to minimize code modification and share most codes with AMD under this consideration. Best Regards? Fanjinke > > Thanks, > Vladimir > >> >> Thanks, >> David >> >>> Thanks, >>> Vladimir >>> >>> On 4/10/19 12:33 AM, David Holmes wrote: >>>> Hi Fanjinke, >>>> >>>> This looks fine to me. I've updated the webrev at: >>>> >>>> http://cr.openjdk.java.net/~dholmes/8222090/webrev.v3/ >>>> >>>> We need a second reviewer before I push it. >>>> >>>> Thanks, >>>> David >>>> >>>> On 9/04/2019 5:22 pm, Jinke Fan wrote: >>>>> diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp >>>>> b/src/hotspot/cpu/x86/assembler_x86.cpp >>>>> --- a/src/hotspot/cpu/x86/assembler_x86.cpp >>>>> +++ b/src/hotspot/cpu/x86/assembler_x86.cpp >>>>> @@ -3099,7 +3099,7 @@ >>>>> ????? } >>>>> ????? return; >>>>> ??? } >>>>> -? if (UseAddressNop && VM_Version::is_amd()) { >>>>> +? if (UseAddressNop && (VM_Version::is_amd() || >>>>> VM_Version::is_hygon())) { >>>>> ????? // >>>>> ????? // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. >>>>> ????? //? 1: 0x90 >>>>> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>> b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>> @@ -340,6 +340,10 @@ >>>>> ????? return !is_amd_Barcelona(); >>>>> ??? } >>>>> >>>>> +? if (is_hygon()) { >>>>> +??? return true; >>>>> +? } >>>>> + >>>>> ??? return false; >>>>> ??} >>>>> >>>>> @@ -407,6 +411,10 @@ >>>>> ????? } >>>>> ????? return _family_id_intel[cpu_family_id]; >>>>> ??? } >>>>> +? if (is_hygon()) { >>>>> +????? return "Dhyana"; >>>>> +? } >>>>> + >>>>> ??? return "Unknown x86"; >>>>> ??} >>>>> >>>>> @@ -423,6 +431,9 @@ >>>>> ??? } else if (is_amd()) { >>>>> ????? cpu_type = "AMD"; >>>>> ????? x64 = cpu_is_em64t() ? " AMD64" : ""; >>>>> +? } else if (is_hygon()) { >>>>> +?????? cpu_type = "Hygon"; >>>>> +?????? x64 = cpu_is_em64t() ? " AMD64" : ""; >>>>> ??? } else { >>>>> ????? cpu_type = "Unknown x86"; >>>>> ????? x64 = cpu_is_em64t() ? " x86_64" : ""; >>>>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>> b/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>> @@ -1165,7 +1165,7 @@ >>>>> ????? } >>>>> ??? } >>>>> >>>>> -? if( is_amd() ) { // AMD cpus specific settings >>>>> +? if( is_amd() || is_hygon() ) { // AMD cpus specific settings >>>>> ????? if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { >>>>> ??????? // Use it on new AMD cpus starting from Opteron. >>>>> ??????? UseAddressNop = true; >>>>> @@ -1239,8 +1239,8 @@ >>>>> ????? } >>>>> ??#endif // COMPILER2 >>>>> >>>>> -??? // Some defaults for AMD family 17h >>>>> -??? if ( cpu_family() == 0x17 ) { >>>>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>>>> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >>>>> ??????? // On family 17h processors use XMM and UnalignedLoadStores >>>>> for Array Copy >>>>> ??????? if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >>>>> ????????? FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >>>>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>> b/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>> --- a/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>> +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>> @@ -495,13 +495,13 @@ >>>>> ??????? result |= CPU_CX8; >>>>> ????? if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) >>>>> ??????? result |= CPU_CMOV; >>>>> -??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && >>>>> +??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() || >>>>> is_hygon()) && >>>>> ????????? _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) >>>>> ??????? result |= CPU_FXSR; >>>>> ????? // HT flag is set for multi-core processors also. >>>>> ????? if (threads_per_core() > 1) >>>>> ??????? result |= CPU_HT; >>>>> -??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && >>>>> +??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() || >>>>> is_hygon()) && >>>>> ????????? _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) >>>>> ??????? result |= CPU_MMX; >>>>> ????? if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) >>>>> @@ -576,8 +576,8 @@ >>>>> ????? if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>> ??????? result |= CPU_FMA; >>>>> >>>>> -??? // AMD features. >>>>> -??? if (is_amd()) { >>>>> +??? // AMD|Hygon features. >>>>> +??? if (is_amd() || is_hygon()) { >>>>> ??????? if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || >>>>> ??????????? (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) >>>>> ????????? result |= CPU_3DNOW_PREFETCH; >>>>> @@ -711,6 +711,7 @@ >>>>> ??? static int? cpu_family()??????? { return _cpu;} >>>>> ??? static bool is_P6()???????????? { return cpu_family() >= 6; } >>>>> ??? static bool is_amd()??????????? { assert_is_initialized(); >>>>> return _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' >>>>> +? static bool is_hygon()????????? { assert_is_initialized(); >>>>> return _cpuid_info.std_vendor_name_0 == 0x6F677948; } // 'ogyH' >>>>> ??? static bool is_intel()????????? { assert_is_initialized(); >>>>> return _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' >>>>> ??? static bool is_zx()???????????? { assert_is_initialized(); >>>>> return (_cpuid_info.std_vendor_name_0 == 0x746e6543) || >>>>> (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS? ' >>>>> ??? static bool is_atom_family()??? { return ((cpu_family() == >>>>> 0x06) && ((extended_cpu_model() == 0x36) || (extended_cpu_model() >>>>> == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont and >>>>> Centerton >>>>> @@ -734,7 +735,7 @@ >>>>> ??????? if (!supports_topology || result == 0) { >>>>> ????????? result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + >>>>> 1); >>>>> ??????? } >>>>> -??? } else if (is_amd()) { >>>>> +??? } else if (is_amd() || is_hygon()) { >>>>> ??????? result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); >>>>> ????? } else if (is_zx()) { >>>>> ??????? bool supports_topology = supports_processor_topology(); >>>>> @@ -770,7 +771,7 @@ >>>>> ????? intx result = 0; >>>>> ????? if (is_intel()) { >>>>> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>>>> -??? } else if (is_amd()) { >>>>> +??? } else if (is_amd() || is_hygon()) { >>>>> ??????? result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; >>>>> ????? } else if (is_zx()) { >>>>> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>>>> @@ -857,7 +858,7 @@ >>>>> >>>>> ??? // AMD features >>>>> ??? static bool supports_3dnow_prefetch()??? { return (_features & >>>>> CPU_3DNOW_PREFETCH) != 0; } >>>>> -? static bool supports_mmx_ext()? { return is_amd() && >>>>> _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >>>>> +? static bool supports_mmx_ext()? { return (is_amd()||is_hygon()) >>>>> && _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >>>>> ??? static bool supports_lzcnt()??? { return (_features & >>>>> CPU_LZCNT) != 0; } >>>>> ??? static bool supports_sse4a()??? { return (_features & >>>>> CPU_SSE4A) != 0; } >>>>> >>>>> @@ -870,7 +871,7 @@ >>>>> ??? } >>>>> ??? static bool supports_tscinv() { >>>>> ????? return supports_tscinv_bit() && >>>>> -?????????? ( (is_amd() && !is_amd_Barcelona()) || >>>>> +?????????? ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || >>>>> ?????????????? is_intel_tsc_synched_at_init() ); >>>>> ??? } >>>>> >>>>> @@ -896,7 +897,7 @@ >>>>> ????? // Core????? - 256 / prefetchnta >>>>> ????? // It will be used only when AllocatePrefetchStyle > 0 >>>>> >>>>> -??? if (is_amd()) { // AMD >>>>> +??? if (is_amd() || is_hygon()) { // AMD >>>>> ??????? if (supports_sse2()) { >>>>> ????????? return 256; // Opteron >>>>> ??????? } else { > From david.holmes at oracle.com Thu Apr 11 05:26:52 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Apr 2019 15:26:52 +1000 Subject: [PATCH v3] JDK-8222090: Add Hygon Dhyana support In-Reply-To: <375b6491-3cd8-3756-ff49-3729214234ed@yeah.net> References: <8eb195a5-900d-6adb-3b10-fbef47c3dbff@oracle.com> <5edf2eea-93ee-aae5-fac5-db6d92cee9e2@oracle.com> <375b6491-3cd8-3756-ff49-3729214234ed@yeah.net> Message-ID: <1e349a3f-11c8-af6f-8b23-6056a81897ae@oracle.com> Updated webrev: http://cr.openjdk.java.net/~dholmes/8222090/webrev.v4/ Seems comments below On 11/04/2019 12:58 pm, Jinke Fan wrote: > On 2019/4/11 10:48, Vladimir Kozlov wrote: >> On 4/10/19 6:14 PM, David Holmes wrote: >>> Hi Vladimir, >>> >>> Thanks for taking look at this. >>> >>> On 11/04/2019 2:41 am, Vladimir Kozlov wrote: >>>> Instead of repeated is_amd() || is_hygon() you can use >>>> is_amd_or_hygon() to be more clean. >>> >>> That doesn't really scale if we get more "cousins" joining the AMD >>> family. I prefer to see the explicit disjunction form. >> >> is_amd_family() ? If it was 2 or 3 cases I would agree with you. But >> you have 10 checks! I made this change. It is also "forced" me to fix up numerous coding style nits with missing and extra spaces in if-expressions. (Sorry) >> >>> >>>> Next check should be explicit for CPU: >>>> >>>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>>> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >>>> >>>> --- >>>> >>>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>>> +??? if ( (cpu_family() == 0x17) && is_amd() || (cpu_family() == >>>> 0x18) && is_hygon()) { >>> >>> I'm wondering if that should just be an assertion? I would not expect >>> it to be possible to have a family 0x17 that is not AMD and likewise >>> for family 0x18 and Hygon. But then I don't know how these family ids >>> get issued. ?? >> >> It is not clear what agreement AMD has with these companies. Any >> company (as AMD and Intel) may have own set of cpu_family ids and we >> can't assume that ids will not be reused. They have only 8 bits for ID. > Hygon has negotiated with AMD to make sure that only Hygon will > use family 18h, so try to minimize code modification and share most > codes with AMD under this consideration. I think in that case we do not need to also check for is_amd() and is_hygon() (noting that the code in question is already in a block guarded by is_amd_family()). Thanks, David ----- > > Best Regards? > Fanjinke >> >> Thanks, >> Vladimir >> >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 4/10/19 12:33 AM, David Holmes wrote: >>>>> Hi Fanjinke, >>>>> >>>>> This looks fine to me. I've updated the webrev at: >>>>> >>>>> http://cr.openjdk.java.net/~dholmes/8222090/webrev.v3/ >>>>> >>>>> We need a second reviewer before I push it. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 9/04/2019 5:22 pm, Jinke Fan wrote: >>>>>> diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp >>>>>> b/src/hotspot/cpu/x86/assembler_x86.cpp >>>>>> --- a/src/hotspot/cpu/x86/assembler_x86.cpp >>>>>> +++ b/src/hotspot/cpu/x86/assembler_x86.cpp >>>>>> @@ -3099,7 +3099,7 @@ >>>>>> ????? } >>>>>> ????? return; >>>>>> ??? } >>>>>> -? if (UseAddressNop && VM_Version::is_amd()) { >>>>>> +? if (UseAddressNop && (VM_Version::is_amd() || >>>>>> VM_Version::is_hygon())) { >>>>>> ????? // >>>>>> ????? // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. >>>>>> ????? //? 1: 0x90 >>>>>> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>>> b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>>> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>>> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>>> @@ -340,6 +340,10 @@ >>>>>> ????? return !is_amd_Barcelona(); >>>>>> ??? } >>>>>> >>>>>> +? if (is_hygon()) { >>>>>> +??? return true; >>>>>> +? } >>>>>> + >>>>>> ??? return false; >>>>>> ??} >>>>>> >>>>>> @@ -407,6 +411,10 @@ >>>>>> ????? } >>>>>> ????? return _family_id_intel[cpu_family_id]; >>>>>> ??? } >>>>>> +? if (is_hygon()) { >>>>>> +????? return "Dhyana"; >>>>>> +? } >>>>>> + >>>>>> ??? return "Unknown x86"; >>>>>> ??} >>>>>> >>>>>> @@ -423,6 +431,9 @@ >>>>>> ??? } else if (is_amd()) { >>>>>> ????? cpu_type = "AMD"; >>>>>> ????? x64 = cpu_is_em64t() ? " AMD64" : ""; >>>>>> +? } else if (is_hygon()) { >>>>>> +?????? cpu_type = "Hygon"; >>>>>> +?????? x64 = cpu_is_em64t() ? " AMD64" : ""; >>>>>> ??? } else { >>>>>> ????? cpu_type = "Unknown x86"; >>>>>> ????? x64 = cpu_is_em64t() ? " x86_64" : ""; >>>>>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>>> b/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>>> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>>> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>>> @@ -1165,7 +1165,7 @@ >>>>>> ????? } >>>>>> ??? } >>>>>> >>>>>> -? if( is_amd() ) { // AMD cpus specific settings >>>>>> +? if( is_amd() || is_hygon() ) { // AMD cpus specific settings >>>>>> ????? if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { >>>>>> ??????? // Use it on new AMD cpus starting from Opteron. >>>>>> ??????? UseAddressNop = true; >>>>>> @@ -1239,8 +1239,8 @@ >>>>>> ????? } >>>>>> ??#endif // COMPILER2 >>>>>> >>>>>> -??? // Some defaults for AMD family 17h >>>>>> -??? if ( cpu_family() == 0x17 ) { >>>>>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>>>>> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >>>>>> ??????? // On family 17h processors use XMM and >>>>>> UnalignedLoadStores for Array Copy >>>>>> ??????? if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >>>>>> ????????? FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >>>>>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>>> b/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>>> --- a/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>>> +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>>> @@ -495,13 +495,13 @@ >>>>>> ??????? result |= CPU_CX8; >>>>>> ????? if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) >>>>>> ??????? result |= CPU_CMOV; >>>>>> -??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && >>>>>> +??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() >>>>>> || is_hygon()) && >>>>>> ????????? _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) >>>>>> ??????? result |= CPU_FXSR; >>>>>> ????? // HT flag is set for multi-core processors also. >>>>>> ????? if (threads_per_core() > 1) >>>>>> ??????? result |= CPU_HT; >>>>>> -??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && >>>>>> +??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() || >>>>>> is_hygon()) && >>>>>> ????????? _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) >>>>>> ??????? result |= CPU_MMX; >>>>>> ????? if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) >>>>>> @@ -576,8 +576,8 @@ >>>>>> ????? if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>>> ??????? result |= CPU_FMA; >>>>>> >>>>>> -??? // AMD features. >>>>>> -??? if (is_amd()) { >>>>>> +??? // AMD|Hygon features. >>>>>> +??? if (is_amd() || is_hygon()) { >>>>>> ??????? if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || >>>>>> ??????????? (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) >>>>>> ????????? result |= CPU_3DNOW_PREFETCH; >>>>>> @@ -711,6 +711,7 @@ >>>>>> ??? static int? cpu_family()??????? { return _cpu;} >>>>>> ??? static bool is_P6()???????????? { return cpu_family() >= 6; } >>>>>> ??? static bool is_amd()??????????? { assert_is_initialized(); >>>>>> return _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' >>>>>> +? static bool is_hygon()????????? { assert_is_initialized(); >>>>>> return _cpuid_info.std_vendor_name_0 == 0x6F677948; } // 'ogyH' >>>>>> ??? static bool is_intel()????????? { assert_is_initialized(); >>>>>> return _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' >>>>>> ??? static bool is_zx()???????????? { assert_is_initialized(); >>>>>> return (_cpuid_info.std_vendor_name_0 == 0x746e6543) || >>>>>> (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS? ' >>>>>> ??? static bool is_atom_family()??? { return ((cpu_family() == >>>>>> 0x06) && ((extended_cpu_model() == 0x36) || (extended_cpu_model() >>>>>> == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont and >>>>>> Centerton >>>>>> @@ -734,7 +735,7 @@ >>>>>> ??????? if (!supports_topology || result == 0) { >>>>>> ????????? result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu >>>>>> + 1); >>>>>> ??????? } >>>>>> -??? } else if (is_amd()) { >>>>>> +??? } else if (is_amd() || is_hygon()) { >>>>>> ??????? result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); >>>>>> ????? } else if (is_zx()) { >>>>>> ??????? bool supports_topology = supports_processor_topology(); >>>>>> @@ -770,7 +771,7 @@ >>>>>> ????? intx result = 0; >>>>>> ????? if (is_intel()) { >>>>>> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>>>>> -??? } else if (is_amd()) { >>>>>> +??? } else if (is_amd() || is_hygon()) { >>>>>> ??????? result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; >>>>>> ????? } else if (is_zx()) { >>>>>> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>>>>> @@ -857,7 +858,7 @@ >>>>>> >>>>>> ??? // AMD features >>>>>> ??? static bool supports_3dnow_prefetch()??? { return (_features & >>>>>> CPU_3DNOW_PREFETCH) != 0; } >>>>>> -? static bool supports_mmx_ext()? { return is_amd() && >>>>>> _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >>>>>> +? static bool supports_mmx_ext()? { return (is_amd()||is_hygon()) >>>>>> && _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >>>>>> ??? static bool supports_lzcnt()??? { return (_features & >>>>>> CPU_LZCNT) != 0; } >>>>>> ??? static bool supports_sse4a()??? { return (_features & >>>>>> CPU_SSE4A) != 0; } >>>>>> >>>>>> @@ -870,7 +871,7 @@ >>>>>> ??? } >>>>>> ??? static bool supports_tscinv() { >>>>>> ????? return supports_tscinv_bit() && >>>>>> -?????????? ( (is_amd() && !is_amd_Barcelona()) || >>>>>> +?????????? ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || >>>>>> ?????????????? is_intel_tsc_synched_at_init() ); >>>>>> ??? } >>>>>> >>>>>> @@ -896,7 +897,7 @@ >>>>>> ????? // Core????? - 256 / prefetchnta >>>>>> ????? // It will be used only when AllocatePrefetchStyle > 0 >>>>>> >>>>>> -??? if (is_amd()) { // AMD >>>>>> +??? if (is_amd() || is_hygon()) { // AMD >>>>>> ??????? if (supports_sse2()) { >>>>>> ????????? return 256; // Opteron >>>>>> ??????? } else { >> > From fanjinke51 at yeah.net Thu Apr 11 05:51:22 2019 From: fanjinke51 at yeah.net (Jinke Fan) Date: Thu, 11 Apr 2019 13:51:22 +0800 Subject: [PATCH v3] JDK-8222090: Add Hygon Dhyana support In-Reply-To: <1e349a3f-11c8-af6f-8b23-6056a81897ae@oracle.com> References: <8eb195a5-900d-6adb-3b10-fbef47c3dbff@oracle.com> <5edf2eea-93ee-aae5-fac5-db6d92cee9e2@oracle.com> <375b6491-3cd8-3756-ff49-3729214234ed@yeah.net> <1e349a3f-11c8-af6f-8b23-6056a81897ae@oracle.com> Message-ID: Hi David, This looks good to me. Thank all of you. Best Regards! Fanjinke On 2019/4/11 13:26, David Holmes wrote: > Updated webrev: > > http://cr.openjdk.java.net/~dholmes/8222090/webrev.v4/ > > Seems comments below > > On 11/04/2019 12:58 pm, Jinke Fan wrote: >> On 2019/4/11 10:48, Vladimir Kozlov wrote: >>> On 4/10/19 6:14 PM, David Holmes wrote: >>>> Hi Vladimir, >>>> >>>> Thanks for taking look at this. >>>> >>>> On 11/04/2019 2:41 am, Vladimir Kozlov wrote: >>>>> Instead of repeated is_amd() || is_hygon() you can use >>>>> is_amd_or_hygon() to be more clean. >>>> >>>> That doesn't really scale if we get more "cousins" joining the AMD >>>> family. I prefer to see the explicit disjunction form. >>> >>> is_amd_family() ? If it was 2 or 3 cases I would agree with you. But >>> you have 10 checks! > > I made this change. It is also "forced" me to fix up numerous coding > style nits with missing and extra spaces in if-expressions. (Sorry) > >>> >>>> >>>>> Next check should be explicit for CPU: >>>>> >>>>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>>>> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >>>>> >>>>> --- >>>>> >>>>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>>>> +??? if ( (cpu_family() == 0x17) && is_amd() || (cpu_family() == >>>>> 0x18) && is_hygon()) { >>>> >>>> I'm wondering if that should just be an assertion? I would not >>>> expect it to be possible to have a family 0x17 that is not AMD and >>>> likewise for family 0x18 and Hygon. But then I don't know how these >>>> family ids get issued. ?? >>> >>> It is not clear what agreement AMD has with these companies. Any >>> company (as AMD and Intel) may have own set of cpu_family ids and we >>> can't assume that ids will not be reused. They have only 8 bits for ID. >> Hygon has negotiated with AMD to make sure that only Hygon will >> use family 18h, so try to minimize code modification and share most >> codes with AMD under this consideration. > > I think in that case we do not need to also check for is_amd() and > is_hygon() (noting that the code in question is already in a block > guarded by is_amd_family()). > > Thanks, > David > ----- >> >> Best Regards? >> Fanjinke >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 4/10/19 12:33 AM, David Holmes wrote: >>>>>> Hi Fanjinke, >>>>>> >>>>>> This looks fine to me. I've updated the webrev at: >>>>>> >>>>>> http://cr.openjdk.java.net/~dholmes/8222090/webrev.v3/ >>>>>> >>>>>> We need a second reviewer before I push it. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 9/04/2019 5:22 pm, Jinke Fan wrote: >>>>>>> diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp >>>>>>> b/src/hotspot/cpu/x86/assembler_x86.cpp >>>>>>> --- a/src/hotspot/cpu/x86/assembler_x86.cpp >>>>>>> +++ b/src/hotspot/cpu/x86/assembler_x86.cpp >>>>>>> @@ -3099,7 +3099,7 @@ >>>>>>> ????? } >>>>>>> ????? return; >>>>>>> ??? } >>>>>>> -? if (UseAddressNop && VM_Version::is_amd()) { >>>>>>> +? if (UseAddressNop && (VM_Version::is_amd() || >>>>>>> VM_Version::is_hygon())) { >>>>>>> ????? // >>>>>>> ????? // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. >>>>>>> ????? //? 1: 0x90 >>>>>>> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>>>> b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>>>> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>>>> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>>>> @@ -340,6 +340,10 @@ >>>>>>> ????? return !is_amd_Barcelona(); >>>>>>> ??? } >>>>>>> >>>>>>> +? if (is_hygon()) { >>>>>>> +??? return true; >>>>>>> +? } >>>>>>> + >>>>>>> ??? return false; >>>>>>> ??} >>>>>>> >>>>>>> @@ -407,6 +411,10 @@ >>>>>>> ????? } >>>>>>> ????? return _family_id_intel[cpu_family_id]; >>>>>>> ??? } >>>>>>> +? if (is_hygon()) { >>>>>>> +????? return "Dhyana"; >>>>>>> +? } >>>>>>> + >>>>>>> ??? return "Unknown x86"; >>>>>>> ??} >>>>>>> >>>>>>> @@ -423,6 +431,9 @@ >>>>>>> ??? } else if (is_amd()) { >>>>>>> ????? cpu_type = "AMD"; >>>>>>> ????? x64 = cpu_is_em64t() ? " AMD64" : ""; >>>>>>> +? } else if (is_hygon()) { >>>>>>> +?????? cpu_type = "Hygon"; >>>>>>> +?????? x64 = cpu_is_em64t() ? " AMD64" : ""; >>>>>>> ??? } else { >>>>>>> ????? cpu_type = "Unknown x86"; >>>>>>> ????? x64 = cpu_is_em64t() ? " x86_64" : ""; >>>>>>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>>>> b/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>>>> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>>>> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>>>> @@ -1165,7 +1165,7 @@ >>>>>>> ????? } >>>>>>> ??? } >>>>>>> >>>>>>> -? if( is_amd() ) { // AMD cpus specific settings >>>>>>> +? if( is_amd() || is_hygon() ) { // AMD cpus specific settings >>>>>>> ????? if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { >>>>>>> ??????? // Use it on new AMD cpus starting from Opteron. >>>>>>> ??????? UseAddressNop = true; >>>>>>> @@ -1239,8 +1239,8 @@ >>>>>>> ????? } >>>>>>> ??#endif // COMPILER2 >>>>>>> >>>>>>> -??? // Some defaults for AMD family 17h >>>>>>> -??? if ( cpu_family() == 0x17 ) { >>>>>>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>>>>>> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >>>>>>> ??????? // On family 17h processors use XMM and >>>>>>> UnalignedLoadStores for Array Copy >>>>>>> ??????? if (supports_sse2() && >>>>>>> FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >>>>>>> ????????? FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >>>>>>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>>>> b/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>>>> --- a/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>>>> +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>>>> @@ -495,13 +495,13 @@ >>>>>>> ??????? result |= CPU_CX8; >>>>>>> ????? if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) >>>>>>> ??????? result |= CPU_CMOV; >>>>>>> -??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && >>>>>>> +??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() >>>>>>> || is_hygon()) && >>>>>>> ????????? _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) >>>>>>> ??????? result |= CPU_FXSR; >>>>>>> ????? // HT flag is set for multi-core processors also. >>>>>>> ????? if (threads_per_core() > 1) >>>>>>> ??????? result |= CPU_HT; >>>>>>> -??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && >>>>>>> +??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() >>>>>>> || is_hygon()) && >>>>>>> ????????? _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) >>>>>>> ??????? result |= CPU_MMX; >>>>>>> ????? if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) >>>>>>> @@ -576,8 +576,8 @@ >>>>>>> ????? if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>>>> ??????? result |= CPU_FMA; >>>>>>> >>>>>>> -??? // AMD features. >>>>>>> -??? if (is_amd()) { >>>>>>> +??? // AMD|Hygon features. >>>>>>> +??? if (is_amd() || is_hygon()) { >>>>>>> ??????? if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || >>>>>>> ??????????? (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) >>>>>>> ????????? result |= CPU_3DNOW_PREFETCH; >>>>>>> @@ -711,6 +711,7 @@ >>>>>>> ??? static int? cpu_family()??????? { return _cpu;} >>>>>>> ??? static bool is_P6()???????????? { return cpu_family() >= 6; } >>>>>>> ??? static bool is_amd()??????????? { assert_is_initialized(); >>>>>>> return _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' >>>>>>> +? static bool is_hygon()????????? { assert_is_initialized(); >>>>>>> return _cpuid_info.std_vendor_name_0 == 0x6F677948; } // 'ogyH' >>>>>>> ??? static bool is_intel()????????? { assert_is_initialized(); >>>>>>> return _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' >>>>>>> ??? static bool is_zx()???????????? { assert_is_initialized(); >>>>>>> return (_cpuid_info.std_vendor_name_0 == 0x746e6543) || >>>>>>> (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS? ' >>>>>>> ??? static bool is_atom_family()??? { return ((cpu_family() == >>>>>>> 0x06) && ((extended_cpu_model() == 0x36) || (extended_cpu_model() >>>>>>> == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont and >>>>>>> Centerton >>>>>>> @@ -734,7 +735,7 @@ >>>>>>> ??????? if (!supports_topology || result == 0) { >>>>>>> ????????? result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu >>>>>>> + 1); >>>>>>> ??????? } >>>>>>> -??? } else if (is_amd()) { >>>>>>> +??? } else if (is_amd() || is_hygon()) { >>>>>>> ??????? result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + >>>>>>> 1); >>>>>>> ????? } else if (is_zx()) { >>>>>>> ??????? bool supports_topology = supports_processor_topology(); >>>>>>> @@ -770,7 +771,7 @@ >>>>>>> ????? intx result = 0; >>>>>>> ????? if (is_intel()) { >>>>>>> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>>>>>> -??? } else if (is_amd()) { >>>>>>> +??? } else if (is_amd() || is_hygon()) { >>>>>>> ??????? result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; >>>>>>> ????? } else if (is_zx()) { >>>>>>> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>>>>>> @@ -857,7 +858,7 @@ >>>>>>> >>>>>>> ??? // AMD features >>>>>>> ??? static bool supports_3dnow_prefetch()??? { return (_features >>>>>>> & CPU_3DNOW_PREFETCH) != 0; } >>>>>>> -? static bool supports_mmx_ext()? { return is_amd() && >>>>>>> _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >>>>>>> +? static bool supports_mmx_ext()? { return >>>>>>> (is_amd()||is_hygon()) && _cpuid_info.ext_cpuid1_edx.bits.mmx_amd >>>>>>> != 0; } >>>>>>> ??? static bool supports_lzcnt()??? { return (_features & >>>>>>> CPU_LZCNT) != 0; } >>>>>>> ??? static bool supports_sse4a()??? { return (_features & >>>>>>> CPU_SSE4A) != 0; } >>>>>>> >>>>>>> @@ -870,7 +871,7 @@ >>>>>>> ??? } >>>>>>> ??? static bool supports_tscinv() { >>>>>>> ????? return supports_tscinv_bit() && >>>>>>> -?????????? ( (is_amd() && !is_amd_Barcelona()) || >>>>>>> +?????????? ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || >>>>>>> ?????????????? is_intel_tsc_synched_at_init() ); >>>>>>> ??? } >>>>>>> >>>>>>> @@ -896,7 +897,7 @@ >>>>>>> ????? // Core????? - 256 / prefetchnta >>>>>>> ????? // It will be used only when AllocatePrefetchStyle > 0 >>>>>>> >>>>>>> -??? if (is_amd()) { // AMD >>>>>>> +??? if (is_amd() || is_hygon()) { // AMD >>>>>>> ??????? if (supports_sse2()) { >>>>>>> ????????? return 256; // Opteron >>>>>>> ??????? } else { >>> >> > From nick.gasson at arm.com Thu Apr 11 10:03:58 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Thu, 11 Apr 2019 18:03:58 +0800 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <571f3d72-a22a-3b52-2942-6408072e353f@oracle.com> <144af13e-33e2-2089-f8d2-902e94485eb1@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> <933540d0-2e72-fed7-3833-35724324e1e6@arm.com> <3523c739-f202-7d9b-6bb2-266606a67ab7@oracle.com> Message-ID: <1886daa5-8f61-6a06-26eb-8023e112f4ef@arm.com> Hi Jamsheed, On 10/04/2019 02:13, Jamsheed wrote: > > i could reproduce the sigsegv. was using slowdebug bits today morning, > and so it didn't fail. > Does the segfault only happen on release builds? I tried webrev.04 again on an AArch64 system with release, fastdebug, and slowdebug but I still don't see this crash :-/. Nick From jamsheed.c.m at oracle.com Thu Apr 11 10:22:41 2019 From: jamsheed.c.m at oracle.com (Jamsheed) Date: Thu, 11 Apr 2019 15:52:41 +0530 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <1886daa5-8f61-6a06-26eb-8023e112f4ef@arm.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <571f3d72-a22a-3b52-2942-6408072e353f@oracle.com> <144af13e-33e2-2089-f8d2-902e94485eb1@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> <933540d0-2e72-fed7-3833-35724324e1e6@arm.com> <3523c739-f202-7d9b-6bb2-266606a67ab7@oracle.com> <1886daa5-8f61-6a06-26eb-8023e112f4ef@arm.com> Message-ID: Hi Nick, i think release and fastdebug should crash basically because, atomic_copy64 get inlined, and get generated as post increment, on sigbus, from doesn't get incremented and it loop forever and crash. Best regards, Jamsheed [1] void _Copy_conjoint_jlongs_atomic(jlong* from, jlong* to, size_t count) { ??? if (from > to) { ????? jlong *end = from + count; ????? while (from < end) ??????? os::atomic_copy64(from++, to++); ??? } ??? else if (from < to) { ????? jlong *end = from; ????? from += count - 1; ????? to?? += count - 1; ????? while (from >= end) ??????? os::atomic_copy64(from--, to--); ??? } ? } ? static void atomic_copy64(const volatile void *src, volatile void *dst) { ????? *(jlong *) dst = *(const jlong *) src; ?? } On 11/04/19 3:33 PM, Nick Gasson wrote: > Does the segfault only happen on release builds? I tried webrev.04 > again on an AArch64 system with release, fastdebug, and slowdebug but > I still don't see this crash :-/. From goetz.lindenmaier at sap.com Thu Apr 11 14:02:57 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 11 Apr 2019 14:02:57 +0000 Subject: RFR(M): jdk11u-dev backport 8205611: Improve the wording of LinkageErrors to include module and class loader information Message-ID: 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 vladimir.kozlov at oracle.com Thu Apr 11 16:04:30 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Apr 2019 09:04:30 -0700 Subject: [PATCH v3] JDK-8222090: Add Hygon Dhyana support In-Reply-To: <1e349a3f-11c8-af6f-8b23-6056a81897ae@oracle.com> References: <8eb195a5-900d-6adb-3b10-fbef47c3dbff@oracle.com> <5edf2eea-93ee-aae5-fac5-db6d92cee9e2@oracle.com> <375b6491-3cd8-3756-ff49-3729214234ed@yeah.net> <1e349a3f-11c8-af6f-8b23-6056a81897ae@oracle.com> Message-ID: <867b3678-0c03-c3a6-ff9c-a16f6566abfe@oracle.com> Hi David, Thank you for cleaning up code. Looks good except next small issues: You missed check in assembler_x86.cpp. In vm_version_ext_x86.cpp indent is wrong in 2 cases: 4 spaces are used instead of 2. Thanks, Vladimir On 4/10/19 10:26 PM, David Holmes wrote: > Updated webrev: > > http://cr.openjdk.java.net/~dholmes/8222090/webrev.v4/ > > Seems comments below > > On 11/04/2019 12:58 pm, Jinke Fan wrote: >> On 2019/4/11 10:48, Vladimir Kozlov wrote: >>> On 4/10/19 6:14 PM, David Holmes wrote: >>>> Hi Vladimir, >>>> >>>> Thanks for taking look at this. >>>> >>>> On 11/04/2019 2:41 am, Vladimir Kozlov wrote: >>>>> Instead of repeated is_amd() || is_hygon() you can use is_amd_or_hygon() to be more clean. >>>> >>>> That doesn't really scale if we get more "cousins" joining the AMD family. I prefer to see the >>>> explicit disjunction form. >>> >>> is_amd_family() ? If it was 2 or 3 cases I would agree with you. But you have 10 checks! > > I made this change. It is also "forced" me to fix up numerous coding style nits with missing and > extra spaces in if-expressions. (Sorry) > >>> >>>> >>>>> Next check should be explicit for CPU: >>>>> >>>>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>>>> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >>>>> >>>>> --- >>>>> >>>>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>>>> +??? if ( (cpu_family() == 0x17) && is_amd() || (cpu_family() == 0x18) && is_hygon()) { >>>> >>>> I'm wondering if that should just be an assertion? I would not expect it to be possible to have >>>> a family 0x17 that is not AMD and likewise for family 0x18 and Hygon. But then I don't know how >>>> these family ids get issued. ?? >>> >>> It is not clear what agreement AMD has with these companies. Any company (as AMD and Intel) may >>> have own set of cpu_family ids and we can't assume that ids will not be reused. They have only 8 >>> bits for ID. >> Hygon has negotiated with AMD to make sure that only Hygon will >> use family 18h, so try to minimize code modification and share most >> codes with AMD under this consideration. > > I think in that case we do not need to also check for is_amd() and is_hygon() (noting that the code > in question is already in a block guarded by is_amd_family()). > > Thanks, > David > ----- >> >> Best Regards? >> Fanjinke >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 4/10/19 12:33 AM, David Holmes wrote: >>>>>> Hi Fanjinke, >>>>>> >>>>>> This looks fine to me. I've updated the webrev at: >>>>>> >>>>>> http://cr.openjdk.java.net/~dholmes/8222090/webrev.v3/ >>>>>> >>>>>> We need a second reviewer before I push it. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 9/04/2019 5:22 pm, Jinke Fan wrote: >>>>>>> diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp b/src/hotspot/cpu/x86/assembler_x86.cpp >>>>>>> --- a/src/hotspot/cpu/x86/assembler_x86.cpp >>>>>>> +++ b/src/hotspot/cpu/x86/assembler_x86.cpp >>>>>>> @@ -3099,7 +3099,7 @@ >>>>>>> ????? } >>>>>>> ????? return; >>>>>>> ??? } >>>>>>> -? if (UseAddressNop && VM_Version::is_amd()) { >>>>>>> +? if (UseAddressNop && (VM_Version::is_amd() || VM_Version::is_hygon())) { >>>>>>> ????? // >>>>>>> ????? // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. >>>>>>> ????? //? 1: 0x90 >>>>>>> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>>>> b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>>>> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>>>> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>>>> @@ -340,6 +340,10 @@ >>>>>>> ????? return !is_amd_Barcelona(); >>>>>>> ??? } >>>>>>> >>>>>>> +? if (is_hygon()) { >>>>>>> +??? return true; >>>>>>> +? } >>>>>>> + >>>>>>> ??? return false; >>>>>>> ??} >>>>>>> >>>>>>> @@ -407,6 +411,10 @@ >>>>>>> ????? } >>>>>>> ????? return _family_id_intel[cpu_family_id]; >>>>>>> ??? } >>>>>>> +? if (is_hygon()) { >>>>>>> +????? return "Dhyana"; >>>>>>> +? } >>>>>>> + >>>>>>> ??? return "Unknown x86"; >>>>>>> ??} >>>>>>> >>>>>>> @@ -423,6 +431,9 @@ >>>>>>> ??? } else if (is_amd()) { >>>>>>> ????? cpu_type = "AMD"; >>>>>>> ????? x64 = cpu_is_em64t() ? " AMD64" : ""; >>>>>>> +? } else if (is_hygon()) { >>>>>>> +?????? cpu_type = "Hygon"; >>>>>>> +?????? x64 = cpu_is_em64t() ? " AMD64" : ""; >>>>>>> ??? } else { >>>>>>> ????? cpu_type = "Unknown x86"; >>>>>>> ????? x64 = cpu_is_em64t() ? " x86_64" : ""; >>>>>>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp b/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>>>> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>>>> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>>>> @@ -1165,7 +1165,7 @@ >>>>>>> ????? } >>>>>>> ??? } >>>>>>> >>>>>>> -? if( is_amd() ) { // AMD cpus specific settings >>>>>>> +? if( is_amd() || is_hygon() ) { // AMD cpus specific settings >>>>>>> ????? if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { >>>>>>> ??????? // Use it on new AMD cpus starting from Opteron. >>>>>>> ??????? UseAddressNop = true; >>>>>>> @@ -1239,8 +1239,8 @@ >>>>>>> ????? } >>>>>>> ??#endif // COMPILER2 >>>>>>> >>>>>>> -??? // Some defaults for AMD family 17h >>>>>>> -??? if ( cpu_family() == 0x17 ) { >>>>>>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>>>>>> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >>>>>>> ??????? // On family 17h processors use XMM and UnalignedLoadStores for Array Copy >>>>>>> ??????? if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >>>>>>> ????????? FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >>>>>>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp b/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>>>> --- a/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>>>> +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>>>> @@ -495,13 +495,13 @@ >>>>>>> ??????? result |= CPU_CX8; >>>>>>> ????? if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) >>>>>>> ??????? result |= CPU_CMOV; >>>>>>> -??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && >>>>>>> +??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() || is_hygon()) && >>>>>>> ????????? _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) >>>>>>> ??????? result |= CPU_FXSR; >>>>>>> ????? // HT flag is set for multi-core processors also. >>>>>>> ????? if (threads_per_core() > 1) >>>>>>> ??????? result |= CPU_HT; >>>>>>> -??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && >>>>>>> +??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() || is_hygon()) && >>>>>>> ????????? _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) >>>>>>> ??????? result |= CPU_MMX; >>>>>>> ????? if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) >>>>>>> @@ -576,8 +576,8 @@ >>>>>>> ????? if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>>>> ??????? result |= CPU_FMA; >>>>>>> >>>>>>> -??? // AMD features. >>>>>>> -??? if (is_amd()) { >>>>>>> +??? // AMD|Hygon features. >>>>>>> +??? if (is_amd() || is_hygon()) { >>>>>>> ??????? if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || >>>>>>> ??????????? (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) >>>>>>> ????????? result |= CPU_3DNOW_PREFETCH; >>>>>>> @@ -711,6 +711,7 @@ >>>>>>> ??? static int? cpu_family()??????? { return _cpu;} >>>>>>> ??? static bool is_P6()???????????? { return cpu_family() >= 6; } >>>>>>> ??? static bool is_amd()??????????? { assert_is_initialized(); return >>>>>>> _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' >>>>>>> +? static bool is_hygon()????????? { assert_is_initialized(); return >>>>>>> _cpuid_info.std_vendor_name_0 == 0x6F677948; } // 'ogyH' >>>>>>> ??? static bool is_intel()????????? { assert_is_initialized(); return >>>>>>> _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' >>>>>>> ??? static bool is_zx()???????????? { assert_is_initialized(); return >>>>>>> (_cpuid_info.std_vendor_name_0 == 0x746e6543) || (_cpuid_info.std_vendor_name_0 == >>>>>>> 0x68532020); } // 'tneC'||'hS? ' >>>>>>> ??? static bool is_atom_family()??? { return ((cpu_family() == 0x06) && >>>>>>> ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) || (extended_cpu_model() == >>>>>>> 0x4D))); } //Silvermont and Centerton >>>>>>> @@ -734,7 +735,7 @@ >>>>>>> ??????? if (!supports_topology || result == 0) { >>>>>>> ????????? result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); >>>>>>> ??????? } >>>>>>> -??? } else if (is_amd()) { >>>>>>> +??? } else if (is_amd() || is_hygon()) { >>>>>>> ??????? result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); >>>>>>> ????? } else if (is_zx()) { >>>>>>> ??????? bool supports_topology = supports_processor_topology(); >>>>>>> @@ -770,7 +771,7 @@ >>>>>>> ????? intx result = 0; >>>>>>> ????? if (is_intel()) { >>>>>>> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>>>>>> -??? } else if (is_amd()) { >>>>>>> +??? } else if (is_amd() || is_hygon()) { >>>>>>> ??????? result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; >>>>>>> ????? } else if (is_zx()) { >>>>>>> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>>>>>> @@ -857,7 +858,7 @@ >>>>>>> >>>>>>> ??? // AMD features >>>>>>> ??? static bool supports_3dnow_prefetch()??? { return (_features & CPU_3DNOW_PREFETCH) != 0; } >>>>>>> -? static bool supports_mmx_ext()? { return is_amd() && >>>>>>> _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >>>>>>> +? static bool supports_mmx_ext()? { return (is_amd()||is_hygon()) && >>>>>>> _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >>>>>>> ??? static bool supports_lzcnt()??? { return (_features & CPU_LZCNT) != 0; } >>>>>>> ??? static bool supports_sse4a()??? { return (_features & CPU_SSE4A) != 0; } >>>>>>> >>>>>>> @@ -870,7 +871,7 @@ >>>>>>> ??? } >>>>>>> ??? static bool supports_tscinv() { >>>>>>> ????? return supports_tscinv_bit() && >>>>>>> -?????????? ( (is_amd() && !is_amd_Barcelona()) || >>>>>>> +?????????? ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || >>>>>>> ?????????????? is_intel_tsc_synched_at_init() ); >>>>>>> ??? } >>>>>>> >>>>>>> @@ -896,7 +897,7 @@ >>>>>>> ????? // Core????? - 256 / prefetchnta >>>>>>> ????? // It will be used only when AllocatePrefetchStyle > 0 >>>>>>> >>>>>>> -??? if (is_amd()) { // AMD >>>>>>> +??? if (is_amd() || is_hygon()) { // AMD >>>>>>> ??????? if (supports_sse2()) { >>>>>>> ????????? return 256; // Opteron >>>>>>> ??????? } else { >>> >> From jamsheed.c.m at oracle.com Thu Apr 11 17:25:39 2019 From: jamsheed.c.m at oracle.com (Jamsheed) Date: Thu, 11 Apr 2019 22:55:39 +0530 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <95af6958-6512-d894-2076-74f1b68e3dbe@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <571f3d72-a22a-3b52-2942-6408072e353f@oracle.com> <144af13e-33e2-2089-f8d2-902e94485eb1@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> Message-ID: <5422bc1c-4640-b3c8-bf26-b91a6df34f1e@oracle.com> Hi Vladimir, the runtime calls uses indirect call, and it is not that straight forward to compare dst i guess. 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. all code whose behavior is unpredictable will be removed. like arm int/c1, non intrinsic c2 (And other platforms). Best regards, Jamsheed On 11/04/19 5:17 AM, Jamsheed wrote: > Hi Vladimir, > > On 10/04/19 10:03 PM, Vladimir Kozlov wrote: >> Okay, I see what you did. But it seems incomplete. You did not set >> continue_pc for some platforms. Why? > for some platform i don't have testing setup, others are not very much > used in servers(32 bit case). >> >> Also this will trigger the code if we hit segv for normal arraycopy. >> You may want to lookup caller frame to get address from call >> instruction and compare it with _unsafe_arraycopy: >> >> if (StubCodeDesc::desc_for(pc)) { >> ? frame fr = os::fetch_frame_from_context(uc); >> ? address ret_pc = fr.sender_pc(); >> ? CodeBlob* cb = CodeCache::find_blob_unsafe(ret_pc); >> ? CompiledMethod* nm = (cb != NULL) ? >> cb->as_compiled_method_or_null() : NULL; >> ? if (nm != NULL && NativeCall::is_call_before(ret_pc)) { >> ??? address dest = nativeCall_before(ret_pc)->destination(); >> ??? if (dest == StubRoutines::_unsafe_arraycopy) { >> >> But you need to verify if it works. > > this should work i guess. > > Best regards, > > Jamsheed > >> >> Thanks, >> Vladimir >> >> On 4/9/19 8:08 PM, Jamsheed wrote: >>> Hi Vladimir, >>> >>> Thank you for looking at this. >>> >>> On 10/04/19 4:01 AM, Vladimir Kozlov wrote: >>>> Hi Jamsheed, >>>> >>>> Instead of finding PC in stubs we should use something similar to >>>> GuardUnsafeAccess to set thread's doing_unsafe_access flag when we >>>> call copy stub for unsafe memory as you suggested first (in bug >>>> report). >>>> >>>> Interpreter set the flag for Unsafe.CopyMemory0() and >>>> Unsafe.copySwapMemory0(). C2 has intrinsic only for CopyMemory0(): >>>> >>>> http://hg.openjdk.java.net/jdk/jdk/file/6ad0281a654e/src/hotspot/share/opto/library_call.cpp#l4189 >>>> >>>> >>>> It only use unsafe_arraycopy stab: >>>> >>>> http://hg.openjdk.java.net/jdk/jdk/file/6ad0281a654e/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#l2434 >>>> >>>> >>>> Setting on it's entry and cleaning on exit >>>> Thread::_doing_unsafe_access field should be enough. Right? >>>> >>>> Or I am missing something? >>> >>> initially thought of implementing it that way[1], but as it is >>> having both store and volatile semantics went with this zero >>> overhead solution. >>> >>> also, that doesn't provide me? continuation pc, which is required >>> for fast exit for bulkaccess? or even for graceful exit in platform >>> like arm. >>> >>>> >>>> An other thing which bothering me is Harold's comment: >>>> >>>> "Unfortunately, "CompiledMethod* nm" gets set to NULL and so >>>> handle_unsafe_access() is not executed." >>>> >>>> Where/why nm is NULLed? >>> as we are in BufferBlob/RuntimeBlob(stub frame). >>>> >>>> Actually I think the whole code for "// BugId 4454115" is >>>> questionable since it replaces any crash (most likely not related >>>> to unsafe access) in compiled method which has at least one unsafe >>>> access with exception. May be we should use PcDesc to record unsafe >>>> instructions and compare with SEGV PC. But it is separate RFE. For >>>> this one we need to fix only Unsafe.CopyMemory0() C2 inrinsic. >>> >>> Right, Ok. >>> >>> Best regards, >>> >>> Jamsheed >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>> [1]http://cr.openjdk.java.net/~jcm/8191278/webrev.00/src/hotspot/share/opto/library_call.cpp.udiff.html >>> >>>> On 4/8/19 4:21 AM, Tobias Hartmann wrote: >>>>> Hi Jamsheed, >>>>> >>>>> On 05.04.19 15:11, Jamsheed wrote: >>>>>> On 04/04/19 7:23 PM, Andrew Haley wrote: >>>>>>>> this looks reasonable to me although the code is getting quite >>>>>>>> complicated to handle this edge case. >>>>>>> Yeah, it really is. Can't we just assume that *any* fault in >>>>>>> these stubs is >>>>>>> caused via Unsafe, and get rid of bool unsafe_copy_code_range? >>>>>> >>>>>> Thanks for the feedback Tobias, Andrew, removed >>>>>> unsafe_copy_code_range. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~jcm/8191278/webrev.04/ >>>>> >>>>> I think what Andrew meant is basically to go with webrev.01: >>>>> http://cr.openjdk.java.net/~jcm/8191278/webrev.01/ >>>>> >>>>> Right? >>>>> >>>>> Thanks, >>>>> Tobias >>>>> From vladimir.kozlov at oracle.com Thu Apr 11 18:50:58 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Apr 2019 11:50:58 -0700 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <5422bc1c-4640-b3c8-bf26-b91a6df34f1e@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <144af13e-33e2-2089-f8d2-902e94485eb1@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> Message-ID: 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. 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() I did not get why you providing next PC only for 64 bit VM. > > all code whose behavior is unpredictable will be removed. like arm int/c1, non intrinsic c2 (And > other platforms). Okay. 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 Thu Apr 11 23:29:19 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Apr 2019 09:29:19 +1000 Subject: [PATCH v3] JDK-8222090: Add Hygon Dhyana support In-Reply-To: <867b3678-0c03-c3a6-ff9c-a16f6566abfe@oracle.com> References: <8eb195a5-900d-6adb-3b10-fbef47c3dbff@oracle.com> <5edf2eea-93ee-aae5-fac5-db6d92cee9e2@oracle.com> <375b6491-3cd8-3756-ff49-3729214234ed@yeah.net> <1e349a3f-11c8-af6f-8b23-6056a81897ae@oracle.com> <867b3678-0c03-c3a6-ff9c-a16f6566abfe@oracle.com> Message-ID: <0fff8ac7-35ed-073b-eded-d4b3d01d14e6@oracle.com> Hi Vladimir, On 12/04/2019 2:04 am, Vladimir Kozlov wrote: > Hi David, > > Thank you for cleaning up code. Looks good except next small issues: > > You missed check in assembler_x86.cpp. Fixed: diff -r 4eefc9f3313c src/hotspot/cpu/x86/assembler_x86.cpp --- a/src/hotspot/cpu/x86/assembler_x86.cpp +++ b/src/hotspot/cpu/x86/assembler_x86.cpp @@ -3099,7 +3099,7 @@ } return; } - if (UseAddressNop && VM_Version::is_amd()) { + if (UseAddressNop && VM_Version::is_amd_family()) { > In vm_version_ext_x86.cpp indent is wrong in 2 cases: 4 spaces are used > instead of 2. Will fix before pushing and update webrev .v4 in place. Thanks, David > Thanks, > Vladimir > > On 4/10/19 10:26 PM, David Holmes wrote: >> Updated webrev: >> >> http://cr.openjdk.java.net/~dholmes/8222090/webrev.v4/ >> >> Seems comments below >> >> On 11/04/2019 12:58 pm, Jinke Fan wrote: >>> On 2019/4/11 10:48, Vladimir Kozlov wrote: >>>> On 4/10/19 6:14 PM, David Holmes wrote: >>>>> Hi Vladimir, >>>>> >>>>> Thanks for taking look at this. >>>>> >>>>> On 11/04/2019 2:41 am, Vladimir Kozlov wrote: >>>>>> Instead of repeated is_amd() || is_hygon() you can use >>>>>> is_amd_or_hygon() to be more clean. >>>>> >>>>> That doesn't really scale if we get more "cousins" joining the AMD >>>>> family. I prefer to see the explicit disjunction form. >>>> >>>> is_amd_family() ? If it was 2 or 3 cases I would agree with you. But >>>> you have 10 checks! >> >> I made this change. It is also "forced" me to fix up numerous coding >> style nits with missing and extra spaces in if-expressions. (Sorry) >> >>>> >>>>> >>>>>> Next check should be explicit for CPU: >>>>>> >>>>>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>>>>> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >>>>>> >>>>>> --- >>>>>> >>>>>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>>>>> +??? if ( (cpu_family() == 0x17) && is_amd() || (cpu_family() == >>>>>> 0x18) && is_hygon()) { >>>>> >>>>> I'm wondering if that should just be an assertion? I would not >>>>> expect it to be possible to have a family 0x17 that is not AMD and >>>>> likewise for family 0x18 and Hygon. But then I don't know how these >>>>> family ids get issued. ?? >>>> >>>> It is not clear what agreement AMD has with these companies. Any >>>> company (as AMD and Intel) may have own set of cpu_family ids and we >>>> can't assume that ids will not be reused. They have only 8 bits for ID. >>> Hygon has negotiated with AMD to make sure that only Hygon will >>> use family 18h, so try to minimize code modification and share most >>> codes with AMD under this consideration. >> >> I think in that case we do not need to also check for is_amd() and >> is_hygon() (noting that the code in question is already in a block >> guarded by is_amd_family()). >> >> Thanks, >> David >> ----- >>> >>> Best Regards? >>> Fanjinke >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 4/10/19 12:33 AM, David Holmes wrote: >>>>>>> Hi Fanjinke, >>>>>>> >>>>>>> This looks fine to me. I've updated the webrev at: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dholmes/8222090/webrev.v3/ >>>>>>> >>>>>>> We need a second reviewer before I push it. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 9/04/2019 5:22 pm, Jinke Fan wrote: >>>>>>>> diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp >>>>>>>> b/src/hotspot/cpu/x86/assembler_x86.cpp >>>>>>>> --- a/src/hotspot/cpu/x86/assembler_x86.cpp >>>>>>>> +++ b/src/hotspot/cpu/x86/assembler_x86.cpp >>>>>>>> @@ -3099,7 +3099,7 @@ >>>>>>>> ????? } >>>>>>>> ????? return; >>>>>>>> ??? } >>>>>>>> -? if (UseAddressNop && VM_Version::is_amd()) { >>>>>>>> +? if (UseAddressNop && (VM_Version::is_amd() || >>>>>>>> VM_Version::is_hygon())) { >>>>>>>> ????? // >>>>>>>> ????? // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. >>>>>>>> ????? //? 1: 0x90 >>>>>>>> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>>>>> b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>>>>> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>>>>> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>>>>> @@ -340,6 +340,10 @@ >>>>>>>> ????? return !is_amd_Barcelona(); >>>>>>>> ??? } >>>>>>>> >>>>>>>> +? if (is_hygon()) { >>>>>>>> +??? return true; >>>>>>>> +? } >>>>>>>> + >>>>>>>> ??? return false; >>>>>>>> ??} >>>>>>>> >>>>>>>> @@ -407,6 +411,10 @@ >>>>>>>> ????? } >>>>>>>> ????? return _family_id_intel[cpu_family_id]; >>>>>>>> ??? } >>>>>>>> +? if (is_hygon()) { >>>>>>>> +????? return "Dhyana"; >>>>>>>> +? } >>>>>>>> + >>>>>>>> ??? return "Unknown x86"; >>>>>>>> ??} >>>>>>>> >>>>>>>> @@ -423,6 +431,9 @@ >>>>>>>> ??? } else if (is_amd()) { >>>>>>>> ????? cpu_type = "AMD"; >>>>>>>> ????? x64 = cpu_is_em64t() ? " AMD64" : ""; >>>>>>>> +? } else if (is_hygon()) { >>>>>>>> +?????? cpu_type = "Hygon"; >>>>>>>> +?????? x64 = cpu_is_em64t() ? " AMD64" : ""; >>>>>>>> ??? } else { >>>>>>>> ????? cpu_type = "Unknown x86"; >>>>>>>> ????? x64 = cpu_is_em64t() ? " x86_64" : ""; >>>>>>>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>>>>> b/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>>>>> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>>>>> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>>>>> @@ -1165,7 +1165,7 @@ >>>>>>>> ????? } >>>>>>>> ??? } >>>>>>>> >>>>>>>> -? if( is_amd() ) { // AMD cpus specific settings >>>>>>>> +? if( is_amd() || is_hygon() ) { // AMD cpus specific settings >>>>>>>> ????? if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { >>>>>>>> ??????? // Use it on new AMD cpus starting from Opteron. >>>>>>>> ??????? UseAddressNop = true; >>>>>>>> @@ -1239,8 +1239,8 @@ >>>>>>>> ????? } >>>>>>>> ??#endif // COMPILER2 >>>>>>>> >>>>>>>> -??? // Some defaults for AMD family 17h >>>>>>>> -??? if ( cpu_family() == 0x17 ) { >>>>>>>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>>>>>>> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >>>>>>>> ??????? // On family 17h processors use XMM and >>>>>>>> UnalignedLoadStores for Array Copy >>>>>>>> ??????? if (supports_sse2() && >>>>>>>> FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >>>>>>>> ????????? FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >>>>>>>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>>>>> b/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>>>>> --- a/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>>>>> +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>>>>> @@ -495,13 +495,13 @@ >>>>>>>> ??????? result |= CPU_CX8; >>>>>>>> ????? if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) >>>>>>>> ??????? result |= CPU_CMOV; >>>>>>>> -??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && >>>>>>>> +??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() >>>>>>>> || is_hygon()) && >>>>>>>> ????????? _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) >>>>>>>> ??????? result |= CPU_FXSR; >>>>>>>> ????? // HT flag is set for multi-core processors also. >>>>>>>> ????? if (threads_per_core() > 1) >>>>>>>> ??????? result |= CPU_HT; >>>>>>>> -??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && >>>>>>>> +??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() >>>>>>>> || is_hygon()) && >>>>>>>> ????????? _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) >>>>>>>> ??????? result |= CPU_MMX; >>>>>>>> ????? if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) >>>>>>>> @@ -576,8 +576,8 @@ >>>>>>>> ????? if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>>>>> ??????? result |= CPU_FMA; >>>>>>>> >>>>>>>> -??? // AMD features. >>>>>>>> -??? if (is_amd()) { >>>>>>>> +??? // AMD|Hygon features. >>>>>>>> +??? if (is_amd() || is_hygon()) { >>>>>>>> ??????? if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || >>>>>>>> ??????????? (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) >>>>>>>> ????????? result |= CPU_3DNOW_PREFETCH; >>>>>>>> @@ -711,6 +711,7 @@ >>>>>>>> ??? static int? cpu_family()??????? { return _cpu;} >>>>>>>> ??? static bool is_P6()???????????? { return cpu_family() >= 6; } >>>>>>>> ??? static bool is_amd()??????????? { assert_is_initialized(); >>>>>>>> return _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' >>>>>>>> +? static bool is_hygon()????????? { assert_is_initialized(); >>>>>>>> return _cpuid_info.std_vendor_name_0 == 0x6F677948; } // 'ogyH' >>>>>>>> ??? static bool is_intel()????????? { assert_is_initialized(); >>>>>>>> return _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' >>>>>>>> ??? static bool is_zx()???????????? { assert_is_initialized(); >>>>>>>> return (_cpuid_info.std_vendor_name_0 == 0x746e6543) || >>>>>>>> (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS? ' >>>>>>>> ??? static bool is_atom_family()??? { return ((cpu_family() == >>>>>>>> 0x06) && ((extended_cpu_model() == 0x36) || >>>>>>>> (extended_cpu_model() == 0x37) || (extended_cpu_model() == >>>>>>>> 0x4D))); } //Silvermont and Centerton >>>>>>>> @@ -734,7 +735,7 @@ >>>>>>>> ??????? if (!supports_topology || result == 0) { >>>>>>>> ????????? result = >>>>>>>> (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); >>>>>>>> ??????? } >>>>>>>> -??? } else if (is_amd()) { >>>>>>>> +??? } else if (is_amd() || is_hygon()) { >>>>>>>> ??????? result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu >>>>>>>> + 1); >>>>>>>> ????? } else if (is_zx()) { >>>>>>>> ??????? bool supports_topology = supports_processor_topology(); >>>>>>>> @@ -770,7 +771,7 @@ >>>>>>>> ????? intx result = 0; >>>>>>>> ????? if (is_intel()) { >>>>>>>> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + >>>>>>>> 1); >>>>>>>> -??? } else if (is_amd()) { >>>>>>>> +??? } else if (is_amd() || is_hygon()) { >>>>>>>> ??????? result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; >>>>>>>> ????? } else if (is_zx()) { >>>>>>>> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + >>>>>>>> 1); >>>>>>>> @@ -857,7 +858,7 @@ >>>>>>>> >>>>>>>> ??? // AMD features >>>>>>>> ??? static bool supports_3dnow_prefetch()??? { return (_features >>>>>>>> & CPU_3DNOW_PREFETCH) != 0; } >>>>>>>> -? static bool supports_mmx_ext()? { return is_amd() && >>>>>>>> _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >>>>>>>> +? static bool supports_mmx_ext()? { return >>>>>>>> (is_amd()||is_hygon()) && >>>>>>>> _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >>>>>>>> ??? static bool supports_lzcnt()??? { return (_features & >>>>>>>> CPU_LZCNT) != 0; } >>>>>>>> ??? static bool supports_sse4a()??? { return (_features & >>>>>>>> CPU_SSE4A) != 0; } >>>>>>>> >>>>>>>> @@ -870,7 +871,7 @@ >>>>>>>> ??? } >>>>>>>> ??? static bool supports_tscinv() { >>>>>>>> ????? return supports_tscinv_bit() && >>>>>>>> -?????????? ( (is_amd() && !is_amd_Barcelona()) || >>>>>>>> +?????????? ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || >>>>>>>> ?????????????? is_intel_tsc_synched_at_init() ); >>>>>>>> ??? } >>>>>>>> >>>>>>>> @@ -896,7 +897,7 @@ >>>>>>>> ????? // Core????? - 256 / prefetchnta >>>>>>>> ????? // It will be used only when AllocatePrefetchStyle > 0 >>>>>>>> >>>>>>>> -??? if (is_amd()) { // AMD >>>>>>>> +??? if (is_amd() || is_hygon()) { // AMD >>>>>>>> ??????? if (supports_sse2()) { >>>>>>>> ????????? return 256; // Opteron >>>>>>>> ??????? } else { >>>> >>> From vladimir.kozlov at oracle.com Fri Apr 12 00:11:18 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Apr 2019 17:11:18 -0700 Subject: [PATCH v3] JDK-8222090: Add Hygon Dhyana support In-Reply-To: <0fff8ac7-35ed-073b-eded-d4b3d01d14e6@oracle.com> References: <8eb195a5-900d-6adb-3b10-fbef47c3dbff@oracle.com> <5edf2eea-93ee-aae5-fac5-db6d92cee9e2@oracle.com> <375b6491-3cd8-3756-ff49-3729214234ed@yeah.net> <1e349a3f-11c8-af6f-8b23-6056a81897ae@oracle.com> <867b3678-0c03-c3a6-ff9c-a16f6566abfe@oracle.com> <0fff8ac7-35ed-073b-eded-d4b3d01d14e6@oracle.com> Message-ID: Good. Thanks, Vladimir On 4/11/19 4:29 PM, David Holmes wrote: > Hi Vladimir, > > On 12/04/2019 2:04 am, Vladimir Kozlov wrote: >> Hi David, >> >> Thank you for cleaning up code. Looks good except next small issues: >> >> You missed check in assembler_x86.cpp. > > Fixed: > > diff -r 4eefc9f3313c src/hotspot/cpu/x86/assembler_x86.cpp > --- a/src/hotspot/cpu/x86/assembler_x86.cpp > +++ b/src/hotspot/cpu/x86/assembler_x86.cpp > @@ -3099,7 +3099,7 @@ > ???? } > ???? return; > ?? } > -? if (UseAddressNop && VM_Version::is_amd()) { > +? if (UseAddressNop && VM_Version::is_amd_family()) { > > >> In vm_version_ext_x86.cpp indent is wrong in 2 cases: 4 spaces are used instead of 2. > > Will fix before pushing and update webrev .v4 in place. > > Thanks, > David > >> Thanks, >> Vladimir >> >> On 4/10/19 10:26 PM, David Holmes wrote: >>> Updated webrev: >>> >>> http://cr.openjdk.java.net/~dholmes/8222090/webrev.v4/ >>> >>> Seems comments below >>> >>> On 11/04/2019 12:58 pm, Jinke Fan wrote: >>>> On 2019/4/11 10:48, Vladimir Kozlov wrote: >>>>> On 4/10/19 6:14 PM, David Holmes wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> Thanks for taking look at this. >>>>>> >>>>>> On 11/04/2019 2:41 am, Vladimir Kozlov wrote: >>>>>>> Instead of repeated is_amd() || is_hygon() you can use is_amd_or_hygon() to be more clean. >>>>>> >>>>>> That doesn't really scale if we get more "cousins" joining the AMD family. I prefer to see the explicit >>>>>> disjunction form. >>>>> >>>>> is_amd_family() ? If it was 2 or 3 cases I would agree with you. But you have 10 checks! >>> >>> I made this change. It is also "forced" me to fix up numerous coding style nits with missing and extra spaces in >>> if-expressions. (Sorry) >>> >>>>> >>>>>> >>>>>>> Next check should be explicit for CPU: >>>>>>> >>>>>>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>>>>>> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>>>>>> +??? if ( (cpu_family() == 0x17) && is_amd() || (cpu_family() == 0x18) && is_hygon()) { >>>>>> >>>>>> I'm wondering if that should just be an assertion? I would not expect it to be possible to have a family 0x17 that >>>>>> is not AMD and likewise for family 0x18 and Hygon. But then I don't know how these family ids get issued. ?? >>>>> >>>>> It is not clear what agreement AMD has with these companies. Any company (as AMD and Intel) may have own set of >>>>> cpu_family ids and we can't assume that ids will not be reused. They have only 8 bits for ID. >>>> Hygon has negotiated with AMD to make sure that only Hygon will >>>> use family 18h, so try to minimize code modification and share most >>>> codes with AMD under this consideration. >>> >>> I think in that case we do not need to also check for is_amd() and is_hygon() (noting that the code in question is >>> already in a block guarded by is_amd_family()). >>> >>> Thanks, >>> David >>> ----- >>>> >>>> Best Regards? >>>> Fanjinke >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 4/10/19 12:33 AM, David Holmes wrote: >>>>>>>> Hi Fanjinke, >>>>>>>> >>>>>>>> This looks fine to me. I've updated the webrev at: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dholmes/8222090/webrev.v3/ >>>>>>>> >>>>>>>> We need a second reviewer before I push it. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 9/04/2019 5:22 pm, Jinke Fan wrote: >>>>>>>>> diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp b/src/hotspot/cpu/x86/assembler_x86.cpp >>>>>>>>> --- a/src/hotspot/cpu/x86/assembler_x86.cpp >>>>>>>>> +++ b/src/hotspot/cpu/x86/assembler_x86.cpp >>>>>>>>> @@ -3099,7 +3099,7 @@ >>>>>>>>> ????? } >>>>>>>>> ????? return; >>>>>>>>> ??? } >>>>>>>>> -? if (UseAddressNop && VM_Version::is_amd()) { >>>>>>>>> +? if (UseAddressNop && (VM_Version::is_amd() || VM_Version::is_hygon())) { >>>>>>>>> ????? // >>>>>>>>> ????? // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. >>>>>>>>> ????? //? 1: 0x90 >>>>>>>>> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>>>>>> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>>>>>> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>>>>>> @@ -340,6 +340,10 @@ >>>>>>>>> ????? return !is_amd_Barcelona(); >>>>>>>>> ??? } >>>>>>>>> >>>>>>>>> +? if (is_hygon()) { >>>>>>>>> +??? return true; >>>>>>>>> +? } >>>>>>>>> + >>>>>>>>> ??? return false; >>>>>>>>> ??} >>>>>>>>> >>>>>>>>> @@ -407,6 +411,10 @@ >>>>>>>>> ????? } >>>>>>>>> ????? return _family_id_intel[cpu_family_id]; >>>>>>>>> ??? } >>>>>>>>> +? if (is_hygon()) { >>>>>>>>> +????? return "Dhyana"; >>>>>>>>> +? } >>>>>>>>> + >>>>>>>>> ??? return "Unknown x86"; >>>>>>>>> ??} >>>>>>>>> >>>>>>>>> @@ -423,6 +431,9 @@ >>>>>>>>> ??? } else if (is_amd()) { >>>>>>>>> ????? cpu_type = "AMD"; >>>>>>>>> ????? x64 = cpu_is_em64t() ? " AMD64" : ""; >>>>>>>>> +? } else if (is_hygon()) { >>>>>>>>> +?????? cpu_type = "Hygon"; >>>>>>>>> +?????? x64 = cpu_is_em64t() ? " AMD64" : ""; >>>>>>>>> ??? } else { >>>>>>>>> ????? cpu_type = "Unknown x86"; >>>>>>>>> ????? x64 = cpu_is_em64t() ? " x86_64" : ""; >>>>>>>>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp b/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>>>>>> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>>>>>> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>>>>>> @@ -1165,7 +1165,7 @@ >>>>>>>>> ????? } >>>>>>>>> ??? } >>>>>>>>> >>>>>>>>> -? if( is_amd() ) { // AMD cpus specific settings >>>>>>>>> +? if( is_amd() || is_hygon() ) { // AMD cpus specific settings >>>>>>>>> ????? if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { >>>>>>>>> ??????? // Use it on new AMD cpus starting from Opteron. >>>>>>>>> ??????? UseAddressNop = true; >>>>>>>>> @@ -1239,8 +1239,8 @@ >>>>>>>>> ????? } >>>>>>>>> ??#endif // COMPILER2 >>>>>>>>> >>>>>>>>> -??? // Some defaults for AMD family 17h >>>>>>>>> -??? if ( cpu_family() == 0x17 ) { >>>>>>>>> +??? // Some defaults for AMD family 17h || Hygon family 18h >>>>>>>>> +??? if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { >>>>>>>>> ??????? // On family 17h processors use XMM and UnalignedLoadStores for Array Copy >>>>>>>>> ??????? if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >>>>>>>>> ????????? FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >>>>>>>>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp b/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>>>>>> --- a/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>>>>>> +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp >>>>>>>>> @@ -495,13 +495,13 @@ >>>>>>>>> ??????? result |= CPU_CX8; >>>>>>>>> ????? if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) >>>>>>>>> ??????? result |= CPU_CMOV; >>>>>>>>> -??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && >>>>>>>>> +??? if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() || is_hygon()) && >>>>>>>>> ????????? _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) >>>>>>>>> ??????? result |= CPU_FXSR; >>>>>>>>> ????? // HT flag is set for multi-core processors also. >>>>>>>>> ????? if (threads_per_core() > 1) >>>>>>>>> ??????? result |= CPU_HT; >>>>>>>>> -??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && >>>>>>>>> +??? if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() || is_hygon()) && >>>>>>>>> ????????? _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) >>>>>>>>> ??????? result |= CPU_MMX; >>>>>>>>> ????? if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) >>>>>>>>> @@ -576,8 +576,8 @@ >>>>>>>>> ????? if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>>>>>> ??????? result |= CPU_FMA; >>>>>>>>> >>>>>>>>> -??? // AMD features. >>>>>>>>> -??? if (is_amd()) { >>>>>>>>> +??? // AMD|Hygon features. >>>>>>>>> +??? if (is_amd() || is_hygon()) { >>>>>>>>> ??????? if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || >>>>>>>>> ??????????? (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) >>>>>>>>> ????????? result |= CPU_3DNOW_PREFETCH; >>>>>>>>> @@ -711,6 +711,7 @@ >>>>>>>>> ??? static int? cpu_family()??????? { return _cpu;} >>>>>>>>> ??? static bool is_P6()???????????? { return cpu_family() >= 6; } >>>>>>>>> ??? static bool is_amd()??????????? { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == >>>>>>>>> 0x68747541; } // 'htuA' >>>>>>>>> +? static bool is_hygon()????????? { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == >>>>>>>>> 0x6F677948; } // 'ogyH' >>>>>>>>> ??? static bool is_intel()????????? { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == >>>>>>>>> 0x756e6547; } // 'uneG' >>>>>>>>> ??? static bool is_zx()???????????? { assert_is_initialized(); return (_cpuid_info.std_vendor_name_0 == >>>>>>>>> 0x746e6543) || (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS? ' >>>>>>>>> ??? static bool is_atom_family()??? { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x36) || >>>>>>>>> (extended_cpu_model() == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton >>>>>>>>> @@ -734,7 +735,7 @@ >>>>>>>>> ??????? if (!supports_topology || result == 0) { >>>>>>>>> ????????? result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); >>>>>>>>> ??????? } >>>>>>>>> -??? } else if (is_amd()) { >>>>>>>>> +??? } else if (is_amd() || is_hygon()) { >>>>>>>>> ??????? result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); >>>>>>>>> ????? } else if (is_zx()) { >>>>>>>>> ??????? bool supports_topology = supports_processor_topology(); >>>>>>>>> @@ -770,7 +771,7 @@ >>>>>>>>> ????? intx result = 0; >>>>>>>>> ????? if (is_intel()) { >>>>>>>>> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>>>>>>>> -??? } else if (is_amd()) { >>>>>>>>> +??? } else if (is_amd() || is_hygon()) { >>>>>>>>> ??????? result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; >>>>>>>>> ????? } else if (is_zx()) { >>>>>>>>> ??????? result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); >>>>>>>>> @@ -857,7 +858,7 @@ >>>>>>>>> >>>>>>>>> ??? // AMD features >>>>>>>>> ??? static bool supports_3dnow_prefetch()??? { return (_features & CPU_3DNOW_PREFETCH) != 0; } >>>>>>>>> -? static bool supports_mmx_ext()? { return is_amd() && _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } >>>>>>>>> +? static bool supports_mmx_ext()? { return (is_amd()||is_hygon()) && _cpuid_info.ext_cpuid1_edx.bits.mmx_amd >>>>>>>>> != 0; } >>>>>>>>> ??? static bool supports_lzcnt()??? { return (_features & CPU_LZCNT) != 0; } >>>>>>>>> ??? static bool supports_sse4a()??? { return (_features & CPU_SSE4A) != 0; } >>>>>>>>> >>>>>>>>> @@ -870,7 +871,7 @@ >>>>>>>>> ??? } >>>>>>>>> ??? static bool supports_tscinv() { >>>>>>>>> ????? return supports_tscinv_bit() && >>>>>>>>> -?????????? ( (is_amd() && !is_amd_Barcelona()) || >>>>>>>>> +?????????? ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || >>>>>>>>> ?????????????? is_intel_tsc_synched_at_init() ); >>>>>>>>> ??? } >>>>>>>>> >>>>>>>>> @@ -896,7 +897,7 @@ >>>>>>>>> ????? // Core????? - 256 / prefetchnta >>>>>>>>> ????? // It will be used only when AllocatePrefetchStyle > 0 >>>>>>>>> >>>>>>>>> -??? if (is_amd()) { // AMD >>>>>>>>> +??? if (is_amd() || is_hygon()) { // AMD >>>>>>>>> ??????? if (supports_sse2()) { >>>>>>>>> ????????? return 256; // Opteron >>>>>>>>> ??????? } else { >>>>> >>>> From fanjinke51 at yeah.net Fri Apr 12 05:47:46 2019 From: fanjinke51 at yeah.net (Jinke Fan) Date: Fri, 12 Apr 2019 13:47:46 +0800 Subject: RFR: Out-of-bounds access in cpu_family_description() Message-ID: Hi David, In VM_Version_Ext::cpu_family_description has out-of-bounds access on AMD 17h (EPYC) processor. const char* VM_Version_Ext::cpu_family_description(void) { On AMD 17h (EPYC) processor extended_cpu_family() will return 23, but array _family_id_amd only has 17 members. int cpu_family_id = extended_cpu_family(); if (is_amd()) { return _family_id_amd[cpu_family_id]; } ... } Result of testcase TestCPUInformation.java on AMD Zen: ----------System.out:(15/1615)---------- ... Family: 386 (0x17), Model: (0x1), Stepping: 0x1 Ext. family: 0x8, Ext. model: 0x0, Type: 0x0, Signature: 0x00800f11 ... } The ?386? string is incorrectly and comes from Illegal access. The patch is based on the original repository: hg.openjdk.java.net/jdk/jdk changeset: 54520:f48312257bc6 tag: tip user: vromero date: Thu Apr 11 22:56:11 2019 -0400 summary: 8222151: refactoring: enhancements to java.lang.Class::methodToString and java.lang.Class::getTypeName *Patch The out of hg diff -g: diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp @@ -262,6 +262,52 @@ int VM_Version_Ext::_no_of_cores = 0; int VM_Version_Ext::_no_of_packages = 0; +const char* const VM_Version_Ext::_family_id_intel[] = { + "8086/8088", + "", + "286", + "386", + "486", + "Pentium", + "Pentium Pro", //or Pentium-M/Woodcrest depeding on model + "", + "", + "", + "", + "", + "", + "", + "", + "Pentium 4" +}; + +const char* const VM_Version_Ext::_family_id_amd[] = { + "", + "", + "", + "", + "5x86", + "K5/K6", + "Athlon/AthlonXP", + "", + "", + "", + "", + "", + "", + "", + "", + "Opteron/Athlon64", + "Opteron QC/Phenom", // Barcelona et.al. + "", + "", + "", + "", + "", + "", + "Zen" +}; + void VM_Version_Ext::initialize(void) { ResourceMark rm; @@ -401,15 +447,19 @@ } const char* VM_Version_Ext::cpu_family_description(void) { - int cpu_family_id = extended_cpu_family(); + uint32_t cpu_family_id = extended_cpu_family(); if (is_amd()) { - return _family_id_amd[cpu_family_id]; + if (cpu_family_id < sizeof(_family_id_amd)/sizeof(_family_id_amd[0])) { + return _family_id_amd[cpu_family_id]; + } } if (is_intel()) { if (cpu_family_id == CPU_FAMILY_PENTIUMPRO) { return cpu_model_description(); } - return _family_id_intel[cpu_family_id]; + if (cpu_family_id < sizeof(_family_id_intel)/sizeof(_family_id_intel[0])) { + return _family_id_intel[cpu_family_id]; + } } if (is_hygon()) { return "Dhyana"; @@ -705,44 +755,6 @@ return _max_qualified_cpu_frequency; } -const char* const VM_Version_Ext::_family_id_intel[] = { - "8086/8088", - "", - "286", - "386", - "486", - "Pentium", - "Pentium Pro", //or Pentium-M/Woodcrest depeding on model - "", - "", - "", - "", - "", - "", - "", - "", - "Pentium 4" -}; - -const char* const VM_Version_Ext::_family_id_amd[] = { - "", - "", - "", - "", - "5x86", - "K5/K6", - "Athlon/AthlonXP", - "", - "", - "", - "", - "", - "", - "", - "", - "Opteron/Athlon64", - "Opteron QC/Phenom" // Barcelona et.al. -}; // Partially from Intel 64 and IA-32 Architecture Software Developer's Manual, // September 2013, Vol 3C Table 35-1 const char* const VM_Version_Ext::_model_id_pentium_pro[] = { *Test: After patched,result of testcase TestCPUInformation.java on AMD Zen: ----------System.out:(15/1615)---------- Event: jdk.CPUInformation { ... Family: Zen (0x17), Model: (0x1), Stepping: 0x1 Ext. family: 0x8, Ext. model: 0x0, Type: 0x0, Signature: 0x00800f11 Features: ebx: 0x4f400800, ecx: 0x7ed8320b, edx: 0x178bfbff ... } Is there anything incorrectly? Please let me know your comments. Best Regards? Fanjinke From jamsheed.c.m at oracle.com Fri Apr 12 06:00:48 2019 From: jamsheed.c.m at oracle.com (Jamsheed) Date: Fri, 12 Apr 2019 11:30:48 +0530 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <144af13e-33e2-2089-f8d2-902e94485eb1@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> Message-ID: <2848933c-e6bc-be44-7970-436ac00f0479@oracle.com> 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 Fri Apr 12 06:20:29 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Apr 2019 16:20:29 +1000 Subject: RFR: Out-of-bounds access in cpu_family_description() In-Reply-To: References: Message-ID: <7e501bc0-c417-f05e-5ef1-21c08536b9b9@oracle.com> Hi, Was there a reason you had to move the existing arrays before extending the amd one with the missing values? Thanks, David On 12/04/2019 3:47 pm, Jinke Fan wrote: > Hi David, > ????In VM_Version_Ext::cpu_family_description has out-of-bounds > access on AMD 17h (EPYC) processor. > > const char* VM_Version_Ext::cpu_family_description(void) { > > On AMD 17h (EPYC) processor extended_cpu_family() will return 23, > but array _family_id_amd only has 17 members. > > ? int cpu_family_id = extended_cpu_family(); > ? if (is_amd()) { > ??? return _family_id_amd[cpu_family_id]; > ? } > ... > } > > Result of testcase TestCPUInformation.java on AMD Zen: > ----------System.out:(15/1615)---------- > ... > Family: 386 (0x17), Model: (0x1), Stepping: 0x1 > Ext. family: 0x8, Ext. model: 0x0, Type: 0x0, Signature: 0x00800f11 > ... > } > > The ?386? string is incorrectly and comes from Illegal access. > > The patch is based on the original repository: > hg.openjdk.java.net/jdk/jdk > > changeset:?? 54520:f48312257bc6 > tag:???????? tip > user:??????? vromero > date:??????? Thu Apr 11 22:56:11 2019 -0400 > summary:???? 8222151: refactoring: enhancements to > java.lang.Class::methodToString and java.lang.Class::getTypeName > > *Patch > The out of hg diff -g: > diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp > b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp > --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp > +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp > @@ -262,6 +262,52 @@ > ?int VM_Version_Ext::_no_of_cores = 0; > ?int VM_Version_Ext::_no_of_packages = 0; > > +const char* const VM_Version_Ext::_family_id_intel[] = { > +? "8086/8088", > +? "", > +? "286", > +? "386", > +? "486", > +? "Pentium", > +? "Pentium Pro",?? //or Pentium-M/Woodcrest depeding on model > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "Pentium 4" > +}; > + > +const char* const VM_Version_Ext::_family_id_amd[] = { > +? "", > +? "", > +? "", > +? "", > +? "5x86", > +? "K5/K6", > +? "Athlon/AthlonXP", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "Opteron/Athlon64", > +? "Opteron QC/Phenom",? // Barcelona et.al. > +? "", > +? "", > +? "", > +? "", > +? "", > +? "", > +? "Zen" > +}; > + > ?void VM_Version_Ext::initialize(void) { > ?? ResourceMark rm; > > @@ -401,15 +447,19 @@ > ?} > > ?const char* VM_Version_Ext::cpu_family_description(void) { > -? int cpu_family_id = extended_cpu_family(); > +? uint32_t cpu_family_id = extended_cpu_family(); > ?? if (is_amd()) { > -??? return _family_id_amd[cpu_family_id]; > +??? if (cpu_family_id < > sizeof(_family_id_amd)/sizeof(_family_id_amd[0])) { > +????? return _family_id_amd[cpu_family_id]; > +??? } > ?? } > ?? if (is_intel()) { > ???? if (cpu_family_id == CPU_FAMILY_PENTIUMPRO) { > ?????? return cpu_model_description(); > ???? } > -??? return _family_id_intel[cpu_family_id]; > +??? if (cpu_family_id < > sizeof(_family_id_intel)/sizeof(_family_id_intel[0])) { > +????? return _family_id_intel[cpu_family_id]; > +??? } > ?? } > ?? if (is_hygon()) { > ???? return "Dhyana"; > @@ -705,44 +755,6 @@ > ?? return _max_qualified_cpu_frequency; > ?} > > -const char* const VM_Version_Ext::_family_id_intel[] = { > -? "8086/8088", > -? "", > -? "286", > -? "386", > -? "486", > -? "Pentium", > -? "Pentium Pro",?? //or Pentium-M/Woodcrest depeding on model > -? "", > -? "", > -? "", > -? "", > -? "", > -? "", > -? "", > -? "", > -? "Pentium 4" > -}; > - > -const char* const VM_Version_Ext::_family_id_amd[] = { > -? "", > -? "", > -? "", > -? "", > -? "5x86", > -? "K5/K6", > -? "Athlon/AthlonXP", > -? "", > -? "", > -? "", > -? "", > -? "", > -? "", > -? "", > -? "", > -? "Opteron/Athlon64", > -? "Opteron QC/Phenom"? // Barcelona et.al. > -}; > ?// Partially from Intel 64 and IA-32 Architecture Software Developer's > Manual, > ?// September 2013, Vol 3C Table 35-1 > ?const char* const VM_Version_Ext::_model_id_pentium_pro[] = { > > *Test: > After patched,result of testcase TestCPUInformation.java on AMD Zen: > ----------System.out:(15/1615)---------- > Event: jdk.CPUInformation { > ? ... > Family: Zen (0x17), Model: (0x1), Stepping: 0x1 > Ext. family: 0x8, Ext. model: 0x0, Type: 0x0, Signature: 0x00800f11 > Features: ebx: 0x4f400800, ecx: 0x7ed8320b, edx: 0x178bfbff > ? ... > } > > Is there anything incorrectly? > Please let me know your comments. > > Best Regards? > Fanjinke > From fanjinke51 at yeah.net Fri Apr 12 06:51:56 2019 From: fanjinke51 at yeah.net (Jinke Fan) Date: Fri, 12 Apr 2019 14:51:56 +0800 Subject: RFR: Out-of-bounds access in cpu_family_description() In-Reply-To: <7e501bc0-c417-f05e-5ef1-21c08536b9b9@oracle.com> References: <7e501bc0-c417-f05e-5ef1-21c08536b9b9@oracle.com> Message-ID: <1993c58b-c8b5-5431-e40d-67d79c93cbc5@yeah.net> On 2019/4/12 14:20, David Holmes wrote: > Hi, > > Was there a reason you had to move the existing arrays before extending > the amd one with the missing values? Yes, because the addition uses sizeof to control the boundary access. If the arrays's defined were behind the sizeof,it causes a compilation error: "error: invalid application of 'sizeof? to incomplete type" Best Regards! Fanjinke > > Thanks, > David > > On 12/04/2019 3:47 pm, Jinke Fan wrote: >> Hi David, >> ?????In VM_Version_Ext::cpu_family_description has out-of-bounds >> access on AMD 17h (EPYC) processor. >> >> const char* VM_Version_Ext::cpu_family_description(void) { >> >> On AMD 17h (EPYC) processor extended_cpu_family() will return 23, >> but array _family_id_amd only has 17 members. >> >> ?? int cpu_family_id = extended_cpu_family(); >> ?? if (is_amd()) { >> ???? return _family_id_amd[cpu_family_id]; >> ?? } >> ... >> } >> >> Result of testcase TestCPUInformation.java on AMD Zen: >> ----------System.out:(15/1615)---------- >> ... >> Family: 386 (0x17), Model: (0x1), Stepping: 0x1 >> Ext. family: 0x8, Ext. model: 0x0, Type: 0x0, Signature: 0x00800f11 >> ... >> } >> >> The ?386? string is incorrectly and comes from Illegal access. >> >> The patch is based on the original repository: >> hg.openjdk.java.net/jdk/jdk >> >> changeset:?? 54520:f48312257bc6 >> tag:???????? tip >> user:??????? vromero >> date:??????? Thu Apr 11 22:56:11 2019 -0400 >> summary:???? 8222151: refactoring: enhancements to >> java.lang.Class::methodToString and java.lang.Class::getTypeName >> >> *Patch >> The out of hg diff -g: >> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >> @@ -262,6 +262,52 @@ >> ??int VM_Version_Ext::_no_of_cores = 0; >> ??int VM_Version_Ext::_no_of_packages = 0; >> >> +const char* const VM_Version_Ext::_family_id_intel[] = { >> +? "8086/8088", >> +? "", >> +? "286", >> +? "386", >> +? "486", >> +? "Pentium", >> +? "Pentium Pro",?? //or Pentium-M/Woodcrest depeding on model >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "Pentium 4" >> +}; >> + >> +const char* const VM_Version_Ext::_family_id_amd[] = { >> +? "", >> +? "", >> +? "", >> +? "", >> +? "5x86", >> +? "K5/K6", >> +? "Athlon/AthlonXP", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "Opteron/Athlon64", >> +? "Opteron QC/Phenom",? // Barcelona et.al. >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "", >> +? "Zen" >> +}; >> + >> ??void VM_Version_Ext::initialize(void) { >> ??? ResourceMark rm; >> >> @@ -401,15 +447,19 @@ >> ??} >> >> ??const char* VM_Version_Ext::cpu_family_description(void) { >> -? int cpu_family_id = extended_cpu_family(); >> +? uint32_t cpu_family_id = extended_cpu_family(); >> ??? if (is_amd()) { >> -??? return _family_id_amd[cpu_family_id]; >> +??? if (cpu_family_id < >> sizeof(_family_id_amd)/sizeof(_family_id_amd[0])) { >> +????? return _family_id_amd[cpu_family_id]; >> +??? } >> ??? } >> ??? if (is_intel()) { >> ????? if (cpu_family_id == CPU_FAMILY_PENTIUMPRO) { >> ??????? return cpu_model_description(); >> ????? } >> -??? return _family_id_intel[cpu_family_id]; >> +??? if (cpu_family_id < >> sizeof(_family_id_intel)/sizeof(_family_id_intel[0])) { >> +????? return _family_id_intel[cpu_family_id]; >> +??? } >> ??? } >> ??? if (is_hygon()) { >> ????? return "Dhyana"; >> @@ -705,44 +755,6 @@ >> ??? return _max_qualified_cpu_frequency; >> ??} >> >> -const char* const VM_Version_Ext::_family_id_intel[] = { >> -? "8086/8088", >> -? "", >> -? "286", >> -? "386", >> -? "486", >> -? "Pentium", >> -? "Pentium Pro",?? //or Pentium-M/Woodcrest depeding on model >> -? "", >> -? "", >> -? "", >> -? "", >> -? "", >> -? "", >> -? "", >> -? "", >> -? "Pentium 4" >> -}; >> - >> -const char* const VM_Version_Ext::_family_id_amd[] = { >> -? "", >> -? "", >> -? "", >> -? "", >> -? "5x86", >> -? "K5/K6", >> -? "Athlon/AthlonXP", >> -? "", >> -? "", >> -? "", >> -? "", >> -? "", >> -? "", >> -? "", >> -? "", >> -? "Opteron/Athlon64", >> -? "Opteron QC/Phenom"? // Barcelona et.al. >> -}; >> ??// Partially from Intel 64 and IA-32 Architecture Software >> Developer's Manual, >> ??// September 2013, Vol 3C Table 35-1 >> ??const char* const VM_Version_Ext::_model_id_pentium_pro[] = { >> >> *Test: >> After patched,result of testcase TestCPUInformation.java on AMD Zen: >> ----------System.out:(15/1615)---------- >> Event: jdk.CPUInformation { >> ?? ... >> Family: Zen (0x17), Model: (0x1), Stepping: 0x1 >> Ext. family: 0x8, Ext. model: 0x0, Type: 0x0, Signature: 0x00800f11 >> Features: ebx: 0x4f400800, ecx: 0x7ed8320b, edx: 0x178bfbff >> ?? ... >> } >> >> Is there anything incorrectly? >> Please let me know your comments. >> >> Best Regards? >> Fanjinke >> > From david.holmes at oracle.com Fri Apr 12 07:50:01 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Apr 2019 17:50:01 +1000 Subject: RFR: Out-of-bounds access in cpu_family_description() In-Reply-To: <1993c58b-c8b5-5431-e40d-67d79c93cbc5@yeah.net> References: <7e501bc0-c417-f05e-5ef1-21c08536b9b9@oracle.com> <1993c58b-c8b5-5431-e40d-67d79c93cbc5@yeah.net> Message-ID: <86575a27-934b-ef38-6ade-e287d158b539@oracle.com> Hi Fanjinke, I have filed: https://bugs.openjdk.java.net/browse/JDK-8222387 On 12/04/2019 4:51 pm, Jinke Fan wrote: > On 2019/4/12 14:20, David Holmes wrote: >> Hi, >> >> Was there a reason you had to move the existing arrays before >> extending the amd one with the missing values? > Yes, because the addition uses sizeof to control the boundary access. > If the arrays's defined were behind the sizeof,it causes a compilation > error: "error: invalid application of 'sizeof? to incomplete type" Okay I found that a little crude so I went for a slightly nicer approach: http://cr.openjdk.java.net/~dholmes/8222387/webrev/ Hope you don't mind. Thanks, David > Best Regards! > Fanjinke >> >> Thanks, >> David >> >> On 12/04/2019 3:47 pm, Jinke Fan wrote: >>> Hi David, >>> ?????In VM_Version_Ext::cpu_family_description has out-of-bounds >>> access on AMD 17h (EPYC) processor. >>> >>> const char* VM_Version_Ext::cpu_family_description(void) { >>> >>> On AMD 17h (EPYC) processor extended_cpu_family() will return 23, >>> but array _family_id_amd only has 17 members. >>> >>> ?? int cpu_family_id = extended_cpu_family(); >>> ?? if (is_amd()) { >>> ???? return _family_id_amd[cpu_family_id]; >>> ?? } >>> ... >>> } >>> >>> Result of testcase TestCPUInformation.java on AMD Zen: >>> ----------System.out:(15/1615)---------- >>> ... >>> Family: 386 (0x17), Model: (0x1), Stepping: 0x1 >>> Ext. family: 0x8, Ext. model: 0x0, Type: 0x0, Signature: 0x00800f11 >>> ... >>> } >>> >>> The ?386? string is incorrectly and comes from Illegal access. >>> >>> The patch is based on the original repository: >>> hg.openjdk.java.net/jdk/jdk >>> >>> changeset:?? 54520:f48312257bc6 >>> tag:???????? tip >>> user:??????? vromero >>> date:??????? Thu Apr 11 22:56:11 2019 -0400 >>> summary:???? 8222151: refactoring: enhancements to >>> java.lang.Class::methodToString and java.lang.Class::getTypeName >>> >>> *Patch >>> The out of hg diff -g: >>> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>> b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>> @@ -262,6 +262,52 @@ >>> ??int VM_Version_Ext::_no_of_cores = 0; >>> ??int VM_Version_Ext::_no_of_packages = 0; >>> >>> +const char* const VM_Version_Ext::_family_id_intel[] = { >>> +? "8086/8088", >>> +? "", >>> +? "286", >>> +? "386", >>> +? "486", >>> +? "Pentium", >>> +? "Pentium Pro",?? //or Pentium-M/Woodcrest depeding on model >>> +? "", >>> +? "", >>> +? "", >>> +? "", >>> +? "", >>> +? "", >>> +? "", >>> +? "", >>> +? "Pentium 4" >>> +}; >>> + >>> +const char* const VM_Version_Ext::_family_id_amd[] = { >>> +? "", >>> +? "", >>> +? "", >>> +? "", >>> +? "5x86", >>> +? "K5/K6", >>> +? "Athlon/AthlonXP", >>> +? "", >>> +? "", >>> +? "", >>> +? "", >>> +? "", >>> +? "", >>> +? "", >>> +? "", >>> +? "Opteron/Athlon64", >>> +? "Opteron QC/Phenom",? // Barcelona et.al. >>> +? "", >>> +? "", >>> +? "", >>> +? "", >>> +? "", >>> +? "", >>> +? "Zen" >>> +}; >>> + >>> ??void VM_Version_Ext::initialize(void) { >>> ??? ResourceMark rm; >>> >>> @@ -401,15 +447,19 @@ >>> ??} >>> >>> ??const char* VM_Version_Ext::cpu_family_description(void) { >>> -? int cpu_family_id = extended_cpu_family(); >>> +? uint32_t cpu_family_id = extended_cpu_family(); >>> ??? if (is_amd()) { >>> -??? return _family_id_amd[cpu_family_id]; >>> +??? if (cpu_family_id < >>> sizeof(_family_id_amd)/sizeof(_family_id_amd[0])) { >>> +????? return _family_id_amd[cpu_family_id]; >>> +??? } >>> ??? } >>> ??? if (is_intel()) { >>> ????? if (cpu_family_id == CPU_FAMILY_PENTIUMPRO) { >>> ??????? return cpu_model_description(); >>> ????? } >>> -??? return _family_id_intel[cpu_family_id]; >>> +??? if (cpu_family_id < >>> sizeof(_family_id_intel)/sizeof(_family_id_intel[0])) { >>> +????? return _family_id_intel[cpu_family_id]; >>> +??? } >>> ??? } >>> ??? if (is_hygon()) { >>> ????? return "Dhyana"; >>> @@ -705,44 +755,6 @@ >>> ??? return _max_qualified_cpu_frequency; >>> ??} >>> >>> -const char* const VM_Version_Ext::_family_id_intel[] = { >>> -? "8086/8088", >>> -? "", >>> -? "286", >>> -? "386", >>> -? "486", >>> -? "Pentium", >>> -? "Pentium Pro",?? //or Pentium-M/Woodcrest depeding on model >>> -? "", >>> -? "", >>> -? "", >>> -? "", >>> -? "", >>> -? "", >>> -? "", >>> -? "", >>> -? "Pentium 4" >>> -}; >>> - >>> -const char* const VM_Version_Ext::_family_id_amd[] = { >>> -? "", >>> -? "", >>> -? "", >>> -? "", >>> -? "5x86", >>> -? "K5/K6", >>> -? "Athlon/AthlonXP", >>> -? "", >>> -? "", >>> -? "", >>> -? "", >>> -? "", >>> -? "", >>> -? "", >>> -? "", >>> -? "Opteron/Athlon64", >>> -? "Opteron QC/Phenom"? // Barcelona et.al. >>> -}; >>> ??// Partially from Intel 64 and IA-32 Architecture Software >>> Developer's Manual, >>> ??// September 2013, Vol 3C Table 35-1 >>> ??const char* const VM_Version_Ext::_model_id_pentium_pro[] = { >>> >>> *Test: >>> After patched,result of testcase TestCPUInformation.java on AMD Zen: >>> ----------System.out:(15/1615)---------- >>> Event: jdk.CPUInformation { >>> ?? ... >>> Family: Zen (0x17), Model: (0x1), Stepping: 0x1 >>> Ext. family: 0x8, Ext. model: 0x0, Type: 0x0, Signature: 0x00800f11 >>> Features: ebx: 0x4f400800, ecx: 0x7ed8320b, edx: 0x178bfbff >>> ?? ... >>> } >>> >>> Is there anything incorrectly? >>> Please let me know your comments. >>> >>> Best Regards? >>> Fanjinke >>> >> > From fanjinke51 at yeah.net Fri Apr 12 07:59:03 2019 From: fanjinke51 at yeah.net (Jinke Fan) Date: Fri, 12 Apr 2019 15:59:03 +0800 Subject: RFR: Out-of-bounds access in cpu_family_description() In-Reply-To: <86575a27-934b-ef38-6ade-e287d158b539@oracle.com> References: <7e501bc0-c417-f05e-5ef1-21c08536b9b9@oracle.com> <1993c58b-c8b5-5431-e40d-67d79c93cbc5@yeah.net> <86575a27-934b-ef38-6ade-e287d158b539@oracle.com> Message-ID: <16d90713-e4eb-8b3e-0850-128580005e3e@yeah.net> Hi David, This seems good to me. Best Regards! Fanjinke On 2019/4/12 15:50, David Holmes wrote: > Hi Fanjinke, > > I have filed: > > https://bugs.openjdk.java.net/browse/JDK-8222387 > > On 12/04/2019 4:51 pm, Jinke Fan wrote: >> On 2019/4/12 14:20, David Holmes wrote: >>> Hi, >>> >>> Was there a reason you had to move the existing arrays before >>> extending the amd one with the missing values? >> Yes, because the addition uses sizeof to control the boundary access. >> If the arrays's defined were behind the sizeof,it causes a compilation >> error: "error: invalid application of 'sizeof? to incomplete type" > > Okay I found that a little crude so I went for a slightly nicer approach: > > http://cr.openjdk.java.net/~dholmes/8222387/webrev/ > > Hope you don't mind. > > Thanks, > David > >> Best Regards! >> Fanjinke >>> >>> Thanks, >>> David >>> >>> On 12/04/2019 3:47 pm, Jinke Fan wrote: >>>> Hi David, >>>> ?????In VM_Version_Ext::cpu_family_description has out-of-bounds >>>> access on AMD 17h (EPYC) processor. >>>> >>>> const char* VM_Version_Ext::cpu_family_description(void) { >>>> >>>> On AMD 17h (EPYC) processor extended_cpu_family() will return 23, >>>> but array _family_id_amd only has 17 members. >>>> >>>> ?? int cpu_family_id = extended_cpu_family(); >>>> ?? if (is_amd()) { >>>> ???? return _family_id_amd[cpu_family_id]; >>>> ?? } >>>> ... >>>> } >>>> >>>> Result of testcase TestCPUInformation.java on AMD Zen: >>>> ----------System.out:(15/1615)---------- >>>> ... >>>> Family: 386 (0x17), Model: (0x1), Stepping: 0x1 >>>> Ext. family: 0x8, Ext. model: 0x0, Type: 0x0, Signature: 0x00800f11 >>>> ... >>>> } >>>> >>>> The ?386? string is incorrectly and comes from Illegal access. >>>> >>>> The patch is based on the original repository: >>>> hg.openjdk.java.net/jdk/jdk >>>> >>>> changeset:?? 54520:f48312257bc6 >>>> tag:???????? tip >>>> user:??????? vromero >>>> date:??????? Thu Apr 11 22:56:11 2019 -0400 >>>> summary:???? 8222151: refactoring: enhancements to >>>> java.lang.Class::methodToString and java.lang.Class::getTypeName >>>> >>>> *Patch >>>> The out of hg diff -g: >>>> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>> b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>> @@ -262,6 +262,52 @@ >>>> ??int VM_Version_Ext::_no_of_cores = 0; >>>> ??int VM_Version_Ext::_no_of_packages = 0; >>>> >>>> +const char* const VM_Version_Ext::_family_id_intel[] = { >>>> +? "8086/8088", >>>> +? "", >>>> +? "286", >>>> +? "386", >>>> +? "486", >>>> +? "Pentium", >>>> +? "Pentium Pro",?? //or Pentium-M/Woodcrest depeding on model >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "Pentium 4" >>>> +}; >>>> + >>>> +const char* const VM_Version_Ext::_family_id_amd[] = { >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "5x86", >>>> +? "K5/K6", >>>> +? "Athlon/AthlonXP", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "Opteron/Athlon64", >>>> +? "Opteron QC/Phenom",? // Barcelona et.al. >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "Zen" >>>> +}; >>>> + >>>> ??void VM_Version_Ext::initialize(void) { >>>> ??? ResourceMark rm; >>>> >>>> @@ -401,15 +447,19 @@ >>>> ??} >>>> >>>> ??const char* VM_Version_Ext::cpu_family_description(void) { >>>> -? int cpu_family_id = extended_cpu_family(); >>>> +? uint32_t cpu_family_id = extended_cpu_family(); >>>> ??? if (is_amd()) { >>>> -??? return _family_id_amd[cpu_family_id]; >>>> +??? if (cpu_family_id < >>>> sizeof(_family_id_amd)/sizeof(_family_id_amd[0])) { >>>> +????? return _family_id_amd[cpu_family_id]; >>>> +??? } >>>> ??? } >>>> ??? if (is_intel()) { >>>> ????? if (cpu_family_id == CPU_FAMILY_PENTIUMPRO) { >>>> ??????? return cpu_model_description(); >>>> ????? } >>>> -??? return _family_id_intel[cpu_family_id]; >>>> +??? if (cpu_family_id < >>>> sizeof(_family_id_intel)/sizeof(_family_id_intel[0])) { >>>> +????? return _family_id_intel[cpu_family_id]; >>>> +??? } >>>> ??? } >>>> ??? if (is_hygon()) { >>>> ????? return "Dhyana"; >>>> @@ -705,44 +755,6 @@ >>>> ??? return _max_qualified_cpu_frequency; >>>> ??} >>>> >>>> -const char* const VM_Version_Ext::_family_id_intel[] = { >>>> -? "8086/8088", >>>> -? "", >>>> -? "286", >>>> -? "386", >>>> -? "486", >>>> -? "Pentium", >>>> -? "Pentium Pro",?? //or Pentium-M/Woodcrest depeding on model >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "Pentium 4" >>>> -}; >>>> - >>>> -const char* const VM_Version_Ext::_family_id_amd[] = { >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "5x86", >>>> -? "K5/K6", >>>> -? "Athlon/AthlonXP", >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "Opteron/Athlon64", >>>> -? "Opteron QC/Phenom"? // Barcelona et.al. >>>> -}; >>>> ??// Partially from Intel 64 and IA-32 Architecture Software >>>> Developer's Manual, >>>> ??// September 2013, Vol 3C Table 35-1 >>>> ??const char* const VM_Version_Ext::_model_id_pentium_pro[] = { >>>> >>>> *Test: >>>> After patched,result of testcase TestCPUInformation.java on AMD Zen: >>>> ----------System.out:(15/1615)---------- >>>> Event: jdk.CPUInformation { >>>> ?? ... >>>> Family: Zen (0x17), Model: (0x1), Stepping: 0x1 >>>> Ext. family: 0x8, Ext. model: 0x0, Type: 0x0, Signature: 0x00800f11 >>>> Features: ebx: 0x4f400800, ecx: 0x7ed8320b, edx: 0x178bfbff >>>> ?? ... >>>> } >>>> >>>> Is there anything incorrectly? >>>> Please let me know your comments. >>>> >>>> Best Regards? >>>> Fanjinke >>>> >>> >> > From lois.foltan at oracle.com Fri Apr 12 12:17:39 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 12 Apr 2019 08:17:39 -0400 Subject: RFR(M) JDK-8218994: Consolidate indy and condy JVM information within a BootstrapInfo data structure In-Reply-To: <6cdcd602-1543-e19e-718e-3a6c0784c2c1@oracle.com> References: <6cdcd602-1543-e19e-718e-3a6c0784c2c1@oracle.com> Message-ID: <49dcdd7a-8d40-f9d1-4334-880f635477ea@oracle.com> I've updated the webrev based on preliminary feedback from Coleen. http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.1/webrev/ Reviews appreciated! Lois On 3/14/2019 7:39 AM, Lois Foltan wrote: > Please review this change to consolidate indy and condy JVM > information to invoke a bootstrap method into a new BootstrapInfo data > structure as well as merge the condy and indy methods to invoke the > bootstrap within SystemDictionary. > > open webrev at: > http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.0/webrev/ > bug link: https://bugs.openjdk.java.net/browse/JDK-8218994 > co-contributors: Lois Foltan & John Rose > > Testing: hs-tier1-3 & jdk-tier1-3 (all platforms), hs-tier4-8 (linux > only), JCK vm & lang > > Thanks, > Lois From matthias.baesken at sap.com Fri Apr 12 12:51:54 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 12 Apr 2019 12:51:54 +0000 Subject: RFR : 8222280 : Provide virtualization related info in the hs_error file on AIX Message-ID: Hello, please review the following change . It brings AIX related virtualization information into the hs_err file . While preparing the patch I wondered a bit about the libperfstat usage in OpenJDK (Hotspot compared to JDK ). In JDK we link already to libperfstat at build time , see : jdk/make/lib/Lib-java.management.gmk BUILD_LIBMANAGEMENT jdk/make/lib/Lib-jdk.management.gmk BUILD_LIBMANAGEMENT_EXT While in hotspot dlopen/dladdr is used , see jdk/src/hotspot/os/aix/libperfstat_aix.cpp 58 bool libperfstat::init() { 59 60 // Dynamically load the libperfstat porting library. 61 g_libhandle = dlopen("/usr/lib/libperfstat.a(shr_64.o)", RTLD_MEMBER | RTLD_NOW); 62 if (!g_libhandle) { 63 trcVerbose("Cannot load libperfstat.a (dlerror: %s)", dlerror()); 64 return false; 65 } we dlopen and then resolve symbols at runtime. This was probably a good thing back then when AIX 5.3 was still supported as build platform , but I am not sure if it is still needed these days on AIX 7.1/7.2 . But in case the dlopen/dladdr approach in HS is still needed/wanted , I would switch to the libperfstat:: functions . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8222280 http://cr.openjdk.java.net/~mbaesken/webrevs/8222280_aix_virt.0/ Thanks , Matthias From vladimir.kozlov at oracle.com Fri Apr 12 15:36:01 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 12 Apr 2019 08:36:01 -0700 Subject: RFR: Out-of-bounds access in cpu_family_description() In-Reply-To: <86575a27-934b-ef38-6ade-e287d158b539@oracle.com> References: <7e501bc0-c417-f05e-5ef1-21c08536b9b9@oracle.com> <1993c58b-c8b5-5431-e40d-67d79c93cbc5@yeah.net> <86575a27-934b-ef38-6ade-e287d158b539@oracle.com> Message-ID: <28f26610-cdf3-bc86-ce5a-003c9315b2b2@oracle.com> Looks good. Thanks, Vladimir On 4/12/19 12:50 AM, David Holmes wrote: > Hi Fanjinke, > > I have filed: > > https://bugs.openjdk.java.net/browse/JDK-8222387 > > On 12/04/2019 4:51 pm, Jinke Fan wrote: >> On 2019/4/12 14:20, David Holmes wrote: >>> Hi, >>> >>> Was there a reason you had to move the existing arrays before extending the amd one with the missing values? >> Yes, because the addition uses sizeof to control the boundary access. >> If the arrays's defined were behind the sizeof,it causes a compilation error: "error: invalid application of 'sizeof? >> to incomplete type" > > Okay I found that a little crude so I went for a slightly nicer approach: > > http://cr.openjdk.java.net/~dholmes/8222387/webrev/ > > Hope you don't mind. > > Thanks, > David > >> Best Regards! >> Fanjinke >>> >>> Thanks, >>> David >>> >>> On 12/04/2019 3:47 pm, Jinke Fan wrote: >>>> Hi David, >>>> ?????In VM_Version_Ext::cpu_family_description has out-of-bounds >>>> access on AMD 17h (EPYC) processor. >>>> >>>> const char* VM_Version_Ext::cpu_family_description(void) { >>>> >>>> On AMD 17h (EPYC) processor extended_cpu_family() will return 23, >>>> but array _family_id_amd only has 17 members. >>>> >>>> ?? int cpu_family_id = extended_cpu_family(); >>>> ?? if (is_amd()) { >>>> ???? return _family_id_amd[cpu_family_id]; >>>> ?? } >>>> ... >>>> } >>>> >>>> Result of testcase TestCPUInformation.java on AMD Zen: >>>> ----------System.out:(15/1615)---------- >>>> ... >>>> Family: 386 (0x17), Model: (0x1), Stepping: 0x1 >>>> Ext. family: 0x8, Ext. model: 0x0, Type: 0x0, Signature: 0x00800f11 >>>> ... >>>> } >>>> >>>> The ?386? string is incorrectly and comes from Illegal access. >>>> >>>> The patch is based on the original repository: >>>> hg.openjdk.java.net/jdk/jdk >>>> >>>> changeset:?? 54520:f48312257bc6 >>>> tag:???????? tip >>>> user:??????? vromero >>>> date:??????? Thu Apr 11 22:56:11 2019 -0400 >>>> summary:???? 8222151: refactoring: enhancements to java.lang.Class::methodToString and java.lang.Class::getTypeName >>>> >>>> *Patch >>>> The out of hg diff -g: >>>> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>> @@ -262,6 +262,52 @@ >>>> ??int VM_Version_Ext::_no_of_cores = 0; >>>> ??int VM_Version_Ext::_no_of_packages = 0; >>>> >>>> +const char* const VM_Version_Ext::_family_id_intel[] = { >>>> +? "8086/8088", >>>> +? "", >>>> +? "286", >>>> +? "386", >>>> +? "486", >>>> +? "Pentium", >>>> +? "Pentium Pro",?? //or Pentium-M/Woodcrest depeding on model >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "Pentium 4" >>>> +}; >>>> + >>>> +const char* const VM_Version_Ext::_family_id_amd[] = { >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "5x86", >>>> +? "K5/K6", >>>> +? "Athlon/AthlonXP", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "Opteron/Athlon64", >>>> +? "Opteron QC/Phenom",? // Barcelona et.al. >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "", >>>> +? "Zen" >>>> +}; >>>> + >>>> ??void VM_Version_Ext::initialize(void) { >>>> ??? ResourceMark rm; >>>> >>>> @@ -401,15 +447,19 @@ >>>> ??} >>>> >>>> ??const char* VM_Version_Ext::cpu_family_description(void) { >>>> -? int cpu_family_id = extended_cpu_family(); >>>> +? uint32_t cpu_family_id = extended_cpu_family(); >>>> ??? if (is_amd()) { >>>> -??? return _family_id_amd[cpu_family_id]; >>>> +??? if (cpu_family_id < sizeof(_family_id_amd)/sizeof(_family_id_amd[0])) { >>>> +????? return _family_id_amd[cpu_family_id]; >>>> +??? } >>>> ??? } >>>> ??? if (is_intel()) { >>>> ????? if (cpu_family_id == CPU_FAMILY_PENTIUMPRO) { >>>> ??????? return cpu_model_description(); >>>> ????? } >>>> -??? return _family_id_intel[cpu_family_id]; >>>> +??? if (cpu_family_id < sizeof(_family_id_intel)/sizeof(_family_id_intel[0])) { >>>> +????? return _family_id_intel[cpu_family_id]; >>>> +??? } >>>> ??? } >>>> ??? if (is_hygon()) { >>>> ????? return "Dhyana"; >>>> @@ -705,44 +755,6 @@ >>>> ??? return _max_qualified_cpu_frequency; >>>> ??} >>>> >>>> -const char* const VM_Version_Ext::_family_id_intel[] = { >>>> -? "8086/8088", >>>> -? "", >>>> -? "286", >>>> -? "386", >>>> -? "486", >>>> -? "Pentium", >>>> -? "Pentium Pro",?? //or Pentium-M/Woodcrest depeding on model >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "Pentium 4" >>>> -}; >>>> - >>>> -const char* const VM_Version_Ext::_family_id_amd[] = { >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "5x86", >>>> -? "K5/K6", >>>> -? "Athlon/AthlonXP", >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "", >>>> -? "Opteron/Athlon64", >>>> -? "Opteron QC/Phenom"? // Barcelona et.al. >>>> -}; >>>> ??// Partially from Intel 64 and IA-32 Architecture Software Developer's Manual, >>>> ??// September 2013, Vol 3C Table 35-1 >>>> ??const char* const VM_Version_Ext::_model_id_pentium_pro[] = { >>>> >>>> *Test: >>>> After patched,result of testcase TestCPUInformation.java on AMD Zen: >>>> ----------System.out:(15/1615)---------- >>>> Event: jdk.CPUInformation { >>>> ?? ... >>>> Family: Zen (0x17), Model: (0x1), Stepping: 0x1 >>>> Ext. family: 0x8, Ext. model: 0x0, Type: 0x0, Signature: 0x00800f11 >>>> Features: ebx: 0x4f400800, ecx: 0x7ed8320b, edx: 0x178bfbff >>>> ?? ... >>>> } >>>> >>>> Is there anything incorrectly? >>>> Please let me know your comments. >>>> >>>> Best Regards? >>>> Fanjinke >>>> >>> >> From vladimir.kozlov at oracle.com Fri Apr 12 15:44:35 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 12 Apr 2019 08:44:35 -0700 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully In-Reply-To: <2848933c-e6bc-be44-7970-436ac00f0479@oracle.com> References: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> <144af13e-33e2-2089-f8d2-902e94485eb1@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> Message-ID: <188da7c3-7384-220a-9290-cdd4bad25fce@oracle.com> 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 hohensee at amazon.com Fri Apr 12 17:20:57 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 12 Apr 2019 17:20:57 +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: <2183FC12-27E9-420C-8906-35138923D8CB@amazon.com> 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 david.holmes at oracle.com Fri Apr 12 22:59:09 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 13 Apr 2019 08:59:09 +1000 Subject: RFR: Out-of-bounds access in cpu_family_description() In-Reply-To: <28f26610-cdf3-bc86-ce5a-003c9315b2b2@oracle.com> References: <7e501bc0-c417-f05e-5ef1-21c08536b9b9@oracle.com> <1993c58b-c8b5-5431-e40d-67d79c93cbc5@yeah.net> <86575a27-934b-ef38-6ade-e287d158b539@oracle.com> <28f26610-cdf3-bc86-ce5a-003c9315b2b2@oracle.com> Message-ID: <3e36b9c3-b380-56f5-67cc-bcceefb28a43@oracle.com> Thanks Vladimir! David On 13/04/2019 1:36 am, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 4/12/19 12:50 AM, David Holmes wrote: >> Hi Fanjinke, >> >> I have filed: >> >> https://bugs.openjdk.java.net/browse/JDK-8222387 >> >> On 12/04/2019 4:51 pm, Jinke Fan wrote: >>> On 2019/4/12 14:20, David Holmes wrote: >>>> Hi, >>>> >>>> Was there a reason you had to move the existing arrays before >>>> extending the amd one with the missing values? >>> Yes, because the addition uses sizeof to control the boundary access. >>> If the arrays's defined were behind the sizeof,it causes a >>> compilation error: "error: invalid application of 'sizeof? to >>> incomplete type" >> >> Okay I found that a little crude so I went for a slightly nicer approach: >> >> http://cr.openjdk.java.net/~dholmes/8222387/webrev/ >> >> Hope you don't mind. >> >> Thanks, >> David >> >>> Best Regards! >>> Fanjinke >>>> >>>> Thanks, >>>> David >>>> >>>> On 12/04/2019 3:47 pm, Jinke Fan wrote: >>>>> Hi David, >>>>> ?????In VM_Version_Ext::cpu_family_description has out-of-bounds >>>>> access on AMD 17h (EPYC) processor. >>>>> >>>>> const char* VM_Version_Ext::cpu_family_description(void) { >>>>> >>>>> On AMD 17h (EPYC) processor extended_cpu_family() will return 23, >>>>> but array _family_id_amd only has 17 members. >>>>> >>>>> ?? int cpu_family_id = extended_cpu_family(); >>>>> ?? if (is_amd()) { >>>>> ???? return _family_id_amd[cpu_family_id]; >>>>> ?? } >>>>> ... >>>>> } >>>>> >>>>> Result of testcase TestCPUInformation.java on AMD Zen: >>>>> ----------System.out:(15/1615)---------- >>>>> ... >>>>> Family: 386 (0x17), Model: (0x1), Stepping: 0x1 >>>>> Ext. family: 0x8, Ext. model: 0x0, Type: 0x0, Signature: 0x00800f11 >>>>> ... >>>>> } >>>>> >>>>> The ?386? string is incorrectly and comes from Illegal access. >>>>> >>>>> The patch is based on the original repository: >>>>> hg.openjdk.java.net/jdk/jdk >>>>> >>>>> changeset:?? 54520:f48312257bc6 >>>>> tag:???????? tip >>>>> user:??????? vromero >>>>> date:??????? Thu Apr 11 22:56:11 2019 -0400 >>>>> summary:???? 8222151: refactoring: enhancements to >>>>> java.lang.Class::methodToString and java.lang.Class::getTypeName >>>>> >>>>> *Patch >>>>> The out of hg diff -g: >>>>> diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>> b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>> --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>> +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp >>>>> @@ -262,6 +262,52 @@ >>>>> ??int VM_Version_Ext::_no_of_cores = 0; >>>>> ??int VM_Version_Ext::_no_of_packages = 0; >>>>> >>>>> +const char* const VM_Version_Ext::_family_id_intel[] = { >>>>> +? "8086/8088", >>>>> +? "", >>>>> +? "286", >>>>> +? "386", >>>>> +? "486", >>>>> +? "Pentium", >>>>> +? "Pentium Pro",?? //or Pentium-M/Woodcrest depeding on model >>>>> +? "", >>>>> +? "", >>>>> +? "", >>>>> +? "", >>>>> +? "", >>>>> +? "", >>>>> +? "", >>>>> +? "", >>>>> +? "Pentium 4" >>>>> +}; >>>>> + >>>>> +const char* const VM_Version_Ext::_family_id_amd[] = { >>>>> +? "", >>>>> +? "", >>>>> +? "", >>>>> +? "", >>>>> +? "5x86", >>>>> +? "K5/K6", >>>>> +? "Athlon/AthlonXP", >>>>> +? "", >>>>> +? "", >>>>> +? "", >>>>> +? "", >>>>> +? "", >>>>> +? "", >>>>> +? "", >>>>> +? "", >>>>> +? "Opteron/Athlon64", >>>>> +? "Opteron QC/Phenom",? // Barcelona et.al. >>>>> +? "", >>>>> +? "", >>>>> +? "", >>>>> +? "", >>>>> +? "", >>>>> +? "", >>>>> +? "Zen" >>>>> +}; >>>>> + >>>>> ??void VM_Version_Ext::initialize(void) { >>>>> ??? ResourceMark rm; >>>>> >>>>> @@ -401,15 +447,19 @@ >>>>> ??} >>>>> >>>>> ??const char* VM_Version_Ext::cpu_family_description(void) { >>>>> -? int cpu_family_id = extended_cpu_family(); >>>>> +? uint32_t cpu_family_id = extended_cpu_family(); >>>>> ??? if (is_amd()) { >>>>> -??? return _family_id_amd[cpu_family_id]; >>>>> +??? if (cpu_family_id < >>>>> sizeof(_family_id_amd)/sizeof(_family_id_amd[0])) { >>>>> +????? return _family_id_amd[cpu_family_id]; >>>>> +??? } >>>>> ??? } >>>>> ??? if (is_intel()) { >>>>> ????? if (cpu_family_id == CPU_FAMILY_PENTIUMPRO) { >>>>> ??????? return cpu_model_description(); >>>>> ????? } >>>>> -??? return _family_id_intel[cpu_family_id]; >>>>> +??? if (cpu_family_id < >>>>> sizeof(_family_id_intel)/sizeof(_family_id_intel[0])) { >>>>> +????? return _family_id_intel[cpu_family_id]; >>>>> +??? } >>>>> ??? } >>>>> ??? if (is_hygon()) { >>>>> ????? return "Dhyana"; >>>>> @@ -705,44 +755,6 @@ >>>>> ??? return _max_qualified_cpu_frequency; >>>>> ??} >>>>> >>>>> -const char* const VM_Version_Ext::_family_id_intel[] = { >>>>> -? "8086/8088", >>>>> -? "", >>>>> -? "286", >>>>> -? "386", >>>>> -? "486", >>>>> -? "Pentium", >>>>> -? "Pentium Pro",?? //or Pentium-M/Woodcrest depeding on model >>>>> -? "", >>>>> -? "", >>>>> -? "", >>>>> -? "", >>>>> -? "", >>>>> -? "", >>>>> -? "", >>>>> -? "", >>>>> -? "Pentium 4" >>>>> -}; >>>>> - >>>>> -const char* const VM_Version_Ext::_family_id_amd[] = { >>>>> -? "", >>>>> -? "", >>>>> -? "", >>>>> -? "", >>>>> -? "5x86", >>>>> -? "K5/K6", >>>>> -? "Athlon/AthlonXP", >>>>> -? "", >>>>> -? "", >>>>> -? "", >>>>> -? "", >>>>> -? "", >>>>> -? "", >>>>> -? "", >>>>> -? "", >>>>> -? "Opteron/Athlon64", >>>>> -? "Opteron QC/Phenom"? // Barcelona et.al. >>>>> -}; >>>>> ??// Partially from Intel 64 and IA-32 Architecture Software >>>>> Developer's Manual, >>>>> ??// September 2013, Vol 3C Table 35-1 >>>>> ??const char* const VM_Version_Ext::_model_id_pentium_pro[] = { >>>>> >>>>> *Test: >>>>> After patched,result of testcase TestCPUInformation.java on AMD Zen: >>>>> ----------System.out:(15/1615)---------- >>>>> Event: jdk.CPUInformation { >>>>> ?? ... >>>>> Family: Zen (0x17), Model: (0x1), Stepping: 0x1 >>>>> Ext. family: 0x8, Ext. model: 0x0, Type: 0x0, Signature: 0x00800f11 >>>>> Features: ebx: 0x4f400800, ecx: 0x7ed8320b, edx: 0x178bfbff >>>>> ?? ... >>>>> } >>>>> >>>>> Is there anything incorrectly? >>>>> Please let me know your comments. >>>>> >>>>> Best Regards? >>>>> Fanjinke >>>>> >>>> >>> From christoph.langer at sap.com Mon Apr 15 06:13:01 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 15 Apr 2019 06:13:01 +0000 Subject: RFR : 8222280 : Provide virtualization related info in the hs_error file on AIX In-Reply-To: References: Message-ID: Hi Matthias, I think the change is good. As regards to libperfstat usage: I think we should clean this up and try to link during the build/use the system headers. We don't need to support AIX V5.3 as build release any longer and probably all required functionality is contained in the headers of the required minimum AIX build release. This needs to be doublechecked when attempting the cleanup, though. Best regards Christoph > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Freitag, 12. April 2019 14:52 > To: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' > > Subject: RFR : 8222280 : Provide virtualization related info in the hs_error file > on AIX > > Hello, please review the following change . It brings AIX related > virtualization information into the hs_err file . > > While preparing the patch I wondered a bit about the libperfstat usage in > OpenJDK (Hotspot compared to JDK ). > In JDK we link already to libperfstat at build time , see : > > jdk/make/lib/Lib-java.management.gmk > BUILD_LIBMANAGEMENT > > jdk/make/lib/Lib-jdk.management.gmk > BUILD_LIBMANAGEMENT_EXT > > > While in hotspot dlopen/dladdr is used , see > jdk/src/hotspot/os/aix/libperfstat_aix.cpp > > 58 bool libperfstat::init() { > 59 > 60 // Dynamically load the libperfstat porting library. > 61 g_libhandle = dlopen("/usr/lib/libperfstat.a(shr_64.o)", RTLD_MEMBER | > RTLD_NOW); > 62 if (!g_libhandle) { > 63 trcVerbose("Cannot load libperfstat.a (dlerror: %s)", dlerror()); > 64 return false; > 65 } > > we dlopen and then resolve symbols at runtime. > This was probably a good thing back then when AIX 5.3 was still supported as > build platform , but I am not sure if it is still needed these days on AIX > 7.1/7.2 . > > But in case the dlopen/dladdr approach in HS is still needed/wanted , I > would switch to the libperfstat:: functions . > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8222280 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8222280_aix_virt.0/ > > > Thanks , Matthias From matthias.baesken at sap.com Mon Apr 15 07:09:52 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 15 Apr 2019 07:09:52 +0000 Subject: RFR : 8222280 : Provide virtualization related info in the hs_error file on AIX In-Reply-To: References: Message-ID: Hi Christoph, thanks for the review . So I stay with the direct usage perfstat API in my change . > > As regards to libperfstat usage: I think we should clean this up and try to link > during the build/use the system headers. We don't need to support AIX V5.3 > as build release any longer and probably all required functionality is > contained in the headers of the required minimum AIX build release. This > needs to be doublechecked when attempting the cleanup, though. > I think this should be done in a separate change . Can we assume minimum AIX 7.1 at build+runtime (I guess this would make things easier and it is anyway documented in the build platforms Wiki) ? Currently I see these usages of libperfstat:: os_aix.cpp 748 const int rc = libperfstat::perfstat_memory_total(NULL, &psmt, sizeof(psmt), 1); 1400 libperfstat::wparinfo_t wi; 1401 if (libperfstat::get_wparinfo(&wi)) { 1409 libperfstat::partitioninfo_t pi; 1410 if (libperfstat::get_partitioninfo(&pi)) { 3482 libperfstat::perfstat_reset(); 4004 // AIX: use libperfstat 4005 libperfstat::cpuinfo_t ci; 4006 if (libperfstat::get_cpuinfo(&ci)) { 4183 if (!libperfstat::init()) { Best regards, Matthias > -----Original Message----- > From: Langer, Christoph > Sent: Montag, 15. April 2019 08:13 > To: Baesken, Matthias ; ppc-aix-port- > dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: RE: RFR : 8222280 : Provide virtualization related info in the hs_error > file on AIX > > Hi Matthias, > > I think the change is good. > > As regards to libperfstat usage: I think we should clean this up and try to link > during the build/use the system headers. We don't need to support AIX V5.3 > as build release any longer and probably all required functionality is > contained in the headers of the required minimum AIX build release. This > needs to be doublechecked when attempting the cleanup, though. > > Best regards > Christoph > > > -----Original Message----- > > From: hotspot-dev On Behalf > Of > > Baesken, Matthias > > Sent: Freitag, 12. April 2019 14:52 > > To: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' > > > > Subject: RFR : 8222280 : Provide virtualization related info in the hs_error > file > > on AIX > > > > Hello, please review the following change . It brings AIX related > > virtualization information into the hs_err file . > > > > While preparing the patch I wondered a bit about the libperfstat usage > in > > OpenJDK (Hotspot compared to JDK ). > > In JDK we link already to libperfstat at build time , see : > > > > jdk/make/lib/Lib-java.management.gmk > > BUILD_LIBMANAGEMENT > > > > jdk/make/lib/Lib-jdk.management.gmk > > BUILD_LIBMANAGEMENT_EXT > > > > > > While in hotspot dlopen/dladdr is used , see > > jdk/src/hotspot/os/aix/libperfstat_aix.cpp > > > > 58 bool libperfstat::init() { > > 59 > > 60 // Dynamically load the libperfstat porting library. > > 61 g_libhandle = dlopen("/usr/lib/libperfstat.a(shr_64.o)", RTLD_MEMBER > | > > RTLD_NOW); > > 62 if (!g_libhandle) { > > 63 trcVerbose("Cannot load libperfstat.a (dlerror: %s)", dlerror()); > > 64 return false; > > 65 } > > > > we dlopen and then resolve symbols at runtime. > > This was probably a good thing back then when AIX 5.3 was still supported > as > > build platform , but I am not sure if it is still needed these days on AIX > > 7.1/7.2 . > > > > But in case the dlopen/dladdr approach in HS is still needed/wanted , I > > would switch to the libperfstat:: functions . > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8222280 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8222280_aix_virt.0/ > > > > > > Thanks , Matthias From jcbeyler at google.com Mon Apr 15 14:31:30 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Mon, 15 Apr 2019 09:31:30 -0500 Subject: RFR (L) 8213501 : Deploy ExceptionJniWrapper for a few tests In-Reply-To: References: <45341168-e7e0-90d1-449f-210500882b8f@oracle.com> <55283958-de3d-07f2-51e3-ad34c5046a96@oracle.com> <31613f88-5f7d-938d-e9f6-69cdaf857268@oracle.com> <839301b7-c247-df3b-e485-283e8bb7388b@oracle.com> <95fe277d-ba6e-4fec-77aa-d1f1051751aa@oracle.com> <72bf2f4a-5bf7-98de-5f00-68485072923d@oracle.com> <25a50bc3-222c-a915-5517-37a2f9375c42@oracle.com> Message-ID: Hi all, Ping for a final LGTM? :) Jc On Wed, Apr 10, 2019 at 8:18 PM Jean Christophe Beyler wrote: > Hi Paul, > > Exactly :). Actually you are right, when trying to figure out build errors > in windows/solaris, I moved declarations around. > > I've moved them back and the incremental is thus: > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.06_08/ > > And the full new version is: > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.08/ > > This has passed the submit repo (thanks serguei ;-)). > > Could I get another LGTM for this and then we can move forward ? :) > > Thanks for your help, > Jc > > > From coppa at di.uniroma1.it Mon Apr 15 17:21:59 2019 From: coppa at di.uniroma1.it (Emilio Coppa) Date: Mon, 15 Apr 2019 19:21:59 +0200 Subject: MPLR 2019 - Call for Papers Message-ID: Apologies if you receive multiple copies of this CFP. The 16th International Conference on Managed Programming Languages & Runtimes (MPLR, formerly ManLang) is a premier forum for presenting and discussing novel results in all aspects of managed programming languages and runtime systems, which serve as building blocks for some of the most important computing systems around, ranging from small-scale (embedded and real-time systems) to large-scale (cloud-computing and big-data platforms) and anything in between (mobile, IoT, and wearable applications). This year, MPLR is co-located with SPLASH 2019 and sponsored by ACM. For more information, check out the conference website: https://conf.researchr.org/home/mplr-2019 # Topics Topics of interest include but are not limited to: * Languages and Compilers - Managed languages (e.g., Java, Scala, JavaScript, Python, Ruby, C#, F#, Clojure, Groovy, Kotlin, R, Smalltalk, Racket, Rust, Go, etc.) - Domain-specific languages - Language design - Compilers and interpreters - Type systems and program logics - Language interoperability - Parallelism, distribution, and concurrency * Virtual Machines - Managed runtime systems (e.g., JVM, Dalvik VM, Android Runtime (ART), LLVM, .NET CLR, RPython, etc.) - VM design and optimization - VMs for mobile and embedded devices - VMs for real-time applications - Memory management - Hardware/software co-design * Techniques, Tools, and Applications - Static and dynamic program analysis - Testing and debugging - Refactoring - Program understanding - Program synthesis - Security and privacy - Performance analysis and monitoring - Compiler and program verification # Submission Categories MPLR accepts four types of submissions: 1. Regular research papers, which describe novel contributions involving managed language platforms (up to 12 pages excluding bibliography and appendix). Research papers will be evaluated based on their relevance, novelty, technical rigor, and contribution to the state-of-the-art. 2. Work-in-progress research papers, which describe promising new ideas but yet have less maturity than full papers (up to 6 pages excluding bibliography and appendix). When evaluating work-in-progress papers, more emphasis will be placed on novelty and the potential of the new ideas than on technical rigor and experimental results. 3. Industry and tool papers, which present technical challenges and solutions for managed language platforms in the context of deployed applications and systems (up to 6 pages excluding bibliography and appendix). Industry and tool papers will be evaluated on their relevance, usefulness, and results. Suitability for demonstration and availability will also be considered for tool papers. 4. Posters, which can be accompanied by a one-page abstract and will be evaluated on similar criteria as Work-in-progress papers. Posters can accompany any submission as a way to provide additional demonstration and discussion opportunities. MPLR 2019 submissions must conform to the ACM Policy on Prior Publication and Simultaneous Submissions and to the SIGPLAN Republication Policy. # Important Dates and Organization Submission Deadline: ***Jul 8, 2019*** Author Notification: Aug 24, 2019 Camera Ready: Sep 12, 2019 Conference Dates: Oct 20-25, 2019 General Chair: Tony Hosking, Australian National University / Data61, Australia Program Chair: Irene Finocchi, Sapienza University of Rome, Italy Program Committee: * Edd Barrett, King's College London, United Kingdom * Steve Blackburn, Australian National University, Australia * Lubom?r Bulej, Charles University, Czech Republic * Shigeru Chiba, University of Tokyo, Japan * Daniele Cono D'Elia, Sapienza University of Rome, Italy * Ana L?cia de Moura, Pontifical Catholic University of Rio de Janeiro, Brazil * Erik Ernst, Google, Denmark * Matthew Hertz, University at Buffalo, United States * Vivek Kumar, Indraprastha Institute of Information Technology, Delhi * Doug Lea, State University of New York (SUNY) Oswego, United States * Magnus Madsen, Aarhus University, Denmark * Hidehiko Masuhara, Tokyo Institute of Technology, Japan * Ana Milanova, Rensselaer Polytechnic Institute, United States * Matthew Parkinson, Microsoft Research, United Kingdom * Gregor Richards, University of Waterloo, Canada * Manuel Rigger, ETH Zurich, Switzerland * Andrea Ros?, University of Lugano, Switzerland * Guido Salvaneschi, TU Darmstadt, Germany * Lukas Stadler, Oracle Labs, Austria * Ben L. Titzer, Google, Germany From lois.foltan at oracle.com Mon Apr 15 19:09:11 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 15 Apr 2019 15:09:11 -0400 Subject: RFR(M) JDK-8218994: Consolidate indy and condy JVM information within a BootstrapInfo data structure In-Reply-To: <49dcdd7a-8d40-f9d1-4334-880f635477ea@oracle.com> References: <6cdcd602-1543-e19e-718e-3a6c0784c2c1@oracle.com> <49dcdd7a-8d40-f9d1-4334-880f635477ea@oracle.com> Message-ID: <22291755-2b3d-01dc-135f-04eb95aef612@oracle.com> Updated webrev to fix typos caught by John's review of the .1 webrev http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.2/webrev/ Thanks, Lois On 4/12/2019 8:17 AM, Lois Foltan wrote: > I've updated the webrev based on preliminary feedback from Coleen. > > http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.1/webrev/ > > Reviews appreciated! > Lois > > On 3/14/2019 7:39 AM, Lois Foltan wrote: >> Please review this change to consolidate indy and condy JVM >> information to invoke a bootstrap method into a new BootstrapInfo >> data structure as well as merge the condy and indy methods to invoke >> the bootstrap within SystemDictionary. >> >> open webrev at: >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.0/webrev/ >> bug link: https://bugs.openjdk.java.net/browse/JDK-8218994 >> co-contributors: Lois Foltan & John Rose >> >> Testing: hs-tier1-3 & jdk-tier1-3 (all platforms), hs-tier4-8 (linux >> only), JCK vm & lang >> >> Thanks, >> Lois > From matthias.baesken at sap.com Tue Apr 16 11:52:20 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 16 Apr 2019 11:52:20 +0000 Subject: RFR : 8222280 : Provide virtualization related info in the hs_error file on AIX In-Reply-To: References: Message-ID: Ping - may I get a second review for this ? Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Montag, 15. April 2019 09:10 > To: Langer, Christoph ; ppc-aix-port- > dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: RE: RFR : 8222280 : Provide virtualization related info in the hs_error > file on AIX > > Hi Christoph, thanks for the review . > So I stay with the direct usage perfstat API in my change . > > > > > As regards to libperfstat usage: I think we should clean this up and try to > link > > during the build/use the system headers. We don't need to support AIX > V5.3 > > as build release any longer and probably all required functionality is > > contained in the headers of the required minimum AIX build release. This > > needs to be doublechecked when attempting the cleanup, though. > > > > I think this should be done in a separate change . > Can we assume minimum AIX 7.1 at build+runtime (I guess this would > make things easier and it is anyway documented in the build platforms Wiki) > ? > > Currently I see these usages of libperfstat:: > > os_aix.cpp > > 748 const int rc = libperfstat::perfstat_memory_total(NULL, &psmt, > sizeof(psmt), 1); > 1400 libperfstat::wparinfo_t wi; > 1401 if (libperfstat::get_wparinfo(&wi)) { > 1409 libperfstat::partitioninfo_t pi; > 1410 if (libperfstat::get_partitioninfo(&pi)) { > 3482 libperfstat::perfstat_reset(); > 4004 // AIX: use libperfstat > 4005 libperfstat::cpuinfo_t ci; > 4006 if (libperfstat::get_cpuinfo(&ci)) { > 4183 if (!libperfstat::init()) { > > > Best regards, Matthias > > > -----Original Message----- > > From: Langer, Christoph > > Sent: Montag, 15. April 2019 08:13 > > To: Baesken, Matthias ; ppc-aix-port- > > dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' > dev at openjdk.java.net> > > Subject: RE: RFR : 8222280 : Provide virtualization related info in the > hs_error > > file on AIX > > > > Hi Matthias, > > > > I think the change is good. > > > > As regards to libperfstat usage: I think we should clean this up and try to > link > > during the build/use the system headers. We don't need to support AIX > V5.3 > > as build release any longer and probably all required functionality is > > contained in the headers of the required minimum AIX build release. This > > needs to be doublechecked when attempting the cleanup, though. > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: hotspot-dev On Behalf > > Of > > > Baesken, Matthias > > > Sent: Freitag, 12. April 2019 14:52 > > > To: ppc-aix-port-dev at openjdk.java.net; 'hotspot- > dev at openjdk.java.net' > > > > > > Subject: RFR : 8222280 : Provide virtualization related info in the hs_error > > file > > > on AIX > > > > > > Hello, please review the following change . It brings AIX related > > > virtualization information into the hs_err file . > > > > > > While preparing the patch I wondered a bit about the libperfstat usage > > in > > > OpenJDK (Hotspot compared to JDK ). > > > In JDK we link already to libperfstat at build time , see : > > > > > > jdk/make/lib/Lib-java.management.gmk > > > BUILD_LIBMANAGEMENT > > > > > > jdk/make/lib/Lib-jdk.management.gmk > > > BUILD_LIBMANAGEMENT_EXT > > > > > > > > > While in hotspot dlopen/dladdr is used , see > > > jdk/src/hotspot/os/aix/libperfstat_aix.cpp > > > > > > 58 bool libperfstat::init() { > > > 59 > > > 60 // Dynamically load the libperfstat porting library. > > > 61 g_libhandle = dlopen("/usr/lib/libperfstat.a(shr_64.o)", > RTLD_MEMBER > > | > > > RTLD_NOW); > > > 62 if (!g_libhandle) { > > > 63 trcVerbose("Cannot load libperfstat.a (dlerror: %s)", dlerror()); > > > 64 return false; > > > 65 } > > > > > > we dlopen and then resolve symbols at runtime. > > > This was probably a good thing back then when AIX 5.3 was still > supported > > as > > > build platform , but I am not sure if it is still needed these days on AIX > > > 7.1/7.2 . > > > > > > But in case the dlopen/dladdr approach in HS is still needed/wanted , I > > > would switch to the libperfstat:: functions . > > > > > > Bug/webrev : > > > > > > https://bugs.openjdk.java.net/browse/JDK-8222280 > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8222280_aix_virt.0/ > > > > > > > > > Thanks , Matthias From martin.doerr at sap.com Tue Apr 16 13:25:07 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 16 Apr 2019 13:25:07 +0000 Subject: RFR : 8222280 : Provide virtualization related info in the hs_error file on AIX In-Reply-To: References: Message-ID: Hi Matthias, I agree with that the libperfstat_aix should be discussed separately. It was needed for 2 reasons: - Support as400/PASE where it is not available at all. - Handle changes between AIX versions. With jdk13, we currently only support AIX 7.2 so including the system header should be fine for now. I can't estimate if there will be changes in future AIX versions which make our own lib important again. But I suggest to remove our own libperfstat_aix in a follow up change with the risk that we may potentially have to add it back. I'd like to hear Thomas' opinion on this, too. We currently support neither as400 nor any other AIX, so your change looks good to me. Best regards, Martin -----Original Message----- From: ppc-aix-port-dev On Behalf Of Baesken, Matthias Sent: Dienstag, 16. April 2019 13:52 To: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' Subject: [CAUTION] RE: RFR : 8222280 : Provide virtualization related info in the hs_error file on AIX Ping - may I get a second review for this ? Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Montag, 15. April 2019 09:10 > To: Langer, Christoph ; ppc-aix-port- > dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: RE: RFR : 8222280 : Provide virtualization related info in the hs_error > file on AIX > > Hi Christoph, thanks for the review . > So I stay with the direct usage perfstat API in my change . > > > > > As regards to libperfstat usage: I think we should clean this up and try to > link > > during the build/use the system headers. We don't need to support AIX > V5.3 > > as build release any longer and probably all required functionality is > > contained in the headers of the required minimum AIX build release. This > > needs to be doublechecked when attempting the cleanup, though. > > > > I think this should be done in a separate change . > Can we assume minimum AIX 7.1 at build+runtime (I guess this would > make things easier and it is anyway documented in the build platforms Wiki) > ? > > Currently I see these usages of libperfstat:: > > os_aix.cpp > > 748 const int rc = libperfstat::perfstat_memory_total(NULL, &psmt, > sizeof(psmt), 1); > 1400 libperfstat::wparinfo_t wi; > 1401 if (libperfstat::get_wparinfo(&wi)) { > 1409 libperfstat::partitioninfo_t pi; > 1410 if (libperfstat::get_partitioninfo(&pi)) { > 3482 libperfstat::perfstat_reset(); > 4004 // AIX: use libperfstat > 4005 libperfstat::cpuinfo_t ci; > 4006 if (libperfstat::get_cpuinfo(&ci)) { > 4183 if (!libperfstat::init()) { > > > Best regards, Matthias > > > -----Original Message----- > > From: Langer, Christoph > > Sent: Montag, 15. April 2019 08:13 > > To: Baesken, Matthias ; ppc-aix-port- > > dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' > dev at openjdk.java.net> > > Subject: RE: RFR : 8222280 : Provide virtualization related info in the > hs_error > > file on AIX > > > > Hi Matthias, > > > > I think the change is good. > > > > As regards to libperfstat usage: I think we should clean this up and try to > link > > during the build/use the system headers. We don't need to support AIX > V5.3 > > as build release any longer and probably all required functionality is > > contained in the headers of the required minimum AIX build release. This > > needs to be doublechecked when attempting the cleanup, though. > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: hotspot-dev On Behalf > > Of > > > Baesken, Matthias > > > Sent: Freitag, 12. April 2019 14:52 > > > To: ppc-aix-port-dev at openjdk.java.net; 'hotspot- > dev at openjdk.java.net' > > > > > > Subject: RFR : 8222280 : Provide virtualization related info in the hs_error > > file > > > on AIX > > > > > > Hello, please review the following change . It brings AIX related > > > virtualization information into the hs_err file . > > > > > > While preparing the patch I wondered a bit about the libperfstat usage > > in > > > OpenJDK (Hotspot compared to JDK ). > > > In JDK we link already to libperfstat at build time , see : > > > > > > jdk/make/lib/Lib-java.management.gmk > > > BUILD_LIBMANAGEMENT > > > > > > jdk/make/lib/Lib-jdk.management.gmk > > > BUILD_LIBMANAGEMENT_EXT > > > > > > > > > While in hotspot dlopen/dladdr is used , see > > > jdk/src/hotspot/os/aix/libperfstat_aix.cpp > > > > > > 58 bool libperfstat::init() { > > > 59 > > > 60 // Dynamically load the libperfstat porting library. > > > 61 g_libhandle = dlopen("/usr/lib/libperfstat.a(shr_64.o)", > RTLD_MEMBER > > | > > > RTLD_NOW); > > > 62 if (!g_libhandle) { > > > 63 trcVerbose("Cannot load libperfstat.a (dlerror: %s)", dlerror()); > > > 64 return false; > > > 65 } > > > > > > we dlopen and then resolve symbols at runtime. > > > This was probably a good thing back then when AIX 5.3 was still > supported > > as > > > build platform , but I am not sure if it is still needed these days on AIX > > > 7.1/7.2 . > > > > > > But in case the dlopen/dladdr approach in HS is still needed/wanted , I > > > would switch to the libperfstat:: functions . > > > > > > Bug/webrev : > > > > > > https://bugs.openjdk.java.net/browse/JDK-8222280 > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8222280_aix_virt.0/ > > > > > > > > > Thanks , Matthias From shade at redhat.com Tue Apr 16 16:05:58 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 16 Apr 2019 18:05:58 +0200 Subject: [11u] RFR 8219974: REDO JDK-8219492: Restore static callsite resolution for the current class Message-ID: <369bf309-c547-f59c-608b-17b872638602@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8219974 Original fix; http://hg.openjdk.java.net/jdk/jdk/rev/77343f5c85cb Patch applies almost cleanly, but the code in 11u misses the rename to "*_unsafe_anonymous*" [1], which means we need to use the older variant of it. 11u webrev: http://cr.openjdk.java.net/~shade/8219974/webrev.11u.01/ Testing: clj -A:user timings (a bit better), tier1 -- Thanks, -Aleksey [1] https://bugs.openjdk.java.net/browse/JDK-8209301 From yumin.qi at gmail.com Tue Apr 16 18:27:32 2019 From: yumin.qi at gmail.com (yumin qi) Date: Tue, 16 Apr 2019 11:27:32 -0700 Subject: RFC: JWarmup precompile java hot methods at application startup In-Reply-To: References: Message-ID: HI, Did anyone have comments for this version? Thanks Yumin On Tue, Apr 9, 2019 at 10:36 AM yumin qi wrote: > Alan, > Thanks! Updated in same link: > http://cr.openjdk.java.net/~minqi/8220692/webrev-02/ > > Removed non-boot loader branch in nativeLookup.cpp. > Added jdk.jwarmup to boot loader list in make/common/Modules.gmk. > Tested again to make sure the new changes. > > Thanks > Yumin > > > On Tue, Apr 9, 2019 at 4:48 AM Alan Bateman > wrote: > >> On 09/04/2019 07:10, yumin qi wrote: >> > >> > Now the registerNatives is found when it looks up for native entry >> > in lookupNative.cpp. I thought the class JWarmUp will be loaded by >> > boot loader like Unsafe or WhiteBox, but I was wrong, it is loaded by >> > app class loader so logic for obtaining its native entry put in both >> > cases, boot loader and non boot loaders. >> > >> make/common/Modules.gmk is where BOOT_MODULES is defined with the list >> of modules mapped to the boot loader. >> >> -Alan >> > From karen.kinnear at oracle.com Tue Apr 16 22:06:28 2019 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 16 Apr 2019 18:06:28 -0400 Subject: RFR(M) JDK-8218994: Consolidate indy and condy JVM information within a BootstrapInfo data structure In-Reply-To: <22291755-2b3d-01dc-135f-04eb95aef612@oracle.com> References: <6cdcd602-1543-e19e-718e-3a6c0784c2c1@oracle.com> <49dcdd7a-8d40-f9d1-4334-880f635477ea@oracle.com> <22291755-2b3d-01dc-135f-04eb95aef612@oracle.com> Message-ID: <0E517D1E-B22B-4BA5-8D19-48ABEA464B01@oracle.com> Lois, Looks really good. A couple minor questions/comments - mostly about comments I did not find any bugs - so I don?t need to see an updated webrev. Pick-and-choose any suggestions you like/don?t like. 1. resolve_metadata Any chance this could be renamed to something more specific? e.g. resolve_bss_name_and_type? 2. bootstrapInfo: Why is there a field _is_method_call ? Couldn?t this be is_method_call() which gets the same info from indy_index <0 vs. >= 0? Or is there a timing reason you need both? 3. resolve_bsm. Nice to have a comment for the first line - since bootstrapInfo is a StackObj, this should only happen if the same thread has more than 1 indy/condy with the same bsm, right? 4. bootstrapInfo Handle _arg_values // array of static args; null for unresolved Could you please clarify what null means? Do you mean _arg_values is a handle to null if there are no static args? Or do you mean that elements in the array are null if unresolved? The former? 5. constantPool.cpp old line 927 // FIXME: Cache this once per BootstrapMethods entry, not once per CONSTANT_Dynamic -- did I read this correctly? That the resulting bootstrap_specifier is still caching the result per bss_index, where bss is either CONSTANT_Dynamic or CONSTANT_InvokeDynamic 6. Trivial How do you feel about asserts with no text message? See bootstrapInfo.cpp lines 55/56 I didn't check for others 7. where is has_bootstrap defined? 8. constantPool.cpp Did I read this correctly that JVMS 5.4.3.6 Steps 1 and 2 are both performed under invoke_bootstrap_method? Could you possibly clarify that in the comments 913-923? 9. bootstrapInfo.cpp resolve_args: if (!use_BSCI) I am confused about _arg_values setting: 1) looks like you set _arg_values = Handle(THREAD< arg_oop) and then overwrite with _arg_values = Handle(THREAD, args()) in some cases 2) if args is already objArrayHandle, why do you handleize again? 10. bootstrapInfo.cpp resolve_previously_linked_invokedynamic I know the include states what true/false mean. It would be helpful to duplicate the comment from the include at the start of the method. 11. linkResolver.cpp line 1727: "relevent" -> "relevant" 12. linkResolver.cpp line 1740 - what does DTRT mean? - is that "Does The Right Thing"? could you be more specific? 13. name resolve_newly_linked_invokedynamic is confusing. Is it worth having this as a separate method? This is just a set_handle call, with a small assertion. If you want to keep it, could you possibly rename it? the bootstrap_specifier is already resolved, and the assertion belongs to the success path after invoke_bootstrap_method I presume. If others feel strongly, ignore my comment. thanks, Karen > On Apr 15, 2019, at 3:09 PM, Lois Foltan wrote: > > Updated webrev to fix typos caught by John's review of the .1 webrev > > http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.2/webrev/ > > Thanks, > Lois > > On 4/12/2019 8:17 AM, Lois Foltan wrote: >> I've updated the webrev based on preliminary feedback from Coleen. >> >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.1/webrev/ >> >> Reviews appreciated! >> Lois >> >> On 3/14/2019 7:39 AM, Lois Foltan wrote: >>> Please review this change to consolidate indy and condy JVM information to invoke a bootstrap method into a new BootstrapInfo data structure as well as merge the condy and indy methods to invoke the bootstrap within SystemDictionary. >>> >>> open webrev at: http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.0/webrev/ >>> bug link: https://bugs.openjdk.java.net/browse/JDK-8218994 >>> co-contributors: Lois Foltan & John Rose >>> >>> Testing: hs-tier1-3 & jdk-tier1-3 (all platforms), hs-tier4-8 (linux only), JCK vm & lang >>> >>> Thanks, >>> Lois >> > From sgehwolf at redhat.com Wed Apr 17 17:32:12 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 17 Apr 2019 19:32:12 +0200 Subject: [PING2] RFR: 8217338: [Containers] Improve systemd slice memory limit support In-Reply-To: References: <4a1ae4e0e3efd68818bfe868349972aa878de60b.camel@redhat.com> <9a911da4b2a4a8eff42c7c2f1a19c06f6521da8d.camel@redhat.com> <226CB44C-7B3A-42E8-8385-4E85168DBA4E@oracle.com> <254f53446176175689373b346c11aabc26d9b4b0.camel@redhat.com> Message-ID: Ping? On Tue, 2019-04-09 at 11:33 +0200, Severin Gehwolf wrote: > Hi, > > Could I get another reviewer for this, please? Bob Vandette already reviewed it. > > Thank you! > > Cheers, > Severin > > On Tue, 2019-04-02 at 13:48 +0200, Severin Gehwolf wrote: > > Could I get a second review, please? > > > > Thanks, > > Severin > > > > On Thu, 2019-03-28 at 11:37 -0400, Bob Vandette wrote: > > > Sorry for the delay. The update looks good. > > > > > > Bob. > > > > > > > > > > On Mar 25, 2019, at 1:30 PM, Severin Gehwolf wrote: > > > > > > > > On Fri, 2019-03-22 at 14:25 -0400, Bob Vandette wrote: > > > > > Could you maybe combine subsystem_file_contents with subsystem_file_line_contents > > > > > by adding an additional argument? > > > > > > > > Done: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/05/webrev/ > > > > > > > > Thanks, > > > > Severin > > > > From david.holmes at oracle.com Wed Apr 17 23:00:08 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Apr 2019 09:00:08 +1000 Subject: [PING2] RFR: 8217338: [Containers] Improve systemd slice memory limit support In-Reply-To: References: <4a1ae4e0e3efd68818bfe868349972aa878de60b.camel@redhat.com> <9a911da4b2a4a8eff42c7c2f1a19c06f6521da8d.camel@redhat.com> <226CB44C-7B3A-42E8-8385-4E85168DBA4E@oracle.com> <254f53446176175689373b346c11aabc26d9b4b0.camel@redhat.com> Message-ID: Hi Severin, I took a look at this (again**) and although I'm not at all familiar with the actual cgroup facilities the changes seem reasonable in that they only look for a hierarchical memory limit if the initial limit is "unlimited". So you can add me as a reviewer. Thanks, David ** I didn't previously review in the hope someone more cgroup knowledgeable would do so. On 18/04/2019 3:32 am, Severin Gehwolf wrote: > Ping? > > On Tue, 2019-04-09 at 11:33 +0200, Severin Gehwolf wrote: >> Hi, >> >> Could I get another reviewer for this, please? Bob Vandette already reviewed it. >> >> Thank you! >> >> Cheers, >> Severin >> >> On Tue, 2019-04-02 at 13:48 +0200, Severin Gehwolf wrote: >>> Could I get a second review, please? >>> >>> Thanks, >>> Severin >>> >>> On Thu, 2019-03-28 at 11:37 -0400, Bob Vandette wrote: >>>> Sorry for the delay. The update looks good. >>>> >>>> Bob. >>>> >>>> >>>>> On Mar 25, 2019, at 1:30 PM, Severin Gehwolf wrote: >>>>> >>>>> On Fri, 2019-03-22 at 14:25 -0400, Bob Vandette wrote: >>>>>> Could you maybe combine subsystem_file_contents with subsystem_file_line_contents >>>>>> by adding an additional argument? >>>>> >>>>> Done: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/05/webrev/ >>>>> >>>>> Thanks, >>>>> Severin >>>>> > From sgehwolf at redhat.com Thu Apr 18 07:52:37 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 18 Apr 2019 09:52:37 +0200 Subject: [PING2] RFR: 8217338: [Containers] Improve systemd slice memory limit support In-Reply-To: References: <4a1ae4e0e3efd68818bfe868349972aa878de60b.camel@redhat.com> <9a911da4b2a4a8eff42c7c2f1a19c06f6521da8d.camel@redhat.com> <226CB44C-7B3A-42E8-8385-4E85168DBA4E@oracle.com> <254f53446176175689373b346c11aabc26d9b4b0.camel@redhat.com> Message-ID: <6a7fce25a4aae4e64b8ca9f248cdf8d633db4132.camel@redhat.com> Hi, On Thu, 2019-04-18 at 09:00 +1000, David Holmes wrote: > So you can add me as a reviewer. Thank you, David! I appreciate that. Cheers, Severin From aph at redhat.com Thu Apr 18 10:52:25 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 18 Apr 2019 11:52:25 +0100 Subject: [aarch64-port-dev ] Update enum Family CPU_Xxx for aarch64 from ISO8859-1 (ASCII) representation to HEX In-Reply-To: References: Message-ID: On 4/18/19 10:52 AM, Patrick Zhang OS wrote: > Thanks for any advice. I prefer Patch02. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From 1948638989 at qq.com Thu Apr 18 13:09:12 2019 From: 1948638989 at qq.com (=?ISO-8859-1?B?a2VsdGh1emFkeA==?=) Date: Thu, 18 Apr 2019 21:09:12 +0800 Subject: Can we dump more pretty CFG file format for C1 compiler HIR Message-ID: `+XX:+PrintCFGToFile` could dump ssa-based HIR into file, but its format is messy:```cfg begin_states begin_locals size 3 method "static jint com.github.kelthuzadx.HelloWorld.jerkSum(jint)" 1 i7 "[R570|I]" end_locals end_states begin_HIR .22 0 i15 ireturn i7 <|@ end_HIR begin_LIR 42 label [label:0x000002136a396400] <|@ 44 move [R570|I] [rax|I] <|@ 46 return [rax|I] <|@ end_LIR end_block end_cfg begin_intervals name "Before Register Allocation" 3 fixed "[rax|I]" 3 570 [0, 1[ [44, 46[ "no spill store" 4 fixed "[rdx|I]" 4 -1 [0, 4[ "no definition" 569 int 569 4 [4, 10[ 4 M 10 S "no spill store" 570 int 570 569 [10, 26[ [38, 44[ 10 M 26 S 38 M 41 L 44 S "no optimization" 571 int 571 573 [12, 30[ [36, 42[ 12 M 18 M 28 S 30 S 36 M 41 L "no optimization" 572 int 572 570 [26, 38[ 26 M 28 M 38 S "no spill store" 573 int 573 571 [30, 36[ 30 M 32 M 36 S "no spill store" end_intervals ``` So can we produce more readable format? From sgehwolf at redhat.com Thu Apr 18 13:41:09 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 18 Apr 2019 15:41:09 +0200 Subject: RFR: 8221639: [x32] expand_exec_shield_cs_limit workaround is undefined code after JDK-8199717 Message-ID: <673a0cc6b25fcfdcb3f3c69f4dcfd06d346e271a.camel@redhat.com> Hi, Could I please get reviews for this Linux x32 fix? JDK-8199717 added a performance optimization to only capture the initial stack size when launched via non-java launchers. However, on Linux x32, there is old code being executed to work around the exec shield CS limit. That code depends on the initial stack size being captured. Right now this is undefined code: Pointer artithmetic on NULL pointer. src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp:884:73: runtime error: pointer index expression with base 0x00000000 overflowed to 0xffffb000 I propose to not perform the optimization of JDK-8199717 for Linux x32. Bug: https://bugs.openjdk.java.net/browse/JDK-8221639 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221639/01/webrev/ Testing: release/fastdebug builds on x32 Linux, inspecting -Xlog:os=info messages, currently running through jdkd/submit. Tier 1 tests on Linux x86_64 Thoughts? Thanks, Severin From david.holmes at oracle.com Thu Apr 18 14:02:22 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 19 Apr 2019 00:02:22 +1000 Subject: RFR: 8221639: [x32] expand_exec_shield_cs_limit workaround is undefined code after JDK-8199717 In-Reply-To: <673a0cc6b25fcfdcb3f3c69f4dcfd06d346e271a.camel@redhat.com> References: <673a0cc6b25fcfdcb3f3c69f4dcfd06d346e271a.camel@redhat.com> Message-ID: <6a9f74f3-a1de-fc2a-370b-c64055611fd9@oracle.com> Hi Severin, I'll have to delve into this more deeply (but I'm on Easter break for the next 4 days). I don't recall ever being aware of "suppress_primordial_thread_resolution"! David On 18/04/2019 11:41 pm, Severin Gehwolf wrote: > Hi, > > Could I please get reviews for this Linux x32 fix? JDK-8199717 added a > performance optimization to only capture the initial stack size when > launched via non-java launchers. However, on Linux x32, there is old > code being executed to work around the exec shield CS limit. That code > depends on the initial stack size being captured. Right now this is > undefined code: Pointer artithmetic on NULL pointer. > > src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp:884:73: runtime error: pointer index expression with base 0x00000000 overflowed to 0xffffb000 > > I propose to not perform the optimization of JDK-8199717 for Linux x32. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221639 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221639/01/webrev/ > > Testing: release/fastdebug builds on x32 Linux, inspecting > -Xlog:os=info messages, currently running through jdkd/submit. Tier 1 > tests on Linux x86_64 > > Thoughts? > > Thanks, > Severin > From hohensee at amazon.com Thu Apr 18 15:10:07 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 18 Apr 2019 15:10:07 +0000 Subject: RFR (L) 8213501 : Deploy ExceptionJniWrapper for a few tests In-Reply-To: References: <45341168-e7e0-90d1-449f-210500882b8f@oracle.com> <55283958-de3d-07f2-51e3-ad34c5046a96@oracle.com> <31613f88-5f7d-938d-e9f6-69cdaf857268@oracle.com> <839301b7-c247-df3b-e485-283e8bb7388b@oracle.com> <95fe277d-ba6e-4fec-77aa-d1f1051751aa@oracle.com> <72bf2f4a-5bf7-98de-5f00-68485072923d@oracle.com> <25a50bc3-222c-a915-5517-37a2f9375c42@oracle.com> Message-ID: <1E4DDEF4-BCBC-473B-AE09-7A945643756F@amazon.com> Looks good. Apologies for the response delay. Paul From: Jean Christophe Beyler Date: Monday, April 15, 2019 at 7:32 AM To: "Hohensee, Paul" Cc: Alex Menkov , hotspot-dev Source Developers Subject: Re: RFR (L) 8213501 : Deploy ExceptionJniWrapper for a few tests Hi all, Ping for a final LGTM? :) Jc On Wed, Apr 10, 2019 at 8:18 PM Jean Christophe Beyler > wrote: Hi Paul, Exactly :). Actually you are right, when trying to figure out build errors in windows/solaris, I moved declarations around. I've moved them back and the incremental is thus: http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.06_08/ And the full new version is: http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.08/ This has passed the submit repo (thanks serguei ;-)). Could I get another LGTM for this and then we can move forward ? :) Thanks for your help, Jc From felix.yang at huawei.com Fri Apr 19 03:14:23 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Fri, 19 Apr 2019 03:14:23 +0000 Subject: Update enum Family CPU_Xxx for aarch64 from ISO8859-1 (ASCII) representation to HEX In-Reply-To: References: Message-ID: Patch02 looks better. But it's meaningless to keep the charater "'?'" in the comment. Thanks, Felix > > Hi > > Here is a quick question about a change upon the "enum Family" defined in > hotspot/cpu/aarch64/vm_version_aarch64.hpp. > > I want to add CPU_AMPERE (0xC0) into the enum; however it is not an "ASCII > printable character" like others, instead it belongs to the list of "The extended > ASCII codes"[2]. A simple patch [3] adding '?' simply would cause many > "multichar" warnings when making, while using HEX directly [4] for this item only > will bring an 'inconsistency' into of the overall definition of this enum, the last > choice is to use Hex representation for all [5]. It can be safe and better for future > new IDs if any; however I know it looks bringing a potential impact to all aarch64 > 'buddies'. > > Thanks for any advice. > > I don't want to add below option in makefiles to suppress warnings as it might be > helpful to detect real typos in future. > -Wno-multichar > Do not warn if a multicharacter constant (''FOOF'') is used. Usually they indicate a > typo in the user's code, as they have implementation-defined values, and should > not be used in portable code. > > [1] https://static.docs.arm.com/ddi0487/da/DDI0487D_a_armv8_arm.pdf, page > 5945. > [2] https://www.ascii-code.com/ > [3] http://cr.openjdk.java.net/~qpzhang/cpu_ampere/patch01.diff, use '?' > [4] http://cr.openjdk.java.net/~qpzhang/cpu_ampere/patch02.diff, use 0xC0 > [5] http://cr.openjdk.java.net/~qpzhang/cpu_ampere/patch03.diff, use Hex > representation for all > > FYI. > > Hex representation ISO8859-1 representation Implementer > 0x0 NUL Reserved for software use > 0xc0 ? Ampere Computing > 0x41 A ARM Limited > 0x42 B Broadcom Corporation > 0x43 C Cavium Inc. > 0x44 D Digital Equipment Corporation > 0x49 I Infineon Technologies AG > 0x4D M Motorola or Freescale Semiconductor Inc. > 0x4E N NVIDIA Corporation > 0x50 P Applied Micro Circuits Corporation > 0x51 Q Qualcomm Inc. > 0x56 V Marvell International Ltd. > 0x69 i Intel Corporation > > Regards > Patrick From patrick at os.amperecomputing.com Fri Apr 19 05:55:47 2019 From: patrick at os.amperecomputing.com (Patrick Zhang OS) Date: Fri, 19 Apr 2019 05:55:47 +0000 Subject: Update enum Family CPU_Xxx for aarch64 from ISO8859-1 (ASCII) representation to HEX In-Reply-To: References: Message-ID: Yes the character displays well in console but messy code in browsers. I would add some comment nearby to describe where the implementer codes come from. Regards Patrick -----Original Message----- From: Yangfei (Felix) Sent: Friday, April 19, 2019 11:14 AM To: Patrick Zhang OS ; aarch64-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: Update enum Family CPU_Xxx for aarch64 from ISO8859-1 (ASCII) representation to HEX Patch02 looks better. But it's meaningless to keep the charater "'?'" in the comment. Thanks, Felix > > Hi > > Here is a quick question about a change upon the "enum Family" defined > in hotspot/cpu/aarch64/vm_version_aarch64.hpp. > > I want to add CPU_AMPERE (0xC0) into the enum; however it is not an > "ASCII printable character" like others, instead it belongs to the > list of "The extended ASCII codes"[2]. A simple patch [3] adding '?' > simply would cause many "multichar" warnings when making, while using > HEX directly [4] for this item only will bring an 'inconsistency' into > of the overall definition of this enum, the last choice is to use Hex > representation for all [5]. It can be safe and better for future new > IDs if any; however I know it looks bringing a potential impact to all aarch64 'buddies'. > > Thanks for any advice. > > I don't want to add below option in makefiles to suppress warnings as > it might be helpful to detect real typos in future. > -Wno-multichar > Do not warn if a multicharacter constant (''FOOF'') is used. Usually > they indicate a typo in the user's code, as they have > implementation-defined values, and should not be used in portable code. > > [1] https://static.docs.arm.com/ddi0487/da/DDI0487D_a_armv8_arm.pdf, > page 5945. > [2] https://www.ascii-code.com/ > [3] http://cr.openjdk.java.net/~qpzhang/cpu_ampere/patch01.diff, use '?' > [4] http://cr.openjdk.java.net/~qpzhang/cpu_ampere/patch02.diff, use > 0xC0 [5] http://cr.openjdk.java.net/~qpzhang/cpu_ampere/patch03.diff, > use Hex representation for all > > FYI. > > Hex representation ISO8859-1 representation Implementer > 0x0 NUL Reserved for software use > 0xc0 ? Ampere Computing > 0x41 A ARM Limited > 0x42 B Broadcom Corporation > 0x43 C Cavium Inc. > 0x44 D Digital Equipment Corporation > 0x49 I Infineon Technologies AG > 0x4D M Motorola or Freescale Semiconductor Inc. > 0x4E N NVIDIA Corporation > 0x50 P Applied Micro Circuits Corporation > 0x51 Q Qualcomm Inc. > 0x56 V Marvell International Ltd. > 0x69 i Intel Corporation > > Regards > Patrick From patrick at os.amperecomputing.com Fri Apr 19 07:02:39 2019 From: patrick at os.amperecomputing.com (Patrick Zhang OS) Date: Fri, 19 Apr 2019 07:02:39 +0000 Subject: Update enum Family CPU_Xxx for aarch64 from ISO8859-1 (ASCII) representation to HEX In-Reply-To: References: Message-ID: Please review http://cr.openjdk.java.net/~qpzhang/8222753/webrev.01, thanks. JBS: https://bugs.openjdk.java.net/browse/JDK-8222753 As there is no 'functionality' change I only tested 'make all' on my eMag aarch64 dev system, everything is fine. Regards Patrick -----Original Message----- From: hotspot-dev On Behalf Of Patrick Zhang OS Sent: Friday, April 19, 2019 1:56 PM To: Yangfei (Felix) ; aarch64-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: RE: Update enum Family CPU_Xxx for aarch64 from ISO8859-1 (ASCII) representation to HEX Yes the character displays well in console but messy code in browsers. I would add some comment nearby to describe where the implementer codes come from. Regards Patrick -----Original Message----- From: Yangfei (Felix) Sent: Friday, April 19, 2019 11:14 AM To: Patrick Zhang OS ; aarch64-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: Update enum Family CPU_Xxx for aarch64 from ISO8859-1 (ASCII) representation to HEX Patch02 looks better. But it's meaningless to keep the charater "'?'" in the comment. Thanks, Felix > > Hi > > Here is a quick question about a change upon the "enum Family" defined > in hotspot/cpu/aarch64/vm_version_aarch64.hpp. > > I want to add CPU_AMPERE (0xC0) into the enum; however it is not an > "ASCII printable character" like others, instead it belongs to the > list of "The extended ASCII codes"[2]. A simple patch [3] adding '?' > simply would cause many "multichar" warnings when making, while using > HEX directly [4] for this item only will bring an 'inconsistency' into > of the overall definition of this enum, the last choice is to use Hex > representation for all [5]. It can be safe and better for future new > IDs if any; however I know it looks bringing a potential impact to all aarch64 'buddies'. > > Thanks for any advice. > > I don't want to add below option in makefiles to suppress warnings as > it might be helpful to detect real typos in future. > -Wno-multichar > Do not warn if a multicharacter constant (''FOOF'') is used. Usually > they indicate a typo in the user's code, as they have > implementation-defined values, and should not be used in portable code. > > [1] https://static.docs.arm.com/ddi0487/da/DDI0487D_a_armv8_arm.pdf, > page 5945. > [2] https://www.ascii-code.com/ > [3] http://cr.openjdk.java.net/~qpzhang/cpu_ampere/patch01.diff, use '?' > [4] http://cr.openjdk.java.net/~qpzhang/cpu_ampere/patch02.diff, use > 0xC0 [5] http://cr.openjdk.java.net/~qpzhang/cpu_ampere/patch03.diff, > use Hex representation for all > > FYI. > > Hex representation ISO8859-1 representation Implementer > 0x0 NUL Reserved for software use > 0xc0 ? Ampere Computing > 0x41 A ARM Limited > 0x42 B Broadcom Corporation > 0x43 C Cavium Inc. > 0x44 D Digital Equipment Corporation > 0x49 I Infineon Technologies AG > 0x4D M Motorola or Freescale Semiconductor Inc. > 0x4E N NVIDIA Corporation > 0x50 P Applied Micro Circuits Corporation > 0x51 Q Qualcomm Inc. > 0x56 V Marvell International Ltd. > 0x69 i Intel Corporation > > Regards > Patrick From aph at redhat.com Fri Apr 19 08:26:21 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 19 Apr 2019 09:26:21 +0100 Subject: Update enum Family CPU_Xxx for aarch64 from ISO8859-1 (ASCII) representation to HEX In-Reply-To: References: Message-ID: On 4/19/19 8:02 AM, Patrick Zhang OS wrote: > JBS: https://bugs.openjdk.java.net/browse/JDK-8222753 > As there is no 'functionality' change I only tested 'make all' on my eMag aarch64 dev system, everything is fine. OK. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From lois.foltan at oracle.com Fri Apr 19 18:51:51 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 19 Apr 2019 14:51:51 -0400 Subject: RFR(M) JDK-8218994: Consolidate indy and condy JVM information within a BootstrapInfo data structure In-Reply-To: <0E517D1E-B22B-4BA5-8D19-48ABEA464B01@oracle.com> References: <6cdcd602-1543-e19e-718e-3a6c0784c2c1@oracle.com> <49dcdd7a-8d40-f9d1-4334-880f635477ea@oracle.com> <22291755-2b3d-01dc-135f-04eb95aef612@oracle.com> <0E517D1E-B22B-4BA5-8D19-48ABEA464B01@oracle.com> Message-ID: <1a483fdd-03be-6c3e-928f-9af5abe3e3a3@oracle.com> Hi Karen, Thank you so much for the thorough review!? I have addressed all your comments, see responses interspersed below. New updated webrev: http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.3/webrev/ Thanks, Lois On 4/16/2019 6:06 PM, Karen Kinnear wrote: > Lois, > > Looks really good. > > A couple minor questions/comments - mostly about comments > I did not find any bugs - so I don?t need to see an updated webrev. > Pick-and-choose any suggestions you like/don?t like. > > 1. resolve_metadata > Any chance this could be renamed to something more specific? e.g. > resolve_bss_name_and_type? Done. > > 2. bootstrapInfo: > Why is there a field _is_method_call ? Couldn?t this be > is_method_call() which gets the same > info from indy_index <0 vs. >= 0? Or is there a timing reason you need > both? Removed field BootstrapInfo::_is_method_call.? Method BootstrapInfo::is_method_call() just checks the _indy_index.? There was no timing issue that warranted this field. > > 3. resolve_bsm. > Nice to have a comment for the first line - since bootstrapInfo is a > StackObj, this should only > happen if the same thread has more than 1 indy/condy with the same > bsm, right? Not quite.? A BootstrapInfo data structure is constructed for every indy and every condy.? It is never the case that they are shared between multiple indys who use the same bsm or for that case multiple condys that use the same bsm.? The first line just simply protects against resolve_bsm being called more than once for the same BootstrapInfo.? That should never occur, I guess the first line could be an assert but I am going to leave as is for now. > > 4. bootstrapInfo > Handle _arg_values // array of static args; null for unresolved > > Could you please clarify what null means? > Do you mean _arg_values is a handle to null if there are no static args? > Or do you mean that elements in the array are null if unresolved? The > former? Yeah, that's confusing.? If BootstrapInfo::_arg_values is null that implies either the static args have not been resolved or there are no static args, _agrc == 0.? I have updated the comment. > > 5. constantPool.cpp > old line 927 > // FIXME: Cache this once per BootstrapMethods entry, not once per > CONSTANT_Dynamic > -- did I read this correctly? That the resulting bootstrap_specifier > is still caching the result per bss_index, where bss is either > CONSTANT_Dynamic or CONSTANT_InvokeDynamic Correct.? The "FIXME" comment was removed because I don't think we ever intend to cache this once per BootstrapMethods entry. > > 6. Trivial > How do you feel about asserts with no text message? See > bootstrapInfo.cpp lines 55/56 > I didn't check for others Fixed, checked others too. > > 7. where is has_bootstrap defined? utilities/constantTag.hpp > > 8. constantPool.cpp > Did I read this correctly that JVMS 5.4.3.6 Steps 1 and 2 are both > performed > under invoke_bootstrap_method? ? Could you possibly clarify that in > the comments 913-923? Yes, steps 1 & 2 are done under invoke_bootstrap_method.? I have improved the comment to state that both the first and second tasks of JVMS section 5.4.3.6 occur within invoke_bootstrap_method(). > > 9. bootstrapInfo.cpp > resolve_args: > if (!use_BSCI) > I am confused about _arg_values setting: > ? 1) looks like you set _arg_values = Handle(THREAD< arg_oop) > ? and then overwrite with _arg_values = Handle(THREAD, args()) in some > cases > ? 2) if args is already objArrayHandle, why do you handleize again? Great catch.? That's not right, the code has been changed: ?if (!use_BSCI) { ??? // return {arg...}; resolution of arguments is done immediately, before JDK code is called ??? objArrayOop args_oop = oopFactory::new_objArray(SystemDictionary::Object_klass(), _argc, CHECK); ??? objArrayHandle args(THREAD, args_oop); ??? _pool->copy_bootstrap_arguments_at(_bss_index, 0, _argc, args, 0, true, Handle(), CHECK); ??? oop arg_oop = ((_argc == 1) ? args->obj_at(0) : (oop)NULL); ??? // try to discard the singleton array ??? if (arg_oop != NULL && !arg_oop->is_array()) { ????? // JVM treats arrays and nulls specially in this position, ????? // but other things are just single arguments ????? _arg_values = Handle(THREAD, arg_oop); ??? } else { ????? _arg_values = args; ??? } ? } else { > > 10. bootstrapInfo.cpp > resolve_previously_linked_invokedynamic > I know the include states what true/false mean. It would be helpful to > duplicate the comment > from the include at the start of the method. > > 11. linkResolver.cpp line 1727: > "relevent" -> "relevant" Fixed. > > 12. linkResolver.cpp > line 1740 - what does DTRT mean? - is that "Does The Right Thing"? > could you be more specific? Removed DTRT, improved the comment. > > 13. name resolve_newly_linked_invokedynamic is confusing. Is it worth > having this as a separate method? This is just a set_handle call, with > a small assertion. If you want to keep it, could you possibly rename it? > the bootstrap_specifier is already resolved, and the assertion belongs > to the success path after invoke_bootstrap_method I presume. > If others feel strongly, ignore my comment. I'm going to leave it for now.? This will be revisited on the next iteration of changes for BootstrapInfo. > > thanks, > Karen > >> On Apr 15, 2019, at 3:09 PM, Lois Foltan > > wrote: >> >> Updated webrev to fix typos caught by John's review of the .1 webrev >> >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.2/webrev/ >> >> Thanks, >> Lois >> >> On 4/12/2019 8:17 AM, Lois Foltan wrote: >>> I've updated the webrev based on preliminary feedback from Coleen. >>> >>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.1/webrev/ >>> >>> Reviews appreciated! >>> Lois >>> >>> On 3/14/2019 7:39 AM, Lois Foltan wrote: >>>> Please review this change to consolidate indy and condy JVM >>>> information to invoke a bootstrap method into a new BootstrapInfo >>>> data structure as well as merge the condy and indy methods to >>>> invoke the bootstrap within SystemDictionary. >>>> >>>> open webrev at: >>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.0/webrev/ >>>> bug link: https://bugs.openjdk.java.net/browse/JDK-8218994 >>>> co-contributors: Lois Foltan & John Rose >>>> >>>> Testing: hs-tier1-3 & jdk-tier1-3 (all platforms), hs-tier4-8 >>>> (linux only), JCK vm & lang >>>> >>>> Thanks, >>>> Lois >>> >> > From vladimir.x.ivanov at oracle.com Fri Apr 19 23:19:23 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 19 Apr 2019 16:19:23 -0700 Subject: RFC: Recuperate slowdown of long-running static initialization Message-ID: <6c94c636-92e7-190a-421e-b68819cd2c3b@oracle.com> Hi, Recent changes severely affected how static intializers are executed and for long-running initializers it manifested as a severe slowdown. As an example, it manifests as 3x slowdown for some Clojure applications (JDK-8219233 [1]). The root cause is that until a class is fully initialized, every invocation of static method on it goes through method resolution. There were some changes (JDK-8219974 [2]) to partially recuperate the slowdown, but they had limited effect. I have been experimenting with a comprehensive fix and ended up with the following: http://cr.openjdk.java.net/~vlivanov/8219233/webrev.02/ (Unfortunately, I had to go with platform-specific changes and the patch contains only x86_64 part. On other platforms original behavior is preserved.) The idea is to put initialization barrier on entry into static methods. If wrong thread enters it, the thread is blocked until class initialization is finished (and exception is thrown if initialization finishes with an error). 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 } Performance experiments demonstrated that even through generated code contributes the most overhead, interpreter overhead is visible as well (~20%). (1) original (always reresolve): ~12,0s ( 1x) (2) C1/C2 - barriers; int - reresolve: ~3,8s (~3x) (3) int/C1/C2 - barriers: ~3,2s (-20%) Based on that, I decided to implement barriers both in JIT-compilers (C1/C2) & interpreter. For C1/C2 I made a decision to put the barrier at callee side (in nmethod prologue). Though it looks attractive to put it on caller side (before the call), it poses major implementation challenges for C1 where unresolved calls are eagerly compiled. For interpreter, on the other hand, it's much simpler to implement the barrier: throwing an exception on method entry is much more complicated than doing that as part of method resolution during the call. So, here's the 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: from interpreter: covered by interpreter barrier from compiled: current patch doesn't cover Graal and AOT, so call site patching is disabled for them leading to repeated call site resolution until method holder is fully initialized. I'd like to hear opinions about the patch and decisions I made before publishing it for review. For example, is it worth to change template interpreter? The change itself is small and localized, and performance improvement is noticeable, but still it resides in platform-specific code. Regarding the implementation of barriers in generated code, nmethod entry barriers (introduced by 8210498 [3]) look like a perfect fit (and I even experimented with them), but I decided to leave it aside for now: mainly to ease backports (8210498 was introduced in 12), but also to ease support on other platforms (as of now, nmethod entry barriers are supported solely on x86_64). As a followup work, the implementations can be unified in 13/12u. Entry barriers support in Graal/AOT is left for future work as well. Once the support is there, call site patching restrictions should be relaxed. Thanks! Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8219233 [2] https://bugs.openjdk.java.net/browse/JDK-8219974 [3] https://bugs.openjdk.java.net/browse/JDK-8210498 From karen.kinnear at oracle.com Mon Apr 22 15:05:50 2019 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 22 Apr 2019 11:05:50 -0400 Subject: RFR(M) JDK-8218994: Consolidate indy and condy JVM information within a BootstrapInfo data structure In-Reply-To: <1a483fdd-03be-6c3e-928f-9af5abe3e3a3@oracle.com> References: <6cdcd602-1543-e19e-718e-3a6c0784c2c1@oracle.com> <49dcdd7a-8d40-f9d1-4334-880f635477ea@oracle.com> <22291755-2b3d-01dc-135f-04eb95aef612@oracle.com> <0E517D1E-B22B-4BA5-8D19-48ABEA464B01@oracle.com> <1a483fdd-03be-6c3e-928f-9af5abe3e3a3@oracle.com> Message-ID: Looks good to go! thanks, Karen > On Apr 19, 2019, at 2:51 PM, Lois Foltan wrote: > > Hi Karen, > > Thank you so much for the thorough review! I have addressed all your comments, see responses interspersed below. > > New updated webrev: http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.3/webrev/ > > Thanks, > Lois > >> >> 3. resolve_bsm. >> Nice to have a comment for the first line - since bootstrapInfo is a StackObj, this should only >> happen if the same thread has more than 1 indy/condy with the same bsm, right? > Not quite. A BootstrapInfo data structure is constructed for every indy and every condy. It is never the case that they are shared between multiple indys who use the same bsm or for that case multiple condys that use the same bsm. The first line just simply protects against resolve_bsm being called more than once for the same BootstrapInfo. That should never occur, I guess the first line could be an assert but I am going to leave as is for now. You are right - I had confused myself. > >> >> 4. bootstrapInfo >> Handle _arg_values // array of static args; null for unresolved >> >> Could you please clarify what null means? >> Do you mean _arg_values is a handle to null if there are no static args? >> Or do you mean that elements in the array are null if unresolved? The former? > Yeah, that's confusing. If BootstrapInfo::_arg_values is null that implies either the static args have not been resolved or there are no static args, _agrc == 0. I have updated the comment. Thank you for clarifying that combining this with args tells the difference. > > >> >> 8. constantPool.cpp >> Did I read this correctly that JVMS 5.4.3.6 Steps 1 and 2 are both performed >> under invoke_bootstrap_method? Could you possibly clarify that in the comments 913-923? > Yes, steps 1 & 2 are done under invoke_bootstrap_method. I have improved the comment to state that both the first and second tasks of JVMS section 5.4.3.6 occur within invoke_bootstrap_method(). Nice! > >> >> 9. bootstrapInfo.cpp >> resolve_args: >> if (!use_BSCI) >> I am confused about _arg_values setting: >> 1) looks like you set _arg_values = Handle(THREAD< arg_oop) >> and then overwrite with _arg_values = Handle(THREAD, args()) in some cases >> 2) if args is already objArrayHandle, why do you handleize again? > Great catch. That's not right, the code has been changed: > > if (!use_BSCI) { > // return {arg...}; resolution of arguments is done immediately, before JDK code is called > objArrayOop args_oop = oopFactory::new_objArray(SystemDictionary::Object_klass(), _argc, CHECK); > objArrayHandle args(THREAD, args_oop); > _pool->copy_bootstrap_arguments_at(_bss_index, 0, _argc, args, 0, true, Handle(), CHECK); > oop arg_oop = ((_argc == 1) ? args->obj_at(0) : (oop)NULL); > // try to discard the singleton array > if (arg_oop != NULL && !arg_oop->is_array()) { > // JVM treats arrays and nulls specially in this position, > // but other things are just single arguments > _arg_values = Handle(THREAD, arg_oop); > } else { > _arg_values = args; > } > } else { Looks good. > >> >> 10. bootstrapInfo.cpp >> resolve_previously_linked_invokedynamic >> I know the include states what true/false mean. It would be helpful to duplicate the comment >> from the include at the start of the method. Thank you. >> >> 12. linkResolver.cpp >> line 1740 - what does DTRT mean? - is that "Does The Right Thing"? >> could you be more specific? > Removed DTRT, improved the comment. Thank you - that is very helpful. >> > >> >> thanks, >> Karen >> >>> On Apr 15, 2019, at 3:09 PM, Lois Foltan > wrote: >>> >>> Updated webrev to fix typos caught by John's review of the .1 webrev >>> >>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.2/webrev/ >>> >>> Thanks, >>> Lois >>> >>> On 4/12/2019 8:17 AM, Lois Foltan wrote: >>>> I've updated the webrev based on preliminary feedback from Coleen. >>>> >>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.1/webrev/ >>>> >>>> Reviews appreciated! >>>> Lois >>>> >>>> On 3/14/2019 7:39 AM, Lois Foltan wrote: >>>>> Please review this change to consolidate indy and condy JVM information to invoke a bootstrap method into a new BootstrapInfo data structure as well as merge the condy and indy methods to invoke the bootstrap within SystemDictionary. >>>>> >>>>> open webrev at: http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.0/webrev/ >>>>> bug link: https://bugs.openjdk.java.net/browse/JDK-8218994 >>>>> co-contributors: Lois Foltan & John Rose >>>>> >>>>> Testing: hs-tier1-3 & jdk-tier1-3 (all platforms), hs-tier4-8 (linux only), JCK vm & lang >>>>> >>>>> Thanks, >>>>> Lois >>>> >>> >> > From lois.foltan at oracle.com Mon Apr 22 15:23:40 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 22 Apr 2019 11:23:40 -0400 Subject: RFR(M) JDK-8218994: Consolidate indy and condy JVM information within a BootstrapInfo data structure In-Reply-To: References: <6cdcd602-1543-e19e-718e-3a6c0784c2c1@oracle.com> <49dcdd7a-8d40-f9d1-4334-880f635477ea@oracle.com> <22291755-2b3d-01dc-135f-04eb95aef612@oracle.com> <0E517D1E-B22B-4BA5-8D19-48ABEA464B01@oracle.com> <1a483fdd-03be-6c3e-928f-9af5abe3e3a3@oracle.com> Message-ID: On 4/22/2019 11:05 AM, Karen Kinnear wrote: > Looks good to go! Great!? Thank you again for the review. Lois > > thanks, > Karen > >> On Apr 19, 2019, at 2:51 PM, Lois Foltan > > wrote: >> >> Hi Karen, >> >> Thank you so much for the thorough review!? I have addressed all your >> comments, see responses interspersed below. >> >> New updated webrev: >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.3/webrev/ >> >> Thanks, >> Lois >> >>> >>> 3. resolve_bsm. >>> Nice to have a comment for the first line - since bootstrapInfo is a >>> StackObj, this should only >>> happen if the same thread has more than 1 indy/condy with the same >>> bsm, right? >> Not quite.? A BootstrapInfo data structure is constructed for every >> indy and every condy.? It is never the case that they are shared >> between multiple indys who use the same bsm or for that case multiple >> condys that use the same bsm.? The first line just simply protects >> against resolve_bsm being called more than once for the same >> BootstrapInfo.? That should never occur, I guess the first line could >> be an assert but I am going to leave as is for now. > You are right - I had confused myself. >> >>> >>> 4. bootstrapInfo >>> Handle _arg_values // array of static args; null for unresolved >>> >>> Could you please clarify what null means? >>> Do you mean _arg_values is a handle to null if there are no static args? >>> Or do you mean that elements in the array are null if unresolved? >>> The former? >> Yeah, that's confusing.? If BootstrapInfo::_arg_values is null that >> implies either the static args have not been resolved or there are no >> static args, _agrc == 0. I have updated the comment. > Thank you for clarifying that combining this with args tells the > difference. >> >> >>> >>> 8. constantPool.cpp >>> Did I read this correctly that JVMS 5.4.3.6 Steps 1 and 2 are both >>> performed >>> under invoke_bootstrap_method? ? Could you possibly clarify that in >>> the comments 913-923? >> Yes, steps 1 & 2 are done under invoke_bootstrap_method.? I have >> improved the comment to state that both the first and second tasks of >> JVMS section 5.4.3.6 occur within invoke_bootstrap_method(). > Nice! >> >>> >>> 9. bootstrapInfo.cpp >>> resolve_args: >>> if (!use_BSCI) >>> I am confused about _arg_values setting: >>> ? 1) looks like you set _arg_values = Handle(THREAD< arg_oop) >>> ? and then overwrite with _arg_values = Handle(THREAD, args()) in >>> some cases >>> ? 2) if args is already objArrayHandle, why do you handleize again? >> Great catch.? That's not right, the code has been changed: >> >> ?if (!use_BSCI) { >> ??? // return {arg...}; resolution of arguments is done immediately, >> before JDK code is called >> ??? objArrayOop args_oop = >> oopFactory::new_objArray(SystemDictionary::Object_klass(), _argc, CHECK); >> ??? objArrayHandle args(THREAD, args_oop); >> ??? _pool->copy_bootstrap_arguments_at(_bss_index, 0, _argc, args, 0, >> true, Handle(), CHECK); >> ??? oop arg_oop = ((_argc == 1) ? args->obj_at(0) : (oop)NULL); >> ??? // try to discard the singleton array >> ??? if (arg_oop != NULL && !arg_oop->is_array()) { >> ????? // JVM treats arrays and nulls specially in this position, >> ????? // but other things are just single arguments >> ????? _arg_values = Handle(THREAD, arg_oop); >> ??? } else { >> ????? _arg_values = args; >> ??? } >> ? } else { > Looks good. >> >>> >>> 10. bootstrapInfo.cpp >>> resolve_previously_linked_invokedynamic >>> I know the include states what true/false mean. It would be helpful >>> to duplicate the comment >>> from the include at the start of the method. > Thank you. >>> >>> 12. linkResolver.cpp >>> line 1740 - what does DTRT mean? - is that "Does The Right Thing"? >>> could you be more specific? >> Removed DTRT, improved the comment. > Thank you - that is very helpful. >>> >> >>> >>> thanks, >>> Karen >>> >>>> On Apr 15, 2019, at 3:09 PM, Lois Foltan >>> > wrote: >>>> >>>> Updated webrev to fix typos caught by John's review of the .1 webrev >>>> >>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.2/webrev/ >>>> >>>> Thanks, >>>> Lois >>>> >>>> On 4/12/2019 8:17 AM, Lois Foltan wrote: >>>>> I've updated the webrev based on preliminary feedback from Coleen. >>>>> >>>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.1/webrev/ >>>>> >>>>> Reviews appreciated! >>>>> Lois >>>>> >>>>> On 3/14/2019 7:39 AM, Lois Foltan wrote: >>>>>> Please review this change to consolidate indy and condy JVM >>>>>> information to invoke a bootstrap method into a new BootstrapInfo >>>>>> data structure as well as merge the condy and indy methods to >>>>>> invoke the bootstrap within SystemDictionary. >>>>>> >>>>>> open webrev at: >>>>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.0/webrev/ >>>>>> bug link: https://bugs.openjdk.java.net/browse/JDK-8218994 >>>>>> co-contributors: Lois Foltan & John Rose >>>>>> >>>>>> Testing: hs-tier1-3 & jdk-tier1-3 (all platforms), hs-tier4-8 >>>>>> (linux only), JCK vm & lang >>>>>> >>>>>> Thanks, >>>>>> Lois >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Mon Apr 22 18:30:06 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 22 Apr 2019 14:30:06 -0400 Subject: RFR(M) JDK-8218994: Consolidate indy and condy JVM information within a BootstrapInfo data structure In-Reply-To: <1a483fdd-03be-6c3e-928f-9af5abe3e3a3@oracle.com> References: <6cdcd602-1543-e19e-718e-3a6c0784c2c1@oracle.com> <49dcdd7a-8d40-f9d1-4334-880f635477ea@oracle.com> <22291755-2b3d-01dc-135f-04eb95aef612@oracle.com> <0E517D1E-B22B-4BA5-8D19-48ABEA464B01@oracle.com> <1a483fdd-03be-6c3e-928f-9af5abe3e3a3@oracle.com> Message-ID: So, this is less of a thorough review: http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.3/webrev/src/hotspot/share/interpreter/linkResolver.hpp.frames.htmlhttp://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.3/webrev/src/hotspot/share/classfile/systemDictionary.hpp.frames.html Can these just have forward declaration of BootstrapInfo here rather than including bootstrapinfo.hpp ? http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.3/webrev/src/hotspot/share/interpreter/linkResolver.cpp.frames.html Really tiny nit, not really worth mentioning but can you remove the space in: 1708 if (is_done) return; 1763 if (is_done) return; http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.3/webrev/src/hotspot/share/oops/constantPool.cpp.frames.html 956 if (TraceMethodHandles) { 957 bootstrap_specifier.print_msg_on(tty, "resolve_constant_at_impl"); 958 } Please can you convert these to UL next ?? :) This change looks good to me. Coleen On 4/19/19 2:51 PM, Lois Foltan wrote: > Hi Karen, > > Thank you so much for the thorough review!? I have addressed all your > comments, see responses interspersed below. > > New updated webrev: > http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.3/webrev/ > > Thanks, > Lois > > On 4/16/2019 6:06 PM, Karen Kinnear wrote: >> Lois, >> >> Looks really good. >> >> A couple minor questions/comments - mostly about comments >> I did not find any bugs - so I don?t need to see an updated webrev. >> Pick-and-choose any suggestions you like/don?t like. >> >> 1. resolve_metadata >> Any chance this could be renamed to something more specific? e.g. >> resolve_bss_name_and_type? > Done. > >> >> 2. bootstrapInfo: >> Why is there a field _is_method_call ? Couldn?t this be >> is_method_call() which gets the same >> info from indy_index <0 vs. >= 0? Or is there a timing reason you >> need both? > Removed field BootstrapInfo::_is_method_call.? Method > BootstrapInfo::is_method_call() just checks the _indy_index. There was > no timing issue that warranted this field. > >> >> 3. resolve_bsm. >> Nice to have a comment for the first line - since bootstrapInfo is a >> StackObj, this should only >> happen if the same thread has more than 1 indy/condy with the same >> bsm, right? > Not quite.? A BootstrapInfo data structure is constructed for every > indy and every condy.? It is never the case that they are shared > between multiple indys who use the same bsm or for that case multiple > condys that use the same bsm.? The first line just simply protects > against resolve_bsm being called more than once for the same > BootstrapInfo.? That should never occur, I guess the first line could > be an assert but I am going to leave as is for now. > >> >> 4. bootstrapInfo >> Handle _arg_values // array of static args; null for unresolved >> >> Could you please clarify what null means? >> Do you mean _arg_values is a handle to null if there are no static args? >> Or do you mean that elements in the array are null if unresolved? The >> former? > Yeah, that's confusing.? If BootstrapInfo::_arg_values is null that > implies either the static args have not been resolved or there are no > static args, _agrc == 0.? I have updated the comment. > >> >> 5. constantPool.cpp >> old line 927 >> // FIXME: Cache this once per BootstrapMethods entry, not once per >> CONSTANT_Dynamic >> -- did I read this correctly? That the resulting bootstrap_specifier >> is still caching the result per bss_index, where bss is either >> CONSTANT_Dynamic or CONSTANT_InvokeDynamic > Correct.? The "FIXME" comment was removed because I don't think we > ever intend to cache this once per BootstrapMethods entry. > >> >> 6. Trivial >> How do you feel about asserts with no text message? See >> bootstrapInfo.cpp lines 55/56 >> I didn't check for others > Fixed, checked others too. > >> >> 7. where is has_bootstrap defined? > utilities/constantTag.hpp > >> >> 8. constantPool.cpp >> Did I read this correctly that JVMS 5.4.3.6 Steps 1 and 2 are both >> performed >> under invoke_bootstrap_method? ? Could you possibly clarify that in >> the comments 913-923? > Yes, steps 1 & 2 are done under invoke_bootstrap_method.? I have > improved the comment to state that both the first and second tasks of > JVMS section 5.4.3.6 occur within invoke_bootstrap_method(). > >> >> 9. bootstrapInfo.cpp >> resolve_args: >> if (!use_BSCI) >> I am confused about _arg_values setting: >> ? 1) looks like you set _arg_values = Handle(THREAD< arg_oop) >> ? and then overwrite with _arg_values = Handle(THREAD, args()) in >> some cases >> ? 2) if args is already objArrayHandle, why do you handleize again? > Great catch.? That's not right, the code has been changed: > > ?if (!use_BSCI) { > ??? // return {arg...}; resolution of arguments is done immediately, > before JDK code is called > ??? objArrayOop args_oop = > oopFactory::new_objArray(SystemDictionary::Object_klass(), _argc, CHECK); > ??? objArrayHandle args(THREAD, args_oop); > ??? _pool->copy_bootstrap_arguments_at(_bss_index, 0, _argc, args, 0, > true, Handle(), CHECK); > ??? oop arg_oop = ((_argc == 1) ? args->obj_at(0) : (oop)NULL); > ??? // try to discard the singleton array > ??? if (arg_oop != NULL && !arg_oop->is_array()) { > ????? // JVM treats arrays and nulls specially in this position, > ????? // but other things are just single arguments > ????? _arg_values = Handle(THREAD, arg_oop); > ??? } else { > ????? _arg_values = args; > ??? } > ? } else { > >> >> 10. bootstrapInfo.cpp >> resolve_previously_linked_invokedynamic >> I know the include states what true/false mean. It would be helpful >> to duplicate the comment >> from the include at the start of the method. >> >> 11. linkResolver.cpp line 1727: >> "relevent" -> "relevant" > Fixed. > >> >> 12. linkResolver.cpp >> line 1740 - what does DTRT mean? - is that "Does The Right Thing"? >> could you be more specific? > Removed DTRT, improved the comment. > >> >> 13. name resolve_newly_linked_invokedynamic is confusing. Is it worth >> having this as a separate method? This is just a set_handle call, with >> a small assertion. If you want to keep it, could you possibly rename it? >> the bootstrap_specifier is already resolved, and the assertion belongs >> to the success path after invoke_bootstrap_method I presume. >> If others feel strongly, ignore my comment. > I'm going to leave it for now.? This will be revisited on the next > iteration of changes for BootstrapInfo. > >> >> thanks, >> Karen >> >>> On Apr 15, 2019, at 3:09 PM, Lois Foltan >> > wrote: >>> >>> Updated webrev to fix typos caught by John's review of the .1 webrev >>> >>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.2/webrev/ >>> >>> Thanks, >>> Lois >>> >>> On 4/12/2019 8:17 AM, Lois Foltan wrote: >>>> I've updated the webrev based on preliminary feedback from Coleen. >>>> >>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.1/webrev/ >>>> >>>> Reviews appreciated! >>>> Lois >>>> >>>> On 3/14/2019 7:39 AM, Lois Foltan wrote: >>>>> Please review this change to consolidate indy and condy JVM >>>>> information to invoke a bootstrap method into a new BootstrapInfo >>>>> data structure as well as merge the condy and indy methods to >>>>> invoke the bootstrap within SystemDictionary. >>>>> >>>>> open webrev at: >>>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.0/webrev/ >>>>> bug link: https://bugs.openjdk.java.net/browse/JDK-8218994 >>>>> co-contributors: Lois Foltan & John Rose >>>>> >>>>> Testing: hs-tier1-3 & jdk-tier1-3 (all platforms), hs-tier4-8 >>>>> (linux only), JCK vm & lang >>>>> >>>>> Thanks, >>>>> Lois >>>> >>> >> > From lois.foltan at oracle.com Mon Apr 22 19:26:36 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 22 Apr 2019 15:26:36 -0400 Subject: RFR(M) JDK-8218994: Consolidate indy and condy JVM information within a BootstrapInfo data structure In-Reply-To: References: <6cdcd602-1543-e19e-718e-3a6c0784c2c1@oracle.com> <49dcdd7a-8d40-f9d1-4334-880f635477ea@oracle.com> <22291755-2b3d-01dc-135f-04eb95aef612@oracle.com> <0E517D1E-B22B-4BA5-8D19-48ABEA464B01@oracle.com> <1a483fdd-03be-6c3e-928f-9af5abe3e3a3@oracle.com> Message-ID: Thanks Coleen!? All items have been addressed.? If you would like another webrev iteration let me know. Lois On 4/22/2019 2:30 PM, coleen.phillimore at oracle.com wrote: > > So, this is less of a thorough review: > > http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.3/webrev/src/hotspot/share/interpreter/linkResolver.hpp.frames.htmlhttp://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.3/webrev/src/hotspot/share/classfile/systemDictionary.hpp.frames.html > > > Can these just have forward declaration of BootstrapInfo here rather > than including bootstrapinfo.hpp ? Yes, fixed. > > http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.3/webrev/src/hotspot/share/interpreter/linkResolver.cpp.frames.html > > > Really tiny nit, not really worth mentioning but can you remove the > space in: > > 1708 if (is_done) return; > > 1763 if (is_done) return; Fixed. > > > http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.3/webrev/src/hotspot/share/oops/constantPool.cpp.frames.html > > > 956 if (TraceMethodHandles) { > 957 bootstrap_specifier.print_msg_on(tty, "resolve_constant_at_impl"); > 958 } > > Please can you convert these to UL next ?? :) Yes, there is an outstanding RFE for this, see https://bugs.openjdk.java.net/browse/JDK-8210012 > > This change looks good to me. > > Coleen > > On 4/19/19 2:51 PM, Lois Foltan wrote: >> Hi Karen, >> >> Thank you so much for the thorough review!? I have addressed all your >> comments, see responses interspersed below. >> >> New updated webrev: >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.3/webrev/ >> >> Thanks, >> Lois >> >> On 4/16/2019 6:06 PM, Karen Kinnear wrote: >>> Lois, >>> >>> Looks really good. >>> >>> A couple minor questions/comments - mostly about comments >>> I did not find any bugs - so I don?t need to see an updated webrev. >>> Pick-and-choose any suggestions you like/don?t like. >>> >>> 1. resolve_metadata >>> Any chance this could be renamed to something more specific? e.g. >>> resolve_bss_name_and_type? >> Done. >> >>> >>> 2. bootstrapInfo: >>> Why is there a field _is_method_call ? Couldn?t this be >>> is_method_call() which gets the same >>> info from indy_index <0 vs. >= 0? Or is there a timing reason you >>> need both? >> Removed field BootstrapInfo::_is_method_call.? Method >> BootstrapInfo::is_method_call() just checks the _indy_index. There >> was no timing issue that warranted this field. >> >>> >>> 3. resolve_bsm. >>> Nice to have a comment for the first line - since bootstrapInfo is a >>> StackObj, this should only >>> happen if the same thread has more than 1 indy/condy with the same >>> bsm, right? >> Not quite.? A BootstrapInfo data structure is constructed for every >> indy and every condy.? It is never the case that they are shared >> between multiple indys who use the same bsm or for that case multiple >> condys that use the same bsm.? The first line just simply protects >> against resolve_bsm being called more than once for the same >> BootstrapInfo.? That should never occur, I guess the first line could >> be an assert but I am going to leave as is for now. >> >>> >>> 4. bootstrapInfo >>> Handle _arg_values // array of static args; null for unresolved >>> >>> Could you please clarify what null means? >>> Do you mean _arg_values is a handle to null if there are no static >>> args? >>> Or do you mean that elements in the array are null if unresolved? >>> The former? >> Yeah, that's confusing.? If BootstrapInfo::_arg_values is null that >> implies either the static args have not been resolved or there are no >> static args, _agrc == 0.? I have updated the comment. >> >>> >>> 5. constantPool.cpp >>> old line 927 >>> // FIXME: Cache this once per BootstrapMethods entry, not once per >>> CONSTANT_Dynamic >>> -- did I read this correctly? That the resulting bootstrap_specifier >>> is still caching the result per bss_index, where bss is either >>> CONSTANT_Dynamic or CONSTANT_InvokeDynamic >> Correct.? The "FIXME" comment was removed because I don't think we >> ever intend to cache this once per BootstrapMethods entry. >> >>> >>> 6. Trivial >>> How do you feel about asserts with no text message? See >>> bootstrapInfo.cpp lines 55/56 >>> I didn't check for others >> Fixed, checked others too. >> >>> >>> 7. where is has_bootstrap defined? >> utilities/constantTag.hpp >> >>> >>> 8. constantPool.cpp >>> Did I read this correctly that JVMS 5.4.3.6 Steps 1 and 2 are both >>> performed >>> under invoke_bootstrap_method? ? Could you possibly clarify that in >>> the comments 913-923? >> Yes, steps 1 & 2 are done under invoke_bootstrap_method.? I have >> improved the comment to state that both the first and second tasks of >> JVMS section 5.4.3.6 occur within invoke_bootstrap_method(). >> >>> >>> 9. bootstrapInfo.cpp >>> resolve_args: >>> if (!use_BSCI) >>> I am confused about _arg_values setting: >>> ? 1) looks like you set _arg_values = Handle(THREAD< arg_oop) >>> ? and then overwrite with _arg_values = Handle(THREAD, args()) in >>> some cases >>> ? 2) if args is already objArrayHandle, why do you handleize again? >> Great catch.? That's not right, the code has been changed: >> >> ?if (!use_BSCI) { >> ??? // return {arg...}; resolution of arguments is done immediately, >> before JDK code is called >> ??? objArrayOop args_oop = >> oopFactory::new_objArray(SystemDictionary::Object_klass(), _argc, >> CHECK); >> ??? objArrayHandle args(THREAD, args_oop); >> ??? _pool->copy_bootstrap_arguments_at(_bss_index, 0, _argc, args, 0, >> true, Handle(), CHECK); >> ??? oop arg_oop = ((_argc == 1) ? args->obj_at(0) : (oop)NULL); >> ??? // try to discard the singleton array >> ??? if (arg_oop != NULL && !arg_oop->is_array()) { >> ????? // JVM treats arrays and nulls specially in this position, >> ????? // but other things are just single arguments >> ????? _arg_values = Handle(THREAD, arg_oop); >> ??? } else { >> ????? _arg_values = args; >> ??? } >> ? } else { >> >>> >>> 10. bootstrapInfo.cpp >>> resolve_previously_linked_invokedynamic >>> I know the include states what true/false mean. It would be helpful >>> to duplicate the comment >>> from the include at the start of the method. >>> >>> 11. linkResolver.cpp line 1727: >>> "relevent" -> "relevant" >> Fixed. >> >>> >>> 12. linkResolver.cpp >>> line 1740 - what does DTRT mean? - is that "Does The Right Thing"? >>> could you be more specific? >> Removed DTRT, improved the comment. >> >>> >>> 13. name resolve_newly_linked_invokedynamic is confusing. Is it worth >>> having this as a separate method? This is just a set_handle call, with >>> a small assertion. If you want to keep it, could you possibly rename >>> it? >>> the bootstrap_specifier is already resolved, and the assertion belongs >>> to the success path after invoke_bootstrap_method I presume. >>> If others feel strongly, ignore my comment. >> I'm going to leave it for now.? This will be revisited on the next >> iteration of changes for BootstrapInfo. >> >>> >>> thanks, >>> Karen >>> >>>> On Apr 15, 2019, at 3:09 PM, Lois Foltan >>> > wrote: >>>> >>>> Updated webrev to fix typos caught by John's review of the .1 webrev >>>> >>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.2/webrev/ >>>> >>>> Thanks, >>>> Lois >>>> >>>> On 4/12/2019 8:17 AM, Lois Foltan wrote: >>>>> I've updated the webrev based on preliminary feedback from Coleen. >>>>> >>>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.1/webrev/ >>>>> >>>>> Reviews appreciated! >>>>> Lois >>>>> >>>>> On 3/14/2019 7:39 AM, Lois Foltan wrote: >>>>>> Please review this change to consolidate indy and condy JVM >>>>>> information to invoke a bootstrap method into a new BootstrapInfo >>>>>> data structure as well as merge the condy and indy methods to >>>>>> invoke the bootstrap within SystemDictionary. >>>>>> >>>>>> open webrev at: >>>>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8218994.0/webrev/ >>>>>> bug link: https://bugs.openjdk.java.net/browse/JDK-8218994 >>>>>> co-contributors: Lois Foltan & John Rose >>>>>> >>>>>> Testing: hs-tier1-3 & jdk-tier1-3 (all platforms), hs-tier4-8 >>>>>> (linux only), JCK vm & lang >>>>>> >>>>>> Thanks, >>>>>> Lois >>>>> >>>> >>> >> > From alexey.menkov at oracle.com Mon Apr 22 22:23:00 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 22 Apr 2019 15:23:00 -0700 Subject: RFR (L) 8213501 : Deploy ExceptionJniWrapper for a few tests In-Reply-To: <1E4DDEF4-BCBC-473B-AE09-7A945643756F@amazon.com> References: <72bf2f4a-5bf7-98de-5f00-68485072923d@oracle.com> <25a50bc3-222c-a915-5517-37a2f9375c42@oracle.com> <1E4DDEF4-BCBC-473B-AE09-7A945643756F@amazon.com> Message-ID: <93fe6d7b-f216-bbc2-a6cc-703f832592b9@oracle.com> +1 --alex On 04/18/2019 08:10, Hohensee, Paul wrote: > Looks good. Apologies for the response delay. > > Paul > > *From: *Jean Christophe Beyler > *Date: *Monday, April 15, 2019 at 7:32 AM > *To: *"Hohensee, Paul" > *Cc: *Alex Menkov , hotspot-dev Source > Developers > *Subject: *Re: RFR (L) 8213501 : Deploy ExceptionJniWrapper for a few tests > > Hi all, > > Ping for a final LGTM? :) > > Jc > > On Wed, Apr 10, 2019 at 8:18 PM Jean Christophe Beyler > > wrote: > > Hi Paul, > > Exactly :). Actually you are right, when trying to figure out build > errors in windows/solaris, I moved declarations around. > > I've moved them back and the incremental is thus: > > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.06_08/ > > And the full new version is: > > http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.08/ > > This has passed the submit repo (thanks serguei ;-)). > > Could I get another LGTM for this and then we can move forward ? :) > > Thanks for your help, > > Jc > From erik.osterlund at oracle.com Tue Apr 23 08:41:09 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 23 Apr 2019 10:41:09 +0200 Subject: RFR: 8222841: Incorrect static call stub interactions with class unloading Message-ID: <067fc16e-3104-4e61-b558-9cd4864f079f@oracle.com> 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 shade at redhat.com Tue Apr 23 09:49:24 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 23 Apr 2019 11:49:24 +0200 Subject: [11u] RFR 8219974: REDO JDK-8219492: Restore static callsite resolution for the current class In-Reply-To: <369bf309-c547-f59c-608b-17b872638602@redhat.com> References: <369bf309-c547-f59c-608b-17b872638602@redhat.com> Message-ID: On 4/16/19 6:05 PM, Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8219974 > > Original fix; > http://hg.openjdk.java.net/jdk/jdk/rev/77343f5c85cb > > Patch applies almost cleanly, but the code in 11u misses the rename to "*_unsafe_anonymous*" [1], > which means we need to use the older variant of it. > > 11u webrev: > http://cr.openjdk.java.net/~shade/8219974/webrev.11u.01/ > > Testing: clj -A:user timings (a bit better), tier1 (friendly reminder) -Aleksey From david.holmes at oracle.com Tue Apr 23 10:03:44 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Apr 2019 20:03:44 +1000 Subject: [11u] RFR 8219974: REDO JDK-8219492: Restore static callsite resolution for the current class In-Reply-To: References: <369bf309-c547-f59c-608b-17b872638602@redhat.com> Message-ID: Hi Aleksey, That looks exactly how I would have done it. ;-) Thanks, David On 23/04/2019 7:49 pm, Aleksey Shipilev wrote: > On 4/16/19 6:05 PM, Aleksey Shipilev wrote: >> Original bug: >> https://bugs.openjdk.java.net/browse/JDK-8219974 >> >> Original fix; >> http://hg.openjdk.java.net/jdk/jdk/rev/77343f5c85cb >> >> Patch applies almost cleanly, but the code in 11u misses the rename to "*_unsafe_anonymous*" [1], >> which means we need to use the older variant of it. >> >> 11u webrev: >> http://cr.openjdk.java.net/~shade/8219974/webrev.11u.01/ >> >> Testing: clj -A:user timings (a bit better), tier1 > > (friendly reminder) > > -Aleksey > From coleen.phillimore at oracle.com Tue Apr 23 15:06:33 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 23 Apr 2019 11:06:33 -0400 Subject: RFR (L, tedious) 8222811: Consolidate MutexLockerEx and MutexLocker Message-ID: <614f0e46-c4ce-d389-88f9-1a73e14fc5dd@oracle.com> Summary: Make MutexLocker be MutexLockerEx implementation, remove MutexLockerEx calls.? Also added wait_without_safepoint_check(). Also made safepoint_check_flag an enum, renamed MonitorLockerEx to MonitorLocker, removed MutexUnlockerEx, and fixed formatting where affected by this change. There's a MutexLocker constructor with a Thread parameter that would actually be more performant if the thread is passed from the current context rather than calling Thread::current() in Monitor::lock.? I think the Thread parameter should be moved to first so that we can have MutexLocker look like the Handle constructor calls, for example.? I didn't make this change in this. ?? MutexLocker ml(THREAD, Monitor_lock). The interesting changes are in: http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutexLocker.hpp.udiff.html http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.hpp.udiff.html http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.cpp.udiff.html The rest is pattern substitution. Ran mach5 tier1-6 tests. open webrev at http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8222811 Thanks! Coleen From shade at redhat.com Tue Apr 23 15:58:46 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 23 Apr 2019 17:58:46 +0200 Subject: [11u] RFR 8219974: REDO JDK-8219492: Restore static callsite resolution for the current class In-Reply-To: References: <369bf309-c547-f59c-608b-17b872638602@redhat.com> Message-ID: On 4/23/19 12:03 PM, David Holmes wrote: > That looks exactly how I would have done it. ;-) Thanks! The 11u backport is now in queue. -Aleksey From daniel.smith at oracle.com Tue Apr 23 21:08:07 2019 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 23 Apr 2019 15:08:07 -0600 Subject: 2019 JVM Language Summit Message-ID: 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 coleen.phillimore at oracle.com Tue Apr 23 21:32:49 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 23 Apr 2019 17:32:49 -0400 Subject: RFR: 8222841: Incorrect static call stub interactions with class unloading In-Reply-To: <067fc16e-3104-4e61-b558-9cd4864f079f@oracle.com> References: <067fc16e-3104-4e61-b558-9cd4864f079f@oracle.com> Message-ID: <1ca35306-6be8-61ec-127f-196367d94899@oracle.com> 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? 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. 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. 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 daniel.daugherty at oracle.com Tue Apr 23 21:43:14 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 23 Apr 2019 17:43:14 -0400 Subject: RFR (L, tedious) 8222811: Consolidate MutexLockerEx and MutexLocker In-Reply-To: <614f0e46-c4ce-d389-88f9-1a73e14fc5dd@oracle.com> References: <614f0e46-c4ce-d389-88f9-1a73e14fc5dd@oracle.com> Message-ID: <3aab6fa3-04e3-47e2-ea34-b4c0b997e44f@oracle.com> On 4/23/19 11:06 AM, coleen.phillimore at oracle.com wrote: > Summary: Make MutexLocker be MutexLockerEx implementation, remove > MutexLockerEx calls.? Also added wait_without_safepoint_check(). > > Also made safepoint_check_flag an enum, renamed MonitorLockerEx to > MonitorLocker, removed MutexUnlockerEx, and fixed formatting where > affected by this change. > > There's a MutexLocker constructor with a Thread parameter that would > actually be more performant if the thread is passed from the current > context rather than calling Thread::current() in Monitor::lock.? I > think the Thread parameter should be moved to first so that we can > have MutexLocker look like the Handle constructor calls, for example.? > I didn't make this change in this. > > ?? MutexLocker ml(THREAD, Monitor_lock). > > The interesting changes are in: > > http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutexLocker.hpp.udiff.html > > http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.hpp.udiff.html > > http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.cpp.udiff.html > > > The rest is pattern substitution. > > Ran mach5 tier1-6 tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev src/hotspot/share/runtime/mutexLocker.hpp ??? L198: ????? assert(_mutex->rank() > Mutex::special || no_safepoint_check, ??? L199: ??????? "Mutexes with rank special or lower should not do safepoint checks"); ??????? nit - indent on L199 needs 5 more spaces ??? L200-203 - this if-block is missing the usual HotSpot '{' and '}'. ??? (Not your fault, but since you're in there...) ??? L211: ????? assert(_mutex->rank() > Mutex::special || no_safepoint_check, ??? L212: ??????? "Mutexes with rank special or lower should not do safepoint checks"); ??????? nit - indent on L211 needs 5 more spaces ??? L213-216 - this if-block is missing the usual HotSpot '{' and '}'. ??? (Not your fault, but since you're in there...) src/hotspot/share/runtime/mutex.hpp ??? L237: ?? // why do these need bodies? ??????? To prevent any calls to Mutex::notify(), Mutex::notify_all(), ??????? Mutex::wait() and Mutex::wait_without_safepoint_check() from ??????? calling the superclass' version of those functions. src/hotspot/share/runtime/mutex.cpp ??? Nice detangling into Monitor::wait() and ??? Monitor::wait_without_safepoint_check(). For the rest of the files, I went through the patch from bottom -> top and looked for anything that didn't look right. I figure other reviewers are looking from top -> bottom... :-) For the multi-line MutexLocker uses in src/hotspot/share/runtime/vmThread.cpp and src/hotspot/share/memory/metaspace.cpp, the second line indents appear to be off by two spaces (because "Ex" was removed). Don't know if you want to fix those or not. Your call. src/hotspot/share/runtime/threadSMR.cpp ? - ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, 0, ? - !Mutex::_as_suspend_equivalent_flag); ? + ThreadsSMRSupport::delete_lock()->wait_without_safepoint_check(); ? You dropped the '!Mutex::_as_suspend_equivalent_flag' flag. I dislike ? default values so that's why I included it. Now the reader has to ? ? 1) remember that there's another parameter ? ? 2) go find the default value for that parameter src/hotspot/share/gc/shared/workgroup.cpp ? This change does not parse: ?? ? ? // The VM thread should not execute here because MutexLocker's are used ? ? -? // as (opposed to MutexLockerEx's). ? ? +? // as (opposed to MutexLocker's). ? since MutexLocker is now on both sides of the verbal comparison. In some cases, there were multi-line MutexLocker uses that you chose to combine into a single line, but in most cases you did not combine them. I couldn't discern a rhyme or reason for the choices (not even a line length of 80). There is a startling number of names in use for the MutexLocker variables. My personal preference would be for 'ml' (and 'ul' for the MutexUnlocker). You have an opportunity to make them all consistent, but that's hard to do. Thumbs up! If you choose to handle and of my comments above, I don't need to see another webrev. Dan > bug link https://bugs.openjdk.java.net/browse/JDK-8222811 > > Thanks! > Coleen > > From coleen.phillimore at oracle.com Tue Apr 23 22:18:33 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 23 Apr 2019 18:18:33 -0400 Subject: RFR (L, tedious) 8222811: Consolidate MutexLockerEx and MutexLocker In-Reply-To: <3aab6fa3-04e3-47e2-ea34-b4c0b997e44f@oracle.com> References: <614f0e46-c4ce-d389-88f9-1a73e14fc5dd@oracle.com> <3aab6fa3-04e3-47e2-ea34-b4c0b997e44f@oracle.com> Message-ID: Hi Dan, Thank you for tackling this code review.? I was hoping you wouldn't do your usual file-by-file comments.? It would have been long. On 4/23/19 5:43 PM, Daniel D. Daugherty wrote: > On 4/23/19 11:06 AM, coleen.phillimore at oracle.com wrote: >> Summary: Make MutexLocker be MutexLockerEx implementation, remove >> MutexLockerEx calls.? Also added wait_without_safepoint_check(). >> >> Also made safepoint_check_flag an enum, renamed MonitorLockerEx to >> MonitorLocker, removed MutexUnlockerEx, and fixed formatting where >> affected by this change. >> >> There's a MutexLocker constructor with a Thread parameter that would >> actually be more performant if the thread is passed from the current >> context rather than calling Thread::current() in Monitor::lock.? I >> think the Thread parameter should be moved to first so that we can >> have MutexLocker look like the Handle constructor calls, for >> example.? I didn't make this change in this. >> >> ?? MutexLocker ml(THREAD, Monitor_lock). >> >> The interesting changes are in: >> >> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutexLocker.hpp.udiff.html >> >> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.hpp.udiff.html >> >> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.cpp.udiff.html >> >> >> The rest is pattern substitution. >> >> Ran mach5 tier1-6 tests. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev > > src/hotspot/share/runtime/mutexLocker.hpp > ??? L198: ????? assert(_mutex->rank() > Mutex::special || > no_safepoint_check, > ??? L199: ??????? "Mutexes with rank special or lower should not do > safepoint checks"); > ??????? nit - indent on L199 needs 5 more spaces > > ??? L200-203 - this if-block is missing the usual HotSpot '{' and '}'. > ??? (Not your fault, but since you're in there...) > > ??? L211: ????? assert(_mutex->rank() > Mutex::special || > no_safepoint_check, > ??? L212: ??????? "Mutexes with rank special or lower should not do > safepoint checks"); > ??????? nit - indent on L211 needs 5 more spaces > > ??? L213-216 - this if-block is missing the usual HotSpot '{' and '}'. > ??? (Not your fault, but since you're in there...) Fixed all of these.? Since I've touched it, I made it follow the coding style. > > src/hotspot/share/runtime/mutex.hpp > ??? L237: ?? // why do these need bodies? > ??????? To prevent any calls to Mutex::notify(), Mutex::notify_all(), > ??????? Mutex::wait() and Mutex::wait_without_safepoint_check() from > ??????? calling the superclass' version of those functions. > I forgot to check this, but if they're private, they shouldn't need bodies.? I'll remove the comment and leave them for now. > src/hotspot/share/runtime/mutex.cpp > ??? Nice detangling into Monitor::wait() and > ??? Monitor::wait_without_safepoint_check(). > Thank you! > > For the rest of the files, I went through the patch from bottom -> top > and looked for anything that didn't look right. I figure other reviewers > are looking from top -> bottom... :-) > > For the multi-line MutexLocker uses in > src/hotspot/share/runtime/vmThread.cpp > and src/hotspot/share/memory/metaspace.cpp, > the second line indents appear to be off by two spaces (because "Ex" > was removed). > Don't know if you want to fix those or not. Your call. You have good eyes.? I checked all of these this morning and I missed these files.? Thank you. > > src/hotspot/share/runtime/threadSMR.cpp > > ? - > ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, > 0, > ? - !Mutex::_as_suspend_equivalent_flag); > ? + ThreadsSMRSupport::delete_lock()->wait_without_safepoint_check(); > > ? You dropped the '!Mutex::_as_suspend_equivalent_flag' flag. I dislike > ? default values so that's why I included it. Now the reader has to > ? ? 1) remember that there's another parameter > ? ? 2) go find the default value for that parameter wait_without_safepoint_check() doesn't have as_suspend_equivalent flag as a parameter.? That code was only used in the safepoint checking case for wait.?? I dislike default parameters too for the same reasons.? Both waits take 0 as the timeout default parameter but I thought that was not a good thing to change. > > src/hotspot/share/gc/shared/workgroup.cpp > ? This change does not parse: > > ?? ? ? // The VM thread should not execute here because MutexLocker's > are used > ? ? -? // as (opposed to MutexLockerEx's). > ? ? +? // as (opposed to MutexLocker's). > > ? since MutexLocker is now on both sides of the verbal comparison. Yeah, I missed that too.? It doesn't actually make sense before either, since there isn't a MutexLocker nearby. > > In some cases, there were multi-line MutexLocker uses that you chose > to combine into a single line, but in most cases you did not combine > them. I couldn't discern a rhyme or reason for the choices (not even > a line length of 80). I combined them if the length wasn't "too long" and it didn't look like the whitespace was helpful.? I did both. > > There is a startling number of names in use for the MutexLocker > variables. My personal preference would be for 'ml' (and 'ul' > for the MutexUnlocker). You have an opportunity to make them all > consistent, but that's hard to do. By convention, ml is used a lot but sometimes you can't use it.? I don't want to change this.? Sometimes people pick names they like for this. > > Thumbs up! If you choose to handle and of my comments above, > I don't need to see another webrev. Thank you Dan for reviewing this!? I'll retest with edits made for comments above. Coleen > > Dan > >> bug link https://bugs.openjdk.java.net/browse/JDK-8222811 >> >> Thanks! >> Coleen >> >> > From coleen.phillimore at oracle.com Tue Apr 23 22:49:19 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 23 Apr 2019 18:49:19 -0400 Subject: RFR (L, tedious) 8222811: Consolidate MutexLockerEx and MutexLocker In-Reply-To: References: <614f0e46-c4ce-d389-88f9-1a73e14fc5dd@oracle.com> <3aab6fa3-04e3-47e2-ea34-b4c0b997e44f@oracle.com> Message-ID: <302fcf8c-35f6-d5a3-2128-a949150583bf@oracle.com> Here's a new webrev with the changes requested by Dan. http://cr.openjdk.java.net/~coleenp/2019/8222811.02/webrev Thanks, Coleen On 4/23/19 6:18 PM, coleen.phillimore at oracle.com wrote: > > Hi Dan, Thank you for tackling this code review.? I was hoping you > wouldn't do your usual file-by-file comments.? It would have been long. > > On 4/23/19 5:43 PM, Daniel D. Daugherty wrote: >> On 4/23/19 11:06 AM, coleen.phillimore at oracle.com wrote: >>> Summary: Make MutexLocker be MutexLockerEx implementation, remove >>> MutexLockerEx calls. Also added wait_without_safepoint_check(). >>> >>> Also made safepoint_check_flag an enum, renamed MonitorLockerEx to >>> MonitorLocker, removed MutexUnlockerEx, and fixed formatting where >>> affected by this change. >>> >>> There's a MutexLocker constructor with a Thread parameter that would >>> actually be more performant if the thread is passed from the current >>> context rather than calling Thread::current() in Monitor::lock.? I >>> think the Thread parameter should be moved to first so that we can >>> have MutexLocker look like the Handle constructor calls, for >>> example.? I didn't make this change in this. >>> >>> ?? MutexLocker ml(THREAD, Monitor_lock). >>> >>> The interesting changes are in: >>> >>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutexLocker.hpp.udiff.html >>> >>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.hpp.udiff.html >>> >>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.cpp.udiff.html >>> >>> >>> The rest is pattern substitution. >>> >>> Ran mach5 tier1-6 tests. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev >> >> src/hotspot/share/runtime/mutexLocker.hpp >> ??? L198: ????? assert(_mutex->rank() > Mutex::special || >> no_safepoint_check, >> ??? L199: ??????? "Mutexes with rank special or lower should not do >> safepoint checks"); >> ??????? nit - indent on L199 needs 5 more spaces >> >> ??? L200-203 - this if-block is missing the usual HotSpot '{' and '}'. >> ??? (Not your fault, but since you're in there...) >> >> ??? L211: ????? assert(_mutex->rank() > Mutex::special || >> no_safepoint_check, >> ??? L212: ??????? "Mutexes with rank special or lower should not do >> safepoint checks"); >> ??????? nit - indent on L211 needs 5 more spaces >> >> ??? L213-216 - this if-block is missing the usual HotSpot '{' and '}'. >> ??? (Not your fault, but since you're in there...) > > Fixed all of these.? Since I've touched it, I made it follow the > coding style. > >> >> src/hotspot/share/runtime/mutex.hpp >> ??? L237: ?? // why do these need bodies? >> ??????? To prevent any calls to Mutex::notify(), Mutex::notify_all(), >> ??????? Mutex::wait() and Mutex::wait_without_safepoint_check() from >> ??????? calling the superclass' version of those functions. >> > > I forgot to check this, but if they're private, they shouldn't need > bodies.? I'll remove the comment and leave them for now. > > >> src/hotspot/share/runtime/mutex.cpp >> ??? Nice detangling into Monitor::wait() and >> ??? Monitor::wait_without_safepoint_check(). >> > Thank you! > >> >> For the rest of the files, I went through the patch from bottom -> top >> and looked for anything that didn't look right. I figure other reviewers >> are looking from top -> bottom... :-) >> >> For the multi-line MutexLocker uses in >> src/hotspot/share/runtime/vmThread.cpp >> and src/hotspot/share/memory/metaspace.cpp, >> the second line indents appear to be off by two spaces (because "Ex" >> was removed). >> Don't know if you want to fix those or not. Your call. > > You have good eyes.? I checked all of these this morning and I missed > these files.? Thank you. >> >> src/hotspot/share/runtime/threadSMR.cpp >> >> ? - >> ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, >> 0, >> ? - !Mutex::_as_suspend_equivalent_flag); >> ? + ThreadsSMRSupport::delete_lock()->wait_without_safepoint_check(); >> >> ? You dropped the '!Mutex::_as_suspend_equivalent_flag' flag. I dislike >> ? default values so that's why I included it. Now the reader has to >> ? ? 1) remember that there's another parameter >> ? ? 2) go find the default value for that parameter > > wait_without_safepoint_check() doesn't have as_suspend_equivalent flag > as a parameter.? That code was only used in the safepoint checking > case for wait.?? I dislike default parameters too for the same > reasons.? Both waits take 0 as the timeout default parameter but I > thought that was not a good thing to change. > >> >> src/hotspot/share/gc/shared/workgroup.cpp >> ? This change does not parse: >> >> ?? ? ? // The VM thread should not execute here because MutexLocker's >> are used >> ? ? -? // as (opposed to MutexLockerEx's). >> ? ? +? // as (opposed to MutexLocker's). >> >> ? since MutexLocker is now on both sides of the verbal comparison. > Yeah, I missed that too.? It doesn't actually make sense before > either, since there isn't a MutexLocker nearby. > >> >> In some cases, there were multi-line MutexLocker uses that you chose >> to combine into a single line, but in most cases you did not combine >> them. I couldn't discern a rhyme or reason for the choices (not even >> a line length of 80). > > I combined them if the length wasn't "too long" and it didn't look > like the whitespace was helpful.? I did both. >> >> There is a startling number of names in use for the MutexLocker >> variables. My personal preference would be for 'ml' (and 'ul' >> for the MutexUnlocker). You have an opportunity to make them all >> consistent, but that's hard to do. > > By convention, ml is used a lot but sometimes you can't use it.? I > don't want to change this.? Sometimes people pick names they like for > this. >> >> Thumbs up! If you choose to handle and of my comments above, >> I don't need to see another webrev. > > Thank you Dan for reviewing this!? I'll retest with edits made for > comments above. > > Coleen > >> >> Dan >> >>> bug link https://bugs.openjdk.java.net/browse/JDK-8222811 >>> >>> Thanks! >>> Coleen >>> >>> >> > From david.holmes at oracle.com Wed Apr 24 01:48:49 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Apr 2019 11:48:49 +1000 Subject: RFR (L, tedious) 8222811: Consolidate MutexLockerEx and MutexLocker In-Reply-To: <302fcf8c-35f6-d5a3-2128-a949150583bf@oracle.com> References: <614f0e46-c4ce-d389-88f9-1a73e14fc5dd@oracle.com> <3aab6fa3-04e3-47e2-ea34-b4c0b997e44f@oracle.com> <302fcf8c-35f6-d5a3-2128-a949150583bf@oracle.com> Message-ID: Hi Coleen, On 24/04/2019 8:49 am, coleen.phillimore at oracle.com wrote: > > Here's a new webrev with the changes requested by Dan. > > http://cr.openjdk.java.net/~coleenp/2019/8222811.02/webrev Overall this seems fine. A few comments on the main changes: mutex.cpp 156 bool Monitor::wait_without_safepoint_check(long timeout) { 157 // Make sure safepoint checking is used properly. 158 assert(_safepoint_check_required != Monitor::_safepoint_check_always, 159 "This lock should never have a safepoint check: %s", name()); The message is the wrong one: s/never/always/ wait_without_safepoint_check is missing: // timeout is in milliseconds - with zero meaning never timeout assert(timeout >= 0, "negative timeout"); --- mutexLocker.hpp 190 protected: 191 Monitor* _mutex; Good catch on the redundant extra field in MonitorLocker! 208 MutexLocker(Monitor* mutex, Thread* thread, Mutex::SafepointCheckFlag flag = Mutex::_safepoint_check_flag) : 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. Thanks, David > Thanks, > Coleen > > On 4/23/19 6:18 PM, coleen.phillimore at oracle.com wrote: >> >> Hi Dan, Thank you for tackling this code review.? I was hoping you >> wouldn't do your usual file-by-file comments.? It would have been long. >> >> On 4/23/19 5:43 PM, Daniel D. Daugherty wrote: >>> On 4/23/19 11:06 AM, coleen.phillimore at oracle.com wrote: >>>> Summary: Make MutexLocker be MutexLockerEx implementation, remove >>>> MutexLockerEx calls. Also added wait_without_safepoint_check(). >>>> >>>> Also made safepoint_check_flag an enum, renamed MonitorLockerEx to >>>> MonitorLocker, removed MutexUnlockerEx, and fixed formatting where >>>> affected by this change. >>>> >>>> There's a MutexLocker constructor with a Thread parameter that would >>>> actually be more performant if the thread is passed from the current >>>> context rather than calling Thread::current() in Monitor::lock.? I >>>> think the Thread parameter should be moved to first so that we can >>>> have MutexLocker look like the Handle constructor calls, for >>>> example.? I didn't make this change in this. >>>> >>>> ?? MutexLocker ml(THREAD, Monitor_lock). >>>> >>>> The interesting changes are in: >>>> >>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutexLocker.hpp.udiff.html >>>> >>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.hpp.udiff.html >>>> >>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.cpp.udiff.html >>>> >>>> >>>> The rest is pattern substitution. >>>> >>>> Ran mach5 tier1-6 tests. >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev >>> >>> src/hotspot/share/runtime/mutexLocker.hpp >>> ??? L198: ????? assert(_mutex->rank() > Mutex::special || >>> no_safepoint_check, >>> ??? L199: ??????? "Mutexes with rank special or lower should not do >>> safepoint checks"); >>> ??????? nit - indent on L199 needs 5 more spaces >>> >>> ??? L200-203 - this if-block is missing the usual HotSpot '{' and '}'. >>> ??? (Not your fault, but since you're in there...) >>> >>> ??? L211: ????? assert(_mutex->rank() > Mutex::special || >>> no_safepoint_check, >>> ??? L212: ??????? "Mutexes with rank special or lower should not do >>> safepoint checks"); >>> ??????? nit - indent on L211 needs 5 more spaces >>> >>> ??? L213-216 - this if-block is missing the usual HotSpot '{' and '}'. >>> ??? (Not your fault, but since you're in there...) >> >> Fixed all of these.? Since I've touched it, I made it follow the >> coding style. >> >>> >>> src/hotspot/share/runtime/mutex.hpp >>> ??? L237: ?? // why do these need bodies? >>> ??????? To prevent any calls to Mutex::notify(), Mutex::notify_all(), >>> ??????? Mutex::wait() and Mutex::wait_without_safepoint_check() from >>> ??????? calling the superclass' version of those functions. >>> >> >> I forgot to check this, but if they're private, they shouldn't need >> bodies.? I'll remove the comment and leave them for now. >> >> >>> src/hotspot/share/runtime/mutex.cpp >>> ??? Nice detangling into Monitor::wait() and >>> ??? Monitor::wait_without_safepoint_check(). >>> >> Thank you! >> >>> >>> For the rest of the files, I went through the patch from bottom -> top >>> and looked for anything that didn't look right. I figure other reviewers >>> are looking from top -> bottom... :-) >>> >>> For the multi-line MutexLocker uses in >>> src/hotspot/share/runtime/vmThread.cpp >>> and src/hotspot/share/memory/metaspace.cpp, >>> the second line indents appear to be off by two spaces (because "Ex" >>> was removed). >>> Don't know if you want to fix those or not. Your call. >> >> You have good eyes.? I checked all of these this morning and I missed >> these files.? Thank you. >>> >>> src/hotspot/share/runtime/threadSMR.cpp >>> >>> ? - >>> ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, >>> 0, >>> ? - !Mutex::_as_suspend_equivalent_flag); >>> ? + ThreadsSMRSupport::delete_lock()->wait_without_safepoint_check(); >>> >>> ? You dropped the '!Mutex::_as_suspend_equivalent_flag' flag. I dislike >>> ? default values so that's why I included it. Now the reader has to >>> ? ? 1) remember that there's another parameter >>> ? ? 2) go find the default value for that parameter >> >> wait_without_safepoint_check() doesn't have as_suspend_equivalent flag >> as a parameter.? That code was only used in the safepoint checking >> case for wait.?? I dislike default parameters too for the same >> reasons.? Both waits take 0 as the timeout default parameter but I >> thought that was not a good thing to change. >> >>> >>> src/hotspot/share/gc/shared/workgroup.cpp >>> ? This change does not parse: >>> >>> ?? ? ? // The VM thread should not execute here because MutexLocker's >>> are used >>> ? ? -? // as (opposed to MutexLockerEx's). >>> ? ? +? // as (opposed to MutexLocker's). >>> >>> ? since MutexLocker is now on both sides of the verbal comparison. >> Yeah, I missed that too.? It doesn't actually make sense before >> either, since there isn't a MutexLocker nearby. >> >>> >>> In some cases, there were multi-line MutexLocker uses that you chose >>> to combine into a single line, but in most cases you did not combine >>> them. I couldn't discern a rhyme or reason for the choices (not even >>> a line length of 80). >> >> I combined them if the length wasn't "too long" and it didn't look >> like the whitespace was helpful.? I did both. >>> >>> There is a startling number of names in use for the MutexLocker >>> variables. My personal preference would be for 'ml' (and 'ul' >>> for the MutexUnlocker). You have an opportunity to make them all >>> consistent, but that's hard to do. >> >> By convention, ml is used a lot but sometimes you can't use it.? I >> don't want to change this.? Sometimes people pick names they like for >> this. >>> >>> Thumbs up! If you choose to handle and of my comments above, >>> I don't need to see another webrev. >> >> Thank you Dan for reviewing this!? I'll retest with edits made for >> comments above. >> >> Coleen >> >>> >>> Dan >>> >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8222811 >>>> >>>> Thanks! >>>> Coleen >>>> >>>> >>> >> > From 1948638989 at qq.com Wed Apr 24 03:03:14 2019 From: 1948638989 at qq.com (=?gb18030?B?a2VsdGh1emFkeA==?=) Date: Wed, 24 Apr 2019 11:03:14 +0800 Subject: CEE optimization for C1 compiler was useless Message-ID: Hi, Conditional expression elimination replaces the common code pattern of a branch that loads one of two values by a conditional move instruction, but it seems produce the same native code with unoptimized version. Let's say I have this code snippet https://paste.ubuntu.com/p/FnQSBCsh4K/, then add -XX:CompileOnly=com.github.kelthuzadx::conditionalExpressionElimination -Xcmp -XX:TieredStopAtLevel=1 -XX:+DoCEE -XX:+PrintIR, -XX:+PrintLIRWithAssembly, here https://paste.ubuntu.com/p/ZRXxHrMG6N/ is the generated machine code and C1' internal IR representation, it is that eliminated conditional expressions in phase 2, but later traditional cmp-jmp combinations were generated as if CEE was useless. mov %eax,-0x9000(%rsp) push %rbp sub $0x30,%rsp cmp $0xa,%edx mov $0x0,%eax jle 0x000001819f0a103f mov $0x1,%eax add $0x30,%rsp pop %rbp mov 0x120(%r15),%r10 test %eax,(%r10) retq I disable this optimization by -XX:-DoCEE, it generated almost the same version with prior one :https://paste.ubuntu.com/p/7mPcVhDT6t/ Moreover, CEE can not apply to normal conditional assignment statement(https://paste.ubuntu.com/p/Zbg3WzRv5J/)?it only works on ternary expression(?:) Is this a bug?Or it intentionally generated cmp-jmp combinations rather than cmovcc/setcc instructions for some reason? From per.liden at oracle.com Wed Apr 24 07:57:08 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 24 Apr 2019 09:57:08 +0200 Subject: RFR (L, tedious) 8222811: Consolidate MutexLockerEx and MutexLocker In-Reply-To: <614f0e46-c4ce-d389-88f9-1a73e14fc5dd@oracle.com> References: <614f0e46-c4ce-d389-88f9-1a73e14fc5dd@oracle.com> Message-ID: <13c77938-c70a-8f6d-7b3e-f4fc01ae989a@oracle.com> Hi Coleen, I like this clean up. However, one thing that always bothered me is this pattern: MonitorLockerEx ml(&_monitor, Monitor::_no_safepoint_check_flag); ... ml.wait(Monitor::_no_safepoint_check_flag); And with your patch it becomes: MonitorLocker ml(&_monitor, Monitor::_no_safepoint_check_flag); ... ml.wait_without_safepoint_check(); Now, it seems a bit silly, and potentially error prone, to always have to say "don't safepoint check" twice. We already told the MonitorLocker what to do when it was constructed, so can't we just have this: MonitorLocker ml(&_monitor, Monitor::_no_safepoint_check_flag); ... ml.wait(); Where wait() does the right thing, i.e. use the flag we passed into the constructor. Since all of MonitorLocker will be inlined, a flag check in wait() would be constant folded, so there's no overhead to worry about here. Can we please have this? cheers, Per On 4/23/19 5:06 PM, coleen.phillimore at oracle.com wrote: > Summary: Make MutexLocker be MutexLockerEx implementation, remove > MutexLockerEx calls.? Also added wait_without_safepoint_check(). > > Also made safepoint_check_flag an enum, renamed MonitorLockerEx to > MonitorLocker, removed MutexUnlockerEx, and fixed formatting where > affected by this change. > > There's a MutexLocker constructor with a Thread parameter that would > actually be more performant if the thread is passed from the current > context rather than calling Thread::current() in Monitor::lock.? I think > the Thread parameter should be moved to first so that we can have > MutexLocker look like the Handle constructor calls, for example.? I > didn't make this change in this. > > ?? MutexLocker ml(THREAD, Monitor_lock). > > The interesting changes are in: > > http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutexLocker.hpp.udiff.html > > http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.hpp.udiff.html > > http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.cpp.udiff.html > > > The rest is pattern substitution. > > Ran mach5 tier1-6 tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8222811 > > Thanks! > Coleen > > From sgehwolf at redhat.com Wed Apr 24 08:13:32 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 24 Apr 2019 10:13:32 +0200 Subject: RFR: 8221639: [x32] expand_exec_shield_cs_limit workaround is undefined code after JDK-8199717 In-Reply-To: <6a9f74f3-a1de-fc2a-370b-c64055611fd9@oracle.com> References: <673a0cc6b25fcfdcb3f3c69f4dcfd06d346e271a.camel@redhat.com> <6a9f74f3-a1de-fc2a-370b-c64055611fd9@oracle.com> Message-ID: Hi David, On Fri, 2019-04-19 at 00:02 +1000, David Holmes wrote: > Hi Severin, > > I'll have to delve into this more deeply (but I'm on Easter break for > the next 4 days). I don't recall ever being aware of > "suppress_primordial_thread_resolution"! So any more thoughts about this? Thanks, Severin > David > > On 18/04/2019 11:41 pm, Severin Gehwolf wrote: > > Hi, > > > > Could I please get reviews for this Linux x32 fix? JDK-8199717 added a > > performance optimization to only capture the initial stack size when > > launched via non-java launchers. However, on Linux x32, there is old > > code being executed to work around the exec shield CS limit. That code > > depends on the initial stack size being captured. Right now this is > > undefined code: Pointer artithmetic on NULL pointer. > > > > src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp:884:73: runtime error: pointer index expression with base 0x00000000 overflowed to 0xffffb000 > > > > I propose to not perform the optimization of JDK-8199717 for Linux x32. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221639 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221639/01/webrev/ > > > > Testing: release/fastdebug builds on x32 Linux, inspecting > > -Xlog:os=info messages, currently running through jdkd/submit. Tier 1 > > tests on Linux x86_64 > > > > Thoughts? > > > > Thanks, > > Severin > > From glaubitz at physik.fu-berlin.de Wed Apr 24 08:24:08 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 24 Apr 2019 10:24:08 +0200 Subject: RFR: 8221639: [x32] expand_exec_shield_cs_limit workaround is undefined code after JDK-8199717 In-Reply-To: References: <673a0cc6b25fcfdcb3f3c69f4dcfd06d346e271a.camel@redhat.com> <6a9f74f3-a1de-fc2a-370b-c64055611fd9@oracle.com> Message-ID: <0D89E633-7B91-4934-882D-B16A183FE376@physik.fu-berlin.de> Hi Severin! > On Apr 24, 2019, at 10:13 AM, Severin Gehwolf wrote: > > Hi David, > >> On Fri, 2019-04-19 at 00:02 +1000, David Holmes wrote: >> Hi Severin, >> >> I'll have to delve into this more deeply (but I'm on Easter break for >> the next 4 days). I don't recall ever being aware of >> "suppress_primordial_thread_resolution"! > > So any more thoughts about this? I?ll be happy to test this later today. Adrian From david.holmes at oracle.com Wed Apr 24 09:13:25 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Apr 2019 19:13:25 +1000 Subject: RFR: 8221639: [x32] expand_exec_shield_cs_limit workaround is undefined code after JDK-8199717 In-Reply-To: <6a9f74f3-a1de-fc2a-370b-c64055611fd9@oracle.com> References: <673a0cc6b25fcfdcb3f3c69f4dcfd06d346e271a.camel@redhat.com> <6a9f74f3-a1de-fc2a-370b-c64055611fd9@oracle.com> Message-ID: <89ab6a7f-79a7-2556-29cb-5cc9289c8ae6@oracle.com> Hi Severin, Sorry for the delay, this slipped off my rader after the break. On 19/04/2019 12:02 am, David Holmes wrote: > Hi Severin, > > I'll have to delve into this more deeply (but I'm on Easter break for > the next 4 days). I don't recall ever being aware of > "suppress_primordial_thread_resolution"! Well I have a bad memory as I reviewed that particular optimisation. So, the exec_shield workaround requires knowing the process's primordial thread stack regardless of whether the JVM is loaded on it or not. So it assumes the initial_thread_stack has been determined, while we now avoid doing that unnecessarily. Okay the suggested fix is okay to achieve that - though alternatively it could be handled inside workaround_expand_exec_shield_cs_limit() via: // Need to ensure we've determined the process's initial stack to // perform the workaround if (suppress_primordial_thread_resolution) { Linux::capture_initial_stack(JavaThread::stack_size_at_create()); } I would like to see a comment like the above regardless of where you make the change. Thanks, David ------ > David > > On 18/04/2019 11:41 pm, Severin Gehwolf wrote: >> Hi, >> >> Could I please get reviews for this Linux x32 fix? JDK-8199717 added a >> performance optimization to only capture the initial stack size when >> launched via non-java launchers. However, on Linux x32, there is old >> code being executed to work around the exec shield CS limit. That code >> depends on the initial stack size being captured. Right now this is >> undefined code: Pointer artithmetic on NULL pointer. >> >> src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp:884:73: runtime error: >> pointer index expression with base 0x00000000 overflowed to 0xffffb000 >> >> I propose to not perform the optimization of JDK-8199717 for Linux x32. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8221639 >> webrev: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221639/01/webrev/ >> >> Testing: release/fastdebug builds on x32 Linux, inspecting >> -Xlog:os=info messages, currently running through jdkd/submit. Tier 1 >> tests on Linux x86_64 >> >> Thoughts? >> >> Thanks, >> Severin >> From coleen.phillimore at oracle.com Wed Apr 24 11:23:45 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 24 Apr 2019 07:23:45 -0400 Subject: RFR (L, tedious) 8222811: Consolidate MutexLockerEx and MutexLocker In-Reply-To: References: <614f0e46-c4ce-d389-88f9-1a73e14fc5dd@oracle.com> <3aab6fa3-04e3-47e2-ea34-b4c0b997e44f@oracle.com> <302fcf8c-35f6-d5a3-2128-a949150583bf@oracle.com> Message-ID: <4396d1dd-25f9-c5ec-4f95-d8f31a260345@oracle.com> On 4/23/19 9:48 PM, David Holmes wrote: > Hi Coleen, > > On 24/04/2019 8:49 am, coleen.phillimore at oracle.com wrote: >> >> Here's a new webrev with the changes requested by Dan. >> >> http://cr.openjdk.java.net/~coleenp/2019/8222811.02/webrev > > Overall this seems fine. A few comments on the main changes: > > mutex.cpp > > ?156 bool Monitor::wait_without_safepoint_check(long timeout) { > ?157?? // Make sure safepoint checking is used properly. > ?158?? assert(_safepoint_check_required != > Monitor::_safepoint_check_always, > ?159????????? "This lock should never have a safepoint check: %s", > name()); > > The message is the wrong one: s/never/always/ I had both of these messages reversed in wait*() functions wrt. never/always.? If a lock L has safepoint_check_required = always and locks or waits without safepoint check, the message is relative to the lock, not the erroneous call.? Inverse for never. Thanks for finding this. > > wait_without_safepoint_check is missing: > > ? // timeout is in milliseconds - with zero meaning never timeout > ? assert(timeout >= 0, "negative timeout"); > Fixed. > --- > > mutexLocker.hpp > > 190? protected: > 191?? Monitor* _mutex; > > Good catch on the redundant extra field in MonitorLocker! Thanks. > > 208?? MutexLocker(Monitor* mutex, Thread* thread, > Mutex::SafepointCheckFlag flag = Mutex::_safepoint_check_flag) : > > 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. I also want to have a patch (I think I said this), to make the Thread argument first.? I could try some more tricks to avoid this duplication when/if I do that.?? How does that sound? Thanks for reviewing! Coleen > > Thanks, > David > >> Thanks, >> Coleen >> >> On 4/23/19 6:18 PM, coleen.phillimore at oracle.com wrote: >>> >>> Hi Dan, Thank you for tackling this code review.? I was hoping you >>> wouldn't do your usual file-by-file comments.? It would have been long. >>> >>> On 4/23/19 5:43 PM, Daniel D. Daugherty wrote: >>>> On 4/23/19 11:06 AM, coleen.phillimore at oracle.com wrote: >>>>> Summary: Make MutexLocker be MutexLockerEx implementation, remove >>>>> MutexLockerEx calls. Also added wait_without_safepoint_check(). >>>>> >>>>> Also made safepoint_check_flag an enum, renamed MonitorLockerEx to >>>>> MonitorLocker, removed MutexUnlockerEx, and fixed formatting where >>>>> affected by this change. >>>>> >>>>> There's a MutexLocker constructor with a Thread parameter that >>>>> would actually be more performant if the thread is passed from the >>>>> current context rather than calling Thread::current() in >>>>> Monitor::lock.? I think the Thread parameter should be moved to >>>>> first so that we can have MutexLocker look like the Handle >>>>> constructor calls, for example.? I didn't make this change in this. >>>>> >>>>> ?? MutexLocker ml(THREAD, Monitor_lock). >>>>> >>>>> The interesting changes are in: >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutexLocker.hpp.udiff.html >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.hpp.udiff.html >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.cpp.udiff.html >>>>> >>>>> >>>>> The rest is pattern substitution. >>>>> >>>>> Ran mach5 tier1-6 tests. >>>>> >>>>> open webrev at >>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev >>>> >>>> src/hotspot/share/runtime/mutexLocker.hpp >>>> ??? L198: ????? assert(_mutex->rank() > Mutex::special || >>>> no_safepoint_check, >>>> ??? L199: ??????? "Mutexes with rank special or lower should not do >>>> safepoint checks"); >>>> ??????? nit - indent on L199 needs 5 more spaces >>>> >>>> ??? L200-203 - this if-block is missing the usual HotSpot '{' and '}'. >>>> ??? (Not your fault, but since you're in there...) >>>> >>>> ??? L211: ????? assert(_mutex->rank() > Mutex::special || >>>> no_safepoint_check, >>>> ??? L212: ??????? "Mutexes with rank special or lower should not do >>>> safepoint checks"); >>>> ??????? nit - indent on L211 needs 5 more spaces >>>> >>>> ??? L213-216 - this if-block is missing the usual HotSpot '{' and '}'. >>>> ??? (Not your fault, but since you're in there...) >>> >>> Fixed all of these.? Since I've touched it, I made it follow the >>> coding style. >>> >>>> >>>> src/hotspot/share/runtime/mutex.hpp >>>> ??? L237: ?? // why do these need bodies? >>>> ??????? To prevent any calls to Mutex::notify(), Mutex::notify_all(), >>>> ??????? Mutex::wait() and Mutex::wait_without_safepoint_check() from >>>> ??????? calling the superclass' version of those functions. >>>> >>> >>> I forgot to check this, but if they're private, they shouldn't need >>> bodies.? I'll remove the comment and leave them for now. >>> >>> >>>> src/hotspot/share/runtime/mutex.cpp >>>> ??? Nice detangling into Monitor::wait() and >>>> ??? Monitor::wait_without_safepoint_check(). >>>> >>> Thank you! >>> >>>> >>>> For the rest of the files, I went through the patch from bottom -> top >>>> and looked for anything that didn't look right. I figure other >>>> reviewers >>>> are looking from top -> bottom... :-) >>>> >>>> For the multi-line MutexLocker uses in >>>> src/hotspot/share/runtime/vmThread.cpp >>>> and src/hotspot/share/memory/metaspace.cpp, >>>> the second line indents appear to be off by two spaces (because >>>> "Ex" was removed). >>>> Don't know if you want to fix those or not. Your call. >>> >>> You have good eyes.? I checked all of these this morning and I >>> missed these files.? Thank you. >>>> >>>> src/hotspot/share/runtime/threadSMR.cpp >>>> >>>> ? - >>>> ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, >>>> 0, >>>> ? - !Mutex::_as_suspend_equivalent_flag); >>>> ? + ThreadsSMRSupport::delete_lock()->wait_without_safepoint_check(); >>>> >>>> ? You dropped the '!Mutex::_as_suspend_equivalent_flag' flag. I >>>> dislike >>>> ? default values so that's why I included it. Now the reader has to >>>> ? ? 1) remember that there's another parameter >>>> ? ? 2) go find the default value for that parameter >>> >>> wait_without_safepoint_check() doesn't have as_suspend_equivalent >>> flag as a parameter.? That code was only used in the safepoint >>> checking case for wait.?? I dislike default parameters too for the >>> same reasons.? Both waits take 0 as the timeout default parameter >>> but I thought that was not a good thing to change. >>> >>>> >>>> src/hotspot/share/gc/shared/workgroup.cpp >>>> ? This change does not parse: >>>> >>>> ?? ? ? // The VM thread should not execute here because >>>> MutexLocker's are used >>>> ? ? -? // as (opposed to MutexLockerEx's). >>>> ? ? +? // as (opposed to MutexLocker's). >>>> >>>> ? since MutexLocker is now on both sides of the verbal comparison. >>> Yeah, I missed that too.? It doesn't actually make sense before >>> either, since there isn't a MutexLocker nearby. >>> >>>> >>>> In some cases, there were multi-line MutexLocker uses that you chose >>>> to combine into a single line, but in most cases you did not combine >>>> them. I couldn't discern a rhyme or reason for the choices (not even >>>> a line length of 80). >>> >>> I combined them if the length wasn't "too long" and it didn't look >>> like the whitespace was helpful.? I did both. >>>> >>>> There is a startling number of names in use for the MutexLocker >>>> variables. My personal preference would be for 'ml' (and 'ul' >>>> for the MutexUnlocker). You have an opportunity to make them all >>>> consistent, but that's hard to do. >>> >>> By convention, ml is used a lot but sometimes you can't use it.? I >>> don't want to change this.? Sometimes people pick names they like >>> for this. >>>> >>>> Thumbs up! If you choose to handle and of my comments above, >>>> I don't need to see another webrev. >>> >>> Thank you Dan for reviewing this!? I'll retest with edits made for >>> comments above. >>> >>> Coleen >>> >>>> >>>> Dan >>>> >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8222811 >>>>> >>>>> Thanks! >>>>> Coleen >>>>> >>>>> >>>> >>> >> From coleen.phillimore at oracle.com Wed Apr 24 11:18:39 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 24 Apr 2019 07:18:39 -0400 Subject: RFR (L, tedious) 8222811: Consolidate MutexLockerEx and MutexLocker In-Reply-To: <13c77938-c70a-8f6d-7b3e-f4fc01ae989a@oracle.com> References: <614f0e46-c4ce-d389-88f9-1a73e14fc5dd@oracle.com> <13c77938-c70a-8f6d-7b3e-f4fc01ae989a@oracle.com> Message-ID: On 4/24/19 3:57 AM, Per Liden wrote: > Hi Coleen, > > I like this clean up. However, one thing that always bothered me is > this pattern: Hi Per,? Erik said you would like it. > > ? MonitorLockerEx ml(&_monitor, Monitor::_no_safepoint_check_flag); > ? ... > ? ml.wait(Monitor::_no_safepoint_check_flag); > > And with your patch it becomes: > > ? MonitorLocker ml(&_monitor, Monitor::_no_safepoint_check_flag); > ? ... > ? ml.wait_without_safepoint_check(); > > Now, it seems a bit silly, and potentially error prone, to always have > to say "don't safepoint check" twice. We already told the > MonitorLocker what to do when it was constructed, so can't we just > have this: > > ? MonitorLocker ml(&_monitor, Monitor::_no_safepoint_check_flag); > ? ... > ? ml.wait(); > > Where wait() does the right thing, i.e. use the flag we passed into > the constructor. Since all of MonitorLocker will be inlined, a flag > check in wait() would be constant folded, so there's no overhead to > worry about here. > > Can we please have this? So I have a follow on patch wrt MonitorLocker.? Actually I've removed it.? Erik thought having a NULL monitor wait was crazy, even though we have a case of that in the GC.?? The code is split whether it uses the MonitorLocker local variable vs. the actual lock. The only code that consistently uses the MonitorLocker local like this is ZGC, so I was going to discuss the next change with you first anyway. I see your point about not having to say whether you're safepoint checking twice though.? People I've been talking to on the project are of two minds.? One set wants it always explicit, the other implicit.? I personally want consistency over all else, which is why I added wait_without_safepoint_check to MonitorLocker. I could change this with this patch.? It's easy enough to do, especially if you see value in MonitorLocker, which was going to be my next discussion with you. Thanks, Coleen > > cheers, > Per > > On 4/23/19 5:06 PM, coleen.phillimore at oracle.com wrote: >> Summary: Make MutexLocker be MutexLockerEx implementation, remove >> MutexLockerEx calls.? Also added wait_without_safepoint_check(). >> >> Also made safepoint_check_flag an enum, renamed MonitorLockerEx to >> MonitorLocker, removed MutexUnlockerEx, and fixed formatting where >> affected by this change. >> >> There's a MutexLocker constructor with a Thread parameter that would >> actually be more performant if the thread is passed from the current >> context rather than calling Thread::current() in Monitor::lock.? I >> think the Thread parameter should be moved to first so that we can >> have MutexLocker look like the Handle constructor calls, for >> example.? I didn't make this change in this. >> >> ??? MutexLocker ml(THREAD, Monitor_lock). >> >> The interesting changes are in: >> >> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutexLocker.hpp.udiff.html >> >> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.hpp.udiff.html >> >> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.cpp.udiff.html >> >> >> The rest is pattern substitution. >> >> Ran mach5 tier1-6 tests. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8222811 >> >> Thanks! >> Coleen >> >> From robbin.ehn at oracle.com Wed Apr 24 11:37:46 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 24 Apr 2019 13:37:46 +0200 Subject: RFR (L, tedious) 8222811: Consolidate MutexLockerEx and MutexLocker In-Reply-To: References: <614f0e46-c4ce-d389-88f9-1a73e14fc5dd@oracle.com> <13c77938-c70a-8f6d-7b3e-f4fc01ae989a@oracle.com> Message-ID: >> ? MonitorLocker ml(&_monitor, Monitor::_no_safepoint_check_flag); >> ? ... >> ? ml.wait(); >> >> Where wait() does the right thing, i.e. use the flag we passed into the >> constructor. Since all of MonitorLocker will be inlined, a flag check in >> wait() would be constant folded, so there's no overhead to worry about here. >> >> Can we please have this? I totally agree, having to supply it twice is just error prone. If it always is constant folded, e.g. known in compile time, it could be a template parameter instead: MonitorLocker ml(&_monitor); Also if we remove the 3 sometimes lock and only have 'always' and 'never' locks, having the two version as different types would give you compile errors instead of runtime asserts. Thanks, Robbin > > So I have a follow on patch wrt MonitorLocker.? Actually I've removed it.? Erik > thought having a NULL monitor wait was crazy, even though we have a case of that > in the GC.?? The code is split whether it uses the MonitorLocker local variable > vs. the actual lock. > > The only code that consistently uses the MonitorLocker local like this is ZGC, > so I was going to discuss the next change with you first anyway. > > I see your point about not having to say whether you're safepoint checking twice > though.? People I've been talking to on the project are of two minds.? One set > wants it always explicit, the other implicit.? I personally want consistency > over all else, which is why I added wait_without_safepoint_check to MonitorLocker. > > I could change this with this patch.? It's easy enough to do, especially if you > see value in MonitorLocker, which was going to be my next discussion with you. > > Thanks, > Coleen > > >> >> cheers, >> Per >> >> On 4/23/19 5:06 PM, coleen.phillimore at oracle.com wrote: >>> Summary: Make MutexLocker be MutexLockerEx implementation, remove >>> MutexLockerEx calls.? Also added wait_without_safepoint_check(). >>> >>> Also made safepoint_check_flag an enum, renamed MonitorLockerEx to >>> MonitorLocker, removed MutexUnlockerEx, and fixed formatting where affected >>> by this change. >>> >>> There's a MutexLocker constructor with a Thread parameter that would actually >>> be more performant if the thread is passed from the current context rather >>> than calling Thread::current() in Monitor::lock.? I think the Thread >>> parameter should be moved to first so that we can have MutexLocker look like >>> the Handle constructor calls, for example.? I didn't make this change in this. >>> >>> ??? MutexLocker ml(THREAD, Monitor_lock). >>> >>> The interesting changes are in: >>> >>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutexLocker.hpp.udiff.html >>> >>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.hpp.udiff.html >>> >>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.cpp.udiff.html >>> >>> >>> The rest is pattern substitution. >>> >>> Ran mach5 tier1-6 tests. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8222811 >>> >>> Thanks! >>> Coleen >>> >>> > From coleen.phillimore at oracle.com Wed Apr 24 11:57:39 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 24 Apr 2019 07:57:39 -0400 Subject: RFR (L, tedious) 8222811: Consolidate MutexLockerEx and MutexLocker In-Reply-To: <4396d1dd-25f9-c5ec-4f95-d8f31a260345@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> Message-ID: <2d1b8ba1-bda1-78c3-b2b0-13774177fcd3@oracle.com> I made the change suggested by Per and it's quite nice.? I also fixed Mutex to not have bodies for the private functions since that's not required to get a compilation error if one uses them. http://cr.openjdk.java.net/~coleenp/2019/8222811.03.incr/webrev/index.html Running again through mach5. Thanks, Coleen On 4/24/19 7:23 AM, coleen.phillimore at oracle.com wrote: > > > On 4/23/19 9:48 PM, David Holmes wrote: >> Hi Coleen, >> >> On 24/04/2019 8:49 am, coleen.phillimore at oracle.com wrote: >>> >>> Here's a new webrev with the changes requested by Dan. >>> >>> http://cr.openjdk.java.net/~coleenp/2019/8222811.02/webrev >> >> Overall this seems fine. A few comments on the main changes: >> >> mutex.cpp >> >> ?156 bool Monitor::wait_without_safepoint_check(long timeout) { >> ?157?? // Make sure safepoint checking is used properly. >> ?158?? assert(_safepoint_check_required != >> Monitor::_safepoint_check_always, >> ?159????????? "This lock should never have a safepoint check: %s", >> name()); >> >> The message is the wrong one: s/never/always/ > > I had both of these messages reversed in wait*() functions wrt. > never/always.? If a lock L has safepoint_check_required = always and > locks or waits without safepoint check, the message is relative to the > lock, not the erroneous call.? Inverse for never. > > Thanks for finding this. >> >> wait_without_safepoint_check is missing: >> >> ? // timeout is in milliseconds - with zero meaning never timeout >> ? assert(timeout >= 0, "negative timeout"); >> > > Fixed. > >> --- >> >> mutexLocker.hpp >> >> 190? protected: >> 191?? Monitor* _mutex; >> >> Good catch on the redundant extra field in MonitorLocker! > > Thanks. >> >> 208?? MutexLocker(Monitor* mutex, Thread* thread, >> Mutex::SafepointCheckFlag flag = Mutex::_safepoint_check_flag) : >> >> 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. > > I also want to have a patch (I think I said this), to make the Thread > argument first.? I could try some more tricks to avoid this > duplication when/if I do that.?? How does that sound? > > Thanks for reviewing! > Coleen > >> >> Thanks, >> David >> >>> Thanks, >>> Coleen >>> >>> On 4/23/19 6:18 PM, coleen.phillimore at oracle.com wrote: >>>> >>>> Hi Dan, Thank you for tackling this code review.? I was hoping you >>>> wouldn't do your usual file-by-file comments.? It would have been >>>> long. >>>> >>>> On 4/23/19 5:43 PM, Daniel D. Daugherty wrote: >>>>> On 4/23/19 11:06 AM, coleen.phillimore at oracle.com wrote: >>>>>> Summary: Make MutexLocker be MutexLockerEx implementation, remove >>>>>> MutexLockerEx calls. Also added wait_without_safepoint_check(). >>>>>> >>>>>> Also made safepoint_check_flag an enum, renamed MonitorLockerEx >>>>>> to MonitorLocker, removed MutexUnlockerEx, and fixed formatting >>>>>> where affected by this change. >>>>>> >>>>>> There's a MutexLocker constructor with a Thread parameter that >>>>>> would actually be more performant if the thread is passed from >>>>>> the current context rather than calling Thread::current() in >>>>>> Monitor::lock.? I think the Thread parameter should be moved to >>>>>> first so that we can have MutexLocker look like the Handle >>>>>> constructor calls, for example.? I didn't make this change in this. >>>>>> >>>>>> ?? MutexLocker ml(THREAD, Monitor_lock). >>>>>> >>>>>> The interesting changes are in: >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutexLocker.hpp.udiff.html >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.hpp.udiff.html >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.cpp.udiff.html >>>>>> >>>>>> >>>>>> The rest is pattern substitution. >>>>>> >>>>>> Ran mach5 tier1-6 tests. >>>>>> >>>>>> open webrev at >>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev >>>>> >>>>> src/hotspot/share/runtime/mutexLocker.hpp >>>>> ??? L198: ????? assert(_mutex->rank() > Mutex::special || >>>>> no_safepoint_check, >>>>> ??? L199: ??????? "Mutexes with rank special or lower should not >>>>> do safepoint checks"); >>>>> ??????? nit - indent on L199 needs 5 more spaces >>>>> >>>>> ??? L200-203 - this if-block is missing the usual HotSpot '{' and >>>>> '}'. >>>>> ??? (Not your fault, but since you're in there...) >>>>> >>>>> ??? L211: ????? assert(_mutex->rank() > Mutex::special || >>>>> no_safepoint_check, >>>>> ??? L212: ??????? "Mutexes with rank special or lower should not >>>>> do safepoint checks"); >>>>> ??????? nit - indent on L211 needs 5 more spaces >>>>> >>>>> ??? L213-216 - this if-block is missing the usual HotSpot '{' and >>>>> '}'. >>>>> ??? (Not your fault, but since you're in there...) >>>> >>>> Fixed all of these.? Since I've touched it, I made it follow the >>>> coding style. >>>> >>>>> >>>>> src/hotspot/share/runtime/mutex.hpp >>>>> ??? L237: ?? // why do these need bodies? >>>>> ??????? To prevent any calls to Mutex::notify(), Mutex::notify_all(), >>>>> ??????? Mutex::wait() and Mutex::wait_without_safepoint_check() from >>>>> ??????? calling the superclass' version of those functions. >>>>> >>>> >>>> I forgot to check this, but if they're private, they shouldn't need >>>> bodies.? I'll remove the comment and leave them for now. >>>> >>>> >>>>> src/hotspot/share/runtime/mutex.cpp >>>>> ??? Nice detangling into Monitor::wait() and >>>>> ??? Monitor::wait_without_safepoint_check(). >>>>> >>>> Thank you! >>>> >>>>> >>>>> For the rest of the files, I went through the patch from bottom -> >>>>> top >>>>> and looked for anything that didn't look right. I figure other >>>>> reviewers >>>>> are looking from top -> bottom... :-) >>>>> >>>>> For the multi-line MutexLocker uses in >>>>> src/hotspot/share/runtime/vmThread.cpp >>>>> and src/hotspot/share/memory/metaspace.cpp, >>>>> the second line indents appear to be off by two spaces (because >>>>> "Ex" was removed). >>>>> Don't know if you want to fix those or not. Your call. >>>> >>>> You have good eyes.? I checked all of these this morning and I >>>> missed these files.? Thank you. >>>>> >>>>> src/hotspot/share/runtime/threadSMR.cpp >>>>> >>>>> ? - >>>>> ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, >>>>> 0, >>>>> ? - !Mutex::_as_suspend_equivalent_flag); >>>>> ? + ThreadsSMRSupport::delete_lock()->wait_without_safepoint_check(); >>>>> >>>>> ? You dropped the '!Mutex::_as_suspend_equivalent_flag' flag. I >>>>> dislike >>>>> ? default values so that's why I included it. Now the reader has to >>>>> ? ? 1) remember that there's another parameter >>>>> ? ? 2) go find the default value for that parameter >>>> >>>> wait_without_safepoint_check() doesn't have as_suspend_equivalent >>>> flag as a parameter.? That code was only used in the safepoint >>>> checking case for wait.?? I dislike default parameters too for the >>>> same reasons.? Both waits take 0 as the timeout default parameter >>>> but I thought that was not a good thing to change. >>>> >>>>> >>>>> src/hotspot/share/gc/shared/workgroup.cpp >>>>> ? This change does not parse: >>>>> >>>>> ?? ? ? // The VM thread should not execute here because >>>>> MutexLocker's are used >>>>> ? ? -? // as (opposed to MutexLockerEx's). >>>>> ? ? +? // as (opposed to MutexLocker's). >>>>> >>>>> ? since MutexLocker is now on both sides of the verbal comparison. >>>> Yeah, I missed that too.? It doesn't actually make sense before >>>> either, since there isn't a MutexLocker nearby. >>>> >>>>> >>>>> In some cases, there were multi-line MutexLocker uses that you chose >>>>> to combine into a single line, but in most cases you did not combine >>>>> them. I couldn't discern a rhyme or reason for the choices (not even >>>>> a line length of 80). >>>> >>>> I combined them if the length wasn't "too long" and it didn't look >>>> like the whitespace was helpful.? I did both. >>>>> >>>>> There is a startling number of names in use for the MutexLocker >>>>> variables. My personal preference would be for 'ml' (and 'ul' >>>>> for the MutexUnlocker). You have an opportunity to make them all >>>>> consistent, but that's hard to do. >>>> >>>> By convention, ml is used a lot but sometimes you can't use it.? I >>>> don't want to change this.? Sometimes people pick names they like >>>> for this. >>>>> >>>>> Thumbs up! If you choose to handle and of my comments above, >>>>> I don't need to see another webrev. >>>> >>>> Thank you Dan for reviewing this!? I'll retest with edits made for >>>> comments above. >>>> >>>> Coleen >>>> >>>>> >>>>> Dan >>>>> >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8222811 >>>>>> >>>>>> Thanks! >>>>>> Coleen >>>>>> >>>>>> >>>>> >>>> >>> > From coleen.phillimore at oracle.com Wed Apr 24 12:02:12 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 24 Apr 2019 08:02:12 -0400 Subject: RFR (L, tedious) 8222811: Consolidate MutexLockerEx and MutexLocker In-Reply-To: References: <614f0e46-c4ce-d389-88f9-1a73e14fc5dd@oracle.com> <13c77938-c70a-8f6d-7b3e-f4fc01ae989a@oracle.com> Message-ID: <7d17530a-8f72-044e-df0a-610177c20ce6@oracle.com> On 4/24/19 7:37 AM, Robbin Ehn wrote: >>> ? MonitorLocker ml(&_monitor, Monitor::_no_safepoint_check_flag); >>> ? ... >>> ? ml.wait(); >>> >>> Where wait() does the right thing, i.e. use the flag we passed into >>> the constructor. Since all of MonitorLocker will be inlined, a flag >>> check in wait() would be constant folded, so there's no overhead to >>> worry about here. >>> >>> Can we please have this? > > I totally agree, having to supply it twice is just error prone. > If it always is constant folded, e.g. known in compile time, it could > be a template parameter instead: > MonitorLocker ml(&_monitor); This could be a further change, ie easy to make.?? I would rather not add this to this already large (in terms of source files) change.? I originally thought we should remove MonitorLocker.? At least I don't think it should allow NULL. > > Also if we remove the 3 sometimes lock and only have 'always' and > 'never' locks, > having the two version as different types would give you compile > errors instead of runtime asserts. We need to revise the discussion whether to require it to be explicit vs. implicit though.?? But this is good because now we can decide what to do about this one: https://bugs.openjdk.java.net/browse/JDK-8074355 Thanks, Coleen > > Thanks, Robbin > >> >> So I have a follow on patch wrt MonitorLocker.? Actually I've removed >> it.? Erik thought having a NULL monitor wait was crazy, even though >> we have a case of that in the GC.?? The code is split whether it uses >> the MonitorLocker local variable vs. the actual lock. >> >> The only code that consistently uses the MonitorLocker local like >> this is ZGC, so I was going to discuss the next change with you first >> anyway. >> >> I see your point about not having to say whether you're safepoint >> checking twice though.? People I've been talking to on the project >> are of two minds.? One set wants it always explicit, the other >> implicit.? I personally want consistency over all else, which is why >> I added wait_without_safepoint_check to MonitorLocker. >> >> I could change this with this patch.? It's easy enough to do, >> especially if you see value in MonitorLocker, which was going to be >> my next discussion with you. >> >> Thanks, >> Coleen >> >> >>> >>> cheers, >>> Per >>> >>> On 4/23/19 5:06 PM, coleen.phillimore at oracle.com wrote: >>>> Summary: Make MutexLocker be MutexLockerEx implementation, remove >>>> MutexLockerEx calls. Also added wait_without_safepoint_check(). >>>> >>>> Also made safepoint_check_flag an enum, renamed MonitorLockerEx to >>>> MonitorLocker, removed MutexUnlockerEx, and fixed formatting where >>>> affected by this change. >>>> >>>> There's a MutexLocker constructor with a Thread parameter that >>>> would actually be more performant if the thread is passed from the >>>> current context rather than calling Thread::current() in >>>> Monitor::lock.? I think the Thread parameter should be moved to >>>> first so that we can have MutexLocker look like the Handle >>>> constructor calls, for example.? I didn't make this change in this. >>>> >>>> ??? MutexLocker ml(THREAD, Monitor_lock). >>>> >>>> The interesting changes are in: >>>> >>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutexLocker.hpp.udiff.html >>>> >>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.hpp.udiff.html >>>> >>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.cpp.udiff.html >>>> >>>> >>>> The rest is pattern substitution. >>>> >>>> Ran mach5 tier1-6 tests. >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8222811 >>>> >>>> Thanks! >>>> Coleen >>>> >>>> >> From robbin.ehn at oracle.com Wed Apr 24 12:08:59 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 24 Apr 2019 14:08:59 +0200 Subject: RFR (L, tedious) 8222811: Consolidate MutexLockerEx and MutexLocker In-Reply-To: <7d17530a-8f72-044e-df0a-610177c20ce6@oracle.com> References: <614f0e46-c4ce-d389-88f9-1a73e14fc5dd@oracle.com> <13c77938-c70a-8f6d-7b3e-f4fc01ae989a@oracle.com> <7d17530a-8f72-044e-df0a-610177c20ce6@oracle.com> Message-ID: <15849d0b-e05f-9648-679b-7493f7b421f8@oracle.com> Hi Coleen, > > This could be a further change, ie easy to make.?? I would rather not add this > to this already large (in terms of source files) change.? I originally thought > we should remove MonitorLocker.? At least I don't think it should allow NULL. Yes, no need to address something like that in this patch. > >> >> Also if we remove the 3 sometimes lock and only have 'always' and 'never' locks, >> having the two version as different types would give you compile errors >> instead of runtime asserts. > > We need to revise the discussion whether to require it to be explicit vs. > implicit though.?? But this is good because now we can decide what to do about > this one: https://bugs.openjdk.java.net/browse/JDK-8074355 Yes Thanks, Robbin > > Thanks, > Coleen > >> >> Thanks, Robbin >> >>> >>> So I have a follow on patch wrt MonitorLocker.? Actually I've removed it. >>> Erik thought having a NULL monitor wait was crazy, even though we have a case >>> of that in the GC.?? The code is split whether it uses the MonitorLocker >>> local variable vs. the actual lock. >>> >>> The only code that consistently uses the MonitorLocker local like this is >>> ZGC, so I was going to discuss the next change with you first anyway. >>> >>> I see your point about not having to say whether you're safepoint checking >>> twice though.? People I've been talking to on the project are of two minds. >>> One set wants it always explicit, the other implicit.? I personally want >>> consistency over all else, which is why I added wait_without_safepoint_check >>> to MonitorLocker. >>> >>> I could change this with this patch.? It's easy enough to do, especially if >>> you see value in MonitorLocker, which was going to be my next discussion with >>> you. >>> >>> Thanks, >>> Coleen >>> >>> >>>> >>>> cheers, >>>> Per >>>> >>>> On 4/23/19 5:06 PM, coleen.phillimore at oracle.com wrote: >>>>> Summary: Make MutexLocker be MutexLockerEx implementation, remove >>>>> MutexLockerEx calls. Also added wait_without_safepoint_check(). >>>>> >>>>> Also made safepoint_check_flag an enum, renamed MonitorLockerEx to >>>>> MonitorLocker, removed MutexUnlockerEx, and fixed formatting where affected >>>>> by this change. >>>>> >>>>> There's a MutexLocker constructor with a Thread parameter that would >>>>> actually be more performant if the thread is passed from the current >>>>> context rather than calling Thread::current() in Monitor::lock.? I think >>>>> the Thread parameter should be moved to first so that we can have >>>>> MutexLocker look like the Handle constructor calls, for example.? I didn't >>>>> make this change in this. >>>>> >>>>> ??? MutexLocker ml(THREAD, Monitor_lock). >>>>> >>>>> The interesting changes are in: >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutexLocker.hpp.udiff.html >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.hpp.udiff.html >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.cpp.udiff.html >>>>> >>>>> >>>>> The rest is pattern substitution. >>>>> >>>>> Ran mach5 tier1-6 tests. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8222811 >>>>> >>>>> Thanks! >>>>> Coleen >>>>> >>>>> >>> > From david.holmes at oracle.com Wed Apr 24 12:10:46 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Apr 2019 22:10:46 +1000 Subject: RFR (L, tedious) 8222811: Consolidate MutexLockerEx and MutexLocker In-Reply-To: <7d17530a-8f72-044e-df0a-610177c20ce6@oracle.com> References: <614f0e46-c4ce-d389-88f9-1a73e14fc5dd@oracle.com> <13c77938-c70a-8f6d-7b3e-f4fc01ae989a@oracle.com> <7d17530a-8f72-044e-df0a-610177c20ce6@oracle.com> Message-ID: <27682c90-ae28-9475-36f0-59971ac9fa73@oracle.com> On 24/04/2019 10:02 pm, coleen.phillimore at oracle.com wrote: > On 4/24/19 7:37 AM, Robbin Ehn wrote: >>>> ? MonitorLocker ml(&_monitor, Monitor::_no_safepoint_check_flag); >>>> ? ... >>>> ? ml.wait(); >>>> >>>> Where wait() does the right thing, i.e. use the flag we passed into >>>> the constructor. Since all of MonitorLocker will be inlined, a flag >>>> check in wait() would be constant folded, so there's no overhead to >>>> worry about here. >>>> >>>> Can we please have this? >> >> I totally agree, having to supply it twice is just error prone. >> If it always is constant folded, e.g. known in compile time, it could >> be a template parameter instead: >> MonitorLocker ml(&_monitor); > > This could be a further change, ie easy to make.?? I would rather not > add this to this already large (in terms of source files) change.? I > originally thought we should remove MonitorLocker.? At least I don't > think it should allow NULL. IIRC one of the suggested follow ups from the Mutex simplification was to do away with Mutex and just have Monitor. But you're right that anyone needing a MonitorLocker for wait etc can never be using NULL. David ----- >> >> Also if we remove the 3 sometimes lock and only have 'always' and >> 'never' locks, >> having the two version as different types would give you compile >> errors instead of runtime asserts. > > We need to revise the discussion whether to require it to be explicit > vs. implicit though.?? But this is good because now we can decide what > to do about this one: https://bugs.openjdk.java.net/browse/JDK-8074355 > > Thanks, > Coleen > >> >> Thanks, Robbin >> >>> >>> So I have a follow on patch wrt MonitorLocker.? Actually I've removed >>> it.? Erik thought having a NULL monitor wait was crazy, even though >>> we have a case of that in the GC.?? The code is split whether it uses >>> the MonitorLocker local variable vs. the actual lock. >>> >>> The only code that consistently uses the MonitorLocker local like >>> this is ZGC, so I was going to discuss the next change with you first >>> anyway. >>> >>> I see your point about not having to say whether you're safepoint >>> checking twice though.? People I've been talking to on the project >>> are of two minds.? One set wants it always explicit, the other >>> implicit.? I personally want consistency over all else, which is why >>> I added wait_without_safepoint_check to MonitorLocker. >>> >>> I could change this with this patch.? It's easy enough to do, >>> especially if you see value in MonitorLocker, which was going to be >>> my next discussion with you. >>> >>> Thanks, >>> Coleen >>> >>> >>>> >>>> cheers, >>>> Per >>>> >>>> On 4/23/19 5:06 PM, coleen.phillimore at oracle.com wrote: >>>>> Summary: Make MutexLocker be MutexLockerEx implementation, remove >>>>> MutexLockerEx calls. Also added wait_without_safepoint_check(). >>>>> >>>>> Also made safepoint_check_flag an enum, renamed MonitorLockerEx to >>>>> MonitorLocker, removed MutexUnlockerEx, and fixed formatting where >>>>> affected by this change. >>>>> >>>>> There's a MutexLocker constructor with a Thread parameter that >>>>> would actually be more performant if the thread is passed from the >>>>> current context rather than calling Thread::current() in >>>>> Monitor::lock.? I think the Thread parameter should be moved to >>>>> first so that we can have MutexLocker look like the Handle >>>>> constructor calls, for example.? I didn't make this change in this. >>>>> >>>>> ??? MutexLocker ml(THREAD, Monitor_lock). >>>>> >>>>> The interesting changes are in: >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutexLocker.hpp.udiff.html >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.hpp.udiff.html >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.cpp.udiff.html >>>>> >>>>> >>>>> The rest is pattern substitution. >>>>> >>>>> Ran mach5 tier1-6 tests. >>>>> >>>>> open webrev at >>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8222811 >>>>> >>>>> Thanks! >>>>> Coleen >>>>> >>>>> >>> > From david.holmes at oracle.com Wed Apr 24 12:14:04 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Apr 2019 22:14:04 +1000 Subject: RFR (L, tedious) 8222811: Consolidate MutexLockerEx and MutexLocker In-Reply-To: <4396d1dd-25f9-c5ec-4f95-d8f31a260345@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> Message-ID: <8cb48709-fc4a-486e-d406-813b87edbfb5@oracle.com> On 24/04/2019 9:23 pm, coleen.phillimore at oracle.com wrote: > On 4/23/19 9:48 PM, David Holmes wrote: >> Hi Coleen, >> >> On 24/04/2019 8:49 am, coleen.phillimore at oracle.com wrote: >>> >>> Here's a new webrev with the changes requested by Dan. >>> >>> http://cr.openjdk.java.net/~coleenp/2019/8222811.02/webrev >> >> Overall this seems fine. A few comments on the main changes: >> >> mutex.cpp >> >> ?156 bool Monitor::wait_without_safepoint_check(long timeout) { >> ?157?? // Make sure safepoint checking is used properly. >> ?158?? assert(_safepoint_check_required != >> Monitor::_safepoint_check_always, >> ?159????????? "This lock should never have a safepoint check: %s", >> name()); >> >> The message is the wrong one: s/never/always/ > > I had both of these messages reversed in wait*() functions wrt. > never/always.? If a lock L has safepoint_check_required = always and > locks or waits without safepoint check, the message is relative to the > lock, not the erroneous call.? Inverse for never. > > Thanks for finding this. >> >> wait_without_safepoint_check is missing: >> >> ? // timeout is in milliseconds - with zero meaning never timeout >> ? assert(timeout >= 0, "negative timeout"); >> > > Fixed. > >> --- >> >> mutexLocker.hpp >> >> 190? protected: >> 191?? Monitor* _mutex; >> >> Good catch on the redundant extra field in MonitorLocker! > > Thanks. >> >> 208?? MutexLocker(Monitor* mutex, Thread* thread, >> Mutex::SafepointCheckFlag flag = Mutex::_safepoint_check_flag) : >> >> 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 :) I don't suppose something like: extern Thread * Thread::current(); is valid? :) > I also want to have a patch (I think I said this), to make the Thread > argument first.? I could try some more tricks to avoid this duplication > when/if I do that.?? How does that sound? Sounds good. Thanks, David ----- > Thanks for reviewing! > Coleen > >> >> Thanks, >> David >> >>> Thanks, >>> Coleen >>> >>> On 4/23/19 6:18 PM, coleen.phillimore at oracle.com wrote: >>>> >>>> Hi Dan, Thank you for tackling this code review.? I was hoping you >>>> wouldn't do your usual file-by-file comments.? It would have been long. >>>> >>>> On 4/23/19 5:43 PM, Daniel D. Daugherty wrote: >>>>> On 4/23/19 11:06 AM, coleen.phillimore at oracle.com wrote: >>>>>> Summary: Make MutexLocker be MutexLockerEx implementation, remove >>>>>> MutexLockerEx calls. Also added wait_without_safepoint_check(). >>>>>> >>>>>> Also made safepoint_check_flag an enum, renamed MonitorLockerEx to >>>>>> MonitorLocker, removed MutexUnlockerEx, and fixed formatting where >>>>>> affected by this change. >>>>>> >>>>>> There's a MutexLocker constructor with a Thread parameter that >>>>>> would actually be more performant if the thread is passed from the >>>>>> current context rather than calling Thread::current() in >>>>>> Monitor::lock.? I think the Thread parameter should be moved to >>>>>> first so that we can have MutexLocker look like the Handle >>>>>> constructor calls, for example.? I didn't make this change in this. >>>>>> >>>>>> ?? MutexLocker ml(THREAD, Monitor_lock). >>>>>> >>>>>> The interesting changes are in: >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutexLocker.hpp.udiff.html >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.hpp.udiff.html >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.cpp.udiff.html >>>>>> >>>>>> >>>>>> The rest is pattern substitution. >>>>>> >>>>>> Ran mach5 tier1-6 tests. >>>>>> >>>>>> open webrev at >>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev >>>>> >>>>> src/hotspot/share/runtime/mutexLocker.hpp >>>>> ??? L198: ????? assert(_mutex->rank() > Mutex::special || >>>>> no_safepoint_check, >>>>> ??? L199: ??????? "Mutexes with rank special or lower should not do >>>>> safepoint checks"); >>>>> ??????? nit - indent on L199 needs 5 more spaces >>>>> >>>>> ??? L200-203 - this if-block is missing the usual HotSpot '{' and '}'. >>>>> ??? (Not your fault, but since you're in there...) >>>>> >>>>> ??? L211: ????? assert(_mutex->rank() > Mutex::special || >>>>> no_safepoint_check, >>>>> ??? L212: ??????? "Mutexes with rank special or lower should not do >>>>> safepoint checks"); >>>>> ??????? nit - indent on L211 needs 5 more spaces >>>>> >>>>> ??? L213-216 - this if-block is missing the usual HotSpot '{' and '}'. >>>>> ??? (Not your fault, but since you're in there...) >>>> >>>> Fixed all of these.? Since I've touched it, I made it follow the >>>> coding style. >>>> >>>>> >>>>> src/hotspot/share/runtime/mutex.hpp >>>>> ??? L237: ?? // why do these need bodies? >>>>> ??????? To prevent any calls to Mutex::notify(), Mutex::notify_all(), >>>>> ??????? Mutex::wait() and Mutex::wait_without_safepoint_check() from >>>>> ??????? calling the superclass' version of those functions. >>>>> >>>> >>>> I forgot to check this, but if they're private, they shouldn't need >>>> bodies.? I'll remove the comment and leave them for now. >>>> >>>> >>>>> src/hotspot/share/runtime/mutex.cpp >>>>> ??? Nice detangling into Monitor::wait() and >>>>> ??? Monitor::wait_without_safepoint_check(). >>>>> >>>> Thank you! >>>> >>>>> >>>>> For the rest of the files, I went through the patch from bottom -> top >>>>> and looked for anything that didn't look right. I figure other >>>>> reviewers >>>>> are looking from top -> bottom... :-) >>>>> >>>>> For the multi-line MutexLocker uses in >>>>> src/hotspot/share/runtime/vmThread.cpp >>>>> and src/hotspot/share/memory/metaspace.cpp, >>>>> the second line indents appear to be off by two spaces (because >>>>> "Ex" was removed). >>>>> Don't know if you want to fix those or not. Your call. >>>> >>>> You have good eyes.? I checked all of these this morning and I >>>> missed these files.? Thank you. >>>>> >>>>> src/hotspot/share/runtime/threadSMR.cpp >>>>> >>>>> ? - >>>>> ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, >>>>> 0, >>>>> ? - !Mutex::_as_suspend_equivalent_flag); >>>>> ? + ThreadsSMRSupport::delete_lock()->wait_without_safepoint_check(); >>>>> >>>>> ? You dropped the '!Mutex::_as_suspend_equivalent_flag' flag. I >>>>> dislike >>>>> ? default values so that's why I included it. Now the reader has to >>>>> ? ? 1) remember that there's another parameter >>>>> ? ? 2) go find the default value for that parameter >>>> >>>> wait_without_safepoint_check() doesn't have as_suspend_equivalent >>>> flag as a parameter.? That code was only used in the safepoint >>>> checking case for wait.?? I dislike default parameters too for the >>>> same reasons.? Both waits take 0 as the timeout default parameter >>>> but I thought that was not a good thing to change. >>>> >>>>> >>>>> src/hotspot/share/gc/shared/workgroup.cpp >>>>> ? This change does not parse: >>>>> >>>>> ?? ? ? // The VM thread should not execute here because >>>>> MutexLocker's are used >>>>> ? ? -? // as (opposed to MutexLockerEx's). >>>>> ? ? +? // as (opposed to MutexLocker's). >>>>> >>>>> ? since MutexLocker is now on both sides of the verbal comparison. >>>> Yeah, I missed that too.? It doesn't actually make sense before >>>> either, since there isn't a MutexLocker nearby. >>>> >>>>> >>>>> In some cases, there were multi-line MutexLocker uses that you chose >>>>> to combine into a single line, but in most cases you did not combine >>>>> them. I couldn't discern a rhyme or reason for the choices (not even >>>>> a line length of 80). >>>> >>>> I combined them if the length wasn't "too long" and it didn't look >>>> like the whitespace was helpful.? I did both. >>>>> >>>>> There is a startling number of names in use for the MutexLocker >>>>> variables. My personal preference would be for 'ml' (and 'ul' >>>>> for the MutexUnlocker). You have an opportunity to make them all >>>>> consistent, but that's hard to do. >>>> >>>> By convention, ml is used a lot but sometimes you can't use it.? I >>>> don't want to change this.? Sometimes people pick names they like >>>> for this. >>>>> >>>>> Thumbs up! If you choose to handle and of my comments above, >>>>> I don't need to see another webrev. >>>> >>>> Thank you Dan for reviewing this!? I'll retest with edits made for >>>> comments above. >>>> >>>> Coleen >>>> >>>>> >>>>> Dan >>>>> >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8222811 >>>>>> >>>>>> Thanks! >>>>>> Coleen >>>>>> >>>>>> >>>>> >>>> >>> > From coleen.phillimore at oracle.com Wed Apr 24 12:49:18 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 24 Apr 2019 08:49:18 -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: On 4/24/19 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: >>> Hi Coleen, >>> >>> On 24/04/2019 8:49 am, coleen.phillimore at oracle.com wrote: >>>> >>>> Here's a new webrev with the changes requested by Dan. >>>> >>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.02/webrev >>> >>> Overall this seems fine. A few comments on the main changes: >>> >>> mutex.cpp >>> >>> ?156 bool Monitor::wait_without_safepoint_check(long timeout) { >>> ?157?? // Make sure safepoint checking is used properly. >>> ?158?? assert(_safepoint_check_required != >>> Monitor::_safepoint_check_always, >>> ?159????????? "This lock should never have a safepoint check: %s", >>> name()); >>> >>> The message is the wrong one: s/never/always/ >> >> I had both of these messages reversed in wait*() functions wrt. >> never/always.? If a lock L has safepoint_check_required = always and >> locks or waits without safepoint check, the message is relative to >> the lock, not the erroneous call.? Inverse for never. >> >> Thanks for finding this. >>> >>> wait_without_safepoint_check is missing: >>> >>> ? // timeout is in milliseconds - with zero meaning never timeout >>> ? assert(timeout >= 0, "negative timeout"); >>> >> >> Fixed. >> >>> --- >>> >>> mutexLocker.hpp >>> >>> 190? protected: >>> 191?? Monitor* _mutex; >>> >>> Good catch on the redundant extra field in MonitorLocker! >> >> Thanks. >>> >>> 208?? MutexLocker(Monitor* mutex, Thread* thread, >>> Mutex::SafepointCheckFlag flag = Mutex::_safepoint_check_flag) : >>> >>> 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 > :) I don't suppose something like: > > extern Thread * Thread::current(); > > is valid? :) I don't know.? This makes me uneasy too.? Maybe we can think of something when he gets back. > >> I also want to have a patch (I think I said this), to make the Thread >> argument first.? I could try some more tricks to avoid this >> duplication when/if I do that.?? How does that sound? > > Sounds good. Thanks! Coleen > > Thanks, > David > ----- > >> Thanks for reviewing! >> Coleen >> >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Coleen >>>> >>>> On 4/23/19 6:18 PM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> Hi Dan, Thank you for tackling this code review.? I was hoping you >>>>> wouldn't do your usual file-by-file comments. It would have been >>>>> long. >>>>> >>>>> On 4/23/19 5:43 PM, Daniel D. Daugherty wrote: >>>>>> On 4/23/19 11:06 AM, coleen.phillimore at oracle.com wrote: >>>>>>> Summary: Make MutexLocker be MutexLockerEx implementation, >>>>>>> remove MutexLockerEx calls. Also added >>>>>>> wait_without_safepoint_check(). >>>>>>> >>>>>>> Also made safepoint_check_flag an enum, renamed MonitorLockerEx >>>>>>> to MonitorLocker, removed MutexUnlockerEx, and fixed formatting >>>>>>> where affected by this change. >>>>>>> >>>>>>> There's a MutexLocker constructor with a Thread parameter that >>>>>>> would actually be more performant if the thread is passed from >>>>>>> the current context rather than calling Thread::current() in >>>>>>> Monitor::lock.? I think the Thread parameter should be moved to >>>>>>> first so that we can have MutexLocker look like the Handle >>>>>>> constructor calls, for example.? I didn't make this change in this. >>>>>>> >>>>>>> ?? MutexLocker ml(THREAD, Monitor_lock). >>>>>>> >>>>>>> The interesting changes are in: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutexLocker.hpp.udiff.html >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.hpp.udiff.html >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> The rest is pattern substitution. >>>>>>> >>>>>>> Ran mach5 tier1-6 tests. >>>>>>> >>>>>>> open webrev at >>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev >>>>>> >>>>>> src/hotspot/share/runtime/mutexLocker.hpp >>>>>> ??? L198: ????? assert(_mutex->rank() > Mutex::special || >>>>>> no_safepoint_check, >>>>>> ??? L199: ??????? "Mutexes with rank special or lower should not >>>>>> do safepoint checks"); >>>>>> ??????? nit - indent on L199 needs 5 more spaces >>>>>> >>>>>> ??? L200-203 - this if-block is missing the usual HotSpot '{' and >>>>>> '}'. >>>>>> ??? (Not your fault, but since you're in there...) >>>>>> >>>>>> ??? L211: ????? assert(_mutex->rank() > Mutex::special || >>>>>> no_safepoint_check, >>>>>> ??? L212: ??????? "Mutexes with rank special or lower should not >>>>>> do safepoint checks"); >>>>>> ??????? nit - indent on L211 needs 5 more spaces >>>>>> >>>>>> ??? L213-216 - this if-block is missing the usual HotSpot '{' and >>>>>> '}'. >>>>>> ??? (Not your fault, but since you're in there...) >>>>> >>>>> Fixed all of these.? Since I've touched it, I made it follow the >>>>> coding style. >>>>> >>>>>> >>>>>> src/hotspot/share/runtime/mutex.hpp >>>>>> ??? L237: ?? // why do these need bodies? >>>>>> ??????? To prevent any calls to Mutex::notify(), >>>>>> Mutex::notify_all(), >>>>>> ??????? Mutex::wait() and Mutex::wait_without_safepoint_check() from >>>>>> ??????? calling the superclass' version of those functions. >>>>>> >>>>> >>>>> I forgot to check this, but if they're private, they shouldn't >>>>> need bodies.? I'll remove the comment and leave them for now. >>>>> >>>>> >>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>> ??? Nice detangling into Monitor::wait() and >>>>>> ??? Monitor::wait_without_safepoint_check(). >>>>>> >>>>> Thank you! >>>>> >>>>>> >>>>>> For the rest of the files, I went through the patch from bottom >>>>>> -> top >>>>>> and looked for anything that didn't look right. I figure other >>>>>> reviewers >>>>>> are looking from top -> bottom... :-) >>>>>> >>>>>> For the multi-line MutexLocker uses in >>>>>> src/hotspot/share/runtime/vmThread.cpp >>>>>> and src/hotspot/share/memory/metaspace.cpp, >>>>>> the second line indents appear to be off by two spaces (because >>>>>> "Ex" was removed). >>>>>> Don't know if you want to fix those or not. Your call. >>>>> >>>>> You have good eyes.? I checked all of these this morning and I >>>>> missed these files.? Thank you. >>>>>> >>>>>> src/hotspot/share/runtime/threadSMR.cpp >>>>>> >>>>>> ? - >>>>>> ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, >>>>>> 0, >>>>>> ? - !Mutex::_as_suspend_equivalent_flag); >>>>>> ? + >>>>>> ThreadsSMRSupport::delete_lock()->wait_without_safepoint_check(); >>>>>> >>>>>> ? You dropped the '!Mutex::_as_suspend_equivalent_flag' flag. I >>>>>> dislike >>>>>> ? default values so that's why I included it. Now the reader has to >>>>>> ? ? 1) remember that there's another parameter >>>>>> ? ? 2) go find the default value for that parameter >>>>> >>>>> wait_without_safepoint_check() doesn't have as_suspend_equivalent >>>>> flag as a parameter.? That code was only used in the safepoint >>>>> checking case for wait.?? I dislike default parameters too for the >>>>> same reasons.? Both waits take 0 as the timeout default parameter >>>>> but I thought that was not a good thing to change. >>>>> >>>>>> >>>>>> src/hotspot/share/gc/shared/workgroup.cpp >>>>>> ? This change does not parse: >>>>>> >>>>>> ?? ? ? // The VM thread should not execute here because >>>>>> MutexLocker's are used >>>>>> ? ? -? // as (opposed to MutexLockerEx's). >>>>>> ? ? +? // as (opposed to MutexLocker's). >>>>>> >>>>>> ? since MutexLocker is now on both sides of the verbal comparison. >>>>> Yeah, I missed that too.? It doesn't actually make sense before >>>>> either, since there isn't a MutexLocker nearby. >>>>> >>>>>> >>>>>> In some cases, there were multi-line MutexLocker uses that you chose >>>>>> to combine into a single line, but in most cases you did not combine >>>>>> them. I couldn't discern a rhyme or reason for the choices (not even >>>>>> a line length of 80). >>>>> >>>>> I combined them if the length wasn't "too long" and it didn't look >>>>> like the whitespace was helpful.? I did both. >>>>>> >>>>>> There is a startling number of names in use for the MutexLocker >>>>>> variables. My personal preference would be for 'ml' (and 'ul' >>>>>> for the MutexUnlocker). You have an opportunity to make them all >>>>>> consistent, but that's hard to do. >>>>> >>>>> By convention, ml is used a lot but sometimes you can't use it.? I >>>>> don't want to change this.? Sometimes people pick names they like >>>>> for this. >>>>>> >>>>>> Thumbs up! If you choose to handle and of my comments above, >>>>>> I don't need to see another webrev. >>>>> >>>>> Thank you Dan for reviewing this!? I'll retest with edits made for >>>>> comments above. >>>>> >>>>> Coleen >>>>> >>>>>> >>>>>> Dan >>>>>> >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8222811 >>>>>>> >>>>>>> Thanks! >>>>>>> Coleen >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> From coleen.phillimore at oracle.com Wed Apr 24 12:51:45 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 24 Apr 2019 08:51:45 -0400 Subject: RFR (L, tedious) 8222811: Consolidate MutexLockerEx and MutexLocker In-Reply-To: <27682c90-ae28-9475-36f0-59971ac9fa73@oracle.com> References: <614f0e46-c4ce-d389-88f9-1a73e14fc5dd@oracle.com> <13c77938-c70a-8f6d-7b3e-f4fc01ae989a@oracle.com> <7d17530a-8f72-044e-df0a-610177c20ce6@oracle.com> <27682c90-ae28-9475-36f0-59971ac9fa73@oracle.com> Message-ID: On 4/24/19 8:10 AM, David Holmes wrote: > On 24/04/2019 10:02 pm, coleen.phillimore at oracle.com wrote: >> On 4/24/19 7:37 AM, Robbin Ehn wrote: >>>>> ? MonitorLocker ml(&_monitor, Monitor::_no_safepoint_check_flag); >>>>> ? ... >>>>> ? ml.wait(); >>>>> >>>>> Where wait() does the right thing, i.e. use the flag we passed >>>>> into the constructor. Since all of MonitorLocker will be inlined, >>>>> a flag check in wait() would be constant folded, so there's no >>>>> overhead to worry about here. >>>>> >>>>> Can we please have this? >>> >>> I totally agree, having to supply it twice is just error prone. >>> If it always is constant folded, e.g. known in compile time, it >>> could be a template parameter instead: >>> MonitorLocker ml(&_monitor); >> >> This could be a further change, ie easy to make.?? I would rather not >> add this to this already large (in terms of source files) change.? I >> originally thought we should remove MonitorLocker.? At least I don't >> think it should allow NULL. > > IIRC one of the suggested follow ups from the Mutex simplification was > to do away with Mutex and just have Monitor. I thought we wanted to have Monitor inherit from Mutex and add in the wait, notify, etc.? which is something I expected when first looking at this. Cleaning up this code is the gift that keeps giving. > > But you're right that anyone needing a MonitorLocker for wait etc can > never be using NULL. There is one: // Update the _full_collections_completed counter // at the end of a stop-world full GC. unsigned int GenCollectedHeap::update_full_collections_completed() { ? MonitorLocker ml(FullGCCount_lock, Mutex::_no_safepoint_check_flag); ? assert(_full_collections_completed <= _total_full_collections, ???????? "Can't complete more collections than were started"); ? _full_collections_completed = _total_full_collections; ? ml.notify_all(); ? return _full_collections_completed; } I think this should be fixed.?? FullGCCount_lock is NULL unless CMS or G1, but other collectors call this.? That's the only one I found. Thanks, Coleen > > David > ----- > >>> >>> Also if we remove the 3 sometimes lock and only have 'always' and >>> 'never' locks, >>> having the two version as different types would give you compile >>> errors instead of runtime asserts. >> >> We need to revise the discussion whether to require it to be explicit >> vs. implicit though.?? But this is good because now we can decide >> what to do about this one: >> https://bugs.openjdk.java.net/browse/JDK-8074355 >> >> Thanks, >> Coleen >> >>> >>> Thanks, Robbin >>> >>>> >>>> So I have a follow on patch wrt MonitorLocker.? Actually I've >>>> removed it.? Erik thought having a NULL monitor wait was crazy, >>>> even though we have a case of that in the GC. The code is split >>>> whether it uses the MonitorLocker local variable vs. the actual lock. >>>> >>>> The only code that consistently uses the MonitorLocker local like >>>> this is ZGC, so I was going to discuss the next change with you >>>> first anyway. >>>> >>>> I see your point about not having to say whether you're safepoint >>>> checking twice though.? People I've been talking to on the project >>>> are of two minds.? One set wants it always explicit, the other >>>> implicit.? I personally want consistency over all else, which is >>>> why I added wait_without_safepoint_check to MonitorLocker. >>>> >>>> I could change this with this patch.? It's easy enough to do, >>>> especially if you see value in MonitorLocker, which was going to be >>>> my next discussion with you. >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>>>> >>>>> cheers, >>>>> Per >>>>> >>>>> On 4/23/19 5:06 PM, coleen.phillimore at oracle.com wrote: >>>>>> Summary: Make MutexLocker be MutexLockerEx implementation, remove >>>>>> MutexLockerEx calls. Also added wait_without_safepoint_check(). >>>>>> >>>>>> Also made safepoint_check_flag an enum, renamed MonitorLockerEx >>>>>> to MonitorLocker, removed MutexUnlockerEx, and fixed formatting >>>>>> where affected by this change. >>>>>> >>>>>> There's a MutexLocker constructor with a Thread parameter that >>>>>> would actually be more performant if the thread is passed from >>>>>> the current context rather than calling Thread::current() in >>>>>> Monitor::lock.? I think the Thread parameter should be moved to >>>>>> first so that we can have MutexLocker look like the Handle >>>>>> constructor calls, for example.? I didn't make this change in this. >>>>>> >>>>>> ??? MutexLocker ml(THREAD, Monitor_lock). >>>>>> >>>>>> The interesting changes are in: >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutexLocker.hpp.udiff.html >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.hpp.udiff.html >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.cpp.udiff.html >>>>>> >>>>>> >>>>>> The rest is pattern substitution. >>>>>> >>>>>> Ran mach5 tier1-6 tests. >>>>>> >>>>>> open webrev at >>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8222811 >>>>>> >>>>>> Thanks! >>>>>> Coleen >>>>>> >>>>>> >>>> >> From sgehwolf at redhat.com Wed Apr 24 13:23:02 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 24 Apr 2019 15:23:02 +0200 Subject: RFR: 8221639: [x32] expand_exec_shield_cs_limit workaround is undefined code after JDK-8199717 In-Reply-To: <89ab6a7f-79a7-2556-29cb-5cc9289c8ae6@oracle.com> References: <673a0cc6b25fcfdcb3f3c69f4dcfd06d346e271a.camel@redhat.com> <6a9f74f3-a1de-fc2a-370b-c64055611fd9@oracle.com> <89ab6a7f-79a7-2556-29cb-5cc9289c8ae6@oracle.com> Message-ID: Hi David, On Wed, 2019-04-24 at 19:13 +1000, David Holmes wrote: > Hi Severin, > > Sorry for the delay, this slipped off my rader after the break. No worries. > On 19/04/2019 12:02 am, David Holmes wrote: > > Hi Severin, > > > > I'll have to delve into this more deeply (but I'm on Easter break for > > the next 4 days). I don't recall ever being aware of > > "suppress_primordial_thread_resolution"! > > Well I have a bad memory as I reviewed that particular optimisation. > > So, the exec_shield workaround requires knowing the process's primordial > thread stack regardless of whether the JVM is loaded on it or not. So it > assumes the initial_thread_stack has been determined, while we now avoid > doing that unnecessarily. > > Okay the suggested fix is okay to achieve that - though alternatively it > could be handled inside workaround_expand_exec_shield_cs_limit() via: > > // Need to ensure we've determined the process's initial stack to > // perform the workaround > if (suppress_primordial_thread_resolution) { > Linux::capture_initial_stack(JavaThread::stack_size_at_create()); > } > > I would like to see a comment like the above regardless of where you > make the change. Thanks for the review! Updated webrev with the comment: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221639/02/webrev/ Would this be a trivial change or do I need a second reviewer? FWIW, jdk/submit testing came back clean with this. Thanks, Severin > Thanks, > David > ------ > > > David > > > > On 18/04/2019 11:41 pm, Severin Gehwolf wrote: > > > Hi, > > > > > > Could I please get reviews for this Linux x32 fix? JDK-8199717 added a > > > performance optimization to only capture the initial stack size when > > > launched via non-java launchers. However, on Linux x32, there is old > > > code being executed to work around the exec shield CS limit. That code > > > depends on the initial stack size being captured. Right now this is > > > undefined code: Pointer artithmetic on NULL pointer. > > > > > > src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp:884:73: runtime error: > > > pointer index expression with base 0x00000000 overflowed to 0xffffb000 > > > > > > I propose to not perform the optimization of JDK-8199717 for Linux x32. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221639 > > > webrev: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221639/01/webrev/ > > > > > > Testing: release/fastdebug builds on x32 Linux, inspecting > > > -Xlog:os=info messages, currently running through jdkd/submit. Tier 1 > > > tests on Linux x86_64 > > > > > > Thoughts? > > > > > > Thanks, > > > Severin > > > From fweimer at redhat.com Wed Apr 24 13:33:29 2019 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 24 Apr 2019 15:33:29 +0200 Subject: RFR: 8221639: [x32] expand_exec_shield_cs_limit workaround is undefined code after JDK-8199717 In-Reply-To: <673a0cc6b25fcfdcb3f3c69f4dcfd06d346e271a.camel@redhat.com> (Severin Gehwolf's message of "Thu, 18 Apr 2019 15:41:09 +0200") References: <673a0cc6b25fcfdcb3f3c69f4dcfd06d346e271a.camel@redhat.com> Message-ID: <87k1fjh6ja.fsf@oldenburg2.str.redhat.com> * Severin Gehwolf: > Hi, > > Could I please get reviews for this Linux x32 fix? JDK-8199717 added a > performance optimization to only capture the initial stack size when > launched via non-java launchers. However, on Linux x32, Do you mean actual x32, or i386? These two are different. Can you actually verify changes in this area? I think it's pretty hard these days to find a machine that actually uses the CS hack to avoid universal read-implies-exec. I don't think this was ever part of any mainline kernel. Thanks, Florian From sgehwolf at redhat.com Wed Apr 24 13:50:43 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 24 Apr 2019 15:50:43 +0200 Subject: RFR: 8221639: [x32] expand_exec_shield_cs_limit workaround is undefined code after JDK-8199717 In-Reply-To: <87k1fjh6ja.fsf@oldenburg2.str.redhat.com> References: <673a0cc6b25fcfdcb3f3c69f4dcfd06d346e271a.camel@redhat.com> <87k1fjh6ja.fsf@oldenburg2.str.redhat.com> Message-ID: <83d540b383d3565b74fb14e84ce33ed0e36c062b.camel@redhat.com> Hi Florian, On Wed, 2019-04-24 at 15:33 +0200, Florian Weimer wrote: > * Severin Gehwolf: > > > Hi, > > > > Could I please get reviews for this Linux x32 fix? JDK-8199717 added a > > performance optimization to only capture the initial stack size when > > launched via non-java launchers. However, on Linux x32, > > Do you mean actual x32, or i386? These two are different. i386 > Can you actually verify changes in this area? I think it's pretty hard > these days to find a machine that actually uses the CS hack to avoid > universal read-implies-exec. I don't think this was ever part of any > mainline kernel. No, I cannot really verify the workaround itself. I can, however, see that the current code is undefined on i386. See the bug for details[1]. This snippet: char* hint = (char*)(Linux::initial_thread_stack_bottom() - (JavaThread::stack_guard_zone_size() + page_size)); Assumes Linux::initial_thread_stack_bottom() != NULL. In this case it's NULL and pointer arithmetic on a NULL pointer is UB. That's what this fix resolves. Thanks, Severin [1] https://bugs.openjdk.java.net/browse/JDK-8221639 From glaubitz at physik.fu-berlin.de Wed Apr 24 13:53:46 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 24 Apr 2019 15:53:46 +0200 Subject: RFR: 8221639: [x32] expand_exec_shield_cs_limit workaround is undefined code after JDK-8199717 In-Reply-To: <83d540b383d3565b74fb14e84ce33ed0e36c062b.camel@redhat.com> References: <673a0cc6b25fcfdcb3f3c69f4dcfd06d346e271a.camel@redhat.com> <87k1fjh6ja.fsf@oldenburg2.str.redhat.com> <83d540b383d3565b74fb14e84ce33ed0e36c062b.camel@redhat.com> Message-ID: On 4/24/19 3:50 PM, Severin Gehwolf wrote: >> Do you mean actual x32, or i386? These two are different. > > i386 I guess then there is no additional testing on Debian/x32 required. 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 per.liden at oracle.com Wed Apr 24 17:19:43 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 24 Apr 2019 19:19:43 +0200 Subject: RFR (L, tedious) 8222811: Consolidate MutexLockerEx and MutexLocker In-Reply-To: References: <614f0e46-c4ce-d389-88f9-1a73e14fc5dd@oracle.com> <13c77938-c70a-8f6d-7b3e-f4fc01ae989a@oracle.com> Message-ID: <0812b6f8-86c0-06c5-92e6-ff6be224a9cf@oracle.com> Hi Coleen, On 04/24/2019 01:18 PM, coleen.phillimore at oracle.com wrote: > > > On 4/24/19 3:57 AM, Per Liden wrote: >> Hi Coleen, >> >> I like this clean up. However, one thing that always bothered me is >> this pattern: > > Hi Per, Erik said you would like it. >> >> MonitorLockerEx ml(&_monitor, Monitor::_no_safepoint_check_flag); >> ... >> ml.wait(Monitor::_no_safepoint_check_flag); >> >> And with your patch it becomes: >> >> MonitorLocker ml(&_monitor, Monitor::_no_safepoint_check_flag); >> ... >> ml.wait_without_safepoint_check(); >> >> Now, it seems a bit silly, and potentially error prone, to always have >> to say "don't safepoint check" twice. We already told the >> MonitorLocker what to do when it was constructed, so can't we just >> have this: >> >> MonitorLocker ml(&_monitor, Monitor::_no_safepoint_check_flag); >> ... >> ml.wait(); >> >> Where wait() does the right thing, i.e. use the flag we passed into >> the constructor. Since all of MonitorLocker will be inlined, a flag >> check in wait() would be constant folded, so there's no overhead to >> worry about here. >> >> Can we please have this? > > So I have a follow on patch wrt MonitorLocker. Actually I've removed > it. Erik thought having a NULL monitor wait was crazy, even though we > have a case of that in the GC. The code is split whether it uses the > MonitorLocker local variable vs. the actual lock. > > The only code that consistently uses the MonitorLocker local like this > is ZGC, so I was going to discuss the next change with you first anyway. > > I see your point about not having to say whether you're safepoint > checking twice though. People I've been talking to on the project are > of two minds. One set wants it always explicit, the other implicit. I > personally want consistency over all else, which is why I added > wait_without_safepoint_check to MonitorLocker. > > I could change this with this patch. It's easy enough to do, especially > if you see value in MonitorLocker, which was going to be my next > discussion with you. I've also noticed that there's a slit in the code, some use the lock directly for wait/notify, and some use them via the MonitorLocker. I see a value in keeping MonitorLocker, especially if we can leave out the safepoint_check argument in wait(). Using the MonitorLocker tends to simplify code IMHO. cheers, Per > > Thanks, > Coleen > > >> >> cheers, >> Per >> >> On 4/23/19 5:06 PM, coleen.phillimore at oracle.com wrote: >>> Summary: Make MutexLocker be MutexLockerEx implementation, remove >>> MutexLockerEx calls. Also added wait_without_safepoint_check(). >>> >>> Also made safepoint_check_flag an enum, renamed MonitorLockerEx to >>> MonitorLocker, removed MutexUnlockerEx, and fixed formatting where >>> affected by this change. >>> >>> There's a MutexLocker constructor with a Thread parameter that would >>> actually be more performant if the thread is passed from the current >>> context rather than calling Thread::current() in Monitor::lock. I >>> think the Thread parameter should be moved to first so that we can >>> have MutexLocker look like the Handle constructor calls, for >>> example. I didn't make this change in this. >>> >>> MutexLocker ml(THREAD, Monitor_lock). >>> >>> The interesting changes are in: >>> >>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutexLocker.hpp.udiff.html >>> >>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.hpp.udiff.html >>> >>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.cpp.udiff.html >>> >>> >>> The rest is pattern substitution. >>> >>> Ran mach5 tier1-6 tests. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8222811 >>> >>> Thanks! >>> Coleen >>> >>> > From jesper.wilhelmsson at oracle.com Wed Apr 24 23:52:26 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 25 Apr 2019 01:52:26 +0200 Subject: RFR(xs): JDK-8222952 - Typo in test/hotspot/jtreg/TEST.groups is causing test harness failures Message-ID: <29DA2B63-B122-484F-A4CC-95318FCB8D77@oracle.com> Hi, Please review this small patch to fix a typo in TEST.groups introduced by JDK-8213501. This is causing failures in every tier 5 run. Bug: https://bugs.openjdk.java.net/browse/JDK-8222952 Patch: diff --git a/test/hotspot/jtreg/TEST.groups b/test/hotspot/jtreg/TEST.groups --- a/test/hotspot/jtreg/TEST.groups +++ b/test/hotspot/jtreg/TEST.groups @@ -439,7 +439,7 @@ # JVMTI tests vmTestbase_nsk_jvmti = \ vmTestbase/nsk/jvmti \ - vmTestbase/nsk/share/ExceptionCheckingJniEnv + vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv # JDWP tests vmTestbase_nsk_jdwp = \ Thanks, /Jesper From joe.darcy at oracle.com Thu Apr 25 00:11:28 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 24 Apr 2019 17:11:28 -0700 Subject: RFR(xs): JDK-8222952 - Typo in test/hotspot/jtreg/TEST.groups is causing test harness failures In-Reply-To: <29DA2B63-B122-484F-A4CC-95318FCB8D77@oracle.com> References: <29DA2B63-B122-484F-A4CC-95318FCB8D77@oracle.com> Message-ID: <5CC0FB30.2070502@oracle.com> Looks fine Jesper; cheers, -Joe On 4/24/2019 4:52 PM, jesper.wilhelmsson at oracle.com wrote: > Hi, > > Please review this small patch to fix a typo in TEST.groups introduced by JDK-8213501. This is causing failures in every tier 5 run. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222952 > Patch: > > diff --git a/test/hotspot/jtreg/TEST.groups b/test/hotspot/jtreg/TEST.groups > --- a/test/hotspot/jtreg/TEST.groups > +++ b/test/hotspot/jtreg/TEST.groups > @@ -439,7 +439,7 @@ > # JVMTI tests > vmTestbase_nsk_jvmti = \ > vmTestbase/nsk/jvmti \ > - vmTestbase/nsk/share/ExceptionCheckingJniEnv > + vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv > > # JDWP tests > vmTestbase_nsk_jdwp = \ > > > Thanks, > /Jesper > From jesper.wilhelmsson at oracle.com Thu Apr 25 00:12:30 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 25 Apr 2019 02:12:30 +0200 Subject: RFR(xs): JDK-8222952 - Typo in test/hotspot/jtreg/TEST.groups is causing test harness failures In-Reply-To: <5CC0FB30.2070502@oracle.com> References: <29DA2B63-B122-484F-A4CC-95318FCB8D77@oracle.com> <5CC0FB30.2070502@oracle.com> Message-ID: <6C0DA621-F835-4944-8948-542B08B7F765@oracle.com> Thanks Joe! /Jesper > On 25 Apr 2019, at 02:11, Joseph D. Darcy wrote: > > Looks fine Jesper; cheers, > > -Joe > > On 4/24/2019 4:52 PM, jesper.wilhelmsson at oracle.com wrote: >> Hi, >> >> Please review this small patch to fix a typo in TEST.groups introduced by JDK-8213501. This is causing failures in every tier 5 run. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8222952 >> Patch: >> >> diff --git a/test/hotspot/jtreg/TEST.groups b/test/hotspot/jtreg/TEST.groups >> --- a/test/hotspot/jtreg/TEST.groups >> +++ b/test/hotspot/jtreg/TEST.groups >> @@ -439,7 +439,7 @@ >> # JVMTI tests >> vmTestbase_nsk_jvmti = \ >> vmTestbase/nsk/jvmti \ >> - vmTestbase/nsk/share/ExceptionCheckingJniEnv >> + vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv >> >> # JDWP tests >> vmTestbase_nsk_jdwp = \ >> >> >> Thanks, >> /Jesper >> > From mikhailo.seledtsov at oracle.com Thu Apr 25 00:12:57 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Wed, 24 Apr 2019 17:12:57 -0700 Subject: RFR(xs): JDK-8222952 - Typo in test/hotspot/jtreg/TEST.groups is causing test harness failures In-Reply-To: <5CC0FB30.2070502@oracle.com> References: <29DA2B63-B122-484F-A4CC-95318FCB8D77@oracle.com> <5CC0FB30.2070502@oracle.com> Message-ID: <17391d6f-3a04-6453-8729-ff28a585da57@oracle.com> +1 Misha On 4/24/19 5:11 PM, Joseph D. Darcy wrote: > Looks fine Jesper; cheers, > > -Joe > > On 4/24/2019 4:52 PM, jesper.wilhelmsson at oracle.com wrote: >> Hi, >> >> Please review this small patch to fix a typo in TEST.groups >> introduced by JDK-8213501. This is causing failures in every tier 5 run. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8222952 >> Patch: >> >> diff --git a/test/hotspot/jtreg/TEST.groups >> b/test/hotspot/jtreg/TEST.groups >> --- a/test/hotspot/jtreg/TEST.groups >> +++ b/test/hotspot/jtreg/TEST.groups >> @@ -439,7 +439,7 @@ >> ? # JVMTI tests >> ? vmTestbase_nsk_jvmti = \ >> ??? vmTestbase/nsk/jvmti \ >> -? vmTestbase/nsk/share/ExceptionCheckingJniEnv >> +? vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv >> >> ? # JDWP tests >> ? vmTestbase_nsk_jdwp = \ >> >> >> Thanks, >> /Jesper >> > From jesper.wilhelmsson at oracle.com Thu Apr 25 00:16:31 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 25 Apr 2019 02:16:31 +0200 Subject: RFR(xs): JDK-8222952 - Typo in test/hotspot/jtreg/TEST.groups is causing test harness failures In-Reply-To: <17391d6f-3a04-6453-8729-ff28a585da57@oracle.com> References: <29DA2B63-B122-484F-A4CC-95318FCB8D77@oracle.com> <5CC0FB30.2070502@oracle.com> <17391d6f-3a04-6453-8729-ff28a585da57@oracle.com> Message-ID: Thanks Misha! /Jesper > On 25 Apr 2019, at 02:12, mikhailo.seledtsov at oracle.com wrote: > > +1 > > Misha > > > On 4/24/19 5:11 PM, Joseph D. Darcy wrote: >> Looks fine Jesper; cheers, >> >> -Joe >> >> On 4/24/2019 4:52 PM, jesper.wilhelmsson at oracle.com wrote: >>> Hi, >>> >>> Please review this small patch to fix a typo in TEST.groups introduced by JDK-8213501. This is causing failures in every tier 5 run. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222952 >>> Patch: >>> >>> diff --git a/test/hotspot/jtreg/TEST.groups b/test/hotspot/jtreg/TEST.groups >>> --- a/test/hotspot/jtreg/TEST.groups >>> +++ b/test/hotspot/jtreg/TEST.groups >>> @@ -439,7 +439,7 @@ >>> # JVMTI tests >>> vmTestbase_nsk_jvmti = \ >>> vmTestbase/nsk/jvmti \ >>> - vmTestbase/nsk/share/ExceptionCheckingJniEnv >>> + vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv >>> >>> # JDWP tests >>> vmTestbase_nsk_jdwp = \ >>> >>> >>> Thanks, >>> /Jesper >>> >> > From igor.ignatyev at oracle.com Thu Apr 25 02:07:07 2019 From: igor.ignatyev at oracle.com (Igor Ignatev) Date: Wed, 24 Apr 2019 19:07:07 -0700 Subject: RFR(xs): JDK-8222952 - Typo in test/hotspot/jtreg/TEST.groups is causing test harness failures In-Reply-To: References: <29DA2B63-B122-484F-A4CC-95318FCB8D77@oracle.com> <5CC0FB30.2070502@oracle.com> <17391d6f-3a04-6453-8729-ff28a585da57@oracle.com> Message-ID: <08C2E9D6-66F4-47EA-90B1-7CCC020B8498@oracle.com> I guess this fix isn?t needed (and is actually incorrect) after the fix for 8222935 is integrated. CC?ing JC. ? Igor > On Apr 24, 2019, at 5:16 PM, jesper.wilhelmsson at oracle.com wrote: > > Thanks Misha! > /Jesper > >> On 25 Apr 2019, at 02:12, mikhailo.seledtsov at oracle.com wrote: >> >> +1 >> >> Misha >> >> >>> On 4/24/19 5:11 PM, Joseph D. Darcy wrote: >>> Looks fine Jesper; cheers, >>> >>> -Joe >>> >>>> On 4/24/2019 4:52 PM, jesper.wilhelmsson at oracle.com wrote: >>>> Hi, >>>> >>>> Please review this small patch to fix a typo in TEST.groups introduced by JDK-8213501. This is causing failures in every tier 5 run. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222952 >>>> Patch: >>>> >>>> diff --git a/test/hotspot/jtreg/TEST.groups b/test/hotspot/jtreg/TEST.groups >>>> --- a/test/hotspot/jtreg/TEST.groups >>>> +++ b/test/hotspot/jtreg/TEST.groups >>>> @@ -439,7 +439,7 @@ >>>> # JVMTI tests >>>> vmTestbase_nsk_jvmti = \ >>>> vmTestbase/nsk/jvmti \ >>>> - vmTestbase/nsk/share/ExceptionCheckingJniEnv >>>> + vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv >>>> >>>> # JDWP tests >>>> vmTestbase_nsk_jdwp = \ >>>> >>>> >>>> Thanks, >>>> /Jesper >>>> >>> >> > From jcbeyler at google.com Thu Apr 25 02:45:38 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 24 Apr 2019 19:45:38 -0700 Subject: RFR(xs): JDK-8222952 - Typo in test/hotspot/jtreg/TEST.groups is causing test harness failures In-Reply-To: <08C2E9D6-66F4-47EA-90B1-7CCC020B8498@oracle.com> References: <29DA2B63-B122-484F-A4CC-95318FCB8D77@oracle.com> <5CC0FB30.2070502@oracle.com> <17391d6f-3a04-6453-8729-ff28a585da57@oracle.com> <08C2E9D6-66F4-47EA-90B1-7CCC020B8498@oracle.com> Message-ID: Yes this is incorrect, I forgot to put the files for the tests (sorry). This fix is just adding the wrong path... Sorry about the confusion and waste of time, I got the LGTM and will be pushing the fix shortly, Jc On Wed, Apr 24, 2019 at 7:07 PM Igor Ignatev wrote: > I guess this fix isn?t needed (and is actually incorrect) after the fix > for 8222935 is > integrated. CC?ing JC. > > ? Igor > > On Apr 24, 2019, at 5:16 PM, jesper.wilhelmsson at oracle.com wrote: > > Thanks Misha! > /Jesper > > On 25 Apr 2019, at 02:12, mikhailo.seledtsov at oracle.com wrote: > > > +1 > > > Misha > > > > On 4/24/19 5:11 PM, Joseph D. Darcy wrote: > > Looks fine Jesper; cheers, > > > -Joe > > > On 4/24/2019 4:52 PM, jesper.wilhelmsson at oracle.com wrote: > > Hi, > > > Please review this small patch to fix a typo in TEST.groups introduced by > JDK-8213501. This is causing failures in every tier 5 run. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222952 > > Patch: > > > diff --git a/test/hotspot/jtreg/TEST.groups > b/test/hotspot/jtreg/TEST.groups > > --- a/test/hotspot/jtreg/TEST.groups > > +++ b/test/hotspot/jtreg/TEST.groups > > @@ -439,7 +439,7 @@ > > # JVMTI tests > > vmTestbase_nsk_jvmti = \ > > vmTestbase/nsk/jvmti \ > > - vmTestbase/nsk/share/ExceptionCheckingJniEnv > > + vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv > > > # JDWP tests > > vmTestbase_nsk_jdwp = \ > > > > Thanks, > > /Jesper > > > > > > -- Thanks, Jc From jcbeyler at google.com Thu Apr 25 02:52:47 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 24 Apr 2019 19:52:47 -0700 Subject: RFR(xs): JDK-8222952 - Typo in test/hotspot/jtreg/TEST.groups is causing test harness failures In-Reply-To: References: <29DA2B63-B122-484F-A4CC-95318FCB8D77@oracle.com> <5CC0FB30.2070502@oracle.com> <17391d6f-3a04-6453-8729-ff28a585da57@oracle.com> <08C2E9D6-66F4-47EA-90B1-7CCC020B8498@oracle.com> Message-ID: Pushed so normally this should be fixed (let me know if not ... :-(), Jc On Wed, Apr 24, 2019 at 7:45 PM Jean Christophe Beyler wrote: > Yes this is incorrect, I forgot to put the files for the tests (sorry). > This fix is just adding the wrong path... > > Sorry about the confusion and waste of time, I got the LGTM and will be > pushing the fix shortly, > Jc > > On Wed, Apr 24, 2019 at 7:07 PM Igor Ignatev > wrote: > >> I guess this fix isn?t needed (and is actually incorrect) after the fix >> for 8222935 is >> integrated. CC?ing JC. >> >> ? Igor >> >> On Apr 24, 2019, at 5:16 PM, jesper.wilhelmsson at oracle.com wrote: >> >> Thanks Misha! >> /Jesper >> >> On 25 Apr 2019, at 02:12, mikhailo.seledtsov at oracle.com wrote: >> >> >> +1 >> >> >> Misha >> >> >> >> On 4/24/19 5:11 PM, Joseph D. Darcy wrote: >> >> Looks fine Jesper; cheers, >> >> >> -Joe >> >> >> On 4/24/2019 4:52 PM, jesper.wilhelmsson at oracle.com wrote: >> >> Hi, >> >> >> Please review this small patch to fix a typo in TEST.groups introduced by >> JDK-8213501. This is causing failures in every tier 5 run. >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8222952 >> >> Patch: >> >> >> diff --git a/test/hotspot/jtreg/TEST.groups >> b/test/hotspot/jtreg/TEST.groups >> >> --- a/test/hotspot/jtreg/TEST.groups >> >> +++ b/test/hotspot/jtreg/TEST.groups >> >> @@ -439,7 +439,7 @@ >> >> # JVMTI tests >> >> vmTestbase_nsk_jvmti = \ >> >> vmTestbase/nsk/jvmti \ >> >> - vmTestbase/nsk/share/ExceptionCheckingJniEnv >> >> + vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv >> >> >> # JDWP tests >> >> vmTestbase_nsk_jdwp = \ >> >> >> >> Thanks, >> >> /Jesper >> >> >> >> >> >> > > -- > > Thanks, > Jc > -- Thanks, Jc From per.liden at oracle.com Thu Apr 25 12:33:26 2019 From: per.liden at oracle.com (Per Liden) Date: Thu, 25 Apr 2019 14:33:26 +0200 Subject: RFR (L, tedious) 8222811: Consolidate MutexLockerEx and MutexLocker In-Reply-To: <2d1b8ba1-bda1-78c3-b2b0-13774177fcd3@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> <2d1b8ba1-bda1-78c3-b2b0-13774177fcd3@oracle.com> Message-ID: Thanks Coleen! Looks good to me, and the ZGC parts too. cheers, Per On 2019-04-24 13:57, coleen.phillimore at oracle.com wrote: > > I made the change suggested by Per and it's quite nice.? I also fixed > Mutex to not have bodies for the private functions since that's not > required to get a compilation error if one uses them. > > http://cr.openjdk.java.net/~coleenp/2019/8222811.03.incr/webrev/index.html > > Running again through mach5. > > Thanks, > Coleen > > On 4/24/19 7:23 AM, coleen.phillimore at oracle.com wrote: >> >> >> On 4/23/19 9:48 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 24/04/2019 8:49 am, coleen.phillimore at oracle.com wrote: >>>> >>>> Here's a new webrev with the changes requested by Dan. >>>> >>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.02/webrev >>> >>> Overall this seems fine. A few comments on the main changes: >>> >>> mutex.cpp >>> >>> ?156 bool Monitor::wait_without_safepoint_check(long timeout) { >>> ?157?? // Make sure safepoint checking is used properly. >>> ?158?? assert(_safepoint_check_required != >>> Monitor::_safepoint_check_always, >>> ?159????????? "This lock should never have a safepoint check: %s", >>> name()); >>> >>> The message is the wrong one: s/never/always/ >> >> I had both of these messages reversed in wait*() functions wrt. >> never/always.? If a lock L has safepoint_check_required = always and >> locks or waits without safepoint check, the message is relative to the >> lock, not the erroneous call.? Inverse for never. >> >> Thanks for finding this. >>> >>> wait_without_safepoint_check is missing: >>> >>> ? // timeout is in milliseconds - with zero meaning never timeout >>> ? assert(timeout >= 0, "negative timeout"); >>> >> >> Fixed. >> >>> --- >>> >>> mutexLocker.hpp >>> >>> 190? protected: >>> 191?? Monitor* _mutex; >>> >>> Good catch on the redundant extra field in MonitorLocker! >> >> Thanks. >>> >>> 208?? MutexLocker(Monitor* mutex, Thread* thread, >>> Mutex::SafepointCheckFlag flag = Mutex::_safepoint_check_flag) : >>> >>> 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. >> >> I also want to have a patch (I think I said this), to make the Thread >> argument first.? I could try some more tricks to avoid this >> duplication when/if I do that.?? How does that sound? >> >> Thanks for reviewing! >> Coleen >> >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Coleen >>>> >>>> On 4/23/19 6:18 PM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> Hi Dan, Thank you for tackling this code review.? I was hoping you >>>>> wouldn't do your usual file-by-file comments.? It would have been >>>>> long. >>>>> >>>>> On 4/23/19 5:43 PM, Daniel D. Daugherty wrote: >>>>>> On 4/23/19 11:06 AM, coleen.phillimore at oracle.com wrote: >>>>>>> Summary: Make MutexLocker be MutexLockerEx implementation, remove >>>>>>> MutexLockerEx calls. Also added wait_without_safepoint_check(). >>>>>>> >>>>>>> Also made safepoint_check_flag an enum, renamed MonitorLockerEx >>>>>>> to MonitorLocker, removed MutexUnlockerEx, and fixed formatting >>>>>>> where affected by this change. >>>>>>> >>>>>>> There's a MutexLocker constructor with a Thread parameter that >>>>>>> would actually be more performant if the thread is passed from >>>>>>> the current context rather than calling Thread::current() in >>>>>>> Monitor::lock.? I think the Thread parameter should be moved to >>>>>>> first so that we can have MutexLocker look like the Handle >>>>>>> constructor calls, for example.? I didn't make this change in this. >>>>>>> >>>>>>> ?? MutexLocker ml(THREAD, Monitor_lock). >>>>>>> >>>>>>> The interesting changes are in: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutexLocker.hpp.udiff.html >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.hpp.udiff.html >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> The rest is pattern substitution. >>>>>>> >>>>>>> Ran mach5 tier1-6 tests. >>>>>>> >>>>>>> open webrev at >>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev >>>>>> >>>>>> src/hotspot/share/runtime/mutexLocker.hpp >>>>>> ??? L198: ????? assert(_mutex->rank() > Mutex::special || >>>>>> no_safepoint_check, >>>>>> ??? L199: ??????? "Mutexes with rank special or lower should not >>>>>> do safepoint checks"); >>>>>> ??????? nit - indent on L199 needs 5 more spaces >>>>>> >>>>>> ??? L200-203 - this if-block is missing the usual HotSpot '{' and >>>>>> '}'. >>>>>> ??? (Not your fault, but since you're in there...) >>>>>> >>>>>> ??? L211: ????? assert(_mutex->rank() > Mutex::special || >>>>>> no_safepoint_check, >>>>>> ??? L212: ??????? "Mutexes with rank special or lower should not >>>>>> do safepoint checks"); >>>>>> ??????? nit - indent on L211 needs 5 more spaces >>>>>> >>>>>> ??? L213-216 - this if-block is missing the usual HotSpot '{' and >>>>>> '}'. >>>>>> ??? (Not your fault, but since you're in there...) >>>>> >>>>> Fixed all of these.? Since I've touched it, I made it follow the >>>>> coding style. >>>>> >>>>>> >>>>>> src/hotspot/share/runtime/mutex.hpp >>>>>> ??? L237: ?? // why do these need bodies? >>>>>> ??????? To prevent any calls to Mutex::notify(), Mutex::notify_all(), >>>>>> ??????? Mutex::wait() and Mutex::wait_without_safepoint_check() from >>>>>> ??????? calling the superclass' version of those functions. >>>>>> >>>>> >>>>> I forgot to check this, but if they're private, they shouldn't need >>>>> bodies.? I'll remove the comment and leave them for now. >>>>> >>>>> >>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>> ??? Nice detangling into Monitor::wait() and >>>>>> ??? Monitor::wait_without_safepoint_check(). >>>>>> >>>>> Thank you! >>>>> >>>>>> >>>>>> For the rest of the files, I went through the patch from bottom -> >>>>>> top >>>>>> and looked for anything that didn't look right. I figure other >>>>>> reviewers >>>>>> are looking from top -> bottom... :-) >>>>>> >>>>>> For the multi-line MutexLocker uses in >>>>>> src/hotspot/share/runtime/vmThread.cpp >>>>>> and src/hotspot/share/memory/metaspace.cpp, >>>>>> the second line indents appear to be off by two spaces (because >>>>>> "Ex" was removed). >>>>>> Don't know if you want to fix those or not. Your call. >>>>> >>>>> You have good eyes.? I checked all of these this morning and I >>>>> missed these files.? Thank you. >>>>>> >>>>>> src/hotspot/share/runtime/threadSMR.cpp >>>>>> >>>>>> ? - >>>>>> ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, >>>>>> 0, >>>>>> ? - !Mutex::_as_suspend_equivalent_flag); >>>>>> ? + ThreadsSMRSupport::delete_lock()->wait_without_safepoint_check(); >>>>>> >>>>>> ? You dropped the '!Mutex::_as_suspend_equivalent_flag' flag. I >>>>>> dislike >>>>>> ? default values so that's why I included it. Now the reader has to >>>>>> ? ? 1) remember that there's another parameter >>>>>> ? ? 2) go find the default value for that parameter >>>>> >>>>> wait_without_safepoint_check() doesn't have as_suspend_equivalent >>>>> flag as a parameter.? That code was only used in the safepoint >>>>> checking case for wait.?? I dislike default parameters too for the >>>>> same reasons.? Both waits take 0 as the timeout default parameter >>>>> but I thought that was not a good thing to change. >>>>> >>>>>> >>>>>> src/hotspot/share/gc/shared/workgroup.cpp >>>>>> ? This change does not parse: >>>>>> >>>>>> ?? ? ? // The VM thread should not execute here because >>>>>> MutexLocker's are used >>>>>> ? ? -? // as (opposed to MutexLockerEx's). >>>>>> ? ? +? // as (opposed to MutexLocker's). >>>>>> >>>>>> ? since MutexLocker is now on both sides of the verbal comparison. >>>>> Yeah, I missed that too.? It doesn't actually make sense before >>>>> either, since there isn't a MutexLocker nearby. >>>>> >>>>>> >>>>>> In some cases, there were multi-line MutexLocker uses that you chose >>>>>> to combine into a single line, but in most cases you did not combine >>>>>> them. I couldn't discern a rhyme or reason for the choices (not even >>>>>> a line length of 80). >>>>> >>>>> I combined them if the length wasn't "too long" and it didn't look >>>>> like the whitespace was helpful.? I did both. >>>>>> >>>>>> There is a startling number of names in use for the MutexLocker >>>>>> variables. My personal preference would be for 'ml' (and 'ul' >>>>>> for the MutexUnlocker). You have an opportunity to make them all >>>>>> consistent, but that's hard to do. >>>>> >>>>> By convention, ml is used a lot but sometimes you can't use it.? I >>>>> don't want to change this.? Sometimes people pick names they like >>>>> for this. >>>>>> >>>>>> Thumbs up! If you choose to handle and of my comments above, >>>>>> I don't need to see another webrev. >>>>> >>>>> Thank you Dan for reviewing this!? I'll retest with edits made for >>>>> comments above. >>>>> >>>>> Coleen >>>>> >>>>>> >>>>>> Dan >>>>>> >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8222811 >>>>>>> >>>>>>> Thanks! >>>>>>> Coleen >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > From coleen.phillimore at oracle.com Thu Apr 25 13:07:24 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 25 Apr 2019 09:07:24 -0400 Subject: RFR (L, tedious) 8222811: Consolidate MutexLockerEx and MutexLocker In-Reply-To: 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> <2d1b8ba1-bda1-78c3-b2b0-13774177fcd3@oracle.com> Message-ID: Thanks, Per! Coleen On 4/25/19 8:33 AM, Per Liden wrote: > Thanks Coleen! Looks good to me, and the ZGC parts too. > > cheers, > Per > > On 2019-04-24 13:57, coleen.phillimore at oracle.com wrote: >> >> I made the change suggested by Per and it's quite nice.? I also fixed >> Mutex to not have bodies for the private functions since that's not >> required to get a compilation error if one uses them. >> >> http://cr.openjdk.java.net/~coleenp/2019/8222811.03.incr/webrev/index.html >> >> >> Running again through mach5. >> >> Thanks, >> Coleen >> >> On 4/24/19 7:23 AM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 4/23/19 9:48 PM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> On 24/04/2019 8:49 am, coleen.phillimore at oracle.com wrote: >>>>> >>>>> Here's a new webrev with the changes requested by Dan. >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.02/webrev >>>> >>>> Overall this seems fine. A few comments on the main changes: >>>> >>>> mutex.cpp >>>> >>>> ?156 bool Monitor::wait_without_safepoint_check(long timeout) { >>>> ?157?? // Make sure safepoint checking is used properly. >>>> ?158?? assert(_safepoint_check_required != >>>> Monitor::_safepoint_check_always, >>>> ?159????????? "This lock should never have a safepoint check: %s", >>>> name()); >>>> >>>> The message is the wrong one: s/never/always/ >>> >>> I had both of these messages reversed in wait*() functions wrt. >>> never/always.? If a lock L has safepoint_check_required = always and >>> locks or waits without safepoint check, the message is relative to >>> the lock, not the erroneous call.? Inverse for never. >>> >>> Thanks for finding this. >>>> >>>> wait_without_safepoint_check is missing: >>>> >>>> ? // timeout is in milliseconds - with zero meaning never timeout >>>> ? assert(timeout >= 0, "negative timeout"); >>>> >>> >>> Fixed. >>> >>>> --- >>>> >>>> mutexLocker.hpp >>>> >>>> 190? protected: >>>> 191?? Monitor* _mutex; >>>> >>>> Good catch on the redundant extra field in MonitorLocker! >>> >>> Thanks. >>>> >>>> 208?? MutexLocker(Monitor* mutex, Thread* thread, >>>> Mutex::SafepointCheckFlag flag = Mutex::_safepoint_check_flag) : >>>> >>>> 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. >>> >>> I also want to have a patch (I think I said this), to make the >>> Thread argument first.? I could try some more tricks to avoid this >>> duplication when/if I do that.?? How does that sound? >>> >>> Thanks for reviewing! >>> Coleen >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 4/23/19 6:18 PM, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>> Hi Dan, Thank you for tackling this code review.? I was hoping >>>>>> you wouldn't do your usual file-by-file comments.? It would have >>>>>> been long. >>>>>> >>>>>> On 4/23/19 5:43 PM, Daniel D. Daugherty wrote: >>>>>>> On 4/23/19 11:06 AM, coleen.phillimore at oracle.com wrote: >>>>>>>> Summary: Make MutexLocker be MutexLockerEx implementation, >>>>>>>> remove MutexLockerEx calls. Also added >>>>>>>> wait_without_safepoint_check(). >>>>>>>> >>>>>>>> Also made safepoint_check_flag an enum, renamed MonitorLockerEx >>>>>>>> to MonitorLocker, removed MutexUnlockerEx, and fixed formatting >>>>>>>> where affected by this change. >>>>>>>> >>>>>>>> There's a MutexLocker constructor with a Thread parameter that >>>>>>>> would actually be more performant if the thread is passed from >>>>>>>> the current context rather than calling Thread::current() in >>>>>>>> Monitor::lock.? I think the Thread parameter should be moved to >>>>>>>> first so that we can have MutexLocker look like the Handle >>>>>>>> constructor calls, for example.? I didn't make this change in >>>>>>>> this. >>>>>>>> >>>>>>>> ?? MutexLocker ml(THREAD, Monitor_lock). >>>>>>>> >>>>>>>> The interesting changes are in: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutexLocker.hpp.udiff.html >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.hpp.udiff.html >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.cpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> The rest is pattern substitution. >>>>>>>> >>>>>>>> Ran mach5 tier1-6 tests. >>>>>>>> >>>>>>>> open webrev at >>>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev >>>>>>> >>>>>>> src/hotspot/share/runtime/mutexLocker.hpp >>>>>>> ??? L198: ????? assert(_mutex->rank() > Mutex::special || >>>>>>> no_safepoint_check, >>>>>>> ??? L199: ??????? "Mutexes with rank special or lower should not >>>>>>> do safepoint checks"); >>>>>>> ??????? nit - indent on L199 needs 5 more spaces >>>>>>> >>>>>>> ??? L200-203 - this if-block is missing the usual HotSpot '{' >>>>>>> and '}'. >>>>>>> ??? (Not your fault, but since you're in there...) >>>>>>> >>>>>>> ??? L211: ????? assert(_mutex->rank() > Mutex::special || >>>>>>> no_safepoint_check, >>>>>>> ??? L212: ??????? "Mutexes with rank special or lower should not >>>>>>> do safepoint checks"); >>>>>>> ??????? nit - indent on L211 needs 5 more spaces >>>>>>> >>>>>>> ??? L213-216 - this if-block is missing the usual HotSpot '{' >>>>>>> and '}'. >>>>>>> ??? (Not your fault, but since you're in there...) >>>>>> >>>>>> Fixed all of these.? Since I've touched it, I made it follow the >>>>>> coding style. >>>>>> >>>>>>> >>>>>>> src/hotspot/share/runtime/mutex.hpp >>>>>>> ??? L237: ?? // why do these need bodies? >>>>>>> ??????? To prevent any calls to Mutex::notify(), >>>>>>> Mutex::notify_all(), >>>>>>> ??????? Mutex::wait() and Mutex::wait_without_safepoint_check() >>>>>>> from >>>>>>> ??????? calling the superclass' version of those functions. >>>>>>> >>>>>> >>>>>> I forgot to check this, but if they're private, they shouldn't >>>>>> need bodies.? I'll remove the comment and leave them for now. >>>>>> >>>>>> >>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>> ??? Nice detangling into Monitor::wait() and >>>>>>> ??? Monitor::wait_without_safepoint_check(). >>>>>>> >>>>>> Thank you! >>>>>> >>>>>>> >>>>>>> For the rest of the files, I went through the patch from bottom >>>>>>> -> top >>>>>>> and looked for anything that didn't look right. I figure other >>>>>>> reviewers >>>>>>> are looking from top -> bottom... :-) >>>>>>> >>>>>>> For the multi-line MutexLocker uses in >>>>>>> src/hotspot/share/runtime/vmThread.cpp >>>>>>> and src/hotspot/share/memory/metaspace.cpp, >>>>>>> the second line indents appear to be off by two spaces (because >>>>>>> "Ex" was removed). >>>>>>> Don't know if you want to fix those or not. Your call. >>>>>> >>>>>> You have good eyes.? I checked all of these this morning and I >>>>>> missed these files.? Thank you. >>>>>>> >>>>>>> src/hotspot/share/runtime/threadSMR.cpp >>>>>>> >>>>>>> ? - >>>>>>> ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, >>>>>>> 0, >>>>>>> ? - !Mutex::_as_suspend_equivalent_flag); >>>>>>> ? + >>>>>>> ThreadsSMRSupport::delete_lock()->wait_without_safepoint_check(); >>>>>>> >>>>>>> ? You dropped the '!Mutex::_as_suspend_equivalent_flag' flag. I >>>>>>> dislike >>>>>>> ? default values so that's why I included it. Now the reader has to >>>>>>> ? ? 1) remember that there's another parameter >>>>>>> ? ? 2) go find the default value for that parameter >>>>>> >>>>>> wait_without_safepoint_check() doesn't have as_suspend_equivalent >>>>>> flag as a parameter.? That code was only used in the safepoint >>>>>> checking case for wait. I dislike default parameters too for the >>>>>> same reasons. Both waits take 0 as the timeout default parameter >>>>>> but I thought that was not a good thing to change. >>>>>> >>>>>>> >>>>>>> src/hotspot/share/gc/shared/workgroup.cpp >>>>>>> ? This change does not parse: >>>>>>> >>>>>>> ?? ? ? // The VM thread should not execute here because >>>>>>> MutexLocker's are used >>>>>>> ? ? -? // as (opposed to MutexLockerEx's). >>>>>>> ? ? +? // as (opposed to MutexLocker's). >>>>>>> >>>>>>> ? since MutexLocker is now on both sides of the verbal comparison. >>>>>> Yeah, I missed that too.? It doesn't actually make sense before >>>>>> either, since there isn't a MutexLocker nearby. >>>>>> >>>>>>> >>>>>>> In some cases, there were multi-line MutexLocker uses that you >>>>>>> chose >>>>>>> to combine into a single line, but in most cases you did not >>>>>>> combine >>>>>>> them. I couldn't discern a rhyme or reason for the choices (not >>>>>>> even >>>>>>> a line length of 80). >>>>>> >>>>>> I combined them if the length wasn't "too long" and it didn't >>>>>> look like the whitespace was helpful.? I did both. >>>>>>> >>>>>>> There is a startling number of names in use for the MutexLocker >>>>>>> variables. My personal preference would be for 'ml' (and 'ul' >>>>>>> for the MutexUnlocker). You have an opportunity to make them all >>>>>>> consistent, but that's hard to do. >>>>>> >>>>>> By convention, ml is used a lot but sometimes you can't use it.? >>>>>> I don't want to change this.? Sometimes people pick names they >>>>>> like for this. >>>>>>> >>>>>>> Thumbs up! If you choose to handle and of my comments above, >>>>>>> I don't need to see another webrev. >>>>>> >>>>>> Thank you Dan for reviewing this!? I'll retest with edits made >>>>>> for comments above. >>>>>> >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8222811 >>>>>>>> >>>>>>>> Thanks! >>>>>>>> Coleen >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >> From daniel.daugherty at oracle.com Thu Apr 25 14:27:13 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 25 Apr 2019 10:27:13 -0400 Subject: RFR (L, tedious) 8222811: Consolidate MutexLockerEx and MutexLocker In-Reply-To: <2d1b8ba1-bda1-78c3-b2b0-13774177fcd3@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> <2d1b8ba1-bda1-78c3-b2b0-13774177fcd3@oracle.com> Message-ID: <2fabd9b2-217d-1661-74f3-55d326611226@oracle.com> On 4/24/19 7:57 AM, coleen.phillimore at oracle.com wrote: > > I made the change suggested by Per and it's quite nice.? I also fixed > Mutex to not have bodies for the private functions since that's not > required to get a compilation error if one uses them. > > http://cr.openjdk.java.net/~coleenp/2019/8222811.03.incr/webrev/index.html > src/hotspot/share/runtime/mutexLocker.hpp ??? No comments. src/hotspot/share/runtime/mutex.hpp ??? L237: ?? void notify (); ??? L239: ?? bool wait (long timeout, bool as_suspend_equivalent); ??????? nit - Please delete the space before '('. src/hotspot/share/runtime/mutex.cpp ??? No comments. src/hotspot/share/compiler/compileBroker.cpp src/hotspot/share/gc/g1/g1StringDedupQueue.cpp src/hotspot/share/gc/shared/owstTaskTerminator.cpp src/hotspot/share/gc/shared/suspendibleThreadSet.cpp src/hotspot/share/gc/shared/workgroup.cpp src/hotspot/share/gc/z/zMessagePort.inline.hpp src/hotspot/share/gc/z/zMetronome.cpp src/hotspot/share/gc/z/zRuntimeWorkers.cpp src/hotspot/share/gc/z/zWorkers.cpp src/hotspot/share/runtime/init.cpp src/hotspot/share/runtime/serviceThread.cpp ??? No comments. Thumbs up. No need for a new webrev if you fix the space issue above. Dan > > Running again through mach5. > > Thanks, > Coleen > > On 4/24/19 7:23 AM, coleen.phillimore at oracle.com wrote: >> >> >> On 4/23/19 9:48 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 24/04/2019 8:49 am, coleen.phillimore at oracle.com wrote: >>>> >>>> Here's a new webrev with the changes requested by Dan. >>>> >>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.02/webrev >>> >>> Overall this seems fine. A few comments on the main changes: >>> >>> mutex.cpp >>> >>> ?156 bool Monitor::wait_without_safepoint_check(long timeout) { >>> ?157?? // Make sure safepoint checking is used properly. >>> ?158?? assert(_safepoint_check_required != >>> Monitor::_safepoint_check_always, >>> ?159????????? "This lock should never have a safepoint check: %s", >>> name()); >>> >>> The message is the wrong one: s/never/always/ >> >> I had both of these messages reversed in wait*() functions wrt. >> never/always.? If a lock L has safepoint_check_required = always and >> locks or waits without safepoint check, the message is relative to >> the lock, not the erroneous call.? Inverse for never. >> >> Thanks for finding this. >>> >>> wait_without_safepoint_check is missing: >>> >>> ? // timeout is in milliseconds - with zero meaning never timeout >>> ? assert(timeout >= 0, "negative timeout"); >>> >> >> Fixed. >> >>> --- >>> >>> mutexLocker.hpp >>> >>> 190? protected: >>> 191?? Monitor* _mutex; >>> >>> Good catch on the redundant extra field in MonitorLocker! >> >> Thanks. >>> >>> 208?? MutexLocker(Monitor* mutex, Thread* thread, >>> Mutex::SafepointCheckFlag flag = Mutex::_safepoint_check_flag) : >>> >>> 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. >> >> I also want to have a patch (I think I said this), to make the Thread >> argument first.? I could try some more tricks to avoid this >> duplication when/if I do that.?? How does that sound? >> >> Thanks for reviewing! >> Coleen >> >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Coleen >>>> >>>> On 4/23/19 6:18 PM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> Hi Dan, Thank you for tackling this code review.? I was hoping you >>>>> wouldn't do your usual file-by-file comments. It would have been >>>>> long. >>>>> >>>>> On 4/23/19 5:43 PM, Daniel D. Daugherty wrote: >>>>>> On 4/23/19 11:06 AM, coleen.phillimore at oracle.com wrote: >>>>>>> Summary: Make MutexLocker be MutexLockerEx implementation, >>>>>>> remove MutexLockerEx calls. Also added >>>>>>> wait_without_safepoint_check(). >>>>>>> >>>>>>> Also made safepoint_check_flag an enum, renamed MonitorLockerEx >>>>>>> to MonitorLocker, removed MutexUnlockerEx, and fixed formatting >>>>>>> where affected by this change. >>>>>>> >>>>>>> There's a MutexLocker constructor with a Thread parameter that >>>>>>> would actually be more performant if the thread is passed from >>>>>>> the current context rather than calling Thread::current() in >>>>>>> Monitor::lock.? I think the Thread parameter should be moved to >>>>>>> first so that we can have MutexLocker look like the Handle >>>>>>> constructor calls, for example.? I didn't make this change in this. >>>>>>> >>>>>>> ?? MutexLocker ml(THREAD, Monitor_lock). >>>>>>> >>>>>>> The interesting changes are in: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutexLocker.hpp.udiff.html >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.hpp.udiff.html >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> The rest is pattern substitution. >>>>>>> >>>>>>> Ran mach5 tier1-6 tests. >>>>>>> >>>>>>> open webrev at >>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev >>>>>> >>>>>> src/hotspot/share/runtime/mutexLocker.hpp >>>>>> ??? L198: ????? assert(_mutex->rank() > Mutex::special || >>>>>> no_safepoint_check, >>>>>> ??? L199: ??????? "Mutexes with rank special or lower should not >>>>>> do safepoint checks"); >>>>>> ??????? nit - indent on L199 needs 5 more spaces >>>>>> >>>>>> ??? L200-203 - this if-block is missing the usual HotSpot '{' and >>>>>> '}'. >>>>>> ??? (Not your fault, but since you're in there...) >>>>>> >>>>>> ??? L211: ????? assert(_mutex->rank() > Mutex::special || >>>>>> no_safepoint_check, >>>>>> ??? L212: ??????? "Mutexes with rank special or lower should not >>>>>> do safepoint checks"); >>>>>> ??????? nit - indent on L211 needs 5 more spaces >>>>>> >>>>>> ??? L213-216 - this if-block is missing the usual HotSpot '{' and >>>>>> '}'. >>>>>> ??? (Not your fault, but since you're in there...) >>>>> >>>>> Fixed all of these.? Since I've touched it, I made it follow the >>>>> coding style. >>>>> >>>>>> >>>>>> src/hotspot/share/runtime/mutex.hpp >>>>>> ??? L237: ?? // why do these need bodies? >>>>>> ??????? To prevent any calls to Mutex::notify(), >>>>>> Mutex::notify_all(), >>>>>> ??????? Mutex::wait() and Mutex::wait_without_safepoint_check() from >>>>>> ??????? calling the superclass' version of those functions. >>>>>> >>>>> >>>>> I forgot to check this, but if they're private, they shouldn't >>>>> need bodies.? I'll remove the comment and leave them for now. >>>>> >>>>> >>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>> ??? Nice detangling into Monitor::wait() and >>>>>> ??? Monitor::wait_without_safepoint_check(). >>>>>> >>>>> Thank you! >>>>> >>>>>> >>>>>> For the rest of the files, I went through the patch from bottom >>>>>> -> top >>>>>> and looked for anything that didn't look right. I figure other >>>>>> reviewers >>>>>> are looking from top -> bottom... :-) >>>>>> >>>>>> For the multi-line MutexLocker uses in >>>>>> src/hotspot/share/runtime/vmThread.cpp >>>>>> and src/hotspot/share/memory/metaspace.cpp, >>>>>> the second line indents appear to be off by two spaces (because >>>>>> "Ex" was removed). >>>>>> Don't know if you want to fix those or not. Your call. >>>>> >>>>> You have good eyes.? I checked all of these this morning and I >>>>> missed these files.? Thank you. >>>>>> >>>>>> src/hotspot/share/runtime/threadSMR.cpp >>>>>> >>>>>> ? - >>>>>> ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, >>>>>> 0, >>>>>> ? - !Mutex::_as_suspend_equivalent_flag); >>>>>> ? + >>>>>> ThreadsSMRSupport::delete_lock()->wait_without_safepoint_check(); >>>>>> >>>>>> ? You dropped the '!Mutex::_as_suspend_equivalent_flag' flag. I >>>>>> dislike >>>>>> ? default values so that's why I included it. Now the reader has to >>>>>> ? ? 1) remember that there's another parameter >>>>>> ? ? 2) go find the default value for that parameter >>>>> >>>>> wait_without_safepoint_check() doesn't have as_suspend_equivalent >>>>> flag as a parameter.? That code was only used in the safepoint >>>>> checking case for wait.?? I dislike default parameters too for the >>>>> same reasons.? Both waits take 0 as the timeout default parameter >>>>> but I thought that was not a good thing to change. >>>>> >>>>>> >>>>>> src/hotspot/share/gc/shared/workgroup.cpp >>>>>> ? This change does not parse: >>>>>> >>>>>> ?? ? ? // The VM thread should not execute here because >>>>>> MutexLocker's are used >>>>>> ? ? -? // as (opposed to MutexLockerEx's). >>>>>> ? ? +? // as (opposed to MutexLocker's). >>>>>> >>>>>> ? since MutexLocker is now on both sides of the verbal comparison. >>>>> Yeah, I missed that too.? It doesn't actually make sense before >>>>> either, since there isn't a MutexLocker nearby. >>>>> >>>>>> >>>>>> In some cases, there were multi-line MutexLocker uses that you chose >>>>>> to combine into a single line, but in most cases you did not combine >>>>>> them. I couldn't discern a rhyme or reason for the choices (not even >>>>>> a line length of 80). >>>>> >>>>> I combined them if the length wasn't "too long" and it didn't look >>>>> like the whitespace was helpful.? I did both. >>>>>> >>>>>> There is a startling number of names in use for the MutexLocker >>>>>> variables. My personal preference would be for 'ml' (and 'ul' >>>>>> for the MutexUnlocker). You have an opportunity to make them all >>>>>> consistent, but that's hard to do. >>>>> >>>>> By convention, ml is used a lot but sometimes you can't use it.? I >>>>> don't want to change this.? Sometimes people pick names they like >>>>> for this. >>>>>> >>>>>> Thumbs up! If you choose to handle and of my comments above, >>>>>> I don't need to see another webrev. >>>>> >>>>> Thank you Dan for reviewing this!? I'll retest with edits made for >>>>> comments above. >>>>> >>>>> Coleen >>>>> >>>>>> >>>>>> Dan >>>>>> >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8222811 >>>>>>> >>>>>>> Thanks! >>>>>>> Coleen >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > > From coleen.phillimore at oracle.com Thu Apr 25 15:33:29 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 25 Apr 2019 11:33:29 -0400 Subject: RFR (L, tedious) 8222811: Consolidate MutexLockerEx and MutexLocker In-Reply-To: <2fabd9b2-217d-1661-74f3-55d326611226@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> <2d1b8ba1-bda1-78c3-b2b0-13774177fcd3@oracle.com> <2fabd9b2-217d-1661-74f3-55d326611226@oracle.com> Message-ID: On 4/25/19 10:27 AM, Daniel D. Daugherty wrote: > On 4/24/19 7:57 AM, coleen.phillimore at oracle.com wrote: >> >> I made the change suggested by Per and it's quite nice.? I also fixed >> Mutex to not have bodies for the private functions since that's not >> required to get a compilation error if one uses them. >> >> http://cr.openjdk.java.net/~coleenp/2019/8222811.03.incr/webrev/index.html >> > > src/hotspot/share/runtime/mutexLocker.hpp > ??? No comments. > > src/hotspot/share/runtime/mutex.hpp > ??? L237: ?? void notify (); > ??? L239: ?? bool wait (long timeout, bool as_suspend_equivalent); > ??????? nit - Please delete the space before '('. Okay.? Got it. > > src/hotspot/share/runtime/mutex.cpp > ??? No comments. > > src/hotspot/share/compiler/compileBroker.cpp > src/hotspot/share/gc/g1/g1StringDedupQueue.cpp > src/hotspot/share/gc/shared/owstTaskTerminator.cpp > src/hotspot/share/gc/shared/suspendibleThreadSet.cpp > src/hotspot/share/gc/shared/workgroup.cpp > src/hotspot/share/gc/z/zMessagePort.inline.hpp > src/hotspot/share/gc/z/zMetronome.cpp > src/hotspot/share/gc/z/zRuntimeWorkers.cpp > src/hotspot/share/gc/z/zWorkers.cpp > src/hotspot/share/runtime/init.cpp > src/hotspot/share/runtime/serviceThread.cpp > ??? No comments. > > Thumbs up. No need for a new webrev if you fix the space issue above. > Thanks for reviewing, Dan! Coleen > Dan > > > >> >> Running again through mach5. >> >> Thanks, >> Coleen >> >> On 4/24/19 7:23 AM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 4/23/19 9:48 PM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> On 24/04/2019 8:49 am, coleen.phillimore at oracle.com wrote: >>>>> >>>>> Here's a new webrev with the changes requested by Dan. >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.02/webrev >>>> >>>> Overall this seems fine. A few comments on the main changes: >>>> >>>> mutex.cpp >>>> >>>> ?156 bool Monitor::wait_without_safepoint_check(long timeout) { >>>> ?157?? // Make sure safepoint checking is used properly. >>>> ?158?? assert(_safepoint_check_required != >>>> Monitor::_safepoint_check_always, >>>> ?159????????? "This lock should never have a safepoint check: %s", >>>> name()); >>>> >>>> The message is the wrong one: s/never/always/ >>> >>> I had both of these messages reversed in wait*() functions wrt. >>> never/always.? If a lock L has safepoint_check_required = always and >>> locks or waits without safepoint check, the message is relative to >>> the lock, not the erroneous call.? Inverse for never. >>> >>> Thanks for finding this. >>>> >>>> wait_without_safepoint_check is missing: >>>> >>>> ? // timeout is in milliseconds - with zero meaning never timeout >>>> ? assert(timeout >= 0, "negative timeout"); >>>> >>> >>> Fixed. >>> >>>> --- >>>> >>>> mutexLocker.hpp >>>> >>>> 190? protected: >>>> 191?? Monitor* _mutex; >>>> >>>> Good catch on the redundant extra field in MonitorLocker! >>> >>> Thanks. >>>> >>>> 208?? MutexLocker(Monitor* mutex, Thread* thread, >>>> Mutex::SafepointCheckFlag flag = Mutex::_safepoint_check_flag) : >>>> >>>> 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. >>> >>> I also want to have a patch (I think I said this), to make the >>> Thread argument first.? I could try some more tricks to avoid this >>> duplication when/if I do that.?? How does that sound? >>> >>> Thanks for reviewing! >>> Coleen >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 4/23/19 6:18 PM, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>> Hi Dan, Thank you for tackling this code review.? I was hoping >>>>>> you wouldn't do your usual file-by-file comments. It would have >>>>>> been long. >>>>>> >>>>>> On 4/23/19 5:43 PM, Daniel D. Daugherty wrote: >>>>>>> On 4/23/19 11:06 AM, coleen.phillimore at oracle.com wrote: >>>>>>>> Summary: Make MutexLocker be MutexLockerEx implementation, >>>>>>>> remove MutexLockerEx calls. Also added >>>>>>>> wait_without_safepoint_check(). >>>>>>>> >>>>>>>> Also made safepoint_check_flag an enum, renamed MonitorLockerEx >>>>>>>> to MonitorLocker, removed MutexUnlockerEx, and fixed formatting >>>>>>>> where affected by this change. >>>>>>>> >>>>>>>> There's a MutexLocker constructor with a Thread parameter that >>>>>>>> would actually be more performant if the thread is passed from >>>>>>>> the current context rather than calling Thread::current() in >>>>>>>> Monitor::lock.? I think the Thread parameter should be moved to >>>>>>>> first so that we can have MutexLocker look like the Handle >>>>>>>> constructor calls, for example.? I didn't make this change in >>>>>>>> this. >>>>>>>> >>>>>>>> ?? MutexLocker ml(THREAD, Monitor_lock). >>>>>>>> >>>>>>>> The interesting changes are in: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutexLocker.hpp.udiff.html >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.hpp.udiff.html >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.cpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> The rest is pattern substitution. >>>>>>>> >>>>>>>> Ran mach5 tier1-6 tests. >>>>>>>> >>>>>>>> open webrev at >>>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev >>>>>>> >>>>>>> src/hotspot/share/runtime/mutexLocker.hpp >>>>>>> ??? L198: ????? assert(_mutex->rank() > Mutex::special || >>>>>>> no_safepoint_check, >>>>>>> ??? L199: ??????? "Mutexes with rank special or lower should not >>>>>>> do safepoint checks"); >>>>>>> ??????? nit - indent on L199 needs 5 more spaces >>>>>>> >>>>>>> ??? L200-203 - this if-block is missing the usual HotSpot '{' >>>>>>> and '}'. >>>>>>> ??? (Not your fault, but since you're in there...) >>>>>>> >>>>>>> ??? L211: ????? assert(_mutex->rank() > Mutex::special || >>>>>>> no_safepoint_check, >>>>>>> ??? L212: ??????? "Mutexes with rank special or lower should not >>>>>>> do safepoint checks"); >>>>>>> ??????? nit - indent on L211 needs 5 more spaces >>>>>>> >>>>>>> ??? L213-216 - this if-block is missing the usual HotSpot '{' >>>>>>> and '}'. >>>>>>> ??? (Not your fault, but since you're in there...) >>>>>> >>>>>> Fixed all of these.? Since I've touched it, I made it follow the >>>>>> coding style. >>>>>> >>>>>>> >>>>>>> src/hotspot/share/runtime/mutex.hpp >>>>>>> ??? L237: ?? // why do these need bodies? >>>>>>> ??????? To prevent any calls to Mutex::notify(), >>>>>>> Mutex::notify_all(), >>>>>>> ??????? Mutex::wait() and Mutex::wait_without_safepoint_check() >>>>>>> from >>>>>>> ??????? calling the superclass' version of those functions. >>>>>>> >>>>>> >>>>>> I forgot to check this, but if they're private, they shouldn't >>>>>> need bodies.? I'll remove the comment and leave them for now. >>>>>> >>>>>> >>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>> ??? Nice detangling into Monitor::wait() and >>>>>>> ??? Monitor::wait_without_safepoint_check(). >>>>>>> >>>>>> Thank you! >>>>>> >>>>>>> >>>>>>> For the rest of the files, I went through the patch from bottom >>>>>>> -> top >>>>>>> and looked for anything that didn't look right. I figure other >>>>>>> reviewers >>>>>>> are looking from top -> bottom... :-) >>>>>>> >>>>>>> For the multi-line MutexLocker uses in >>>>>>> src/hotspot/share/runtime/vmThread.cpp >>>>>>> and src/hotspot/share/memory/metaspace.cpp, >>>>>>> the second line indents appear to be off by two spaces (because >>>>>>> "Ex" was removed). >>>>>>> Don't know if you want to fix those or not. Your call. >>>>>> >>>>>> You have good eyes.? I checked all of these this morning and I >>>>>> missed these files.? Thank you. >>>>>>> >>>>>>> src/hotspot/share/runtime/threadSMR.cpp >>>>>>> >>>>>>> ? - >>>>>>> ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, >>>>>>> 0, >>>>>>> ? - !Mutex::_as_suspend_equivalent_flag); >>>>>>> ? + >>>>>>> ThreadsSMRSupport::delete_lock()->wait_without_safepoint_check(); >>>>>>> >>>>>>> ? You dropped the '!Mutex::_as_suspend_equivalent_flag' flag. I >>>>>>> dislike >>>>>>> ? default values so that's why I included it. Now the reader has to >>>>>>> ? ? 1) remember that there's another parameter >>>>>>> ? ? 2) go find the default value for that parameter >>>>>> >>>>>> wait_without_safepoint_check() doesn't have as_suspend_equivalent >>>>>> flag as a parameter.? That code was only used in the safepoint >>>>>> checking case for wait. I dislike default parameters too for the >>>>>> same reasons. Both waits take 0 as the timeout default parameter >>>>>> but I thought that was not a good thing to change. >>>>>> >>>>>>> >>>>>>> src/hotspot/share/gc/shared/workgroup.cpp >>>>>>> ? This change does not parse: >>>>>>> >>>>>>> ?? ? ? // The VM thread should not execute here because >>>>>>> MutexLocker's are used >>>>>>> ? ? -? // as (opposed to MutexLockerEx's). >>>>>>> ? ? +? // as (opposed to MutexLocker's). >>>>>>> >>>>>>> ? since MutexLocker is now on both sides of the verbal comparison. >>>>>> Yeah, I missed that too.? It doesn't actually make sense before >>>>>> either, since there isn't a MutexLocker nearby. >>>>>> >>>>>>> >>>>>>> In some cases, there were multi-line MutexLocker uses that you >>>>>>> chose >>>>>>> to combine into a single line, but in most cases you did not >>>>>>> combine >>>>>>> them. I couldn't discern a rhyme or reason for the choices (not >>>>>>> even >>>>>>> a line length of 80). >>>>>> >>>>>> I combined them if the length wasn't "too long" and it didn't >>>>>> look like the whitespace was helpful.? I did both. >>>>>>> >>>>>>> There is a startling number of names in use for the MutexLocker >>>>>>> variables. My personal preference would be for 'ml' (and 'ul' >>>>>>> for the MutexUnlocker). You have an opportunity to make them all >>>>>>> consistent, but that's hard to do. >>>>>> >>>>>> By convention, ml is used a lot but sometimes you can't use it.? >>>>>> I don't want to change this.? Sometimes people pick names they >>>>>> like for this. >>>>>>> >>>>>>> Thumbs up! If you choose to handle and of my comments above, >>>>>>> I don't need to see another webrev. >>>>>> >>>>>> Thank you Dan for reviewing this!? I'll retest with edits made >>>>>> for comments above. >>>>>> >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8222811 >>>>>>>> >>>>>>>> Thanks! >>>>>>>> Coleen >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >> >> > From coleen.phillimore at oracle.com Thu Apr 25 15:40:33 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 25 Apr 2019 11:40:33 -0400 Subject: hg: jdk/jdk: 8222811: Consolidate MutexLockerEx and MutexLocker In-Reply-To: <201904251532.x3PFWpJs022525@aojmv0008.oracle.com> References: <201904251532.x3PFWpJs022525@aojmv0008.oracle.com> Message-ID: Hi, Be careful if you are about to check in changes that have added a {Mutex,Monitor}LockerEx, since this class doesn't exist anymore. Thanks, Coleen On 4/25/19 11:32 AM, coleen.phillimore at oracle.com wrote: > Changeset: 1126f0607c70 > Author: coleenp > Date: 2019-04-25 10:56 -0400 > URL: http://hg.openjdk.java.net/jdk/jdk/rev/1126f0607c70 > > 8222811: Consolidate MutexLockerEx and MutexLocker > Summary: Make MutexLocker be MutexLockerEx implementation, remove MutexLockerEx calls. > Reviewed-by: dcubed, dholmes, pliden, rehn > > ! src/hotspot/os/bsd/os_bsd.cpp > ! src/hotspot/os/linux/os_linux.cpp > ! src/hotspot/share/aot/aotCompiledMethod.cpp > ! src/hotspot/share/aot/aotLoader.cpp > ! src/hotspot/share/c1/c1_Runtime1.cpp > ! src/hotspot/share/classfile/classLoaderData.cpp > ! src/hotspot/share/classfile/dictionary.cpp > ! src/hotspot/share/classfile/packageEntry.cpp > ! src/hotspot/share/classfile/protectionDomainCache.cpp > ! src/hotspot/share/classfile/stringTable.cpp > ! src/hotspot/share/classfile/symbolTable.cpp > ! src/hotspot/share/classfile/systemDictionary.cpp > ! src/hotspot/share/code/codeBlob.cpp > ! src/hotspot/share/code/codeCache.cpp > ! src/hotspot/share/code/icBuffer.cpp > ! src/hotspot/share/code/nmethod.cpp > ! src/hotspot/share/code/stubs.cpp > ! src/hotspot/share/code/vtableStubs.cpp > ! src/hotspot/share/compiler/compileBroker.cpp > ! src/hotspot/share/compiler/compilerDirectives.cpp > ! src/hotspot/share/compiler/oopMap.cpp > ! src/hotspot/share/gc/cms/cmsVMOperations.cpp > ! src/hotspot/share/gc/cms/compactibleFreeListSpace.cpp > ! src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.cpp > ! src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.hpp > ! src/hotspot/share/gc/cms/concurrentMarkSweepThread.cpp > ! src/hotspot/share/gc/cms/yieldingWorkgroup.cpp > ! src/hotspot/share/gc/epsilon/epsilonHeap.cpp > ! src/hotspot/share/gc/g1/g1Allocator.cpp > ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp > ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp > ! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp > ! src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp > ! src/hotspot/share/gc/g1/g1FullGCOopClosures.cpp > ! src/hotspot/share/gc/g1/g1MonitoringSupport.cpp > ! src/hotspot/share/gc/g1/g1RootProcessor.cpp > ! src/hotspot/share/gc/g1/g1SharedDirtyCardQueue.cpp > ! src/hotspot/share/gc/g1/g1StringDedupQueue.cpp > ! src/hotspot/share/gc/g1/g1VMOperations.cpp > ! src/hotspot/share/gc/g1/g1YoungRemSetSamplingThread.cpp > ! src/hotspot/share/gc/g1/heapRegion.cpp > ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp > ! src/hotspot/share/gc/g1/heapRegionRemSet.hpp > ! src/hotspot/share/gc/parallel/gcTaskManager.cpp > ! src/hotspot/share/gc/shared/collectedHeap.cpp > ! src/hotspot/share/gc/shared/concurrentGCPhaseManager.cpp > ! src/hotspot/share/gc/shared/concurrentGCThread.cpp > ! src/hotspot/share/gc/shared/genCollectedHeap.cpp > ! src/hotspot/share/gc/shared/oopStorage.cpp > ! src/hotspot/share/gc/shared/owstTaskTerminator.cpp > ! src/hotspot/share/gc/shared/ptrQueue.cpp > ! src/hotspot/share/gc/shared/satbMarkQueue.cpp > ! src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp > ! src/hotspot/share/gc/shared/stringdedup/stringDedupTable.hpp > ! src/hotspot/share/gc/shared/suspendibleThreadSet.cpp > ! src/hotspot/share/gc/shared/workgroup.cpp > ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp > ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp > ! src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.cpp > ! src/hotspot/share/gc/z/zMessagePort.inline.hpp > ! src/hotspot/share/gc/z/zMetronome.cpp > ! src/hotspot/share/gc/z/zNMethodTable.cpp > ! src/hotspot/share/gc/z/zReferenceProcessor.cpp > ! src/hotspot/share/gc/z/zRuntimeWorkers.cpp > ! src/hotspot/share/gc/z/zUnload.cpp > ! src/hotspot/share/gc/z/zWorkers.cpp > ! src/hotspot/share/jfr/periodic/jfrPeriodic.cpp > ! src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp > ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeManager.cpp > ! src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp > ! src/hotspot/share/jfr/recorder/repository/jfrRepository.cpp > ! src/hotspot/share/jfr/recorder/service/jfrPostBox.cpp > ! src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp > ! src/hotspot/share/jfr/recorder/service/jfrRecorderThreadLoop.cpp > ! src/hotspot/share/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp > ! src/hotspot/share/jfr/recorder/storage/jfrStorage.cpp > ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp > ! src/hotspot/share/memory/metaspace.cpp > ! src/hotspot/share/memory/metaspace/chunkManager.cpp > ! src/hotspot/share/memory/metaspace/spaceManager.cpp > ! src/hotspot/share/memory/metaspace/virtualSpaceList.cpp > ! src/hotspot/share/memory/universe.cpp > ! src/hotspot/share/oops/instanceKlass.cpp > ! src/hotspot/share/oops/method.cpp > ! src/hotspot/share/prims/jvm.cpp > ! src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp > ! src/hotspot/share/prims/jvmtiEnv.cpp > ! src/hotspot/share/prims/jvmtiEventController.cpp > ! src/hotspot/share/prims/jvmtiExport.cpp > ! src/hotspot/share/prims/methodHandles.cpp > ! src/hotspot/share/prims/resolvedMethodTable.cpp > ! src/hotspot/share/prims/whitebox.cpp > ! src/hotspot/share/runtime/handshake.cpp > ! src/hotspot/share/runtime/init.cpp > ! src/hotspot/share/runtime/java.cpp > ! src/hotspot/share/runtime/jniHandles.cpp > ! src/hotspot/share/runtime/mutex.cpp > ! src/hotspot/share/runtime/mutex.hpp > ! src/hotspot/share/runtime/mutexLocker.hpp > ! src/hotspot/share/runtime/os.cpp > ! src/hotspot/share/runtime/serviceThread.cpp > ! src/hotspot/share/runtime/sharedRuntime.cpp > ! src/hotspot/share/runtime/sweeper.cpp > ! src/hotspot/share/runtime/task.cpp > ! src/hotspot/share/runtime/thread.cpp > ! src/hotspot/share/runtime/thread.hpp > ! src/hotspot/share/runtime/threadSMR.cpp > ! src/hotspot/share/runtime/threadSMR.inline.hpp > ! src/hotspot/share/runtime/vmOperations.cpp > ! src/hotspot/share/runtime/vmThread.cpp > ! src/hotspot/share/services/diagnosticFramework.cpp > ! src/hotspot/share/services/gcNotifier.cpp > ! src/hotspot/share/services/lowMemoryDetector.cpp > ! src/hotspot/share/services/management.cpp > ! src/hotspot/share/services/memoryManager.cpp > ! src/hotspot/share/services/threadService.cpp > ! src/hotspot/share/utilities/decoder.cpp > ! src/hotspot/share/utilities/decoder.hpp > ! src/hotspot/share/utilities/events.cpp > ! src/hotspot/share/utilities/events.hpp > ! src/hotspot/share/utilities/vmError.cpp > ! test/hotspot/gtest/gc/shared/test_oopStorage.cpp > ! test/hotspot/gtest/memory/test_is_metaspace_obj.cpp > ! test/hotspot/gtest/memory/test_metaspace.cpp > ! test/hotspot/gtest/memory/test_metaspace_allocation.cpp > ! test/hotspot/gtest/runtime/test_threads.cpp > ! test/hotspot/gtest/threadHelper.inline.hpp > From coleen.phillimore at oracle.com Thu Apr 25 16:05:12 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 25 Apr 2019 12:05:12 -0400 Subject: RFR (T) 8222977: Fix shenandoah broken with JDK-8222811 Message-ID: open webrev at http://cr.openjdk.java.net/~coleenp/2019/8222977.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8222977 I just found this.? Please review before Aleksey finds it. Shendandoah build in progress. Thanks, Coleen From yumin.qi at gmail.com Thu Apr 25 16:07:55 2019 From: yumin.qi at gmail.com (yumin qi) Date: Thu, 25 Apr 2019 09:07:55 -0700 Subject: RFC: JWarmup precompile java hot methods at application startup In-Reply-To: References: Message-ID: Hi, Apart from comments from compiler professionals can I have comments from runtime either? The changes mostly land in runtime area. Thanks Yumin On Tue, Apr 16, 2019 at 11:27 AM yumin qi wrote: > HI, > > Did anyone have comments for this version? > > Thanks > Yumin > > On Tue, Apr 9, 2019 at 10:36 AM yumin qi wrote: > >> Alan, >> Thanks! Updated in same link: >> http://cr.openjdk.java.net/~minqi/8220692/webrev-02/ >> >> Removed non-boot loader branch in nativeLookup.cpp. >> Added jdk.jwarmup to boot loader list in make/common/Modules.gmk. >> Tested again to make sure the new changes. >> >> Thanks >> Yumin >> >> >> On Tue, Apr 9, 2019 at 4:48 AM Alan Bateman >> wrote: >> >>> On 09/04/2019 07:10, yumin qi wrote: >>> > >>> > Now the registerNatives is found when it looks up for native entry >>> > in lookupNative.cpp. I thought the class JWarmUp will be loaded by >>> > boot loader like Unsafe or WhiteBox, but I was wrong, it is loaded by >>> > app class loader so logic for obtaining its native entry put in both >>> > cases, boot loader and non boot loaders. >>> > >>> make/common/Modules.gmk is where BOOT_MODULES is defined with the list >>> of modules mapped to the boot loader. >>> >>> -Alan >>> >> From daniel.daugherty at oracle.com Thu Apr 25 16:06:53 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 25 Apr 2019 12:06:53 -0400 Subject: RFR (T) 8222977: Fix shenandoah broken with JDK-8222811 In-Reply-To: References: Message-ID: On 4/25/19 12:05 PM, coleen.phillimore at oracle.com wrote: > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8222977.01/webrev src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.cpp ??? No comments. Thumbs up. And I agree that this is trivial. Dan > bug link https://bugs.openjdk.java.net/browse/JDK-8222977 > > I just found this.? Please review before Aleksey finds it. Shendandoah > build in progress. > > Thanks, > Coleen From shade at redhat.com Thu Apr 25 17:01:24 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 25 Apr 2019 19:01:24 +0200 Subject: RFR (T) 8222977: Fix shenandoah broken with JDK-8222811 In-Reply-To: References: Message-ID: <72050521-ad5b-958f-bac5-4ef89049d5be@redhat.com> On 4/25/19 6:05 PM, coleen.phillimore at oracle.com wrote: > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8222977.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8222977 > > I just found this.? Please review before Aleksey finds it. Shendandoah build in progress. Too late! Looks good. -Aleksey From coleen.phillimore at oracle.com Thu Apr 25 17:07:26 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 25 Apr 2019 13:07:26 -0400 Subject: RFR (T) 8222977: Fix shenandoah broken with JDK-8222811 In-Reply-To: <72050521-ad5b-958f-bac5-4ef89049d5be@redhat.com> References: <72050521-ad5b-958f-bac5-4ef89049d5be@redhat.com> Message-ID: Thanks Dan and Aleksey. Coleen On 4/25/19 1:01 PM, Aleksey Shipilev wrote: > On 4/25/19 6:05 PM, coleen.phillimore at oracle.com wrote: >> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8222977.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8222977 >> >> I just found this.? Please review before Aleksey finds it. Shendandoah build in progress. > Too late! Looks good. > > -Aleksey > From stefan.karlsson at oracle.com Thu Apr 25 18:36:33 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 25 Apr 2019 20:36:33 +0200 Subject: RFR: 8222986: Add parameter to skip clearing CHeapBitMaps when resizing Message-ID: <41788301-04af-879f-527d-44673831d857@oracle.com> Hi all, Please review this patch to add a 'clear' parameter to the CHeapBitMap initialize, resize, and reinitialize functions. https://cr.openjdk.java.net/~stefank/8222986/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8222986 We want this functionally for the ZUncommit feature, where we now split ZPages and resize the bitmaps. These bitmaps are cleared lazily, so we don't want to also clear them when they are resized. Thanks, StefanK From per.liden at oracle.com Thu Apr 25 21:58:01 2019 From: per.liden at oracle.com (Per Liden) Date: Thu, 25 Apr 2019 23:58:01 +0200 Subject: RFR: 8222986: Add parameter to skip clearing CHeapBitMaps when resizing In-Reply-To: <41788301-04af-879f-527d-44673831d857@oracle.com> References: <41788301-04af-879f-527d-44673831d857@oracle.com> Message-ID: <62979740-cb0c-6718-f8f9-3ba47182f118@oracle.com> Looks good! One minor thing, the comments in the header file still says the memory will be cleared. Should we change that to "optionally cleared" or something similar? /Per On 04/25/2019 08:36 PM, Stefan Karlsson wrote: > Hi all, > > Please review this patch to add a 'clear' parameter to the CHeapBitMap > initialize, resize, and reinitialize functions. > > https://cr.openjdk.java.net/~stefank/8222986/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8222986 > > We want this functionally for the ZUncommit feature, where we now split > ZPages and resize the bitmaps. These bitmaps are cleared lazily, so we > don't want to also clear them when they are resized. > > Thanks, > StefanK From shengpei92 at gmail.com Fri Apr 26 00:19:50 2019 From: shengpei92 at gmail.com (Shengpei Zhang) Date: Thu, 25 Apr 2019 17:19:50 -0700 Subject: Metaspace OOM before reaching MaxMetaspaceSize Message-ID: Hi, We recently saw a weird Metaspace OOM. The hs_err_pid log showed the metaspace usage was 325078K, while the MaxMetaspaceSize was set to 4G. The machine was running JAVA10. Few observations: 1. It only happened at one machine, and we were not able to reproduce it. 2. Error log indicated memory allocation failure in native memory. [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] Chunkmanager (non-class): [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] 62578 specialized (128 bytes) chunks, total 64079872 bytes [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] 5778 small (512 bytes) chunks, total 23666688 bytes [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] 27 medium (8192 bytes) chunks, total 1769472 bytes [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] 13 humongous chunks, total 8890368 bytes [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] total size: 98406400 bytes. [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] Chunkmanager (class): [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] unavailable. java.lang.OutOfMemoryError: Metaspace Dumping heap to java_pid240.hprof ... vmop [ threads: total initially_running wait_to_block ][ time: spin block sync cleanup vmop ] page_trap_count 66467.977: ICBufferFull [ 3427 154 353 ][ 0 60 63 8 0 ] 58 [2019-03-29T11:18:01.308-0700][459 ][info ][safepoint ] Total time for which application threads were stopped: 0.0725507 seconds, Stopping threads took: 0.0630158 seconds [thread 384508 also had an error] # # There is insufficient memory for the Java Runtime Environment to continue. # Native memory allocation (mmap) failed to map 16384 bytes for committing reserved memory. # An error report file with more information is saved as: # /data/hs_err_pid240.log 3. The hs_err_pid log showed the metaspace memory usage was 325078K, it is far less than the reserved size 568176K. Also, the MaxMetaspaceSize was set to 4G. I checked the machine had plenty of free native memory at that time. If there was a huge allocation, I assume JVM would try to reserve more memory first? Heap: garbage-first heap total 188743680K, used 47178320K [0x00007ee320000000, 0x00007f1020000000) region size 32768K, 70 young (2293760K), 0 survivors (0K) Metaspace used 325078K, capacity 451348K, committed 547448K, reserved 568176K Also it showed that there was 5G free memory on the machine: /proc/meminfo: MemTotal: 263892284 kB MemFree: 5111480 kB MemAvailable: 42423728 kB Buffers: 752620 kB Cached: 36011560 kB SwapCached: 0 kB Active: 221763832 kB Inactive: 31633872 kB 4. The stacktrace --------------- T H R E A D --------------- Current thread (0x00007edec0023840): JavaThread "http-client-exchange-39327" daemon [_thread_new, id=384507, stack(0x00007ed6c8a6b000,0x00007ed6c8c6c000)] Stack: [0x00007ed6c8a6b000,0x00007ed6c8c6c000], sp=0x00007ed6c8c6aa90, free space=2046k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xdf3ee2] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x162 V [libjvm.so+0xdf4b8b] VMError::report_and_die(Thread*, char const*, int, unsigned long, VMErrorType, char const*, __va_list_tag*)+0x2b V [libjvm.so+0x6a7c98] report_vm_out_of_memory(char const*, int, unsigned long, VMErrorType, char const*, ...)+0xd8 V [libjvm.so+0xbfdc8e] os::pd_commit_memory(char*, unsigned long, bool)+0xce V [libjvm.so+0xbf647f] os::commit_memory(char*, unsigned long, bool)+0x1f V [libjvm.so+0xbff1f8] os::pd_create_stack_guard_pages(char*, unsigned long)+0x68 V [libjvm.so+0xd9013c] JavaThread::create_stack_guard_pages()+0x5c V [libjvm.so+0xd92c7c] JavaThread::run()+0x2c V [libjvm.so+0xc03e82] thread_native_entry(Thread*)+0xf2 C [libpthread.so.0+0x7e25] start_thread+0xc5 We have never seen such issue before. Does anyone have insights? Thanks, Shengpei From david.holmes at oracle.com Fri Apr 26 04:25:11 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Apr 2019 14:25:11 +1000 Subject: RFR (L, tedious) 8222811: Consolidate MutexLockerEx and MutexLocker In-Reply-To: <2d1b8ba1-bda1-78c3-b2b0-13774177fcd3@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> <2d1b8ba1-bda1-78c3-b2b0-13774177fcd3@oracle.com> Message-ID: <3116eba3-614a-0a8c-5c3d-72c5536bc725@oracle.com> Hi Coleen, On 24/04/2019 9:57 pm, coleen.phillimore at oracle.com wrote: > I made the change suggested by Per and it's quite nice.? I also fixed > Mutex to not have bodies for the private functions since that's not > required to get a compilation error if one uses them. Not required for attempted use outside the class, but if you call them from within the class then I think you'll just execute the inherited methods - yes? Not that it makes any sense to do such a thing but ... I don't know what the original intent was here. I'm okay with getting rid of the code bloat. Other changes seem okay. Thanks, David ----- > http://cr.openjdk.java.net/~coleenp/2019/8222811.03.incr/webrev/index.html > > Running again through mach5. > > Thanks, > Coleen > > On 4/24/19 7:23 AM, coleen.phillimore at oracle.com wrote: >> >> >> On 4/23/19 9:48 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 24/04/2019 8:49 am, coleen.phillimore at oracle.com wrote: >>>> >>>> Here's a new webrev with the changes requested by Dan. >>>> >>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.02/webrev >>> >>> Overall this seems fine. A few comments on the main changes: >>> >>> mutex.cpp >>> >>> ?156 bool Monitor::wait_without_safepoint_check(long timeout) { >>> ?157?? // Make sure safepoint checking is used properly. >>> ?158?? assert(_safepoint_check_required != >>> Monitor::_safepoint_check_always, >>> ?159????????? "This lock should never have a safepoint check: %s", >>> name()); >>> >>> The message is the wrong one: s/never/always/ >> >> I had both of these messages reversed in wait*() functions wrt. >> never/always.? If a lock L has safepoint_check_required = always and >> locks or waits without safepoint check, the message is relative to the >> lock, not the erroneous call.? Inverse for never. >> >> Thanks for finding this. >>> >>> wait_without_safepoint_check is missing: >>> >>> ? // timeout is in milliseconds - with zero meaning never timeout >>> ? assert(timeout >= 0, "negative timeout"); >>> >> >> Fixed. >> >>> --- >>> >>> mutexLocker.hpp >>> >>> 190? protected: >>> 191?? Monitor* _mutex; >>> >>> Good catch on the redundant extra field in MonitorLocker! >> >> Thanks. >>> >>> 208?? MutexLocker(Monitor* mutex, Thread* thread, >>> Mutex::SafepointCheckFlag flag = Mutex::_safepoint_check_flag) : >>> >>> 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. >> >> I also want to have a patch (I think I said this), to make the Thread >> argument first.? I could try some more tricks to avoid this >> duplication when/if I do that.?? How does that sound? >> >> Thanks for reviewing! >> Coleen >> >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Coleen >>>> >>>> On 4/23/19 6:18 PM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> Hi Dan, Thank you for tackling this code review.? I was hoping you >>>>> wouldn't do your usual file-by-file comments.? It would have been >>>>> long. >>>>> >>>>> On 4/23/19 5:43 PM, Daniel D. Daugherty wrote: >>>>>> On 4/23/19 11:06 AM, coleen.phillimore at oracle.com wrote: >>>>>>> Summary: Make MutexLocker be MutexLockerEx implementation, remove >>>>>>> MutexLockerEx calls. Also added wait_without_safepoint_check(). >>>>>>> >>>>>>> Also made safepoint_check_flag an enum, renamed MonitorLockerEx >>>>>>> to MonitorLocker, removed MutexUnlockerEx, and fixed formatting >>>>>>> where affected by this change. >>>>>>> >>>>>>> There's a MutexLocker constructor with a Thread parameter that >>>>>>> would actually be more performant if the thread is passed from >>>>>>> the current context rather than calling Thread::current() in >>>>>>> Monitor::lock.? I think the Thread parameter should be moved to >>>>>>> first so that we can have MutexLocker look like the Handle >>>>>>> constructor calls, for example.? I didn't make this change in this. >>>>>>> >>>>>>> ?? MutexLocker ml(THREAD, Monitor_lock). >>>>>>> >>>>>>> The interesting changes are in: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutexLocker.hpp.udiff.html >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.hpp.udiff.html >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> The rest is pattern substitution. >>>>>>> >>>>>>> Ran mach5 tier1-6 tests. >>>>>>> >>>>>>> open webrev at >>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev >>>>>> >>>>>> src/hotspot/share/runtime/mutexLocker.hpp >>>>>> ??? L198: ????? assert(_mutex->rank() > Mutex::special || >>>>>> no_safepoint_check, >>>>>> ??? L199: ??????? "Mutexes with rank special or lower should not >>>>>> do safepoint checks"); >>>>>> ??????? nit - indent on L199 needs 5 more spaces >>>>>> >>>>>> ??? L200-203 - this if-block is missing the usual HotSpot '{' and >>>>>> '}'. >>>>>> ??? (Not your fault, but since you're in there...) >>>>>> >>>>>> ??? L211: ????? assert(_mutex->rank() > Mutex::special || >>>>>> no_safepoint_check, >>>>>> ??? L212: ??????? "Mutexes with rank special or lower should not >>>>>> do safepoint checks"); >>>>>> ??????? nit - indent on L211 needs 5 more spaces >>>>>> >>>>>> ??? L213-216 - this if-block is missing the usual HotSpot '{' and >>>>>> '}'. >>>>>> ??? (Not your fault, but since you're in there...) >>>>> >>>>> Fixed all of these.? Since I've touched it, I made it follow the >>>>> coding style. >>>>> >>>>>> >>>>>> src/hotspot/share/runtime/mutex.hpp >>>>>> ??? L237: ?? // why do these need bodies? >>>>>> ??????? To prevent any calls to Mutex::notify(), Mutex::notify_all(), >>>>>> ??????? Mutex::wait() and Mutex::wait_without_safepoint_check() from >>>>>> ??????? calling the superclass' version of those functions. >>>>>> >>>>> >>>>> I forgot to check this, but if they're private, they shouldn't need >>>>> bodies.? I'll remove the comment and leave them for now. >>>>> >>>>> >>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>> ??? Nice detangling into Monitor::wait() and >>>>>> ??? Monitor::wait_without_safepoint_check(). >>>>>> >>>>> Thank you! >>>>> >>>>>> >>>>>> For the rest of the files, I went through the patch from bottom -> >>>>>> top >>>>>> and looked for anything that didn't look right. I figure other >>>>>> reviewers >>>>>> are looking from top -> bottom... :-) >>>>>> >>>>>> For the multi-line MutexLocker uses in >>>>>> src/hotspot/share/runtime/vmThread.cpp >>>>>> and src/hotspot/share/memory/metaspace.cpp, >>>>>> the second line indents appear to be off by two spaces (because >>>>>> "Ex" was removed). >>>>>> Don't know if you want to fix those or not. Your call. >>>>> >>>>> You have good eyes.? I checked all of these this morning and I >>>>> missed these files.? Thank you. >>>>>> >>>>>> src/hotspot/share/runtime/threadSMR.cpp >>>>>> >>>>>> ? - >>>>>> ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, >>>>>> 0, >>>>>> ? - !Mutex::_as_suspend_equivalent_flag); >>>>>> ? + ThreadsSMRSupport::delete_lock()->wait_without_safepoint_check(); >>>>>> >>>>>> ? You dropped the '!Mutex::_as_suspend_equivalent_flag' flag. I >>>>>> dislike >>>>>> ? default values so that's why I included it. Now the reader has to >>>>>> ? ? 1) remember that there's another parameter >>>>>> ? ? 2) go find the default value for that parameter >>>>> >>>>> wait_without_safepoint_check() doesn't have as_suspend_equivalent >>>>> flag as a parameter.? That code was only used in the safepoint >>>>> checking case for wait.?? I dislike default parameters too for the >>>>> same reasons.? Both waits take 0 as the timeout default parameter >>>>> but I thought that was not a good thing to change. >>>>> >>>>>> >>>>>> src/hotspot/share/gc/shared/workgroup.cpp >>>>>> ? This change does not parse: >>>>>> >>>>>> ?? ? ? // The VM thread should not execute here because >>>>>> MutexLocker's are used >>>>>> ? ? -? // as (opposed to MutexLockerEx's). >>>>>> ? ? +? // as (opposed to MutexLocker's). >>>>>> >>>>>> ? since MutexLocker is now on both sides of the verbal comparison. >>>>> Yeah, I missed that too.? It doesn't actually make sense before >>>>> either, since there isn't a MutexLocker nearby. >>>>> >>>>>> >>>>>> In some cases, there were multi-line MutexLocker uses that you chose >>>>>> to combine into a single line, but in most cases you did not combine >>>>>> them. I couldn't discern a rhyme or reason for the choices (not even >>>>>> a line length of 80). >>>>> >>>>> I combined them if the length wasn't "too long" and it didn't look >>>>> like the whitespace was helpful.? I did both. >>>>>> >>>>>> There is a startling number of names in use for the MutexLocker >>>>>> variables. My personal preference would be for 'ml' (and 'ul' >>>>>> for the MutexUnlocker). You have an opportunity to make them all >>>>>> consistent, but that's hard to do. >>>>> >>>>> By convention, ml is used a lot but sometimes you can't use it.? I >>>>> don't want to change this.? Sometimes people pick names they like >>>>> for this. >>>>>> >>>>>> Thumbs up! If you choose to handle and of my comments above, >>>>>> I don't need to see another webrev. >>>>> >>>>> Thank you Dan for reviewing this!? I'll retest with edits made for >>>>> comments above. >>>>> >>>>> Coleen >>>>> >>>>>> >>>>>> Dan >>>>>> >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8222811 >>>>>>> >>>>>>> Thanks! >>>>>>> Coleen >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > From david.holmes at oracle.com Fri Apr 26 04:41:18 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Apr 2019 14:41:18 +1000 Subject: RFR: 8221639: [x32] expand_exec_shield_cs_limit workaround is undefined code after JDK-8199717 In-Reply-To: <87k1fjh6ja.fsf@oldenburg2.str.redhat.com> References: <673a0cc6b25fcfdcb3f3c69f4dcfd06d346e271a.camel@redhat.com> <87k1fjh6ja.fsf@oldenburg2.str.redhat.com> Message-ID: <1cb99e07-b4c9-725d-8cca-fbc26661a8c5@oracle.com> On 24/04/2019 11:33 pm, Florian Weimer wrote: > * Severin Gehwolf: > >> Hi, >> >> Could I please get reviews for this Linux x32 fix? JDK-8199717 added a >> performance optimization to only capture the initial stack size when >> launched via non-java launchers. However, on Linux x32, > > Do you mean actual x32, or i386? These two are different. The code is selected based on the IA32 define which is set for a detected architecture of "i?86" as returned by uname I presume. I had assumed this was simply equivalent to 32-but x86, but apparently x32 is something else. > Can you actually verify changes in this area? I think it's pretty hard > these days to find a machine that actually uses the CS hack to avoid > universal read-implies-exec. I don't think this was ever part of any > mainline kernel. According to: https://bugs.openjdk.java.net/browse/JDK-8023956 A number of mainline kernels were affected: "RHEL 5 & 6 are affected, and earlier Ubuntu releases 10.04 (LTS), 11.04, and 12.04 have also taken in the patch. " David ----- > Thanks, > Florian > From david.holmes at oracle.com Fri Apr 26 06:28:42 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Apr 2019 16:28:42 +1000 Subject: Metaspace OOM before reaching MaxMetaspaceSize In-Reply-To: References: Message-ID: <2709d948-74d9-134b-fcf4-bcefc11fc648@oracle.com> Hi Shengpei, On 26/04/2019 10:19 am, Shengpei Zhang wrote: > Hi, > > We recently saw a weird Metaspace OOM. The hs_err_pid log showed the > metaspace usage was 325078K, while the MaxMetaspaceSize was set to 4G. The log shows the mmap failure occurs when trying to create the stack guard pages of the new thread - nothing related to Metaspace. Cheers, David > The machine was running JAVA10. > > Few observations: > > 1. It only happened at one machine, and we were not able to reproduce it. > > 2. Error log indicated memory allocation failure in native memory. > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > Chunkmanager (non-class): > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > 62578 specialized (128 bytes) chunks, total 64079872 bytes > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] 5778 > small (512 bytes) chunks, total 23666688 bytes > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] 27 > medium (8192 bytes) chunks, total 1769472 bytes > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] 13 > humongous chunks, total 8890368 bytes > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > total size: 98406400 bytes. > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > Chunkmanager (class): > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > unavailable. > java.lang.OutOfMemoryError: Metaspace > Dumping heap to java_pid240.hprof ... > vmop [ threads: total > initially_running wait_to_block ][ time: spin block sync cleanup > vmop ] page_trap_count > 66467.977: ICBufferFull [ 3427 > 154 353 ][ 0 60 63 8 0 ] > 58 > [2019-03-29T11:18:01.308-0700][459 ][info ][safepoint ] Total > time for which application threads were stopped: 0.0725507 seconds, > Stopping threads took: 0.0630158 seconds > [thread 384508 also had an error] > # > # There is insufficient memory for the Java Runtime Environment to continue. > # Native memory allocation (mmap) failed to map 16384 bytes for committing > reserved memory. > # An error report file with more information is saved as: > # /data/hs_err_pid240.log > > 3. The hs_err_pid log showed the metaspace memory usage was 325078K, it is > far less than the reserved size 568176K. Also, the MaxMetaspaceSize was set > to 4G. I checked the machine had plenty of free native memory at that time. > If there was a huge allocation, I assume JVM would try to reserve more > memory first? > > Heap: > garbage-first heap total 188743680K, used 47178320K [0x00007ee320000000, > 0x00007f1020000000) > region size 32768K, 70 young (2293760K), 0 survivors (0K) > Metaspace used 325078K, capacity 451348K, committed 547448K, > reserved 568176K > > Also it showed that there was 5G free memory on the machine: > > /proc/meminfo: > MemTotal: 263892284 kB > MemFree: 5111480 kB > MemAvailable: 42423728 kB > Buffers: 752620 kB > Cached: 36011560 kB > SwapCached: 0 kB > Active: 221763832 kB > Inactive: 31633872 kB > > 4. The stacktrace > > --------------- T H R E A D --------------- > > Current thread (0x00007edec0023840): JavaThread > "http-client-exchange-39327" daemon [_thread_new, id=384507, > stack(0x00007ed6c8a6b000,0x00007ed6c8c6c000)] > > Stack: [0x00007ed6c8a6b000,0x00007ed6c8c6c000], sp=0x00007ed6c8c6aa90, > free space=2046k > Native frames: (J=compiled Java code, A=aot compiled Java code, > j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0xdf3ee2] VMError::report_and_die(int, char const*, char > const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, > int, unsigned long)+0x162 > V [libjvm.so+0xdf4b8b] VMError::report_and_die(Thread*, char const*, int, > unsigned long, VMErrorType, char const*, __va_list_tag*)+0x2b > V [libjvm.so+0x6a7c98] report_vm_out_of_memory(char const*, int, unsigned > long, VMErrorType, char const*, ...)+0xd8 > V [libjvm.so+0xbfdc8e] os::pd_commit_memory(char*, unsigned long, > bool)+0xce > V [libjvm.so+0xbf647f] os::commit_memory(char*, unsigned long, bool)+0x1f > V [libjvm.so+0xbff1f8] os::pd_create_stack_guard_pages(char*, unsigned > long)+0x68 > V [libjvm.so+0xd9013c] JavaThread::create_stack_guard_pages()+0x5c > V [libjvm.so+0xd92c7c] JavaThread::run()+0x2c > V [libjvm.so+0xc03e82] thread_native_entry(Thread*)+0xf2 > C [libpthread.so.0+0x7e25] start_thread+0xc5 > > We have never seen such issue before. Does anyone have insights? > > Thanks, > Shengpei > From thomas.schatzl at oracle.com Fri Apr 26 06:45:43 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 26 Apr 2019 08:45:43 +0200 Subject: Metaspace OOM before reaching MaxMetaspaceSize In-Reply-To: References: Message-ID: <21f1c70851f20f0036bd754179ddb81696f6e045.camel@oracle.com> Hi, some random comments: On Thu, 2019-04-25 at 17:19 -0700, Shengpei Zhang wrote: > Hi, > > We recently saw a weird Metaspace OOM. The hs_err_pid log showed the > metaspace usage was 325078K, while the MaxMetaspaceSize was set to > 4G. > > The machine was running JAVA10. > > Few observations: > > 1. It only happened at one machine, and we were not able to reproduce > it. > > 2. Error log indicated memory allocation failure in native memory. > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > Chunkmanager (non-class): > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > 62578 specialized (128 bytes) chunks, total 64079872 bytes > [2019-03-29T11:18:01.298-0700][126538][info > ][gc,metaspace,freelist] 5778 > small (512 bytes) chunks, total 23666688 bytes > [2019-03-29T11:18:01.298-0700][126538][info > ][gc,metaspace,freelist] 27 > medium (8192 bytes) chunks, total 1769472 bytes > [2019-03-29T11:18:01.298-0700][126538][info > ][gc,metaspace,freelist] 13 > humongous chunks, total 8890368 bytes > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > total size: 98406400 bytes. > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > Chunkmanager (class): > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > unavailable. > java.lang.OutOfMemoryError: Metaspace > Dumping heap to java_pid240.hprof ... > vmop [ threads: total > initially_running wait_to_block ][ time: spin block sync > cleanup > vmop ] page_trap_count > 66467.977: ICBufferFull [ 3427 > 154 353 ][ 0 60 63 8 0 ] > 58 > [2019-03-29T11:18:01.308-0700][459 ][info ][safepoint ] > Total > time for which application threads were stopped: 0.0725507 seconds, > Stopping threads took: 0.0630158 seconds > [thread 384508 also had an error] > # > # There is insufficient memory for the Java Runtime Environment to > continue. > # Native memory allocation (mmap) failed to map 16384 bytes for > committing > reserved memory. > # An error report file with more information is saved as: > # /data/hs_err_pid240.log In Linux there is a limit on the amount of memory mappings (iirc 65k by default) if your application maps memory by itself, and does not unmap in time, you will run out of memory mappings. If the hs_err log contains lots and lots of memory mappings, this is a strong indication that this is your issue, not actual native memory pressure. See e.g. https://bugs.openjdk.java.net/browse/JDK-8216619 for more details on another example. > > 3. The hs_err_pid log showed the metaspace memory usage was 325078K, > it is far less than the reserved size 568176K. Also, the > MaxMetaspaceSize was set to 4G. I checked the machine had plenty of > free native memory at that time. If there was a huge allocation, I > assume JVM would try to reserve more memory first? Please check if your program leaks memory reservations or not, see above. The difference between usage and reservation size may be down to fragmentation: later VM versions included some patches that improve the situation. Thanks, Thomas From david.holmes at oracle.com Fri Apr 26 06:52:15 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Apr 2019 16:52:15 +1000 Subject: RFC: JWarmup precompile java hot methods at application startup In-Reply-To: References: Message-ID: Hi Yumin, On 26/04/2019 2:07 am, yumin qi wrote: > Hi, > > Apart from comments from compiler professionals can I have comments from > runtime either? The changes mostly land in runtime area. I have to question why the changes mostly land in runtime area! The high-level description of this feature does not sound like it depends on the runtime at all. The "recording" feature should just come from the JITs data; and the actual warmup should just be an interaction during VM initialization with the JIT. I don't see anything in the JEP to explain the actual design, and why it impacts on the runtime so much. It also sounds like a selective Xcomp mode to me. It even sounds very similar to Initialization-Time-Compilation (ITC) that we employed in Java Real-Time System: https://docs.oracle.com/javase/realtime/doc_2.2u1/release/JavaRTSCompilation.html Cheers, David > Thanks > Yumin > > On Tue, Apr 16, 2019 at 11:27 AM yumin qi wrote: > >> HI, >> >> Did anyone have comments for this version? >> >> Thanks >> Yumin >> >> On Tue, Apr 9, 2019 at 10:36 AM yumin qi wrote: >> >>> Alan, >>> Thanks! Updated in same link: >>> http://cr.openjdk.java.net/~minqi/8220692/webrev-02/ >>> >>> Removed non-boot loader branch in nativeLookup.cpp. >>> Added jdk.jwarmup to boot loader list in make/common/Modules.gmk. >>> Tested again to make sure the new changes. >>> >>> Thanks >>> Yumin >>> >>> >>> On Tue, Apr 9, 2019 at 4:48 AM Alan Bateman >>> wrote: >>> >>>> On 09/04/2019 07:10, yumin qi wrote: >>>>> >>>>> Now the registerNatives is found when it looks up for native entry >>>>> in lookupNative.cpp. I thought the class JWarmUp will be loaded by >>>>> boot loader like Unsafe or WhiteBox, but I was wrong, it is loaded by >>>>> app class loader so logic for obtaining its native entry put in both >>>>> cases, boot loader and non boot loaders. >>>>> >>>> make/common/Modules.gmk is where BOOT_MODULES is defined with the list >>>> of modules mapped to the boot loader. >>>> >>>> -Alan >>>> >>> From sgehwolf at redhat.com Fri Apr 26 09:15:04 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 26 Apr 2019 11:15:04 +0200 Subject: RFR: 8221639: [x32] expand_exec_shield_cs_limit workaround is undefined code after JDK-8199717 In-Reply-To: References: <673a0cc6b25fcfdcb3f3c69f4dcfd06d346e271a.camel@redhat.com> <6a9f74f3-a1de-fc2a-370b-c64055611fd9@oracle.com> <89ab6a7f-79a7-2556-29cb-5cc9289c8ae6@oracle.com> Message-ID: Hi David, Can I consider webrev 02 reviewed by yourself? Thanks, Severin On Wed, 2019-04-24 at 15:23 +0200, Severin Gehwolf wrote: > Hi David, > > On Wed, 2019-04-24 at 19:13 +1000, David Holmes wrote: > > Hi Severin, > > > > Sorry for the delay, this slipped off my rader after the break. > > No worries. > > > On 19/04/2019 12:02 am, David Holmes wrote: > > > Hi Severin, > > > > > > I'll have to delve into this more deeply (but I'm on Easter break for > > > the next 4 days). I don't recall ever being aware of > > > "suppress_primordial_thread_resolution"! > > > > Well I have a bad memory as I reviewed that particular optimisation. > > > > So, the exec_shield workaround requires knowing the process's primordial > > thread stack regardless of whether the JVM is loaded on it or not. So it > > assumes the initial_thread_stack has been determined, while we now avoid > > doing that unnecessarily. > > > > Okay the suggested fix is okay to achieve that - though alternatively it > > could be handled inside workaround_expand_exec_shield_cs_limit() via: > > > > // Need to ensure we've determined the process's initial stack to > > // perform the workaround > > if (suppress_primordial_thread_resolution) { > > Linux::capture_initial_stack(JavaThread::stack_size_at_create()); > > } > > > > I would like to see a comment like the above regardless of where you > > make the change. > > Thanks for the review! Updated webrev with the comment: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221639/02/webrev/ > > Would this be a trivial change or do I need a second reviewer? FWIW, > jdk/submit testing came back clean with this. > > Thanks, > Severin > > > Thanks, > > David > > ------ > > > > > David > > > > > > On 18/04/2019 11:41 pm, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Could I please get reviews for this Linux x32 fix? JDK-8199717 added a > > > > performance optimization to only capture the initial stack size when > > > > launched via non-java launchers. However, on Linux x32, there is old > > > > code being executed to work around the exec shield CS limit. That code > > > > depends on the initial stack size being captured. Right now this is > > > > undefined code: Pointer artithmetic on NULL pointer. > > > > > > > > src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp:884:73: runtime error: > > > > pointer index expression with base 0x00000000 overflowed to 0xffffb000 > > > > > > > > I propose to not perform the optimization of JDK-8199717 for Linux x32. > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221639 > > > > webrev: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221639/01/webrev/ > > > > > > > > Testing: release/fastdebug builds on x32 Linux, inspecting > > > > -Xlog:os=info messages, currently running through jdkd/submit. Tier 1 > > > > tests on Linux x86_64 > > > > > > > > Thoughts? > > > > > > > > Thanks, > > > > Severin > > > > From Alan.Bateman at oracle.com Fri Apr 26 10:56:00 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 26 Apr 2019 11:56:00 +0100 Subject: RFC: JWarmup precompile java hot methods at application startup In-Reply-To: References: Message-ID: <028f6a4a-b0be-bd65-519e-d76b5054e0e8@oracle.com> On 26/04/2019 07:52, David Holmes wrote: > > I have to question why the changes mostly land in runtime area! The > high-level description of this feature does not sound like it depends > on the runtime at all. The "recording" feature should just come from > the JITs data; and the actual warmup should just be an interaction > during VM initialization with the JIT. I don't see anything in the JEP > to explain the actual design, and why it impacts on the runtime so much. In addition, the draft JEP may need updating to outline the mode that requires the application to "notify" the runtime via a JDK-specific API that it has completed initialization. If this mode is part of the proposal then it should be described in the JEP. -Alan From coleen.phillimore at oracle.com Fri Apr 26 12:22:49 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 26 Apr 2019 08:22:49 -0400 Subject: RFR (L, tedious) 8222811: Consolidate MutexLockerEx and MutexLocker In-Reply-To: <3116eba3-614a-0a8c-5c3d-72c5536bc725@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> <2d1b8ba1-bda1-78c3-b2b0-13774177fcd3@oracle.com> <3116eba3-614a-0a8c-5c3d-72c5536bc725@oracle.com> Message-ID: On 4/26/19 12:25 AM, David Holmes wrote: > Hi Coleen, > > On 24/04/2019 9:57 pm, coleen.phillimore at oracle.com wrote: >> I made the change suggested by Per and it's quite nice.? I also fixed >> Mutex to not have bodies for the private functions since that's not >> required to get a compilation error if one uses them. > > Not required for attempted use outside the class, but if you call them > from within the class then I think you'll just execute the inherited > methods - yes? Not that it makes any sense to do such a thing but ... > I don't know what the original intent was here. I'm okay with getting > rid of the code bloat. If you use these private methods from within the class, you'll get a link error. Thanks for looking at the rest. Coleen > > Other changes seem okay. > > Thanks, > David > ----- > >> http://cr.openjdk.java.net/~coleenp/2019/8222811.03.incr/webrev/index.html >> >> >> Running again through mach5. >> >> Thanks, >> Coleen >> >> On 4/24/19 7:23 AM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 4/23/19 9:48 PM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> On 24/04/2019 8:49 am, coleen.phillimore at oracle.com wrote: >>>>> >>>>> Here's a new webrev with the changes requested by Dan. >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.02/webrev >>>> >>>> Overall this seems fine. A few comments on the main changes: >>>> >>>> mutex.cpp >>>> >>>> ?156 bool Monitor::wait_without_safepoint_check(long timeout) { >>>> ?157?? // Make sure safepoint checking is used properly. >>>> ?158?? assert(_safepoint_check_required != >>>> Monitor::_safepoint_check_always, >>>> ?159????????? "This lock should never have a safepoint check: %s", >>>> name()); >>>> >>>> The message is the wrong one: s/never/always/ >>> >>> I had both of these messages reversed in wait*() functions wrt. >>> never/always.? If a lock L has safepoint_check_required = always and >>> locks or waits without safepoint check, the message is relative to >>> the lock, not the erroneous call.? Inverse for never. >>> >>> Thanks for finding this. >>>> >>>> wait_without_safepoint_check is missing: >>>> >>>> ? // timeout is in milliseconds - with zero meaning never timeout >>>> ? assert(timeout >= 0, "negative timeout"); >>>> >>> >>> Fixed. >>> >>>> --- >>>> >>>> mutexLocker.hpp >>>> >>>> 190? protected: >>>> 191?? Monitor* _mutex; >>>> >>>> Good catch on the redundant extra field in MonitorLocker! >>> >>> Thanks. >>>> >>>> 208?? MutexLocker(Monitor* mutex, Thread* thread, >>>> Mutex::SafepointCheckFlag flag = Mutex::_safepoint_check_flag) : >>>> >>>> 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. >>> >>> I also want to have a patch (I think I said this), to make the >>> Thread argument first.? I could try some more tricks to avoid this >>> duplication when/if I do that.?? How does that sound? >>> >>> Thanks for reviewing! >>> Coleen >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 4/23/19 6:18 PM, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>> Hi Dan, Thank you for tackling this code review.? I was hoping >>>>>> you wouldn't do your usual file-by-file comments.? It would have >>>>>> been long. >>>>>> >>>>>> On 4/23/19 5:43 PM, Daniel D. Daugherty wrote: >>>>>>> On 4/23/19 11:06 AM, coleen.phillimore at oracle.com wrote: >>>>>>>> Summary: Make MutexLocker be MutexLockerEx implementation, >>>>>>>> remove MutexLockerEx calls. Also added >>>>>>>> wait_without_safepoint_check(). >>>>>>>> >>>>>>>> Also made safepoint_check_flag an enum, renamed MonitorLockerEx >>>>>>>> to MonitorLocker, removed MutexUnlockerEx, and fixed formatting >>>>>>>> where affected by this change. >>>>>>>> >>>>>>>> There's a MutexLocker constructor with a Thread parameter that >>>>>>>> would actually be more performant if the thread is passed from >>>>>>>> the current context rather than calling Thread::current() in >>>>>>>> Monitor::lock.? I think the Thread parameter should be moved to >>>>>>>> first so that we can have MutexLocker look like the Handle >>>>>>>> constructor calls, for example.? I didn't make this change in >>>>>>>> this. >>>>>>>> >>>>>>>> ?? MutexLocker ml(THREAD, Monitor_lock). >>>>>>>> >>>>>>>> The interesting changes are in: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutexLocker.hpp.udiff.html >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.hpp.udiff.html >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev/src/hotspot/share/runtime/mutex.cpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> The rest is pattern substitution. >>>>>>>> >>>>>>>> Ran mach5 tier1-6 tests. >>>>>>>> >>>>>>>> open webrev at >>>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8222811.01/webrev >>>>>>> >>>>>>> src/hotspot/share/runtime/mutexLocker.hpp >>>>>>> ??? L198: ????? assert(_mutex->rank() > Mutex::special || >>>>>>> no_safepoint_check, >>>>>>> ??? L199: ??????? "Mutexes with rank special or lower should not >>>>>>> do safepoint checks"); >>>>>>> ??????? nit - indent on L199 needs 5 more spaces >>>>>>> >>>>>>> ??? L200-203 - this if-block is missing the usual HotSpot '{' >>>>>>> and '}'. >>>>>>> ??? (Not your fault, but since you're in there...) >>>>>>> >>>>>>> ??? L211: ????? assert(_mutex->rank() > Mutex::special || >>>>>>> no_safepoint_check, >>>>>>> ??? L212: ??????? "Mutexes with rank special or lower should not >>>>>>> do safepoint checks"); >>>>>>> ??????? nit - indent on L211 needs 5 more spaces >>>>>>> >>>>>>> ??? L213-216 - this if-block is missing the usual HotSpot '{' >>>>>>> and '}'. >>>>>>> ??? (Not your fault, but since you're in there...) >>>>>> >>>>>> Fixed all of these.? Since I've touched it, I made it follow the >>>>>> coding style. >>>>>> >>>>>>> >>>>>>> src/hotspot/share/runtime/mutex.hpp >>>>>>> ??? L237: ?? // why do these need bodies? >>>>>>> ??????? To prevent any calls to Mutex::notify(), >>>>>>> Mutex::notify_all(), >>>>>>> ??????? Mutex::wait() and Mutex::wait_without_safepoint_check() >>>>>>> from >>>>>>> ??????? calling the superclass' version of those functions. >>>>>>> >>>>>> >>>>>> I forgot to check this, but if they're private, they shouldn't >>>>>> need bodies.? I'll remove the comment and leave them for now. >>>>>> >>>>>> >>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>> ??? Nice detangling into Monitor::wait() and >>>>>>> ??? Monitor::wait_without_safepoint_check(). >>>>>>> >>>>>> Thank you! >>>>>> >>>>>>> >>>>>>> For the rest of the files, I went through the patch from bottom >>>>>>> -> top >>>>>>> and looked for anything that didn't look right. I figure other >>>>>>> reviewers >>>>>>> are looking from top -> bottom... :-) >>>>>>> >>>>>>> For the multi-line MutexLocker uses in >>>>>>> src/hotspot/share/runtime/vmThread.cpp >>>>>>> and src/hotspot/share/memory/metaspace.cpp, >>>>>>> the second line indents appear to be off by two spaces (because >>>>>>> "Ex" was removed). >>>>>>> Don't know if you want to fix those or not. Your call. >>>>>> >>>>>> You have good eyes.? I checked all of these this morning and I >>>>>> missed these files.? Thank you. >>>>>>> >>>>>>> src/hotspot/share/runtime/threadSMR.cpp >>>>>>> >>>>>>> ? - >>>>>>> ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, >>>>>>> 0, >>>>>>> ? - !Mutex::_as_suspend_equivalent_flag); >>>>>>> ? + >>>>>>> ThreadsSMRSupport::delete_lock()->wait_without_safepoint_check(); >>>>>>> >>>>>>> ? You dropped the '!Mutex::_as_suspend_equivalent_flag' flag. I >>>>>>> dislike >>>>>>> ? default values so that's why I included it. Now the reader has to >>>>>>> ? ? 1) remember that there's another parameter >>>>>>> ? ? 2) go find the default value for that parameter >>>>>> >>>>>> wait_without_safepoint_check() doesn't have as_suspend_equivalent >>>>>> flag as a parameter.? That code was only used in the safepoint >>>>>> checking case for wait. I dislike default parameters too for the >>>>>> same reasons. Both waits take 0 as the timeout default parameter >>>>>> but I thought that was not a good thing to change. >>>>>> >>>>>>> >>>>>>> src/hotspot/share/gc/shared/workgroup.cpp >>>>>>> ? This change does not parse: >>>>>>> >>>>>>> ?? ? ? // The VM thread should not execute here because >>>>>>> MutexLocker's are used >>>>>>> ? ? -? // as (opposed to MutexLockerEx's). >>>>>>> ? ? +? // as (opposed to MutexLocker's). >>>>>>> >>>>>>> ? since MutexLocker is now on both sides of the verbal comparison. >>>>>> Yeah, I missed that too.? It doesn't actually make sense before >>>>>> either, since there isn't a MutexLocker nearby. >>>>>> >>>>>>> >>>>>>> In some cases, there were multi-line MutexLocker uses that you >>>>>>> chose >>>>>>> to combine into a single line, but in most cases you did not >>>>>>> combine >>>>>>> them. I couldn't discern a rhyme or reason for the choices (not >>>>>>> even >>>>>>> a line length of 80). >>>>>> >>>>>> I combined them if the length wasn't "too long" and it didn't >>>>>> look like the whitespace was helpful.? I did both. >>>>>>> >>>>>>> There is a startling number of names in use for the MutexLocker >>>>>>> variables. My personal preference would be for 'ml' (and 'ul' >>>>>>> for the MutexUnlocker). You have an opportunity to make them all >>>>>>> consistent, but that's hard to do. >>>>>> >>>>>> By convention, ml is used a lot but sometimes you can't use it.? >>>>>> I don't want to change this.? Sometimes people pick names they >>>>>> like for this. >>>>>>> >>>>>>> Thumbs up! If you choose to handle and of my comments above, >>>>>>> I don't need to see another webrev. >>>>>> >>>>>> Thank you Dan for reviewing this!? I'll retest with edits made >>>>>> for comments above. >>>>>> >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8222811 >>>>>>>> >>>>>>>> Thanks! >>>>>>>> Coleen >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >> From david.holmes at oracle.com Fri Apr 26 12:15:22 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Apr 2019 22:15:22 +1000 Subject: RFR: 8221639: [x32] expand_exec_shield_cs_limit workaround is undefined code after JDK-8199717 In-Reply-To: References: <673a0cc6b25fcfdcb3f3c69f4dcfd06d346e271a.camel@redhat.com> <6a9f74f3-a1de-fc2a-370b-c64055611fd9@oracle.com> <89ab6a7f-79a7-2556-29cb-5cc9289c8ae6@oracle.com> Message-ID: <9c112d1b-6290-940e-ca65-51e8e128b4b9@oracle.com> On 26/04/2019 7:15 pm, Severin Gehwolf wrote: > Hi David, > > Can I consider webrev 02 reviewed by yourself? Of course. Thanks for adding the comment. David > Thanks, > Severin > > On Wed, 2019-04-24 at 15:23 +0200, Severin Gehwolf wrote: >> Hi David, >> >> On Wed, 2019-04-24 at 19:13 +1000, David Holmes wrote: >>> Hi Severin, >>> >>> Sorry for the delay, this slipped off my rader after the break. >> >> No worries. >> >>> On 19/04/2019 12:02 am, David Holmes wrote: >>>> Hi Severin, >>>> >>>> I'll have to delve into this more deeply (but I'm on Easter break for >>>> the next 4 days). I don't recall ever being aware of >>>> "suppress_primordial_thread_resolution"! >>> >>> Well I have a bad memory as I reviewed that particular optimisation. >>> >>> So, the exec_shield workaround requires knowing the process's primordial >>> thread stack regardless of whether the JVM is loaded on it or not. So it >>> assumes the initial_thread_stack has been determined, while we now avoid >>> doing that unnecessarily. >>> >>> Okay the suggested fix is okay to achieve that - though alternatively it >>> could be handled inside workaround_expand_exec_shield_cs_limit() via: >>> >>> // Need to ensure we've determined the process's initial stack to >>> // perform the workaround >>> if (suppress_primordial_thread_resolution) { >>> Linux::capture_initial_stack(JavaThread::stack_size_at_create()); >>> } >>> >>> I would like to see a comment like the above regardless of where you >>> make the change. >> >> Thanks for the review! Updated webrev with the comment: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221639/02/webrev/ >> >> Would this be a trivial change or do I need a second reviewer? FWIW, >> jdk/submit testing came back clean with this. >> >> Thanks, >> Severin >> >>> Thanks, >>> David >>> ------ >>> >>>> David >>>> >>>> On 18/04/2019 11:41 pm, Severin Gehwolf wrote: >>>>> Hi, >>>>> >>>>> Could I please get reviews for this Linux x32 fix? JDK-8199717 added a >>>>> performance optimization to only capture the initial stack size when >>>>> launched via non-java launchers. However, on Linux x32, there is old >>>>> code being executed to work around the exec shield CS limit. That code >>>>> depends on the initial stack size being captured. Right now this is >>>>> undefined code: Pointer artithmetic on NULL pointer. >>>>> >>>>> src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp:884:73: runtime error: >>>>> pointer index expression with base 0x00000000 overflowed to 0xffffb000 >>>>> >>>>> I propose to not perform the optimization of JDK-8199717 for Linux x32. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221639 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221639/01/webrev/ >>>>> >>>>> Testing: release/fastdebug builds on x32 Linux, inspecting >>>>> -Xlog:os=info messages, currently running through jdkd/submit. Tier 1 >>>>> tests on Linux x86_64 >>>>> >>>>> Thoughts? >>>>> >>>>> Thanks, >>>>> Severin >>>>> > From fweimer at redhat.com Fri Apr 26 12:37:48 2019 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 26 Apr 2019 14:37:48 +0200 Subject: RFR: 8221639: [x32] expand_exec_shield_cs_limit workaround is undefined code after JDK-8199717 References: <673a0cc6b25fcfdcb3f3c69f4dcfd06d346e271a.camel@redhat.com> <87k1fjh6ja.fsf@oldenburg2.str.redhat.com> <1cb99e07-b4c9-725d-8cca-fbc26661a8c5@oracle.com> Message-ID: <8736m57xib.fsf@oldenburg2.str.redhat.com> * David Holmes: > On 24/04/2019 11:33 pm, Florian Weimer wrote: >> * Severin Gehwolf: >> >>> Hi, >>> >>> Could I please get reviews for this Linux x32 fix? JDK-8199717 added a >>> performance optimization to only capture the initial stack size when >>> launched via non-java launchers. However, on Linux x32, >> >> Do you mean actual x32, or i386? These two are different. > > The code is selected based on the IA32 define which is set for a > detected architecture of "i?86" as returned by uname I presume. > > I had assumed this was simply equivalent to 32-but x86, but apparently > x32 is something else. > >> Can you actually verify changes in this area? I think it's pretty hard >> these days to find a machine that actually uses the CS hack to avoid >> universal read-implies-exec. I don't think this was ever part of any >> mainline kernel. > > According to: > > https://bugs.openjdk.java.net/browse/JDK-8023956 > > A number of mainline kernels were affected: > > "RHEL 5 & 6 are affected, and earlier Ubuntu releases 10.04 (LTS), > 11.04, and 12.04 have also taken in the patch. " I meant mainline as in kernel.org. The RHEL 6 kernel requires PAE, so you need to find a box which supports PAE but not NX. These are more common than I expected (at least in our labs). So the changes should indeed be testable, and the CS limit workaround may still be needed. Thanks, Florian From kuaiwei.kw at alibaba-inc.com Fri Apr 26 12:53:33 2019 From: kuaiwei.kw at alibaba-inc.com (Kuai Wei) Date: Fri, 26 Apr 2019 20:53:33 +0800 Subject: =?UTF-8?B?UmU6IFJGQzogSldhcm11cCBwcmVjb21waWxlIGphdmEgaG90IG1ldGhvZHMgYXQgYXBwbGlj?= =?UTF-8?B?YXRpb24gc3RhcnR1cA==?= In-Reply-To: References: , Message-ID: <0f11a565-930f-4456-b2fa-3cb9bc476c16.kuaiwei.kw@alibaba-inc.com> Hi David, I try to add more info about JWarmup. Yumin may explain more detail later. In record phase, JWarmup will record hot methods and the class initialize order. We believe class order is important. Without it, most warmup compilation will be failed by deopt. In warmup phase, JVM will check init order before warmup compilation. If the recorded dependent classes are initialized, (the classes may not be really dependent, we just check the init order), the methods will be warmup compiled. So we delay warmup compilation after JVM startup, we need wait JVM to load most classes. Thanks, Kuai Wei ------------------------------------------------------------------ From:David Holmes Send Time:2019?4?26?(???) 14:54 To:yumin qi ; hotspot-runtim. Cc:hotspot-dev Subject:Re: RFC: JWarmup precompile java hot methods at application startup Hi Yumin, On 26/04/2019 2:07 am, yumin qi wrote: > Hi, > > Apart from comments from compiler professionals can I have comments from > runtime either? The changes mostly land in runtime area. I have to question why the changes mostly land in runtime area! The high-level description of this feature does not sound like it depends on the runtime at all. The "recording" feature should just come from the JITs data; and the actual warmup should just be an interaction during VM initialization with the JIT. I don't see anything in the JEP to explain the actual design, and why it impacts on the runtime so much. It also sounds like a selective Xcomp mode to me. It even sounds very similar to Initialization-Time-Compilation (ITC) that we employed in Java Real-Time System: https://docs.oracle.com/javase/realtime/doc_2.2u1/release/JavaRTSCompilation.html Cheers, David > Thanks > Yumin > > On Tue, Apr 16, 2019 at 11:27 AM yumin qi wrote: > >> HI, >> >> Did anyone have comments for this version? >> >> Thanks >> Yumin >> >> On Tue, Apr 9, 2019 at 10:36 AM yumin qi wrote: >> >>> Alan, >>> Thanks! Updated in same link: >>> http://cr.openjdk.java.net/~minqi/8220692/webrev-02/ >>> >>> Removed non-boot loader branch in nativeLookup.cpp. >>> Added jdk.jwarmup to boot loader list in make/common/Modules.gmk. >>> Tested again to make sure the new changes. >>> >>> Thanks >>> Yumin >>> >>> >>> On Tue, Apr 9, 2019 at 4:48 AM Alan Bateman >>> wrote: >>> >>>> On 09/04/2019 07:10, yumin qi wrote: >>>>> >>>>> Now the registerNatives is found when it looks up for native entry >>>>> in lookupNative.cpp. I thought the class JWarmUp will be loaded by >>>>> boot loader like Unsafe or WhiteBox, but I was wrong, it is loaded by >>>>> app class loader so logic for obtaining its native entry put in both >>>>> cases, boot loader and non boot loaders. >>>>> >>>> make/common/Modules.gmk is where BOOT_MODULES is defined with the list >>>> of modules mapped to the boot loader. >>>> >>>> -Alan >>>> >>> From coleen.phillimore at oracle.com Fri Apr 26 13:10:58 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 26 Apr 2019 09:10:58 -0400 Subject: RFR (S) 8222988: Use MonitorLocker rather than MutexLocker when wait/notify used Message-ID: Summary: fixed use cases in code except CMS. This affects some GC code and runtime code.? It looks like a nice change to me.? Tested with hs tier1-3. open webrev at http://cr.openjdk.java.net/~coleenp/2019/8222988.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8222988 Thanks, Coleen From robbin.ehn at oracle.com Fri Apr 26 14:27:09 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 26 Apr 2019 16:27:09 +0200 Subject: RFR (S) 8222988: Use MonitorLocker rather than MutexLocker when wait/notify used In-Reply-To: References: Message-ID: <751cc7f3-43a9-6367-c77c-a0bf2735804c@oracle.com> Hi Coleen, Looks good, thanks! /Robbin On 4/26/19 3:10 PM, coleen.phillimore at oracle.com wrote: > Summary: fixed use cases in code except CMS. > > This affects some GC code and runtime code.? It looks like a nice change to me. > Tested with hs tier1-3. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8222988.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8222988 > > Thanks, > Coleen From coleen.phillimore at oracle.com Fri Apr 26 15:35:05 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 26 Apr 2019 11:35:05 -0400 Subject: RFR (S) 8222988: Use MonitorLocker rather than MutexLocker when wait/notify used In-Reply-To: <751cc7f3-43a9-6367-c77c-a0bf2735804c@oracle.com> References: <751cc7f3-43a9-6367-c77c-a0bf2735804c@oracle.com> Message-ID: <3a1d707d-3b80-c406-f154-463f441ec2c5@oracle.com> Thanks Robbin! Coleen On 4/26/19 10:27 AM, Robbin Ehn wrote: > Hi Coleen, > > Looks good, thanks! > > /Robbin > > On 4/26/19 3:10 PM, coleen.phillimore at oracle.com wrote: >> Summary: fixed use cases in code except CMS. >> >> This affects some GC code and runtime code.? It looks like a nice >> change to me.? Tested with hs tier1-3. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8222988.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8222988 >> >> Thanks, >> Coleen From coleen.phillimore at oracle.com Fri Apr 26 16:10:15 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 26 Apr 2019 12:10:15 -0400 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads Message-ID: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> Summary: Use safepoint_check_always/safepoint_check_never instead of safepoint_check_sometimes for locks that are taken by JavaThreads and non-JavaThreads This patch moves all but 3 of the locks to not be safepoint_check_sometimes.? We have plans to fix these three.? Also, 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. 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 Thanks, Coleen From yumin.qi at gmail.com Fri Apr 26 17:41:30 2019 From: yumin.qi at gmail.com (yumin qi) Date: Fri, 26 Apr 2019 10:41:30 -0700 Subject: RFC: JWarmup precompile java hot methods at application startup In-Reply-To: <0f11a565-930f-4456-b2fa-3cb9bc476c16.kuaiwei.kw@alibaba-inc.com> References: <0f11a565-930f-4456-b2fa-3cb9bc476c16.kuaiwei.kw@alibaba-inc.com> Message-ID: David, Wei Thanks for your comment. Java RTS has an option -XX:PreInitList=my-preinit-file which stores the pre-init class list. Will the classes in that list be initialized in order? JWarmUp recorded the class init order in pre-run to prevent runtime unnecessary deoptimization due to class initialization out of order. The current design is wait for vm finished startup to startup warm up. We have tried compile when class loading and found many problems so decided go with current design. You said it is like selective -Xcomp, yes, it looks like in first, but next we will enhance with method profiling information to make more optimized code. The changes have been made to many runtime files, so need comments from runtime either. Thanks Yumin On Fri, Apr 26, 2019 at 5:53 AM Kuai Wei wrote: > Hi David, > > I try to add more info about JWarmup. Yumin may explain more detail > later. > > In record phase, JWarmup will record hot methods and the class > initialize order. We believe class order is important. Without it, most > warmup compilation will be failed by deopt. > > In warmup phase, JVM will check init order before warmup compilation. If > the recorded dependent classes are initialized, (the classes may not be > really dependent, we just check the init order), the methods will be warmup > compiled. So we delay warmup compilation after JVM startup, we need wait > JVM to load most classes. > > Thanks, > Kuai Wei > > ------------------------------------------------------------------ > From:David Holmes > Send Time:2019?4?26?(???) 14:54 > To:yumin qi ; hotspot-runtim. < > hotspot-runtime-dev at openjdk.java.net> > Cc:hotspot-dev > Subject:Re: RFC: JWarmup precompile java hot methods at application startup > > Hi Yumin, > > On 26/04/2019 2:07 am, yumin qi wrote: > > Hi, > > > > > Apart from comments from compiler professionals can I have comments from > > runtime either? The changes mostly land in runtime area. > > I have to question why the changes mostly land in runtime area! The > high-level description of this feature does not sound like it depends on > the runtime at all. The "recording" feature should just come from the > JITs data; and the actual warmup should just be an interaction during VM > initialization with the JIT. I don't see anything in the JEP to explain > the actual design, and why it impacts on the runtime so much. > > It also sounds like a selective Xcomp mode to me. > > It even sounds very similar to Initialization-Time-Compilation (ITC) > that we employed in Java Real-Time System: > > > https://docs.oracle.com/javase/realtime/doc_2.2u1/release/JavaRTSCompilation.html > > > Cheers, > David > > > Thanks > > Yumin > > > > On Tue, Apr 16, 2019 at 11:27 AM yumin qi wrote: > > > >> HI, > >> > >> Did anyone have comments for this version? > >> > >> Thanks > >> Yumin > >> > >> On Tue, Apr 9, 2019 at 10:36 AM yumin qi wrote: > >> > >>> Alan, > >>> Thanks! Updated in same link: > >>> http://cr.openjdk.java.net/~minqi/8220692/webrev-02/ > >>> > >>> Removed non-boot loader branch in nativeLookup.cpp. > >>> Added jdk.jwarmup to boot loader list in make/common/Modules.gmk. > >>> Tested again to make sure the new changes. > >>> > >>> Thanks > >>> Yumin > >>> > >>> > >>> On Tue, Apr 9, 2019 at 4:48 AM Alan Bateman > >>> wrote: > >>> > >>>> On 09/04/2019 07:10, yumin qi wrote: > >>>>> > >>>>> Now the registerNatives is found when it looks up for native entry > >>>>> in lookupNative.cpp. I thought the class JWarmUp will be loaded by > >>>>> boot loader like Unsafe or WhiteBox, but I was wrong, it is loaded by > >>>>> app class loader so logic for obtaining its native entry put in both > >>>>> cases, boot loader and non boot loaders. > >>>>> > >>>> make/common/Modules.gmk is where BOOT_MODULES is defined with the list > >>>> of modules mapped to the boot loader. > >>>> > >>>> -Alan > >>>> > >>> > > From yumin.qi at gmail.com Fri Apr 26 17:42:12 2019 From: yumin.qi at gmail.com (yumin qi) Date: Fri, 26 Apr 2019 10:42:12 -0700 Subject: RFC: JWarmup precompile java hot methods at application startup In-Reply-To: <028f6a4a-b0be-bd65-519e-d76b5054e0e8@oracle.com> References: <028f6a4a-b0be-bd65-519e-d76b5054e0e8@oracle.com> Message-ID: Hi, Alan Thanks! I will update the JEP for this information. Thanks Yumin On Fri, Apr 26, 2019 at 3:56 AM Alan Bateman wrote: > On 26/04/2019 07:52, David Holmes wrote: > > > > I have to question why the changes mostly land in runtime area! The > > high-level description of this feature does not sound like it depends > > on the runtime at all. The "recording" feature should just come from > > the JITs data; and the actual warmup should just be an interaction > > during VM initialization with the JIT. I don't see anything in the JEP > > to explain the actual design, and why it impacts on the runtime so much. > In addition, the draft JEP may need updating to outline the mode that > requires the application to "notify" the runtime via a JDK-specific API > that it has completed initialization. If this mode is part of the > proposal then it should be described in the JEP. > > -Alan > From coleen.phillimore at oracle.com Fri Apr 26 19:22:14 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 26 Apr 2019 15:22:14 -0400 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> References: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> Message-ID: <7f87c37e-669e-0712-5623-5b17af4e1ec8@oracle.com> On 4/26/19 12:10 PM, 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 > > This patch moves all but 3 of the locks to not be > safepoint_check_sometimes.? We have plans to fix these three. Also, > 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. > > 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 > > Thanks, > Coleen One note about the additional ShutdownTest.? This is an old test that was removed that shows that Heap_lock needs to be taken in Threads::destroy_vm().?? So I've added the test back. Coleen From shengpei92 at gmail.com Fri Apr 26 20:08:48 2019 From: shengpei92 at gmail.com (Shengpei Zhang) Date: Fri, 26 Apr 2019 13:08:48 -0700 Subject: Metaspace OOM before reaching MaxMetaspaceSize In-Reply-To: <21f1c70851f20f0036bd754179ddb81696f6e045.camel@oracle.com> References: <21f1c70851f20f0036bd754179ddb81696f6e045.camel@oracle.com> Message-ID: Thanks David and Thomas, @David My impression was also that this is not related with Metaspace, but I got confused by the error msg "java.lang.OutOfMemoryError: Metaspace" here. Maybe this is a mis-classification? If that is the case, I assume some part of native memory is OOMed? It should be an area with a tight limit as there are still free memory on the machine. Do you know which part of memory the stack_guard_pages are using? @Thomas Not sure how to check number of memory mappings, from the example you provided seemed like you were counting the mappings under the "dynamic libraries" section? Then no, I checked it was ~6K. I was not able to reproduce the issue, below is a NMT diff I took just now, I didn't see anything suspicious here: Total: reserved=228671672KB +24437546KB, committed=228134376KB +24813862KB - Java Heap (reserved=188743680KB, committed=188743680KB) (mmap: reserved=188743680KB, committed=188743680KB) - Class (reserved=851747KB +655100KB, committed=830967KB +635128KB) (classes #51634 +19878) (malloc=142319KB +134088KB #3339917 +3183393) (mmap: reserved=709428KB +521012KB, committed=688648KB +501040KB) ( Metadata: ) ( reserved=0KB, committed=0KB) ( used=0KB) ( free=0KB) ( waste=0KB =-nan%) - Thread (reserved=7543768KB +5003196KB, committed=7543768KB +5003196KB) (thread #3725 +2435) (stack: reserved=7533768KB +4996620KB, committed=7533768KB +4996620KB) (malloc=5603KB +3691KB #18712 +12175) (arena=4397KB +2885 #7434 +4870) - Code (reserved=1084696KB +18645KB, committed=568180KB +414933KB) (malloc=27920KB +18645KB #75586 +41577) (mmap: reserved=1056776KB, committed=540260KB +396288KB) - GC (reserved=22058971KB +12626721KB, committed=22058971KB +12626721KB) (malloc=12911575KB +12626721KB #3259193 +3182155) (mmap: reserved=9147396KB, committed=9147396KB) - Compiler (reserved=30365KB +26208KB, committed=30365KB +26208KB) (malloc=30235KB +26208KB #20637 +15823) (arena=131KB #18) - Internal (reserved=8157510KB +5937989KB, committed=8157510KB +5937989KB) (malloc=8157478KB +5937989KB #2966920 +2914279) (mmap: reserved=32KB, committed=32KB) - Symbol (reserved=30174KB +9428KB, committed=30174KB +9428KB) (malloc=26745KB +9332KB #252220 +78699) (arena=3428KB +96 #1) - Native Memory Tracking (reserved=158258KB +149406KB, committed=158258KB +149406KB) (malloc=1839KB +1179KB #25013 +15914) (tracking overhead=156419KB +148226KB) - Arena Chunk (reserved=1388KB +1130KB, committed=1388KB +1130KB) (malloc=1388KB +1130KB) - Logging (reserved=8KB, committed=8KB) (malloc=8KB #164) - Arguments (reserved=27KB, committed=27KB) (malloc=27KB #515) - Module (reserved=11073KB +9722KB, committed=11073KB +9722KB) (malloc=11073KB +9722KB #44352 +37576) - Unknown (reserved=8KB, committed=8KB) (mmap: reserved=8KB, committed=8KB) Best, Shengpei On Thu, Apr 25, 2019 at 11:45 PM Thomas Schatzl wrote: > Hi, > > some random comments: > > On Thu, 2019-04-25 at 17:19 -0700, Shengpei Zhang wrote: > > Hi, > > > > We recently saw a weird Metaspace OOM. The hs_err_pid log showed the > > metaspace usage was 325078K, while the MaxMetaspaceSize was set to > > 4G. > > > > The machine was running JAVA10. > > > > Few observations: > > > > 1. It only happened at one machine, and we were not able to reproduce > > it. > > > > 2. Error log indicated memory allocation failure in native memory. > > > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > > Chunkmanager (non-class): > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > > 62578 specialized (128 bytes) chunks, total 64079872 bytes > > [2019-03-29T11:18:01.298-0700][126538][info > > ][gc,metaspace,freelist] 5778 > > small (512 bytes) chunks, total 23666688 bytes > > [2019-03-29T11:18:01.298-0700][126538][info > > ][gc,metaspace,freelist] 27 > > medium (8192 bytes) chunks, total 1769472 bytes > > [2019-03-29T11:18:01.298-0700][126538][info > > ][gc,metaspace,freelist] 13 > > humongous chunks, total 8890368 bytes > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > > total size: 98406400 bytes. > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > > Chunkmanager (class): > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > > unavailable. > > java.lang.OutOfMemoryError: Metaspace > > Dumping heap to java_pid240.hprof ... > > vmop [ threads: total > > initially_running wait_to_block ][ time: spin block sync > > cleanup > > vmop ] page_trap_count > > 66467.977: ICBufferFull [ 3427 > > 154 353 ][ 0 60 63 8 0 ] > > 58 > > [2019-03-29T11:18:01.308-0700][459 ][info ][safepoint ] > > Total > > time for which application threads were stopped: 0.0725507 seconds, > > Stopping threads took: 0.0630158 seconds > > [thread 384508 also had an error] > > # > > # There is insufficient memory for the Java Runtime Environment to > > continue. > > # Native memory allocation (mmap) failed to map 16384 bytes for > > committing > > reserved memory. > > # An error report file with more information is saved as: > > # /data/hs_err_pid240.log > > In Linux there is a limit on the amount of memory mappings (iirc 65k by > default) if your application maps memory by itself, and does not unmap > in time, you will run out of memory mappings. > > If the hs_err log contains lots and lots of memory mappings, this is a > strong indication that this is your issue, not actual native memory > pressure. > > See e.g. https://bugs.openjdk.java.net/browse/JDK-8216619 for more > details on another example. > > > > > 3. The hs_err_pid log showed the metaspace memory usage was 325078K, > > it is far less than the reserved size 568176K. Also, the > > MaxMetaspaceSize was set to 4G. I checked the machine had plenty of > > free native memory at that time. If there was a huge allocation, I > > assume JVM would try to reserve more memory first? > > Please check if your program leaks memory reservations or not, see > above. > > The difference between usage and reservation size may be down to > fragmentation: later VM versions included some patches that improve the > situation. > > Thanks, > Thomas > > > From vladimir.kozlov at oracle.com Fri Apr 26 22:46:36 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 26 Apr 2019 15:46:36 -0700 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: <39774cdd-de9e-c878-4a5a-f6595a93859f@oracle.com> References: <4b759550-f185-724f-7139-9bab648a1966@oracle.com> <119335f1-acb7-fffc-f38a-e50a96b73b3c@oracle.com> <2d206374-cfeb-9b1b-2838-e4e0a774e89d@oracle.com> <8063fb37-f1b0-8b93-bbe8-4dbeeaa54959@oracle.com> <17233985-18c7-305e-5556-fe2b38926b71@oracle.com> <3514c74d-5f6a-61cc-ebea-b9564df61673@oracle.com> <63b8e1d2-3516-88f5-02ac-828dd15baf83@oracle.com> <39774cdd-de9e-c878-4a5a-f6595a93859f@oracle.com> Message-ID: Hi I have 2 new deltas for easy review. Delta 1 is mostly JVMCI HotSpot refactoring and cleanup: http://cr.openjdk.java.net/~kvn/8220623/webrev_delta1.07/ - Cleanup #include jvmci files. - Removed BoolObjectClosure parameter from JVMCI::do_unloading() since it is not used. In JDK 13 this parameter is removed from other places too. - Added mtJVMCI type to track memory used by JVMCI. - Passed Handles as constant references. - Moved JNIAccessMark, JVMCIObject, MetadataHandleBlock class to separate new files. - Moved JVMCI methods bodies from jvmciRuntime.cpp into new jvmci.cpp file. - Moved bodies of some JVMCIEnv methods from .hpp into jvmciEnv.cpp file. They use JNIAccessMark and ThreadToNativeFromVM and I can't use them in header file because they require #include inline.hpp files. - Moved bodies of some HotSpotJVMCI methods into jvmciJavaClasses.cpp file because, again, they need jniHandles.inline.hpp. - Moved JVMCICompileState class definition to the beginning of jvmciEnv.hpp file. Delta 2: http://cr.openjdk.java.net/~kvn/8220623/webrev_delta2.07/ - Changed MetadataHandleBlock fields which are used only by one instance to static. - Renamed field _jmetadata::_handle to _value and corresponding access methods because it was confusing: handle->handle(). - Switched from JNIHandleBlock to OopStorage use for _object_handles. - Additional JVMCI Java side fix for libgraal. Full: http://cr.openjdk.java.net/~kvn/8220623/webrev.07/ I think I addressed all comments I received so far. Thanks, Vladimir On 4/9/19 7:25 PM, Vladimir Kozlov wrote: > Thank you, Coleen > > On 4/9/19 1:36 PM, coleen.phillimore at oracle.com wrote: >> >> I think I missed graal-dev with this reply.? I have a few other comments. >> >> +void MetadataHandleBlock::do_unloading(BoolObjectClosure* is_alive) { >> >> >> We've removed the is_alive parameter from all do_unloading, and it appears unused here also. > > Yes, I can remove it. > >> >> I don't know about this MetadataHandles block.?? It seems that it could be a concurrent hashtable with a WeakHandle<> >> if it's for jdk11 and beyond.? Kim might have mentioned this (I haven't read all the replies thoroughly) but >> JNIHandleBlock wasn't MT safe, and the new OopStorage is safe and scalable. > > Yes, Kim also suggested OopStorage. I did not get into that part yet but I will definitely do. > >> >> +? jmetadata allocate_handle(methodHandle handle)?????? { return allocate_metadata_handle(handle()); } >> +? jmetadata allocate_handle(constantPoolHandle handle) { return allocate_metadata_handle(handle()); } >> >> +CompLevel JVMCI::adjust_comp_level(methodHandle method, bool is_osr, CompLevel level, JavaThread* thread) { >> >> +JVMCIObject JVMCIEnv::new_StackTraceElement(methodHandle method, int bci, JVMCI_TRAPS) { >> >> +JVMCIObject JVMCIEnv::new_HotSpotNmethod(methodHandle method, const char* name, jboolean isDefault, jlong compileId, >> JVMCI_TRAPS) { >> >> Passing metadata Handles by copy will call the copy constructor and destructor for these parameters unnecessarily. >> They should be passed as *const* references to avoid this. > > Okay. > >> >> +class MetadataHandleBlock : public CHeapObj { >> >> >> There should be a better mt? for this.? mtCompiler seems appropriate here.? Depending on how many others of these, you >> could add an mtJVMCI. > > mtJVMCI is good suggestion. > >> >> +??????????? if (TraceNMethodInstalls) { >> >> >> We've had Unified Logging in the sources for a long time now. New code should use UL rather than adding a >> TraceSomething option.?? I understand it's supposed to be shared with JDK8 code but it seems that you're forward >> porting what looks like old code into the repository. > > Yes, we should use UL for this. > > Existing JIT code (ciEnv.cpp) still not using UL for this: > http://hg.openjdk.java.net/jdk/jdk/file/f847a42ddc01/src/hotspot/share/ci/ciEnv.cpp#l1075 > > May be I should update it too ... > >> >> Coleen >> >> >> On 4/9/19 4:00 PM, coleen.phillimore at oracle.com wrote: >>> >>> http://cr.openjdk.java.net/~kvn/8220623/webrev.06/src/hotspot/share/classfile/classFileParser.cpp.udiff.html >>> >>> It appears this change is to implement https://bugs.openjdk.java.net/browse/JDK-8193513 which we closed as WNF.? If >>> you want this change, remove it from this giant patch and reopen and submit a separate patch for this bug. > > Thank you for pointing it. I will do as you suggested. > >>> >>> It shouldn't be conditional on JVMCI and should use the normal unified logging mechanism. > > Okay. > >>> >>> http://cr.openjdk.java.net/~kvn/8220623/webrev.06/src/hotspot/share/runtime/thread.hpp.udiff.html >>> >>> *!_jlong__pending_failed_speculation;* >>> >>> >>> We've been trying to remove and avoid java types in hotspot code and use the appropriate C++ types instead.? Can this >>> be changed to int64_t?? 'long' is generally wrong though. > > This field should be java type since it is accessed from Java Graal: > > http://hg.openjdk.java.net/jdk/jdk/file/f847a42ddc01/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java#l401 > > >>> >>> I seem to remember there was code to deal with metadata in oops for redefinition, but I can't find it in this big >>> patch.? I was going to look at that. > > May be it is MetadataHandleBlock::metadata_do() (in jvmciRuntime.cpp)? > >>> >>> Otherwise, I've reviewed the runtime code. > > Thanks, > Vladimir > >>> >>> Coleen >>> >>> On 4/4/19 3:22 AM, Vladimir Kozlov wrote: >>>> New delta: >>>> http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.06/ >>>> >>>> Full: >>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.06/ >>>> >>>> New changes are based on Kim and Stefan suggestions: >>>> >>>> - Moved JVMCI::oops_do() from JNIHandles to places where it should be called. >>>> - Moved JVMCI cleanup task to the beginning of ParallelCleaningTask::work(). >>>> - Used JVMCI_ONLY macro with COMMA. >>>> - Disable JVMCI build on SPARC. We don't use it - neither Graal or AOT are built on SPARC. Disabling also helps to >>>> find missing JVMCI guards. >>>> >>>> I ran hs-tier1-3 testing - it passed (hs-tier3 includes graal testing). >>>> I started hs-tier4..8-graal testing. >>>> I will do performance testing next. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 4/3/19 9:54 AM, Vladimir Kozlov wrote: >>>>> On 4/2/19 11:35 PM, Stefan Karlsson wrote: >>>>>> On 2019-04-02 22:41, Vladimir Kozlov wrote: >>>>>>> I ran Kitchensink with G1 and -Xmx8g. I observed that Remark pause times are not consistent even without Graal. >>>>>>> To see effect I added time spent in JVMCI::do_unloading() to GC log (see below [3]). The result is < 1ms - it is >>>>>>> less than 1% of a pause time. >>>>>> >>>>>> Kitchensink isn't really a benchmark, but a stress test. I sent you a private mail how to run these changes >>>>>> through our internal performance test setup. >>>>> >>>>> Okay, I will run performance tests there too. >>>>> >>>>>> >>>>>>> >>>>>>> It will have even less effect since I moved JVMCI::do_unloading() from serial path to parallel worker thread as >>>>>>> Stefan suggested. >>>>>>> >>>>>>> Stefan, are you satisfied with these changes now? >>>>>> >>>>>> Yes, the clean-ups look good. Thanks for cleaning this up. >>>>>> >>>>>> Kim had some extra comments about a few more places where JVMCI_ONLY could be used. >>>>>> >>>>>> I also agree with him that JVMCI::oops_do should not be placed in JNIHandles::oops_do. I think you should put it >>>>>> where you put the AOTLoader::oops_do calls. >>>>> >>>>> Okay. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> Thanks, >>>>>> StefanK >>>>>> >>>>>> >>>>>>> >>>>>>> Here is latest delta update which includes previous [1] delta and >>>>>>> - use CompilerThreadStackSize * 2 for libgraal instead of exact value, >>>>>>> - removed HandleMark added for debugging (reverted changes in jvmtiImpl.cpp), >>>>>>> - added recent jvmci-8 changes to fix registration of native methods in libgraal (jvmciCompilerToVM.cpp) >>>>>>> >>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.05/ >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> [1] http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.04/ >>>>>>> [2] Original webrev http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ >>>>>>> [3] Pauses times from Kitchensink (0.0ms means there were no unloaded classes, 'NNN alive' shows how many >>>>>>> metadata references were processed): >>>>>>> >>>>>>> [1.083s][1554229160638ms][info ][gc,start???? ] GC(2) Pause Remark >>>>>>> [1.085s][1554229160639ms][info ][gc?????????? ] GC(2) JVMCI::do_unloading(): 0 alive 0.000ms >>>>>>> [1.099s][1554229160654ms][info ][gc?????????? ] GC(2) Pause Remark 28M->28M(108M) 16.123ms >>>>>>> >>>>>>> [3.097s][1554229162651ms][info ][gc,start???? ] GC(12) Pause Remark >>>>>>> [3.114s][1554229162668ms][info ][gc?????????? ] GC(12) JVMCI::do_unloading(): 3471 alive 0.164ms >>>>>>> [3.148s][1554229162702ms][info ][gc?????????? ] GC(12) Pause Remark 215M->213M(720M) 51.103ms >>>>>>> >>>>>>> [455.111s][1554229614666ms][info ][gc,phases,start] GC(1095) Phase 1: Mark live objects >>>>>>> [455.455s][1554229615010ms][info ][gc???????????? ] GC(1095) JVMCI::do_unloading(): 4048 alive 0.821ms >>>>>>> [455.456s][1554229615010ms][info ][gc,phases????? ] GC(1095) Phase 1: Mark live objects 344.107ms >>>>>>> >>>>>>> [848.932s][1554230008486ms][info ][gc,phases,start] GC(1860) Phase 1: Mark live objects >>>>>>> [849.248s][1554230008803ms][info ][gc???????????? ] GC(1860) JVMCI::do_unloading(): 3266 alive 0.470ms >>>>>>> [849.249s][1554230008803ms][info ][gc,phases????? ] GC(1860) Phase 1: Mark live objects 316.527ms >>>>>>> >>>>>>> [1163.778s][1554230323332ms][info ][gc,start?????? ] GC(2627) Pause Remark >>>>>>> [1163.932s][1554230323486ms][info ][gc???????????? ] GC(2627) JVMCI::do_unloading(): 3474 alive 0.642ms >>>>>>> [1163.941s][1554230323496ms][info ][gc???????????? ] GC(2627) Pause Remark 2502M->2486M(4248M) 163.296ms >>>>>>> >>>>>>> [1242.587s][1554230402141ms][info ][gc,phases,start] GC(2734) Phase 1: Mark live objects >>>>>>> [1242.899s][1554230402453ms][info ][gc???????????? ] GC(2734) JVMCI::do_unloading(): 3449 alive 0.570ms >>>>>>> [1242.899s][1554230402453ms][info ][gc,phases????? ] GC(2734) Phase 1: Mark live objects 311.719ms >>>>>>> >>>>>>> [1364.164s][1554230523718ms][info ][gc,phases,start] GC(3023) Phase 1: Mark live objects >>>>>>> [1364.613s][1554230524167ms][info ][gc???????????? ] GC(3023) JVMCI::do_unloading(): 3449 alive 0.000ms >>>>>>> [1364.613s][1554230524167ms][info ][gc,phases????? ] GC(3023) Phase 1: Mark live objects 448.495ms >>>>>>> >>>>>>> [1425.222s][1554230584776ms][info ][gc,phases,start] GC(3151) Phase 1: Mark live objects >>>>>>> [1425.587s][1554230585142ms][info ][gc???????????? ] GC(3151) JVMCI::do_unloading(): 3491 alive 0.882ms >>>>>>> [1425.587s][1554230585142ms][info ][gc,phases????? ] GC(3151) Phase 1: Mark live objects 365.403ms >>>>>>> >>>>>>> [1456.401s][1554230615955ms][info ][gc,phases,start] GC(3223) Phase 1: Mark live objects >>>>>>> [1456.769s][1554230616324ms][info ][gc???????????? ] GC(3223) JVMCI::do_unloading(): 3478 alive 0.616ms >>>>>>> [1456.769s][1554230616324ms][info ][gc,phases????? ] GC(3223) Phase 1: Mark live objects 368.643ms >>>>>>> >>>>>>> [1806.139s][1554230965694ms][info?? ][gc,start?????? ] GC(4014) Pause Remark >>>>>>> [1806.161s][1554230965716ms][info?? ][gc???????????? ] GC(4014) JVMCI::do_unloading(): 3478 alive 0.000ms >>>>>>> [1806.163s][1554230965717ms][info?? ][gc???????????? ] GC(4014) Pause Remark 1305M->1177M(2772M) 23.190ms >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 4/1/19 12:34 AM, Stefan Karlsson wrote: >>>>>>>> On 2019-03-29 17:55, Vladimir Kozlov wrote: >>>>>>>>> Stefan, >>>>>>>>> >>>>>>>>> Do you have a test (and flags) which can allow me to measure effect of this code on G1 remark pause? >>>>>>>> >>>>>>>> >>>>>>>> -Xlog:gc prints the remark times: >>>>>>>> [4,296s][info][gc?????? ] GC(89) Pause Remark 4M->4M(28M) 36,412ms >>>>>>>> >>>>>>>> StefanK >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 3/29/19 12:36 AM, Stefan Karlsson wrote: >>>>>>>>>> On 2019-03-29 03:07, Vladimir Kozlov wrote: >>>>>>>>>>> Hi Stefan, >>>>>>>>>>> >>>>>>>>>>> I collected some data on MetadataHandleBlock. >>>>>>>>>>> >>>>>>>>>>> First, do_unloading() code is executed only when class_unloading_occurred is 'true' - it is rare case. It >>>>>>>>>>> should not affect normal G1 remark pause. >>>>>>>>>> >>>>>>>>>> It's only rare for applications that don't do dynamic class loading and unloading. The applications that do, >>>>>>>>>> will be affected. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Second, I run a test with -Xcomp. I got about 10,000 compilations by Graal and next data at the end of >>>>>>>>>>> execution: >>>>>>>>>>> >>>>>>>>>>> max_blocks = 232 >>>>>>>>>>> max_handles_per_block = 32 (since handles array has 32 elements) >>>>>>>>>>> max_total_alive_values = 4631 >>>>>>>>>> >>>>>>>>>> OK. Thanks for the info. >>>>>>>>>> >>>>>>>>>> StefanK >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> On 3/28/19 2:44 PM, Vladimir Kozlov wrote: >>>>>>>>>>>> Thank you, Stefan >>>>>>>>>>>> >>>>>>>>>>>> On 3/28/19 12:54 PM, Stefan Karlsson wrote: >>>>>>>>>>>>> Hi Vladimir, >>>>>>>>>>>>> >>>>>>>>>>>>> I started to check the GC code. >>>>>>>>>>>>> >>>>>>>>>>>>> ======================================================================== >>>>>>>>>>>>> I see that you've added guarded includes in the middle of the include list: >>>>>>>>>>>>> ?? #include "gc/shared/strongRootsScope.hpp" >>>>>>>>>>>>> ?? #include "gc/shared/weakProcessor.hpp" >>>>>>>>>>>>> + #if INCLUDE_JVMCI >>>>>>>>>>>>> + #include "jvmci/jvmci.hpp" >>>>>>>>>>>>> + #endif >>>>>>>>>>>>> ?? #include "oops/instanceRefKlass.hpp" >>>>>>>>>>>>> ?? #include "oops/oop.inline.hpp" >>>>>>>>>>>>> >>>>>>>>>>>>> The style we use is to put these conditional includes at the end of the include lists. >>>>>>>>>>>> >>>>>>>>>>>> okay >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ======================================================================== >>>>>>>>>>>>> Could you also change the following: >>>>>>>>>>>>> >>>>>>>>>>>>> + #if INCLUDE_JVMCI >>>>>>>>>>>>> +???? // Clean JVMCI metadata handles. >>>>>>>>>>>>> +???? JVMCI::do_unloading(is_alive_closure(), purged_class); >>>>>>>>>>>>> + #endif >>>>>>>>>>>>> >>>>>>>>>>>>> to: >>>>>>>>>>>>> +???? // Clean JVMCI metadata handles. >>>>>>>>>>>>> + JVMCI_ONLY(JVMCI::do_unloading(is_alive_closure(), purged_class);) >>>>>>>>>>>>> >>>>>>>>>>>>> to get rid of some of the line noise in the GC files. >>>>>>>>>>>> >>>>>>>>>>>> okay >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ======================================================================== >>>>>>>>>>>>> In the future we will need version of JVMCI::do_unloading that supports concurrent cleaning for ZGC. >>>>>>>>>>>> >>>>>>>>>>>> Yes, we need to support concurrent cleaning in a future. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ======================================================================== >>>>>>>>>>>>> What's the performance impact for G1 remark pause with this serial walk over the MetadataHandleBlock? >>>>>>>>>>>>> >>>>>>>>>>>>> 3275 void G1CollectedHeap::complete_cleaning(BoolObjectClosure* is_alive, >>>>>>>>>>>>> 3276 bool class_unloading_occurred) { >>>>>>>>>>>>> 3277?? uint num_workers = workers()->active_workers(); >>>>>>>>>>>>> 3278?? ParallelCleaningTask unlink_task(is_alive, num_workers, class_unloading_occurred, false); >>>>>>>>>>>>> 3279 workers()->run_task(&unlink_task); >>>>>>>>>>>>> 3280 #if INCLUDE_JVMCI >>>>>>>>>>>>> 3281?? // No parallel processing of JVMCI metadata handles for now. >>>>>>>>>>>>> 3282?? JVMCI::do_unloading(is_alive, class_unloading_occurred); >>>>>>>>>>>>> 3283 #endif >>>>>>>>>>>>> 3284 } >>>>>>>>>>>> >>>>>>>>>>>> There should not be impact if Graal is not used. Only cost of call (which most likely is inlined in product >>>>>>>>>>>> VM) and check: >>>>>>>>>>>> >>>>>>>>>>>> http://hg.openjdk.java.net/metropolis/dev/file/530fc1427d02/src/hotspot/share/jvmci/jvmciRuntime.cpp#l1237 >>>>>>>>>>>> >>>>>>>>>>>> If Graal is used it should not have big impact since these metadata has regular pattern (32 handles per >>>>>>>>>>>> array and array per MetadataHandleBlock block which are linked in list) and not large. >>>>>>>>>>>> If there will be noticeable impact - we will work on it as you suggested by using ParallelCleaningTask. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ======================================================================== >>>>>>>>>>>>> Did you consider adding it as a task for one of the worker threads to execute in ParallelCleaningTask? >>>>>>>>>>>>> >>>>>>>>>>>>> See how other tasks are claimed by one worker: >>>>>>>>>>>>> void KlassCleaningTask::work() { >>>>>>>>>>>>> ?? ResourceMark rm; >>>>>>>>>>>>> >>>>>>>>>>>>> ?? // One worker will clean the subklass/sibling klass tree. >>>>>>>>>>>>> ?? if (claim_clean_klass_tree_task()) { >>>>>>>>>>>>> ???? Klass::clean_subklass_tree(); >>>>>>>>>>>>> ?? } >>>>>>>>>>>> >>>>>>>>>>>> These changes were ported from JDK8u based changes in graal-jvmci-8 and there are no ParallelCleaningTask in >>>>>>>>>>>> JDK8. >>>>>>>>>>>> >>>>>>>>>>>> Your suggestion is interesting and I agree that we should investigate it. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ======================================================================== >>>>>>>>>>>>> In MetadataHandleBlock::do_unloading: >>>>>>>>>>>>> >>>>>>>>>>>>> +??????? if (klass->class_loader_data()->is_unloading()) { >>>>>>>>>>>>> +????????? // This needs to be marked so that it's no longer scanned >>>>>>>>>>>>> +????????? // but can't be put on the free list yet. The >>>>>>>>>>>>> +????????? // ReferenceCleaner will set this to NULL and >>>>>>>>>>>>> +????????? // put it on the free list. >>>>>>>>>>>>> >>>>>>>>>>>>> I couldn't find the ReferenceCleaner in the patch or in the source. Where can I find this code? >>>>>>>>>>>> >>>>>>>>>>>> I think it is typo (I will fix it) - it references new HandleCleaner class: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HandleCleaner.java.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> StefanK >>>>>>>>>>>>> >>>>>>>>>>>>> On 2019-03-28 20:15, Vladimir Kozlov wrote: >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8220623 >>>>>>>>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Update JVMCI to support pre-compiled as shared library Graal. >>>>>>>>>>>>>> Using aoted Graal can offers benefits including: >>>>>>>>>>>>>> ?- fast startup >>>>>>>>>>>>>> ?- compile time similar to native JIt compilers (C2) >>>>>>>>>>>>>> ?- memory usage disjoint from the application Java heap >>>>>>>>>>>>>> ?- no profile pollution of JDK code used by the application >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is JDK13 port of JVMCI changes done in graal-jvmci-8 [1] up to date. >>>>>>>>>>>>>> Changes were collected in Metropolis repo [2] and tested there. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Changes we reviewed by Oracle Labs (authors of JVMCI and Graal) and our compiler group. >>>>>>>>>>>>>> Changes in shared code are guarded by #if INCLUDE_JVMCI and JVMCI flags. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I ran tier1-tier8 (which includes HotSpot and JDK tests) and it was clean. In this set Graal was tested >>>>>>>>>>>>>> only in tier3. >>>>>>>>>>>>>> >>>>>>>>>>>>>> And I ran all hs-tier3-graal .. hs-tier8-graal Graal tests available in our system. Several issue were >>>>>>>>>>>>>> found which were present before these changes. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>> >>>>>>>>>>>>>> [1] https://github.com/graalvm/graal-jvmci-8/commit/49ff2045fb603e35516a3a427d8023c00e1607af >>>>>>>>>>>>>> [2] http://hg.openjdk.java.net/metropolis/dev/ >>>>>>>>>>>>> >>> >> From david.holmes at oracle.com Fri Apr 26 22:52:40 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 27 Apr 2019 08:52:40 +1000 Subject: Metaspace OOM before reaching MaxMetaspaceSize In-Reply-To: References: <21f1c70851f20f0036bd754179ddb81696f6e045.camel@oracle.com> Message-ID: On 27/04/2019 6:08 am, Shengpei Zhang wrote: > Thanks David and Thomas, > > @David > My impression was also that this is not related with Metaspace, but I > got confused by the error msg "java.lang.OutOfMemoryError: Metaspace" > here. Maybe this is a mis-classification? Two different OOM conditions in different threads. But without a stacktrace there's no way to see where the OutOfMemoryError was coming from. The stack guard failure is unrelated to that, but what caused the termination of the process. > If that is the case, I assume some part of native memory is OOMed? It > should be an area with a tight limit as there are still free memory on > the machine. Do you know which part of memory the stack_guard_pages are > using? The stack guard pages are within the stack created for the new thread. I would have to assume there is something preventing contiguous memory mapping from succeeding. The map part of the hs_err log may shed some light on that. It's not a detail I'm that familiar with. David ----- > @Thomas > Not sure how to check number of memory mappings, from the example you > provided seemed like you were counting the mappings under the "dynamic > libraries" section? Then no, I checked it was ~6K. > I was not able to reproduce the issue, below is a NMT diff I took just > now, I didn't see anything suspicious here: > > Total: reserved=228671672KB +24437546KB, committed=228134376KB +24813862KB > > -? ? ? ? ? ? ? ? ?Java Heap (reserved=188743680KB, committed=188743680KB) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (mmap: reserved=188743680KB, > committed=188743680KB) > > -? ? ? ? ? ? ? ? ? ? ?Class (reserved=851747KB +655100KB, > committed=830967KB +635128KB) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (classes #51634 +19878) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (malloc=142319KB +134088KB #3339917 +3183393) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (mmap: reserved=709428KB +521012KB, > committed=688648KB +501040KB) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (? Metadata:? ?) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (? ? reserved=0KB, committed=0KB) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (? ? used=0KB) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (? ? free=0KB) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (? ? waste=0KB =-nan%) > > -? ? ? ? ? ? ? ? ? ? Thread (reserved=7543768KB +5003196KB, > committed=7543768KB +5003196KB) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (thread #3725 +2435) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (stack: reserved=7533768KB +4996620KB, > committed=7533768KB +4996620KB) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (malloc=5603KB +3691KB #18712 +12175) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (arena=4397KB +2885 #7434 +4870) > > -? ? ? ? ? ? ? ? ? ? ? Code (reserved=1084696KB +18645KB, > committed=568180KB +414933KB) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (malloc=27920KB +18645KB #75586 +41577) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (mmap: reserved=1056776KB, > committed=540260KB +396288KB) > > -? ? ? ? ? ? ? ? ? ? ? ? GC (reserved=22058971KB +12626721KB, > committed=22058971KB +12626721KB) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (malloc=12911575KB +12626721KB #3259193 > +3182155) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (mmap: reserved=9147396KB, committed=9147396KB) > > -? ? ? ? ? ? ? ? ? Compiler (reserved=30365KB +26208KB, > committed=30365KB +26208KB) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (malloc=30235KB +26208KB #20637 +15823) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (arena=131KB #18) > > -? ? ? ? ? ? ? ? ? Internal (reserved=8157510KB +5937989KB, > committed=8157510KB +5937989KB) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (malloc=8157478KB +5937989KB #2966920 +2914279) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (mmap: reserved=32KB, committed=32KB) > > -? ? ? ? ? ? ? ? ? ? Symbol (reserved=30174KB +9428KB, committed=30174KB > +9428KB) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (malloc=26745KB +9332KB #252220 +78699) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (arena=3428KB +96 #1) > > -? ? Native Memory Tracking (reserved=158258KB +149406KB, > committed=158258KB +149406KB) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (malloc=1839KB +1179KB #25013 +15914) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (tracking overhead=156419KB +148226KB) > > -? ? ? ? ? ? ? ?Arena Chunk (reserved=1388KB +1130KB, committed=1388KB > +1130KB) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (malloc=1388KB +1130KB) > > -? ? ? ? ? ? ? ? ? ?Logging (reserved=8KB, committed=8KB) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (malloc=8KB #164) > > -? ? ? ? ? ? ? ? ?Arguments (reserved=27KB, committed=27KB) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (malloc=27KB #515) > > -? ? ? ? ? ? ? ? ? ? Module (reserved=11073KB +9722KB, committed=11073KB > +9722KB) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (malloc=11073KB +9722KB #44352 +37576) > > -? ? ? ? ? ? ? ? ? ?Unknown (reserved=8KB, committed=8KB) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (mmap: reserved=8KB, committed=8KB) > > > Best, > Shengpei > > On Thu, Apr 25, 2019 at 11:45 PM Thomas Schatzl > > wrote: > > Hi, > > ? some random comments: > > On Thu, 2019-04-25 at 17:19 -0700, Shengpei Zhang wrote: > > Hi, > > > > We recently saw a weird Metaspace OOM. The hs_err_pid log showed the > > metaspace usage was 325078K, while the MaxMetaspaceSize was set to > > 4G. > > > > The machine was running JAVA10. > > > > Few observations: > > > > 1. It only happened at one machine, and we were not able to reproduce > > it. > > > > 2. Error log indicated memory allocation failure in native memory. > > > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > > Chunkmanager (non-class): > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > >? 62578 specialized (128 bytes) chunks, total 64079872 bytes > > [2019-03-29T11:18:01.298-0700][126538][info > > ][gc,metaspace,freelist]? ?5778 > > small (512 bytes) chunks, total 23666688 bytes > > [2019-03-29T11:18:01.298-0700][126538][info > > ][gc,metaspace,freelist]? ?27 > > medium (8192 bytes) chunks, total 1769472 bytes > > [2019-03-29T11:18:01.298-0700][126538][info > > ][gc,metaspace,freelist]? ?13 > > humongous chunks, total 8890368 bytes > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > >? total size: 98406400 bytes. > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > > Chunkmanager (class): > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > > unavailable. > > java.lang.OutOfMemoryError: Metaspace > > Dumping heap to java_pid240.hprof ... > >? ? ? ? ? ?vmop? ? ? ? ? ? ? ? ? ? ? ? ? ? [ threads:? ? total > > initially_running wait_to_block ][ time:? ? spin? ?block? ? sync > > cleanup > > vmop ] page_trap_count > > 66467.977: ICBufferFull? ? ? ? ? ? ? ? ? ? [? ? ? ? ? ? ? 3427 > >? 154? ? ? ? ? ?353 ][? ? ? ? ? ? ?0? ? ? 60? ? ? 63? ? ? ?8? ? ? ?0 ] > >? ? ? ? ?58 > > [2019-03-29T11:18:01.308-0700][459? ?][info ][safepoint? ? ? ? ? ? ] > > Total > > time for which application threads were stopped: 0.0725507 seconds, > > Stopping threads took: 0.0630158 seconds > > [thread 384508 also had an error] > > # > > # There is insufficient memory for the Java Runtime Environment to > > continue. > > # Native memory allocation (mmap) failed to map 16384 bytes for > > committing > > reserved memory. > > # An error report file with more information is saved as: > > # /data/hs_err_pid240.log > > In Linux there is a limit on the amount of memory mappings (iirc 65k by > default) if your application maps memory by itself, and does not unmap > in time, you will run out of memory mappings. > > If the hs_err log contains lots and lots of memory mappings, this is a > strong indication that this is your issue, not actual native memory > pressure. > > See e.g. https://bugs.openjdk.java.net/browse/JDK-8216619 for more > details on another example. > > > > > 3. The hs_err_pid log showed the metaspace memory usage was 325078K, > > it is far less than the reserved size 568176K. Also, the > > MaxMetaspaceSize was set to 4G. I checked the machine had plenty of > > free native memory at that time. If there was a huge allocation, I > > assume JVM would try to reserve more memory first? > > Please check if your program leaks memory reservations or not, see > above. > > The difference between usage and reservation size may be down to > fragmentation: later VM versions included some patches that improve the > situation. > > Thanks, > ? Thomas > > From thomas.stuefe at gmail.com Sat Apr 27 06:17:21 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 27 Apr 2019 08:17:21 +0200 Subject: Metaspace OOM before reaching MaxMetaspaceSize In-Reply-To: References: <21f1c70851f20f0036bd754179ddb81696f6e045.camel@oracle.com> Message-ID: Hi Shengpei, (different Thomas :) I agree with David and Thomas 1, you probably hit a limit which prevents your mmap calls from succeeding. Both cases - failing to establish the guard page on the thread and failing to enlarge the Metaspace - can be caused by failing mmap calls. So the "out of metaspace" message is not wrong, it just is not the whole answer. My guess would be it is either the number-of-mappings Thomas mentioned, or a ulimit you hit, maby the virtual size ulimit. The former you is a sysctl setting: sysctl vm.max_map_count - as Thomas said, it is usually 64K. And yes, the number of "native libraries" in the hs-err file is really the list of memory mappings, aka the plain /proc//maps. The ulimit you may be hitting could be the virtual size one, ulimit -d. ulimit -a gives you all limits. Limits are also printed as part of the hs-err file (look for rlimit). Still, it would also be helpfiul to have the output of VM.metaspace (via jcmd) to see in detail metaspace usage. Thanks, Thomas On Fri, Apr 26, 2019 at 10:09 PM Shengpei Zhang wrote: > Thanks David and Thomas, > > @David > My impression was also that this is not related with Metaspace, but I got > confused by the error msg "java.lang.OutOfMemoryError: Metaspace" here. > Maybe this is a mis-classification? > If that is the case, I assume some part of native memory is OOMed? It > should be an area with a tight limit as there are still free memory on the > machine. Do you know which part of memory the stack_guard_pages are using? > > @Thomas > Not sure how to check number of memory mappings, from the example you > provided seemed like you were counting the mappings under the "dynamic > libraries" section? Then no, I checked it was ~6K. > I was not able to reproduce the issue, below is a NMT diff I took just now, > I didn't see anything suspicious here: > > Total: reserved=228671672KB +24437546KB, committed=228134376KB +24813862KB > > - Java Heap (reserved=188743680KB, committed=188743680KB) > (mmap: reserved=188743680KB, > committed=188743680KB) > > - Class (reserved=851747KB +655100KB, > committed=830967KB +635128KB) > (classes #51634 +19878) > (malloc=142319KB +134088KB #3339917 +3183393) > (mmap: reserved=709428KB +521012KB, > committed=688648KB +501040KB) > ( Metadata: ) > ( reserved=0KB, committed=0KB) > ( used=0KB) > ( free=0KB) > ( waste=0KB =-nan%) > > - Thread (reserved=7543768KB +5003196KB, > committed=7543768KB +5003196KB) > (thread #3725 +2435) > (stack: reserved=7533768KB +4996620KB, > committed=7533768KB +4996620KB) > (malloc=5603KB +3691KB #18712 +12175) > (arena=4397KB +2885 #7434 +4870) > > - Code (reserved=1084696KB +18645KB, > committed=568180KB +414933KB) > (malloc=27920KB +18645KB #75586 +41577) > (mmap: reserved=1056776KB, committed=540260KB > +396288KB) > > - GC (reserved=22058971KB +12626721KB, > committed=22058971KB +12626721KB) > (malloc=12911575KB +12626721KB #3259193 > +3182155) > (mmap: reserved=9147396KB, committed=9147396KB) > > - Compiler (reserved=30365KB +26208KB, committed=30365KB > +26208KB) > (malloc=30235KB +26208KB #20637 +15823) > (arena=131KB #18) > > - Internal (reserved=8157510KB +5937989KB, > committed=8157510KB +5937989KB) > (malloc=8157478KB +5937989KB #2966920 +2914279) > (mmap: reserved=32KB, committed=32KB) > > - Symbol (reserved=30174KB +9428KB, committed=30174KB > +9428KB) > (malloc=26745KB +9332KB #252220 +78699) > (arena=3428KB +96 #1) > > - Native Memory Tracking (reserved=158258KB +149406KB, > committed=158258KB +149406KB) > (malloc=1839KB +1179KB #25013 +15914) > (tracking overhead=156419KB +148226KB) > > - Arena Chunk (reserved=1388KB +1130KB, committed=1388KB > +1130KB) > (malloc=1388KB +1130KB) > > - Logging (reserved=8KB, committed=8KB) > (malloc=8KB #164) > > - Arguments (reserved=27KB, committed=27KB) > (malloc=27KB #515) > > - Module (reserved=11073KB +9722KB, committed=11073KB > +9722KB) > (malloc=11073KB +9722KB #44352 +37576) > > - Unknown (reserved=8KB, committed=8KB) > (mmap: reserved=8KB, committed=8KB) > > > Best, > Shengpei > > On Thu, Apr 25, 2019 at 11:45 PM Thomas Schatzl > > wrote: > > > Hi, > > > > some random comments: > > > > On Thu, 2019-04-25 at 17:19 -0700, Shengpei Zhang wrote: > > > Hi, > > > > > > We recently saw a weird Metaspace OOM. The hs_err_pid log showed the > > > metaspace usage was 325078K, while the MaxMetaspaceSize was set to > > > 4G. > > > > > > The machine was running JAVA10. > > > > > > Few observations: > > > > > > 1. It only happened at one machine, and we were not able to reproduce > > > it. > > > > > > 2. Error log indicated memory allocation failure in native memory. > > > > > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > > > Chunkmanager (non-class): > > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > > > 62578 specialized (128 bytes) chunks, total 64079872 bytes > > > [2019-03-29T11:18:01.298-0700][126538][info > > > ][gc,metaspace,freelist] 5778 > > > small (512 bytes) chunks, total 23666688 bytes > > > [2019-03-29T11:18:01.298-0700][126538][info > > > ][gc,metaspace,freelist] 27 > > > medium (8192 bytes) chunks, total 1769472 bytes > > > [2019-03-29T11:18:01.298-0700][126538][info > > > ][gc,metaspace,freelist] 13 > > > humongous chunks, total 8890368 bytes > > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > > > total size: 98406400 bytes. > > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > > > Chunkmanager (class): > > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] > > > unavailable. > > > java.lang.OutOfMemoryError: Metaspace > > > Dumping heap to java_pid240.hprof ... > > > vmop [ threads: total > > > initially_running wait_to_block ][ time: spin block sync > > > cleanup > > > vmop ] page_trap_count > > > 66467.977: ICBufferFull [ 3427 > > > 154 353 ][ 0 60 63 8 0 ] > > > 58 > > > [2019-03-29T11:18:01.308-0700][459 ][info ][safepoint ] > > > Total > > > time for which application threads were stopped: 0.0725507 seconds, > > > Stopping threads took: 0.0630158 seconds > > > [thread 384508 also had an error] > > > # > > > # There is insufficient memory for the Java Runtime Environment to > > > continue. > > > # Native memory allocation (mmap) failed to map 16384 bytes for > > > committing > > > reserved memory. > > > # An error report file with more information is saved as: > > > # /data/hs_err_pid240.log > > > > In Linux there is a limit on the amount of memory mappings (iirc 65k by > > default) if your application maps memory by itself, and does not unmap > > in time, you will run out of memory mappings. > > > > If the hs_err log contains lots and lots of memory mappings, this is a > > strong indication that this is your issue, not actual native memory > > pressure. > > > > See e.g. https://bugs.openjdk.java.net/browse/JDK-8216619 for more > > details on another example. > > > > > > > > 3. The hs_err_pid log showed the metaspace memory usage was 325078K, > > > it is far less than the reserved size 568176K. Also, the > > > MaxMetaspaceSize was set to 4G. I checked the machine had plenty of > > > free native memory at that time. If there was a huge allocation, I > > > assume JVM would try to reserve more memory first? > > > > Please check if your program leaks memory reservations or not, see > > above. > > > > The difference between usage and reservation size may be down to > > fragmentation: later VM versions included some patches that improve the > > situation. > > > > Thanks, > > Thomas > > > > > > > From per.liden at oracle.com Sat Apr 27 20:49:29 2019 From: per.liden at oracle.com (Per Liden) Date: Sat, 27 Apr 2019 22:49:29 +0200 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> References: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> Message-ID: <628159dd-757e-900a-aafa-40bd7d3a3657@oracle.com> Hi Coleen, Not a review, just a comment on your comment: + // There are a couple of existing locks that will sometimes have a safepoint check and + // sometimes not when acquired by a JavaThread, but these locks are set up carefully + // to avoid deadlocks. TODO: Fix these locks and remove _safepoint_check_sometimes. Once _safepoint_check_sometimes is gone, we can simplify things even further and remove the {lock,wait}_without_safepoint_check() functions, and ditch the Mutex::SafepointCheckFlag argument in the constructors for MutexLocker and MonitorLocker. Everyone can just call lock()/wait(), and the lock itself knows what to do. That would be great! cheers, Per On 04/26/2019 06:10 PM, 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 > > This patch moves all but 3 of the locks to not be > safepoint_check_sometimes. We have plans to fix these three. Also, > 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. > > 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 > > Thanks, > Coleen From david.holmes at oracle.com Mon Apr 29 00:42:48 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 29 Apr 2019 10:42:48 +1000 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> References: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> Message-ID: 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. > 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? > 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(). > 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? --- 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. 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. 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. ? --- 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. 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. 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. --- Thanks, David > Thanks, > Coleen From david.holmes at oracle.com Mon Apr 29 01:48:37 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 29 Apr 2019 11:48:37 +1000 Subject: RFC: JWarmup precompile java hot methods at application startup In-Reply-To: References: <0f11a565-930f-4456-b2fa-3cb9bc476c16.kuaiwei.kw@alibaba-inc.com> Message-ID: <84654b41-d785-13e7-27cf-4cdc0a868982@oracle.com> On 27/04/2019 3:41 am, yumin qi wrote: > David, Wei > ? Thanks for your comment. > ? Java RTS has an option -XX:PreInitList=my-preinit-file which stores > the pre-init class list. Will the classes in that list be initialized in > order? Yes they would. That was its purpose. > ?JWarmUp recorded the class init order in pre-run to prevent runtime > unnecessary?deoptimization due to class initialization out of order. The I don't understand that sentence sorry. > current design is wait for vm finished startup to startup warm up. We > have tried compile when class loading and found many problems so decided > go with current design. I'm trying to understand the details of the current design and I'm afraid I'm not getting it at all. I would have expected the "pre-run" to generate a list of methods to compile, sorted by initialization order. So yes some tweaking to the runtime to track the initialization order. I would then expect the actual run to take that file and at some point during startup run through that list and load and initialize each class, then compile each method. David ----- > ?You said it is like selective -Xcomp, yes, it looks like in first, but > next we will enhance?with method profiling information to make more > optimized code. > > ?The changes have been made to many runtime files, so need comments > from runtime either. > > Thanks > Yumin > > On Fri, Apr 26, 2019 at 5:53 AM Kuai Wei > wrote: > > Hi David, > > ? I try to add more info about JWarmup. Yumin may explain more > detail later. > > ? In record phase, JWarmup will record hot methods and the class > initialize order. We believe class order is important. Without it, > most warmup compilation will be failed by deopt. > > ? In warmup phase, JVM will check init order before warmup > compilation. If the recorded dependent classes are initialized, (the > classes may not be really dependent, we just check the init order), > the methods will be warmup compiled. So we delay warmup compilation > after JVM startup, we need wait JVM to load most classes. > > Thanks, > Kuai Wei > > ------------------------------------------------------------------ > From:David Holmes > > Send Time:2019?4?26?(???) 14:54 > To:yumin qi >; > hotspot-runtim. > > Cc:hotspot-dev > > Subject:Re: RFC: JWarmup precompile java hot methods at > application startup > > Hi?Yumin, > > On?26/04/2019?2:07?am,?yumin?qi?wrote: > >?Hi, > > > >????Apart?from?comments?from?compiler?professionals?can?I?have?comments?from > >?runtime?either??The?changes?mostly?land?in?runtime?area. > > I?have?to?question?why?the?changes?mostly?land?in?runtime?area!?The > high-level?description?of?this?feature?does?not?sound?like?it?depends?on > > the?runtime?at?all.?The?"recording"?feature?should?just?come?from?the > > JITs?data;?and?the?actual?warmup?should?just?be?an?interaction?during?VM > > initialization?with?the?JIT.?I?don't?see?anything?in?the?JEP?to?explain > > the?actual?design,?and?why?it?impacts?on?the?runtime?so?much. > > It?also?sounds?like?a?selective?Xcomp?mode?to?me. > > It?even?sounds?very?similar?to?Initialization-Time-Compilation?(ITC) > > that?we?employed?in?Java?Real-Time?System: > > https://docs.oracle.com/javase/realtime/doc_2.2u1/release/JavaRTSCompilation.html > > Cheers, > David > > >?Thanks > >?Yumin > > > >?On?Tue,?Apr?16,?2019?at?11:27?AM?yumin?qi? >?wrote: > > > >>?HI, > >> > >>????Did?anyone?have?comments?for?this?version? > >> > >>?Thanks > >>?Yumin > >> > >>?On?Tue,?Apr?9,?2019?at?10:36?AM?yumin?qi? >?wrote: > >> > >>>?Alan, > >>>????Thanks!?Updated?in?same?link: > >>> http://cr.openjdk.java.net/~minqi/8220692/webrev-02/ > >>> > >>>????Removed?non-boot?loader?branch?in?nativeLookup.cpp. > >>>????Added?jdk.jwarmup?to?boot?loader?list?in?make/common/Modules.gmk. > >>>????Tested?again?to?make?sure?the?new?changes. > >>> > >>>????Thanks > >>>????Yumin > >>> > >>> > >>>?On?Tue,?Apr?9,?2019?at?4:48?AM?Alan?Bateman?> > >>>?wrote: > >>> > >>>>?On?09/04/2019?07:10,?yumin?qi?wrote: > >>>>> > >>>>>????Now?the?registerNatives?is?found?when?it?looks?up?for?native?entry > >>>>>?in?lookupNative.cpp.?I?thought?the?class?JWarmUp?will?be?loaded?by > >>>>>?boot?loader?like?Unsafe?or?WhiteBox,?but?I?was?wrong,?it?is?loaded?by > >>>>>?app?class?loader?so?logic?for?obtaining?its?native?entry?put?in?both > >>>>>?cases,?boot?loader?and?non?boot?loaders. > >>>>> > >>>>?make/common/Modules.gmk?is?where?BOOT_MODULES?is?defined?with?the?list > >>>>?of?modules?mapped?to?the?boot?loader. > >>>> > >>>>?-Alan > >>>> > >>> > From matthias.baesken at sap.com Mon Apr 29 11:02:10 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 29 Apr 2019 11:02:10 +0000 Subject: 8222720: Provide extended VMWare/vSphere virtualization related info in the hs_error file on linux/windows x86_64 Message-ID: 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 Mon Apr 29 11:44:59 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 29 Apr 2019 04:44:59 -0700 (PDT) Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: <628159dd-757e-900a-aafa-40bd7d3a3657@oracle.com> References: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> <628159dd-757e-900a-aafa-40bd7d3a3657@oracle.com> Message-ID: On 4/27/19 4:49 PM, Per Liden wrote: > Hi Coleen, > > Not a review, just a comment on your comment: > > +? // There are a couple of existing locks that will sometimes have a > safepoint check and > +? // sometimes not when acquired by a JavaThread, but these locks are > set up carefully > +? // to avoid deadlocks. TODO: Fix these locks and remove > _safepoint_check_sometimes. > > Once _safepoint_check_sometimes is gone, we can simplify things even > further and remove the {lock,wait}_without_safepoint_check() > functions, and ditch the Mutex::SafepointCheckFlag argument in the > constructors for MutexLocker and MonitorLocker. Everyone can just call > lock()/wait(), and the lock itself knows what to do. That would be great! Yes, I happen to agree with you. Thanks! Coleen > > cheers, > Per > > On 04/26/2019 06:10 PM, 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 >> >> This patch moves all but 3 of the locks to not be >> safepoint_check_sometimes.? We have plans to fix these three. Also, >> 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. >> >> 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 >> >> Thanks, >> Coleen From coleen.phillimore at oracle.com Mon Apr 29 12:11:41 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 29 Apr 2019 08:11:41 -0400 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: References: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> Message-ID: 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. > > ?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. Thanks, Coleen > --- > > Thanks, > David > > >> Thanks, >> Coleen From yumin.qi at gmail.com Mon Apr 29 16:35:15 2019 From: yumin.qi at gmail.com (yumin qi) Date: Mon, 29 Apr 2019 09:35:15 -0700 Subject: RFC: JWarmup precompile java hot methods at application startup In-Reply-To: <84654b41-d785-13e7-27cf-4cdc0a868982@oracle.com> References: <0f11a565-930f-4456-b2fa-3cb9bc476c16.kuaiwei.kw@alibaba-inc.com> <84654b41-d785-13e7-27cf-4cdc0a868982@oracle.com> Message-ID: HI, David Thanks for comments. On Sun, Apr 28, 2019 at 6:50 PM David Holmes wrote: > > > JWarmUp recorded the class init order in pre-run to prevent runtime > > unnecessary deoptimization due to class initialization out of order. The > > I don't understand that sentence sorry. > > Sorry, that is my mistake, it should be 'compilation failure'. > > current design is wait for vm finished startup to startup warm up. We > > have tried compile when class loading and found many problems so decided > > go with current design. > > I'm trying to understand the details of the current design and I'm > afraid I'm not getting it at all. I would have expected the "pre-run" to > generate a list of methods to compile, sorted by initialization order. > So yes some tweaking to the runtime to track the initialization order. > > I would then expect the actual run to take that file and at some point > during startup run through that list and load and initialize each class, > then compile each method. > > The methods remembered in order of time already in the file. In regular compilation, all the classes in the compilation already resolved or can be resolved. Since JWarmUp pre-compile those methods (in order as they are in pre-run) at some point which is early than they were in pre-run, some classes have not been loaded yet. We could not assume the class is loaded by which class loader especially for custom class loaders, the compilation has to fail. We supply an API for application to inform VM the time to start warmup compilation. At that point, most classes have been loaded already since application started, so most of the methods can be compiled successfully though we may have a very small number of failures. Application developers know the time point when to use this API to start warmup compilation. Would this answer your question? Thanks Yumin > David > ----- > > > You said it is like selective -Xcomp, yes, it looks like in first, but > > next we will enhance with method profiling information to make more > > optimized code. > > > > The changes have been made to many runtime files, so need comments > > from runtime either. > > > > Thanks > > Yumin > > > > On Fri, Apr 26, 2019 at 5:53 AM Kuai Wei > > wrote: > > > > Hi David, > > > > I try to add more info about JWarmup. Yumin may explain more > > detail later. > > > > In record phase, JWarmup will record hot methods and the class > > initialize order. We believe class order is important. Without it, > > most warmup compilation will be failed by deopt. > > > > In warmup phase, JVM will check init order before warmup > > compilation. If the recorded dependent classes are initialized, (the > > classes may not be really dependent, we just check the init order), > > the methods will be warmup compiled. So we delay warmup compilation > > after JVM startup, we need wait JVM to load most classes. > > > > Thanks, > > Kuai Wei > > > > > ------------------------------------------------------------------ > > From:David Holmes > > > > Send Time:2019?4?26?(???) 14:54 > > To:yumin qi >; > > hotspot-runtim. > > > > Cc:hotspot-dev > > > > Subject:Re: RFC: JWarmup precompile java hot methods at > > application startup > > > > Hi Yumin, > > > > On 26/04/2019 2:07 am, yumin qi wrote: > > > Hi, > > > > > > > Apart from comments from compiler professionals can I have comments from > > > runtime either? The changes mostly land in runtime area. > > > > > I have to question why the changes mostly land in runtime area! The > > > high-level description of this feature does not sound like it depends on > > > > > the runtime at all. The "recording" feature should just come from the > > > > > JITs data; and the actual warmup should just be an interaction during VM > > > > > initialization with the JIT. I don't see anything in the JEP to explain > > > > the actual design, and why it impacts on the runtime so much. > > > > It also sounds like a selective Xcomp mode to me. > > > > > It even sounds very similar to Initialization-Time-Compilation (ITC) > > > > that we employed in Java Real-Time System: > > > > > https://docs.oracle.com/javase/realtime/doc_2.2u1/release/JavaRTSCompilation.html > > > > Cheers, > > David > > > > > Thanks > > > Yumin > > > > > > On Tue, Apr 16, 2019 at 11:27 AM yumin qi > > wrote: > > > > > >> HI, > > >> > > >> Did anyone have comments for this version? > > >> > > >> Thanks > > >> Yumin > > >> > > >> On Tue, Apr 9, 2019 at 10:36 AM yumin qi > > wrote: > > >> > > >>> Alan, > > >>> Thanks! Updated in same link: > > >>> http://cr.openjdk.java.net/~minqi/8220692/webrev-02/ > > >>> > > >>> Removed non-boot loader branch in nativeLookup.cpp. > > > >>> Added jdk.jwarmup to boot loader list in make/common/Modules.gmk. > > >>> Tested again to make sure the new changes. > > >>> > > >>> Thanks > > >>> Yumin > > >>> > > >>> > > >>> On Tue, Apr 9, 2019 at 4:48 AM Alan Bateman < > Alan.Bateman at oracle.com > > > >>> wrote: > > >>> > > >>>> On 09/04/2019 07:10, yumin qi wrote: > > >>>>> > > > >>>>> Now the registerNatives is found when it looks up for native entry > > > >>>>> in lookupNative.cpp. I thought the class JWarmUp will be loaded by > > > >>>>> boot loader like Unsafe or WhiteBox, but I was wrong, it is loaded by > > > >>>>> app class loader so logic for obtaining its native entry put in both > > >>>>> cases, boot loader and non boot loaders. > > >>>>> > > > >>>> make/common/Modules.gmk is where BOOT_MODULES is defined with the list > > >>>> of modules mapped to the boot loader. > > >>>> > > >>>> -Alan > > >>>> > > >>> > > > From shengpei92 at gmail.com Mon Apr 29 18:05:59 2019 From: shengpei92 at gmail.com (Shengpei Zhang) Date: Mon, 29 Apr 2019 11:05:59 -0700 Subject: Metaspace OOM before reaching MaxMetaspaceSize In-Reply-To: References: <21f1c70851f20f0036bd754179ddb81696f6e045.camel@oracle.com> Message-ID: Thanks David and Thomas :) I checked our mmap limit, it is 64M. The # of mmap in the hs file is around 6K. I also did checked the current running process, it is about 8K. So I do not think it hit the mmap limit. @Thomas Below is the rlimit output in the hs_err log, I am not sure how to interrupt it... --------------- S Y S T E M --------------- OS:CentOS Linux release 7.5.1804 (Core) uname:Linux 4.11.3-88_fbk23_4223_g7d3b7f39d8b1 #88 SMP Thu Jan 31 13:08:24 PST 2019 x86_64 libc:glibc 2.17 NPTL 2.17 rlimit: STACK 8192k, CORE infinity, NPROC 1030660, NOFILE 262144, AS infinity, DATA infinity, FSIZE infinity load average:99.10 107.68 103.71 One interesting article I saw is https://bugs.openjdk.java.net/browse/JDK-8187709. Someone mentioned for (-XX:-UseCompressedOops) enabled machines, the native memory might be allocated at lower memory space, so the actual available memory is less than free memory. Could this be the cause? I hope I could provide more logs :( But I only saw this issue once. The only thing I had is a hs_err file and stdout log. Best, Shengpei On Fri, Apr 26, 2019 at 11:17 PM Thomas St?fe wrote: > Hi Shengpei, > > (different Thomas :) > > I agree with David and Thomas 1, you probably hit a limit which prevents > your mmap calls from succeeding. Both cases - failing to establish the > guard page on the thread and failing to enlarge the Metaspace - can be > caused by failing mmap calls. So the "out of metaspace" message is not > wrong, it just is not the whole answer. > > My guess would be it is either the number-of-mappings Thomas mentioned, or > a ulimit you hit, maby the virtual size ulimit. > > The former you is a sysctl setting: sysctl vm.max_map_count - as Thomas > said, it is usually 64K. And yes, the number of "native libraries" in the > hs-err file is really the list of memory mappings, aka the plain > /proc//maps. > > The ulimit you may be hitting could be the virtual size one, ulimit -d. > ulimit -a gives you all limits. Limits are also printed as part of the > hs-err file (look for rlimit). > > Still, it would also be helpfiul to have the output of VM.metaspace (via > jcmd) to see in detail metaspace usage. > > Thanks, Thomas > > > On Fri, Apr 26, 2019 at 10:09 PM Shengpei Zhang > wrote: > >> Thanks David and Thomas, >> >> @David >> My impression was also that this is not related with Metaspace, but I got >> confused by the error msg "java.lang.OutOfMemoryError: Metaspace" here. >> Maybe this is a mis-classification? >> If that is the case, I assume some part of native memory is OOMed? It >> should be an area with a tight limit as there are still free memory on the >> machine. Do you know which part of memory the stack_guard_pages are using? >> >> @Thomas >> Not sure how to check number of memory mappings, from the example you >> provided seemed like you were counting the mappings under the "dynamic >> libraries" section? Then no, I checked it was ~6K. >> I was not able to reproduce the issue, below is a NMT diff I took just >> now, >> I didn't see anything suspicious here: >> >> Total: reserved=228671672KB +24437546KB, committed=228134376KB +24813862KB >> >> - Java Heap (reserved=188743680KB, committed=188743680KB) >> (mmap: reserved=188743680KB, >> committed=188743680KB) >> >> - Class (reserved=851747KB +655100KB, >> committed=830967KB +635128KB) >> (classes #51634 +19878) >> (malloc=142319KB +134088KB #3339917 +3183393) >> (mmap: reserved=709428KB +521012KB, >> committed=688648KB +501040KB) >> ( Metadata: ) >> ( reserved=0KB, committed=0KB) >> ( used=0KB) >> ( free=0KB) >> ( waste=0KB =-nan%) >> >> - Thread (reserved=7543768KB +5003196KB, >> committed=7543768KB +5003196KB) >> (thread #3725 +2435) >> (stack: reserved=7533768KB +4996620KB, >> committed=7533768KB +4996620KB) >> (malloc=5603KB +3691KB #18712 +12175) >> (arena=4397KB +2885 #7434 +4870) >> >> - Code (reserved=1084696KB +18645KB, >> committed=568180KB +414933KB) >> (malloc=27920KB +18645KB #75586 +41577) >> (mmap: reserved=1056776KB, committed=540260KB >> +396288KB) >> >> - GC (reserved=22058971KB +12626721KB, >> committed=22058971KB +12626721KB) >> (malloc=12911575KB +12626721KB #3259193 >> +3182155) >> (mmap: reserved=9147396KB, >> committed=9147396KB) >> >> - Compiler (reserved=30365KB +26208KB, committed=30365KB >> +26208KB) >> (malloc=30235KB +26208KB #20637 +15823) >> (arena=131KB #18) >> >> - Internal (reserved=8157510KB +5937989KB, >> committed=8157510KB +5937989KB) >> (malloc=8157478KB +5937989KB #2966920 >> +2914279) >> (mmap: reserved=32KB, committed=32KB) >> >> - Symbol (reserved=30174KB +9428KB, committed=30174KB >> +9428KB) >> (malloc=26745KB +9332KB #252220 +78699) >> (arena=3428KB +96 #1) >> >> - Native Memory Tracking (reserved=158258KB +149406KB, >> committed=158258KB +149406KB) >> (malloc=1839KB +1179KB #25013 +15914) >> (tracking overhead=156419KB +148226KB) >> >> - Arena Chunk (reserved=1388KB +1130KB, committed=1388KB >> +1130KB) >> (malloc=1388KB +1130KB) >> >> - Logging (reserved=8KB, committed=8KB) >> (malloc=8KB #164) >> >> - Arguments (reserved=27KB, committed=27KB) >> (malloc=27KB #515) >> >> - Module (reserved=11073KB +9722KB, committed=11073KB >> +9722KB) >> (malloc=11073KB +9722KB #44352 +37576) >> >> - Unknown (reserved=8KB, committed=8KB) >> (mmap: reserved=8KB, committed=8KB) >> >> >> Best, >> Shengpei >> >> On Thu, Apr 25, 2019 at 11:45 PM Thomas Schatzl < >> thomas.schatzl at oracle.com> >> wrote: >> >> > Hi, >> > >> > some random comments: >> > >> > On Thu, 2019-04-25 at 17:19 -0700, Shengpei Zhang wrote: >> > > Hi, >> > > >> > > We recently saw a weird Metaspace OOM. The hs_err_pid log showed the >> > > metaspace usage was 325078K, while the MaxMetaspaceSize was set to >> > > 4G. >> > > >> > > The machine was running JAVA10. >> > > >> > > Few observations: >> > > >> > > 1. It only happened at one machine, and we were not able to reproduce >> > > it. >> > > >> > > 2. Error log indicated memory allocation failure in native memory. >> > > >> > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] >> > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] >> > > Chunkmanager (non-class): >> > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] >> > > 62578 specialized (128 bytes) chunks, total 64079872 bytes >> > > [2019-03-29T11:18:01.298-0700][126538][info >> > > ][gc,metaspace,freelist] 5778 >> > > small (512 bytes) chunks, total 23666688 bytes >> > > [2019-03-29T11:18:01.298-0700][126538][info >> > > ][gc,metaspace,freelist] 27 >> > > medium (8192 bytes) chunks, total 1769472 bytes >> > > [2019-03-29T11:18:01.298-0700][126538][info >> > > ][gc,metaspace,freelist] 13 >> > > humongous chunks, total 8890368 bytes >> > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] >> > > total size: 98406400 bytes. >> > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] >> > > Chunkmanager (class): >> > > [2019-03-29T11:18:01.298-0700][126538][info ][gc,metaspace,freelist] >> > > unavailable. >> > > java.lang.OutOfMemoryError: Metaspace >> > > Dumping heap to java_pid240.hprof ... >> > > vmop [ threads: total >> > > initially_running wait_to_block ][ time: spin block sync >> > > cleanup >> > > vmop ] page_trap_count >> > > 66467.977: ICBufferFull [ 3427 >> > > 154 353 ][ 0 60 63 8 0 ] >> > > 58 >> > > [2019-03-29T11:18:01.308-0700][459 ][info ][safepoint ] >> > > Total >> > > time for which application threads were stopped: 0.0725507 seconds, >> > > Stopping threads took: 0.0630158 seconds >> > > [thread 384508 also had an error] >> > > # >> > > # There is insufficient memory for the Java Runtime Environment to >> > > continue. >> > > # Native memory allocation (mmap) failed to map 16384 bytes for >> > > committing >> > > reserved memory. >> > > # An error report file with more information is saved as: >> > > # /data/hs_err_pid240.log >> > >> > In Linux there is a limit on the amount of memory mappings (iirc 65k by >> > default) if your application maps memory by itself, and does not unmap >> > in time, you will run out of memory mappings. >> > >> > If the hs_err log contains lots and lots of memory mappings, this is a >> > strong indication that this is your issue, not actual native memory >> > pressure. >> > >> > See e.g. https://bugs.openjdk.java.net/browse/JDK-8216619 for more >> > details on another example. >> > >> > > >> > > 3. The hs_err_pid log showed the metaspace memory usage was 325078K, >> > > it is far less than the reserved size 568176K. Also, the >> > > MaxMetaspaceSize was set to 4G. I checked the machine had plenty of >> > > free native memory at that time. If there was a huge allocation, I >> > > assume JVM would try to reserve more memory first? >> > >> > Please check if your program leaks memory reservations or not, see >> > above. >> > >> > The difference between usage and reservation size may be down to >> > fragmentation: later VM versions included some patches that improve the >> > situation. >> > >> > Thanks, >> > Thomas >> > >> > >> > >> > From gnu.andrew at redhat.com Mon Apr 29 18:20:57 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 29 Apr 2019 19:20:57 +0100 Subject: RFR: 8221639: [x32] expand_exec_shield_cs_limit workaround is undefined code after JDK-8199717 In-Reply-To: <87k1fjh6ja.fsf@oldenburg2.str.redhat.com> References: <673a0cc6b25fcfdcb3f3c69f4dcfd06d346e271a.camel@redhat.com> <87k1fjh6ja.fsf@oldenburg2.str.redhat.com> Message-ID: On 24/04/2019 14:33, Florian Weimer wrote: > * Severin Gehwolf: > >> Hi, >> >> Could I please get reviews for this Linux x32 fix? JDK-8199717 added a >> performance optimization to only capture the initial stack size when >> launched via non-java launchers. However, on Linux x32, > > Do you mean actual x32, or i386? These two are different. > > Can you actually verify changes in this area? I think it's pretty hard > these days to find a machine that actually uses the CS hack to avoid > universal read-implies-exec. I don't think this was ever part of any > mainline kernel. > > Thanks, > Florian > I don't believe OpenJDK has support for x32. At least, we've had a ticket for it for a long time and I've never had the time to look at getting even Zero to build on such a platform: https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1300 -- 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 gnu.andrew at redhat.com Mon Apr 29 18:29:05 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 29 Apr 2019 19:29:05 +0100 Subject: RFR: 8221639: [x32] expand_exec_shield_cs_limit workaround is undefined code after JDK-8199717 In-Reply-To: <9c112d1b-6290-940e-ca65-51e8e128b4b9@oracle.com> References: <673a0cc6b25fcfdcb3f3c69f4dcfd06d346e271a.camel@redhat.com> <6a9f74f3-a1de-fc2a-370b-c64055611fd9@oracle.com> <89ab6a7f-79a7-2556-29cb-5cc9289c8ae6@oracle.com> <9c112d1b-6290-940e-ca65-51e8e128b4b9@oracle.com> Message-ID: <504f92b1-70f8-8421-2865-451069c022cb@redhat.com> On 26/04/2019 13:15, David Holmes wrote: > On 26/04/2019 7:15 pm, Severin Gehwolf wrote: >> Hi David, >> >> Can I consider webrev 02 reviewed by yourself? > > Of course. Thanks for adding the comment. > > David > Looks good to me too. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From daniel.daugherty at oracle.com Mon Apr 29 18:53:21 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 29 Apr 2019 14:53:21 -0400 Subject: RFR (S) 8222988: Use MonitorLocker rather than MutexLocker when wait/notify used In-Reply-To: References: Message-ID: <51e281d0-7544-bc24-196c-ba1da7bf15b9@oracle.com> On 4/26/19 9:10 AM, coleen.phillimore at oracle.com wrote: > Summary: fixed use cases in code except CMS. > > This affects some GC code and runtime code.? It looks like a nice > change to me.? Tested with hs tier1-3. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8222988.01/webrev src/hotspot/share/runtime/mutexLocker.hpp ??? No comments. src/hotspot/share/runtime/mutexLocker.cpp ??? No comments. src/hotspot/share/runtime/thread.cpp ??? No comments. src/hotspot/share/runtime/vmThread.cpp ??? L377: ??? while(!VMThread::is_terminated()) { ??? L378: ??????? ml.wait(); ??????? nit - please decrease indent by 2 spaces (not your fault) ??????? nit - L377 needs a space before '(' (also not your fault ????????????? and you didn't touch this line) src/hotspot/share/compiler/abstractCompiler.cpp src/hotspot/share/compiler/compileBroker.cpp src/hotspot/share/gc/g1/g1ConcurrentMark.cpp src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp src/hotspot/share/gc/g1/g1RootProcessor.cpp src/hotspot/share/gc/g1/g1VMOperations.cpp src/hotspot/share/gc/g1/g1YoungRemSetSamplingThread.cpp src/hotspot/share/gc/parallel/gcTaskManager.cpp src/hotspot/share/gc/shared/gcLocker.cpp src/hotspot/share/gc/shared/workgroup.cpp src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.cpp src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp src/hotspot/share/jfr/recorder/service/jfrPostBox.cpp src/hotspot/share/prims/jvmtiRedefineClasses.cpp src/hotspot/share/runtime/java.cpp src/hotspot/share/runtime/sweeper.cpp src/hotspot/share/runtime/vmOperations.cpp ??? No comments (checked these via Udiffs). Thumbs up! Dan > bug link https://bugs.openjdk.java.net/browse/JDK-8222988 > > Thanks, > Coleen From glaubitz at physik.fu-berlin.de Mon Apr 29 19:40:47 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 29 Apr 2019 21:40:47 +0200 Subject: RFR: 8221639: [x32] expand_exec_shield_cs_limit workaround is undefined code after JDK-8199717 In-Reply-To: References: <673a0cc6b25fcfdcb3f3c69f4dcfd06d346e271a.camel@redhat.com> <87k1fjh6ja.fsf@oldenburg2.str.redhat.com> Message-ID: <40E94D58-B22F-4FE5-8DD8-0AC6A9390EF7@physik.fu-berlin.de> > On Apr 29, 2019, at 8:20 PM, Andrew John Hughes wrote: > > I don't believe OpenJDK has support for x32. At least, we've had a > ticket for it for a long time and I've never had the time to look at > getting even Zero to build on such a platform: We?re building Zero on x32 in Debian, so I think the bug report title should be changed to avoid confusion. I did actually add basic build support for x32 for Zero at some point. Adrian From coleen.phillimore at oracle.com Mon Apr 29 20:26:16 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 29 Apr 2019 16:26:16 -0400 Subject: RFR (S) 8222988: Use MonitorLocker rather than MutexLocker when wait/notify used In-Reply-To: <51e281d0-7544-bc24-196c-ba1da7bf15b9@oracle.com> References: <51e281d0-7544-bc24-196c-ba1da7bf15b9@oracle.com> Message-ID: On 4/29/19 2:53 PM, Daniel D. Daugherty wrote: > On 4/26/19 9:10 AM, coleen.phillimore at oracle.com wrote: >> Summary: fixed use cases in code except CMS. >> >> This affects some GC code and runtime code.? It looks like a nice >> change to me.? Tested with hs tier1-3. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8222988.01/webrev > > src/hotspot/share/runtime/mutexLocker.hpp > ??? No comments. > > src/hotspot/share/runtime/mutexLocker.cpp > ??? No comments. > > src/hotspot/share/runtime/thread.cpp > ??? No comments. > > src/hotspot/share/runtime/vmThread.cpp > ??? L377: ??? while(!VMThread::is_terminated()) { > ??? L378: ??????? ml.wait(); > ??????? nit - please decrease indent by 2 spaces (not your fault) > ??????? nit - L377 needs a space before '(' (also not your fault > ????????????? and you didn't touch this line) Got it! Thank you for reviewing this! Coleen > > src/hotspot/share/compiler/abstractCompiler.cpp > src/hotspot/share/compiler/compileBroker.cpp > src/hotspot/share/gc/g1/g1ConcurrentMark.cpp > src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp > src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp > src/hotspot/share/gc/g1/g1RootProcessor.cpp > src/hotspot/share/gc/g1/g1VMOperations.cpp > src/hotspot/share/gc/g1/g1YoungRemSetSamplingThread.cpp > src/hotspot/share/gc/parallel/gcTaskManager.cpp > src/hotspot/share/gc/shared/gcLocker.cpp > src/hotspot/share/gc/shared/workgroup.cpp > src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.cpp > src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp > src/hotspot/share/jfr/recorder/service/jfrPostBox.cpp > src/hotspot/share/prims/jvmtiRedefineClasses.cpp > src/hotspot/share/runtime/java.cpp > src/hotspot/share/runtime/sweeper.cpp > src/hotspot/share/runtime/vmOperations.cpp > ??? No comments (checked these via Udiffs). > > Thumbs up! > > Dan > > > >> bug link https://bugs.openjdk.java.net/browse/JDK-8222988 >> >> Thanks, >> Coleen > From david.holmes at oracle.com Mon Apr 29 21:35:11 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Apr 2019 07:35:11 +1000 Subject: RFR (S) 8222988: Use MonitorLocker rather than MutexLocker when wait/notify used In-Reply-To: References: Message-ID: Hi Coleen, Sorry I missed this yesterday. This all looks good to me. Thanks, David On 26/04/2019 11:10 pm, coleen.phillimore at oracle.com wrote: > Summary: fixed use cases in code except CMS. > > This affects some GC code and runtime code.? It looks like a nice change > to me.? Tested with hs tier1-3. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8222988.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8222988 > > Thanks, > Coleen From coleen.phillimore at oracle.com Mon Apr 29 21:43:27 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 29 Apr 2019 17:43:27 -0400 Subject: RFR (S) 8222988: Use MonitorLocker rather than MutexLocker when wait/notify used In-Reply-To: References: Message-ID: <90f0c63a-1a43-2ad9-7211-b3f85c6144c9@oracle.com> Thanks David! Coleen On 4/29/19 5:35 PM, David Holmes wrote: > Hi Coleen, > > Sorry I missed this yesterday. This all looks good to me. > > Thanks, > David > > On 26/04/2019 11:10 pm, coleen.phillimore at oracle.com wrote: >> Summary: fixed use cases in code except CMS. >> >> This affects some GC code and runtime code.? It looks like a nice >> change to me.? Tested with hs tier1-3. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8222988.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8222988 >> >> Thanks, >> Coleen From david.holmes at oracle.com Mon Apr 29 22:07:33 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Apr 2019 08:07:33 +1000 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: References: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> Message-ID: <6fb6c390-b987-0be0-6a94-984ce97daa78@oracle.com> Hi Coleen, On 29/04/2019 10:11 pm, 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. So is there a write up of this analysis for the bug report? > >> >>> 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. So these locks are only used by JavaThreads but never with a safepoint check? Thats perfectly valid - I just find it very strange they were previously marked as "always". > >> --- >> >> 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. But that is the problem, the underscore does not make it clear it is a field because _safepoint_check_never and _safepoint_check_always are not fields they are enum values! I think we need a convention for enums values to ensure they can't be mistaken for fields. But that's another issue ... Aside: the hotspot style guide says to avoid use of leading underscores. >> >> ?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"); Whether NJTs use lock() or lock_without_safepoint_check() they are never "asking for a safepoint check" because it is simply doesn't apply to them. You seem to be wanting to enforce that for "never" locks NJTs must use lock_without_safepoint_check() - but that seems an arbitrary constraint. They can use lock() as well because the safepoint-check part is irrelevant. Otherwise you should be barring NJTs from being able to call lock() in all cases regardless of whether it is a always/sometimes/never lock. Thanks, David ----- >> >> 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. > > Thanks, > Coleen >> --- >> >> Thanks, >> David >> >> >>> Thanks, >>> Coleen > From coleen.phillimore at oracle.com Mon Apr 29 22:21:38 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 29 Apr 2019 18:21:38 -0400 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: References: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> Message-ID: <5f534345-4224-3eb0-ba7f-0bbd3300f807@oracle.com> 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. > >> >> ?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. 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 Mon Apr 29 22:38:41 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 29 Apr 2019 18:38:41 -0400 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: <6fb6c390-b987-0be0-6a94-984ce97daa78@oracle.com> References: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> <6fb6c390-b987-0be0-6a94-984ce97daa78@oracle.com> Message-ID: <399568f9-ad0b-2f0d-8602-02b2a593f3aa@oracle.com> Hi David, We had a bit of a collision. On 4/29/19 6:07 PM, David Holmes wrote: > Hi Coleen, > > On 29/04/2019 10:11 pm, 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. > > So is there a write up of this analysis for the bug report? There will be in the subsequent bug report to move the "sometimes" locks to "always" and "never".? I haven't filed it yet. > >> >>> >>>> 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. > > So these locks are only used by JavaThreads but never with a safepoint > check? Thats perfectly valid - I just find it very strange they were > previously marked as "always". > These asserts in OopStorage allowed these locks to be "sometimes" locks, but never "always" locks.? But the locks we actually use for OopStorage were always defined as "never" locks.? We don't want them to be sometimes locks. >> >>> --- >>> >>> 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. > > But that is the problem, the underscore does not make it clear it is a > field because _safepoint_check_never and _safepoint_check_always are > not fields they are enum values! I think we need a convention for > enums values to ensure they can't be mistaken for fields. But that's > another issue ... > > Aside: the hotspot style guide says to avoid use of leading underscores. See next webrev.? I don't want to remove the _ to make the edit larger. > >>> >>> ?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"); > > Whether NJTs use lock() or lock_without_safepoint_check() they are > never "asking for a safepoint check" because it is simply doesn't > apply to them. You seem to be wanting to enforce that for "never" > locks NJTs must use lock_without_safepoint_check() - but that seems an > arbitrary constraint. They can use lock() as well because the > safepoint-check part is irrelevant. Otherwise you should be barring > NJTs from being able to call lock() in all cases regardless of whether > it is a always/sometimes/never lock. > Yes, I'm adding this constraint because it seems kinda pointless to declare a lock to be safepoint_check_never and then call lock() with a safepoint check, even though NJTs don't participate in the safepoint protocol.? I can remove this assert but it did help me find and clean up an inconsistent lock, so now everything is more clear and following the rules. Thanks, Coleen > Thanks, > David > ----- > >>> >>> 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. >> >> Thanks, >> Coleen >>> --- >>> >>> Thanks, >>> David >>> >>> >>>> Thanks, >>>> Coleen >> From david.holmes at oracle.com Tue Apr 30 00:22:30 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Apr 2019 10:22:30 +1000 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: <5f534345-4224-3eb0-ba7f-0bbd3300f807@oracle.com> References: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> <5f534345-4224-3eb0-ba7f-0bbd3300f807@oracle.com> Message-ID: 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 david.holmes at oracle.com Tue Apr 30 00:39:29 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Apr 2019 10:39:29 +1000 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: <399568f9-ad0b-2f0d-8602-02b2a593f3aa@oracle.com> References: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> <6fb6c390-b987-0be0-6a94-984ce97daa78@oracle.com> <399568f9-ad0b-2f0d-8602-02b2a593f3aa@oracle.com> Message-ID: Hi Coleen, On 30/04/2019 8:38 am, coleen.phillimore at oracle.com wrote: > > Hi David, We had a bit of a collision. Yep so trimming ... > On 4/29/19 6:07 PM, David Holmes wrote: >> On 29/04/2019 10:11 pm, coleen.phillimore at oracle.com wrote: >>>> 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. >> >> So is there a write up of this analysis for the bug report? > > There will be in the subsequent bug report to move the "sometimes" locks > to "always" and "never".? I haven't filed it yet. Okay but that is for the three remaining "sometimes" locks - right? Not the many that have been changed as part of this RFE. >>>> 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? > > These asserts in OopStorage allowed these locks to be "sometimes" locks, > but never "always" locks.? But the locks we actually use for OopStorage > were always defined as "never" locks.? We don't want them to be > sometimes locks. Okay. >>>> ?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"); >> >> Whether NJTs use lock() or lock_without_safepoint_check() they are >> never "asking for a safepoint check" because it is simply doesn't >> apply to them. You seem to be wanting to enforce that for "never" >> locks NJTs must use lock_without_safepoint_check() - but that seems an >> arbitrary constraint. They can use lock() as well because the >> safepoint-check part is irrelevant. Otherwise you should be barring >> NJTs from being able to call lock() in all cases regardless of whether >> it is a always/sometimes/never lock. >> > > Yes, I'm adding this constraint because it seems kinda pointless to > declare a lock to be safepoint_check_never and then call lock() with a > safepoint check, even though NJTs don't participate in the safepoint > protocol.? I can remove this assert but it did help me find and clean up > an inconsistent lock, so now everything is more clear and following the > rules. I don't agree but will let it drop. I do request a change to the comment though because it isn't the NJT that is defined with safepoint_check_never // If defined with safepoint_check_never a NonJavaThread should never ask to safepoint check either. Thanks, David ----- > Thanks, > Coleen > > > > > >> Thanks, >> David >> ----- >> >>>> >>>> 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. >>> >>> Thanks, >>> Coleen >>>> --- >>>> >>>> Thanks, >>>> David >>>> >>>> >>>>> Thanks, >>>>> Coleen >>> > From coleen.phillimore at oracle.com Tue Apr 30 00:53:26 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 29 Apr 2019 20:53:26 -0400 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: References: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> <6fb6c390-b987-0be0-6a94-984ce97daa78@oracle.com> <399568f9-ad0b-2f0d-8602-02b2a593f3aa@oracle.com> Message-ID: <3f36ad0b-d784-e529-7b40-eb1d60b3a483@oracle.com> 2 replies. On 4/29/19 8:39 PM, David Holmes wrote: > Hi Coleen, > > On 30/04/2019 8:38 am, coleen.phillimore at oracle.com wrote: >> >> Hi David, We had a bit of a collision. > > Yep so trimming ... > >> On 4/29/19 6:07 PM, David Holmes wrote: >>> On 29/04/2019 10:11 pm, coleen.phillimore at oracle.com wrote: >>>>> 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. >>> >>> So is there a write up of this analysis for the bug report? >> >> There will be in the subsequent bug report to move the "sometimes" >> locks to "always" and "never".? I haven't filed it yet. > > Okay but that is for the three remaining "sometimes" locks - right? > Not the many that have been changed as part of this RFE. Okay, yes, I will list the ones I changed to the bug report. > >>>>> 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? >> >> These asserts in OopStorage allowed these locks to be "sometimes" >> locks, but never "always" locks.? But the locks we actually use for >> OopStorage were always defined as "never" locks.? We don't want them >> to be sometimes locks. > > Okay. > >>>>> ?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"); >>> >>> Whether NJTs use lock() or lock_without_safepoint_check() they are >>> never "asking for a safepoint check" because it is simply doesn't >>> apply to them. You seem to be wanting to enforce that for "never" >>> locks NJTs must use lock_without_safepoint_check() - but that seems >>> an arbitrary constraint. They can use lock() as well because the >>> safepoint-check part is irrelevant. Otherwise you should be barring >>> NJTs from being able to call lock() in all cases regardless of >>> whether it is a always/sometimes/never lock. >>> >> >> Yes, I'm adding this constraint because it seems kinda pointless to >> declare a lock to be safepoint_check_never and then call lock() with >> a safepoint check, even though NJTs don't participate in the >> safepoint protocol.? I can remove this assert but it did help me find >> and clean up an inconsistent lock, so now everything is more clear >> and following the rules. > > I don't agree but will let it drop. I do request a change to the > comment though because it isn't the NJT that is defined with > safepoint_check_never > > // If defined with safepoint_check_never a NonJavaThread should never > ask to safepoint check either. Added with comma between never and a. Thanks, Coleen > > Thanks, > David > ----- > >> Thanks, >> Coleen >> >> >> >> >> >>> Thanks, >>> David >>> ----- >>> >>>>> >>>>> 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. >>>> >>>> Thanks, >>>> Coleen >>>>> --- >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>>> Thanks, >>>>>> Coleen >>>> >> From coleen.phillimore at oracle.com Tue Apr 30 01:23:31 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 29 Apr 2019 21:23:31 -0400 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: References: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> <5f534345-4224-3eb0-ba7f-0bbd3300f807@oracle.com> Message-ID: > 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 david.holmes at oracle.com Tue Apr 30 02:06:14 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Apr 2019 12:06:14 +1000 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: References: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> <5f534345-4224-3eb0-ba7f-0bbd3300f807@oracle.com> Message-ID: On 30/04/2019 11:23 am, 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 Looks good - thanks! I almost forgot to comment on the test. :) I don't quite understand the comments about needing to acquire the Heap_lock wityhout a safepoint checks, as VerifyBeforeExit is processed by the VMThread whilst at the final safepoint. Thanks again, David > 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 leonid.mesnik at oracle.com Tue Apr 30 03:14:27 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Mon, 29 Apr 2019 20:14:27 -0700 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: References: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> <5f534345-4224-3eb0-ba7f-0bbd3300f807@oracle.com> Message-ID: <65031818-D07C-4D28-AD80-B5371B61B4F3@oracle.com> 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'? 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. 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 david.holmes at oracle.com Tue Apr 30 03:54:42 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Apr 2019 13:54:42 +1000 Subject: RFR (S): 8222534: VerifyBeforeExit is not honored when System.exit is called Message-ID: <94327eae-0553-a346-bc4f-e0ff8ffa7ce5@oracle.com> 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 Tue Apr 30 06:40:26 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 30 Apr 2019 08:40:26 +0200 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: References: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> <5f534345-4224-3eb0-ba7f-0bbd3300f807@oracle.com> Message-ID: <03b64b54-bf28-60ad-0d3e-7d05528bdc5e@oracle.com> > Looks good - thanks! +1, thanks. > > I almost forgot to comment on the test. :) I don't quite understand the comments > about needing to acquire the Heap_lock wityhout a safepoint checks, as > VerifyBeforeExit is processed by the VMThread whilst at the final safepoint. The problematic usecase is in Threads::destroy_vm(). A JavaThread off the ThreadsList must never use safepoint checking. I'm playing with patch which changes the check in mutex.cpp. - if (self->is_Java_thread()) { + // Is it a JavaThread participating in the safepoint protocol. + if (self->is_active_Java_thread()) { Which fixes both Heap and Threads lock. For the record when(/if) we succeeded to only have always and never locks, I strongly suggest they are different types. E.g. in oopStorage we can remove asserts because we get compile error instead. /Robbin > > Thanks again, > David > >> 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 robbin.ehn at oracle.com Tue Apr 30 06:51:46 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 30 Apr 2019 08:51:46 +0200 Subject: RFR (S): 8222534: VerifyBeforeExit is not honored when System.exit is called In-Reply-To: <94327eae-0553-a346-bc4f-e0ff8ffa7ce5@oracle.com> References: <94327eae-0553-a346-bc4f-e0ff8ffa7ce5@oracle.com> Message-ID: <4b9f7810-1d9b-a700-b909-40317232ccfa@oracle.com> Hi David, looks good, thanks for fixing! /Robbin On 2019-04-30 05:54, 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 Tue Apr 30 07:04:27 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 30 Apr 2019 09:04:27 +0200 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: <44b9455e-9642-729d-6ef4-64603bdf278e@oracle.com> 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 dean.long at oracle.com Tue Apr 30 07:07:08 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 30 Apr 2019 00:07:08 -0700 Subject: RFR (S): 8222534: VerifyBeforeExit is not honored when System.exit is called In-Reply-To: <94327eae-0553-a346-bc4f-e0ff8ffa7ce5@oracle.com> References: <94327eae-0553-a346-bc4f-e0ff8ffa7ce5@oracle.com> Message-ID: 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. dl From matthias.baesken at sap.com Tue Apr 30 07:23:10 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 30 Apr 2019 07:23:10 +0000 Subject: 8222720: Provide extended VMWare/vSphere virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: <44b9455e-9642-729d-6ef4-64603bdf278e@oracle.com> References: <44b9455e-9642-729d-6ef4-64603bdf278e@oracle.com> Message-ID: 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 david.holmes at oracle.com Tue Apr 30 07:36:29 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Apr 2019 17:36:29 +1000 Subject: RFR (S): 8222534: VerifyBeforeExit is not honored when System.exit is called In-Reply-To: <4b9f7810-1d9b-a700-b909-40317232ccfa@oracle.com> References: <94327eae-0553-a346-bc4f-e0ff8ffa7ce5@oracle.com> <4b9f7810-1d9b-a700-b909-40317232ccfa@oracle.com> Message-ID: Thanks Robbin! David On 30/04/2019 4:51 pm, Robbin Ehn wrote: > Hi David, looks good, thanks for fixing! > > /Robbin > > On 2019-04-30 05:54, 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 Tue Apr 30 08:07:21 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Apr 2019 18:07:21 +1000 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: <03b64b54-bf28-60ad-0d3e-7d05528bdc5e@oracle.com> References: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> <5f534345-4224-3eb0-ba7f-0bbd3300f807@oracle.com> <03b64b54-bf28-60ad-0d3e-7d05528bdc5e@oracle.com> Message-ID: <047dedcf-d091-3a24-9995-556357a438b9@oracle.com> Hi Robbin, On 30/04/2019 4:40 pm, Robbin Ehn wrote: >> Looks good - thanks! > > +1, thanks. > >> >> I almost forgot to comment on the test. :) I don't quite understand >> the comments about needing to acquire the Heap_lock wityhout a >> safepoint checks, as VerifyBeforeExit is processed by the VMThread >> whilst at the final safepoint. > > The problematic usecase is in Threads::destroy_vm(). > A JavaThread off the ThreadsList must never use safepoint checking. Ah I see - this is not directly related to verifyBeforeExit. It's just a way of "pausing" the GC while we shutdown. > I'm playing with patch which changes the check in mutex.cpp. > > -??? if (self->is_Java_thread()) { > +??? // Is it a JavaThread participating in the safepoint protocol. > +??? if (self->is_active_Java_thread()) { > > Which fixes both Heap and Threads lock. Yuck. Yet another lifecycle state test :( Oh well discussion for another time. :) > For the record when(/if) we succeeded to only have always and never locks, > I strongly suggest they are different types. Not sure about that either. Cheers, David > E.g. in oopStorage we can remove asserts because we get compile error > instead. > > /Robbin > >> >> Thanks again, >> David >> >>> 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 stefan.karlsson at oracle.com Tue Apr 30 08:58:49 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 30 Apr 2019 10:58:49 +0200 Subject: RFR: 8223136: Move compressed oops functions to CompressedOops class Message-ID: <61cb41e8-fcd5-845f-e57f-7a2d46c0c995@oracle.com> 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 thomas.schatzl at oracle.com Tue Apr 30 09:43:49 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 30 Apr 2019 11:43:49 +0200 Subject: Metaspace OOM before reaching MaxMetaspaceSize In-Reply-To: References: <21f1c70851f20f0036bd754179ddb81696f6e045.camel@oracle.com> Message-ID: <868a7a186cfe93b10a278f0c8d85fdc39eef8d97.camel@oracle.com> Hi, On Mon, 2019-04-29 at 11:05 -0700, Shengpei Zhang wrote: > Thanks David and Thomas :) > > I checked our mmap limit, it is 64M. The # of mmap in the hs file is > around 6K. I also did checked the current running process, it is > about 8K. So I do not think it hit the mmap limit. > > @Thomas > Below is the rlimit output in the hs_err log, I am not sure how to > interrupt it... > > --------------- S Y S T E M --------------- > > OS:CentOS Linux release 7.5.1804 (Core) > uname:Linux 4.11.3-88_fbk23_4223_g7d3b7f39d8b1 #88 SMP Thu Jan 31 > 13:08:24 PST 2019 x86_64 > libc:glibc 2.17 NPTL 2.17 > rlimit: STACK 8192k, CORE infinity, NPROC 1030660, NOFILE 262144, AS > infinity, DATA infinity, FSIZE infinity > load average:99.10 107.68 103.71 > > One interesting article I saw is > https://bugs.openjdk.java.net/browse/JDK-8187709. Someone mentioned > for (-XX:-UseCompressedOops) enabled machines, the native memory > might be allocated at lower memory space, so the actual available > memory is less than free memory. Could this be the cause? > as far as I know this only affects the default Solaris memory manager, so not applicable. Thanks, Thomas From aph at redhat.com Tue Apr 30 09:44:10 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 30 Apr 2019 10:44:10 +0100 Subject: RFR: 8221639: [x32] expand_exec_shield_cs_limit workaround is undefined code after JDK-8199717 In-Reply-To: <8736m57xib.fsf@oldenburg2.str.redhat.com> References: <673a0cc6b25fcfdcb3f3c69f4dcfd06d346e271a.camel@redhat.com> <87k1fjh6ja.fsf@oldenburg2.str.redhat.com> <1cb99e07-b4c9-725d-8cca-fbc26661a8c5@oracle.com> <8736m57xib.fsf@oldenburg2.str.redhat.com> Message-ID: <75ebbbba-b27a-93dc-a61d-8232a95492f0@redhat.com> On 4/26/19 1:37 PM, Florian Weimer wrote: > The RHEL 6 kernel requires PAE, so you need to find a box which supports > PAE but not NX. These are more common than I expected (at least in our > labs). So the changes should indeed be testable, and the CS limit > workaround may still be needed. Yes, exactly. I wrote test/hotspot/jtreg/runtime/StackGap to test this. i386 OpenJDK is going to be kept for a long time on ancient systems with ancient kernels. It'd be a shame to break it. -- 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 Tue Apr 30 10:45:26 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Apr 2019 20:45:26 +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: 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 robbin.ehn at oracle.com Tue Apr 30 10:59:29 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 30 Apr 2019 12:59:29 +0200 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: <047dedcf-d091-3a24-9995-556357a438b9@oracle.com> References: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> <5f534345-4224-3eb0-ba7f-0bbd3300f807@oracle.com> <03b64b54-bf28-60ad-0d3e-7d05528bdc5e@oracle.com> <047dedcf-d091-3a24-9995-556357a438b9@oracle.com> Message-ID: <3a2f6ebb-c2bd-6bfe-43dd-9701ec320e3b@oracle.com> Hi Coleen, I think you missed a spot for freeList lock: if (is_par) _indexedFreeListParLocks[rem_sz]->lock(); returnChunkToFreeList(ffc); split(size, rem_sz); if (is_par) _indexedFreeListParLocks[rem_sz]->unlock(); I hit this assert: # assert(self->is_Java_thread() || !do_safepoint_check || _safepoint_check_required != _safepoint_check_never) failed: NonJavaThreads can only check for safepoints if shared with JavaThreads Since we pass this lock around like crazy there is no way to search for this lock. If 'never locks' was a different type from 'always locks' this would have been caught in compile time... :) V [libjvm.so+0x131b1ac] FreeChunk*CompactibleFreeListSpace::splitChunkAndReturnRemainder(FreeChunk*,unsigned long)+0x38c V [libjvm.so+0x1319f74] FreeChunk*CompactibleFreeListSpace::getChunkFromDictionaryExact(unsigned long)+0x2c4 V [libjvm.so+0x131d854] HeapWordImpl**CompactibleFreeListSpaceLAB::alloc(unsigned long)+0xb4 V [libjvm.so+0x139194c] oop ConcurrentMarkSweepGeneration::par_promote(int,oop,markOopDesc*,unsigned long)+0x18c V [libjvm.so+0x1f68170] oop ParNewGeneration::copy_to_survivor_space(ParScanThreadState*,oop,unsigned long,markOopDesc*)+0x2d0 V [libjvm.so+0x1f72894] void ParScanClosure::do_oop_work(__type_0*,bool,bool)+0x674 V [libjvm.so+0x1f7b91c] void InstanceKlass::oop_oop_iterate_oop_maps(oop,__type_1*)+0x36c V [libjvm.so+0x1f79590] void OopOopIterateDispatch::Table::oop_oop_iterate(ParScanWithBarrierClosure*,oop,Klass*)+0x80 V [libjvm.so+0x1f65d68] void ParEvacuateFollowersClosure::do_void()+0xbc8 V [libjvm.so+0x1f6677c] void ParNewGenTask::work(unsigned)+0x10c V [libjvm.so+0x23c05d4] void GangWorker::loop()+0xa4 V [libjvm.so+0x2268df8] void Thread::call_run()+0x178 V [libjvm.so+0x1f37b6c] thread_native_entry+0x3ac /Robbin On 2019-04-30 10:07, David Holmes wrote: > Hi Robbin, > > On 30/04/2019 4:40 pm, Robbin Ehn wrote: >>> Looks good - thanks! >> >> +1, thanks. >> >>> >>> I almost forgot to comment on the test. :) I don't quite understand the >>> comments about needing to acquire the Heap_lock wityhout a safepoint checks, >>> as VerifyBeforeExit is processed by the VMThread whilst at the final safepoint. >> >> The problematic usecase is in Threads::destroy_vm(). >> A JavaThread off the ThreadsList must never use safepoint checking. > > Ah I see - this is not directly related to verifyBeforeExit. It's just a way of > "pausing" the GC while we shutdown. > >> I'm playing with patch which changes the check in mutex.cpp. >> >> -??? if (self->is_Java_thread()) { >> +??? // Is it a JavaThread participating in the safepoint protocol. >> +??? if (self->is_active_Java_thread()) { >> >> Which fixes both Heap and Threads lock. > > Yuck. Yet another lifecycle state test :( Oh well discussion for another time. :) > >> For the record when(/if) we succeeded to only have always and never locks, >> I strongly suggest they are different types. > > Not sure about that either. > > Cheers, > David > >> E.g. in oopStorage we can remove asserts because we get compile error instead. >> >> /Robbin >> >>> >>> Thanks again, >>> David >>> >>>> 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 david.holmes at oracle.com Tue Apr 30 12:52:16 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Apr 2019 22:52:16 +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: 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 aph at redhat.com Tue Apr 30 14:42:47 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 30 Apr 2019 15:42:47 +0100 Subject: RFR: 8223089: Stack alignment for x86-32 Message-ID: <481b88c2-1243-2990-6898-d5fe3108eb2d@redhat.com> 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. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From stefan.karlsson at oracle.com Tue Apr 30 14:53:21 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 30 Apr 2019 16:53:21 +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: <08faca7a-db6d-9d12-2800-002f52b10a8b@oracle.com> On 2019-04-30 10:58, Stefan Karlsson wrote: ... > I've tried to update all platforms, but would appreciate verification > from platform maintainers that the changes don't break the build. I realize that the patch above won't apply as is, since I've based it on top of '8198505: Remove CollectorPolicy and its subclasses' I'll get back to this thread after that patch has been pushed. Thanks, StefanK > Thanks, > StefanK From coleen.phillimore at oracle.com Tue Apr 30 15:27:03 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 30 Apr 2019 11:27:03 -0400 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: <65031818-D07C-4D28-AD80-B5371B61B4F3@oracle.com> References: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> <5f534345-4224-3eb0-ba7f-0bbd3300f807@oracle.com> <65031818-D07C-4D28-AD80-B5371B61B4F3@oracle.com> Message-ID: <6cc59904-fcfb-d8b7-021e-c9fc2bb39cac@oracle.com> 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 Tue Apr 30 15:49:54 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 30 Apr 2019 11:49:54 -0400 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: <3a2f6ebb-c2bd-6bfe-43dd-9701ec320e3b@oracle.com> References: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> <5f534345-4224-3eb0-ba7f-0bbd3300f807@oracle.com> <03b64b54-bf28-60ad-0d3e-7d05528bdc5e@oracle.com> <047dedcf-d091-3a24-9995-556357a438b9@oracle.com> <3a2f6ebb-c2bd-6bfe-43dd-9701ec320e3b@oracle.com> Message-ID: On 4/30/19 6:59 AM, Robbin Ehn wrote: > Hi Coleen, > > I think you missed a spot for freeList lock: > ??? if (is_par) _indexedFreeListParLocks[rem_sz]->lock(); > ??? returnChunkToFreeList(ffc); > ??? split(size, rem_sz); > ??? if (is_par) _indexedFreeListParLocks[rem_sz]->unlock(); Got it.? I was able to reproduce this and test the fix.? Thank you! > > I hit this assert: > #? assert(self->is_Java_thread() || !do_safepoint_check || > _safepoint_check_required != _safepoint_check_never) failed: > NonJavaThreads can only check for safepoints if shared with JavaThreads > > Since we pass this lock around like crazy there is no way to search > for this lock. > If 'never locks' was a different type from 'always locks' this would > have been caught in compile time... :) Okay, you're made this more convincing.? I'll open an RFE and we can discuss this. Thanks for the review! Coleen > > V? [libjvm.so+0x131b1ac] > FreeChunk*CompactibleFreeListSpace::splitChunkAndReturnRemainder(FreeChunk*,unsigned > long)+0x38c > V? [libjvm.so+0x1319f74] > FreeChunk*CompactibleFreeListSpace::getChunkFromDictionaryExact(unsigned > long)+0x2c4 > V? [libjvm.so+0x131d854] > HeapWordImpl**CompactibleFreeListSpaceLAB::alloc(unsigned long)+0xb4 > V? [libjvm.so+0x139194c]? oop > ConcurrentMarkSweepGeneration::par_promote(int,oop,markOopDesc*,unsigned > long)+0x18c > V? [libjvm.so+0x1f68170]? oop > ParNewGeneration::copy_to_survivor_space(ParScanThreadState*,oop,unsigned > long,markOopDesc*)+0x2d0 > V? [libjvm.so+0x1f72894]? void > ParScanClosure::do_oop_work(__type_0*,bool,bool)+0x674 > V? [libjvm.so+0x1f7b91c]? void > InstanceKlass::oop_oop_iterate_oop_maps(oop,__type_1*)+0x36c > V? [libjvm.so+0x1f79590]? void > OopOopIterateDispatch::Table::oop_oop_iterate(ParScanWithBarrierClosure*,oop,Klass*)+0x80 > V? [libjvm.so+0x1f65d68]? void > ParEvacuateFollowersClosure::do_void()+0xbc8 > V? [libjvm.so+0x1f6677c]? void ParNewGenTask::work(unsigned)+0x10c > V? [libjvm.so+0x23c05d4]? void GangWorker::loop()+0xa4 > V? [libjvm.so+0x2268df8]? void Thread::call_run()+0x178 > V? [libjvm.so+0x1f37b6c]? thread_native_entry+0x3ac > > /Robbin > > > On 2019-04-30 10:07, David Holmes wrote: >> Hi Robbin, >> >> On 30/04/2019 4:40 pm, Robbin Ehn wrote: >>>> Looks good - thanks! >>> >>> +1, thanks. >>> >>>> >>>> I almost forgot to comment on the test. :) I don't quite understand >>>> the comments about needing to acquire the Heap_lock wityhout a >>>> safepoint checks, as VerifyBeforeExit is processed by the VMThread >>>> whilst at the final safepoint. >>> >>> The problematic usecase is in Threads::destroy_vm(). >>> A JavaThread off the ThreadsList must never use safepoint checking. >> >> Ah I see - this is not directly related to verifyBeforeExit. It's >> just a way of "pausing" the GC while we shutdown. >> >>> I'm playing with patch which changes the check in mutex.cpp. >>> >>> -??? if (self->is_Java_thread()) { >>> +??? // Is it a JavaThread participating in the safepoint protocol. >>> +??? if (self->is_active_Java_thread()) { >>> >>> Which fixes both Heap and Threads lock. >> >> Yuck. Yet another lifecycle state test :( Oh well discussion for >> another time. :) >> >>> For the record when(/if) we succeeded to only have always and never >>> locks, >>> I strongly suggest they are different types. >> >> Not sure about that either. >> >> Cheers, >> David >> >>> E.g. in oopStorage we can remove asserts because we get compile >>> error instead. >>> >>> /Robbin >>> >>>> >>>> Thanks again, >>>> David >>>> >>>>> 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 leonid.mesnik at oracle.com Tue Apr 30 15:57:04 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Tue, 30 Apr 2019 08:57:04 -0700 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: <6cc59904-fcfb-d8b7-021e-c9fc2bb39cac@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> Message-ID: 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 martin.doerr at sap.com Tue Apr 30 16:01:00 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 30 Apr 2019 16:01:00 +0000 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, AFAIK Windows 32 bit only requires 4 byte stack alignment (and 16 byte alignment for 64 bit). Are you planning to make the change only for linux 32 bit? Best regards, Martin -----Original Message----- From: hotspot-dev On Behalf Of Andrew Haley Sent: Dienstag, 30. April 2019 16:43 To: hotspot-dev at openjdk.java.net Subject: RFR: 8223089: Stack alignment for x86-32 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. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From coleen.phillimore at oracle.com Tue Apr 30 15:59:24 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 30 Apr 2019 11:59:24 -0400 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: <047dedcf-d091-3a24-9995-556357a438b9@oracle.com> References: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> <5f534345-4224-3eb0-ba7f-0bbd3300f807@oracle.com> <03b64b54-bf28-60ad-0d3e-7d05528bdc5e@oracle.com> <047dedcf-d091-3a24-9995-556357a438b9@oracle.com> Message-ID: <51f75e4d-00c1-b48e-0b61-21e4f482e012@oracle.com> On 4/30/19 4:07 AM, David Holmes wrote: > Hi Robbin, > > On 30/04/2019 4:40 pm, Robbin Ehn wrote: >>> Looks good - thanks! >> >> +1, thanks. >> >>> >>> I almost forgot to comment on the test. :) I don't quite understand >>> the comments about needing to acquire the Heap_lock wityhout a >>> safepoint checks, as VerifyBeforeExit is processed by the VMThread >>> whilst at the final safepoint. >> >> The problematic usecase is in Threads::destroy_vm(). >> A JavaThread off the ThreadsList must never use safepoint checking. > > Ah I see - this is not directly related to verifyBeforeExit. It's just > a way of "pausing" the GC while we shutdown. Yes.? Thank you Robbin for answering.? The VerifyBeforeExit will crash though if GC isn't paused there for the exiting thread. > >> I'm playing with patch which changes the check in mutex.cpp. >> >> -??? if (self->is_Java_thread()) { >> +??? // Is it a JavaThread participating in the safepoint protocol. >> +??? if (self->is_active_Java_thread()) { >> >> Which fixes both Heap and Threads lock. > > Yuck. Yet another lifecycle state test :( Oh well discussion for > another time. :) > >> For the record when(/if) we succeeded to only have always and never >> locks, >> I strongly suggest they are different types. > > Not sure about that either. I'm starting to be convinced this would be good, despite more code churn.? But we'll see how it looks. Thanks, Coleen > > Cheers, > David > >> E.g. in oopStorage we can remove asserts because we get compile error >> instead. >> >> /Robbin >> >>> >>> Thanks again, >>> David >>> >>>> 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 aph at redhat.com Tue Apr 30 16:09:52 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 30 Apr 2019 17:09:52 +0100 Subject: RFR: 8223089: Stack alignment for x86-32 In-Reply-To: References: <481b88c2-1243-2990-6898-d5fe3108eb2d@redhat.com> Message-ID: On 4/30/19 5:01 PM, Doerr, Martin wrote: > AFAIK Windows 32 bit only requires 4 byte stack alignment (and 16 byte alignment for 64 bit). OK. I didn't know that. > Are you planning to make the change only for linux 32 bit? I certainly could do that, if required. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From daniel.daugherty at oracle.com Tue Apr 30 16:20:10 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 30 Apr 2019 12:20:10 -0400 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: References: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> <5f534345-4224-3eb0-ba7f-0bbd3300f807@oracle.com> Message-ID: On 4/29/19 9: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 src/hotspot/share/gc/cms/compactibleFreeListSpace.cpp ??? No comments. src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.cpp ??? No comments. src/hotspot/share/gc/cms/yieldingWorkgroup.cpp ??? No comments. src/hotspot/share/gc/shared/oopStorage.cpp ??? L769: ???????? "%s: active mutex requires never to safepoint check", _name); ??? L771: ???????? "%s: allocation mutex requires never to safepoint check", _name); ??????? "never to safepoint" reads strangely. Perhaps "never safepoint". src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp ??? No comments. src/hotspot/share/runtime/mutex.cpp ??????? L50: void Monitor::lock(Thread * self) { ??? old L37: ? // Ensure that the Monitor requires/allows safepoint checks. ??????? You deleted the comment here, but you kept the comment here: ??????? L105: void Monitor::lock_without_safepoint_check(Thread * self) { ??????? L106: ? // Ensure that the Monitor does not require safepoint checks. ??????? Why the difference? Looking forward, it looks like you deleted the ??????? comment from other place where check_safepoint_state() is now called. ??????? So it looks like L106 is the odd man out... ??? L286: ? return (strcmp(name, "Threads_lock") == 0 || strcmp(name, "Heap_lock") == 0 || rank == Mutex::suspend_resume); ??????? Using "rank" to determine if this is an SR_lock instead of a name ??????? comparison is just begging for a comment. :-) src/hotspot/share/runtime/mutex.hpp ??? No comments. src/hotspot/share/runtime/mutexLocker.cpp ??? No comments. src/hotspot/share/runtime/vmThread.cpp ??? No comments. test/hotspot/jtreg/runtime/Shutdown/ShutdownTest.java ??? L38: // the threads list.? This fix is still valid.? This code requires Heap_lock be aquired ??????? typo: s/aquired/acquired/ Thumbs up. Dan > > 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 Tue Apr 30 18:47:17 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 30 Apr 2019 14:47:17 -0400 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: References: <6a633b03-404b-3491-32b3-9429a43c616c@oracle.com> <5f534345-4224-3eb0-ba7f-0bbd3300f807@oracle.com> Message-ID: Thank you for reviewing this, Dan! On 4/30/19 12:20 PM, Daniel D. Daugherty wrote: > On 4/29/19 9: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 > > src/hotspot/share/gc/cms/compactibleFreeListSpace.cpp > ??? No comments. > > src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.cpp > ??? No comments. > > src/hotspot/share/gc/cms/yieldingWorkgroup.cpp > ??? No comments. > > src/hotspot/share/gc/shared/oopStorage.cpp > ??? L769: ???????? "%s: active mutex requires never to safepoint > check", _name); > ??? L771: ???????? "%s: allocation mutex requires never to safepoint > check", _name); > ??????? "never to safepoint" reads strangely. Perhaps "never safepoint". Ok, fixed, took out both "to". > > src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp > ??? No comments. > > src/hotspot/share/runtime/mutex.cpp > ??????? L50: void Monitor::lock(Thread * self) { > ??? old L37: ? // Ensure that the Monitor requires/allows safepoint > checks. > ??????? You deleted the comment here, but you kept the comment here: > > ??????? L105: void Monitor::lock_without_safepoint_check(Thread * self) { > ??????? L106: ? // Ensure that the Monitor does not require safepoint > checks. > > ??????? Why the difference? Looking forward, it looks like you deleted > the > ??????? comment from other place where check_safepoint_state() is now > called. > ??????? So it looks like L106 is the odd man out... I deleted the comment at L:106 to be consistent because the function also has comments. > > ??? L286: ? return (strcmp(name, "Threads_lock") == 0 || strcmp(name, > "Heap_lock") == 0 || rank == Mutex::suspend_resume); > ??????? Using "rank" to determine if this is an SR_lock instead of a name > ??????? comparison is just begging for a comment. :-) I originally used "rank" because because in the old location, I was couldn't compare this == SR_lock because there are more than one. Since it uses name in the constructor for the others, I changed it to this: // Only Threads_lock, Heap_lock and SR_lock may be safepoint_check_sometimes. bool is_sometimes_ok(const char* name) { ? return (strcmp(name, "Threads_lock") == 0 || strcmp(name, "Heap_lock") == 0 || strcmp(name, "SR_lock") == 0); } > > src/hotspot/share/runtime/mutex.hpp > ??? No comments. > > src/hotspot/share/runtime/mutexLocker.cpp > ??? No comments. > > src/hotspot/share/runtime/vmThread.cpp > ??? No comments. > > test/hotspot/jtreg/runtime/Shutdown/ShutdownTest.java > ??? L38: // the threads list.? This fix is still valid.? This code > requires Heap_lock be aquired > ??????? typo: s/aquired/acquired/ > Fixed.? I have fixed the test for Leonid also, so I'll send out another version.?? Sorry for not sending out incremental webrevs.? I should have used mq. Thanks! Coleen > > Thumbs up. > > Dan > > >> >> 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 Tue Apr 30 19:03:09 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 30 Apr 2019 15:03:09 -0400 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: 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> Message-ID: <3d4fe829-05fd-64d7-d75a-6b4d9d59003c@oracle.com> 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 Whole (non-incremental) webrev is here.? It only has minor changes to mutex.cpp and oopStorage.cpp. 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 daniel.daugherty at oracle.com Tue Apr 30 19:26:00 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 30 Apr 2019 15:26:00 -0400 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: On 4/30/19 3:03 PM, 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 > > > Whole (non-incremental) webrev is here.? It only has minor changes to > mutex.cpp and oopStorage.cpp. > > http://cr.openjdk.java.net/~coleenp/2019/8074355.06/webrev > Compared the 8074355.0[56] patches in jfilemerge... share/gc/cms/compactibleFreeListSpace.cpp ??? No comments. src/hotspot/share/gc/shared/oopStorage.cpp ??? No comments. src/hotspot/share/runtime/mutex.cpp ??? No comments. test/hotspot/jtreg/runtime/Shutdown/ShutdownTest.java ??? No comments. Thumbs up. Dan > > 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 leonid.mesnik at oracle.com Tue Apr 30 20:02:09 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Tue, 30 Apr 2019 13:02:09 -0700 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: <45f5bc72-0767-c27b-7ad5-928e97431d1c@oracle.com> Test looks good. Leonid On 4/30/19 12:03 PM, 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 > > Whole (non-incremental) webrev is here.? It only has minor changes to > mutex.cpp and oopStorage.cpp. > > 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 Tue Apr 30 20:08:00 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 30 Apr 2019 16:08:00 -0400 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: <45f5bc72-0767-c27b-7ad5-928e97431d1c@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> <45f5bc72-0767-c27b-7ad5-928e97431d1c@oracle.com> Message-ID: Thanks, Leonid - thank you for your help! Coleen On 4/30/19 4:02 PM, Leonid Mesnik wrote: > > Test looks good. > > Leonid > > On 4/30/19 12:03 PM, 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 >> >> Whole (non-incremental) webrev is here.? It only has minor changes to >> mutex.cpp and oopStorage.cpp. >> >> 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 Tue Apr 30 20:23:57 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 30 Apr 2019 16:23:57 -0400 Subject: RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads In-Reply-To: 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: <564633ed-027a-aa16-5377-749fe1c5d886@oracle.com> Thanks Dan! Coleen On 4/30/19 3:26 PM, Daniel D. Daugherty wrote: > On 4/30/19 3:03 PM, 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 >> >> >> Whole (non-incremental) webrev is here.? It only has minor changes to >> mutex.cpp and oopStorage.cpp. >> >> http://cr.openjdk.java.net/~coleenp/2019/8074355.06/webrev >> > > Compared the 8074355.0[56] patches in jfilemerge... > > share/gc/cms/compactibleFreeListSpace.cpp > ??? No comments. > > src/hotspot/share/gc/shared/oopStorage.cpp > ??? No comments. > > src/hotspot/share/runtime/mutex.cpp > ??? No comments. > > test/hotspot/jtreg/runtime/Shutdown/ShutdownTest.java > ??? No comments. > > Thumbs up. > > Dan > > >> >> 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 Tue Apr 30 21:28:53 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 30 Apr 2019 17:28:53 -0400 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: References: <4b759550-f185-724f-7139-9bab648a1966@oracle.com> <119335f1-acb7-fffc-f38a-e50a96b73b3c@oracle.com> <2d206374-cfeb-9b1b-2838-e4e0a774e89d@oracle.com> <8063fb37-f1b0-8b93-bbe8-4dbeeaa54959@oracle.com> <17233985-18c7-305e-5556-fe2b38926b71@oracle.com> <3514c74d-5f6a-61cc-ebea-b9564df61673@oracle.com> <63b8e1d2-3516-88f5-02ac-828dd15baf83@oracle.com> <39774cdd-de9e-c878-4a5a-f6595a93859f@oracle.com> Message-ID: This looks good to me.? Thank you for addressing my comments. Coleen On 4/26/19 6:46 PM, Vladimir Kozlov wrote: > Hi > > I have 2 new deltas for easy review. > > Delta 1 is mostly JVMCI HotSpot refactoring and cleanup: > http://cr.openjdk.java.net/~kvn/8220623/webrev_delta1.07/ > > - Cleanup #include jvmci files. > - Removed BoolObjectClosure parameter from JVMCI::do_unloading() since > it is not used. In JDK 13 this parameter is removed from other places > too. > - Added mtJVMCI type to track memory used by JVMCI. > - Passed Handles as constant references. > - Moved JNIAccessMark, JVMCIObject, MetadataHandleBlock class to > separate new files. > - Moved JVMCI methods bodies from jvmciRuntime.cpp into new jvmci.cpp > file. > - Moved bodies of some JVMCIEnv methods from .hpp into jvmciEnv.cpp > file. They use JNIAccessMark and ThreadToNativeFromVM and I can't use > them in header file because they require #include inline.hpp files. > - Moved bodies of some HotSpotJVMCI methods into jvmciJavaClasses.cpp > file because, again, they need jniHandles.inline.hpp. > - Moved JVMCICompileState class definition to the beginning of > jvmciEnv.hpp file. > > Delta 2: > http://cr.openjdk.java.net/~kvn/8220623/webrev_delta2.07/ > > - Changed MetadataHandleBlock fields which are used only by one > instance to static. > - Renamed field _jmetadata::_handle to _value and corresponding access > methods because it was confusing: handle->handle(). > - Switched from JNIHandleBlock to OopStorage use for _object_handles. > - Additional JVMCI Java side fix for libgraal. > > Full: > http://cr.openjdk.java.net/~kvn/8220623/webrev.07/ > > I think I addressed all comments I received so far. > > Thanks, > Vladimir > > On 4/9/19 7:25 PM, Vladimir Kozlov wrote: >> Thank you, Coleen >> >> On 4/9/19 1:36 PM, coleen.phillimore at oracle.com wrote: >>> >>> I think I missed graal-dev with this reply.? I have a few other >>> comments. >>> >>> +void MetadataHandleBlock::do_unloading(BoolObjectClosure* is_alive) { >>> >>> >>> We've removed the is_alive parameter from all do_unloading, and it >>> appears unused here also. >> >> Yes, I can remove it. >> >>> >>> I don't know about this MetadataHandles block.?? It seems that it >>> could be a concurrent hashtable with a WeakHandle<> if it's for >>> jdk11 and beyond.? Kim might have mentioned this (I haven't read all >>> the replies thoroughly) but JNIHandleBlock wasn't MT safe, and the >>> new OopStorage is safe and scalable. >> >> Yes, Kim also suggested OopStorage. I did not get into that part yet >> but I will definitely do. >> >>> >>> +? jmetadata allocate_handle(methodHandle handle)?????? { return >>> allocate_metadata_handle(handle()); } >>> +? jmetadata allocate_handle(constantPoolHandle handle) { return >>> allocate_metadata_handle(handle()); } >>> >>> +CompLevel JVMCI::adjust_comp_level(methodHandle method, bool >>> is_osr, CompLevel level, JavaThread* thread) { >>> >>> +JVMCIObject JVMCIEnv::new_StackTraceElement(methodHandle method, >>> int bci, JVMCI_TRAPS) { >>> >>> +JVMCIObject JVMCIEnv::new_HotSpotNmethod(methodHandle method, const >>> char* name, jboolean isDefault, jlong compileId, JVMCI_TRAPS) { >>> >>> Passing metadata Handles by copy will call the copy constructor and >>> destructor for these parameters unnecessarily.? They should be >>> passed as *const* references to avoid this. >> >> Okay. >> >>> >>> +class MetadataHandleBlock : public CHeapObj { >>> >>> >>> There should be a better mt? for this.? mtCompiler seems appropriate >>> here.? Depending on how many others of these, you could add an mtJVMCI. >> >> mtJVMCI is good suggestion. >> >>> >>> +??????????? if (TraceNMethodInstalls) { >>> >>> >>> We've had Unified Logging in the sources for a long time now. New >>> code should use UL rather than adding a TraceSomething option.?? I >>> understand it's supposed to be shared with JDK8 code but it seems >>> that you're forward porting what looks like old code into the >>> repository. >> >> Yes, we should use UL for this. >> >> Existing JIT code (ciEnv.cpp) still not using UL for this: >> http://hg.openjdk.java.net/jdk/jdk/file/f847a42ddc01/src/hotspot/share/ci/ciEnv.cpp#l1075 >> >> >> May be I should update it too ... >> >>> >>> Coleen >>> >>> >>> On 4/9/19 4:00 PM, coleen.phillimore at oracle.com wrote: >>>> >>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.06/src/hotspot/share/classfile/classFileParser.cpp.udiff.html >>>> >>>> >>>> It appears this change is to implement >>>> https://bugs.openjdk.java.net/browse/JDK-8193513 which we closed as >>>> WNF.? If you want this change, remove it from this giant patch and >>>> reopen and submit a separate patch for this bug. >> >> Thank you for pointing it. I will do as you suggested. >> >>>> >>>> It shouldn't be conditional on JVMCI and should use the normal >>>> unified logging mechanism. >> >> Okay. >> >>>> >>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.06/src/hotspot/share/runtime/thread.hpp.udiff.html >>>> >>>> >>>> *!_jlong__pending_failed_speculation;* >>>> >>>> >>>> We've been trying to remove and avoid java types in hotspot code >>>> and use the appropriate C++ types instead.? Can this be changed to >>>> int64_t?? 'long' is generally wrong though. >> >> This field should be java type since it is accessed from Java Graal: >> >> http://hg.openjdk.java.net/jdk/jdk/file/f847a42ddc01/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java#l401 >> >> >>>> >>>> I seem to remember there was code to deal with metadata in oops for >>>> redefinition, but I can't find it in this big patch.? I was going >>>> to look at that. >> >> May be it is MetadataHandleBlock::metadata_do() (in jvmciRuntime.cpp)? >> >>>> >>>> Otherwise, I've reviewed the runtime code. >> >> Thanks, >> Vladimir >> >>>> >>>> Coleen >>>> >>>> On 4/4/19 3:22 AM, Vladimir Kozlov wrote: >>>>> New delta: >>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.06/ >>>>> >>>>> Full: >>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.06/ >>>>> >>>>> New changes are based on Kim and Stefan suggestions: >>>>> >>>>> - Moved JVMCI::oops_do() from JNIHandles to places where it should >>>>> be called. >>>>> - Moved JVMCI cleanup task to the beginning of >>>>> ParallelCleaningTask::work(). >>>>> - Used JVMCI_ONLY macro with COMMA. >>>>> - Disable JVMCI build on SPARC. We don't use it - neither Graal or >>>>> AOT are built on SPARC. Disabling also helps to find missing JVMCI >>>>> guards. >>>>> >>>>> I ran hs-tier1-3 testing - it passed (hs-tier3 includes graal >>>>> testing). >>>>> I started hs-tier4..8-graal testing. >>>>> I will do performance testing next. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 4/3/19 9:54 AM, Vladimir Kozlov wrote: >>>>>> On 4/2/19 11:35 PM, Stefan Karlsson wrote: >>>>>>> On 2019-04-02 22:41, Vladimir Kozlov wrote: >>>>>>>> I ran Kitchensink with G1 and -Xmx8g. I observed that Remark >>>>>>>> pause times are not consistent even without Graal. >>>>>>>> To see effect I added time spent in JVMCI::do_unloading() to GC >>>>>>>> log (see below [3]). The result is < 1ms - it is less than 1% >>>>>>>> of a pause time. >>>>>>> >>>>>>> Kitchensink isn't really a benchmark, but a stress test. I sent >>>>>>> you a private mail how to run these changes through our internal >>>>>>> performance test setup. >>>>>> >>>>>> Okay, I will run performance tests there too. >>>>>> >>>>>>> >>>>>>>> >>>>>>>> It will have even less effect since I moved >>>>>>>> JVMCI::do_unloading() from serial path to parallel worker >>>>>>>> thread as Stefan suggested. >>>>>>>> >>>>>>>> Stefan, are you satisfied with these changes now? >>>>>>> >>>>>>> Yes, the clean-ups look good. Thanks for cleaning this up. >>>>>>> >>>>>>> Kim had some extra comments about a few more places where >>>>>>> JVMCI_ONLY could be used. >>>>>>> >>>>>>> I also agree with him that JVMCI::oops_do should not be placed >>>>>>> in JNIHandles::oops_do. I think you should put it where you put >>>>>>> the AOTLoader::oops_do calls. >>>>>> >>>>>> Okay. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> StefanK >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Here is latest delta update which includes previous [1] delta and >>>>>>>> - use CompilerThreadStackSize * 2 for libgraal instead of exact >>>>>>>> value, >>>>>>>> - removed HandleMark added for debugging (reverted changes in >>>>>>>> jvmtiImpl.cpp), >>>>>>>> - added recent jvmci-8 changes to fix registration of native >>>>>>>> methods in libgraal (jvmciCompilerToVM.cpp) >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.05/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> [1] http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.04/ >>>>>>>> [2] Original webrev >>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ >>>>>>>> [3] Pauses times from Kitchensink (0.0ms means there were no >>>>>>>> unloaded classes, 'NNN alive' shows how many metadata >>>>>>>> references were processed): >>>>>>>> >>>>>>>> [1.083s][1554229160638ms][info ][gc,start???? ] GC(2) Pause Remark >>>>>>>> [1.085s][1554229160639ms][info ][gc?????????? ] GC(2) >>>>>>>> JVMCI::do_unloading(): 0 alive 0.000ms >>>>>>>> [1.099s][1554229160654ms][info ][gc?????????? ] GC(2) Pause >>>>>>>> Remark 28M->28M(108M) 16.123ms >>>>>>>> >>>>>>>> [3.097s][1554229162651ms][info ][gc,start???? ] GC(12) Pause >>>>>>>> Remark >>>>>>>> [3.114s][1554229162668ms][info ][gc?????????? ] GC(12) >>>>>>>> JVMCI::do_unloading(): 3471 alive 0.164ms >>>>>>>> [3.148s][1554229162702ms][info ][gc?????????? ] GC(12) Pause >>>>>>>> Remark 215M->213M(720M) 51.103ms >>>>>>>> >>>>>>>> [455.111s][1554229614666ms][info ][gc,phases,start] GC(1095) >>>>>>>> Phase 1: Mark live objects >>>>>>>> [455.455s][1554229615010ms][info ][gc???????????? ] GC(1095) >>>>>>>> JVMCI::do_unloading(): 4048 alive 0.821ms >>>>>>>> [455.456s][1554229615010ms][info ][gc,phases????? ] GC(1095) >>>>>>>> Phase 1: Mark live objects 344.107ms >>>>>>>> >>>>>>>> [848.932s][1554230008486ms][info ][gc,phases,start] GC(1860) >>>>>>>> Phase 1: Mark live objects >>>>>>>> [849.248s][1554230008803ms][info ][gc???????????? ] GC(1860) >>>>>>>> JVMCI::do_unloading(): 3266 alive 0.470ms >>>>>>>> [849.249s][1554230008803ms][info ][gc,phases????? ] GC(1860) >>>>>>>> Phase 1: Mark live objects 316.527ms >>>>>>>> >>>>>>>> [1163.778s][1554230323332ms][info ][gc,start?????? ] GC(2627) >>>>>>>> Pause Remark >>>>>>>> [1163.932s][1554230323486ms][info ][gc???????????? ] GC(2627) >>>>>>>> JVMCI::do_unloading(): 3474 alive 0.642ms >>>>>>>> [1163.941s][1554230323496ms][info ][gc???????????? ] GC(2627) >>>>>>>> Pause Remark 2502M->2486M(4248M) 163.296ms >>>>>>>> >>>>>>>> [1242.587s][1554230402141ms][info ][gc,phases,start] GC(2734) >>>>>>>> Phase 1: Mark live objects >>>>>>>> [1242.899s][1554230402453ms][info ][gc???????????? ] GC(2734) >>>>>>>> JVMCI::do_unloading(): 3449 alive 0.570ms >>>>>>>> [1242.899s][1554230402453ms][info ][gc,phases????? ] GC(2734) >>>>>>>> Phase 1: Mark live objects 311.719ms >>>>>>>> >>>>>>>> [1364.164s][1554230523718ms][info ][gc,phases,start] GC(3023) >>>>>>>> Phase 1: Mark live objects >>>>>>>> [1364.613s][1554230524167ms][info ][gc???????????? ] GC(3023) >>>>>>>> JVMCI::do_unloading(): 3449 alive 0.000ms >>>>>>>> [1364.613s][1554230524167ms][info ][gc,phases????? ] GC(3023) >>>>>>>> Phase 1: Mark live objects 448.495ms >>>>>>>> >>>>>>>> [1425.222s][1554230584776ms][info ][gc,phases,start] GC(3151) >>>>>>>> Phase 1: Mark live objects >>>>>>>> [1425.587s][1554230585142ms][info ][gc???????????? ] GC(3151) >>>>>>>> JVMCI::do_unloading(): 3491 alive 0.882ms >>>>>>>> [1425.587s][1554230585142ms][info ][gc,phases????? ] GC(3151) >>>>>>>> Phase 1: Mark live objects 365.403ms >>>>>>>> >>>>>>>> [1456.401s][1554230615955ms][info ][gc,phases,start] GC(3223) >>>>>>>> Phase 1: Mark live objects >>>>>>>> [1456.769s][1554230616324ms][info ][gc???????????? ] GC(3223) >>>>>>>> JVMCI::do_unloading(): 3478 alive 0.616ms >>>>>>>> [1456.769s][1554230616324ms][info ][gc,phases????? ] GC(3223) >>>>>>>> Phase 1: Mark live objects 368.643ms >>>>>>>> >>>>>>>> [1806.139s][1554230965694ms][info?? ][gc,start ] GC(4014) Pause >>>>>>>> Remark >>>>>>>> [1806.161s][1554230965716ms][info?? ][gc ] GC(4014) >>>>>>>> JVMCI::do_unloading(): 3478 alive 0.000ms >>>>>>>> [1806.163s][1554230965717ms][info?? ][gc ] GC(4014) Pause >>>>>>>> Remark 1305M->1177M(2772M) 23.190ms >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 4/1/19 12:34 AM, Stefan Karlsson wrote: >>>>>>>>> On 2019-03-29 17:55, Vladimir Kozlov wrote: >>>>>>>>>> Stefan, >>>>>>>>>> >>>>>>>>>> Do you have a test (and flags) which can allow me to measure >>>>>>>>>> effect of this code on G1 remark pause? >>>>>>>>> >>>>>>>>> >>>>>>>>> -Xlog:gc prints the remark times: >>>>>>>>> [4,296s][info][gc?????? ] GC(89) Pause Remark 4M->4M(28M) >>>>>>>>> 36,412ms >>>>>>>>> >>>>>>>>> StefanK >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 3/29/19 12:36 AM, Stefan Karlsson wrote: >>>>>>>>>>> On 2019-03-29 03:07, Vladimir Kozlov wrote: >>>>>>>>>>>> Hi Stefan, >>>>>>>>>>>> >>>>>>>>>>>> I collected some data on MetadataHandleBlock. >>>>>>>>>>>> >>>>>>>>>>>> First, do_unloading() code is executed only when >>>>>>>>>>>> class_unloading_occurred is 'true' - it is rare case. It >>>>>>>>>>>> should not affect normal G1 remark pause. >>>>>>>>>>> >>>>>>>>>>> It's only rare for applications that don't do dynamic class >>>>>>>>>>> loading and unloading. The applications that do, will be >>>>>>>>>>> affected. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Second, I run a test with -Xcomp. I got about 10,000 >>>>>>>>>>>> compilations by Graal and next data at the end of execution: >>>>>>>>>>>> >>>>>>>>>>>> max_blocks = 232 >>>>>>>>>>>> max_handles_per_block = 32 (since handles array has 32 >>>>>>>>>>>> elements) >>>>>>>>>>>> max_total_alive_values = 4631 >>>>>>>>>>> >>>>>>>>>>> OK. Thanks for the info. >>>>>>>>>>> >>>>>>>>>>> StefanK >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>> On 3/28/19 2:44 PM, Vladimir Kozlov wrote: >>>>>>>>>>>>> Thank you, Stefan >>>>>>>>>>>>> >>>>>>>>>>>>> On 3/28/19 12:54 PM, Stefan Karlsson wrote: >>>>>>>>>>>>>> Hi Vladimir, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I started to check the GC code. >>>>>>>>>>>>>> >>>>>>>>>>>>>> ======================================================================== >>>>>>>>>>>>>> >>>>>>>>>>>>>> I see that you've added guarded includes in the middle of >>>>>>>>>>>>>> the include list: >>>>>>>>>>>>>> ?? #include "gc/shared/strongRootsScope.hpp" >>>>>>>>>>>>>> ?? #include "gc/shared/weakProcessor.hpp" >>>>>>>>>>>>>> + #if INCLUDE_JVMCI >>>>>>>>>>>>>> + #include "jvmci/jvmci.hpp" >>>>>>>>>>>>>> + #endif >>>>>>>>>>>>>> ?? #include "oops/instanceRefKlass.hpp" >>>>>>>>>>>>>> ?? #include "oops/oop.inline.hpp" >>>>>>>>>>>>>> >>>>>>>>>>>>>> The style we use is to put these conditional includes at >>>>>>>>>>>>>> the end of the include lists. >>>>>>>>>>>>> >>>>>>>>>>>>> okay >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ======================================================================== >>>>>>>>>>>>>> >>>>>>>>>>>>>> Could you also change the following: >>>>>>>>>>>>>> >>>>>>>>>>>>>> + #if INCLUDE_JVMCI >>>>>>>>>>>>>> +???? // Clean JVMCI metadata handles. >>>>>>>>>>>>>> + JVMCI::do_unloading(is_alive_closure(), purged_class); >>>>>>>>>>>>>> + #endif >>>>>>>>>>>>>> >>>>>>>>>>>>>> to: >>>>>>>>>>>>>> +???? // Clean JVMCI metadata handles. >>>>>>>>>>>>>> + JVMCI_ONLY(JVMCI::do_unloading(is_alive_closure(), >>>>>>>>>>>>>> purged_class);) >>>>>>>>>>>>>> >>>>>>>>>>>>>> to get rid of some of the line noise in the GC files. >>>>>>>>>>>>> >>>>>>>>>>>>> okay >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ======================================================================== >>>>>>>>>>>>>> >>>>>>>>>>>>>> In the future we will need version of JVMCI::do_unloading >>>>>>>>>>>>>> that supports concurrent cleaning for ZGC. >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, we need to support concurrent cleaning in a future. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ======================================================================== >>>>>>>>>>>>>> >>>>>>>>>>>>>> What's the performance impact for G1 remark pause with >>>>>>>>>>>>>> this serial walk over the MetadataHandleBlock? >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3275 void >>>>>>>>>>>>>> G1CollectedHeap::complete_cleaning(BoolObjectClosure* >>>>>>>>>>>>>> is_alive, >>>>>>>>>>>>>> 3276 bool class_unloading_occurred) { >>>>>>>>>>>>>> 3277?? uint num_workers = workers()->active_workers(); >>>>>>>>>>>>>> 3278?? ParallelCleaningTask unlink_task(is_alive, >>>>>>>>>>>>>> num_workers, class_unloading_occurred, false); >>>>>>>>>>>>>> 3279 workers()->run_task(&unlink_task); >>>>>>>>>>>>>> 3280 #if INCLUDE_JVMCI >>>>>>>>>>>>>> 3281?? // No parallel processing of JVMCI metadata >>>>>>>>>>>>>> handles for now. >>>>>>>>>>>>>> 3282?? JVMCI::do_unloading(is_alive, >>>>>>>>>>>>>> class_unloading_occurred); >>>>>>>>>>>>>> 3283 #endif >>>>>>>>>>>>>> 3284 } >>>>>>>>>>>>> >>>>>>>>>>>>> There should not be impact if Graal is not used. Only cost >>>>>>>>>>>>> of call (which most likely is inlined in product VM) and >>>>>>>>>>>>> check: >>>>>>>>>>>>> >>>>>>>>>>>>> http://hg.openjdk.java.net/metropolis/dev/file/530fc1427d02/src/hotspot/share/jvmci/jvmciRuntime.cpp#l1237 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> If Graal is used it should not have big impact since these >>>>>>>>>>>>> metadata has regular pattern (32 handles per array and >>>>>>>>>>>>> array per MetadataHandleBlock block which are linked in >>>>>>>>>>>>> list) and not large. >>>>>>>>>>>>> If there will be noticeable impact - we will work on it as >>>>>>>>>>>>> you suggested by using ParallelCleaningTask. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ======================================================================== >>>>>>>>>>>>>> >>>>>>>>>>>>>> Did you consider adding it as a task for one of the >>>>>>>>>>>>>> worker threads to execute in ParallelCleaningTask? >>>>>>>>>>>>>> >>>>>>>>>>>>>> See how other tasks are claimed by one worker: >>>>>>>>>>>>>> void KlassCleaningTask::work() { >>>>>>>>>>>>>> ?? ResourceMark rm; >>>>>>>>>>>>>> >>>>>>>>>>>>>> ?? // One worker will clean the subklass/sibling klass tree. >>>>>>>>>>>>>> ?? if (claim_clean_klass_tree_task()) { >>>>>>>>>>>>>> ???? Klass::clean_subklass_tree(); >>>>>>>>>>>>>> ?? } >>>>>>>>>>>>> >>>>>>>>>>>>> These changes were ported from JDK8u based changes in >>>>>>>>>>>>> graal-jvmci-8 and there are no ParallelCleaningTask in JDK8. >>>>>>>>>>>>> >>>>>>>>>>>>> Your suggestion is interesting and I agree that we should >>>>>>>>>>>>> investigate it. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ======================================================================== >>>>>>>>>>>>>> >>>>>>>>>>>>>> In MetadataHandleBlock::do_unloading: >>>>>>>>>>>>>> >>>>>>>>>>>>>> +??????? if (klass->class_loader_data()->is_unloading()) { >>>>>>>>>>>>>> +????????? // This needs to be marked so that it's no >>>>>>>>>>>>>> longer scanned >>>>>>>>>>>>>> +????????? // but can't be put on the free list yet. The >>>>>>>>>>>>>> +????????? // ReferenceCleaner will set this to NULL and >>>>>>>>>>>>>> +????????? // put it on the free list. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I couldn't find the ReferenceCleaner in the patch or in >>>>>>>>>>>>>> the source. Where can I find this code? >>>>>>>>>>>>> >>>>>>>>>>>>> I think it is typo (I will fix it) - it references new >>>>>>>>>>>>> HandleCleaner class: >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HandleCleaner.java.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Vladimir >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> StefanK >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2019-03-28 20:15, Vladimir Kozlov wrote: >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8220623 >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Update JVMCI to support pre-compiled as shared library >>>>>>>>>>>>>>> Graal. >>>>>>>>>>>>>>> Using aoted Graal can offers benefits including: >>>>>>>>>>>>>>> ?- fast startup >>>>>>>>>>>>>>> ?- compile time similar to native JIt compilers (C2) >>>>>>>>>>>>>>> ?- memory usage disjoint from the application Java heap >>>>>>>>>>>>>>> ?- no profile pollution of JDK code used by the application >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is JDK13 port of JVMCI changes done in >>>>>>>>>>>>>>> graal-jvmci-8 [1] up to date. >>>>>>>>>>>>>>> Changes were collected in Metropolis repo [2] and tested >>>>>>>>>>>>>>> there. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Changes we reviewed by Oracle Labs (authors of JVMCI and >>>>>>>>>>>>>>> Graal) and our compiler group. >>>>>>>>>>>>>>> Changes in shared code are guarded by #if INCLUDE_JVMCI >>>>>>>>>>>>>>> and JVMCI flags. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I ran tier1-tier8 (which includes HotSpot and JDK tests) >>>>>>>>>>>>>>> and it was clean. In this set Graal was tested only in >>>>>>>>>>>>>>> tier3. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> And I ran all hs-tier3-graal .. hs-tier8-graal Graal >>>>>>>>>>>>>>> tests available in our system. Several issue were found >>>>>>>>>>>>>>> which were present before these changes. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>> https://github.com/graalvm/graal-jvmci-8/commit/49ff2045fb603e35516a3a427d8023c00e1607af >>>>>>>>>>>>>>> [2] http://hg.openjdk.java.net/metropolis/dev/ >>>>>>>>>>>>>> >>>> >>> From vladimir.kozlov at oracle.com Tue Apr 30 21:37:22 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 30 Apr 2019 14:37:22 -0700 Subject: [13] RFR(L) 8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library In-Reply-To: References: <4b759550-f185-724f-7139-9bab648a1966@oracle.com> <119335f1-acb7-fffc-f38a-e50a96b73b3c@oracle.com> <2d206374-cfeb-9b1b-2838-e4e0a774e89d@oracle.com> <8063fb37-f1b0-8b93-bbe8-4dbeeaa54959@oracle.com> <17233985-18c7-305e-5556-fe2b38926b71@oracle.com> <3514c74d-5f6a-61cc-ebea-b9564df61673@oracle.com> <63b8e1d2-3516-88f5-02ac-828dd15baf83@oracle.com> <39774cdd-de9e-c878-4a5a-f6595a93859f@oracle.com> Message-ID: <9605842f-416b-4ed9-7098-0b390b3d6a56@oracle.com> Thank you, Coleen, for reviews of these huge changes. Best regards, Vladimir K On 4/30/19 2:28 PM, coleen.phillimore at oracle.com wrote: > > This looks good to me.? Thank you for addressing my comments. > Coleen > > On 4/26/19 6:46 PM, Vladimir Kozlov wrote: >> Hi >> >> I have 2 new deltas for easy review. >> >> Delta 1 is mostly JVMCI HotSpot refactoring and cleanup: >> http://cr.openjdk.java.net/~kvn/8220623/webrev_delta1.07/ >> >> - Cleanup #include jvmci files. >> - Removed BoolObjectClosure parameter from JVMCI::do_unloading() since it is not used. In JDK 13 this parameter is >> removed from other places too. >> - Added mtJVMCI type to track memory used by JVMCI. >> - Passed Handles as constant references. >> - Moved JNIAccessMark, JVMCIObject, MetadataHandleBlock class to separate new files. >> - Moved JVMCI methods bodies from jvmciRuntime.cpp into new jvmci.cpp file. >> - Moved bodies of some JVMCIEnv methods from .hpp into jvmciEnv.cpp file. They use JNIAccessMark and >> ThreadToNativeFromVM and I can't use them in header file because they require #include inline.hpp files. >> - Moved bodies of some HotSpotJVMCI methods into jvmciJavaClasses.cpp file because, again, they need >> jniHandles.inline.hpp. >> - Moved JVMCICompileState class definition to the beginning of jvmciEnv.hpp file. >> >> Delta 2: >> http://cr.openjdk.java.net/~kvn/8220623/webrev_delta2.07/ >> >> - Changed MetadataHandleBlock fields which are used only by one instance to static. >> - Renamed field _jmetadata::_handle to _value and corresponding access methods because it was confusing: >> handle->handle(). >> - Switched from JNIHandleBlock to OopStorage use for _object_handles. >> - Additional JVMCI Java side fix for libgraal. >> >> Full: >> http://cr.openjdk.java.net/~kvn/8220623/webrev.07/ >> >> I think I addressed all comments I received so far. >> >> Thanks, >> Vladimir >> >> On 4/9/19 7:25 PM, Vladimir Kozlov wrote: >>> Thank you, Coleen >>> >>> On 4/9/19 1:36 PM, coleen.phillimore at oracle.com wrote: >>>> >>>> I think I missed graal-dev with this reply.? I have a few other comments. >>>> >>>> +void MetadataHandleBlock::do_unloading(BoolObjectClosure* is_alive) { >>>> >>>> >>>> We've removed the is_alive parameter from all do_unloading, and it appears unused here also. >>> >>> Yes, I can remove it. >>> >>>> >>>> I don't know about this MetadataHandles block.?? It seems that it could be a concurrent hashtable with a >>>> WeakHandle<> if it's for jdk11 and beyond.? Kim might have mentioned this (I haven't read all the replies >>>> thoroughly) but JNIHandleBlock wasn't MT safe, and the new OopStorage is safe and scalable. >>> >>> Yes, Kim also suggested OopStorage. I did not get into that part yet but I will definitely do. >>> >>>> >>>> +? jmetadata allocate_handle(methodHandle handle)?????? { return allocate_metadata_handle(handle()); } >>>> +? jmetadata allocate_handle(constantPoolHandle handle) { return allocate_metadata_handle(handle()); } >>>> >>>> +CompLevel JVMCI::adjust_comp_level(methodHandle method, bool is_osr, CompLevel level, JavaThread* thread) { >>>> >>>> +JVMCIObject JVMCIEnv::new_StackTraceElement(methodHandle method, int bci, JVMCI_TRAPS) { >>>> >>>> +JVMCIObject JVMCIEnv::new_HotSpotNmethod(methodHandle method, const char* name, jboolean isDefault, jlong >>>> compileId, JVMCI_TRAPS) { >>>> >>>> Passing metadata Handles by copy will call the copy constructor and destructor for these parameters unnecessarily. >>>> They should be passed as *const* references to avoid this. >>> >>> Okay. >>> >>>> >>>> +class MetadataHandleBlock : public CHeapObj { >>>> >>>> >>>> There should be a better mt? for this.? mtCompiler seems appropriate here.? Depending on how many others of these, >>>> you could add an mtJVMCI. >>> >>> mtJVMCI is good suggestion. >>> >>>> >>>> +??????????? if (TraceNMethodInstalls) { >>>> >>>> >>>> We've had Unified Logging in the sources for a long time now. New code should use UL rather than adding a >>>> TraceSomething option.?? I understand it's supposed to be shared with JDK8 code but it seems that you're forward >>>> porting what looks like old code into the repository. >>> >>> Yes, we should use UL for this. >>> >>> Existing JIT code (ciEnv.cpp) still not using UL for this: >>> http://hg.openjdk.java.net/jdk/jdk/file/f847a42ddc01/src/hotspot/share/ci/ciEnv.cpp#l1075 >>> >>> May be I should update it too ... >>> >>>> >>>> Coleen >>>> >>>> >>>> On 4/9/19 4:00 PM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.06/src/hotspot/share/classfile/classFileParser.cpp.udiff.html >>>>> >>>>> It appears this change is to implement https://bugs.openjdk.java.net/browse/JDK-8193513 which we closed as WNF.? If >>>>> you want this change, remove it from this giant patch and reopen and submit a separate patch for this bug. >>> >>> Thank you for pointing it. I will do as you suggested. >>> >>>>> >>>>> It shouldn't be conditional on JVMCI and should use the normal unified logging mechanism. >>> >>> Okay. >>> >>>>> >>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.06/src/hotspot/share/runtime/thread.hpp.udiff.html >>>>> >>>>> *!_jlong__pending_failed_speculation;* >>>>> >>>>> >>>>> We've been trying to remove and avoid java types in hotspot code and use the appropriate C++ types instead.? Can >>>>> this be changed to int64_t?? 'long' is generally wrong though. >>> >>> This field should be java type since it is accessed from Java Graal: >>> >>> http://hg.openjdk.java.net/jdk/jdk/file/f847a42ddc01/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java#l401 >>> >>> >>>>> >>>>> I seem to remember there was code to deal with metadata in oops for redefinition, but I can't find it in this big >>>>> patch.? I was going to look at that. >>> >>> May be it is MetadataHandleBlock::metadata_do() (in jvmciRuntime.cpp)? >>> >>>>> >>>>> Otherwise, I've reviewed the runtime code. >>> >>> Thanks, >>> Vladimir >>> >>>>> >>>>> Coleen >>>>> >>>>> On 4/4/19 3:22 AM, Vladimir Kozlov wrote: >>>>>> New delta: >>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.06/ >>>>>> >>>>>> Full: >>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.06/ >>>>>> >>>>>> New changes are based on Kim and Stefan suggestions: >>>>>> >>>>>> - Moved JVMCI::oops_do() from JNIHandles to places where it should be called. >>>>>> - Moved JVMCI cleanup task to the beginning of ParallelCleaningTask::work(). >>>>>> - Used JVMCI_ONLY macro with COMMA. >>>>>> - Disable JVMCI build on SPARC. We don't use it - neither Graal or AOT are built on SPARC. Disabling also helps to >>>>>> find missing JVMCI guards. >>>>>> >>>>>> I ran hs-tier1-3 testing - it passed (hs-tier3 includes graal testing). >>>>>> I started hs-tier4..8-graal testing. >>>>>> I will do performance testing next. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 4/3/19 9:54 AM, Vladimir Kozlov wrote: >>>>>>> On 4/2/19 11:35 PM, Stefan Karlsson wrote: >>>>>>>> On 2019-04-02 22:41, Vladimir Kozlov wrote: >>>>>>>>> I ran Kitchensink with G1 and -Xmx8g. I observed that Remark pause times are not consistent even without Graal. >>>>>>>>> To see effect I added time spent in JVMCI::do_unloading() to GC log (see below [3]). The result is < 1ms - it >>>>>>>>> is less than 1% of a pause time. >>>>>>>> >>>>>>>> Kitchensink isn't really a benchmark, but a stress test. I sent you a private mail how to run these changes >>>>>>>> through our internal performance test setup. >>>>>>> >>>>>>> Okay, I will run performance tests there too. >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> It will have even less effect since I moved JVMCI::do_unloading() from serial path to parallel worker thread as >>>>>>>>> Stefan suggested. >>>>>>>>> >>>>>>>>> Stefan, are you satisfied with these changes now? >>>>>>>> >>>>>>>> Yes, the clean-ups look good. Thanks for cleaning this up. >>>>>>>> >>>>>>>> Kim had some extra comments about a few more places where JVMCI_ONLY could be used. >>>>>>>> >>>>>>>> I also agree with him that JVMCI::oops_do should not be placed in JNIHandles::oops_do. I think you should put it >>>>>>>> where you put the AOTLoader::oops_do calls. >>>>>>> >>>>>>> Okay. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> StefanK >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Here is latest delta update which includes previous [1] delta and >>>>>>>>> - use CompilerThreadStackSize * 2 for libgraal instead of exact value, >>>>>>>>> - removed HandleMark added for debugging (reverted changes in jvmtiImpl.cpp), >>>>>>>>> - added recent jvmci-8 changes to fix registration of native methods in libgraal (jvmciCompilerToVM.cpp) >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.05/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> [1] http://cr.openjdk.java.net/~kvn/8220623/webrev_delta.04/ >>>>>>>>> [2] Original webrev http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ >>>>>>>>> [3] Pauses times from Kitchensink (0.0ms means there were no unloaded classes, 'NNN alive' shows how many >>>>>>>>> metadata references were processed): >>>>>>>>> >>>>>>>>> [1.083s][1554229160638ms][info ][gc,start???? ] GC(2) Pause Remark >>>>>>>>> [1.085s][1554229160639ms][info ][gc?????????? ] GC(2) JVMCI::do_unloading(): 0 alive 0.000ms >>>>>>>>> [1.099s][1554229160654ms][info ][gc?????????? ] GC(2) Pause Remark 28M->28M(108M) 16.123ms >>>>>>>>> >>>>>>>>> [3.097s][1554229162651ms][info ][gc,start???? ] GC(12) Pause Remark >>>>>>>>> [3.114s][1554229162668ms][info ][gc?????????? ] GC(12) JVMCI::do_unloading(): 3471 alive 0.164ms >>>>>>>>> [3.148s][1554229162702ms][info ][gc?????????? ] GC(12) Pause Remark 215M->213M(720M) 51.103ms >>>>>>>>> >>>>>>>>> [455.111s][1554229614666ms][info ][gc,phases,start] GC(1095) Phase 1: Mark live objects >>>>>>>>> [455.455s][1554229615010ms][info ][gc???????????? ] GC(1095) JVMCI::do_unloading(): 4048 alive 0.821ms >>>>>>>>> [455.456s][1554229615010ms][info ][gc,phases????? ] GC(1095) Phase 1: Mark live objects 344.107ms >>>>>>>>> >>>>>>>>> [848.932s][1554230008486ms][info ][gc,phases,start] GC(1860) Phase 1: Mark live objects >>>>>>>>> [849.248s][1554230008803ms][info ][gc???????????? ] GC(1860) JVMCI::do_unloading(): 3266 alive 0.470ms >>>>>>>>> [849.249s][1554230008803ms][info ][gc,phases????? ] GC(1860) Phase 1: Mark live objects 316.527ms >>>>>>>>> >>>>>>>>> [1163.778s][1554230323332ms][info ][gc,start?????? ] GC(2627) Pause Remark >>>>>>>>> [1163.932s][1554230323486ms][info ][gc???????????? ] GC(2627) JVMCI::do_unloading(): 3474 alive 0.642ms >>>>>>>>> [1163.941s][1554230323496ms][info ][gc???????????? ] GC(2627) Pause Remark 2502M->2486M(4248M) 163.296ms >>>>>>>>> >>>>>>>>> [1242.587s][1554230402141ms][info ][gc,phases,start] GC(2734) Phase 1: Mark live objects >>>>>>>>> [1242.899s][1554230402453ms][info ][gc???????????? ] GC(2734) JVMCI::do_unloading(): 3449 alive 0.570ms >>>>>>>>> [1242.899s][1554230402453ms][info ][gc,phases????? ] GC(2734) Phase 1: Mark live objects 311.719ms >>>>>>>>> >>>>>>>>> [1364.164s][1554230523718ms][info ][gc,phases,start] GC(3023) Phase 1: Mark live objects >>>>>>>>> [1364.613s][1554230524167ms][info ][gc???????????? ] GC(3023) JVMCI::do_unloading(): 3449 alive 0.000ms >>>>>>>>> [1364.613s][1554230524167ms][info ][gc,phases????? ] GC(3023) Phase 1: Mark live objects 448.495ms >>>>>>>>> >>>>>>>>> [1425.222s][1554230584776ms][info ][gc,phases,start] GC(3151) Phase 1: Mark live objects >>>>>>>>> [1425.587s][1554230585142ms][info ][gc???????????? ] GC(3151) JVMCI::do_unloading(): 3491 alive 0.882ms >>>>>>>>> [1425.587s][1554230585142ms][info ][gc,phases????? ] GC(3151) Phase 1: Mark live objects 365.403ms >>>>>>>>> >>>>>>>>> [1456.401s][1554230615955ms][info ][gc,phases,start] GC(3223) Phase 1: Mark live objects >>>>>>>>> [1456.769s][1554230616324ms][info ][gc???????????? ] GC(3223) JVMCI::do_unloading(): 3478 alive 0.616ms >>>>>>>>> [1456.769s][1554230616324ms][info ][gc,phases????? ] GC(3223) Phase 1: Mark live objects 368.643ms >>>>>>>>> >>>>>>>>> [1806.139s][1554230965694ms][info?? ][gc,start ] GC(4014) Pause Remark >>>>>>>>> [1806.161s][1554230965716ms][info?? ][gc ] GC(4014) JVMCI::do_unloading(): 3478 alive 0.000ms >>>>>>>>> [1806.163s][1554230965717ms][info?? ][gc ] GC(4014) Pause Remark 1305M->1177M(2772M) 23.190ms >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 4/1/19 12:34 AM, Stefan Karlsson wrote: >>>>>>>>>> On 2019-03-29 17:55, Vladimir Kozlov wrote: >>>>>>>>>>> Stefan, >>>>>>>>>>> >>>>>>>>>>> Do you have a test (and flags) which can allow me to measure effect of this code on G1 remark pause? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Xlog:gc prints the remark times: >>>>>>>>>> [4,296s][info][gc?????? ] GC(89) Pause Remark 4M->4M(28M) 36,412ms >>>>>>>>>> >>>>>>>>>> StefanK >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> On 3/29/19 12:36 AM, Stefan Karlsson wrote: >>>>>>>>>>>> On 2019-03-29 03:07, Vladimir Kozlov wrote: >>>>>>>>>>>>> Hi Stefan, >>>>>>>>>>>>> >>>>>>>>>>>>> I collected some data on MetadataHandleBlock. >>>>>>>>>>>>> >>>>>>>>>>>>> First, do_unloading() code is executed only when class_unloading_occurred is 'true' - it is rare case. It >>>>>>>>>>>>> should not affect normal G1 remark pause. >>>>>>>>>>>> >>>>>>>>>>>> It's only rare for applications that don't do dynamic class loading and unloading. The applications that do, >>>>>>>>>>>> will be affected. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Second, I run a test with -Xcomp. I got about 10,000 compilations by Graal and next data at the end of >>>>>>>>>>>>> execution: >>>>>>>>>>>>> >>>>>>>>>>>>> max_blocks = 232 >>>>>>>>>>>>> max_handles_per_block = 32 (since handles array has 32 elements) >>>>>>>>>>>>> max_total_alive_values = 4631 >>>>>>>>>>>> >>>>>>>>>>>> OK. Thanks for the info. >>>>>>>>>>>> >>>>>>>>>>>> StefanK >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Vladimir >>>>>>>>>>>>> >>>>>>>>>>>>> On 3/28/19 2:44 PM, Vladimir Kozlov wrote: >>>>>>>>>>>>>> Thank you, Stefan >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 3/28/19 12:54 PM, Stefan Karlsson wrote: >>>>>>>>>>>>>>> Hi Vladimir, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I started to check the GC code. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ======================================================================== >>>>>>>>>>>>>>> I see that you've added guarded includes in the middle of the include list: >>>>>>>>>>>>>>> ?? #include "gc/shared/strongRootsScope.hpp" >>>>>>>>>>>>>>> ?? #include "gc/shared/weakProcessor.hpp" >>>>>>>>>>>>>>> + #if INCLUDE_JVMCI >>>>>>>>>>>>>>> + #include "jvmci/jvmci.hpp" >>>>>>>>>>>>>>> + #endif >>>>>>>>>>>>>>> ?? #include "oops/instanceRefKlass.hpp" >>>>>>>>>>>>>>> ?? #include "oops/oop.inline.hpp" >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The style we use is to put these conditional includes at the end of the include lists. >>>>>>>>>>>>>> >>>>>>>>>>>>>> okay >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ======================================================================== >>>>>>>>>>>>>>> Could you also change the following: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> + #if INCLUDE_JVMCI >>>>>>>>>>>>>>> +???? // Clean JVMCI metadata handles. >>>>>>>>>>>>>>> + JVMCI::do_unloading(is_alive_closure(), purged_class); >>>>>>>>>>>>>>> + #endif >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> to: >>>>>>>>>>>>>>> +???? // Clean JVMCI metadata handles. >>>>>>>>>>>>>>> + JVMCI_ONLY(JVMCI::do_unloading(is_alive_closure(), purged_class);) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> to get rid of some of the line noise in the GC files. >>>>>>>>>>>>>> >>>>>>>>>>>>>> okay >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ======================================================================== >>>>>>>>>>>>>>> In the future we will need version of JVMCI::do_unloading that supports concurrent cleaning for ZGC. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes, we need to support concurrent cleaning in a future. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ======================================================================== >>>>>>>>>>>>>>> What's the performance impact for G1 remark pause with this serial walk over the MetadataHandleBlock? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 3275 void G1CollectedHeap::complete_cleaning(BoolObjectClosure* is_alive, >>>>>>>>>>>>>>> 3276 bool class_unloading_occurred) { >>>>>>>>>>>>>>> 3277?? uint num_workers = workers()->active_workers(); >>>>>>>>>>>>>>> 3278?? ParallelCleaningTask unlink_task(is_alive, num_workers, class_unloading_occurred, false); >>>>>>>>>>>>>>> 3279 workers()->run_task(&unlink_task); >>>>>>>>>>>>>>> 3280 #if INCLUDE_JVMCI >>>>>>>>>>>>>>> 3281?? // No parallel processing of JVMCI metadata handles for now. >>>>>>>>>>>>>>> 3282?? JVMCI::do_unloading(is_alive, class_unloading_occurred); >>>>>>>>>>>>>>> 3283 #endif >>>>>>>>>>>>>>> 3284 } >>>>>>>>>>>>>> >>>>>>>>>>>>>> There should not be impact if Graal is not used. Only cost of call (which most likely is inlined in >>>>>>>>>>>>>> product VM) and check: >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://hg.openjdk.java.net/metropolis/dev/file/530fc1427d02/src/hotspot/share/jvmci/jvmciRuntime.cpp#l1237 >>>>>>>>>>>>>> >>>>>>>>>>>>>> If Graal is used it should not have big impact since these metadata has regular pattern (32 handles per >>>>>>>>>>>>>> array and array per MetadataHandleBlock block which are linked in list) and not large. >>>>>>>>>>>>>> If there will be noticeable impact - we will work on it as you suggested by using ParallelCleaningTask. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ======================================================================== >>>>>>>>>>>>>>> Did you consider adding it as a task for one of the worker threads to execute in ParallelCleaningTask? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> See how other tasks are claimed by one worker: >>>>>>>>>>>>>>> void KlassCleaningTask::work() { >>>>>>>>>>>>>>> ?? ResourceMark rm; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ?? // One worker will clean the subklass/sibling klass tree. >>>>>>>>>>>>>>> ?? if (claim_clean_klass_tree_task()) { >>>>>>>>>>>>>>> ???? Klass::clean_subklass_tree(); >>>>>>>>>>>>>>> ?? } >>>>>>>>>>>>>> >>>>>>>>>>>>>> These changes were ported from JDK8u based changes in graal-jvmci-8 and there are no ParallelCleaningTask >>>>>>>>>>>>>> in JDK8. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Your suggestion is interesting and I agree that we should investigate it. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ======================================================================== >>>>>>>>>>>>>>> In MetadataHandleBlock::do_unloading: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> +??????? if (klass->class_loader_data()->is_unloading()) { >>>>>>>>>>>>>>> +????????? // This needs to be marked so that it's no longer scanned >>>>>>>>>>>>>>> +????????? // but can't be put on the free list yet. The >>>>>>>>>>>>>>> +????????? // ReferenceCleaner will set this to NULL and >>>>>>>>>>>>>>> +????????? // put it on the free list. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I couldn't find the ReferenceCleaner in the patch or in the source. Where can I find this code? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think it is typo (I will fix it) - it references new HandleCleaner class: >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HandleCleaner.java.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> StefanK >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2019-03-28 20:15, Vladimir Kozlov wrote: >>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8220623 >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~kvn/8220623/webrev.03/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Update JVMCI to support pre-compiled as shared library Graal. >>>>>>>>>>>>>>>> Using aoted Graal can offers benefits including: >>>>>>>>>>>>>>>> ?- fast startup >>>>>>>>>>>>>>>> ?- compile time similar to native JIt compilers (C2) >>>>>>>>>>>>>>>> ?- memory usage disjoint from the application Java heap >>>>>>>>>>>>>>>> ?- no profile pollution of JDK code used by the application >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This is JDK13 port of JVMCI changes done in graal-jvmci-8 [1] up to date. >>>>>>>>>>>>>>>> Changes were collected in Metropolis repo [2] and tested there. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Changes we reviewed by Oracle Labs (authors of JVMCI and Graal) and our compiler group. >>>>>>>>>>>>>>>> Changes in shared code are guarded by #if INCLUDE_JVMCI and JVMCI flags. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I ran tier1-tier8 (which includes HotSpot and JDK tests) and it was clean. In this set Graal was tested >>>>>>>>>>>>>>>> only in tier3. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> And I ran all hs-tier3-graal .. hs-tier8-graal Graal tests available in our system. Several issue were >>>>>>>>>>>>>>>> found which were present before these changes. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [1] https://github.com/graalvm/graal-jvmci-8/commit/49ff2045fb603e35516a3a427d8023c00e1607af >>>>>>>>>>>>>>>> [2] http://hg.openjdk.java.net/metropolis/dev/ >>>>>>>>>>>>>>> >>>>> >>>> > From coleen.phillimore at oracle.com Tue Apr 30 21:59:41 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 30 Apr 2019 17:59:41 -0400 Subject: RFR (S): 8222534: VerifyBeforeExit is not honored when System.exit is called In-Reply-To: <94327eae-0553-a346-bc4f-e0ff8ffa7ce5@oracle.com> References: <94327eae-0553-a346-bc4f-e0ff8ffa7ce5@oracle.com> Message-ID: <3bf1af77-83d3-04b4-20b5-6950de1d5e5c@oracle.com> 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. 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