From kim.barrett at oracle.com Thu Oct 1 01:19:59 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 30 Sep 2015 21:19:59 -0400 Subject: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface In-Reply-To: <97150580-7329-438F-9B64-F47E3BFE9F08@oracle.com> References: <2B401EAC-B386-4E42-BC4C-DD267FFD4970@oracle.com> <55F9671C.4000208@oracle.com> <99042B61-9F43-42CE-835C-095CD2858CB1@oracle.com> <55F9F08E.8010506@oracle.com> <08A9DB82-58D0-41F8-97F5-23AD78205263@oracle.com>

<067C7DA1-7422-411E-A678-91FBDECEBE1D@oracle.com> <8E92D69B-7207-4CDC-80F7-3AA65AC5C482@oracle.com> <97150580-7329-438F-9B64-F47E3BFE9F08@oracle.com> Message-ID: <0B9B6287-20E1-4F60-A03F-E046920BB1BB@oracle.com> >> Here are new webrevs against hs-comp: >> >> http://cr.openjdk.java.net/~twisti/8136421/webrev/ >> http://cr.openjdk.java.net/~twisti/8136421/hotspot/webrev/ > > I have refreshed these webrevs. They contain all the changes we discussed here plus a bunch of new tests that SQE finished. ------------------------------------------------------------------------------ src/share/vm/gc/g1/g1SATBCardTableModRefBS.cpp 260 class G1EnsureLastRefToRegion : public OopClosure { ... 270 void do_oop(oop* p) { There's no way to terminate the iteration early when a match is found, so it always visits every oop in the nmethod. The early test of the result short circuits most of the work, but it would be better still if we didn't need to continue the iteration at all. This suggests there's a missing API in nmethod for iterating with early termination. This should be deferred to a followup RFE. ------------------------------------------------------------------------------ src/share/vm/gc/shared/cardTableRS.cpp Changes in CardTableRS::verify_space function. These don't appear to be specifically related to JVMCI. I'm not sure whether this is someone's debugging code that was left in, or if it might be viewed as an improvement. Either way, I'd prefer that it be a separate change that gets reviewed by folks interested in GC changes, rather than being buried in the JVMCI change set. Also, I think the cast to HeapWord* is unnecessary here: 352 p2i((HeapWord*)obj), p2i(jp), p2i(_boundary)); The implicit conversion to void* by p2i should be sufficient. ------------------------------------------------------------------------------ src/share/vm/utilities/growableArray.hpp 382 template E insert_sorted(E& key) { 392 template int find_sorted(K& key, bool& found) { The parameters (except "found") and the find_sorted function should be const, e.g. template E insert_sorted(const E& key) { template int find_sorted(const K& key, bool& found) const { ------------------------------------------------------------------------------ src/share/vm/utilities/growableArray.hpp 382 template E insert_sorted(E& key) { 392 template int find_sorted(K& key, bool& found) { Having the compare function be specified via a function type (e.g. a non-type template parameter) rather than an argument seems rather limiting. More general, and (IMO) easier to use, would be a type template parameter deduced from an argument, e.g. template E insert_sorted(const E& key, Compare compare) { ... int location = find_sorted(key, found, compare); ... } template int find_sorted(const K& key, bool& found, Compare compare) const { ... } Let - ga is a GrowableArray - my_value is an instance f T - my_compare is a function of type int (*)(const T&, const T&) Old usage: ga.insert_sorted(my_value); ga.find_sorted(my_value, found); New usage: ga.insert_sorted(my_value, my_compare); ga.find_sorted(my_value, found, my_compare); and new usage also allows the use of function objects, not just pointers to functions. This can be deferred to a followup RFE. ------------------------------------------------------------------------------ src/share/vm/utilities/growableArray.hpp 386 assert(location <= length(), "out of range"); 387 insert_before(location, key); The assertion here is redundant with the better assertion in insert_before. ------------------------------------------------------------------------------ From bengt.rutisson at oracle.com Thu Oct 1 05:47:55 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 1 Oct 2015 07:47:55 +0200 Subject: RFR: JDK-8134953: Make the GC ID available in a central place In-Reply-To: <560C1348.6020003@oracle.com> References: <55EEC7F0.1060701@oracle.com> <55EEE152.3030404@oracle.com> <55F01A53.1070905@oracle.com> <55F044DD.4080301@oracle.com> <55F0BA00.5000704@oracle.com> <55F17982.3080606@oracle.com> <56093EC1.9090109@oracle.com> <5609768A.5030209@oracle.com> <560A4723.90604@oracle.com> <560AB551.6010507@oracle.com> <560AB4FC.1050805@oracle.com> <560AB765.9020605@oracle.com> <560B8D41.10107@oracle.com> <560C1348.6020003@oracle.com> Message-ID: <560CC90B.3000305@oracle.com> On 30/09/15 18:52, Jon Masamitsu wrote: > > > On 9/30/2015 12:20 AM, Bengt Rutisson wrote: >> >> >> On 2015-09-29 18:08, Jon Masamitsu wrote: >>> >>> >>> On 9/29/15 8:57 AM, Bengt Rutisson wrote: >>>> >>>> >>>> On 2015-09-29 17:59, Jon Masamitsu wrote: >>>>> >>>>> >>>>> On 9/29/15 1:09 AM, Bengt Rutisson wrote: >>>>>> >>>>>> Hi Jon, >>>>>> >>>>>> On 2015-09-28 19:19, Jon Masamitsu wrote: >>>>>>> >>>>>>> >>>>>>> On 09/28/2015 06:21 AM, Bengt Rutisson wrote: >>>>>>>> >>>>>>>> Hi Jon and Per, >>>>>>>> >>>>>>>> I've been trying to get the version proposed in webrev.02 to >>>>>>>> work but I ran into a show stopper for this approach. The G1 >>>>>>>> concurrent mark thread is at times executing (and logging) at >>>>>>>> the same time as a young or mixed GC is executing. There is no >>>>>>>> good way of handling this with a common place to store the GC >>>>>>>> ID. Instead I've decided to go back to storing the current GC >>>>>>>> ID in the thread. That way the G1 concurrent marking and the >>>>>>>> young/mixed GCs will have their own GC IDs. >>>>>>>> >>>>>>>> Here's an updated webrev: >>>>>>>> http://cr.openjdk.java.net/~brutisso/8134953/webrev.03/ >>>>>>> Bengt, >>>>>>> >>>>>>> The _gc_id is needed in a JavaThread because a JavaThread >>>>>>> might do work for G1 (concurrent refinement for example) and >>>>>>> needs a GC ID? >>>>>> >>>>>> The Java threads currently don't log anything when they do GC >>>>>> work. But in the future it is likely that they will. >>>>>> >>>>>>> But a WatcherThread would never need one, >>>>>>> right? >>>>>> >>>>>> Right. Initially I only added the _gc_id field to NamedThread. >>>>>> But Per thought it would be better to have it in Thread. Both for >>>>>> making it possible for future improvements (such as logging GC >>>>>> work from JavaThreads) and because it seems like we normally keep >>>>>> storage in the Thread class even for things that are not used by >>>>>> all subclasses. For example TLABs and allocated_bytes() are only >>>>>> relevant for JavaThreads but have their storage in Thread. >>>>> >>>>> Yes, Thread could be improved but I'm not sure I can stand adding >>>>> GC data where >>>>> it's not needed. Unless GC logging from JavaThread is something >>>>> that's going to >>>>> happen soon, I'd rather add it when it's needed rather than right >>>>> now. I'd personally >>>>> rather duplicate the code in JavaThread if it is needed rather >>>>> than have WatcherThreads >>>>> have a _gc_id. >>>> >>>> I tend to agree. I'll discuss this with Per tomorrow. If he agrees >>>> that we can move the _gc_id down to NamedThread, are you ok with me >>>> pushing the fix? >>> >>> Yes, I'm good with the fix then. >> >> Thanks Jon! >> >> I talked to Per and moved the _gc_id field down to NamedThread. >> Pushing it now. >> >>> >>> Would it be appropriate for me to file a CR to change NamedThread to >>> something >>> like GCThread? Or ??? >> >> >> I don't think GCThread is the right name since VMThread is a >> NamedThread and it can schedule tasks that are not GC related. I >> agree that NamedThread is not a great name. But I actually think that >> the naming in the Thread hierarchy is just part of the problem. The >> real problem is that the division of responsibility is not really >> correctly partitioned among the classes. >> >> If we should file a RFE I think it should be to clean up the Thread >> hierarchy, including finding good names for the classes. > > That's fine. I created > > https://bugs.openjdk.java.net/browse/JDK-8138655 Thanks, Jon. Good description in the bug. Bengt > > Jon > >> >> Bengt >> >> >>> >>> Jon >>> >>>> >>>> Thanks, >>>> Bengt >>>> >>>>> >>>>> Jon >>>>> >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>>> >>>>>>> >>>>>>> Jon >>>>>>> >>>>>>>> >>>>>>>> This is the same as webrev.01 that both of you already looked >>>>>>>> at. I've made two minor adjustments: >>>>>>>> >>>>>>>> - I removed the currentNamedthread() function in gcId.cpp that >>>>>>>> Per pointed out in his review of webrev.01. Instead I use >>>>>>>> Thread::current() directly. >>>>>>>> >>>>>>>> - I made GCIdMark a StackObj. >>>>>>>> >>>>>>>> Otherwise the patch is the same as in webrev.01. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Bengt >>>>>>>> >>>>>>>> On 2015-09-10 14:37, Bengt Rutisson wrote: >>>>>>>>> >>>>>>>>> Hi Jon, >>>>>>>>> >>>>>>>>> Thanks for looking at this! >>>>>>>>> >>>>>>>>> On 2015-09-10 01:00, Jon Masamitsu wrote: >>>>>>>>>> Bengt, >>>>>>>>>> >>>>>>>>>> When a CMS concurrent collection hands off to a STW >>>>>>>>>> foreground collection, >>>>>>>>>> (done in acquire_control_and_collect()), I expected a new >>>>>>>>>> GCId would be >>>>>>>>>> used. Did I miss it? That STW collection does not go >>>>>>>>>> through do_collection(). >>>>>>>>> >>>>>>>>> The call to acquire_control_and_collect() originates from >>>>>>>>> GenCollectedHeap::collect_generation() and there is a new >>>>>>>>> GCIdMark in there that will create a new GCId for the STW >>>>>>>>> collection. That's the "extra" GCIdMark that Per asked about >>>>>>>>> in his review. >>>>>>>>> >>>>>>>>> *But* I wanted to verify that it worked properly since you >>>>>>>>> asked about it and I realized that there is another bug. >>>>>>>>> >>>>>>>>> The GCId that is set up for the concurrent cycle, the one set >>>>>>>>> up in ConcurrentMarkSweepThread::run(), will is still active >>>>>>>>> over the complete STW foreground collection. That's fine in my >>>>>>>>> model since the new GCIdMark in >>>>>>>>> GenCollectedHeap::collect_generation() will cache that GCId. >>>>>>>>> But the ConcurrentMarkSweep thread is not completely idle even >>>>>>>>> though control has been left to the foreground collection in >>>>>>>>> acquire_control_and_collect(). So, there is some logging done >>>>>>>>> (by fore example CMSPhaseAccounting) that is done at the same >>>>>>>>> time as the foreground collection. This logging will now use >>>>>>>>> the foreground GCId instead of the CMS GCId. >>>>>>>>> >>>>>>>>> I haven't had time to dig in to the details of that just yet. >>>>>>>>> But this is an unintended change of the logging, so I would >>>>>>>>> like to fix it. Hopefully I'll have an updated webrev tomorrow. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Bengt >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Jon >>>>>>>>>> >>>>>>>>>> On 9/9/2015 7:40 AM, Bengt Rutisson wrote: >>>>>>>>>>> >>>>>>>>>>> Hi again, >>>>>>>>>>> >>>>>>>>>>> I found an issue with how G1 young collections kick off >>>>>>>>>>> concurrent marks. There is a short window where we might >>>>>>>>>>> have two active GC IDs at the same time. I've fixed this and >>>>>>>>>>> updated the webrevs. In case anyone had already started >>>>>>>>>>> looking at the webrevs you need to do a refresh now. The fix >>>>>>>>>>> is in G1CollectedHeap::do_collection_pause_at_safepoint(). >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Bengt >>>>>>>>>>> >>>>>>>>>>> On 09/09/15 13:38, Bengt Rutisson wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Per, >>>>>>>>>>>> >>>>>>>>>>>> Thanks for looking at this! >>>>>>>>>>>> >>>>>>>>>>>> On 2015-09-08 15:23, Per Liden wrote: >>>>>>>>>>>>> Hi Bengt, >>>>>>>>>>>>> >>>>>>>>>>>>> On 2015-09-08 13:35, Bengt Rutisson wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi everyone, >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is mostly a GC related patch, but it adds a field to >>>>>>>>>>>>>> the Thread >>>>>>>>>>>>>> class, so I'm sending this out on the broader hotspot-dev >>>>>>>>>>>>>> list. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Could I have a couple of reviews for this patch? >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/8134953/webrev.01/ >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8134953 >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Looks good. I think this is a nice simplification, >>>>>>>>>>>>> especially for G1's concurrent parts. Just two comments: >>>>>>>>>>>>> >>>>>>>>>>>>> genCollectedHeap.cpp: >>>>>>>>>>>>> --------------------- >>>>>>>>>>>>> - GenCollectedHeap::do_collection() has two GCIdMarks, in >>>>>>>>>>>>> different scopes. Do we really want that second mark? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> We potentially do two GCs in >>>>>>>>>>>> GenCollectedHeap::do_collection(). First a young GC and >>>>>>>>>>>> then potentially a full GC. These two should have different >>>>>>>>>>>> GC IDs. So, yes, we need two GCIdMarks in this method. The >>>>>>>>>>>> scoping could be better, but I think that is a refactoring >>>>>>>>>>>> that should be done separately from my current patch. I'll >>>>>>>>>>>> talk to Jesper about it since he has been cleaning up this >>>>>>>>>>>> code lately. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> gcId.cpp: >>>>>>>>>>>>> -------- >>>>>>>>>>>>> - I think you might have left currentNamedthread() in >>>>>>>>>>>>> there. You probably just want to use Thread::current() >>>>>>>>>>>>> instead. >>>>>>>>>>>> >>>>>>>>>>>> Yes, good catch. Thanks. >>>>>>>>>>>> >>>>>>>>>>>> However, after thinking some more about the implications of >>>>>>>>>>>> moving the GC ID out from the GCTracer I figured it would >>>>>>>>>>>> be possible to just store the previous GC ID in the >>>>>>>>>>>> GCIdMark and then restore it in the destructor of that >>>>>>>>>>>> class. That way we don't have to store anything in the >>>>>>>>>>>> Thread class but can still have both a concurrent GC ID and >>>>>>>>>>>> a STW GC ID active at the same time. This also removes the >>>>>>>>>>>> need to copy the GC ID to the worker tasks. >>>>>>>>>>>> >>>>>>>>>>>> Here's an updated webrev with a solution that does not add >>>>>>>>>>>> anything to the Thread class: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/8134953/webrev.02/ >>>>>>>>>>>> >>>>>>>>>>>> And here's a diff compared to the last version: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/8134953/webrev.01-02.diff/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Unfotunately the webrev tool had some bad luck when >>>>>>>>>>>> creating the diff webrev so at least the >>>>>>>>>>>> g1CollectedHeap.cpp seem to contain the complete changes >>>>>>>>>>>> rather than just the diff compared to the 01 version. The >>>>>>>>>>>> rest of the diff looks correct as far as I can tell. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Bengt >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> cheers, >>>>>>>>>>>>> /Per >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Currently the GC ID, that is used for event tracing and >>>>>>>>>>>>>> logging, is >>>>>>>>>>>>>> stored in the GCTracer object. That has caused some minor >>>>>>>>>>>>>> problems since >>>>>>>>>>>>>> there are multiple GCTracers active at the same time. The >>>>>>>>>>>>>> correct GC IDs >>>>>>>>>>>>>> need to be passed around in many places. >>>>>>>>>>>>>> >>>>>>>>>>>>>> For some upcoming GC logging changes I would like to have >>>>>>>>>>>>>> a more >>>>>>>>>>>>>> consistent way of finding the currently active GC ID. >>>>>>>>>>>>>> I've played around >>>>>>>>>>>>>> with a couple of different solutions, but eventually I >>>>>>>>>>>>>> found that the >>>>>>>>>>>>>> simplest solution is to store the current GC ID in the >>>>>>>>>>>>>> thread. That way >>>>>>>>>>>>>> there is a single way to look it up in all places. It is >>>>>>>>>>>>>> also fairly >>>>>>>>>>>>>> straight forward to set it up. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've reworked the GCId class a bit to support this and >>>>>>>>>>>>>> I've introduced a >>>>>>>>>>>>>> GCIdMark class that is a scoped object that helps to set >>>>>>>>>>>>>> up and tear >>>>>>>>>>>>>> down a current GC ID. By moving the GC ID out from the >>>>>>>>>>>>>> GCTracer class I >>>>>>>>>>>>>> got rid of a few minor issues as well. One is that we no >>>>>>>>>>>>>> longer need to >>>>>>>>>>>>>> keep track of the G1 "aborted concurrent GC ID". That was >>>>>>>>>>>>>> necessary >>>>>>>>>>>>>> before since we did logging *after* we had told the >>>>>>>>>>>>>> corresponding >>>>>>>>>>>>>> GCTracer that the concurrent cycle was aborted and it had >>>>>>>>>>>>>> thrown its GC >>>>>>>>>>>>>> ID away. Now the GC ID can stay in scope until we have >>>>>>>>>>>>>> completed all >>>>>>>>>>>>>> logging. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also the HeapDumpBeforeFullGC and >>>>>>>>>>>>>> PrintClassHistogramBeforeFullGC used >>>>>>>>>>>>>> to have to create a new GC ID since their logging was >>>>>>>>>>>>>> done before we had >>>>>>>>>>>>>> the correct GCTracer set up. Now the GC ID can be >>>>>>>>>>>>>> available early enough >>>>>>>>>>>>>> for this logging to be using the same (and correct) GC ID >>>>>>>>>>>>>> as the rest of >>>>>>>>>>>>>> the GC. Same for HeapDumpAfterFullGC and >>>>>>>>>>>>>> PrintClassHistogramAfterFullGC. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've added an uint to the Thread class to keep track of >>>>>>>>>>>>>> the currently >>>>>>>>>>>>>> active GC ID. In the current code there are actually only >>>>>>>>>>>>>> NamedThreads >>>>>>>>>>>>>> that need the GC ID. So, I'm not sure where the best >>>>>>>>>>>>>> place is for this >>>>>>>>>>>>>> field is. But it seems like the Thread class contains >>>>>>>>>>>>>> most of the data, >>>>>>>>>>>>>> even data that is only used by some subclasses, so I >>>>>>>>>>>>>> opted for putting >>>>>>>>>>>>>> the field in Thread as opposed to in NamedThread. This >>>>>>>>>>>>>> opens up for >>>>>>>>>>>>>> possible future extensions when Java threads may do part >>>>>>>>>>>>>> of the GC work. >>>>>>>>>>>>>> However, I'm open to moving the field down to NamedThread >>>>>>>>>>>>>> if that is >>>>>>>>>>>>>> seen as better. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In the GCTracer class there were many asserts that were >>>>>>>>>>>>>> checking that >>>>>>>>>>>>>> the GC ID was properly set up. Mostly these assert verify >>>>>>>>>>>>>> that start/end >>>>>>>>>>>>>> is called correctly and that the other methods are called >>>>>>>>>>>>>> inside of the >>>>>>>>>>>>>> start/end scope. Now that the GC ID is moved out of the >>>>>>>>>>>>>> GCTracer class >>>>>>>>>>>>>> these asserts had to be dealt with. I figured there were >>>>>>>>>>>>>> three ways to >>>>>>>>>>>>>> handle it; just remove them, replace them with check that >>>>>>>>>>>>>> the GC ID from >>>>>>>>>>>>>> the current thread is correct, or implement a new status >>>>>>>>>>>>>> field to keep >>>>>>>>>>>>>> track of GC start/end state. Personally I'm not sure >>>>>>>>>>>>>> these asserts are >>>>>>>>>>>>>> valuable enough to spend time on, so I went for the first >>>>>>>>>>>>>> approach: >>>>>>>>>>>>>> removing them. I don't think making them use the thread >>>>>>>>>>>>>> GC ID will be >>>>>>>>>>>>>> appropriate. But if anyone feels strongly about these >>>>>>>>>>>>>> asserts I can >>>>>>>>>>>>>> implement a separate start/end state. >>>>>>>>>>>>>> >>>>>>>>>>>>>> There are a few "Tasks" in the GC code that are executed >>>>>>>>>>>>>> by worker >>>>>>>>>>>>>> threads. To make the worker threads use the correct GC ID >>>>>>>>>>>>>> I make sure >>>>>>>>>>>>>> that the Task constructors copy the GC ID from the >>>>>>>>>>>>>> initiating thread >>>>>>>>>>>>>> into a local variable. When the task is executed in its >>>>>>>>>>>>>> worker thread it >>>>>>>>>>>>>> sets up the GC ID based on the local variable. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The proposed change does not alter any logging (except >>>>>>>>>>>>>> for the small bug >>>>>>>>>>>>>> fix for >>>>>>>>>>>>>> HeapDumpBefore(After)FullGC/PrintClassHistogramBefore(After)FullGC. >>>>>>>>>>>>>> This >>>>>>>>>>>>>> means that no existing tests need to be updated. In >>>>>>>>>>>>>> particular the >>>>>>>>>>>>>> test/gc/logging/TestGCId.java test passes even after >>>>>>>>>>>>>> these changes. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> A big thanks to Per, who pre-reviewed these changes and >>>>>>>>>>>>>> came with some >>>>>>>>>>>>>> really good feedback. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Bengt >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From erik.joelsson at oracle.com Thu Oct 1 13:16:08 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 1 Oct 2015 15:16:08 +0200 Subject: [8u] Request for Approval and Review: JDK-8136980: build for 8u65 and 8u66 for solaris platforms is failing In-Reply-To: <560BD900.9000308@oracle.com> References: <560BD900.9000308@oracle.com> Message-ID: <560D3218.5070205@oracle.com> Still looking for an official review from 8u reviewer for this. Ideally someone from Hotspot. /Erik On 2015-09-30 14:43, Erik Joelsson wrote: > Hello, > > Please approve and review this fix for 8u. > > My last fix for this issue, JDK-8136691, was not enough. I made a > mistake while verifying the fix and the problem is still there. > > There are more discrepancies between Solaris and the other platform > makefiles. The excludeSrc.gmk file is not included anywhere when > building on Solaris. The variable Src_Files_EXCLUDE is overwritten in > vm.make instead of appended to, so even when including excludeSrc.gmk, > it wasn't enough. The other platform specific buildtree.make files > also set INCLUDE_TRACE in the generated makefile. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8136980 > Webrev: http://cr.openjdk.java.net/~erikj/8136980/webrev.hotspot.01/ > > /Erik From erik.joelsson at oracle.com Thu Oct 1 13:31:36 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 1 Oct 2015 15:31:36 +0200 Subject: RFR: JDK-8138692: libjsig compilation is missing EXTRA_CFLAGS on macosx Message-ID: <560D35B8.70101@oracle.com> Hello, Please review this trivial fix for compiling libjsig on macosx. The compilation of libjsig on macosx is currently not getting the EXTRA_CFLAGS supplied to the hotspot build. This means any kind of sysroot/sdkname setting from configure isn't honored. Historically this has likely not mattered at all, but in the compiler upgrade project, it matters a great deal. Bug: https://bugs.openjdk.java.net/browse/JDK-8138692 Patch: diff -r 983c56341c80 make/bsd/makefiles/jsig.make --- a/make/bsd/makefiles/jsig.make +++ b/make/bsd/makefiles/jsig.make @@ -62,7 +62,7 @@ $(LIBJSIG): $(JSIGSRCDIR)/jsig.c $(LIBJSIG_MAPFILE) @echo $(LOG_INFO) Making signal interposition lib... $(QUIETLY) $(CC) $(SYMFLAG) $(ARCHFLAG) $(SHARED_FLAG) $(PICFLAG) \ - $(LFLAGS_JSIG) $(JSIG_DEBUG_CFLAGS) -o $@ $< + $(LFLAGS_JSIG) $(JSIG_DEBUG_CFLAGS) $(EXTRA_CFLAGS) -o $@ $< ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) ifeq ($(OS_VENDOR), Darwin) $(DSYMUTIL) $@ /Erik From magnus.ihse.bursie at oracle.com Thu Oct 1 13:32:43 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 1 Oct 2015 15:32:43 +0200 Subject: RFR: JDK-8138692: libjsig compilation is missing EXTRA_CFLAGS on macosx In-Reply-To: <560D35B8.70101@oracle.com> References: <560D35B8.70101@oracle.com> Message-ID: <560D35FB.8080402@oracle.com> On 2015-10-01 15:31, Erik Joelsson wrote: > Hello, > > Please review this trivial fix for compiling libjsig on macosx. > > The compilation of libjsig on macosx is currently not getting the > EXTRA_CFLAGS supplied to the hotspot build. This means any kind of > sysroot/sdkname setting from configure isn't honored. Historically > this has likely not mattered at all, but in the compiler upgrade > project, it matters a great deal. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8138692 > Patch: > diff -r 983c56341c80 make/bsd/makefiles/jsig.make > --- a/make/bsd/makefiles/jsig.make > +++ b/make/bsd/makefiles/jsig.make > @@ -62,7 +62,7 @@ > $(LIBJSIG): $(JSIGSRCDIR)/jsig.c $(LIBJSIG_MAPFILE) > @echo $(LOG_INFO) Making signal interposition lib... > $(QUIETLY) $(CC) $(SYMFLAG) $(ARCHFLAG) $(SHARED_FLAG) $(PICFLAG) \ > - $(LFLAGS_JSIG) $(JSIG_DEBUG_CFLAGS) -o $@ $< > + $(LFLAGS_JSIG) $(JSIG_DEBUG_CFLAGS) > $(EXTRA_CFLAGS) -o $@ $< > ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) > ifeq ($(OS_VENDOR), Darwin) > $(DSYMUTIL) $@ > > /Erik Looks good to me. /Magnus From sangheon.kim at oracle.com Thu Oct 1 16:24:04 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Thu, 1 Oct 2015 09:24:04 -0700 Subject: RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <5605D02F.6070307@oracle.com> References: <55F219CE.3010006@oracle.com> <55F319B8.1000803@oracle.com> <55F32A81.8000307@oracle.com> <55F3E484.70107@oracle.com> <55F6D878.1070903@oracle.com> <5605D02F.6070307@oracle.com> Message-ID: <560D5E24.4050706@oracle.com> Hi all, During this code review, newly added gc test found a problem of 1 gc constraint function(MaxGCPauseMillisConstraintFunc). So I updated it and related function (GCPauseIntervalMillisConstraintFunc). - Added checking for MaxGCPauseMillis and GCPauseIntervalMillis whether these are set via commandline or not to proceed the constraint function logic. http://cr.openjdk.java.net/~sangheki/8134995/webrev.03 http://cr.openjdk.java.net/~sangheki/8134995/webrev.03_to_02/ * Testing: JPRT and RBT(to manually test runtime/CommandLine for embedded) Thanks, Sangheon On 09/25/2015 03:52 PM, sangheon.kim wrote: > Hi Gerard, > > I found that I missed your comment from webrev.01. > Here's a new one which includes yours for TestOptionsWithRanges.java. > > http://cr.openjdk.java.net/~sangheki/8134995/webrev.02/ > http://cr.openjdk.java.net/~sangheki/8134995/webrev.02_to_01 > > Thanks, > Sangheon > > > On 09/14/2015 07:23 AM, gerard ziemski wrote: >> Thank you. I have no more comments - reviewed. >> >> >> cheers >> >> >> On 09/12/2015 03:38 AM, sangheon.kim wrote: >>> Hi Gerard, >>> >>> On 09/11/2015 12:24 PM, sangheon.kim wrote: >>>> Hi Gerard, >>>> >>>> Thank you for looking at this. >>>> >>>> On 09/11/2015 11:13 AM, gerard ziemski wrote: >>>>> hi Sangheon, >>>>> >>>>> #1 >>>>> test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>>> >>>>> Please change the comment to: >>>>> >>>>> + /* >>>>> + * Exclude below options as their maximum value would >>>>> consume too much memory >>>>> + * and would affect other tests that run in parallel. >>>>> + */ >>>> Okay, I will fix as you suggested. >>>> >>>>> >>>>> >>>>> #2 What tests did you run? Did you run >>>>> test/runtime/CommandLine/OptionsValidation on all platforms >>>>> (including embedded)? >>>> No. >>>> I ran tests under test/runtime/CommandLine/OptionsValidation >>>> (especially TestOptionsWithRanges.java) for all platforms >>>> except embedded. >>>> Let me back after testing on embedded. >>> I ran for embedded (linux-arm64, linux-armvh, linux-armvfpsflt, >>> linux-armvfphflt, linux-armsflt) and all of them PASSED >>> for test/runtime/CommandLine/OptionsValidation. >>> >>> Thanks, >>> Sangheon >>> >>> >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>>> >>>>> >>>>> cheers >>>>> >>>>> >>>>> On 09/10/2015 07:01 PM, sangheon.kim wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review this patch for command-line validation for GC flags. >>>>>> This REDO patch is adding ranges and implementing constraint >>>>>> functions for GC flags. >>>>>> >>>>>> Original CR of JDK-8078555 was backout as it made a test failure >>>>>> from 'TestOptionsWithRanges.java'. >>>>>> And also there were some discussion of OOM handling. >>>>>> >>>>>> Most parts are same as JDK-8078555 except below: >>>>>> 1. Changed 'range' for some flags. >>>>>> 2. Excluded 3 flags for TestOptionsWithRanges.java test. These >>>>>> flags make this test unstable as it tries to allocate >>>>>> huge amount of memory. >>>>>> >>>>>> And below are the suggestion note for JDK-8078555: >>>>>> 1. Exponential notation for 'double' type variable parse: >>>>>> Previously there were some discussion for maximum value for >>>>>> double type flags from code review of JDK-8059557 and >>>>>> JDK-8112746. And Kim and I decided not to add upper limit unless >>>>>> there are problems with DBL_MAX. And as 255 is the maximum length >>>>>> that can be passed via command-line, we introduced >>>>>> exponential notation to avoid this limit. ( arguments.cpp ) >>>>>> 2. These GC flags ranges are not ideal ranges but ranges which >>>>>> don't make problem with current source code. >>>>>> If one flag makes some problem but hard to find good range, >>>>>> I added some ranges. >>>>>> 3. There are some constraint functions to avoid overflow. >>>>>> 4. Test applications are changed: as some of them assumed to be >>>>>> ParallelGC or to check it's output messages. >>>>>> 5. Includes cleanup of JDK-8133565: GC -2nd followup to JDK-8059557. >>>>>> >>>>>> CR: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8134995 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.00/ >>>>>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.00_to_8078555 >>>>>> >>>>>> Testing: >>>>>> JPRT, UTE(vm.quick-pcl) and >>>>>> test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>> >>> >>> > From kim.barrett at oracle.com Thu Oct 1 17:52:07 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 1 Oct 2015 13:52:07 -0400 Subject: RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <560D5E24.4050706@oracle.com> References: <55F219CE.3010006@oracle.com> <55F319B8.1000803@oracle.com> <55F32A81.8000307@oracle.com> <55F3E484.70107@oracle.com> <55F6D878.1070903@oracle.com> <5605D02F.6070307@oracle.com> <560D5E24.4050706@oracle.com> Message-ID: On Oct 1, 2015, at 12:24 PM, sangheon.kim wrote: > > Hi all, > > During this code review, newly added gc test found a problem of 1 gc constraint function(MaxGCPauseMillisConstraintFunc). > > So I updated it and related function (GCPauseIntervalMillisConstraintFunc). > - Added checking for MaxGCPauseMillis and GCPauseIntervalMillis whether these are set via commandline or not to proceed the constraint function logic. > > http://cr.openjdk.java.net/~sangheki/8134995/webrev.03 > http://cr.openjdk.java.net/~sangheki/8134995/webrev.03_to_02/ > > * Testing: JPRT and RBT(to manually test runtime/CommandLine for embedded) This change doesn't seem right. There is a relationship between these two values that should hold after all the argument processing is done, and it doesn't matter where the values came from. All of the FLAG_IS_CMDLINE checks (including those from earlier versions) in these constraint functions now seem questionable to me. It seems to me that if there is an unexpected test failure here, then the problem is that some "ergonomic" setting of these values is occurring after the constraint function is being called. Or alternatively, the ergnonomic settings are not right in some cases. From sangheon.kim at oracle.com Thu Oct 1 18:20:46 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Thu, 1 Oct 2015 11:20:46 -0700 Subject: RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: References: <55F219CE.3010006@oracle.com> <55F319B8.1000803@oracle.com> <55F32A81.8000307@oracle.com> <55F3E484.70107@oracle.com> <55F6D878.1070903@oracle.com> <5605D02F.6070307@oracle.com> <560D5E24.4050706@oracle.com> Message-ID: <560D797E.9010901@oracle.com> Hi Kim, On 10/01/2015 10:52 AM, Kim Barrett wrote: > On Oct 1, 2015, at 12:24 PM, sangheon.kim wrote: >> Hi all, >> >> During this code review, newly added gc test found a problem of 1 gc constraint function(MaxGCPauseMillisConstraintFunc). >> >> So I updated it and related function (GCPauseIntervalMillisConstraintFunc). >> - Added checking for MaxGCPauseMillis and GCPauseIntervalMillis whether these are set via commandline or not to proceed the constraint function logic. >> >> http://cr.openjdk.java.net/~sangheki/8134995/webrev.03 >> http://cr.openjdk.java.net/~sangheki/8134995/webrev.03_to_02/ >> >> * Testing: JPRT and RBT(to manually test runtime/CommandLine for embedded) > This change doesn't seem right. There is a relationship between these > two values that should hold after all the argument processing is done, > and it doesn't matter where the values came from. All of the > FLAG_IS_CMDLINE checks (including those from earlier versions) in > these constraint functions now seem questionable to me. > > It seems to me that if there is an unexpected test failure here, then > the problem is that some "ergonomic" setting of these values is > occurring after the constraint function is being called. Or > alternatively, the ergnonomic settings are not right in some cases. The reason of test failure is simply can't pass the constraint function. The test is setting only 'MaxGCPauseMillis=30000' which means GCPauseIntervalMillis will have default value of 0(zero means set ergonomically). Without constraint function, G1CollectorPolicy will set GCPauseIntervalMillis=30001. No problem with the test. For G1, 'MaxGCPauseMillis >= GCPauseIntervalMillis' is one of the condition should be kept. But the constraint function is trying to compare 30000(set via cmd line) vs. 0(default). The intend of using FLAG_IS_CMDLINE() is to avoid comparison with default value which means set ergonomically. All other cases that using FLAG_IS_CMDLINE() is for same purpose, to avoid comparison with default value. Thanks, Sangheon From mikael.vidstedt at oracle.com Thu Oct 1 18:35:22 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 1 Oct 2015 11:35:22 -0700 Subject: [8u] Request for Approval and Review: JDK-8136980: build for 8u65 and 8u66 for solaris platforms is failing In-Reply-To: <560D3218.5070205@oracle.com> References: <560BD900.9000308@oracle.com> <560D3218.5070205@oracle.com> Message-ID: <560D7CEA.5050302@oracle.com> Looks ok. (This really needs to be unified, but we know that) Cheers, Mikael On 2015-10-01 06:16, Erik Joelsson wrote: > Still looking for an official review from 8u reviewer for this. > Ideally someone from Hotspot. > > /Erik > > On 2015-09-30 14:43, Erik Joelsson wrote: >> Hello, >> >> Please approve and review this fix for 8u. >> >> My last fix for this issue, JDK-8136691, was not enough. I made a >> mistake while verifying the fix and the problem is still there. >> >> There are more discrepancies between Solaris and the other platform >> makefiles. The excludeSrc.gmk file is not included anywhere when >> building on Solaris. The variable Src_Files_EXCLUDE is overwritten in >> vm.make instead of appended to, so even when including >> excludeSrc.gmk, it wasn't enough. The other platform specific >> buildtree.make files also set INCLUDE_TRACE in the generated makefile. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8136980 >> Webrev: http://cr.openjdk.java.net/~erikj/8136980/webrev.hotspot.01/ >> >> /Erik > From mikael.vidstedt at oracle.com Thu Oct 1 18:36:31 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 1 Oct 2015 11:36:31 -0700 Subject: RFR: JDK-8138692: libjsig compilation is missing EXTRA_CFLAGS on macosx In-Reply-To: <560D35B8.70101@oracle.com> References: <560D35B8.70101@oracle.com> Message-ID: <560D7D2F.8060707@oracle.com> Good! Cheers, Mikael On 2015-10-01 06:31, Erik Joelsson wrote: > Hello, > > Please review this trivial fix for compiling libjsig on macosx. > > The compilation of libjsig on macosx is currently not getting the > EXTRA_CFLAGS supplied to the hotspot build. This means any kind of > sysroot/sdkname setting from configure isn't honored. Historically > this has likely not mattered at all, but in the compiler upgrade > project, it matters a great deal. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8138692 > Patch: > diff -r 983c56341c80 make/bsd/makefiles/jsig.make > --- a/make/bsd/makefiles/jsig.make > +++ b/make/bsd/makefiles/jsig.make > @@ -62,7 +62,7 @@ > $(LIBJSIG): $(JSIGSRCDIR)/jsig.c $(LIBJSIG_MAPFILE) > @echo $(LOG_INFO) Making signal interposition lib... > $(QUIETLY) $(CC) $(SYMFLAG) $(ARCHFLAG) $(SHARED_FLAG) $(PICFLAG) \ > - $(LFLAGS_JSIG) $(JSIG_DEBUG_CFLAGS) -o $@ $< > + $(LFLAGS_JSIG) $(JSIG_DEBUG_CFLAGS) > $(EXTRA_CFLAGS) -o $@ $< > ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) > ifeq ($(OS_VENDOR), Darwin) > $(DSYMUTIL) $@ > > /Erik From jon.masamitsu at oracle.com Thu Oct 1 18:57:21 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 1 Oct 2015 11:57:21 -0700 Subject: RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <560D5E24.4050706@oracle.com> References: <55F219CE.3010006@oracle.com> <55F319B8.1000803@oracle.com> <55F32A81.8000307@oracle.com> <55F3E484.70107@oracle.com> <55F6D878.1070903@oracle.com> <5605D02F.6070307@oracle.com> <560D5E24.4050706@oracle.com> Message-ID: <560D8211.9040903@oracle.com> Sangheon, What was the failure that prompted this change? I don't understand why the check for FLAG_IS_CMDLINE() is needed. Jon On 10/01/2015 09:24 AM, sangheon.kim wrote: > Hi all, > > During this code review, newly added gc test found a problem of 1 gc > constraint function(MaxGCPauseMillisConstraintFunc). > > So I updated it and related function > (GCPauseIntervalMillisConstraintFunc). > - Added checking for MaxGCPauseMillis and GCPauseIntervalMillis > whether these are set via commandline or not to proceed the constraint > function logic. > > http://cr.openjdk.java.net/~sangheki/8134995/webrev.03 > http://cr.openjdk.java.net/~sangheki/8134995/webrev.03_to_02/ > > * Testing: JPRT and RBT(to manually test runtime/CommandLine for > embedded) > > Thanks, > Sangheon > > > On 09/25/2015 03:52 PM, sangheon.kim wrote: >> Hi Gerard, >> >> I found that I missed your comment from webrev.01. >> Here's a new one which includes yours for TestOptionsWithRanges.java. >> >> http://cr.openjdk.java.net/~sangheki/8134995/webrev.02/ >> http://cr.openjdk.java.net/~sangheki/8134995/webrev.02_to_01 >> >> Thanks, >> Sangheon >> >> >> On 09/14/2015 07:23 AM, gerard ziemski wrote: >>> Thank you. I have no more comments - reviewed. >>> >>> >>> cheers >>> >>> >>> On 09/12/2015 03:38 AM, sangheon.kim wrote: >>>> Hi Gerard, >>>> >>>> On 09/11/2015 12:24 PM, sangheon.kim wrote: >>>>> Hi Gerard, >>>>> >>>>> Thank you for looking at this. >>>>> >>>>> On 09/11/2015 11:13 AM, gerard ziemski wrote: >>>>>> hi Sangheon, >>>>>> >>>>>> #1 >>>>>> test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>>>> >>>>>> >>>>>> Please change the comment to: >>>>>> >>>>>> + /* >>>>>> + * Exclude below options as their maximum value would >>>>>> consume too much memory >>>>>> + * and would affect other tests that run in parallel. >>>>>> + */ >>>>> Okay, I will fix as you suggested. >>>>> >>>>>> >>>>>> >>>>>> #2 What tests did you run? Did you run >>>>>> test/runtime/CommandLine/OptionsValidation on all platforms >>>>>> (including embedded)? >>>>> No. >>>>> I ran tests under test/runtime/CommandLine/OptionsValidation >>>>> (especially TestOptionsWithRanges.java) for all platforms >>>>> except embedded. >>>>> Let me back after testing on embedded. >>>> I ran for embedded (linux-arm64, linux-armvh, linux-armvfpsflt, >>>> linux-armvfphflt, linux-armsflt) and all of them PASSED >>>> for test/runtime/CommandLine/OptionsValidation. >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>>> >>>>>> >>>>>> cheers >>>>>> >>>>>> >>>>>> On 09/10/2015 07:01 PM, sangheon.kim wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review this patch for command-line validation for GC flags. >>>>>>> This REDO patch is adding ranges and implementing constraint >>>>>>> functions for GC flags. >>>>>>> >>>>>>> Original CR of JDK-8078555 was backout as it made a test failure >>>>>>> from 'TestOptionsWithRanges.java'. >>>>>>> And also there were some discussion of OOM handling. >>>>>>> >>>>>>> Most parts are same as JDK-8078555 except below: >>>>>>> 1. Changed 'range' for some flags. >>>>>>> 2. Excluded 3 flags for TestOptionsWithRanges.java test. These >>>>>>> flags make this test unstable as it tries to allocate >>>>>>> huge amount of memory. >>>>>>> >>>>>>> And below are the suggestion note for JDK-8078555: >>>>>>> 1. Exponential notation for 'double' type variable parse: >>>>>>> Previously there were some discussion for maximum value for >>>>>>> double type flags from code review of JDK-8059557 and >>>>>>> JDK-8112746. And Kim and I decided not to add upper limit unless >>>>>>> there are problems with DBL_MAX. And as 255 is the maximum >>>>>>> length that can be passed via command-line, we introduced >>>>>>> exponential notation to avoid this limit. ( arguments.cpp ) >>>>>>> 2. These GC flags ranges are not ideal ranges but ranges which >>>>>>> don't make problem with current source code. >>>>>>> If one flag makes some problem but hard to find good range, >>>>>>> I added some ranges. >>>>>>> 3. There are some constraint functions to avoid overflow. >>>>>>> 4. Test applications are changed: as some of them assumed to be >>>>>>> ParallelGC or to check it's output messages. >>>>>>> 5. Includes cleanup of JDK-8133565: GC -2nd followup to >>>>>>> JDK-8059557. >>>>>>> >>>>>>> CR: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8134995 >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.00/ >>>>>>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.00_to_8078555 >>>>>>> >>>>>>> Testing: >>>>>>> JPRT, UTE(vm.quick-pcl) and >>>>>>> test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Sangheon >>>>>>> >>>>>>> >>>>> >>>> >>>> >> > From sangheon.kim at oracle.com Thu Oct 1 19:10:41 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Thu, 1 Oct 2015 12:10:41 -0700 Subject: RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <560D8211.9040903@oracle.com> References: <55F219CE.3010006@oracle.com> <55F319B8.1000803@oracle.com> <55F32A81.8000307@oracle.com> <55F3E484.70107@oracle.com> <55F6D878.1070903@oracle.com> <5605D02F.6070307@oracle.com> <560D5E24.4050706@oracle.com> <560D8211.9040903@oracle.com> Message-ID: <560D8531.5040101@oracle.com> Hi Jon, On 10/01/2015 11:57 AM, Jon Masamitsu wrote: > Sangheon, > > What was the failure that prompted this change? test/gc/g1/mixedgc/TestLogging.java And as I answered to Kim, this test is wrote correctly. Current constraint function is trying to verify below: MaxGCPauseMillis >= GCPauseIntervalMillis But if one of them is using default value, this comparison is not valid as default value means set it ergonomically. This is why I added FLAG_IS_CMDLINE(). Sangheon > I > don't understand why the check for FLAG_IS_CMDLINE() > is needed. > > Jon > > On 10/01/2015 09:24 AM, sangheon.kim wrote: >> Hi all, >> >> During this code review, newly added gc test found a problem of 1 gc >> constraint function(MaxGCPauseMillisConstraintFunc). >> >> So I updated it and related function >> (GCPauseIntervalMillisConstraintFunc). >> - Added checking for MaxGCPauseMillis and GCPauseIntervalMillis >> whether these are set via commandline or not to proceed the >> constraint function logic. >> >> http://cr.openjdk.java.net/~sangheki/8134995/webrev.03 >> http://cr.openjdk.java.net/~sangheki/8134995/webrev.03_to_02/ >> >> * Testing: JPRT and RBT(to manually test runtime/CommandLine for >> embedded) >> >> Thanks, >> Sangheon >> >> >> On 09/25/2015 03:52 PM, sangheon.kim wrote: >>> Hi Gerard, >>> >>> I found that I missed your comment from webrev.01. >>> Here's a new one which includes yours for TestOptionsWithRanges.java. >>> >>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.02/ >>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.02_to_01 >>> >>> Thanks, >>> Sangheon >>> >>> >>> On 09/14/2015 07:23 AM, gerard ziemski wrote: >>>> Thank you. I have no more comments - reviewed. >>>> >>>> >>>> cheers >>>> >>>> >>>> On 09/12/2015 03:38 AM, sangheon.kim wrote: >>>>> Hi Gerard, >>>>> >>>>> On 09/11/2015 12:24 PM, sangheon.kim wrote: >>>>>> Hi Gerard, >>>>>> >>>>>> Thank you for looking at this. >>>>>> >>>>>> On 09/11/2015 11:13 AM, gerard ziemski wrote: >>>>>>> hi Sangheon, >>>>>>> >>>>>>> #1 >>>>>>> test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>>>>> >>>>>>> >>>>>>> Please change the comment to: >>>>>>> >>>>>>> + /* >>>>>>> + * Exclude below options as their maximum value would >>>>>>> consume too much memory >>>>>>> + * and would affect other tests that run in parallel. >>>>>>> + */ >>>>>> Okay, I will fix as you suggested. >>>>>> >>>>>>> >>>>>>> >>>>>>> #2 What tests did you run? Did you run >>>>>>> test/runtime/CommandLine/OptionsValidation on all platforms >>>>>>> (including embedded)? >>>>>> No. >>>>>> I ran tests under test/runtime/CommandLine/OptionsValidation >>>>>> (especially TestOptionsWithRanges.java) for all platforms >>>>>> except embedded. >>>>>> Let me back after testing on embedded. >>>>> I ran for embedded (linux-arm64, linux-armvh, linux-armvfpsflt, >>>>> linux-armvfphflt, linux-armsflt) and all of them PASSED >>>>> for test/runtime/CommandLine/OptionsValidation. >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> cheers >>>>>>> >>>>>>> >>>>>>> On 09/10/2015 07:01 PM, sangheon.kim wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review this patch for command-line validation for GC flags. >>>>>>>> This REDO patch is adding ranges and implementing constraint >>>>>>>> functions for GC flags. >>>>>>>> >>>>>>>> Original CR of JDK-8078555 was backout as it made a test >>>>>>>> failure from 'TestOptionsWithRanges.java'. >>>>>>>> And also there were some discussion of OOM handling. >>>>>>>> >>>>>>>> Most parts are same as JDK-8078555 except below: >>>>>>>> 1. Changed 'range' for some flags. >>>>>>>> 2. Excluded 3 flags for TestOptionsWithRanges.java test. These >>>>>>>> flags make this test unstable as it tries to allocate >>>>>>>> huge amount of memory. >>>>>>>> >>>>>>>> And below are the suggestion note for JDK-8078555: >>>>>>>> 1. Exponential notation for 'double' type variable parse: >>>>>>>> Previously there were some discussion for maximum value for >>>>>>>> double type flags from code review of JDK-8059557 and >>>>>>>> JDK-8112746. And Kim and I decided not to add upper limit unless >>>>>>>> there are problems with DBL_MAX. And as 255 is the maximum >>>>>>>> length that can be passed via command-line, we introduced >>>>>>>> exponential notation to avoid this limit. ( arguments.cpp ) >>>>>>>> 2. These GC flags ranges are not ideal ranges but ranges which >>>>>>>> don't make problem with current source code. >>>>>>>> If one flag makes some problem but hard to find good >>>>>>>> range, I added some ranges. >>>>>>>> 3. There are some constraint functions to avoid overflow. >>>>>>>> 4. Test applications are changed: as some of them assumed to be >>>>>>>> ParallelGC or to check it's output messages. >>>>>>>> 5. Includes cleanup of JDK-8133565: GC -2nd followup to >>>>>>>> JDK-8059557. >>>>>>>> >>>>>>>> CR: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8134995 >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.00/ >>>>>>>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.00_to_8078555 >>>>>>>> >>>>>>>> Testing: >>>>>>>> JPRT, UTE(vm.quick-pcl) and >>>>>>>> test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sangheon >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>>> >>> >> > From kim.barrett at oracle.com Thu Oct 1 21:16:47 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 1 Oct 2015 17:16:47 -0400 Subject: RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <560D797E.9010901@oracle.com> References: <55F219CE.3010006@oracle.com> <55F319B8.1000803@oracle.com> <55F32A81.8000307@oracle.com> <55F3E484.70107@oracle.com> <55F6D878.1070903@oracle.com> <5605D02F.6070307@oracle.com> <560D5E24.4050706@oracle.com> <560D797E.9010901@oracle.com> Message-ID: <0E0A2899-ECC6-4065-8029-6D0A88E9F6C9@oracle.com> On Oct 1, 2015, at 2:20 PM, sangheon.kim wrote: > > On 10/01/2015 10:52 AM, Kim Barrett wrote: >> On Oct 1, 2015, at 12:24 PM, sangheon.kim wrote: >>> Hi all, >>> >>> During this code review, newly added gc test found a problem of 1 gc constraint function(MaxGCPauseMillisConstraintFunc). >>> >>> So I updated it and related function (GCPauseIntervalMillisConstraintFunc). >>> - Added checking for MaxGCPauseMillis and GCPauseIntervalMillis whether these are set via commandline or not to proceed the constraint function logic. >>> >>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.03 >>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.03_to_02/ >>> >>> * Testing: JPRT and RBT(to manually test runtime/CommandLine for embedded) >> This change doesn't seem right. There is a relationship between these >> two values that should hold after all the argument processing is done, >> and it doesn't matter where the values came from. All of the >> FLAG_IS_CMDLINE checks (including those from earlier versions) in >> these constraint functions now seem questionable to me. >> >> It seems to me that if there is an unexpected test failure here, then >> the problem is that some "ergonomic" setting of these values is >> occurring after the constraint function is being called. Or >> alternatively, the ergnonomic settings are not right in some cases. > The reason of test failure is simply can't pass the constraint function. > The test is setting only 'MaxGCPauseMillis=30000' which means GCPauseIntervalMillis will have default value of 0(zero means set ergonomically). > Without constraint function, G1CollectorPolicy will set GCPauseIntervalMillis=30001. > No problem with the test. > > For G1, 'MaxGCPauseMillis >= GCPauseIntervalMillis' is one of the condition should be kept. > But the constraint function is trying to compare 30000(set via cmd line) vs. 0(default). > The intend of using FLAG_IS_CMDLINE() is to avoid comparison with default value which means set ergonomically. > > All other cases that using FLAG_IS_CMDLINE() is for same purpose, to avoid comparison with default value. The constructor for G1CollectorPolicy is responsible for some of the ergonomic setup, most particularly the two options in question (MaxGCPauseMillis and GCPauseIntervalMillis). I think that constraint functions are not supposed to be run until after the associated ergonomics have been applied. But the constraint functions for these options are being assigned to the AfterErgo group, which is run before the heap is created, which includes creating the collector policy. One possible fix might be to assign these constraint functions to the AfterMemoryInit group. That certainly seems appropriate for GCPauseIntervalMillis, which appears to be G1-specific. And since MaxGCPauseMillis has no additional constraints when not using G1, such a move would also work for it. But this discussion is making me question all of the FLAG_IS_xxx uses in commandLineFlagConstraintsGC.cpp. From jon.masamitsu at oracle.com Thu Oct 1 22:06:38 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 1 Oct 2015 15:06:38 -0700 Subject: RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <560D8531.5040101@oracle.com> References: <55F219CE.3010006@oracle.com> <55F319B8.1000803@oracle.com> <55F32A81.8000307@oracle.com> <55F3E484.70107@oracle.com> <55F6D878.1070903@oracle.com> <5605D02F.6070307@oracle.com> <560D5E24.4050706@oracle.com> <560D8211.9040903@oracle.com> <560D8531.5040101@oracle.com> Message-ID: <560DAE6E.2010205@oracle.com> On 10/01/2015 12:10 PM, sangheon.kim wrote: > Hi Jon, > > On 10/01/2015 11:57 AM, Jon Masamitsu wrote: >> Sangheon, >> >> What was the failure that prompted this change? > test/gc/g1/mixedgc/TestLogging.java > And as I answered to Kim, this test is wrote correctly. > > Current constraint function is trying to verify below: > MaxGCPauseMillis >= GCPauseIntervalMillis > > But if one of them is using default value, this comparison is not > valid as default value means set it ergonomically. > This is why I added FLAG_IS_CMDLINE(). OK. I understand better now. Perhaps you could add a comment such as this to the top of the file. // Some flags that have default values that indicate that the // JVM should automatically determine an appropriate value // for that flag. In those cases it is only appropriate for the // constraint checking to be done if the user has specified the // value(s) of the flag(s) on the command line. In the constraint // checking functions, FLAG_IS_CMDLINE() is used to check if // the flag has been set by the user and so should be checked. Jon > > Sangheon > > >> I >> don't understand why the check for FLAG_IS_CMDLINE() >> is needed. >> >> Jon >> >> On 10/01/2015 09:24 AM, sangheon.kim wrote: >>> Hi all, >>> >>> During this code review, newly added gc test found a problem of 1 gc >>> constraint function(MaxGCPauseMillisConstraintFunc). >>> >>> So I updated it and related function >>> (GCPauseIntervalMillisConstraintFunc). >>> - Added checking for MaxGCPauseMillis and GCPauseIntervalMillis >>> whether these are set via commandline or not to proceed the >>> constraint function logic. >>> >>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.03 >>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.03_to_02/ >>> >>> * Testing: JPRT and RBT(to manually test runtime/CommandLine for >>> embedded) >>> >>> Thanks, >>> Sangheon >>> >>> >>> On 09/25/2015 03:52 PM, sangheon.kim wrote: >>>> Hi Gerard, >>>> >>>> I found that I missed your comment from webrev.01. >>>> Here's a new one which includes yours for TestOptionsWithRanges.java. >>>> >>>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.02/ >>>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.02_to_01 >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>> On 09/14/2015 07:23 AM, gerard ziemski wrote: >>>>> Thank you. I have no more comments - reviewed. >>>>> >>>>> >>>>> cheers >>>>> >>>>> >>>>> On 09/12/2015 03:38 AM, sangheon.kim wrote: >>>>>> Hi Gerard, >>>>>> >>>>>> On 09/11/2015 12:24 PM, sangheon.kim wrote: >>>>>>> Hi Gerard, >>>>>>> >>>>>>> Thank you for looking at this. >>>>>>> >>>>>>> On 09/11/2015 11:13 AM, gerard ziemski wrote: >>>>>>>> hi Sangheon, >>>>>>>> >>>>>>>> #1 >>>>>>>> test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>>>>>> >>>>>>>> >>>>>>>> Please change the comment to: >>>>>>>> >>>>>>>> + /* >>>>>>>> + * Exclude below options as their maximum value would >>>>>>>> consume too much memory >>>>>>>> + * and would affect other tests that run in parallel. >>>>>>>> + */ >>>>>>> Okay, I will fix as you suggested. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> #2 What tests did you run? Did you run >>>>>>>> test/runtime/CommandLine/OptionsValidation on all platforms >>>>>>>> (including embedded)? >>>>>>> No. >>>>>>> I ran tests under test/runtime/CommandLine/OptionsValidation >>>>>>> (especially TestOptionsWithRanges.java) for all platforms >>>>>>> except embedded. >>>>>>> Let me back after testing on embedded. >>>>>> I ran for embedded (linux-arm64, linux-armvh, linux-armvfpsflt, >>>>>> linux-armvfphflt, linux-armsflt) and all of them PASSED >>>>>> for test/runtime/CommandLine/OptionsValidation. >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Sangheon >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> cheers >>>>>>>> >>>>>>>> >>>>>>>> On 09/10/2015 07:01 PM, sangheon.kim wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Please review this patch for command-line validation for GC >>>>>>>>> flags. >>>>>>>>> This REDO patch is adding ranges and implementing constraint >>>>>>>>> functions for GC flags. >>>>>>>>> >>>>>>>>> Original CR of JDK-8078555 was backout as it made a test >>>>>>>>> failure from 'TestOptionsWithRanges.java'. >>>>>>>>> And also there were some discussion of OOM handling. >>>>>>>>> >>>>>>>>> Most parts are same as JDK-8078555 except below: >>>>>>>>> 1. Changed 'range' for some flags. >>>>>>>>> 2. Excluded 3 flags for TestOptionsWithRanges.java test. These >>>>>>>>> flags make this test unstable as it tries to allocate >>>>>>>>> huge amount of memory. >>>>>>>>> >>>>>>>>> And below are the suggestion note for JDK-8078555: >>>>>>>>> 1. Exponential notation for 'double' type variable parse: >>>>>>>>> Previously there were some discussion for maximum value for >>>>>>>>> double type flags from code review of JDK-8059557 and >>>>>>>>> JDK-8112746. And Kim and I decided not to add upper limit unless >>>>>>>>> there are problems with DBL_MAX. And as 255 is the maximum >>>>>>>>> length that can be passed via command-line, we introduced >>>>>>>>> exponential notation to avoid this limit. ( arguments.cpp ) >>>>>>>>> 2. These GC flags ranges are not ideal ranges but ranges which >>>>>>>>> don't make problem with current source code. >>>>>>>>> If one flag makes some problem but hard to find good >>>>>>>>> range, I added some ranges. >>>>>>>>> 3. There are some constraint functions to avoid overflow. >>>>>>>>> 4. Test applications are changed: as some of them assumed to >>>>>>>>> be ParallelGC or to check it's output messages. >>>>>>>>> 5. Includes cleanup of JDK-8133565: GC -2nd followup to >>>>>>>>> JDK-8059557. >>>>>>>>> >>>>>>>>> CR: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8134995 >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.00/ >>>>>>>>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.00_to_8078555 >>>>>>>>> >>>>>>>>> Testing: >>>>>>>>> JPRT, UTE(vm.quick-pcl) and >>>>>>>>> test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Sangheon >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>> >> > From sangheon.kim at oracle.com Thu Oct 1 22:27:00 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Thu, 1 Oct 2015 15:27:00 -0700 Subject: RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <0E0A2899-ECC6-4065-8029-6D0A88E9F6C9@oracle.com> References: <55F219CE.3010006@oracle.com> <55F319B8.1000803@oracle.com> <55F32A81.8000307@oracle.com> <55F3E484.70107@oracle.com> <55F6D878.1070903@oracle.com> <5605D02F.6070307@oracle.com> <560D5E24.4050706@oracle.com> <560D797E.9010901@oracle.com> <0E0A2899-ECC6-4065-8029-6D0A88E9F6C9@oracle.com> Message-ID: <560DB334.5000805@oracle.com> On 10/01/2015 02:16 PM, Kim Barrett wrote: > On Oct 1, 2015, at 2:20 PM, sangheon.kim wrote: >> On 10/01/2015 10:52 AM, Kim Barrett wrote: >>> On Oct 1, 2015, at 12:24 PM, sangheon.kim wrote: >>>> Hi all, >>>> >>>> During this code review, newly added gc test found a problem of 1 gc constraint function(MaxGCPauseMillisConstraintFunc). >>>> >>>> So I updated it and related function (GCPauseIntervalMillisConstraintFunc). >>>> - Added checking for MaxGCPauseMillis and GCPauseIntervalMillis whether these are set via commandline or not to proceed the constraint function logic. >>>> >>>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.03 >>>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.03_to_02/ >>>> >>>> * Testing: JPRT and RBT(to manually test runtime/CommandLine for embedded) >>> This change doesn't seem right. There is a relationship between these >>> two values that should hold after all the argument processing is done, >>> and it doesn't matter where the values came from. All of the >>> FLAG_IS_CMDLINE checks (including those from earlier versions) in >>> these constraint functions now seem questionable to me. >>> >>> It seems to me that if there is an unexpected test failure here, then >>> the problem is that some "ergonomic" setting of these values is >>> occurring after the constraint function is being called. Or >>> alternatively, the ergnonomic settings are not right in some cases. >> The reason of test failure is simply can't pass the constraint function. >> The test is setting only 'MaxGCPauseMillis=30000' which means GCPauseIntervalMillis will have default value of 0(zero means set ergonomically). >> Without constraint function, G1CollectorPolicy will set GCPauseIntervalMillis=30001. >> No problem with the test. >> >> For G1, 'MaxGCPauseMillis >= GCPauseIntervalMillis' is one of the condition should be kept. >> But the constraint function is trying to compare 30000(set via cmd line) vs. 0(default). >> The intend of using FLAG_IS_CMDLINE() is to avoid comparison with default value which means set ergonomically. >> >> All other cases that using FLAG_IS_CMDLINE() is for same purpose, to avoid comparison with default value. > The constructor for G1CollectorPolicy is responsible for some of the > ergonomic setup, most particularly the two options in question > (MaxGCPauseMillis and GCPauseIntervalMillis). > > I think that constraint functions are not supposed to be run until > after the associated ergonomics have been applied. But the constraint > functions for these options are being assigned to the AfterErgo group, > which is run before the heap is created, which includes creating the > collector policy. > > One possible fix might be to assign these constraint functions to the > AfterMemoryInit group. That certainly seems appropriate for > GCPauseIntervalMillis, which appears to be G1-specific. And since > MaxGCPauseMillis has no additional constraints when not using G1, such > a move would also work for it. Right, that is also possible solution. And I already tried this approach of changing group to AfterMemoryInit and it also works fine. (JPRT and running TestOptionsWithRanges.java for all platforms including embedded) But the reason of stopping this approach was current webrev.03 also can fix the problem. In addition, personally adding more options to AfterMemoryInit group seems weakening validation framework as sooner validation check seems better for me. For this case, I don't think they are weakening though. But I don't have strong opinion on this. I can revert to webrev.02 and change groups to AfterMemoryInit. > > But this discussion is making me question all of the FLAG_IS_xxx uses > in commandLineFlagConstraintsGC.cpp. For some options, they are automatically added to validate. (e.g. SurvivorRatio for CMS GC ) So FLAG_IS_xxx is needed for some cases. Will you review them again or okay to go (and handle from separate RFE)? Thanks, Sangheon > From sangheon.kim at oracle.com Thu Oct 1 22:30:05 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Thu, 1 Oct 2015 15:30:05 -0700 Subject: RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <560DAE6E.2010205@oracle.com> References: <55F219CE.3010006@oracle.com> <55F319B8.1000803@oracle.com> <55F32A81.8000307@oracle.com> <55F3E484.70107@oracle.com> <55F6D878.1070903@oracle.com> <5605D02F.6070307@oracle.com> <560D5E24.4050706@oracle.com> <560D8211.9040903@oracle.com> <560D8531.5040101@oracle.com> <560DAE6E.2010205@oracle.com> Message-ID: <560DB3ED.5090801@oracle.com> On 10/01/2015 03:06 PM, Jon Masamitsu wrote: > > > On 10/01/2015 12:10 PM, sangheon.kim wrote: >> Hi Jon, >> >> On 10/01/2015 11:57 AM, Jon Masamitsu wrote: >>> Sangheon, >>> >>> What was the failure that prompted this change? >> test/gc/g1/mixedgc/TestLogging.java >> And as I answered to Kim, this test is wrote correctly. >> >> Current constraint function is trying to verify below: >> MaxGCPauseMillis >= GCPauseIntervalMillis >> >> But if one of them is using default value, this comparison is not >> valid as default value means set it ergonomically. >> This is why I added FLAG_IS_CMDLINE(). > > OK. I understand better now. Perhaps you could add a comment > such as this to the top of the file. > > // Some flags that have default values that indicate that the > // JVM should automatically determine an appropriate value > // for that flag. In those cases it is only appropriate for the > // constraint checking to be done if the user has specified the > // value(s) of the flag(s) on the command line. In the constraint > // checking functions, FLAG_IS_CMDLINE() is used to check if > // the flag has been set by the user and so should be checked. Okay, I will add this explanation at the top of the file. Sangheon > > Jon > >> >> Sangheon >> >> >>> I >>> don't understand why the check for FLAG_IS_CMDLINE() >>> is needed. >>> >>> Jon >>> >>> On 10/01/2015 09:24 AM, sangheon.kim wrote: >>>> Hi all, >>>> >>>> During this code review, newly added gc test found a problem of 1 >>>> gc constraint function(MaxGCPauseMillisConstraintFunc). >>>> >>>> So I updated it and related function >>>> (GCPauseIntervalMillisConstraintFunc). >>>> - Added checking for MaxGCPauseMillis and GCPauseIntervalMillis >>>> whether these are set via commandline or not to proceed the >>>> constraint function logic. >>>> >>>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.03 >>>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.03_to_02/ >>>> >>>> * Testing: JPRT and RBT(to manually test runtime/CommandLine for >>>> embedded) >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>> On 09/25/2015 03:52 PM, sangheon.kim wrote: >>>>> Hi Gerard, >>>>> >>>>> I found that I missed your comment from webrev.01. >>>>> Here's a new one which includes yours for TestOptionsWithRanges.java. >>>>> >>>>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.02/ >>>>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.02_to_01 >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>> On 09/14/2015 07:23 AM, gerard ziemski wrote: >>>>>> Thank you. I have no more comments - reviewed. >>>>>> >>>>>> >>>>>> cheers >>>>>> >>>>>> >>>>>> On 09/12/2015 03:38 AM, sangheon.kim wrote: >>>>>>> Hi Gerard, >>>>>>> >>>>>>> On 09/11/2015 12:24 PM, sangheon.kim wrote: >>>>>>>> Hi Gerard, >>>>>>>> >>>>>>>> Thank you for looking at this. >>>>>>>> >>>>>>>> On 09/11/2015 11:13 AM, gerard ziemski wrote: >>>>>>>>> hi Sangheon, >>>>>>>>> >>>>>>>>> #1 >>>>>>>>> test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>>>>>>> >>>>>>>>> >>>>>>>>> Please change the comment to: >>>>>>>>> >>>>>>>>> + /* >>>>>>>>> + * Exclude below options as their maximum value would >>>>>>>>> consume too much memory >>>>>>>>> + * and would affect other tests that run in parallel. >>>>>>>>> + */ >>>>>>>> Okay, I will fix as you suggested. >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> #2 What tests did you run? Did you run >>>>>>>>> test/runtime/CommandLine/OptionsValidation on all platforms >>>>>>>>> (including embedded)? >>>>>>>> No. >>>>>>>> I ran tests under test/runtime/CommandLine/OptionsValidation >>>>>>>> (especially TestOptionsWithRanges.java) for all platforms >>>>>>>> except embedded. >>>>>>>> Let me back after testing on embedded. >>>>>>> I ran for embedded (linux-arm64, linux-armvh, linux-armvfpsflt, >>>>>>> linux-armvfphflt, linux-armsflt) and all of them PASSED >>>>>>> for test/runtime/CommandLine/OptionsValidation. >>>>>>> >>>>>>> Thanks, >>>>>>> Sangheon >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sangheon >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> cheers >>>>>>>>> >>>>>>>>> >>>>>>>>> On 09/10/2015 07:01 PM, sangheon.kim wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Please review this patch for command-line validation for GC >>>>>>>>>> flags. >>>>>>>>>> This REDO patch is adding ranges and implementing constraint >>>>>>>>>> functions for GC flags. >>>>>>>>>> >>>>>>>>>> Original CR of JDK-8078555 was backout as it made a test >>>>>>>>>> failure from 'TestOptionsWithRanges.java'. >>>>>>>>>> And also there were some discussion of OOM handling. >>>>>>>>>> >>>>>>>>>> Most parts are same as JDK-8078555 except below: >>>>>>>>>> 1. Changed 'range' for some flags. >>>>>>>>>> 2. Excluded 3 flags for TestOptionsWithRanges.java test. >>>>>>>>>> These flags make this test unstable as it tries to allocate >>>>>>>>>> huge amount of memory. >>>>>>>>>> >>>>>>>>>> And below are the suggestion note for JDK-8078555: >>>>>>>>>> 1. Exponential notation for 'double' type variable parse: >>>>>>>>>> Previously there were some discussion for maximum value for >>>>>>>>>> double type flags from code review of JDK-8059557 and >>>>>>>>>> JDK-8112746. And Kim and I decided not to add upper limit unless >>>>>>>>>> there are problems with DBL_MAX. And as 255 is the maximum >>>>>>>>>> length that can be passed via command-line, we introduced >>>>>>>>>> exponential notation to avoid this limit. ( arguments.cpp ) >>>>>>>>>> 2. These GC flags ranges are not ideal ranges but ranges >>>>>>>>>> which don't make problem with current source code. >>>>>>>>>> If one flag makes some problem but hard to find good >>>>>>>>>> range, I added some ranges. >>>>>>>>>> 3. There are some constraint functions to avoid overflow. >>>>>>>>>> 4. Test applications are changed: as some of them assumed to >>>>>>>>>> be ParallelGC or to check it's output messages. >>>>>>>>>> 5. Includes cleanup of JDK-8133565: GC -2nd followup to >>>>>>>>>> JDK-8059557. >>>>>>>>>> >>>>>>>>>> CR: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8134995 >>>>>>>>>> >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.00/ >>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.00_to_8078555 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Testing: >>>>>>>>>> JPRT, UTE(vm.quick-pcl) and >>>>>>>>>> test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Sangheon >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>> >> > From christian.thalinger at oracle.com Thu Oct 1 23:46:55 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 1 Oct 2015 13:46:55 -1000 Subject: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface In-Reply-To: <0B9B6287-20E1-4F60-A03F-E046920BB1BB@oracle.com> References: <2B401EAC-B386-4E42-BC4C-DD267FFD4970@oracle.com> <55F9671C.4000208@oracle.com> <99042B61-9F43-42CE-835C-095CD2858CB1@oracle.com> <55F9F08E.8010506@oracle.com> <08A9DB82-58D0-41F8-97F5-23AD78205263@oracle.com>

<067C7DA1-7422-411E-A678-91FBDECEBE1D@oracle.com> <8E92D69B-7207-4CDC-80F7-3AA65AC5C482@oracle.com> <97150580-7329-438F-9B64-F47E3BFE9F08@oracle.com> <0B9B6287-20E1-4F60-A03F-E046920BB1BB@oracle.com> <16E5DFE6-B289-4AA6-8819-EF85398B3465@oracle.com> <7EE5070A-30FE-42D9-91BC-BA58B9E925BC@oracle.com> <5B49BED2-D14C-4304-BDA2-B07E7DE83D96@oracle.com> <50D145A5-A06C-48F4-B7E4-89223DDDCCAE@oracle.com> Message-ID: > On Oct 2, 2015, at 12:31 PM, Kim Barrett wrote: > > On Oct 2, 2015, at 5:04 PM, Christian Thalinger wrote: >> >>> On Oct 2, 2015, at 10:15 AM, Kim Barrett wrote: >>> >>> On Oct 1, 2015, at 7:46 PM, Christian Thalinger wrote: >>>> >>>>> On Sep 30, 2015, at 3:19 PM, Kim Barrett wrote: >>>>> src/share/vm/gc/shared/cardTableRS.cpp >>>>> Changes in CardTableRS::verify_space function. >>>>> >>>>> These don't appear to be specifically related to JVMCI. I'm not sure >>>>> whether this is someone's debugging code that was left in, or if it >>>>> might be viewed as an improvement. Either way, I'd prefer that it be >>>>> a separate change that gets reviewed by folks interested in GC >>>>> changes, rather than being buried in the JVMCI change set. >>>> >>>> Removed. >>> >>> Not completely. [?] >>> >>> [Note that the removal of the unnecessary (HeapWord*) cast is in there.] >> >> But you want me to keep that, right? > > Yes - just highlighting that this change to keep was intermixed with the stuff to remove. > Looks like you did what I wanted, even if I didn?t say it clearly. > >>> @@ -344,19 +344,26 @@ >>> assert(jp >= _begin && jp < _end, >>> err_msg("Error: jp " PTR_FORMAT " should be within " >>> "[_begin, _end) = [" PTR_FORMAT "," PTR_FORMAT ")", >>> p2i(jp), p2i(_begin), p2i(_end))); >>> oop obj = oopDesc::load_decode_heap_oop(p); >>> - guarantee(obj == NULL || (HeapWord*)obj >= _boundary, >>> - err_msg("pointer " PTR_FORMAT " at " PTR_FORMAT " on " >>> + if (!(obj == NULL || (HeapWord*)obj >= _boundary)) { >>> + tty->print_cr("pointer " PTR_FORMAT " at " PTR_FORMAT " on " >>> "clean card crosses boundary" PTR_FORMAT, >>> - p2i((HeapWord*)obj), p2i(jp), p2i(_boundary))); >>> + p2i(obj), p2i(jp), p2i(_boundary)); >>> +#ifndef PRODUCT >>> + obj->print(); >>> +#endif >>> + had_error = true; >>> + } >>> } >>> >>> public: >>> + bool had_error; >>> + >>> VerifyCleanCardClosure(HeapWord* b, HeapWord* begin, HeapWord* end) : >>> - _boundary(b), _begin(begin), _end(end) { >>> + _boundary(b), _begin(begin), _end(end), had_error(false) { >>> assert(b <= begin, >>> err_msg("Error: boundary " PTR_FORMAT " should be at or below begin " PTR_FORMAT, >>> p2i(b), p2i(begin))); >>> assert(begin <= end, >>> err_msg("Error: begin " PTR_FORMAT " should be strictly below end " PTR_FORMAT, >> >> Sorry, it wasn?t obvious to me that you are also talking about this code. Removed: >> >> http://hg.openjdk.java.net/graal/graal-jvmci-9/hotspot/rev/2d707abdbfba > > Thanks. Sorry for being unclear; when I said ?changes to verify_space? I was including the > related changes to the helper closure object. > > And that addresses the last of my comments. Thanks. From kim.barrett at oracle.com Sat Oct 3 18:26:06 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 3 Oct 2015 14:26:06 -0400 Subject: RFR: 8138659: Speed up InstanceKlass subclass discrimination Message-ID: Please review this change to speed up discrimination among the classes rooted at InstanceKlass. We use 2 bits from InstanceKlass::_misc_flags (the _misc_kind field) for discrimination among the four kinds of InstanceKlass. We use the low 2 bits of _misc_flags to avoid a shift when accessing the field. This means that all the existing flags are being shifted up 2 bits. Added an accessor and a suite of predicates to InstanceKlass. Added kind argument to InstanceKlass constructor, which is used to set the _misc_kind field. Updated all callers to provide the appropriate value. With these changes we can use the layout_helper-based Klass::oop_is_instance to get to the InstanceKlass case, and use the _misc_kind value to further discriminate from there. In particular, the concrete InstanceKlass case is (after inlining) (klass->_layout_helper > 0) && ((static_cast(klass)->_misc_flags & 3) == 0) We could do better with a single discriminator, but there doesn't appear to be a good place to add such in Klass, and we don't want to make Klass bigger. Changed calls to Klass::oop_is_instanceXXX to instead call Klass::oop_is_instance then cast to InstanceKlass and use the corresponding kind_is_xxx predicate. Removed the no longer used Klass::oop_is_instanceXXX functions. Removed unused InstanceRefKlass::cast. InstanceMirrorKlass::cast is retained because it is used. InstanceClassLoaderKlass::cast does not exist. CR: https://bugs.openjdk.java.net/browse/JDK-8138659 Webrev: http://cr.openjdk.java.net/~kbarrett/8138659/webrev.00/ Testing: JPRT Aurora ad-hoc defaults + GC Nightly + Runtime Nightly From vladimir.kozlov at oracle.com Mon Oct 5 06:36:37 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 5 Oct 2015 14:36:37 +0800 Subject: RFR: AARCH64: 8138575: Improve generated code for profile counters In-Reply-To: <560AC796.9030301@redhat.com> References: <560AC796.9030301@redhat.com> Message-ID: <56121A75.5010400@oracle.com> Good. Thanks, Vladimir On 9/30/15 1:17 AM, Andrew Haley wrote: > AArch64 generates suboptimal code for profile counters. > > This > > add xscratch2, x0, #0x218 > ldr xscratch1, [xscratch2] > add xscratch1, xscratch1, #0x1 > str xscratch1, [xscratch2] > > can be this: > > ldr xscratch1, [x0, #0x218] > add xscratch1, xscratch1, #0x1 > str xscratch1, [x0, #0x218] > > Although this looks like a very minor improvement, the same pattern > is repeated many times in C1-generated code. > > http://cr.openjdk.java.net/~aph/8138575/ > > Thanks, > Andrew. > From stefan.karlsson at oracle.com Mon Oct 5 08:03:10 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 5 Oct 2015 10:03:10 +0200 Subject: RFR: 8138659: Speed up InstanceKlass subclass discrimination In-Reply-To: References: Message-ID: <56122EBE.30608@oracle.com> Hi Kim, On 2015-10-03 20:26, Kim Barrett wrote: > Please review this change to speed up discrimination among the classes > rooted at InstanceKlass. > > We use 2 bits from InstanceKlass::_misc_flags (the _misc_kind field) > for discrimination among the four kinds of InstanceKlass. We use the > low 2 bits of _misc_flags to avoid a shift when accessing the field. > This means that all the existing flags are being shifted up 2 bits. > Added an accessor and a suite of predicates to InstanceKlass. Added > kind argument to InstanceKlass constructor, which is used to set the > _misc_kind field. Updated all callers to provide the appropriate > value. > > With these changes we can use the layout_helper-based > Klass::oop_is_instance to get to the InstanceKlass case, and use the > _misc_kind value to further discriminate from there. In particular, > the concrete InstanceKlass case is (after inlining) > > (klass->_layout_helper > 0) && > ((static_cast(klass)->_misc_flags & 3) == 0) > > We could do better with a single discriminator, but there doesn't > appear to be a good place to add such in Klass, and we don't want to > make Klass bigger. > > Changed calls to Klass::oop_is_instanceXXX to instead call > Klass::oop_is_instance then cast to InstanceKlass and use the > corresponding kind_is_xxx predicate. Removed the no longer used > Klass::oop_is_instanceXXX functions. > > Removed unused InstanceRefKlass::cast. InstanceMirrorKlass::cast is > retained because it is used. InstanceClassLoaderKlass::cast does not > exist. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8138659 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8138659/webrev.00/ Did you consider keeping the "kind" infrastructure within the instanceKlass files instead of letting it leak down into oop.inline.hpp and out to the rest of the runtime? - virtual bool oop_is_instanceClassLoader() const { return false; } - virtual bool oop_is_instanceMirror() const { return false; } - virtual bool oop_is_instanceRef() const { return false; } Could be: bool oop_is_instanceClassLoader() const { return oop_is_instance() && InstanceKlass::cast(k)->oop_is_class_loader(); } bool oop_is_instanceMirror() const { return oop_is_instance() && InstanceKlass::cast(k)->oop_is_mirror(); } bool oop_is_instanceRef() const { return oop_is_instance() && InstanceKlass::cast(k)->oop_is_reference(); } and then the following change would be unnecessary: - assert(SystemDictionary::Class_klass()->oop_is_instanceMirror(), "Is not?"); + assert(InstanceKlass::cast(SystemDictionary::Class_klass())->kind_is_mirror(), "Is not?"); Other than that, this looks good to me. StefanK > > Testing: > JPRT > Aurora ad-hoc defaults + GC Nightly + Runtime Nightly > From aleksey.shipilev at oracle.com Mon Oct 5 08:56:39 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 5 Oct 2015 11:56:39 +0300 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> Message-ID: <56123B47.4070706@oracle.com> Hi Gil, Glad to see this being addressed! On 10/04/2015 07:22 PM, Gil Tene wrote: > We propose to add a method to the JDK which would be hint that a spin > loop is being performed. E.g. > jdk.util.PerformanceHints.spinLoopHint(), which will hopefully evolve > to a Java SE API, e.g. java.util.PerformanceHints.spinLoopHint(). The > specific name space location, class name, and method name will be > determined as part of development of this JEP. Yes, that would be a tough part. JDK is usually oblivious of these low-level platform-specific hints, they go to sun.misc.* (e.g. Unsafe, @Contended and others...). I'll let Project Leads to make that call :) > [4] HotSpot WebRevs for prototype implementation which intrinsifies > org.performancehintsSpinHint.spinLoopHint() > http://ivankrylov.github.io/spinloophint/webrev/ > * product_pd (platform-dependent) flags can be used to conditionalize the support on a platform. This helps to avoid vm_version_* tricks. * Does spinloophint imply membar as well? x86_64.ad suggests so. library_call.cpp suggests so. It seems weird to conflate the two, even though it's understandable you want to piggyback on existing machinery. * I think spinLoopHint() misses a @HotspotIntrinsicCandidate annotation. Thanks, -Aleksey From Alan.Bateman at oracle.com Mon Oct 5 09:04:22 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 5 Oct 2015 10:04:22 +0100 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> Message-ID: <56123D16.4070800@oracle.com> On 04/10/2015 17:22, Gil Tene wrote: > I would like to circulate this draft JEP proposal for initial review and consensus building purposes. > > I'm cross-posting to both core-libs-dev and hotspot-dev. From a spec perspective, the main change it suggests is the addition of a method (and probably a class to hold it) to the core libraries. And intrinsifying implementations would involve changes in HotSpot (see prototype WebRev links included below). > > Draft JEP follows inline... > > ? Gil. > I don't see any mention in the JEP about existing mechanisms to give hints to the runtime, as in @Contended (JEP 142) and @HotSpotIntrinsicCandidate (JDK-8076112). Just wondering if there is an alternative to explore where something like @Spinloop int ignore; would emit the PAUSE. This would at least give a starting point for usages in the JDK. The bigger question is whether to expose such runtime hints in an API. It's very much for the advanced developer and if an API is really needed then it might be something for a JDK-specific API. -Alan From mikeb01 at gmail.com Mon Oct 5 09:24:29 2015 From: mikeb01 at gmail.com (Michael Barker) Date: Mon, 5 Oct 2015 22:24:29 +1300 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56123B47.4070706@oracle.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <56123B47.4070706@oracle.com> Message-ID: > > Hi Gil, > > Glad to see this being addressed! > Me too, this would be a useful addition to the Disruptor. On 10/04/2015 07:22 PM, Gil Tene wrote: > > We propose to add a method to the JDK which would be hint that a spin > > loop is being performed. E.g. > > jdk.util.PerformanceHints.spinLoopHint(), which will hopefully evolve > > to a Java SE API, e.g. java.util.PerformanceHints.spinLoopHint(). The > > specific name space location, class name, and method name will be > > determined as part of development of this JEP. > > Yes, that would be a tough part. JDK is usually oblivious of these > low-level platform-specific hints, they go to sun.misc.* (e.g. Unsafe, > @Contended and others...). I'll let Project Leads to make that call :) > I think many of us are hoping that this will actually be a public API, unlike @Contented, will be enabled by default and therefore useful for third party libraries. Mike. From adinn at redhat.com Mon Oct 5 09:34:18 2015 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 5 Oct 2015 10:34:18 +0100 Subject: RFR: AARCH64: 8138575: Improve generated code for profile counters In-Reply-To: <560AC796.9030301@redhat.com> References: <560AC796.9030301@redhat.com> Message-ID: <5612441A.3060707@redhat.com> On 29/09/15 18:17, Andrew Haley wrote: > AArch64 generates suboptimal code for profile counters. > > This > > add xscratch2, x0, #0x218 > ldr xscratch1, [xscratch2] > add xscratch1, xscratch1, #0x1 > str xscratch1, [xscratch2] > > can be this: > > ldr xscratch1, [x0, #0x218] > add xscratch1, xscratch1, #0x1 > str xscratch1, [x0, #0x218] > > Although this looks like a very minor improvement, the same pattern > is repeated many times in C1-generated code. > > http://cr.openjdk.java.net/~aph/8138575/ Looks good to me too. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From erik.joelsson at oracle.com Mon Oct 5 09:38:09 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 5 Oct 2015 11:38:09 +0200 Subject: [8u] Request for Approval and Review: JDK-8136980: build for 8u65 and 8u66 for solaris platforms is failing In-Reply-To: <560D3218.5070205@oracle.com> References: <560BD900.9000308@oracle.com> <560D3218.5070205@oracle.com> Message-ID: <56124501.5090702@oracle.com> Another friendly bump for an 8u (R)eviewer for this. /Erik On 2015-10-01 15:16, Erik Joelsson wrote: > Still looking for an official review from 8u reviewer for this. > Ideally someone from Hotspot. > > /Erik > > On 2015-09-30 14:43, Erik Joelsson wrote: >> Hello, >> >> Please approve and review this fix for 8u. >> >> My last fix for this issue, JDK-8136691, was not enough. I made a >> mistake while verifying the fix and the problem is still there. >> >> There are more discrepancies between Solaris and the other platform >> makefiles. The excludeSrc.gmk file is not included anywhere when >> building on Solaris. The variable Src_Files_EXCLUDE is overwritten in >> vm.make instead of appended to, so even when including >> excludeSrc.gmk, it wasn't enough. The other platform specific >> buildtree.make files also set INCLUDE_TRACE in the generated makefile. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8136980 >> Webrev: http://cr.openjdk.java.net/~erikj/8136980/webrev.hotspot.01/ >> >> /Erik > From aph at redhat.com Mon Oct 5 09:41:52 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 5 Oct 2015 10:41:52 +0100 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> Message-ID: <561245E0.8030708@redhat.com> Hi Gil, On 04/10/15 17:22, Gil Tene wrote: > Summary > > Add an API that would allow Java code to hint that a spin loop is > being executed. I don't think this will work for ARM, which has a rather different spinlock mechanism. Instead of PAUSE, we wait on a lock word with WFE. WFE puts a core into a lightweight sleep state waiting on a particular address (the lock word) and a write to the lock word wakes it up. This is very useful and somewhat analogous to 86's MONITOR/MWAIT. I can't immediately see how to generalize your proposal to ARM, which is a shame. Andrew. From kirk.pepperdine at gmail.com Mon Oct 5 11:54:22 2015 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Mon, 5 Oct 2015 13:54:22 +0200 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56123D16.4070800@oracle.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <56123D16.4070800@oracle.com> Message-ID: <84DEC537-6E97-4C8D-9F1E-1F0163AA484E@gmail.com> Hi Alan, When would a developer know when to apply these annotations. Regards, Kirk > On Oct 5, 2015, at 11:04 AM, Alan Bateman wrote: > > On 04/10/2015 17:22, Gil Tene wrote: >> I would like to circulate this draft JEP proposal for initial review and consensus building purposes. >> >> I'm cross-posting to both core-libs-dev and hotspot-dev. From a spec perspective, the main change it suggests is the addition of a method (and probably a class to hold it) to the core libraries. And intrinsifying implementations would involve changes in HotSpot (see prototype WebRev links included below). >> >> Draft JEP follows inline... >> >> ? Gil. >> > I don't see any mention in the JEP about existing mechanisms to give hints to the runtime, as in @Contended (JEP 142) and @HotSpotIntrinsicCandidate (JDK-8076112). Just wondering if there is an alternative to explore where something like @Spinloop int ignore; would emit the PAUSE. This would at least give a starting point for usages in the JDK. The bigger question is whether to expose such runtime hints in an API. It's very much for the advanced developer and if an API is really needed then it might be something for a JDK-specific API. > > -Alan From magnus.ihse.bursie at oracle.com Mon Oct 5 12:47:05 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 5 Oct 2015 14:47:05 +0200 Subject: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface In-Reply-To: <2C323894-C058-442D-92CF-BDF969CD6504@oracle.com> References: <2B401EAC-B386-4E42-BC4C-DD267FFD4970@oracle.com> <55F9671C.4000208@oracle.com> <99042B61-9F43-42CE-835C-095CD2858CB1@oracle.com> <55F9F08E.8010506@oracle.com> <08A9DB82-58D0-41F8-97F5-23AD78205263@oracle.com>

<067C7DA1-7422-411E-A678-91FBDECEBE1D@oracle.com> <8E92D69B-7207-4CDC-80F7-3AA65AC5C482@oracle.com> <97150580-7329-438F-9B64-F47E3BFE9F08@oracle.com> <56051FD0.4010303@oracle.com> <1F931EBE-F2C0-413D-BFE4-787362577384@oracle.com> <56090777.2090807@oracle.com> <2C323894-C058-442D-92CF-BDF969CD6504@oracle.com> Message-ID: <56127149.6060701@oracle.com> On 2015-09-29 03:12, Christian Thalinger wrote: >> On Sep 27, 2015, at 11:25 PM, Magnus Ihse Bursie wrote: >> >> On 2015-09-25 22:00, Christian Thalinger wrote: >>> Btw. we found a bug in creating the OptionDescriptors files; we get duplicate entries: >>> >>> $ cat build/macosx-x86_64-normal-server-release/jdk/modules/java.base/META-INF/services/jdk.internal.jvmci.options.OptionDescriptors >>> jdk.internal.jvmci.compiler.Compiler_OptionDescriptors >>> jdk.internal.jvmci.hotspot.HotSpotConstantReflectionProvider_OptionDescriptors >>> jdk.internal.jvmci.hotspot.HotSpotResolvedJavaFieldImpl_OptionDescriptors >>> jdk.internal.jvmci.hotspot.HotSpotResolvedJavaMethodImpl_OptionDescriptors >>> jdk.internal.jvmci.compiler.Compiler_OptionDescriptors >>> jdk.internal.jvmci.hotspot.HotSpotConstantReflectionProvider_OptionDescriptors >>> jdk.internal.jvmci.hotspot.HotSpotResolvedJavaFieldImpl_OptionDescriptors >>> jdk.internal.jvmci.hotspot.HotSpotResolvedJavaMethodImpl_OptionDescriptors >>> ? >>> >>> Would this be the right fix? >>> >>> diff -r db1a815d2f6c make/gensrc/Gensrc-java.base.gmk >>> --- a/make/gensrc/Gensrc-java.base.gmkThu Sep 24 15:35:49 2015 -1000 >>> +++ b/make/gensrc/Gensrc-java.base.gmkFri Sep 25 18:18:35 2015 +0200 >>> @@ -94,6 +94,7 @@ >>> $(GENSRC_DIR)/_gensrc_proc_done >>> $(MKDIR) -p $(@D) >>> ($(CD) $(GENSRC_DIR)/META-INF/jvmci.options && \ >>> + $(RM) -f $@; \ >>> for i in $$(ls); do \ >>> echo $${i}_OptionDescriptors >> $@; \ >>> done) >>> >> That seems like a reasonable fix, yes. > Thanks, but? (see below) > >> >>> And I see the same behavior for HotSpotJVMCIBackendFactory: >>> >>> $ cat build/macosx-x86_64-normal-server-release/jdk/modules/java.base/META-INF/services/jdk.internal.jvmci.hotspot.HotSpotJVMCIBackendFactory >>> jdk.internal.jvmci.hotspot.amd64.AMD64HotSpotJVMCIBackendFactory >>> jdk.internal.jvmci.hotspot.sparc.SPARCHotSpotJVMCIBackendFactory >>> jdk.internal.jvmci.hotspot.amd64.AMD64HotSpotJVMCIBackendFactory >>> jdk.internal.jvmci.hotspot.sparc.SPARCHotSpotJVMCIBackendFactory >>> ? >>> >>> So I think a similar fix needs to be applied there. > ?I?ve look at the code that creates this file and it isn?t obvious to me how to fix it. Any good ideas? Try this: ($(CD) $(GENSRC_DIR)/META-INF/jvmci.providers && \ for i in $$($(LS)); do \ c=$$($(CAT) $$i | $(TR) -d '\n\r'); \ + $(RM) $(GENSRC_DIR)/META-INF/services/$$c; \ $(ECHO) $$i >> $(GENSRC_DIR)/META-INF/services/$$c; \ done) $(TOUCH) $@ I have not tested it but it should work. /Magnus From daniel.daugherty at oracle.com Mon Oct 5 13:31:11 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 5 Oct 2015 07:31:11 -0600 Subject: RFR (XS) 8078295 - hotspot test_env.sh can set VM_CPU incorrectly In-Reply-To: <560AE404.4050503@oracle.com> References: <560AE404.4050503@oracle.com> Message-ID: <56127B9F.308@oracle.com> On 9/29/15 1:18 PM, Ioi Lam wrote: > Please review a very small fix: > > http://cr.openjdk.java.net/~iklam/8078295_test_env_sh.01/ test/test_env.sh No comments. Thumbs up. Dan > > Bug: [TESTBUG] hotspot test_env.sh can set VM_CPU incorrectly > > https://bugs.openjdk.java.net/browse/JDK-8078295 > > Summary of fix: > > test_env.sh uses the following to get information such as VM_CPU > > ${TESTJAVA}${FS}bin${FS}java ${TESTOPTS} -Xinternalversion > > vm_version.out 2>&1 > > VM_CPU="unknown" > grep "arm" vm_version.out > ${NULL} > if [ $? = 0 ] > then > VM_CPU="arm" > fi > > However, the internal version may contain arbitrary text (from the > user name and pwd) > such as "arm", which would cause VM_CPU to have incorrect value. > > The fix is to filter out the arbitrary text using a sed script > (please see the bug report > for details and sample output): > > ${TESTJAVA}${FS}bin${FS}java ${TESTOPTS} -Xinternalversion \ > | sed -e 's/[(][^)]*[)]//g' -e 's/ by "[^"]*"//g' \ > > vm_version.out 2>&1 > > Tests: > > JPRT > RBT, with the following tests > hotspot/test/:hotspot_all > vm.parallel_class_loading.testlist > vm.regression.testlist > vm.runtime.testlist > vm.tmtools.testlist) > > Thanks > - Ioi > From aph at redhat.com Mon Oct 5 15:19:38 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 5 Oct 2015 16:19:38 +0100 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56129040.8060701@gmail.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> <56129040.8060701@gmail.com> Message-ID: <5612950A.5070203@redhat.com> On 10/05/2015 03:59 PM, Peter Levart wrote: > > On 10/05/2015 11:41 AM, Andrew Haley wrote: >> Hi Gil, >> >> On 04/10/15 17:22, Gil Tene wrote: >> >>> Summary >>> >>> Add an API that would allow Java code to hint that a spin loop is >>> being executed. >> >> I don't think this will work for ARM, which has a rather different >> spinlock mechanism. >> >> Instead of PAUSE, we wait on a lock word with WFE. WFE puts a core >> into a lightweight sleep state waiting on a particular address (the >> lock word) and a write to the lock word wakes it up. This is very >> useful and somewhat analogous to 86's MONITOR/MWAIT. >> >> I can't immediately see how to generalize your proposal to ARM, >> which is a shame. > > Just a thought... > > ARM WaitForEvent/SendEvent instructions sound like a kind of > park/unpark, but on a CPU-core-level (WFE) and global system-level > (SendEvent). Pretty much, although the wakeup is just a store. > I wonder whether it would be possible to use them to optimize the > latency of the implementation of park/unpark. The same goes for Spin > Loop Hint. Would it be possible to incorporate spin-looping in the > park/unpark implementation for x86 itself? Higher-level > synchronization constructs (like locks, synchronizers, etc..) would > then just use park/unpark and not bother with spin-looping > themselves. I spent a while thinking about that, and I'm not sure it's possible. WFE can wait for a very long time, and there is a general presumption that if a thread blocks it really should be descheduled rather than hog a core with a WFE. WFE is excellent if you have many cores (more cores than threads) and don't mind dedicating them to particular tasks: it's great for fork/join thread pools, etc, because it doesn't have the overhead of blocking and unblocking. Maybe the best thing would be a different version of park/unpark. Andrew. From xueming.shen at oracle.com Mon Oct 5 15:30:14 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 5 Oct 2015 08:30:14 -0700 Subject: RFR: String Density/Compact String JEP 254 Message-ID: <56129786.1090402@oracle.com> (resent to hotspot-dev at openjdk.java.net) Hi, Please review the change for JEP 254/Compact String project. JPE 254: http://openjdk.java.net/jeps/254 Issue: https://bugs.openjdk.java.net/browse/JDK-8054307 Webrevs: http://cr.openjdk.java.net/~sherman/8054307/jdk/ http://cr.openjdk.java.net/~thartmann/compact_strings/webrev/hotspot Description: String Density project is to change the internal representation of the String class from a UTF-16 char array to a byte array plus an encoding flag field. The new String class stores characters encoded either as ISO-8859-1/Latin-1 (one byte per character), or as UTF-16 (two bytes per character), based upon the contents of the string. The encoding flag indicates which encoding is used. It offers reduced memory footprint while maintaining throughput performance. See JEP 254 for more additional information Implementation repo/try out: http://hg.openjdk.java.net/jdk9/sandbox/ branch: JDK-8054307-branch $ hg clone http://hg.openjdk.java.net/jdk9/sandbox/ $ cd sandbox $ sh ./get_source.sh $ sh ./common/bin/hgforest.sh up -r JDK-8054307-branch $ make configure $ make images Implementation Notes: - To change the internal representation of the String and the String builder classes (AbstractStringBuilder, StringBuilder and StringBuffer) from a UTF-16 char array to a byte array plus an encoding flag field. The new representation stores the String characters in a single byte format using the lower 8-bit of character's 16-bit UTF16 value, and sets the encoding flag as LATIN1, if all characters of the String object are Unicode Latin1 characters (with its UTF16 value < \u0100) It stores the String characters in 2-byte format with their UTF-16 value and sets the flag as UTF16, if any of the character inside the String object is NOT Unicode latin1 character. - To change the method implementation of the String class and its builders to function on the new internal character storage, mainly to delegate to two implementation classes StringUTF16 and StringLatin1 - To update the StringCoding class to decoding/encoding the String between String.byte[]/coder(LATIN1/UTF16) <-> byte[](native encoding) instead of the original String.char[] <-> byte[] (native encoding) - To update the hotSpot compiler (new and updated instrinsics), GC (String Deduplication mods) and Runtime to work with the new internal "byte[] + coder flag" representation. See Tobias's note for details of the hotspot changes: http://cr.openjdk.java.net/~thartmann/compact_strings/hotspot-impl-note - To add a vm option "CompactStrings" (default is true) to provide a switch-off mechanism to always store the String characters in UTF16 encoding (always 2 bytes, but still in a byte[], instead of the original char[]). Supporting performance artifacts: - Report(s) on memory footprint impact http://cr.openjdk.java.net/~shade/density/string-density-report.pdf Latest SPECjbb2005 footprint reduction and throughput numbers for both Intel (Linux) and SPARC, in which it shows the Compact String binaries use less memory and have higher throughput. latest:http://cr.openjdk.java.net/~sherman/8054307/specjbb2005 old: http://cr.openjdk.java.net/~huntch/string-density/reports/String-Density-SPARC-jbb2005-Report.pdf - Throughput performance impact via String API micro-benchmarks http://cr.openjdk.java.net/~thartmann/compact_strings/microbenchmarks/Haswell_090915.pdf http://cr.openjdk.java.net/~thartmann/compact_strings/microbenchmarks/IvyBridge_090915.pdf http://cr.openjdk.java.net/~thartmann/compact_strings/microbenchmarks/Sparc_090915.pdf http://cr.openjdk.java.net/~sherman/8054307/string-coding.txt Thanks, Sherman From paul.sandoz at oracle.com Mon Oct 5 15:46:43 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 5 Oct 2015 17:46:43 +0200 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <561299F2.3080000@gmail.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> <56129040.8060701@gmail.com> <5612950A.5070203@redhat.com> <561299F2.3080000@gmail.com> Message-ID: > I wonder how Gil's proposed PerformanceHints.spinLoopHint() is to be called. Just before entering the spin-loop or at each iteration of the loop? The latter, e.g. see the benchmark code. > Is this some kind of CPU.yield() (by analogy to Thread.yield())? > I was wondering the same, it feels like a more vague (API abstraction-wise at least) architecture specific Thread.yield(). Paul. From kim.barrett at oracle.com Mon Oct 5 18:31:26 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 5 Oct 2015 14:31:26 -0400 Subject: RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <560DB334.5000805@oracle.com> References: <55F219CE.3010006@oracle.com> <55F319B8.1000803@oracle.com> <55F32A81.8000307@oracle.com> <55F3E484.70107@oracle.com> <55F6D878.1070903@oracle.com> <5605D02F.6070307@oracle.com> <560D5E24.4050706@oracle.com> <560D797E.9010901@oracle.com> <0E0A2899-ECC6-4065-8029-6D0A88E9F6C9@oracle.com> <560DB334.5000805@oracle.com> Message-ID: <803AAB2F-A697-4358-8B60-722BFDAD155E@oracle.com> On Oct 1, 2015, at 6:27 PM, sangheon.kim wrote: > On 10/01/2015 02:16 PM, Kim Barrett wrote: >> On Oct 1, 2015, at 2:20 PM, sangheon.kim wrote: >>> On 10/01/2015 10:52 AM, Kim Barrett wrote: >>>> On Oct 1, 2015, at 12:24 PM, sangheon.kim wrote: >>>>> Hi all, >>>>> >>>>> During this code review, newly added gc test found a problem of 1 gc constraint function(MaxGCPauseMillisConstraintFunc). >>>>> >>>>> So I updated it and related function (GCPauseIntervalMillisConstraintFunc). >>>>> - Added checking for MaxGCPauseMillis and GCPauseIntervalMillis whether these are set via commandline or not to proceed the constraint function logic. >>>>> >>>>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.03 >>>>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.03_to_02/ >>>>> >>>>> * Testing: JPRT and RBT(to manually test runtime/CommandLine for embedded) >>>> This change doesn't seem right. There is a relationship between these >>>> two values that should hold after all the argument processing is done, >>>> and it doesn't matter where the values came from. All of the >>>> FLAG_IS_CMDLINE checks (including those from earlier versions) in >>>> these constraint functions now seem questionable to me. >>>> >>>> It seems to me that if there is an unexpected test failure here, then >>>> the problem is that some "ergonomic" setting of these values is >>>> occurring after the constraint function is being called. Or >>>> alternatively, the ergnonomic settings are not right in some cases. >>> The reason of test failure is simply can't pass the constraint function. >>> The test is setting only 'MaxGCPauseMillis=30000' which means GCPauseIntervalMillis will have default value of 0(zero means set ergonomically). >>> Without constraint function, G1CollectorPolicy will set GCPauseIntervalMillis=30001. >>> No problem with the test. >>> >>> For G1, 'MaxGCPauseMillis >= GCPauseIntervalMillis' is one of the condition should be kept. >>> But the constraint function is trying to compare 30000(set via cmd line) vs. 0(default). >>> The intend of using FLAG_IS_CMDLINE() is to avoid comparison with default value which means set ergonomically. >>> >>> All other cases that using FLAG_IS_CMDLINE() is for same purpose, to avoid comparison with default value. >> The constructor for G1CollectorPolicy is responsible for some of the >> ergonomic setup, most particularly the two options in question >> (MaxGCPauseMillis and GCPauseIntervalMillis). >> >> I think that constraint functions are not supposed to be run until >> after the associated ergonomics have been applied. But the constraint >> functions for these options are being assigned to the AfterErgo group, >> which is run before the heap is created, which includes creating the >> collector policy. >> >> One possible fix might be to assign these constraint functions to the >> AfterMemoryInit group. That certainly seems appropriate for >> GCPauseIntervalMillis, which appears to be G1-specific. And since >> MaxGCPauseMillis has no additional constraints when not using G1, such >> a move would also work for it. > Right, that is also possible solution. > And I already tried this approach of changing group to AfterMemoryInit and it also works fine. > (JPRT and running TestOptionsWithRanges.java for all platforms including embedded) > But the reason of stopping this approach was current webrev.03 also can fix the problem. > In addition, personally adding more options to AfterMemoryInit group seems weakening validation framework as sooner validation check seems better for me. For this case, I don't think they are weakening though. > But I don't have strong opinion on this. My understanding was that the rationale for the different constraint groups was to allow for options that are "finalized" at different stages of the initialization process, so that the constraints would be applied to the "final" values (subject to later management-API-based modifications). I think that the webrev.03 approach (using FLAG_IS_CMDLINE in the constraint function) tightly couples the constraint function with the (textually distant) ergonomics implementation in a way that I'm not very comfortable with. I also think that in that form it could be moved to the AtParse category. In fact, it seems likely that we could rewrite all of the constraint functions in this style, in which case why do we have the different constraint category stages? > I can revert to webrev.02 and change groups to AfterMemoryInit. I would prefer that. >> But this discussion is making me question all of the FLAG_IS_xxx uses >> in commandLineFlagConstraintsGC.cpp. > For some options, they are automatically added to validate. > (e.g. SurvivorRatio for CMS GC ) > So FLAG_IS_xxx is needed for some cases. The (pre-existing) ergonomics around SurvivorRatio seem quite strange to me. Why is the behavior be different when the value is defaulted vs when it is explicitly specified with the same value as the default? I don't expect anything to be done about this right now, but I think this does help make the case for using FLAG_IS_CMDLINE in the pause time options under discussion. From kim.barrett at oracle.com Mon Oct 5 19:28:56 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 5 Oct 2015 15:28:56 -0400 Subject: RFR: 8138659: Speed up InstanceKlass subclass discrimination In-Reply-To: <56122EBE.30608@oracle.com> References: <56122EBE.30608@oracle.com> Message-ID: <81333756-68F6-4C23-9906-0A790E6630F0@oracle.com> On Oct 5, 2015, at 4:03 AM, Stefan Karlsson wrote: > On 2015-10-03 20:26, Kim Barrett wrote: >> Please review this change to speed up discrimination among the classes >> rooted at InstanceKlass. >> >> [?] >> Changed calls to Klass::oop_is_instanceXXX to instead call >> Klass::oop_is_instance then cast to InstanceKlass and use the >> corresponding kind_is_xxx predicate. Removed the no longer used >> Klass::oop_is_instanceXXX functions. >> >> [?] >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8138659 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8138659/webrev.00/ > > Did you consider keeping the "kind" infrastructure within the instanceKlass files instead of letting it leak down into oop.inline.hpp and out to the rest of the runtime? > > - virtual bool oop_is_instanceClassLoader() const { return false; } > - virtual bool oop_is_instanceMirror() const { return false; } > - virtual bool oop_is_instanceRef() const { return false; } > > > Could be: > > bool oop_is_instanceClassLoader() const { return oop_is_instance() && InstanceKlass::cast(k)->oop_is_class_loader(); } > bool oop_is_instanceMirror() const { return oop_is_instance() && InstanceKlass::cast(k)->oop_is_mirror(); } > bool oop_is_instanceRef() const { return oop_is_instance() && InstanceKlass::cast(k)->oop_is_reference(); } Thanks for looking at this. I did think about it. It's a bit fishy for Klass to have such knowlege about InstanceKlass, though I'd have held my nose if the dispatch could have been put entirely in Klass. Coleen expressed a similar dislike of the Klass::oop_is_instanceXXX functions when we talked about this change. There's also the technical difficulty that this introduces a circular dependency between Klass and InstanceKlass. I think it might work today to have klass.inline.hpp #include instanceKlass.hpp, but that would be quite fragile. Or the definitions of the Klass::oop_is_instanceXXX functions could be moved to klass.cpp, giving up on inlining them. So even ignoring semantic issues, there are syntactic problems. > Other than that, this looks good to me. > > StefanK > >> >> Testing: >> JPRT >> Aurora ad-hoc defaults + GC Nightly + Runtime Nightly From coleen.phillimore at oracle.com Mon Oct 5 19:54:14 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 05 Oct 2015 15:54:14 -0400 Subject: RFR: 8138659: Speed up InstanceKlass subclass discrimination In-Reply-To: <81333756-68F6-4C23-9906-0A790E6630F0@oracle.com> References: <56122EBE.30608@oracle.com> <81333756-68F6-4C23-9906-0A790E6630F0@oracle.com> Message-ID: <5612D566.9050700@oracle.com> On 10/5/15 3:28 PM, Kim Barrett wrote: > On Oct 5, 2015, at 4:03 AM, Stefan Karlsson wrote: >> On 2015-10-03 20:26, Kim Barrett wrote: >>> Please review this change to speed up discrimination among the classes >>> rooted at InstanceKlass. >>> >>> [?] >>> Changed calls to Klass::oop_is_instanceXXX to instead call >>> Klass::oop_is_instance then cast to InstanceKlass and use the >>> corresponding kind_is_xxx predicate. Removed the no longer used >>> Klass::oop_is_instanceXXX functions. >>> >>> [?] >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8138659 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~kbarrett/8138659/webrev.00/ >> Did you consider keeping the "kind" infrastructure within the instanceKlass files instead of letting it leak down into oop.inline.hpp and out to the rest of the runtime? >> >> - virtual bool oop_is_instanceClassLoader() const { return false; } >> - virtual bool oop_is_instanceMirror() const { return false; } >> - virtual bool oop_is_instanceRef() const { return false; } >> >> >> Could be: >> >> bool oop_is_instanceClassLoader() const { return oop_is_instance() && InstanceKlass::cast(k)->oop_is_class_loader(); } >> bool oop_is_instanceMirror() const { return oop_is_instance() && InstanceKlass::cast(k)->oop_is_mirror(); } >> bool oop_is_instanceRef() const { return oop_is_instance() && InstanceKlass::cast(k)->oop_is_reference(); } > Thanks for looking at this. > > I did think about it. > > It's a bit fishy for Klass to have such knowlege about InstanceKlass, > though I'd have held my nose if the dispatch could have been put > entirely in Klass. Coleen expressed a similar dislike of the > Klass::oop_is_instanceXXX functions when we talked about this change. Yes, this was my opinion. I didn't think Klass needs to know what sort of InstanceKlasses there are. Coleen > > There's also the technical difficulty that this introduces a circular > dependency between Klass and InstanceKlass. I think it might work > today to have klass.inline.hpp #include instanceKlass.hpp, but that > would be quite fragile. Or the definitions of the > Klass::oop_is_instanceXXX functions could be moved to klass.cpp, > giving up on inlining them. So even ignoring semantic issues, there > are syntactic problems. > >> Other than that, this looks good to me. >> >> StefanK >> >>> Testing: >>> JPRT >>> Aurora ad-hoc defaults + GC Nightly + Runtime Nightly > From coleen.phillimore at oracle.com Mon Oct 5 20:02:31 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 05 Oct 2015 16:02:31 -0400 Subject: RFR: 8138659: Speed up InstanceKlass subclass discrimination In-Reply-To: References: Message-ID: <5612D757.5040905@oracle.com> In http://cr.openjdk.java.net/~kbarrett/8138659/webrev.00/src/share/vm/oops/instanceKlass.hpp.udiff.html There are right_n_bits() and bitfield functions in globalDefinitions.hpp that would make some bit manipulation in this set_kind() easier to read. Minor comment: I'd put kind_is_instance() .. kind_is_class_loader() functions on one line each and not use so much vertical space. This is all I have to comment. It looks like a good change to me. Coleen On 10/3/15 2:26 PM, Kim Barrett wrote: > Please review this change to speed up discrimination among the classes > rooted at InstanceKlass. > > We use 2 bits from InstanceKlass::_misc_flags (the _misc_kind field) > for discrimination among the four kinds of InstanceKlass. We use the > low 2 bits of _misc_flags to avoid a shift when accessing the field. > This means that all the existing flags are being shifted up 2 bits. > Added an accessor and a suite of predicates to InstanceKlass. Added > kind argument to InstanceKlass constructor, which is used to set the > _misc_kind field. Updated all callers to provide the appropriate > value. > > With these changes we can use the layout_helper-based > Klass::oop_is_instance to get to the InstanceKlass case, and use the > _misc_kind value to further discriminate from there. In particular, > the concrete InstanceKlass case is (after inlining) > > (klass->_layout_helper > 0) && > ((static_cast(klass)->_misc_flags & 3) == 0) > > We could do better with a single discriminator, but there doesn't > appear to be a good place to add such in Klass, and we don't want to > make Klass bigger. > > Changed calls to Klass::oop_is_instanceXXX to instead call > Klass::oop_is_instance then cast to InstanceKlass and use the > corresponding kind_is_xxx predicate. Removed the no longer used > Klass::oop_is_instanceXXX functions. > > Removed unused InstanceRefKlass::cast. InstanceMirrorKlass::cast is > retained because it is used. InstanceClassLoaderKlass::cast does not > exist. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8138659 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8138659/webrev.00/ > > Testing: > JPRT > Aurora ad-hoc defaults + GC Nightly + Runtime Nightly > From sangheon.kim at oracle.com Mon Oct 5 20:35:57 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Mon, 5 Oct 2015 13:35:57 -0700 Subject: RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <803AAB2F-A697-4358-8B60-722BFDAD155E@oracle.com> References: <55F219CE.3010006@oracle.com> <55F319B8.1000803@oracle.com> <55F32A81.8000307@oracle.com> <55F3E484.70107@oracle.com> <55F6D878.1070903@oracle.com> <5605D02F.6070307@oracle.com> <560D5E24.4050706@oracle.com> <560D797E.9010901@oracle.com> <0E0A2899-ECC6-4065-8029-6D0A88E9F6C9@oracle.com> <560DB334.5000805@oracle.com> <803AAB2F-A697-4358-8B60-722BFDAD155E@oracle.com> Message-ID: <5612DF2D.1090502@oracle.com> On 10/05/2015 11:31 AM, Kim Barrett wrote: > On Oct 1, 2015, at 6:27 PM, sangheon.kim wrote: >> On 10/01/2015 02:16 PM, Kim Barrett wrote: >>> On Oct 1, 2015, at 2:20 PM, sangheon.kim wrote: >>>> On 10/01/2015 10:52 AM, Kim Barrett wrote: >>>>> On Oct 1, 2015, at 12:24 PM, sangheon.kim wrote: >>>>>> Hi all, >>>>>> >>>>>> During this code review, newly added gc test found a problem of 1 gc constraint function(MaxGCPauseMillisConstraintFunc). >>>>>> >>>>>> So I updated it and related function (GCPauseIntervalMillisConstraintFunc). >>>>>> - Added checking for MaxGCPauseMillis and GCPauseIntervalMillis whether these are set via commandline or not to proceed the constraint function logic. >>>>>> >>>>>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.03 >>>>>> http://cr.openjdk.java.net/~sangheki/8134995/webrev.03_to_02/ >>>>>> >>>>>> * Testing: JPRT and RBT(to manually test runtime/CommandLine for embedded) >>>>> This change doesn't seem right. There is a relationship between these >>>>> two values that should hold after all the argument processing is done, >>>>> and it doesn't matter where the values came from. All of the >>>>> FLAG_IS_CMDLINE checks (including those from earlier versions) in >>>>> these constraint functions now seem questionable to me. >>>>> >>>>> It seems to me that if there is an unexpected test failure here, then >>>>> the problem is that some "ergonomic" setting of these values is >>>>> occurring after the constraint function is being called. Or >>>>> alternatively, the ergnonomic settings are not right in some cases. >>>> The reason of test failure is simply can't pass the constraint function. >>>> The test is setting only 'MaxGCPauseMillis=30000' which means GCPauseIntervalMillis will have default value of 0(zero means set ergonomically). >>>> Without constraint function, G1CollectorPolicy will set GCPauseIntervalMillis=30001. >>>> No problem with the test. >>>> >>>> For G1, 'MaxGCPauseMillis >= GCPauseIntervalMillis' is one of the condition should be kept. >>>> But the constraint function is trying to compare 30000(set via cmd line) vs. 0(default). >>>> The intend of using FLAG_IS_CMDLINE() is to avoid comparison with default value which means set ergonomically. >>>> >>>> All other cases that using FLAG_IS_CMDLINE() is for same purpose, to avoid comparison with default value. >>> The constructor for G1CollectorPolicy is responsible for some of the >>> ergonomic setup, most particularly the two options in question >>> (MaxGCPauseMillis and GCPauseIntervalMillis). >>> >>> I think that constraint functions are not supposed to be run until >>> after the associated ergonomics have been applied. But the constraint >>> functions for these options are being assigned to the AfterErgo group, >>> which is run before the heap is created, which includes creating the >>> collector policy. >>> >>> One possible fix might be to assign these constraint functions to the >>> AfterMemoryInit group. That certainly seems appropriate for >>> GCPauseIntervalMillis, which appears to be G1-specific. And since >>> MaxGCPauseMillis has no additional constraints when not using G1, such >>> a move would also work for it. >> Right, that is also possible solution. >> And I already tried this approach of changing group to AfterMemoryInit and it also works fine. >> (JPRT and running TestOptionsWithRanges.java for all platforms including embedded) >> But the reason of stopping this approach was current webrev.03 also can fix the problem. >> In addition, personally adding more options to AfterMemoryInit group seems weakening validation framework as sooner validation check seems better for me. For this case, I don't think they are weakening though. >> But I don't have strong opinion on this. > My understanding was that the rationale for the different constraint > groups was to allow for options that are "finalized" at different > stages of the initialization process, so that the constraints would be > applied to the "final" values (subject to later management-API-based > modifications). > > I think that the webrev.03 approach (using FLAG_IS_CMDLINE in the > constraint function) tightly couples the constraint function with the > (textually distant) ergonomics implementation in a way that I'm not > very comfortable with. I also think that in that form it could be > moved to the AtParse category. In fact, it seems likely that we could > rewrite all of the constraint functions in this style, in which case > why do we have the different constraint category stages? > >> I can revert to webrev.02 and change groups to AfterMemoryInit. > I would prefer that. Okay, I will revert to webrev.02 and change the group to AfterMemoryInit. > >>> But this discussion is making me question all of the FLAG_IS_xxx uses >>> in commandLineFlagConstraintsGC.cpp. >> For some options, they are automatically added to validate. >> (e.g. SurvivorRatio for CMS GC ) >> So FLAG_IS_xxx is needed for some cases. > The (pre-existing) ergonomics around SurvivorRatio seem quite strange > to me. Why is the behavior be different when the value is defaulted > vs when it is explicitly specified with the same value as the default? SurvivorRatio is a little bit special as it will be automatically validated and its default value is 8. And this behavior would make hard to constraint function to decide. For example, when we set 4m of heap for G1, the SurvivorRatio is 8 but we have only 4 regions from default setting. In this case, without FLAG_IS_xxx it is hard to decide whether the result is FAIL or SUCCESS. And I think it is okay in this case. This is why explicitly specified option is only validated. > > I don't expect anything to be done about this right now, but I think > this does help make the case for using FLAG_IS_CMDLINE in the pause > time options under discussion. Okay. I agreed to revert to webrev.02 + changing group. What is next? :) Thanks, Sangheon > From gil at azulsystems.com Mon Oct 5 20:43:18 2015 From: gil at azulsystems.com (Gil Tene) Date: Mon, 5 Oct 2015 20:43:18 +0000 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <561245E0.8030708@redhat.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> Message-ID: I see SpinLoopHint as very separate from things like MONITOR/WAIT (on x86) and WFE/SEV (on ARM), as well as any other "wait in a nice way until this state changes" instructions that other architectures may have or add. Mechanisms like MONITOR/WAIT and WFE/SEV provide a way to potentially wait for specific state changes to occur. As such, they can be used to implement a specific form of a spin loop (the most common one, probably). But they do not provide for generic spinning forms. E.g. loops that have multiple exit conditions in different memory locations, loops that wait on internal state changes that are no affected by other CPUs (like "spin only this many times before giving up" or "spin for this much time"), and loops that may use transactional state changes (e.g. LOCK XADD, or wider things with TSX) are probably "hard" to model with these instructions. In contrast, spinLoopHint() is intended to hint that the loop it is in is spinning, regardless of the logic used for the spinning or the spin termination. It is useful, for example, in heuristic spinning-before-blocking situations, where WFE/SEV MONITOR/WAIT would not be appropriate. MONITOR/MWAIT and WFE/SEV would be a good way to implement an actual spinning test or atomic operation (if it were available in user mode, but alas it isn't). And I could see some variant of AtomicX.CompareAndSet being proposed to use them, but the semantics and context are different. There are at least two architectures for which spinLoophint() is both a natural fit as well as the way everything else (kernels, libraries) seem to be spinning: In x86, the PAUSE instruction is a classic example of the spinLoopHint() use case. On some PowerPC implementations with multiple hardware threads (HMT), a lowering of the hardware thread priority is probably another example of a good use for spinLoopHint() [I haven't tried or tested this for spinLoopHint(), but that's what the linux kernel spinloops do for example: http://lxr.free-electrons.com/source/arch/powerpc/include/asm/spinlock.h?v=2.6.35#L116]. On some CPUs there might not (or not yet) be equivalent operation. A nop would be a valid way to implement it on current ARM. ? Gil. > On Oct 5, 2015, at 2:41 AM, Andrew Haley wrote: > > Hi Gil, > > On 04/10/15 17:22, Gil Tene wrote: > >> Summary >> >> Add an API that would allow Java code to hint that a spin loop is >> being executed. > > > I don't think this will work for ARM, which has a rather different > spinlock mechanism. > > Instead of PAUSE, we wait on a lock word with WFE. WFE puts a core > into a lightweight sleep state waiting on a particular address (the > lock word) and a write to the lock word wakes it up. This is very > useful and somewhat analogous to 86's MONITOR/MWAIT. > > I can't immediately see how to generalize your proposal to ARM, which > is a shame. > > Andrew. > From gil at azulsystems.com Mon Oct 5 21:01:47 2015 From: gil at azulsystems.com (Gil Tene) Date: Mon, 5 Oct 2015 21:01:47 +0000 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56123D16.4070800@oracle.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <56123D16.4070800@oracle.com> Message-ID: > On Oct 5, 2015, at 2:04 AM, Alan Bateman wrote: > > On 04/10/2015 17:22, Gil Tene wrote: >> I would like to circulate this draft JEP proposal for initial review and consensus building purposes. >> >> I'm cross-posting to both core-libs-dev and hotspot-dev. From a spec perspective, the main change it suggests is the addition of a method (and probably a class to hold it) to the core libraries. And intrinsifying implementations would involve changes in HotSpot (see prototype WebRev links included below). >> >> Draft JEP follows inline... >> >> ? Gil. >> > I don't see any mention in the JEP about existing mechanisms to give hints to the runtime, as in @Contended (JEP 142) and @HotSpotIntrinsicCandidate (JDK-8076112). Just wondering if there is an alternative to explore where something like @Spinloop int ignore; would emit the PAUSE. This would at least give a starting point for usages in the JDK. The bigger question is whether to expose such runtime hints in an API. It's very much for the advanced developer and if an API is really needed then it might be something for a JDK-specific API. Alan, The JEP is not about performance hints in general, it's about (and only about) spin loop hints. While there are many "spelling" options possible, I don't think annotations will fit well. The needs of a spinLoopHint seem to be very different from those of the @Contended and @HotSpotIntrinsicCandidate in several way. Annotations have limited places in code where they can be applied. Specifically, they apply to declarations but not to execution. E.g. "@SpinLoop int ignore;" is a declaration: it does not emit any bytecodes. Without actually using the variable "ignore" later in the code, there would be no way to link it to code. The place where actual byte-codes are emitted would need to tie in to the declared variable, which would probably make the "spelling" more cumbersome than a trivial method call (with a hopefully self-explanatory name). ? Gil. From kim.barrett at oracle.com Mon Oct 5 21:06:45 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 5 Oct 2015 17:06:45 -0400 Subject: RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <5612DF2D.1090502@oracle.com> References: <55F219CE.3010006@oracle.com> <55F319B8.1000803@oracle.com> <55F32A81.8000307@oracle.com> <55F3E484.70107@oracle.com> <55F6D878.1070903@oracle.com> <5605D02F.6070307@oracle.com> <560D5E24.4050706@oracle.com> <560D797E.9010901@oracle.com> <0E0A2899-ECC6-4065-8029-6D0A88E9F6C9@oracle.com> <560DB334.5000805@oracle.com> <803AAB2F-A697-4358-8B60-722BFDAD155E@oracle.com> <5612DF2D.1090502@oracle.com> Message-ID: <32F8A741-7E5B-4E06-BEE7-3EE7D2192E63@oracle.com> On Oct 5, 2015, at 4:35 PM, sangheon.kim wrote: > > On 10/05/2015 11:31 AM, Kim Barrett wrote: >>> I can revert to webrev.02 and change groups to AfterMemoryInit. >> I would prefer that. > Okay, I will revert to webrev.02 and change the group to AfterMemoryInit. Thanks. >>>> But this discussion is making me question all of the FLAG_IS_xxx uses >>>> in commandLineFlagConstraintsGC.cpp. >>> For some options, they are automatically added to validate. >>> (e.g. SurvivorRatio for CMS GC ) >>> So FLAG_IS_xxx is needed for some cases. >> The (pre-existing) ergonomics around SurvivorRatio seem quite strange >> to me. Why is the behavior be different when the value is defaulted >> vs when it is explicitly specified with the same value as the default? > SurvivorRatio is a little bit special as it will be automatically validated and its default value is 8. > And this behavior would make hard to constraint function to decide. > For example, when we set 4m of heap for G1, the SurvivorRatio is 8 but we have only 4 regions from default setting. > In this case, without FLAG_IS_xxx it is hard to decide whether the result is FAIL or SUCCESS. > And I think it is okay in this case. > This is why explicitly specified option is only validated. So the ?default" value isn?t *really* the default, but more of a suggested value to use if it would work and is not overridden from the command line. Specifying the purported default value explicitly and getting different behavior would, for me, violate the principal of least surprise. The present implementation also violates the ?rule? that when there is a default that can be overridden, there should always be a way to explicitly request the default. But none of this really has anything to do with 8134995. >> I don't expect anything to be done about this right now, but I think >> this does help make the case for using FLAG_IS_CMDLINE in the pause >> time options under discussion. Drat. I meant ?? this does *not* help make the case ?? > I agreed to revert to webrev.02 + changing group. > What is next? :) Nothing that I know of. I think you?re good to go. From gil at azulsystems.com Sun Oct 4 16:22:51 2015 From: gil at azulsystems.com (Gil Tene) Date: Sun, 4 Oct 2015 16:22:51 +0000 Subject: Spin Loop Hint support: Draft JEP proposal Message-ID: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> I would like to circulate this draft JEP proposal for initial review and consensus building purposes. I'm cross-posting to both core-libs-dev and hotspot-dev. From a spec perspective, the main change it suggests is the addition of a method (and probably a class to hold it) to the core libraries. And intrinsifying implementations would involve changes in HotSpot (see prototype WebRev links included below). Draft JEP follows inline... ? Gil. JEP XYZ: Spin Loop Hint (suggested content for some JEP fields): Authors Gil Tene Owner Gil Tene Type Feature Status Draft Component core-libs Scope JDK Discussion core dash libs dash dev at openjdk dot java dot net Effort S Duration S Summary Add an API that would allow Java code to hint that a spin loop is being executed. Goals Provide an API that would allow Java code to hint to the runtime that it is in a spin loop. The API would be a pure hint, and will carry no semantic behavior requirements (i.e. a no-op is a valid implementation). Allow the JVM to benefit from spin loop specific behaviors that may be useful on certain hardware platforms. Provide both a no-op implementation and an intrinsic implementation in the JDK, and demonstrate an execution benefit on at least one major hardware platform. Non-Goals It is NOT a goal to look at performance hints beyond spin loops. Other performance hints, such as prefetch hints, are outside the scope of this JEP. Motivation Some hardware platforms benefit from software indication that a spin loop is in progress. Some common execution benefits may be observed: A) The reaction time of a spin loop may be improved when a spin hint is used due to various factors, reducing thread-to-thread latencies in spinning wait situations. and B) The power consumed by the core or hardware thread involved in the spin loop may be reduced, benefitting overall power consumption of a program, and possibly allowing other cores or hardware threads to execute at faster speeds within the same power consumption envelope. While long term spinning is often discouraged as a general user-mode programming practice, short term spinning prior to blocking is a common practice (both inside and outside of the JDK). Furthermore, as core-rich computing platforms are commonly available, many performance and/or latency sensitive applications use a pattern that dedicates a spinning thread to a latency critical function [1], and may involve long term spinning as well. As a practical example and use case, current x86 processors support a PAUSE instruction that can be used to indicate spinning behavior. Using a PAUSE instruction demonstrably reduces thread-to-thread round trips. Due to it's benefits and commonly recommended use, the x86 PAUSE instruction is commonly used in kernel spinlocks, in POSIX libraries that perform heuristic spins prior to blocking, and even by the JVM itself. However, due to the inability to hint that a Java loop is spinning, it's benefits are not available to regular Java code. We include specific supporting evidence: In simple tests [2] performed on a E5-2697 v2, measuring the round trip latency behavior between two threads that communicate by spinning on a volatile field, round-trip latencies were demonstrably reduced by 18-20nsec across a wide percentile spectrum (from the 10%'ile to the 99.9%'ile). This reduction can represent an improvement as high as 35%-50% in best-case thread-to-thread communication latency. E.g. when two spinning threads execute on two hardware threads that share a physical CPU core and an L1 data cache. See example latency measurement results comparing the reaction latency of a spin loop that includes an intrinsified spinLoopHint() call [intrinsified as a PAUSE instruction] to the same loop executed without using a PAUSE instruction [3], along with the measurements of the it takes to perform an actual System.nantoTime() call to measure time. Description We propose to add a method to the JDK which would be hint that a spin loop is being performed. E.g. jdk.util.PerformanceHints.spinLoopHint(), which will hopefully evolve to a Java SE API, e.g. java.util.PerformanceHints.spinLoopHint(). The specific name space location, class name, and method name will be determined as part of development of this JEP. An empty method would be a valid implementation of the spinLoopHint() method, but intrisic implementation is the obvious goal for hardware platforms that can benefit from it. We intend to produce an intrinsic x86 implementation for OpenJDK as part of developing this JEP. A prototype implementation already exists [4] [5] [6] [7] and results from initial testing show promise. Alternatives JNI can be used to spin loop with a spin-loop-hinting CPU instruction, but the JNI-boundary crossing overhead tends to be larger than the benefit provided by the instruction, at least where latency is concerned. We could attempt to have the JIT compilers deduce spin-loop situations and code and choose to automatically include a spin-loop-hinting CPU instructions with no Java code hints required. We expect that the complexity of automatically and reliably detecting spinning situations, coupled with questions about potential tradeoffs in using the hints on some platform to delay the availability of viable implementations significantly. Testing Testing of a "vanilla" no-op implementation will obviously be fairly simple. We believe that given the vey small footprint of this API, testing of an intrinsified x86 implementation in OpenJDK will also be straightforward. We expect testing to focus on confirming both the code generation correctness and latency benefits of using the spin loop hint with an intrinsic implementation. Should this API be proposed as a Java SE API (e.g. for inclusion in the java.* namespace in a future Java SE 9 or Java SE 10), we expect to develop an associated TCK tests for the API for potential inclusion in the Java SE TCK. Risks and Assumptions The "vanilla" no-op implementation is obviously fairly low risk. An intrinsic x86 implementation will involve modifications to multiple JVM components and as such they carry some risks, but no more than other simple intrinsics added to the JDK. [1] The LMAX Disruptor https://lmax-exchange.github.io/disruptor/ [2] https://github.com/giltene/GilExamples/tree/master/SpinHintTest [3] Chart depicting SpinLoopHint intrinsification impact https://github.com/giltene/GilExamples/blob/master/SpinHintTest/SpinLoopLatency_E5-2697v2_sharedCore.png [4] HotSpot WebRevs for prototype implementation which intrinsifies org.performancehintsSpinHint.spinLoopHint() http://ivankrylov.github.io/spinloophint/webrev/ [5] JDK WebRevs for prototype intrinsifying implementation: http://ivankrylov.github.io/spinloophint/webrev.jdk/ [6] Build environment WebRevs for prototype intrinsifying implementation: http://ivankrylov.github.io/spinloophint/webrev.main/ [7] Link to a working Linux protoype OpenJDK9-based JDK (accepts optional -XX:+UseSpinLoopHintIntrinsic) https://www.dropbox.com/s/r2w1s1jykr2qs01/slh-openjdk-9-b70-bin-linux-x64.tar.gz?dl=0 From sangheon.kim at oracle.com Mon Oct 5 21:45:06 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Mon, 5 Oct 2015 14:45:06 -0700 Subject: RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <32F8A741-7E5B-4E06-BEE7-3EE7D2192E63@oracle.com> References: <55F219CE.3010006@oracle.com> <55F319B8.1000803@oracle.com> <55F32A81.8000307@oracle.com> <55F3E484.70107@oracle.com> <55F6D878.1070903@oracle.com> <5605D02F.6070307@oracle.com> <560D5E24.4050706@oracle.com> <560D797E.9010901@oracle.com> <0E0A2899-ECC6-4065-8029-6D0A88E9F6C9@oracle.com> <560DB334.5000805@oracle.com> <803AAB2F-A697-4358-8B60-722BFDAD155E@oracle.com> <5612DF2D.1090502@oracle.com> <32F8A741-7E5B-4E06-BEE7-3EE7D2192E63@oracle.com> Message-ID: <5612EF62.50301@oracle.com> On 10/05/2015 02:06 PM, Kim Barrett wrote: > On Oct 5, 2015, at 4:35 PM, sangheon.kim wrote: >> On 10/05/2015 11:31 AM, Kim Barrett wrote: >>>> I can revert to webrev.02 and change groups to AfterMemoryInit. >>> I would prefer that. >> Okay, I will revert to webrev.02 and change the group to AfterMemoryInit. > Thanks. > >>>>> But this discussion is making me question all of the FLAG_IS_xxx uses >>>>> in commandLineFlagConstraintsGC.cpp. >>>> For some options, they are automatically added to validate. >>>> (e.g. SurvivorRatio for CMS GC ) >>>> So FLAG_IS_xxx is needed for some cases. >>> The (pre-existing) ergonomics around SurvivorRatio seem quite strange >>> to me. Why is the behavior be different when the value is defaulted >>> vs when it is explicitly specified with the same value as the default? >> SurvivorRatio is a little bit special as it will be automatically validated and its default value is 8. >> And this behavior would make hard to constraint function to decide. >> For example, when we set 4m of heap for G1, the SurvivorRatio is 8 but we have only 4 regions from default setting. >> In this case, without FLAG_IS_xxx it is hard to decide whether the result is FAIL or SUCCESS. >> And I think it is okay in this case. >> This is why explicitly specified option is only validated. > So the ?default" value isn?t *really* the default, but more of a suggested value to use > if it would work and is not overridden from the command line. Specifying the purported > default value explicitly and getting different behavior would, for me, violate the principal > of least surprise. Yes, it is strange. > The present implementation also violates the ?rule? that when there is > a default that can be overridden, there should always be a way to explicitly request the > default. If you are talking about we should have a way to get the default value of an option(even though the option's value is changed, need a way to get the previous default value), yes it would be nice to have. > But none of this really has anything to do with 8134995. > >>> I don't expect anything to be done about this right now, but I think >>> this does help make the case for using FLAG_IS_CMDLINE in the pause >>> time options under discussion. > Drat. I meant ?? this does *not* help make the case ?? :) > >> I agreed to revert to webrev.02 + changing group. >> What is next? :) > Nothing that I know of. I think you?re good to go. Okay, thanks! Here's next webrev: http://cr.openjdk.java.net/~sangheki/8134995/webrev.04 http://cr.openjdk.java.net/~sangheki/8134995/webrev.04_to_03 Thanks, Sangheon > From kim.barrett at oracle.com Tue Oct 6 00:46:50 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 5 Oct 2015 20:46:50 -0400 Subject: RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <5612EF62.50301@oracle.com> References: <55F219CE.3010006@oracle.com> <55F319B8.1000803@oracle.com> <55F32A81.8000307@oracle.com> <55F3E484.70107@oracle.com> <55F6D878.1070903@oracle.com> <5605D02F.6070307@oracle.com> <560D5E24.4050706@oracle.com> <560D797E.9010901@oracle.com> <0E0A2899-ECC6-4065-8029-6D0A88E9F6C9@oracle.com> <560DB334.5000805@oracle.com> <803AAB2F-A697-4358-8B60-722BFDAD155E@oracle.com> <5612DF2D.1090502@oracle.com> <32F8A741-7E5B-4E06-BEE7-3EE7D2192E63@oracle.com> <5612EF62.50301@oracle.com> Message-ID: <2B6845FB-ECA7-4EBE-AC16-0BE87520529A@oracle.com> On Oct 5, 2015, at 5:45 PM, sangheon.kim wrote: > > On 10/05/2015 02:06 PM, Kim Barrett wrote: >> On Oct 5, 2015, at 4:35 PM, sangheon.kim wrote: > Here's next webrev: > http://cr.openjdk.java.net/~sangheki/8134995/webrev.04 > http://cr.openjdk.java.net/~sangheki/8134995/webrev.04_to_03 I think there is still at least a potential for problems around the use of FLAG_IS_CMDLINE in the constraint functions, but I don?t see an actual problem at this time. Another issue besides those I?ve mentioned before is that if the constraint is only active when FLAG_IS_CMDLINE and no command line option was given, but the option is manageable and later set through that interface, I think the constraint won?t check the new value being provided. However, none of the options with new constraint functions using FLAG_IS_CMDLINE are manageable, so I think there?s no immediate problem on that score. But there should be an RFE to follow up in this area. So looks good to me. From gil at azulsystems.com Tue Oct 6 04:32:43 2015 From: gil at azulsystems.com (Gil Tene) Date: Tue, 6 Oct 2015 04:32:43 +0000 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56123B47.4070706@oracle.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <56123B47.4070706@oracle.com> Message-ID: <9FD5F6D1-2875-469C-B4C1-5F7ED0740084@azulsystems.com> > On Oct 5, 2015, at 1:56 AM, Aleksey Shipilev wrote: > > Hi Gil, > > Glad to see this being addressed! > > On 10/04/2015 07:22 PM, Gil Tene wrote: >> We propose to add a method to the JDK which would be hint that a spin >> loop is being performed. E.g. >> jdk.util.PerformanceHints.spinLoopHint(), which will hopefully evolve >> to a Java SE API, e.g. java.util.PerformanceHints.spinLoopHint(). The >> specific name space location, class name, and method name will be >> determined as part of development of this JEP. > > Yes, that would be a tough part. JDK is usually oblivious of these > low-level platform-specific hints, they go to sun.misc.* (e.g. Unsafe, > @Contended and others...). I'll let Project Leads to make that call :) I don't think of this as platform specific. And it's not much lower level than e.g. some java.util.concurrent stuff (but probably doesn't belong in that package because it's not really about concurrency). I'm looking for a proper Java SE spec'ed way to do this. So sun.misc.* won't work. I'm sure we don't want another Unsafe for people to abuse... But naming the class and method is the smaller, easier detail. Right? ;-) > >> [4] HotSpot WebRevs for prototype implementation which intrinsifies >> org.performancehintsSpinHint.spinLoopHint() >> http://ivankrylov.github.io/spinloophint/webrev/ >> > > * product_pd (platform-dependent) flags can be used to conditionalize > the support on a platform. This helps to avoid vm_version_* tricks. Thx. > * Does spinloophint imply membar as well? x86_64.ad suggests so. > library_call.cpp suggests so. It seems weird to conflate the two, even > though it's understandable you want to piggyback on existing machinery. Semantically. spinLoopHint() has zero semantic requirements, and therefore no implied behavior of any kind (no membar). We implemented the pause intrinsic as a variant representation of a membar because that was one relatively simple way of having it stay within the loop (or with whatever control flow it is under). The "membar" variant implementation doesn't prohibit reordering of loads or stores. > > * I think spinLoopHint() misses a @HotspotIntrinsicCandidate annotation. Will add that in future prototypes. > Thanks, > -Aleksey > From sangheon.kim at oracle.com Tue Oct 6 06:19:43 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Mon, 5 Oct 2015 23:19:43 -0700 Subject: RFR 8134995(M): [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <2B6845FB-ECA7-4EBE-AC16-0BE87520529A@oracle.com> References: <55F219CE.3010006@oracle.com> <55F319B8.1000803@oracle.com> <55F32A81.8000307@oracle.com> <55F3E484.70107@oracle.com> <55F6D878.1070903@oracle.com> <5605D02F.6070307@oracle.com> <560D5E24.4050706@oracle.com> <560D797E.9010901@oracle.com> <0E0A2899-ECC6-4065-8029-6D0A88E9F6C9@oracle.com> <560DB334.5000805@oracle.com> <803AAB2F-A697-4358-8B60-722BFDAD155E@oracle.com> <5612DF2D.1090502@oracle.com> <32F8A741-7E5B-4E06-BEE7-3EE7D2192E63@oracle.com> <5612EF62.50301@oracle.com> <2B6845FB-ECA7-4EBE-AC16-0BE87520529A@oracle.com> Message-ID: <561367FF.1090406@oracle.com> On 10/05/2015 05:46 PM, Kim Barrett wrote: > On Oct 5, 2015, at 5:45 PM, sangheon.kim wrote: >> On 10/05/2015 02:06 PM, Kim Barrett wrote: >>> On Oct 5, 2015, at 4:35 PM, sangheon.kim wrote: >> Here's next webrev: >> http://cr.openjdk.java.net/~sangheki/8134995/webrev.04 >> http://cr.openjdk.java.net/~sangheki/8134995/webrev.04_to_03 > I think there is still at least a potential for problems around the use of FLAG_IS_CMDLINE in > the constraint functions, but I don?t see an actual problem at this time. Another issue besides > those I?ve mentioned before is that if the constraint is only active when FLAG_IS_CMDLINE > and no command line option was given, but the option is manageable and later set through > that interface, I think the constraint won?t check the new value being provided. However, > none of the options with new constraint functions using FLAG_IS_CMDLINE are manageable, > so I think there?s no immediate problem on that score. But there should be an RFE to > follow up in this area. > > So looks good to me. Okay, I added your point at JDK-8134348. And thank you again for the review! Thanks, Sangheon From goetz.lindenmaier at sap.com Tue Oct 6 07:06:44 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 6 Oct 2015 07:06:44 +0000 Subject: RFR(S): 8138733: Fix build: gcc < 4.8 doesn't grok -Wno-format-zero-length added in 8080775 In-Reply-To: <560E6506.3010608@oracle.com> References: <4295855A5C1DE049A61835A1887419CC41E7EBD4@DEWDFEMB12A.global.corp.sap> <560E6506.3010608@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41E7F3AF@DEWDFEMB12A.global.corp.sap> Hi, could I please get a review and a sponsor for this change? http://cr.openjdk.java.net/~goetz/webrevs/8138733-warn/webrev.00/ Sorry for first posting to the wrong list. Best regards, Goetz. -----Original Message----- From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] Sent: Freitag, 2. Oktober 2015 13:06 To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net Developers Subject: Re: RFR(S): 8138733: Fix build: gcc < 4.8 doesn't grok -Wno-format-zero-length added in 8080775 Redirecting to hotspot-dev at ... On 2015-10-02 12:58, Lindenmaier, Goetz wrote: > Hi, > > We appreciate change 8080775 a lot, but it breaks the build with older gcc. > > They don't know the option -Wno-format-zero-length. > > To fix this, I only add -Wno-format-zero-length for gcc >= 4.8. > > For the other gccs, I remove ATTRIBUTE_PRINTF from the declaration of > > report_vm_error(). > > This is no big deal, as correctness is guaranteed once it's compiled with > > gcc 4.8. > > I had to fix one fatal() in the ppc files, too. > > Please review this change. I please need a sponsor. > > http://cr.openjdk.java.net/~goetz/webrevs/8138733-warn/webrev.00/ > > Best regards, > > Goetz. > From aph at redhat.com Tue Oct 6 08:16:50 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 6 Oct 2015 09:16:50 +0100 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <9FD5F6D1-2875-469C-B4C1-5F7ED0740084@azulsystems.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <56123B47.4070706@oracle.com> <9FD5F6D1-2875-469C-B4C1-5F7ED0740084@azulsystems.com> Message-ID: <56138372.7050107@redhat.com> On 06/10/15 05:32, Gil Tene wrote: > I don't think of this as platform specific. And it's not much lower > level than e.g. some java.util.concurrent stuff (but probably > doesn't belong in that package because it's not really about > concurrency). I'm looking for a proper Java SE spec'ed way to do > this. So sun.misc.* won't work. I'm sure we don't want another > Unsafe for people to abuse... > > But naming the class and method is the smaller, easier detail. Right? ;-) Sure. I would have thought, though, that java.util.concurrent was a natural home for this. Is there any kind of userland spinlock which is not about concurrency? Andrew. From paul.sandoz at oracle.com Tue Oct 6 08:27:38 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 6 Oct 2015 10:27:38 +0200 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> Message-ID: Hi Gil, Have you investigated the use of this spin loop hint in j.u.concurrent classes and other potential areas in the JDK? I think it would be useful to include some investigation to validate it?s use and then follow up with updates, perhaps separate to this JEP. > On 6 Oct 2015, at 06:32, Gil Tene wrote: > > But naming the class and method is the smaller, easier detail. Right? ;-) :-) indeed. IMHO j.u.c.LockSupport seems a reasonable location, backed by some JDK internal method which is intrinsic. One way forward is to start with the latter and if investigations with j.u.c. are fruitful expose via something like the former. Paul. > On 4 Oct 2015, at 18:22, Gil Tene wrote: > > I would like to circulate this draft JEP proposal for initial review and consensus building purposes. > > I'm cross-posting to both core-libs-dev and hotspot-dev. From a spec perspective, the main change it suggests is the addition of a method (and probably a class to hold it) to the core libraries. And intrinsifying implementations would involve changes in HotSpot (see prototype WebRev links included below). > > Draft JEP follows inline... From david.lindholm at oracle.com Tue Oct 6 08:46:49 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Tue, 6 Oct 2015 10:46:49 +0200 Subject: RFR(S): 8138733: Fix build: gcc < 4.8 doesn't grok -Wno-format-zero-length added in 8080775 In-Reply-To: <4295855A5C1DE049A61835A1887419CC41E7F3AF@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC41E7EBD4@DEWDFEMB12A.global.corp.sap> <560E6506.3010608@oracle.com> <4295855A5C1DE049A61835A1887419CC41E7F3AF@DEWDFEMB12A.global.corp.sap> Message-ID: <56138A79.3010408@oracle.com> Goetz, On 2015-10-06 09:06, Lindenmaier, Goetz wrote: > Hi, > > could I please get a review and a sponsor for this change? > http://cr.openjdk.java.net/~goetz/webrevs/8138733-warn/webrev.00/ While I don't really like the GCC-dependency in debug.hpp, I understand that it is necessary for older GCCs. Reviewed. (I'm not an JDK 9 Reviewer). Thanks, David > Sorry for first posting to the wrong list. > > Best regards, > Goetz. > > > -----Original Message----- > From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] > Sent: Freitag, 2. Oktober 2015 13:06 > To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net Developers > Subject: Re: RFR(S): 8138733: Fix build: gcc < 4.8 doesn't grok -Wno-format-zero-length added in 8080775 > > Redirecting to hotspot-dev at ... > > On 2015-10-02 12:58, Lindenmaier, Goetz wrote: >> Hi, >> >> We appreciate change 8080775 a lot, but it breaks the build with older gcc. >> >> They don't know the option -Wno-format-zero-length. >> >> To fix this, I only add -Wno-format-zero-length for gcc >= 4.8. >> >> For the other gccs, I remove ATTRIBUTE_PRINTF from the declaration of >> >> report_vm_error(). >> >> This is no big deal, as correctness is guaranteed once it's compiled with >> >> gcc 4.8. >> >> I had to fix one fatal() in the ppc files, too. >> >> Please review this change. I please need a sponsor. >> >> http://cr.openjdk.java.net/~goetz/webrevs/8138733-warn/webrev.00/ >> >> Best regards, >> >> Goetz. >> From goetz.lindenmaier at sap.com Tue Oct 6 09:11:18 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 6 Oct 2015 09:11:18 +0000 Subject: RFR(S): 8138733: Fix build: gcc < 4.8 doesn't grok -Wno-format-zero-length added in 8080775 In-Reply-To: <56138A79.3010408@oracle.com> References: <4295855A5C1DE049A61835A1887419CC41E7EBD4@DEWDFEMB12A.global.corp.sap> <560E6506.3010608@oracle.com> <4295855A5C1DE049A61835A1887419CC41E7F3AF@DEWDFEMB12A.global.corp.sap> <56138A79.3010408@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41E7F42D@DEWDFEMB12A.global.corp.sap> Hi David, thanks for reviewing! I also don't like that dependency, but in case -Wno-format-zero-length is removed, that can be removed, too. Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of David Lindholm Sent: Dienstag, 6. Oktober 2015 10:47 To: hotspot-dev at openjdk.java.net Subject: Re: RFR(S): 8138733: Fix build: gcc < 4.8 doesn't grok -Wno-format-zero-length added in 8080775 Goetz, On 2015-10-06 09:06, Lindenmaier, Goetz wrote: > Hi, > > could I please get a review and a sponsor for this change? > http://cr.openjdk.java.net/~goetz/webrevs/8138733-warn/webrev.00/ While I don't really like the GCC-dependency in debug.hpp, I understand that it is necessary for older GCCs. Reviewed. (I'm not an JDK 9 Reviewer). Thanks, David > Sorry for first posting to the wrong list. > > Best regards, > Goetz. > > > -----Original Message----- > From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] > Sent: Freitag, 2. Oktober 2015 13:06 > To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net Developers > Subject: Re: RFR(S): 8138733: Fix build: gcc < 4.8 doesn't grok -Wno-format-zero-length added in 8080775 > > Redirecting to hotspot-dev at ... > > On 2015-10-02 12:58, Lindenmaier, Goetz wrote: >> Hi, >> >> We appreciate change 8080775 a lot, but it breaks the build with older gcc. >> >> They don't know the option -Wno-format-zero-length. >> >> To fix this, I only add -Wno-format-zero-length for gcc >= 4.8. >> >> For the other gccs, I remove ATTRIBUTE_PRINTF from the declaration of >> >> report_vm_error(). >> >> This is no big deal, as correctness is guaranteed once it's compiled with >> >> gcc 4.8. >> >> I had to fix one fatal() in the ppc files, too. >> >> Please review this change. I please need a sponsor. >> >> http://cr.openjdk.java.net/~goetz/webrevs/8138733-warn/webrev.00/ >> >> Best regards, >> >> Goetz. >> From bengt.rutisson at oracle.com Tue Oct 6 10:01:29 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 06 Oct 2015 12:01:29 +0200 Subject: [8u] Request for Approval and Review: JDK-8136980: build for 8u65 and 8u66 for solaris platforms is failing In-Reply-To: <56124501.5090702@oracle.com> References: <560BD900.9000308@oracle.com> <560D3218.5070205@oracle.com> <56124501.5090702@oracle.com> Message-ID: <56139BF9.4030902@oracle.com> Hi Erik, On 2015-10-05 11:38, Erik Joelsson wrote: > Another friendly bump for an 8u (R)eviewer for this. Rubber stamped. (Thanks for walking me through the patch, Erik!) Bengt > > /Erik > > On 2015-10-01 15:16, Erik Joelsson wrote: >> Still looking for an official review from 8u reviewer for this. >> Ideally someone from Hotspot. >> >> /Erik >> >> On 2015-09-30 14:43, Erik Joelsson wrote: >>> Hello, >>> >>> Please approve and review this fix for 8u. >>> >>> My last fix for this issue, JDK-8136691, was not enough. I made a >>> mistake while verifying the fix and the problem is still there. >>> >>> There are more discrepancies between Solaris and the other platform >>> makefiles. The excludeSrc.gmk file is not included anywhere when >>> building on Solaris. The variable Src_Files_EXCLUDE is overwritten >>> in vm.make instead of appended to, so even when including >>> excludeSrc.gmk, it wasn't enough. The other platform specific >>> buildtree.make files also set INCLUDE_TRACE in the generated makefile. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8136980 >>> Webrev: http://cr.openjdk.java.net/~erikj/8136980/webrev.hotspot.01/ >>> >>> /Erik >> > From gil at azulsystems.com Tue Oct 6 14:04:54 2015 From: gil at azulsystems.com (Gil Tene) Date: Tue, 6 Oct 2015 14:04:54 +0000 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56138372.7050107@redhat.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <56123B47.4070706@oracle.com> <9FD5F6D1-2875-469C-B4C1-5F7ED0740084@azulsystems.com>, <56138372.7050107@redhat.com> Message-ID: Sent from Gil's iPhone > On Oct 6, 2015, at 1:16 AM, Andrew Haley wrote: > >> On 06/10/15 05:32, Gil Tene wrote: >> >> I don't think of this as platform specific. And it's not much lower >> level than e.g. some java.util.concurrent stuff (but probably >> doesn't belong in that package because it's not really about >> concurrency). I'm looking for a proper Java SE spec'ed way to do >> this. So sun.misc.* won't work. I'm sure we don't want another >> Unsafe for people to abuse... >> >> But naming the class and method is the smaller, easier detail. Right? ;-) > > Sure. I would have thought, though, that java.util.concurrent was a > natural home for this. Is there any kind of userland spinlock which > is not about concurrency? The same can be asked about Thread.notify(). To me, spinKoopHint() fits in (as in "probably a method in the same class") with other performance-oriented hints. Like prefetch variants (which we don't have but also probably need. E.g. prefetchWithIntentToWrite()). And placing prefetch hints in j.u.c would not make much sense. From vitalyd at gmail.com Tue Oct 6 14:12:24 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 6 Oct 2015 10:12:24 -0400 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56138372.7050107@redhat.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <56123B47.4070706@oracle.com> <9FD5F6D1-2875-469C-B4C1-5F7ED0740084@azulsystems.com> <56138372.7050107@redhat.com> Message-ID: Although spin lock would also benefit from this, the spinning is also done when doing message hand off between threads. It's common in low latency space to monopolize the cpu(s) and spin wait for data to arrive; this is to avoid parking the thread in kernel when you know arrival rate is very high. As for j.u.c. I believe StampedLock had some manual spinning and uses ThreadLocalRandom to create artificial mispredicts to prevent speculative pipeline from filling up (basically simulating pause like instruction). sent from my phone On Oct 6, 2015 4:17 AM, "Andrew Haley" wrote: > On 06/10/15 05:32, Gil Tene wrote: > > > I don't think of this as platform specific. And it's not much lower > > level than e.g. some java.util.concurrent stuff (but probably > > doesn't belong in that package because it's not really about > > concurrency). I'm looking for a proper Java SE spec'ed way to do > > this. So sun.misc.* won't work. I'm sure we don't want another > > Unsafe for people to abuse... > > > > But naming the class and method is the smaller, easier detail. Right? ;-) > > Sure. I would have thought, though, that java.util.concurrent was a > natural home for this. Is there any kind of userland spinlock which > is not about concurrency? > > Andrew. > From daniel.daugherty at oracle.com Tue Oct 6 14:38:31 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 6 Oct 2015 08:38:31 -0600 Subject: [8u] Request for Approval and Review: JDK-8136980: build for 8u65 and 8u66 for solaris platforms is failing In-Reply-To: <560BD900.9000308@oracle.com> References: <560BD900.9000308@oracle.com> Message-ID: <5613DCE7.1080706@oracle.com> Sorry for missing this review request. I'm still learning to deal with my new e-mail filters (restored from memory after losing my MacBook Pro env). On 9/30/15 6:43 AM, Erik Joelsson wrote: > Hello, > > Please approve and review this fix for 8u. > > My last fix for this issue, JDK-8136691, was not enough. I made a > mistake while verifying the fix and the problem is still there. > > There are more discrepancies between Solaris and the other platform > makefiles. The excludeSrc.gmk file is not included anywhere when > building on Solaris. The variable Src_Files_EXCLUDE is overwritten in > vm.make instead of appended to, so even when including excludeSrc.gmk, > it wasn't enough. The other platform specific buildtree.make files > also set INCLUDE_TRACE in the generated makefile. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8136980 > Webrev: http://cr.openjdk.java.net/~erikj/8136980/webrev.hotspot.01/ make/solaris/makefiles/buildtree.make No comments. make/solaris/makefiles/vm.make No comments. Thumbs up. Dan > > /Erik > From gil at azulsystems.com Tue Oct 6 15:26:31 2015 From: gil at azulsystems.com (Gil Tene) Date: Tue, 6 Oct 2015 15:26:31 +0000 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <6882C9A35DFB9B4FA2779F7BF5B9757D2083639C97@GSCMAMP06EX.firmwide.corp.gs.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <56123B47.4070706@oracle.com> <9FD5F6D1-2875-469C-B4C1-5F7ED0740084@azulsystems.com> <56138372.7050107@redhat.com> <6882C9A35DFB9B4FA2779F7BF5B9757D2083639C97@GSCMAMP06EX.firmwide.corp.gs.com> Message-ID: <9A739B8F-EB55-45C5-806B-D17C48168446@azulsystems.com> > On Oct 6, 2015, at 7:54 AM, Rezaei, Mohammad A. wrote: > > Thread.yield(), Thread.sleep(), Thread.spinLoopHint()? That's probably a good place, especially since it doesn't add a new class. Will need feedback about the concerns of adding methods to existing commonly used classes though. E.g. with non-static methods (which this isn't) there is often the "what if someone already has a xyz() method in a subclass" concern. Less of an issue with static methods. > Somehow, it feels right (as in consistent), but also off at the same time (as in, why are these on Thread). > > I'd take consistent over bespoke-one-static-method-class, unless there was a concerted effort to consolidate other related api/concerns. > > Thanks > Moh > >> -----Original Message----- >> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >> Of Gil Tene >> Sent: Tuesday, October 06, 2015 10:05 AM >> To: Andrew Haley >> Cc: hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >> Subject: Re: Spin Loop Hint support: Draft JEP proposal >> >> >> >> Sent from Gil's iPhone >> >>> On Oct 6, 2015, at 1:16 AM, Andrew Haley wrote: >>> >>>> On 06/10/15 05:32, Gil Tene wrote: >>>> >>>> I don't think of this as platform specific. And it's not much lower >>>> level than e.g. some java.util.concurrent stuff (but probably >>>> doesn't belong in that package because it's not really about >>>> concurrency). I'm looking for a proper Java SE spec'ed way to do >>>> this. So sun.misc.* won't work. I'm sure we don't want another >>>> Unsafe for people to abuse... >>>> >>>> But naming the class and method is the smaller, easier detail. Right? ;-) >>> >>> Sure. I would have thought, though, that java.util.concurrent was a >>> natural home for this. Is there any kind of userland spinlock which >>> is not about concurrency? >> >> The same can be asked about Thread.notify(). >> >> To me, spinKoopHint() fits in (as in "probably a method in the same class") >> with other performance-oriented hints. Like prefetch variants (which we don't >> have but also probably need. E.g. prefetchWithIntentToWrite()). And placing >> prefetch hints in j.u.c would not make much sense. From max.ockner at oracle.com Tue Oct 6 15:51:32 2015 From: max.ockner at oracle.com (Max Ockner) Date: Tue, 06 Oct 2015 11:51:32 -0400 Subject: RFR: 8138917: Back out of failing change set for 8130681. In-Reply-To: <5613379A.4030706@oracle.com> References: <5613379A.4030706@oracle.com> Message-ID: <5613EE04.6020004@oracle.com> Hello all, Please review this back out of a recent change for bug 8130681. Bug: https://bugs.openjdk.java.net/browse/JDK-8138917 Webrev: http://cr.openjdk.java.net/~mockner/8138917/ Summary: The previous fix was incomplete and introduced a new failure in the kitchensink tests. This bug is an integration blocker. The current fix simply backs out the faulty changes for 8130681. There will be a more extensive fix in the near future. Tested using jtreg for runtime/NMT/ Thanks, Max From kim.barrett at oracle.com Tue Oct 6 15:59:13 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 6 Oct 2015 11:59:13 -0400 Subject: RFR: 8138659: Speed up InstanceKlass subclass discrimination In-Reply-To: <5612D757.5040905@oracle.com> References: <5612D757.5040905@oracle.com> Message-ID: <5422E78A-5321-406D-9997-7A19BB4A4ABD@oracle.com> On Oct 5, 2015, at 4:02 PM, Coleen Phillimore wrote: > > > In http://cr.openjdk.java.net/~kbarrett/8138659/webrev.00/src/share/vm/oops/instanceKlass.hpp.udiff.html > > There are right_n_bits() and bitfield functions in globalDefinitions.hpp that would make some bit manipulation in this set_kind() easier to read. I tried to do that, but ran into signed vs unsigned warning problems, because I used unsigned types here but the globalDefinitions.hpp bitfield operations are wired for signed types. I believe unsigned is right for the changes I'm making, and I don't feel like generalizing the bitfield operations today. I did make a couple of small tweaks for readability though. > Minor comment: I'd put kind_is_instance() .. kind_is_class_loader() functions on one line each and not use so much vertical space. I reformatted the second (ordinary member function) block, but left the first (static member function) block alone because the line lengths became a little excessive for my taste. New full and incremental webrevs: http://cr.openjdk.java.net/~kbarrett/8138659/webrev.01/ http://cr.openjdk.java.net/~kbarrett/8138659/webrev.01.inc/ Testing: JPRT From jeanphilippe.bempel at ullink.com Tue Oct 6 13:31:43 2015 From: jeanphilippe.bempel at ullink.com (Jean Philippe Bempel) Date: Tue, 6 Oct 2015 15:31:43 +0200 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56138372.7050107@redhat.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <56123B47.4070706@oracle.com> <9FD5F6D1-2875-469C-B4C1-5F7ED0740084@azulsystems.com> <56138372.7050107@redhat.com> Message-ID: On Tue, Oct 6, 2015 at 10:16 AM, Andrew Haley wrote: > > Sure. I would have thought, though, that java.util.concurrent was a > natural home for this. Is there any kind of userland spinlock which > is not about concurrency? > > Andrew. > Spinning is not always for a spinlock. Most of the time is a lightweight & userland only wait/notify implementation. Or park/unpark equivalent which tends to fit into LockSupport like Paul Sandoz suggests. *Jean-Philippe Bempel* *|* Software Architect* |* *ULLINK |* T: +33 1 49 95 10 29 | 23-25 rue de Provence | 75009 Paris | *jpbempel at ullink.com* | -- *The information contained in or attached to this email is strictly confidential. If you are not the intended recipient, please notify us immediately by telephone and return the message to us.* From coleen.phillimore at oracle.com Tue Oct 6 17:39:13 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 06 Oct 2015 13:39:13 -0400 Subject: RFR: 8138917: Back out of failing change set for 8130681. In-Reply-To: <5613EE04.6020004@oracle.com> References: <5613379A.4030706@oracle.com> <5613EE04.6020004@oracle.com> Message-ID: <56140741.4000104@oracle.com> This looks good. I'll sponsor it. Coleen On 10/6/15 11:51 AM, Max Ockner wrote: > > Hello all, > Please review this back out of a recent change for bug 8130681. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8138917 > Webrev: http://cr.openjdk.java.net/~mockner/8138917/ > > Summary: The previous fix was incomplete and introduced a new failure in > the kitchensink tests. This bug is an integration blocker. The current > fix simply backs out the faulty changes for 8130681. There will be a > more extensive fix in the near future. > > Tested using jtreg for runtime/NMT/ > > Thanks, > Max > > > > From george.triantafillou at oracle.com Tue Oct 6 17:59:30 2015 From: george.triantafillou at oracle.com (George Triantafillou) Date: Tue, 6 Oct 2015 13:59:30 -0400 Subject: RFR: 8138917: Back out of failing change set for 8130681. In-Reply-To: <56140741.4000104@oracle.com> References: <5613379A.4030706@oracle.com> <5613EE04.6020004@oracle.com> <56140741.4000104@oracle.com> Message-ID: <56140C02.6030201@oracle.com> Hi Max, This looks good. -George On 10/6/2015 1:39 PM, Coleen Phillimore wrote: > > This looks good. I'll sponsor it. > > Coleen > > On 10/6/15 11:51 AM, Max Ockner wrote: >> >> Hello all, >> Please review this back out of a recent change for bug 8130681. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8138917 >> Webrev: http://cr.openjdk.java.net/~mockner/8138917/ >> >> Summary: The previous fix was incomplete and introduced a new failure in >> the kitchensink tests. This bug is an integration blocker. The current >> fix simply backs out the faulty changes for 8130681. There will be a >> more extensive fix in the near future. >> >> Tested using jtreg for runtime/NMT/ >> >> Thanks, >> Max >> >> >> >> > From coleen.phillimore at oracle.com Tue Oct 6 18:35:17 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 06 Oct 2015 14:35:17 -0400 Subject: RFR: 8138659: Speed up InstanceKlass subclass discrimination In-Reply-To: <5422E78A-5321-406D-9997-7A19BB4A4ABD@oracle.com> References: <5612D757.5040905@oracle.com> <5422E78A-5321-406D-9997-7A19BB4A4ABD@oracle.com> Message-ID: <56141465.10407@oracle.com> On 10/6/15 11:59 AM, Kim Barrett wrote: > On Oct 5, 2015, at 4:02 PM, Coleen Phillimore wrote: >> >> In http://cr.openjdk.java.net/~kbarrett/8138659/webrev.00/src/share/vm/oops/instanceKlass.hpp.udiff.html >> >> There are right_n_bits() and bitfield functions in globalDefinitions.hpp that would make some bit manipulation in this set_kind() easier to read. > I tried to do that, but ran into signed vs unsigned warning problems, > because I used unsigned types here but the globalDefinitions.hpp > bitfield operations are wired for signed types. I believe unsigned is > right for the changes I'm making, and I don't feel like generalizing > the bitfield operations today. > > I did make a couple of small tweaks for readability though. Okay, I don't know how much more readable they are but they're fine. > >> Minor comment: I'd put kind_is_instance() .. kind_is_class_loader() functions on one line each and not use so much vertical space. > I reformatted the second (ordinary member function) block, but left > the first (static member function) block alone because the line > lengths became a little excessive for my taste. > > New full and incremental webrevs: > http://cr.openjdk.java.net/~kbarrett/8138659/webrev.01/ > http://cr.openjdk.java.net/~kbarrett/8138659/webrev.01.inc/ These changes are fine with me. Thanks, Coleen > Testing: JPRT > From Mohammad.Rezaei at gs.com Tue Oct 6 14:54:57 2015 From: Mohammad.Rezaei at gs.com (Rezaei, Mohammad A.) Date: Tue, 6 Oct 2015 10:54:57 -0400 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <56123B47.4070706@oracle.com> <9FD5F6D1-2875-469C-B4C1-5F7ED0740084@azulsystems.com>, <56138372.7050107@redhat.com> Message-ID: <6882C9A35DFB9B4FA2779F7BF5B9757D2083639C97@GSCMAMP06EX.firmwide.corp.gs.com> Thread.yield(), Thread.sleep(), Thread.spinLoopHint()? Somehow, it feels right (as in consistent), but also off at the same time (as in, why are these on Thread). I'd take consistent over bespoke-one-static-method-class, unless there was a concerted effort to consolidate other related api/concerns. Thanks Moh >-----Original Message----- >From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >Of Gil Tene >Sent: Tuesday, October 06, 2015 10:05 AM >To: Andrew Haley >Cc: hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >Subject: Re: Spin Loop Hint support: Draft JEP proposal > > > >Sent from Gil's iPhone > >> On Oct 6, 2015, at 1:16 AM, Andrew Haley wrote: >> >>> On 06/10/15 05:32, Gil Tene wrote: >>> >>> I don't think of this as platform specific. And it's not much lower >>> level than e.g. some java.util.concurrent stuff (but probably >>> doesn't belong in that package because it's not really about >>> concurrency). I'm looking for a proper Java SE spec'ed way to do >>> this. So sun.misc.* won't work. I'm sure we don't want another >>> Unsafe for people to abuse... >>> >>> But naming the class and method is the smaller, easier detail. Right? ;-) >> >> Sure. I would have thought, though, that java.util.concurrent was a >> natural home for this. Is there any kind of userland spinlock which >> is not about concurrency? > >The same can be asked about Thread.notify(). > >To me, spinKoopHint() fits in (as in "probably a method in the same class") >with other performance-oriented hints. Like prefetch variants (which we don't >have but also probably need. E.g. prefetchWithIntentToWrite()). And placing >prefetch hints in j.u.c would not make much sense. From peter.levart at gmail.com Mon Oct 5 14:59:12 2015 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 5 Oct 2015 16:59:12 +0200 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <561245E0.8030708@redhat.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> Message-ID: <56129040.8060701@gmail.com> On 10/05/2015 11:41 AM, Andrew Haley wrote: > Hi Gil, > > On 04/10/15 17:22, Gil Tene wrote: > >> Summary >> >> Add an API that would allow Java code to hint that a spin loop is >> being executed. > > I don't think this will work for ARM, which has a rather different > spinlock mechanism. > > Instead of PAUSE, we wait on a lock word with WFE. WFE puts a core > into a lightweight sleep state waiting on a particular address (the > lock word) and a write to the lock word wakes it up. This is very > useful and somewhat analogous to 86's MONITOR/MWAIT. > > I can't immediately see how to generalize your proposal to ARM, which > is a shame. > > Andrew. > Just a thought... ARM WaitForEvent/SendEvent instructions sound like a kind of park/unpark, but on a CPU-core-level (WFE) and global system-level (SendEvent). I wonder whether it would be possible to use them to optimize the latency of the implementation of park/unpark. The same goes for Spin Loop Hint. Would it be possible to incorporate spin-looping in the park/unpark implementation for x86 itself? Higher-level synchronization constructs (like locks, synchronizers, etc..) would then just use park/unpark and not bother with spin-looping themselves. Regards, Peter From peter.levart at gmail.com Mon Oct 5 15:40:34 2015 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 5 Oct 2015 17:40:34 +0200 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <5612950A.5070203@redhat.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> <56129040.8060701@gmail.com> <5612950A.5070203@redhat.com> Message-ID: <561299F2.3080000@gmail.com> On 10/05/2015 05:19 PM, Andrew Haley wrote: > On 10/05/2015 03:59 PM, Peter Levart wrote: >> On 10/05/2015 11:41 AM, Andrew Haley wrote: >>> Hi Gil, >>> >>> On 04/10/15 17:22, Gil Tene wrote: >>> >>>> Summary >>>> >>>> Add an API that would allow Java code to hint that a spin loop is >>>> being executed. >>> I don't think this will work for ARM, which has a rather different >>> spinlock mechanism. >>> >>> Instead of PAUSE, we wait on a lock word with WFE. WFE puts a core >>> into a lightweight sleep state waiting on a particular address (the >>> lock word) and a write to the lock word wakes it up. This is very >>> useful and somewhat analogous to 86's MONITOR/MWAIT. >>> >>> I can't immediately see how to generalize your proposal to ARM, >>> which is a shame. >> Just a thought... >> >> ARM WaitForEvent/SendEvent instructions sound like a kind of >> park/unpark, but on a CPU-core-level (WFE) and global system-level >> (SendEvent). > Pretty much, although the wakeup is just a store. > >> I wonder whether it would be possible to use them to optimize the >> latency of the implementation of park/unpark. The same goes for Spin >> Loop Hint. Would it be possible to incorporate spin-looping in the >> park/unpark implementation for x86 itself? Higher-level >> synchronization constructs (like locks, synchronizers, etc..) would >> then just use park/unpark and not bother with spin-looping >> themselves. > I spent a while thinking about that, and I'm not sure it's possible. > WFE can wait for a very long time, and there is a general presumption > that if a thread blocks it really should be descheduled rather than > hog a core with a WFE. WFE is excellent if you have many cores (more > cores than threads) and don't mind dedicating them to particular > tasks: it's great for fork/join thread pools, etc, because it doesn't > have the overhead of blocking and unblocking. Maybe the best thing > would be a different version of park/unpark. > > Andrew. Yes, perhaps park/unpark is already to high-level as it requires Thread to be passed to unpark and therefore requires a thread to publish itself before doing park(), etc. Spin-looping is usually used without thread bookkeeping. I wonder how Gil's proposed PerformanceHints.spinLoopHint() is to be called. Just before entering the spin-loop or at each iteration of the loop? Is this some kind of CPU.yield() (by analogy to Thread.yield())? Regards, Peter From staffan.larsen at oracle.com Tue Oct 6 19:17:46 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 6 Oct 2015 21:17:46 +0200 Subject: CLANG special case In-Reply-To: <5613EAF0.6000102@oracle.com> References: <5A5E3D06-3825-40C9-92BA-511C41ACFEF3@oracle.com> <5613EAF0.6000102@oracle.com> Message-ID: When we upgraded to clang 6.3, I verified that the problem still existed. See: https://bugs.openjdk.java.net/browse/JDK-8077364 which has pointers to the two tests that fail without the workaround. /Staffan > On 6 okt 2015, at 17:38, Phil Race wrote: > > Ideally hotspot would review this, not build. > so it would be helpful if hotspot found an engineer to own the bug :- > https://bugs.openjdk.java.net/browse/JDK-8138820 > So far as I know this is not tracked under any other bug id. > > -phil. > > On 10/06/2015 05:30 AM, Jim Laskey (Oracle) wrote: >> I?ve updated to El Capitan and, of course, builds fail, and, of course, I modify hotspot/make/bsd/makefiles/gcc.make one more time and? I think this conditional clause should be removed at the very least (commenting to indicate needs investigation), or someone should research and see which version of clang fixes the issues associate with the patch. Since it?s likely that no one has the cycles, please remove the condition. >> >> Cheers, >> >> ? Jim >> >> >> >> diff -r a02911828e48 make/bsd/makefiles/gcc.make >> --- a/make/bsd/makefiles/gcc.make Wed Sep 30 07:41:36 2015 -0700 >> +++ b/make/bsd/makefiles/gcc.make Tue Oct 06 09:22:50 2015 -0300 >> @@ -313,21 +313,13 @@ >> # Work around some compiler bugs. >> ifeq ($(USE_CLANG), true) >> - # Clang <= 6.1 >> - ifeq ($(shell expr \ >> - $(CC_VER_MAJOR) \< 6 \| \ >> - $ $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) \<= 1 $ \ >> - ), 1) >> - OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) >> - OPT_CFLAGS/unsafe.o += -O1 >> - else >> - $(error "Update compiler workarounds for Clang $(CC_VER_MAJOR).$(CC_VER_MINOR)") >> - endif >> + OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) >> + OPT_CFLAGS/unsafe.o += -O1 >> else >> # 6835796. Problem in GCC 4.3.0 with mulnode.o optimized compilation. >> ifeq ($(shell expr $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 3), 1) >> OPT_CFLAGS/mulnode.o += $(OPT_CFLAGS/NOOPT) >> - endif >> + endif >> endif >> # Flags for generating make dependency flags. >> > From dl at cs.oswego.edu Tue Oct 6 20:02:04 2015 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 6 Oct 2015 16:02:04 -0400 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> Message-ID: <561428BC.3060806@cs.oswego.edu> On 10/04/2015 12:22 PM, Gil Tene wrote: > I would like to circulate this draft JEP proposal for initial review and consensus building purposes. > Some background: about two years ago, Dave Dice and I put together a pre-jep proposal for JVM support for recent CPU features covering: (1) MWAIT/PAUSE/etc (for spins as well as other uses people have noted); (2) Core topology/neighborhood information and; (3) 2CAS, as a foothold on HTM that could still be reasonably efficient on non-transactional processors. My understanding of the result of this effort was that Oracle JVM engineers didn't think they had resources to do this for jdk9. It didn't occur to me that non-Oracle contributors might want to cherry-pick one (some of (1) above). It seems plausible to do this, but only if designed as the first of some possible enhanced support along these lines. -Doug From gil at azulsystems.com Wed Oct 7 01:28:44 2015 From: gil at azulsystems.com (Gil Tene) Date: Wed, 7 Oct 2015 01:28:44 +0000 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <561428BC.3060806@cs.oswego.edu> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> Message-ID: <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> > On Oct 6, 2015, at 1:02 PM, Doug Lea

wrote: > > On 10/04/2015 12:22 PM, Gil Tene wrote: >> I would like to circulate this draft JEP proposal for initial review and consensus building purposes. >> > > Some background: about two years ago, Dave Dice and I put together > a pre-jep proposal for JVM support for recent CPU features covering: > > (1) MWAIT/PAUSE/etc (for spins as well as other uses people have noted); > (2) Core topology/neighborhood information and; > (3) 2CAS, as a foothold on HTM that could still be reasonably efficient > on non-transactional processors. > > My understanding of the result of this effort was that Oracle JVM engineers > didn't think they had resources to do this for jdk9. It didn't occur to > me that non-Oracle contributors might want to cherry-pick one (some > of (1) above). It seems plausible to do this, but only if designed > as the first of some possible enhanced support along these lines. Good point. But that's what an actual community is about. Isn't it? We (Azul) are volunteering the resources for spinloopHint(). Including experimentation, implementation, testing, and even a TCK (which in this case will be trivial). So the vast majority of resources needed will not be coming other budgeted jdk9 resources. I certainly recognize that there will still be work involved that others will end up having to do: reviewing, arguing, contributing opinions, etc., as well as integrating the work into the whole. But this specific proposed JEP is about as narrow and low risk as you can get. especially from a specification point of view (e.g. intrinsic implementation can be left under a flag if deemed risky to stability or schedule). As for fitting in with larger-picture or theme things (listed above). I think that agonizing over the choice of where to put this is important (e.g. the Thread.spinLoopHint() idea, or a create new class that other hints will go into in the future, and where?). But I don't think that there is good reason to bundle this work with e.g. 2CAS, HTM, and affinity. Work. While we can think of them all as "support for recent CPU features", they are very different (and probably have multiple other unrelated groupings). MWAIT (and the like) and PAUSE do deserve some co-thinking (see earlier discussion on the thread). So does a discussion about a capturing abstraction like synchronic (raised in concurrency interest), But given the actual common uses already waiting for a spinLoopHint(), the very tangible and immediate benefit it shows, and the fact that most of the use cases wouldn't be able to make use of MWAIT (or the like), and some won't be able to use a synchronic-like thing, I think that either a spin-hint-only JEP is not just a good "shortcut", but also an actual stand-alone feature need. > -Doug > > > From joe.darcy at oracle.com Wed Oct 7 01:50:18 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 06 Oct 2015 18:50:18 -0700 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> Message-ID: <56147A5A.5040308@oracle.com> On 10/6/2015 6:28 PM, Gil Tene wrote: >> On Oct 6, 2015, at 1:02 PM, Doug Lea

wrote: >> >> On 10/04/2015 12:22 PM, Gil Tene wrote: >>> I would like to circulate this draft JEP proposal for initial review and consensus building purposes. >>> >> Some background: about two years ago, Dave Dice and I put together >> a pre-jep proposal for JVM support for recent CPU features covering: >> >> (1) MWAIT/PAUSE/etc (for spins as well as other uses people have noted); >> (2) Core topology/neighborhood information and; >> (3) 2CAS, as a foothold on HTM that could still be reasonably efficient >> on non-transactional processors. >> >> My understanding of the result of this effort was that Oracle JVM engineers >> didn't think they had resources to do this for jdk9. It didn't occur to >> me that non-Oracle contributors might want to cherry-pick one (some >> of (1) above). It seems plausible to do this, but only if designed >> as the first of some possible enhanced support along these lines. > Good point. But that's what an actual community is about. Isn't it? > > We (Azul) are volunteering the resources for spinloopHint(). Including > experimentation, implementation, testing, and even a TCK (which in this case > will be trivial). So the vast majority of resources needed will not be coming > other budgeted jdk9 resources. > > I certainly recognize that there will still be work involved that others will > end up having to do: reviewing, arguing, contributing opinions, etc., as well > as integrating the work into the whole. But this specific proposed JEP is about > as narrow and low risk as you can get. especially from a specification point of > view (e.g. intrinsic implementation can be left under a flag if deemed risky to > stability or schedule). > > As for fitting in with larger-picture or theme things (listed above). I think that > agonizing over the choice of where to put this is important (e.g. the Thread.spinLoopHint() > idea, or a create new class that other hints will go into in the future, and where?). > But I don't think that there is good reason to bundle this work with e.g. 2CAS, HTM, > and affinity. Work. While we can think of them all as "support for recent CPU features", > they are very different (and probably have multiple other unrelated groupings). > > MWAIT (and the like) and PAUSE do deserve some co-thinking (see earlier discussion > on the thread). So does a discussion about a capturing abstraction like synchronic > (raised in concurrency interest), But given the actual common uses already waiting > for a spinLoopHint(), the very tangible and immediate benefit it shows, and the fact that > most of the use cases wouldn't be able to make use of MWAIT (or the like), and some > won't be able to use a synchronic-like thing, I think that either a spin-hint-only JEP > is not just a good "shortcut", but also an actual stand-alone feature need. > Taking a long-term view, it seems to me premature to burn this kind of hint into the Java SE API (effectively) forever in the absence of experience that the hint in this form is useful and will continue to be useful in 5 years, 10 years, etc. If the hint started out as a JDK-specific API, there would be (some) more room to modify or drop the API in the future, leaving open the possibility of migrating the functionality to the Java SE API too. -Joe From manasthakur17 at gmail.com Wed Oct 7 04:43:31 2015 From: manasthakur17 at gmail.com (Manas Thakur) Date: Wed, 7 Oct 2015 10:13:31 +0530 Subject: Compiling OpenJDK with C++11 support Message-ID: <033062EE-C322-45CE-A11F-735F18C9ED5B@gmail.com> Hello all, In which file should I give the option to use C++11 support while building images with gcc? Regards, Manas From manasthakur17 at gmail.com Wed Oct 7 04:45:53 2015 From: manasthakur17 at gmail.com (Manas Thakur) Date: Wed, 7 Oct 2015 10:15:53 +0530 Subject: Compiling OpenJDK with C++11 support In-Reply-To: <033062EE-C322-45CE-A11F-735F18C9ED5B@gmail.com> References: <033062EE-C322-45CE-A11F-735F18C9ED5B@gmail.com> Message-ID: Forgot to mention: I am building OpenJDK 8. Regards, Manas > On 07-Oct-2015, at 10:13 AM, Manas Thakur wrote: > > Hello all, > > In which file should I give the option to use C++11 support while building images with gcc? > > Regards, > Manas From thomas.stuefe at gmail.com Wed Oct 7 07:01:21 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 7 Oct 2015 09:01:21 +0200 Subject: RFR(xxs): [windows] Build broken on VS2010 after "8046148: JEP 158: Unified JVM Logging" In-Reply-To: References: <560A9F58.2080309@oracle.com>

<560BE5A9.2000706@oracle.com>

Message-ID: Hi all, could I have a sponsor please? I think enough people think this makes sense to fix, and the fix is cheap and small. bug: https://bugs.openjdk.java.net/browse/JDK-8137329 patch: http://cr.openjdk.java.net/~stuefe/webrevs/8137329/webrev.01/webrev/ Thanks! Thomas On Mon, Oct 5, 2015 at 3:25 PM, Thomas St?fe wrote: > Hi all, > > may I have a sponsor please? > > Or have we decided not to fix this ? > > Regards, Thomas > > On Thu, Oct 1, 2015 at 9:41 AM, Thomas St?fe > wrote: > >> Hi all, >> >> New version of this patch: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8137329/webrev.01/webrev/ >> >> As Volker suggests, makes the workaround depend on _MSC_VER and also >> moves the patch to globalDefinitions_visCPP.hpp where it fits better and >> works for the whole hotspot. >> >> Kind regards, Thomas >> >> >> On Wed, Sep 30, 2015 at 3:51 PM, Volker Simonis > > wrote: >> >>> Hi, >>> >>> I second Phil,Goetz and Magnus and think this is a good change. >>> >>> But I suggest we should use "#if _MSC_VER < 1800" together with a >>> small comment instead of "#ifdef _WIN32" to make it more clear why we >>> have to redefine strtoull. >>> >>> Regards, >>> Volker >>> >>> >>> On Wed, Sep 30, 2015 at 3:37 PM, Magnus Ihse Bursie >>> wrote: >>> > On 2015-09-30 14:40, Thomas St?fe wrote: >>> >> >>> >> I would like to hear more opinions, and possibly a sponsor and a >>> reviewer. >>> >> >>> >> In my opinion it makes sense to fix this. The fix is small and cheap >>> and >>> >> makes people happy who still work with older versions of VS2010. >>> > >>> > I agree. It makes sense for trivial fixes to extend the range of >>> compiler >>> > versions that are possible to use. Major changes to support older >>> compilers >>> > is another thing, but simple stuff like this should be a no-brainer. >>> This is >>> > not really related to the fact that Oracle internally uses a specific >>> > version for daily quality control. >>> > >>> > /Magnus >>> > >>> >> >>> >> Kind Regards, Thomas >>> >> >>> >> On Tue, Sep 29, 2015 at 5:12 PM, Thomas St?fe < >>> thomas.stuefe at gmail.com> >>> >> wrote: >>> >> >>> >>> Ok, I did not check this. Nevermind, then. >>> >>> >>> >>> Kind Regards, Thomas >>> >>> >>> >>> On Tue, Sep 29, 2015 at 4:25 PM, Daniel D. Daugherty < >>> >>> daniel.daugherty at oracle.com> wrote: >>> >>> >>> >>>> Ummm... VS2013 is the official compiler for JDK9 and Win*. >>> >>>> Why would we want to make a change to permit VS2010 to >>> >>>> continue to be used? >>> >>>> >>> >>>> Dan >>> >>>> >>> >>>> >>> >>>> On 9/29/15 7:58 AM, Thomas St?fe wrote: >>> >>>> >>> >>>>> Hi all, >>> >>>>> >>> >>>>> please review this tiny change. It fixes the build on >>> windows/Visual >>> >>>>> Studio >>> >>>>> 2010 after "8046148: JEP 158: Unified JVM Logging". >>> >>>>> >>> >>>>> strtoull() is missing from Visual Studio versions < 2013, but >>> >>>>> _strtoui64() >>> >>>>> can be used instead. >>> >>>>> >>> >>>>> webrev: >>> >>>>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8137329/webrev.00/webrev/ >>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8137329 >>> >>>>> >>> >>>>> Thanks & Kind Regards, Thomas >>> >>>>> >>> >>>> >>> > >>> >> >> > From gil at azulsystems.com Wed Oct 7 07:17:46 2015 From: gil at azulsystems.com (Gil Tene) Date: Wed, 7 Oct 2015 07:17:46 +0000 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56147A5A.5040308@oracle.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56147A5A.5040308@oracle.com> Message-ID: <60ED335F-9898-4496-99AF-C5DBE5B3E8F1@azulsystems.com> > On Oct 6, 2015, at 6:50 PM, Joseph D. Darcy wrote: > > > On 10/6/2015 6:28 PM, Gil Tene wrote: >>> On Oct 6, 2015, at 1:02 PM, Doug Lea

wrote: >>> >>> On 10/04/2015 12:22 PM, Gil Tene wrote: >>>> I would like to circulate this draft JEP proposal for initial review and consensus building purposes. >>>> >>> Some background: about two years ago, Dave Dice and I put together >>> a pre-jep proposal for JVM support for recent CPU features covering: >>> >>> (1) MWAIT/PAUSE/etc (for spins as well as other uses people have noted); >>> (2) Core topology/neighborhood information and; >>> (3) 2CAS, as a foothold on HTM that could still be reasonably efficient >>> on non-transactional processors. >>> >>> My understanding of the result of this effort was that Oracle JVM engineers >>> didn't think they had resources to do this for jdk9. It didn't occur to >>> me that non-Oracle contributors might want to cherry-pick one (some >>> of (1) above). It seems plausible to do this, but only if designed >>> as the first of some possible enhanced support along these lines. >> Good point. But that's what an actual community is about. Isn't it? >> >> We (Azul) are volunteering the resources for spinloopHint(). Including >> experimentation, implementation, testing, and even a TCK (which in this case >> will be trivial). So the vast majority of resources needed will not be coming >> other budgeted jdk9 resources. >> >> I certainly recognize that there will still be work involved that others will >> end up having to do: reviewing, arguing, contributing opinions, etc., as well >> as integrating the work into the whole. But this specific proposed JEP is about >> as narrow and low risk as you can get. especially from a specification point of >> view (e.g. intrinsic implementation can be left under a flag if deemed risky to >> stability or schedule). >> >> As for fitting in with larger-picture or theme things (listed above). I think that >> agonizing over the choice of where to put this is important (e.g. the Thread.spinLoopHint() >> idea, or a create new class that other hints will go into in the future, and where?). >> But I don't think that there is good reason to bundle this work with e.g. 2CAS, HTM, >> and affinity. Work. While we can think of them all as "support for recent CPU features", >> they are very different (and probably have multiple other unrelated groupings). >> >> MWAIT (and the like) and PAUSE do deserve some co-thinking (see earlier discussion >> on the thread). So does a discussion about a capturing abstraction like synchronic >> (raised in concurrency interest), But given the actual common uses already waiting >> for a spinLoopHint(), the very tangible and immediate benefit it shows, and the fact that >> most of the use cases wouldn't be able to make use of MWAIT (or the like), and some >> won't be able to use a synchronic-like thing, I think that either a spin-hint-only JEP >> is not just a good "shortcut", but also an actual stand-alone feature need. >> > > Taking a long-term view, it seems to me premature to burn this kind of hint into the Java SE API (effectively) forever in the absence of experience that the hint in this form is useful and will continue to be useful in 5 years, 10 years, etc. > > If the hint started out as a JDK-specific API, there would be (some) more room to modify or drop the API in the future, leaving open the possibility of migrating the functionality to the Java SE API too. > > -Joe While I don't disagree with the need for long term thinking, I think this JEP represents exactly that. It is hardly "premature". "Very late" is probably a much better description. There is overwhelming evidence and experience showing that this exact form of hint is useful, and will likely continue to be useful for a decade or more. Spin hinting isn't something new. This hint technique (include an explicit instruction or function call hinting that you are in a spin loop) has been dominantly and beneficially used for over a decade in virtually all spinning code *other* than Java. E.g. Linux (and probably all other OSs) uses this for virtually all kernel spinning situations on x86 and PowerPC. POSIX libraries do so too in mutexes and semaphores in user mode. Even the JVM's own custom C++ spinning code has been doing it for many years. It is only pure Java code that has been deprived this ability for the past decade. And in the many-core world we've been living in for at least 5 years, even on commodity hardware, the lack really hurts. This JEP is a fairly late reaction to the very patient requests of a substantial set of Java developers. The community of people doing performant messaging and latency sensitive stuff with Java has been asking for this for a long time as well. Usually with variants of sentences like "Our C and C++ versions of these things use a PAUSE instruction, but in Java we have no way to make that happen. As a result, the reaction time of our Java spin loops is unnecessarily slower than non-Java setups, and our metrics suffer". People often phrase their request as "I'd like PAUSE instruction API in Java". The JEP is aiming for a platform-independent way to express that. ?Gil. From volker.simonis at gmail.com Wed Oct 7 07:54:03 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 7 Oct 2015 09:54:03 +0200 Subject: RFR(S): 8138733: Fix build: gcc < 4.8 doesn't grok -Wno-format-zero-length added in 8080775 In-Reply-To: <4295855A5C1DE049A61835A1887419CC41E7F42D@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC41E7EBD4@DEWDFEMB12A.global.corp.sap> <560E6506.3010608@oracle.com> <4295855A5C1DE049A61835A1887419CC41E7F3AF@DEWDFEMB12A.global.corp.sap> <56138A79.3010408@oracle.com> <4295855A5C1DE049A61835A1887419CC41E7F42D@DEWDFEMB12A.global.corp.sap> Message-ID: Hi Goetz, David, this change looks good. You can consider it as reviewed. I'd appreciate though if you could open a new bug for fixing the zero-length argument strings and removing "-Wno-format-zero-length". This new bug should be linked to the current big. Thank you and best regards, Volker On Tue, Oct 6, 2015 at 11:11 AM, Lindenmaier, Goetz wrote: > Hi David, > > thanks for reviewing! > > I also don't like that dependency, but in case -Wno-format-zero-length > is removed, that can be removed, too. > > Best regards, > Goetz. > > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of David Lindholm > Sent: Dienstag, 6. Oktober 2015 10:47 > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR(S): 8138733: Fix build: gcc < 4.8 doesn't grok -Wno-format-zero-length added in 8080775 > > Goetz, > > On 2015-10-06 09:06, Lindenmaier, Goetz wrote: >> Hi, >> >> could I please get a review and a sponsor for this change? >> http://cr.openjdk.java.net/~goetz/webrevs/8138733-warn/webrev.00/ > > While I don't really like the GCC-dependency in debug.hpp, I understand > that it is necessary for older GCCs. Reviewed. > > (I'm not an JDK 9 Reviewer). > > > Thanks, > David > >> Sorry for first posting to the wrong list. >> >> Best regards, >> Goetz. >> >> >> -----Original Message----- >> From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] >> Sent: Freitag, 2. Oktober 2015 13:06 >> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net Developers >> Subject: Re: RFR(S): 8138733: Fix build: gcc < 4.8 doesn't grok -Wno-format-zero-length added in 8080775 >> >> Redirecting to hotspot-dev at ... >> >> On 2015-10-02 12:58, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> We appreciate change 8080775 a lot, but it breaks the build with older gcc. >>> >>> They don't know the option -Wno-format-zero-length. >>> >>> To fix this, I only add -Wno-format-zero-length for gcc >= 4.8. >>> >>> For the other gccs, I remove ATTRIBUTE_PRINTF from the declaration of >>> >>> report_vm_error(). >>> >>> This is no big deal, as correctness is guaranteed once it's compiled with >>> >>> gcc 4.8. >>> >>> I had to fix one fatal() in the ppc files, too. >>> >>> Please review this change. I please need a sponsor. >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8138733-warn/webrev.00/ >>> >>> Best regards, >>> >>> Goetz. >>> > From jeanphilippe.bempel at ullink.com Wed Oct 7 08:03:32 2015 From: jeanphilippe.bempel at ullink.com (Jean Philippe Bempel) Date: Wed, 7 Oct 2015 10:03:32 +0200 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56147A5A.5040308@oracle.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56147A5A.5040308@oracle.com> Message-ID: It seems you suggest to hide this feature "? la" Unsafe to avoid exposing a new Java SE API. But the move is quite the opposite right now where all Unsafe "features" will find an exit to a public reliable API which is good and low latency and performance people is waiting for. JVM already uses the PAUSE instruction into the synchronized block implementation before inflating part which is also a sign of a good behavior that Java users would like to leverage on their code. Spinning is here since a long time now, and there is no evidence it will change in the next year. And even if this is changing, roll backing to a no-op implementation will be safe anyway. This JEP starts with a baby step, but some other stuffs are in the pipe (like Doug's list). The most difficult part is to agree on the API for future improvement in that area. *Jean-Philippe Bempel* *|* Software Architect* |* *ULLINK |* T: +33 1 49 95 10 29 | 23-25 rue de Provence | 75009 Paris | *jpbempel at ullink.com* | On Wed, Oct 7, 2015 at 3:50 AM, Joseph D. Darcy wrote: > > On 10/6/2015 6:28 PM, Gil Tene wrote: > >> On Oct 6, 2015, at 1:02 PM, Doug Lea

wrote: >>> >>> On 10/04/2015 12:22 PM, Gil Tene wrote: >>> >>>> I would like to circulate this draft JEP proposal for initial review >>>> and consensus building purposes. >>>> >>>> Some background: about two years ago, Dave Dice and I put together >>> a pre-jep proposal for JVM support for recent CPU features covering: >>> >>> (1) MWAIT/PAUSE/etc (for spins as well as other uses people have noted); >>> (2) Core topology/neighborhood information and; >>> (3) 2CAS, as a foothold on HTM that could still be reasonably efficient >>> on non-transactional processors. >>> >>> My understanding of the result of this effort was that Oracle JVM >>> engineers >>> didn't think they had resources to do this for jdk9. It didn't occur to >>> me that non-Oracle contributors might want to cherry-pick one (some >>> of (1) above). It seems plausible to do this, but only if designed >>> as the first of some possible enhanced support along these lines. >>> >> Good point. But that's what an actual community is about. Isn't it? >> >> We (Azul) are volunteering the resources for spinloopHint(). Including >> experimentation, implementation, testing, and even a TCK (which in this >> case >> will be trivial). So the vast majority of resources needed will not be >> coming >> other budgeted jdk9 resources. >> >> I certainly recognize that there will still be work involved that others >> will >> end up having to do: reviewing, arguing, contributing opinions, etc., as >> well >> as integrating the work into the whole. But this specific proposed JEP is >> about >> as narrow and low risk as you can get. especially from a specification >> point of >> view (e.g. intrinsic implementation can be left under a flag if deemed >> risky to >> stability or schedule). >> >> As for fitting in with larger-picture or theme things (listed above). I >> think that >> agonizing over the choice of where to put this is important (e.g. the >> Thread.spinLoopHint() >> idea, or a create new class that other hints will go into in the future, >> and where?). >> But I don't think that there is good reason to bundle this work with e.g. >> 2CAS, HTM, >> and affinity. Work. While we can think of them all as "support for recent >> CPU features", >> they are very different (and probably have multiple other unrelated >> groupings). >> >> MWAIT (and the like) and PAUSE do deserve some co-thinking (see earlier >> discussion >> on the thread). So does a discussion about a capturing abstraction like >> synchronic >> (raised in concurrency interest), But given the actual common uses >> already waiting >> for a spinLoopHint(), the very tangible and immediate benefit it shows, >> and the fact that >> most of the use cases wouldn't be able to make use of MWAIT (or the >> like), and some >> won't be able to use a synchronic-like thing, I think that either a >> spin-hint-only JEP >> is not just a good "shortcut", but also an actual stand-alone feature >> need. >> >> > Taking a long-term view, it seems to me premature to burn this kind of > hint into the Java SE API (effectively) forever in the absence of > experience that the hint in this form is useful and will continue to be > useful in 5 years, 10 years, etc. > > If the hint started out as a JDK-specific API, there would be (some) more > room to modify or drop the API in the future, leaving open the possibility > of migrating the functionality to the Java SE API too. > > -Joe > -- *The information contained in or attached to this email is strictly confidential. If you are not the intended recipient, please notify us immediately by telephone and return the message to us.* From david.lindholm at oracle.com Wed Oct 7 08:01:41 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Wed, 7 Oct 2015 10:01:41 +0200 Subject: RFR(S): 8138733: Fix build: gcc < 4.8 doesn't grok -Wno-format-zero-length added in 8080775 In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC41E7EBD4@DEWDFEMB12A.global.corp.sap> <560E6506.3010608@oracle.com> <4295855A5C1DE049A61835A1887419CC41E7F3AF@DEWDFEMB12A.global.corp.sap> <56138A79.3010408@oracle.com> <4295855A5C1DE049A61835A1887419CC41E7F42D@DEWDFEMB12A.global.corp.sap> Message-ID: <5614D165.3070400@oracle.com> Volker, I created a bug for this, JDK-8139035. Thanks, David On 2015-10-07 09:54, Volker Simonis wrote: > Hi Goetz, David, > > this change looks good. You can consider it as reviewed. > > I'd appreciate though if you could open a new bug for fixing the > zero-length argument strings and removing "-Wno-format-zero-length". > This new bug should be linked to the current big. > > Thank you and best regards, > Volker > > > On Tue, Oct 6, 2015 at 11:11 AM, Lindenmaier, Goetz > wrote: >> Hi David, >> >> thanks for reviewing! >> >> I also don't like that dependency, but in case -Wno-format-zero-length >> is removed, that can be removed, too. >> >> Best regards, >> Goetz. >> >> >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of David Lindholm >> Sent: Dienstag, 6. Oktober 2015 10:47 >> To: hotspot-dev at openjdk.java.net >> Subject: Re: RFR(S): 8138733: Fix build: gcc < 4.8 doesn't grok -Wno-format-zero-length added in 8080775 >> >> Goetz, >> >> On 2015-10-06 09:06, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> could I please get a review and a sponsor for this change? >>> http://cr.openjdk.java.net/~goetz/webrevs/8138733-warn/webrev.00/ >> While I don't really like the GCC-dependency in debug.hpp, I understand >> that it is necessary for older GCCs. Reviewed. >> >> (I'm not an JDK 9 Reviewer). >> >> >> Thanks, >> David >> >>> Sorry for first posting to the wrong list. >>> >>> Best regards, >>> Goetz. >>> >>> >>> -----Original Message----- >>> From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] >>> Sent: Freitag, 2. Oktober 2015 13:06 >>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net Developers >>> Subject: Re: RFR(S): 8138733: Fix build: gcc < 4.8 doesn't grok -Wno-format-zero-length added in 8080775 >>> >>> Redirecting to hotspot-dev at ... >>> >>> On 2015-10-02 12:58, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> We appreciate change 8080775 a lot, but it breaks the build with older gcc. >>>> >>>> They don't know the option -Wno-format-zero-length. >>>> >>>> To fix this, I only add -Wno-format-zero-length for gcc >= 4.8. >>>> >>>> For the other gccs, I remove ATTRIBUTE_PRINTF from the declaration of >>>> >>>> report_vm_error(). >>>> >>>> This is no big deal, as correctness is guaranteed once it's compiled with >>>> >>>> gcc 4.8. >>>> >>>> I had to fix one fatal() in the ppc files, too. >>>> >>>> Please review this change. I please need a sponsor. >>>> >>>> http://cr.openjdk.java.net/~goetz/webrevs/8138733-warn/webrev.00/ >>>> >>>> Best regards, >>>> >>>> Goetz. >>>> From aph at redhat.com Wed Oct 7 08:14:25 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 7 Oct 2015 09:14:25 +0100 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> Message-ID: <5614D461.8050403@redhat.com> On 05/10/15 21:43, Gil Tene wrote: > I see SpinLoopHint as very separate from things like MONITOR/WAIT > (on x86) and WFE/SEV (on ARM), as well as any other "wait in a nice > way until this state changes" instructions that other architectures > may have or add. > > Mechanisms like MONITOR/WAIT and WFE/SEV provide a way to > potentially wait for specific state changes to occur. As such, they > can be used to implement a specific form of a spin loop (the most > common one, probably). But they do not provide for generic spinning > forms. E.g. loops that have multiple exit conditions in different > memory locations, loops that wait on internal state changes that are > no affected by other CPUs (like "spin only this many times before > giving up" or "spin for this much time"), and loops that may use > transactional state changes (e.g. LOCK XADD, or wider things with > TSX) are probably "hard" to model with these instructions. Yes, you're right: there's no real way to combine these things, and support for WFE requires some other kind of interface -- if I ever manage to think of a nice way to express it in Java. So, my apologies for hijacking this thread, but now you've got me thinking. In an ideal world there would be a timer associated with WFE which would trigger after a short while and allow a thread to be descheduled. However, it is possible to set a periodic timer which regularly signals each worker thread, giving it the opportunity to block if unused for a long time. This should make a much more responsive thread pool, so that when worker threads are active they respond in nanoseconds rather than microseconds. [ An aside: WFE is available in user mode, and according to Intel's documentation it should be possible to configre an OS to use MONITOR/WAIT in user mode too. I don't know why it doesn't work. ] Andrew. From aph at redhat.com Wed Oct 7 08:24:58 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 7 Oct 2015 09:24:58 +0100 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56147A5A.5040308@oracle.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56147A5A.5040308@oracle.com> Message-ID: <5614D6DA.7080008@redhat.com> On 07/10/15 02:50, Joseph D. Darcy wrote: > Taking a long-term view, it seems to me premature to burn this kind of > hint into the Java SE API (effectively) forever in the absence of > experience that the hint in this form is useful and will continue to be > useful in 5 years, 10 years, etc. This seems to me to be a very odd thing to say. Of course there is no experience with this in Java because it's not been available, but there is plenty of experience outside Java. If this goes into a JDK- specific API we'll also have to support it for a long while or we'll break programs. It's not obvious how pushing this outside Java SE will aid practical portability. Also, this hint is very much in tune with the trend to do more in Java and less in native code: it moves the barrier between code that must be native and can be Java. That's a good thing. Andrew. From goetz.lindenmaier at sap.com Wed Oct 7 08:59:54 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 7 Oct 2015 08:59:54 +0000 Subject: RFR(S): 8138733: Fix build: gcc < 4.8 doesn't grok -Wno-format-zero-length added in 8080775 In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC41E7EBD4@DEWDFEMB12A.global.corp.sap> <560E6506.3010608@oracle.com> <4295855A5C1DE049A61835A1887419CC41E7F3AF@DEWDFEMB12A.global.corp.sap> <56138A79.3010408@oracle.com> <4295855A5C1DE049A61835A1887419CC41E7F42D@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC41E80A02@DEWDFEMB12A.global.corp.sap> Hi Volker, thanks for the review! Best regards, Goetz. -----Original Message----- From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Mittwoch, 7. Oktober 2015 09:54 To: Lindenmaier, Goetz Cc: David Lindholm; hotspot-dev at openjdk.java.net Subject: Re: RFR(S): 8138733: Fix build: gcc < 4.8 doesn't grok -Wno-format-zero-length added in 8080775 Hi Goetz, David, this change looks good. You can consider it as reviewed. I'd appreciate though if you could open a new bug for fixing the zero-length argument strings and removing "-Wno-format-zero-length". This new bug should be linked to the current big. Thank you and best regards, Volker On Tue, Oct 6, 2015 at 11:11 AM, Lindenmaier, Goetz wrote: > Hi David, > > thanks for reviewing! > > I also don't like that dependency, but in case -Wno-format-zero-length > is removed, that can be removed, too. > > Best regards, > Goetz. > > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of David Lindholm > Sent: Dienstag, 6. Oktober 2015 10:47 > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR(S): 8138733: Fix build: gcc < 4.8 doesn't grok -Wno-format-zero-length added in 8080775 > > Goetz, > > On 2015-10-06 09:06, Lindenmaier, Goetz wrote: >> Hi, >> >> could I please get a review and a sponsor for this change? >> http://cr.openjdk.java.net/~goetz/webrevs/8138733-warn/webrev.00/ > > While I don't really like the GCC-dependency in debug.hpp, I understand > that it is necessary for older GCCs. Reviewed. > > (I'm not an JDK 9 Reviewer). > > > Thanks, > David > >> Sorry for first posting to the wrong list. >> >> Best regards, >> Goetz. >> >> >> -----Original Message----- >> From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] >> Sent: Freitag, 2. Oktober 2015 13:06 >> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net Developers >> Subject: Re: RFR(S): 8138733: Fix build: gcc < 4.8 doesn't grok -Wno-format-zero-length added in 8080775 >> >> Redirecting to hotspot-dev at ... >> >> On 2015-10-02 12:58, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> We appreciate change 8080775 a lot, but it breaks the build with older gcc. >>> >>> They don't know the option -Wno-format-zero-length. >>> >>> To fix this, I only add -Wno-format-zero-length for gcc >= 4.8. >>> >>> For the other gccs, I remove ATTRIBUTE_PRINTF from the declaration of >>> >>> report_vm_error(). >>> >>> This is no big deal, as correctness is guaranteed once it's compiled with >>> >>> gcc 4.8. >>> >>> I had to fix one fatal() in the ppc files, too. >>> >>> Please review this change. I please need a sponsor. >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8138733-warn/webrev.00/ >>> >>> Best regards, >>> >>> Goetz. >>> > From tobias.hartmann at oracle.com Wed Oct 7 10:27:10 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 07 Oct 2015 12:27:10 +0200 Subject: [8u] Request for approval and review: 8075805: Crash while trying to release CompiledICHolder Message-ID: <5614F37E.8090208@oracle.com> Hi, please approve and review the following backport to 8u. 8075805: Crash while trying to release CompiledICHolder https://bugs.openjdk.java.net/browse/JDK-8075805 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c0ea5537dc8b http://cr.openjdk.java.net/~thartmann/8075805/webrev.01/ I would also like to backport this follow up change that fixes an issue with the fix for 8075805: 8134493: Cleaning inline caches of unloaded nmethods should be done in sweeper https://bugs.openjdk.java.net/browse/JDK-8134493 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9df4555d2d7d http://cr.openjdk.java.net/~thartmann/8134493/webrev.01/ Unfortunately, both changesets do not apply cleanly to 8u. I merged the fixes, here are the new webrevs: JDK-8075805: http://cr.openjdk.java.net/~thartmann/8075805_8u/webrev.00/ JDK-8134493 (incremental): http://cr.openjdk.java.net/~thartmann/8134493_8u/webrev.00/ Both changes: http://cr.openjdk.java.net/~thartmann/8075805_8134493_8u/webrev.00/ Both fixes were pushed some months ago and testing showed no problems. Thanks, Tobias From aph at redhat.com Wed Oct 7 11:47:56 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 7 Oct 2015 12:47:56 +0100 Subject: hs-rt, hs-comp, etc. Message-ID: <5615066C.60307@redhat.com> I'm trying to test AArch64 HotSpot. Unfortunately, some fatal bugs are corrected in hs-rt/hotspot, and some in hs-comp/hotspot. This means that there is no checked-out tree I can test. What do y'all do? Thanks, Andrew. From tobias.hartmann at oracle.com Wed Oct 7 11:48:33 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 07 Oct 2015 13:48:33 +0200 Subject: [8u] Request for approval and review: 8075805: Crash while trying to release CompiledICHolder In-Reply-To: <5614F6EE.9000501@oracle.com> References: <5614F37E.8090208@oracle.com> <5614F6EE.9000501@oracle.com> Message-ID: <56150691.9030407@oracle.com> Thanks, David. On 07.10.2015 12:41, david buck wrote: > approved for 8u-dev backport pending successful completion of code review > > Please add the appropriate noreg label to JDK-8134493. Done (noreg-hard). Best, Tobias > > Cheers, > -Buck > > On 2015/10/07 19:27, Tobias Hartmann wrote: >> Hi, >> >> please approve and review the following backport to 8u. >> >> 8075805: Crash while trying to release CompiledICHolder >> https://bugs.openjdk.java.net/browse/JDK-8075805 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c0ea5537dc8b >> http://cr.openjdk.java.net/~thartmann/8075805/webrev.01/ >> >> I would also like to backport this follow up change that fixes an issue with the fix for 8075805: >> >> 8134493: Cleaning inline caches of unloaded nmethods should be done in sweeper >> https://bugs.openjdk.java.net/browse/JDK-8134493 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9df4555d2d7d >> http://cr.openjdk.java.net/~thartmann/8134493/webrev.01/ >> >> Unfortunately, both changesets do not apply cleanly to 8u. I merged the fixes, here are the new webrevs: >> >> JDK-8075805: >> http://cr.openjdk.java.net/~thartmann/8075805_8u/webrev.00/ >> >> JDK-8134493 (incremental): >> http://cr.openjdk.java.net/~thartmann/8134493_8u/webrev.00/ >> >> Both changes: >> http://cr.openjdk.java.net/~thartmann/8075805_8134493_8u/webrev.00/ >> >> Both fixes were pushed some months ago and testing showed no problems. >> >> Thanks, >> Tobias >> From dmitry.samersoff at oracle.com Wed Oct 7 11:54:26 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 7 Oct 2015 14:54:26 +0300 Subject: hs-rt, hs-comp, etc. In-Reply-To: <5615066C.60307@redhat.com> References: <5615066C.60307@redhat.com> Message-ID: <561507F2.500@oracle.com> Andrew, You can try hs-main: http://hg.openjdk.java.net/jdk9/hs If all required fixes is not there yet, you can try to merge it by your self (typically it's straightforward) or wait for about a week. hs-comp -> main than hs-rt -> main. -Dmitry On 2015-10-07 14:47, Andrew Haley wrote: > I'm trying to test AArch64 HotSpot. > > Unfortunately, some fatal bugs are corrected in hs-rt/hotspot, and some > in hs-comp/hotspot. This means that there is no checked-out tree I can > test. > > What do y'all do? > > Thanks, > Andrew. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From volker.simonis at gmail.com Wed Oct 7 12:13:50 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 7 Oct 2015 14:13:50 +0200 Subject: RFR(S): 8138733: Fix build: gcc < 4.8 doesn't grok -Wno-format-zero-length added in 8080775 In-Reply-To: <5614D165.3070400@oracle.com> References: <4295855A5C1DE049A61835A1887419CC41E7EBD4@DEWDFEMB12A.global.corp.sap> <560E6506.3010608@oracle.com> <4295855A5C1DE049A61835A1887419CC41E7F3AF@DEWDFEMB12A.global.corp.sap> <56138A79.3010408@oracle.com> <4295855A5C1DE049A61835A1887419CC41E7F42D@DEWDFEMB12A.global.corp.sap> <5614D165.3070400@oracle.com> Message-ID: Great - thanks a lot. Volker On Wed, Oct 7, 2015 at 10:01 AM, David Lindholm wrote: > Volker, > > I created a bug for this, JDK-8139035. > > > Thanks, > David > > > On 2015-10-07 09:54, Volker Simonis wrote: >> >> Hi Goetz, David, >> >> this change looks good. You can consider it as reviewed. >> >> I'd appreciate though if you could open a new bug for fixing the >> zero-length argument strings and removing "-Wno-format-zero-length". >> This new bug should be linked to the current big. >> >> Thank you and best regards, >> Volker >> >> >> On Tue, Oct 6, 2015 at 11:11 AM, Lindenmaier, Goetz >> wrote: >>> >>> Hi David, >>> >>> thanks for reviewing! >>> >>> I also don't like that dependency, but in case -Wno-format-zero-length >>> is removed, that can be removed, too. >>> >>> Best regards, >>> Goetz. >>> >>> >>> -----Original Message----- >>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf >>> Of David Lindholm >>> Sent: Dienstag, 6. Oktober 2015 10:47 >>> To: hotspot-dev at openjdk.java.net >>> Subject: Re: RFR(S): 8138733: Fix build: gcc < 4.8 doesn't grok >>> -Wno-format-zero-length added in 8080775 >>> >>> Goetz, >>> >>> On 2015-10-06 09:06, Lindenmaier, Goetz wrote: >>>> >>>> Hi, >>>> >>>> could I please get a review and a sponsor for this change? >>>> http://cr.openjdk.java.net/~goetz/webrevs/8138733-warn/webrev.00/ >>> >>> While I don't really like the GCC-dependency in debug.hpp, I understand >>> that it is necessary for older GCCs. Reviewed. >>> >>> (I'm not an JDK 9 Reviewer). >>> >>> >>> Thanks, >>> David >>> >>>> Sorry for first posting to the wrong list. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> -----Original Message----- >>>> From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] >>>> Sent: Freitag, 2. Oktober 2015 13:06 >>>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net Developers >>>> Subject: Re: RFR(S): 8138733: Fix build: gcc < 4.8 doesn't grok >>>> -Wno-format-zero-length added in 8080775 >>>> >>>> Redirecting to hotspot-dev at ... >>>> >>>> On 2015-10-02 12:58, Lindenmaier, Goetz wrote: >>>>> >>>>> Hi, >>>>> >>>>> We appreciate change 8080775 a lot, but it breaks the build with older >>>>> gcc. >>>>> >>>>> They don't know the option -Wno-format-zero-length. >>>>> >>>>> To fix this, I only add -Wno-format-zero-length for gcc >= 4.8. >>>>> >>>>> For the other gccs, I remove ATTRIBUTE_PRINTF from the declaration of >>>>> >>>>> report_vm_error(). >>>>> >>>>> This is no big deal, as correctness is guaranteed once it's compiled >>>>> with >>>>> >>>>> gcc 4.8. >>>>> >>>>> I had to fix one fatal() in the ppc files, too. >>>>> >>>>> Please review this change. I please need a sponsor. >>>>> >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8138733-warn/webrev.00/ >>>>> >>>>> Best regards, >>>>> >>>>> Goetz. >>>>> > From vladimir.kozlov at oracle.com Wed Oct 7 12:43:20 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 7 Oct 2015 20:43:20 +0800 Subject: [8u] Request for approval and review: 8075805: Crash while trying to release CompiledICHolder In-Reply-To: <5614F37E.8090208@oracle.com> References: <5614F37E.8090208@oracle.com> Message-ID: <56151368.3030405@oracle.com> Changes are matching jdk9 changes. Tobias, should we backport 8058737 changes too? Next code is missing in 8u now: + MutexLocker cl(CompiledIC_lock); + nm->clear_ic_stubs(); It was P2. Why we did not backport it? Thanks, Vladimir On 10/7/15 6:27 PM, Tobias Hartmann wrote: > Hi, > > please approve and review the following backport to 8u. > > 8075805: Crash while trying to release CompiledICHolder > https://bugs.openjdk.java.net/browse/JDK-8075805 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c0ea5537dc8b > http://cr.openjdk.java.net/~thartmann/8075805/webrev.01/ > > I would also like to backport this follow up change that fixes an issue with the fix for 8075805: > > 8134493: Cleaning inline caches of unloaded nmethods should be done in sweeper > https://bugs.openjdk.java.net/browse/JDK-8134493 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9df4555d2d7d > http://cr.openjdk.java.net/~thartmann/8134493/webrev.01/ > > Unfortunately, both changesets do not apply cleanly to 8u. I merged the fixes, here are the new webrevs: > > JDK-8075805: > http://cr.openjdk.java.net/~thartmann/8075805_8u/webrev.00/ > > JDK-8134493 (incremental): > http://cr.openjdk.java.net/~thartmann/8134493_8u/webrev.00/ > > Both changes: > http://cr.openjdk.java.net/~thartmann/8075805_8134493_8u/webrev.00/ > > Both fixes were pushed some months ago and testing showed no problems. > > Thanks, > Tobias > From david.lindholm at oracle.com Wed Oct 7 13:12:01 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Wed, 7 Oct 2015 15:12:01 +0200 Subject: RFR: 8138832: CreateCoredumpOnCrash on linux ARM causes assert message to be repeated. Message-ID: <56151A21.2060002@oracle.com> Hi, Please review this patch. The unnecessary wide jlong type were used to store a thread_id, even on 32bit platforms. Instead I now use an intptr_t. Bug: https://bugs.openjdk.java.net/browse/JDK-8138832 Webrev: http://cr.openjdk.java.net/~david/JDK-8138832/webrev.00/ Testing: Passed JPRT and verified that the failing test works now. Thanks, David From jesper.wilhelmsson at oracle.com Wed Oct 7 13:19:34 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 7 Oct 2015 15:19:34 +0200 Subject: RFR: 8138832: CreateCoredumpOnCrash on linux ARM causes assert message to be repeated. In-Reply-To: <56151A21.2060002@oracle.com> References: <56151A21.2060002@oracle.com> Message-ID: <56151BE6.2020403@oracle.com> Looks good! /Jesper Den 7/10/15 kl. 15:12, skrev David Lindholm: > Hi, > > Please review this patch. The unnecessary wide jlong type were used to store a > thread_id, even on 32bit platforms. Instead I now use an intptr_t. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8138832 > Webrev: http://cr.openjdk.java.net/~david/JDK-8138832/webrev.00/ > > Testing: Passed JPRT and verified that the failing test works now. > > > Thanks, > David From mikael.gerdin at oracle.com Wed Oct 7 13:22:27 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 7 Oct 2015 15:22:27 +0200 Subject: RFR: 8138832: CreateCoredumpOnCrash on linux ARM causes assert message to be repeated. In-Reply-To: <56151A21.2060002@oracle.com> References: <56151A21.2060002@oracle.com> Message-ID: <56151C93.20603@oracle.com> Hi David, On 2015-10-07 15:12, David Lindholm wrote: > Hi, > > Please review this patch. The unnecessary wide jlong type were used to > store a thread_id, even on 32bit platforms. Instead I now use an intptr_t. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8138832 > Webrev: http://cr.openjdk.java.net/~david/JDK-8138832/webrev.00/ Looks good. /Mikael > > Testing: Passed JPRT and verified that the failing test works now. > > > Thanks, > David From roland.westrelin at oracle.com Wed Oct 7 13:28:55 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 7 Oct 2015 15:28:55 +0200 Subject: RFR: String Density/Compact String JEP 254 In-Reply-To: <56129786.1090402@oracle.com> References: <56129786.1090402@oracle.com> Message-ID: <628568DB-F47A-4BD7-A032-2BECD0E2C539@oracle.com> > http://cr.openjdk.java.net/~thartmann/compact_strings/webrev/hotspot I looked at the compiler related files only. intrinsicnode.hpp A comment would be nice: 49 typedef enum ArgEncoding { LL, LU, UL, UU, none } ArgEnc; The (ASSERT only) comment should be removed: 53 virtual uint size_of() const; // Size is bigger (ASSERT only) library_call.cpp In LibraryCallKit::inline_hasNegatives(), don?t you need to test for too many Deoptimization::Reason_intrinsic before intrinsifying? Shouldn?t LibraryCallKit::inline_string_toBytesU() and LibraryCallKit::inline_string_getCharsU() use an ArrayCopyNode (maybe an improvement/cleanup for later)? Same is true for PhaseStringOpts::arraycopy macroAssembler_sparc.cpp I don?t think you should reference c2 stuff outside c2: 4440 if (ae == StrIntrinsicNode::LU || ae == StrIntrinsicNode::UL) { Roland. From bertrand.delsart at oracle.com Wed Oct 7 14:10:55 2015 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Wed, 7 Oct 2015 16:10:55 +0200 Subject: RFR: 8138832: CreateCoredumpOnCrash on linux ARM causes assert message to be repeated. In-Reply-To: <56151A21.2060002@oracle.com> References: <56151A21.2060002@oracle.com> Message-ID: <561527EF.1040602@oracle.com> Approved :-) Bertrand. On 07/10/2015 15:12, David Lindholm wrote: > Hi, > > Please review this patch. The unnecessary wide jlong type were used to > store a thread_id, even on 32bit platforms. Instead I now use an intptr_t. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8138832 > Webrev: http://cr.openjdk.java.net/~david/JDK-8138832/webrev.00/ > > Testing: Passed JPRT and verified that the failing test works now. > > > Thanks, > David -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38330 Montbonnot Saint Martin, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From tobias.hartmann at oracle.com Wed Oct 7 14:19:48 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 07 Oct 2015 16:19:48 +0200 Subject: [8u] Request for approval and review: 8075805: Crash while trying to release CompiledICHolder In-Reply-To: <56151368.3030405@oracle.com> References: <5614F37E.8090208@oracle.com> <56151368.3030405@oracle.com> Message-ID: <56152A04.8040006@oracle.com> Hi Vladimir, On 07.10.2015 14:43, Vladimir Kozlov wrote: > Changes are matching jdk9 changes. > Tobias, should we backport 8058737 changes too? Next code is missing in 8u now: > > + MutexLocker cl(CompiledIC_lock); > + nm->clear_ic_stubs(); > > It was P2. Why we did not backport it? Yes, you are right. It seems like I missed to backport that one because it never showed up with 8. However, we should backport it. The patch for JDK-8058737 applies cleanly. I updated the other webrevs: JDK-8058737: CodeCache::find_blob fails with 'unsafe access to zombie method' https://bugs.openjdk.java.net/browse/JDK-8058737 http://cr.openjdk.java.net/~thartmann/8058737/webrev.01/ JDK-8075805: Crash while trying to release CompiledICHolder https://bugs.openjdk.java.net/browse/JDK-8075805 http://cr.openjdk.java.net/~thartmann/8075805_8u/webrev.01/ JDK-8134493: Cleaning inline caches of unloaded nmethods should be done in sweeper https://bugs.openjdk.java.net/browse/JDK-8134493 http://cr.openjdk.java.net/~thartmann/8134493_8u/webrev.01/ All changes (now also including 8058737) : http://cr.openjdk.java.net/~thartmann/8075805_8134493_8u/webrev.01 Thanks, Tobias > Thanks, > Vladimir > > On 10/7/15 6:27 PM, Tobias Hartmann wrote: >> Hi, >> >> please approve and review the following backport to 8u. >> >> 8075805: Crash while trying to release CompiledICHolder >> https://bugs.openjdk.java.net/browse/JDK-8075805 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c0ea5537dc8b >> http://cr.openjdk.java.net/~thartmann/8075805/webrev.01/ >> >> I would also like to backport this follow up change that fixes an issue with the fix for 8075805: >> >> 8134493: Cleaning inline caches of unloaded nmethods should be done in sweeper >> https://bugs.openjdk.java.net/browse/JDK-8134493 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9df4555d2d7d >> http://cr.openjdk.java.net/~thartmann/8134493/webrev.01/ >> >> Unfortunately, both changesets do not apply cleanly to 8u. I merged the fixes, here are the new webrevs: >> >> JDK-8075805: >> http://cr.openjdk.java.net/~thartmann/8075805_8u/webrev.00/ >> >> JDK-8134493 (incremental): >> http://cr.openjdk.java.net/~thartmann/8134493_8u/webrev.00/ >> >> Both changes: >> http://cr.openjdk.java.net/~thartmann/8075805_8134493_8u/webrev.00/ >> >> Both fixes were pushed some months ago and testing showed no problems. >> >> Thanks, >> Tobias >> From vladimir.kozlov at oracle.com Wed Oct 7 14:23:13 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 7 Oct 2015 22:23:13 +0800 Subject: [8u] Request for approval and review: 8075805: Crash while trying to release CompiledICHolder In-Reply-To: <56152A04.8040006@oracle.com> References: <5614F37E.8090208@oracle.com> <56151368.3030405@oracle.com> <56152A04.8040006@oracle.com> Message-ID: <56152AD1.6040600@oracle.com> Nice. Looks good. Thanks, Vladimir On 10/7/15 10:19 PM, Tobias Hartmann wrote: > Hi Vladimir, > > On 07.10.2015 14:43, Vladimir Kozlov wrote: >> Changes are matching jdk9 changes. >> Tobias, should we backport 8058737 changes too? Next code is missing in 8u now: >> >> + MutexLocker cl(CompiledIC_lock); >> + nm->clear_ic_stubs(); >> >> It was P2. Why we did not backport it? > > Yes, you are right. It seems like I missed to backport that one because it never showed up with 8. However, we should backport it. The patch for JDK-8058737 applies cleanly. I updated the other webrevs: > > JDK-8058737: CodeCache::find_blob fails with 'unsafe access to zombie method' > https://bugs.openjdk.java.net/browse/JDK-8058737 > http://cr.openjdk.java.net/~thartmann/8058737/webrev.01/ > > JDK-8075805: Crash while trying to release CompiledICHolder > https://bugs.openjdk.java.net/browse/JDK-8075805 > http://cr.openjdk.java.net/~thartmann/8075805_8u/webrev.01/ > > JDK-8134493: Cleaning inline caches of unloaded nmethods should be done in sweeper > https://bugs.openjdk.java.net/browse/JDK-8134493 > http://cr.openjdk.java.net/~thartmann/8134493_8u/webrev.01/ > > All changes (now also including 8058737) : > http://cr.openjdk.java.net/~thartmann/8075805_8134493_8u/webrev.01 > > Thanks, > Tobias > > >> Thanks, >> Vladimir >> >> On 10/7/15 6:27 PM, Tobias Hartmann wrote: >>> Hi, >>> >>> please approve and review the following backport to 8u. >>> >>> 8075805: Crash while trying to release CompiledICHolder >>> https://bugs.openjdk.java.net/browse/JDK-8075805 >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c0ea5537dc8b >>> http://cr.openjdk.java.net/~thartmann/8075805/webrev.01/ >>> >>> I would also like to backport this follow up change that fixes an issue with the fix for 8075805: >>> >>> 8134493: Cleaning inline caches of unloaded nmethods should be done in sweeper >>> https://bugs.openjdk.java.net/browse/JDK-8134493 >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9df4555d2d7d >>> http://cr.openjdk.java.net/~thartmann/8134493/webrev.01/ >>> >>> Unfortunately, both changesets do not apply cleanly to 8u. I merged the fixes, here are the new webrevs: >>> >>> JDK-8075805: >>> http://cr.openjdk.java.net/~thartmann/8075805_8u/webrev.00/ >>> >>> JDK-8134493 (incremental): >>> http://cr.openjdk.java.net/~thartmann/8134493_8u/webrev.00/ >>> >>> Both changes: >>> http://cr.openjdk.java.net/~thartmann/8075805_8134493_8u/webrev.00/ >>> >>> Both fixes were pushed some months ago and testing showed no problems. >>> >>> Thanks, >>> Tobias >>> From david.lindholm at oracle.com Wed Oct 7 15:39:16 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Wed, 7 Oct 2015 17:39:16 +0200 Subject: RFR: 8042893 and 8042894: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files Message-ID: <56153CA4.2050008@oracle.com> Hi, Please review the following patch that removes PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC from all source files in HotSpot. It also fixes all compiler warnings caused by format strings that were previously silenced by this pragma. This patch is a joint effort by me and Goetz Lindenmaier. Bug: https://bugs.openjdk.java.net/browse/JDK-8042893 Bug: https://bugs.openjdk.java.net/browse/JDK-8042894 Webrev: http://cr.openjdk.java.net/~david/JDK-8042893-8042894/webrev.00/ Testing: Passed JPRT Thanks, David From gil at azulsystems.com Wed Oct 7 15:45:44 2015 From: gil at azulsystems.com (Gil Tene) Date: Wed, 7 Oct 2015 15:45:44 +0000 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <5614D461.8050403@redhat.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> , <5614D461.8050403@redhat.com> Message-ID: Sent from Gil's iPhone > On Oct 7, 2015, at 1:14 AM, Andrew Haley wrote: > >> On 05/10/15 21:43, Gil Tene wrote: >> >> I see SpinLoopHint as very separate from things like MONITOR/WAIT >> (on x86) and WFE/SEV (on ARM), as well as any other "wait in a nice >> way until this state changes" instructions that other architectures >> may have or add. >> >> Mechanisms like MONITOR/WAIT and WFE/SEV provide a way to >> potentially wait for specific state changes to occur. As such, they >> can be used to implement a specific form of a spin loop (the most >> common one, probably). But they do not provide for generic spinning >> forms. E.g. loops that have multiple exit conditions in different >> memory locations, loops that wait on internal state changes that are >> no affected by other CPUs (like "spin only this many times before >> giving up" or "spin for this much time"), and loops that may use >> transactional state changes (e.g. LOCK XADD, or wider things with >> TSX) are probably "hard" to model with these instructions. > > Yes, you're right: there's no real way to combine these things, and > support for WFE requires some other kind of interface -- if I ever > manage to think of a nice way to express it in Java. So, my > apologies for hijacking this thread, but now you've got me thinking. > > In an ideal world there would be a timer associated with WFE which > would trigger after a short while and allow a thread to be > descheduled. However, it is possible to set a periodic timer which > regularly signals each worker thread, giving it the opportunity to > block if unused for a long time. This should make a much more > responsive thread pool, so that when worker threads are active they > respond in nanoseconds rather than microseconds. The problem with using timer based interrupts to kick out of WFE or MWAIT situations is that the granularity is often too thin for timers (and interrupts). E.g. j.u.c often uses "magic number of spins" of 64 or so before backed my out of the spin. That's just too short to get a timer going (and canceled) in, and the overhead of interrupt handling will overwhelm the actual action being attempted. "What we really need" for WFE/MEAIT hardware instructions to be useful in this space (of spin-for-bit-before-giving-up) is for the instructions to take a timeout argument (e.g. # of clock cycles. A power of two would probably suffice, so not slot of bits needed). But that's just not how they work on current HW... > > [ An aside: WFE is available in user mode, and according to Intel's > documentation it should be possible to configre an OS to use > MONITOR/WAIT in user mode too. I don't know why it doesn't work. ] While there are some ambiguous suggestions that MONITOR/MWAIT may be available in CPLs above 0 in some documentation, the current documentation for the actual MWAIT instruction is pretty clear about it only working in privilege level 0. So maybe this will be relaxed in the future? In any case, even if it were user-mode-accessible, MWAIT may not appropriate for latency-sensitive spinning because it can apparently take 1000s of cycles to come out of the C-state modes it goes into. At those level, you may be better off blocking or yielding, and no one would make use of it if they care about quick reaction time. It may be that it's not that bad, depending on the cstate requested, but the fact that Linux kernels don't currently use MWAIT for spin loops suggests that it not good for that use case yet. For ARM, I expect WFE/SEV to need to evolve as well, and for other reasons, even fit use within OSs. The current WFE/SEV scheme is not scalable. While it probably works ok for spinning at the kernel level on hardware that only has s handful of cores, the fact that the event WFE waits for (and SEV sends) is global to the system will break things as core counts grow (it is the hardware equivalent of wait/notifyAll() with a single global monitor). I expect that for OSs to use it for spinning on many-core systems, there would need to be some de-muxing capability added (e.g. by address or by some id). In its current form, it is probably not ready for exposure to user mode code. (Imagine what would happen if user code started doing system-wide SEVs on every unlock). From aph at redhat.com Wed Oct 7 15:49:49 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 7 Oct 2015 16:49:49 +0100 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> <5614D461.8050403@redhat.com> Message-ID: <56153F1D.80503@redhat.com> On 10/07/2015 04:45 PM, Gil Tene wrote: > In any case, even if it were user-mode-accessible, MWAIT may not appropriate for latency-sensitive spinning because it can apparently take 1000s of cycles to come out of the C-state modes it goes into. Oh, yuck. OK, forget it. Thanks, Andrew. From aph at redhat.com Wed Oct 7 15:51:39 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 7 Oct 2015 16:51:39 +0100 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> <5614D461.8050403@redhat.com> Message-ID: <56153F8B.8000102@redhat.com> On 10/07/2015 04:45 PM, Gil Tene wrote: > For ARM, I expect WFE/SEV to need to evolve as well, and for other > reasons, even fit use within OSs. The current WFE/SEV scheme is not > scalable. While it probably works ok for spinning at the kernel > level on hardware that only has s handful of cores, the fact that > the event WFE waits for (and SEV sends) is global to the system will > break things as core counts grow (it is the hardware equivalent of > wait/notifyAll() with a single global monitor). That's not how it works. It's sufficient to write to the lock word to wake a core from a WFE: SEV is not required. Each core has its own event monitor, and wakeup is handled by the cache coherency logic. Andrew. From kim.barrett at oracle.com Wed Oct 7 16:02:19 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 7 Oct 2015 12:02:19 -0400 Subject: RFR: 8138659: Speed up InstanceKlass subclass discrimination In-Reply-To: <5422E78A-5321-406D-9997-7A19BB4A4ABD@oracle.com> References: <5612D757.5040905@oracle.com> <5422E78A-5321-406D-9997-7A19BB4A4ABD@oracle.com> Message-ID: <294721F8-D7E7-4FB5-9CC7-39C984EC87F0@oracle.com> Another round, with some name changes that resulted from discussion with StefanK and Coleen. Also, Coleen convinced me some functions weren't needed. New full and incremental webrevs: http://cr.openjdk.java.net/~kbarrett/8138659/webrev.02/ http://cr.openjdk.java.net/~kbarrett/8138659/webrev.02.inc/ From daniel.daugherty at oracle.com Wed Oct 7 16:13:18 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 7 Oct 2015 10:13:18 -0600 Subject: RFR(xxs): [windows] Build broken on VS2010 after "8046148: JEP 158: Unified JVM Logging" In-Reply-To: References: <560A9F58.2080309@oracle.com>

<560BE5A9.2000706@oracle.com>

Message-ID: <5615449E.2060903@oracle.com> Thomas, I'm on it... While there have been several comments on the review thread (including mine), the only clear review of the bits came from Volker who suggested a change that motivated the new webrev... I'll (R)eview the latest version shortly. Dan On 10/7/15 1:01 AM, Thomas St?fe wrote: > Hi all, > > could I have a sponsor please? > > I think enough people think this makes sense to fix, and the fix is cheap > and small. > > bug: https://bugs.openjdk.java.net/browse/JDK-8137329 > patch: http://cr.openjdk.java.net/~stuefe/webrevs/8137329/webrev.01/webrev/ > > Thanks! > > Thomas > > On Mon, Oct 5, 2015 at 3:25 PM, Thomas St?fe > wrote: > >> Hi all, >> >> may I have a sponsor please? >> >> Or have we decided not to fix this ? >> >> Regards, Thomas >> >> On Thu, Oct 1, 2015 at 9:41 AM, Thomas St?fe >> wrote: >> >>> Hi all, >>> >>> New version of this patch: >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8137329/webrev.01/webrev/ >>> >>> As Volker suggests, makes the workaround depend on _MSC_VER and also >>> moves the patch to globalDefinitions_visCPP.hpp where it fits better and >>> works for the whole hotspot. >>> >>> Kind regards, Thomas >>> >>> >>> On Wed, Sep 30, 2015 at 3:51 PM, Volker Simonis >>> wrote: >>>> Hi, >>>> >>>> I second Phil,Goetz and Magnus and think this is a good change. >>>> >>>> But I suggest we should use "#if _MSC_VER < 1800" together with a >>>> small comment instead of "#ifdef _WIN32" to make it more clear why we >>>> have to redefine strtoull. >>>> >>>> Regards, >>>> Volker >>>> >>>> >>>> On Wed, Sep 30, 2015 at 3:37 PM, Magnus Ihse Bursie >>>> wrote: >>>>> On 2015-09-30 14:40, Thomas St?fe wrote: >>>>>> I would like to hear more opinions, and possibly a sponsor and a >>>> reviewer. >>>>>> In my opinion it makes sense to fix this. The fix is small and cheap >>>> and >>>>>> makes people happy who still work with older versions of VS2010. >>>>> I agree. It makes sense for trivial fixes to extend the range of >>>> compiler >>>>> versions that are possible to use. Major changes to support older >>>> compilers >>>>> is another thing, but simple stuff like this should be a no-brainer. >>>> This is >>>>> not really related to the fact that Oracle internally uses a specific >>>>> version for daily quality control. >>>>> >>>>> /Magnus >>>>> >>>>>> Kind Regards, Thomas >>>>>> >>>>>> On Tue, Sep 29, 2015 at 5:12 PM, Thomas St?fe < >>>> thomas.stuefe at gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Ok, I did not check this. Nevermind, then. >>>>>>> >>>>>>> Kind Regards, Thomas >>>>>>> >>>>>>> On Tue, Sep 29, 2015 at 4:25 PM, Daniel D. Daugherty < >>>>>>> daniel.daugherty at oracle.com> wrote: >>>>>>> >>>>>>>> Ummm... VS2013 is the official compiler for JDK9 and Win*. >>>>>>>> Why would we want to make a change to permit VS2010 to >>>>>>>> continue to be used? >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>> On 9/29/15 7:58 AM, Thomas St?fe wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> please review this tiny change. It fixes the build on >>>> windows/Visual >>>>>>>>> Studio >>>>>>>>> 2010 after "8046148: JEP 158: Unified JVM Logging". >>>>>>>>> >>>>>>>>> strtoull() is missing from Visual Studio versions < 2013, but >>>>>>>>> _strtoui64() >>>>>>>>> can be used instead. >>>>>>>>> >>>>>>>>> webrev: >>>>>>>>> >>>> http://cr.openjdk.java.net/~stuefe/webrevs/8137329/webrev.00/webrev/ >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8137329 >>>>>>>>> >>>>>>>>> Thanks & Kind Regards, Thomas >>>>>>>>> >>> From daniel.daugherty at oracle.com Wed Oct 7 16:17:42 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 7 Oct 2015 10:17:42 -0600 Subject: RFR(xxs): [windows] Build broken on VS2010 after "8046148: JEP 158: Unified JVM Logging" In-Reply-To: <5615449E.2060903@oracle.com> References: <560A9F58.2080309@oracle.com>

<560BE5A9.2000706@oracle.com>

<5615449E.2060903@oracle.com> Message-ID: <561545A6.1090904@oracle.com> On 10/7/15 10:13 AM, Daniel D. Daugherty wrote: > Thomas, > > I'm on it... > > While there have been several comments on the review thread > (including mine), the only clear review of the bits came from > Volker who suggested a change that motivated the new webrev... I see the patch in your webrev already lists all the reviewers. I'll add myself to that list and get this changeset moving... Dan > > I'll (R)eview the latest version shortly. > > Dan > > > > On 10/7/15 1:01 AM, Thomas St?fe wrote: >> Hi all, >> >> could I have a sponsor please? >> >> I think enough people think this makes sense to fix, and the fix is >> cheap >> and small. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8137329 >> patch: >> http://cr.openjdk.java.net/~stuefe/webrevs/8137329/webrev.01/webrev/ >> >> Thanks! >> >> Thomas >> >> On Mon, Oct 5, 2015 at 3:25 PM, Thomas St?fe >> wrote: >> >>> Hi all, >>> >>> may I have a sponsor please? >>> >>> Or have we decided not to fix this ? >>> >>> Regards, Thomas >>> >>> On Thu, Oct 1, 2015 at 9:41 AM, Thomas St?fe >>> wrote: >>> >>>> Hi all, >>>> >>>> New version of this patch: >>>> >>>> http://cr.openjdk.java.net/~stuefe/webrevs/8137329/webrev.01/webrev/ >>>> >>>> As Volker suggests, makes the workaround depend on _MSC_VER and also >>>> moves the patch to globalDefinitions_visCPP.hpp where it fits >>>> better and >>>> works for the whole hotspot. >>>> >>>> Kind regards, Thomas >>>> >>>> >>>> On Wed, Sep 30, 2015 at 3:51 PM, Volker Simonis >>>> >>>> wrote: >>>>> Hi, >>>>> >>>>> I second Phil,Goetz and Magnus and think this is a good change. >>>>> >>>>> But I suggest we should use "#if _MSC_VER < 1800" together with a >>>>> small comment instead of "#ifdef _WIN32" to make it more clear why we >>>>> have to redefine strtoull. >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> >>>>> On Wed, Sep 30, 2015 at 3:37 PM, Magnus Ihse Bursie >>>>> wrote: >>>>>> On 2015-09-30 14:40, Thomas St?fe wrote: >>>>>>> I would like to hear more opinions, and possibly a sponsor and a >>>>> reviewer. >>>>>>> In my opinion it makes sense to fix this. The fix is small and >>>>>>> cheap >>>>> and >>>>>>> makes people happy who still work with older versions of VS2010. >>>>>> I agree. It makes sense for trivial fixes to extend the range of >>>>> compiler >>>>>> versions that are possible to use. Major changes to support older >>>>> compilers >>>>>> is another thing, but simple stuff like this should be a no-brainer. >>>>> This is >>>>>> not really related to the fact that Oracle internally uses a >>>>>> specific >>>>>> version for daily quality control. >>>>>> >>>>>> /Magnus >>>>>> >>>>>>> Kind Regards, Thomas >>>>>>> >>>>>>> On Tue, Sep 29, 2015 at 5:12 PM, Thomas St?fe < >>>>> thomas.stuefe at gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Ok, I did not check this. Nevermind, then. >>>>>>>> >>>>>>>> Kind Regards, Thomas >>>>>>>> >>>>>>>> On Tue, Sep 29, 2015 at 4:25 PM, Daniel D. Daugherty < >>>>>>>> daniel.daugherty at oracle.com> wrote: >>>>>>>> >>>>>>>>> Ummm... VS2013 is the official compiler for JDK9 and Win*. >>>>>>>>> Why would we want to make a change to permit VS2010 to >>>>>>>>> continue to be used? >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9/29/15 7:58 AM, Thomas St?fe wrote: >>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> please review this tiny change. It fixes the build on >>>>> windows/Visual >>>>>>>>>> Studio >>>>>>>>>> 2010 after "8046148: JEP 158: Unified JVM Logging". >>>>>>>>>> >>>>>>>>>> strtoull() is missing from Visual Studio versions < 2013, but >>>>>>>>>> _strtoui64() >>>>>>>>>> can be used instead. >>>>>>>>>> >>>>>>>>>> webrev: >>>>>>>>>> >>>>> http://cr.openjdk.java.net/~stuefe/webrevs/8137329/webrev.00/webrev/ >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8137329 >>>>>>>>>> >>>>>>>>>> Thanks & Kind Regards, Thomas >>>>>>>>>> >>>> > > From james.laskey at oracle.com Tue Oct 6 19:23:26 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 6 Oct 2015 16:23:26 -0300 Subject: CLANG special case In-Reply-To: References: <5A5E3D06-3825-40C9-92BA-511C41ACFEF3@oracle.com> <5613EAF0.6000102@oracle.com> Message-ID: Since we are will to live with the de-optimization now, we should just remove the condition until proven otherwise. > On Oct 6, 2015, at 4:17 PM, Staffan Larsen wrote: > > When we upgraded to clang 6.3, I verified that the problem still existed. See: https://bugs.openjdk.java.net/browse/JDK-8077364 which has pointers to the two tests that fail without the workaround. > > /Staffan > >> On 6 okt 2015, at 17:38, Phil Race > wrote: >> >> Ideally hotspot would review this, not build. >> so it would be helpful if hotspot found an engineer to own the bug :- >> https://bugs.openjdk.java.net/browse/JDK-8138820 >> So far as I know this is not tracked under any other bug id. >> >> -phil. >> >> On 10/06/2015 05:30 AM, Jim Laskey (Oracle) wrote: >>> I?ve updated to El Capitan and, of course, builds fail, and, of course, I modify hotspot/make/bsd/makefiles/gcc.make one more time and? I think this conditional clause should be removed at the very least (commenting to indicate needs investigation), or someone should research and see which version of clang fixes the issues associate with the patch. Since it?s likely that no one has the cycles, please remove the condition. >>> >>> Cheers, >>> >>> ? Jim >>> >>> >>> >>> diff -r a02911828e48 make/bsd/makefiles/gcc.make >>> --- a/make/bsd/makefiles/gcc.make Wed Sep 30 07:41:36 2015 -0700 >>> +++ b/make/bsd/makefiles/gcc.make Tue Oct 06 09:22:50 2015 -0300 >>> @@ -313,21 +313,13 @@ >>> # Work around some compiler bugs. >>> ifeq ($(USE_CLANG), true) >>> - # Clang <= 6.1 >>> - ifeq ($(shell expr \ >>> - $(CC_VER_MAJOR) \< 6 \| \ >>> - $ $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) \<= 1 $ \ >>> - ), 1) >>> - OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) >>> - OPT_CFLAGS/unsafe.o += -O1 >>> - else >>> - $(error "Update compiler workarounds for Clang $(CC_VER_MAJOR).$(CC_VER_MINOR)") >>> - endif >>> + OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) >>> + OPT_CFLAGS/unsafe.o += -O1 >>> else >>> # 6835796. Problem in GCC 4.3.0 with mulnode.o optimized compilation. >>> ifeq ($(shell expr $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 3), 1) >>> OPT_CFLAGS/mulnode.o += $(OPT_CFLAGS/NOOPT) >>> - endif >>> + endif >>> endif >>> # Flags for generating make dependency flags. >>> >> > From david.buck at oracle.com Wed Oct 7 10:41:50 2015 From: david.buck at oracle.com (david buck) Date: Wed, 7 Oct 2015 19:41:50 +0900 Subject: [8u] Request for approval and review: 8075805: Crash while trying to release CompiledICHolder In-Reply-To: <5614F37E.8090208@oracle.com> References: <5614F37E.8090208@oracle.com> Message-ID: <5614F6EE.9000501@oracle.com> approved for 8u-dev backport pending successful completion of code review Please add the appropriate noreg label to JDK-8134493. Cheers, -Buck On 2015/10/07 19:27, Tobias Hartmann wrote: > Hi, > > please approve and review the following backport to 8u. > > 8075805: Crash while trying to release CompiledICHolder > https://bugs.openjdk.java.net/browse/JDK-8075805 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c0ea5537dc8b > http://cr.openjdk.java.net/~thartmann/8075805/webrev.01/ > > I would also like to backport this follow up change that fixes an issue with the fix for 8075805: > > 8134493: Cleaning inline caches of unloaded nmethods should be done in sweeper > https://bugs.openjdk.java.net/browse/JDK-8134493 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9df4555d2d7d > http://cr.openjdk.java.net/~thartmann/8134493/webrev.01/ > > Unfortunately, both changesets do not apply cleanly to 8u. I merged the fixes, here are the new webrevs: > > JDK-8075805: > http://cr.openjdk.java.net/~thartmann/8075805_8u/webrev.00/ > > JDK-8134493 (incremental): > http://cr.openjdk.java.net/~thartmann/8134493_8u/webrev.00/ > > Both changes: > http://cr.openjdk.java.net/~thartmann/8075805_8134493_8u/webrev.00/ > > Both fixes were pushed some months ago and testing showed no problems. > > Thanks, > Tobias > From sebastian.sickelmann at gmx.de Wed Oct 7 19:59:07 2015 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Wed, 7 Oct 2015 21:59:07 +0200 Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created in Java application(hotspot) In-Reply-To: <118235E4-AD96-4666-8A63-58FB403324BC@oracle.com> References: <5608201C.4020109@gmx.de> <560B5939.6010100@gmx.de> <118235E4-AD96-4666-8A63-58FB403324BC@oracle.com> Message-ID: <5615798B.2080708@gmx.de> Please find the webrev hosted on openjdk-infrastructure at: http://cr.openjdk.java.net/~sebastian/5108778/hotspot/webrev.00/ For some general discussion on regression-tests for this please find the thread in discuss[0][1] and for the general suggestion to make more wrapper-type-constructors deprecated find [2] at core-libs-dev. [0] http://mail.openjdk.java.net/pipermail/discuss/2015-September/003804.html [1] http://mail.openjdk.java.net/pipermail/discuss/2015-October/003805.html [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035642.html -- Sebastian On 09/30/2015 07:50 AM, Christian Thalinger wrote: > Sounds good. If you have the final patch, let us know. > >> On Sep 29, 2015, at 5:38 PM, Sebastian Sickelmann wrote: >> >> Yes it is the only (non-test) source i could find in hotspot, but i want >> to change it in all openjdk sources i can find it. >> I thought i really must discuss it part by part in the mailing-lists. >> Actually i am working on the issue to save against regression on this. >> Thanks Alexandr for this input. So there will be something that >> integrates into jtreg for this too. >> >> -- Sebastian >> >> >> On 09/30/2015 01:11 AM, Christian Thalinger wrote: >>> Thanks for volunteering to look into such old bugs! >>> >>> Is this the only occurrence of that pattern in the hotspot repository? If you want to fix this in hotspot only without the jdk changes described in the RFE (I just changed the type from Bug to Enhancement) then we have to file a new RFE because we can?t close the original one. >>> >>>> On Sep 27, 2015, at 6:58 AM, Sebastian Sickelmann wrote: >>>> >>>> Hello, >>>> >>>> my name is Sebastian Sickelmann and i signed the OCA. >>>> >>>> Actually I am searching through the JBS for low hanging fruits. >>>> Right now i am looking through the openjdk-sources and try to evaluate >>>> if i can make something about JDK-5108778. >>>> >>>> As I am not an author, I am actually not able to host webrevs on >>>> cr.openjdk.java.net. >>>> >>>> Is there someone who would support at hosting the hotspot-part of >>>> JDK-5108778 on cr.openjdk.java.net for reviewing? >>>> >>>> I placed the hotspot part in my dropbox at: >>>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/hotspot_0/webrev/index.html >>>> or as zip: >>>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/hotspot_0/webrev.zip >>>> >>>> I executed all jtreg tests in hotspot/test and get no more errors than before the change. >>>> >>>> -- Sebastian >>>> > From thomas.stuefe at gmail.com Wed Oct 7 21:01:31 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 7 Oct 2015 23:01:31 +0200 Subject: RFR(xxs): [windows] Build broken on VS2010 after "8046148: JEP 158: Unified JVM Logging" In-Reply-To: <561545A6.1090904@oracle.com> References: <560A9F58.2080309@oracle.com>

<560BE5A9.2000706@oracle.com>

<5615449E.2060903@oracle.com> <561545A6.1090904@oracle.com> Message-ID: Thank you Dan! On Wednesday, 7 October 2015, Daniel D. Daugherty < daniel.daugherty at oracle.com> wrote: > On 10/7/15 10:13 AM, Daniel D. Daugherty wrote: > >> Thomas, >> >> I'm on it... >> >> While there have been several comments on the review thread >> (including mine), the only clear review of the bits came from >> Volker who suggested a change that motivated the new webrev... >> > > I see the patch in your webrev already lists all the reviewers. > I'll add myself to that list and get this changeset moving... > > Dan > > > >> I'll (R)eview the latest version shortly. >> >> Dan >> >> >> >> On 10/7/15 1:01 AM, Thomas St?fe wrote: >> >>> Hi all, >>> >>> could I have a sponsor please? >>> >>> I think enough people think this makes sense to fix, and the fix is cheap >>> and small. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8137329 >>> patch: >>> http://cr.openjdk.java.net/~stuefe/webrevs/8137329/webrev.01/webrev/ >>> >>> Thanks! >>> >>> Thomas >>> >>> On Mon, Oct 5, 2015 at 3:25 PM, Thomas St?fe >>> wrote: >>> >>> Hi all, >>>> >>>> may I have a sponsor please? >>>> >>>> Or have we decided not to fix this ? >>>> >>>> Regards, Thomas >>>> >>>> On Thu, Oct 1, 2015 at 9:41 AM, Thomas St?fe >>>> wrote: >>>> >>>> Hi all, >>>>> >>>>> New version of this patch: >>>>> >>>>> http://cr.openjdk.java.net/~stuefe/webrevs/8137329/webrev.01/webrev/ >>>>> >>>>> As Volker suggests, makes the workaround depend on _MSC_VER and also >>>>> moves the patch to globalDefinitions_visCPP.hpp where it fits better >>>>> and >>>>> works for the whole hotspot. >>>>> >>>>> Kind regards, Thomas >>>>> >>>>> >>>>> On Wed, Sep 30, 2015 at 3:51 PM, Volker Simonis < >>>>> volker.simonis at gmail.com >>>>> >>>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> I second Phil,Goetz and Magnus and think this is a good change. >>>>>> >>>>>> But I suggest we should use "#if _MSC_VER < 1800" together with a >>>>>> small comment instead of "#ifdef _WIN32" to make it more clear why we >>>>>> have to redefine strtoull. >>>>>> >>>>>> Regards, >>>>>> Volker >>>>>> >>>>>> >>>>>> On Wed, Sep 30, 2015 at 3:37 PM, Magnus Ihse Bursie >>>>>> wrote: >>>>>> >>>>>>> On 2015-09-30 14:40, Thomas St?fe wrote: >>>>>>> >>>>>>>> I would like to hear more opinions, and possibly a sponsor and a >>>>>>>> >>>>>>> reviewer. >>>>>> >>>>>>> In my opinion it makes sense to fix this. The fix is small and cheap >>>>>>>> >>>>>>> and >>>>>> >>>>>>> makes people happy who still work with older versions of VS2010. >>>>>>>> >>>>>>> I agree. It makes sense for trivial fixes to extend the range of >>>>>>> >>>>>> compiler >>>>>> >>>>>>> versions that are possible to use. Major changes to support older >>>>>>> >>>>>> compilers >>>>>> >>>>>>> is another thing, but simple stuff like this should be a no-brainer. >>>>>>> >>>>>> This is >>>>>> >>>>>>> not really related to the fact that Oracle internally uses a specific >>>>>>> version for daily quality control. >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>> Kind Regards, Thomas >>>>>>>> >>>>>>>> On Tue, Sep 29, 2015 at 5:12 PM, Thomas St?fe < >>>>>>>> >>>>>>> thomas.stuefe at gmail.com> >>>>>> >>>>>>> wrote: >>>>>>>> >>>>>>>> Ok, I did not check this. Nevermind, then. >>>>>>>>> >>>>>>>>> Kind Regards, Thomas >>>>>>>>> >>>>>>>>> On Tue, Sep 29, 2015 at 4:25 PM, Daniel D. Daugherty < >>>>>>>>> daniel.daugherty at oracle.com> wrote: >>>>>>>>> >>>>>>>>> Ummm... VS2013 is the official compiler for JDK9 and Win*. >>>>>>>>>> Why would we want to make a change to permit VS2010 to >>>>>>>>>> continue to be used? >>>>>>>>>> >>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 9/29/15 7:58 AM, Thomas St?fe wrote: >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> please review this tiny change. It fixes the build on >>>>>>>>>>> >>>>>>>>>> windows/Visual >>>>>> >>>>>>> Studio >>>>>>>>>>> 2010 after "8046148: JEP 158: Unified JVM Logging". >>>>>>>>>>> >>>>>>>>>>> strtoull() is missing from Visual Studio versions < 2013, but >>>>>>>>>>> _strtoui64() >>>>>>>>>>> can be used instead. >>>>>>>>>>> >>>>>>>>>>> webrev: >>>>>>>>>>> >>>>>>>>>>> >>>>>> http://cr.openjdk.java.net/~stuefe/webrevs/8137329/webrev.00/webrev/ >>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8137329 >>>>>>>>>>> >>>>>>>>>>> Thanks & Kind Regards, Thomas >>>>>>>>>>> >>>>>>>>>>> >>>>> >> >> > From joe.darcy at oracle.com Wed Oct 7 21:23:07 2015 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 7 Oct 2015 14:23:07 -0700 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <5614D6DA.7080008@redhat.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56147A5A.5040308@oracle.com> <5614D6DA.7080008@redhat.com> Message-ID: <56158D3B.6060804@oracle.com> On 10/7/2015 1:24 AM, Andrew Haley wrote: > On 07/10/15 02:50, Joseph D. Darcy wrote: >> Taking a long-term view, it seems to me premature to burn this kind of >> hint into the Java SE API (effectively) forever in the absence of >> experience that the hint in this form is useful and will continue to be >> useful in 5 years, 10 years, etc. > This seems to me to be a very odd thing to say. Of course there is no > experience with this in Java because it's not been available, but > there is plenty of experience outside Java. If this goes into a JDK- > specific API we'll also have to support it for a long while or we'll > break programs. It's not obvious how pushing this outside Java SE > will aid practical portability. > > Also, this hint is very much in tune with the trend to do more in Java > and less in native code: it moves the barrier between code that must > be native and can be Java. That's a good thing. The most operative phrasing is "a hint *in this form*". To my knowledge, we don't have an existing hint in the Java SE API which uses this proposed mechanism of a possibly no-op API call. Further, the proposed hint in this JEP is a singleton without any peers, at least not initially. In other contexts, annotations are used to convey this sort of meta-data which doesn't affect the semantics of the code (for some definition of semantics) to various tools consuming class files, which can include JVMs. Annotations are not an ideal fit here since statements cannot be annotated, but one could imagine various workaround with different levels of hackery. I take it that it is difficult / impractical for JVMs to infer which loops would benefit from things like pause instructions? Is this an area of research? If something is added to Java SE, it is there practically forever, is extremely difficult to jettison, and basically can only be changed in platform releases (e.g. can be changed in releases like 8, 9, 10 and not changed in 8u60, 9.1, etc.). If something is a JDK API, if there is a problem or should be removed, that only take "a long term" (vs forever) and it is easier to make changes / additions in minor releases like 9.1. -Joe From john.r.rose at oracle.com Wed Oct 7 22:01:31 2015 From: john.r.rose at oracle.com (John Rose) Date: Wed, 7 Oct 2015 15:01:31 -0700 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <561245E0.8030708@redhat.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> Message-ID: <38110705-2789-4050-913C-0568DD8B61E9@oracle.com> On Oct 5, 2015, at 2:41 AM, Andrew Haley wrote: > > Hi Gil, > > On 04/10/15 17:22, Gil Tene wrote: > >> Summary >> >> Add an API that would allow Java code to hint that a spin loop is >> being executed. > > > I don't think this will work for ARM, which has a rather different > spinlock mechanism. > > Instead of PAUSE, we wait on a lock word with WFE. WFE puts a core > into a lightweight sleep state waiting on a particular address (the > lock word) and a write to the lock word wakes it up. This is very > useful and somewhat analogous to 86's MONITOR/MWAIT. > > I can't immediately see how to generalize your proposal to ARM, which > is a shame. Suggestion: Allow the hint intrinsic to take an argument, from which a JIT can infer a memory dependency (if one is in fact present). Even if we are just targeting a PAUSE instruction, I think it is helpful to the JIT to add more connection points (beyond control flow) between the intrinsic and the surrounding loop. class jdk.internal.vm.SpinLoop { /** Provides a hint to the processor that a spin loop is in progress. * The boolean is returned unchanged. The processor may assume * that the loop is likely to continue as long as the boolean is false. * The processor may pause or wait after a false result, if there is * some reason to believe that the boolean argument, if re-evaluated, * will be false again. Any pausing behavior is system-specific. * The processor may not pause indefinitely. *

Example: *

{@code
MyMailbox mb = ?;
while (true) {
  if (!pollSpinExit(mb.hasMail())  continue;
  Object m = mb.getMail();
  if (m != null)  return m;
}
     * }

* / @jdk.internal.HotSpotIntrinsicCandidate public static boolean pollSpinExit(boolean spinExit) { return spinExit; } } I'm going to guess that the extra hinting provided by the parameter would make it easier for a JIT to generate MWAIT and WFEs. Also, the boolean argument is easy to profile in the interpreter, if that's what a VM wants to do. For a similar mechanism (which again uses a boolean to provide IR connection to a data dependency), see: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/fe40b31c0e52/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java#l697 In fact, something like the profileBoolean intrinsic might be useful to allow spin loops to gather their own statistics. Getting the array allocation right might require an invokedynamic site (or some equivalent, like a static method handle), in order to control the allocation of profile state per call site. HTH ? John P.S. I agree with others that this needs cooking, in a jdk.internal place, before it is ready for SE. From daniel.daugherty at oracle.com Wed Oct 7 22:14:45 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 7 Oct 2015 16:14:45 -0600 Subject: RFR (S): JDK-8129855: -XX:+IgnoreUnrecognizedVMOptions hides out of range VM options. In-Reply-To: <560AD3C2.7090905@oracle.com> References: <5609B768.8010109@oracle.com> <560AD3C2.7090905@oracle.com> Message-ID: <56159955.1070409@oracle.com> On 9/29/15 12:09 PM, gerard ziemski wrote: > Here is a webrev1 updated with fixes based on Dmitry's feedback (ie. > changes to the java test only): > > http://cr.openjdk.java.net/~gziemski/8129855_rev1 src/share/vm/runtime/arguments.cpp It took a couple of reading attempts (L893-899), but I'm good with this file. src/share/vm/runtime/globals.cpp L336: get_locked_message_ext(buf, buflen); L337: return Flag::NONE; Seems a bit strange for Flag::NONE to be returned after we've called out to get_locked_message_ext(buf, buflen). Looks like the protocol is to check buf[0]. If it's non-NULL: (buf[0] != '\0'), then we've gotten a message from the extension... src/share/vm/runtime/globals.hpp No comments. test/runtime/CommandLine/IgnoreUnrecognizedVMOptions.java L29 * @summary -XX:+IgnoreUnrecognizedVMOptions should work according to the spec from https:... Is this URL persistent and will it survive the test of time (and DB changes)? L84: runJavaAndCheckExitValue(false, "-XX:-IgnoreUnrecognizedVMOptions", "-XX:-UnlockDiagnosticVMOptions", "-XX:+AlwaysSafeConstructors", "-version"); Should this be '-XX:-UnlockExperimentalVMOptions'? L85: runJavaAndCheckExitValue(false, "-XX:-IgnoreUnrecognizedVMOptions", "-XX:-UnlockDiagnosticVMOptions", "-XX:+FlightRecorder", "-version"); Should this be '-XX:-UnlockCommercialFeatures'? L87: runJavaAndCheckExitValue(false, "-XX:+IgnoreUnrecognizedVMOptions", "-XX:-UnlockDiagnosticVMOptions", "-XX:+AlwaysSafeConstructors", "-version"); Should this be '-XX:-UnlockExperimentalVMOptions'? L88: runJavaAndCheckExitValue(false, "-XX:+IgnoreUnrecognizedVMOptions", "-XX:-UnlockDiagnosticVMOptions", "-XX:+FlightRecorder", "-version"); Should this be '-XX:-UnlockCommercialFeatures'? L126-131: seems like you should narrow down the use of "-XX:-IgnoreUnrecognizedVMOptions" and "-XX:-UnlockDiagnosticVMOptions" to just the options to which they apply. Dan > > > cheers > > On 09/28/2015 04:55 PM, gerard ziemski wrote: >> hi all, >> >> We are fixing how IgnoreUnrecognizedVMOptions treats those flags >> whose values are out of range. Before the fix, the VM >> would continue even if flag?s value was out of range, ex: >> >> java_old -XX:+IgnoreUnrecognizedVMOptions -XX:MinTLABSize=0 -version >> size_t MinTLABSize=0 is outside the allowed range [ 1 ... 4294967295 ] >> java version "1.9.0-internal-fastdebug" >> Java(TM) SE Runtime Environment (build >> 1.9.0-internal-fastdebug-20150624183527.jesper.main2rt-b00) >> Java HotSpot(TM) Server VM (build >> 1.9.0-internal-fastdebug-20150624183527.jesper.main2rt-b00, mixed mode) >> >> now, we correctly exit the VM with an error, ex: >> >> java_new -XX:+IgnoreUnrecognizedVMOptions -XX:MinTLABSize=0 -version >> size_t MinTLABSize=0 is outside the allowed range [ 1 ... >> 18446744073709551615 ] >> Improperly specified VM option 'MinTLABSize=0' >> Error: Could not create the Java Virtual Machine. >> Error: A fatal exception has occurred. Program will exit. >> >> In addition IgnoreUnrecognizedVMOptions nows strictly follows the >> spec as outlined in JDK-8129855. The behavior changes >> depending on whether the build is product or debug. >> >> We also introduce a new test that verifies all known use cases that >> we care about. >> >> References: >> bugid: https://bugs.openjdk.java.net/browse/JDK-8129855 >> webrev: http://cr.openjdk.java.net/~gziemski/8129855_rev0 >> discussion: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/019213.html >> >> Passes "JPRT hotspot" and "RBT testlist,noncolo.testlist quick" >> >> >> cheers >> > From vitalyd at gmail.com Wed Oct 7 22:38:11 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 7 Oct 2015 18:38:11 -0400 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56158D3B.6060804@oracle.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56147A5A.5040308@oracle.com> <5614D6DA.7080008@redhat.com> <56158D3B.6060804@oracle.com> Message-ID: A key motivator behind this JEP is to allow non-JDK users to get access to this instruction in a cheap manner - how is making it jdk-internal addressing that? How long would it be in jdk internal before being blessed for SE? What would need to happen for that blessing to take place? I understand that removing APIs in SE is challenging, but implementations are allowed to be nops so maintenance burden should be minimal, if any. If something better comes along, then I don't see why this method couldn't be deprecated and then removed in a subsequent major release. Right now, it doesn't look like anyone is proposing any better solution to the problem this JEP addresses. Otherwise, this is just staying with status quo instead of at least moving in the right direction, even if not the final destination in X years. sent from my phone On Oct 7, 2015 5:23 PM, "joe darcy" wrote: > On 10/7/2015 1:24 AM, Andrew Haley wrote: > >> On 07/10/15 02:50, Joseph D. Darcy wrote: >> >>> Taking a long-term view, it seems to me premature to burn this kind of >>> hint into the Java SE API (effectively) forever in the absence of >>> experience that the hint in this form is useful and will continue to be >>> useful in 5 years, 10 years, etc. >>> >> This seems to me to be a very odd thing to say. Of course there is no >> experience with this in Java because it's not been available, but >> there is plenty of experience outside Java. If this goes into a JDK- >> specific API we'll also have to support it for a long while or we'll >> break programs. It's not obvious how pushing this outside Java SE >> will aid practical portability. >> >> Also, this hint is very much in tune with the trend to do more in Java >> and less in native code: it moves the barrier between code that must >> be native and can be Java. That's a good thing. >> > > The most operative phrasing is "a hint *in this form*". > > To my knowledge, we don't have an existing hint in the Java SE API which > uses this proposed mechanism of a possibly no-op API call. Further, the > proposed hint in this JEP is a singleton without any peers, at least not > initially. > > In other contexts, annotations are used to convey this sort of meta-data > which doesn't affect the semantics of the code (for some definition of > semantics) to various tools consuming class files, which can include JVMs. > Annotations are not an ideal fit here since statements cannot be annotated, > but one could imagine various workaround with different levels of hackery. > > I take it that it is difficult / impractical for JVMs to infer which loops > would benefit from things like pause instructions? Is this an area of > research? > > If something is added to Java SE, it is there practically forever, is > extremely difficult to jettison, and basically can only be changed in > platform releases (e.g. can be changed in releases like 8, 9, 10 and not > changed in 8u60, 9.1, etc.). If something is a JDK API, if there is a > problem or should be removed, that only take "a long term" (vs forever) and > it is easier to make changes / additions in minor releases like 9.1. > > -Joe > > From gil at azul.com Wed Oct 7 20:21:37 2015 From: gil at azul.com (Gil Tene) Date: Wed, 7 Oct 2015 20:21:37 +0000 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56153F8B.8000102@redhat.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> <5614D461.8050403@redhat.com> <56153F8B.8000102@redhat.com> Message-ID: <2C546647-3BC9-4A9D-938B-7192824B2D05@azul.com> > On Oct 7, 2015, at 8:51 AM, Andrew Haley wrote: > > On 10/07/2015 04:45 PM, Gil Tene wrote: > >> For ARM, I expect WFE/SEV to need to evolve as well, and for other >> reasons, even fit use within OSs. The current WFE/SEV scheme is not >> scalable. While it probably works ok for spinning at the kernel >> level on hardware that only has s handful of cores, the fact that >> the event WFE waits for (and SEV sends) is global to the system will >> break things as core counts grow (it is the hardware equivalent of >> wait/notifyAll() with a single global monitor). > > That's not how it works. It's sufficient to write to the lock word to > wake a core from a WFE: SEV is not required. Each core has its own > event monitor, and wakeup is handled by the cache coherency logic. > > Andrew. Interesting. I was going off of the 32 bit ARM documentation. Looks like ARMv8 improved on that, and did it implicitly (without requiring different instructions). You can see the differences on the unlock path between the 32 bit and 64 bit implementations here: http://lxr.free-electrons.com/source/arch/arm/include/asm/spinlock.h http://lxr.free-electrons.com/source/arch/arm64/include/asm/spinlock.h From joe.darcy at oracle.com Wed Oct 7 22:57:34 2015 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 7 Oct 2015 15:57:34 -0700 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56147A5A.5040308@oracle.com> <5614D6DA.7080008@redhat.com> <56158D3B.6060804@oracle.com> Message-ID: <5615A35E.3080203@oracle.com> On 10/7/2015 3:38 PM, Vitaly Davidovich wrote: > > A key motivator behind this JEP is to allow non-JDK users to get > access to this instruction in a cheap manner - how is making it > jdk-internal addressing that? How long would it be in jdk internal > before being blessed for SE? What would need to happen for that > blessing to take place? > The JDK has a public API that is a proper superset of the Java SE API. The Java SE API historically includes the java.* and javax.* packages. (In Java SE 9, this API will be redefined in terms of modules.) The JDK API in addition includes the exported portions of com.sun.* and more recently the exported portions of jdk.*. (Note that sun.* and jdk.internal.* and not part of the exported API even if people have treated them as such ;-) We have more flexibility and options for changing the exported JDK API that is not part of Java SE. -Joe > I understand that removing APIs in SE is challenging, but > implementations are allowed to be nops so maintenance burden should be > minimal, if any. If something better comes along, then I don't see > why this method couldn't be deprecated and then removed in a > subsequent major release. Right now, it doesn't look like anyone is > proposing any better solution to the problem this JEP addresses. > Otherwise, this is just staying with status quo instead of at least > moving in the right direction, even if not the final destination in X > years. > > sent from my phone > > On Oct 7, 2015 5:23 PM, "joe darcy" > wrote: > > On 10/7/2015 1:24 AM, Andrew Haley wrote: > > On 07/10/15 02:50, Joseph D. Darcy wrote: > > Taking a long-term view, it seems to me premature to burn > this kind of > hint into the Java SE API (effectively) forever in the > absence of > experience that the hint in this form is useful and will > continue to be > useful in 5 years, 10 years, etc. > > This seems to me to be a very odd thing to say. Of course > there is no > experience with this in Java because it's not been available, but > there is plenty of experience outside Java. If this goes into > a JDK- > specific API we'll also have to support it for a long while or > we'll > break programs. It's not obvious how pushing this outside Java SE > will aid practical portability. > > Also, this hint is very much in tune with the trend to do more > in Java > and less in native code: it moves the barrier between code > that must > be native and can be Java. That's a good thing. > > > The most operative phrasing is "a hint *in this form*". > > To my knowledge, we don't have an existing hint in the Java SE API > which uses this proposed mechanism of a possibly no-op API call. > Further, the proposed hint in this JEP is a singleton without any > peers, at least not initially. > > In other contexts, annotations are used to convey this sort of > meta-data which doesn't affect the semantics of the code (for some > definition of semantics) to various tools consuming class files, > which can include JVMs. Annotations are not an ideal fit here > since statements cannot be annotated, but one could imagine > various workaround with different levels of hackery. > > I take it that it is difficult / impractical for JVMs to infer > which loops would benefit from things like pause instructions? Is > this an area of research? > > If something is added to Java SE, it is there practically forever, > is extremely difficult to jettison, and basically can only be > changed in platform releases (e.g. can be changed in releases like > 8, 9, 10 and not changed in 8u60, 9.1, etc.). If something is a > JDK API, if there is a problem or should be removed, that only > take "a long term" (vs forever) and it is easier to make changes / > additions in minor releases like 9.1. > > -Joe > From vitalyd at gmail.com Wed Oct 7 23:12:20 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 7 Oct 2015 19:12:20 -0400 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <5615A35E.3080203@oracle.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56147A5A.5040308@oracle.com> <5614D6DA.7080008@redhat.com> <56158D3B.6060804@oracle.com> <5615A35E.3080203@oracle.com> Message-ID: Ok, so the suggestion is to place this into some exported jdk.X package, where X isn't "internal"? What are the practical implications for a non-JDK user of this, beyond those APIs subject to (more aggressive) change? If this path is taken, I'm still unclear on what needs to happen to have it promoted to SE. sent from my phone On Oct 7, 2015 6:57 PM, "joe darcy" wrote: > On 10/7/2015 3:38 PM, Vitaly Davidovich wrote: > > A key motivator behind this JEP is to allow non-JDK users to get access to > this instruction in a cheap manner - how is making it jdk-internal > addressing that? How long would it be in jdk internal before being blessed > for SE? What would need to happen for that blessing to take place? > > > The JDK has a public API that is a proper superset of the Java SE API. > > The Java SE API historically includes the java.* and javax.* packages. (In > Java SE 9, this API will be redefined in terms of modules.) The JDK API in > addition includes the exported portions of com.sun.* and more recently the > exported portions of jdk.*. (Note that sun.* and jdk.internal.* and not > part of the exported API even if people have treated them as such ;-) > > We have more flexibility and options for changing the exported JDK API > that is not part of Java SE. > > -Joe > > I understand that removing APIs in SE is challenging, but implementations > are allowed to be nops so maintenance burden should be minimal, if any. If > something better comes along, then I don't see why this method couldn't be > deprecated and then removed in a subsequent major release. Right now, it > doesn't look like anyone is proposing any better solution to the problem > this JEP addresses. Otherwise, this is just staying with status quo > instead of at least moving in the right direction, even if not the final > destination in X years. > > sent from my phone > On Oct 7, 2015 5:23 PM, "joe darcy" wrote: > >> On 10/7/2015 1:24 AM, Andrew Haley wrote: >> >>> On 07/10/15 02:50, Joseph D. Darcy wrote: >>> >>>> Taking a long-term view, it seems to me premature to burn this kind of >>>> hint into the Java SE API (effectively) forever in the absence of >>>> experience that the hint in this form is useful and will continue to be >>>> useful in 5 years, 10 years, etc. >>>> >>> This seems to me to be a very odd thing to say. Of course there is no >>> experience with this in Java because it's not been available, but >>> there is plenty of experience outside Java. If this goes into a JDK- >>> specific API we'll also have to support it for a long while or we'll >>> break programs. It's not obvious how pushing this outside Java SE >>> will aid practical portability. >>> >>> Also, this hint is very much in tune with the trend to do more in Java >>> and less in native code: it moves the barrier between code that must >>> be native and can be Java. That's a good thing. >>> >> >> The most operative phrasing is "a hint *in this form*". >> >> To my knowledge, we don't have an existing hint in the Java SE API which >> uses this proposed mechanism of a possibly no-op API call. Further, the >> proposed hint in this JEP is a singleton without any peers, at least not >> initially. >> >> In other contexts, annotations are used to convey this sort of meta-data >> which doesn't affect the semantics of the code (for some definition of >> semantics) to various tools consuming class files, which can include JVMs. >> Annotations are not an ideal fit here since statements cannot be annotated, >> but one could imagine various workaround with different levels of hackery. >> >> I take it that it is difficult / impractical for JVMs to infer which >> loops would benefit from things like pause instructions? Is this an area of >> research? >> >> If something is added to Java SE, it is there practically forever, is >> extremely difficult to jettison, and basically can only be changed in >> platform releases (e.g. can be changed in releases like 8, 9, 10 and not >> changed in 8u60, 9.1, etc.). If something is a JDK API, if there is a >> problem or should be removed, that only take "a long term" (vs forever) and >> it is easier to make changes / additions in minor releases like 9.1. >> >> -Joe >> >> > From coleen.phillimore at oracle.com Wed Oct 7 23:35:09 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 07 Oct 2015 19:35:09 -0400 Subject: RFR: 8138659: Speed up InstanceKlass subclass discrimination In-Reply-To: <294721F8-D7E7-4FB5-9CC7-39C984EC87F0@oracle.com> References: <5612D757.5040905@oracle.com> <5422E78A-5321-406D-9997-7A19BB4A4ABD@oracle.com> <294721F8-D7E7-4FB5-9CC7-39C984EC87F0@oracle.com> Message-ID: <5615AC2D.3030204@oracle.com> Kim, This looks *very* nice. Thank you for doing this: + return static_cast(k); For bonus points can you change this to a static_cast<> ??? // Casting from Klass* static InstanceKlass* cast(Klass* k) { assert(k == NULL || k->is_klass(), "must be"); assert(k == NULL || k->oop_is_instance(), "cast to InstanceKlass"); return (InstanceKlass*) k; } I don't have to see it though. Thanks! Coleen On 10/7/15 12:02 PM, Kim Barrett wrote: > Another round, with some name changes that resulted from discussion > with StefanK and Coleen. Also, Coleen convinced me some functions > weren't needed. > > New full and incremental webrevs: > http://cr.openjdk.java.net/~kbarrett/8138659/webrev.02/ > http://cr.openjdk.java.net/~kbarrett/8138659/webrev.02.inc/ > From kim.barrett at oracle.com Thu Oct 8 00:43:31 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 7 Oct 2015 20:43:31 -0400 Subject: RFR: 8138659: Speed up InstanceKlass subclass discrimination In-Reply-To: <5615AC2D.3030204@oracle.com> References: <5612D757.5040905@oracle.com> <5422E78A-5321-406D-9997-7A19BB4A4ABD@oracle.com> <294721F8-D7E7-4FB5-9CC7-39C984EC87F0@oracle.com> <5615AC2D.3030204@oracle.com> Message-ID: On Oct 7, 2015, at 7:35 PM, Coleen Phillimore wrote: > Kim, > > This looks *very* nice. Thank you for doing this: > > + return static_cast(k); > > > For bonus points can you change this to a static_cast<> ??? > > // Casting from Klass* > static InstanceKlass* cast(Klass* k) { > assert(k == NULL || k->is_klass(), "must be"); > assert(k == NULL || k->oop_is_instance(), "cast to InstanceKlass"); > return (InstanceKlass*) k; > } Yikes! I somehow forgot that InstanceKlass::cast accepted NULL. But I wonder if that case really arises? Certainly a large percentage of uses of it will (nearly) instantly crash if k is NULL, because we immediately call some member function on the result of the cast. [And the is_klass is questionable too, since for it to even potentially return false someone must have performed a bad cast, so we?re already in the realm of undefined behavior and that call could do anything.] From christian.thalinger at oracle.com Thu Oct 8 02:42:20 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 7 Oct 2015 16:42:20 -1000 Subject: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface In-Reply-To: <56127149.6060701@oracle.com> References: <2B401EAC-B386-4E42-BC4C-DD267FFD4970@oracle.com> <55F9671C.4000208@oracle.com> <99042B61-9F43-42CE-835C-095CD2858CB1@oracle.com> <55F9F08E.8010506@oracle.com> <08A9DB82-58D0-41F8-97F5-23AD78205263@oracle.com>

Example: *

{@code
MyMailbox mb = ?;
while (true) {
  if (!pollSpinExit(mb.hasMail())  continue;
  Object m = mb.getMail();
  if (m != null)  return m;
}
     * }

* / @jdk.internal.HotSpotIntrinsicCandidate public static boolean pollSpinExit(boolean spinExit) { return spinExit; } } I'm going to guess that the extra hinting provided by the parameter would make it easier for a JIT to generate MWAIT and WFEs. On the one hand: I like the idea of (an optional?) boolean parameter as a means of hinting at the thing that may terminate the spin. It's probably much more general than identifying a specific field or address. And it can be used to cover cases that poll multiple addresses (an or in the boolean) or look a termination time. If the JVM can track down the boolean's evaluation to dependencies on specific memory state changes, it could pass it on to hardware, if such hardware exists. On the other hard: Unfortunately, I don't think that hardware support that can receive the address information exists right now, and if/when it does, I'm not sure the semantics of passing the boolean through are enough to cover the actual way to use such hardware when it becomes available. It is probably premature to design a generic way to provide addresses and/or state to this "spin until something interesting changes" stuff without looking at working examples. A single watched address API is much more likely to fit current implementations without being fragile. ARM v8's WFE is probably the most real user-mode-accesible thing for this right now (MWAIT isn't real yet, as it's not accessible from user mode). We can look at an example of how a spinloop needs to coordinate the use of WFE, SEVL, and the evaluation of memory location with load exclusive operations here: http://lxr.free-electrons.com/source/arch/arm64/include/asm/spinlock.h . The tricky part is that the SEVL needs to immediately proceed the loop (and all accesses that need to be watched by the WFE), but can't be part of the loop (if were in the loop the WFE would always trigger immediately). But the code in the spinning loop can can only track a single address (the exclusive tag in load exclusive applies only the the most recent address used), so it would be wrong to allow generic code in the spin (it would have to be code that watches exactly one address). My suspicion is that the "right" way to capture the various ways a spin loop would need to interact with RFE logic will be different than tracking things that can generically affect the value of a boolean. E.g. the evaluation of the boolean could be based on multiple addresses, and since it's not clear (in the API) that this is a problem, the benefits derived would be fragile. In addition, there can validly be state mutating logic in the loop (e.g. counting), and implicitly re-executing that logic repeatedly inside a pollSpinExit(booleanThatOnlyWatchesOneAddress) call would seem "wrong" (the logic would presumably proceed the call, and it would be surprising to see it execute more than once within the call). I suspect that the right way to deal with RFE would be to provide an API that is closer to what it needs (and which is different from spin-hinting in the loop). E.g. some way to designate the beginning of the loop (so SEVL could be inserted right before it), some way to indicate the address that needs to use exclusive load in the loop, and some way to indicate that the loop is done. A possible way to do this is by wrapping the spinloop code and providing the address. E.g.: /** * Execute the spinCode repeatedly until it returns false. The processor * may assume that of the return value is false, it is likely to continue to * return false as long as the contents of the fieldToWatch field of the * objectToWatchFieldIn object does not change. he processor may therefore * pause or wait after a false result. The processor must not pause indefinitely, * but other pausing behavior is system-specific. */ void spinExecuteWhileTrue(BooleanSupplier spinCode, Field fieldToWatch, Object objectToWatchFieldIn); This would probably be a good fit for the specific WFE/SEVL semantics: the loop is implicit to the call, so the SEVL can be placed ahead of it; The loop can perform a load exclusive on the designated field of the designated object, and the spinCode can then do whatever it wants, with the understanding that no address other than the fieldToWatch is being watched to provide a timely exit from the loop. [Similar variant can be done for watching array fields]. The same single-watched-address API will probably fit MONITOR/MWAIT if it becomes available, and possibly ll/sc variants in other CPUs too. But wider-watching variants (NCAS, TSX) will not be covered by this API. And common uses of the x86 PAUSE instruction wouldn't either (since they are not limited at all to a limited number of addresses). Th good news is that even though the single-address-watching API only covers limited use cases, it can be easily implemented on architectures that only support spin hinting. So if someone's use case does fit into the API and is codes to that form, they are likely to gain benefits on both types of platforms. This leads me to believe that we are looking at two different APIs: - Spin loop hinting (matching the mature use cases of the PAUSE instruction in x86 and HW thread priority reduction in Power). - Single-watched-address spinning, matching ARM v8's WFE/SEVL use case, and potential other single address watchers (MONITOR/WAIT, and potential ll/sc based hints in other future cpus). I think the first use case is very mature and well understood, and certainly ready for a long term supported Java SE API. The second use case only applies to recently introduced hardware (ARM v8 right now), but it is fairly simple and *may* be useful more widely in the future. Since it can be beneficially intrinsified on platforms that support the wider spin-hinting API, we could add the single-address-watching for the JEP (as the two do seem related). I just worry that the questions about the usefulness and longevity of the single-address-watching use model may shadow the simplicity and apparent slam-dunkness of the spin loop hinting solution. Also, the boolean argument is easy to profile in the interpreter, if that's what a VM wants to do. For a similar mechanism (which again uses a boolean to provide IR connection to a data dependency), see: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/fe40b31c0e52/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java#l697 In fact, something like the profileBoolean intrinsic might be useful to allow spin loops to gather their own statistics. Getting the array allocation right might require an invokedynamic site (or some equivalent, like a static method handle), in order to control the allocation of profile state per call site. HTH ? John P.S. I agree with others that this needs cooking, in a jdk.internal place, before it is ready for SE. From aph at redhat.com Thu Oct 8 09:28:15 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 8 Oct 2015 10:28:15 +0100 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <2C546647-3BC9-4A9D-938B-7192824B2D05@azul.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> <5614D461.8050403@redhat.com> <56153F8B.8000102@redhat.com> <2C546647-3BC9-4A9D-938B-7192824B2D05@azul.com> Message-ID: <5616372F.7090506@redhat.com> On 10/07/2015 09:21 PM, Gil Tene wrote: > Interesting. I was going off of the 32 bit ARM documentation. Looks like > ARMv8 improved on that, and did it implicitly (without requiring different > instructions). > > You can see the differences on the unlock path between the 32 bit and 64 bit implementations here: > http://lxr.free-electrons.com/source/arch/arm/include/asm/spinlock.h > http://lxr.free-electrons.com/source/arch/arm64/include/asm/spinlock.h Yeah, that's right. SEV is very broadcasty and not at all suited to large systems, which is obviously what v8 is aimed at. There are also local timer queues, BTW, and one of the things a timer can do is a local SEV. So we have just the right things, if we can ever figure out how to use them in Java! BTW, I apologize for hijacking your thread. Your JEP looks good, and I can't see any good reason that such a simple and non-intrusive API shouldn't go in. Andrew. From tobias.hartmann at oracle.com Thu Oct 8 10:23:15 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 08 Oct 2015 12:23:15 +0200 Subject: RFR: String Density/Compact String JEP 254 In-Reply-To: <628568DB-F47A-4BD7-A032-2BECD0E2C539@oracle.com> References: <56129786.1090402@oracle.com> <628568DB-F47A-4BD7-A032-2BECD0E2C539@oracle.com> Message-ID: <56164413.6060405@oracle.com> Hi Roland, thanks for the review! On 07.10.2015 15:28, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~thartmann/compact_strings/webrev/hotspot > > I looked at the compiler related files only. > > intrinsicnode.hpp > > A comment would be nice: > > 49 typedef enum ArgEncoding { LL, LU, UL, UU, none } ArgEnc; Yes, that enum is a little bit cryptic. I added a comment describing it's purpose. > The (ASSERT only) comment should be removed: > > 53 virtual uint size_of() const; // Size is bigger (ASSERT only) Done. > library_call.cpp > > In LibraryCallKit::inline_hasNegatives(), don?t you need to test for too many Deoptimization::Reason_intrinsic before intrinsifying? Right, I added a check to bail out if we hit too many traps. > Shouldn?t LibraryCallKit::inline_string_toBytesU() and LibraryCallKit::inline_string_getCharsU() use an ArrayCopyNode (maybe an improvement/cleanup for later)? > > Same is true for PhaseStringOpts::arraycopy The problem with using an ArrayCopyNode is that it requires // (2) src and dest arrays must have elements of the same BasicType otherwise PhaseMacroExpand::generate_slow_arraycopy() is used. Since for ..toBytesU() and ..getCharsU() we are copying from char[] to byte[] or vice-versa, we cannot use ArrayCopyNode without modifying the macro expansion. I think the same applies to PhaseStringOpts::arraycopy() where we are copying between two byte arrays because the ArrayCopyNode does not "know" that we can always copy chars since the offsets are guaranteed to be char aligned. I created a JEP subtask to keep track of this: https://bugs.openjdk.java.net/browse/JDK-8139132 We may convert this to an "enhancement" after integrating the changes. > macroAssembler_sparc.cpp > > I don?t think you should reference c2 stuff outside c2: > > 4440 if (ae == StrIntrinsicNode::LU || ae == StrIntrinsicNode::UL) { I added '#ifdef COMPILER2' statements to guard the C2 specific string methods in macroAssembler_sparc.cpp. Here is the incremental webrev: http://cr.openjdk.java.net/~thartmann/compact_strings/incremental/webrev.03/ I updated the overall webrev in-place: http://cr.openjdk.java.net/~thartmann/compact_strings/webrev/hotspot/ Thanks, Tobias From dl at cs.oswego.edu Thu Oct 8 10:58:04 2015 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 8 Oct 2015 06:58:04 -0400 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> Message-ID: <56164C3C.4050800@cs.oswego.edu> On 10/06/2015 09:28 PM, Gil Tene wrote: > > As for fitting in with larger-picture or theme things (listed above). I think that > agonizing over the choice of where to put this is important To avoid the kinds of problems we later saw when basic JVM methods were placed in odd places just for the sake of appearances (e.g., park/unpark), the best choice seems to be class Thread, as in: class Thread { // /** * A hint to the platform that the current thread is momentarily * unable to progress. ... add more guidance ... */ void spinYield(); } In principle, this would also allow the implementation to do an actual yield on uniprocessors or when the load average is high. Probably not in initial implementation though. Adding a method to class Thread risks name clashes with existing methods introduced in subclasses. So this might need a clunkier name to effectively eliminate the possibility. An analogous method could also be added (now or later) for MWAIT-based support for waits on the thread's park semaphore (which is more tractable than doing so for an arbitrary variable). An alternative to either is to add optional arguments to yield and park providing a hint about whether to context-switch. Joe Darcy: Thread.yield does set a precedent here: * A hint to the scheduler that the current thread is willing to yield * its current use of a processor. The scheduler is free to ignore this * hint. -Doug From coleen.phillimore at oracle.com Thu Oct 8 11:21:35 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 08 Oct 2015 07:21:35 -0400 Subject: RFR: 8138659: Speed up InstanceKlass subclass discrimination In-Reply-To: References: <5612D757.5040905@oracle.com> <5422E78A-5321-406D-9997-7A19BB4A4ABD@oracle.com> <294721F8-D7E7-4FB5-9CC7-39C984EC87F0@oracle.com> <5615AC2D.3030204@oracle.com> Message-ID: <561651BF.6050806@oracle.com> On 10/7/15 8:43 PM, Kim Barrett wrote: > On Oct 7, 2015, at 7:35 PM, Coleen Phillimore wrote: >> Kim, >> >> This looks *very* nice. Thank you for doing this: >> >> + return static_cast(k); >> >> >> For bonus points can you change this to a static_cast<> ??? >> >> // Casting from Klass* >> static InstanceKlass* cast(Klass* k) { >> assert(k == NULL || k->is_klass(), "must be"); >> assert(k == NULL || k->oop_is_instance(), "cast to InstanceKlass"); >> return (InstanceKlass*) k; >> } > Yikes! I somehow forgot that InstanceKlass::cast accepted NULL. But I wonder if that case really > arises? Certainly a large percentage of uses of it will (nearly) instantly crash if k is NULL, because > we immediately call some member function on the result of the cast. Oh, yeah, this looks bad! File another bug and someone will look for why we allow null here. Coleen > > [And the is_klass is questionable too, since for it to even potentially return false someone must > have performed a bad cast, so we?re already in the realm of undefined behavior and that call > could do anything.] > From roland.westrelin at oracle.com Thu Oct 8 12:02:16 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 8 Oct 2015 14:02:16 +0200 Subject: RFR: String Density/Compact String JEP 254 In-Reply-To: <56164413.6060405@oracle.com> References: <56129786.1090402@oracle.com> <628568DB-F47A-4BD7-A032-2BECD0E2C539@oracle.com> <56164413.6060405@oracle.com> Message-ID: <230D7F3E-5685-4962-99C6-383B8E6785B4@oracle.com> >> Shouldn?t LibraryCallKit::inline_string_toBytesU() and LibraryCallKit::inline_string_getCharsU() use an ArrayCopyNode (maybe an improvement/cleanup for later)? >> >> Same is true for PhaseStringOpts::arraycopy > > The problem with using an ArrayCopyNode is that it requires > > // (2) src and dest arrays must have elements of the same BasicType > > otherwise PhaseMacroExpand::generate_slow_arraycopy() is used. Since for ..toBytesU() and ..getCharsU() we are copying from char[] to byte[] or vice-versa, we cannot use ArrayCopyNode without modifying the macro expansion. > > I think the same applies to PhaseStringOpts::arraycopy() where we are copying between two byte arrays because the ArrayCopyNode does not "know" that we can always copy chars since the offsets are guaranteed to be char aligned. > > I created a JEP subtask to keep track of this: > > https://bugs.openjdk.java.net/browse/JDK-8139132 > > We may convert this to an "enhancement" after integrating the changes. That sounds good to me. >> macroAssembler_sparc.cpp >> >> I don?t think you should reference c2 stuff outside c2: >> >> 4440 if (ae == StrIntrinsicNode::LU || ae == StrIntrinsicNode::UL) { > > I added '#ifdef COMPILER2' statements to guard the C2 specific string methods in macroAssembler_sparc.cpp. That still doesn?t feel right but I don?t see where the definitions should go either so we can leave it like that and change it if that code becomes shared. Roland. From mikael.gerdin at oracle.com Thu Oct 8 12:31:07 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 8 Oct 2015 14:31:07 +0200 Subject: RFR (XS) 8139086: Solaris/Sparc slowdebug build fails for memset_with_concurrent_readers.cpp Message-ID: <5616620B.6020606@oracle.com> Hi all, We recently discovered that slowdebug builds fail on Solaris/SPARC due to an issue with inline assembly in memset_with_concurrent_readers_sparc.cpp After discussions with the C++ compiler team at Oracle it was pointed out to us that the code was incorrect in that it had too few %'s. Actual registers referenced by name must be escaped with %% but it appears that enabling optimization in the Studio compiler disregards that requirement. Bug: https://bugs.openjdk.java.net/browse/JDK-8139086 Webrev: http://cr.openjdk.java.net/~mgerdin/8139086/webrev/ Testing: Building product|fastdebug|slowdebug on Solaris/SPARC. Thanks /Mikael From jesper.wilhelmsson at oracle.com Thu Oct 8 12:32:16 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 8 Oct 2015 14:32:16 +0200 Subject: No integration of hs-rt to main this week Message-ID: <56166250.70500@oracle.com> Hi, The integration blockers has been overlapping throughout the week. In total four blockers has been involved. The two from last week was fixed but another blocker (JDK-8138832) was stopping the Tuesday snapshot. This turned out to actually be a good thing since a new bug was found yesterday in one of the changes from last week. This bug (JDK-8138717) is now a blocker. The last blocker is being fixed today and I will take a snapshot tonight. If this snapshot looks good in the Thursday and Friday nightlies I will push this to main on Monday. So, we will miss the integration today but at least we will try to get something into main asap. /Jesper From daniel.daugherty at oracle.com Thu Oct 8 13:09:09 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 8 Oct 2015 07:09:09 -0600 Subject: No integration of hs-rt to main this week In-Reply-To: <56166250.70500@oracle.com> References: <56166250.70500@oracle.com> Message-ID: <56166AF5.1000600@oracle.com> Ummmm... JDK-8138717 was filed six days ago... and now it's a blocker? I'm confused... Dan On 10/8/15 6:32 AM, Jesper Wilhelmsson wrote: > Hi, > > The integration blockers has been overlapping throughout the week. In > total four blockers has been involved. The two from last week was > fixed but another blocker (JDK-8138832) was stopping the Tuesday > snapshot. This turned out to actually be a good thing since a new bug > was found yesterday in one of the changes from last week. This bug > (JDK-8138717) is now a blocker. > > The last blocker is being fixed today and I will take a snapshot > tonight. If this snapshot looks good in the Thursday and Friday > nightlies I will push this to main on Monday. > > So, we will miss the integration today but at least we will try to get > something into main asap. > /Jesper From jesper.wilhelmsson at oracle.com Thu Oct 8 13:14:32 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 8 Oct 2015 15:14:32 +0200 Subject: No integration of hs-rt to main this week In-Reply-To: <56166AF5.1000600@oracle.com> References: <56166250.70500@oracle.com> <56166AF5.1000600@oracle.com> Message-ID: <56166C38.9060704@oracle.com> It should have been a blocker from start. I only noticed today that it didn't have the label. We know what change causes the bug and that change is not in main. /Jesper Den 8/10/15 kl. 15:09, skrev Daniel D. Daugherty: > Ummmm... JDK-8138717 was filed six days ago... and now it's a blocker? > I'm confused... > > Dan > > > On 10/8/15 6:32 AM, Jesper Wilhelmsson wrote: >> Hi, >> >> The integration blockers has been overlapping throughout the week. In total >> four blockers has been involved. The two from last week was fixed but another >> blocker (JDK-8138832) was stopping the Tuesday snapshot. This turned out to >> actually be a good thing since a new bug was found yesterday in one of the >> changes from last week. This bug (JDK-8138717) is now a blocker. >> >> The last blocker is being fixed today and I will take a snapshot tonight. If >> this snapshot looks good in the Thursday and Friday nightlies I will push this >> to main on Monday. >> >> So, we will miss the integration today but at least we will try to get >> something into main asap. >> /Jesper > From tobias.hartmann at oracle.com Thu Oct 8 14:08:39 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 08 Oct 2015 16:08:39 +0200 Subject: RFR: String Density/Compact String JEP 254 In-Reply-To: <230D7F3E-5685-4962-99C6-383B8E6785B4@oracle.com> References: <56129786.1090402@oracle.com> <628568DB-F47A-4BD7-A032-2BECD0E2C539@oracle.com> <56164413.6060405@oracle.com> <230D7F3E-5685-4962-99C6-383B8E6785B4@oracle.com> Message-ID: <561678E7.7010700@oracle.com> Thanks, Roland. On 08.10.2015 14:02, Roland Westrelin wrote: >>> Shouldn?t LibraryCallKit::inline_string_toBytesU() and LibraryCallKit::inline_string_getCharsU() use an ArrayCopyNode (maybe an improvement/cleanup for later)? >>> >>> Same is true for PhaseStringOpts::arraycopy >> >> The problem with using an ArrayCopyNode is that it requires >> >> // (2) src and dest arrays must have elements of the same BasicType >> >> otherwise PhaseMacroExpand::generate_slow_arraycopy() is used. Since for ..toBytesU() and ..getCharsU() we are copying from char[] to byte[] or vice-versa, we cannot use ArrayCopyNode without modifying the macro expansion. >> >> I think the same applies to PhaseStringOpts::arraycopy() where we are copying between two byte arrays because the ArrayCopyNode does not "know" that we can always copy chars since the offsets are guaranteed to be char aligned. >> >> I created a JEP subtask to keep track of this: >> >> https://bugs.openjdk.java.net/browse/JDK-8139132 >> >> We may convert this to an "enhancement" after integrating the changes. > > That sounds good to me. > >>> macroAssembler_sparc.cpp >>> >>> I don?t think you should reference c2 stuff outside c2: >>> >>> 4440 if (ae == StrIntrinsicNode::LU || ae == StrIntrinsicNode::UL) { >> >> I added '#ifdef COMPILER2' statements to guard the C2 specific string methods in macroAssembler_sparc.cpp. > > That still doesn?t feel right but I don?t see where the definitions should go either so we can leave it like that and change it if that code becomes shared. Yes, I agree. The same ifdefs were added to the x86 C2 code. Best, Tobias From kirk.pepperdine at gmail.com Thu Oct 8 14:13:27 2015 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Thu, 8 Oct 2015 16:13:27 +0200 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56164C3C.4050800@cs.oswego.edu> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> Message-ID: <257A3F23-9F15-4BFF-A42B-AAC979A0C8A6@gmail.com> Hi Doug, Brilliant thought, absolutely?. so obvious that it is completely hidden in plain sight. In the past dumping these things into unsafe was a huge mistake. It?s like a back alley for homeless behavior. If you think about it, it?s the thread that would be spinning so it?s obviously the thread that needs the hint. It should own the behavior? Very clear thinking. Regards, Kirk > On Oct 8, 2015, at 12:58 PM, Doug Lea

wrote: > > On 10/06/2015 09:28 PM, Gil Tene wrote: >> >> As for fitting in with larger-picture or theme things (listed above). I think that >> agonizing over the choice of where to put this is important > > To avoid the kinds of problems we later saw when basic JVM methods were > placed in odd places just for the sake of appearances (e.g., park/unpark), > the best choice seems to be class Thread, as in: > > class Thread { // > /** > * A hint to the platform that the current thread is momentarily > * unable to progress. ... add more guidance ... > */ > void spinYield(); > } > > In principle, this would also allow the implementation to do an actual > yield on uniprocessors or when the load average is high. Probably not > in initial implementation though. > > Adding a method to class Thread risks name clashes with existing > methods introduced in subclasses. So this might need a clunkier name > to effectively eliminate the possibility. > > An analogous method could also be added (now or later) > for MWAIT-based support for waits on the thread's park semaphore > (which is more tractable than doing so for an arbitrary variable). > > An alternative to either is to add optional arguments to > yield and park providing a hint about whether to context-switch. > > Joe Darcy: Thread.yield does set a precedent here: > > * A hint to the scheduler that the current thread is willing to yield > * its current use of a processor. The scheduler is free to ignore this > * hint. > > > -Doug > From vitalyd at gmail.com Thu Oct 8 14:39:30 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 8 Oct 2015 10:39:30 -0400 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <257A3F23-9F15-4BFF-A42B-AAC979A0C8A6@gmail.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <257A3F23-9F15-4BFF-A42B-AAC979A0C8A6@gmail.com> Message-ID: I agree with David that it should be static though; it doesn't really make sense to be instance. sent from my phone On Oct 8, 2015 10:13 AM, "Kirk Pepperdine" wrote: > Hi Doug, > > Brilliant thought, absolutely?. so obvious that it is completely hidden in > plain sight. In the past dumping these things into unsafe was a huge > mistake. It?s like a back alley for homeless behavior. If you think about > it, it?s the thread that would be spinning so it?s obviously the thread > that needs the hint. It should own the behavior? Very clear thinking. > > Regards, > Kirk > > > On Oct 8, 2015, at 12:58 PM, Doug Lea

wrote: > > > > On 10/06/2015 09:28 PM, Gil Tene wrote: > >> > >> As for fitting in with larger-picture or theme things (listed above). I > think that > >> agonizing over the choice of where to put this is important > > > > To avoid the kinds of problems we later saw when basic JVM methods were > > placed in odd places just for the sake of appearances (e.g., > park/unpark), > > the best choice seems to be class Thread, as in: > > > > class Thread { // > > /** > > * A hint to the platform that the current thread is momentarily > > * unable to progress. ... add more guidance ... > > */ > > void spinYield(); > > } > > > > In principle, this would also allow the implementation to do an actual > > yield on uniprocessors or when the load average is high. Probably not > > in initial implementation though. > > > > Adding a method to class Thread risks name clashes with existing > > methods introduced in subclasses. So this might need a clunkier name > > to effectively eliminate the possibility. > > > > An analogous method could also be added (now or later) > > for MWAIT-based support for waits on the thread's park semaphore > > (which is more tractable than doing so for an arbitrary variable). > > > > An alternative to either is to add optional arguments to > > yield and park providing a hint about whether to context-switch. > > > > Joe Darcy: Thread.yield does set a precedent here: > > > > * A hint to the scheduler that the current thread is willing to yield > > * its current use of a processor. The scheduler is free to ignore this > > * hint. > > > > > > -Doug > > > > From daniel.daugherty at oracle.com Thu Oct 8 14:39:29 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 8 Oct 2015 08:39:29 -0600 Subject: RFR (XS) 8139086: Solaris/Sparc slowdebug build fails for memset_with_concurrent_readers.cpp In-Reply-To: <5616620B.6020606@oracle.com> References: <5616620B.6020606@oracle.com> Message-ID: <56168021.3040809@oracle.com> On 10/8/15 6:31 AM, Mikael Gerdin wrote: > Hi all, > > We recently discovered that slowdebug builds fail on Solaris/SPARC due > to an issue with inline assembly in > memset_with_concurrent_readers_sparc.cpp > > After discussions with the C++ compiler team at Oracle it was pointed > out to us that the code was incorrect in that it had too few %'s. > > Actual registers referenced by name must be escaped with %% but it > appears that enabling optimization in the Studio compiler disregards > that requirement. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139086 > Webrev: http://cr.openjdk.java.net/~mgerdin/8139086/webrev/ src/cpu/sparc/vm/memset_with_concurrent_readers_sparc.cpp No comments. I did a quick audit in the above file and didn't see any other SPARC register usage that wasn't properly escaped. However, I'm getting rusty with SPARC assembly so someone else with more recent Task Relevant Experience (TRE) should sanity check this also... Thumbs up. Dan > > Testing: Building product|fastdebug|slowdebug on Solaris/SPARC. > > Thanks > /Mikael From dl at cs.oswego.edu Thu Oct 8 14:56:28 2015 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 8 Oct 2015 10:56:28 -0400 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56164D1F.405@redhat.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <56164D1F.405@redhat.com> Message-ID: <5616841C.6000406@cs.oswego.edu> On 10/08/2015 07:01 AM, David M. Lloyd wrote: > On 10/08/2015 05:58 AM, Doug Lea wrote: > >> class Thread { // >> /** >> * A hint to the platform that the current thread is momentarily >> * unable to progress. ... add more guidance ... >> */ >> void spinYield(); should be: public static void spinYield(); >> } >> >> In principle, this would also allow the implementation to do an actual >> yield on uniprocessors or when the load average is high. Probably not >> in initial implementation though. >> >> Adding a method to class Thread risks name clashes with existing >> methods introduced in subclasses. So this might need a clunkier name >> to effectively eliminate the possibility. > > If the method is static, then the impact of a clashing name should be fairly > minimal. > Right. For statics, pretty much the only concern is whether reflective mechanics (Class.getMethod etc) return unexpected entries that would break existing code. The name "spinYield" seems unlikely enough to be a problem though. -Doug From jeanphilippe.bempel at ullink.com Thu Oct 8 15:37:31 2015 From: jeanphilippe.bempel at ullink.com (Jean Philippe Bempel) Date: Thu, 8 Oct 2015 17:37:31 +0200 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56164D1F.405@redhat.com> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <56164D1F.405@redhat.com> Message-ID: On Thu, Oct 8, 2015 at 1:01 PM, David M. Lloyd wrote: > > If the method is static, then the impact of a clashing name should be > fairly minimal. > > +1 on this, I do not see the benefit of an instance method either here. But good idea, Doug, for Thread class and the yield hint :) -- *The information contained in or attached to this email is strictly confidential. If you are not the intended recipient, please notify us immediately by telephone and return the message to us.* From tobias.hartmann at oracle.com Thu Oct 8 15:38:08 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 08 Oct 2015 17:38:08 +0200 Subject: [9] RFR(S): 8139150: ClassVerifier frees exception message while it's still in use Message-ID: <56168DE0.6060602@oracle.com> Hi, please review the following patch. https://bugs.openjdk.java.net/browse/JDK-8139150 http://cr.openjdk.java.net/~thartmann/8139150/webrev.00/ Problem: If class verification fails in StackMapReader::parse_verification_type(), ClassVerifier::class_format_error() is invoked to pass the error message. The method allocates a new string and saves it in ClassVerifier::_message. The problem is that the caller creates a new ResourceMark that leads to _message being deallocated after return. However, later in Verifier::verify() we call ClassVerifier::exception_message() to get the message and pass it on. Solution: We should not create a ResourceMark here. There is a top level ResourceMark in Verifier::verify() that will take care of freeing the memory allocated in ClassVerifier::class_format_error(). Tested with JPRT and the failing testcase. Thanks, Tobias From zoltan.majo at oracle.com Thu Oct 8 15:51:47 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 8 Oct 2015 17:51:47 +0200 Subject: [9] RFR(S): 8139150: ClassVerifier frees exception message while it's still in use In-Reply-To: <56168DE0.6060602@oracle.com> References: <56168DE0.6060602@oracle.com> Message-ID: <56169113.8030300@oracle.com> Hi Tobias, the fix looks good to me. (I'm not a *R*eviewer.) Best regards, Zoltan On 10/08/2015 05:38 PM, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > https://bugs.openjdk.java.net/browse/JDK-8139150 > http://cr.openjdk.java.net/~thartmann/8139150/webrev.00/ > > Problem: > If class verification fails in StackMapReader::parse_verification_type(), ClassVerifier::class_format_error() is invoked to pass the error message. The method allocates a new string and saves it in ClassVerifier::_message. The problem is that the caller creates a new ResourceMark that leads to _message being deallocated after return. However, later in Verifier::verify() we call ClassVerifier::exception_message() to get the message and pass it on. > > Solution: > We should not create a ResourceMark here. There is a top level ResourceMark in Verifier::verify() that will take care of freeing the memory allocated in ClassVerifier::class_format_error(). > > Tested with JPRT and the failing testcase. > > Thanks, > Tobias From daniel.daugherty at oracle.com Thu Oct 8 16:08:43 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 8 Oct 2015 10:08:43 -0600 Subject: [9] RFR(S): 8139150: ClassVerifier frees exception message while it's still in use In-Reply-To: <56168DE0.6060602@oracle.com> References: <56168DE0.6060602@oracle.com> Message-ID: <5616950B.4050402@oracle.com> On 10/8/15 9:38 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > https://bugs.openjdk.java.net/browse/JDK-8139150 > http://cr.openjdk.java.net/~thartmann/8139150/webrev.00/ src/share/vm/classfile/stackMapTable.cpp No comments. Thumbs up! Did a quick audit and I don't see any other calls to class_format_error() with the same issue. This bug is very old. That ResourceMark came from here: $ sp -r1.17 src/share/vm/classfile/stackMapTable.cpp src/share/vm/classfile/SCCS/s.stackMapTable.cpp: D 1.17 05/06/20 17:21:50 mingyao 18 17 00015/00008/00446 MRs: COMMENTS: Fixed 6275215, VM fails on StackMapTable jcod tests (VerifyError) Fixed 6275199, VM fails on StackMapTable jcod tests Fixed 6275153, VM fails on StackMapTable tests And the code looked like this: 187a185,194 > if (offset >= _code_length || > _code_data[offset] != ClassVerifier::NEW_OFFSET) { > ResourceMark rm(THREAD); > Exceptions::fthrow( > THREAD_AND_LOCATION, > vmSymbolHandles::java_lang_ClassFormatError(), > "StackMapTable format error: bad offset for Uninitialized" > ); > return NULL; > } The class_format_error() call came from here: D 1.21 06/04/13 11:43:50 km88527 23 22 00064/00108/00360 MRs: COMMENTS: fixed 6402717: Error verifying java.lang.Error causes VM to exit silently due to stack overflow and the code changed to look like this: if (offset >= _code_length || _code_data[offset] != ClassVerifier::NEW_OFFSET) { ResourceMark rm(THREAD); _verifier->class_format_error( "StackMapTable format error: bad offset for Uninitialized"); return NULL; } This fix should probably be backported... but I would check with Harold... Dan > > Problem: > If class verification fails in StackMapReader::parse_verification_type(), ClassVerifier::class_format_error() is invoked to pass the error message. The method allocates a new string and saves it in ClassVerifier::_message. The problem is that the caller creates a new ResourceMark that leads to _message being deallocated after return. However, later in Verifier::verify() we call ClassVerifier::exception_message() to get the message and pass it on. > > Solution: > We should not create a ResourceMark here. There is a top level ResourceMark in Verifier::verify() that will take care of freeing the memory allocated in ClassVerifier::class_format_error(). > > Tested with JPRT and the failing testcase. > > Thanks, > Tobias From harold.seigel at oracle.com Thu Oct 8 16:17:36 2015 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 8 Oct 2015 12:17:36 -0400 Subject: [9] RFR(S): 8139150: ClassVerifier frees exception message while it's still in use In-Reply-To: <5616950B.4050402@oracle.com> References: <56168DE0.6060602@oracle.com> <5616950B.4050402@oracle.com> Message-ID: <56169720.7020804@oracle.com> I think we should backport the fix to 8u. Harold On 10/8/2015 12:08 PM, Daniel D. Daugherty wrote: > On 10/8/15 9:38 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch. >> >> https://bugs.openjdk.java.net/browse/JDK-8139150 >> http://cr.openjdk.java.net/~thartmann/8139150/webrev.00/ > > src/share/vm/classfile/stackMapTable.cpp > No comments. > > Thumbs up! > > Did a quick audit and I don't see any other calls to > class_format_error() with the same issue. > > This bug is very old. That ResourceMark came from here: > > $ sp -r1.17 src/share/vm/classfile/stackMapTable.cpp > src/share/vm/classfile/SCCS/s.stackMapTable.cpp: > > D 1.17 05/06/20 17:21:50 mingyao 18 17 00015/00008/00446 > MRs: > COMMENTS: > Fixed 6275215, VM fails on StackMapTable jcod tests (VerifyError) > Fixed 6275199, VM fails on StackMapTable jcod tests > Fixed 6275153, VM fails on StackMapTable tests > > And the code looked like this: > > 187a185,194 > > if (offset >= _code_length || > > _code_data[offset] != ClassVerifier::NEW_OFFSET) { > > ResourceMark rm(THREAD); > > Exceptions::fthrow( > > THREAD_AND_LOCATION, > > vmSymbolHandles::java_lang_ClassFormatError(), > > "StackMapTable format error: bad offset for Uninitialized" > > ); > > return NULL; > > } > > > The class_format_error() call came from here: > > D 1.21 06/04/13 11:43:50 km88527 23 22 00064/00108/00360 > MRs: > COMMENTS: > fixed 6402717: Error verifying java.lang.Error causes VM to exit > silently due to stack overflow > > and the code changed to look like this: > > if (offset >= _code_length || > _code_data[offset] != ClassVerifier::NEW_OFFSET) { > ResourceMark rm(THREAD); > _verifier->class_format_error( > "StackMapTable format error: bad offset for Uninitialized"); > return NULL; > } > > This fix should probably be backported... but I would > check with Harold... > > Dan > > >> >> Problem: >> If class verification fails in >> StackMapReader::parse_verification_type(), >> ClassVerifier::class_format_error() is invoked to pass the error >> message. The method allocates a new string and saves it in >> ClassVerifier::_message. The problem is that the caller creates a new >> ResourceMark that leads to _message being deallocated after return. >> However, later in Verifier::verify() we call >> ClassVerifier::exception_message() to get the message and pass it on. >> >> Solution: >> We should not create a ResourceMark here. There is a top level >> ResourceMark in Verifier::verify() that will take care of freeing the >> memory allocated in ClassVerifier::class_format_error(). >> >> Tested with JPRT and the failing testcase. >> >> Thanks, >> Tobias > From mark.reinhold at oracle.com Thu Oct 8 16:33:18 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 08 Oct 2015 09:33:18 -0700 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <5616841C.6000406@cs.oswego.edu> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com>, <561428BC.3060806@cs.oswego.edu>, <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com>, <56164C3C.4050800@cs.oswego.edu>, <56164D1F.405@redhat.com>, <5616841C.6000406@cs.oswego.edu> Message-ID: <20151008093318.990378@eggemoggin.niobe.net> 2015/10/8 7:56 -0700, dl at cs.oswego.edu: >>> ... >>> >>> class Thread { // >>> /** >>> * A hint to the platform that the current thread is momentarily >>> * unable to progress. ... add more guidance ... >>> */ >>> void spinYield(); > > should be: > public static void spinYield(); Yes -- let's keep this simple. It's just one method, another hint in j.l.Thread which can be ignored (or not) by the VM. This concept seems sufficiently well understood, based on its use in other platforms, that putting it directly into j.l.Thread is not a huge risk. I don't see a strong need for this to start out as a JDK-specific API. - Mark From paul.sandoz at oracle.com Thu Oct 8 16:35:45 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 8 Oct 2015 18:35:45 +0200 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <20151008093318.990378@eggemoggin.niobe.net> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <56164D1F.405@redhat.com> <5616841C.6000406@cs.oswego.edu> <20151008093318.990378@eggemoggin.niobe.net> Message-ID: > On 8 Oct 2015, at 18:33, mark.reinhold at oracle.com wrote: > > 2015/10/8 7:56 -0700, dl at cs.oswego.edu: >>>> ... >>>> >>>> class Thread { // >>>> /** >>>> * A hint to the platform that the current thread is momentarily >>>> * unable to progress. ... add more guidance ... >>>> */ >>>> void spinYield(); >> >> should be: >> public static void spinYield(); > > Yes -- let's keep this simple. It's just one method, another hint > in j.l.Thread which can be ignored (or not) by the VM. > > This concept seems sufficiently well understood, based on its use > in other platforms, that putting it directly into j.l.Thread is not > a huge risk. I don't see a strong need for this to start out as a > JDK-specific API. > +1 Paul. From kim.barrett at oracle.com Thu Oct 8 16:37:43 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 8 Oct 2015 12:37:43 -0400 Subject: RFR (XS) 8139086: Solaris/Sparc slowdebug build fails for memset_with_concurrent_readers.cpp In-Reply-To: <5616620B.6020606@oracle.com> References: <5616620B.6020606@oracle.com> Message-ID: <77CD18C8-E241-4933-89EA-7347E672C0FC@oracle.com> On Oct 8, 2015, at 8:31 AM, Mikael Gerdin wrote: > > Hi all, > > We recently discovered that slowdebug builds fail on Solaris/SPARC due to an issue with inline assembly in memset_with_concurrent_readers_sparc.cpp > > After discussions with the C++ compiler team at Oracle it was pointed out to us that the code was incorrect in that it had too few %'s. > > Actual registers referenced by name must be escaped with %% but it appears that enabling optimization in the Studio compiler disregards that requirement. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139086 > Webrev: http://cr.openjdk.java.net/~mgerdin/8139086/webrev/ > > Testing: Building product|fastdebug|slowdebug on Solaris/SPARC. Looks good. Thanks for taking care of this so quickly. From alejandro.murillo at oracle.com Thu Oct 8 16:38:22 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Thu, 08 Oct 2015 10:38:22 -0600 Subject: No integration of hs-rt to main this week In-Reply-To: <56166250.70500@oracle.com> References: <56166250.70500@oracle.com> Message-ID: <56169BFE.9040004@oracle.com> On 10/8/2015 6:32 AM, Jesper Wilhelmsson wrote: > Hi, > > The integration blockers has been overlapping throughout the week. In > total four blockers has been involved. The two from last week was > fixed but another blocker (JDK-8138832) was stopping the Tuesday > snapshot. This turned out to actually be a good thing since a new bug > was found yesterday in one of the changes from last week. This bug > (JDK-8138717) is now a blocker. > > The last blocker is being fixed today and I will take a snapshot > tonight. If this snapshot looks good in the Thursday and Friday > nightlies I will push this to main on Monday. > > So, we will miss the integration today but at least we will try to get > something into main asap. > /Jesper sounds good, thanks for the heads up -- Alejandro From christian.thalinger at oracle.com Thu Oct 8 17:19:16 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 8 Oct 2015 07:19:16 -1000 Subject: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface In-Reply-To: <97150580-7329-438F-9B64-F47E3BFE9F08@oracle.com> References: <2B401EAC-B386-4E42-BC4C-DD267FFD4970@oracle.com> <55F9671C.4000208@oracle.com> <99042B61-9F43-42CE-835C-095CD2858CB1@oracle.com> <55F9F08E.8010506@oracle.com> <08A9DB82-58D0-41F8-97F5-23AD78205263@oracle.com>

<067C7DA1-7422-411E-A678-91FBDECEBE1D@oracle.com> <8E92D69B-7207-4CDC-80F7-3AA65AC5C482@oracle.com> <97150580-7329-438F-9B64-F47E3BFE9F08@oracle.com> Message-ID: <6E2F68BA-95EF-4E50-AE0A-40D25507DA62@oracle.com> > On Sep 24, 2015, at 8:57 AM, Christian Thalinger wrote: > >> >> On Sep 21, 2015, at 12:24 PM, Christian Thalinger > wrote: >> >> >>> On Sep 18, 2015, at 2:19 PM, Christian Thalinger wrote: >>> >>> >>>> On Sep 18, 2015, at 7:00 AM, Christian Thalinger wrote: >>>> >>>> >>>>> On Sep 17, 2015, at 11:00 PM, Volker Simonis wrote: >>>>> >>>>> To which repository will you finally push these changes? >>>>> >>>>> The current webrevs are against jdk9/jdk9/hotspot but I doubt that >>>>> they will be integrated there. >>>> >>>> Good point. >>>> >>>>> >>>>> Unfortunately the patches don't apply to jdk9/dev/hotspot anymore >>>>> because of '8135067: Preparatory refactorings for compiler control' >>>>> and "8134626: Misc cleanups after generation array removal": >>>>> >>>>> 3 out of 18 hunks FAILED -- saving rejects to file >>>>> src/share/vm/compiler/compileBroker.cpp.rej >>>>> 1 out of 5 hunks FAILED -- saving rejects to file >>>>> src/share/vm/compiler/compileBroker.hpp.rej >>>>> 6 out of 40 hunks FAILED -- saving rejects to file >>>>> src/share/vm/runtime/vmStructs.cpp.rej >>>>> >>>>> Will you update the patches and if yes against which repositories? >>>> >>>> Yes. Let me update the graal-jvmci-9 repository to hs-comp. >>> >>> Done. Now I have to create new webrevs? >> >> Here are new webrevs against hs-comp: >> >> http://cr.openjdk.java.net/~twisti/8136421/webrev/ > >> http://cr.openjdk.java.net/~twisti/8136421/hotspot/webrev/ > > > I have refreshed these webrevs. They contain all the changes we discussed here plus a bunch of new tests that SQE finished. Quick update: we are more or less ready for integration. Today I pushed one last big changeset which renames the JVMCI package name from jdk.internal.jvmci to jdk.vm.ci and moves the JVMCI into its own module jdk.vm.ci. There are no changes semantically (except the build system changes). If testing looks good I will integrate this into hs-comp later today. > >> >>> >>>> >>>>> >>>>> If I want to work on the ppc64 implementation, which repository should I use? >>>> >>>> graal-jvmci-9. Are you working on this for fun or do you want to have that integrated with this JEP? >>>> >>>>> >>>>> Thank you and best regards, >>>>> Volker >>>>> >>>>> >>>>> On Fri, Sep 18, 2015 at 10:20 AM, Volker Simonis >>>>> wrote: >>>>>> For the top-level change I always get a strange error when importing it: >>>>>> >>>>>> patch failed, unable to continue (try -v) >>>>>> patch failed, rejects left in working dir >>>>>> errors during apply, please fix and refresh 8062493_jvmci_top_0911.v1.patch >>>>>> >>>>>> It is because of the strange path syntax of the last hunk in the patch file: >>>>>> >>>>>> --- old/./modules.xml 2015-09-16 15:11:14.000000000 -0700 >>>>>> +++ new/./modules.xml 2015-09-16 15:11:14.000000000 -0700 >>>>>> @@ -254,6 +254,14 @@ >>>>>> jdk.jfr >>>>>> >>>>>> >>>>>> + jdk.internal.jvmci.hotspot >>>>>> + jdk.jfr >>>>>> + >>>>>> + >>>>>> + jdk.internal.jvmci.hotspot.events >>>>>> + jdk.jfr >>>>>> + >>>>>> + >>>>>> sun.misc >>>>>> java.corba >>>>>> java.desktop >>>>>> >>>>>> >>>>>> Notice the strange syntax "old/./modules.xml" and "new/./modules.xml". >>>>>> If I remove the redundant './' from the path, everything works fine. >>>>>> For some reason only the diffs for modules.xml has this strange path >>>>>> syntax in the patch. >>>>>> >>>>>> Regards, >>>>>> Volker >>>>>> >>>>>> >>>>>> On Thu, Sep 17, 2015 at 10:32 PM, Christian Thalinger >>>>>> wrote: >>>>>>> Since there are no objections I?m going to push this? >>>>>>> >>>>>>> http://hg.openjdk.java.net/graal/graal-jvmci-9/hotspot/rev/6a6766a8cbbf >>>>>>> >>>>>>>> On Sep 16, 2015, at 3:05 PM, Christian Thalinger wrote: >>>>>>>> >>>>>>>> I would like to add this change: >>>>>>>> >>>>>>>> diff -r 2134e08cc132 src/share/vm/utilities/vmError.cpp >>>>>>>> --- a/src/share/vm/utilities/vmError.cpp Wed Sep 16 14:28:33 2015 -1000 >>>>>>>> +++ b/src/share/vm/utilities/vmError.cpp Wed Sep 16 15:04:02 2015 -1000 >>>>>>>> @@ -517,6 +517,10 @@ void VMError::report(outputStream* st) { >>>>>>>> Abstract_VM_Version::vm_release(), >>>>>>>> Abstract_VM_Version::vm_info_string(), >>>>>>>> TieredCompilation ? ", tiered" : "", >>>>>>>> +#if INCLUDE_JVMCI >>>>>>>> + EnableJVMCI ? ", jvmci" : "", >>>>>>>> + UseJVMCICompiler ? ", jvmci compiler" : "", >>>>>>>> +#endif >>>>>>>> UseCompressedOops ? ", compressed oops" : "", >>>>>>>> gc_mode(), >>>>>>>> Abstract_VM_Version::vm_platform_string() >>>>>>>> >>>>>>>> It would be useful to see in the crash logs if this experimental feature was turned on. >>>>>>>> >>>>>>>>> On Sep 16, 2015, at 12:43 PM, Vladimir Kozlov wrote: >>>>>>>>> >>>>>>>>> I updated top and hotspot webrev with latest (build) changes. >>>>>>>>> >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 9/16/15 2:28 PM, Christian Thalinger wrote: >>>>>>>>>> >>>>>>>>>>> On Sep 16, 2015, at 6:52 AM, Christian Thalinger wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Sep 16, 2015, at 2:57 AM, Magnus Ihse Bursie wrote: >>>>>>>>>>>> >>>>>>>>>>>> On 2015-09-14 09:24, Christian Thalinger wrote: >>>>>>>>>>>>> The JEP itself can be found here: >>>>>>>>>>>>> >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8062493 >>>>>>>>>>>>> >>>>>>>>>>>>> Here are the webrevs: >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.top/ >>>>>>>>>>>>> http://cr.openjdk.java.net/~kvn/JVMCI/webrev.hotspot/ >>>>>>>>>>>>> >>>>>>>>>>>>> The change has already undergone a few iterations of internal review by different people of different teams. Most comments and suggestions were handled accordingly. Although there is one open item we agreed we will address after the integration of JEP 243 and that work is captured in RFE: >>>>>>>>>>>>> >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8134994 >>>>>>>>>>>>> >>>>>>>>>>>>> SQE is still working on the tests and all test tasks can be seen as sub-tasks of the JEP. >>>>>>>>>>>>> >>>>>>>>>>>>> The integration will happen under the bug number: >>>>>>>>>>>>> >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8136421 >>>>>>>>>>>>> >>>>>>>>>>>> Hi Christian, >>>>>>>>>>>> >>>>>>>>>>>> (Adding build-dev since this review includes some major build changes.) >>>>>>>>>>>> >>>>>>>>>>>> The makefile changes looks good in general to me. I have not reviewed the source code changes. >>>>>>>>>>>> >>>>>>>>>>>> Some comments: >>>>>>>>>>>> >>>>>>>>>>>> * modules.xml: >>>>>>>>>>>> Make sure you get sign-off from a Jigsaw developer for modifying this file. >>>>>>>>>>> >>>>>>>>>>> I?ve asked Alan to take a look. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> * hotspot/make/linux/makefiles/gcc.make: >>>>>>>>>>>> Seems unfortunate to have to disable a new warning (undefined-bool-conversion) for newly incorporated code. Is it not possible to fix the code emitting this warning instead? >>>>>>>>>>> >>>>>>>>>>> We had this question before. It?s not obvious because you can?t see it in the regular diff views but this is under: >>>>>>>>>>> >>>>>>>>>>> ifeq ($(USE_CLANG), true) >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> * make/common/MakeBase.gmk and hotspot/make/gensrc/Gensrc-java.base.gmk: >>>>>>>>>>>> I see a coming merge conflict. In jdk9/dev, there is now a new function that performs the same function as CreatePath, but it's named PathList. (It's a bit unfortunate that this code snippet has bounced around as patches without a definite name.) I assume you are going to push this through a hotspot forest. If the PathList patch reaches the hotspot repo before this, please remove the CreatePath from MakeBase, and change the calls to CreatePath to PathList instead. (I could only find such calls in hotspot/make/gensrc/Gensrc-java.base.gmk). If this patch goes in before that, we'll need to give a heads-up to the integrator about this conflict. >>>>>>>>>>> >>>>>>>>>>> Thanks for the heads up. >>>>>>>>>> >>>>>>>>>> Erik sent me a patch to avoid merge conflicts. I?ve integrated two changesets: >>>>>>>>>> >>>>>>>>>> http://hg.openjdk.java.net/graal/graal-jvmci-9/rev/ddedccc5c0ab > >>>>>>>>>> http://hg.openjdk.java.net/graal/graal-jvmci-9/hotspot/rev/fee6b89199c9 > >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Another potential coming merge conflict relates to ListPathsSafely in Gensrc-java.base.gmk. There is currenlty a review out from Erik which modifies the API for ListPathsSafely. If/when it goes in, the call to ListPathsSafely in Gensrc-java.base.gmk will need to be modified (Erik can give advice on how). Depending on timing, this too might hit the integrator rather than your push. >>>>>>>>>>> >>>>>>>>>>> Ok, thanks. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> /Magnus From coleen.phillimore at oracle.com Thu Oct 8 17:26:09 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 08 Oct 2015 13:26:09 -0400 Subject: RFR (XS) 8139086: Solaris/Sparc slowdebug build fails for memset_with_concurrent_readers.cpp In-Reply-To: <77CD18C8-E241-4933-89EA-7347E672C0FC@oracle.com> References: <5616620B.6020606@oracle.com> <77CD18C8-E241-4933-89EA-7347E672C0FC@oracle.com> Message-ID: <5616A731.30200@oracle.com> On 10/8/15 12:37 PM, Kim Barrett wrote: > On Oct 8, 2015, at 8:31 AM, Mikael Gerdin wrote: >> Hi all, >> >> We recently discovered that slowdebug builds fail on Solaris/SPARC due to an issue with inline assembly in memset_with_concurrent_readers_sparc.cpp >> >> After discussions with the C++ compiler team at Oracle it was pointed out to us that the code was incorrect in that it had too few %'s. >> >> Actual registers referenced by name must be escaped with %% but it appears that enabling optimization in the Studio compiler disregards that requirement. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8139086 >> Webrev: http://cr.openjdk.java.net/~mgerdin/8139086/webrev/ >> >> Testing: Building product|fastdebug|slowdebug on Solaris/SPARC. > Looks good. Thanks for taking care of this so quickly. +1 I really appreciate it! Coleen > From kim.barrett at oracle.com Thu Oct 8 17:30:52 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 8 Oct 2015 13:30:52 -0400 Subject: RFR: 8138659: Speed up InstanceKlass subclass discrimination In-Reply-To: <561651BF.6050806@oracle.com> References: <5612D757.5040905@oracle.com> <5422E78A-5321-406D-9997-7A19BB4A4ABD@oracle.com> <294721F8-D7E7-4FB5-9CC7-39C984EC87F0@oracle.com> <5615AC2D.3030204@oracle.com> <561651BF.6050806@oracle.com> Message-ID: <2A7586A9-DF9D-40E4-8DF2-290EACA644AF@oracle.com> On Oct 8, 2015, at 7:21 AM, Coleen Phillimore wrote: > > > > On 10/7/15 8:43 PM, Kim Barrett wrote: >> On Oct 7, 2015, at 7:35 PM, Coleen Phillimore wrote: >>> Kim, >>> >>> This looks *very* nice. Thank you for doing this: >>> >>> + return static_cast(k); >>> >>> >>> For bonus points can you change this to a static_cast<> ??? >>> >>> // Casting from Klass* >>> static InstanceKlass* cast(Klass* k) { >>> assert(k == NULL || k->is_klass(), "must be"); >>> assert(k == NULL || k->oop_is_instance(), "cast to InstanceKlass"); >>> return (InstanceKlass*) k; >>> } >> Yikes! I somehow forgot that InstanceKlass::cast accepted NULL. But I wonder if that case really >> arises? Certainly a large percentage of uses of it will (nearly) instantly crash if k is NULL, because >> we immediately call some member function on the result of the cast. > > Oh, yeah, this looks bad! File another bug and someone will look for why we allow null here. https://bugs.openjdk.java.net/browse/JDK-8139163 A quick look found a place that requires that behavior, though it could easily be rewritten to not. There are likely at least a few more, but I would still be inclined to make the change and fix the problem cases. See the bug report for more details, including some numbers. From viktor.klang at gmail.com Thu Oct 8 17:48:51 2015 From: viktor.klang at gmail.com (Viktor Klang) Date: Thu, 8 Oct 2015 19:48:51 +0200 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <56164D1F.405@redhat.com> <5616841C.6000406@cs.oswego.edu> <20151008093318.990378@eggemoggin.niobe.net> Message-ID: +1 On Thu, Oct 8, 2015 at 6:35 PM, Paul Sandoz wrote: > > > On 8 Oct 2015, at 18:33, mark.reinhold at oracle.com wrote: > > > > 2015/10/8 7:56 -0700, dl at cs.oswego.edu: > >>>> ... > >>>> > >>>> class Thread { // > >>>> /** > >>>> * A hint to the platform that the current thread is momentarily > >>>> * unable to progress. ... add more guidance ... > >>>> */ > >>>> void spinYield(); > >> > >> should be: > >> public static void spinYield(); > > > > Yes -- let's keep this simple. It's just one method, another hint > > in j.l.Thread which can be ignored (or not) by the VM. > > > > This concept seems sufficiently well understood, based on its use > > in other platforms, that putting it directly into j.l.Thread is not > > a huge risk. I don't see a strong need for this to start out as a > > JDK-specific API. > > > > +1 > > Paul. > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > > -- Cheers, ? From christian.thalinger at oracle.com Thu Oct 8 19:58:43 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 8 Oct 2015 09:58:43 -1000 Subject: CLANG special case In-Reply-To: References: <5A5E3D06-3825-40C9-92BA-511C41ACFEF3@oracle.com> <5613EAF0.6000102@oracle.com>

Message-ID: I?ve assigned the bug to me and will verify? > On Oct 6, 2015, at 9:23 AM, Jim Laskey (Oracle) wrote: > > Since we are will to live with the de-optimization now, we should just remove the condition until proven otherwise. > > >> On Oct 6, 2015, at 4:17 PM, Staffan Larsen wrote: >> >> When we upgraded to clang 6.3, I verified that the problem still existed. See: https://bugs.openjdk.java.net/browse/JDK-8077364 which has pointers to the two tests that fail without the workaround. >> >> /Staffan >> >>> On 6 okt 2015, at 17:38, Phil Race > wrote: >>> >>> Ideally hotspot would review this, not build. >>> so it would be helpful if hotspot found an engineer to own the bug :- >>> https://bugs.openjdk.java.net/browse/JDK-8138820 >>> So far as I know this is not tracked under any other bug id. >>> >>> -phil. >>> >>> On 10/06/2015 05:30 AM, Jim Laskey (Oracle) wrote: >>>> I?ve updated to El Capitan and, of course, builds fail, and, of course, I modify hotspot/make/bsd/makefiles/gcc.make one more time and? I think this conditional clause should be removed at the very least (commenting to indicate needs investigation), or someone should research and see which version of clang fixes the issues associate with the patch. Since it?s likely that no one has the cycles, please remove the condition. >>>> >>>> Cheers, >>>> >>>> ? Jim >>>> >>>> >>>> >>>> diff -r a02911828e48 make/bsd/makefiles/gcc.make >>>> --- a/make/bsd/makefiles/gcc.make Wed Sep 30 07:41:36 2015 -0700 >>>> +++ b/make/bsd/makefiles/gcc.make Tue Oct 06 09:22:50 2015 -0300 >>>> @@ -313,21 +313,13 @@ >>>> # Work around some compiler bugs. >>>> ifeq ($(USE_CLANG), true) >>>> - # Clang <= 6.1 >>>> - ifeq ($(shell expr \ >>>> - $(CC_VER_MAJOR) \< 6 \| \ >>>> - $ $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) \<= 1 $ \ >>>> - ), 1) >>>> - OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) >>>> - OPT_CFLAGS/unsafe.o += -O1 >>>> - else >>>> - $(error "Update compiler workarounds for Clang $(CC_VER_MAJOR).$(CC_VER_MINOR)") >>>> - endif >>>> + OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) >>>> + OPT_CFLAGS/unsafe.o += -O1 >>>> else >>>> # 6835796. Problem in GCC 4.3.0 with mulnode.o optimized compilation. >>>> ifeq ($(shell expr $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 3), 1) >>>> OPT_CFLAGS/mulnode.o += $(OPT_CFLAGS/NOOPT) >>>> - endif >>>> + endif >>>> endif >>>> # Flags for generating make dependency flags. >>>> >>> >> > From christian.thalinger at oracle.com Thu Oct 8 20:34:51 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 8 Oct 2015 10:34:51 -1000 Subject: RFR (XXS): 8138820: JDK Hotspot build fails with Xcode 7.0.1 Message-ID: <0AF6364F-0E12-460D-A1C8-0F0FA72FAA7C@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8138820 I?ve verified we still need both workarounds. diff -r 0011fab3f1b5 make/bsd/makefiles/gcc.make --- a/make/bsd/makefiles/gcc.make Thu Oct 08 10:25:45 2015 +0000 +++ b/make/bsd/makefiles/gcc.make Thu Oct 08 10:33:02 2015 -1000 @@ -313,10 +313,11 @@ endif # Work around some compiler bugs. ifeq ($(USE_CLANG), true) - # Clang <= 6.1 + # Clang <= 6.1 | <= 7.0 ifeq ($(shell expr \ $(CC_VER_MAJOR) \< 6 \| \ - $ $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) \<= 1 $ \ + $ $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) \<= 1 $ \| \ + $ $(CC_VER_MAJOR) = 7 \& $(CC_VER_MINOR) \<= 0 $ \ ), 1) OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) OPT_CFLAGS/unsafe.o += -O1 From igor.veresov at oracle.com Thu Oct 8 23:37:47 2015 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 8 Oct 2015 16:37:47 -0700 Subject: RFR (XXS): 8138820: JDK Hotspot build fails with Xcode 7.0.1 In-Reply-To: <0AF6364F-0E12-460D-A1C8-0F0FA72FAA7C@oracle.com> References: <0AF6364F-0E12-460D-A1C8-0F0FA72FAA7C@oracle.com> Message-ID: Good. igor > On Oct 8, 2015, at 1:34 PM, Christian Thalinger wrote: > > https://bugs.openjdk.java.net/browse/JDK-8138820 > > I?ve verified we still need both workarounds. > > diff -r 0011fab3f1b5 make/bsd/makefiles/gcc.make > --- a/make/bsd/makefiles/gcc.make Thu Oct 08 10:25:45 2015 +0000 > +++ b/make/bsd/makefiles/gcc.make Thu Oct 08 10:33:02 2015 -1000 > @@ -313,10 +313,11 @@ endif > > # Work around some compiler bugs. > ifeq ($(USE_CLANG), true) > - # Clang <= 6.1 > + # Clang <= 6.1 | <= 7.0 > ifeq ($(shell expr \ > $(CC_VER_MAJOR) \< 6 \| \ > - $ $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) \<= 1 $ \ > + $ $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) \<= 1 $ \| \ > + $ $(CC_VER_MAJOR) = 7 \& $(CC_VER_MINOR) \<= 0 $ \ > ), 1) > OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) > OPT_CFLAGS/unsafe.o += -O1 > From christian.thalinger at oracle.com Thu Oct 8 23:44:25 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 8 Oct 2015 13:44:25 -1000 Subject: RFR (XXS): 8138820: JDK Hotspot build fails with Xcode 7.0.1 In-Reply-To: References: <0AF6364F-0E12-460D-A1C8-0F0FA72FAA7C@oracle.com> Message-ID: Thanks, Igor. > On Oct 8, 2015, at 1:37 PM, Igor Veresov wrote: > > Good. > > igor > >> On Oct 8, 2015, at 1:34 PM, Christian Thalinger wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8138820 >> >> I?ve verified we still need both workarounds. >> >> diff -r 0011fab3f1b5 make/bsd/makefiles/gcc.make >> --- a/make/bsd/makefiles/gcc.make Thu Oct 08 10:25:45 2015 +0000 >> +++ b/make/bsd/makefiles/gcc.make Thu Oct 08 10:33:02 2015 -1000 >> @@ -313,10 +313,11 @@ endif >> >> # Work around some compiler bugs. >> ifeq ($(USE_CLANG), true) >> - # Clang <= 6.1 >> + # Clang <= 6.1 | <= 7.0 >> ifeq ($(shell expr \ >> $(CC_VER_MAJOR) \< 6 \| \ >> - $ $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) \<= 1 $ \ >> + $ $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) \<= 1 $ \| \ >> + $ $(CC_VER_MAJOR) = 7 \& $(CC_VER_MINOR) \<= 0 $ \ >> ), 1) >> OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) >> OPT_CFLAGS/unsafe.o += -O1 >> > From david.lloyd at redhat.com Thu Oct 8 11:01:51 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 8 Oct 2015 06:01:51 -0500 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: <56164C3C.4050800@cs.oswego.edu> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> Message-ID: <56164D1F.405@redhat.com> On 10/08/2015 05:58 AM, Doug Lea wrote: > On 10/06/2015 09:28 PM, Gil Tene wrote: >> >> As for fitting in with larger-picture or theme things (listed above). >> I think that >> agonizing over the choice of where to put this is important > > To avoid the kinds of problems we later saw when basic JVM methods were > placed in odd places just for the sake of appearances (e.g., park/unpark), > the best choice seems to be class Thread, as in: > > class Thread { // > /** > * A hint to the platform that the current thread is momentarily > * unable to progress. ... add more guidance ... > */ > void spinYield(); > } > > In principle, this would also allow the implementation to do an actual > yield on uniprocessors or when the load average is high. Probably not > in initial implementation though. > > Adding a method to class Thread risks name clashes with existing > methods introduced in subclasses. So this might need a clunkier name > to effectively eliminate the possibility. If the method is static, then the impact of a clashing name should be fairly minimal. -- - DML From john.r.rose at oracle.com Fri Oct 9 01:18:22 2015 From: john.r.rose at oracle.com (John Rose) Date: Thu, 8 Oct 2015 18:18:22 -0700 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> <38110705-2789-4050-913C-0568DD8B61E9@oracle.com> Message-ID: On Oct 8, 2015, at 12:39 AM, Gil Tene wrote: > > On the one hand: > > I like the idea of (an optional?) boolean parameter as a means of hinting at the thing that may terminate the spin. It's probably much more general than identifying a specific field or address. And it can be used to cover cases that poll multiple addresses (an or in the boolean) or look a termination time. If the JVM can track down the boolean's evaluation to dependencies on specific memory state changes, it could pass it on to hardware, if such hardware exists. Yep. And there is a user-mode MWAIT in SPARC M7, today. For Intel, Dave Dice wrote this up: https://blogs.oracle.com/dave/entry/monitor_mwait_for_spin_loops Also, from a cross-platform POV, a boolean would provide an easy to use "hook" for profiling how often the polling is failing. Failure frequency is an important input to the tuning of spin loops, isn't it? Why not feed that info through to the JVM? > On the other hard: > > Unfortunately, I don't think that hardware support that can receive the address information exists right now, (It does, on SPARC.) > and if/when it does, I'm not sure the semantics of passing the boolean through are enough to cover the actual way to use such hardware when it becomes available. The alternative is to have the JIT pattern-match for loop control around the call to Thread.yield. That is obviously less robust than having the user thread the poll condition bit through the poll primitive. > It is probably premature to design a generic way to provide addresses and/or state to this "spin until something interesting changes" stuff without looking at working examples. A single watched address API is much more likely to fit current implementations without being fragile. > > ARM v8's WFE is probably the most real user-mode-accesible thing for this right now (MWAIT isn't real yet, as it's not accessible from user mode). We can look at an example of how a spinloop needs to coordinate the use of WFE, SEVL, and the evaluation of memory location with load exclusive operations here: http://lxr.free-electrons.com/source/arch/arm64/include/asm/spinlock.h . The tricky part is that the SEVL needs to immediately proceed the loop (and all accesses that need to be watched by the WFE), but can't be part of the loop (if were in the loop the WFE would always trigger immediately). But the code in the spinning loop can can only track a single address (the exclusive tag in load exclusive applies only the the most recent address used), so it would be wrong to allow generic code in the spin (it would have to be code that watches exactly one address). > > My suspicion is that the "right" way to capture the various ways a spin loop would need to interact with RFE logic will be different than tracking things that can generically affect the value of a boolean. E.g. the evaluation of the boolean could be based on multiple addresses, and since it's not clear (in the API) that this is a problem, the benefits derived would be fragile. Having the JIT explore nearby loop structure for memory references is even more fragile. If we can agree that (a) there are advantages to profiling the boolean parameter for all platforms, and (b) the single-poll-variable case is likely to be optimizable sooner *with* a parameter than *without*, maybe this is enough to tip the scales towards boolean parameter. The idea would be that programmers would take a little extra thought when using yield(Z)Z, and get paid immediately from good profiling. They would get paid again later if and when platforms analyze data dependencies on the Z. If there's no initial payoff, then, yes, it is hard asking programmers to expend extra thought that only benefits on some platforrms. ? John From gil at azul.com Fri Oct 9 06:56:02 2015 From: gil at azul.com (Gil Tene) Date: Fri, 9 Oct 2015 06:56:02 +0000 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> <38110705-2789-4050-913C-0568DD8B61E9@oracle.com>

Message-ID: > On Oct 8, 2015, at 6:18 PM, John Rose wrote: > > On Oct 8, 2015, at 12:39 AM, Gil Tene wrote: >> >> On the one hand: >> >> I like the idea of (an optional?) boolean parameter as a means of hinting at the thing that may terminate the spin. It's probably much more general than identifying a specific field or address. And it can be used to cover cases that poll multiple addresses (an or in the boolean) or look a termination time. If the JVM can track down the boolean's evaluation to dependencies on specific memory state changes, it could pass it on to hardware, if such hardware exists. > > Yep. And there is a user-mode MWAIT in SPARC M7, today. Cool. Didn't know that. So now It's SPARC M7 and ARM v8. Both fairly new, but the pattern of monitoring a single address (or range) and waiting on a potential change to it seems common (and similar to the kernel mode MONITOR/MWAIT in x86). Anything similar coming (or already here) in Power or MIPS? > For Intel, Dave Dice wrote this up: > https://blogs.oracle.com/dave/entry/monitor_mwait_for_spin_loops Cool writeup. But with the current need to transition to kernel mode this may work for loops that want to idle and save power and are willing to sacrifice reaction time to do so. But it is the opposite of what a spinHintLoop() would typically be looking to do. On modern x86, for example, adding a pause instruction improves the reaction speed of the spin loop (see charts attached to JEP), but adding the trapping cost and protection mode transition of a system call to do an MWAIT will almost certainly do the opposite. If/when MONITOR/MWAIT becomes available in user mode, it will join ARM v8 and SPARC M7 in a common useful paradigm. > Also, from a cross-platform POV, a boolean would provide an easy to use "hook" for profiling how often the polling is failing. Failure frequency is an important input to the tuning of spin loops, isn't it? Why not feed that info through to the JVM? I don't follow. Perhaps I'm missing something. Spin loops are "strange" in that they tend to not care about how "fast" they spin, but do care about their reaction time to a change in the thing(s) they are spinning on. I don't think profiling will help here? E.g. in the example tests for this JEP on Ivy Bridge Xeons, adding an intrinsified spinLoopHint() to the a simple spin volatile value loop appears to reduce the "spin throughput" by a significant ratio (3x-5x for L1-sharing threads), but also reduces the reaction time by 35-50%. > ... >> and if/when it does, I'm not sure the semantics of passing the boolean through are enough to cover the actual way to use such hardware when it becomes available. > > The alternative is to have the JIT pattern-match for loop control around the call to Thread.yield. That is obviously less robust than having the user thread the poll condition bit through the poll primitive. I dont' think that's the alternative. The alternative(s) I suggest require no analysis by the JIT: The main means of spin loop hinting I am suggesting is a simple no args hint. [Folks seem to be converging on using Thread as the home for this stuff, so I'll use that]: E.g.: while (!done) { Thread.spinLoopHint(); } The second form I'm suggesting (mostly in reaction to discussion on this thread) directly captures the notion that a single address is being monitored: E.g. volatile boolean done; static final Field doneField = ?; ... Thread.spinExecuteWhileTrue( () -> !done, doneField, this ); // ugly method name I'm not married to... or a slighltly more complicated: Thread.spinExecuteWhileTrue( () -> { count++; return !done;} , doneField, this ); [These Thread.spinExecuteWhileTrue() examples will execute the BooleanSupplier each time, but will only watch the specified field for changes in the spin loop, potentially pausing the loop until a change in the field is detected, but will not pause indefinitely. This can be implemented with a MONITOR/MWAIT, WFE/SEVL, or by just using a PAUSE instruction and not watching the field at all.] (for Java 9, a varhandle variant of the above reflection based model is probably more appropriate. I spelled this with the reflection form for readability by pre-varhandles-speakers). Neither of these forms require any specific JIT matching or exploration. We know the first form is fairly robust on architectures that support stuff like PAUSE. The second form will probably be robust both architectures that support MWAIT or WFE, and on those that support PAUSE (those just won't watch anything). On how this differs from a single boolean parameter: My notion (in the example above) of a single poll variable would be one that specifically designates the poll variable as a field (or maybe array index as an option), rather than provide a boolean parameter that is potentially evaluated based on data read from more than one memory location. The issue is that while it's an easy fit if the boolean is computed based on evaluating a single address, it becomes fragile if multiple addresses are involved and the hardware can only watch one (which is the current trend for ARM v8, SPARC M7, and a potential MONITOR/WAIT x86). It would be "hard" for a JIT to figure out which of the addresses read to compute the bollean should be watched in the spin. And getting it wrong can have potentially surprising consequences (not just lack of benefit, but terribly slow execution due to waiting for something that is not going to be externally modified and timing out each time before spinning). e.g. these probably look good to a programmer: while (!pollSpinExit(done1 || done 2 || (count++ > limit)) { } And it could translate to the following rough mixed pseudo code: SEVL loop: WFE ldaxrh %done1, [done] if (!(%done1 || done2 || (count++ > limit)) goto loop: ? But it could also be translated to: SEVL loop: WFE ldaxrh %done2, [done] if (!(done1 || %done2 || (count++ > limit)) goto loop: ? (or a third option that decides to watch count instead). None of these are "right". And there is nothing in the semantics that suggests which one to expect. You could fall back and say that you would only get the benefit if there is exactly one address used in deriving the boolean, but this would probably make it hard to code to and maintain. A form that forces you to specific the polling parameter would be less generic in expression, but will be less fragile to program to as well, IMO. > >> It is probably premature to design a generic way to provide addresses and/or state to this "spin until something interesting changes" stuff without looking at working examples. A single watched address API is much more likely to fit current implementations without being fragile. >> >> ARM v8's WFE is probably the most real user-mode-accesible thing for this right now (MWAIT isn't real yet, as it's not accessible from user mode). We can look at an example of how a spinloop needs to coordinate the use of WFE, SEVL, and the evaluation of memory location with load exclusive operations here: http://lxr.free-electrons.com/source/arch/arm64/include/asm/spinlock.h . The tricky part is that the SEVL needs to immediately proceed the loop (and all accesses that need to be watched by the WFE), but can't be part of the loop (if were in the loop the WFE would always trigger immediately). But the code in the spinning loop can can only track a single address (the exclusive tag in load exclusive applies only the the most recent address used), so it would be wrong to allow generic code in the spin (it would have to be code that watches exactly one address). >> >> My suspicion is that the "right" way to capture the various ways a spin loop would need to interact with RFE logic will be different than tracking things that can generically affect the value of a boolean. E.g. the evaluation of the boolean could be based on multiple addresses, and since it's not clear (in the API) that this is a problem, the benefits derived would be fragile. > > Having the JIT explore nearby loop structure for memory references is even more fragile. Agreed. Which is why I'm not suggesting it. > If we can agree that (a) there are advantages to profiling the boolean parameter for all platforms, and (b) the single-poll-variable case is likely to be optimizable sooner *with* a parameter than *without*, maybe this is enough to tip the scales towards boolean parameter. I guess that's where we differ: I don't see a benefit in profiling the spin loop, so we disagree on (a). And hence (b) is not relevant? Maybe I'm mis-reading what you mean by "profiling" and "optimizing" above? > The idea would be that programmers would take a little extra thought when using yield(Z)Z, and get paid immediately from good profiling. They would get paid again later if and when platforms analyze data dependencies on the Z. > > If there's no initial payoff, then, yes, it is hard asking programmers to expend extra thought that only benefits on some platforrms. Whatever the choices end up being, we could provide multiple signatures or APIs. E.g. I think that the no-args spinLoopHint() is the de-facto spinning model for x86 and Power (and have been for over a decade for everything outside of Java). So it's a safe bet and a natural form. The spin-execute-something-while-watching-a-single-address model is *probably* a good fit for some relatively young but very useful hardware capabilities, and can probably be captured in a long-lasting API as well. More complicated boolean-derived-from-pretty-much-anything or multi-address watching schemes are IMO too early to evaluate. E.g. they could potentially leverage some just-around-the-corner (or recently arrived) features like TSX and NCAS schemes, but since there is relatively little experience with using such things for spinning (outside of Java), it is probably pre-mature to solidify a Java API for them. BTW, even with user-mode MWAIT and cousins, and with the watch-a-single-address API forms, we may be looking at two separate motivations, and may want to consider a hint of which one is intended. E.g. one of spinLoopHint()'s main drivers is latency improvement, and the other is power reduction (with potential speed benefits or just power savings benefits). It appears that on x86 a PAUSE provides both, so there is no choice needed there. But MWAIT may be much more of a power-centric approach that sacrifices latency, and that may be OK for some and un-OK for others. We may want to have API variants that allow a hint about whether power-reduction or latency-reduction is the preferred driver. > > ? John > From tobias.hartmann at oracle.com Fri Oct 9 07:07:25 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 09 Oct 2015 09:07:25 +0200 Subject: [9] RFR(S): 8139150: ClassVerifier frees exception message while it's still in use In-Reply-To: <56169113.8030300@oracle.com> References: <56168DE0.6060602@oracle.com> <56169113.8030300@oracle.com> Message-ID: <561767AD.6050803@oracle.com> Thanks, Zolt?n! Best, Tobias On 08.10.2015 17:51, Zolt?n Maj? wrote: > Hi Tobias, > > > the fix looks good to me. (I'm not a *R*eviewer.) > > Best regards, > > > Zoltan > > On 10/08/2015 05:38 PM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch. >> >> https://bugs.openjdk.java.net/browse/JDK-8139150 >> http://cr.openjdk.java.net/~thartmann/8139150/webrev.00/ >> >> Problem: >> If class verification fails in StackMapReader::parse_verification_type(), ClassVerifier::class_format_error() is invoked to pass the error message. The method allocates a new string and saves it in ClassVerifier::_message. The problem is that the caller creates a new ResourceMark that leads to _message being deallocated after return. However, later in Verifier::verify() we call ClassVerifier::exception_message() to get the message and pass it on. >> >> Solution: >> We should not create a ResourceMark here. There is a top level ResourceMark in Verifier::verify() that will take care of freeing the memory allocated in ClassVerifier::class_format_error(). >> >> Tested with JPRT and the failing testcase. >> >> Thanks, >> Tobias > From tobias.hartmann at oracle.com Fri Oct 9 07:11:10 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 09 Oct 2015 09:11:10 +0200 Subject: [9] RFR(S): 8139150: ClassVerifier frees exception message while it's still in use In-Reply-To: <5616950B.4050402@oracle.com> References: <56168DE0.6060602@oracle.com> <5616950B.4050402@oracle.com> Message-ID: <5617688E.5040807@oracle.com> Hi Daniel, On 08.10.2015 18:08, Daniel D. Daugherty wrote: > On 10/8/15 9:38 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch. >> >> https://bugs.openjdk.java.net/browse/JDK-8139150 >> http://cr.openjdk.java.net/~thartmann/8139150/webrev.00/ > > src/share/vm/classfile/stackMapTable.cpp > No comments. > > Thumbs up! > > Did a quick audit and I don't see any other calls to > class_format_error() with the same issue. > > This bug is very old. That ResourceMark came from here: > > $ sp -r1.17 src/share/vm/classfile/stackMapTable.cpp > src/share/vm/classfile/SCCS/s.stackMapTable.cpp: > > D 1.17 05/06/20 17:21:50 mingyao 18 17 00015/00008/00446 > MRs: > COMMENTS: > Fixed 6275215, VM fails on StackMapTable jcod tests (VerifyError) > Fixed 6275199, VM fails on StackMapTable jcod tests > Fixed 6275153, VM fails on StackMapTable tests > > And the code looked like this: > > 187a185,194 >> if (offset >= _code_length || >> _code_data[offset] != ClassVerifier::NEW_OFFSET) { >> ResourceMark rm(THREAD); >> Exceptions::fthrow( >> THREAD_AND_LOCATION, >> vmSymbolHandles::java_lang_ClassFormatError(), >> "StackMapTable format error: bad offset for Uninitialized" >> ); >> return NULL; >> } > > > The class_format_error() call came from here: > > D 1.21 06/04/13 11:43:50 km88527 23 22 00064/00108/00360 > MRs: > COMMENTS: > fixed 6402717: Error verifying java.lang.Error causes VM to exit silently due to stack overflow > > and the code changed to look like this: > > if (offset >= _code_length || > _code_data[offset] != ClassVerifier::NEW_OFFSET) { > ResourceMark rm(THREAD); > _verifier->class_format_error( > "StackMapTable format error: bad offset for Uninitialized"); > return NULL; > } Thanks for tracking this down. Seems like the old fix forgot to remove the ResourceMark and for some reason this never showed up. > This fix should probably be backported... but I would > check with Harold... Yes, I think so too. Thanks, Tobias > > Dan > > >> >> Problem: >> If class verification fails in StackMapReader::parse_verification_type(), ClassVerifier::class_format_error() is invoked to pass the error message. The method allocates a new string and saves it in ClassVerifier::_message. The problem is that the caller creates a new ResourceMark that leads to _message being deallocated after return. However, later in Verifier::verify() we call ClassVerifier::exception_message() to get the message and pass it on. >> >> Solution: >> We should not create a ResourceMark here. There is a top level ResourceMark in Verifier::verify() that will take care of freeing the memory allocated in ClassVerifier::class_format_error(). >> >> Tested with JPRT and the failing testcase. >> >> Thanks, >> Tobias > From tobias.hartmann at oracle.com Fri Oct 9 07:12:33 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 09 Oct 2015 09:12:33 +0200 Subject: [9] RFR(S): 8139150: ClassVerifier frees exception message while it's still in use In-Reply-To: <56169720.7020804@oracle.com> References: <56168DE0.6060602@oracle.com> <5616950B.4050402@oracle.com> <56169720.7020804@oracle.com> Message-ID: <561768E1.50407@oracle.com> Hi Harold, thanks for the review. On 08.10.2015 18:17, harold seigel wrote: > I think we should backport the fix to 8u. Okay, I'll push the fix into hs-comp and backport it as soon as it passed nightly testing. Best, Tobias > > Harold > > On 10/8/2015 12:08 PM, Daniel D. Daugherty wrote: >> On 10/8/15 9:38 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8139150 >>> http://cr.openjdk.java.net/~thartmann/8139150/webrev.00/ >> >> src/share/vm/classfile/stackMapTable.cpp >> No comments. >> >> Thumbs up! >> >> Did a quick audit and I don't see any other calls to >> class_format_error() with the same issue. >> >> This bug is very old. That ResourceMark came from here: >> >> $ sp -r1.17 src/share/vm/classfile/stackMapTable.cpp >> src/share/vm/classfile/SCCS/s.stackMapTable.cpp: >> >> D 1.17 05/06/20 17:21:50 mingyao 18 17 00015/00008/00446 >> MRs: >> COMMENTS: >> Fixed 6275215, VM fails on StackMapTable jcod tests (VerifyError) >> Fixed 6275199, VM fails on StackMapTable jcod tests >> Fixed 6275153, VM fails on StackMapTable tests >> >> And the code looked like this: >> >> 187a185,194 >> > if (offset >= _code_length || >> > _code_data[offset] != ClassVerifier::NEW_OFFSET) { >> > ResourceMark rm(THREAD); >> > Exceptions::fthrow( >> > THREAD_AND_LOCATION, >> > vmSymbolHandles::java_lang_ClassFormatError(), >> > "StackMapTable format error: bad offset for Uninitialized" >> > ); >> > return NULL; >> > } >> >> >> The class_format_error() call came from here: >> >> D 1.21 06/04/13 11:43:50 km88527 23 22 00064/00108/00360 >> MRs: >> COMMENTS: >> fixed 6402717: Error verifying java.lang.Error causes VM to exit silently due to stack overflow >> >> and the code changed to look like this: >> >> if (offset >= _code_length || >> _code_data[offset] != ClassVerifier::NEW_OFFSET) { >> ResourceMark rm(THREAD); >> _verifier->class_format_error( >> "StackMapTable format error: bad offset for Uninitialized"); >> return NULL; >> } >> >> This fix should probably be backported... but I would >> check with Harold... >> >> Dan >> >> >>> >>> Problem: >>> If class verification fails in StackMapReader::parse_verification_type(), ClassVerifier::class_format_error() is invoked to pass the error message. The method allocates a new string and saves it in ClassVerifier::_message. The problem is that the caller creates a new ResourceMark that leads to _message being deallocated after return. However, later in Verifier::verify() we call ClassVerifier::exception_message() to get the message and pass it on. >>> >>> Solution: >>> We should not create a ResourceMark here. There is a top level ResourceMark in Verifier::verify() that will take care of freeing the memory allocated in ClassVerifier::class_format_error(). >>> >>> Tested with JPRT and the failing testcase. >>> >>> Thanks, >>> Tobias >> > From mikael.gerdin at oracle.com Fri Oct 9 07:47:43 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 9 Oct 2015 09:47:43 +0200 Subject: RFR (XS) 8139086: Solaris/Sparc slowdebug build fails for memset_with_concurrent_readers.cpp In-Reply-To: <5616A731.30200@oracle.com> References: <5616620B.6020606@oracle.com> <77CD18C8-E241-4933-89EA-7347E672C0FC@oracle.com> <5616A731.30200@oracle.com> Message-ID: <5617711F.5040800@oracle.com> Thanks for the speedy reviews, the fix is in the queue for hs-rt now. On 2015-10-08 19:26, Coleen Phillimore wrote: > > > On 10/8/15 12:37 PM, Kim Barrett wrote: >> On Oct 8, 2015, at 8:31 AM, Mikael Gerdin >> wrote: >>> Hi all, >>> >>> We recently discovered that slowdebug builds fail on Solaris/SPARC >>> due to an issue with inline assembly in >>> memset_with_concurrent_readers_sparc.cpp >>> >>> After discussions with the C++ compiler team at Oracle it was pointed >>> out to us that the code was incorrect in that it had too few %'s. >>> >>> Actual registers referenced by name must be escaped with %% but it >>> appears that enabling optimization in the Studio compiler disregards >>> that requirement. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8139086 >>> Webrev: http://cr.openjdk.java.net/~mgerdin/8139086/webrev/ >>> >>> Testing: Building product|fastdebug|slowdebug on Solaris/SPARC. >> Looks good. Thanks for taking care of this so quickly. > > +1 > > I really appreciate it! No problem! /Mikael > Coleen >> > From david.lindholm at oracle.com Fri Oct 9 07:46:25 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Fri, 9 Oct 2015 09:46:25 +0200 Subject: 8042893 and 8042894: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <4295855A5C1DE049A61835A1887419CC41E80E1D@DEWDFEMB12A.global.corp.sap> References: <56153CA4.2050008@oracle.com> <4295855A5C1DE049A61835A1887419CC41E80E1D@DEWDFEMB12A.global.corp.sap> Message-ID: <561770D1.8040709@oracle.com> Goetz, Thanks for the review! /David On 2015-10-08 08:50, Lindenmaier, Goetz wrote: > Hi David, > > thanks for doing all these changes and incorporating my > pre-RFR input. > > The change looks good. > > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of David Lindholm > Sent: Mittwoch, 7. Oktober 2015 17:39 > To: hotspot-dev at openjdk.java.net > Subject: RFR: 8042893 and 8042894: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files > > Hi, > > Please review the following patch that removes > PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC from all source files in HotSpot. It > also fixes all compiler warnings caused by format strings that were > previously silenced by this pragma. > > This patch is a joint effort by me and Goetz Lindenmaier. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8042893 > Bug: https://bugs.openjdk.java.net/browse/JDK-8042894 > Webrev: http://cr.openjdk.java.net/~david/JDK-8042893-8042894/webrev.00/ > > Testing: Passed JPRT > > > Thanks, > David From david.lindholm at oracle.com Fri Oct 9 07:46:52 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Fri, 9 Oct 2015 09:46:52 +0200 Subject: RFR: 8042893 and 8042894: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files In-Reply-To: <561613F2.3060203@oracle.com> References: <56153CA4.2050008@oracle.com> <561613F2.3060203@oracle.com> Message-ID: <561770EC.6020905@oracle.com> Bengt, Thanks for the review! /David On 2015-10-08 08:57, Bengt Rutisson wrote: > > Hi David, > > Nice cleanup! Thanks for doing this! > > On 2015-10-07 17:39, David Lindholm wrote: >> Hi, >> >> Please review the following patch that removes >> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC from all source files in HotSpot. >> It also fixes all compiler warnings caused by format strings that >> were previously silenced by this pragma. >> >> This patch is a joint effort by me and Goetz Lindenmaier. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8042893 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8042894 >> Webrev: http://cr.openjdk.java.net/~david/JDK-8042893-8042894/webrev.00/ > > I've browsed the webrev. All changes that I looked closer at looks > good and I with all the PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC gone and > it still compiles I think it should be fine. > > Looks good. > > Bengt > >> >> Testing: Passed JPRT >> >> >> Thanks, >> David > From erik.helin at oracle.com Fri Oct 9 08:35:26 2015 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 9 Oct 2015 10:35:26 +0200 Subject: RFR: 8139256: Add Makefile target to run internal VM tests Message-ID: <20151009083526.GT14241@ehelin.jrpg.bea.com> Hi all, this small patch add a new top-level Makefile target: test-hotspot-internal. The target is just an easier way to run the unit tests in hotspot (the ones you execute by using the flag -XX:+ExecuteInternalVMTests). Enhancement: https://bugs.openjdk.java.net/browse/JDK-8139256 Webrev: - root: http://cr.openjdk.java.net/~ehelin/8139256/root/webrev.00/ - hotspot: http://cr.openjdk.java.net/~ehelin/8139256/hotspot/webrev.00/ Thanks, Erik From erik.joelsson at oracle.com Fri Oct 9 09:39:39 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 9 Oct 2015 11:39:39 +0200 Subject: RFR: 8139256: Add Makefile target to run internal VM tests In-Reply-To: <20151009083526.GT14241@ehelin.jrpg.bea.com> References: <20151009083526.GT14241@ehelin.jrpg.bea.com> Message-ID: <56178B5B.7030708@oracle.com> Looks good to me. /Erik On 2015-10-09 10:35, Erik Helin wrote: > Hi all, > > this small patch add a new top-level Makefile target: > test-hotspot-internal. The target is just an easier way to run the unit > tests in hotspot (the ones you execute by using the flag > -XX:+ExecuteInternalVMTests). > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8139256 > > Webrev: > - root: > http://cr.openjdk.java.net/~ehelin/8139256/root/webrev.00/ > - hotspot: > http://cr.openjdk.java.net/~ehelin/8139256/hotspot/webrev.00/ > > Thanks, > Erik From magnus.ihse.bursie at oracle.com Fri Oct 9 10:42:12 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 9 Oct 2015 12:42:12 +0200 Subject: RFR: 8139256: Add Makefile target to run internal VM tests In-Reply-To: <20151009083526.GT14241@ehelin.jrpg.bea.com> References: <20151009083526.GT14241@ehelin.jrpg.bea.com> Message-ID: <56179A04.6090404@oracle.com> On 2015-10-09 10:35, Erik Helin wrote: > Hi all, > > this small patch add a new top-level Makefile target: > test-hotspot-internal. The target is just an easier way to run the unit > tests in hotspot (the ones you execute by using the flag > -XX:+ExecuteInternalVMTests). > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8139256 > > Webrev: > - root: > http://cr.openjdk.java.net/~ehelin/8139256/root/webrev.00/ > - hotspot: > http://cr.openjdk.java.net/~ehelin/8139256/hotspot/webrev.00/ Looks good to me. /Magnus From erik.helin at oracle.com Fri Oct 9 12:09:47 2015 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 9 Oct 2015 14:09:47 +0200 Subject: RFR: 8139272: Add configure variable to set concurrency for jtreg tests Message-ID: <20151009120947.GU14241@ehelin.jrpg.bea.com> Hi all, this patch adds a new configure variable: --with-test-jobs. The new variable configures how many tests jobs we run concurrently (aka the -concurrency flag to JTReg). Today --with-jobs is passed as the -concurrency flag to JTReg which most likely is too big for most systems with many cores. For hotspot, the only "supported" configuration for running the jtreg tests is with -concurrency:1. However, most machines will run the tests successfully with more concurrency, but I used a default of 1. For the JDK tests I kept --with-jobs as the default concurrency since I want to keep the old behaviour. Enhancement: https://bugs.openjdk.java.net/browse/JDK-8139272 Webrev: http://cr.openjdk.java.net/~ehelin/8139272/webrev.00/ Thanks, Erik From erik.helin at oracle.com Fri Oct 9 12:23:44 2015 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 9 Oct 2015 14:23:44 +0200 Subject: RFR: 8139271: Add top-level Makefile target to run hotspots jtreg tests Message-ID: <20151009122344.GV14241@ehelin.jrpg.bea.com> Hi all, this patch adds a new top-level Makefile to run the hotspot jtreg tests. This is already possible today by running: $ make test TEST="hotspot_all" The new target, test-hotspot-jtreg, is a bit more discoverable in my opinion (will also work with tab completion in supported shells). Enhancement: https://bugs.openjdk.java.net/browse/JDK-8139271 Webrev: http://cr.openjdk.java.net/~ehelin/8139271/webrev.00/ Thanks, Erik From erik.helin at oracle.com Fri Oct 9 12:27:32 2015 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 9 Oct 2015 14:27:32 +0200 Subject: RFR: 8139256: Add Makefile target to run internal VM tests In-Reply-To: <56179A04.6090404@oracle.com> References: <20151009083526.GT14241@ehelin.jrpg.bea.com> <56179A04.6090404@oracle.com> Message-ID: <20151009122732.GW14241@ehelin.jrpg.bea.com> On 2015-10-09, Magnus Ihse Bursie wrote: > On 2015-10-09 10:35, Erik Helin wrote: > >Hi all, > > > >this small patch add a new top-level Makefile target: > >test-hotspot-internal. The target is just an easier way to run the unit > >tests in hotspot (the ones you execute by using the flag > >-XX:+ExecuteInternalVMTests). > > > >Enhancement: > >https://bugs.openjdk.java.net/browse/JDK-8139256 > > > >Webrev: > >- root: > > http://cr.openjdk.java.net/~ehelin/8139256/root/webrev.00/ > >- hotspot: > > http://cr.openjdk.java.net/~ehelin/8139256/hotspot/webrev.00/ > > Looks good to me. Thanks! Erik > /Magnus From erik.helin at oracle.com Fri Oct 9 12:27:49 2015 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 9 Oct 2015 14:27:49 +0200 Subject: RFR: 8139256: Add Makefile target to run internal VM tests In-Reply-To: <56178B5B.7030708@oracle.com> References: <20151009083526.GT14241@ehelin.jrpg.bea.com> <56178B5B.7030708@oracle.com> Message-ID: <20151009122749.GX14241@ehelin.jrpg.bea.com> On 2015-10-09, Erik Joelsson wrote: > Looks good to me. Thanks! Erik > /Erik > > On 2015-10-09 10:35, Erik Helin wrote: > >Hi all, > > > >this small patch add a new top-level Makefile target: > >test-hotspot-internal. The target is just an easier way to run the unit > >tests in hotspot (the ones you execute by using the flag > >-XX:+ExecuteInternalVMTests). > > > >Enhancement: > >https://bugs.openjdk.java.net/browse/JDK-8139256 > > > >Webrev: > >- root: > > http://cr.openjdk.java.net/~ehelin/8139256/root/webrev.00/ > >- hotspot: > > http://cr.openjdk.java.net/~ehelin/8139256/hotspot/webrev.00/ > > > >Thanks, > >Erik > From erik.joelsson at oracle.com Fri Oct 9 12:56:05 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 9 Oct 2015 14:56:05 +0200 Subject: RFR: 8139271: Add top-level Makefile target to run hotspots jtreg tests In-Reply-To: <20151009122344.GV14241@ehelin.jrpg.bea.com> References: <20151009122344.GV14241@ehelin.jrpg.bea.com> Message-ID: <5617B965.7080805@oracle.com> Looks good to me. /Erik On 2015-10-09 14:23, Erik Helin wrote: > Hi all, > > this patch adds a new top-level Makefile to run the hotspot jtreg tests. > This is already possible today by running: > $ make test TEST="hotspot_all" > > The new target, test-hotspot-jtreg, is a bit more discoverable in my > opinion (will also work with tab completion in supported shells). > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8139271 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8139271/webrev.00/ > > Thanks, > Erik From stefan.karlsson at oracle.com Fri Oct 9 15:40:28 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 9 Oct 2015 17:40:28 +0200 Subject: RFR: 8138659: Speed up InstanceKlass subclass discrimination In-Reply-To: <294721F8-D7E7-4FB5-9CC7-39C984EC87F0@oracle.com> References: <5612D757.5040905@oracle.com> <5422E78A-5321-406D-9997-7A19BB4A4ABD@oracle.com> <294721F8-D7E7-4FB5-9CC7-39C984EC87F0@oracle.com> Message-ID: <5617DFEC.3090706@oracle.com> Hi Kim, On 2015-10-07 18:02, Kim Barrett wrote: > Another round, with some name changes that resulted from discussion > with StefanK and Coleen. Also, Coleen convinced me some functions > weren't needed. > > New full and incremental webrevs: > http://cr.openjdk.java.net/~kbarrett/8138659/webrev.02/ > http://cr.openjdk.java.net/~kbarrett/8138659/webrev.02.inc/ Looks OK. Reviewed. As we've discussed offline, this patch changes the type-checking functions from: Klass::oop_is_instance() Klass::oop_is_array() Klass::oop_is_objArray() Klass::oop_is_typeArray() Klass::oop_is_instanceMirror() Klass::oop_is_instanceClassLoader() Klass::oop_is_instanceRef() to: Klass::oop_is_instance() Klass::oop_is_array() Klass::oop_is_objArray() Klass::oop_is_typeArray() InstanceKlass::is_mirror_instance_klass() InstanceKlass::is_class_loader_instance_klass() InstanceKlass::is_reference_instance_klass() InstanceKlass::is_other_instance_klass() I would prefer if we could rename the first four functions to: Klass::is_instance_klass() Klass::is_array() Klass::is_obj_array_klass() Klass::is_type_array_klass() InstanceKlass::is_instance_mirror_klass() InstanceKlass::is_instance_class_loader_klass() InstanceKlass::is_instance_ref_klass() InstanceKlass::is_instance_other_klass() to keep a slightly more consistent naming scheme. But this should be done as a separate RFE. Thanks, StefanK > From kim.barrett at oracle.com Fri Oct 9 16:22:43 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 9 Oct 2015 12:22:43 -0400 Subject: RFR: 8138659: Speed up InstanceKlass subclass discrimination In-Reply-To: <5617DFEC.3090706@oracle.com> References: <5612D757.5040905@oracle.com> <5422E78A-5321-406D-9997-7A19BB4A4ABD@oracle.com> <294721F8-D7E7-4FB5-9CC7-39C984EC87F0@oracle.com> <5617DFEC.3090706@oracle.com> Message-ID: On Oct 9, 2015, at 11:40 AM, Stefan Karlsson wrote: > > Hi Kim, > > On 2015-10-07 18:02, Kim Barrett wrote: >> Another round, with some name changes that resulted from discussion >> with StefanK and Coleen. Also, Coleen convinced me some functions >> weren't needed. >> >> New full and incremental webrevs: >> http://cr.openjdk.java.net/~kbarrett/8138659/webrev.02/ >> http://cr.openjdk.java.net/~kbarrett/8138659/webrev.02.inc/ > > Looks OK. Reviewed. Thanks. > As we've discussed offline, this patch changes the type-checking functions from: > [?] > to: > [?] > I would prefer if we could rename the first four functions to: > [?] > to keep a slightly more consistent naming scheme. But this should be done as a separate RFE. https://bugs.openjdk.java.net/browse/JDK-8139203 From haim at performize-it.com Fri Oct 9 15:34:02 2015 From: haim at performize-it.com (Haim Yadid) Date: Fri, 9 Oct 2015 18:34:02 +0300 Subject: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal In-Reply-To: <5616841C.6000406@cs.oswego.edu> References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561428BC.3060806@cs.oswego.edu> <015C733F-130A-47C0-8F68-1CBB11CC0C38@azulsystems.com> <56164C3C.4050800@cs.oswego.edu> <56164D1F.405@redhat.com> <5616841C.6000406@cs.oswego.edu> Message-ID: <902D73C6-8BDA-4FCD-BEE8-EA10808B3B28@performize-it.com> +1 as well :) BR, Haim Yadid > On 8 ????? 2015, at 17:56, Doug Lea

wrote: > >> On 10/08/2015 07:01 AM, David M. Lloyd wrote: >>> On 10/08/2015 05:58 AM, Doug Lea wrote: >>> >>> class Thread { // >>> /** >>> * A hint to the platform that the current thread is momentarily >>> * unable to progress. ... add more guidance ... >>> */ >>> void spinYield(); > > should be: > public static void spinYield(); > >>> } >>> >>> In principle, this would also allow the implementation to do an actual >>> yield on uniprocessors or when the load average is high. Probably not >>> in initial implementation though. >>> >>> Adding a method to class Thread risks name clashes with existing >>> methods introduced in subclasses. So this might need a clunkier name >>> to effectively eliminate the possibility. >> >> If the method is static, then the impact of a clashing name should be fairly >> minimal. > > Right. For statics, pretty much the only concern is whether > reflective mechanics (Class.getMethod etc) return unexpected > entries that would break existing code. The name "spinYield" > seems unlikely enough to be a problem though. > > -Doug > > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest From david.buck at oracle.com Thu Oct 8 07:07:38 2015 From: david.buck at oracle.com (David Buck) Date: Thu, 8 Oct 2015 16:07:38 +0900 Subject: [8u] Request for approval and review: 8075805: Crash while trying to release CompiledICHolder In-Reply-To: <56161410.4080207@oracle.com> References: <5614F37E.8090208@oracle.com> <56151368.3030405@oracle.com> <56152A04.8040006@oracle.com> <56152AD1.6040600@oracle.com> <56161410.4080207@oracle.com> Message-ID: Yes, I also approve JDK-8058737 for backport to jdk8u-dev. Cheers, -Buck > On Oct 8, 2015, at 15:58, Tobias Hartmann wrote: > > Thanks, Vladimir. > > David, are you fine with backporting JDK-8058737 as well? > > Best, > Tobias > > On 07.10.2015 16:23, Vladimir Kozlov wrote: >> Nice. Looks good. >> >> Thanks, >> Vladimir >> >> On 10/7/15 10:19 PM, Tobias Hartmann wrote: >>> Hi Vladimir, >>> >>> On 07.10.2015 14:43, Vladimir Kozlov wrote: >>>> Changes are matching jdk9 changes. >>>> Tobias, should we backport 8058737 changes too? Next code is missing in 8u now: >>>> >>>> + MutexLocker cl(CompiledIC_lock); >>>> + nm->clear_ic_stubs(); >>>> >>>> It was P2. Why we did not backport it? >>> >>> Yes, you are right. It seems like I missed to backport that one because it never showed up with 8. However, we should backport it. The patch for JDK-8058737 applies cleanly. I updated the other webrevs: >>> >>> JDK-8058737: CodeCache::find_blob fails with 'unsafe access to zombie method' >>> https://bugs.openjdk.java.net/browse/JDK-8058737 >>> http://cr.openjdk.java.net/~thartmann/8058737/webrev.01/ >>> >>> JDK-8075805: Crash while trying to release CompiledICHolder >>> https://bugs.openjdk.java.net/browse/JDK-8075805 >>> http://cr.openjdk.java.net/~thartmann/8075805_8u/webrev.01/ >>> >>> JDK-8134493: Cleaning inline caches of unloaded nmethods should be done in sweeper >>> https://bugs.openjdk.java.net/browse/JDK-8134493 >>> http://cr.openjdk.java.net/~thartmann/8134493_8u/webrev.01/ >>> >>> All changes (now also including 8058737) : >>> http://cr.openjdk.java.net/~thartmann/8075805_8134493_8u/webrev.01 >>> >>> Thanks, >>> Tobias >>> >>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/7/15 6:27 PM, Tobias Hartmann wrote: >>>>> Hi, >>>>> >>>>> please approve and review the following backport to 8u. >>>>> >>>>> 8075805: Crash while trying to release CompiledICHolder >>>>> https://bugs.openjdk.java.net/browse/JDK-8075805 >>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c0ea5537dc8b >>>>> http://cr.openjdk.java.net/~thartmann/8075805/webrev.01/ >>>>> >>>>> I would also like to backport this follow up change that fixes an issue with the fix for 8075805: >>>>> >>>>> 8134493: Cleaning inline caches of unloaded nmethods should be done in sweeper >>>>> https://bugs.openjdk.java.net/browse/JDK-8134493 >>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9df4555d2d7d >>>>> http://cr.openjdk.java.net/~thartmann/8134493/webrev.01/ >>>>> >>>>> Unfortunately, both changesets do not apply cleanly to 8u. I merged the fixes, here are the new webrevs: >>>>> >>>>> JDK-8075805: >>>>> http://cr.openjdk.java.net/~thartmann/8075805_8u/webrev.00/ >>>>> >>>>> JDK-8134493 (incremental): >>>>> http://cr.openjdk.java.net/~thartmann/8134493_8u/webrev.00/ >>>>> >>>>> Both changes: >>>>> http://cr.openjdk.java.net/~thartmann/8075805_8134493_8u/webrev.00/ >>>>> >>>>> Both fixes were pushed some months ago and testing showed no problems. >>>>> >>>>> Thanks, >>>>> Tobias >>>>> From magnus.ihse.bursie at oracle.com Fri Oct 9 17:56:23 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 9 Oct 2015 19:56:23 +0200 Subject: RFR: 8139271: Add top-level Makefile target to run hotspots jtreg tests In-Reply-To: <20151009122344.GV14241@ehelin.jrpg.bea.com> References: <20151009122344.GV14241@ehelin.jrpg.bea.com> Message-ID: Looks good to me. /Magnus > 9 okt 2015 kl. 14:23 skrev Erik Helin : > > Hi all, > > this patch adds a new top-level Makefile to run the hotspot jtreg tests. > This is already possible today by running: > $ make test TEST="hotspot_all" > > The new target, test-hotspot-jtreg, is a bit more discoverable in my > opinion (will also work with tab completion in supported shells). > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8139271 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8139271/webrev.00/ > > Thanks, > Erik From john.r.rose at oracle.com Fri Oct 9 21:32:01 2015 From: john.r.rose at oracle.com (John Rose) Date: Fri, 9 Oct 2015 14:32:01 -0700 Subject: Spin Loop Hint support: Draft JEP proposal In-Reply-To: References: <5932C61D-C9D8-493D-9E2F-2C7965398C41@azulsystems.com> <561245E0.8030708@redhat.com> <38110705-2789-4050-913C-0568DD8B61E9@oracle.com>

Message-ID: On Oct 8, 2015, at 11:56 PM, Gil Tene wrote: > >> >> On Oct 8, 2015, at 6:18 PM, John Rose wrote: >> >> On Oct 8, 2015, at 12:39 AM, Gil Tene