From aph at redhat.com Thu Oct 1 10:27:46 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 1 Oct 2015 11:27:46 +0100 Subject: CSE, loops, and array accesses Message-ID: <560D0AA2.6000200@redhat.com> I'm looking at a failure to CSE the array base offset in this loop: for (int i = 0; i < array.length; i++) { res += array[i]; } ;; B2: # B2 B3 <- B1 B2 Loop: B2-B2 inner Freq: 100.958 0x000003ff9d1a1a30: add xscratch1, x10, #0x10 0x000003ff9d1a1a34: ldr w13, [xscratch1,w11,sxtw #2] 0x000003ff9d1a1a38: add w11, w11, #0x1 ;*iinc ; - tests.ScalarReduce::test1 at 20 (line 22) 0x000003ff9d1a1a3c: add w0, w0, w13 ;*iadd ; - tests.ScalarReduce::test1 at 18 (line 23) 0x000003ff9d1a1a40: cmp w11, #0x64 0x000003ff9d1a1a44: b.lt 0x000003ff9d1a1a30 ;*if_icmpge ; - tests.ScalarReduce::test1 at 9 (line 22) The odd thing is that if I use Unsafe it's fine: for (int i = 0; i < array.length; i++) { long address = (((long) i) << 2) + base; res += UNSAFE.getInt(array, address); } ;; B2: # B2 B3 <- B1 B2 Loop: B2-B2 inner Freq: 101.004 0x000003ff8d1a16c0: ldr w13, [x10,w11,sxtw #2] 0x000003ff8d1a16c4: add w11, w11, #0x1 ;*iinc ; - tests.Tests::test1 at 34 (line 22) 0x000003ff8d1a16c8: add w0, w0, w13 ;*iadd ; - tests.Tests::test1 at 32 (line 24) 0x000003ff8d1a16cc: cmp w11, #0x64 0x000003ff8d1a16d0: b.lt 0x000003ff8d1a16c0 ;*if_icmpge So, something somewhere in the compiler is preventing the array base offset from being detached from the actual memory access. I can understand why this is desirable on x86 where we have instructions which can do base+offset+index, but I don't understand why CSE works with Unsafe but not actual arrays. Note that I had to disable unrolling to demonstrate this simple test case. So, why are arrays treated differently? Thanks, Andrew. $ java -XX:-TieredCompilation -XX:LoopMaxUnroll=1 -Xbootclasspath/a:/home/aph/NetBeansProjects/Tests/build/classes/ tests/ScalarReduce package tests; import sun.misc.Unsafe; /** * * @author aph */ public class Tests { private static final Unsafe UNSAFE = Unsafe.getUnsafe(); static final int[] array = new int[100]; static long base = UNSAFE.arrayBaseOffset(array.getClass()); static int test1() { int res = 0; for (int i = 0; i < array.length; i++) { long address = (((long) i) << 2) + base; res += UNSAFE.getInt(array, address); } return res; } /** * @param args the command line arguments */ public static void main(String[] args) { long foo = 0; for (int i = 0; i < 10000000; i++) foo += test1(); if (foo != 0) System.out.println(""); } } From nils.eliasson at oracle.com Thu Oct 1 11:47:22 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 1 Oct 2015 13:47:22 +0200 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: References: <56018E2B.2000108@oracle.com> <56055B50.4040304@oracle.com> Message-ID: <560D1D4A.8030001@oracle.com> Hi Roland, On 2015-09-28 12:02, Roland Westrelin wrote: > Hi Nils, > >> http://cr.openjdk.java.net/~neliasso/8046155/webrev.03/ > What does CompileCommandCompatibility do? Control backwards compatibility with CompileCommand for testing purposes. I 'll change the name to the moee descriptive CompilerDirectivesIgnoreCompileCommands (default false). > > vm_operations.cpp > > Is that extra include really needed? No, removed. > > CompilerQueueTest.java > > Is that extra import really needed? No, removed. > > block.hpp > > You don?t need that ciEnv here, right? No, left over from when the directives was stored in the viEnv. > > compileBroker.cpp > > 1717 should_break = dirset->BreakAtExecuteOption || task->check_break_at_flags(); > > doesn?t seem to be used > > Except for those minor issues, looks good to me. Fixed. > > >> - Won't build c1 only or shark only. > You can?t push if c1 only doesn?t build, right? It was just a temporary glitch that is fixed now. Thanks, Nils > > Roland. From edward.nevill at gmail.com Thu Oct 1 13:00:59 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 01 Oct 2015 14:00:59 +0100 Subject: CSE, loops, and array accesses In-Reply-To: <560D0AA2.6000200@redhat.com> References: <560D0AA2.6000200@redhat.com> Message-ID: <1443704459.5907.3.camel@mylittlepony.linaroharston> On Thu, 2015-10-01 at 11:27 +0100, Andrew Haley wrote: > I'm looking at a failure to CSE the array base offset in this loop: > > for (int i = 0; i < array.length; i++) { > res += array[i]; > } > > ;; B2: # B2 B3 <- B1 B2 Loop: B2-B2 inner Freq: 100.958 > > 0x000003ff9d1a1a30: add xscratch1, x10, #0x10 > 0x000003ff9d1a1a34: ldr w13, [xscratch1,w11,sxtw #2] > 0x000003ff9d1a1a38: add w11, w11, #0x1 ;*iinc > ; - tests.ScalarReduce::test1 at 20 (line 22) > > 0x000003ff9d1a1a3c: add w0, w0, w13 ;*iadd > ; - tests.ScalarReduce::test1 at 18 (line 23) > > 0x000003ff9d1a1a40: cmp w11, #0x64 > 0x000003ff9d1a1a44: b.lt 0x000003ff9d1a1a30 ;*if_icmpge > ; - tests.ScalarReduce::test1 at 9 (line 22) The reason it does not do the loop invariant lifting is because of the following transformation in AddPNode::Ideal in addnode.cpp // Else move the constant to the right. ((A+con)+B) into ((A+B)+con) address = phase->transform(new (phase->C) AddPNode(in(Base),addp->in(Address),in(Offset))); offset = addp->in(Offset); So, once it has transformed ((A+con)+B) into ((A+B)+con) all bets are off, we can never CSE/Loop invariant lift. Try the following patch, it should generate the code you want. All the best, Ed. --- CUT HERE --- diff -r fa430fa4f577 src/share/vm/opto/addnode.cpp --- a/src/share/vm/opto/addnode.cpp Wed Sep 23 12:39:30 2015 -0400 +++ b/src/share/vm/opto/addnode.cpp Thu Oct 01 12:59:19 2015 +0000 @@ -592,20 +592,16 @@ // The Add of the flattened expression address = addp->in(Address); offset = phase->MakeConX(t2->get_con() + t12->get_con()); - } else { - // Else move the constant to the right. ((A+con)+B) into ((A+B)+con) - address = phase->transform(new AddPNode(in(Base),addp->in(Address),in(Offset))); - offset = addp->in(Offset); + PhaseIterGVN *igvn = phase->is_IterGVN(); + if( igvn ) { + set_req_X(Address,address,igvn); + set_req_X(Offset,offset,igvn); + } else { + set_req(Address,address); + set_req(Offset,offset); + } + return this; } - PhaseIterGVN *igvn = phase->is_IterGVN(); - if( igvn ) { - set_req_X(Address,address,igvn); - set_req_X(Offset,offset,igvn); - } else { - set_req(Address,address); - set_req(Offset,offset); - } - return this; } } --- CUT HERE --- From aph at redhat.com Thu Oct 1 13:19:55 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 1 Oct 2015 14:19:55 +0100 Subject: CSE, loops, and array accesses In-Reply-To: <1443704459.5907.3.camel@mylittlepony.linaroharston> References: <560D0AA2.6000200@redhat.com> <1443704459.5907.3.camel@mylittlepony.linaroharston> Message-ID: <560D32FB.7090201@redhat.com> On 10/01/2015 02:00 PM, Edward Nevill wrote: > Try the following patch, it should generate the code you want. OK, so perhaps the question is how to fix this in the form of a patch which can go into JDK9. But there is a deeper question: why is ((A+B)+con) so tightly bound that the constant add can never be CSE'd? I guess there is some special-case code somewhere which detects address this case. Speculating, perhaps the real reason for this is loops with safepoints. Andrew. From edward.nevill at gmail.com Thu Oct 1 13:36:32 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 01 Oct 2015 14:36:32 +0100 Subject: CSE, loops, and array accesses In-Reply-To: <560D32FB.7090201@redhat.com> References: <560D0AA2.6000200@redhat.com> <1443704459.5907.3.camel@mylittlepony.linaroharston> <560D32FB.7090201@redhat.com> Message-ID: <1443706592.5907.11.camel@mylittlepony.linaroharston> On Thu, 2015-10-01 at 14:19 +0100, Andrew Haley wrote: > On 10/01/2015 02:00 PM, Edward Nevill wrote: > > Try the following patch, it should generate the code you want. > > OK, so perhaps the question is how to fix this in the form of a patch > which can go into JDK9. > > But there is a deeper question: why is ((A+B)+con) so tightly bound > that the constant add can never be CSE'd? I guess there is some > special-case code somewhere which detects address this case. I guess the reason for rewriting ((A+con)+B) to ((A+B)+con) is to match Intel's complex addressing mode [reg + reg< References: <56018E2B.2000108@oracle.com> <56055B50.4040304@oracle.com> <560D1D4A.8030001@oracle.com> Message-ID: Hi Nils, I've just found another problem with the IGV. After your changes it will crash because you changed IdealGraphPrinter::should_print() to use "C->dirset()->IGVPrintLevelOption >= level" but at the call sites where should_print() is used the Compiler field of the IGV printer isn't initialized. The quick hack attached below, which always passes the compiler object to should_print() fixes the problem, but may you can up with something better? And what about the InlineMatcherTest.java which I've already objected in my previous mail. It still doesn't seem to work. How is it supposed to be executed? Regards, Volker diff -r 6fba102266ad src/share/vm/opto/compile.cpp --- a/src/share/vm/opto/compile.cpp Thu Oct 01 16:24:12 2015 +0200 +++ b/src/share/vm/opto/compile.cpp Thu Oct 01 16:40:46 2015 +0200 @@ -838,7 +838,7 @@ // Drain the list. Finish_Warm(); #ifndef PRODUCT - if (_printer && _printer->should_print(1)) { + if (_printer && _printer->should_print(C, 1)) { _printer->print_inlining(this); } #endif diff -r 6fba102266ad src/share/vm/opto/compile.hpp --- a/src/share/vm/opto/compile.hpp Thu Oct 01 16:24:12 2015 +0200 +++ b/src/share/vm/opto/compile.hpp Thu Oct 01 16:40:46 2015 +0200 @@ -691,7 +691,7 @@ void begin_method() { #ifndef PRODUCT - if (_printer && _printer->should_print(1)) { + if (_printer && _printer->should_print(C, 1)) { _printer->begin_method(this); } #endif @@ -710,7 +710,7 @@ #ifndef PRODUCT - if (_printer && _printer->should_print(level)) { + if (_printer && _printer->should_print(C, level)) { _printer->print_method(this, CompilerPhaseTypeHelper::to_string(cpt), level); } #endif @@ -727,7 +727,7 @@ event.commit(); } #ifndef PRODUCT - if (_printer && _printer->should_print(level)) { + if (_printer && _printer->should_print(C, level)) { _printer->end_method(); } #endif diff -r 6fba102266ad src/share/vm/opto/idealGraphPrinter.cpp --- a/src/share/vm/opto/idealGraphPrinter.cpp Thu Oct 01 16:24:12 2015 +0200 +++ b/src/share/vm/opto/idealGraphPrinter.cpp Thu Oct 01 16:40:46 2015 +0200 @@ -669,7 +669,7 @@ // Print current ideal graph void IdealGraphPrinter::print(Compile* compile, const char *name, Node *node, int level, bool clear_nodes) { - if (!_current_method || !_should_send_method || !should_print(level)) return; + if (!_current_method || !_should_send_method || !should_print(compile, level)) return; this->C = compile; @@ -722,8 +722,8 @@ } // Should method be printed? -bool IdealGraphPrinter::should_print(int level) { - return C->dirset()->IGVPrintLevelOption >= level; +bool IdealGraphPrinter::should_print(Compile* compile, int level) { + return compile->dirset()->IGVPrintLevelOption >= level; } extern const char *NodeClassNames[]; diff -r 6fba102266ad src/share/vm/opto/idealGraphPrinter.hpp --- a/src/share/vm/opto/idealGraphPrinter.hpp Thu Oct 01 16:24:12 2015 +0200 +++ b/src/share/vm/opto/idealGraphPrinter.hpp Thu Oct 01 16:40:46 2015 +0200 @@ -133,7 +133,7 @@ void print_method(Compile* compile, const char *name, int level=1, bool clear_nodes = false); void print(Compile* compile, const char *name, Node *root, int level=1, bool clear_nodes = false); void print_xml(const char *name); - bool should_print(int level); + bool should_print(Compile* compile, int level); }; #endif diff -r 6fba102266ad src/share/vm/opto/parse2.cpp --- a/src/share/vm/opto/parse2.cpp Thu Oct 01 16:24:12 2015 +0200 +++ b/src/share/vm/opto/parse2.cpp Thu Oct 01 16:40:46 2015 +0200 @@ -2379,7 +2379,7 @@ #ifndef PRODUCT IdealGraphPrinter *printer = IdealGraphPrinter::printer(); - if (printer && printer->should_print(1)) { + if (printer && printer->should_print(C, 1)) { char buffer[256]; sprintf(buffer, "Bytecode %d: %s", bci(), Bytecodes::name(bc())); bool old = printer->traverse_outs(); On Thu, Oct 1, 2015 at 1:47 PM, Nils Eliasson wrote: > Hi Roland, > > On 2015-09-28 12:02, Roland Westrelin wrote: > >> Hi Nils, >> >> http://cr.openjdk.java.net/~neliasso/8046155/webrev.03/ >>> >> What does CompileCommandCompatibility do? >> > > Control backwards compatibility with CompileCommand for testing purposes. > I 'll change the name to the moee descriptive > CompilerDirectivesIgnoreCompileCommands (default false). > >> >> vm_operations.cpp >> >> Is that extra include really needed? >> > No, removed. > >> >> CompilerQueueTest.java >> >> Is that extra import really needed? >> > No, removed. > > >> block.hpp >> >> You don?t need that ciEnv here, right? >> > No, left over from when the directives was stored in the viEnv. > >> >> compileBroker.cpp >> >> 1717 should_break = dirset->BreakAtExecuteOption || >> task->check_break_at_flags(); >> >> doesn?t seem to be used >> >> Except for those minor issues, looks good to me. >> > Fixed. > >> >> >> - Won't build c1 only or shark only. >>> >> You can?t push if c1 only doesn?t build, right? >> > > It was just a temporary glitch that is fixed now. > > Thanks, > Nils > >> >> Roland. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zoltan.majo at oracle.com Thu Oct 1 15:31:09 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 1 Oct 2015 17:31:09 +0200 Subject: [9] RFR(XS): 8137173: @HotSpotIntrinsicCandidate is not Oracle-specific Message-ID: <560D51BD.6030108@oracle.com> Hi, please review the patch for JDK-8137173. https://bugs.openjdk.java.net/browse/JDK-8137173 Problem: Mark Rheinhold filed this bug and suggested the following: "The doc comment for the @jdk.internal.HotSpotIntrinsicCandidate annotation says that it is "specific to the Oracle Java HotSpot Virtual Machine implementation". That's not true. The annotation is defined in the open-source HotSpot repository, so it is in fact available in all implementations derived from that code, whether from Oracle or from other vendors." Solution: I adopted the solution proposed by Mark. Webrev: http://cr.openjdk.java.net/~zmajo/8137173/webrev.00/ Testing: JPRT run (build + tests). I intend to push this into jdk9/hs-comp/jdk, from there it will eventually propagate to all repositories. Thank you and best regards, Zoltan From adinn at redhat.com Thu Oct 1 15:32:34 2015 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 1 Oct 2015 16:32:34 +0100 Subject: CSE, loops, and array accesses In-Reply-To: <1443704459.5907.3.camel@mylittlepony.linaroharston> References: <560D0AA2.6000200@redhat.com> <1443704459.5907.3.camel@mylittlepony.linaroharston> Message-ID: <560D5212.3060504@redhat.com> On 01/10/15 14:00, Edward Nevill wrote: > On Thu, 2015-10-01 at 11:27 +0100, Andrew Haley wrote: >> I'm looking at a failure to CSE the array base offset in this loop: >> . . . > > The reason it does not do the loop invariant lifting is because of the following transformation in AddPNode::Ideal in addnode.cpp > > // Else move the constant to the right. ((A+con)+B) into ((A+B)+con) > address = phase->transform(new (phase->C) AddPNode(in(Base),addp->in(Address),in(Offset))); > offset = addp->in(Offset); > > So, once it has transformed ((A+con)+B) into ((A+B)+con) all bets are off, we can never CSE/Loop invariant lift. > > Try the following patch, it should generate the code you want. That may indeed fix this case but at what cost to other optimizations? The implementations of Ideal across all graph nodes are supposed to reduce to a normal form in an order-independent manner -- normally described as 'reduction is confluent'. I wonder if this change will break the confluence property because other transformations expect (eventually) to see constants pushed up and to the right. If that is the case then I think the real problem here is that the loop invariant test knows that (A+con) is invariant when A is invariant but does not know that ((A+B)+con) also contains a loop invariant when either A or B is invariant. Maybe that is where the fix should be applied? 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 zoltan.majo at oracle.com Thu Oct 1 15:34:57 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 1 Oct 2015 17:34:57 +0200 Subject: [9] RFR(XS): 8137173: @HotSpotIntrinsicCandidate is not Oracle-specific In-Reply-To: <560D51BD.6030108@oracle.com> References: <560D51BD.6030108@oracle.com> Message-ID: <560D52A1.80406@oracle.com> P.S.: On 10/01/2015 05:31 PM, Zolt?n Maj? wrote: > Problem: Mark Rheinhold filed this bug and suggested the following: I ment Mark Reinhold (w/o the 'h'). Sorry for the mistake. Best regards, Zoltan > > "The doc comment for the @jdk.internal.HotSpotIntrinsicCandidate > annotation says that it is "specific to the Oracle Java HotSpot Virtual > Machine implementation". That's not true. The annotation is defined > in the open-source HotSpot repository, so it is in fact available in all > implementations derived from that code, whether from Oracle or from other > vendors." > > Solution: I adopted the solution proposed by Mark. > > Webrev: http://cr.openjdk.java.net/~zmajo/8137173/webrev.00/ > > Testing: JPRT run (build + tests). > > I intend to push this into jdk9/hs-comp/jdk, from there it will > eventually propagate to all repositories. > > Thank you and best regards, > > > Zoltan > From Alan.Bateman at oracle.com Thu Oct 1 15:41:02 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 01 Oct 2015 16:41:02 +0100 Subject: [9] RFR(XS): 8137173: @HotSpotIntrinsicCandidate is not Oracle-specific In-Reply-To: <560D51BD.6030108@oracle.com> References: <560D51BD.6030108@oracle.com> Message-ID: <560D540E.4090609@oracle.com> On 01/10/2015 16:31, Zolt?n Maj? wrote: > Hi, > > > please review the patch for JDK-8137173. > > https://bugs.openjdk.java.net/browse/JDK-8137173 > > Problem: Mark Rheinhold filed this bug and suggested the following: > > "The doc comment for the @jdk.internal.HotSpotIntrinsicCandidate > annotation says that it is "specific to the Oracle Java HotSpot Virtual > Machine implementation". That's not true. The annotation is defined > in the open-source HotSpot repository, so it is in fact available in all > implementations derived from that code, whether from Oracle or from other > vendors." > > Solution: I adopted the solution proposed by Mark. > > Webrev: http://cr.openjdk.java.net/~zmajo/8137173/webrev.00/ > This looks okay. Is it time to discuss moving the annotation to another package too? -Alan. From mark.reinhold at oracle.com Thu Oct 1 15:54:41 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 01 Oct 2015 08:54:41 -0700 Subject: [9] RFR(XS): 8137173: @HotSpotIntrinsicCandidate is not Oracle-specific In-Reply-To: <560D540E.4090609@oracle.com> References: <560D51BD.6030108@oracle.com>,<560D540E.4090609@oracle.com> Message-ID: <20151001085441.434440@eggemoggin.niobe.net> 2015/10/1 8:41 -0700, alan.bateman at oracle.com: > On 01/10/2015 16:31, Zolt?n Maj? wrote: >> please review the patch for JDK-8137173. >> >> https://bugs.openjdk.java.net/browse/JDK-8137173 >> >> ... >> >> Webrev: http://cr.openjdk.java.net/~zmajo/8137173/webrev.00/ >> > This looks okay. Is it time to discuss moving the annotation to > another package too? Yes. We don't want to create another sun.misc-like dumping ground with jdk.internal. We should prefer small, descriptive subpackages for things like this so that, when they are (inevitably) exposed via -XaddExports, their exposure can be limited. I suggest putting this into jdk.internal.vm.annotation, which is also a good place for the ReservedStackAccess annotation envisioned in JEP 270 (http://openjdk.java.net/jeps/270). - Mark From irogers at google.com Thu Oct 1 16:05:30 2015 From: irogers at google.com (Ian Rogers) Date: Thu, 1 Oct 2015 09:05:30 -0700 Subject: JIT code generation for Long/Integer.compare In-Reply-To: <5609BB02.2010204@oracle.com> References: <5604A3A1.60200@oracle.com> <56060456.10403@oracle.com> <5609BB02.2010204@oracle.com> Message-ID: Thanks Aleksey, I'd comment on the bug but I have no login. With your analysis could you look at the effect of the codegen around: @CompilerControl(CompilerControl.Mode.DONT_INLINE) private boolean compare(long a, long b) { return Long.compare(a, b) < 0; } without the intrinsic you effectively (currently) get: return ((x < y) ? -1 : ((x == y) ? 0 : 1)) < 0; with the intrinsic you get: return x < y; That's not to say intrinsics are good, but recognizing the code as a CmplL3 means it folds into the outer comparison which is common in the use of compareTo methods. I didn't notice this in your examples above, which may be error on my part - apologies in advance. Thanks, Ian On Mon, Sep 28, 2015 at 3:11 PM, Aleksey Shipilev < aleksey.shipilev at oracle.com> wrote: > Hi Ian, > > I filed: > https://bugs.openjdk.java.net/browse/JDK-8137309 > > I can see some improvement with your patch, mostly when Longs are > random, and therefore branch profile is polluted, and current generated > code is not laid out well. Current Hotspot seems to generate multiple > redundant cmp-s, which looks like a generic issue that should be > addressed. See e.g. the very first disassembly here: > http://cr.openjdk.java.net/~shade/8137309/BiasedCompareTo.java > > In some other cases, patched version is regressing. It seems to be the > interaction with intrinsic not using any branch profile to figure out > which option is more frequent, and some minor regalloc/constant > propagation issues. See e.g.: > http://cr.openjdk.java.net/~shade/8137309/PredictedCompareTo.java > > With that, fixing the optimizer/codegen without resorting to point > intrinsics does look like a better course of action. > > Thanks, > -Aleksey > > On 09/28/2015 04:44 AM, Ian Rogers wrote: > > Thanks. I'm not disagreeing with anything here. is_x2logic is 45 lines > > long and doing less (at least half) pattern matching work than would be > > required for compare. Wrt implementation approach, ReverseBytesI is > > purely an intrinsic but could also be implemented by pattern matching, > > which fwiw is how its implemented in Jikes RVM as part of instruction > > selection. With hindsight a high/ideal level BURS matching phase would > > be nice. The intrinsic implementation is trivially correct and easy for > > developers to target, whereas pattern matching can be buggy, hard to > > test, and so on. Its inherently more LOC complex. I have long thought > > pattern matching is the more laudable approach, but there's also a > > certain amount of pragmatism when selecting between an intrinsic and > > pattern matching. The scale of the proposed pattern match is beyond the > > size of any equivalent in C2, so I have concerns around correctness and > > in the consistency of the codebase in implementing it this way. > > > > If I may explain some of the background for this change, aside pure > > performance. There is a common bug pattern of: > > > > class MyFoo implements Comparable { > > private long x; > > int compareTo(MyFoo o) { > > return (int)(o.x - x); > > } > > } > > > > As the int cast doesn't preserve the sign of the long subtract, subtract > > results that overflow 31-bits may produce incorrect sort orders. > > Rewriting the above code to use Long.compare is currently a performance > > loss, although far more correct. What's true of long is also somewhat > > true for ints as the subtract approach doesn't behave correctly around > > Integer.MIN_VALUE. Having Long.compare and Integer.compare flagged as > > intrinsics would go someway to remove developers reticence to prefer it > > over the pervasive subtract approach which is naively considered more > > performant. > > > > Thanks, > > Ian > > > > > > On Sat, Sep 26, 2015 at 12:02 PM, John Rose > > wrote: > > > > On Sep 25, 2015, at 7:35 PM, Vladimir Kozlov > > > > wrote: > >> > >> For pattern matching I mean ideal transformation in ideal graph. > >> See, fro example, is_x2logic() in cfgnode.cpp and other > >> transformations for Phi node. > >> > >> You will still need new CmpI3 node and changes in .ad file. > > > > +1 Ideally, we pattern-match the body of the method we know about > and > > generate the new IR, and then two good things happen: Other > expressions > > we didn't know about also pattern match, and after looking at the > > pattern > > logic we discover straightforward generalizations that go beyond the > > method > > we knew about at first. > > > > ? John > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksey.shipilev at oracle.com Thu Oct 1 17:05:04 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 1 Oct 2015 20:05:04 +0300 Subject: JIT code generation for Long/Integer.compare In-Reply-To: References: <5604A3A1.60200@oracle.com> <56060456.10403@oracle.com> <5609BB02.2010204@oracle.com> Message-ID: <560D67C0.8060402@oracle.com> Hi Ian, Don't you want to replicate these results yourself, since it may serve to validate any polishings for the patch? ;) The benchmark you suggest is easily runnable, and -prof perfasm can give you the generated code in a minute. Also, why would anyone do "Long.compare(a, b) < 0" when it's actually "a < b"? Should we actually care about this (arguably) code smell? Anyhow, my quick runs suggest with current JDK implementation C2 compiles "Long.compare(a, b) < 0" expressions nicely, collapsing some code paths that used to return 0xff..ff / setne to just returning 1 / 0, sometimes even folding into conditional move. The generated code with the intrinsic is the same! E.g. @Benchmark public void first(Blackhole bh) { for (long v : a) { bh.consume(compare(v, 0L)); } } @CompilerControl(CompilerControl.Mode.DONT_INLINE) private boolean compare(long a, long b) { return Long.compare(a, b) < 0; } ...with bias=0.5 emits this with both baseline and intrinsified versions: [Verified Entry Point] 0.78% 0.92% 0x00007fa9395f9b00: sub $0x18,%rsp 6.37% 6.16% 0x00007fa9395f9b07: mov %rbp,0x10(%rsp) 0.08% 0.08% 0x00007fa9395f9b0c: xor %r10d,%r10d 1.05% 0.71% 0x00007fa9395f9b0f: mov $0x1,%eax 0x00007fa9395f9b14: cmp %rcx,%rdx 6.23% 5.44% 0x00007fa9395f9b17: cmovge %r10d,%eax 0.82% 0.48% 0x00007fa9395f9b1b: add $0x10,%rsp 0x00007fa9395f9b1f: pop %rbp 6.25% 5.74% 0x00007fa9395f9b20: test %eax,0x134ae4da(%rip) 0.04% 0.08% 0x00007fa9395f9b26: retq Other biases are swinging back and forth, mostly tied, depending on how lucky you are in laying out the branches. (Admittedly, "< 0" shape is favorited by non-optimized intrinsic code -- it without setne; so even better benchmarks would quantify "> 0" and "== 0" patterns as well). So, I would say we should mostly care about ternary (-1, 0, 1) cases? I still think the work optimizing Long/Integer.compare is about dealing with optimizer quirks... Thanks, -Aleksey On 10/01/2015 07:05 PM, Ian Rogers wrote: > Thanks Aleksey, > > I'd comment on the bug but I have no login. With your analysis could you > look at the effect of the codegen around: > > @CompilerControl(CompilerControl.Mode.DONT_INLINE) > private boolean compare(long a, long b) { > return Long.compare(a, b) < 0; > } > > without the intrinsic you effectively (currently) get: > > return ((x < y) ? -1 : ((x == y) ? 0 : 1)) < 0; > > with the intrinsic you get: > > return x < y; > > That's not to say intrinsics are good, but recognizing the code as a > CmplL3 means it folds into the outer comparison which is common in the > use of compareTo methods. I didn't notice this in your examples above, > which may be error on my part - apologies in advance. > > Thanks, > Ian > > > On Mon, Sep 28, 2015 at 3:11 PM, Aleksey Shipilev > > wrote: > > Hi Ian, > > I filed: > https://bugs.openjdk.java.net/browse/JDK-8137309 > > I can see some improvement with your patch, mostly when Longs are > random, and therefore branch profile is polluted, and current generated > code is not laid out well. Current Hotspot seems to generate multiple > redundant cmp-s, which looks like a generic issue that should be > addressed. See e.g. the very first disassembly here: > http://cr.openjdk.java.net/~shade/8137309/BiasedCompareTo.java > > > In some other cases, patched version is regressing. It seems to be the > interaction with intrinsic not using any branch profile to figure out > which option is more frequent, and some minor regalloc/constant > propagation issues. See e.g.: > http://cr.openjdk.java.net/~shade/8137309/PredictedCompareTo.java > > > With that, fixing the optimizer/codegen without resorting to point > intrinsics does look like a better course of action. > > Thanks, > -Aleksey > > On 09/28/2015 04:44 AM, Ian Rogers wrote: > > Thanks. I'm not disagreeing with anything here. is_x2logic is 45 lines > > long and doing less (at least half) pattern matching work than > would be > > required for compare. Wrt implementation approach, ReverseBytesI is > > purely an intrinsic but could also be implemented by pattern matching, > > which fwiw is how its implemented in Jikes RVM as part of instruction > > selection. With hindsight a high/ideal level BURS matching phase would > > be nice. The intrinsic implementation is trivially correct and > easy for > > developers to target, whereas pattern matching can be buggy, hard to > > test, and so on. Its inherently more LOC complex. I have long thought > > pattern matching is the more laudable approach, but there's also a > > certain amount of pragmatism when selecting between an intrinsic and > > pattern matching. The scale of the proposed pattern match is > beyond the > > size of any equivalent in C2, so I have concerns around > correctness and > > in the consistency of the codebase in implementing it this way. > > > > If I may explain some of the background for this change, aside pure > > performance. There is a common bug pattern of: > > > > class MyFoo implements Comparable { > > private long x; > > int compareTo(MyFoo o) { > > return (int)(o.x - x); > > } > > } > > > > As the int cast doesn't preserve the sign of the long subtract, > subtract > > results that overflow 31-bits may produce incorrect sort orders. > > Rewriting the above code to use Long.compare is currently a > performance > > loss, although far more correct. What's true of long is also somewhat > > true for ints as the subtract approach doesn't behave correctly around > > Integer.MIN_VALUE. Having Long.compare and Integer.compare flagged as > > intrinsics would go someway to remove developers reticence to > prefer it > > over the pervasive subtract approach which is naively considered more > > performant. > > > > Thanks, > > Ian > > > > > > On Sat, Sep 26, 2015 at 12:02 PM, John Rose > > > >> wrote: > > > > On Sep 25, 2015, at 7:35 PM, Vladimir Kozlov > > > >> wrote: > >> > >> For pattern matching I mean ideal transformation in ideal graph. > >> See, fro example, is_x2logic() in cfgnode.cpp and other > >> transformations for Phi node. > >> > >> You will still need new CmpI3 node and changes in .ad file. > > > > +1 Ideally, we pattern-match the body of the method we know > about and > > generate the new IR, and then two good things happen: Other > expressions > > we didn't know about also pattern match, and after looking at the > > pattern > > logic we discover straightforward generalizations that go > beyond the > > method > > we knew about at first. > > > > ? John > > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From john.r.rose at oracle.com Thu Oct 1 19:20:57 2015 From: john.r.rose at oracle.com (John Rose) Date: Thu, 1 Oct 2015 12:20:57 -0700 Subject: JIT code generation for Long/Integer.compare In-Reply-To: <560D67C0.8060402@oracle.com> References: <5604A3A1.60200@oracle.com> <56060456.10403@oracle.com> <5609BB02.2010204@oracle.com> <560D67C0.8060402@oracle.com> Message-ID: <6C9AA606-9D8A-41D1-B096-087C3349483B@oracle.com> On Oct 1, 2015, at 10:05 AM, Aleksey Shipilev wrote: > > Also, why would anyone do "Long.compare(a, b) < 0" when it's actually "a > < b"? Should we actually care about this (arguably) code smell? Smelly code arises naturally from well-written code after inlining and type sharpening. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From zoltan.majo at oracle.com Fri Oct 2 05:57:51 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 2 Oct 2015 07:57:51 +0200 Subject: [9] RFR(XS): 8137173: @HotSpotIntrinsicCandidate is not Oracle-specific In-Reply-To: <20151001085441.434440@eggemoggin.niobe.net> References: <560D51BD.6030108@oracle.com> <560D540E.4090609@oracle.com> <20151001085441.434440@eggemoggin.niobe.net> Message-ID: <560E1CDF.7070307@oracle.com> Hi Alan, Hi Mark, On 10/01/2015 05:54 PM, mark.reinhold at oracle.com wrote: > 2015/10/1 8:41 -0700, alan.bateman at oracle.com: >> On 01/10/2015 16:31, Zolt?n Maj? wrote: >>> please review the patch for JDK-8137173. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8137173 >>> >>> ... >>> >>> Webrev: http://cr.openjdk.java.net/~zmajo/8137173/webrev.00/ >>> >> This looks okay. Is it time to discuss moving the annotation to >> another package too? thank you for the review! > Yes. We don't want to create another sun.misc-like dumping ground > with jdk.internal. We should prefer small, descriptive subpackages > for things like this so that, when they are (inevitably) exposed via > -XaddExports, their exposure can be limited. > > I suggest putting this into jdk.internal.vm.annotation, which is > also a good place for the ReservedStackAccess annotation envisioned > in JEP 270 (http://openjdk.java.net/jeps/270). I filed an RFE, JDK-8138732: "move @HotSpotIntrinsicCandidate to the jdk.internal.vm.annotation package" [1], to track the issue of moving the annotation to a different package. I hope I can take care of it soon. Thank you and best regards, Zoltan [1] https://bugs.openjdk.java.net/browse/JDK-8138732 > > - Mark From goetz.lindenmaier at sap.com Fri Oct 2 10:58:51 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 2 Oct 2015 10:58:51 +0000 Subject: RFR(S): 8138733: Fix build: gcc < 4.8 doesn't grok -Wno-format-zero-length added in 8080775 Message-ID: <4295855A5C1DE049A61835A1887419CC41E7EBD4@DEWDFEMB12A.global.corp.sap> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.westrelin at oracle.com Fri Oct 2 13:30:46 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 2 Oct 2015 15:30:46 +0200 Subject: Request for Reviews (S): JDK-8003585 strength reduce or eliminate range checks for power-of-two sized arrays In-Reply-To: References: <440F2280-4B25-4AE6-A4F6-DDD4EB529636@oracle.com> <52FC129D.7040409@oracle.com> <52FE6A08.20400@oracle.com> <52FE7313.3060404@oracle.com> <530209A8.1020501@oracle.com> <38EE6922-0B9C-49A6-B54D-E78BA0EFECB1@oracle.com> Message-ID: <8232A81B-6B78-4F61-A8EC-1A3DF3938648@oracle.com> Hi Chris, > Thanks for picking it up! It mostly looks good to me. (Not a Reviewer) Thanks for looking at this again. > What I really needed with my earlier webrev was some instructions as to what test to write -- since the Java corelibs can come across this optimization a lot (e.g. HashMap), I didn't have a good idea of what kind of test really needs to be written. > > A couple of issues with this webrev: > > 1. In subnode.cpp, line 1346: > > 1344 } else if (_test._test == BoolTest::lt && > 1345 cmp2->Opcode() == Op_AddI && > 1346 cmp2->in(2)->find_int_con(1)) { > 1347 bound = cmp2->in(1); > 1348 } > > I think it should be > cmp2->in(2)->find_int_con(0) == 1 > instead, because the value passed into this function is actually for a "fallback when no int constant is found". Passing the expected value (1) to it defeats the purpose. You?re right. Thanks for spotting that. > jint find_int_con(jint value_if_unknown) const { > const TypeInt* t = find_int_type(); > return (t != NULL && t->is_con()) ? t->get_con() : value_if_unknown; > } > > 2. Formattign nitpick: could you please trim the spaces before the new's on lines 1368, 1369 and 1387 Sure. I?ll send an updated webrev. Roland. > > Thanks, > Kris (OpenJDK username: krismo) > > On Wed, Sep 30, 2015 at 1:34 AM, Roland Westrelin wrote: > I?m picking that one up. Here is a new webrev: > > http://cr.openjdk.java.net/~roland/8003585/webrev.00/ > > The only change to c2 compared to the previous webrev is that ((x & m) u< m+1) is optimized the same way ((x & m) u<= m) is. Actually, I don?t think that C2 currently produces the ((x & m) u<= m) shape. The IfNode::fold_compares() logic produces the ((x & m) u< m+1) variant. I also added a test case to check the validity of the transformations and ran usual testing on the change. > > Roland. > From roland.westrelin at oracle.com Fri Oct 2 13:55:09 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 2 Oct 2015 15:55:09 +0200 Subject: [9] RFR(M): 8078554: Compiler: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <560BB4F6.3050703@oracle.com> References: <560BB4F6.3050703@oracle.com> Message-ID: <4502D8F6-B256-4222-B1D3-92ED5C100B6E@oracle.com> Hi Zoltan, > Webrev: http://cr.openjdk.java.net/~zmajo/8078554/ c2_globals.hpp That one is not correct: 461 product(intx, MaxNodeLimit, 80000, \ 462 "Maximum number of nodes") \ 463 range(1000, 80000) \ I think the upper bound should be max_juint 699 product(intx, LiveNodeCountInliningCutoff, 40000, \ 700 "max number of live nodes in a method") \ 701 range(0, max_juint / 8) \ Out of curiosity why max_juint / 8 (not that it makes much of a difference)? arguments.cpp 1099 Tier3InvokeNotifyFreqLog = 1; 1100 Tier4InvocationThreshold = 1; Why that change? globals.hp 2870 product_pd(uintx, TypeProfileLevel, \ 2871 "=XYZ, with Z: Type profiling of arguments at call; " \ 2872 "Y: Type profiling of return value at call; " \ 2873 "X: Type profiling of parameters to methods; " \ 2874 "X, Y and Z in 0=off ; 1=jsr292 only; 2=all methods") \ 2875 range(0, 222) Legal values are 0, 1, 2, 10, 11, 12, 100, 101, 102, 110, 111, 112 etc. 70 is not for instance. So range(0, 222) is incorrect. 2877 product(intx, TypeProfileArgsLimit, 2, \ 2878 "max number of call arguments to consider for type profiling") \ 2879 range(0, 16) \ 2880 \ 2881 product(intx, TypeProfileParmsLimit, 2, \ 2882 "max number of incoming parameters to consider for type profiling"\ 2883 ", -1 for all") \ 2884 range(-1, 64) Why 16 and 64? Roland. From roland.westrelin at oracle.com Fri Oct 2 14:04:51 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 2 Oct 2015 16:04:51 +0200 Subject: RFR: aarch64: add support for vectorizing floating-point fabs & fneg In-Reply-To: <1443602324.20740.3.camel@mint> References: <5605792B.5000408@redhat.com> <56095AFD.9000405@redhat.com> <1443602324.20740.3.camel@mint> Message-ID: <5890687B-F5B9-4854-8878-5B1986875B83@oracle.com> > I have created a JIRA issue and webrev for this. > > https://bugs.openjdk.java.net/browse/JDK-8138583 > > http://cr.openjdk.java.net/~enevill/8138583/webrev/ > > As this modifies shared code could someone sponsor it and push it through JPRT. I?m pushing it. Roland. From nils.eliasson at oracle.com Fri Oct 2 14:10:24 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 2 Oct 2015 16:10:24 +0200 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: <56018E2B.2000108@oracle.com> References: <56018E2B.2000108@oracle.com> Message-ID: <560E9050.6000804@oracle.com> Hi all, A new webrev with all the feedback from reviewers and others. http://cr.openjdk.java.net/~neliasso/8046155/webrev.04/ - name changes as requested by christian - various small bug fixes - New tests for sanity testing flags and their behaviour with vm flags and compile commands present Regards, Nils On 2015-09-22 19:21, Nils Eliasson wrote: > Hi, > > This is the initial RFR for JEP165: Compiler Control. This feature > enables runtime manageable, method dependent compiler flags. > (Immutable for the duration of a compilation.) > > The change includes: > - A parser for the directives format (json like) including vmtests > (json.cpp/hpp) > - A component for construction of compiler directives > (directivesParser.cpp/hpp) > - The directives including the option definitions, default values and > compilecommand relations (compilerDirectives.cpp/hpp) > - Diagnostic commands for working with the directives - installing, > removing, printing > - Lots of small changes wherever we access flags or legacy > compilecommands in the compiler > > Notes: > The feature is documented in the JEP > (https://bugs.openjdk.java.net/browse/JDK-8046155). > > Currently only a small amount of compiler flags are included in the > change. The flags are a representative selection of different types > targeting both compilers. All of them existed as CompilerOracle option > commands. Two commands was not included in the directives due to time > constraints - CompilerThresholdScaling and UseRTMLocks. Both are > accessed from runtime (outside any compiler) and requires some special > handling. (Solved but not implemented.) > > Full backwards compatibility with CompileCommands is implemented but > can be turned off with flag -XX:CompileCommandCompatibilty. Also meta > handling the compatibility flag by supporting it in the directives > (test feature). > > The change contain some rough edges that will polished over the coming > days. > > JEP: https://bugs.openjdk.java.net/browse/JDK-8046155 > Hotspot webrev: http://cr.openjdk.java.net/~neliasso/8046155/webrev.01/ > JDK webrev: http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.01/ > > Please review! > > Best regards, > Nils Eliasson From xueming.shen at oracle.com Fri Oct 2 21:13:38 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 02 Oct 2015 14:13:38 -0700 Subject: RFR: String Density/Compact String JEP 254 Message-ID: <560EF382.3000507@oracle.com> 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 uschindler at apache.org Sun Oct 4 18:10:26 2015 From: uschindler at apache.org (Uwe Schindler) Date: Sun, 4 Oct 2015 20:10:26 +0200 Subject: RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server compiler In-Reply-To: References: <53037D5B-7CA1-493C-837B-AF502ADFDF83@oracle.com> <55E721C6.2000206@oracle.com> Message-ID: <066d01d0fecf$f4f42230$dedc6690$@apache.org> Hi, is this already in build 82? I did not find it in changes log, but I have the feeling it should be :-) Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Roland Westrelin > Sent: Wednesday, September 02, 2015 8:40 PM > To: hotspot compiler > Subject: Re: RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server > compiler > > Thanks for the reviews, Vladimir & Igor. > > Roland. From mikael.gerdin at oracle.com Fri Oct 2 11:05:42 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 2 Oct 2015 13:05:42 +0200 Subject: RFR(S): 8138733: Fix build: gcc < 4.8 doesn't grok -Wno-format-zero-length added in 8080775 In-Reply-To: <4295855A5C1DE049A61835A1887419CC41E7EBD4@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC41E7EBD4@DEWDFEMB12A.global.corp.sap> Message-ID: <560E6506.3010608@oracle.com> 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 konstantin.shefov at oracle.com Fri Oct 2 12:11:26 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Fri, 2 Oct 2015 15:11:26 +0300 Subject: [9] RFR 8072369: [TESTBUG] Remove potentially insecure class cast in some hotspot tests In-Reply-To: <55F0312E.7020908@oracle.com> References: <55EF0649.8050109@oracle.com> <55F0312E.7020908@oracle.com> Message-ID: <560E746E.4000103@oracle.com> Please, review the test bug fix. -Konstantin On 09/09/2015 04:16 PM, Konstantin Shefov wrote: > Description of the fix. > Some tests in hotspot repo use class cast from Application class > loader to URLClassLoader, but Application class loader is not > guaranteed to be always an instance of a URLClassLoader. > The tests should be changed so that they do not cast appclassloader to > URLClassLoader. > > -Konstantin > > On 09/08/2015 07:01 PM, Konstantin Shefov wrote: >> Hello >> >> Please review a test bug fix. >> >> JBS entry: https://bugs.openjdk.java.net/browse/JDK-8072369 >> Webrev: http://cr.openjdk.java.net/~kshefov/8072369/webrev.00 >> >> Thanks >> -Konstantin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xueming.shen at oracle.com Fri Oct 2 21:02:18 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 02 Oct 2015 14:02:18 -0700 Subject: RFR: String Density/Compact String JEP 254 Message-ID: <560EF0DA.8020908@oracle.com> 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 to 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 vladimir.kozlov at oracle.com Mon Oct 5 07:58:05 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 5 Oct 2015 15:58:05 +0800 Subject: RFR(S): 8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI In-Reply-To: References: <7B89ADB9-1DF9-4DE2-85C8-0ADFF34A3190@oracle.com> <55F99D08.3010204@oracle.com> <4DAAADBF-9A3C-46BD-9E86-29E9B5044FAA@oracle.com> <55F9AB59.6030604@oracle.com> <07AAF0D5-134D-4D85-BD4C-EA5049EF8857@oracle.com> <55FF5E26.1060008@oracle.com> <041EEDC9-D32F-420D-9D55-111499B13321@oracle.com> <9D17B19D-9A35-4EFE-B5F7-954629DA2FC2@oracle.com> <10866B0A-712E-4665-9CC3-838AE6536D4A@oracle.com> <56014EA4.50907@oracle.com> Message-ID: <56122D8D.1050909@oracle.com> Mismatching access can be only for basic type as I understand. The code for mismatched = true could be rearranged by checking type != T_OBJECT first. Why you set mismatched only for array element? What about fields? And next should be && I think (if you keep your code) if (type != T_OBJECT || !element->isa_narrowoop()) Thanks, Vladimir On 9/28/15 11:44 PM, Roland Westrelin wrote: > That fix wasn?t sufficient so here is a new webrev: > > http://cr.openjdk.java.net/~roland/8136473/webrev.02/ > > On platforms that don?t support unaligned accesses we still have mismatched accesses because the java code of Unsafe.putIntUnaligned() is implemented in terms of putShort() and putByte() so my test case fails on sparc. I added a new boolean to MemNode to record whether the node is ?mismatched? in addition to the ?unaligned? boolean. > > Roland. > >> On Sep 22, 2015, at 2:50 PM, Vladimir Kozlov wrote: >> >> Okay. >> >> Vladimir >> >> On 9/22/15 8:47 PM, Roland Westrelin wrote: >>> For the record, it seems _unaligned is a reserved keyword for MSVC so I will change the field and function names to unaligned_access: >>> >>> diff --git a/src/share/vm/opto/memnode.hpp b/src/share/vm/opto/memnode.hpp >>> --- a/src/share/vm/opto/memnode.hpp >>> +++ b/src/share/vm/opto/memnode.hpp >>> @@ -40,7 +40,7 @@ >>> // Load or Store, possibly throwing a NULL pointer exception >>> class MemNode : public Node { >>> private: >>> - bool _unaligned; >>> + bool _unaligned_access; >>> protected: >>> #ifdef ASSERT >>> const TypePtr* _adr_type; // What kind of memory is being addressed? >>> >>> @@ -129,8 +129,8 @@ >>> // the given memory state? (The state may or may not be in(Memory).) >>> Node* can_see_stored_value(Node* st, PhaseTransform* phase) const; >>> >>> - void set_unaligned() { _unaligned = true; } >>> - bool is_unaligned() const { return _unaligned; } >>> + void set_unaligned_access() { _unaligned_access = true; } >>> + bool is_unaligned_access() const { return _unaligned_access; } >>> >>> #ifndef PRODUCT >>> static void dump_adr_type(const Node* mem, const TypePtr* adr_type, outputStream *st); >>> >>> Roland. >>> >>>> On Sep 22, 2015, at 9:43 AM, Roland Westrelin wrote: >>>> >>>>> Roland I had a look too, the code looks good. >>>> >>>> Thanks, Michael. >>>> >>>> Roland. >>>> >>>>> >>>>> -Michael >>>>> >>>>> -----Original Message----- >>>>> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Roland Westrelin >>>>> Sent: Monday, September 21, 2015 2:03 AM >>>>> To: hotspot compiler >>>>> Subject: Re: RFR(S): 8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI >>>>> >>>>> Thanks for the review, Vladimir. >>>>> >>>>> Roland. >>>>> >>>>>> On Sep 21, 2015, at 3:32 AM, Vladimir Kozlov wrote: >>>>>> >>>>>> This is good. Thank you for extending the test. >>>>>> >>>>>> Vladimir >>>>>> >>>>>> On 9/18/15 11:03 PM, Roland Westrelin wrote: >>>>>>>>>> Hmm, so you just relaxed the assert. You may need to fix EA too because it also checks for matching types(memory sizes). >>>>>>>>>> I remember we had problem with RAW accesses back when jsr292 was implemented. So EA gave up on RAW access and marks allocations as escaping. Also may be superword/vectorization will be affected. >>>>>>>>>> >>>>>>>>>> In general it is very bad for C2 to have different memory on the same non-RAW memory. >>>>>>>>> >>>>>>>>> It already happens with vectorization. Do you see another solution (rather than relaxing the assert)? Putting a MemBarCPUOrder before and after the unaligned store? >>>>>>>> >>>>>>>> MemBarCPUOrder are definitely will help and it is simplest solution but, I think, it is too drastic. >>>>>>>> It affect control flow and other memory slices. >>>>>>>> We can try to mark such memory accesses or/and mark objects which have such accesses (if it is possible) and prevent vectorization and scalarization for them only. We should be able execute optimization on other memory slices then. >>>>>>> >>>>>>> Here is a new change: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~roland/8136473/webrev.01/ >>>>>>> >>>>>>> Unaligned accesses are explicitly marked as such. >>>>>>> >>>>>>> I added a test case with a non escaping allocation and it works fine. I also added test case with vectorization and if the accesses are effectively unaligned vectorization doesn't happen. One of the test cases causes an assertion to fire when the allocation is expanded: the logic in InitializeNode::complete_stores() is confused by the unaligned store so I made sure unaligned stores are not captured by the initialization. >>>>>>> >>>>>>> Roland. >>>>>>> >>>>> >>>> >>> > From vladimir.kozlov at oracle.com Mon Oct 5 08:07:44 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 5 Oct 2015 16:07:44 +0800 Subject: RFR(M): 8136725 Provide utility for creation a counted loop reserve copy (clone) In-Reply-To: <30A22020-0926-4C94-A44E-8CEA37565C96@oracle.com> References: <012766EA-BDDF-4E0D-A01C-7B96591ABC64@oracle.com> <39F83597C33E5F408096702907E6C45005852375@ORSMSX104.amr.corp.intel.com> <56028117.50706@oracle.com> <39F83597C33E5F408096702907E6C4500585A55E@ORSMSX104.amr.corp.intel.com> <30A22020-0926-4C94-A44E-8CEA37565C96@oracle.com> Message-ID: <56122FD0.2050200@oracle.com> remove .hgtags changes Trace outputs in create_reserve() are not under trace flag. I would suggest to remove them or put under TraceLoopOpts && Verbose combination. Also, please, split next and similar lines according to our code stile: if (!_lp_reserved->is_CountedLoop()) return false; --- if (!_lp_reserved->is_CountedLoop()) { return false; } The rest looks fine. Thanks, Vladimir On 10/1/15 4:31 AM, Igor Veresov wrote: > Here?s the updated webrev: > > http://cr.openjdk.java.net/~iveresov/loop-reverse/webrev.02/ > > igor > >> On Sep 28, 2015, at 2:25 AM, Civlin, Jan > > wrote: >> >> Vladimir, >> >> Thank you for the review. >> I'm attaching the patch reflecting your comments. >> >> Regards, >> >> Jan >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Wednesday, September 23, 2015 3:38 AM >> To: Civlin, Jan; hotspot compiler >> Subject: Re: RFR(M): 8136725 Provide utility for creation a counted >> loop reserve copy (clone) >> >> in loopUnswitch.cpp debug output should be under nonproduct flag >> (could be TraceLoopOpts or separate new flag). Use #ifndef PRODUCT >> around print code instead of repeated NOT_PRODUCT() macro. And I don't >> think you need all output you added in final version. >> >> All constants are IGVNed so you don't need to pre-generate const_0. >> Since it is not connected to graph it could be eliminated. >> And I don't think you need next for the same reason: >> >> 311 lk->set_const_0(const_0); >> 312 lk->set_const_1(const_1); >> >> In ~CountedLoopReserveKit() and switch_to_reserved() you can make new >> const_0 since you have pointer to IGVN: >> >> _phase->_igvn.intcon(0); >> >> You can't use subsume() since it will replace all users of const_1: >> >> + //TODO bug? could not use here _const_1->subsume_by(_const_0, >> _phase->C); >> >> It is correct to use set_req() for constants here. >> >> superword.cpp I don't think you need to keep _CountedLoopReserveKit_test >> code in final version after you verified it works during development: >> >> + //!/// Testing that switching to reserved copy works >> >> Thanks, >> Vladimir >> >> On 9/19/15 1:05 AM, Civlin, Jan wrote: >>> As I was working on modification of SuperWord::output - and this is a >>> function where you modify the ideal graph on the fly and cannot exit >>> on error - I was wondering how can I protect my algorithm in a case >>> some wrong decision was made on the previous stage of the SuperWord >>> but discovered only at the final stage, when the graph is already >>> half modified. >>> >>> So here is my solution: >>> - the graph to be modified is cloned. >>> - five nodes are added: intcon(0) is disconnected, intcon(1)->If-> >>> IfTrue->orig_loop: IfFalse->clone_loop. >>> >>> Then any optimization is executed on the original loop, and if it >>> finishes ok, nothing else need to be done, the clone_loop will be >>> removed as dead in the consecutive stages of compiler. >>> At any moment, if an error occurs, the node intcon(1) may be subsumed >>> by node intcon(0), therefore the clone_loop becomes "active" and the >>> original "unfinished in modification" loop will be removed later. >>> >>> This utility is implemented in class CountedLoopReserveKit. >>> The loop cloning and 5 nodes adding is realized in the ctor and >>> possible subsuming intcon(1) by intcon(0) in dtor, so a simple return >>> from the modifying graph function will do graph correction (switching >>> in choice) of the graph. >>> Basically, it is sufficient the create a local object of >>> CountedLoopReserveKit class, the scoped dtor makes the choice: >>> modified or original loop. >>> >>> SuperWord::output in this submission is included only to illustrate >>> how to use the CountedLoopReserveKit. >>> The actual new SuperWord::output where CountedLoopReserveKit is >>> indeed substantial is coming in the next patch. >>> >>> This reserve loop cloning in SuperWord may be disabled by the global >>> flag DoReserveCopyInSuperWord. >>> >>> -----Original Message----- >>> From: Igor Veresov [mailto:igor.veresov at oracle.com] >>> Sent: Thursday, September 17, 2015 2:31 PM >>> To: hotspot compiler >>> Cc: Civlin, Jan >>> Subject: RFR(M): 8136725 Provide utility for creation a counted loop >>> reserve copy (clone) >>> >>> Provide utility for creation a counted loop reserve copy (clone). >>> May be used in any graph optimization for simple roll back to the >>> original loop, in partially will be used in SuperWord, where the loop >>> modification goes on-the-fly and potentially may not finish correctly >>> (the patch for SuperWord is coming soon). >>> >>> This is contributed by Jan Civlin >> > >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/loop-reverse/webrev-091515/ >>> >>> igor >>> >> > From roland.westrelin at oracle.com Mon Oct 5 08:17:04 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 5 Oct 2015 10:17:04 +0200 Subject: RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server compiler In-Reply-To: <066d01d0fecf$f4f42230$dedc6690$@apache.org> References: <53037D5B-7CA1-493C-837B-AF502ADFDF83@oracle.com> <55E721C6.2000206@oracle.com> <066d01d0fecf$f4f42230$dedc6690$@apache.org> Message-ID: Hi Uwe, > is this already in build 82? I did not find it in changes log, but I have the feeling it should be :-) It?s in b83. Roland. From uschindler at apache.org Mon Oct 5 08:31:37 2015 From: uschindler at apache.org (Uwe Schindler) Date: Mon, 5 Oct 2015 10:31:37 +0200 Subject: RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server compiler In-Reply-To: References: <53037D5B-7CA1-493C-837B-AF502ADFDF83@oracle.com> <55E721C6.2000206@oracle.com> <066d01d0fecf$f4f42230$dedc6690$@apache.org> Message-ID: <06e001d0ff48$427d23d0$c7776b70$@apache.org> Hi Roland, Thanks. I was trying b82 yesterday and we already found a new bug. Tests were failing with SIGSEGV on Jenkins: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14121/ (you can download "hs_err" and "replay" from there, you can also see JVM settings like bitness, Garbage Collector from there). Current CompileTask: C2: 866319 28632 4 org.apache.directory.api.ldap.model.name.Rdn::apply (45 bytes) Stack: [0x00007f3e647e6000,0x00007f3e648e7000], sp=0x00007f3e648e1e60, free space=1007k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x80ccce] PhaseIdealLoop::build_loop_late_post(Node*)+0x13e V [libjvm.so+0x80d06b] PhaseIdealLoop::build_loop_late(VectorSet&, Node_List&, Node_Stack&)+0x13b V [libjvm.so+0x8102dc] PhaseIdealLoop::build_and_optimize(bool, bool)+0x88c V [libjvm.so+0x4e699a] Compile::Optimize()+0x6ca V [libjvm.so+0x4e83f0] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0x1040 V [libjvm.so+0x42dbb9] C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0xe9 V [libjvm.so+0x4effda] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x8ca V [libjvm.so+0x4f0a58] CompileBroker::compiler_thread_loop()+0x4a8 V [libjvm.so+0xa61038] JavaThread::thread_main_inner()+0xd8 V [libjvm.so+0xa611d8] JavaThread::run()+0x158 V [libjvm.so+0x9048e2] java_start(Thread*)+0xc2 C [libpthread.so.0+0x8182] start_thread+0xc2 siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000008 This happened in parallel for 2 different JVMs (we are running tests in parallel with multiple JVMs). We should look into this, too! Tell me how I can help (as always, it is hard to reproduce). So this must be some change between b78 and b82 (b78 is last known working config). Maybe bells are ringing for you. Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Roland Westrelin [mailto:roland.westrelin at oracle.com] > Sent: Monday, October 05, 2015 10:17 AM > To: Uwe Schindler > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server > compiler > > Hi Uwe, > > > is this already in build 82? I did not find it in changes log, but I have the > feeling it should be :-) > > It?s in b83. > > Roland.= From dawid.weiss at gmail.com Mon Oct 5 08:36:37 2015 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Mon, 5 Oct 2015 10:36:37 +0200 Subject: RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server compiler In-Reply-To: <06e001d0ff48$427d23d0$c7776b70$@apache.org> References: <53037D5B-7CA1-493C-837B-AF502ADFDF83@oracle.com> <55E721C6.2000206@oracle.com> <066d01d0fecf$f4f42230$dedc6690$@apache.org> <06e001d0ff48$427d23d0$c7776b70$@apache.org> Message-ID: Maybe we should include a custom-built fastdebug JVM to jenkins... Could be that it'd provide more info if it trips on an earlier assertion. I also like your previous suggestion that Lucene's sanity test case could be run as a smokechecker before openjdk release :) Dawid On Mon, Oct 5, 2015 at 10:31 AM, Uwe Schindler wrote: > Hi Roland, > > Thanks. I was trying b82 yesterday and we already found a new bug. Tests were failing with SIGSEGV on Jenkins: > http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14121/ > (you can download "hs_err" and "replay" from there, you can also see JVM settings like bitness, Garbage Collector from there). > > Current CompileTask: > C2: 866319 28632 4 org.apache.directory.api.ldap.model.name.Rdn::apply (45 bytes) > > Stack: [0x00007f3e647e6000,0x00007f3e648e7000], sp=0x00007f3e648e1e60, free space=1007k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x80ccce] PhaseIdealLoop::build_loop_late_post(Node*)+0x13e > V [libjvm.so+0x80d06b] PhaseIdealLoop::build_loop_late(VectorSet&, Node_List&, Node_Stack&)+0x13b > V [libjvm.so+0x8102dc] PhaseIdealLoop::build_and_optimize(bool, bool)+0x88c > V [libjvm.so+0x4e699a] Compile::Optimize()+0x6ca > V [libjvm.so+0x4e83f0] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0x1040 > V [libjvm.so+0x42dbb9] C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0xe9 > V [libjvm.so+0x4effda] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x8ca > V [libjvm.so+0x4f0a58] CompileBroker::compiler_thread_loop()+0x4a8 > V [libjvm.so+0xa61038] JavaThread::thread_main_inner()+0xd8 > V [libjvm.so+0xa611d8] JavaThread::run()+0x158 > V [libjvm.so+0x9048e2] java_start(Thread*)+0xc2 > C [libpthread.so.0+0x8182] start_thread+0xc2 > > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000008 > > > This happened in parallel for 2 different JVMs (we are running tests in parallel with multiple JVMs). We should look into this, too! Tell me how I can help (as always, it is hard to reproduce). So this must be some change between b78 and b82 (b78 is last known working config). Maybe bells are ringing for you. > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ > > >> -----Original Message----- >> From: Roland Westrelin [mailto:roland.westrelin at oracle.com] >> Sent: Monday, October 05, 2015 10:17 AM >> To: Uwe Schindler >> Cc: hotspot-compiler-dev at openjdk.java.net >> Subject: Re: RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server >> compiler >> >> Hi Uwe, >> >> > is this already in build 82? I did not find it in changes log, but I have the >> feeling it should be :-) >> >> It?s in b83. >> >> Roland.= > From roland.westrelin at oracle.com Mon Oct 5 09:01:22 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 5 Oct 2015 11:01:22 +0200 Subject: RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server compiler In-Reply-To: <06e001d0ff48$427d23d0$c7776b70$@apache.org> References: <53037D5B-7CA1-493C-837B-AF502ADFDF83@oracle.com> <55E721C6.2000206@oracle.com> <066d01d0fecf$f4f42230$dedc6690$@apache.org> <06e001d0ff48$427d23d0$c7776b70$@apache.org> Message-ID: <82C6CE6C-1B2D-490C-9A0F-DE4132EDFE46@oracle.com> Uwe, > Thanks. I was trying b82 yesterday and we already found a new bug. Tests were failing with SIGSEGV on Jenkins: > http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14121/ > (you can download "hs_err" and "replay" from there, you can also see JVM settings like bitness, Garbage Collector from there). Thanks for reporting this new issue. > > Current CompileTask: > C2: 866319 28632 4 org.apache.directory.api.ldap.model.name.Rdn::apply (45 bytes) > > Stack: [0x00007f3e647e6000,0x00007f3e648e7000], sp=0x00007f3e648e1e60, free space=1007k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x80ccce] PhaseIdealLoop::build_loop_late_post(Node*)+0x13e > V [libjvm.so+0x80d06b] PhaseIdealLoop::build_loop_late(VectorSet&, Node_List&, Node_Stack&)+0x13b > V [libjvm.so+0x8102dc] PhaseIdealLoop::build_and_optimize(bool, bool)+0x88c > V [libjvm.so+0x4e699a] Compile::Optimize()+0x6ca > V [libjvm.so+0x4e83f0] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0x1040 > V [libjvm.so+0x42dbb9] C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0xe9 > V [libjvm.so+0x4effda] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x8ca > V [libjvm.so+0x4f0a58] CompileBroker::compiler_thread_loop()+0x4a8 > V [libjvm.so+0xa61038] JavaThread::thread_main_inner()+0xd8 > V [libjvm.so+0xa611d8] JavaThread::run()+0x158 > V [libjvm.so+0x9048e2] java_start(Thread*)+0xc2 > C [libpthread.so.0+0x8182] start_thread+0xc2 > > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000008 > > > This happened in parallel for 2 different JVMs (we are running tests in parallel with multiple JVMs). We should look into this, too! Tell me how I can help (as always, it is hard to reproduce). So this must be some change between b78 and b82 (b78 is last known working config). Maybe bells are ringing for you. It looks like it could be: https://bugs.openjdk.java.net/browse/JDK-8134974 Can you reproduce the issue at all? Roland. From roland.westrelin at oracle.com Mon Oct 5 09:12:10 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 5 Oct 2015 11:12:10 +0200 Subject: RFR(S): 8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI In-Reply-To: <56122D8D.1050909@oracle.com> References: <7B89ADB9-1DF9-4DE2-85C8-0ADFF34A3190@oracle.com> <55F99D08.3010204@oracle.com> <4DAAADBF-9A3C-46BD-9E86-29E9B5044FAA@oracle.com> <55F9AB59.6030604@oracle.com> <07AAF0D5-134D-4D85-BD4C-EA5049EF8857@oracle.com> <55FF5E26.1060008@oracle.com> <041EEDC9-D32F-420D-9D55-111499B13321@oracle.com> <9D17B19D-9A35-4EFE-B5F7-954629DA2FC2@oracle.com> <10866B0A-712E-4665-9CC3-838AE6536D4A@oracle.com> <56014EA4.50907@oracle.com> <56122D8D.1050909@oracle.com> Message-ID: Thanks for looking at this, Vladimir. > Mismatching access can be only for basic type as I understand. The code for mismatched = true could be rearranged by checking type != T_OBJECT first. People do such crazy things with Unsafe, I thought it was best to be prepared for anything. > Why you set mismatched only for array element? What about fields? You?re right, fields need to be handled the same way. > And next should be && I think (if you keep your code) > if (type != T_OBJECT || !element->isa_narrowoop()) Either we reach that test with a basic type that is not an object (type != T_OBJECT) and there?s a mismatch but if we have element->array_element_basic_type() = T_NARROWOOP and type = T_OBJECT, then there?s no mismatch. Roland. > > Thanks, > Vladimir > > On 9/28/15 11:44 PM, Roland Westrelin wrote: >> That fix wasn?t sufficient so here is a new webrev: >> >> http://cr.openjdk.java.net/~roland/8136473/webrev.02/ >> >> On platforms that don?t support unaligned accesses we still have mismatched accesses because the java code of Unsafe.putIntUnaligned() is implemented in terms of putShort() and putByte() so my test case fails on sparc. I added a new boolean to MemNode to record whether the node is ?mismatched? in addition to the ?unaligned? boolean. >> >> Roland. >> >>> On Sep 22, 2015, at 2:50 PM, Vladimir Kozlov wrote: >>> >>> Okay. >>> >>> Vladimir >>> >>> On 9/22/15 8:47 PM, Roland Westrelin wrote: >>>> For the record, it seems _unaligned is a reserved keyword for MSVC so I will change the field and function names to unaligned_access: >>>> >>>> diff --git a/src/share/vm/opto/memnode.hpp b/src/share/vm/opto/memnode.hpp >>>> --- a/src/share/vm/opto/memnode.hpp >>>> +++ b/src/share/vm/opto/memnode.hpp >>>> @@ -40,7 +40,7 @@ >>>> // Load or Store, possibly throwing a NULL pointer exception >>>> class MemNode : public Node { >>>> private: >>>> - bool _unaligned; >>>> + bool _unaligned_access; >>>> protected: >>>> #ifdef ASSERT >>>> const TypePtr* _adr_type; // What kind of memory is being addressed? >>>> >>>> @@ -129,8 +129,8 @@ >>>> // the given memory state? (The state may or may not be in(Memory).) >>>> Node* can_see_stored_value(Node* st, PhaseTransform* phase) const; >>>> >>>> - void set_unaligned() { _unaligned = true; } >>>> - bool is_unaligned() const { return _unaligned; } >>>> + void set_unaligned_access() { _unaligned_access = true; } >>>> + bool is_unaligned_access() const { return _unaligned_access; } >>>> >>>> #ifndef PRODUCT >>>> static void dump_adr_type(const Node* mem, const TypePtr* adr_type, outputStream *st); >>>> >>>> Roland. >>>> >>>>> On Sep 22, 2015, at 9:43 AM, Roland Westrelin wrote: >>>>> >>>>>> Roland I had a look too, the code looks good. >>>>> >>>>> Thanks, Michael. >>>>> >>>>> Roland. >>>>> >>>>>> >>>>>> -Michael >>>>>> >>>>>> -----Original Message----- >>>>>> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Roland Westrelin >>>>>> Sent: Monday, September 21, 2015 2:03 AM >>>>>> To: hotspot compiler >>>>>> Subject: Re: RFR(S): 8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI >>>>>> >>>>>> Thanks for the review, Vladimir. >>>>>> >>>>>> Roland. >>>>>> >>>>>>> On Sep 21, 2015, at 3:32 AM, Vladimir Kozlov wrote: >>>>>>> >>>>>>> This is good. Thank you for extending the test. >>>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>> On 9/18/15 11:03 PM, Roland Westrelin wrote: >>>>>>>>>>> Hmm, so you just relaxed the assert. You may need to fix EA too because it also checks for matching types(memory sizes). >>>>>>>>>>> I remember we had problem with RAW accesses back when jsr292 was implemented. So EA gave up on RAW access and marks allocations as escaping. Also may be superword/vectorization will be affected. >>>>>>>>>>> >>>>>>>>>>> In general it is very bad for C2 to have different memory on the same non-RAW memory. >>>>>>>>>> >>>>>>>>>> It already happens with vectorization. Do you see another solution (rather than relaxing the assert)? Putting a MemBarCPUOrder before and after the unaligned store? >>>>>>>>> >>>>>>>>> MemBarCPUOrder are definitely will help and it is simplest solution but, I think, it is too drastic. >>>>>>>>> It affect control flow and other memory slices. >>>>>>>>> We can try to mark such memory accesses or/and mark objects which have such accesses (if it is possible) and prevent vectorization and scalarization for them only. We should be able execute optimization on other memory slices then. >>>>>>>> >>>>>>>> Here is a new change: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~roland/8136473/webrev.01/ >>>>>>>> >>>>>>>> Unaligned accesses are explicitly marked as such. >>>>>>>> >>>>>>>> I added a test case with a non escaping allocation and it works fine. I also added test case with vectorization and if the accesses are effectively unaligned vectorization doesn't happen. One of the test cases causes an assertion to fire when the allocation is expanded: the logic in InitializeNode::complete_stores() is confused by the unaligned store so I made sure unaligned stores are not captured by the initialization. >>>>>>>> >>>>>>>> Roland. >>>>>>>> >>>>>> >>>>> >>>> >> From uschindler at apache.org Mon Oct 5 09:44:38 2015 From: uschindler at apache.org (Uwe Schindler) Date: Mon, 5 Oct 2015 11:44:38 +0200 Subject: RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server compiler In-Reply-To: <82C6CE6C-1B2D-490C-9A0F-DE4132EDFE46@oracle.com> References: <53037D5B-7CA1-493C-837B-AF502ADFDF83@oracle.com> <55E721C6.2000206@oracle.com> <066d01d0fecf$f4f42230$dedc6690$@apache.org> <06e001d0ff48$427d23d0$c7776b70$@apache.org> <82C6CE6C-1B2D-490C-9A0F-DE4132EDFE46@oracle.com> Message-ID: <06f801d0ff52$767fc2f0$637f48d0$@apache.org> Hi, I will try to reproduce. This happened in 2 different JVMs at the same time at same underlying Java code, so I assume that this must be somehow reproducible. Unfortunately the test failure happens in Apache Solr (which is the server based on Lucene and it's much more hard to debug this). As the stack trace for both failures always displays the same signature, it could be a problem only with Apache Directory API (https://directory.apache.org/), which may reproduce by running their tests. I will report back. Do you know when the fix for JDK-8134974 is included in EA builds? If yes, maybe we first try to check if it's already fixed. Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Roland Westrelin [mailto:roland.westrelin at oracle.com] > Sent: Monday, October 05, 2015 11:01 AM > To: Uwe Schindler > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server > compiler > > Uwe, > > > Thanks. I was trying b82 yesterday and we already found a new bug. Tests > were failing with SIGSEGV on Jenkins: > > http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14121/ > > (you can download "hs_err" and "replay" from there, you can also see JVM > settings like bitness, Garbage Collector from there). > > Thanks for reporting this new issue. > > > > > Current CompileTask: > > C2: 866319 28632 4 > org.apache.directory.api.ldap.model.name.Rdn::apply (45 bytes) > > > > Stack: [0x00007f3e647e6000,0x00007f3e648e7000], > > sp=0x00007f3e648e1e60, free space=1007k Native frames: (J=compiled > > Java code, j=interpreted, Vv=VM code, C=native code) V > > [libjvm.so+0x80ccce] > > PhaseIdealLoop::build_loop_late_post(Node*)+0x13e > > V [libjvm.so+0x80d06b] PhaseIdealLoop::build_loop_late(VectorSet&, > > Node_List&, Node_Stack&)+0x13b V [libjvm.so+0x8102dc] > > PhaseIdealLoop::build_and_optimize(bool, bool)+0x88c V > > [libjvm.so+0x4e699a] Compile::Optimize()+0x6ca V > > [libjvm.so+0x4e83f0] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, > > int, bool, bool, bool)+0x1040 V [libjvm.so+0x42dbb9] > > C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0xe9 V > > [libjvm.so+0x4effda] > > CompileBroker::invoke_compiler_on_method(CompileTask*)+0x8ca > > V [libjvm.so+0x4f0a58] CompileBroker::compiler_thread_loop()+0x4a8 > > V [libjvm.so+0xa61038] JavaThread::thread_main_inner()+0xd8 > > V [libjvm.so+0xa611d8] JavaThread::run()+0x158 V > > [libjvm.so+0x9048e2] java_start(Thread*)+0xc2 C > > [libpthread.so.0+0x8182] start_thread+0xc2 > > > > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: > > 0x0000000000000008 > > > > > > This happened in parallel for 2 different JVMs (we are running tests in > parallel with multiple JVMs). We should look into this, too! Tell me how I can > help (as always, it is hard to reproduce). So this must be some change > between b78 and b82 (b78 is last known working config). Maybe bells are > ringing for you. > > It looks like it could be: > > https://bugs.openjdk.java.net/browse/JDK-8134974 > > Can you reproduce the issue at all? > > Roland.= From roland.westrelin at oracle.com Mon Oct 5 09:55:16 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 5 Oct 2015 11:55:16 +0200 Subject: RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server compiler In-Reply-To: <06f801d0ff52$767fc2f0$637f48d0$@apache.org> References: <53037D5B-7CA1-493C-837B-AF502ADFDF83@oracle.com> <55E721C6.2000206@oracle.com> <066d01d0fecf$f4f42230$dedc6690$@apache.org> <06e001d0ff48$427d23d0$c7776b70$@apache.org> <82C6CE6C-1B2D-490C-9A0F-DE4132EDFE46@oracle.com> <06f801d0ff52$767fc2f0$637f48d0$@apache.org> Message-ID: <846C489A-B3DE-4E55-A5EC-C70146ADBF4E@oracle.com> > Do you know when the fix for JDK-8134974 is included in EA builds? If yes, maybe we first try to check if it's already fixed. b84 it seems. You could try to apply the fix, it?s small: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/bfb61f868681 Or we can wait until b84 is out and see if it?s still there. Roland. > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ > > >> -----Original Message----- >> From: Roland Westrelin [mailto:roland.westrelin at oracle.com] >> Sent: Monday, October 05, 2015 11:01 AM >> To: Uwe Schindler >> Cc: hotspot-compiler-dev at openjdk.java.net >> Subject: Re: RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server >> compiler >> >> Uwe, >> >>> Thanks. I was trying b82 yesterday and we already found a new bug. Tests >> were failing with SIGSEGV on Jenkins: >>> http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14121/ >>> (you can download "hs_err" and "replay" from there, you can also see JVM >> settings like bitness, Garbage Collector from there). >> >> Thanks for reporting this new issue. >> >>> >>> Current CompileTask: >>> C2: 866319 28632 4 >> org.apache.directory.api.ldap.model.name.Rdn::apply (45 bytes) >>> >>> Stack: [0x00007f3e647e6000,0x00007f3e648e7000], >>> sp=0x00007f3e648e1e60, free space=1007k Native frames: (J=compiled >>> Java code, j=interpreted, Vv=VM code, C=native code) V >>> [libjvm.so+0x80ccce] >>> PhaseIdealLoop::build_loop_late_post(Node*)+0x13e >>> V [libjvm.so+0x80d06b] PhaseIdealLoop::build_loop_late(VectorSet&, >>> Node_List&, Node_Stack&)+0x13b V [libjvm.so+0x8102dc] >>> PhaseIdealLoop::build_and_optimize(bool, bool)+0x88c V >>> [libjvm.so+0x4e699a] Compile::Optimize()+0x6ca V >>> [libjvm.so+0x4e83f0] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, >>> int, bool, bool, bool)+0x1040 V [libjvm.so+0x42dbb9] >>> C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0xe9 V >>> [libjvm.so+0x4effda] >>> CompileBroker::invoke_compiler_on_method(CompileTask*)+0x8ca >>> V [libjvm.so+0x4f0a58] CompileBroker::compiler_thread_loop()+0x4a8 >>> V [libjvm.so+0xa61038] JavaThread::thread_main_inner()+0xd8 >>> V [libjvm.so+0xa611d8] JavaThread::run()+0x158 V >>> [libjvm.so+0x9048e2] java_start(Thread*)+0xc2 C >>> [libpthread.so.0+0x8182] start_thread+0xc2 >>> >>> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: >>> 0x0000000000000008 >>> >>> >>> This happened in parallel for 2 different JVMs (we are running tests in >> parallel with multiple JVMs). We should look into this, too! Tell me how I can >> help (as always, it is hard to reproduce). So this must be some change >> between b78 and b82 (b78 is last known working config). Maybe bells are >> ringing for you. >> >> It looks like it could be: >> >> https://bugs.openjdk.java.net/browse/JDK-8134974 >> >> Can you reproduce the issue at all? >> >> Roland.= > From roland.westrelin at oracle.com Mon Oct 5 10:51:31 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 5 Oct 2015 12:51:31 +0200 Subject: Request for Reviews (S): JDK-8003585 strength reduce or eliminate range checks for power-of-two sized arrays In-Reply-To: <8232A81B-6B78-4F61-A8EC-1A3DF3938648@oracle.com> References: <440F2280-4B25-4AE6-A4F6-DDD4EB529636@oracle.com> <52FC129D.7040409@oracle.com> <52FE6A08.20400@oracle.com> <52FE7313.3060404@oracle.com> <530209A8.1020501@oracle.com> <38EE6922-0B9C-49A6-B54D-E78BA0EFECB1@oracle.com> <8232A81B-6B78-4F61-A8EC-1A3DF3938648@oracle.com> Message-ID: Here is a new webrev: http://cr.openjdk.java.net/~roland/8003585/webrev.01/ Roland. > On Oct 2, 2015, at 3:30 PM, Roland Westrelin wrote: > > Hi Chris, > >> Thanks for picking it up! It mostly looks good to me. (Not a Reviewer) > > Thanks for looking at this again. > >> What I really needed with my earlier webrev was some instructions as to what test to write -- since the Java corelibs can come across this optimization a lot (e.g. HashMap), I didn't have a good idea of what kind of test really needs to be written. >> >> A couple of issues with this webrev: >> >> 1. In subnode.cpp, line 1346: >> >> 1344 } else if (_test._test == BoolTest::lt && >> 1345 cmp2->Opcode() == Op_AddI && >> 1346 cmp2->in(2)->find_int_con(1)) { >> 1347 bound = cmp2->in(1); >> 1348 } >> >> I think it should be >> cmp2->in(2)->find_int_con(0) == 1 >> instead, because the value passed into this function is actually for a "fallback when no int constant is found". Passing the expected value (1) to it defeats the purpose. > > You?re right. Thanks for spotting that. > >> jint find_int_con(jint value_if_unknown) const { >> const TypeInt* t = find_int_type(); >> return (t != NULL && t->is_con()) ? t->get_con() : value_if_unknown; >> } >> >> 2. Formattign nitpick: could you please trim the spaces before the new's on lines 1368, 1369 and 1387 > > Sure. > > I?ll send an updated webrev. > > Roland. > >> >> Thanks, >> Kris (OpenJDK username: krismo) >> >> On Wed, Sep 30, 2015 at 1:34 AM, Roland Westrelin wrote: >> I?m picking that one up. Here is a new webrev: >> >> http://cr.openjdk.java.net/~roland/8003585/webrev.00/ >> >> The only change to c2 compared to the previous webrev is that ((x & m) u< m+1) is optimized the same way ((x & m) u<= m) is. Actually, I don?t think that C2 currently produces the ((x & m) u<= m) shape. The IfNode::fold_compares() logic produces the ((x & m) u< m+1) variant. I also added a test case to check the validity of the transformations and ran usual testing on the change. >> >> Roland. From vladimir.kozlov at oracle.com Mon Oct 5 11:22:02 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 5 Oct 2015 19:22:02 +0800 Subject: RFR(S): 8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI In-Reply-To: References: <7B89ADB9-1DF9-4DE2-85C8-0ADFF34A3190@oracle.com> <55F99D08.3010204@oracle.com> <4DAAADBF-9A3C-46BD-9E86-29E9B5044FAA@oracle.com> <55F9AB59.6030604@oracle.com> <07AAF0D5-134D-4D85-BD4C-EA5049EF8857@oracle.com> <55FF5E26.1060008@oracle.com> <041EEDC9-D32F-420D-9D55-111499B13321@oracle.com> <9D17B19D-9A35-4EFE-B5F7-954629DA2FC2@oracle.com> <10866B0A-712E-4665-9CC3-838AE6536D4A@oracle.com> <56014EA4.50907@oracle.com> <56122D8D.1050909@oracle.com> Message-ID: <56125D5A.7060708@oracle.com> So you are covering oops too. Okay then. Thanks, Vladimir On 10/5/15 5:12 PM, Roland Westrelin wrote: > Thanks for looking at this, Vladimir. > >> Mismatching access can be only for basic type as I understand. The code for mismatched = true could be rearranged by checking type != T_OBJECT first. > > People do such crazy things with Unsafe, I thought it was best to be prepared for anything. > >> Why you set mismatched only for array element? What about fields? > > You?re right, fields need to be handled the same way. > >> And next should be && I think (if you keep your code) >> if (type != T_OBJECT || !element->isa_narrowoop()) > > Either we reach that test with a basic type that is not an object (type != T_OBJECT) and there?s a mismatch but > if we have element->array_element_basic_type() = T_NARROWOOP and type = T_OBJECT, then there?s no mismatch. > > Roland. > >> >> Thanks, >> Vladimir >> >> On 9/28/15 11:44 PM, Roland Westrelin wrote: >>> That fix wasn?t sufficient so here is a new webrev: >>> >>> http://cr.openjdk.java.net/~roland/8136473/webrev.02/ >>> >>> On platforms that don?t support unaligned accesses we still have mismatched accesses because the java code of Unsafe.putIntUnaligned() is implemented in terms of putShort() and putByte() so my test case fails on sparc. I added a new boolean to MemNode to record whether the node is ?mismatched? in addition to the ?unaligned? boolean. >>> >>> Roland. >>> >>>> On Sep 22, 2015, at 2:50 PM, Vladimir Kozlov wrote: >>>> >>>> Okay. >>>> >>>> Vladimir >>>> >>>> On 9/22/15 8:47 PM, Roland Westrelin wrote: >>>>> For the record, it seems _unaligned is a reserved keyword for MSVC so I will change the field and function names to unaligned_access: >>>>> >>>>> diff --git a/src/share/vm/opto/memnode.hpp b/src/share/vm/opto/memnode.hpp >>>>> --- a/src/share/vm/opto/memnode.hpp >>>>> +++ b/src/share/vm/opto/memnode.hpp >>>>> @@ -40,7 +40,7 @@ >>>>> // Load or Store, possibly throwing a NULL pointer exception >>>>> class MemNode : public Node { >>>>> private: >>>>> - bool _unaligned; >>>>> + bool _unaligned_access; >>>>> protected: >>>>> #ifdef ASSERT >>>>> const TypePtr* _adr_type; // What kind of memory is being addressed? >>>>> >>>>> @@ -129,8 +129,8 @@ >>>>> // the given memory state? (The state may or may not be in(Memory).) >>>>> Node* can_see_stored_value(Node* st, PhaseTransform* phase) const; >>>>> >>>>> - void set_unaligned() { _unaligned = true; } >>>>> - bool is_unaligned() const { return _unaligned; } >>>>> + void set_unaligned_access() { _unaligned_access = true; } >>>>> + bool is_unaligned_access() const { return _unaligned_access; } >>>>> >>>>> #ifndef PRODUCT >>>>> static void dump_adr_type(const Node* mem, const TypePtr* adr_type, outputStream *st); >>>>> >>>>> Roland. >>>>> >>>>>> On Sep 22, 2015, at 9:43 AM, Roland Westrelin wrote: >>>>>> >>>>>>> Roland I had a look too, the code looks good. >>>>>> >>>>>> Thanks, Michael. >>>>>> >>>>>> Roland. >>>>>> >>>>>>> >>>>>>> -Michael >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Roland Westrelin >>>>>>> Sent: Monday, September 21, 2015 2:03 AM >>>>>>> To: hotspot compiler >>>>>>> Subject: Re: RFR(S): 8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI >>>>>>> >>>>>>> Thanks for the review, Vladimir. >>>>>>> >>>>>>> Roland. >>>>>>> >>>>>>>> On Sep 21, 2015, at 3:32 AM, Vladimir Kozlov wrote: >>>>>>>> >>>>>>>> This is good. Thank you for extending the test. >>>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 9/18/15 11:03 PM, Roland Westrelin wrote: >>>>>>>>>>>> Hmm, so you just relaxed the assert. You may need to fix EA too because it also checks for matching types(memory sizes). >>>>>>>>>>>> I remember we had problem with RAW accesses back when jsr292 was implemented. So EA gave up on RAW access and marks allocations as escaping. Also may be superword/vectorization will be affected. >>>>>>>>>>>> >>>>>>>>>>>> In general it is very bad for C2 to have different memory on the same non-RAW memory. >>>>>>>>>>> >>>>>>>>>>> It already happens with vectorization. Do you see another solution (rather than relaxing the assert)? Putting a MemBarCPUOrder before and after the unaligned store? >>>>>>>>>> >>>>>>>>>> MemBarCPUOrder are definitely will help and it is simplest solution but, I think, it is too drastic. >>>>>>>>>> It affect control flow and other memory slices. >>>>>>>>>> We can try to mark such memory accesses or/and mark objects which have such accesses (if it is possible) and prevent vectorization and scalarization for them only. We should be able execute optimization on other memory slices then. >>>>>>>>> >>>>>>>>> Here is a new change: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~roland/8136473/webrev.01/ >>>>>>>>> >>>>>>>>> Unaligned accesses are explicitly marked as such. >>>>>>>>> >>>>>>>>> I added a test case with a non escaping allocation and it works fine. I also added test case with vectorization and if the accesses are effectively unaligned vectorization doesn't happen. One of the test cases causes an assertion to fire when the allocation is expanded: the logic in InitializeNode::complete_stores() is confused by the unaligned store so I made sure unaligned stores are not captured by the initialization. >>>>>>>>> >>>>>>>>> Roland. >>>>>>>>> >>>>>>> >>>>>> >>>>> >>> > From nils.eliasson at oracle.com Mon Oct 5 12:27:20 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 5 Oct 2015 14:27:20 +0200 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: References: <56018E2B.2000108@oracle.com> <56055B50.4040304@oracle.com> <560D1D4A.8030001@oracle.com> Message-ID: <56126CA8.7060700@oracle.com> Hi, Thanks for finding. I fixed it by setting the Compile in the IdealGraphPrinter at the beginning of a compilation, and then removed the passing of Compile as an argument. Best regards, Nils Eliasson On 2015-10-01 16:48, Volker Simonis wrote: > Hi Nils, > > I've just found another problem with the IGV. After your changes it > will crash because you changed IdealGraphPrinter::should_print() to > use "C->dirset()->IGVPrintLevelOption >= level" but at the call sites > where should_print() is used the Compiler field of the IGV printer > isn't initialized. > > The quick hack attached below, which always passes the compiler object > to should_print() fixes the problem, but may you can up with something > better? > > And what about the InlineMatcherTest.java which I've already objected > in my previous mail. It still doesn't seem to work. How is it supposed > to be executed? > > Regards, > Volker > > diff -r 6fba102266ad src/share/vm/opto/compile.cpp > --- a/src/share/vm/opto/compile.cpp Thu Oct 01 16:24:12 2015 +0200 > +++ b/src/share/vm/opto/compile.cpp Thu Oct 01 16:40:46 2015 +0200 > @@ -838,7 +838,7 @@ > // Drain the list. > Finish_Warm(); > #ifndef PRODUCT > - if (_printer && _printer->should_print(1)) { > + if (_printer && _printer->should_print(C, 1)) { > _printer->print_inlining(this); > } > #endif > diff -r 6fba102266ad src/share/vm/opto/compile.hpp > --- a/src/share/vm/opto/compile.hpp Thu Oct 01 16:24:12 2015 +0200 > +++ b/src/share/vm/opto/compile.hpp Thu Oct 01 16:40:46 2015 +0200 > @@ -691,7 +691,7 @@ > > void begin_method() { > #ifndef PRODUCT > - if (_printer && _printer->should_print(1)) { > + if (_printer && _printer->should_print(C, 1)) { > _printer->begin_method(this); > } > #endif > @@ -710,7 +710,7 @@ > > > #ifndef PRODUCT > - if (_printer && _printer->should_print(level)) { > + if (_printer && _printer->should_print(C, level)) { > _printer->print_method(this, > CompilerPhaseTypeHelper::to_string(cpt), level); > } > #endif > @@ -727,7 +727,7 @@ > event.commit(); > } > #ifndef PRODUCT > - if (_printer && _printer->should_print(level)) { > + if (_printer && _printer->should_print(C, level)) { > _printer->end_method(); > } > #endif > diff -r 6fba102266ad src/share/vm/opto/idealGraphPrinter.cpp > --- a/src/share/vm/opto/idealGraphPrinter.cpp Thu Oct 01 16:24:12 > 2015 +0200 > +++ b/src/share/vm/opto/idealGraphPrinter.cpp Thu Oct 01 16:40:46 > 2015 +0200 > @@ -669,7 +669,7 @@ > // Print current ideal graph > void IdealGraphPrinter::print(Compile* compile, const char *name, > Node *node, int level, bool clear_nodes) { > > - if (!_current_method || !_should_send_method || > !should_print(level)) return; > + if (!_current_method || !_should_send_method || > !should_print(compile, level)) return; > > this->C = compile; > > @@ -722,8 +722,8 @@ > } > > // Should method be printed? > -bool IdealGraphPrinter::should_print(int level) { > - return C->dirset()->IGVPrintLevelOption >= level; > +bool IdealGraphPrinter::should_print(Compile* compile, int level) { > + return compile->dirset()->IGVPrintLevelOption >= level; > } > > extern const char *NodeClassNames[]; > diff -r 6fba102266ad src/share/vm/opto/idealGraphPrinter.hpp > --- a/src/share/vm/opto/idealGraphPrinter.hpp Thu Oct 01 16:24:12 > 2015 +0200 > +++ b/src/share/vm/opto/idealGraphPrinter.hpp Thu Oct 01 16:40:46 > 2015 +0200 > @@ -133,7 +133,7 @@ > void print_method(Compile* compile, const char *name, int level=1, > bool clear_nodes = false); > void print(Compile* compile, const char *name, Node *root, int > level=1, bool clear_nodes = false); > void print_xml(const char *name); > - bool should_print(int level); > + bool should_print(Compile* compile, int level); > }; > > #endif > diff -r 6fba102266ad src/share/vm/opto/parse2.cpp > --- a/src/share/vm/opto/parse2.cpp Thu Oct 01 16:24:12 2015 +0200 > +++ b/src/share/vm/opto/parse2.cpp Thu Oct 01 16:40:46 2015 +0200 > @@ -2379,7 +2379,7 @@ > > #ifndef PRODUCT > IdealGraphPrinter *printer = IdealGraphPrinter::printer(); > - if (printer && printer->should_print(1)) { > + if (printer && printer->should_print(C, 1)) { > char buffer[256]; > sprintf(buffer, "Bytecode %d: %s", bci(), Bytecodes::name(bc())); > bool old = printer->traverse_outs(); > > On Thu, Oct 1, 2015 at 1:47 PM, Nils Eliasson > > wrote: > > Hi Roland, > > On 2015-09-28 12:02, Roland Westrelin wrote: > > Hi Nils, > > http://cr.openjdk.java.net/~neliasso/8046155/webrev.03/ > > > What does CompileCommandCompatibility do? > > > Control backwards compatibility with CompileCommand for testing > purposes. I 'll change the name to the moee descriptive > CompilerDirectivesIgnoreCompileCommands (default false). > > > vm_operations.cpp > > Is that extra include really needed? > > No, removed. > > > CompilerQueueTest.java > > Is that extra import really needed? > > No, removed. > > > block.hpp > > You don?t need that ciEnv here, right? > > No, left over from when the directives was stored in the viEnv. > > > compileBroker.cpp > > 1717 should_break = dirset->BreakAtExecuteOption || > task->check_break_at_flags(); > > doesn?t seem to be used > > Except for those minor issues, looks good to me. > > Fixed. > > > > - Won't build c1 only or shark only. > > You can?t push if c1 only doesn?t build, right? > > > It was just a temporary glitch that is fixed now. > > Thanks, > Nils > > > Roland. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hui.shi at linaro.org Mon Oct 5 13:14:45 2015 From: hui.shi at linaro.org (Hui Shi) Date: Mon, 5 Oct 2015 21:14:45 +0800 Subject: RFR: Elide more final field's write memory barrier with escape analysis result Message-ID: Would some one please help review and comments this change? MemBarRelease for final field write can be removed when its allocation doesn't escape thread, allocation node can be acquired from its MemBarNode::Precedent input. Currently, MemBarRelase's Precedent input is only added when eliminate_boxing is true and its owning object is primitive Box (see Parse::do_put_xxx and Parse::do_exits). Checking OpenJDK log, this is added for autoboxing elimination early. Now I suggest turn on this optimization for general object type, this can benefit RMO platform (like aarch64) performance. This patch is not trivial, so put it at http://people.linaro.org/~hui.shi/membar_precedent/membar_precedent.patch Patch removes constraints for set_alloc_with_final(obj) in do_put_xxx (parse3.cpp). This leads to adding Precedent input for all kind object's final field writes' MemBarRelase node. Then they have opportunities to get optimized. In TestString small case, String object is allocated but not escaped in bar. Checking TestString_base.txt and TestString_fix.txt. Without this patch, Memory barrier is not removed even object allocation is optimized out. http://people.linaro.org/~hui.shi/membar_precedent/TestString.java http://people.linaro.org/~hui.shi/membar_precedent/TestString_base.txt http://people.linaro.org/~hui.shi/membar_precedent/TestString_fix.txt All kind object's final/stable field store's MemBarRelease node has chance to be optimized when its allocation doesn't escape thread. It?s safe based on following 4 pre-conditions: 1. Only MemBarRelease created for final/stable field store has MemBarNode::Precedent input. 2. MemBarRelease nodes' MemBarNode::Precedent input is only used in MemBarNode.Ideal, removing MemBarRelease when allocation doesn't escape. 3. MemBarRelease's MemBarNode::Precedent input is correctly set with final/stable field's owning object allocation if exist. 4. Escape analysis result is correct. Extra changes in patch target the 3rd pre-condition. In Parse::do_put_xxx, alloc_with_final is set and used for both final and Stable fields write. As final field can only be written in owning class initializer, but Stable field can be written in any method. There might be issues when writing both final and Stable field (could be stable field from different allocation) in same initializer method. 1. Stable field and final field has different owning object, it trigger assertions in set_alloc_with_final (different allocation objs). 2. If final field's allocation doesn't escape and stable field's allocation is unknown, both MemBarRelased node will be removed as they use same final field's allocation as Precedent input. Above issues can be reproduced with http://people.linaro.org/~hui.shi/membar_precedent/TestStable.java These issue can't be reproduced with current implementation, because alloc_with_final is only set in primitive box type initializer and no final and stable field both written cases there. Issues become visible with my change. So I suggest re-factor final and stable field handling here. Add an alloc_with_stable field for stable field write's MemBarRelease Precedent input, initialize as NodeSentinel. If stable field's allocation node is conflict or unknown, set it as NULL. Another small issue for MemBarRelease node created for volatile field write on PPC64. Volatile field?s owning object might be different with final field?s allocation. When MemBarRelease is removed because final field's allocation doesn?t escape, still need keep MemBarRelease for volatile write. Solution is using NULL as MemBarRelase node precedent input when wrote volatile is true. Regards Shi Hui -------------- next part -------------- An HTML attachment was scrubbed... URL: From nils.eliasson at oracle.com Mon Oct 5 14:25:05 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 5 Oct 2015 16:25:05 +0200 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: <56126CA8.7060700@oracle.com> References: <56018E2B.2000108@oracle.com> <56055B50.4040304@oracle.com> <560D1D4A.8030001@oracle.com> <56126CA8.7060700@oracle.com> Message-ID: <56128841.2@oracle.com> New webrev here: http://cr.openjdk.java.net/~neliasso/8046155/webrev.06/ Regards Nils On 2015-10-05 14:27, Nils Eliasson wrote: > Hi, > > Thanks for finding. > > I fixed it by setting the Compile in the IdealGraphPrinter at the > beginning of a compilation, and then removed the passing of Compile as > an argument. > > Best regards, > Nils Eliasson > > On 2015-10-01 16:48, Volker Simonis wrote: >> Hi Nils, >> >> I've just found another problem with the IGV. After your changes it >> will crash because you changed IdealGraphPrinter::should_print() to >> use "C->dirset()->IGVPrintLevelOption >= level" but at the call sites >> where should_print() is used the Compiler field of the IGV printer >> isn't initialized. >> >> The quick hack attached below, which always passes the compiler >> object to should_print() fixes the problem, but may you can up with >> something better? >> >> And what about the InlineMatcherTest.java which I've already objected >> in my previous mail. It still doesn't seem to work. How is it >> supposed to be executed? >> >> Regards, >> Volker >> >> diff -r 6fba102266ad src/share/vm/opto/compile.cpp >> --- a/src/share/vm/opto/compile.cpp Thu Oct 01 16:24:12 2015 +0200 >> +++ b/src/share/vm/opto/compile.cpp Thu Oct 01 16:40:46 2015 +0200 >> @@ -838,7 +838,7 @@ >> // Drain the list. >> Finish_Warm(); >> #ifndef PRODUCT >> - if (_printer && _printer->should_print(1)) { >> + if (_printer && _printer->should_print(C, 1)) { >> _printer->print_inlining(this); >> } >> #endif >> diff -r 6fba102266ad src/share/vm/opto/compile.hpp >> --- a/src/share/vm/opto/compile.hpp Thu Oct 01 16:24:12 2015 +0200 >> +++ b/src/share/vm/opto/compile.hpp Thu Oct 01 16:40:46 2015 +0200 >> @@ -691,7 +691,7 @@ >> >> void begin_method() { >> #ifndef PRODUCT >> - if (_printer && _printer->should_print(1)) { >> + if (_printer && _printer->should_print(C, 1)) { >> _printer->begin_method(this); >> } >> #endif >> @@ -710,7 +710,7 @@ >> >> >> #ifndef PRODUCT >> - if (_printer && _printer->should_print(level)) { >> + if (_printer && _printer->should_print(C, level)) { >> _printer->print_method(this, >> CompilerPhaseTypeHelper::to_string(cpt), level); >> } >> #endif >> @@ -727,7 +727,7 @@ >> event.commit(); >> } >> #ifndef PRODUCT >> - if (_printer && _printer->should_print(level)) { >> + if (_printer && _printer->should_print(C, level)) { >> _printer->end_method(); >> } >> #endif >> diff -r 6fba102266ad src/share/vm/opto/idealGraphPrinter.cpp >> --- a/src/share/vm/opto/idealGraphPrinter.cpp Thu Oct 01 16:24:12 >> 2015 +0200 >> +++ b/src/share/vm/opto/idealGraphPrinter.cpp Thu Oct 01 16:40:46 >> 2015 +0200 >> @@ -669,7 +669,7 @@ >> // Print current ideal graph >> void IdealGraphPrinter::print(Compile* compile, const char *name, >> Node *node, int level, bool clear_nodes) { >> >> - if (!_current_method || !_should_send_method || >> !should_print(level)) return; >> + if (!_current_method || !_should_send_method || >> !should_print(compile, level)) return; >> >> this->C = compile; >> >> @@ -722,8 +722,8 @@ >> } >> >> // Should method be printed? >> -bool IdealGraphPrinter::should_print(int level) { >> - return C->dirset()->IGVPrintLevelOption >= level; >> +bool IdealGraphPrinter::should_print(Compile* compile, int level) { >> + return compile->dirset()->IGVPrintLevelOption >= level; >> } >> >> extern const char *NodeClassNames[]; >> diff -r 6fba102266ad src/share/vm/opto/idealGraphPrinter.hpp >> --- a/src/share/vm/opto/idealGraphPrinter.hpp Thu Oct 01 16:24:12 >> 2015 +0200 >> +++ b/src/share/vm/opto/idealGraphPrinter.hpp Thu Oct 01 16:40:46 >> 2015 +0200 >> @@ -133,7 +133,7 @@ >> void print_method(Compile* compile, const char *name, int level=1, >> bool clear_nodes = false); >> void print(Compile* compile, const char *name, Node *root, int >> level=1, bool clear_nodes = false); >> void print_xml(const char *name); >> - bool should_print(int level); >> + bool should_print(Compile* compile, int level); >> }; >> >> #endif >> diff -r 6fba102266ad src/share/vm/opto/parse2.cpp >> --- a/src/share/vm/opto/parse2.cpp Thu Oct 01 16:24:12 2015 +0200 >> +++ b/src/share/vm/opto/parse2.cpp Thu Oct 01 16:40:46 2015 +0200 >> @@ -2379,7 +2379,7 @@ >> >> #ifndef PRODUCT >> IdealGraphPrinter *printer = IdealGraphPrinter::printer(); >> - if (printer && printer->should_print(1)) { >> + if (printer && printer->should_print(C, 1)) { >> char buffer[256]; >> sprintf(buffer, "Bytecode %d: %s", bci(), Bytecodes::name(bc())); >> bool old = printer->traverse_outs(); >> >> On Thu, Oct 1, 2015 at 1:47 PM, Nils Eliasson >> > wrote: >> >> Hi Roland, >> >> On 2015-09-28 12:02, Roland Westrelin wrote: >> >> Hi Nils, >> >> http://cr.openjdk.java.net/~neliasso/8046155/webrev.03/ >> >> >> What does CompileCommandCompatibility do? >> >> >> Control backwards compatibility with CompileCommand for testing >> purposes. I 'll change the name to the moee descriptive >> CompilerDirectivesIgnoreCompileCommands (default false). >> >> >> vm_operations.cpp >> >> Is that extra include really needed? >> >> No, removed. >> >> >> CompilerQueueTest.java >> >> Is that extra import really needed? >> >> No, removed. >> >> >> block.hpp >> >> You don?t need that ciEnv here, right? >> >> No, left over from when the directives was stored in the viEnv. >> >> >> compileBroker.cpp >> >> 1717 should_break = dirset->BreakAtExecuteOption || >> task->check_break_at_flags(); >> >> doesn?t seem to be used >> >> Except for those minor issues, looks good to me. >> >> Fixed. >> >> >> >> - Won't build c1 only or shark only. >> >> You can?t push if c1 only doesn?t build, right? >> >> >> It was just a temporary glitch that is fixed now. >> >> Thanks, >> Nils >> >> >> Roland. >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Mon Oct 5 14:43:06 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 5 Oct 2015 16:43:06 +0200 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: <56128841.2@oracle.com> References: <56018E2B.2000108@oracle.com> <56055B50.4040304@oracle.com> <560D1D4A.8030001@oracle.com> <56126CA8.7060700@oracle.com> <56128841.2@oracle.com> Message-ID: Hi Nils, the IGV printing seems to work fine now. Thanks for fixing it! But I?ve also noticed another change of the previous default behaviour for printing methods which are not compiled. Before, if I used the 'compileonly' command and PrintCompilation the VM only printed the compilation of the requested method. Now, by default it prints all the methods which have been excluded from the compilation. I don't know if this was done intentionally, but in my opinion it is annoying and I'd appreciate if you could restore the original behaviour (although this could also be worked around by using the 'quite' command). This is the old code: -bool CompilerOracle::should_exclude(methodHandle method, bool& quietly) { - quietly = true; ... if (lists[CompileOnlyCommand] != NULL) { return !lists[CompileOnlyCommand]->match(method); } which returned "quietly=true" for methods not in the CompileOnlyCommand list. This is the new code: +bool CompilerOracle::should_exclude(methodHandle method) { + if (check_predicate(ExcludeCommand, method)) { + return true; } if (lists[CompileOnlyCommand] != NULL) { return !lists[CompileOnlyCommand]->match(method); } Here, quietly is not touched but instead the new method should_exclude_quietly() is used later on which returns "quiet=false". Regards, Volker On Mon, Oct 5, 2015 at 4:25 PM, Nils Eliasson wrote: > New webrev here: > http://cr.openjdk.java.net/~neliasso/8046155/webrev.06/ > > Regards > Nils > > > On 2015-10-05 14:27, Nils Eliasson wrote: > > Hi, > > Thanks for finding. > > I fixed it by setting the Compile in the IdealGraphPrinter at the beginning > of a compilation, and then removed the passing of Compile as an argument. > > Best regards, > Nils Eliasson > > On 2015-10-01 16:48, Volker Simonis wrote: > > Hi Nils, > > I've just found another problem with the IGV. After your changes it will > crash because you changed IdealGraphPrinter::should_print() to use > "C->dirset()->IGVPrintLevelOption >= level" but at the call sites where > should_print() is used the Compiler field of the IGV printer isn't > initialized. > > The quick hack attached below, which always passes the compiler object to > should_print() fixes the problem, but may you can up with something better? > > And what about the InlineMatcherTest.java which I've already objected in my > previous mail. It still doesn't seem to work. How is it supposed to be > executed? > > Regards, > Volker > > diff -r 6fba102266ad src/share/vm/opto/compile.cpp > --- a/src/share/vm/opto/compile.cpp Thu Oct 01 16:24:12 2015 +0200 > +++ b/src/share/vm/opto/compile.cpp Thu Oct 01 16:40:46 2015 +0200 > @@ -838,7 +838,7 @@ > // Drain the list. > Finish_Warm(); > #ifndef PRODUCT > - if (_printer && _printer->should_print(1)) { > + if (_printer && _printer->should_print(C, 1)) { > _printer->print_inlining(this); > } > #endif > diff -r 6fba102266ad src/share/vm/opto/compile.hpp > --- a/src/share/vm/opto/compile.hpp Thu Oct 01 16:24:12 2015 +0200 > +++ b/src/share/vm/opto/compile.hpp Thu Oct 01 16:40:46 2015 +0200 > @@ -691,7 +691,7 @@ > > void begin_method() { > #ifndef PRODUCT > - if (_printer && _printer->should_print(1)) { > + if (_printer && _printer->should_print(C, 1)) { > _printer->begin_method(this); > } > #endif > @@ -710,7 +710,7 @@ > > > #ifndef PRODUCT > - if (_printer && _printer->should_print(level)) { > + if (_printer && _printer->should_print(C, level)) { > _printer->print_method(this, CompilerPhaseTypeHelper::to_string(cpt), > level); > } > #endif > @@ -727,7 +727,7 @@ > event.commit(); > } > #ifndef PRODUCT > - if (_printer && _printer->should_print(level)) { > + if (_printer && _printer->should_print(C, level)) { > _printer->end_method(); > } > #endif > diff -r 6fba102266ad src/share/vm/opto/idealGraphPrinter.cpp > --- a/src/share/vm/opto/idealGraphPrinter.cpp Thu Oct 01 16:24:12 2015 > +0200 > +++ b/src/share/vm/opto/idealGraphPrinter.cpp Thu Oct 01 16:40:46 2015 > +0200 > @@ -669,7 +669,7 @@ > // Print current ideal graph > void IdealGraphPrinter::print(Compile* compile, const char *name, Node > *node, int level, bool clear_nodes) { > > - if (!_current_method || !_should_send_method || !should_print(level)) > return; > + if (!_current_method || !_should_send_method || !should_print(compile, > level)) return; > > this->C = compile; > > @@ -722,8 +722,8 @@ > } > > // Should method be printed? > -bool IdealGraphPrinter::should_print(int level) { > - return C->dirset()->IGVPrintLevelOption >= level; > +bool IdealGraphPrinter::should_print(Compile* compile, int level) { > + return compile->dirset()->IGVPrintLevelOption >= level; > } > > extern const char *NodeClassNames[]; > diff -r 6fba102266ad src/share/vm/opto/idealGraphPrinter.hpp > --- a/src/share/vm/opto/idealGraphPrinter.hpp Thu Oct 01 16:24:12 2015 > +0200 > +++ b/src/share/vm/opto/idealGraphPrinter.hpp Thu Oct 01 16:40:46 2015 > +0200 > @@ -133,7 +133,7 @@ > void print_method(Compile* compile, const char *name, int level=1, bool > clear_nodes = false); > void print(Compile* compile, const char *name, Node *root, int level=1, > bool clear_nodes = false); > void print_xml(const char *name); > - bool should_print(int level); > + bool should_print(Compile* compile, int level); > }; > > #endif > diff -r 6fba102266ad src/share/vm/opto/parse2.cpp > --- a/src/share/vm/opto/parse2.cpp Thu Oct 01 16:24:12 2015 +0200 > +++ b/src/share/vm/opto/parse2.cpp Thu Oct 01 16:40:46 2015 +0200 > @@ -2379,7 +2379,7 @@ > > #ifndef PRODUCT > IdealGraphPrinter *printer = IdealGraphPrinter::printer(); > - if (printer && printer->should_print(1)) { > + if (printer && printer->should_print(C, 1)) { > char buffer[256]; > sprintf(buffer, "Bytecode %d: %s", bci(), Bytecodes::name(bc())); > bool old = printer->traverse_outs(); > > On Thu, Oct 1, 2015 at 1:47 PM, Nils Eliasson > wrote: >> >> Hi Roland, >> >> On 2015-09-28 12:02, Roland Westrelin wrote: >>> >>> Hi Nils, >>> >>>> http://cr.openjdk.java.net/~neliasso/8046155/webrev.03/ >>> >>> What does CompileCommandCompatibility do? >> >> >> Control backwards compatibility with CompileCommand for testing purposes. >> I 'll change the name to the moee descriptive >> CompilerDirectivesIgnoreCompileCommands (default false). >>> >>> >>> vm_operations.cpp >>> >>> Is that extra include really needed? >> >> No, removed. >>> >>> >>> CompilerQueueTest.java >>> >>> Is that extra import really needed? >> >> No, removed. >> >>> >>> block.hpp >>> >>> You don?t need that ciEnv here, right? >> >> No, left over from when the directives was stored in the viEnv. >>> >>> >>> compileBroker.cpp >>> >>> 1717 should_break = dirset->BreakAtExecuteOption || >>> task->check_break_at_flags(); >>> >>> doesn?t seem to be used >>> >>> Except for those minor issues, looks good to me. >> >> Fixed. >>> >>> >>> >>>> - Won't build c1 only or shark only. >>> >>> You can?t push if c1 only doesn?t build, right? >> >> >> It was just a temporary glitch that is fixed now. >> >> Thanks, >> Nils >>> >>> >>> Roland. >> >> > > > From aph at redhat.com Mon Oct 5 16:18:14 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 5 Oct 2015 17:18:14 +0100 Subject: RFR: Elide more final field's write memory barrier with escape analysis result In-Reply-To: References: Message-ID: <5612A2C6.5080108@redhat.com> I like this patch. It seems to do the right thing, although it'll be necessary to check with jcstress and perhaps write a few more jcstress test cases to make sure that the right thing happens in all cases. Andrew. From jan.civlin at intel.com Tue Oct 6 01:54:22 2015 From: jan.civlin at intel.com (Civlin, Jan) Date: Tue, 6 Oct 2015 01:54:22 +0000 Subject: RFR(M): 8136725 Provide utility for creation a counted loop reserve copy (clone) In-Reply-To: <56122FD0.2050200@oracle.com> References: <012766EA-BDDF-4E0D-A01C-7B96591ABC64@oracle.com> <39F83597C33E5F408096702907E6C45005852375@ORSMSX104.amr.corp.intel.com> <56028117.50706@oracle.com> <39F83597C33E5F408096702907E6C4500585A55E@ORSMSX104.amr.corp.intel.com> <30A22020-0926-4C94-A44E-8CEA37565C96@oracle.com> <56122FD0.2050200@oracle.com> Message-ID: <39F83597C33E5F408096702907E6C4500585C111@ORSMSX104.amr.corp.intel.com> Vladimir, thank you for the review. Here is the updated patch. I decided to stick to simple if(TraceLoopOpts) condition for checking in printing, since these messages are printed on error only. Regards, Jan. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Monday, October 05, 2015 1:08 AM To: Civlin, Jan Cc: hotspot compiler Subject: Re: RFR(M): 8136725 Provide utility for creation a counted loop reserve copy (clone) remove .hgtags changes Trace outputs in create_reserve() are not under trace flag. I would suggest to remove them or put under TraceLoopOpts && Verbose combination. Also, please, split next and similar lines according to our code stile: if (!_lp_reserved->is_CountedLoop()) return false; --- if (!_lp_reserved->is_CountedLoop()) { return false; } The rest looks fine. Thanks, Vladimir On 10/1/15 4:31 AM, Igor Veresov wrote: > Here?s the updated webrev: > > http://cr.openjdk.java.net/~iveresov/loop-reverse/webrev.02/ > > igor > >> On Sep 28, 2015, at 2:25 AM, Civlin, Jan > > wrote: >> >> Vladimir, >> >> Thank you for the review. >> I'm attaching the patch reflecting your comments. >> >> Regards, >> >> Jan >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Wednesday, September 23, 2015 3:38 AM >> To: Civlin, Jan; hotspot compiler >> Subject: Re: RFR(M): 8136725 Provide utility for creation a counted >> loop reserve copy (clone) >> >> in loopUnswitch.cpp debug output should be under nonproduct flag >> (could be TraceLoopOpts or separate new flag). Use #ifndef PRODUCT >> around print code instead of repeated NOT_PRODUCT() macro. And I >> don't think you need all output you added in final version. >> >> All constants are IGVNed so you don't need to pre-generate const_0. >> Since it is not connected to graph it could be eliminated. >> And I don't think you need next for the same reason: >> >> 311 lk->set_const_0(const_0); >> 312 lk->set_const_1(const_1); >> >> In ~CountedLoopReserveKit() and switch_to_reserved() you can make new >> const_0 since you have pointer to IGVN: >> >> _phase->_igvn.intcon(0); >> >> You can't use subsume() since it will replace all users of const_1: >> >> + //TODO bug? could not use here _const_1->subsume_by(_const_0, >> _phase->C); >> >> It is correct to use set_req() for constants here. >> >> superword.cpp I don't think you need to keep >> _CountedLoopReserveKit_test code in final version after you verified it works during development: >> >> + //!/// Testing that switching to reserved copy works >> >> Thanks, >> Vladimir >> >> On 9/19/15 1:05 AM, Civlin, Jan wrote: >>> As I was working on modification of SuperWord::output - and this is >>> a function where you modify the ideal graph on the fly and cannot >>> exit on error - I was wondering how can I protect my algorithm in a >>> case some wrong decision was made on the previous stage of the >>> SuperWord but discovered only at the final stage, when the graph is >>> already half modified. >>> >>> So here is my solution: >>> - the graph to be modified is cloned. >>> - five nodes are added: intcon(0) is disconnected, intcon(1)->If-> >>> IfTrue->orig_loop: IfFalse->clone_loop. >>> >>> Then any optimization is executed on the original loop, and if it >>> finishes ok, nothing else need to be done, the clone_loop will be >>> removed as dead in the consecutive stages of compiler. >>> At any moment, if an error occurs, the node intcon(1) may be >>> subsumed by node intcon(0), therefore the clone_loop becomes >>> "active" and the original "unfinished in modification" loop will be removed later. >>> >>> This utility is implemented in class CountedLoopReserveKit. >>> The loop cloning and 5 nodes adding is realized in the ctor and >>> possible subsuming intcon(1) by intcon(0) in dtor, so a simple >>> return from the modifying graph function will do graph correction >>> (switching in choice) of the graph. >>> Basically, it is sufficient the create a local object of >>> CountedLoopReserveKit class, the scoped dtor makes the choice: >>> modified or original loop. >>> >>> SuperWord::output in this submission is included only to illustrate >>> how to use the CountedLoopReserveKit. >>> The actual new SuperWord::output where CountedLoopReserveKit is >>> indeed substantial is coming in the next patch. >>> >>> This reserve loop cloning in SuperWord may be disabled by the global >>> flag DoReserveCopyInSuperWord. >>> >>> -----Original Message----- >>> From: Igor Veresov [mailto:igor.veresov at oracle.com] >>> Sent: Thursday, September 17, 2015 2:31 PM >>> To: hotspot compiler >>> Cc: Civlin, Jan >>> Subject: RFR(M): 8136725 Provide utility for creation a counted loop >>> reserve copy (clone) >>> >>> Provide utility for creation a counted loop reserve copy (clone). >>> May be used in any graph optimization for simple roll back to the >>> original loop, in partially will be used in SuperWord, where the >>> loop modification goes on-the-fly and potentially may not finish >>> correctly (the patch for SuperWord is coming soon). >>> >>> This is contributed by Jan Civlin >> > >>> >>> Webrev: >>> http://cr.openjdk.java.net/~iveresov/loop-reverse/webrev-091515/ >>> >>> igor >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.westrelin at oracle.com Tue Oct 6 07:44:51 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 6 Oct 2015 09:44:51 +0200 Subject: RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server compiler In-Reply-To: <07e801d0ffb3$64a44360$2decca20$@thetaphi.de> References: <53037D5B-7CA1-493C-837B-AF502ADFDF83@oracle.com> <55E721C6.2000206@oracle.com> <066d01d0fecf$f4f42230$dedc6690$@apache.org> <06e001d0ff48$427d23d0$c7776b70$@apache.org> <82C6CE6C-1B2D-490C-9A0F-DE4132EDFE46@oracle.com> <06f801d0ff52$767fc2f0$637f48d0$@apache.org> <846C489A-B3DE-4E55-A5EC-C70146ADBF4E@oracle.com> <07e801d0ffb3$64a44360$2decca20$@thetaphi.de> Message-ID: > I got another failure with exactly same code: > > http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14421/ > > So it is definitely reproducible. I was not yet able to reproduce it or test your patch (I have not much experience in doing this). Maybe Dawid Weiss has some time to try it out. > I just wanted to let you know that it is reproducible. The above Jenkins link allows to download hserr.pid and replay logs, too. Thanks. The replay files are truncated AFAICT, so unusable. Unless this bug is blocking your work, I would recommend waiting until the fix for JDK-8134974 is available. Do you test the official EA builds only? Or do you build your own JDK? If that?s the case what repo do you clone? Roland. > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ > > >> -----Original Message----- >> From: Roland Westrelin [mailto:roland.westrelin at oracle.com] >> Sent: Monday, October 05, 2015 11:55 AM >> To: Uwe Schindler >> Cc: hotspot-compiler-dev at openjdk.java.net >> Subject: Re: RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server >> compiler >> >>> Do you know when the fix for JDK-8134974 is included in EA builds? If yes, >> maybe we first try to check if it's already fixed. >> >> b84 it seems. >> >> You could try to apply the fix, it?s small: >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/bfb61f868681 >> >> Or we can wait until b84 is out and see if it?s still there. >> >> Roland. >> >>> >>> Uwe >>> >>> ----- >>> Uwe Schindler >>> uschindler at apache.org >>> ASF Member, Apache Lucene PMC / Committer Bremen, Germany >>> http://lucene.apache.org/ >>> >>> >>>> -----Original Message----- >>>> From: Roland Westrelin [mailto:roland.westrelin at oracle.com] >>>> Sent: Monday, October 05, 2015 11:01 AM >>>> To: Uwe Schindler >>>> Cc: hotspot-compiler-dev at openjdk.java.net >>>> Subject: Re: RFR(S): 8134468: Lucene test failures with 32 bit JDK >>>> 9b78, Server compiler >>>> >>>> Uwe, >>>> >>>>> Thanks. I was trying b82 yesterday and we already found a new bug. >>>>> Tests >>>> were failing with SIGSEGV on Jenkins: >>>>> http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14121/ >>>>> (you can download "hs_err" and "replay" from there, you can also see >>>>> JVM >>>> settings like bitness, Garbage Collector from there). >>>> >>>> Thanks for reporting this new issue. >>>> >>>>> >>>>> Current CompileTask: >>>>> C2: 866319 28632 4 >>>> org.apache.directory.api.ldap.model.name.Rdn::apply (45 bytes) >>>>> >>>>> Stack: [0x00007f3e647e6000,0x00007f3e648e7000], >>>>> sp=0x00007f3e648e1e60, free space=1007k Native frames: (J=compiled >>>>> Java code, j=interpreted, Vv=VM code, C=native code) V >>>>> [libjvm.so+0x80ccce] >>>>> PhaseIdealLoop::build_loop_late_post(Node*)+0x13e >>>>> V [libjvm.so+0x80d06b] PhaseIdealLoop::build_loop_late(VectorSet&, >>>>> Node_List&, Node_Stack&)+0x13b V [libjvm.so+0x8102dc] >>>>> PhaseIdealLoop::build_and_optimize(bool, bool)+0x88c V >>>>> [libjvm.so+0x4e699a] Compile::Optimize()+0x6ca V >>>>> [libjvm.so+0x4e83f0] Compile::Compile(ciEnv*, C2Compiler*, >>>>> ciMethod*, int, bool, bool, bool)+0x1040 V [libjvm.so+0x42dbb9] >>>>> C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0xe9 V >>>>> [libjvm.so+0x4effda] >>>>> CompileBroker::invoke_compiler_on_method(CompileTask*)+0x8ca >>>>> V [libjvm.so+0x4f0a58] CompileBroker::compiler_thread_loop()+0x4a8 >>>>> V [libjvm.so+0xa61038] JavaThread::thread_main_inner()+0xd8 >>>>> V [libjvm.so+0xa611d8] JavaThread::run()+0x158 V >>>>> [libjvm.so+0x9048e2] java_start(Thread*)+0xc2 C >>>>> [libpthread.so.0+0x8182] start_thread+0xc2 >>>>> >>>>> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: >>>>> 0x0000000000000008 >>>>> >>>>> >>>>> This happened in parallel for 2 different JVMs (we are running tests >>>>> in >>>> parallel with multiple JVMs). We should look into this, too! Tell me >>>> how I can help (as always, it is hard to reproduce). So this must be >>>> some change between b78 and b82 (b78 is last known working config). >>>> Maybe bells are ringing for you. >>>> >>>> It looks like it could be: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8134974 >>>> >>>> Can you reproduce the issue at all? >>>> >>>> Roland.= >>> > From jan.civlin at intel.com Tue Oct 6 08:44:04 2015 From: jan.civlin at intel.com (Civlin, Jan) Date: Tue, 6 Oct 2015 08:44:04 +0000 Subject: RFR(M): 8136725 Provide utility for creation a counted loop reserve copy (clone) In-Reply-To: <39F83597C33E5F408096702907E6C4500585C111@ORSMSX104.amr.corp.intel.com> References: <012766EA-BDDF-4E0D-A01C-7B96591ABC64@oracle.com> <39F83597C33E5F408096702907E6C45005852375@ORSMSX104.amr.corp.intel.com> <56028117.50706@oracle.com> <39F83597C33E5F408096702907E6C4500585A55E@ORSMSX104.amr.corp.intel.com> <30A22020-0926-4C94-A44E-8CEA37565C96@oracle.com> <56122FD0.2050200@oracle.com> <39F83597C33E5F408096702907E6C4500585C111@ORSMSX104.amr.corp.intel.com> Message-ID: <39F83597C33E5F408096702907E6C4500585C2A5@ORSMSX104.amr.corp.intel.com> Seems the attached file was stripped by firewall. Trying to send again. -----Original Message----- From: Civlin, Jan Sent: Monday, October 5, 2015 6:54 PM To: Vladimir Kozlov Cc: hotspot compiler; Civlin, Jan Subject: RE: RFR(M): 8136725 Provide utility for creation a counted loop reserve copy (clone) Vladimir, thank you for the review. Here is the updated patch. I decided to stick to simple if(TraceLoopOpts) condition for checking in printing, since these messages are printed on error only. Regards, Jan. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Monday, October 05, 2015 1:08 AM To: Civlin, Jan Cc: hotspot compiler Subject: Re: RFR(M): 8136725 Provide utility for creation a counted loop reserve copy (clone) remove .hgtags changes Trace outputs in create_reserve() are not under trace flag. I would suggest to remove them or put under TraceLoopOpts && Verbose combination. Also, please, split next and similar lines according to our code stile: if (!_lp_reserved->is_CountedLoop()) return false; --- if (!_lp_reserved->is_CountedLoop()) { return false; } The rest looks fine. Thanks, Vladimir On 10/1/15 4:31 AM, Igor Veresov wrote: > Here?s the updated webrev: > > http://cr.openjdk.java.net/~iveresov/loop-reverse/webrev.02/ > > igor > >> On Sep 28, 2015, at 2:25 AM, Civlin, Jan > > wrote: >> >> Vladimir, >> >> Thank you for the review. >> I'm attaching the patch reflecting your comments. >> >> Regards, >> >> Jan >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Wednesday, September 23, 2015 3:38 AM >> To: Civlin, Jan; hotspot compiler >> Subject: Re: RFR(M): 8136725 Provide utility for creation a counted >> loop reserve copy (clone) >> >> in loopUnswitch.cpp debug output should be under nonproduct flag >> (could be TraceLoopOpts or separate new flag). Use #ifndef PRODUCT >> around print code instead of repeated NOT_PRODUCT() macro. And I >> don't think you need all output you added in final version. >> >> All constants are IGVNed so you don't need to pre-generate const_0. >> Since it is not connected to graph it could be eliminated. >> And I don't think you need next for the same reason: >> >> 311 lk->set_const_0(const_0); >> 312 lk->set_const_1(const_1); >> >> In ~CountedLoopReserveKit() and switch_to_reserved() you can make new >> const_0 since you have pointer to IGVN: >> >> _phase->_igvn.intcon(0); >> >> You can't use subsume() since it will replace all users of const_1: >> >> + //TODO bug? could not use here _const_1->subsume_by(_const_0, >> _phase->C); >> >> It is correct to use set_req() for constants here. >> >> superword.cpp I don't think you need to keep >> _CountedLoopReserveKit_test code in final version after you verified it works during development: >> >> + //!/// Testing that switching to reserved copy works >> >> Thanks, >> Vladimir >> >> On 9/19/15 1:05 AM, Civlin, Jan wrote: >>> As I was working on modification of SuperWord::output - and this is >>> a function where you modify the ideal graph on the fly and cannot >>> exit on error - I was wondering how can I protect my algorithm in a >>> case some wrong decision was made on the previous stage of the >>> SuperWord but discovered only at the final stage, when the graph is >>> already half modified. >>> >>> So here is my solution: >>> - the graph to be modified is cloned. >>> - five nodes are added: intcon(0) is disconnected, intcon(1)->If-> >>> IfTrue->orig_loop: IfFalse->clone_loop. >>> >>> Then any optimization is executed on the original loop, and if it >>> finishes ok, nothing else need to be done, the clone_loop will be >>> removed as dead in the consecutive stages of compiler. >>> At any moment, if an error occurs, the node intcon(1) may be >>> subsumed by node intcon(0), therefore the clone_loop becomes >>> "active" and the original "unfinished in modification" loop will be removed later. >>> >>> This utility is implemented in class CountedLoopReserveKit. >>> The loop cloning and 5 nodes adding is realized in the ctor and >>> possible subsuming intcon(1) by intcon(0) in dtor, so a simple >>> return from the modifying graph function will do graph correction >>> (switching in choice) of the graph. >>> Basically, it is sufficient the create a local object of >>> CountedLoopReserveKit class, the scoped dtor makes the choice: >>> modified or original loop. >>> >>> SuperWord::output in this submission is included only to illustrate >>> how to use the CountedLoopReserveKit. >>> The actual new SuperWord::output where CountedLoopReserveKit is >>> indeed substantial is coming in the next patch. >>> >>> This reserve loop cloning in SuperWord may be disabled by the global >>> flag DoReserveCopyInSuperWord. >>> >>> -----Original Message----- >>> From: Igor Veresov [mailto:igor.veresov at oracle.com] >>> Sent: Thursday, September 17, 2015 2:31 PM >>> To: hotspot compiler >>> Cc: Civlin, Jan >>> Subject: RFR(M): 8136725 Provide utility for creation a counted loop >>> reserve copy (clone) >>> >>> Provide utility for creation a counted loop reserve copy (clone). >>> May be used in any graph optimization for simple roll back to the >>> original loop, in partially will be used in SuperWord, where the >>> loop modification goes on-the-fly and potentially may not finish >>> correctly (the patch for SuperWord is coming soon). >>> >>> This is contributed by Jan Civlin >> > >>> >>> Webrev: >>> http://cr.openjdk.java.net/~iveresov/loop-reverse/webrev-091515/ >>> >>> igor >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uschindler at apache.org Tue Oct 6 08:44:11 2015 From: uschindler at apache.org (Uwe Schindler) Date: Tue, 6 Oct 2015 10:44:11 +0200 Subject: RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server compiler In-Reply-To: References: <53037D5B-7CA1-493C-837B-AF502ADFDF83@oracle.com> <55E721C6.2000206@oracle.com> <066d01d0fecf$f4f42230$dedc6690$@apache.org> <06e001d0ff48$427d23d0$c7776b70$@apache.org> <82C6CE6C-1B2D-490C-9A0F-DE4132EDFE46@oracle.com> <06f801d0ff52$767fc2f0$637f48d0$@apache.org> <846C489A-B3DE-4E55-A5EC-C70146ADBF4E@oracle.com> <07e801d0ffb3$64a44360$2decca20$@thetaphi.de> Message-ID: <088901d10013$2e92db50$8bb891f0$@apache.org> Hi, > > I got another failure with exactly same code: > > > > http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14421/ > > > > So it is definitely reproducible. I was not yet able to reproduce it or test > your patch (I have not much experience in doing this). Maybe Dawid Weiss > has some time to try it out. > > I just wanted to let you know that it is reproducible. The above Jenkins link > allows to download hserr.pid and replay logs, too. > > Thanks. > The replay files are truncated AFAICT, so unusable. Is this our fault or a general problem with the JDK replay files? The files were archived by Jenkins, so I have no idea what could truncate them. > Unless this bug is blocking your work, I would recommend waiting until the > fix for JDK-8134974 is available. OK. That's fine. I may disable b82 testing, but the errors don't happen too often, so it is still good to test the other stuff thoroughly. > Do you test the official EA builds only? Or do you build your own JDK? If that?s > the case what repo do you clone? I am downloading the official builds from jdk9.java.net. We also tested Jigsaw, but not yet regularily, because there are some minor problems with Apache Solr. Uwe From tobias.hartmann at oracle.com Tue Oct 6 09:15:53 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 06 Oct 2015 11:15:53 +0200 Subject: [9] RFR(S): 8136469: OptimizeStringConcat fails on pre-sized StringBuilder shapes In-Reply-To: References: <55FBDFEC.4060405@oracle.com> Message-ID: <56139149.5080906@oracle.com> Thanks, Roland! Sorry for the delay, I was busy with other work. On 22.09.2015 15:04, Roland Westrelin wrote: > So why don?t we run PhaseStringOpts after IGVN? We do that for incremental inlining so we know the PhaseStringOpts code is robust enough to be run after IGVN, now. Maybe it wasn?t initially. I also suspect that it initially wasn't robust enough. Seems like you did some changes with JDK-8005071 to make it work after IGVN: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009266.html However, I would prefer not to change the order of optimization phases here but it's probably worth to investigate. > Maybe we could add an IfProjNode::Ideal method that disconnects the other branch of the If when this branch is always taken and that does so even during parsing. Given Ideal is called before Identity, that would guarantee the next call to Identity optimizes the If out. As you suggested, I added an IfProjNode::Ideal that disconnects the never taken branch from the IfNode. The subsequent call to Identity then removes the IfNode: http://cr.openjdk.java.net/~thartmann/8136469/webrev.03/ However, I wondered if this is "legal" because the comment in Node::ideal says: // The Ideal call almost arbitrarily reshape the graph rooted at the 'this' // pointer. But we are changing the graph "above" the this pointer. I executed tests with -XX:+VerifyIterativeGVN and everything seems to work fine. Another solution would be to cut the *current* branch if it is never taken: http://cr.openjdk.java.net/~thartmann/8136469/webrev.02/ But this solution depends on the assumption that we execute the identity() of the other ProjNode which is not guaranteed by GVN (I think). Therefore I would like to go for webrev.03. I verified that this solves the problem and tested the fix with JPRT. Best, Tobias From zoltan.majo at oracle.com Tue Oct 6 11:45:19 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 6 Oct 2015 13:45:19 +0200 Subject: [9] RFR(M): 8078554: Compiler: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <4502D8F6-B256-4222-B1D3-92ED5C100B6E@oracle.com> References: <560BB4F6.3050703@oracle.com> <4502D8F6-B256-4222-B1D3-92ED5C100B6E@oracle.com> Message-ID: <5613B44F.4090007@oracle.com> Hi Roland, thank you for the feedback! On 10/02/2015 03:55 PM, Roland Westrelin wrote: > Hi Zoltan, > >> Webrev:http://cr.openjdk.java.net/~zmajo/8078554/ > c2_globals.hpp > > That one is not correct: > 461 product(intx, MaxNodeLimit, 80000, \ > 462 "Maximum number of nodes") \ > 463 range(1000, 80000) \ > > I think the upper bound should be max_juint You are right that the limit of 80'000 is too conservative. But max_j*u*int as an upper bound would cause an overflow when parsing the flag's value, because on 32-bit machines intx is a 32-bit signed integer. Using max_jint instead of max_j*u*int as an upper bound would not cause an overflow at parse time. However, in Parse::do_call() the maximum node limit is increased by 3 times for jsr292 users C->set_max_node_limit(3*MaxNodeLimit); If MaxNodeLimit == max_jint, this expression will overflow, I think. So I set the limit to (max_jint / 3) in the updated webrev. If we would set MaxNodeLimit to max_j*u*int / 3 (instead of max_jint / 3), the expression 3 * MaxNodeLimit would overflow as well. Changing the type of the flag from intx to uintx could let use use max_j*u*int / 3 as an upper bound, but that is most likely not worth the effort. > 699 product(intx, LiveNodeCountInliningCutoff, 40000, \ > 700 "max number of live nodes in a method") \ > 701 range(0, max_juint / 8) \ > > Out of curiosity why max_juint / 8 (not that it makes much of a difference)? In Compile::inline_incrementally, the 80% of LiveNodeCountInliningCutoff is computed the following way: if (low_live_nodes < (uint)LiveNodeCountInliningCutoff * 8 / 10) { If LiveNodeCountInliningCutoff == max_juint, we'd have an overflow because of the multiplication by 8. > arguments.cpp > > 1099 Tier3InvokeNotifyFreqLog = 0; > 1100 Tier4InvocationThreshold = 0; > > Why that change? I proposed that change because I misread the code. I reverted that change and also changed the range of all Tier*FreqLog flags from range(1, 30) to range(0, 30). > globals.hp > > 2870 product_pd(uintx, TypeProfileLevel, \ > 2871 "=XYZ, with Z: Type profiling of arguments at call; " \ > 2872 "Y: Type profiling of return value at call; " \ > 2873 "X: Type profiling of parameters to methods; " \ > 2874 "X, Y and Z in 0=off ; 1=jsr292 only; 2=all methods") \ > 2875 range(0, 222) > > Legal values are 0, 1, 2, 10, 11, 12, 100, 101, 102, 110, 111, 112 etc. > > 70 is not for instance. So range(0, 222) is incorrect. I agree. I removed the range check and implemented a constraint function instead (TypeProfileLevelConstraintFunc). > 2877 product(intx, TypeProfileArgsLimit, 2, \ > 2878 "max number of call arguments to consider for type profiling") \ > 2879 range(0, 16) \ > > 2880 \ > 2881 product(intx, TypeProfileParmsLimit, 2, \ > 2882 "max number of incoming parameters to consider for type profiling"\ > 2883 ", -1 for all") \ > 2884 range(-1, 64) > > Why 16 and 64? These are the largest values that work on all platforms we support. Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8078554/webrev.01/ I repeated the testing with JPRT. I also executed the currently disabled TestOptionsWithRanges.java test on all platforms we support. All tests pass. Thank you and best regards, Zoltan > Roland. From nils.eliasson at oracle.com Tue Oct 6 11:54:39 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 6 Oct 2015 13:54:39 +0200 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: References: <56018E2B.2000108@oracle.com> <56055B50.4040304@oracle.com> <560D1D4A.8030001@oracle.com> <56126CA8.7060700@oracle.com> <56128841.2@oracle.com> Message-ID: <5613B67F.1050703@oracle.com> Hi Volker, Yes, this is a difference. The old implementation makes difference between compileonly and exclude, and that it is difficult keeping that distinction and at the same time create a new compatibility layer from the new. A problem is that if I mute it by default, then there is no way to turn it on. (Only a quiet command.) That problem remains for the old implementation. Regards, Nils On 2015-10-05 16:43, Volker Simonis wrote: > Hi Nils, > > the IGV printing seems to work fine now. Thanks for fixing it! > > But I?ve also noticed another change of the previous default behaviour > for printing methods which are not compiled. > > Before, if I used the 'compileonly' command and PrintCompilation the > VM only printed the compilation of the requested method. Now, by > default it prints all the methods which have been excluded from the > compilation. I don't know if this was done intentionally, but in my > opinion it is annoying and I'd appreciate if you could restore the > original behaviour (although this could also be worked around by using > the 'quite' command). > > This is the old code: > > -bool CompilerOracle::should_exclude(methodHandle method, bool& quietly) { > - quietly = true; > ... > if (lists[CompileOnlyCommand] != NULL) { > return !lists[CompileOnlyCommand]->match(method); > } > > which returned "quietly=true" for methods not in the CompileOnlyCommand list. > > This is the new code: > > +bool CompilerOracle::should_exclude(methodHandle method) { > + if (check_predicate(ExcludeCommand, method)) { > + return true; > } > if (lists[CompileOnlyCommand] != NULL) { > return !lists[CompileOnlyCommand]->match(method); > } > > Here, quietly is not touched but instead the new method > should_exclude_quietly() is used later on which returns "quiet=false". > > Regards, > Volker > > > On Mon, Oct 5, 2015 at 4:25 PM, Nils Eliasson wrote: >> New webrev here: >> http://cr.openjdk.java.net/~neliasso/8046155/webrev.06/ >> >> Regards >> Nils >> >> >> On 2015-10-05 14:27, Nils Eliasson wrote: >> >> Hi, >> >> Thanks for finding. >> >> I fixed it by setting the Compile in the IdealGraphPrinter at the beginning >> of a compilation, and then removed the passing of Compile as an argument. >> >> Best regards, >> Nils Eliasson >> >> On 2015-10-01 16:48, Volker Simonis wrote: >> >> Hi Nils, >> >> I've just found another problem with the IGV. After your changes it will >> crash because you changed IdealGraphPrinter::should_print() to use >> "C->dirset()->IGVPrintLevelOption >= level" but at the call sites where >> should_print() is used the Compiler field of the IGV printer isn't >> initialized. >> >> The quick hack attached below, which always passes the compiler object to >> should_print() fixes the problem, but may you can up with something better? >> >> And what about the InlineMatcherTest.java which I've already objected in my >> previous mail. It still doesn't seem to work. How is it supposed to be >> executed? >> >> Regards, >> Volker >> >> diff -r 6fba102266ad src/share/vm/opto/compile.cpp >> --- a/src/share/vm/opto/compile.cpp Thu Oct 01 16:24:12 2015 +0200 >> +++ b/src/share/vm/opto/compile.cpp Thu Oct 01 16:40:46 2015 +0200 >> @@ -838,7 +838,7 @@ >> // Drain the list. >> Finish_Warm(); >> #ifndef PRODUCT >> - if (_printer && _printer->should_print(1)) { >> + if (_printer && _printer->should_print(C, 1)) { >> _printer->print_inlining(this); >> } >> #endif >> diff -r 6fba102266ad src/share/vm/opto/compile.hpp >> --- a/src/share/vm/opto/compile.hpp Thu Oct 01 16:24:12 2015 +0200 >> +++ b/src/share/vm/opto/compile.hpp Thu Oct 01 16:40:46 2015 +0200 >> @@ -691,7 +691,7 @@ >> >> void begin_method() { >> #ifndef PRODUCT >> - if (_printer && _printer->should_print(1)) { >> + if (_printer && _printer->should_print(C, 1)) { >> _printer->begin_method(this); >> } >> #endif >> @@ -710,7 +710,7 @@ >> >> >> #ifndef PRODUCT >> - if (_printer && _printer->should_print(level)) { >> + if (_printer && _printer->should_print(C, level)) { >> _printer->print_method(this, CompilerPhaseTypeHelper::to_string(cpt), >> level); >> } >> #endif >> @@ -727,7 +727,7 @@ >> event.commit(); >> } >> #ifndef PRODUCT >> - if (_printer && _printer->should_print(level)) { >> + if (_printer && _printer->should_print(C, level)) { >> _printer->end_method(); >> } >> #endif >> diff -r 6fba102266ad src/share/vm/opto/idealGraphPrinter.cpp >> --- a/src/share/vm/opto/idealGraphPrinter.cpp Thu Oct 01 16:24:12 2015 >> +0200 >> +++ b/src/share/vm/opto/idealGraphPrinter.cpp Thu Oct 01 16:40:46 2015 >> +0200 >> @@ -669,7 +669,7 @@ >> // Print current ideal graph >> void IdealGraphPrinter::print(Compile* compile, const char *name, Node >> *node, int level, bool clear_nodes) { >> >> - if (!_current_method || !_should_send_method || !should_print(level)) >> return; >> + if (!_current_method || !_should_send_method || !should_print(compile, >> level)) return; >> >> this->C = compile; >> >> @@ -722,8 +722,8 @@ >> } >> >> // Should method be printed? >> -bool IdealGraphPrinter::should_print(int level) { >> - return C->dirset()->IGVPrintLevelOption >= level; >> +bool IdealGraphPrinter::should_print(Compile* compile, int level) { >> + return compile->dirset()->IGVPrintLevelOption >= level; >> } >> >> extern const char *NodeClassNames[]; >> diff -r 6fba102266ad src/share/vm/opto/idealGraphPrinter.hpp >> --- a/src/share/vm/opto/idealGraphPrinter.hpp Thu Oct 01 16:24:12 2015 >> +0200 >> +++ b/src/share/vm/opto/idealGraphPrinter.hpp Thu Oct 01 16:40:46 2015 >> +0200 >> @@ -133,7 +133,7 @@ >> void print_method(Compile* compile, const char *name, int level=1, bool >> clear_nodes = false); >> void print(Compile* compile, const char *name, Node *root, int level=1, >> bool clear_nodes = false); >> void print_xml(const char *name); >> - bool should_print(int level); >> + bool should_print(Compile* compile, int level); >> }; >> >> #endif >> diff -r 6fba102266ad src/share/vm/opto/parse2.cpp >> --- a/src/share/vm/opto/parse2.cpp Thu Oct 01 16:24:12 2015 +0200 >> +++ b/src/share/vm/opto/parse2.cpp Thu Oct 01 16:40:46 2015 +0200 >> @@ -2379,7 +2379,7 @@ >> >> #ifndef PRODUCT >> IdealGraphPrinter *printer = IdealGraphPrinter::printer(); >> - if (printer && printer->should_print(1)) { >> + if (printer && printer->should_print(C, 1)) { >> char buffer[256]; >> sprintf(buffer, "Bytecode %d: %s", bci(), Bytecodes::name(bc())); >> bool old = printer->traverse_outs(); >> >> On Thu, Oct 1, 2015 at 1:47 PM, Nils Eliasson >> wrote: >>> Hi Roland, >>> >>> On 2015-09-28 12:02, Roland Westrelin wrote: >>>> Hi Nils, >>>> >>>>> http://cr.openjdk.java.net/~neliasso/8046155/webrev.03/ >>>> What does CompileCommandCompatibility do? >>> >>> Control backwards compatibility with CompileCommand for testing purposes. >>> I 'll change the name to the moee descriptive >>> CompilerDirectivesIgnoreCompileCommands (default false). >>>> >>>> vm_operations.cpp >>>> >>>> Is that extra include really needed? >>> No, removed. >>>> >>>> CompilerQueueTest.java >>>> >>>> Is that extra import really needed? >>> No, removed. >>> >>>> block.hpp >>>> >>>> You don?t need that ciEnv here, right? >>> No, left over from when the directives was stored in the viEnv. >>>> >>>> compileBroker.cpp >>>> >>>> 1717 should_break = dirset->BreakAtExecuteOption || >>>> task->check_break_at_flags(); >>>> >>>> doesn?t seem to be used >>>> >>>> Except for those minor issues, looks good to me. >>> Fixed. >>>> >>>> >>>>> - Won't build c1 only or shark only. >>>> You can?t push if c1 only doesn?t build, right? >>> >>> It was just a temporary glitch that is fixed now. >>> >>> Thanks, >>> Nils >>>> >>>> Roland. >>> >> >> From zoltan.majo at oracle.com Tue Oct 6 12:00:21 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 6 Oct 2015 14:00:21 +0200 Subject: [9] RFR(S): 8138651: -XX:DisableIntrinsic matches intrinsics overly eagerly Message-ID: <5613B7D5.5090702@oracle.com> Hi, please review the patch for JDK-8138651. https://bugs.openjdk.java.net/browse/JDK-8138651 Problem: The DisableIntrinsic flag does not disable intrinsics accurately. For example, -XX:DisableIntrinsic=_copyOfRange disables both the intrinsic with the ID _copyOfRange and the intrinsic with the _copyOf. Solution: Change the processing of the DisableIntrinsic flag (both globally and on a per-method level). Webrev: http://cr.openjdk.java.net/~zmajo/8138651/webrev.00/ Testing: - JPRT (testset hotspot); - executed the the newly added test compiler/intrinsics/IntrinsicDisabledTest.java with/without the fix on all platforms, the test behaves as expected. Thank you and best regards, Zoltan From hui.shi at linaro.org Tue Oct 6 12:52:50 2015 From: hui.shi at linaro.org (Hui Shi) Date: Tue, 6 Oct 2015 20:52:50 +0800 Subject: RFR: Elide more final field's write memory barrier with escape analysis result In-Reply-To: <5612A2C6.5080108@redhat.com> References: <5612A2C6.5080108@redhat.com> Message-ID: Thanks Andrew! This patch modifies share code. Except jcstress, would someone help sponsor and run JPRT? create webrev for this change (just got my openjdk id) http://cr.openjdk.java.net/~hshi/8138956/webrev/ Small test shows patch enhancement *http://cr.openjdk.java.net/~hshi/8138956/TestString.java * *http://cr.openjdk.java.net/~hshi/8138956/TestString_base.txt * *http://cr.openjdk.java.net/~hshi/8138956/TestString_fix.txt * Example shows stable field write needs code refactoring http://cr.openjdk.java.net/~hshi/8138956/TestStable.java Regards Shi Hui On 6 October 2015 at 00:18, Andrew Haley wrote: > I like this patch. It seems to do the right thing, although it'll > be necessary to check with jcstress and perhaps write a few more > jcstress test cases to make sure that the right thing happens in > all cases. > > Andrew. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Tue Oct 6 12:59:36 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 6 Oct 2015 12:59:36 +0000 Subject: C1 for PPC64 contribution Message-ID: <7C9B87B351A4BA4AA9EC95BB418116567226074C@DEWDFEMB19C.global.corp.sap> Hi, SAP has ported the C1 compiler to PPC64. To contribute it, we require to do some minor shared changes to C1. Some are bugfixes, others minor adaptions to support PPC64 specialities. We will send out RFRs for the following changes step by step: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete http://cr.openjdk.java.net/~mdoerr/8138891_c1_cms_membar http://cr.openjdk.java.net/~mdoerr/8138892_c1_counter_overflow http://cr.openjdk.java.net/~mdoerr/8138894_c1_IRIW http://cr.openjdk.java.net/~mdoerr/8138895_c1_syncLockOpr http://cr.openjdk.java.net/~mdoerr/8138896_c1_patching_fix http://cr.openjdk.java.net/~mdoerr/8138952_c1_PPC64_defs After this, we will contribute the changes to the ppc files in one blob. We would appreciate your help in reviewing and especially sponsoring! Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksey.shipilev at oracle.com Tue Oct 6 13:05:57 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 6 Oct 2015 16:05:57 +0300 Subject: [9] RFR(S): 8138651: -XX:DisableIntrinsic matches intrinsics overly eagerly In-Reply-To: <5613B7D5.5090702@oracle.com> References: <5613B7D5.5090702@oracle.com> Message-ID: <5613C735.60006@oracle.com> On 10/06/2015 03:00 PM, Zolt?n Maj? wrote: > https://bugs.openjdk.java.net/browse/JDK-8138651 > > Problem: The DisableIntrinsic flag does not disable intrinsics > accurately. For example, -XX:DisableIntrinsic=_copyOfRange disables both > the intrinsic with the ID _copyOfRange and the intrinsic with the _copyOf. > > Solution: Change the processing of the DisableIntrinsic flag (both > globally and on a per-method level). > > Webrev: http://cr.openjdk.java.net/~zmajo/8138651/webrev.00/ Thanks for fixing this annoyance, Zoltan! The patch looks good to me. A few comments: * Why do you need a copy of the list? Can't strtok operate on ccstr itself? * I think this collides with Nil's CompilerControl JEP a bit, that apparently moved/redone this part of compiler. Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From zoltan.majo at oracle.com Tue Oct 6 13:55:09 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 6 Oct 2015 15:55:09 +0200 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: <560E9050.6000804@oracle.com> References: <56018E2B.2000108@oracle.com> <560E9050.6000804@oracle.com> Message-ID: <5613D2BD.3040401@oracle.com> Hi Nils, Currently, there are two ways the the DisableIntrinsic flag can be used to disable intrinsics. 1) Intrinsics can be disabled globally, that is, the compilers are not allowed to "use" (e.g., inline) the intrinsic in any calling context. For example: -XX:DisableIntrinsic=_hashCode,_getClass disables two intrinsics globally. 2) Intrinsics can be disabled on a per-method level, that is, the compiler is not allowed to use the intrinsic if it is called from a specific method, but the compiler is still allowed to use the intrinsic otherwise. For example: -XX:CompileCommand=option,aClass::aMethod,ccstr,DisableIntrinsic,_hashCode disables intrinsification of _hashCode if it is called from aClass::aMethod (but not for any other call site of _hashCode). It seems to me that your changes preserve (1) but eliminate (2). Could you please explain to me why you remove the functionality of disabling intrinsics on a per-method level? Also, currently there are some comments describing the way the DisableIntrinsic flag works: - abstractCompiler.hpp: line 70--98: Please update the description to match the way DisableIntrinsic works with your changes; - vmSymbols.cpp: line 420; Please update the comment. Also, please also move part of that comment to the place where you check if intrinsics are disabled, as the method is_disabled_by_flags() does not check at the value of the DisableIntrinsic flag. Thank you and best regards, Zoltan On 10/02/2015 04:10 PM, Nils Eliasson wrote: > Hi all, > > A new webrev with all the feedback from reviewers and others. > > http://cr.openjdk.java.net/~neliasso/8046155/webrev.04/ > > - name changes as requested by christian > - various small bug fixes > - New tests for sanity testing flags and their behaviour with vm flags > and compile commands present > > Regards, > Nils > > On 2015-09-22 19:21, Nils Eliasson wrote: >> Hi, >> >> This is the initial RFR for JEP165: Compiler Control. This feature >> enables runtime manageable, method dependent compiler flags. >> (Immutable for the duration of a compilation.) >> >> The change includes: >> - A parser for the directives format (json like) including vmtests >> (json.cpp/hpp) >> - A component for construction of compiler directives >> (directivesParser.cpp/hpp) >> - The directives including the option definitions, default values and >> compilecommand relations (compilerDirectives.cpp/hpp) >> - Diagnostic commands for working with the directives - installing, >> removing, printing >> - Lots of small changes wherever we access flags or legacy >> compilecommands in the compiler >> >> Notes: >> The feature is documented in the JEP >> (https://bugs.openjdk.java.net/browse/JDK-8046155). >> >> Currently only a small amount of compiler flags are included in the >> change. The flags are a representative selection of different types >> targeting both compilers. All of them existed as CompilerOracle >> option commands. Two commands was not included in the directives due >> to time constraints - CompilerThresholdScaling and UseRTMLocks. Both >> are accessed from runtime (outside any compiler) and requires some >> special handling. (Solved but not implemented.) >> >> Full backwards compatibility with CompileCommands is implemented but >> can be turned off with flag -XX:CompileCommandCompatibilty. Also meta >> handling the compatibility flag by supporting it in the directives >> (test feature). >> >> The change contain some rough edges that will polished over the >> coming days. >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8046155 >> Hotspot webrev: http://cr.openjdk.java.net/~neliasso/8046155/webrev.01/ >> JDK webrev: http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.01/ >> >> Please review! >> >> Best regards, >> Nils Eliasson > From martin.doerr at sap.com Tue Oct 6 13:56:06 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 6 Oct 2015 13:56:06 +0000 Subject: RFR(S): 8138890: C1: Ambiguous operator delete Message-ID: <7C9B87B351A4BA4AA9EC95BB41811656722607B5@DEWDFEMB19C.global.corp.sap> Hi, xlC on AIX rejects to compile LIRGenerator and RangeCheckEliminator::Verification due to ambiguous operator delete which gets inherited from multiple base classes. This change is a prerequisite for our C1 on PPC64 contribution. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.00 Please review this change. I need a sponsor, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.westrelin at oracle.com Tue Oct 6 14:07:58 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 6 Oct 2015 16:07:58 +0200 Subject: RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server compiler In-Reply-To: <088901d10013$2e92db50$8bb891f0$@apache.org> References: <53037D5B-7CA1-493C-837B-AF502ADFDF83@oracle.com> <55E721C6.2000206@oracle.com> <066d01d0fecf$f4f42230$dedc6690$@apache.org> <06e001d0ff48$427d23d0$c7776b70$@apache.org> <82C6CE6C-1B2D-490C-9A0F-DE4132EDFE46@oracle.com> <06f801d0ff52$767fc2f0$637f48d0$@apache.org> <846C489A-B3DE-4E55-A5EC-C70146ADBF4E@oracle.com> <07e801d0ffb3$64a44360$2decca20$@thetaphi.de> <088901d10013$2e92db50$8bb891f0$@apache.org> Message-ID: <0344906B-B5DB-4A17-B891-BBB474CD3D23@oracle.com> >> The replay files are truncated AFAICT, so unusable. > > Is this our fault or a general problem with the JDK replay files? The files were archived by Jenkins, so I have no idea what could truncate them. I don?t think it?s your fault, I?ve seen it in our own testing sometimes. I don?t know what?s causing it. Roland. From zoltan.majo at oracle.com Tue Oct 6 14:16:04 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 6 Oct 2015 16:16:04 +0200 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: <560E9050.6000804@oracle.com> References: <56018E2B.2000108@oracle.com> <560E9050.6000804@oracle.com> Message-ID: <5613D7A4.6010205@oracle.com> Hi, there is another question that comes to my mind. For command-line flags that allow per-method usage you propose to get the flag's value from the directive instead of getting the value using ciMethod()::has_option_value(). For example, you propose to use _vector_loop_debug = directive()->VectorizeDebugOption; instead of method()->has_option_value("VectorizeDebug", _vector_loop_debug); You propose to do this for almost all flags (e.g., VectorizeDebug, DisableIntrinsic, MaxNodeLimit, PrintIdealGraphLevel) except one, CompileThresholdScaling. Could you please explain why? Thank you and best regards, Zoltan On 10/02/2015 04:10 PM, Nils Eliasson wrote: > Hi all, > > A new webrev with all the feedback from reviewers and others. > > http://cr.openjdk.java.net/~neliasso/8046155/webrev.04/ > > - name changes as requested by christian > - various small bug fixes > - New tests for sanity testing flags and their behaviour with vm flags > and compile commands present > > Regards, > Nils > > On 2015-09-22 19:21, Nils Eliasson wrote: >> Hi, >> >> This is the initial RFR for JEP165: Compiler Control. This feature >> enables runtime manageable, method dependent compiler flags. >> (Immutable for the duration of a compilation.) >> >> The change includes: >> - A parser for the directives format (json like) including vmtests >> (json.cpp/hpp) >> - A component for construction of compiler directives >> (directivesParser.cpp/hpp) >> - The directives including the option definitions, default values and >> compilecommand relations (compilerDirectives.cpp/hpp) >> - Diagnostic commands for working with the directives - installing, >> removing, printing >> - Lots of small changes wherever we access flags or legacy >> compilecommands in the compiler >> >> Notes: >> The feature is documented in the JEP >> (https://bugs.openjdk.java.net/browse/JDK-8046155). >> >> Currently only a small amount of compiler flags are included in the >> change. The flags are a representative selection of different types >> targeting both compilers. All of them existed as CompilerOracle >> option commands. Two commands was not included in the directives due >> to time constraints - CompilerThresholdScaling and UseRTMLocks. Both >> are accessed from runtime (outside any compiler) and requires some >> special handling. (Solved but not implemented.) >> >> Full backwards compatibility with CompileCommands is implemented but >> can be turned off with flag -XX:CompileCommandCompatibilty. Also meta >> handling the compatibility flag by supporting it in the directives >> (test feature). >> >> The change contain some rough edges that will polished over the >> coming days. >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8046155 >> Hotspot webrev: http://cr.openjdk.java.net/~neliasso/8046155/webrev.01/ >> JDK webrev: http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.01/ >> >> Please review! >> >> Best regards, >> Nils Eliasson > From martin.doerr at sap.com Tue Oct 6 14:24:05 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 6 Oct 2015 14:24:05 +0000 Subject: RFR(XS) 8138891: C1: Missing release memory barrier in C1's CMS post-barrier Message-ID: <7C9B87B351A4BA4AA9EC95BB41811656722607F8@DEWDFEMB19C.global.corp.sap> Hi, the dirty marking of the card table needs to be a releasing store for CMS. It's already there in template interpreter and C2 on PPC64. We have seen GC crashed when testing C1 on PPC64. Unfortunately, C1 does currently not support releasing stores (or load-acquire) which could be exploited on aarch64 or ia64. Hence, we're using a membar_store_store. This change is a prerequisite for our C1 on PPC64 contribution. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8138891_c1_cms_membar/webrev.00 Please review this change. I need a sponsor, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From nils.eliasson at oracle.com Tue Oct 6 16:57:44 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 06 Oct 2015 18:57:44 +0200 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: <5613D2BD.3040401@oracle.com> References: <56018E2B.2000108@oracle.com> <560E9050.6000804@oracle.com> <5613D2BD.3040401@oracle.com> Message-ID: <5613FD88.9020505@oracle.com> Hi Zoltan, On 2015-10-06 15:55, Zolt?n Maj? wrote: > Hi Nils, > > > Currently, there are two ways the the DisableIntrinsic flag can be > used to disable intrinsics. > > 1) Intrinsics can be disabled globally, that is, the compilers are not > allowed to "use" (e.g., inline) the intrinsic in any calling context. > For example: > > -XX:DisableIntrinsic=_hashCode,_getClass > > disables two intrinsics globally. > > 2) Intrinsics can be disabled on a per-method level, that is, the > compiler is not allowed to use the intrinsic if it is called from a > specific method, but the compiler is still allowed to use the > intrinsic otherwise. For example: > overri > -XX:CompileCommand=option,aClass::aMethod,ccstr,DisableIntrinsic,_hashCode > > > disables intrinsification of _hashCode if it is called from > aClass::aMethod (but not for any other call site of _hashCode). > > It seems to me that your changes preserve (1) but eliminate (2). Could > you please explain to me why you remove the functionality of disabling > intrinsics on a per-method level? It isn't removed :) The option is as you say available as a VM flag and as an per method CompileCommand option. Compiler Directives has full compatibility with this with one small exception. 1) The global vm flag "-XX:DisableIntrinsic=_hashCode,_getClass " is added as the default value to all directives. 2) CompileCommand option " -XX:CompileCommand=option,aClass::aMethod,ccstr,DisableIntrinsic,_hashCode " overrides this if the method is matching. That matching is taking place in compilecommand_compatibility_init(). This happens after a directive is choosen because the directive and compile command may have different matches. 3) Any CompilerDirective that set this flag will override both above. The difference is that you where able to forbid the union of the intrinsics in the vmflag and the one from the compilecommand. Now CompileCommand overrides the vmflag. This is how all the other options that are available as vmflags and compilecommand works. I haven't seen this in any test or use case - but if this is a problem I could make a custom workaround for this option that appends the two sets. CompilerDirectives will always override since you want to be able to remove any flag that is set. The table at the beginning of compilerDirectives.hpp declares all options, their default values (sometimes vmflags, sometimes constants) and any compilecommand that must be checked. > > Also, currently there are some comments describing the way the > DisableIntrinsic flag works: > - abstractCompiler.hpp: line 70--98: Please update the description to > match the way DisableIntrinsic works with your changes; > - vmSymbols.cpp: line 420; Please update the comment. Also, please > also move part of that comment to the place where you check if > intrinsics are disabled, as the method is_disabled_by_flags() does not > check at the value of the DisableIntrinsic flag. Ok, I'll check and update the comments. Thanks for looking at my code! Best regards, Nils Eliasson > > Thank you and best regards, > > > Zoltan > > > On 10/02/2015 04:10 PM, Nils Eliasson wrote: >> Hi all, >> >> A new webrev with all the feedback from reviewers and others. >> >> http://cr.openjdk.java.net/~neliasso/8046155/webrev.04/ >> >> - name changes as requested by christian >> - various small bug fixes >> - New tests for sanity testing flags and their behaviour with vm >> flags and compile commands present >> >> Regards, >> Nils >> >> On 2015-09-22 19:21, Nils Eliasson wrote: >>> Hi, >>> >>> This is the initial RFR for JEP165: Compiler Control. This feature >>> enables runtime manageable, method dependent compiler flags. >>> (Immutable for the duration of a compilation.) >>> >>> The change includes: >>> - A parser for the directives format (json like) including vmtests >>> (json.cpp/hpp) >>> - A component for construction of compiler directives >>> (directivesParser.cpp/hpp) >>> - The directives including the option definitions, default values >>> and compilecommand relations (compilerDirectives.cpp/hpp) >>> - Diagnostic commands for working with the directives - installing, >>> removing, printing >>> - Lots of small changes wherever we access flags or legacy >>> compilecommands in the compiler >>> >>> Notes: >>> The feature is documented in the JEP >>> (https://bugs.openjdk.java.net/browse/JDK-8046155). >>> >>> Currently only a small amount of compiler flags are included in the >>> change. The flags are a representative selection of different types >>> targeting both compilers. All of them existed as CompilerOracle >>> option commands. Two commands was not included in the directives due >>> to time constraints - CompilerThresholdScaling and UseRTMLocks. Both >>> are accessed from runtime (outside any compiler) and requires some >>> special handling. (Solved but not implemented.) >>> >>> Full backwards compatibility with CompileCommands is implemented but >>> can be turned off with flag -XX:CompileCommandCompatibilty. Also >>> meta handling the compatibility flag by supporting it in the >>> directives (test feature). >>> >>> The change contain some rough edges that will polished over the >>> coming days. >>> >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8046155 >>> Hotspot webrev: http://cr.openjdk.java.net/~neliasso/8046155/webrev.01/ >>> JDK webrev: http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.01/ >>> >>> Please review! >>> >>> Best regards, >>> Nils Eliasson >> > From nils.eliasson at oracle.com Tue Oct 6 17:06:09 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 06 Oct 2015 19:06:09 +0200 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: <5613D7A4.6010205@oracle.com> References: <56018E2B.2000108@oracle.com> <560E9050.6000804@oracle.com> <5613D7A4.6010205@oracle.com> Message-ID: <5613FF81.9070304@oracle.com> Hi Zoltan, All the CompileCommand options work in the same way as described in the intrinsics-mail. In compilerDirectives.hpp the flags are declared with their CompileCommand equivalent. And in compilecommand_compatibility_init the directives may be updated with these flags. Take a look at test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityCommandOn.java for an example of how it can work. First these are set on the commandline "-XX:-PrintAssembly -XX:CompileCommand=print,*.*", then in the test a directive is loaded that turns it off. Later the directive is removed. The result is verified at each step. I hope my explanation is understandable. Best regards, Nils Eliasson On 2015-10-06 16:16, Zolt?n Maj? wrote: > Hi, > > > there is another question that comes to my mind. > > For command-line flags that allow per-method usage you propose to get > the flag's value from the directive instead of getting the value using > ciMethod()::has_option_value(). For example, you propose to use > > _vector_loop_debug = directive()->VectorizeDebugOption; > > instead of > > method()->has_option_value("VectorizeDebug", _vector_loop_debug); > > You propose to do this for almost all flags (e.g., VectorizeDebug, > DisableIntrinsic, MaxNodeLimit, PrintIdealGraphLevel) except one, > CompileThresholdScaling. Could you please explain why? > > Thank you and best regards, > > > Zoltan > > On 10/02/2015 04:10 PM, Nils Eliasson wrote: >> Hi all, >> >> A new webrev with all the feedback from reviewers and others. >> >> http://cr.openjdk.java.net/~neliasso/8046155/webrev.04/ >> >> - name changes as requested by christian >> - various small bug fixes >> - New tests for sanity testing flags and their behaviour with vm >> flags and compile commands present >> >> Regards, >> Nils >> >> On 2015-09-22 19:21, Nils Eliasson wrote: >>> Hi, >>> >>> This is the initial RFR for JEP165: Compiler Control. This feature >>> enables runtime manageable, method dependent compiler flags. >>> (Immutable for the duration of a compilation.) >>> >>> The change includes: >>> - A parser for the directives format (json like) including vmtests >>> (json.cpp/hpp) >>> - A component for construction of compiler directives >>> (directivesParser.cpp/hpp) >>> - The directives including the option definitions, default values >>> and compilecommand relations (compilerDirectives.cpp/hpp) >>> - Diagnostic commands for working with the directives - installing, >>> removing, printing >>> - Lots of small changes wherever we access flags or legacy >>> compilecommands in the compiler >>> >>> Notes: >>> The feature is documented in the JEP >>> (https://bugs.openjdk.java.net/browse/JDK-8046155). >>> >>> Currently only a small amount of compiler flags are included in the >>> change. The flags are a representative selection of different types >>> targeting both compilers. All of them existed as CompilerOracle >>> option commands. Two commands was not included in the directives due >>> to time constraints - CompilerThresholdScaling and UseRTMLocks. Both >>> are accessed from runtime (outside any compiler) and requires some >>> special handling. (Solved but not implemented.) >>> >>> Full backwards compatibility with CompileCommands is implemented but >>> can be turned off with flag -XX:CompileCommandCompatibilty. Also >>> meta handling the compatibility flag by supporting it in the >>> directives (test feature). >>> >>> The change contain some rough edges that will polished over the >>> coming days. >>> >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8046155 >>> Hotspot webrev: http://cr.openjdk.java.net/~neliasso/8046155/webrev.01/ >>> JDK webrev: http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.01/ >>> >>> Please review! >>> >>> Best regards, >>> Nils Eliasson >> > From edward.nevill at gmail.com Tue Oct 6 18:24:50 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 06 Oct 2015 19:24:50 +0100 Subject: RFR: Elide more final field's write memory barrier with escape analysis result In-Reply-To: References: <5612A2C6.5080108@redhat.com> Message-ID: <1444155890.7706.1.camel@mint> On Tue, 2015-10-06 at 20:52 +0800, Hui Shi wrote: > Thanks Andrew! > > This patch modifies share code. Except jcstress, would someone help sponsor and run JPRT? > Hi Hui Shi, I have tested this patch with jcstress on aarch64 partner HW with no errors. Looks good to me. All the best, Ed. From christian.thalinger at oracle.com Tue Oct 6 19:35:12 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 6 Oct 2015 09:35:12 -1000 Subject: [9] RFR 8072369: [TESTBUG] Remove potentially insecure class cast in some hotspot tests In-Reply-To: <55F0312E.7020908@oracle.com> References: <55EF0649.8050109@oracle.com> <55F0312E.7020908@oracle.com> Message-ID: > On Sep 9, 2015, at 3:16 AM, Konstantin Shefov wrote: > > Description of the fix. > Some tests in hotspot repo use class cast from Application class loader to URLClassLoader, but Application class loader is not guaranteed to be always an instance of a URLClassLoader. Please excuse my lack of knowledge here but in what configuration does this happen? > The tests should be changed so that they do not cast appclassloader to URLClassLoader. > > -Konstantin > > On 09/08/2015 07:01 PM, Konstantin Shefov wrote: >> Hello >> >> Please review a test bug fix. >> >> JBS entry: https://bugs.openjdk.java.net/browse/JDK-8072369 >> Webrev: http://cr.openjdk.java.net/~kshefov/8072369/webrev.00 >> >> Thanks >> -Konstantin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Tue Oct 6 22:57:47 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 6 Oct 2015 12:57:47 -1000 Subject: C1 for PPC64 contribution In-Reply-To: <7C9B87B351A4BA4AA9EC95BB418116567226074C@DEWDFEMB19C.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB418116567226074C@DEWDFEMB19C.global.corp.sap> Message-ID: <907154CE-1ABB-4DE9-A487-8D2192108CEC@oracle.com> > On Oct 6, 2015, at 2:59 AM, Doerr, Martin wrote: > > Hi, > > SAP has ported the C1 compiler to PPC64. To contribute it, we require to do > some minor shared changes to C1. Some are bugfixes, others minor adaptions > to support PPC64 specialities. We will send out RFRs for the following changes > step by step: > http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete It?s unfortunate that the delete methods need to be public. Why is that? > http://cr.openjdk.java.net/~mdoerr/8138891_c1_cms_membar All the other architectures including AArch64 don?t need this and the implementation for membar_storestore is empty? > http://cr.openjdk.java.net/~mdoerr/8138892_c1_counter_overflow Can you give a little more context for this change? > http://cr.openjdk.java.net/~mdoerr/8138894_c1_IRIW That one looks ok. > http://cr.openjdk.java.net/~mdoerr/8138895_c1_syncLockOpr Looks ok. > http://cr.openjdk.java.net/~mdoerr/8138896_c1_patching_fix And you noticed this because the instruction size is different on PPC64? > http://cr.openjdk.java.net/~mdoerr/8138952_c1_PPC64_defs static int desired_max_code_buffer_size() { -#ifndef PPC - return (int) NMethodSizeLimit; // default 256K or 512K +#if defined(PPC32) + return MIN2((size_t)NMethodSizeLimit, 32*K); // range of conditional branches +#elif defined(PPC64) + return MIN2((size_t)NMethodSizeLimit, 32*M); // range of unconditional branches #else - // conditional branches on PPC are restricted to 16 bit signed - return MIN2((unsigned int)NMethodSizeLimit,32*K); + return (int) NMethodSizeLimit; // default 256K or 512K #endif } I wish this code be architecture dependent. Wouldn?t it be better to limit the maximum NMethodSizeLimit via a command line flag constraint? +#if defined(PPC64) + static LIR_Opr double_fpu(int reg) { return (LIR_Opr)(intptr_t)((reg << LIR_OprDesc::reg1_shift) | + (reg << LIR_OprDesc::reg2_shift) | + LIR_OprDesc::double_type | + LIR_OprDesc::fpu_register | + LIR_OprDesc::double_size); } +#endif +#ifdef PPC32 static LIR_Opr double_fpu(int reg) { return (LIR_Opr)(intptr_t)((reg << LIR_OprDesc::reg1_shift) | (reg << LIR_OprDesc::reg2_shift) | LIR_OprDesc::double_type | LIR_OprDesc::fpu_register | LIR_OprDesc::double_size); } What?s the difference between 32 and 64? I don?t see it. > > After this, we will contribute the changes to the ppc files in one blob. > > We would appreciate your help in reviewing and especially sponsoring! > > Best regards, > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Tue Oct 6 23:40:12 2015 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 6 Oct 2015 16:40:12 -0700 Subject: C1 for PPC64 contribution In-Reply-To: <7C9B87B351A4BA4AA9EC95BB418116567226074C@DEWDFEMB19C.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB418116567226074C@DEWDFEMB19C.global.corp.sap> Message-ID: > On Oct 6, 2015, at 5:59 AM, Doerr, Martin wrote: > > Hi, > > SAP has ported the C1 compiler to PPC64. To contribute it, we require to do > some minor shared changes to C1. Some are bugfixes, others minor adaptions > to support PPC64 specialities. We will send out RFRs for the following changes > step by step: > http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete > http://cr.openjdk.java.net/~mdoerr/8138891_c1_cms_membar > http://cr.openjdk.java.net/~mdoerr/8138892_c1_counter_overflow Could you please be add LIR_Assembler::store_parameter() on x86 to support metadata constant? Otherwise it kind of breaks the pattern used in CounterOverflowStub. I guess, it?s all just to produce a little tighter code by moving constant materialization to the stub, or is it something else? Any visible effects? > http://cr.openjdk.java.net/~mdoerr/8138894_c1_IRIW > http://cr.openjdk.java.net/~mdoerr/8138895_c1_syncLockOpr > http://cr.openjdk.java.net/~mdoerr/8138896_c1_patching_fix > http://cr.openjdk.java.net/~mdoerr/8138952_c1_PPC64_defs -#if defined(__SOFTFP__) || defined(PPC32) +#if defined(__SOFTFP__) || defined(PPC) double SharedRuntime::dsqrt(double f) { return sqrt(f); } #endif -#if defined(__SOFTFP__) || defined(PPC32) +#if defined(__SOFTFP__) || defined(PPC) static double dsqrt(double f); #endif So here is PPC defined if either PPC32 and PPC64 is defined? igor > > After this, we will contribute the changes to the ppc files in one blob. > > We would appreciate your help in reviewing and especially sponsoring! > > Best regards, > Martin From igor.veresov at oracle.com Tue Oct 6 23:42:07 2015 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 6 Oct 2015 16:42:07 -0700 Subject: RFR(XS) 8138891: C1: Missing release memory barrier in C1's CMS post-barrier In-Reply-To: <7C9B87B351A4BA4AA9EC95BB41811656722607F8@DEWDFEMB19C.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB41811656722607F8@DEWDFEMB19C.global.corp.sap> Message-ID: Looks good. igor > On Oct 6, 2015, at 7:24 AM, Doerr, Martin wrote: > > Hi, > > the dirty marking of the card table needs to be a releasing store for CMS. It's already there in template interpreter and C2 on PPC64. We have seen GC crashed when testing C1 on PPC64. > Unfortunately, C1 does currently not support releasing stores (or load-acquire) which could be exploited on aarch64 or ia64. Hence, we?re using a membar_store_store. > This change is a prerequisite for our C1 on PPC64 contribution. > > Webrev is here: > http://cr.openjdk.java.net/~mdoerr/8138891_c1_cms_membar /webrev.00 > > Please review this change. I need a sponsor, please. > > Best regards, > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Wed Oct 7 01:32:26 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 6 Oct 2015 15:32:26 -1000 Subject: RFR(S): 8138890: C1: Ambiguous operator delete In-Reply-To: <7C9B87B351A4BA4AA9EC95BB41811656722607B5@DEWDFEMB19C.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB41811656722607B5@DEWDFEMB19C.global.corp.sap> Message-ID: > On Oct 6, 2015, at 3:56 AM, Doerr, Martin wrote: > > Hi, > > xlC on AIX rejects to compile LIRGenerator and RangeCheckEliminator::Verification due to ambiguous operator delete which gets inherited from multiple base classes. > This change is a prerequisite for our C1 on PPC64 contribution. > > Webrev is here: > http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.00 Let me ask my question here: why do you need the delete methods to be public on AIX? > > Please review this change. I need a sponsor, please. > > Best regards, > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From hui.shi at linaro.org Wed Oct 7 02:16:46 2015 From: hui.shi at linaro.org (Hui Shi) Date: Wed, 7 Oct 2015 10:16:46 +0800 Subject: RFR: Elide more final field's write memory barrier with escape analysis result In-Reply-To: <1444155890.7706.1.camel@mint> References: <5612A2C6.5080108@redhat.com> <1444155890.7706.1.camel@mint> Message-ID: Thanks Edward! Regards Shi Hui On 7 October 2015 at 02:24, Edward Nevill wrote: > On Tue, 2015-10-06 at 20:52 +0800, Hui Shi wrote: > > Thanks Andrew! > > > > This patch modifies share code. Except jcstress, would someone help > sponsor and run JPRT? > > > > Hi Hui Shi, > > I have tested this patch with jcstress on aarch64 partner HW with no > errors. Looks good to me. > > All the best, > Ed. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed Oct 7 02:37:57 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 7 Oct 2015 10:37:57 +0800 Subject: [9] RFR(S): 8138651: -XX:DisableIntrinsic matches intrinsics overly eagerly In-Reply-To: <5613B7D5.5090702@oracle.com> References: <5613B7D5.5090702@oracle.com> Message-ID: <56148585.1020507@oracle.com> To be precise DisableIntrinsic is ccstrlist option, not ccstr. Yes, the actual type is the same. An other concern is separators since format could be different if option specified in file. Look how we do search in DeoptimizeOnlyAt string. Thanks, Vladimir On 10/6/15 8:00 PM, Zolt?n Maj? wrote: > Hi, > > > please review the patch for JDK-8138651. > > https://bugs.openjdk.java.net/browse/JDK-8138651 > > Problem: The DisableIntrinsic flag does not disable intrinsics > accurately. For example, -XX:DisableIntrinsic=_copyOfRange disables both > the intrinsic with the ID _copyOfRange and the intrinsic with the _copyOf. > > Solution: Change the processing of the DisableIntrinsic flag (both > globally and on a per-method level). > > Webrev: http://cr.openjdk.java.net/~zmajo/8138651/webrev.00/ > > Testing: > - JPRT (testset hotspot); > - executed the the newly added test > compiler/intrinsics/IntrinsicDisabledTest.java with/without the fix on > all platforms, the test behaves as expected. > > Thank you and best regards, > > > Zoltan > From vladimir.kozlov at oracle.com Wed Oct 7 02:50:19 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 7 Oct 2015 10:50:19 +0800 Subject: RFR(L): 8066153: JEP-JDK-8046155: Test task: cover existing In-Reply-To: <5609334B.7050200@oracle.com> References: <5609334B.7050200@oracle.com> Message-ID: <5614886B.9050508@oracle.com> We have test problems with parsing output of LogCompilation and other outputs because it could be cut off. I would prefer adding new WB events API to record interesting events. Otherwise seems fine. Nils should look on this to make sure all paths/flags are tested. Thanks, Vladimir On 9/28/15 8:32 PM, Pavel Punegov wrote: > Hi, > > please review the following tests fro JEP 165 Compiler Control. > These tests cover both CompileCommand and new directives (through > CompileDirectivesFile). > > The main idea of tests is to create a one or multiple commands or > directives for methods in the pool and execute a test VM with a set of > method states (should method be compiled, inlined, printed, etc.). On > the end test checks that only correct methods are logged with > LogCompilation, or printed via PrintAssembly. > > Bugs: > https://bugs.openjdk.java.net/browse/JDK-8066153 > https://bugs.openjdk.java.net/browse/JDK-8066165 > > webrev: http://cr.openjdk.java.net/~ppunegov/8066153/webrev.00/ > From vladimir.kozlov at oracle.com Wed Oct 7 03:11:46 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 7 Oct 2015 11:11:46 +0800 Subject: [9] RFR 8072369: [TESTBUG] Remove potentially insecure class cast in some hotspot tests In-Reply-To: References: <55EF0649.8050109@oracle.com> <55F0312E.7020908@oracle.com> Message-ID: <56148D72.3050400@oracle.com> On 10/7/15 3:35 AM, Christian Thalinger wrote: > >> On Sep 9, 2015, at 3:16 AM, Konstantin Shefov >> > >> wrote: >> >> Description of the fix. >> Some tests in hotspot repo use class cast from Application class >> loader to URLClassLoader, but Application class loader is not >> guaranteed to be always an instance of a URLClassLoader. > > Please excuse my lack of knowledge here but in what configuration does > this happen? Based on bug report it is sun.misc.Launcher$AppClassLoader. Duplication of 'parent': + * @param parent parent class loader Why do you need import next in each test? Is not enough to import them to Utils.java only?: +import java.io.File; +import java.net.URL; Thanks, Vladimir > >> The tests should be changed so that they do not cast appclassloader to >> URLClassLoader. >> >> -Konstantin >> >> On 09/08/2015 07:01 PM, Konstantin Shefov wrote: >>> Hello >>> >>> Please review a test bug fix. >>> >>> JBS entry: https://bugs.openjdk.java.net/browse/JDK-8072369 >>> Webrev: http://cr.openjdk.java.net/~kshefov/8072369/webrev.00 >>> >>> Thanks >>> -Konstantin >> > From zoltan.majo at oracle.com Wed Oct 7 07:44:28 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 7 Oct 2015 09:44:28 +0200 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: <5613FD88.9020505@oracle.com> References: <56018E2B.2000108@oracle.com> <560E9050.6000804@oracle.com> <5613D2BD.3040401@oracle.com> <5613FD88.9020505@oracle.com> Message-ID: <5614CD5C.4070801@oracle.com> Hi Nils, thank you for the clarifications! Please see my comments below. On 10/06/2015 06:57 PM, Nils Eliasson wrote: > Hi Zoltan, > > On 2015-10-06 15:55, Zolt?n Maj? wrote: >> Hi Nils, >> >> >> Currently, there are two ways the the DisableIntrinsic flag can be >> used to disable intrinsics. >> >> 1) Intrinsics can be disabled globally, that is, the compilers are >> not allowed to "use" (e.g., inline) the intrinsic in any calling >> context. For example: >> >> -XX:DisableIntrinsic=_hashCode,_getClass >> >> disables two intrinsics globally. >> >> 2) Intrinsics can be disabled on a per-method level, that is, the >> compiler is not allowed to use the intrinsic if it is called from a >> specific method, but the compiler is still allowed to use the >> intrinsic otherwise. For example: >> overri >> -XX:CompileCommand=option,aClass::aMethod,ccstr,DisableIntrinsic,_hashCode >> >> >> disables intrinsification of _hashCode if it is called from >> aClass::aMethod (but not for any other call site of _hashCode). >> >> It seems to me that your changes preserve (1) but eliminate (2). >> Could you please explain to me why you remove the functionality of >> disabling intrinsics on a per-method level? > > It isn't removed :) I'm afraid that the functionality is indeed removed. Here is a small experiment to prove that. I use the following test program: class MathTest { public static double test1() { return Math.sin(3.14); } public static double test2() { return Math.sin(3.14); } public static void main(String args[]) throws Exception { double value = 0.0; for (int i = 0; i < 20000; i++) { value = test1(); } for (int i = 0; i < 20000; i++) { value = test2(); } } } I execute MathTest with JDK9-b83 and also a recent build patched with your changes. I use the following command line: -XX:CompileCommand=option,MathTest::test2,ccstr,DisableIntrinsic,_dsin That means that the Math.sin intrinsic can be inlined into every method except MathTest.test2. With JDK9-b83 I get the expected behavior (Math.sin is inlined into test1 but not into test2) 124 1 b 3 MathTest::test1 (7 bytes) @ 3 java.lang.Math::sin (5 bytes) intrinsic 131 2 b 3 MathTest::test2 (7 bytes) @ 3 java.lang.Math::sin (5 bytes) @ 1 java/lang/StrictMath::sin (not loaded) not inlineable 133 3 n 0 java.lang.StrictMath::sin (native) (static) With your changes I get: 143 1 b 3 MathTest::test1 (7 bytes) @ 3 java.lang.Math::sin (5 bytes) intrinsic 148 2 b 3 MathTest::test2 (7 bytes) @ 3 java.lang.Math::sin (5 bytes) intrinsic That is, Math.sin is inlined into both test1 and test2, even though the per-method DisableIntrinsc flag forbids that. Is it intended that you remove this functionality and if yes, why do you remove it? Thank you and best regards, Zoltan > > The option is as you say available as a VM flag and as an per method > CompileCommand option. Compiler Directives has full compatibility with > this with one small exception. > > 1) The global vm flag "-XX:DisableIntrinsic=_hashCode,_getClass " is > added as the default value to all directives. > 2) CompileCommand option " > -XX:CompileCommand=option,aClass::aMethod,ccstr,DisableIntrinsic,_hashCode > " overrides this if the method is matching. That matching is taking > place in compilecommand_compatibility_init(). This happens after a > directive is choosen because the directive and compile command may > have different matches. > 3) Any CompilerDirective that set this flag will override both above. > > The difference is that you where able to forbid the union of the > intrinsics in the vmflag and the one from the compilecommand. Now > CompileCommand overrides the vmflag. This is how all the other options > that are available as vmflags and compilecommand works. I haven't seen > this in any test or use case - but if this is a problem I could make a > custom workaround for this option that appends the two sets. > CompilerDirectives will always override since you want to be able to > remove any flag that is set. > > The table at the beginning of compilerDirectives.hpp declares all > options, their default values (sometimes vmflags, sometimes constants) > and any compilecommand that must be checked. > >> >> Also, currently there are some comments describing the way the >> DisableIntrinsic flag works: >> - abstractCompiler.hpp: line 70--98: Please update the description to >> match the way DisableIntrinsic works with your changes; >> - vmSymbols.cpp: line 420; Please update the comment. Also, please >> also move part of that comment to the place where you check if >> intrinsics are disabled, as the method is_disabled_by_flags() does >> not check at the value of the DisableIntrinsic flag. > > Ok, I'll check and update the comments. > > Thanks for looking at my code! > > Best regards, > Nils Eliasson > >> >> Thank you and best regards, >> >> >> Zoltan >> >> >> On 10/02/2015 04:10 PM, Nils Eliasson wrote: >>> Hi all, >>> >>> A new webrev with all the feedback from reviewers and others. >>> >>> http://cr.openjdk.java.net/~neliasso/8046155/webrev.04/ >>> >>> - name changes as requested by christian >>> - various small bug fixes >>> - New tests for sanity testing flags and their behaviour with vm >>> flags and compile commands present >>> >>> Regards, >>> Nils >>> >>> On 2015-09-22 19:21, Nils Eliasson wrote: >>>> Hi, >>>> >>>> This is the initial RFR for JEP165: Compiler Control. This feature >>>> enables runtime manageable, method dependent compiler flags. >>>> (Immutable for the duration of a compilation.) >>>> >>>> The change includes: >>>> - A parser for the directives format (json like) including vmtests >>>> (json.cpp/hpp) >>>> - A component for construction of compiler directives >>>> (directivesParser.cpp/hpp) >>>> - The directives including the option definitions, default values >>>> and compilecommand relations (compilerDirectives.cpp/hpp) >>>> - Diagnostic commands for working with the directives - installing, >>>> removing, printing >>>> - Lots of small changes wherever we access flags or legacy >>>> compilecommands in the compiler >>>> >>>> Notes: >>>> The feature is documented in the JEP >>>> (https://bugs.openjdk.java.net/browse/JDK-8046155). >>>> >>>> Currently only a small amount of compiler flags are included in the >>>> change. The flags are a representative selection of different types >>>> targeting both compilers. All of them existed as CompilerOracle >>>> option commands. Two commands was not included in the directives >>>> due to time constraints - CompilerThresholdScaling and UseRTMLocks. >>>> Both are accessed from runtime (outside any compiler) and requires >>>> some special handling. (Solved but not implemented.) >>>> >>>> Full backwards compatibility with CompileCommands is implemented >>>> but can be turned off with flag -XX:CompileCommandCompatibilty. >>>> Also meta handling the compatibility flag by supporting it in the >>>> directives (test feature). >>>> >>>> The change contain some rough edges that will polished over the >>>> coming days. >>>> >>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8046155 >>>> Hotspot webrev: >>>> http://cr.openjdk.java.net/~neliasso/8046155/webrev.01/ >>>> JDK webrev: >>>> http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.01/ >>>> >>>> Please review! >>>> >>>> Best regards, >>>> Nils Eliasson >>> >> > From zoltan.majo at oracle.com Wed Oct 7 08:09:37 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 7 Oct 2015 10:09:37 +0200 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: <5613FF81.9070304@oracle.com> References: <56018E2B.2000108@oracle.com> <560E9050.6000804@oracle.com> <5613D7A4.6010205@oracle.com> <5613FF81.9070304@oracle.com> Message-ID: <5614D341.1030707@oracle.com> Hi Nils, thank you for clarification. I think in my previous email I did not formulate my question clearly enough. What I meant is the following: Previously, ciMethod::has_option_value was used to determine if there is a per-method flag value available for a method. You have replaced the usages of ciMethod::has_option_value() with querying a directive directly. For example: src/share/vm/opto/idealGraphPrinter.cpp - method->has_option_value("PrintIdealGraphLevel", ideal_graph_level); // update value with per-method value (if available) + return C->directive()->IGVPrintLevelOption >= level; src/share/vm/opto/compile.cpp - method_has_option_value("MaxNodeLimit", _max_node_limit); + _max_node_limit = _directive->MaxNodeLimitOption; src/share/vm/opto/superword.cpp - _phase->C->method()->has_option_value("VectorizeDebug", _vector_loop_debug); + _vector_loop_debug = phase->C->directive()->VectorizeDebugOption; The only location in the source code that you still use has_option_value() is: src/share/vm/compiler/compileBroker.cpp - if (CompilerOracle::should_exclude(method, quietly) - || (CompilerOracle::has_option_value(method, "CompileThresholdScaling", scale) && scale == 0)) { + if (excluded || (CompilerOracle::has_option_value(method, "CompileThresholdScaling", scale) && scale == 0)) { Could you please explain why you use has_option_value() at this source location instead of a directive (as at all other places, e.g, in the case of PrintIdealGraphLevel, MaxNodeLimit, and VectorizeDebug)? Thank you and best regards, Zoltan On 10/06/2015 07:06 PM, Nils Eliasson wrote: > Hi Zoltan, > > All the CompileCommand options work in the same way as described in > the intrinsics-mail. In compilerDirectives.hpp the flags are declared > with their CompileCommand equivalent. And in > compilecommand_compatibility_init the directives may be updated with > these flags. > > Take a look at > test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityCommandOn.java > for an example of how it can work. First these are set on the > commandline "-XX:-PrintAssembly -XX:CompileCommand=print,*.*", then in > the test a directive is loaded that turns it off. Later the directive > is removed. The result is verified at each step. > > I hope my explanation is understandable. > > Best regards, > Nils Eliasson > > > > > On 2015-10-06 16:16, Zolt?n Maj? wrote: >> Hi, >> >> >> there is another question that comes to my mind. >> >> For command-line flags that allow per-method usage you propose to get >> the flag's value from the directive instead of getting the value >> using ciMethod()::has_option_value(). For example, you propose to use >> >> _vector_loop_debug = directive()->VectorizeDebugOption; >> >> instead of >> >> method()->has_option_value("VectorizeDebug", _vector_loop_debug); >> >> You propose to do this for almost all flags (e.g., VectorizeDebug, >> DisableIntrinsic, MaxNodeLimit, PrintIdealGraphLevel) except one, >> CompileThresholdScaling. Could you please explain why? >> >> Thank you and best regards, >> >> >> Zoltan >> >> On 10/02/2015 04:10 PM, Nils Eliasson wrote: >>> Hi all, >>> >>> A new webrev with all the feedback from reviewers and others. >>> >>> http://cr.openjdk.java.net/~neliasso/8046155/webrev.04/ >>> >>> - name changes as requested by christian >>> - various small bug fixes >>> - New tests for sanity testing flags and their behaviour with vm >>> flags and compile commands present >>> >>> Regards, >>> Nils >>> >>> On 2015-09-22 19:21, Nils Eliasson wrote: >>>> Hi, >>>> >>>> This is the initial RFR for JEP165: Compiler Control. This feature >>>> enables runtime manageable, method dependent compiler flags. >>>> (Immutable for the duration of a compilation.) >>>> >>>> The change includes: >>>> - A parser for the directives format (json like) including vmtests >>>> (json.cpp/hpp) >>>> - A component for construction of compiler directives >>>> (directivesParser.cpp/hpp) >>>> - The directives including the option definitions, default values >>>> and compilecommand relations (compilerDirectives.cpp/hpp) >>>> - Diagnostic commands for working with the directives - installing, >>>> removing, printing >>>> - Lots of small changes wherever we access flags or legacy >>>> compilecommands in the compiler >>>> >>>> Notes: >>>> The feature is documented in the JEP >>>> (https://bugs.openjdk.java.net/browse/JDK-8046155). >>>> >>>> Currently only a small amount of compiler flags are included in the >>>> change. The flags are a representative selection of different types >>>> targeting both compilers. All of them existed as CompilerOracle >>>> option commands. Two commands was not included in the directives >>>> due to time constraints - CompilerThresholdScaling and UseRTMLocks. >>>> Both are accessed from runtime (outside any compiler) and requires >>>> some special handling. (Solved but not implemented.) >>>> >>>> Full backwards compatibility with CompileCommands is implemented >>>> but can be turned off with flag -XX:CompileCommandCompatibilty. >>>> Also meta handling the compatibility flag by supporting it in the >>>> directives (test feature). >>>> >>>> The change contain some rough edges that will polished over the >>>> coming days. >>>> >>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8046155 >>>> Hotspot webrev: >>>> http://cr.openjdk.java.net/~neliasso/8046155/webrev.01/ >>>> JDK webrev: >>>> http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.01/ >>>> >>>> Please review! >>>> >>>> Best regards, >>>> Nils Eliasson >>> >> > From roland.westrelin at oracle.com Wed Oct 7 08:24:04 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 7 Oct 2015 10:24:04 +0200 Subject: [9] RFR(M): 8078554: Compiler: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <5613B44F.4090007@oracle.com> References: <560BB4F6.3050703@oracle.com> <4502D8F6-B256-4222-B1D3-92ED5C100B6E@oracle.com> <5613B44F.4090007@oracle.com> Message-ID: Hi Zoltan, >> That one is not correct: >> 461 product(intx, MaxNodeLimit, 80000, \ >> 462 "Maximum number of nodes") \ >> 463 range(1000, 80000) \ >> >> I think the upper bound should be max_juint > > You are right that the limit of 80'000 is too conservative. But max_j*u*int as an upper bound would cause an overflow when parsing the flag's value, because on 32-bit machines intx is a 32-bit signed integer. > > Using max_jint instead of max_j*u*int as an upper bound would not cause an overflow at parse time. However, in Parse::do_call() the maximum node limit is increased by 3 times for jsr292 users > > C->set_max_node_limit(3*MaxNodeLimit); > > If MaxNodeLimit == max_jint, this expression will overflow, I think. Shouldn?t ranges in the flags definition check for reasonable values and then code like the 3*MaxNodeLimit above or the 80% of LiveNodeCountInliningCutoff below be robust to overflow? When someone changes the 3*MaxNodeLimit to 4*MaxNodeLimit, I doubt he?ll think he needs to update the flag definition: because it?s in a completely different location and because it doesn?t feel logical (at least, not to me). > So I set the limit to (max_jint / 3) in the updated webrev. > > If we would set MaxNodeLimit to max_j*u*int / 3 (instead of max_jint / 3), the expression 3 * MaxNodeLimit would overflow as well. Changing the type of the flag from intx to uintx could let use use max_j*u*int / 3 as an upper bound, but that is most likely not worth the effort. > >> 699 product(intx, LiveNodeCountInliningCutoff, 40000, \ >> 700 "max number of live nodes in a method") \ >> 701 range(0, max_juint / 8) \ >> >> Out of curiosity why max_juint / 8 (not that it makes much of a difference)? > > In Compile::inline_incrementally, the 80% of LiveNodeCountInliningCutoff is computed the following way: > > if (low_live_nodes < (uint)LiveNodeCountInliningCutoff * 8 / 10) { > > If LiveNodeCountInliningCutoff == max_juint, we'd have an overflow because of the multiplication by 8. >> 2877 product(intx, TypeProfileArgsLimit, 2, \ >> 2878 "max number of call arguments to consider for type profiling") \ >> 2879 range(0, 16) \ >> >> 2880 \ >> 2881 product(intx, TypeProfileParmsLimit, 2, \ >> 2882 "max number of incoming parameters to consider for type profiling"\ >> 2883 ", -1 for all") \ >> 2884 range(-1, 64) >> >> Why 16 and 64? > > These are the largest values that work on all platforms we support. Sorry, I still don?t understand that. Based on implementation details? Roland. From zoltan.majo at oracle.com Wed Oct 7 08:36:17 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 7 Oct 2015 10:36:17 +0200 Subject: [9] RFR(S): 8138651: -XX:DisableIntrinsic matches intrinsics overly eagerly In-Reply-To: <56148585.1020507@oracle.com> References: <5613B7D5.5090702@oracle.com> <56148585.1020507@oracle.com> Message-ID: <5614D981.7080304@oracle.com> Thank, Vladimir and Aleksey, for the feedback! I'll put this issue on hold until Nils has pushed his work on compiler control and will produce an updated version then. Best regards, Zoltan On 10/07/2015 04:37 AM, Vladimir Kozlov wrote: > To be precise DisableIntrinsic is ccstrlist option, not ccstr. Yes, > the actual type is the same. > > An other concern is separators since format could be different if > option specified in file. Look how we do search in DeoptimizeOnlyAt > string. > > Thanks, > Vladimir > > On 10/6/15 8:00 PM, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the patch for JDK-8138651. >> >> https://bugs.openjdk.java.net/browse/JDK-8138651 >> >> Problem: The DisableIntrinsic flag does not disable intrinsics >> accurately. For example, -XX:DisableIntrinsic=_copyOfRange disables both >> the intrinsic with the ID _copyOfRange and the intrinsic with the >> _copyOf. >> >> Solution: Change the processing of the DisableIntrinsic flag (both >> globally and on a per-method level). >> >> Webrev: http://cr.openjdk.java.net/~zmajo/8138651/webrev.00/ >> >> Testing: >> - JPRT (testset hotspot); >> - executed the the newly added test >> compiler/intrinsics/IntrinsicDisabledTest.java with/without the fix on >> all platforms, the test behaves as expected. >> >> Thank you and best regards, >> >> >> Zoltan >> From roland.westrelin at oracle.com Wed Oct 7 09:06:55 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 7 Oct 2015 11:06:55 +0200 Subject: [9] RFR(S): 8136469: OptimizeStringConcat fails on pre-sized StringBuilder shapes In-Reply-To: <56139149.5080906@oracle.com> References: <55FBDFEC.4060405@oracle.com> <56139149.5080906@oracle.com> Message-ID: >> Maybe we could add an IfProjNode::Ideal method that disconnects the other branch of the If when this branch is always taken and that does so even during parsing. Given Ideal is called before Identity, that would guarantee the next call to Identity optimizes the If out. > > As you suggested, I added an IfProjNode::Ideal that disconnects the never taken branch from the IfNode. The subsequent call to Identity then removes the IfNode: > http://cr.openjdk.java.net/~thartmann/8136469/webrev.03/ > > However, I wondered if this is "legal" because the comment in Node::ideal says: > > // The Ideal call almost arbitrarily reshape the graph rooted at the 'this' > // pointer. > > But we are changing the graph "above" the this pointer. I executed tests with -XX:+VerifyIterativeGVN and everything seems to work fine. > Another solution would be to cut the *current* branch if it is never taken: > http://cr.openjdk.java.net/~thartmann/8136469/webrev.02/ > > But this solution depends on the assumption that we execute the identity() of the other ProjNode which is not guaranteed by GVN (I think). > > Therefore I would like to go for webrev.03. I verified that this solves the problem and tested the fix with JPRT. I thought about this more and I don?t think either work ok. The problem with webrev.02 is that depending on the order the projection nodes are allocated and transformed, the optimization may not happened: Node* never_taken = new IfTrueNode(..); Node* always_taken = new IfFalseNode(..); always_taken = gvn.transform(always_taken); never_taken = gvn.transform(never_taken); The problem with webrev.03 is that we may change a node that is not yet transformed (never_taken changed by call to gvn.transform(always_taken)). Not sure if it could break existing code but it?s clearly an unexpected behavior. An other way would be to remove the in(0)->outcnt() == 1 check from IfProjNode::Identity() and in an IfProjNode::Ideal method do what you do in webrev.03 but when can_reshape is true only. Roland. From roland.westrelin at oracle.com Wed Oct 7 09:10:05 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 7 Oct 2015 11:10:05 +0200 Subject: [9] RFR(M): 8078554: Compiler: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: References: <560BB4F6.3050703@oracle.com> <4502D8F6-B256-4222-B1D3-92ED5C100B6E@oracle.com> <5613B44F.4090007@oracle.com> Message-ID: >>> That one is not correct: >>> 461 product(intx, MaxNodeLimit, 80000, \ >>> 462 "Maximum number of nodes") \ >>> 463 range(1000, 80000) \ >>> >>> I think the upper bound should be max_juint >> >> You are right that the limit of 80'000 is too conservative. But max_j*u*int as an upper bound would cause an overflow when parsing the flag's value, because on 32-bit machines intx is a 32-bit signed integer. >> >> Using max_jint instead of max_j*u*int as an upper bound would not cause an overflow at parse time. However, in Parse::do_call() the maximum node limit is increased by 3 times for jsr292 users >> >> C->set_max_node_limit(3*MaxNodeLimit); >> >> If MaxNodeLimit == max_jint, this expression will overflow, I think. > > Shouldn?t ranges in the flags definition check for reasonable values and then code like the 3*MaxNodeLimit above or the 80% of LiveNodeCountInliningCutoff below be robust to overflow? When someone changes the 3*MaxNodeLimit to 4*MaxNodeLimit, I doubt he?ll think he needs to update the flag definition: because it?s in a completely different location and because it doesn?t feel logical (at least, not to me). For the record, I discussed this privately with Zolt?n and he convinced me that going over every flags and making sure they don?t overflow where they are used is an unreasonable amount of work. This change looks good to me. Roland. From nils.eliasson at oracle.com Wed Oct 7 09:47:32 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 7 Oct 2015 11:47:32 +0200 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: <5614CD5C.4070801@oracle.com> References: <56018E2B.2000108@oracle.com> <560E9050.6000804@oracle.com> <5613D2BD.3040401@oracle.com> <5613FD88.9020505@oracle.com> <5614CD5C.4070801@oracle.com> Message-ID: <5614EA34.7030904@oracle.com> Hi Zoltan, It was not the intention to remove. I found a bug - I had spelled "DisableIntrinsic" wrong in the flag table in compilerDirectives.hpp. The stringly typed option commands didn't complain and I missed it. Thanks for finding the bug! Best regards, Nils Eliasson On 2015-10-07 09:44, Zolt?n Maj? wrote: > Hi Nils, > > > thank you for the clarifications! Please see my comments below. > > On 10/06/2015 06:57 PM, Nils Eliasson wrote: >> Hi Zoltan, >> >> On 2015-10-06 15:55, Zolt?n Maj? wrote: >>> Hi Nils, >>> >>> >>> Currently, there are two ways the the DisableIntrinsic flag can be >>> used to disable intrinsics. >>> >>> 1) Intrinsics can be disabled globally, that is, the compilers are >>> not allowed to "use" (e.g., inline) the intrinsic in any calling >>> context. For example: >>> >>> -XX:DisableIntrinsic=_hashCode,_getClass >>> >>> disables two intrinsics globally. >>> >>> 2) Intrinsics can be disabled on a per-method level, that is, the >>> compiler is not allowed to use the intrinsic if it is called from a >>> specific method, but the compiler is still allowed to use the >>> intrinsic otherwise. For example: >>> overri >>> -XX:CompileCommand=option,aClass::aMethod,ccstr,DisableIntrinsic,_hashCode >>> >>> >>> disables intrinsification of _hashCode if it is called from >>> aClass::aMethod (but not for any other call site of _hashCode). >>> >>> It seems to me that your changes preserve (1) but eliminate (2). >>> Could you please explain to me why you remove the functionality of >>> disabling intrinsics on a per-method level? >> >> It isn't removed :) > > I'm afraid that the functionality is indeed removed. Here is a small > experiment to prove that. > > I use the following test program: > > class MathTest { > public static double test1() { > return Math.sin(3.14); > } > > public static double test2() { > return Math.sin(3.14); > } > > public static void main(String args[]) throws Exception { > double value = 0.0; > > for (int i = 0; i < 20000; i++) { > value = test1(); > } > > for (int i = 0; i < 20000; i++) { > value = test2(); > } > } > } > > > I execute MathTest with JDK9-b83 and also a recent build patched with > your changes. I use the following command line: > > -XX:CompileCommand=option,MathTest::test2,ccstr,DisableIntrinsic,_dsin > > That means that the Math.sin intrinsic can be inlined into every > method except MathTest.test2. > > With JDK9-b83 I get the expected behavior (Math.sin is inlined into > test1 but not into test2) > > 124 1 b 3 MathTest::test1 (7 bytes) > @ 3 java.lang.Math::sin (5 bytes) > intrinsic > 131 2 b 3 MathTest::test2 (7 bytes) > @ 3 java.lang.Math::sin (5 bytes) > @ 1 java/lang/StrictMath::sin (not loaded) not > inlineable > 133 3 n 0 java.lang.StrictMath::sin (native) (static) > > With your changes I get: > > 143 1 b 3 MathTest::test1 (7 bytes) > @ 3 java.lang.Math::sin (5 bytes) > intrinsic > 148 2 b 3 MathTest::test2 (7 bytes) > @ 3 java.lang.Math::sin (5 bytes) > intrinsic > > That is, Math.sin is inlined into both test1 and test2, even though > the per-method DisableIntrinsc flag forbids that. > > Is it intended that you remove this functionality and if yes, why do > you remove it? > > Thank you and best regards, > > > Zoltan > > > >> >> The option is as you say available as a VM flag and as an per method >> CompileCommand option. Compiler Directives has full compatibility >> with this with one small exception. >> >> 1) The global vm flag "-XX:DisableIntrinsic=_hashCode,_getClass " is >> added as the default value to all directives. >> 2) CompileCommand option " >> -XX:CompileCommand=option,aClass::aMethod,ccstr,DisableIntrinsic,_hashCode >> " overrides this if the method is matching. That matching is taking >> place in compilecommand_compatibility_init(). This happens after a >> directive is choosen because the directive and compile command may >> have different matches. >> 3) Any CompilerDirective that set this flag will override both above. >> >> The difference is that you where able to forbid the union of the >> intrinsics in the vmflag and the one from the compilecommand. Now >> CompileCommand overrides the vmflag. This is how all the other >> options that are available as vmflags and compilecommand works. I >> haven't seen this in any test or use case - but if this is a problem >> I could make a custom workaround for this option that appends the two >> sets. CompilerDirectives will always override since you want to be >> able to remove any flag that is set. >> >> The table at the beginning of compilerDirectives.hpp declares all >> options, their default values (sometimes vmflags, sometimes >> constants) and any compilecommand that must be checked. >> >>> >>> Also, currently there are some comments describing the way the >>> DisableIntrinsic flag works: >>> - abstractCompiler.hpp: line 70--98: Please update the description >>> to match the way DisableIntrinsic works with your changes; >>> - vmSymbols.cpp: line 420; Please update the comment. Also, please >>> also move part of that comment to the place where you check if >>> intrinsics are disabled, as the method is_disabled_by_flags() does >>> not check at the value of the DisableIntrinsic flag. >> >> Ok, I'll check and update the comments. >> >> Thanks for looking at my code! >> >> Best regards, >> Nils Eliasson >> >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> >>> >>> On 10/02/2015 04:10 PM, Nils Eliasson wrote: >>>> Hi all, >>>> >>>> A new webrev with all the feedback from reviewers and others. >>>> >>>> http://cr.openjdk.java.net/~neliasso/8046155/webrev.04/ >>>> >>>> - name changes as requested by christian >>>> - various small bug fixes >>>> - New tests for sanity testing flags and their behaviour with vm >>>> flags and compile commands present >>>> >>>> Regards, >>>> Nils >>>> >>>> On 2015-09-22 19:21, Nils Eliasson wrote: >>>>> Hi, >>>>> >>>>> This is the initial RFR for JEP165: Compiler Control. This feature >>>>> enables runtime manageable, method dependent compiler flags. >>>>> (Immutable for the duration of a compilation.) >>>>> >>>>> The change includes: >>>>> - A parser for the directives format (json like) including vmtests >>>>> (json.cpp/hpp) >>>>> - A component for construction of compiler directives >>>>> (directivesParser.cpp/hpp) >>>>> - The directives including the option definitions, default values >>>>> and compilecommand relations (compilerDirectives.cpp/hpp) >>>>> - Diagnostic commands for working with the directives - >>>>> installing, removing, printing >>>>> - Lots of small changes wherever we access flags or legacy >>>>> compilecommands in the compiler >>>>> >>>>> Notes: >>>>> The feature is documented in the JEP >>>>> (https://bugs.openjdk.java.net/browse/JDK-8046155). >>>>> >>>>> Currently only a small amount of compiler flags are included in >>>>> the change. The flags are a representative selection of different >>>>> types targeting both compilers. All of them existed as >>>>> CompilerOracle option commands. Two commands was not included in >>>>> the directives due to time constraints - CompilerThresholdScaling >>>>> and UseRTMLocks. Both are accessed from runtime (outside any >>>>> compiler) and requires some special handling. (Solved but not >>>>> implemented.) >>>>> >>>>> Full backwards compatibility with CompileCommands is implemented >>>>> but can be turned off with flag -XX:CompileCommandCompatibilty. >>>>> Also meta handling the compatibility flag by supporting it in the >>>>> directives (test feature). >>>>> >>>>> The change contain some rough edges that will polished over the >>>>> coming days. >>>>> >>>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8046155 >>>>> Hotspot webrev: >>>>> http://cr.openjdk.java.net/~neliasso/8046155/webrev.01/ >>>>> JDK webrev: >>>>> http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.01/ >>>>> >>>>> Please review! >>>>> >>>>> Best regards, >>>>> Nils Eliasson >>>> >>> >> > From nils.eliasson at oracle.com Wed Oct 7 09:58:41 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 7 Oct 2015 11:58:41 +0200 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: <5614D341.1030707@oracle.com> References: <56018E2B.2000108@oracle.com> <560E9050.6000804@oracle.com> <5613D7A4.6010205@oracle.com> <5613FF81.9070304@oracle.com> <5614D341.1030707@oracle.com> Message-ID: <5614ECD1.60108@oracle.com> Hi Zoltan, See below. On 2015-10-07 10:09, Zolt?n Maj? wrote: > Hi Nils, > > > thank you for clarification. I think in my previous email I did not > formulate my question clearly enough. > > What I meant is the following: Previously, ciMethod::has_option_value > was used to determine if there is a per-method flag value available > for a method. You have replaced the usages of > ciMethod::has_option_value() with querying a directive directly. For > example: > > src/share/vm/opto/idealGraphPrinter.cpp > - method->has_option_value("PrintIdealGraphLevel", > ideal_graph_level); // update value with per-method value (if available) > + return C->directive()->IGVPrintLevelOption >= level; > > src/share/vm/opto/compile.cpp > - method_has_option_value("MaxNodeLimit", _max_node_limit); > + _max_node_limit = _directive->MaxNodeLimitOption; > > src/share/vm/opto/superword.cpp > - _phase->C->method()->has_option_value("VectorizeDebug", > _vector_loop_debug); > + _vector_loop_debug = phase->C->directive()->VectorizeDebugOption; > > > The only location in the source code that you still use > has_option_value() is: > > src/share/vm/compiler/compileBroker.cpp > - if (CompilerOracle::should_exclude(method, quietly) > - || (CompilerOracle::has_option_value(method, > "CompileThresholdScaling", scale) && scale == 0)) { > + if (excluded || (CompilerOracle::has_option_value(method, > "CompileThresholdScaling", scale) && scale == 0)) { > > Could you please explain why you use has_option_value() at this source > location instead of a directive (as at all other places, e.g, in the > case of PrintIdealGraphLevel, MaxNodeLimit, and VectorizeDebug)? Yes. The intention was to use directives everywhere where option-commands are used. However - the "CompileThresholdScaling" (and the lock eliding options) is also accessed from outside the compilers. (That means a lot of the efficiency gains of having directives is lost.) I didn't have the time to test and verify the performance of that, so I have left it out. I will address this in the future as a small update. Best regards, Nils > > Thank you and best regards, > > > Zoltan > > On 10/06/2015 07:06 PM, Nils Eliasson wrote: >> Hi Zoltan, >> >> All the CompileCommand options work in the same way as described in >> the intrinsics-mail. In compilerDirectives.hpp the flags are declared >> with their CompileCommand equivalent. And in >> compilecommand_compatibility_init the directives may be updated with >> these flags. >> >> Take a look at >> test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityCommandOn.java >> for an example of how it can work. First these are set on the >> commandline "-XX:-PrintAssembly -XX:CompileCommand=print,*.*", then >> in the test a directive is loaded that turns it off. Later the >> directive is removed. The result is verified at each step. >> >> I hope my explanation is understandable. >> >> Best regards, >> Nils Eliasson >> >> >> >> >> On 2015-10-06 16:16, Zolt?n Maj? wrote: >>> Hi, >>> >>> >>> there is another question that comes to my mind. >>> >>> For command-line flags that allow per-method usage you propose to >>> get the flag's value from the directive instead of getting the value >>> using ciMethod()::has_option_value(). For example, you propose to use >>> >>> _vector_loop_debug = directive()->VectorizeDebugOption; >>> >>> instead of >>> >>> method()->has_option_value("VectorizeDebug", _vector_loop_debug); >>> >>> You propose to do this for almost all flags (e.g., VectorizeDebug, >>> DisableIntrinsic, MaxNodeLimit, PrintIdealGraphLevel) except one, >>> CompileThresholdScaling. Could you please explain why? >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> >>> On 10/02/2015 04:10 PM, Nils Eliasson wrote: >>>> Hi all, >>>> >>>> A new webrev with all the feedback from reviewers and others. >>>> >>>> http://cr.openjdk.java.net/~neliasso/8046155/webrev.04/ >>>> >>>> - name changes as requested by christian >>>> - various small bug fixes >>>> - New tests for sanity testing flags and their behaviour with vm >>>> flags and compile commands present >>>> >>>> Regards, >>>> Nils >>>> >>>> On 2015-09-22 19:21, Nils Eliasson wrote: >>>>> Hi, >>>>> >>>>> This is the initial RFR for JEP165: Compiler Control. This feature >>>>> enables runtime manageable, method dependent compiler flags. >>>>> (Immutable for the duration of a compilation.) >>>>> >>>>> The change includes: >>>>> - A parser for the directives format (json like) including vmtests >>>>> (json.cpp/hpp) >>>>> - A component for construction of compiler directives >>>>> (directivesParser.cpp/hpp) >>>>> - The directives including the option definitions, default values >>>>> and compilecommand relations (compilerDirectives.cpp/hpp) >>>>> - Diagnostic commands for working with the directives - >>>>> installing, removing, printing >>>>> - Lots of small changes wherever we access flags or legacy >>>>> compilecommands in the compiler >>>>> >>>>> Notes: >>>>> The feature is documented in the JEP >>>>> (https://bugs.openjdk.java.net/browse/JDK-8046155). >>>>> >>>>> Currently only a small amount of compiler flags are included in >>>>> the change. The flags are a representative selection of different >>>>> types targeting both compilers. All of them existed as >>>>> CompilerOracle option commands. Two commands was not included in >>>>> the directives due to time constraints - CompilerThresholdScaling >>>>> and UseRTMLocks. Both are accessed from runtime (outside any >>>>> compiler) and requires some special handling. (Solved but not >>>>> implemented.) >>>>> >>>>> Full backwards compatibility with CompileCommands is implemented >>>>> but can be turned off with flag -XX:CompileCommandCompatibilty. >>>>> Also meta handling the compatibility flag by supporting it in the >>>>> directives (test feature). >>>>> >>>>> The change contain some rough edges that will polished over the >>>>> coming days. >>>>> >>>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8046155 >>>>> Hotspot webrev: >>>>> http://cr.openjdk.java.net/~neliasso/8046155/webrev.01/ >>>>> JDK webrev: >>>>> http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.01/ >>>>> >>>>> Please review! >>>>> >>>>> Best regards, >>>>> Nils Eliasson >>>> >>> >> > From zoltan.majo at oracle.com Wed Oct 7 10:21:02 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 7 Oct 2015 12:21:02 +0200 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: <5614ECD1.60108@oracle.com> References: <56018E2B.2000108@oracle.com> <560E9050.6000804@oracle.com> <5613D7A4.6010205@oracle.com> <5613FF81.9070304@oracle.com> <5614D341.1030707@oracle.com> <5614ECD1.60108@oracle.com> Message-ID: <5614F20E.3020504@oracle.com> Hi Nils, On 10/07/2015 11:58 AM, Nils Eliasson wrote: > [...] > > Yes. The intention was to use directives everywhere where > option-commands are used. However - the "CompileThresholdScaling" (and > the lock eliding options) is also accessed from outside the compilers. > (That means a lot of the efficiency gains of having directives is > lost.) I didn't have the time to test and verify the performance of > that, so I have left it out. I will address this in the future as a > small update. Thank you for explaining! I'm fine with addressing this in the future. Best regards, Zoltan > > Best regards, > Nils > >> >> Thank you and best regards, >> >> >> Zoltan >> >> On 10/06/2015 07:06 PM, Nils Eliasson wrote: >>> Hi Zoltan, >>> >>> All the CompileCommand options work in the same way as described in >>> the intrinsics-mail. In compilerDirectives.hpp the flags are >>> declared with their CompileCommand equivalent. And in >>> compilecommand_compatibility_init the directives may be updated with >>> these flags. >>> >>> Take a look at >>> test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityCommandOn.java >>> for an example of how it can work. First these are set on the >>> commandline "-XX:-PrintAssembly -XX:CompileCommand=print,*.*", then >>> in the test a directive is loaded that turns it off. Later the >>> directive is removed. The result is verified at each step. >>> >>> I hope my explanation is understandable. >>> >>> Best regards, >>> Nils Eliasson >>> >>> >>> >>> >>> On 2015-10-06 16:16, Zolt?n Maj? wrote: >>>> Hi, >>>> >>>> >>>> there is another question that comes to my mind. >>>> >>>> For command-line flags that allow per-method usage you propose to >>>> get the flag's value from the directive instead of getting the >>>> value using ciMethod()::has_option_value(). For example, you >>>> propose to use >>>> >>>> _vector_loop_debug = directive()->VectorizeDebugOption; >>>> >>>> instead of >>>> >>>> method()->has_option_value("VectorizeDebug", _vector_loop_debug); >>>> >>>> You propose to do this for almost all flags (e.g., VectorizeDebug, >>>> DisableIntrinsic, MaxNodeLimit, PrintIdealGraphLevel) except one, >>>> CompileThresholdScaling. Could you please explain why? >>>> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> >>>> On 10/02/2015 04:10 PM, Nils Eliasson wrote: >>>>> Hi all, >>>>> >>>>> A new webrev with all the feedback from reviewers and others. >>>>> >>>>> http://cr.openjdk.java.net/~neliasso/8046155/webrev.04/ >>>>> >>>>> - name changes as requested by christian >>>>> - various small bug fixes >>>>> - New tests for sanity testing flags and their behaviour with vm >>>>> flags and compile commands present >>>>> >>>>> Regards, >>>>> Nils >>>>> >>>>> On 2015-09-22 19:21, Nils Eliasson wrote: >>>>>> Hi, >>>>>> >>>>>> This is the initial RFR for JEP165: Compiler Control. This >>>>>> feature enables runtime manageable, method dependent compiler >>>>>> flags. (Immutable for the duration of a compilation.) >>>>>> >>>>>> The change includes: >>>>>> - A parser for the directives format (json like) including >>>>>> vmtests (json.cpp/hpp) >>>>>> - A component for construction of compiler directives >>>>>> (directivesParser.cpp/hpp) >>>>>> - The directives including the option definitions, default values >>>>>> and compilecommand relations (compilerDirectives.cpp/hpp) >>>>>> - Diagnostic commands for working with the directives - >>>>>> installing, removing, printing >>>>>> - Lots of small changes wherever we access flags or legacy >>>>>> compilecommands in the compiler >>>>>> >>>>>> Notes: >>>>>> The feature is documented in the JEP >>>>>> (https://bugs.openjdk.java.net/browse/JDK-8046155). >>>>>> >>>>>> Currently only a small amount of compiler flags are included in >>>>>> the change. The flags are a representative selection of different >>>>>> types targeting both compilers. All of them existed as >>>>>> CompilerOracle option commands. Two commands was not included in >>>>>> the directives due to time constraints - CompilerThresholdScaling >>>>>> and UseRTMLocks. Both are accessed from runtime (outside any >>>>>> compiler) and requires some special handling. (Solved but not >>>>>> implemented.) >>>>>> >>>>>> Full backwards compatibility with CompileCommands is implemented >>>>>> but can be turned off with flag -XX:CompileCommandCompatibilty. >>>>>> Also meta handling the compatibility flag by supporting it in the >>>>>> directives (test feature). >>>>>> >>>>>> The change contain some rough edges that will polished over the >>>>>> coming days. >>>>>> >>>>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8046155 >>>>>> Hotspot webrev: >>>>>> http://cr.openjdk.java.net/~neliasso/8046155/webrev.01/ >>>>>> JDK webrev: >>>>>> http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.01/ >>>>>> >>>>>> Please review! >>>>>> >>>>>> Best regards, >>>>>> Nils Eliasson >>>>> >>>> >>> >> > From nils.eliasson at oracle.com Wed Oct 7 10:38:05 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 7 Oct 2015 12:38:05 +0200 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: <56018E2B.2000108@oracle.com> References: <56018E2B.2000108@oracle.com> Message-ID: <5614F60D.3040602@oracle.com> Hi all, Latest webrev including fixes after comments from Chris and Zoltan: http://cr.openjdk.java.net/~neliasso/8046155/webrev.09/ Regards, //Nils On 2015-09-22 19:21, Nils Eliasson wrote: > Hi, > > This is the initial RFR for JEP165: Compiler Control. This feature > enables runtime manageable, method dependent compiler flags. > (Immutable for the duration of a compilation.) > > The change includes: - A parser for the directives format (json like) > including vmtests (json.cpp/hpp) - A component for construction of > compiler directives (directivesParser.cpp/hpp) - The directives > including the option definitions, default values and compilecommand > relations (compilerDirectives.cpp/hpp) - Diagnostic commands for > working with the directives - installing, removing, printing - Lots > of small changes wherever we access flags or legacy compilecommands > in the compiler > > Notes: The feature is documented in the JEP > (https://bugs.openjdk.java.net/browse/JDK-8046155). > > Currently only a small amount of compiler flags are included in the > change. The flags are a representative selection of different types > targeting both compilers. All of them existed as CompilerOracle > option commands. Two commands was not included in the directives due > to time constraints - CompilerThresholdScaling and UseRTMLocks. Both > are accessed from runtime (outside any compiler) and requires some > special handling. (Solved but not implemented.) > > Full backwards compatibility with CompileCommands is implemented but > can be turned off with flag -XX:CompileCommandCompatibilty. Also meta > handling the compatibility flag by supporting it in the directives > (test feature). > > The change contain some rough edges that will polished over the > coming days. > > JEP: https://bugs.openjdk.java.net/browse/JDK-8046155 Hotspot webrev: > http://cr.openjdk.java.net/~neliasso/8046155/webrev.01/ JDK webrev: > http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.01/ > > Please review! > > Best regards, Nils Eliasson -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Wed Oct 7 11:20:24 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 7 Oct 2015 12:20:24 +0100 Subject: AARCH64: 8139041: Redundant DMB instructions Message-ID: <5614FFF8.3070308@redhat.com> In many places we issue redundant memory barriers. For example, in (C2-compiled) java.util.concurrent.ConcurrentHashMap$Node:: we see: 0x000003ffa85d73d0: dmb ish 0x000003ffa85d73d4: mov x11, x4 0x000003ffa85d73d8: lsr xmethod, x1, #9 0x000003ffa85d73dc: str w11, [x1,#20] 0x000003ffa85d73e0: dmb ishst 0x000003ffa85d73e4: strb wzr, [x10,x12,lsl #0] ;; membar_volatile 0x000003ffa85d73e8: dmb ish ;*putfield val ; - java.util.concurrent.ConcurrentHashMap$Node::@16 (line 629) ;; membar_release 0x000003ffa85d73ec: dmb ish 0x000003ffa85d73f0: mov x11, x5 0x000003ffa85d73f4: lsr xmethod, x1, #9 0x000003ffa85d73f8: str w11, [x1,#24] 0x000003ffa85d73fc: dmb ishst 0x000003ffa85d7400: strb wzr, [x10,x12,lsl #0] ;; membar_volatile 0x000003ffa85d7404: dmb ish ;*putfield next ; - java.util.concurrent.ConcurrentHashMap$Node::@22 (line 630) We see essentially the same effect in C1-compiled code. I'm sure that it is possible to write (or modify) a C2 pass to remove these. However, the ideal graph structure around the barriers is complex, getting it right would be hard, and it would add compilation time. There is a much simpler way: remove adjacent barriers in MacroAssembler. Thanks to the way that the AArch64 ISA is designed, barriers can be merged simply by ORing them together. Of course, this technique works for C1 and C2, and it adds essentially nothing to the compilation time. http://cr.openjdk.java.net/~aph/JDK-6584008/ One thing which may be controversial is that I've added a field to CodeBuffer to keep track of barriers and labels. I had to do this because when we're compiling there is (AFAICS) essentially nowhere else to keep the state. Thoughts? Thanks, Andrew. From adinn at redhat.com Wed Oct 7 11:25:35 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 7 Oct 2015 12:25:35 +0100 Subject: RFR: 8139042: AARCH64: Correct regression introduced by 8080293 Message-ID: <5615012F.4090500@redhat.com> Could two reviewers please review this AArch64 only patch. http://cr.openjdk.java.net/~adinn/8139042/webrev.00/ The fix for issue JDK-8080293 (AARCH64: Remove unnecessary dmbs from generated CAS code) inadvertently disabled one step of the optimization process for unsafe volatile object gets. The result is that unsafe volatile get is successfully translated to ldar but generation of the trailing dmb ishld instruction is not inhibited. The patch for 8080293 extended predicate unnecessary_acquire to check for a MemBarAcquire associated with a CompareAndSwapX node. In doing so it changed the logic of a sanity check for MemBarAcquire introdcued as part of an unsafe volatile get. The patch modified the code to conditionally return true instead of return false. However the condition retained the original != where it should have employed ==. 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 hui.shi at linaro.org Wed Oct 7 11:42:32 2015 From: hui.shi at linaro.org (Hui Shi) Date: Wed, 7 Oct 2015 19:42:32 +0800 Subject: AARCH64: 8139041: Redundant DMB instructions In-Reply-To: <5614FFF8.3070308@redhat.com> References: <5614FFF8.3070308@redhat.com> Message-ID: Hi Andrew, Is your patch for other work item? http://cr.openjdk.java.net/~aph/JDK-6584008/ is not patch in MacroAssembler Regards Shi Hui On 7 October 2015 at 19:20, Andrew Haley wrote: > In many places we issue redundant memory barriers. > > For example, in (C2-compiled) > java.util.concurrent.ConcurrentHashMap$Node:: we see: > > 0x000003ffa85d73d0: dmb ish > 0x000003ffa85d73d4: mov x11, x4 > 0x000003ffa85d73d8: lsr xmethod, x1, #9 > 0x000003ffa85d73dc: str w11, [x1,#20] > 0x000003ffa85d73e0: dmb ishst > 0x000003ffa85d73e4: strb wzr, [x10,x12,lsl #0] > ;; membar_volatile > 0x000003ffa85d73e8: dmb ish ;*putfield val > ; - > java.util.concurrent.ConcurrentHashMap$Node::@16 (line 629) > > ;; membar_release > 0x000003ffa85d73ec: dmb ish > 0x000003ffa85d73f0: mov x11, x5 > 0x000003ffa85d73f4: lsr xmethod, x1, #9 > 0x000003ffa85d73f8: str w11, [x1,#24] > 0x000003ffa85d73fc: dmb ishst > 0x000003ffa85d7400: strb wzr, [x10,x12,lsl #0] > ;; membar_volatile > 0x000003ffa85d7404: dmb ish ;*putfield next > ; - > java.util.concurrent.ConcurrentHashMap$Node::@22 (line 630) > > We see essentially the same effect in C1-compiled code. > > I'm sure that it is possible to write (or modify) a C2 pass to remove > these. However, the ideal graph structure around the barriers is > complex, getting it right would be hard, and it would add compilation > time. > > There is a much simpler way: remove adjacent barriers in > MacroAssembler. Thanks to the way that the AArch64 ISA is designed, > barriers can be merged simply by ORing them together. Of course, this > technique works for C1 and C2, and it adds essentially nothing to the > compilation time. > > http://cr.openjdk.java.net/~aph/JDK-6584008/ > > One thing which may be controversial is that I've added a field to > CodeBuffer to keep track of barriers and labels. I had to do this > because when we're compiling there is (AFAICS) essentially nowhere > else to keep the state. > > Thoughts? > > Thanks, > Andrew. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adinn at redhat.com Wed Oct 7 11:45:14 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 7 Oct 2015 12:45:14 +0100 Subject: RFR: 8139042: AARCH64: Correct regression introduced by 8080293 In-Reply-To: <5615012F.4090500@redhat.com> References: <5615012F.4090500@redhat.com> Message-ID: <561505CA.1020505@redhat.com> Oops. forgot to copy to aarch64-port-dev n.b. the patch is against the latest jdk9/hs--comp -------- Forwarded Message -------- Subject: RFR: 8139042: AARCH64: Correct regression introduced by 8080293 Date: Wed, 7 Oct 2015 12:25:35 +0100 From: Andrew Dinn To: hotspot compiler Could two reviewers please review this AArch64 only patch. http://cr.openjdk.java.net/~adinn/8139042/webrev.00/ The fix for issue JDK-8080293 (AARCH64: Remove unnecessary dmbs from generated CAS code) inadvertently disabled one step of the optimization process for unsafe volatile object gets. The result is that unsafe volatile get is successfully translated to ldar but generation of the trailing dmb ishld instruction is not inhibited. The patch for 8080293 extended predicate unnecessary_acquire to check for a MemBarAcquire associated with a CompareAndSwapX node. In doing so it changed the logic of a sanity check for MemBarAcquire introdcued as part of an unsafe volatile get. The patch modified the code to conditionally return true instead of return false. However the condition retained the original != where it should have employed ==. 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 aph at redhat.com Wed Oct 7 11:45:38 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 7 Oct 2015 12:45:38 +0100 Subject: AARCH64: 8139041: Redundant DMB instructions In-Reply-To: References: <5614FFF8.3070308@redhat.com> Message-ID: <561505E2.7070307@redhat.com> On 10/07/2015 12:42 PM, Hui Shi wrote: > Is your patch for other work item? > http://cr.openjdk.java.net/~aph/JDK-6584008/ is not patch in MacroAssembler Should be http://cr.openjdk.java.net/~aph/8139041/ Thanks, Andrew. From aph at redhat.com Wed Oct 7 11:45:40 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 7 Oct 2015 12:45:40 +0100 Subject: AARCH64: 8139041: Redundant DMB instructions (CORRECTED ) Message-ID: <561505E4.207@redhat.com> Please ignore the previous message which had an incorrect URL. In many places we issue redundant memory barriers. For example, in (C2-compiled) java.util.concurrent.ConcurrentHashMap$Node:: we see: 0x000003ffa85d73d0: dmb ish 0x000003ffa85d73d4: mov x11, x4 0x000003ffa85d73d8: lsr xmethod, x1, #9 0x000003ffa85d73dc: str w11, [x1,#20] 0x000003ffa85d73e0: dmb ishst 0x000003ffa85d73e4: strb wzr, [x10,x12,lsl #0] ;; membar_volatile 0x000003ffa85d73e8: dmb ish ;*putfield val ; - java.util.concurrent.ConcurrentHashMap$Node::@16 (line 629) ;; membar_release 0x000003ffa85d73ec: dmb ish 0x000003ffa85d73f0: mov x11, x5 0x000003ffa85d73f4: lsr xmethod, x1, #9 0x000003ffa85d73f8: str w11, [x1,#24] 0x000003ffa85d73fc: dmb ishst 0x000003ffa85d7400: strb wzr, [x10,x12,lsl #0] ;; membar_volatile 0x000003ffa85d7404: dmb ish ;*putfield next ; - java.util.concurrent.ConcurrentHashMap$Node::@22 (line 630) We see essentially the same effect in C1-compiled code. I'm sure that it is possible to write (or modify) a C2 pass to remove these. However, the ideal graph structure around the barriers is complex, getting it right would be hard, and it would add compilation time. There is a much simpler way: remove adjacent barriers in MacroAssembler. Thanks to the way that the AArch64 ISA is designed, barriers can be merged simply by ORing them together. Of course, this technique works for C1 and C2, and it adds essentially nothing to the compilation time. http://cr.openjdk.java.net/~aph/8139041/ One thing which may be controversial is that I've added a field to CodeBuffer to keep track of barriers and labels. I had to do this because when we're compiling there is (AFAICS) essentially nowhere else to keep the state. Thoughts? Thanks, Andrew. From tobias.hartmann at oracle.com Wed Oct 7 13:10:57 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 07 Oct 2015 15:10:57 +0200 Subject: [9] RFR(XS): 8139048: Quarantine compiler/startup/SmallCodeCacheStartup.java Message-ID: <561519E1.6090501@oracle.com> Hi, please review this fix that quarantines compiler/startup/SmallCodeCacheStartup.java until JDK-8134286 is fixed. The test fails on JPRT for the CPU, CompactStrings and JVMCI repositories. http://cr.openjdk.java.net/~thartmann/8139048/webrev.00/ Thanks, Tobias From martin.doerr at sap.com Wed Oct 7 13:15:55 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 7 Oct 2015 13:15:55 +0000 Subject: RFR(XS) 8138891: C1: Missing release memory barrier in C1's CMS post-barrier In-Reply-To: References: <7C9B87B351A4BA4AA9EC95BB41811656722607F8@DEWDFEMB19C.global.corp.sap> Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165672260A57@DEWDFEMB19C.global.corp.sap> Hi, thanks for reviewing, Igor. Can any aarch64 expert comment on this? Are there known CMS problems? I couldn?t find a release barrier for the card mark store in C1 while I believe there is a releasing store in C2. This change adds a dmb instruction in front of the card mark store in C1 if ConcMarkSweepGC is used. Best regards, Martin From: Igor Veresov [mailto:igor.veresov at oracle.com] Sent: Mittwoch, 7. Oktober 2015 01:42 To: Doerr, Martin Cc: hotspot compiler Subject: Re: RFR(XS) 8138891: C1: Missing release memory barrier in C1's CMS post-barrier Looks good. igor On Oct 6, 2015, at 7:24 AM, Doerr, Martin > wrote: Hi, the dirty marking of the card table needs to be a releasing store for CMS. It's already there in template interpreter and C2 on PPC64. We have seen GC crashed when testing C1 on PPC64. Unfortunately, C1 does currently not support releasing stores (or load-acquire) which could be exploited on aarch64 or ia64. Hence, we?re using a membar_store_store. This change is a prerequisite for our C1 on PPC64 contribution. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8138891_c1_cms_membar/webrev.00 Please review this change. I need a sponsor, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.westrelin at oracle.com Wed Oct 7 13:16:12 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 7 Oct 2015 15:16:12 +0200 Subject: [9] RFR(XS): 8139048: Quarantine compiler/startup/SmallCodeCacheStartup.java In-Reply-To: <561519E1.6090501@oracle.com> References: <561519E1.6090501@oracle.com> Message-ID: <0A4D8372-5071-4D50-993E-CCE674E0A479@oracle.com> > http://cr.openjdk.java.net/~thartmann/8139048/webrev.00/ Looks good to me. Roland. From zoltan.majo at oracle.com Wed Oct 7 13:27:42 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 7 Oct 2015 15:27:42 +0200 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: <5614F60D.3040602@oracle.com> References: <56018E2B.2000108@oracle.com> <5614F60D.3040602@oracle.com> Message-ID: <56151DCE.90407@oracle.com> Hi Nils, On 10/07/2015 12:38 PM, Nils Eliasson wrote: > Hi all, > > Latest webrev including fixes after comments from Chris and Zoltan: > http://cr.openjdk.java.net/~neliasso/8046155/webrev.09/ thank you for the updated version. It seems, however, that the DisableIntrinsic flag does not work correctly on the per-method level. If I execute the MathTest program I've sent out before with the command-line option -XX:CompileCommand=option,MathTest::test1,ccstr,DisableIntrinsic,_dsin with jdk9-b83, I get the expected behavior (Math.sin is inlined into test2 but not into test1): 128 1 b 3 MathTest::test1 (7 bytes) @ 3 java.lang.Math::sin (5 bytes) @ 1 java/lang/StrictMath::sin (not loaded) not inlineable 130 2 n 0 java.lang.StrictMath::sin (native) (static) 132 3 b 3 MathTest::test2 (7 bytes) @ 3 java.lang.Math::sin (5 bytes) intrinsic If I execute the test case with a locally-built jdk patched with webrev.09, I get an erronous behavior (Math.sin is not inlined into test2 although it should be): 133 1 b 3 MathTest::test1 (7 bytes) @ 3 java.lang.Math::sin (5 bytes) @ 1 java/lang/StrictMath::sin (not loaded) not inlineable 136 2 n 0 java.lang.StrictMath::sin (native) (static) 138 3 b 3 MathTest::test2 (7 bytes) @ 3 java.lang.Math::sin (5 bytes) @ 1 java.lang.StrictMath::sin (0 bytes) native method Could you please check why that happens? Thank you and best regards, Zoltan > > Regards, > //Nils > > > > On 2015-09-22 19:21, Nils Eliasson wrote: > > Hi, > > This is the initial RFR for JEP165: Compiler Control. This > feature > enables runtime manageable, method dependent compiler flags. > > (Immutable for the duration of a compilation.) > > The change > includes: - A parser for the directives format (json like) > including > vmtests (json.cpp/hpp) - A component for construction of > compiler > directives (directivesParser.cpp/hpp) - The directives > including the > option definitions, default values and compilecommand > relations > (compilerDirectives.cpp/hpp) - Diagnostic commands for > working with > the directives - installing, removing, printing - Lots > of small > changes wherever we access flags or legacy compilecommands > in the > compiler > > Notes: The feature is documented in the JEP > > (https://bugs.openjdk.java.net/browse/JDK-8046155). > > Currently only > a small amount of compiler flags are included in the > change. The > flags are a representative selection of different types > targeting > both compilers. All of them existed as CompilerOracle > option > commands. Two commands was not included in the directives due > to > time constraints - CompilerThresholdScaling and UseRTMLocks. Both > > are accessed from runtime (outside any compiler) and requires some > > special handling. (Solved but not implemented.) > > Full backwards > compatibility with CompileCommands is implemented but > can be turned > off with flag -XX:CompileCommandCompatibilty. Also meta > handling the > compatibility flag by supporting it in the directives > (test > feature). > > The change contain some rough edges that will polished > over the > coming days. > > JEP: > https://bugs.openjdk.java.net/browse/JDK-8046155 Hotspot webrev: > > http://cr.openjdk.java.net/~neliasso/8046155/webrev.01/ JDK webrev: > > http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.01/ > > Please > review! > > Best regards, Nils Eliasson > > From aph at redhat.com Wed Oct 7 13:28:06 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 7 Oct 2015 14:28:06 +0100 Subject: RFR(XS) 8138891: C1: Missing release memory barrier in C1's CMS post-barrier In-Reply-To: <7C9B87B351A4BA4AA9EC95BB4181165672260A57@DEWDFEMB19C.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB41811656722607F8@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672260A57@DEWDFEMB19C.global.corp.sap> Message-ID: <56151DE6.8090605@redhat.com> On 10/07/2015 02:15 PM, Doerr, Martin wrote: > Can any aarch64 expert comment on this? Are there known CMS problems? This is already fixed. http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/raw-rev/91c907c47794 Andrew. From tobias.hartmann at oracle.com Wed Oct 7 13:37:09 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 07 Oct 2015 15:37:09 +0200 Subject: [9] RFR(XS): 8139048: Quarantine compiler/startup/SmallCodeCacheStartup.java In-Reply-To: <0A4D8372-5071-4D50-993E-CCE674E0A479@oracle.com> References: <561519E1.6090501@oracle.com> <0A4D8372-5071-4D50-993E-CCE674E0A479@oracle.com> Message-ID: <56152005.9060307@oracle.com> Thanks, Roland. Best, Tobias On 07.10.2015 15:16, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~thartmann/8139048/webrev.00/ > > Looks good to me. > > Roland. > From tobias.hartmann at oracle.com Wed Oct 7 13:38:20 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 07 Oct 2015 15:38:20 +0200 Subject: [9] RFR(M): 8078554: Compiler: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <5613B44F.4090007@oracle.com> References: <560BB4F6.3050703@oracle.com> <4502D8F6-B256-4222-B1D3-92ED5C100B6E@oracle.com> <5613B44F.4090007@oracle.com> Message-ID: <5615204C.8080202@oracle.com> Hi Zoltan, I had a look at your changes and just spotted some minor things: globals_sparc.hpp: - I think there is a '\' missing in line 119 globals_x86.hpp: - Isn't this also a compiler flag we should add range checks for? 136 product(uintx, RTMRetryCount, 5, commandLineFlagConstraintsCompiler.cpp: - I think there is a "rule" that the include statements should be in alphabetical order - the indentation is wrong here: 179 return Flag::VIOLATES_CONSTRAINT; Best, Tobias On 06.10.2015 13:45, Zolt?n Maj? wrote: > Hi Roland, > > > thank you for the feedback! > > On 10/02/2015 03:55 PM, Roland Westrelin wrote: >> Hi Zoltan, >> >>> Webrev:http://cr.openjdk.java.net/~zmajo/8078554/ >> c2_globals.hpp >> >> That one is not correct: >> 461 product(intx, MaxNodeLimit, 80000, \ >> 462 "Maximum number of nodes") \ >> 463 range(1000, 80000) \ >> >> I think the upper bound should be max_juint > > You are right that the limit of 80'000 is too conservative. But max_j*u*int as an upper bound would cause an overflow when parsing the flag's value, because on 32-bit machines intx is a 32-bit signed integer. > > Using max_jint instead of max_j*u*int as an upper bound would not cause an overflow at parse time. However, in Parse::do_call() the maximum node limit is increased by 3 times for jsr292 users > > C->set_max_node_limit(3*MaxNodeLimit); > > If MaxNodeLimit == max_jint, this expression will overflow, I think. > > So I set the limit to (max_jint / 3) in the updated webrev. > > If we would set MaxNodeLimit to max_j*u*int / 3 (instead of max_jint / 3), the expression 3 * MaxNodeLimit would overflow as well. Changing the type of the flag from intx to uintx could let use use max_j*u*int / 3 as an upper bound, but that is most likely not worth the effort. > >> 699 product(intx, LiveNodeCountInliningCutoff, 40000, \ >> 700 "max number of live nodes in a method") \ >> 701 range(0, max_juint / 8) \ >> >> Out of curiosity why max_juint / 8 (not that it makes much of a difference)? > > In Compile::inline_incrementally, the 80% of LiveNodeCountInliningCutoff is computed the following way: > > if (low_live_nodes < (uint)LiveNodeCountInliningCutoff * 8 / 10) { > > If LiveNodeCountInliningCutoff == max_juint, we'd have an overflow because of the multiplication by 8. > >> arguments.cpp >> >> 1099 Tier3InvokeNotifyFreqLog = 0; >> 1100 Tier4InvocationThreshold = 0; >> >> Why that change? > > I proposed that change because I misread the code. I reverted that change and also changed the range of all Tier*FreqLog flags from range(1, 30) to range(0, 30). > >> globals.hp >> >> 2870 product_pd(uintx, TypeProfileLevel, \ >> 2871 "=XYZ, with Z: Type profiling of arguments at call; " \ >> 2872 "Y: Type profiling of return value at call; " \ >> 2873 "X: Type profiling of parameters to methods; " \ >> 2874 "X, Y and Z in 0=off ; 1=jsr292 only; 2=all methods") \ >> 2875 range(0, 222) >> >> Legal values are 0, 1, 2, 10, 11, 12, 100, 101, 102, 110, 111, 112 etc. >> >> 70 is not for instance. So range(0, 222) is incorrect. > > I agree. I removed the range check and implemented a constraint function instead (TypeProfileLevelConstraintFunc). > >> 2877 product(intx, TypeProfileArgsLimit, 2, \ >> 2878 "max number of call arguments to consider for type profiling") \ >> 2879 range(0, 16) \ >> >> 2880 \ >> 2881 product(intx, TypeProfileParmsLimit, 2, \ >> 2882 "max number of incoming parameters to consider for type profiling"\ >> 2883 ", -1 for all") \ >> 2884 range(-1, 64) >> >> Why 16 and 64? > > These are the largest values that work on all platforms we support. > > Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8078554/webrev.01/ > > I repeated the testing with JPRT. I also executed the currently disabled TestOptionsWithRanges.java test on all platforms we support. All tests pass. > > Thank you and best regards, > > > Zoltan > >> Roland. > From martin.doerr at sap.com Wed Oct 7 13:46:54 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 7 Oct 2015 13:46:54 +0000 Subject: RFR(XS) 8138891: C1: Missing release memory barrier in C1's CMS post-barrier In-Reply-To: <56151DE6.8090605@redhat.com> References: <7C9B87B351A4BA4AA9EC95BB41811656722607F8@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672260A57@DEWDFEMB19C.global.corp.sap> <56151DE6.8090605@redhat.com> Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165672260AAB@DEWDFEMB19C.global.corp.sap> Thanks for pointing me to 8135018: AARCH64: Missing memory barriers for CMS collector It is already fixed in hs-rt. Will it get merged into hs-comp soon? Can I close my bug as duplicate? Best regards, Martin -----Original Message----- From: Andrew Haley [mailto:aph at redhat.com] Sent: Mittwoch, 7. Oktober 2015 15:28 To: Doerr, Martin; Igor Veresov Cc: hotspot compiler Subject: Re: RFR(XS) 8138891: C1: Missing release memory barrier in C1's CMS post-barrier On 10/07/2015 02:15 PM, Doerr, Martin wrote: > Can any aarch64 expert comment on this? Are there known CMS problems? This is already fixed. http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/raw-rev/91c907c47794 Andrew. From martin.doerr at sap.com Wed Oct 7 14:17:15 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 7 Oct 2015 14:17:15 +0000 Subject: RFR(S): 8138890: C1: Ambiguous operator delete In-Reply-To: References: <7C9B87B351A4BA4AA9EC95BB41811656722607B5@DEWDFEMB19C.global.corp.sap> Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165672260AE1@DEWDFEMB19C.global.corp.sap> Hi, that's a good question :) I can only remember that there were problems with some old compilers. Anyway, xlC 12.1 can deal with the private delete operators. Here's the new webrev: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.01 Best regards, Martin From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Mittwoch, 7. Oktober 2015 03:32 To: Doerr, Martin Cc: hotspot compiler Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete On Oct 6, 2015, at 3:56 AM, Doerr, Martin > wrote: Hi, xlC on AIX rejects to compile LIRGenerator and RangeCheckEliminator::Verification due to ambiguous operator delete which gets inherited from multiple base classes. This change is a prerequisite for our C1 on PPC64 contribution. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.00 Let me ask my question here: why do you need the delete methods to be public on AIX? Please review this change. I need a sponsor, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From zoltan.majo at oracle.com Wed Oct 7 14:20:15 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 7 Oct 2015 16:20:15 +0200 Subject: [9] RFR(S): 8137160: Use Compile::live_nodes instead of Compile::unique() in appropriate places -- followup Message-ID: <56152A1F.6030609@oracle.com> Hi, please review the following patch for JDK-8137160. Bug: https://bugs.openjdk.java.net/browse/JDK-8137160 Problem: JDK-8011858 changed memory allocation for compiler-related data structures to use Compile::live_nodes() instead of Compile::unique_nodes() to reduce the C2 compiler's memory usage. While backporting JDK-8011858 to 8u72, we discovered two code locations where live_nodes() and be used instead of unique_nodes(). Solution: This patch changes allocation at the above-mentioned two code locations to use live_nodes() instead of unique_nodes(). The patch also updates comments so that they match the source code. Webrev: http://cr.openjdk.java.net/~zmajo/8137160/webrev.00/ Testing: - JPRT, all tests pass; - all hotspot tests executed locally; all tests pass that pass with an unmodified VM. Thank you and best regards, Zoltan From vladimir.kozlov at oracle.com Wed Oct 7 14:24:49 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 7 Oct 2015 22:24:49 +0800 Subject: [9] RFR(S): 8137160: Use Compile::live_nodes instead of Compile::unique() in appropriate places -- followup In-Reply-To: <56152A1F.6030609@oracle.com> References: <56152A1F.6030609@oracle.com> Message-ID: <56152B31.70200@oracle.com> Looks good. Thanks, Vladimir On 10/7/15 10:20 PM, Zolt?n Maj? wrote: > Hi, > > > please review the following patch for JDK-8137160. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8137160 > > Problem: JDK-8011858 changed memory allocation for compiler-related data > structures to use Compile::live_nodes() instead of > Compile::unique_nodes() to reduce the C2 compiler's memory usage. While > backporting JDK-8011858 to 8u72, we discovered two code locations where > live_nodes() and be used instead of unique_nodes(). > > Solution: This patch changes allocation at the above-mentioned two code > locations to use live_nodes() instead of unique_nodes(). The patch also > updates comments so that they match the source code. > > Webrev: > http://cr.openjdk.java.net/~zmajo/8137160/webrev.00/ > > Testing: > - JPRT, all tests pass; > - all hotspot tests executed locally; all tests pass that pass with an > unmodified VM. > > Thank you and best regards, > > > Zoltan > From vladimir.kozlov at oracle.com Wed Oct 7 14:31:27 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 7 Oct 2015 22:31:27 +0800 Subject: RFR: 8139042: AARCH64: Correct regression introduced by 8080293 In-Reply-To: <5615012F.4090500@redhat.com> References: <5615012F.4090500@redhat.com> Message-ID: <56152CBF.2090404@oracle.com> Good. Thanks, Vladimir On 10/7/15 7:25 PM, Andrew Dinn wrote: > Could two reviewers please review this AArch64 only patch. > > http://cr.openjdk.java.net/~adinn/8139042/webrev.00/ > > The fix for issue JDK-8080293 (AARCH64: Remove unnecessary dmbs from > generated CAS code) inadvertently disabled one step of the optimization > process for unsafe volatile object gets. The result is that unsafe > volatile get is successfully translated to ldar but generation of the > trailing dmb ishld instruction is not inhibited. > > The patch for 8080293 extended predicate unnecessary_acquire to check > for a MemBarAcquire associated with a CompareAndSwapX node. In doing so > it changed the logic of a sanity check for MemBarAcquire introdcued as > part of an unsafe volatile get. The patch modified the code to > conditionally return true instead of return false. However the condition > retained the original != where it should have employed ==. > > 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 zoltan.majo at oracle.com Wed Oct 7 14:33:41 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 7 Oct 2015 16:33:41 +0200 Subject: [9] RFR(S): 8137160: Use Compile::live_nodes instead of Compile::unique() in appropriate places -- followup In-Reply-To: <56152B31.70200@oracle.com> References: <56152A1F.6030609@oracle.com> <56152B31.70200@oracle.com> Message-ID: <56152D45.5060007@oracle.com> Thank you, Vladimir, for the review! Best regards, Zoltan On 10/07/2015 04:24 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 10/7/15 10:20 PM, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the following patch for JDK-8137160. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8137160 >> >> Problem: JDK-8011858 changed memory allocation for compiler-related data >> structures to use Compile::live_nodes() instead of >> Compile::unique_nodes() to reduce the C2 compiler's memory usage. While >> backporting JDK-8011858 to 8u72, we discovered two code locations where >> live_nodes() and be used instead of unique_nodes(). >> >> Solution: This patch changes allocation at the above-mentioned two code >> locations to use live_nodes() instead of unique_nodes(). The patch also >> updates comments so that they match the source code. >> >> Webrev: >> http://cr.openjdk.java.net/~zmajo/8137160/webrev.00/ >> >> Testing: >> - JPRT, all tests pass; >> - all hotspot tests executed locally; all tests pass that pass with an >> unmodified VM. >> >> Thank you and best regards, >> >> >> Zoltan >> From aph at redhat.com Wed Oct 7 14:36:49 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 7 Oct 2015 15:36:49 +0100 Subject: RFR: 8139042: AARCH64: Correct regression introduced by 8080293 In-Reply-To: <5615012F.4090500@redhat.com> References: <5615012F.4090500@redhat.com> Message-ID: <56152E01.3060201@redhat.com> On 10/07/2015 12:25 PM, Andrew Dinn wrote: > Could two reviewers please review this AArch64 only patch. > > http://cr.openjdk.java.net/~adinn/8139042/webrev.00/ Looks good. Andrew. From mikael.gerdin at oracle.com Wed Oct 7 14:55:35 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 7 Oct 2015 16:55:35 +0200 Subject: RFR(S): 8138890: C1: Ambiguous operator delete In-Reply-To: <7C9B87B351A4BA4AA9EC95BB4181165672260AE1@DEWDFEMB19C.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB41811656722607B5@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672260AE1@DEWDFEMB19C.global.corp.sap> Message-ID: <56153267.7060401@oracle.com> On 2015-10-07 16:17, Doerr, Martin wrote: > Hi, > > that?s a good question J > > I can only remember that there were problems with some old compilers. > > Anyway, xlC 12.1 can deal with the private delete operators. If that's the case, can we also get rid of the workaround in allocation.hpp? Thanks /Mikael > > Here?s the new webrev: > > http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.01 > > Best regards, > > Martin > > *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com] > *Sent:* Mittwoch, 7. Oktober 2015 03:32 > *To:* Doerr, Martin > *Cc:* hotspot compiler > *Subject:* Re: RFR(S): 8138890: C1: Ambiguous operator delete > > On Oct 6, 2015, at 3:56 AM, Doerr, Martin > wrote: > > Hi, > > xlC on AIX rejects to compile LIRGenerator and > RangeCheckEliminator::Verification due to ambiguous operator delete > which gets inherited from multiple base classes. > > This change is a prerequisite for our C1 on PPC64 contribution. > > Webrev is here: > > http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.00 > > Let me ask my question here: why do you need the delete methods to be > public on AIX? > > > > Please review this change. I need a sponsor, please. > > Best regards, > > Martin > From goetz.lindenmaier at sap.com Wed Oct 7 15:28:50 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 7 Oct 2015 15:28:50 +0000 Subject: RFR(S): 8138890: C1: Ambiguous operator delete In-Reply-To: <56153267.7060401@oracle.com> References: <7C9B87B351A4BA4AA9EC95BB41811656722607B5@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672260AE1@DEWDFEMB19C.global.corp.sap> <56153267.7060401@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41E80C45@DEWDFEMB12A.global.corp.sap> Hi, As I remember we drilled down the issue in allocation.hpp to the attached test, which compiles with gcc but not with xlC. And the test still does not compile. IBM stated that that is incorrect C++. Martin, you can now remove the second 'private:'. And we wondered why no implementation is needed for the operators. Best regards, Goetz. -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Mikael Gerdin Sent: Mittwoch, 7. Oktober 2015 16:56 To: Doerr, Martin; Christian Thalinger Cc: hotspot compiler Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete On 2015-10-07 16:17, Doerr, Martin wrote: > Hi, > > that's a good question J > > I can only remember that there were problems with some old compilers. > > Anyway, xlC 12.1 can deal with the private delete operators. If that's the case, can we also get rid of the workaround in allocation.hpp? Thanks /Mikael > > Here's the new webrev: > > http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.01 > > Best regards, > > Martin > > *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com] > *Sent:* Mittwoch, 7. Oktober 2015 03:32 > *To:* Doerr, Martin > *Cc:* hotspot compiler > *Subject:* Re: RFR(S): 8138890: C1: Ambiguous operator delete > > On Oct 6, 2015, at 3:56 AM, Doerr, Martin > wrote: > > Hi, > > xlC on AIX rejects to compile LIRGenerator and > RangeCheckEliminator::Verification due to ambiguous operator delete > which gets inherited from multiple base classes. > > This change is a prerequisite for our C1 on PPC64 contribution. > > Webrev is here: > > http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.00 > > Let me ask my question here: why do you need the delete methods to be > public on AIX? > > > > Please review this change. I need a sponsor, please. > > Best regards, > > Martin > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test.cpp URL: From uwe at thetaphi.de Mon Oct 5 21:18:34 2015 From: uwe at thetaphi.de (Uwe Schindler) Date: Mon, 5 Oct 2015 23:18:34 +0200 Subject: RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server compiler In-Reply-To: <846C489A-B3DE-4E55-A5EC-C70146ADBF4E@oracle.com> References: <53037D5B-7CA1-493C-837B-AF502ADFDF83@oracle.com> <55E721C6.2000206@oracle.com> <066d01d0fecf$f4f42230$dedc6690$@apache.org> <06e001d0ff48$427d23d0$c7776b70$@apache.org> <82C6CE6C-1B2D-490C-9A0F-DE4132EDFE46@oracle.com> <06f801d0ff52$767fc2f0$637f48d0$@apache.org> <846C489A-B3DE-4E55-A5EC-C70146ADBF4E@oracle.com> Message-ID: <07e801d0ffb3$64a44360$2decca20$@thetaphi.de> I got another failure with exactly same code: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14421/ So it is definitely reproducible. I was not yet able to reproduce it or test your patch (I have not much experience in doing this). Maybe Dawid Weiss has some time to try it out. I just wanted to let you know that it is reproducible. The above Jenkins link allows to download hserr.pid and replay logs, too. Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Roland Westrelin [mailto:roland.westrelin at oracle.com] > Sent: Monday, October 05, 2015 11:55 AM > To: Uwe Schindler > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server > compiler > > > Do you know when the fix for JDK-8134974 is included in EA builds? If yes, > maybe we first try to check if it's already fixed. > > b84 it seems. > > You could try to apply the fix, it?s small: > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/bfb61f868681 > > Or we can wait until b84 is out and see if it?s still there. > > Roland. > > > > > Uwe > > > > ----- > > Uwe Schindler > > uschindler at apache.org > > ASF Member, Apache Lucene PMC / Committer Bremen, Germany > > http://lucene.apache.org/ > > > > > >> -----Original Message----- > >> From: Roland Westrelin [mailto:roland.westrelin at oracle.com] > >> Sent: Monday, October 05, 2015 11:01 AM > >> To: Uwe Schindler > >> Cc: hotspot-compiler-dev at openjdk.java.net > >> Subject: Re: RFR(S): 8134468: Lucene test failures with 32 bit JDK > >> 9b78, Server compiler > >> > >> Uwe, > >> > >>> Thanks. I was trying b82 yesterday and we already found a new bug. > >>> Tests > >> were failing with SIGSEGV on Jenkins: > >>> http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14121/ > >>> (you can download "hs_err" and "replay" from there, you can also see > >>> JVM > >> settings like bitness, Garbage Collector from there). > >> > >> Thanks for reporting this new issue. > >> > >>> > >>> Current CompileTask: > >>> C2: 866319 28632 4 > >> org.apache.directory.api.ldap.model.name.Rdn::apply (45 bytes) > >>> > >>> Stack: [0x00007f3e647e6000,0x00007f3e648e7000], > >>> sp=0x00007f3e648e1e60, free space=1007k Native frames: (J=compiled > >>> Java code, j=interpreted, Vv=VM code, C=native code) V > >>> [libjvm.so+0x80ccce] > >>> PhaseIdealLoop::build_loop_late_post(Node*)+0x13e > >>> V [libjvm.so+0x80d06b] PhaseIdealLoop::build_loop_late(VectorSet&, > >>> Node_List&, Node_Stack&)+0x13b V [libjvm.so+0x8102dc] > >>> PhaseIdealLoop::build_and_optimize(bool, bool)+0x88c V > >>> [libjvm.so+0x4e699a] Compile::Optimize()+0x6ca V > >>> [libjvm.so+0x4e83f0] Compile::Compile(ciEnv*, C2Compiler*, > >>> ciMethod*, int, bool, bool, bool)+0x1040 V [libjvm.so+0x42dbb9] > >>> C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0xe9 V > >>> [libjvm.so+0x4effda] > >>> CompileBroker::invoke_compiler_on_method(CompileTask*)+0x8ca > >>> V [libjvm.so+0x4f0a58] CompileBroker::compiler_thread_loop()+0x4a8 > >>> V [libjvm.so+0xa61038] JavaThread::thread_main_inner()+0xd8 > >>> V [libjvm.so+0xa611d8] JavaThread::run()+0x158 V > >>> [libjvm.so+0x9048e2] java_start(Thread*)+0xc2 C > >>> [libpthread.so.0+0x8182] start_thread+0xc2 > >>> > >>> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: > >>> 0x0000000000000008 > >>> > >>> > >>> This happened in parallel for 2 different JVMs (we are running tests > >>> in > >> parallel with multiple JVMs). We should look into this, too! Tell me > >> how I can help (as always, it is hard to reproduce). So this must be > >> some change between b78 and b82 (b78 is last known working config). > >> Maybe bells are ringing for you. > >> > >> It looks like it could be: > >> > >> https://bugs.openjdk.java.net/browse/JDK-8134974 > >> > >> Can you reproduce the issue at all? > >> > >> Roland.= > > From konstantin.shefov at oracle.com Wed Oct 7 15:28:48 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Wed, 7 Oct 2015 18:28:48 +0300 Subject: [9] RFR 8072369: [TESTBUG] Remove potentially insecure class cast in some hotspot tests In-Reply-To: References: <55EF0649.8050109@oracle.com> <55F0312E.7020908@oracle.com> Message-ID: <56153A30.7040705@oracle.com> Hi Christian The assumption that the Application Class Loader is an instance of URLClassLoader can be false, because, AFAIK, it is not documented anywhere. This may become false in the future releases of JDK. That is why it is better not to relay on this assumption. Thanks -Konstantin 06.10.2015 22:35, Christian Thalinger ?????: > >> On Sep 9, 2015, at 3:16 AM, Konstantin Shefov >> > >> wrote: >> >> Description of the fix. >> Some tests in hotspot repo use class cast from Application class >> loader to URLClassLoader, but Application class loader is not >> guaranteed to be always an instance of a URLClassLoader. > > Please excuse my lack of knowledge here but in what configuration does > this happen? > >> The tests should be changed so that they do not cast appclassloader >> to URLClassLoader. >> >> -Konstantin >> >> On 09/08/2015 07:01 PM, Konstantin Shefov wrote: >>> Hello >>> >>> Please review a test bug fix. >>> >>> JBS entry: https://bugs.openjdk.java.net/browse/JDK-8072369 >>> Webrev: http://cr.openjdk.java.net/~kshefov/8072369/webrev.00 >>> >>> Thanks >>> -Konstantin >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Wed Oct 7 15:31:06 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 7 Oct 2015 15:31:06 +0000 Subject: RFR(S): 8138890: C1: Ambiguous operator delete In-Reply-To: <56153267.7060401@oracle.com> References: <7C9B87B351A4BA4AA9EC95BB41811656722607B5@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672260AE1@DEWDFEMB19C.global.corp.sap> <56153267.7060401@oracle.com> Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165672260B8A@DEWDFEMB19C.global.corp.sap> Hi Mikael, unfortunately, the answer is no. 1540-0300 (S) The "private" member "StackObj::operator delete(void *)" cannot be accessed. However, the C1 files were ok without it. Best regards, Martin -----Original Message----- From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] Sent: Mittwoch, 7. Oktober 2015 16:56 To: Doerr, Martin; Christian Thalinger Cc: hotspot compiler Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete On 2015-10-07 16:17, Doerr, Martin wrote: > Hi, > > that's a good question J > > I can only remember that there were problems with some old compilers. > > Anyway, xlC 12.1 can deal with the private delete operators. If that's the case, can we also get rid of the workaround in allocation.hpp? Thanks /Mikael > > Here's the new webrev: > > http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.01 > > Best regards, > > Martin > > *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com] > *Sent:* Mittwoch, 7. Oktober 2015 03:32 > *To:* Doerr, Martin > *Cc:* hotspot compiler > *Subject:* Re: RFR(S): 8138890: C1: Ambiguous operator delete > > On Oct 6, 2015, at 3:56 AM, Doerr, Martin > wrote: > > Hi, > > xlC on AIX rejects to compile LIRGenerator and > RangeCheckEliminator::Verification due to ambiguous operator delete > which gets inherited from multiple base classes. > > This change is a prerequisite for our C1 on PPC64 contribution. > > Webrev is here: > > http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.00 > > Let me ask my question here: why do you need the delete methods to be > public on AIX? > > > > Please review this change. I need a sponsor, please. > > Best regards, > > Martin > From volker.simonis at gmail.com Wed Oct 7 15:56:52 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 7 Oct 2015 17:56:52 +0200 Subject: RFR(S): 8138890: C1: Ambiguous operator delete In-Reply-To: <56153267.7060401@oracle.com> References: <7C9B87B351A4BA4AA9EC95BB41811656722607B5@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672260AE1@DEWDFEMB19C.global.corp.sap> <56153267.7060401@oracle.com> Message-ID: Hi Martin, we have: class LIRGenerator: public InstructionVisitor, public BlockClosure and: class BlockClosure: public CompilationResourceObj class CompilationResourceObj ALLOCATION_SUPER_CLASS_SPEC { public: void* operator new(size_t size) throw() { return Compilation::current()->arena()->Amalloc(size); } void* operator new(size_t size, Arena* arena) throw() { return arena->Amalloc(size); } void operator delete(void* p) {} // nothing to do }; class InstructionVisitor: public StackObj class StackObj ALLOCATION_SUPER_CLASS_SPEC { private: void* operator new(size_t size) throw(); void* operator new [](size_t size) throw(); #ifdef __IBMCPP__ public: #endif void operator delete(void* p); void operator delete [](void* p); Now you declare new "new()" and "delete()" operators in the LIRGenerator which will actually hide the corresponding operators from the base classes. You also provide no implementation for the new operators in LIRGenerator. So which new/delete operators will be actually used for allocating new LIRGenerator instances? OK, wait. As far as I can see, LIRGenerator is never dynamically allocated, right? In that case it should be a StackObj and you could probably solve the problem with "using" directives (e.g. using StackObj::operator new, ...). Have you tried that? Regards, Volker On Wed, Oct 7, 2015 at 4:55 PM, Mikael Gerdin wrote: > On 2015-10-07 16:17, Doerr, Martin wrote: > >> Hi, >> >> that?s a good question J >> >> I can only remember that there were problems with some old compilers. >> >> Anyway, xlC 12.1 can deal with the private delete operators. >> > > If that's the case, can we also get rid of the workaround in > allocation.hpp? > > Thanks > /Mikael > > >> Here?s the new webrev: >> >> http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.01 >> >> Best regards, >> >> Martin >> >> *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com] >> *Sent:* Mittwoch, 7. Oktober 2015 03:32 >> *To:* Doerr, Martin >> *Cc:* hotspot compiler >> *Subject:* Re: RFR(S): 8138890: C1: Ambiguous operator delete >> >> On Oct 6, 2015, at 3:56 AM, Doerr, Martin > > wrote: >> >> Hi, >> >> xlC on AIX rejects to compile LIRGenerator and >> RangeCheckEliminator::Verification due to ambiguous operator delete >> which gets inherited from multiple base classes. >> >> This change is a prerequisite for our C1 on PPC64 contribution. >> >> Webrev is here: >> >> >> http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.00 >> >> Let me ask my question here: why do you need the delete methods to be >> public on AIX? >> >> >> >> Please review this change. I need a sponsor, please. >> >> Best regards, >> >> Martin >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adinn at redhat.com Wed Oct 7 16:31:02 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 7 Oct 2015 17:31:02 +0100 Subject: RFR: 8139042: AARCH64: Correct regression introduced by 8080293 In-Reply-To: <56152CBF.2090404@oracle.com> References: <5615012F.4090500@redhat.com> <56152CBF.2090404@oracle.com> Message-ID: <561548C6.10002@redhat.com> Thanks, Andrew and Vladimir for the reviews. Since this has had two reviews and is aarch64 only I have exercised my newly granted Committer status to push it to hs-comp! (yes, a whole 1 character got changed! :-) 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) On 07/10/15 15:31, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 10/7/15 7:25 PM, Andrew Dinn wrote: >> Could two reviewers please review this AArch64 only patch. >> >> http://cr.openjdk.java.net/~adinn/8139042/webrev.00/ >> >> The fix for issue JDK-8080293 (AARCH64: Remove unnecessary dmbs from >> generated CAS code) inadvertently disabled one step of the optimization >> process for unsafe volatile object gets. The result is that unsafe >> volatile get is successfully translated to ldar but generation of the >> trailing dmb ishld instruction is not inhibited. >> >> The patch for 8080293 extended predicate unnecessary_acquire to check >> for a MemBarAcquire associated with a CompareAndSwapX node. In doing so >> it changed the logic of a sanity check for MemBarAcquire introdcued as >> part of an unsafe volatile get. The patch modified the code to >> conditionally return true instead of return false. However the condition >> retained the original != where it should have employed ==. >> >> 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 martin.doerr at sap.com Wed Oct 7 16:32:56 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 7 Oct 2015 16:32:56 +0000 Subject: RFR(S): 8138890: C1: Ambiguous operator delete In-Reply-To: References: <7C9B87B351A4BA4AA9EC95BB41811656722607B5@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672260AE1@DEWDFEMB19C.global.corp.sap> <56153267.7060401@oracle.com> Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165672260BFB@DEWDFEMB19C.global.corp.sap> Hi Volker, the C1 classes we are talking about should never get instantiated by operator new. A typical way to establish this is to make the new operators private. I don?t really care if the delete operators are public or private because if the new operator is never used, how can the delete operator get used? It may be more beautiful to declare them as private as well. Only in the case G?tz has showed, some Compilers reject the private delete operators. Best regards, Martin From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Mittwoch, 7. Oktober 2015 17:57 To: Mikael Gerdin Cc: Doerr, Martin; Christian Thalinger; hotspot compiler Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete Hi Martin, we have: class LIRGenerator: public InstructionVisitor, public BlockClosure and: class BlockClosure: public CompilationResourceObj class CompilationResourceObj ALLOCATION_SUPER_CLASS_SPEC { public: void* operator new(size_t size) throw() { return Compilation::current()->arena()->Amalloc(size); } void* operator new(size_t size, Arena* arena) throw() { return arena->Amalloc(size); } void operator delete(void* p) {} // nothing to do }; class InstructionVisitor: public StackObj class StackObj ALLOCATION_SUPER_CLASS_SPEC { private: void* operator new(size_t size) throw(); void* operator new [](size_t size) throw(); #ifdef __IBMCPP__ public: #endif void operator delete(void* p); void operator delete [](void* p); Now you declare new "new()" and "delete()" operators in the LIRGenerator which will actually hide the corresponding operators from the base classes. You also provide no implementation for the new operators in LIRGenerator. So which new/delete operators will be actually used for allocating new LIRGenerator instances? OK, wait. As far as I can see, LIRGenerator is never dynamically allocated, right? In that case it should be a StackObj and you could probably solve the problem with "using" directives (e.g. using StackObj::operator new, ...). Have you tried that? Regards, Volker On Wed, Oct 7, 2015 at 4:55 PM, Mikael Gerdin > wrote: On 2015-10-07 16:17, Doerr, Martin wrote: Hi, that?s a good question J I can only remember that there were problems with some old compilers. Anyway, xlC 12.1 can deal with the private delete operators. If that's the case, can we also get rid of the workaround in allocation.hpp? Thanks /Mikael Here?s the new webrev: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.01 Best regards, Martin *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com] *Sent:* Mittwoch, 7. Oktober 2015 03:32 *To:* Doerr, Martin *Cc:* hotspot compiler *Subject:* Re: RFR(S): 8138890: C1: Ambiguous operator delete On Oct 6, 2015, at 3:56 AM, Doerr, Martin >> wrote: Hi, xlC on AIX rejects to compile LIRGenerator and RangeCheckEliminator::Verification due to ambiguous operator delete which gets inherited from multiple base classes. This change is a prerequisite for our C1 on PPC64 contribution. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.00 Let me ask my question here: why do you need the delete methods to be public on AIX? Please review this change. I need a sponsor, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavel.punegov at oracle.com Wed Oct 7 18:49:04 2015 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Wed, 07 Oct 2015 21:49:04 +0300 Subject: RFR(L): 8066153: JEP-JDK-8046155: Test task: cover existing In-Reply-To: <5614886B.9050508@oracle.com> References: <5609334B.7050200@oracle.com> <5614886B.9050508@oracle.com> Message-ID: <56156920.2020405@oracle.com> Thank you, Vladimir. LogCompilation output processing will signal failure only if we found that the method was printed when it should not be. It won't fail if there are no methods that should be printed at all, or there is a broken output that just wouldn't match regexps. On 07.10.2015 05:50, Vladimir Kozlov wrote: > We have test problems with parsing output of LogCompilation and other > outputs because it could be cut off. I would prefer adding new WB > events API to record interesting events. > Otherwise seems fine. Nils should look on this to make sure all > paths/flags are tested. > > Thanks, > Vladimir > > On 9/28/15 8:32 PM, Pavel Punegov wrote: >> Hi, >> >> please review the following tests fro JEP 165 Compiler Control. >> These tests cover both CompileCommand and new directives (through >> CompileDirectivesFile). >> >> The main idea of tests is to create a one or multiple commands or >> directives for methods in the pool and execute a test VM with a set of >> method states (should method be compiled, inlined, printed, etc.). On >> the end test checks that only correct methods are logged with >> LogCompilation, or printed via PrintAssembly. >> >> Bugs: >> https://bugs.openjdk.java.net/browse/JDK-8066153 >> https://bugs.openjdk.java.net/browse/JDK-8066165 >> >> webrev: http://cr.openjdk.java.net/~ppunegov/8066153/webrev.00/ >> -- Thanks, Pavel Punegov From pavel.punegov at oracle.com Wed Oct 7 19:26:27 2015 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Wed, 07 Oct 2015 22:26:27 +0300 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: <5614F60D.3040602@oracle.com> References: <56018E2B.2000108@oracle.com> <5614F60D.3040602@oracle.com> Message-ID: <561571E3.2010304@oracle.com> Hi Nils, What is a reason for CompilerDirectivesFile option to be diagnostic, while CompileCommand is a product one? I think they both should be product options. In src/share/vm/runtime/globals.hpp 3552 diagnostic(ccstr, CompilerDirectivesFile, NULL, \ On 07.10.2015 13:38, Nils Eliasson wrote: > Hi all, > > Latest webrev including fixes after comments from Chris and Zoltan: > http://cr.openjdk.java.net/~neliasso/8046155/webrev.09/ > > Regards, > //Nils > > > > On 2015-09-22 19:21, Nils Eliasson wrote: > > Hi, > > This is the initial RFR for JEP165: Compiler Control. This > feature > enables runtime manageable, method dependent compiler flags. > > (Immutable for the duration of a compilation.) > > The change > includes: - A parser for the directives format (json like) > including > vmtests (json.cpp/hpp) - A component for construction of > compiler > directives (directivesParser.cpp/hpp) - The directives > including the > option definitions, default values and compilecommand > relations > (compilerDirectives.cpp/hpp) - Diagnostic commands for > working with > the directives - installing, removing, printing - Lots > of small > changes wherever we access flags or legacy compilecommands > in the > compiler > > Notes: The feature is documented in the JEP > > (https://bugs.openjdk.java.net/browse/JDK-8046155). > > Currently only > a small amount of compiler flags are included in the > change. The > flags are a representative selection of different types > targeting > both compilers. All of them existed as CompilerOracle > option > commands. Two commands was not included in the directives due > to > time constraints - CompilerThresholdScaling and UseRTMLocks. Both > > are accessed from runtime (outside any compiler) and requires some > > special handling. (Solved but not implemented.) > > Full backwards > compatibility with CompileCommands is implemented but > can be turned > off with flag -XX:CompileCommandCompatibilty. Also meta > handling the > compatibility flag by supporting it in the directives > (test > feature). > > The change contain some rough edges that will polished > over the > coming days. > > JEP: > https://bugs.openjdk.java.net/browse/JDK-8046155 Hotspot webrev: > > http://cr.openjdk.java.net/~neliasso/8046155/webrev.01/ JDK webrev: > > http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.01/ > > Please > review! > > Best regards, Nils Eliasson > > -- Thanks, Pavel Punegov -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Wed Oct 7 19:27:55 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 7 Oct 2015 21:27:55 +0200 Subject: RFR(S): 8138890: C1: Ambiguous operator delete In-Reply-To: <7C9B87B351A4BA4AA9EC95BB4181165672260BFB@DEWDFEMB19C.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB41811656722607B5@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672260AE1@DEWDFEMB19C.global.corp.sap> <56153267.7060401@oracle.com> <7C9B87B351A4BA4AA9EC95BB4181165672260BFB@DEWDFEMB19C.global.corp.sap> Message-ID: Hi Martin, as the new/delete operators in StackObj are private (I missed that before) they shouldn't be visible in LIRGenerator. So this is probably yet another xlC bug :( On the other hand the new/delete operators in CompilationResourceObject are public and are inherited by LIRGenerator. So if we only want to generate LIRGenerator instances on the stack, your change is good, because it ensures this. And in that case we surely don't need an implementation. So thumbs up from me! Volker On Wednesday, October 7, 2015, Doerr, Martin wrote: > Hi Volker, > > > > the C1 classes we are talking about should never get instantiated by > operator new. > > A typical way to establish this is to make the new operators private. > > > > I don?t really care if the delete operators are public or private because > if the new operator is never used, how can the delete operator get used? > > It may be more beautiful to declare them as private as well. Only in the > case G?tz has showed, some Compilers reject the private delete operators. > > > > Best regards, > > Martin > > > > > > *From:* Volker Simonis [mailto:volker.simonis at gmail.com > ] > *Sent:* Mittwoch, 7. Oktober 2015 17:57 > *To:* Mikael Gerdin > *Cc:* Doerr, Martin; Christian Thalinger; hotspot compiler > *Subject:* Re: RFR(S): 8138890: C1: Ambiguous operator delete > > > > Hi Martin, > > we have: > class LIRGenerator: public InstructionVisitor, public BlockClosure > > and: > > class BlockClosure: public CompilationResourceObj > > class CompilationResourceObj ALLOCATION_SUPER_CLASS_SPEC { > public: > void* operator new(size_t size) throw() { return > Compilation::current()->arena()->Amalloc(size); } > void* operator new(size_t size, Arena* arena) throw() { > return arena->Amalloc(size); > } > void operator delete(void* p) {} // nothing to do > }; > > class InstructionVisitor: public StackObj > > class StackObj ALLOCATION_SUPER_CLASS_SPEC { > private: > void* operator new(size_t size) throw(); > void* operator new [](size_t size) throw(); > #ifdef __IBMCPP__ > public: > #endif > void operator delete(void* p); > void operator delete [](void* p); > > Now you declare new "new()" and "delete()" operators in the LIRGenerator > which will actually hide the corresponding operators from the base classes. > You also provide no implementation for the new operators in LIRGenerator. > So which new/delete operators will be actually used for allocating new > LIRGenerator instances? > > OK, wait. As far as I can see, LIRGenerator is never dynamically > allocated, right? In that case it should be a StackObj and you could > probably solve the problem with "using" directives (e.g. using > StackObj::operator new, ...). Have you tried that? > > Regards, > > Volker > > > > > > On Wed, Oct 7, 2015 at 4:55 PM, Mikael Gerdin > wrote: > > On 2015-10-07 16:17, Doerr, Martin wrote: > > Hi, > > that?s a good question J > > I can only remember that there were problems with some old compilers. > > Anyway, xlC 12.1 can deal with the private delete operators. > > > If that's the case, can we also get rid of the workaround in > allocation.hpp? > > Thanks > /Mikael > > > Here?s the new webrev: > > http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.01 > > Best regards, > > Martin > > *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com > ] > *Sent:* Mittwoch, 7. Oktober 2015 03:32 > *To:* Doerr, Martin > *Cc:* hotspot compiler > *Subject:* Re: RFR(S): 8138890: C1: Ambiguous operator delete > > On Oct 6, 2015, at 3:56 AM, Doerr, Martin > >> wrote: > > Hi, > > xlC on AIX rejects to compile LIRGenerator and > RangeCheckEliminator::Verification due to ambiguous operator delete > which gets inherited from multiple base classes. > > This change is a prerequisite for our C1 on PPC64 contribution. > > Webrev is here: > > > http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.00 > > Let me ask my question here: why do you need the delete methods to be > public on AIX? > > > > Please review this change. I need a sponsor, please. > > Best regards, > > Martin > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Wed Oct 7 21:01:45 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 7 Oct 2015 21:01:45 +0000 Subject: RFR(M) 8138892: C1: Improve counter overflow checking Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165672260C97@DEWDFEMB19C.global.corp.sap> Hi, C1 currently loads the Method pointer in the fast path even though it is only required in the overflow case. In addition, stupid code gets generated when the frequency is set to 0 which occurs with -Xcomp. The following webrev optimizes that: http://cr.openjdk.java.net/~mdoerr/8138892_c1_counter_overflow/webrev.02 It's not tested on aarch64. Please review this change. I need a sponsor, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Oct 8 01:32:57 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 8 Oct 2015 09:32:57 +0800 Subject: RFR(L): 8066153: JEP-JDK-8046155: Test task: cover existing In-Reply-To: <56156920.2020405@oracle.com> References: <5609334B.7050200@oracle.com> <5614886B.9050508@oracle.com> <56156920.2020405@oracle.com> Message-ID: <5615C7C9.7030604@oracle.com> Got it. Okay then. Thanks, Vladimir On 10/8/15 2:49 AM, Pavel Punegov wrote: > Thank you, Vladimir. > > LogCompilation output processing will signal failure only if we found > that the method was printed when it should not be. > It won't fail if there are no methods that should be printed at all, or > there is a broken output that just wouldn't match regexps. > > On 07.10.2015 05:50, Vladimir Kozlov wrote: >> We have test problems with parsing output of LogCompilation and other >> outputs because it could be cut off. I would prefer adding new WB >> events API to record interesting events. >> Otherwise seems fine. Nils should look on this to make sure all >> paths/flags are tested. >> >> Thanks, >> Vladimir >> >> On 9/28/15 8:32 PM, Pavel Punegov wrote: >>> Hi, >>> >>> please review the following tests fro JEP 165 Compiler Control. >>> These tests cover both CompileCommand and new directives (through >>> CompileDirectivesFile). >>> >>> The main idea of tests is to create a one or multiple commands or >>> directives for methods in the pool and execute a test VM with a set of >>> method states (should method be compiled, inlined, printed, etc.). On >>> the end test checks that only correct methods are logged with >>> LogCompilation, or printed via PrintAssembly. >>> >>> Bugs: >>> https://bugs.openjdk.java.net/browse/JDK-8066153 >>> https://bugs.openjdk.java.net/browse/JDK-8066165 >>> >>> webrev: http://cr.openjdk.java.net/~ppunegov/8066153/webrev.00/ >>> > From igor.veresov at oracle.com Thu Oct 8 01:39:46 2015 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 7 Oct 2015 18:39:46 -0700 Subject: RFR(M) 8138892: C1: Improve counter overflow checking In-Reply-To: <7C9B87B351A4BA4AA9EC95BB4181165672260C97@DEWDFEMB19C.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB4181165672260C97@DEWDFEMB19C.global.corp.sap> Message-ID: That look good to me. igor > On Oct 7, 2015, at 2:01 PM, Doerr, Martin wrote: > > Hi, > > C1 currently loads the Method pointer in the fast path even though it is only required in the overflow case. In addition, stupid code gets generated when the frequency is set to 0 which occurs with -Xcomp. > > The following webrev optimizes that: > http://cr.openjdk.java.net/~mdoerr/8138892_c1_counter_overflow/webrev.02 > > It?s not tested on aarch64. > > Please review this change. I need a sponsor, please. > > Best regards, > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Thu Oct 8 07:44:42 2015 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 8 Oct 2015 00:44:42 -0700 Subject: RFR(XXS): 8139094 Tier1 test java/util/zip/TestCRC32C.java fails due to fixes for JDK-8134553 Message-ID: <4102E82E-486F-4F1E-B7CB-E42558FC483B@oracle.com> Tomasz Wojtowicz fixed the problem. Here?s the webrev: http://cr.openjdk.java.net/~iveresov/8139094/webrev.00/ I?ve reviewed and tested the fix. igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Thu Oct 8 08:19:19 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 8 Oct 2015 08:19:19 +0000 Subject: RFR(XS) 8138891: C1: Missing release memory barrier in C1's CMS post-barrier In-Reply-To: <7C9B87B351A4BA4AA9EC95BB4181165672260AAB@DEWDFEMB19C.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB41811656722607F8@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672260A57@DEWDFEMB19C.global.corp.sap> <56151DE6.8090605@redhat.com> <7C9B87B351A4BA4AA9EC95BB4181165672260AAB@DEWDFEMB19C.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC41E80E81@DEWDFEMB12A.global.corp.sap> Hi Martin, the change will show up in hs-comp in time. Yes, just close the bug as duplicate. Best regards, Goetz. -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Doerr, Martin Sent: Mittwoch, 7. Oktober 2015 15:47 To: Andrew Haley; Igor Veresov Cc: hotspot compiler Subject: RE: RFR(XS) 8138891: C1: Missing release memory barrier in C1's CMS post-barrier Thanks for pointing me to 8135018: AARCH64: Missing memory barriers for CMS collector It is already fixed in hs-rt. Will it get merged into hs-comp soon? Can I close my bug as duplicate? Best regards, Martin -----Original Message----- From: Andrew Haley [mailto:aph at redhat.com] Sent: Mittwoch, 7. Oktober 2015 15:28 To: Doerr, Martin; Igor Veresov Cc: hotspot compiler Subject: Re: RFR(XS) 8138891: C1: Missing release memory barrier in C1's CMS post-barrier On 10/07/2015 02:15 PM, Doerr, Martin wrote: > Can any aarch64 expert comment on this? Are there known CMS problems? This is already fixed. http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/raw-rev/91c907c47794 Andrew. From vladimir.kozlov at oracle.com Thu Oct 8 09:12:24 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 8 Oct 2015 17:12:24 +0800 Subject: RFR(XXS): 8139094 Tier1 test java/util/zip/TestCRC32C.java fails due to fixes for JDK-8134553 In-Reply-To: <4102E82E-486F-4F1E-B7CB-E42558FC483B@oracle.com> References: <4102E82E-486F-4F1E-B7CB-E42558FC483B@oracle.com> Message-ID: <56163378.5010205@oracle.com> Looks good. Thanks, Vladimir On 10/8/15 3:44 PM, Igor Veresov wrote: > Tomasz Wojtowicz fixed the problem. > Here?s the webrev: http://cr.openjdk.java.net/~iveresov/8139094/webrev.00/ > > I?ve reviewed and tested the fix. > > igor From claes.redestad at oracle.com Thu Oct 8 10:37:40 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 08 Oct 2015 12:37:40 +0200 Subject: RFR(S): 8134607: Remove per-compiler performance counters Message-ID: <56164774.2080504@oracle.com> Hello hotspot-compiler.dev, anyone care to review this patch to remove per-compiler thread performance counters? Bug: https://bugs.openjdk.java.net/browse/JDK-8134607 HotSpot webrev: http://cr.openjdk.java.net/~redestad/8134607/hotspot.01 JDK webrev: http://cr.openjdk.java.net/~redestad/8134607/jdk.01 CCC approved, no new test failures running JPRT against hs-comp. /Claes From roland.westrelin at oracle.com Thu Oct 8 11:51:11 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 8 Oct 2015 13:51:11 +0200 Subject: RFR: Elide more final field's write memory barrier with escape analysis result In-Reply-To: References: <5612A2C6.5080108@redhat.com> Message-ID: > http://cr.openjdk.java.net/~hshi/8138956/webrev/ The code change looks good to me. The comments have a few typos and are a bit confusing. I'll tweak them before I push it. PPC folks, in case you missed it, parse1.cpp has a ppc related fix. Roland. From zoltan.majo at oracle.com Thu Oct 8 12:07:08 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 8 Oct 2015 14:07:08 +0200 Subject: [9] RFR(M): 8078554: Compiler: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <5615204C.8080202@oracle.com> References: <560BB4F6.3050703@oracle.com> <4502D8F6-B256-4222-B1D3-92ED5C100B6E@oracle.com> <5613B44F.4090007@oracle.com> <5615204C.8080202@oracle.com> Message-ID: <56165C6C.70705@oracle.com> Hi Tobias, thank you for the feedback! On 10/07/2015 03:38 PM, Tobias Hartmann wrote: > Hi Zoltan, > > I had a look at your changes and just spotted some minor things: > > globals_sparc.hpp: > - I think there is a '\' missing in line 119 thank you for spotting that! > > globals_x86.hpp: > - Isn't this also a compiler flag we should add range checks for? > 136 product(uintx, RTMRetryCount, 5, JEP 245 considers it as a runtime flag and JDK-8078556 "Runtime: implement ranges..." [1] will take care of it. But you are right, that flag could be also considered a compiler flag. > > commandLineFlagConstraintsCompiler.cpp: > - I think there is a "rule" that the include statements should be in alphabetical order Yes, I think there is such a rule (or convention). I diverged from the rule because the include of code/relocInfo.hpp depends on 'os', 'vm_page_size', and 'Metadata'. Therefore, "oops/metadata.hpp" and "runtime/os.hpp" must be included before relocInfo.hpp (otherwise the Solaris compiler complains). The remaining includes are ordered alphabetically. > - the indentation is wrong here: > 179 return Flag::VIOLATES_CONSTRAINT; I updated the indentation. Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8078554/webrev.02/ I re-tested the updated webrev with JPRT (testset hotspot), all tests pass. Thank you and best regards, Zoltan [1] https://bugs.openjdk.java.net/browse/JDK-8078556 > > Best, > Tobias > > On 06.10.2015 13:45, Zolt?n Maj? wrote: >> Hi Roland, >> >> >> thank you for the feedback! >> >> On 10/02/2015 03:55 PM, Roland Westrelin wrote: >>> Hi Zoltan, >>> >>>> Webrev:http://cr.openjdk.java.net/~zmajo/8078554/ >>> c2_globals.hpp >>> >>> That one is not correct: >>> 461 product(intx, MaxNodeLimit, 80000, \ >>> 462 "Maximum number of nodes") \ >>> 463 range(1000, 80000) \ >>> >>> I think the upper bound should be max_juint >> You are right that the limit of 80'000 is too conservative. But max_j*u*int as an upper bound would cause an overflow when parsing the flag's value, because on 32-bit machines intx is a 32-bit signed integer. >> >> Using max_jint instead of max_j*u*int as an upper bound would not cause an overflow at parse time. However, in Parse::do_call() the maximum node limit is increased by 3 times for jsr292 users >> >> C->set_max_node_limit(3*MaxNodeLimit); >> >> If MaxNodeLimit == max_jint, this expression will overflow, I think. >> >> So I set the limit to (max_jint / 3) in the updated webrev. >> >> If we would set MaxNodeLimit to max_j*u*int / 3 (instead of max_jint / 3), the expression 3 * MaxNodeLimit would overflow as well. Changing the type of the flag from intx to uintx could let use use max_j*u*int / 3 as an upper bound, but that is most likely not worth the effort. >> >>> 699 product(intx, LiveNodeCountInliningCutoff, 40000, \ >>> 700 "max number of live nodes in a method") \ >>> 701 range(0, max_juint / 8) \ >>> >>> Out of curiosity why max_juint / 8 (not that it makes much of a difference)? >> In Compile::inline_incrementally, the 80% of LiveNodeCountInliningCutoff is computed the following way: >> >> if (low_live_nodes < (uint)LiveNodeCountInliningCutoff * 8 / 10) { >> >> If LiveNodeCountInliningCutoff == max_juint, we'd have an overflow because of the multiplication by 8. >> >>> arguments.cpp >>> >>> 1099 Tier3InvokeNotifyFreqLog = 0; >>> 1100 Tier4InvocationThreshold = 0; >>> >>> Why that change? >> I proposed that change because I misread the code. I reverted that change and also changed the range of all Tier*FreqLog flags from range(1, 30) to range(0, 30). >> >>> globals.hp >>> >>> 2870 product_pd(uintx, TypeProfileLevel, \ >>> 2871 "=XYZ, with Z: Type profiling of arguments at call; " \ >>> 2872 "Y: Type profiling of return value at call; " \ >>> 2873 "X: Type profiling of parameters to methods; " \ >>> 2874 "X, Y and Z in 0=off ; 1=jsr292 only; 2=all methods") \ >>> 2875 range(0, 222) >>> >>> Legal values are 0, 1, 2, 10, 11, 12, 100, 101, 102, 110, 111, 112 etc. >>> >>> 70 is not for instance. So range(0, 222) is incorrect. >> I agree. I removed the range check and implemented a constraint function instead (TypeProfileLevelConstraintFunc). >> >>> 2877 product(intx, TypeProfileArgsLimit, 2, \ >>> 2878 "max number of call arguments to consider for type profiling") \ >>> 2879 range(0, 16) \ >>> >>> 2880 \ >>> 2881 product(intx, TypeProfileParmsLimit, 2, \ >>> 2882 "max number of incoming parameters to consider for type profiling"\ >>> 2883 ", -1 for all") \ >>> 2884 range(-1, 64) >>> >>> Why 16 and 64? >> These are the largest values that work on all platforms we support. >> >> Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8078554/webrev.01/ >> >> I repeated the testing with JPRT. I also executed the currently disabled TestOptionsWithRanges.java test on all platforms we support. All tests pass. >> >> Thank you and best regards, >> >> >> Zoltan >> >>> Roland. From nils.eliasson at oracle.com Thu Oct 8 12:10:18 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 8 Oct 2015 14:10:18 +0200 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: <56151DCE.90407@oracle.com> References: <56018E2B.2000108@oracle.com> <5614F60D.3040602@oracle.com> <56151DCE.90407@oracle.com> Message-ID: <56165D2A.7010407@oracle.com> Hi Zoltan, Thanks for the repro. Found a bug where the base directives got corrupted. Added test cases to the TestCompilerDirectivesCompatibility* which will cover that. New webrev: http://cr.openjdk.java.net/~neliasso/8046155/webrev.10/ Best regards, Nils On 2015-10-07 15:27, Zolt?n Maj? wrote: > Hi Nils, > > > On 10/07/2015 12:38 PM, Nils Eliasson wrote: >> Hi all, >> >> Latest webrev including fixes after comments from Chris and Zoltan: >> http://cr.openjdk.java.net/~neliasso/8046155/webrev.09/ > > thank you for the updated version. It seems, however, that the > DisableIntrinsic flag does not work correctly on the per-method level. > > If I execute the MathTest program I've sent out before with the > command-line option > > -XX:CompileCommand=option,MathTest::test1,ccstr,DisableIntrinsic,_dsin > > with jdk9-b83, I get the expected behavior (Math.sin is inlined into > test2 but not into test1): > > 128 1 b 3 MathTest::test1 (7 bytes) > @ 3 java.lang.Math::sin (5 bytes) > @ 1 java/lang/StrictMath::sin (not > loaded) not inlineable > 130 2 n 0 java.lang.StrictMath::sin (native) (static) > 132 3 b 3 MathTest::test2 (7 bytes) > @ 3 java.lang.Math::sin (5 bytes) > intrinsic > > > If I execute the test case with a locally-built jdk patched with > webrev.09, I get an erronous behavior (Math.sin is not inlined into > test2 although it should be): > > 133 1 b 3 MathTest::test1 (7 bytes) > @ 3 java.lang.Math::sin (5 bytes) > @ 1 java/lang/StrictMath::sin (not > loaded) not inlineable > 136 2 n 0 java.lang.StrictMath::sin (native) (static) > 138 3 b 3 MathTest::test2 (7 bytes) > @ 3 java.lang.Math::sin (5 bytes) > @ 1 java.lang.StrictMath::sin (0 > bytes) native method > > Could you please check why that happens? > > Thank you and best regards, > > > Zoltan > > > >> >> Regards, >> //Nils >> >> >> >> On 2015-09-22 19:21, Nils Eliasson wrote: >> > Hi, > > This is the initial RFR for JEP165: Compiler Control. This >> feature > enables runtime manageable, method dependent compiler >> flags. > (Immutable for the duration of a compilation.) > > The >> change includes: - A parser for the directives format (json like) > >> including vmtests (json.cpp/hpp) - A component for construction of > >> compiler directives (directivesParser.cpp/hpp) - The directives > >> including the option definitions, default values and compilecommand > >> relations (compilerDirectives.cpp/hpp) - Diagnostic commands for > >> working with the directives - installing, removing, printing - Lots > >> of small changes wherever we access flags or legacy compilecommands > >> in the compiler > > Notes: The feature is documented in the JEP > >> (https://bugs.openjdk.java.net/browse/JDK-8046155). > > Currently >> only a small amount of compiler flags are included in the > change. >> The flags are a representative selection of different types > >> targeting both compilers. All of them existed as CompilerOracle > >> option commands. Two commands was not included in the directives due >> > to time constraints - CompilerThresholdScaling and UseRTMLocks. >> Both > are accessed from runtime (outside any compiler) and requires >> some > special handling. (Solved but not implemented.) > > Full >> backwards compatibility with CompileCommands is implemented but > can >> be turned off with flag -XX:CompileCommandCompatibilty. Also meta > >> handling the compatibility flag by supporting it in the directives > >> (test feature). > > The change contain some rough edges that will >> polished over the > coming days. > > JEP: >> https://bugs.openjdk.java.net/browse/JDK-8046155 Hotspot webrev: > >> http://cr.openjdk.java.net/~neliasso/8046155/webrev.01/ JDK webrev: > >> http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.01/ > > >> Please review! > > Best regards, Nils Eliasson >> >> > From zoltan.majo at oracle.com Thu Oct 8 12:36:58 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 8 Oct 2015 14:36:58 +0200 Subject: [9] RFR(XS): 8081288: erronous free in RegClass::~RegClass() Message-ID: <5616636A.5010909@oracle.com> Hi, please review the patch for JDK-8081288. Bug: https://bugs.openjdk.java.net/browse/JDK-8081288 Problem: JDK-8075798 modified the destructor of RegClass to free the _classid field of that class: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ac291bc3ece2#l5.50 This is bad software engineering practice because the _classid field points to a memory region *not* allocated by the class itself (allocation happens in ADLParser::get_ident_common); freeing the memory region in RegClass can also lead to errors if ADLParser is changed in the future to release memory it has allocated. The problem was spotted by Krystal Mok. Solution: Change code to not free _classid. Webrev: http://cr.openjdk.java.net/~zmajo/8081288/webrev.00/ Testing: JPRT. Thank you and best regards, Zoltan From zoltan.majo at oracle.com Thu Oct 8 13:33:16 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 8 Oct 2015 15:33:16 +0200 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: <56165D2A.7010407@oracle.com> References: <56018E2B.2000108@oracle.com> <5614F60D.3040602@oracle.com> <56151DCE.90407@oracle.com> <56165D2A.7010407@oracle.com> Message-ID: <5616709C.809@oracle.com> Hi Nils, On 10/08/2015 02:10 PM, Nils Eliasson wrote: > Hi Zoltan, > > Thanks for the repro. Found a bug where the base directives got > corrupted. Added test cases to the > TestCompilerDirectivesCompatibility* which will cover that. Thank you for fixing the problem with the DisableIntrinsic flag (the flag works now as expected). I've spotted two other small problems: 1) src/share/vm/compiler/abstractCompiler.hpp 72 // - the intrinsic is enabled (by using the appropriate command-line flag 73 // , the command-line compile ommand, or a compiler directive) The comma on line 73 should be at the end of line 72. 2) In your JDK changes (I've looked at webrev_jdk.01, as I think there is no newer version): You have not declared the sun.hotspot.WhiteBox::shouldPrintAssembly(Ljava/lang/reflect/Executable;)Z method. As a result the VM is complaining if the WhiteBox API is enabled: Warning: 'NoSuchMethodError' on register of sun.hotspot.WhiteBox::shouldPrintAssembly(Ljava/lang/reflect/Executable;)Z Thank you and best regards, Zoltan > > New webrev: > http://cr.openjdk.java.net/~neliasso/8046155/webrev.10/ > > Best regards, > Nils > > > On 2015-10-07 15:27, Zolt?n Maj? wrote: >> Hi Nils, >> >> >> On 10/07/2015 12:38 PM, Nils Eliasson wrote: >>> Hi all, >>> >>> Latest webrev including fixes after comments from Chris and Zoltan: >>> http://cr.openjdk.java.net/~neliasso/8046155/webrev.09/ >> >> thank you for the updated version. It seems, however, that the >> DisableIntrinsic flag does not work correctly on the per-method level. >> >> If I execute the MathTest program I've sent out before with the >> command-line option >> >> -XX:CompileCommand=option,MathTest::test1,ccstr,DisableIntrinsic,_dsin >> >> with jdk9-b83, I get the expected behavior (Math.sin is inlined into >> test2 but not into test1): >> >> 128 1 b 3 MathTest::test1 (7 bytes) >> @ 3 java.lang.Math::sin (5 bytes) >> @ 1 java/lang/StrictMath::sin (not >> loaded) not inlineable >> 130 2 n 0 java.lang.StrictMath::sin (native) (static) >> 132 3 b 3 MathTest::test2 (7 bytes) >> @ 3 java.lang.Math::sin (5 bytes) >> intrinsic >> >> >> If I execute the test case with a locally-built jdk patched with >> webrev.09, I get an erronous behavior (Math.sin is not inlined into >> test2 although it should be): >> >> 133 1 b 3 MathTest::test1 (7 bytes) >> @ 3 java.lang.Math::sin (5 bytes) >> @ 1 java/lang/StrictMath::sin (not >> loaded) not inlineable >> 136 2 n 0 java.lang.StrictMath::sin (native) (static) >> 138 3 b 3 MathTest::test2 (7 bytes) >> @ 3 java.lang.Math::sin (5 bytes) >> @ 1 java.lang.StrictMath::sin (0 >> bytes) native method >> >> Could you please check why that happens? >> >> Thank you and best regards, >> >> >> Zoltan >> >> >> >>> >>> Regards, >>> //Nils >>> >>> >>> >>> On 2015-09-22 19:21, Nils Eliasson wrote: >>> > Hi, > > This is the initial RFR for JEP165: Compiler Control. This >>> feature > enables runtime manageable, method dependent compiler >>> flags. > (Immutable for the duration of a compilation.) > > The >>> change includes: - A parser for the directives format (json like) > >>> including vmtests (json.cpp/hpp) - A component for construction of > >>> compiler directives (directivesParser.cpp/hpp) - The directives > >>> including the option definitions, default values and compilecommand >>> > relations (compilerDirectives.cpp/hpp) - Diagnostic commands for > >>> working with the directives - installing, removing, printing - Lots >>> > of small changes wherever we access flags or legacy >>> compilecommands > in the compiler > > Notes: The feature is >>> documented in the JEP > >>> (https://bugs.openjdk.java.net/browse/JDK-8046155). > > Currently >>> only a small amount of compiler flags are included in the > change. >>> The flags are a representative selection of different types > >>> targeting both compilers. All of them existed as CompilerOracle > >>> option commands. Two commands was not included in the directives due >>> > to time constraints - CompilerThresholdScaling and UseRTMLocks. >>> Both > are accessed from runtime (outside any compiler) and requires >>> some > special handling. (Solved but not implemented.) > > Full >>> backwards compatibility with CompileCommands is implemented but > >>> can be turned off with flag -XX:CompileCommandCompatibilty. Also >>> meta > handling the compatibility flag by supporting it in the >>> directives > (test feature). > > The change contain some rough edges >>> that will polished over the > coming days. > > JEP: >>> https://bugs.openjdk.java.net/browse/JDK-8046155 Hotspot webrev: > >>> http://cr.openjdk.java.net/~neliasso/8046155/webrev.01/ JDK webrev: >>> > http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.01/ > > >>> Please review! > > Best regards, Nils Eliasson >>> >>> >> > From vladimir.kozlov at oracle.com Thu Oct 8 13:57:35 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 8 Oct 2015 21:57:35 +0800 Subject: [9] RFR(XS): 8081288: erronous free in RegClass::~RegClass() In-Reply-To: <5616636A.5010909@oracle.com> References: <5616636A.5010909@oracle.com> Message-ID: <5616764F.1070403@oracle.com> Looks good. Thanks, Vladimir On 10/8/15 8:36 PM, Zolt?n Maj? wrote: > Hi, > > > please review the patch for JDK-8081288. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8081288 > > > Problem: JDK-8075798 modified the destructor of RegClass to free the > _classid field of that class: > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ac291bc3ece2#l5.50 > > This is bad software engineering practice because the _classid field > points to a memory region *not* allocated by the class itself > (allocation happens in ADLParser::get_ident_common); freeing the memory > region in RegClass can also lead to errors if ADLParser is changed in > the future to release memory it has allocated. > > The problem was spotted by Krystal Mok. > > > Solution: Change code to not free _classid. > > Webrev: http://cr.openjdk.java.net/~zmajo/8081288/webrev.00/ > > Testing: JPRT. > > Thank you and best regards, > > > Zoltan > From tobias.hartmann at oracle.com Thu Oct 8 14:10:59 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 08 Oct 2015 16:10:59 +0200 Subject: [9] RFR(M): 8078554: Compiler: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <56165C6C.70705@oracle.com> References: <560BB4F6.3050703@oracle.com> <4502D8F6-B256-4222-B1D3-92ED5C100B6E@oracle.com> <5613B44F.4090007@oracle.com> <5615204C.8080202@oracle.com> <56165C6C.70705@oracle.com> Message-ID: <56167973.9020002@oracle.com> Hi Zolt?n, On 08.10.2015 14:07, Zolt?n Maj? wrote: > Hi Tobias, > > > thank you for the feedback! > > On 10/07/2015 03:38 PM, Tobias Hartmann wrote: >> Hi Zoltan, >> >> I had a look at your changes and just spotted some minor things: >> >> globals_sparc.hpp: >> - I think there is a '\' missing in line 119 > > thank you for spotting that! > >> >> globals_x86.hpp: >> - Isn't this also a compiler flag we should add range checks for? >> 136 product(uintx, RTMRetryCount, 5, > > JEP 245 considers it as a runtime flag and JDK-8078556 "Runtime: implement ranges..." [1] will take care of it. But you are right, that flag could be also considered a compiler flag. Okay, thanks for pointing that out. >> >> commandLineFlagConstraintsCompiler.cpp: >> - I think there is a "rule" that the include statements should be in alphabetical order > > Yes, I think there is such a rule (or convention). I diverged from the rule because the include of code/relocInfo.hpp depends on 'os', 'vm_page_size', and 'Metadata'. Therefore, "oops/metadata.hpp" and "runtime/os.hpp" must be included before relocInfo.hpp (otherwise the Solaris compiler complains). The remaining includes are ordered alphabetically. Okay, makes sense. >> - the indentation is wrong here: >> 179 return Flag::VIOLATES_CONSTRAINT; > > I updated the indentation. > > Here is the updated webrev: > http://cr.openjdk.java.net/~zmajo/8078554/webrev.02/ > > I re-tested the updated webrev with JPRT (testset hotspot), all tests pass. Looks good to me (not a Reviewer). Best, Tobias > > Thank you and best regards, > > > Zoltan > > [1] https://bugs.openjdk.java.net/browse/JDK-8078556 >> >> Best, >> Tobias > > >> >> On 06.10.2015 13:45, Zolt?n Maj? wrote: >>> Hi Roland, >>> >>> >>> thank you for the feedback! >>> >>> On 10/02/2015 03:55 PM, Roland Westrelin wrote: >>>> Hi Zoltan, >>>> >>>>> Webrev:http://cr.openjdk.java.net/~zmajo/8078554/ >>>> c2_globals.hpp >>>> >>>> That one is not correct: >>>> 461 product(intx, MaxNodeLimit, 80000, \ >>>> 462 "Maximum number of nodes") \ >>>> 463 range(1000, 80000) \ >>>> >>>> I think the upper bound should be max_juint >>> You are right that the limit of 80'000 is too conservative. But max_j*u*int as an upper bound would cause an overflow when parsing the flag's value, because on 32-bit machines intx is a 32-bit signed integer. >>> >>> Using max_jint instead of max_j*u*int as an upper bound would not cause an overflow at parse time. However, in Parse::do_call() the maximum node limit is increased by 3 times for jsr292 users >>> >>> C->set_max_node_limit(3*MaxNodeLimit); >>> >>> If MaxNodeLimit == max_jint, this expression will overflow, I think. >>> >>> So I set the limit to (max_jint / 3) in the updated webrev. >>> >>> If we would set MaxNodeLimit to max_j*u*int / 3 (instead of max_jint / 3), the expression 3 * MaxNodeLimit would overflow as well. Changing the type of the flag from intx to uintx could let use use max_j*u*int / 3 as an upper bound, but that is most likely not worth the effort. >>> >>>> 699 product(intx, LiveNodeCountInliningCutoff, 40000, \ >>>> 700 "max number of live nodes in a method") \ >>>> 701 range(0, max_juint / 8) \ >>>> >>>> Out of curiosity why max_juint / 8 (not that it makes much of a difference)? >>> In Compile::inline_incrementally, the 80% of LiveNodeCountInliningCutoff is computed the following way: >>> >>> if (low_live_nodes < (uint)LiveNodeCountInliningCutoff * 8 / 10) { >>> >>> If LiveNodeCountInliningCutoff == max_juint, we'd have an overflow because of the multiplication by 8. >>> >>>> arguments.cpp >>>> >>>> 1099 Tier3InvokeNotifyFreqLog = 0; >>>> 1100 Tier4InvocationThreshold = 0; >>>> >>>> Why that change? >>> I proposed that change because I misread the code. I reverted that change and also changed the range of all Tier*FreqLog flags from range(1, 30) to range(0, 30). >>> >>>> globals.hp >>>> >>>> 2870 product_pd(uintx, TypeProfileLevel, \ >>>> 2871 "=XYZ, with Z: Type profiling of arguments at call; " \ >>>> 2872 "Y: Type profiling of return value at call; " \ >>>> 2873 "X: Type profiling of parameters to methods; " \ >>>> 2874 "X, Y and Z in 0=off ; 1=jsr292 only; 2=all methods") \ >>>> 2875 range(0, 222) >>>> >>>> Legal values are 0, 1, 2, 10, 11, 12, 100, 101, 102, 110, 111, 112 etc. >>>> >>>> 70 is not for instance. So range(0, 222) is incorrect. >>> I agree. I removed the range check and implemented a constraint function instead (TypeProfileLevelConstraintFunc). >>> >>>> 2877 product(intx, TypeProfileArgsLimit, 2, \ >>>> 2878 "max number of call arguments to consider for type profiling") \ >>>> 2879 range(0, 16) \ >>>> >>>> 2880 \ >>>> 2881 product(intx, TypeProfileParmsLimit, 2, \ >>>> 2882 "max number of incoming parameters to consider for type profiling"\ >>>> 2883 ", -1 for all") \ >>>> 2884 range(-1, 64) >>>> >>>> Why 16 and 64? >>> These are the largest values that work on all platforms we support. >>> >>> Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8078554/webrev.01/ >>> >>> I repeated the testing with JPRT. I also executed the currently disabled TestOptionsWithRanges.java test on all platforms we support. All tests pass. >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> >>>> Roland. > From edward.nevill at gmail.com Thu Oct 8 14:23:45 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 08 Oct 2015 15:23:45 +0100 Subject: RFR: 8139043: aarch64: add support for adler32 intrinsic Message-ID: <1444314225.15616.12.camel@mylittlepony.linaroharston> Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8139043/webrev/ Jira Issue: https://bugs.openjdk.java.net/browse/JDK-8139043 This webrev adds support for adler32 intrinsic on aarch64 in the same way that support for adler32 was added for Sparc recently (see https://bugs.openjdk.java.net/browse/JDK-8132081) Testing using TestAdler32.java from jtreg test suite shows between 60% and 155% improvement depending on the size of buffer. Tested with jtreg hotspot. Results the same before and after patch (Test results: passed: 896; failed: 6; error: 10) Thanks for your help, Ed From zoltan.majo at oracle.com Thu Oct 8 15:52:39 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 8 Oct 2015 17:52:39 +0200 Subject: [9] RFR(M): 8078554: Compiler: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <56167973.9020002@oracle.com> References: <560BB4F6.3050703@oracle.com> <4502D8F6-B256-4222-B1D3-92ED5C100B6E@oracle.com> <5613B44F.4090007@oracle.com> <5615204C.8080202@oracle.com> <56165C6C.70705@oracle.com> <56167973.9020002@oracle.com> Message-ID: <56169147.80901@oracle.com> Thank you, Tobias, for the review! Best regards, Zolt?n On 10/08/2015 04:10 PM, Tobias Hartmann wrote: > Hi Zolt?n, > > On 08.10.2015 14:07, Zolt?n Maj? wrote: >> Hi Tobias, >> >> >> thank you for the feedback! >> >> On 10/07/2015 03:38 PM, Tobias Hartmann wrote: >>> Hi Zoltan, >>> >>> I had a look at your changes and just spotted some minor things: >>> >>> globals_sparc.hpp: >>> - I think there is a '\' missing in line 119 >> thank you for spotting that! >> >>> globals_x86.hpp: >>> - Isn't this also a compiler flag we should add range checks for? >>> 136 product(uintx, RTMRetryCount, 5, >> JEP 245 considers it as a runtime flag and JDK-8078556 "Runtime: implement ranges..." [1] will take care of it. But you are right, that flag could be also considered a compiler flag. > Okay, thanks for pointing that out. > >>> commandLineFlagConstraintsCompiler.cpp: >>> - I think there is a "rule" that the include statements should be in alphabetical order >> Yes, I think there is such a rule (or convention). I diverged from the rule because the include of code/relocInfo.hpp depends on 'os', 'vm_page_size', and 'Metadata'. Therefore, "oops/metadata.hpp" and "runtime/os.hpp" must be included before relocInfo.hpp (otherwise the Solaris compiler complains). The remaining includes are ordered alphabetically. > Okay, makes sense. > >>> - the indentation is wrong here: >>> 179 return Flag::VIOLATES_CONSTRAINT; >> I updated the indentation. >> >> Here is the updated webrev: >> http://cr.openjdk.java.net/~zmajo/8078554/webrev.02/ >> >> I re-tested the updated webrev with JPRT (testset hotspot), all tests pass. > Looks good to me (not a Reviewer). > > Best, > Tobias > > >> Thank you and best regards, >> >> >> Zoltan >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8078556 >>> Best, >>> Tobias >> >>> On 06.10.2015 13:45, Zolt?n Maj? wrote: >>>> Hi Roland, >>>> >>>> >>>> thank you for the feedback! >>>> >>>> On 10/02/2015 03:55 PM, Roland Westrelin wrote: >>>>> Hi Zoltan, >>>>> >>>>>> Webrev:http://cr.openjdk.java.net/~zmajo/8078554/ >>>>> c2_globals.hpp >>>>> >>>>> That one is not correct: >>>>> 461 product(intx, MaxNodeLimit, 80000, \ >>>>> 462 "Maximum number of nodes") \ >>>>> 463 range(1000, 80000) \ >>>>> >>>>> I think the upper bound should be max_juint >>>> You are right that the limit of 80'000 is too conservative. But max_j*u*int as an upper bound would cause an overflow when parsing the flag's value, because on 32-bit machines intx is a 32-bit signed integer. >>>> >>>> Using max_jint instead of max_j*u*int as an upper bound would not cause an overflow at parse time. However, in Parse::do_call() the maximum node limit is increased by 3 times for jsr292 users >>>> >>>> C->set_max_node_limit(3*MaxNodeLimit); >>>> >>>> If MaxNodeLimit == max_jint, this expression will overflow, I think. >>>> >>>> So I set the limit to (max_jint / 3) in the updated webrev. >>>> >>>> If we would set MaxNodeLimit to max_j*u*int / 3 (instead of max_jint / 3), the expression 3 * MaxNodeLimit would overflow as well. Changing the type of the flag from intx to uintx could let use use max_j*u*int / 3 as an upper bound, but that is most likely not worth the effort. >>>> >>>>> 699 product(intx, LiveNodeCountInliningCutoff, 40000, \ >>>>> 700 "max number of live nodes in a method") \ >>>>> 701 range(0, max_juint / 8) \ >>>>> >>>>> Out of curiosity why max_juint / 8 (not that it makes much of a difference)? >>>> In Compile::inline_incrementally, the 80% of LiveNodeCountInliningCutoff is computed the following way: >>>> >>>> if (low_live_nodes < (uint)LiveNodeCountInliningCutoff * 8 / 10) { >>>> >>>> If LiveNodeCountInliningCutoff == max_juint, we'd have an overflow because of the multiplication by 8. >>>> >>>>> arguments.cpp >>>>> >>>>> 1099 Tier3InvokeNotifyFreqLog = 0; >>>>> 1100 Tier4InvocationThreshold = 0; >>>>> >>>>> Why that change? >>>> I proposed that change because I misread the code. I reverted that change and also changed the range of all Tier*FreqLog flags from range(1, 30) to range(0, 30). >>>> >>>>> globals.hp >>>>> >>>>> 2870 product_pd(uintx, TypeProfileLevel, \ >>>>> 2871 "=XYZ, with Z: Type profiling of arguments at call; " \ >>>>> 2872 "Y: Type profiling of return value at call; " \ >>>>> 2873 "X: Type profiling of parameters to methods; " \ >>>>> 2874 "X, Y and Z in 0=off ; 1=jsr292 only; 2=all methods") \ >>>>> 2875 range(0, 222) >>>>> >>>>> Legal values are 0, 1, 2, 10, 11, 12, 100, 101, 102, 110, 111, 112 etc. >>>>> >>>>> 70 is not for instance. So range(0, 222) is incorrect. >>>> I agree. I removed the range check and implemented a constraint function instead (TypeProfileLevelConstraintFunc). >>>> >>>>> 2877 product(intx, TypeProfileArgsLimit, 2, \ >>>>> 2878 "max number of call arguments to consider for type profiling") \ >>>>> 2879 range(0, 16) \ >>>>> >>>>> 2880 \ >>>>> 2881 product(intx, TypeProfileParmsLimit, 2, \ >>>>> 2882 "max number of incoming parameters to consider for type profiling"\ >>>>> 2883 ", -1 for all") \ >>>>> 2884 range(-1, 64) >>>>> >>>>> Why 16 and 64? >>>> These are the largest values that work on all platforms we support. >>>> >>>> Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8078554/webrev.01/ >>>> >>>> I repeated the testing with JPRT. I also executed the currently disabled TestOptionsWithRanges.java test on all platforms we support. All tests pass. >>>> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> >>>>> Roland. From igor.veresov at oracle.com Thu Oct 8 16:11:51 2015 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 8 Oct 2015 09:11:51 -0700 Subject: RFR(XXS): 8139094 Tier1 test java/util/zip/TestCRC32C.java fails due to fixes for JDK-8134553 In-Reply-To: <56163378.5010205@oracle.com> References: <4102E82E-486F-4F1E-B7CB-E42558FC483B@oracle.com> <56163378.5010205@oracle.com> Message-ID: <812604D8-9170-448C-8E24-D66A9AE81A10@oracle.com> Thanks, Vladimir! igor > On Oct 8, 2015, at 2:12 AM, Vladimir Kozlov wrote: > > Looks good. > > Thanks, > Vladimir > > On 10/8/15 3:44 PM, Igor Veresov wrote: >> Tomasz Wojtowicz fixed the problem. >> Here?s the webrev: http://cr.openjdk.java.net/~iveresov/8139094/webrev.00/ >> >> I?ve reviewed and tested the fix. >> >> igor From martin.doerr at sap.com Thu Oct 8 21:44:15 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 8 Oct 2015 21:44:15 +0000 Subject: 8138894: C1: Support IRIW on weak memory platforms Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165672260EB1@DEWDFEMB19C.global.corp.sap> Hi, Some time ago, we implemented support for ordering of "Independent Reads of Independent Writes" in the template interpreter and C2 Compiler for PPC64. However, it needs to be consistent with C1. Without "IRIW" support, we generate load-acquire for volatile loads and release-store-fence for volatile stores. With "IRIW" support, we generate fence-load-acquire for volatile loads and release-store for volatile stores. CPU_NOT_MULTIPLE_COPY_ATOMIC is currently only defined on PPC64 (though it may be interesting for aarch64 as well). This change is a prerequisite for our C1 on PPC64 contribution. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8138894_c1_IRIW/webrev.00 Please review this change. I need a sponsor, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Thu Oct 8 21:46:50 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 8 Oct 2015 21:46:50 +0000 Subject: RFR(M) 8138894: C1: Support IRIW on weak memory platforms Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165672260ECB@DEWDFEMB19C.global.corp.sap> Hi, Some time ago, we implemented support for ordering of "Independent Reads of Independent Writes" in the template interpreter and C2 Compiler for PPC64. However, it needs to be consistent with C1. Without "IRIW" support, we generate load-acquire for volatile loads and release-store-fence for volatile stores. With "IRIW" support, we generate fence-load-acquire for volatile loads and release-store for volatile stores. CPU_NOT_MULTIPLE_COPY_ATOMIC is currently only defined on PPC64 (though it may be interesting for aarch64 as well). This change is a prerequisite for our C1 on PPC64 contribution. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8138894_c1_IRIW/webrev.00 Please review this change. I need a sponsor, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Thu Oct 8 21:49:01 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 8 Oct 2015 21:49:01 +0000 Subject: RFR(M) 8138895: C1: PPC64 Port needs special register for Locks in synchronization code Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165672260ED9@DEWDFEMB19C.global.corp.sap> Hi, This change introduces syncLockOpr like the existing syncTempOpr. Other platforms than PPC64 just return a new register so it's no functional change there. This change is a prerequisite for our C1 on PPC64 contribution. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8138895_c1_syncLockOpr/webrev.00 Implementation for aarch64 is included but not tested. Please review this change. I need a sponsor, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.civlin at intel.com Thu Oct 8 23:14:35 2015 From: jan.civlin at intel.com (Civlin, Jan) Date: Thu, 8 Oct 2015 23:14:35 +0000 Subject: RFR(M): 8136725 Provide utility for creation a counted loop reserve copy (clone) In-Reply-To: <39F83597C33E5F408096702907E6C4500585C2A5@ORSMSX104.amr.corp.intel.com> References: <012766EA-BDDF-4E0D-A01C-7B96591ABC64@oracle.com> <39F83597C33E5F408096702907E6C45005852375@ORSMSX104.amr.corp.intel.com> <56028117.50706@oracle.com> <39F83597C33E5F408096702907E6C4500585A55E@ORSMSX104.amr.corp.intel.com> <30A22020-0926-4C94-A44E-8CEA37565C96@oracle.com> <56122FD0.2050200@oracle.com> <39F83597C33E5F408096702907E6C4500585C111@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C4500585C2A5@ORSMSX104.amr.corp.intel.com> Message-ID: <39F83597C33E5F408096702907E6C45005877BC6@ORSMSX104.amr.corp.intel.com> Vladimir, Igor, The webrev was uploaded to this location: http://cr.openjdk.java.net/~mcberg/8136725/webrev.03/ -----Original Message----- From: Civlin, Jan Sent: Tuesday, October 06, 2015 1:44 AM To: 'Vladimir Kozlov' Cc: 'hotspot compiler'; Civlin, Jan Subject: RE: RFR(M): 8136725 Provide utility for creation a counted loop reserve copy (clone) Seems the attached file was stripped by firewall. Trying to send again. -----Original Message----- From: Civlin, Jan Sent: Monday, October 5, 2015 6:54 PM To: Vladimir Kozlov Cc: hotspot compiler; Civlin, Jan Subject: RE: RFR(M): 8136725 Provide utility for creation a counted loop reserve copy (clone) Vladimir, thank you for the review. Here is the updated patch. I decided to stick to simple if(TraceLoopOpts) condition for checking in printing, since these messages are printed on error only. Regards, Jan. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Monday, October 05, 2015 1:08 AM To: Civlin, Jan Cc: hotspot compiler Subject: Re: RFR(M): 8136725 Provide utility for creation a counted loop reserve copy (clone) remove .hgtags changes Trace outputs in create_reserve() are not under trace flag. I would suggest to remove them or put under TraceLoopOpts && Verbose combination. Also, please, split next and similar lines according to our code stile: if (!_lp_reserved->is_CountedLoop()) return false; --- if (!_lp_reserved->is_CountedLoop()) { return false; } The rest looks fine. Thanks, Vladimir On 10/1/15 4:31 AM, Igor Veresov wrote: > Here?s the updated webrev: > > http://cr.openjdk.java.net/~iveresov/loop-reverse/webrev.02/ > > igor > >> On Sep 28, 2015, at 2:25 AM, Civlin, Jan > > wrote: >> >> Vladimir, >> >> Thank you for the review. >> I'm attaching the patch reflecting your comments. >> >> Regards, >> >> Jan >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Wednesday, September 23, 2015 3:38 AM >> To: Civlin, Jan; hotspot compiler >> Subject: Re: RFR(M): 8136725 Provide utility for creation a counted >> loop reserve copy (clone) >> >> in loopUnswitch.cpp debug output should be under nonproduct flag >> (could be TraceLoopOpts or separate new flag). Use #ifndef PRODUCT >> around print code instead of repeated NOT_PRODUCT() macro. And I >> don't think you need all output you added in final version. >> >> All constants are IGVNed so you don't need to pre-generate const_0. >> Since it is not connected to graph it could be eliminated. >> And I don't think you need next for the same reason: >> >> 311 lk->set_const_0(const_0); >> 312 lk->set_const_1(const_1); >> >> In ~CountedLoopReserveKit() and switch_to_reserved() you can make new >> const_0 since you have pointer to IGVN: >> >> _phase->_igvn.intcon(0); >> >> You can't use subsume() since it will replace all users of const_1: >> >> + //TODO bug? could not use here _const_1->subsume_by(_const_0, >> _phase->C); >> >> It is correct to use set_req() for constants here. >> >> superword.cpp I don't think you need to keep >> _CountedLoopReserveKit_test code in final version after you verified it works during development: >> >> + //!/// Testing that switching to reserved copy works >> >> Thanks, >> Vladimir >> >> On 9/19/15 1:05 AM, Civlin, Jan wrote: >>> As I was working on modification of SuperWord::output - and this is >>> a function where you modify the ideal graph on the fly and cannot >>> exit on error - I was wondering how can I protect my algorithm in a >>> case some wrong decision was made on the previous stage of the >>> SuperWord but discovered only at the final stage, when the graph is >>> already half modified. >>> >>> So here is my solution: >>> - the graph to be modified is cloned. >>> - five nodes are added: intcon(0) is disconnected, intcon(1)->If-> >>> IfTrue->orig_loop: IfFalse->clone_loop. >>> >>> Then any optimization is executed on the original loop, and if it >>> finishes ok, nothing else need to be done, the clone_loop will be >>> removed as dead in the consecutive stages of compiler. >>> At any moment, if an error occurs, the node intcon(1) may be >>> subsumed by node intcon(0), therefore the clone_loop becomes >>> "active" and the original "unfinished in modification" loop will be removed later. >>> >>> This utility is implemented in class CountedLoopReserveKit. >>> The loop cloning and 5 nodes adding is realized in the ctor and >>> possible subsuming intcon(1) by intcon(0) in dtor, so a simple >>> return from the modifying graph function will do graph correction >>> (switching in choice) of the graph. >>> Basically, it is sufficient the create a local object of >>> CountedLoopReserveKit class, the scoped dtor makes the choice: >>> modified or original loop. >>> >>> SuperWord::output in this submission is included only to illustrate >>> how to use the CountedLoopReserveKit. >>> The actual new SuperWord::output where CountedLoopReserveKit is >>> indeed substantial is coming in the next patch. >>> >>> This reserve loop cloning in SuperWord may be disabled by the global >>> flag DoReserveCopyInSuperWord. >>> >>> -----Original Message----- >>> From: Igor Veresov [mailto:igor.veresov at oracle.com] >>> Sent: Thursday, September 17, 2015 2:31 PM >>> To: hotspot compiler >>> Cc: Civlin, Jan >>> Subject: RFR(M): 8136725 Provide utility for creation a counted loop >>> reserve copy (clone) >>> >>> Provide utility for creation a counted loop reserve copy (clone). >>> May be used in any graph optimization for simple roll back to the >>> original loop, in partially will be used in SuperWord, where the >>> loop modification goes on-the-fly and potentially may not finish >>> correctly (the patch for SuperWord is coming soon). >>> >>> This is contributed by Jan Civlin >> > >>> >>> Webrev: >>> http://cr.openjdk.java.net/~iveresov/loop-reverse/webrev-091515/ >>> >>> igor >>> >> > From christian.thalinger at oracle.com Fri Oct 9 00:32:24 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 8 Oct 2015 14:32:24 -1000 Subject: RFR(S): 8134607: Remove per-compiler performance counters In-Reply-To: <56164774.2080504@oracle.com> References: <56164774.2080504@oracle.com> Message-ID: <14408518-3FC6-4ECC-80FF-DEA48992C3F5@oracle.com> > On Oct 8, 2015, at 12:37 AM, Claes Redestad wrote: > > Hello hotspot-compiler.dev, > > anyone care to review this patch to remove per-compiler thread performance counters? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8134607 > > HotSpot webrev: http://cr.openjdk.java.net/~redestad/8134607/hotspot.01 > JDK webrev: http://cr.openjdk.java.net/~redestad/8134607/jdk.01 Looks good. When will the Java class be removed? > > CCC approved, no new test failures running JPRT against hs-comp. > > /Claes From vladimir.kozlov at oracle.com Fri Oct 9 03:14:25 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 9 Oct 2015 11:14:25 +0800 Subject: RFR(M): 8136725 Provide utility for creation a counted loop reserve copy (clone) In-Reply-To: <39F83597C33E5F408096702907E6C45005877BC6@ORSMSX104.amr.corp.intel.com> References: <012766EA-BDDF-4E0D-A01C-7B96591ABC64@oracle.com> <39F83597C33E5F408096702907E6C45005852375@ORSMSX104.amr.corp.intel.com> <56028117.50706@oracle.com> <39F83597C33E5F408096702907E6C4500585A55E@ORSMSX104.amr.corp.intel.com> <30A22020-0926-4C94-A44E-8CEA37565C96@oracle.com> <56122FD0.2050200@oracle.com> <39F83597C33E5F408096702907E6C4500585C111@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C4500585C2A5@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C45005877BC6@ORSMSX104.amr.corp.intel.com> Message-ID: <56173111.5070603@oracle.com> Looks good. Igor, please, use hotspot.patch which does not have .hgtag. Don't forgot to add Contributed-by: jan.civlin at intel.com http://cr.openjdk.java.net/~mcberg/8136725/webrev.03/hotspot.patch Thanks, Vladimir On 10/9/15 7:14 AM, Civlin, Jan wrote: > Vladimir, Igor, > > The webrev was uploaded to this location: > > http://cr.openjdk.java.net/~mcberg/8136725/webrev.03/ > > > -----Original Message----- > From: Civlin, Jan > Sent: Tuesday, October 06, 2015 1:44 AM > To: 'Vladimir Kozlov' > Cc: 'hotspot compiler'; Civlin, Jan > Subject: RE: RFR(M): 8136725 Provide utility for creation a counted loop reserve copy (clone) > > Seems the attached file was stripped by firewall. Trying to send again. > > -----Original Message----- > From: Civlin, Jan > Sent: Monday, October 5, 2015 6:54 PM > To: Vladimir Kozlov > Cc: hotspot compiler; Civlin, Jan > Subject: RE: RFR(M): 8136725 Provide utility for creation a counted loop reserve copy (clone) > > Vladimir, thank you for the review. > > Here is the updated patch. > > I decided to stick to simple if(TraceLoopOpts) condition for checking in printing, since these messages are printed on error only. > > > Regards, > > Jan. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Monday, October 05, 2015 1:08 AM > To: Civlin, Jan > Cc: hotspot compiler > Subject: Re: RFR(M): 8136725 Provide utility for creation a counted loop reserve copy (clone) > > remove .hgtags changes > > Trace outputs in create_reserve() are not under trace flag. I would suggest to remove them or put under TraceLoopOpts && Verbose combination. > Also, please, split next and similar lines according to our code stile: > > if (!_lp_reserved->is_CountedLoop()) return false; > --- > if (!_lp_reserved->is_CountedLoop()) { > return false; > } > > The rest looks fine. > > Thanks, > Vladimir > > On 10/1/15 4:31 AM, Igor Veresov wrote: >> Here?s the updated webrev: >> >> http://cr.openjdk.java.net/~iveresov/loop-reverse/webrev.02/ >> >> igor >> >>> On Sep 28, 2015, at 2:25 AM, Civlin, Jan >> > wrote: >>> >>> Vladimir, >>> >>> Thank you for the review. >>> I'm attaching the patch reflecting your comments. >>> >>> Regards, >>> >>> Jan >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Wednesday, September 23, 2015 3:38 AM >>> To: Civlin, Jan; hotspot compiler >>> Subject: Re: RFR(M): 8136725 Provide utility for creation a counted >>> loop reserve copy (clone) >>> >>> in loopUnswitch.cpp debug output should be under nonproduct flag >>> (could be TraceLoopOpts or separate new flag). Use #ifndef PRODUCT >>> around print code instead of repeated NOT_PRODUCT() macro. And I >>> don't think you need all output you added in final version. >>> >>> All constants are IGVNed so you don't need to pre-generate const_0. >>> Since it is not connected to graph it could be eliminated. >>> And I don't think you need next for the same reason: >>> >>> 311 lk->set_const_0(const_0); >>> 312 lk->set_const_1(const_1); >>> >>> In ~CountedLoopReserveKit() and switch_to_reserved() you can make new >>> const_0 since you have pointer to IGVN: >>> >>> _phase->_igvn.intcon(0); >>> >>> You can't use subsume() since it will replace all users of const_1: >>> >>> + //TODO bug? could not use here _const_1->subsume_by(_const_0, >>> _phase->C); >>> >>> It is correct to use set_req() for constants here. >>> >>> superword.cpp I don't think you need to keep >>> _CountedLoopReserveKit_test code in final version after you verified it works during development: >>> >>> + //!/// Testing that switching to reserved copy works >>> >>> Thanks, >>> Vladimir >>> >>> On 9/19/15 1:05 AM, Civlin, Jan wrote: >>>> As I was working on modification of SuperWord::output - and this is >>>> a function where you modify the ideal graph on the fly and cannot >>>> exit on error - I was wondering how can I protect my algorithm in a >>>> case some wrong decision was made on the previous stage of the >>>> SuperWord but discovered only at the final stage, when the graph is >>>> already half modified. >>>> >>>> So here is my solution: >>>> - the graph to be modified is cloned. >>>> - five nodes are added: intcon(0) is disconnected, intcon(1)->If-> >>>> IfTrue->orig_loop: IfFalse->clone_loop. >>>> >>>> Then any optimization is executed on the original loop, and if it >>>> finishes ok, nothing else need to be done, the clone_loop will be >>>> removed as dead in the consecutive stages of compiler. >>>> At any moment, if an error occurs, the node intcon(1) may be >>>> subsumed by node intcon(0), therefore the clone_loop becomes >>>> "active" and the original "unfinished in modification" loop will be removed later. >>>> >>>> This utility is implemented in class CountedLoopReserveKit. >>>> The loop cloning and 5 nodes adding is realized in the ctor and >>>> possible subsuming intcon(1) by intcon(0) in dtor, so a simple >>>> return from the modifying graph function will do graph correction >>>> (switching in choice) of the graph. >>>> Basically, it is sufficient the create a local object of >>>> CountedLoopReserveKit class, the scoped dtor makes the choice: >>>> modified or original loop. >>>> >>>> SuperWord::output in this submission is included only to illustrate >>>> how to use the CountedLoopReserveKit. >>>> The actual new SuperWord::output where CountedLoopReserveKit is >>>> indeed substantial is coming in the next patch. >>>> >>>> This reserve loop cloning in SuperWord may be disabled by the global >>>> flag DoReserveCopyInSuperWord. >>>> >>>> -----Original Message----- >>>> From: Igor Veresov [mailto:igor.veresov at oracle.com] >>>> Sent: Thursday, September 17, 2015 2:31 PM >>>> To: hotspot compiler >>>> Cc: Civlin, Jan >>>> Subject: RFR(M): 8136725 Provide utility for creation a counted loop >>>> reserve copy (clone) >>>> >>>> Provide utility for creation a counted loop reserve copy (clone). >>>> May be used in any graph optimization for simple roll back to the >>>> original loop, in partially will be used in SuperWord, where the >>>> loop modification goes on-the-fly and potentially may not finish >>>> correctly (the patch for SuperWord is coming soon). >>>> >>>> This is contributed by Jan Civlin >>> > >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~iveresov/loop-reverse/webrev-091515/ >>>> >>>> igor >>>> >>> >> From vladimir.kozlov at oracle.com Fri Oct 9 03:39:42 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 9 Oct 2015 11:39:42 +0800 Subject: RFR: 8139043: aarch64: add support for adler32 intrinsic In-Reply-To: <1444314225.15616.12.camel@mylittlepony.linaroharston> References: <1444314225.15616.12.camel@mylittlepony.linaroharston> Message-ID: <561736FE.50702@oracle.com> Looks good. Thanks, Vladimir On 10/8/15 10:23 PM, Edward Nevill wrote: > Hi, > > Please review the following webrev > > http://cr.openjdk.java.net/~enevill/8139043/webrev/ > > Jira Issue: https://bugs.openjdk.java.net/browse/JDK-8139043 > > This webrev adds support for adler32 intrinsic on aarch64 in the same way that support for adler32 was added for Sparc recently (see https://bugs.openjdk.java.net/browse/JDK-8132081) > > Testing using TestAdler32.java from jtreg test suite shows between 60% and 155% improvement depending on the size of buffer. > > Tested with jtreg hotspot. Results the same before and after patch (Test results: passed: 896; failed: 6; error: 10) > > Thanks for your help, > Ed > > From jan.civlin at intel.com Fri Oct 9 04:03:36 2015 From: jan.civlin at intel.com (Civlin, Jan) Date: Fri, 9 Oct 2015 04:03:36 +0000 Subject: RFR(M): 8136725 Provide utility for creation a counted loop reserve copy (clone) In-Reply-To: <56173111.5070603@oracle.com> References: <012766EA-BDDF-4E0D-A01C-7B96591ABC64@oracle.com> <39F83597C33E5F408096702907E6C45005852375@ORSMSX104.amr.corp.intel.com> <56028117.50706@oracle.com> <39F83597C33E5F408096702907E6C4500585A55E@ORSMSX104.amr.corp.intel.com> <30A22020-0926-4C94-A44E-8CEA37565C96@oracle.com> <56122FD0.2050200@oracle.com> <39F83597C33E5F408096702907E6C4500585C111@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C4500585C2A5@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C45005877BC6@ORSMSX104.amr.corp.intel.com> <56173111.5070603@oracle.com> Message-ID: <39F83597C33E5F408096702907E6C45005877BF5@ORSMSX104.amr.corp.intel.com> Thank you, Vladimir. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Thursday, October 08, 2015 8:14 PM To: Civlin, Jan; Igor Veresov Cc: 'hotspot compiler' Subject: Re: RFR(M): 8136725 Provide utility for creation a counted loop reserve copy (clone) Looks good. Igor, please, use hotspot.patch which does not have .hgtag. Don't forgot to add Contributed-by: jan.civlin at intel.com http://cr.openjdk.java.net/~mcberg/8136725/webrev.03/hotspot.patch Thanks, Vladimir On 10/9/15 7:14 AM, Civlin, Jan wrote: > Vladimir, Igor, > > The webrev was uploaded to this location: > > http://cr.openjdk.java.net/~mcberg/8136725/webrev.03/ > > > -----Original Message----- > From: Civlin, Jan > Sent: Tuesday, October 06, 2015 1:44 AM > To: 'Vladimir Kozlov' > Cc: 'hotspot compiler'; Civlin, Jan > Subject: RE: RFR(M): 8136725 Provide utility for creation a counted > loop reserve copy (clone) > > Seems the attached file was stripped by firewall. Trying to send again. > > -----Original Message----- > From: Civlin, Jan > Sent: Monday, October 5, 2015 6:54 PM > To: Vladimir Kozlov > Cc: hotspot compiler; Civlin, Jan > Subject: RE: RFR(M): 8136725 Provide utility for creation a counted > loop reserve copy (clone) > > Vladimir, thank you for the review. > > Here is the updated patch. > > I decided to stick to simple if(TraceLoopOpts) condition for checking in printing, since these messages are printed on error only. > > > Regards, > > Jan. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Monday, October 05, 2015 1:08 AM > To: Civlin, Jan > Cc: hotspot compiler > Subject: Re: RFR(M): 8136725 Provide utility for creation a counted > loop reserve copy (clone) > > remove .hgtags changes > > Trace outputs in create_reserve() are not under trace flag. I would suggest to remove them or put under TraceLoopOpts && Verbose combination. > Also, please, split next and similar lines according to our code stile: > > if (!_lp_reserved->is_CountedLoop()) return false; > --- > if (!_lp_reserved->is_CountedLoop()) { > return false; > } > > The rest looks fine. > > Thanks, > Vladimir > > On 10/1/15 4:31 AM, Igor Veresov wrote: >> Here?s the updated webrev: >> >> http://cr.openjdk.java.net/~iveresov/loop-reverse/webrev.02/ >> >> igor >> >>> On Sep 28, 2015, at 2:25 AM, Civlin, Jan >> > wrote: >>> >>> Vladimir, >>> >>> Thank you for the review. >>> I'm attaching the patch reflecting your comments. >>> >>> Regards, >>> >>> Jan >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Wednesday, September 23, 2015 3:38 AM >>> To: Civlin, Jan; hotspot compiler >>> Subject: Re: RFR(M): 8136725 Provide utility for creation a counted >>> loop reserve copy (clone) >>> >>> in loopUnswitch.cpp debug output should be under nonproduct flag >>> (could be TraceLoopOpts or separate new flag). Use #ifndef PRODUCT >>> around print code instead of repeated NOT_PRODUCT() macro. And I >>> don't think you need all output you added in final version. >>> >>> All constants are IGVNed so you don't need to pre-generate const_0. >>> Since it is not connected to graph it could be eliminated. >>> And I don't think you need next for the same reason: >>> >>> 311 lk->set_const_0(const_0); >>> 312 lk->set_const_1(const_1); >>> >>> In ~CountedLoopReserveKit() and switch_to_reserved() you can make >>> new >>> const_0 since you have pointer to IGVN: >>> >>> _phase->_igvn.intcon(0); >>> >>> You can't use subsume() since it will replace all users of const_1: >>> >>> + //TODO bug? could not use here _const_1->subsume_by(_const_0, >>> _phase->C); >>> >>> It is correct to use set_req() for constants here. >>> >>> superword.cpp I don't think you need to keep >>> _CountedLoopReserveKit_test code in final version after you verified it works during development: >>> >>> + //!/// Testing that switching to reserved copy works >>> >>> Thanks, >>> Vladimir >>> >>> On 9/19/15 1:05 AM, Civlin, Jan wrote: >>>> As I was working on modification of SuperWord::output - and this is >>>> a function where you modify the ideal graph on the fly and cannot >>>> exit on error - I was wondering how can I protect my algorithm in a >>>> case some wrong decision was made on the previous stage of the >>>> SuperWord but discovered only at the final stage, when the graph is >>>> already half modified. >>>> >>>> So here is my solution: >>>> - the graph to be modified is cloned. >>>> - five nodes are added: intcon(0) is disconnected, intcon(1)->If-> >>>> IfTrue->orig_loop: IfFalse->clone_loop. >>>> >>>> Then any optimization is executed on the original loop, and if it >>>> finishes ok, nothing else need to be done, the clone_loop will be >>>> removed as dead in the consecutive stages of compiler. >>>> At any moment, if an error occurs, the node intcon(1) may be >>>> subsumed by node intcon(0), therefore the clone_loop becomes >>>> "active" and the original "unfinished in modification" loop will be removed later. >>>> >>>> This utility is implemented in class CountedLoopReserveKit. >>>> The loop cloning and 5 nodes adding is realized in the ctor and >>>> possible subsuming intcon(1) by intcon(0) in dtor, so a simple >>>> return from the modifying graph function will do graph correction >>>> (switching in choice) of the graph. >>>> Basically, it is sufficient the create a local object of >>>> CountedLoopReserveKit class, the scoped dtor makes the choice: >>>> modified or original loop. >>>> >>>> SuperWord::output in this submission is included only to illustrate >>>> how to use the CountedLoopReserveKit. >>>> The actual new SuperWord::output where CountedLoopReserveKit is >>>> indeed substantial is coming in the next patch. >>>> >>>> This reserve loop cloning in SuperWord may be disabled by the >>>> global flag DoReserveCopyInSuperWord. >>>> >>>> -----Original Message----- >>>> From: Igor Veresov [mailto:igor.veresov at oracle.com] >>>> Sent: Thursday, September 17, 2015 2:31 PM >>>> To: hotspot compiler >>>> Cc: Civlin, Jan >>>> Subject: RFR(M): 8136725 Provide utility for creation a counted >>>> loop reserve copy (clone) >>>> >>>> Provide utility for creation a counted loop reserve copy (clone). >>>> May be used in any graph optimization for simple roll back to the >>>> original loop, in partially will be used in SuperWord, where the >>>> loop modification goes on-the-fly and potentially may not finish >>>> correctly (the patch for SuperWord is coming soon). >>>> >>>> This is contributed by Jan Civlin >>> > >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~iveresov/loop-reverse/webrev-091515/ >>>> >>>> igor >>>> >>> >> From martin.doerr at sap.com Fri Oct 9 10:03:56 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 9 Oct 2015 10:03:56 +0000 Subject: RFR(S): 8138890: C1: Ambiguous operator delete In-Reply-To: References: <7C9B87B351A4BA4AA9EC95BB41811656722607B5@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672260AE1@DEWDFEMB19C.global.corp.sap> <56153267.7060401@oracle.com> <7C9B87B351A4BA4AA9EC95BB4181165672260BFB@DEWDFEMB19C.global.corp.sap> Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165672261012@DEWDFEMB19C.global.corp.sap> Hi, thanks for reviewing. As requested by G?tz, I just removed the second ?private?. The new webrev is here: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.02 Best regards, Martin From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Mittwoch, 7. Oktober 2015 21:28 To: Doerr, Martin Cc: Mikael Gerdin; Christian Thalinger; hotspot compiler Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete Hi Martin, as the new/delete operators in StackObj are private (I missed that before) they shouldn't be visible in LIRGenerator. So this is probably yet another xlC bug :( On the other hand the new/delete operators in CompilationResourceObject are public and are inherited by LIRGenerator. So if we only want to generate LIRGenerator instances on the stack, your change is good, because it ensures this. And in that case we surely don't need an implementation. So thumbs up from me! Volker On Wednesday, October 7, 2015, Doerr, Martin > wrote: Hi Volker, the C1 classes we are talking about should never get instantiated by operator new. A typical way to establish this is to make the new operators private. I don?t really care if the delete operators are public or private because if the new operator is never used, how can the delete operator get used? It may be more beautiful to declare them as private as well. Only in the case G?tz has showed, some Compilers reject the private delete operators. Best regards, Martin From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Mittwoch, 7. Oktober 2015 17:57 To: Mikael Gerdin Cc: Doerr, Martin; Christian Thalinger; hotspot compiler Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete Hi Martin, we have: class LIRGenerator: public InstructionVisitor, public BlockClosure and: class BlockClosure: public CompilationResourceObj class CompilationResourceObj ALLOCATION_SUPER_CLASS_SPEC { public: void* operator new(size_t size) throw() { return Compilation::current()->arena()->Amalloc(size); } void* operator new(size_t size, Arena* arena) throw() { return arena->Amalloc(size); } void operator delete(void* p) {} // nothing to do }; class InstructionVisitor: public StackObj class StackObj ALLOCATION_SUPER_CLASS_SPEC { private: void* operator new(size_t size) throw(); void* operator new [](size_t size) throw(); #ifdef __IBMCPP__ public: #endif void operator delete(void* p); void operator delete [](void* p); Now you declare new "new()" and "delete()" operators in the LIRGenerator which will actually hide the corresponding operators from the base classes. You also provide no implementation for the new operators in LIRGenerator. So which new/delete operators will be actually used for allocating new LIRGenerator instances? OK, wait. As far as I can see, LIRGenerator is never dynamically allocated, right? In that case it should be a StackObj and you could probably solve the problem with "using" directives (e.g. using StackObj::operator new, ...). Have you tried that? Regards, Volker On Wed, Oct 7, 2015 at 4:55 PM, Mikael Gerdin > wrote: On 2015-10-07 16:17, Doerr, Martin wrote: Hi, that?s a good question J I can only remember that there were problems with some old compilers. Anyway, xlC 12.1 can deal with the private delete operators. If that's the case, can we also get rid of the workaround in allocation.hpp? Thanks /Mikael Here?s the new webrev: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.01 Best regards, Martin *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com] *Sent:* Mittwoch, 7. Oktober 2015 03:32 *To:* Doerr, Martin *Cc:* hotspot compiler *Subject:* Re: RFR(S): 8138890: C1: Ambiguous operator delete On Oct 6, 2015, at 3:56 AM, Doerr, Martin >> wrote: Hi, xlC on AIX rejects to compile LIRGenerator and RangeCheckEliminator::Verification due to ambiguous operator delete which gets inherited from multiple base classes. This change is a prerequisite for our C1 on PPC64 contribution. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.00 Let me ask my question here: why do you need the delete methods to be public on AIX? Please review this change. I need a sponsor, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.nevill at gmail.com Fri Oct 9 11:17:50 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Fri, 09 Oct 2015 12:17:50 +0100 Subject: RFR: 8139259: aarch64: jtreg test TestLogSum segvs after 8132207 Message-ID: <1444389470.23861.23.camel@mint> Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8139259/webrev/ Jira issue: https://bugs.openjdk.java.net/browse/JDK-8139259 This fixes a SEGV which was introduced to the aarch64 port after the following patch http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/324ea1a2419a The problem is that the aarch64 port ends up calling StubRoutines::_dexp when it is initialised to NULL. The reason is the following lines --- src/share/vm/opto/library_call.cpp --- 1764 case vmIntrinsics::_dexp: 1765 return (UseSSE >= 2) ? runtime_math(OptoRuntime::Math_D_D_Type(), StubRoutines::dexp(), "dexp") : 1766 runtime_math(OptoRuntime::Math_D_D_Type(), FN_PTR(SharedRuntime::dexp), "EXP"); --- src/share/vm/runtime/globals.hpp 702 product(intx, UseSSE, 99, \ 703 "Highest supported SSE instructions set on x86/x64") \ --- src/share/vm/runtime/stubRoutines.cpp 151 address StubRoutines::_dexp = NULL; I could fix this by forcing UseSSE to 0 in vm_version_aarch64 however there are about 20 other places in C1 and C2 shared code where UseSSE is used and I would be changing the behaviour of all of these. So instead the patch above removes the usage of UseSSE in library_call above. At some time all the usages of UseSSE in shared code should be reviewed. This patch affects shared code so will need to be sponsored and pushed through JPRT Thanks for your help, Ed. From roland.westrelin at oracle.com Fri Oct 9 12:23:51 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 9 Oct 2015 14:23:51 +0200 Subject: RFR: 8139259: aarch64: jtreg test TestLogSum segvs after 8132207 In-Reply-To: <1444389470.23861.23.camel@mint> References: <1444389470.23861.23.camel@mint> Message-ID: <8AF4C615-5E7A-425E-8883-5E7ECE2669E7@oracle.com> Hi Ed, > http://cr.openjdk.java.net/~enevill/8139259/webrev/ All 64 bit x86 cpus support sse2 so the new check in stubGenerator_x86_64.cpp is useless. Given in the interpreter and c1, we call the exp stub unconditionally, it didn?t really make sense that it was conditional on UseSSE in c2, anyway. Your library_call.cpp change looks good to me. I?ll sponsor it. Roland. From zoltan.majo at oracle.com Fri Oct 9 12:36:28 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 9 Oct 2015 14:36:28 +0200 Subject: [9] RFR(XS): 8081288: erronous free in RegClass::~RegClass() In-Reply-To: <5616764F.1070403@oracle.com> References: <5616636A.5010909@oracle.com> <5616764F.1070403@oracle.com> Message-ID: <5617B4CC.1040802@oracle.com> Thank you, Vladimir, for the review! Best regards, Zoltan On 10/08/2015 03:57 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 10/8/15 8:36 PM, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the patch for JDK-8081288. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8081288 >> >> >> Problem: JDK-8075798 modified the destructor of RegClass to free the >> _classid field of that class: >> >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ac291bc3ece2#l5.50 >> >> This is bad software engineering practice because the _classid field >> points to a memory region *not* allocated by the class itself >> (allocation happens in ADLParser::get_ident_common); freeing the memory >> region in RegClass can also lead to errors if ADLParser is changed in >> the future to release memory it has allocated. >> >> The problem was spotted by Krystal Mok. >> >> >> Solution: Change code to not free _classid. >> >> Webrev: http://cr.openjdk.java.net/~zmajo/8081288/webrev.00/ >> >> Testing: JPRT. >> >> Thank you and best regards, >> >> >> Zoltan >> From martin.doerr at sap.com Fri Oct 9 13:59:36 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 9 Oct 2015 13:59:36 +0000 Subject: RFR(M) 8138894: C1: Support IRIW on weak memory platforms In-Reply-To: References: <7C9B87B351A4BA4AA9EC95BB4181165672260ECB@DEWDFEMB19C.global.corp.sap> Message-ID: <7C9B87B351A4BA4AA9EC95BB418116567226109D@DEWDFEMB19C.global.corp.sap> Hi Hui Shi, I appreciate that aarch64 experts are interested in this topic as well. Here are my answers to your questions: > why volatile field write only in initializer method requires memory barrier? As explained earlier, we don?t emit any membar instructions after volatile stores by default if IRIW support is enabled. (The Java memory model compliant ordering of volatile accesses is fulfilled by the membar scheme described below.) This leads to the behavior of the following example. We initialize an AtomicInteger (which contains a volatile int) and publish it to another thread. This thread may observe 0 instead of the init value. As far as I know, this behavior is allowed by the Java memory model. However, we think that it is undesired. There was also a Concurrency Torture Test which flagged this as error. The short answer is, it may not be strictly necessary, but it could otherwise be unexpected for Java developers. > If volatile field is written in initializer, but volatile field isn't initialized object's field, does it need memory barrier? I don?t think there?s any undesired behavior in this case. So it should not be needed. Anyway, I don?t think this case is worth optimizing for C1. This change makes C1 support IRIW in the same way as C2. If you?re thinking about using it on aarch64 there may be a desire to refine the implementation. If I remember correctly, aarch64 is also CPU_NOT_MULTIPLE_COPY_ATOMIC, but has some instructions which behave multiple copy atomic. Best regards, Martin From: Hui Shi [mailto:hui.shi at linaro.org] Sent: Freitag, 9. Oktober 2015 15:11 To: Doerr, Martin Subject: Re: RFR(M) 8138894: C1: Support IRIW on weak memory platforms Hi Martin, I'm interested in PPC insert memory barrier when volatile field is wrote in initializer method. why volatile field write only in initializer method requires memory barrier? If volatile field is written in initializer, but volatile field isn't initialized object's field, does it need memory barrier? For example written b's volatile field in A's initializer. class A { A(B b) { b.vol = 1; } } class B { int vol = 0; } Regards Shi Hui On 9 October 2015 at 05:46, Doerr, Martin > wrote: Hi, Some time ago, we implemented support for ordering of "Independent Reads of Independent Writes" in the template interpreter and C2 Compiler for PPC64. However, it needs to be consistent with C1. Without "IRIW" support, we generate load-acquire for volatile loads and release-store-fence for volatile stores. With "IRIW" support, we generate fence-load-acquire for volatile loads and release-store for volatile stores. CPU_NOT_MULTIPLE_COPY_ATOMIC is currently only defined on PPC64 (though it may be interesting for aarch64 as well). This change is a prerequisite for our C1 on PPC64 contribution. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8138894_c1_IRIW/webrev.00 Please review this change. I need a sponsor, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.westrelin at oracle.com Fri Oct 9 14:41:45 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 9 Oct 2015 16:41:45 +0200 Subject: RFR(M) 8138894: C1: Support IRIW on weak memory platforms In-Reply-To: <7C9B87B351A4BA4AA9EC95BB418116567226109D@DEWDFEMB19C.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB4181165672260ECB@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB418116567226109D@DEWDFEMB19C.global.corp.sap> Message-ID: <762DC4CC-A22C-4640-995A-946ED675FA88@oracle.com> Martin, Can you (or someone working on PPC) take a look at the change under the email thread: RFR: Elide more final field's write memory barrier with escape analysis result and confirm whether the PPC change is ok or not? Roland. > On Oct 9, 2015, at 3:59 PM, Doerr, Martin wrote: > > Hi Hui Shi, > > I appreciate that aarch64 experts are interested in this topic as well. > > Here are my answers to your questions: > > why volatile field write only in initializer method requires memory barrier? > > As explained earlier, we don?t emit any membar instructions after volatile stores by default if IRIW support is enabled. > (The Java memory model compliant ordering of volatile accesses is fulfilled by the membar scheme described below.) > This leads to the behavior of the following example. > We initialize an AtomicInteger (which contains a volatile int) and publish it to another thread. This thread may observe 0 instead of the init value. > > As far as I know, this behavior is allowed by the Java memory model. However, we think that it is undesired. > There was also a Concurrency Torture Test which flagged this as error. > > The short answer is, it may not be strictly necessary, but it could otherwise be unexpected for Java developers. > > > > If volatile field is written in initializer, but volatile field isn't initialized object's field, does it need memory barrier? > I don?t think there?s any undesired behavior in this case. So it should not be needed. Anyway, I don?t think this case is worth optimizing for C1. > This change makes C1 support IRIW in the same way as C2. > > > If you?re thinking about using it on aarch64 there may be a desire to refine the implementation. > If I remember correctly, aarch64 is also CPU_NOT_MULTIPLE_COPY_ATOMIC, but has some instructions which behave multiple copy atomic. > > Best regards, > Martin > > From: Hui Shi [mailto:hui.shi at linaro.org] > Sent: Freitag, 9. Oktober 2015 15:11 > To: Doerr, Martin > Subject: Re: RFR(M) 8138894: C1: Support IRIW on weak memory platforms > > Hi Martin, > > I'm interested in PPC insert memory barrier when volatile field is wrote in initializer method. > why volatile field write only in initializer method requires memory barrier? > > If volatile field is written in initializer, but volatile field isn't initialized object's field, does it need memory barrier? For example written b's volatile field in A's initializer. > > class A { > A(B b) { b.vol = 1; } > } > > class B { int vol = 0; } > > Regards > Shi Hui > > On 9 October 2015 at 05:46, Doerr, Martin wrote: > Hi, > > Some time ago, we implemented support for ordering of "Independent Reads of Independent Writes" in the template interpreter and C2 Compiler for PPC64. However, it needs to be consistent with C1. > > > > Without "IRIW" support, we generate load-acquire for volatile loads and release-store-fence for volatile stores. > > With "IRIW" support, we generate fence-load-acquire for volatile loads and release-store for volatile stores. > > CPU_NOT_MULTIPLE_COPY_ATOMIC is currently only defined on PPC64 (though it may be interesting for aarch64 as well). > > This change is a prerequisite for our C1 on PPC64 contribution. > > > > Webrev is here: > > http://cr.openjdk.java.net/~mdoerr/8138894_c1_IRIW/webrev.00 > > > > Please review this change. I need a sponsor, please. > > > > Best regards, > Martin From claes.redestad at oracle.com Fri Oct 9 14:42:56 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 09 Oct 2015 16:42:56 +0200 Subject: RFR(S): 8134607: Remove per-compiler performance counters In-Reply-To: <14408518-3FC6-4ECC-80FF-DEA48992C3F5@oracle.com> References: <56164774.2080504@oracle.com> <14408518-3FC6-4ECC-80FF-DEA48992C3F5@oracle.com> Message-ID: <5617D270.3060606@oracle.com> On 2015-10-09 02:32, Christian Thalinger wrote: >> On Oct 8, 2015, at 12:37 AM, Claes Redestad wrote: >> >> Hello hotspot-compiler.dev, >> >> anyone care to review this patch to remove per-compiler thread performance counters? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8134607 >> >> HotSpot webrev: http://cr.openjdk.java.net/~redestad/8134607/hotspot.01 >> JDK webrev: http://cr.openjdk.java.net/~redestad/8134607/jdk.01 > Looks good. When will the Java class be removed? Thanks! Assuming the entirety of sun.management is being encapsulated with Jigsaw (currently seems to be the case), I guesswe could follow-up with a removal of the deprecated methods and classes for JDK 10? http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-August/004433.html /Claes > >> CCC approved, no new test failures running JPRT against hs-comp. >> >> /Claes From vladimir.kozlov at oracle.com Fri Oct 9 14:53:40 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 9 Oct 2015 22:53:40 +0800 Subject: RFR: 8139259: aarch64: jtreg test TestLogSum segvs after 8132207 In-Reply-To: <8AF4C615-5E7A-425E-8883-5E7ECE2669E7@oracle.com> References: <1444389470.23861.23.camel@mint> <8AF4C615-5E7A-425E-8883-5E7ECE2669E7@oracle.com> Message-ID: <5617D4F4.8010809@oracle.com> Yes, we should avoid using platform specific flags (UseSSE or UseAVX) directly in shared (C2, for example) code. Thank you for fixing it, Ed. Reviewed with Roland's comment. Vladimir On 10/9/15 8:23 PM, Roland Westrelin wrote: > Hi Ed, > >> http://cr.openjdk.java.net/~enevill/8139259/webrev/ > > All 64 bit x86 cpus support sse2 so the new check in stubGenerator_x86_64.cpp is useless. Given in the interpreter and c1, we call the exp stub unconditionally, it didn?t really make sense that it was conditional on UseSSE in c2, anyway. Your library_call.cpp change looks good to me. I?ll sponsor it. > > Roland. > From roland.westrelin at oracle.com Fri Oct 9 14:59:54 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 9 Oct 2015 16:59:54 +0200 Subject: AARCH64: 8139041: Redundant DMB instructions (CORRECTED ) In-Reply-To: <561505E4.207@redhat.com> References: <561505E4.207@redhat.com> Message-ID: Hi Andrew, > There is a much simpler way: remove adjacent barriers in > MacroAssembler. Thanks to the way that the AArch64 ISA is designed, > barriers can be merged simply by ORing them together. Of course, this > technique works for C1 and C2, and it adds essentially nothing to the > compilation time. > > http://cr.openjdk.java.net/~aph/8139041/ > > One thing which may be controversial is that I've added a field to > CodeBuffer to keep track of barriers and labels. I had to do this > because when we're compiling there is (AFAICS) essentially nowhere > else to keep the state. Isn?t your new field a bit like: address insts_mark() const { return _insts.mark(); } void set_insts_mark() { _insts.set_mark(); } void clear_insts_mark() { _insts.clear_mark(); } which is used in very few locations AFAIK. Do you think you could reuse that one? Roland. From aph at redhat.com Fri Oct 9 15:37:22 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 9 Oct 2015 16:37:22 +0100 Subject: AARCH64: 8139041: Redundant DMB instructions (CORRECTED ) In-Reply-To: References: <561505E4.207@redhat.com> Message-ID: <5617DF32.4090508@redhat.com> Hi, On 10/09/2015 03:59 PM, Roland Westrelin wrote: >> There is a much simpler way: remove adjacent barriers in >> MacroAssembler. Thanks to the way that the AArch64 ISA is designed, >> barriers can be merged simply by ORing them together. Of course, this >> technique works for C1 and C2, and it adds essentially nothing to the >> compilation time. >> >> http://cr.openjdk.java.net/~aph/8139041/ >> >> One thing which may be controversial is that I've added a field to >> CodeBuffer to keep track of barriers and labels. I had to do this >> because when we're compiling there is (AFAICS) essentially nowhere >> else to keep the state. > > Isn?t your new field a bit like: > > address insts_mark() const { return _insts.mark(); } > void set_insts_mark() { _insts.set_mark(); } > void clear_insts_mark() { _insts.clear_mark(); } > > which is used in very few locations AFAIK. Do you think you could reuse that one? Yes, that's what it's based on. I guess that is possible in theory, but AbstractAssembler::InstructionMark() looks like this: InstructionMark(AbstractAssembler* assm) : _assm(assm) { assert(assm->inst_mark() == NULL, "overlapping instructions"); _assm->set_inst_mark(); } so any instruction which leaves the mark set will trigger an assertion failure the next time InstructionMark is used. I suppose that in extremis I could make every instruction which is not a memory barrier clear the mark, but ewww. :( I suppose I could define an AArch64-specific version of InstructionMark which does not have this assert, but I'm not sure I like that either. [An aside: we use InstructionMark unnecessarily in AArch64, and it's on my list of things to remove, but that's for another day.] Thanks for looking at this, Andrew. From martin.doerr at sap.com Fri Oct 9 16:17:37 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 9 Oct 2015 16:17:37 +0000 Subject: RFR: Elide more final field's write memory barrier with escape analysis result In-Reply-To: References: <5612A2C6.5080108@redhat.com> Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165672261165@DEWDFEMB19C.global.corp.sap> Hi, I basically like this change. Thanks for pointing me to it. But I don't like the extra code for PPC64. If the allocation does not escape globally it should be safe to elide the membar regardless of whether we wrote final or volatile fields. Please also note that PPC64_ONLY(...) NOT_PPC(...) is incorrect on PPC32. Actually, it's ugly that PPC64_ONLY was used here. Should better be (support_IRIW_for_not_multiple_copy_atomic_cpu && wrote_volatile()), but that's not the topic of this change. Best regards, Martin -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Roland Westrelin Sent: Donnerstag, 8. Oktober 2015 13:51 To: Hui Shi Cc: hotspot compiler; aarch64-port-dev at openjdk.java.net Subject: Re: RFR: Elide more final field's write memory barrier with escape analysis result > http://cr.openjdk.java.net/~hshi/8138956/webrev/ The code change looks good to me. The comments have a few typos and are a bit confusing. I'll tweak them before I push it. PPC folks, in case you missed it, parse1.cpp has a ppc related fix. Roland. From roland.westrelin at oracle.com Fri Oct 9 16:37:10 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 9 Oct 2015 18:37:10 +0200 Subject: AARCH64: 8139041: Redundant DMB instructions (CORRECTED ) In-Reply-To: <5617DF32.4090508@redhat.com> References: <561505E4.207@redhat.com> <5617DF32.4090508@redhat.com> Message-ID: >> Isn?t your new field a bit like: >> >> address insts_mark() const { return _insts.mark(); } >> void set_insts_mark() { _insts.set_mark(); } >> void clear_insts_mark() { _insts.clear_mark(); } >> >> which is used in very few locations AFAIK. Do you think you could reuse that one? > > Yes, that's what it's based on. I guess that is possible in theory, > but AbstractAssembler::InstructionMark() looks like this: > > InstructionMark(AbstractAssembler* assm) : _assm(assm) { > assert(assm->inst_mark() == NULL, "overlapping instructions"); > _assm->set_inst_mark(); > } > > so any instruction which leaves the mark set will trigger an assertion > failure the next time InstructionMark is used. I suppose that in > extremis I could make every instruction which is not a memory barrier > clear the mark, but ewww. :( > > I suppose I could define an AArch64-specific version of > InstructionMark which does not have this assert, but I'm not sure I > like that either. Ok. I don?t see a way around the shared code change so even if it?s not great, that?s ok with me. Let?s see what (if) others have (something) to say. Roland. From christian.thalinger at oracle.com Fri Oct 9 18:31:11 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 9 Oct 2015 08:31:11 -1000 Subject: Jitted array-length checks before entering a loop In-Reply-To: References: Message-ID: <780C7C66-6E88-4B38-8156-EA53525F863A@oracle.com> > On Sep 28, 2015, at 3:37 AM, Nassim Halli wrote: > > Hi guys, > > I have a question relative to some code generated by the C2 compiler. > > When I look at the assembly codes for this method: > > static void compiledMethod (Atype[] data) { > int n = data.length > for (int i = 0; i < n; ++i) > data[i].amethod(); > } > > I get the this assembly on Linux X86_64 before entering the loop (not OSR): > > # data is in rbx > mov 0xc(%rbx),%r9d > > # data.length is in r9d > test %r9d,%r9d > jle END_OF_LOOP > > test %r9d,%r9d > jbe BB0 > > mov %r9d,%r11d > dec %r11d > cmp %r9d,%r11d > jae BB0 > Did you leave out any assembly? Where is BB0? > > It seems to me the second and third check are useless and the corresponding branches are never taken. > Could you please tell me more about these checks, If and why are they required ? > > Thanks a lot. > > Nassim H. > > > Test conditions: > > java version "1.8.0_51" > Java(TM) SE Runtime Environment (build 1.8.0_51-b16) > Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode) > Default options. > Linux, Intel Sandy Bridge core i5-2000 -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Fri Oct 9 18:34:44 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 9 Oct 2015 08:34:44 -1000 Subject: RFR(S): 8138890: C1: Ambiguous operator delete In-Reply-To: <7C9B87B351A4BA4AA9EC95BB4181165672261012@DEWDFEMB19C.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB41811656722607B5@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672260AE1@DEWDFEMB19C.global.corp.sap> <56153267.7060401@oracle.com> <7C9B87B351A4BA4AA9EC95BB4181165672260BFB@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672261012@DEWDFEMB19C.global.corp.sap> Message-ID: > On Oct 9, 2015, at 12:03 AM, Doerr, Martin wrote: > > Hi, > > thanks for reviewing. > As requested by G?tz, I just removed the second ?private?. > The new webrev is here: > http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.02 Looks good. Can we add a comment saying that objects of this class should never be allocated on the heap or something? > > Best regards, > Martin > > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Mittwoch, 7. Oktober 2015 21:28 > To: Doerr, Martin > Cc: Mikael Gerdin; Christian Thalinger; hotspot compiler > Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete > > Hi Martin, > > as the new/delete operators in StackObj are private (I missed that before) they shouldn't be visible in LIRGenerator. So this is probably yet another xlC bug :( > On the other hand the new/delete operators in CompilationResourceObject are public and are inherited by LIRGenerator. So if we only want to generate LIRGenerator instances on the stack, your change is good, because it ensures this. And in that case we surely don't need an implementation. > > So thumbs up from me! > > Volker > > > On Wednesday, October 7, 2015, Doerr, Martin > wrote: > Hi Volker, > > the C1 classes we are talking about should never get instantiated by operator new. > A typical way to establish this is to make the new operators private. > > I don?t really care if the delete operators are public or private because if the new operator is never used, how can the delete operator get used? > It may be more beautiful to declare them as private as well. Only in the case G?tz has showed, some Compilers reject the private delete operators. > > Best regards, > Martin > > > From: Volker Simonis [mailto:volker.simonis at gmail.com <>] > Sent: Mittwoch, 7. Oktober 2015 17:57 > To: Mikael Gerdin > Cc: Doerr, Martin; Christian Thalinger; hotspot compiler > Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete > > Hi Martin, > > we have: > class LIRGenerator: public InstructionVisitor, public BlockClosure > > and: > > class BlockClosure: public CompilationResourceObj > > class CompilationResourceObj ALLOCATION_SUPER_CLASS_SPEC { > public: > void* operator new(size_t size) throw() { return Compilation::current()->arena()->Amalloc(size); } > void* operator new(size_t size, Arena* arena) throw() { > return arena->Amalloc(size); > } > void operator delete(void* p) {} // nothing to do > }; > > class InstructionVisitor: public StackObj > > class StackObj ALLOCATION_SUPER_CLASS_SPEC { > private: > void* operator new(size_t size) throw(); > void* operator new [](size_t size) throw(); > #ifdef __IBMCPP__ > public: > #endif > void operator delete(void* p); > void operator delete [](void* p); > > Now you declare new "new()" and "delete()" operators in the LIRGenerator which will actually hide the corresponding operators from the base classes. You also provide no implementation for the new operators in LIRGenerator. So which new/delete operators will be actually used for allocating new LIRGenerator instances? > > OK, wait. As far as I can see, LIRGenerator is never dynamically allocated, right? In that case it should be a StackObj and you could probably solve the problem with "using" directives (e.g. using StackObj::operator new, ...). Have you tried that? > > Regards, > Volker > > > On Wed, Oct 7, 2015 at 4:55 PM, Mikael Gerdin > wrote: > On 2015-10-07 16:17, Doerr, Martin wrote: > Hi, > > that?s a good question J > > I can only remember that there were problems with some old compilers. > > Anyway, xlC 12.1 can deal with the private delete operators. > > If that's the case, can we also get rid of the workaround in allocation.hpp? > > Thanks > /Mikael > > > Here?s the new webrev: > > http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.01 > > Best regards, > > Martin > > *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com <>] > *Sent:* Mittwoch, 7. Oktober 2015 03:32 > *To:* Doerr, Martin > *Cc:* hotspot compiler > *Subject:* Re: RFR(S): 8138890: C1: Ambiguous operator delete > > On Oct 6, 2015, at 3:56 AM, Doerr, Martin > >> wrote: > > Hi, > > xlC on AIX rejects to compile LIRGenerator and > RangeCheckEliminator::Verification due to ambiguous operator delete > which gets inherited from multiple base classes. > > This change is a prerequisite for our C1 on PPC64 contribution. > > Webrev is here: > > http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.00 > > Let me ask my question here: why do you need the delete methods to be > public on AIX? > > > > Please review this change. I need a sponsor, please. > > Best regards, > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Fri Oct 9 18:47:03 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 9 Oct 2015 08:47:03 -1000 Subject: AARCH64: 8139041: Redundant DMB instructions (CORRECTED ) In-Reply-To: <5617DF32.4090508@redhat.com> References: <561505E4.207@redhat.com> <5617DF32.4090508@redhat.com> Message-ID: > On Oct 9, 2015, at 5:37 AM, Andrew Haley wrote: > > Hi, > > On 10/09/2015 03:59 PM, Roland Westrelin wrote: > >>> There is a much simpler way: remove adjacent barriers in >>> MacroAssembler. Thanks to the way that the AArch64 ISA is designed, >>> barriers can be merged simply by ORing them together. Of course, this >>> technique works for C1 and C2, and it adds essentially nothing to the >>> compilation time. >>> >>> http://cr.openjdk.java.net/~aph/8139041/ >>> >>> One thing which may be controversial is that I've added a field to >>> CodeBuffer to keep track of barriers and labels. I had to do this >>> because when we're compiling there is (AFAICS) essentially nowhere >>> else to keep the state. I don?t think it matters to have an additional field in CodeBuffer. It?s a temporary data structure and we use much more memory for graphs. I would even go that far and questioning putting it under #ifdef AARCH64. >> >> Isn?t your new field a bit like: >> >> address insts_mark() const { return _insts.mark(); } >> void set_insts_mark() { _insts.set_mark(); } >> void clear_insts_mark() { _insts.clear_mark(); } >> >> which is used in very few locations AFAIK. Do you think you could reuse that one? > > Yes, that's what it's based on. I guess that is possible in theory, > but AbstractAssembler::InstructionMark() looks like this: > > InstructionMark(AbstractAssembler* assm) : _assm(assm) { > assert(assm->inst_mark() == NULL, "overlapping instructions"); > _assm->set_inst_mark(); > } > > so any instruction which leaves the mark set will trigger an assertion > failure the next time InstructionMark is used. I suppose that in > extremis I could make every instruction which is not a memory barrier > clear the mark, but ewww. :( > > I suppose I could define an AArch64-specific version of > InstructionMark which does not have this assert, but I'm not sure I > like that either. > > [An aside: we use InstructionMark unnecessarily in AArch64, and it's > on my list of things to remove, but that's for another day.] > > Thanks for looking at this, > > Andrew. From vitalyd at gmail.com Fri Oct 9 18:51:40 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 9 Oct 2015 14:51:40 -0400 Subject: Jitted array-length checks before entering a loop In-Reply-To: <780C7C66-6E88-4B38-8156-EA53525F863A@oracle.com> References: <780C7C66-6E88-4B38-8156-EA53525F863A@oracle.com> Message-ID: Chris, Below is a sample dump (array is in %rsi). You can see the 2 tests in question that jump to deopt blobs (I presume). If I change the code to always pass a zero length array (the below assembly is for non-empty array 100% of the time), the code generation changes to favor that case, and these tests are not present. 0x00007f63476c7da0: mov %eax,-0x14000(%rsp) 0x00007f63476c7da7: push %rbp 0x00007f63476c7da8: sub $0x10,%rsp ;*synchronization entry 0x00007f63476c7dac: mov 0xc(%rsi),%r10d ;*arraylength ; implicit exception: dispatches to 0x00007f63476c7e11 0x00007f63476c7db0: test %r10d,%r10d 0x00007f63476c7db3: jle 0x00007f63476c7de2 ;*if_icmplt 0x00007f63476c7db5: test %r10d,%r10d 0x00007f63476c7db8: jbe 0x00007f63476c7dfd 0x00007f63476c7dba: mov %r10d,%r8d 0x00007f63476c7dbd: dec %r8d 0x00007f63476c7dc0: cmp %r10d,%r8d 0x00007f63476c7dc3: jae 0x00007f63476c7dfd 0x00007f63476c7dc5: xor %r11d,%r11d 0x00007f63476c7dc8: nopl 0x0(%rax,%rax,1) ;*aload_0 0x00007f63476c7dd0: mov 0x10(%rsi,%r11,4),%r8d ;*aaload 0x00007f63476c7dd5: test %r8d,%r8d 0x00007f63476c7dd8: je 0x00007f63476c7dee ;*invokevirtual amethod 0x00007f63476c7dda: inc %r11d ;*iinc 0x00007f63476c7ddd: cmp %r10d,%r11d 0x00007f63476c7de0: jl 0x00007f63476c7dd0 ;*return 0x00007f63476c7de2: add $0x10,%rsp 0x00007f63476c7de6: pop %rbp 0x00007f63476c7de7: test %eax,0x5cd3213(%rip) # 0x00007f634d39b000 ; {poll_return} 0x00007f63476c7ded: retq 0x00007f63476c7dee: mov $0xfffffff6,%esi 0x00007f63476c7df3: callq 0x00007f6347684320 ; OopMap{off=88} ;*invokevirtual amethod ; {runtime_call} 0x00007f63476c7df8: callq 0x00007f634c17f570 ;*invokevirtual amethod ; {runtime_call} 0x00007f63476c7dfd: mov %rsi,%rbp 0x00007f63476c7e00: mov $0xffffff86,%esi 0x00007f63476c7e05: xchg %ax,%ax 0x00007f63476c7e07: callq 0x00007f6347684320 ; OopMap{rbp=Oop off=108} ;*aload_0 ; {runtime_call} 0x00007f63476c7e0c: callq 0x00007f634c17f570 ;*aload_0 ; {runtime_call} 0x00007f63476c7e11: mov $0xfffffff6,%esi 0x00007f63476c7e16: nop 0x00007f63476c7e17: callq 0x00007f6347684320 ; OopMap{off=124} ;*arraylength ; {runtime_call} 0x00007f63476c7e1c: callq 0x00007f634c17f570 ;*arraylength ; {runtime_call} On Fri, Oct 9, 2015 at 2:31 PM, Christian Thalinger < christian.thalinger at oracle.com> wrote: > > On Sep 28, 2015, at 3:37 AM, Nassim Halli wrote: > > Hi guys, > > I have a question relative to some code generated by the C2 compiler. > > When I look at the assembly codes for this method: > > static void compiledMethod (Atype[] data) { > int n = data.length > for (int i = 0; i < n; ++i) > data[i].amethod(); > } > > I get the this assembly on Linux X86_64 before entering the loop (not OSR): > > # data is in rbx > mov 0xc(%rbx),%r9d > > # data.length is in r9d > test %r9d,%r9d > jle END_OF_LOOP > > test %r9d,%r9d > jbe BB0 > > mov %r9d,%r11d > dec %r11d > cmp %r9d,%r11d > jae BB0 > > > Did you leave out any assembly? Where is BB0? > > > It seems to me the second and third check are useless and the > corresponding branches are never taken. > Could you please tell me more about these checks, If and why are they > required ? > > Thanks a lot. > > Nassim H. > > > *Test conditions:* > > java version "1.8.0_51" > Java(TM) SE Runtime Environment (build 1.8.0_51-b16) > Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode) > Default options. > Linux, Intel Sandy Bridge core i5-2000 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Fri Oct 9 19:08:47 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 9 Oct 2015 19:08:47 +0000 Subject: RFR(S): 8138890: C1: Ambiguous operator delete In-Reply-To: References: <7C9B87B351A4BA4AA9EC95BB41811656722607B5@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672260AE1@DEWDFEMB19C.global.corp.sap> <56153267.7060401@oracle.com> <7C9B87B351A4BA4AA9EC95BB4181165672260BFB@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672261012@DEWDFEMB19C.global.corp.sap> Message-ID: <7C9B87B351A4BA4AA9EC95BB41811656722611F8@DEWDFEMB19C.global.corp.sap> Hi Christian, I have just added comments. We can also get rid of the multi-inheritance in RanceCheckEliminator::Verification. The new webrev is: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.03 Best regards, Martin From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Freitag, 9. Oktober 2015 20:35 To: Doerr, Martin Cc: Volker Simonis; Lindenmaier, Goetz; Mikael Gerdin; hotspot compiler Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete On Oct 9, 2015, at 12:03 AM, Doerr, Martin > wrote: Hi, thanks for reviewing. As requested by G?tz, I just removed the second ?private?. The new webrev is here: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.02 Looks good. Can we add a comment saying that objects of this class should never be allocated on the heap or something? Best regards, Martin From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Mittwoch, 7. Oktober 2015 21:28 To: Doerr, Martin Cc: Mikael Gerdin; Christian Thalinger; hotspot compiler Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete Hi Martin, as the new/delete operators in StackObj are private (I missed that before) they shouldn't be visible in LIRGenerator. So this is probably yet another xlC bug :( On the other hand the new/delete operators in CompilationResourceObject are public and are inherited by LIRGenerator. So if we only want to generate LIRGenerator instances on the stack, your change is good, because it ensures this. And in that case we surely don't need an implementation. So thumbs up from me! Volker On Wednesday, October 7, 2015, Doerr, Martin > wrote: Hi Volker, the C1 classes we are talking about should never get instantiated by operator new. A typical way to establish this is to make the new operators private. I don?t really care if the delete operators are public or private because if the new operator is never used, how can the delete operator get used? It may be more beautiful to declare them as private as well. Only in the case G?tz has showed, some Compilers reject the private delete operators. Best regards, Martin From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Mittwoch, 7. Oktober 2015 17:57 To: Mikael Gerdin Cc: Doerr, Martin; Christian Thalinger; hotspot compiler Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete Hi Martin, we have: class LIRGenerator: public InstructionVisitor, public BlockClosure and: class BlockClosure: public CompilationResourceObj class CompilationResourceObj ALLOCATION_SUPER_CLASS_SPEC { public: void* operator new(size_t size) throw() { return Compilation::current()->arena()->Amalloc(size); } void* operator new(size_t size, Arena* arena) throw() { return arena->Amalloc(size); } void operator delete(void* p) {} // nothing to do }; class InstructionVisitor: public StackObj class StackObj ALLOCATION_SUPER_CLASS_SPEC { private: void* operator new(size_t size) throw(); void* operator new [](size_t size) throw(); #ifdef __IBMCPP__ public: #endif void operator delete(void* p); void operator delete [](void* p); Now you declare new "new()" and "delete()" operators in the LIRGenerator which will actually hide the corresponding operators from the base classes. You also provide no implementation for the new operators in LIRGenerator. So which new/delete operators will be actually used for allocating new LIRGenerator instances? OK, wait. As far as I can see, LIRGenerator is never dynamically allocated, right? In that case it should be a StackObj and you could probably solve the problem with "using" directives (e.g. using StackObj::operator new, ...). Have you tried that? Regards, Volker On Wed, Oct 7, 2015 at 4:55 PM, Mikael Gerdin > wrote: On 2015-10-07 16:17, Doerr, Martin wrote: Hi, that?s a good question J I can only remember that there were problems with some old compilers. Anyway, xlC 12.1 can deal with the private delete operators. If that's the case, can we also get rid of the workaround in allocation.hpp? Thanks /Mikael Here?s the new webrev: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.01 Best regards, Martin *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com] *Sent:* Mittwoch, 7. Oktober 2015 03:32 *To:* Doerr, Martin *Cc:* hotspot compiler *Subject:* Re: RFR(S): 8138890: C1: Ambiguous operator delete On Oct 6, 2015, at 3:56 AM, Doerr, Martin >> wrote: Hi, xlC on AIX rejects to compile LIRGenerator and RangeCheckEliminator::Verification due to ambiguous operator delete which gets inherited from multiple base classes. This change is a prerequisite for our C1 on PPC64 contribution. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.00 Let me ask my question here: why do you need the delete methods to be public on AIX? Please review this change. I need a sponsor, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalyd at gmail.com Fri Oct 9 20:14:58 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 9 Oct 2015 16:14:58 -0400 Subject: Jitted array-length checks before entering a loop In-Reply-To: References: <780C7C66-6E88-4B38-8156-EA53525F863A@oracle.com> Message-ID: So basically, the deopt blobs are unreachable -- not sure if that's intentional or not. Perhaps it's intentional in that deopt'ing in this case is a waste of time (the simple exit is just fine), but the code for it is left behind. On Fri, Oct 9, 2015 at 2:51 PM, Vitaly Davidovich wrote: > Chris, > > Below is a sample dump (array is in %rsi). You can see the 2 tests in > question that jump to deopt blobs (I presume). If I change the code to > always pass a zero length array (the below assembly is for non-empty array > 100% of the time), the code generation changes to favor that case, and > these tests are not present. > > 0x00007f63476c7da0: mov %eax,-0x14000(%rsp) > 0x00007f63476c7da7: push %rbp > 0x00007f63476c7da8: sub $0x10,%rsp ;*synchronization entry > > 0x00007f63476c7dac: mov 0xc(%rsi),%r10d ;*arraylength > > ; implicit exception: > dispatches to 0x00007f63476c7e11 > 0x00007f63476c7db0: test %r10d,%r10d > 0x00007f63476c7db3: jle 0x00007f63476c7de2 ;*if_icmplt > > 0x00007f63476c7db5: test %r10d,%r10d > 0x00007f63476c7db8: jbe 0x00007f63476c7dfd > 0x00007f63476c7dba: mov %r10d,%r8d > 0x00007f63476c7dbd: dec %r8d > 0x00007f63476c7dc0: cmp %r10d,%r8d > 0x00007f63476c7dc3: jae 0x00007f63476c7dfd > 0x00007f63476c7dc5: xor %r11d,%r11d > 0x00007f63476c7dc8: nopl 0x0(%rax,%rax,1) ;*aload_0 > > 0x00007f63476c7dd0: mov 0x10(%rsi,%r11,4),%r8d ;*aaload > > 0x00007f63476c7dd5: test %r8d,%r8d > 0x00007f63476c7dd8: je 0x00007f63476c7dee ;*invokevirtual amethod > > 0x00007f63476c7dda: inc %r11d ;*iinc > > 0x00007f63476c7ddd: cmp %r10d,%r11d > 0x00007f63476c7de0: jl 0x00007f63476c7dd0 ;*return > > 0x00007f63476c7de2: add $0x10,%rsp > 0x00007f63476c7de6: pop %rbp > 0x00007f63476c7de7: test %eax,0x5cd3213(%rip) # > 0x00007f634d39b000 > ; {poll_return} > 0x00007f63476c7ded: retq > 0x00007f63476c7dee: mov $0xfffffff6,%esi > 0x00007f63476c7df3: callq 0x00007f6347684320 ; OopMap{off=88} > ;*invokevirtual amethod > ; {runtime_call} > 0x00007f63476c7df8: callq 0x00007f634c17f570 ;*invokevirtual amethod > ; {runtime_call} > 0x00007f63476c7dfd: mov %rsi,%rbp > 0x00007f63476c7e00: mov $0xffffff86,%esi > 0x00007f63476c7e05: xchg %ax,%ax > 0x00007f63476c7e07: callq 0x00007f6347684320 ; OopMap{rbp=Oop off=108} > ;*aload_0 > ; {runtime_call} > 0x00007f63476c7e0c: callq 0x00007f634c17f570 ;*aload_0 > ; {runtime_call} > 0x00007f63476c7e11: mov $0xfffffff6,%esi > 0x00007f63476c7e16: nop > 0x00007f63476c7e17: callq 0x00007f6347684320 ; OopMap{off=124} > ;*arraylength > ; {runtime_call} > 0x00007f63476c7e1c: callq 0x00007f634c17f570 ;*arraylength > ; {runtime_call} > > > On Fri, Oct 9, 2015 at 2:31 PM, Christian Thalinger < > christian.thalinger at oracle.com> wrote: > >> >> On Sep 28, 2015, at 3:37 AM, Nassim Halli wrote: >> >> Hi guys, >> >> I have a question relative to some code generated by the C2 compiler. >> >> When I look at the assembly codes for this method: >> >> static void compiledMethod (Atype[] data) { >> int n = data.length >> for (int i = 0; i < n; ++i) >> data[i].amethod(); >> } >> >> I get the this assembly on Linux X86_64 before entering the loop (not >> OSR): >> >> # data is in rbx >> mov 0xc(%rbx),%r9d >> >> # data.length is in r9d >> test %r9d,%r9d >> jle END_OF_LOOP >> >> test %r9d,%r9d >> jbe BB0 >> >> mov %r9d,%r11d >> dec %r11d >> cmp %r9d,%r11d >> jae BB0 >> >> >> Did you leave out any assembly? Where is BB0? >> >> >> It seems to me the second and third check are useless and the >> corresponding branches are never taken. >> Could you please tell me more about these checks, If and why are they >> required ? >> >> Thanks a lot. >> >> Nassim H. >> >> >> *Test conditions:* >> >> java version "1.8.0_51" >> Java(TM) SE Runtime Environment (build 1.8.0_51-b16) >> Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode) >> Default options. >> Linux, Intel Sandy Bridge core i5-2000 >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Fri Oct 9 21:33:55 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 9 Oct 2015 11:33:55 -1000 Subject: [9] RFR(M): 8078554: Compiler: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <56169147.80901@oracle.com> References: <560BB4F6.3050703@oracle.com> <4502D8F6-B256-4222-B1D3-92ED5C100B6E@oracle.com> <5613B44F.4090007@oracle.com> <5615204C.8080202@oracle.com> <56165C6C.70705@oracle.com> <56167973.9020002@oracle.com> <56169147.80901@oracle.com> Message-ID: <4D6D08C8-A649-4D91-938C-6BA6E0F214AD@oracle.com> After JEP 243 was integrated we fail one of the new tests with: intx TypeProfileWidth=8 is outside the allowed range [ 0 ... 4 ] The reason is that JVMCI can support more than 4 type profiles. Currently the default is 8: if (UseJVMCICompiler) { if (FLAG_IS_DEFAULT(TypeProfileWidth)) { TypeProfileWidth = 8; } } We should increase the range. Not sure what a good number would be, though. Maybe 100 just to be safe? > On Oct 8, 2015, at 5:52 AM, Zolt?n Maj? wrote: > > Thank you, Tobias, for the review! > > Best regards, > > > Zolt?n > > On 10/08/2015 04:10 PM, Tobias Hartmann wrote: >> Hi Zolt?n, >> >> On 08.10.2015 14:07, Zolt?n Maj? wrote: >>> Hi Tobias, >>> >>> >>> thank you for the feedback! >>> >>> On 10/07/2015 03:38 PM, Tobias Hartmann wrote: >>>> Hi Zoltan, >>>> >>>> I had a look at your changes and just spotted some minor things: >>>> >>>> globals_sparc.hpp: >>>> - I think there is a '\' missing in line 119 >>> thank you for spotting that! >>> >>>> globals_x86.hpp: >>>> - Isn't this also a compiler flag we should add range checks for? >>>> 136 product(uintx, RTMRetryCount, 5, >>> JEP 245 considers it as a runtime flag and JDK-8078556 "Runtime: implement ranges..." [1] will take care of it. But you are right, that flag could be also considered a compiler flag. >> Okay, thanks for pointing that out. >> >>>> commandLineFlagConstraintsCompiler.cpp: >>>> - I think there is a "rule" that the include statements should be in alphabetical order >>> Yes, I think there is such a rule (or convention). I diverged from the rule because the include of code/relocInfo.hpp depends on 'os', 'vm_page_size', and 'Metadata'. Therefore, "oops/metadata.hpp" and "runtime/os.hpp" must be included before relocInfo.hpp (otherwise the Solaris compiler complains). The remaining includes are ordered alphabetically. >> Okay, makes sense. >> >>>> - the indentation is wrong here: >>>> 179 return Flag::VIOLATES_CONSTRAINT; >>> I updated the indentation. >>> >>> Here is the updated webrev: >>> http://cr.openjdk.java.net/~zmajo/8078554/webrev.02/ >>> >>> I re-tested the updated webrev with JPRT (testset hotspot), all tests pass. >> Looks good to me (not a Reviewer). >> >> Best, >> Tobias >> >> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8078556 >>>> Best, >>>> Tobias >>> >>>> On 06.10.2015 13:45, Zolt?n Maj? wrote: >>>>> Hi Roland, >>>>> >>>>> >>>>> thank you for the feedback! >>>>> >>>>> On 10/02/2015 03:55 PM, Roland Westrelin wrote: >>>>>> Hi Zoltan, >>>>>> >>>>>>> Webrev:http://cr.openjdk.java.net/~zmajo/8078554/ >>>>>> c2_globals.hpp >>>>>> >>>>>> That one is not correct: >>>>>> 461 product(intx, MaxNodeLimit, 80000, \ >>>>>> 462 "Maximum number of nodes") \ >>>>>> 463 range(1000, 80000) \ >>>>>> >>>>>> I think the upper bound should be max_juint >>>>> You are right that the limit of 80'000 is too conservative. But max_j*u*int as an upper bound would cause an overflow when parsing the flag's value, because on 32-bit machines intx is a 32-bit signed integer. >>>>> >>>>> Using max_jint instead of max_j*u*int as an upper bound would not cause an overflow at parse time. However, in Parse::do_call() the maximum node limit is increased by 3 times for jsr292 users >>>>> >>>>> C->set_max_node_limit(3*MaxNodeLimit); >>>>> >>>>> If MaxNodeLimit == max_jint, this expression will overflow, I think. >>>>> >>>>> So I set the limit to (max_jint / 3) in the updated webrev. >>>>> >>>>> If we would set MaxNodeLimit to max_j*u*int / 3 (instead of max_jint / 3), the expression 3 * MaxNodeLimit would overflow as well. Changing the type of the flag from intx to uintx could let use use max_j*u*int / 3 as an upper bound, but that is most likely not worth the effort. >>>>> >>>>>> 699 product(intx, LiveNodeCountInliningCutoff, 40000, \ >>>>>> 700 "max number of live nodes in a method") \ >>>>>> 701 range(0, max_juint / 8) \ >>>>>> >>>>>> Out of curiosity why max_juint / 8 (not that it makes much of a difference)? >>>>> In Compile::inline_incrementally, the 80% of LiveNodeCountInliningCutoff is computed the following way: >>>>> >>>>> if (low_live_nodes < (uint)LiveNodeCountInliningCutoff * 8 / 10) { >>>>> >>>>> If LiveNodeCountInliningCutoff == max_juint, we'd have an overflow because of the multiplication by 8. >>>>> >>>>>> arguments.cpp >>>>>> >>>>>> 1099 Tier3InvokeNotifyFreqLog = 0; >>>>>> 1100 Tier4InvocationThreshold = 0; >>>>>> >>>>>> Why that change? >>>>> I proposed that change because I misread the code. I reverted that change and also changed the range of all Tier*FreqLog flags from range(1, 30) to range(0, 30). >>>>> >>>>>> globals.hp >>>>>> >>>>>> 2870 product_pd(uintx, TypeProfileLevel, \ >>>>>> 2871 "=XYZ, with Z: Type profiling of arguments at call; " \ >>>>>> 2872 "Y: Type profiling of return value at call; " \ >>>>>> 2873 "X: Type profiling of parameters to methods; " \ >>>>>> 2874 "X, Y and Z in 0=off ; 1=jsr292 only; 2=all methods") \ >>>>>> 2875 range(0, 222) >>>>>> >>>>>> Legal values are 0, 1, 2, 10, 11, 12, 100, 101, 102, 110, 111, 112 etc. >>>>>> >>>>>> 70 is not for instance. So range(0, 222) is incorrect. >>>>> I agree. I removed the range check and implemented a constraint function instead (TypeProfileLevelConstraintFunc). >>>>> >>>>>> 2877 product(intx, TypeProfileArgsLimit, 2, \ >>>>>> 2878 "max number of call arguments to consider for type profiling") \ >>>>>> 2879 range(0, 16) \ >>>>>> >>>>>> 2880 \ >>>>>> 2881 product(intx, TypeProfileParmsLimit, 2, \ >>>>>> 2882 "max number of incoming parameters to consider for type profiling"\ >>>>>> 2883 ", -1 for all") \ >>>>>> 2884 range(-1, 64) >>>>>> >>>>>> Why 16 and 64? >>>>> These are the largest values that work on all platforms we support. >>>>> >>>>> Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8078554/webrev.01/ >>>>> >>>>> I repeated the testing with JPRT. I also executed the currently disabled TestOptionsWithRanges.java test on all platforms we support. All tests pass. >>>>> >>>>> Thank you and best regards, >>>>> >>>>> >>>>> Zoltan >>>>> >>>>>> Roland. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Fri Oct 9 21:53:10 2015 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 9 Oct 2015 14:53:10 -0700 Subject: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. In-Reply-To: <39F83597C33E5F408096702907E6C45005878CBF@ORSMSX104.amr.corp.intel.com> References: <39F83597C33E5F408096702907E6C45005878CBF@ORSMSX104.amr.corp.intel.com> Message-ID: <687A231C-FC93-4068-9223-41D6A642B6D8@oracle.com> Here the webrev: http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ igor > On Oct 9, 2015, at 1:15 PM, Civlin, Jan wrote: > > Igor, > > Please create RFR and upload this patch. You may need to rename ancnav.js.remove_this_extention back to ancnav.js (I have to rename it for passing the mail server filters). > > Description: > SuperWord enhancement to support vector conditional move (CMovVD) on Intel AVX cpu. > The SuperWord optimization bails out on counted loops that contain any conditional statement other than the loop exit, and this prevents vectorization of many compute bound loops. > The proposed enhancement enables generation of CMovD on demand (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD ) in SuperWord optimization. > > The performance gain observed on a simplified Monte Carlo Option Calculation was up to 2x speed-up. > > Thank you, > > Jan. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.civlin at intel.com Fri Oct 9 21:57:30 2015 From: jan.civlin at intel.com (Civlin, Jan) Date: Fri, 9 Oct 2015 21:57:30 +0000 Subject: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. In-Reply-To: <687A231C-FC93-4068-9223-41D6A642B6D8@oracle.com> References: <39F83597C33E5F408096702907E6C45005878CBF@ORSMSX104.amr.corp.intel.com> <687A231C-FC93-4068-9223-41D6A642B6D8@oracle.com> Message-ID: <39F83597C33E5F408096702907E6C45005878D6E@ORSMSX104.amr.corp.intel.com> Thank you, Igor. What is the RFR for this? From: Igor Veresov [mailto:igor.veresov at oracle.com] Sent: Friday, October 9, 2015 2:53 PM To: Civlin, Jan Cc: hotspot compiler; Vladimir Kozlov Subject: Re: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. Here the webrev: http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ igor On Oct 9, 2015, at 1:15 PM, Civlin, Jan > wrote: Igor, Please create RFR and upload this patch. You may need to rename ancnav.js.remove_this_extention back to ancnav.js (I have to rename it for passing the mail server filters). Description: SuperWord enhancement to support vector conditional move (CMovVD) on Intel AVX cpu. The SuperWord optimization bails out on counted loops that contain any conditional statement other than the loop exit, and this prevents vectorization of many compute bound loops. The proposed enhancement enables generation of CMovD on demand (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD ) in SuperWord optimization. The performance gain observed on a simplified Monte Carlo Option Calculation was up to 2x speed-up. Thank you, Jan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Fri Oct 9 22:22:09 2015 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 9 Oct 2015 15:22:09 -0700 Subject: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. In-Reply-To: <39F83597C33E5F408096702907E6C45005878D6E@ORSMSX104.amr.corp.intel.com> References: <39F83597C33E5F408096702907E6C45005878CBF@ORSMSX104.amr.corp.intel.com> <687A231C-FC93-4068-9223-41D6A642B6D8@oracle.com> <39F83597C33E5F408096702907E6C45005878D6E@ORSMSX104.amr.corp.intel.com> Message-ID: Here it is: https://bugs.openjdk.java.net/browse/JDK-8139340 igor > On Oct 9, 2015, at 2:57 PM, Civlin, Jan wrote: > > Thank you, Igor. > What is the RFR for this? > > From: Igor Veresov [mailto:igor.veresov at oracle.com] > Sent: Friday, October 9, 2015 2:53 PM > To: Civlin, Jan > Cc: hotspot compiler; Vladimir Kozlov > Subject: Re: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. > > Here the webrev: http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ > > igor > > On Oct 9, 2015, at 1:15 PM, Civlin, Jan > wrote: > > Igor, > > Please create RFR and upload this patch. You may need to rename ancnav.js.remove_this_extention back to ancnav.js (I have to rename it for passing the mail server filters). > > Description: > SuperWord enhancement to support vector conditional move (CMovVD) on Intel AVX cpu. > The SuperWord optimization bails out on counted loops that contain any conditional statement other than the loop exit, and this prevents vectorization of many compute bound loops. > The proposed enhancement enables generation of CMovD on demand (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD ) in SuperWord optimization. > > The performance gain observed on a simplified Monte Carlo Option Calculation was up to 2x speed-up. > > Thank you, > > Jan. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Fri Oct 9 22:32:24 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 9 Oct 2015 12:32:24 -1000 Subject: RFR(S): 8138890: C1: Ambiguous operator delete In-Reply-To: <7C9B87B351A4BA4AA9EC95BB41811656722611F8@DEWDFEMB19C.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB41811656722607B5@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672260AE1@DEWDFEMB19C.global.corp.sap> <56153267.7060401@oracle.com> <7C9B87B351A4BA4AA9EC95BB4181165672260BFB@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672261012@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB41811656722611F8@DEWDFEMB19C.global.corp.sap> Message-ID: <3D04808B-DB7A-4ECF-A3BF-42D5A20E2419@oracle.com> > On Oct 9, 2015, at 9:08 AM, Doerr, Martin wrote: > > Hi Christian, > > I have just added comments. We can also get rid of the multi-inheritance in RanceCheckEliminator::Verification. Hmm. Why did we have it this way (not using the macro and such)? - class Verification : public _ValueObj /*VALUE_OBJ_CLASS_SPEC*/, public BlockClosure { + class Verification : public BlockClosure { > > The new webrev is: > http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.03 > Best regards, > Martin > > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Freitag, 9. Oktober 2015 20:35 > To: Doerr, Martin > Cc: Volker Simonis; Lindenmaier, Goetz; Mikael Gerdin; hotspot compiler > Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete > > > On Oct 9, 2015, at 12:03 AM, Doerr, Martin > wrote: > > Hi, > > thanks for reviewing. > As requested by G?tz, I just removed the second ?private?. > The new webrev is here: > http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.02 > > Looks good. Can we add a comment saying that objects of this class should never be allocated on the heap or something? > > > > Best regards, > Martin > > From: Volker Simonis [mailto:volker.simonis at gmail.com ] > Sent: Mittwoch, 7. Oktober 2015 21:28 > To: Doerr, Martin > Cc: Mikael Gerdin; Christian Thalinger; hotspot compiler > Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete > > Hi Martin, > > as the new/delete operators in StackObj are private (I missed that before) they shouldn't be visible in LIRGenerator. So this is probably yet another xlC bug :( > On the other hand the new/delete operators in CompilationResourceObject are public and are inherited by LIRGenerator. So if we only want to generate LIRGenerator instances on the stack, your change is good, because it ensures this. And in that case we surely don't need an implementation. > > So thumbs up from me! > > Volker > > > On Wednesday, October 7, 2015, Doerr, Martin > wrote: > Hi Volker, > > the C1 classes we are talking about should never get instantiated by operator new. > A typical way to establish this is to make the new operators private. > > I don?t really care if the delete operators are public or private because if the new operator is never used, how can the delete operator get used? > It may be more beautiful to declare them as private as well. Only in the case G?tz has showed, some Compilers reject the private delete operators. > > Best regards, > Martin > > > From: Volker Simonis [mailto:volker.simonis at gmail.com ] > Sent: Mittwoch, 7. Oktober 2015 17:57 > To: Mikael Gerdin > Cc: Doerr, Martin; Christian Thalinger; hotspot compiler > Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete > > Hi Martin, > > we have: > class LIRGenerator: public InstructionVisitor, public BlockClosure > > and: > > class BlockClosure: public CompilationResourceObj > > class CompilationResourceObj ALLOCATION_SUPER_CLASS_SPEC { > public: > void* operator new(size_t size) throw() { return Compilation::current()->arena()->Amalloc(size); } > void* operator new(size_t size, Arena* arena) throw() { > return arena->Amalloc(size); > } > void operator delete(void* p) {} // nothing to do > }; > > class InstructionVisitor: public StackObj > > class StackObj ALLOCATION_SUPER_CLASS_SPEC { > private: > void* operator new(size_t size) throw(); > void* operator new [](size_t size) throw(); > #ifdef __IBMCPP__ > public: > #endif > void operator delete(void* p); > void operator delete [](void* p); > > Now you declare new "new()" and "delete()" operators in the LIRGenerator which will actually hide the corresponding operators from the base classes. You also provide no implementation for the new operators in LIRGenerator. So which new/delete operators will be actually used for allocating new LIRGenerator instances? > > OK, wait. As far as I can see, LIRGenerator is never dynamically allocated, right? In that case it should be a StackObj and you could probably solve the problem with "using" directives (e.g. using StackObj::operator new, ...). Have you tried that? > > Regards, > Volker > > > On Wed, Oct 7, 2015 at 4:55 PM, Mikael Gerdin > wrote: > On 2015-10-07 16:17, Doerr, Martin wrote: > Hi, > > that?s a good question J > > I can only remember that there were problems with some old compilers. > > Anyway, xlC 12.1 can deal with the private delete operators. > > If that's the case, can we also get rid of the workaround in allocation.hpp? > > Thanks > /Mikael > > > Here?s the new webrev: > > http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.01 > > Best regards, > > Martin > > *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com ] > *Sent:* Mittwoch, 7. Oktober 2015 03:32 > *To:* Doerr, Martin > *Cc:* hotspot compiler > *Subject:* Re: RFR(S): 8138890: C1: Ambiguous operator delete > > On Oct 6, 2015, at 3:56 AM, Doerr, Martin ? ? >> wrote: > > Hi, > > xlC on AIX rejects to compile LIRGenerator and > RangeCheckEliminator::Verification due to ambiguous operator delete > which gets inherited from multiple base classes. > > This change is a prerequisite for our C1 on PPC64 contribution. > > Webrev is here: > > http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.00 > > Let me ask my question here: why do you need the delete methods to be > public on AIX? > > > > Please review this change. I need a sponsor, please. > > Best regards, > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.civlin at intel.com Fri Oct 9 23:04:35 2015 From: jan.civlin at intel.com (Civlin, Jan) Date: Fri, 9 Oct 2015 23:04:35 +0000 Subject: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. Message-ID: <39F83597C33E5F408096702907E6C45005878DDA@ORSMSX104.amr.corp.intel.com> Please review this patch. Hi All, We would like to contribute the SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. The contribution Bug ID: 8139340. Please review this patch: Bug-id: https://bugs.openjdk.java.net/browse/JDK-8139340 webrev: http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ Description: SuperWord enhancement to support vector conditional move (CMovVD) on Intel AVX cpu. The SuperWord optimization bails out on counted loops that contain any conditional statement other than the loop exit, and this prevents vectorization of many compute bound loops. The proposed enhancement enables generation of CMovD on demand (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD ) in SuperWord optimization. The performance gain observed on a simplified Monte Carlo Option Calculation was up to 2x speed-up. Thank you, Jan. From: Igor Veresov [mailto:igor.veresov at oracle.com] Sent: Friday, October 9, 2015 3:22 PM To: Civlin, Jan Cc: hotspot compiler; Vladimir Kozlov Subject: Re: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. Here it is: https://bugs.openjdk.java.net/browse/JDK-8139340 igor On Oct 9, 2015, at 2:57 PM, Civlin, Jan > wrote: Thank you, Igor. What is the RFR for this? From: Igor Veresov [mailto:igor.veresov at oracle.com] Sent: Friday, October 9, 2015 2:53 PM To: Civlin, Jan Cc: hotspot compiler; Vladimir Kozlov Subject: Re: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. Here the webrev: http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ igor On Oct 9, 2015, at 1:15 PM, Civlin, Jan > wrote: Igor, Please create RFR and upload this patch. You may need to rename ancnav.js.remove_this_extention back to ancnav.js (I have to rename it for passing the mail server filters). Description: SuperWord enhancement to support vector conditional move (CMovVD) on Intel AVX cpu. The SuperWord optimization bails out on counted loops that contain any conditional statement other than the loop exit, and this prevents vectorization of many compute bound loops. The proposed enhancement enables generation of CMovD on demand (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD ) in SuperWord optimization. The performance gain observed on a simplified Monte Carlo Option Calculation was up to 2x speed-up. Thank you, Jan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Sat Oct 10 01:00:17 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 10 Oct 2015 09:00:17 +0800 Subject: AARCH64: 8139041: Redundant DMB instructions (CORRECTED ) In-Reply-To: References: <561505E4.207@redhat.com> <5617DF32.4090508@redhat.com> Message-ID: <56186321.6010505@oracle.com> On 10/10/15 2:47 AM, Christian Thalinger wrote: > >> On Oct 9, 2015, at 5:37 AM, Andrew Haley wrote: >> >> Hi, >> >> On 10/09/2015 03:59 PM, Roland Westrelin wrote: >> >>>> There is a much simpler way: remove adjacent barriers in >>>> MacroAssembler. Thanks to the way that the AArch64 ISA is designed, >>>> barriers can be merged simply by ORing them together. Of course, this >>>> technique works for C1 and C2, and it adds essentially nothing to the >>>> compilation time. >>>> >>>> http://cr.openjdk.java.net/~aph/8139041/ >>>> >>>> One thing which may be controversial is that I've added a field to >>>> CodeBuffer to keep track of barriers and labels. I had to do this >>>> because when we're compiling there is (AFAICS) essentially nowhere >>>> else to keep the state. > > I don?t think it matters to have an additional field in CodeBuffer. It?s a temporary data structure and we use much more memory for graphs. > > I would even go that far and questioning putting it under #ifdef AARCH64. +1 that. Vladimir > >>> >>> Isn?t your new field a bit like: >>> >>> address insts_mark() const { return _insts.mark(); } >>> void set_insts_mark() { _insts.set_mark(); } >>> void clear_insts_mark() { _insts.clear_mark(); } >>> >>> which is used in very few locations AFAIK. Do you think you could reuse that one? >> >> Yes, that's what it's based on. I guess that is possible in theory, >> but AbstractAssembler::InstructionMark() looks like this: >> >> InstructionMark(AbstractAssembler* assm) : _assm(assm) { >> assert(assm->inst_mark() == NULL, "overlapping instructions"); >> _assm->set_inst_mark(); >> } >> >> so any instruction which leaves the mark set will trigger an assertion >> failure the next time InstructionMark is used. I suppose that in >> extremis I could make every instruction which is not a memory barrier >> clear the mark, but ewww. :( >> >> I suppose I could define an AArch64-specific version of >> InstructionMark which does not have this assert, but I'm not sure I >> like that either. >> >> [An aside: we use InstructionMark unnecessarily in AArch64, and it's >> on my list of things to remove, but that's for another day.] >> >> Thanks for looking at this, >> >> Andrew. > From vladimir.kozlov at oracle.com Sat Oct 10 12:52:09 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 10 Oct 2015 20:52:09 +0800 Subject: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. In-Reply-To: <39F83597C33E5F408096702907E6C45005878DDA@ORSMSX104.amr.corp.intel.com> References: <39F83597C33E5F408096702907E6C45005878DDA@ORSMSX104.amr.corp.intel.com> Message-ID: <561909F9.2020205@oracle.com> Changes contains also 8136725 (loop reserve copy) changes. Please, clean up. x86.ad WAIT! According to next conditions (BTW, support condition should match predicate) this is only supported with AVX1 and AVX2 and not AVX3. Really? I think it should be reversed condition (< 3): + case Op_CMoveVD: + if (UseAVX > 2) + ret_value = false; + instruct vcmov4D_reg(vecY dst, vecY src1, vecY src2, immI8 cop, cmpOp_vcmppd copnd) %{ + predicate(UseAVX > 0 && UseAVX < 3 && n->as_Vector()->length() == 4); x86_64.ad changes are empty (could be only spacing change) so remove it from change. c2_globals.hpp DoReserveCopyInSuperWord is defined in 8136725 changes. UseCMov should be UseCMoveUnconditionally I think (note 'move' instead of 'mov'). Also I am not sure that you should mix 2 things into this changes: one is vectorizing cmoveD (for doubles) and always generate cmoves. I think it is different issues and this change should concentrate on vectorizing only double cmoves. Then flag could be VectorizeCMoveD. compile.cpp print not under UseCmov flag: + NOT_PRODUCT(if (Verbose && has_method()) {tty->print("Compile::Init: use CMove without profitability tests for method %s\n", method()->name()->as_quoted_ascii());}) loopopts.cpp changes inconsistent. In one place you check use_cmove only for doubles and in other for all. I will look on superword changes after you cleanup changes: remove 8136725 and also create history from fresh repo - I don't want to see 50 revisions descriptions in webrev. Thanks, Vladimir On 10/10/15 7:04 AM, Civlin, Jan wrote: > Please review this patch. > > Hi All, > > > We would like to contribute the SuperWord enhancement to support > vector conditional move (CMovVD ) on Intel AVX cpu. > > > The contribution Bug ID: 8139340. > > Please review this patch: > > Bug-id: https://bugs.openjdk.java.net/browse/JDK-8139340 > > webrev: http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ > > Description: > > SuperWord enhancement to support vector conditional move (CMovVD) on > Intel AVX cpu. > > The SuperWord optimization bails out on counted loops that contain any > conditional statement other than the loop exit, and this prevents > vectorization of many compute bound loops. > > The proposed enhancement enables generation of CMovD on demand > (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD ) in > SuperWord optimization. > > The performance gain observed on a simplified Monte Carlo Option > Calculation was up to 2x speed-up. > > Thank you, > > Jan. > > *From:*Igor Veresov [mailto:igor.veresov at oracle.com] > *Sent:* Friday, October 9, 2015 3:22 PM > *To:* Civlin, Jan > *Cc:* hotspot compiler; Vladimir Kozlov > *Subject:* Re: SuperWord enhancement to support vector conditional move > (CMovVD ) on Intel AVX cpu. > > Here it is: https://bugs.openjdk.java.net/browse/JDK-8139340 > > igor > > On Oct 9, 2015, at 2:57 PM, Civlin, Jan > wrote: > > Thank you, Igor. > > What is the RFR for this? > > *From:*Igor Veresov [mailto:igor.veresov at oracle.com] > *Sent:*Friday, October 9, 2015 2:53 PM > *To:*Civlin, Jan > *Cc:*hotspot compiler; Vladimir Kozlov > *Subject:*Re: SuperWord enhancement to support vector conditional > move (CMovVD ) on Intel AVX cpu. > > Here the webrev: > http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ > > igor > > On Oct 9, 2015, at 1:15 PM, Civlin, Jan > wrote: > > Igor, > > Please create RFR and upload this patch. You may need to rename > ancnav.js.remove_this_extention back to ancnav.js (I have to > rename it for passing the mail server filters). > > Description: > > SuperWord enhancement to support vector conditional move > (CMovVD) on Intel AVX cpu. > > The SuperWord optimization bails out on counted loops that > contain any conditional statement other than the loop exit, and > this prevents vectorization of many compute bound loops. > > The proposed enhancement enables generation of CMovD on demand > (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD > ) in SuperWord optimization. > > The performance gain observed on a simplified Monte Carlo Option > Calculation was up to 2x speed-up. > > Thank you, > > Jan. > > > From hui.shi at linaro.org Sat Oct 10 13:25:10 2015 From: hui.shi at linaro.org (Hui Shi) Date: Sat, 10 Oct 2015 21:25:10 +0800 Subject: RFR: Elide more final field's write memory barrier with escape analysis result In-Reply-To: <7C9B87B351A4BA4AA9EC95BB4181165672261165@DEWDFEMB19C.global.corp.sap> References: <5612A2C6.5080108@redhat.com> <7C9B87B351A4BA4AA9EC95BB4181165672261165@DEWDFEMB19C.global.corp.sap> Message-ID: Thanks Roland and Martin! Agree, it's better remove extra code for PPC64. new webrev http://cr.openjdk.java.net/~hshi/8138956/webrev_v2/ comments below Regards Shi Hui On 10 October 2015 at 00:17, Doerr, Martin wrote: > Hi, > > I basically like this change. Thanks for pointing me to it. > > But I don't like the extra code for PPC64. If the allocation does not > escape globally it should be safe to elide the membar regardless of whether > we wrote final or volatile fields. > > Difference is final field is always belonging to initializing object while volatile field isn't. It's reasonable to insert MemoryBarrier, when volatile field is written in its owning class' initializer method, like you example of AtomicInteger. In following example, class A initiailzer writes both final field and volatile field, suppose A instance doesn't escape. MemBarRelase is inserted because final and volatile field wirte. Writing b.vol in A's initializer is same with writing b.vol in none-initalizer method and doesn't need MemBarRelease in my understanding. 1. If final and volatile field from same allocation, elide MemBarRelase when allocation doesn't escape is safe. 2. If volatile field doesn't belong to final field's allocation object, MemBarRelase for volatile is not necessary. So it's safe to remove MemBarRelease when final field's allocation object doesn't escape. Class A { final int a; A(int val, B b) { a=val; b.vol = val; } } Class B { volatile int vol;} > Please also note that PPC64_ONLY(...) NOT_PPC(...) is incorrect on PPC32. > > Actually, it's ugly that PPC64_ONLY was used here. Should better be > (support_IRIW_for_not_multiple_copy_atomic_cpu && wrote_volatile()), but > that's not the topic of this change. > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-compiler-dev [mailto: > hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Roland > Westrelin > Sent: Donnerstag, 8. Oktober 2015 13:51 > To: Hui Shi > Cc: hotspot compiler; aarch64-port-dev at openjdk.java.net > Subject: Re: RFR: Elide more final field's write memory barrier with > escape analysis result > > > http://cr.openjdk.java.net/~hshi/8138956/webrev/ > > The code change looks good to me. The comments have a few typos and are a > bit confusing. I'll tweak them before I push it. > > PPC folks, in case you missed it, parse1.cpp has a ppc related fix. > > Roland. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.civlin at intel.com Sat Oct 10 19:13:40 2015 From: jan.civlin at intel.com (Civlin, Jan) Date: Sat, 10 Oct 2015 19:13:40 +0000 Subject: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. In-Reply-To: <561909F9.2020205@oracle.com> References: <39F83597C33E5F408096702907E6C45005878DDA@ORSMSX104.amr.corp.intel.com> <561909F9.2020205@oracle.com> Message-ID: <39F83597C33E5F408096702907E6C45005878E67@ORSMSX104.amr.corp.intel.com> Vladimir, Thank you for the quick review. I thought you are patching your repo using hotspot.patch which is clean of empty files or .hgtag and you use webrev only for facilitation of visual code review. If you use hotspot.patch it does not propagate to your repo empty or already integrated in 8136725 files or my repo tags, since none of them are in the patch. I thought you are simply skipping unchanged files if you see them in webrev html pages. My repo is a consistent and long living clone of your repo. It is a single place that includes the history of all my changes, which let me go ahead in development way far of what is ready for going out to you. I can create an additional repo and filter out my tags on way out, but it will create more possibilities for accidental errors. x86.ad: it is indeed not (yet) AVX3, since AVX3 will have different ISA. Once we have AVX3 in the house and can debug it, AVX3 case will be added. c2_globals.hpp: I will rename the flag to UseCMoveUnconditionally, but I see no point of having another flag for the vector: once SuperWord detects CMovD, it merely vectorize it. In the opposite direction: one cannot ask for vectorization of CMovD and not to get them in the scalar case. compile.cpp: 1114: will add "do_vector_loop() &&" and change to NOT_PRODUCT(if (do_vector_loop() && Verbose&& && has_method()) {tty->print("Compile::Init: use CMove without profitability tests for method %s\n", method()->name()->as_quoted_ascii());}) loopopts.cpp: 601: will add "&& cmp_op == Op_CmpD" and change to if (C->use_cmove() && cmp_op == Op_CmpD) ;//keep going Thank you, Jan -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Saturday, October 10, 2015 5:52 AM To: Civlin, Jan Cc: hotspot compiler Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. Changes contains also 8136725 (loop reserve copy) changes. Please, clean up. x86.ad WAIT! According to next conditions (BTW, support condition should match predicate) this is only supported with AVX1 and AVX2 and not AVX3. Really? I think it should be reversed condition (< 3): + case Op_CMoveVD: + if (UseAVX > 2) + ret_value = false; + instruct vcmov4D_reg(vecY dst, vecY src1, vecY src2, immI8 cop, cmpOp_vcmppd copnd) %{ + predicate(UseAVX > 0 && UseAVX < 3 && n->as_Vector()->length() == + 4); x86_64.ad changes are empty (could be only spacing change) so remove it from change. c2_globals.hpp DoReserveCopyInSuperWord is defined in 8136725 changes. UseCMov should be UseCMoveUnconditionally I think (note 'move' instead of 'mov'). Also I am not sure that you should mix 2 things into this changes: one is vectorizing cmoveD (for doubles) and always generate cmoves. I think it is different issues and this change should concentrate on vectorizing only double cmoves. Then flag could be VectorizeCMoveD. compile.cpp print not under UseCmov flag: + NOT_PRODUCT(if (Verbose && has_method()) {tty->print("Compile::Init: use CMove without profitability tests for method %s\n", method()->name()->as_quoted_ascii());}) loopopts.cpp changes inconsistent. In one place you check use_cmove only for doubles and in other for all. I will look on superword changes after you cleanup changes: remove 8136725 and also create history from fresh repo - I don't want to see 50 revisions descriptions in webrev. Thanks, Vladimir On 10/10/15 7:04 AM, Civlin, Jan wrote: > Please review this patch. > > Hi All, > > > We would like to contribute the SuperWord enhancement to support > vector conditional move (CMovVD ) on Intel AVX cpu. > > > The contribution Bug ID: 8139340. > > Please review this patch: > > Bug-id: https://bugs.openjdk.java.net/browse/JDK-8139340 > > webrev: http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ > > Description: > > SuperWord enhancement to support vector conditional move (CMovVD) on > Intel AVX cpu. > > The SuperWord optimization bails out on counted loops that contain any > conditional statement other than the loop exit, and this prevents > vectorization of many compute bound loops. > > The proposed enhancement enables generation of CMovD on demand > (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD ) in > SuperWord optimization. > > The performance gain observed on a simplified Monte Carlo Option > Calculation was up to 2x speed-up. > > Thank you, > > Jan. > > *From:*Igor Veresov [mailto:igor.veresov at oracle.com] > *Sent:* Friday, October 9, 2015 3:22 PM > *To:* Civlin, Jan > *Cc:* hotspot compiler; Vladimir Kozlov > *Subject:* Re: SuperWord enhancement to support vector conditional > move (CMovVD ) on Intel AVX cpu. > > Here it is: https://bugs.openjdk.java.net/browse/JDK-8139340 > > igor > > On Oct 9, 2015, at 2:57 PM, Civlin, Jan > wrote: > > Thank you, Igor. > > What is the RFR for this? > > *From:*Igor Veresov [mailto:igor.veresov at oracle.com] > *Sent:*Friday, October 9, 2015 2:53 PM > *To:*Civlin, Jan > *Cc:*hotspot compiler; Vladimir Kozlov > *Subject:*Re: SuperWord enhancement to support vector conditional > move (CMovVD ) on Intel AVX cpu. > > Here the webrev: > http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ > > igor > > On Oct 9, 2015, at 1:15 PM, Civlin, Jan > wrote: > > Igor, > > Please create RFR and upload this patch. You may need to rename > ancnav.js.remove_this_extention back to ancnav.js (I have to > rename it for passing the mail server filters). > > Description: > > SuperWord enhancement to support vector conditional move > (CMovVD) on Intel AVX cpu. > > The SuperWord optimization bails out on counted loops that > contain any conditional statement other than the loop exit, and > this prevents vectorization of many compute bound loops. > > The proposed enhancement enables generation of CMovD on demand > (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD > ) in SuperWord optimization. > > The performance gain observed on a simplified Monte Carlo Option > Calculation was up to 2x speed-up. > > Thank you, > > Jan. > > > From zoltan.majo at oracle.com Mon Oct 12 08:06:00 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 12 Oct 2015 10:06:00 +0200 Subject: [9] RFR(M): 8078554: Compiler: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <4D6D08C8-A649-4D91-938C-6BA6E0F214AD@oracle.com> References: <560BB4F6.3050703@oracle.com> <4502D8F6-B256-4222-B1D3-92ED5C100B6E@oracle.com> <5613B44F.4090007@oracle.com> <5615204C.8080202@oracle.com> <56165C6C.70705@oracle.com> <56167973.9020002@oracle.com> <56169147.80901@oracle.com> <4D6D08C8-A649-4D91-938C-6BA6E0F214AD@oracle.com> Message-ID: <561B69E8.5030309@oracle.com> Hi, On 10/09/2015 11:33 PM, Christian Thalinger wrote: > After JEP 243 was integrated we fail one of the new tests with: > > intx TypeProfileWidth=8 is outside the allowed range [ 0 ... 4 ] > > The reason is that JVMCI can support more than 4 type profiles. > Currently the default is 8: > > if (UseJVMCICompiler) { > if (FLAG_IS_DEFAULT(TypeProfileWidth)) { > TypeProfileWidth = 8; > } > } > > We should increase the range. Not sure what a good number would be, > though. Maybe 100 just to be safe? 16 is already too large -- it triggers an assert on a platform we support. I'll look into extending the range to 8. Best regards, Zoltan > >> On Oct 8, 2015, at 5:52 AM, Zolt?n Maj? > > wrote: >> >> Thank you, Tobias, for the review! >> >> Best regards, >> >> >> Zolt?n >> >> On 10/08/2015 04:10 PM, Tobias Hartmann wrote: >>> Hi Zolt?n, >>> >>> On 08.10.2015 14:07, Zolt?n Maj? wrote: >>>> Hi Tobias, >>>> >>>> >>>> thank you for the feedback! >>>> >>>> On 10/07/2015 03:38 PM, Tobias Hartmann wrote: >>>>> Hi Zoltan, >>>>> >>>>> I had a look at your changes and just spotted some minor things: >>>>> >>>>> globals_sparc.hpp: >>>>> - I think there is a '\' missing in line 119 >>>> thank you for spotting that! >>>> >>>>> globals_x86.hpp: >>>>> - Isn't this also a compiler flag we should add range checks for? >>>>> 136 product(uintx, RTMRetryCount, 5, >>>> JEP 245 considers it as a runtime flag and JDK-8078556 "Runtime: >>>> implement ranges..." [1] will take care of it. But you are right, >>>> that flag could be also considered a compiler flag. >>> Okay, thanks for pointing that out. >>> >>>>> commandLineFlagConstraintsCompiler.cpp: >>>>> - I think there is a "rule" that the include statements should be >>>>> in alphabetical order >>>> Yes, I think there is such a rule (or convention). I diverged from >>>> the rule because the include of code/relocInfo.hpp depends on 'os', >>>> 'vm_page_size', and 'Metadata'. Therefore, "oops/metadata.hpp" and >>>> "runtime/os.hpp" must be included before relocInfo.hpp (otherwise >>>> the Solaris compiler complains). The remaining includes are ordered >>>> alphabetically. >>> Okay, makes sense. >>> >>>>> - the indentation is wrong here: >>>>> 179 return Flag::VIOLATES_CONSTRAINT; >>>> I updated the indentation. >>>> >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~zmajo/8078554/webrev.02/ >>>> >>>> >>>> I re-tested the updated webrev with JPRT (testset hotspot), all >>>> tests pass. >>> Looks good to me (not a Reviewer). >>> >>> Best, >>> Tobias >>> >>> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8078556 >>>>> Best, >>>>> Tobias >>>> >>>>> On 06.10.2015 13:45, Zolt?n Maj? wrote: >>>>>> Hi Roland, >>>>>> >>>>>> >>>>>> thank you for the feedback! >>>>>> >>>>>> On 10/02/2015 03:55 PM, Roland Westrelin wrote: >>>>>>> Hi Zoltan, >>>>>>> >>>>>>>> Webrev:http://cr.openjdk.java.net/~zmajo/8078554/ >>>>>>>> >>>>>>> c2_globals.hpp >>>>>>> >>>>>>> That one is not correct: >>>>>>> 461 product(intx, MaxNodeLimit, 80000, >>>>>>> \ >>>>>>> 462 "Maximum number of nodes") >>>>>>> \ >>>>>>> 463 range(1000, 80000) >>>>>>> \ >>>>>>> >>>>>>> I think the upper bound should be max_juint >>>>>> You are right that the limit of 80'000 is too conservative. But >>>>>> max_j*u*int as an upper bound would cause an overflow when >>>>>> parsing the flag's value, because on 32-bit machines intx is a >>>>>> 32-bit signed integer. >>>>>> >>>>>> Using max_jint instead of max_j*u*int as an upper bound would not >>>>>> cause an overflow at parse time. However, in Parse::do_call() the >>>>>> maximum node limit is increased by 3 times for jsr292 users >>>>>> >>>>>> C->set_max_node_limit(3*MaxNodeLimit); >>>>>> >>>>>> If MaxNodeLimit == max_jint, this expression will overflow, I think. >>>>>> >>>>>> So I set the limit to (max_jint / 3) in the updated webrev. >>>>>> >>>>>> If we would set MaxNodeLimit to max_j*u*int / 3 (instead of >>>>>> max_jint / 3), the expression 3 * MaxNodeLimit would overflow as >>>>>> well. Changing the type of the flag from intx to uintx could let >>>>>> use use max_j*u*int / 3 as an upper bound, but that is most >>>>>> likely not worth the effort. >>>>>> >>>>>>> 699 product(intx, LiveNodeCountInliningCutoff, 40000, >>>>>>> \ >>>>>>> 700 "max number of live nodes in a method") >>>>>>> \ >>>>>>> 701 range(0, max_juint / 8) >>>>>>> \ >>>>>>> >>>>>>> Out of curiosity why max_juint / 8 (not that it makes much of a >>>>>>> difference)? >>>>>> In Compile::inline_incrementally, the 80% of >>>>>> LiveNodeCountInliningCutoff is computed the following way: >>>>>> >>>>>> if (low_live_nodes < (uint)LiveNodeCountInliningCutoff * 8 / 10) { >>>>>> >>>>>> If LiveNodeCountInliningCutoff == max_juint, we'd have an >>>>>> overflow because of the multiplication by 8. >>>>>> >>>>>>> arguments.cpp >>>>>>> >>>>>>> 1099 Tier3InvokeNotifyFreqLog = 0; >>>>>>> 1100 Tier4InvocationThreshold = 0; >>>>>>> >>>>>>> Why that change? >>>>>> I proposed that change because I misread the code. I reverted >>>>>> that change and also changed the range of all Tier*FreqLog flags >>>>>> from range(1, 30) to range(0, 30). >>>>>> >>>>>>> globals.hp >>>>>>> >>>>>>> 2870 product_pd(uintx, TypeProfileLevel, >>>>>>> \ >>>>>>> 2871 "=XYZ, with Z: Type profiling of arguments at >>>>>>> call; " \ >>>>>>> 2872 "Y: Type profiling of return value at >>>>>>> call; " \ >>>>>>> 2873 "X: Type profiling of parameters to >>>>>>> methods; " \ >>>>>>> 2874 "X, Y and Z in 0=off ; 1=jsr292 only; 2=all >>>>>>> methods") \ >>>>>>> 2875 range(0, 222) >>>>>>> >>>>>>> Legal values are 0, 1, 2, 10, 11, 12, 100, 101, 102, 110, 111, >>>>>>> 112 etc. >>>>>>> >>>>>>> 70 is not for instance. So range(0, 222) is incorrect. >>>>>> I agree. I removed the range check and implemented a constraint >>>>>> function instead (TypeProfileLevelConstraintFunc). >>>>>> >>>>>>> 2877 product(intx, TypeProfileArgsLimit, 2, >>>>>>> \ >>>>>>> 2878 "max number of call arguments to consider for >>>>>>> type profiling") \ >>>>>>> 2879 range(0, 16) >>>>>>> \ >>>>>>> >>>>>>> 2880 >>>>>>> \ >>>>>>> 2881 product(intx, TypeProfileParmsLimit, 2, >>>>>>> \ >>>>>>> 2882 "max number of incoming parameters to consider >>>>>>> for type profiling"\ >>>>>>> 2883 ", -1 for all") >>>>>>> \ >>>>>>> 2884 range(-1, 64) >>>>>>> >>>>>>> Why 16 and 64? >>>>>> These are the largest values that work on all platforms we support. >>>>>> >>>>>> Here is the updated webrev: >>>>>> http://cr.openjdk.java.net/~zmajo/8078554/webrev.01/ >>>>>> >>>>>> >>>>>> I repeated the testing with JPRT. I also executed the currently >>>>>> disabled TestOptionsWithRanges.java test on all platforms we >>>>>> support. All tests pass. >>>>>> >>>>>> Thank you and best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>>> >>>>>>> Roland. >> > From roland.westrelin at oracle.com Mon Oct 12 08:46:50 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 12 Oct 2015 10:46:50 +0200 Subject: RFR(S): 8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI In-Reply-To: <56125D5A.7060708@oracle.com> References: <7B89ADB9-1DF9-4DE2-85C8-0ADFF34A3190@oracle.com> <55F99D08.3010204@oracle.com> <4DAAADBF-9A3C-46BD-9E86-29E9B5044FAA@oracle.com> <55F9AB59.6030604@oracle.com> <07AAF0D5-134D-4D85-BD4C-EA5049EF8857@oracle.com> <55FF5E26.1060008@oracle.com> <041EEDC9-D32F-420D-9D55-111499B13321@oracle.com> <9D17B19D-9A35-4EFE-B5F7-954629DA2FC2@oracle.com> <10866B0A-712E-4665-9CC3-838AE6536D4A@oracle.com> <56014EA4.50907@oracle.com> <56122D8D.1050909@oracle.com> <56125D5A.7060708@oracle.com> Message-ID: Here is a new webrev that covers mismatched field accesses as well: http://cr.openjdk.java.net/~roland/8136473/webrev.03/ Roland. > On Oct 5, 2015, at 1:22 PM, Vladimir Kozlov wrote: > > So you are covering oops too. Okay then. > > Thanks, > Vladimir > > On 10/5/15 5:12 PM, Roland Westrelin wrote: >> Thanks for looking at this, Vladimir. >> >>> Mismatching access can be only for basic type as I understand. The code for mismatched = true could be rearranged by checking type != T_OBJECT first. >> >> People do such crazy things with Unsafe, I thought it was best to be prepared for anything. >> >>> Why you set mismatched only for array element? What about fields? >> >> You?re right, fields need to be handled the same way. >> >>> And next should be && I think (if you keep your code) >>> if (type != T_OBJECT || !element->isa_narrowoop()) >> >> Either we reach that test with a basic type that is not an object (type != T_OBJECT) and there?s a mismatch but >> if we have element->array_element_basic_type() = T_NARROWOOP and type = T_OBJECT, then there?s no mismatch. >> >> Roland. >> >>> >>> Thanks, >>> Vladimir >>> >>> On 9/28/15 11:44 PM, Roland Westrelin wrote: >>>> That fix wasn?t sufficient so here is a new webrev: >>>> >>>> http://cr.openjdk.java.net/~roland/8136473/webrev.02/ >>>> >>>> On platforms that don?t support unaligned accesses we still have mismatched accesses because the java code of Unsafe.putIntUnaligned() is implemented in terms of putShort() and putByte() so my test case fails on sparc. I added a new boolean to MemNode to record whether the node is ?mismatched? in addition to the ?unaligned? boolean. >>>> >>>> Roland. >>>> >>>>> On Sep 22, 2015, at 2:50 PM, Vladimir Kozlov wrote: >>>>> >>>>> Okay. >>>>> >>>>> Vladimir >>>>> >>>>> On 9/22/15 8:47 PM, Roland Westrelin wrote: >>>>>> For the record, it seems _unaligned is a reserved keyword for MSVC so I will change the field and function names to unaligned_access: >>>>>> >>>>>> diff --git a/src/share/vm/opto/memnode.hpp b/src/share/vm/opto/memnode.hpp >>>>>> --- a/src/share/vm/opto/memnode.hpp >>>>>> +++ b/src/share/vm/opto/memnode.hpp >>>>>> @@ -40,7 +40,7 @@ >>>>>> // Load or Store, possibly throwing a NULL pointer exception >>>>>> class MemNode : public Node { >>>>>> private: >>>>>> - bool _unaligned; >>>>>> + bool _unaligned_access; >>>>>> protected: >>>>>> #ifdef ASSERT >>>>>> const TypePtr* _adr_type; // What kind of memory is being addressed? >>>>>> >>>>>> @@ -129,8 +129,8 @@ >>>>>> // the given memory state? (The state may or may not be in(Memory).) >>>>>> Node* can_see_stored_value(Node* st, PhaseTransform* phase) const; >>>>>> >>>>>> - void set_unaligned() { _unaligned = true; } >>>>>> - bool is_unaligned() const { return _unaligned; } >>>>>> + void set_unaligned_access() { _unaligned_access = true; } >>>>>> + bool is_unaligned_access() const { return _unaligned_access; } >>>>>> >>>>>> #ifndef PRODUCT >>>>>> static void dump_adr_type(const Node* mem, const TypePtr* adr_type, outputStream *st); >>>>>> >>>>>> Roland. >>>>>> >>>>>>> On Sep 22, 2015, at 9:43 AM, Roland Westrelin wrote: >>>>>>> >>>>>>>> Roland I had a look too, the code looks good. >>>>>>> >>>>>>> Thanks, Michael. >>>>>>> >>>>>>> Roland. >>>>>>> >>>>>>>> >>>>>>>> -Michael >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Roland Westrelin >>>>>>>> Sent: Monday, September 21, 2015 2:03 AM >>>>>>>> To: hotspot compiler >>>>>>>> Subject: Re: RFR(S): 8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI >>>>>>>> >>>>>>>> Thanks for the review, Vladimir. >>>>>>>> >>>>>>>> Roland. >>>>>>>> >>>>>>>>> On Sep 21, 2015, at 3:32 AM, Vladimir Kozlov wrote: >>>>>>>>> >>>>>>>>> This is good. Thank you for extending the test. >>>>>>>>> >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 9/18/15 11:03 PM, Roland Westrelin wrote: >>>>>>>>>>>>> Hmm, so you just relaxed the assert. You may need to fix EA too because it also checks for matching types(memory sizes). >>>>>>>>>>>>> I remember we had problem with RAW accesses back when jsr292 was implemented. So EA gave up on RAW access and marks allocations as escaping. Also may be superword/vectorization will be affected. >>>>>>>>>>>>> >>>>>>>>>>>>> In general it is very bad for C2 to have different memory on the same non-RAW memory. >>>>>>>>>>>> >>>>>>>>>>>> It already happens with vectorization. Do you see another solution (rather than relaxing the assert)? Putting a MemBarCPUOrder before and after the unaligned store? >>>>>>>>>>> >>>>>>>>>>> MemBarCPUOrder are definitely will help and it is simplest solution but, I think, it is too drastic. >>>>>>>>>>> It affect control flow and other memory slices. >>>>>>>>>>> We can try to mark such memory accesses or/and mark objects which have such accesses (if it is possible) and prevent vectorization and scalarization for them only. We should be able execute optimization on other memory slices then. >>>>>>>>>> >>>>>>>>>> Here is a new change: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~roland/8136473/webrev.01/ >>>>>>>>>> >>>>>>>>>> Unaligned accesses are explicitly marked as such. >>>>>>>>>> >>>>>>>>>> I added a test case with a non escaping allocation and it works fine. I also added test case with vectorization and if the accesses are effectively unaligned vectorization doesn't happen. One of the test cases causes an assertion to fire when the allocation is expanded: the logic in InitializeNode::complete_stores() is confused by the unaligned store so I made sure unaligned stores are not captured by the initialization. >>>>>>>>>> >>>>>>>>>> Roland. >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> From goetz.lindenmaier at sap.com Mon Oct 12 08:58:10 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 12 Oct 2015 08:58:10 +0000 Subject: RFR(M) 8138892: C1: Improve counter overflow checking In-Reply-To: <7C9B87B351A4BA4AA9EC95BB4181165672260C97@DEWDFEMB19C.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB4181165672260C97@DEWDFEMB19C.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC41E81D63@DEWDFEMB12A.global.corp.sap> Hi Martin, this change looks good, thank you. Could someone please sponsor this? Best regards, Goetz. From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Doerr, Martin Sent: Mittwoch, 7. Oktober 2015 23:02 To: hotspot compiler; Andrew Haley (aph at redhat.com) Subject: RFR(M) 8138892: C1: Improve counter overflow checking Hi, C1 currently loads the Method pointer in the fast path even though it is only required in the overflow case. In addition, stupid code gets generated when the frequency is set to 0 which occurs with -Xcomp. The following webrev optimizes that: http://cr.openjdk.java.net/~mdoerr/8138892_c1_counter_overflow/webrev.02 It's not tested on aarch64. Please review this change. I need a sponsor, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Mon Oct 12 09:14:08 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 12 Oct 2015 09:14:08 +0000 Subject: RFR(S): 8138890: C1: Ambiguous operator delete In-Reply-To: <3D04808B-DB7A-4ECF-A3BF-42D5A20E2419@oracle.com> References: <7C9B87B351A4BA4AA9EC95BB41811656722607B5@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672260AE1@DEWDFEMB19C.global.corp.sap> <56153267.7060401@oracle.com> <7C9B87B351A4BA4AA9EC95BB4181165672260BFB@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672261012@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB41811656722611F8@DEWDFEMB19C.global.corp.sap> <3D04808B-DB7A-4ECF-A3BF-42D5A20E2419@oracle.com> Message-ID: <7C9B87B351A4BA4AA9EC95BB418116567226135E@DEWDFEMB19C.global.corp.sap> Hi Christian, seems like VALUE_OBJ_CLASS_SPEC inherits from _ValueObj on platforms on which the compiler uses empty base class optimization. On these platforms, the inheritance comes for free (no extra size for the object). A problem is that the macro VALUE_OBJ_CLASS_SPEC does not work for multi-inheritance because it translates to either nothing or a term which would need comma separation. The other class we inherit from defines new/delete operators which are not supposed to get used for this derived class, so I think making these operators private there is just the right thing to do. Best regards, Martin From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Samstag, 10. Oktober 2015 00:32 To: Doerr, Martin Cc: Volker Simonis; Lindenmaier, Goetz; Mikael Gerdin; hotspot compiler Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete On Oct 9, 2015, at 9:08 AM, Doerr, Martin > wrote: Hi Christian, I have just added comments. We can also get rid of the multi-inheritance in RanceCheckEliminator::Verification. Hmm. Why did we have it this way (not using the macro and such)? - class Verification : public _ValueObj /*VALUE_OBJ_CLASS_SPEC*/, public BlockClosure { + class Verification : public BlockClosure { The new webrev is: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.03 Best regards, Martin From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Freitag, 9. Oktober 2015 20:35 To: Doerr, Martin Cc: Volker Simonis; Lindenmaier, Goetz; Mikael Gerdin; hotspot compiler Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete On Oct 9, 2015, at 12:03 AM, Doerr, Martin > wrote: Hi, thanks for reviewing. As requested by G?tz, I just removed the second ?private?. The new webrev is here: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.02 Looks good. Can we add a comment saying that objects of this class should never be allocated on the heap or something? Best regards, Martin From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Mittwoch, 7. Oktober 2015 21:28 To: Doerr, Martin Cc: Mikael Gerdin; Christian Thalinger; hotspot compiler Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete Hi Martin, as the new/delete operators in StackObj are private (I missed that before) they shouldn't be visible in LIRGenerator. So this is probably yet another xlC bug :( On the other hand the new/delete operators in CompilationResourceObject are public and are inherited by LIRGenerator. So if we only want to generate LIRGenerator instances on the stack, your change is good, because it ensures this. And in that case we surely don't need an implementation. So thumbs up from me! Volker On Wednesday, October 7, 2015, Doerr, Martin > wrote: Hi Volker, the C1 classes we are talking about should never get instantiated by operator new. A typical way to establish this is to make the new operators private. I don?t really care if the delete operators are public or private because if the new operator is never used, how can the delete operator get used? It may be more beautiful to declare them as private as well. Only in the case G?tz has showed, some Compilers reject the private delete operators. Best regards, Martin From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Mittwoch, 7. Oktober 2015 17:57 To: Mikael Gerdin Cc: Doerr, Martin; Christian Thalinger; hotspot compiler Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete Hi Martin, we have: class LIRGenerator: public InstructionVisitor, public BlockClosure and: class BlockClosure: public CompilationResourceObj class CompilationResourceObj ALLOCATION_SUPER_CLASS_SPEC { public: void* operator new(size_t size) throw() { return Compilation::current()->arena()->Amalloc(size); } void* operator new(size_t size, Arena* arena) throw() { return arena->Amalloc(size); } void operator delete(void* p) {} // nothing to do }; class InstructionVisitor: public StackObj class StackObj ALLOCATION_SUPER_CLASS_SPEC { private: void* operator new(size_t size) throw(); void* operator new [](size_t size) throw(); #ifdef __IBMCPP__ public: #endif void operator delete(void* p); void operator delete [](void* p); Now you declare new "new()" and "delete()" operators in the LIRGenerator which will actually hide the corresponding operators from the base classes. You also provide no implementation for the new operators in LIRGenerator. So which new/delete operators will be actually used for allocating new LIRGenerator instances? OK, wait. As far as I can see, LIRGenerator is never dynamically allocated, right? In that case it should be a StackObj and you could probably solve the problem with "using" directives (e.g. using StackObj::operator new, ...). Have you tried that? Regards, Volker On Wed, Oct 7, 2015 at 4:55 PM, Mikael Gerdin > wrote: On 2015-10-07 16:17, Doerr, Martin wrote: Hi, that?s a good question J I can only remember that there were problems with some old compilers. Anyway, xlC 12.1 can deal with the private delete operators. If that's the case, can we also get rid of the workaround in allocation.hpp? Thanks /Mikael Here?s the new webrev: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.01 Best regards, Martin *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com] *Sent:* Mittwoch, 7. Oktober 2015 03:32 *To:* Doerr, Martin *Cc:* hotspot compiler *Subject:* Re: RFR(S): 8138890: C1: Ambiguous operator delete On Oct 6, 2015, at 3:56 AM, Doerr, Martin >> wrote: Hi, xlC on AIX rejects to compile LIRGenerator and RangeCheckEliminator::Verification due to ambiguous operator delete which gets inherited from multiple base classes. This change is a prerequisite for our C1 on PPC64 contribution. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.00 Let me ask my question here: why do you need the delete methods to be public on AIX? Please review this change. I need a sponsor, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Mon Oct 12 09:39:16 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 12 Oct 2015 09:39:16 +0000 Subject: RFR: Elide more final field's write memory barrier with escape analysis result In-Reply-To: References: <5612A2C6.5080108@redhat.com> <7C9B87B351A4BA4AA9EC95BB4181165672261165@DEWDFEMB19C.global.corp.sap> Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165672261384@DEWDFEMB19C.global.corp.sap> Hi Hui Shi, thanks for the update. Looks good for PPC64 as well, now. As you already explained, the MemBarRelease is only relevant for fields of the allocated object. Hence, the final and volatile cases can be handled the same way. Best regards, Martin From: Hui Shi [mailto:hui.shi at linaro.org] Sent: Samstag, 10. Oktober 2015 15:25 To: Doerr, Martin Cc: Roland Westrelin; hotspot compiler; aarch64-port-dev at openjdk.java.net Subject: Re: RFR: Elide more final field's write memory barrier with escape analysis result Thanks Roland and Martin! Agree, it's better remove extra code for PPC64. new webrev http://cr.openjdk.java.net/~hshi/8138956/webrev_v2/ comments below Regards Shi Hui On 10 October 2015 at 00:17, Doerr, Martin > wrote: Hi, I basically like this change. Thanks for pointing me to it. But I don't like the extra code for PPC64. If the allocation does not escape globally it should be safe to elide the membar regardless of whether we wrote final or volatile fields. Difference is final field is always belonging to initializing object while volatile field isn't. It's reasonable to insert MemoryBarrier, when volatile field is written in its owning class' initializer method, like you example of AtomicInteger. In following example, class A initiailzer writes both final field and volatile field, suppose A instance doesn't escape. MemBarRelase is inserted because final and volatile field wirte. Writing b.vol in A's initializer is same with writing b.vol in none-initalizer method and doesn't need MemBarRelease in my understanding. 1. If final and volatile field from same allocation, elide MemBarRelase when allocation doesn't escape is safe. 2. If volatile field doesn't belong to final field's allocation object, MemBarRelase for volatile is not necessary. So it's safe to remove MemBarRelease when final field's allocation object doesn't escape. Class A { final int a; A(int val, B b) { a=val; b.vol = val; } } Class B { volatile int vol;} Please also note that PPC64_ONLY(...) NOT_PPC(...) is incorrect on PPC32. Actually, it's ugly that PPC64_ONLY was used here. Should better be (support_IRIW_for_not_multiple_copy_atomic_cpu && wrote_volatile()), but that's not the topic of this change. Best regards, Martin -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Roland Westrelin Sent: Donnerstag, 8. Oktober 2015 13:51 To: Hui Shi Cc: hotspot compiler; aarch64-port-dev at openjdk.java.net Subject: Re: RFR: Elide more final field's write memory barrier with escape analysis result > http://cr.openjdk.java.net/~hshi/8138956/webrev/ The code change looks good to me. The comments have a few typos and are a bit confusing. I'll tweak them before I push it. PPC folks, in case you missed it, parse1.cpp has a ppc related fix. Roland. -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Mon Oct 12 10:51:57 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 12 Oct 2015 10:51:57 +0000 Subject: RFR(S): 8139421: PPC64LE: MacroAssembler::bxx64_patchable kills register R12 Message-ID: <7C9B87B351A4BA4AA9EC95BB41811656722613B0@DEWDFEMB19C.global.corp.sap> Hi, PPC64LE has a different implementation for bxx64_patchable which kills Register R12. However, register R12 must be preserved for stub calls. It is used to call the deopt handler for example. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8139421_PPC64LE_R12/webrev.00 Please review this change. I need a sponsor, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From nils.eliasson at oracle.com Mon Oct 12 11:27:45 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 12 Oct 2015 13:27:45 +0200 Subject: RFR(S): 8134607: Remove per-compiler performance counters In-Reply-To: <56164774.2080504@oracle.com> References: <56164774.2080504@oracle.com> Message-ID: <561B9931.5050500@oracle.com> Looks good! Thanks for cleaning up! //Nils On 2015-10-08 12:37, Claes Redestad wrote: > Hello hotspot-compiler.dev, > > anyone care to review this patch to remove per-compiler thread > performance counters? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8134607 > > HotSpot webrev: http://cr.openjdk.java.net/~redestad/8134607/hotspot.01 > JDK webrev: http://cr.openjdk.java.net/~redestad/8134607/jdk.01 > > CCC approved, no new test failures running JPRT against hs-comp. > > /Claes From zoltan.majo at oracle.com Mon Oct 12 12:42:47 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 12 Oct 2015 14:42:47 +0200 Subject: [9] RFR(S): 8080650: enable stubs to use frame pointers correctly Message-ID: <561BAAC7.9080206@oracle.com> Hi, please review the following patch for JDK-8080650. Bug: https://bugs.openjdk.java.net/browse/JDK-8080650 Problem: The following stack frame layout allows external tools (e.g., Linux perf or Solaris pstack) to determine the call chain currently on the stack: ... ======================== ^ 0x108 | return address | | caller's frame ======================== ==================== 0x100 | RBP of caller | | callee's frame ======================== v ... The example above assumes a 64-bit architecture, the addresses 0x108 and 0x100 are randomly chosen. For stack tracing to work, RBP must have the value 0x100 while execution is in the method "callee". However, when HotSpot generates code that does not need stack banging (e.g., stubs), RBP is assigned anincorrect value. For stubs, RBP is 8 bytes off the incorrect value (e.g., RBP contains the value 0x108 instead of 0x100 for the above example). Solution: Change MacroAssembler::verified_entry() to set up RBP correctly when generating stub code. Setting up RBP is now done the same way as it is done for compiled code (i.e., when stack banging is needed). Webrev: http://cr.openjdk.java.net/~zmajo/8080650/webrev.00/ Testing: - JPRT (testset hotspot), all tests pass; - locally executed all hotspot JTREG tests and all JTREG tests in jdk/test/java/lang/invoke, all tests pass that pass with an unmodified VM. Many thanks to Hongxi Sy for reporting this problem. Thank you and best regards, Zoltan From vladimir.kozlov at oracle.com Mon Oct 12 14:25:00 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 12 Oct 2015 22:25:00 +0800 Subject: [9] RFR(S): 8080650: enable stubs to use frame pointers correctly In-Reply-To: <561BAAC7.9080206@oracle.com> References: <561BAAC7.9080206@oracle.com> Message-ID: <561BC2BC.8070005@oracle.com> The code which does not do stack banging seems incorrect - RSP is modified before it is saved in RBP: subptr_imm32(rsp, framesize); Thanks, Vladimir On 10/12/15 8:42 PM, Zolt?n Maj? wrote: > Hi, > > > please review the following patch for JDK-8080650. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8080650 > > > Problem: The following stack frame layout allows external tools (e.g., > Linux perf or Solaris pstack) to determine the call chain currently on > the stack: > > ... > ======================== ^ > 0x108 | return address | | caller's frame > ======================== ==================== > 0x100 | RBP of caller | | callee's frame > ======================== v > ... > > The example above assumes a 64-bit architecture, the addresses 0x108 and > 0x100 are randomly chosen. > > For stack tracing to work, RBP must have the value 0x100 while execution > is in the method "callee". However, when HotSpot generates code that > does not need stack banging (e.g., stubs), RBP is assigned anincorrect > value. For stubs, RBP is 8 bytes off the incorrect value (e.g., RBP > contains the value 0x108 instead of 0x100 for the above example). > > > Solution: Change MacroAssembler::verified_entry() to set up RBP > correctly when generating stub code. Setting up RBP is now done the same > way as it is done for compiled code (i.e., when stack banging is needed). > > Webrev: http://cr.openjdk.java.net/~zmajo/8080650/webrev.00/ > > Testing: > - JPRT (testset hotspot), all tests pass; > - locally executed all hotspot JTREG tests and all JTREG tests in > jdk/test/java/lang/invoke, all tests pass that pass with an unmodified VM. > > > Many thanks to Hongxi Sy for reporting this problem. > > Thank you and best regards, > > > Zoltan > From zoltan.majo at oracle.com Mon Oct 12 16:16:31 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 12 Oct 2015 18:16:31 +0200 Subject: [9] RFR(S): 8139377: JVM can't be started w/ -XX:+EnableJVMCI -XX:+UseJVMCICompiler and default TypeProfileWidth Message-ID: <561BDCDF.1090603@oracle.com> Hi, please review the following patch for JDK-8139377. Bug: https://bugs.openjdk.java.net/browse/JDK-8139377 Problem: JDK-8078554 defined a valid range for compiler-related command-line flags. The JVM checks at runtime if the value of each flag is within the range defined for the flag. JEP 243 (Java-Level JVM Compiler Interface) increased the value of TypeProfileWidth to 8 that is outside of the currently defined range for that flag. Solution: Increase the upper bound of TypeProfileWidth to 8. I also tried to increase the value to 16 but that value triggers an assert on one of our supported platforms. Webrev: http://cr.openjdk.java.net/~zmajo/8139377/webrev.00/ Testing: - all tests in hotspot/test/runtime/CommandLine on all supported platforms, all tests pass; - JPRT (testset hotspot), all tests pass. Thank you and best regards, Zoltan From igor.veresov at oracle.com Mon Oct 12 16:37:16 2015 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 12 Oct 2015 09:37:16 -0700 Subject: [9] RFR(S): 8139377: JVM can't be started w/ -XX:+EnableJVMCI -XX:+UseJVMCICompiler and default TypeProfileWidth In-Reply-To: <561BDCDF.1090603@oracle.com> References: <561BDCDF.1090603@oracle.com> Message-ID: <68B6D138-2641-4141-843F-9CCD3055F629@oracle.com> Looks good. igor > On Oct 12, 2015, at 9:16 AM, Zolt?n Maj? wrote: > > Hi, > > > please review the following patch for JDK-8139377. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139377 > > Problem: JDK-8078554 defined a valid range for compiler-related command-line flags. The JVM checks at runtime if the value of each flag is within the range defined for the flag. JEP 243 (Java-Level JVM Compiler Interface) increased the value of TypeProfileWidth to 8 that is outside of the currently defined range for that flag. > > Solution: Increase the upper bound of TypeProfileWidth to 8. I also tried to increase the value to 16 but that value triggers an assert on one of our supported platforms. > > Webrev: > http://cr.openjdk.java.net/~zmajo/8139377/webrev.00/ > > Testing: > - all tests in hotspot/test/runtime/CommandLine on all supported platforms, all tests pass; > - JPRT (testset hotspot), all tests pass. > > Thank you and best regards, > > > Zoltan > From tatiana.pivovarova at oracle.com Mon Oct 12 17:39:22 2015 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Mon, 12 Oct 2015 20:39:22 +0300 Subject: [9] RFR(S): 8139375: [TESTBUG] compiler/jvmci/SecurityRestrictionsTest checks are too tight Message-ID: <561BF04A.6030701@oracle.com> Hello guys, Please review this small patch When we use JVMCI functions without permissions we expect AccessControlException. But this exception raises not explicitly. It causes other exception (for example ExceptionInInitializerError). This patch add a workaround: we got the deepest cause and check that it is AccessControlException. Also I slightly changed Utils::runAndCheckException(Runnable runnable, Class expectedException) to ensure that this changes don't break other tests which use this function. bug id: https://bugs.openjdk.java.net/browse/JDK-8139375 webrev: http://cr.openjdk.java.net/~tpivovarova/8139375/webrev.00/ --- Thanks, Tatiana -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Mon Oct 12 17:58:22 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 12 Oct 2015 07:58:22 -1000 Subject: [9] RFR(M): 8078554: Compiler: implement ranges (optionally constraints) for those flags that have them missing In-Reply-To: <561B69E8.5030309@oracle.com> References: <560BB4F6.3050703@oracle.com> <4502D8F6-B256-4222-B1D3-92ED5C100B6E@oracle.com> <5613B44F.4090007@oracle.com> <5615204C.8080202@oracle.com> <56165C6C.70705@oracle.com> <56167973.9020002@oracle.com> <56169147.80901@oracle.com> <4D6D08C8-A649-4D91-938C-6BA6E0F214AD@oracle.com> <561B69E8.5030309@oracle.com> Message-ID: <505C68B9-A16A-42DE-B3A4-67097F207311@oracle.com> > On Oct 11, 2015, at 10:06 PM, Zolt?n Maj? wrote: > > Hi, > > > On 10/09/2015 11:33 PM, Christian Thalinger wrote: >> After JEP 243 was integrated we fail one of the new tests with: >> >> intx TypeProfileWidth=8 is outside the allowed range [ 0 ... 4 ] >> >> The reason is that JVMCI can support more than 4 type profiles. Currently the default is 8: >> >> if (UseJVMCICompiler) { >> if (FLAG_IS_DEFAULT(TypeProfileWidth)) { >> TypeProfileWidth = 8; >> } >> } >> >> We should increase the range. Not sure what a good number would be, though. Maybe 100 just to be safe? > > 16 is already too large -- it triggers an assert on a platform we support. I'll look into extending the range to 8. I didn?t try :-) Thanks. > > Best regards, > > > Zoltan > >> >>> On Oct 8, 2015, at 5:52 AM, Zolt?n Maj? >> wrote: >>> >>> Thank you, Tobias, for the review! >>> >>> Best regards, >>> >>> >>> Zolt?n >>> >>> On 10/08/2015 04:10 PM, Tobias Hartmann wrote: >>>> Hi Zolt?n, >>>> >>>> On 08.10.2015 14:07, Zolt?n Maj? wrote: >>>>> Hi Tobias, >>>>> >>>>> >>>>> thank you for the feedback! >>>>> >>>>> On 10/07/2015 03:38 PM, Tobias Hartmann wrote: >>>>>> Hi Zoltan, >>>>>> >>>>>> I had a look at your changes and just spotted some minor things: >>>>>> >>>>>> globals_sparc.hpp: >>>>>> - I think there is a '\' missing in line 119 >>>>> thank you for spotting that! >>>>> >>>>>> globals_x86.hpp: >>>>>> - Isn't this also a compiler flag we should add range checks for? >>>>>> 136 product(uintx, RTMRetryCount, 5, >>>>> JEP 245 considers it as a runtime flag and JDK-8078556 "Runtime: implement ranges..." [1] will take care of it. But you are right, that flag could be also considered a compiler flag. >>>> Okay, thanks for pointing that out. >>>> >>>>>> commandLineFlagConstraintsCompiler.cpp: >>>>>> - I think there is a "rule" that the include statements should be in alphabetical order >>>>> Yes, I think there is such a rule (or convention). I diverged from the rule because the include of code/relocInfo.hpp depends on 'os', 'vm_page_size', and 'Metadata'. Therefore, "oops/metadata.hpp" and "runtime/os.hpp" must be included before relocInfo.hpp (otherwise the Solaris compiler complains). The remaining includes are ordered alphabetically. >>>> Okay, makes sense. >>>> >>>>>> - the indentation is wrong here: >>>>>> 179 return Flag::VIOLATES_CONSTRAINT; >>>>> I updated the indentation. >>>>> >>>>> Here is the updated webrev: >>>>> http://cr.openjdk.java.net/~zmajo/8078554/webrev.02/ > >>>>> >>>>> I re-tested the updated webrev with JPRT (testset hotspot), all tests pass. >>>> Looks good to me (not a Reviewer). >>>> >>>> Best, >>>> Tobias >>>> >>>> >>>>> Thank you and best regards, >>>>> >>>>> >>>>> Zoltan >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8078556 >>>>>> Best, >>>>>> Tobias >>>>> >>>>>> On 06.10.2015 13:45, Zolt?n Maj? wrote: >>>>>>> Hi Roland, >>>>>>> >>>>>>> >>>>>>> thank you for the feedback! >>>>>>> >>>>>>> On 10/02/2015 03:55 PM, Roland Westrelin wrote: >>>>>>>> Hi Zoltan, >>>>>>>> >>>>>>>>> Webrev:http://cr.openjdk.java.net/~zmajo/8078554/ > >>>>>>>> c2_globals.hpp >>>>>>>> >>>>>>>> That one is not correct: >>>>>>>> 461 product(intx, MaxNodeLimit, 80000, \ >>>>>>>> 462 "Maximum number of nodes") \ >>>>>>>> 463 range(1000, 80000) \ >>>>>>>> >>>>>>>> I think the upper bound should be max_juint >>>>>>> You are right that the limit of 80'000 is too conservative. But max_j*u*int as an upper bound would cause an overflow when parsing the flag's value, because on 32-bit machines intx is a 32-bit signed integer. >>>>>>> >>>>>>> Using max_jint instead of max_j*u*int as an upper bound would not cause an overflow at parse time. However, in Parse::do_call() the maximum node limit is increased by 3 times for jsr292 users >>>>>>> >>>>>>> C->set_max_node_limit(3*MaxNodeLimit); >>>>>>> >>>>>>> If MaxNodeLimit == max_jint, this expression will overflow, I think. >>>>>>> >>>>>>> So I set the limit to (max_jint / 3) in the updated webrev. >>>>>>> >>>>>>> If we would set MaxNodeLimit to max_j*u*int / 3 (instead of max_jint / 3), the expression 3 * MaxNodeLimit would overflow as well. Changing the type of the flag from intx to uintx could let use use max_j*u*int / 3 as an upper bound, but that is most likely not worth the effort. >>>>>>> >>>>>>>> 699 product(intx, LiveNodeCountInliningCutoff, 40000, \ >>>>>>>> 700 "max number of live nodes in a method") \ >>>>>>>> 701 range(0, max_juint / 8) \ >>>>>>>> >>>>>>>> Out of curiosity why max_juint / 8 (not that it makes much of a difference)? >>>>>>> In Compile::inline_incrementally, the 80% of LiveNodeCountInliningCutoff is computed the following way: >>>>>>> >>>>>>> if (low_live_nodes < (uint)LiveNodeCountInliningCutoff * 8 / 10) { >>>>>>> >>>>>>> If LiveNodeCountInliningCutoff == max_juint, we'd have an overflow because of the multiplication by 8. >>>>>>> >>>>>>>> arguments.cpp >>>>>>>> >>>>>>>> 1099 Tier3InvokeNotifyFreqLog = 0; >>>>>>>> 1100 Tier4InvocationThreshold = 0; >>>>>>>> >>>>>>>> Why that change? >>>>>>> I proposed that change because I misread the code. I reverted that change and also changed the range of all Tier*FreqLog flags from range(1, 30) to range(0, 30). >>>>>>> >>>>>>>> globals.hp >>>>>>>> >>>>>>>> 2870 product_pd(uintx, TypeProfileLevel, \ >>>>>>>> 2871 "=XYZ, with Z: Type profiling of arguments at call; " \ >>>>>>>> 2872 "Y: Type profiling of return value at call; " \ >>>>>>>> 2873 "X: Type profiling of parameters to methods; " \ >>>>>>>> 2874 "X, Y and Z in 0=off ; 1=jsr292 only; 2=all methods") \ >>>>>>>> 2875 range(0, 222) >>>>>>>> >>>>>>>> Legal values are 0, 1, 2, 10, 11, 12, 100, 101, 102, 110, 111, 112 etc. >>>>>>>> >>>>>>>> 70 is not for instance. So range(0, 222) is incorrect. >>>>>>> I agree. I removed the range check and implemented a constraint function instead (TypeProfileLevelConstraintFunc). >>>>>>> >>>>>>>> 2877 product(intx, TypeProfileArgsLimit, 2, \ >>>>>>>> 2878 "max number of call arguments to consider for type profiling") \ >>>>>>>> 2879 range(0, 16) \ >>>>>>>> >>>>>>>> 2880 \ >>>>>>>> 2881 product(intx, TypeProfileParmsLimit, 2, \ >>>>>>>> 2882 "max number of incoming parameters to consider for type profiling"\ >>>>>>>> 2883 ", -1 for all") \ >>>>>>>> 2884 range(-1, 64) >>>>>>>> >>>>>>>> Why 16 and 64? >>>>>>> These are the largest values that work on all platforms we support. >>>>>>> >>>>>>> Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8078554/webrev.01/ > >>>>>>> >>>>>>> I repeated the testing with JPRT. I also executed the currently disabled TestOptionsWithRanges.java test on all platforms we support. All tests pass. >>>>>>> >>>>>>> Thank you and best regards, >>>>>>> >>>>>>> >>>>>>> Zoltan >>>>>>> >>>>>>>> Roland. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Mon Oct 12 18:00:24 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 12 Oct 2015 08:00:24 -1000 Subject: [9] RFR(S): 8139377: JVM can't be started w/ -XX:+EnableJVMCI -XX:+UseJVMCICompiler and default TypeProfileWidth In-Reply-To: <561BDCDF.1090603@oracle.com> References: <561BDCDF.1090603@oracle.com> Message-ID: Looks good, thanks. > On Oct 12, 2015, at 6:16 AM, Zolt?n Maj? wrote: > > Hi, > > > please review the following patch for JDK-8139377. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139377 > > Problem: JDK-8078554 defined a valid range for compiler-related command-line flags. The JVM checks at runtime if the value of each flag is within the range defined for the flag. JEP 243 (Java-Level JVM Compiler Interface) increased the value of TypeProfileWidth to 8 that is outside of the currently defined range for that flag. > > Solution: Increase the upper bound of TypeProfileWidth to 8. I also tried to increase the value to 16 but that value triggers an assert on one of our supported platforms. > > Webrev: > http://cr.openjdk.java.net/~zmajo/8139377/webrev.00/ > > Testing: > - all tests in hotspot/test/runtime/CommandLine on all supported platforms, all tests pass; > - JPRT (testset hotspot), all tests pass. > > Thank you and best regards, > > > Zoltan > From coleen.phillimore at oracle.com Mon Oct 12 18:03:03 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 12 Oct 2015 14:03:03 -0400 Subject: RFR(M): 8139040: Fix initializations before ShouldNotReachHere() In-Reply-To: <4295855A5C1DE049A61835A1887419CC41E80B3B@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC41E80B3B@DEWDFEMB12A.global.corp.sap> Message-ID: <561BF5D7.9000803@oracle.com> Hi, There are surprisingly few changes to runtime code for this, which look fine. I'm adding the compiler alias though. Thanks, Coleen On 10/7/15 9:22 AM, Lindenmaier, Goetz wrote: > Hi, > > SAP requires us to fix a row of issues in the hotspot coding. I would like > to share these with openJDK. > > This webrev fixes a row of missing intializations, mostly combined with ShouldNotReachHere() > in default cases of switches or the like. > http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.00/ > > In the debug build, ShouldNotReachHere() can be suppressed, so the uninitialized value actually can cause problems. > In opt builds, not all tools recognize the ShouldNotReachHere properly. > > In addition to this I would like to add -Wuninitialized to the warning flags. > This finds most of these issues in the opt build and > would require an additional 70 fixes plus fixes in jvmtiEnter.xsl. > Would it be appreciated to set this flag? > > Best regards, > Goetz. > > > From christian.thalinger at oracle.com Mon Oct 12 18:05:10 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 12 Oct 2015 08:05:10 -1000 Subject: [9] RFR(S): 8139375: [TESTBUG] compiler/jvmci/SecurityRestrictionsTest checks are too tight In-Reply-To: <561BF04A.6030701@oracle.com> References: <561BF04A.6030701@oracle.com> Message-ID: Looks good. > On Oct 12, 2015, at 7:39 AM, Tatiana Pivovarova wrote: > > Hello guys, > > Please review this small patch > When we use JVMCI functions without permissions we expect AccessControlException. But this exception raises not explicitly. It causes other exception (for example ExceptionInInitializerError). > This patch add a workaround: we got the deepest cause and check that it is AccessControlException. Also I slightly changed Utils::runAndCheckException(Runnable runnable, Class expectedException) to ensure that this changes don't break other tests which use this function. > > bug id: https://bugs.openjdk.java.net/browse/JDK-8139375 > webrev: http://cr.openjdk.java.net/~tpivovarova/8139375/webrev.00/ > --- > Thanks, > Tatiana -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Mon Oct 12 18:06:15 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 12 Oct 2015 08:06:15 -1000 Subject: RFR(S): 8134607: Remove per-compiler performance counters In-Reply-To: <5617D270.3060606@oracle.com> References: <56164774.2080504@oracle.com> <14408518-3FC6-4ECC-80FF-DEA48992C3F5@oracle.com> <5617D270.3060606@oracle.com> Message-ID: > On Oct 9, 2015, at 4:42 AM, Claes Redestad wrote: > > > > On 2015-10-09 02:32, Christian Thalinger wrote: >>> On Oct 8, 2015, at 12:37 AM, Claes Redestad wrote: >>> >>> Hello hotspot-compiler.dev, >>> >>> anyone care to review this patch to remove per-compiler thread performance counters? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8134607 >>> >>> HotSpot webrev: http://cr.openjdk.java.net/~redestad/8134607/hotspot.01 >>> JDK webrev: http://cr.openjdk.java.net/~redestad/8134607/jdk.01 >> Looks good. When will the Java class be removed? > > Thanks! > > Assuming the entirety of sun.management is being encapsulated with Jigsaw (currently seems to > be the case), I guesswe could follow-up with a removal of the deprecated methods and classes for JDK 10? Sounds good. > > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-August/004433.html > > /Claes > >> >>> CCC approved, no new test failures running JPRT against hs-comp. >>> >>> /Claes > From tatiana.pivovarova at oracle.com Mon Oct 12 18:19:09 2015 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Mon, 12 Oct 2015 21:19:09 +0300 Subject: [9] RFR(S): 8139375: [TESTBUG] compiler/jvmci/SecurityRestrictionsTest checks are too tight In-Reply-To: References: <561BF04A.6030701@oracle.com> Message-ID: <561BF99D.9060306@oracle.com> Thanks for review, Christian! --- Tatiana On 10/12/2015 09:05 PM, Christian Thalinger wrote: > Looks good. > >> On Oct 12, 2015, at 7:39 AM, Tatiana Pivovarova >> > > wrote: >> >> Hello guys, >> >> Please review this small patch >> When we use JVMCI functions without permissions we expect >> AccessControlException. But this exception raises not explicitly. It >> causes other exception (for example ExceptionInInitializerError). >> This patch add a workaround: we got the deepest cause and check that >> it is AccessControlException. Also I slightly changed >> Utils::runAndCheckException(Runnable runnable, Class> Throwable> expectedException) to ensure that this changes don't break >> other tests which use this function. >> >> bug id: https://bugs.openjdk.java.net/browse/JDK-8139375 >> webrev: http://cr.openjdk.java.net/~tpivovarova/8139375/webrev.00/ >> --- >> Thanks, >> Tatiana > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Mon Oct 12 20:45:49 2015 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 12 Oct 2015 13:45:49 -0700 Subject: RFR: 8139259: aarch64: jtreg test TestLogSum segvs after 8132207 In-Reply-To: <8AF4C615-5E7A-425E-8883-5E7ECE2669E7@oracle.com> References: <1444389470.23861.23.camel@mint> <8AF4C615-5E7A-425E-8883-5E7ECE2669E7@oracle.com> Message-ID: <6E7C7761-DD7B-4CCB-AE6D-0ADA27385F83@oracle.com> This seems one of parts of the P1 blocker (https://bugs.openjdk.java.net/browse/JDK-8139454 ). Roland, could you please push this (at least the library_call.cpp part)? Thanks! igor > On Oct 9, 2015, at 5:23 AM, Roland Westrelin wrote: > > Hi Ed, > >> http://cr.openjdk.java.net/~enevill/8139259/webrev/ > > All 64 bit x86 cpus support sse2 so the new check in stubGenerator_x86_64.cpp is useless. Given in the interpreter and c1, we call the exp stub unconditionally, it didn?t really make sense that it was conditional on UseSSE in c2, anyway. Your library_call.cpp change looks good to me. I?ll sponsor it. > > Roland. -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Mon Oct 12 21:36:57 2015 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 12 Oct 2015 14:36:57 -0700 Subject: RFR(XS): 8139454 java/lang/Math/WorstCaseTests.java crashes on Linux-amd64 Message-ID: <9A09B0CC-3FBA-476C-8908-DA53EA0295A4@oracle.com> This fixes the encoding of pextrw instruction, to make it work with with sse2 only. Webrev: http://cr.openjdk.java.net/~iveresov/8139454/webrev-pextrw/ Contributed by: vivek.r.deshpande at intel.com For the record, I reviewed this. Thanks, igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Mon Oct 12 23:08:35 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 12 Oct 2015 13:08:35 -1000 Subject: RFR(XS): 8139454 java/lang/Math/WorstCaseTests.java crashes on Linux-amd64 In-Reply-To: <9A09B0CC-3FBA-476C-8908-DA53EA0295A4@oracle.com> References: <9A09B0CC-3FBA-476C-8908-DA53EA0295A4@oracle.com> Message-ID: Good. Just in case. > On Oct 12, 2015, at 11:36 AM, Igor Veresov wrote: > > This fixes the encoding of pextrw instruction, to make it work with with sse2 only. > > Webrev: http://cr.openjdk.java.net/~iveresov/8139454/webrev-pextrw/ > Contributed by: vivek.r.deshpande at intel.com > > For the record, I reviewed this. > > Thanks, > igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Mon Oct 12 23:09:56 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 12 Oct 2015 13:09:56 -1000 Subject: RFR(S): 8138890: C1: Ambiguous operator delete In-Reply-To: <7C9B87B351A4BA4AA9EC95BB418116567226135E@DEWDFEMB19C.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB41811656722607B5@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672260AE1@DEWDFEMB19C.global.corp.sap> <56153267.7060401@oracle.com> <7C9B87B351A4BA4AA9EC95BB4181165672260BFB@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672261012@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB41811656722611F8@DEWDFEMB19C.global.corp.sap> <3D04808B-DB7A-4ECF-A3BF-42D5A20E2419@oracle.com> <7C9B87B351A4BA4AA9EC95BB418116567226135E@DEWDFEMB19C.global.corp.sap> Message-ID: > On Oct 11, 2015, at 11:14 PM, Doerr, Martin wrote: > > Hi Christian, > > seems like VALUE_OBJ_CLASS_SPEC inherits from _ValueObj on platforms on which the compiler uses empty base class optimization. > On these platforms, the inheritance comes for free (no extra size for the object). > A problem is that the macro VALUE_OBJ_CLASS_SPEC does not work for multi-inheritance because it translates to either nothing or a term which would need comma separation. That answers my question, thanks. > > The other class we inherit from defines new/delete operators which are not supposed to get used for this derived class, so I think making these operators private there is just the right thing to do. > > Best regards, > Martin > > > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Samstag, 10. Oktober 2015 00:32 > To: Doerr, Martin > Cc: Volker Simonis; Lindenmaier, Goetz; Mikael Gerdin; hotspot compiler > Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete > > > On Oct 9, 2015, at 9:08 AM, Doerr, Martin > wrote: > > Hi Christian, > > I have just added comments. We can also get rid of the multi-inheritance in RanceCheckEliminator::Verification. > > Hmm. Why did we have it this way (not using the macro and such)? > > - class Verification : public _ValueObj /*VALUE_OBJ_CLASS_SPEC*/, public BlockClosure { > + class Verification : public BlockClosure { > > > The new webrev is: > http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.03 > > Best regards, > Martin > > From: Christian Thalinger [mailto:christian.thalinger at oracle.com ] > Sent: Freitag, 9. Oktober 2015 20:35 > To: Doerr, Martin > Cc: Volker Simonis; Lindenmaier, Goetz; Mikael Gerdin; hotspot compiler > Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete > > > On Oct 9, 2015, at 12:03 AM, Doerr, Martin > wrote: > > Hi, > > thanks for reviewing. > As requested by G?tz, I just removed the second ?private?. > The new webrev is here: > http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.02 > > Looks good. Can we add a comment saying that objects of this class should never be allocated on the heap or something? > > > > > Best regards, > Martin > > From: Volker Simonis [mailto:volker.simonis at gmail.com ] > Sent: Mittwoch, 7. Oktober 2015 21:28 > To: Doerr, Martin > Cc: Mikael Gerdin; Christian Thalinger; hotspot compiler > Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete > > Hi Martin, > > as the new/delete operators in StackObj are private (I missed that before) they shouldn't be visible in LIRGenerator. So this is probably yet another xlC bug :( > On the other hand the new/delete operators in CompilationResourceObject are public and are inherited by LIRGenerator. So if we only want to generate LIRGenerator instances on the stack, your change is good, because it ensures this. And in that case we surely don't need an implementation. > > So thumbs up from me! > > Volker > > > On Wednesday, October 7, 2015, Doerr, Martin > wrote: > Hi Volker, > > the C1 classes we are talking about should never get instantiated by operator new. > A typical way to establish this is to make the new operators private. > > I don?t really care if the delete operators are public or private because if the new operator is never used, how can the delete operator get used? > It may be more beautiful to declare them as private as well. Only in the case G?tz has showed, some Compilers reject the private delete operators. > > Best regards, > Martin > > > From: Volker Simonis [mailto:volker.simonis at gmail.com ] > Sent: Mittwoch, 7. Oktober 2015 17:57 > To: Mikael Gerdin > Cc: Doerr, Martin; Christian Thalinger; hotspot compiler > Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete > > Hi Martin, > > we have: > class LIRGenerator: public InstructionVisitor, public BlockClosure > > and: > > class BlockClosure: public CompilationResourceObj > > class CompilationResourceObj ALLOCATION_SUPER_CLASS_SPEC { > public: > void* operator new(size_t size) throw() { return Compilation::current()->arena()->Amalloc(size); } > void* operator new(size_t size, Arena* arena) throw() { > return arena->Amalloc(size); > } > void operator delete(void* p) {} // nothing to do > }; > > class InstructionVisitor: public StackObj > > class StackObj ALLOCATION_SUPER_CLASS_SPEC { > private: > void* operator new(size_t size) throw(); > void* operator new [](size_t size) throw(); > #ifdef __IBMCPP__ > public: > #endif > void operator delete(void* p); > void operator delete [](void* p); > > Now you declare new "new()" and "delete()" operators in the LIRGenerator which will actually hide the corresponding operators from the base classes. You also provide no implementation for the new operators in LIRGenerator. So which new/delete operators will be actually used for allocating new LIRGenerator instances? > > OK, wait. As far as I can see, LIRGenerator is never dynamically allocated, right? In that case it should be a StackObj and you could probably solve the problem with "using" directives (e.g. using StackObj::operator new, ...). Have you tried that? > > Regards, > Volker > > > On Wed, Oct 7, 2015 at 4:55 PM, Mikael Gerdin > wrote: > On 2015-10-07 16:17, Doerr, Martin wrote: > Hi, > > that?s a good question J > > I can only remember that there were problems with some old compilers. > > Anyway, xlC 12.1 can deal with the private delete operators. > > If that's the case, can we also get rid of the workaround in allocation.hpp? > > Thanks > /Mikael > > > Here?s the new webrev: > > http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.01 > > Best regards, > > Martin > > *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com ] > *Sent:* Mittwoch, 7. Oktober 2015 03:32 > *To:* Doerr, Martin > *Cc:* hotspot compiler > *Subject:* Re: RFR(S): 8138890: C1: Ambiguous operator delete > > On Oct 6, 2015, at 3:56 AM, Doerr, Martin ? ? >> wrote: > > Hi, > > xlC on AIX rejects to compile LIRGenerator and > RangeCheckEliminator::Verification due to ambiguous operator delete > which gets inherited from multiple base classes. > > This change is a prerequisite for our C1 on PPC64 contribution. > > Webrev is here: > > http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.00 > > Let me ask my question here: why do you need the delete methods to be > public on AIX? > > > > Please review this change. I need a sponsor, please. > > Best regards, > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Mon Oct 12 23:33:08 2015 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 12 Oct 2015 16:33:08 -0700 Subject: RFR(XS): 8139454 java/lang/Math/WorstCaseTests.java crashes on Linux-amd64 In-Reply-To: References: <9A09B0CC-3FBA-476C-8908-DA53EA0295A4@oracle.com> Message-ID: Thanks! > On Oct 12, 2015, at 4:08 PM, Christian Thalinger wrote: > > Good. Just in case. > >> On Oct 12, 2015, at 11:36 AM, Igor Veresov > wrote: >> >> This fixes the encoding of pextrw instruction, to make it work with with sse2 only. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8139454/webrev-pextrw/ >> Contributed by: vivek.r.deshpande at intel.com >> >> For the record, I reviewed this. >> >> Thanks, >> igor > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Tue Oct 13 02:19:26 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 12 Oct 2015 16:19:26 -1000 Subject: RFR (XL): 8139170: JVMCI refresh Message-ID: <6ECC12F2-8693-43AD-8F08-B7E3F21AEB40@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8139170 http://cr.openjdk.java.net/~twisti/8139170/webrev/ During the review period for JEP 243 there were some changes and enhancements to the JVMCI code done by Oracle Labs. In order to not disturb the already long and complicated review of JEP 243 we decided to do a refresh after the initial integration. A lot of the Java changes is switching to using explicit imports. From vladimir.kozlov at oracle.com Tue Oct 13 04:19:09 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 13 Oct 2015 12:19:09 +0800 Subject: RFR (XL): 8139170: JVMCI refresh In-Reply-To: <6ECC12F2-8693-43AD-8F08-B7E3F21AEB40@oracle.com> References: <6ECC12F2-8693-43AD-8F08-B7E3F21AEB40@oracle.com> Message-ID: <561C863D.7080800@oracle.com> Since we will get more changes from labs later we may enumerate them: JVMCI refresh 1. Can you explain new sed command in Gensrc-jdk.vm.ci.gmk. Are you sure it works on windows? Instead of is_trivial(method) may be we should have general function called from AdvancedThresholdPolicy::common() which return compilation level for particular method (for example, we can also limit it using compilecommand). Could be done as separate change after this. I looked on jdk.vm.ci changes and nothing looks terrible wrong. I am not familiar with it so I can't say that each line is correct. One thing I am wondering is why explicit imports are used instead of .* (compilation speed?): -import java.lang.annotation.*; +import java.lang.annotation.ElementType; +import java.lang.annotation.Retention; +import java.lang.annotation.RetentionPolicy; +import java.lang.annotation.Target; An other thing is using AMD64/amd64 in files and directory names. May be we should rename it to x64. jvmciCodeInstaller_x86.cpp and jvmciCodeInstaller.cpp has next pattern: + if (HotSpotMetaspaceConstantImpl::compressed(constant)) { +#ifdef _LP64 + ... +#else + fatal("unexpected compressed Klass* in 32-bit mode"); +#endif + } else { It would be nice to hide fatal() in some wrapper function. jvmciEnv.cpp use ASSERT instead of DEBUG. We renamed ifdef DEBUG long ago. globals.hpp changes conflict with 8139377. Tests changes (mostly renaming) looks fine. Fix copyright years (2015, 2015) in new files. Thanks, Vladimir On 10/13/15 10:19 AM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8139170 > http://cr.openjdk.java.net/~twisti/8139170/webrev/ > > During the review period for JEP 243 there were some changes and enhancements to the JVMCI code done by Oracle Labs. In order to not disturb the already long and complicated review of JEP 243 we decided to do a refresh after the initial integration. > > A lot of the Java changes is switching to using explicit imports. > From goetz.lindenmaier at sap.com Tue Oct 13 06:07:36 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 13 Oct 2015 06:07:36 +0000 Subject: RFR(S): 8139421: PPC64LE: MacroAssembler::bxx64_patchable kills register R12 In-Reply-To: <7C9B87B351A4BA4AA9EC95BB41811656722613B0@DEWDFEMB19C.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB41811656722613B0@DEWDFEMB19C.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC41E81FC3@DEWDFEMB12A.global.corp.sap> Hi Martin, the change looks good, thanks. I'll push it. I'ts ppc-only, so I can do it. Best regards, Goetz. From: Doerr, Martin Sent: Montag, 12. Oktober 2015 12:52 To: hotspot-compiler-dev at openjdk.java.net; Lindenmaier, Goetz; Simonis, Volker Subject: RFR(S): 8139421: PPC64LE: MacroAssembler::bxx64_patchable kills register R12 Hi, PPC64LE has a different implementation for bxx64_patchable which kills Register R12. However, register R12 must be preserved for stub calls. It is used to call the deopt handler for example. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8139421_PPC64LE_R12/webrev.00 Please review this change. I need a sponsor, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Tue Oct 13 06:52:50 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 13 Oct 2015 06:52:50 +0000 Subject: RFR(M): 8139040: Fix initializations before ShouldNotReachHere() In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC41E81D98@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC41E81FF4@DEWDFEMB12A.global.corp.sap> Hi Thomas, thanks for looking at this! C1_LIRGenerator.hpp: I added handling of the default case (assert(0)). compactHashtable.cpp: Hmm, I?m not clear why get_num says corrupted() in one case, and in the other returns false. The code is dead, anyways, so I rather leave it as is. heapRegionRemSet.cpp I added guarantee(max_prev != NULL). I think this is better understandable. Else it looks as if there is a legal case where *max_prev must not be set. Updated webrev: http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.03/ Best regards, Goetz. From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: Montag, 12. Oktober 2015 16:45 To: Lindenmaier, Goetz Cc: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(M): 8139040: Fix initializations before ShouldNotReachHere() Hi Goetz, More small nitpicks: http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.02/src/share/vm/c1/c1_LIRGenerator.hpp.sdiff.html handle default case? I dont see callers handling lir_cond_unknown. ------------ http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.02/src/share/vm/classfile/compactHashtable.cpp.html maybe the right thing to do would be to handle errors returned by HashTableHexDump::get_num() ? (but your change is still better than the original) -------------- http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.02/src/share/vm/gc/g1/heapRegionRemSet.cpp.sdiff.html In PerRegionTable* OtherRegionsTable::delete_region_table(): 617 // Unsplice. 618 *max_prev = max->collision_list_next(); Should the access to max_prev be guarded against != NULL? ------------ Otherwise the change looks good. Kind Regards, Thomas On Mon, Oct 12, 2015 at 11:18 AM, Lindenmaier, Goetz > wrote: Hi, I now fixed the warnings showing with -Wuninitialized anyways. The change now enables this flag per default with gcc 4.8. Older gcc versions detect more issues, as far as I checked all false positives. Therefore I don't enable the flag for gcc < 4.8. The warnings reported by this flag depend on the optimization level, it's most effective in the opt build. This unveiled some missing initializations in constructors, as in compile.hpp, and oopMap.hpp that can actually cause wrong behavior. Complete webrev: http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.02/ incremental webrev: http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.02-incremental/ Best regards, Goetz. From: Lindenmaier, Goetz Sent: Mittwoch, 7. Oktober 2015 15:22 To: hotspot-runtime-dev at openjdk.java.net Subject: RFR(M): 8139040: Fix initializations before ShouldNotReachHere() Hi, SAP requires us to fix a row of issues in the hotspot coding. I would like to share these with openJDK. This webrev fixes a row of missing intializations, mostly combined with ShouldNotReachHere() in default cases of switches or the like. http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.00/ In the debug build, ShouldNotReachHere() can be suppressed, so the uninitialized value actually can cause problems. In opt builds, not all tools recognize the ShouldNotReachHere properly. In addition to this I would like to add -Wuninitialized to the warning flags. This finds most of these issues in the opt build and would require an additional 70 fixes plus fixes in jvmtiEnter.xsl. Would it be appreciated to set this flag? Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Tue Oct 13 06:56:17 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 13 Oct 2015 06:56:17 +0000 Subject: RFR(M): 8139040: Fix initializations before ShouldNotReachHere() In-Reply-To: <561BF5D7.9000803@oracle.com> References: <4295855A5C1DE049A61835A1887419CC41E80B3B@DEWDFEMB12A.global.corp.sap> <561BF5D7.9000803@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41E8200C@DEWDFEMB12A.global.corp.sap> Hi Coleen, thanks for looking at this! I'm never sure which list to post to, and don't want to spam too much of them. But you're right, this contains quite some compiler changes. Best regards, Goetz. -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore Sent: Montag, 12. Oktober 2015 20:03 To: hotspot-runtime-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR(M): 8139040: Fix initializations before ShouldNotReachHere() Hi, There are surprisingly few changes to runtime code for this, which look fine. I'm adding the compiler alias though. Thanks, Coleen On 10/7/15 9:22 AM, Lindenmaier, Goetz wrote: > Hi, > > SAP requires us to fix a row of issues in the hotspot coding. I would like > to share these with openJDK. > > This webrev fixes a row of missing intializations, mostly combined with ShouldNotReachHere() > in default cases of switches or the like. > http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.00/ > > In the debug build, ShouldNotReachHere() can be suppressed, so the uninitialized value actually can cause problems. > In opt builds, not all tools recognize the ShouldNotReachHere properly. > > In addition to this I would like to add -Wuninitialized to the warning flags. > This finds most of these issues in the opt build and > would require an additional 70 fixes plus fixes in jvmtiEnter.xsl. > Would it be appreciated to set this flag? > > Best regards, > Goetz. > > > From zoltan.majo at oracle.com Tue Oct 13 07:15:22 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 13 Oct 2015 09:15:22 +0200 Subject: [9] RFR(S): 8139377: JVM can't be started w/ -XX:+EnableJVMCI -XX:+UseJVMCICompiler and default TypeProfileWidth In-Reply-To: References: <561BDCDF.1090603@oracle.com> Message-ID: <561CAF8A.1060403@oracle.com> Thank you, Igor and Chris, for the review! Best regards, Zoltan On 10/12/2015 08:00 PM, Christian Thalinger wrote: > Looks good, thanks. > >> On Oct 12, 2015, at 6:16 AM, Zolt?n Maj? wrote: >> >> Hi, >> >> >> please review the following patch for JDK-8139377. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8139377 >> >> Problem: JDK-8078554 defined a valid range for compiler-related command-line flags. The JVM checks at runtime if the value of each flag is within the range defined for the flag. JEP 243 (Java-Level JVM Compiler Interface) increased the value of TypeProfileWidth to 8 that is outside of the currently defined range for that flag. >> >> Solution: Increase the upper bound of TypeProfileWidth to 8. I also tried to increase the value to 16 but that value triggers an assert on one of our supported platforms. >> >> Webrev: >> http://cr.openjdk.java.net/~zmajo/8139377/webrev.00/ >> >> Testing: >> - all tests in hotspot/test/runtime/CommandLine on all supported platforms, all tests pass; >> - JPRT (testset hotspot), all tests pass. >> >> Thank you and best regards, >> >> >> Zoltan >> From roland.westrelin at oracle.com Tue Oct 13 08:10:00 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 13 Oct 2015 10:10:00 +0200 Subject: RFR(M): 8139040: Fix initializations before ShouldNotReachHere() In-Reply-To: <4295855A5C1DE049A61835A1887419CC41E81FF4@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC41E81D98@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41E81FF4@DEWDFEMB12A.global.corp.sap> Message-ID: Hi Goetz, > C1_LIRGenerator.hpp: > I added handling of the default case (assert(0)). Shouldn?t you use fatal instead of assert(0)? I went over the compiler related files and they look ok to me. Roland. > > compactHashtable.cpp: > Hmm, I?m not clear why get_num says corrupted() in one case, > and in the other returns false. The code is dead, anyways, so I > rather leave it as is. > > heapRegionRemSet.cpp > I added guarantee(max_prev != NULL). I think this is better understandable. > Else it looks as if there is a legal case where *max_prev must not be set. > > Updated webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.03/ > > Best regards, > Goetz. > > > > > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > Sent: Montag, 12. Oktober 2015 16:45 > To: Lindenmaier, Goetz > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(M): 8139040: Fix initializations before ShouldNotReachHere() > > Hi Goetz, > > More small nitpicks: > > http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.02/src/share/vm/c1/c1_LIRGenerator.hpp.sdiff.html > > handle default case? I dont see callers handling lir_cond_unknown. > > ------------ > > http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.02/src/share/vm/classfile/compactHashtable.cpp.html > > maybe the right thing to do would be to handle errors returned by HashTableHexDump::get_num() ? > (but your change is still better than the original) > > -------------- > > http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.02/src/share/vm/gc/g1/heapRegionRemSet.cpp.sdiff.html > > In PerRegionTable* OtherRegionsTable::delete_region_table(): > > 617 // Unsplice. > 618 *max_prev = max->collision_list_next(); > > Should the access to max_prev be guarded against != NULL? > > ------------ > > Otherwise the change looks good. > > Kind Regards, Thomas > > > On Mon, Oct 12, 2015 at 11:18 AM, Lindenmaier, Goetz > wrote: > Hi, > > I now fixed the warnings showing with -Wuninitialized anyways. > The change now enables this flag per default with gcc 4.8. > Older gcc versions detect more issues, as far as I checked all false > positives. Therefore I don't enable the flag for gcc < 4.8. > > The warnings reported by this flag depend on the optimization level, it's > most effective in the opt build. > > This unveiled some missing initializations in constructors, as in compile.hpp, > and oopMap.hpp that can actually cause wrong behavior. > > Complete webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.02/ > incremental webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.02-incremental/ > > Best regards, > Goetz. > > > From: Lindenmaier, Goetz > Sent: Mittwoch, 7. Oktober 2015 15:22 > To: hotspot-runtime-dev at openjdk.java.net > Subject: RFR(M): 8139040: Fix initializations before ShouldNotReachHere() > > Hi, > > SAP requires us to fix a row of issues in the hotspot coding. I would like > to share these with openJDK. > > This webrev fixes a row of missing intializations, mostly combined with ShouldNotReachHere() > in default cases of switches or the like. > http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.00/ > > In the debug build, ShouldNotReachHere() can be suppressed, so the uninitialized value actually can cause problems. > In opt builds, not all tools recognize the ShouldNotReachHere properly. > > In addition to this I would like to add -Wuninitialized to the warning flags. > This finds most of these issues in the opt build and > would require an additional 70 fixes plus fixes in jvmtiEnter.xsl. > Would it be appreciated to set this flag? > > Best regards, > Goetz. From thomas.stuefe at gmail.com Tue Oct 13 08:30:43 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 13 Oct 2015 10:30:43 +0200 Subject: RFR(M): 8139040: Fix initializations before ShouldNotReachHere() In-Reply-To: <4295855A5C1DE049A61835A1887419CC41E81FF4@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC41E81D98@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41E81FF4@DEWDFEMB12A.global.corp.sap> Message-ID: Hi Goetz, thanks! looks good, nothing further to add from me. Regards, Thomas On Tue, Oct 13, 2015 at 8:52 AM, Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > Hi Thomas, > > > > thanks for looking at this! > > > > C1_LIRGenerator.hpp: > > I added handling of the default case (assert(0)). > > > > compactHashtable.cpp: > > Hmm, I?m not clear why get_num says corrupted() in one case, > > and in the other returns false. The code is dead, anyways, so I > > rather leave it as is. > > > > heapRegionRemSet.cpp > > I added guarantee(max_prev != NULL). I think this is better > understandable. > > Else it looks as if there is a legal case where *max_prev must not be set. > > > > Updated webrev: > > http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.03/ > > > > Best regards, > > Goetz. > > > > > > > > > > *From:* Thomas St?fe [mailto:thomas.stuefe at gmail.com] > *Sent:* Montag, 12. Oktober 2015 16:45 > *To:* Lindenmaier, Goetz > *Cc:* hotspot-runtime-dev at openjdk.java.net > *Subject:* Re: RFR(M): 8139040: Fix initializations before > ShouldNotReachHere() > > > > Hi Goetz, > > > > More small nitpicks: > > > > > http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.02/src/share/vm/c1/c1_LIRGenerator.hpp.sdiff.html > > > > handle default case? I dont see callers handling lir_cond_unknown. > > > > ------------ > > > > > http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.02/src/share/vm/classfile/compactHashtable.cpp.html > > > > maybe the right thing to do would be to handle errors returned by > HashTableHexDump::get_num() ? > > (but your change is still better than the original) > > > > -------------- > > > > > http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.02/src/share/vm/gc/g1/heapRegionRemSet.cpp.sdiff.html > > > > In PerRegionTable* OtherRegionsTable::delete_region_table(): > > > > 617 // Unsplice. > > 618 *max_prev = max->collision_list_next(); > > > > Should the access to max_prev be guarded against != NULL? > > > > ------------ > > > > Otherwise the change looks good. > > > > Kind Regards, Thomas > > > > > > On Mon, Oct 12, 2015 at 11:18 AM, Lindenmaier, Goetz < > goetz.lindenmaier at sap.com> wrote: > > Hi, > > I now fixed the warnings showing with -Wuninitialized anyways. > The change now enables this flag per default with gcc 4.8. > Older gcc versions detect more issues, as far as I checked all false > positives. Therefore I don't enable the flag for gcc < 4.8. > > The warnings reported by this flag depend on the optimization level, it's > most effective in the opt build. > > This unveiled some missing initializations in constructors, as in > compile.hpp, > and oopMap.hpp that can actually cause wrong behavior. > > Complete webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.02/ > incremental webrev: > > http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.02-incremental/ > > Best regards, > Goetz. > > > From: Lindenmaier, Goetz > Sent: Mittwoch, 7. Oktober 2015 15:22 > To: hotspot-runtime-dev at openjdk.java.net > Subject: RFR(M): 8139040: Fix initializations before ShouldNotReachHere() > > > Hi, > > SAP requires us to fix a row of issues in the hotspot coding. I would like > to share these with openJDK. > > This webrev fixes a row of missing intializations, mostly combined with > ShouldNotReachHere() > in default cases of switches or the like. > http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.00/ > > In the debug build, ShouldNotReachHere() can be suppressed, so the > uninitialized value actually can cause problems. > In opt builds, not all tools recognize the ShouldNotReachHere properly. > > In addition to this I would like to add -Wuninitialized to the warning > flags. > This finds most of these issues in the opt build and > would require an additional 70 fixes plus fixes in jvmtiEnter.xsl. > Would it be appreciated to set this flag? > > Best regards, > Goetz. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.simon at oracle.com Tue Oct 13 08:59:08 2015 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 13 Oct 2015 10:59:08 +0200 Subject: RFR (XL): 8139170: JVMCI refresh In-Reply-To: <561C863D.7080800@oracle.com> References: <6ECC12F2-8693-43AD-8F08-B7E3F21AEB40@oracle.com> <561C863D.7080800@oracle.com> Message-ID: > On 13 Oct 2015, at 06:19, Vladimir Kozlov wrote: > > Since we will get more changes from labs later we may enumerate them: JVMCI refresh 1. Or, pessimistically, JVMCI refresh 01 ;-) > Can you explain new sed command in Gensrc-jdk.vm.ci.gmk. http://hg.openjdk.java.net/graal/graal-jvmci-8/rev/1852abfbaca3 > Are you sure it works on windows? I can?t say for sure but given that I see similar patterns in other *.gmk files, I think it should be fine. > Instead of is_trivial(method) may be we should have general function called from AdvancedThresholdPolicy::common() which return compilation level for particular method (for example, we can also limit it using compilecommand). Could be done as separate change after this. > > I looked on jdk.vm.ci changes and nothing looks terrible wrong. I am not familiar with it so I can't say that each line is correct. One thing I am wondering is why explicit imports are used instead of .* (compilation speed?): http://mail.openjdk.java.net/pipermail/graal-dev/2015-September/003546.html > -import java.lang.annotation.*; > +import java.lang.annotation.ElementType; > +import java.lang.annotation.Retention; > +import java.lang.annotation.RetentionPolicy; > +import java.lang.annotation.Target; > > An other thing is using AMD64/amd64 in files and directory names. May be we should rename it to x64. > > jvmciCodeInstaller_x86.cpp and jvmciCodeInstaller.cpp has next pattern: > + if (HotSpotMetaspaceConstantImpl::compressed(constant)) { > +#ifdef _LP64 > + ... > +#else > + fatal("unexpected compressed Klass* in 32-bit mode"); > +#endif > + } else { > > It would be nice to hide fatal() in some wrapper function. > > jvmciEnv.cpp use ASSERT instead of DEBUG. We renamed ifdef DEBUG long ago. > > globals.hpp changes conflict with 8139377. Then we should adopt 8139377 instead. > Tests changes (mostly renaming) looks fine. > > Fix copyright years (2015, 2015) in new files. > > Thanks, > Vladimir > > On 10/13/15 10:19 AM, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8139170 >> http://cr.openjdk.java.net/~twisti/8139170/webrev/ >> >> During the review period for JEP 243 there were some changes and enhancements to the JVMCI code done by Oracle Labs. In order to not disturb the already long and complicated review of JEP 243 we decided to do a refresh after the initial integration. >> >> A lot of the Java changes is switching to using explicit imports. >> From zoltan.majo at oracle.com Tue Oct 13 10:30:32 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 13 Oct 2015 12:30:32 +0200 Subject: [9] RFR(S): 8080650: enable stubs to use frame pointers correctly In-Reply-To: <561BC2BC.8070005@oracle.com> References: <561BAAC7.9080206@oracle.com> <561BC2BC.8070005@oracle.com> Message-ID: <561CDD48.5000408@oracle.com> Hi Vladimir, On 10/12/2015 04:25 PM, Vladimir Kozlov wrote: > The code which does not do stack banging seems incorrect - RSP is > modified before it is saved in RBP: > > subptr_imm32(rsp, framesize); you are right and thank you for catching the mistake! Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8080650/webrev.01/ I re-executed all JPRT tests (testset hotspot), all tests pass. Thank you and best regards, Zoltan > > Thanks, > Vladimir > > On 10/12/15 8:42 PM, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the following patch for JDK-8080650. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8080650 >> >> >> Problem: The following stack frame layout allows external tools (e.g., >> Linux perf or Solaris pstack) to determine the call chain currently on >> the stack: >> >> ... >> ======================== ^ >> 0x108 | return address | | caller's frame >> ======================== ==================== >> 0x100 | RBP of caller | | callee's frame >> ======================== v >> ... >> >> The example above assumes a 64-bit architecture, the addresses 0x108 and >> 0x100 are randomly chosen. >> >> For stack tracing to work, RBP must have the value 0x100 while execution >> is in the method "callee". However, when HotSpot generates code that >> does not need stack banging (e.g., stubs), RBP is assigned anincorrect >> value. For stubs, RBP is 8 bytes off the incorrect value (e.g., RBP >> contains the value 0x108 instead of 0x100 for the above example). >> >> >> Solution: Change MacroAssembler::verified_entry() to set up RBP >> correctly when generating stub code. Setting up RBP is now done the same >> way as it is done for compiled code (i.e., when stack banging is >> needed). >> >> Webrev: http://cr.openjdk.java.net/~zmajo/8080650/webrev.00/ >> >> Testing: >> - JPRT (testset hotspot), all tests pass; >> - locally executed all hotspot JTREG tests and all JTREG tests in >> jdk/test/java/lang/invoke, all tests pass that pass with an >> unmodified VM. >> >> >> Many thanks to Hongxi Sy for reporting this problem. >> >> Thank you and best regards, >> >> >> Zoltan >> From vladimir.kozlov at oracle.com Tue Oct 13 12:24:49 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 13 Oct 2015 20:24:49 +0800 Subject: [9] RFR(S): 8080650: enable stubs to use frame pointers correctly In-Reply-To: <561CDD48.5000408@oracle.com> References: <561BAAC7.9080206@oracle.com> <561BC2BC.8070005@oracle.com> <561CDD48.5000408@oracle.com> Message-ID: <561CF811.3080604@oracle.com> This seems right. Did you run with -XX:-UseStackBanging? Run at least jtreg tests. Thanks Vladimir On 10/13/15 6:30 PM, Zolt?n Maj? wrote: > Hi Vladimir, > > > On 10/12/2015 04:25 PM, Vladimir Kozlov wrote: >> The code which does not do stack banging seems incorrect - RSP is >> modified before it is saved in RBP: >> >> subptr_imm32(rsp, framesize); > > you are right and thank you for catching the mistake! > > Here is the updated webrev: > http://cr.openjdk.java.net/~zmajo/8080650/webrev.01/ > > I re-executed all JPRT tests (testset hotspot), all tests pass. > > Thank you and best regards, > > > Zoltan > >> >> Thanks, >> Vladimir >> >> On 10/12/15 8:42 PM, Zolt?n Maj? wrote: >>> Hi, >>> >>> >>> please review the following patch for JDK-8080650. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080650 >>> >>> >>> Problem: The following stack frame layout allows external tools (e.g., >>> Linux perf or Solaris pstack) to determine the call chain currently on >>> the stack: >>> >>> ... >>> ======================== ^ >>> 0x108 | return address | | caller's frame >>> ======================== ==================== >>> 0x100 | RBP of caller | | callee's frame >>> ======================== v >>> ... >>> >>> The example above assumes a 64-bit architecture, the addresses 0x108 and >>> 0x100 are randomly chosen. >>> >>> For stack tracing to work, RBP must have the value 0x100 while execution >>> is in the method "callee". However, when HotSpot generates code that >>> does not need stack banging (e.g., stubs), RBP is assigned anincorrect >>> value. For stubs, RBP is 8 bytes off the incorrect value (e.g., RBP >>> contains the value 0x108 instead of 0x100 for the above example). >>> >>> >>> Solution: Change MacroAssembler::verified_entry() to set up RBP >>> correctly when generating stub code. Setting up RBP is now done the same >>> way as it is done for compiled code (i.e., when stack banging is >>> needed). >>> >>> Webrev: http://cr.openjdk.java.net/~zmajo/8080650/webrev.00/ >>> >>> Testing: >>> - JPRT (testset hotspot), all tests pass; >>> - locally executed all hotspot JTREG tests and all JTREG tests in >>> jdk/test/java/lang/invoke, all tests pass that pass with an >>> unmodified VM. >>> >>> >>> Many thanks to Hongxi Sy for reporting this problem. >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> > From igor.ignatyev at oracle.com Tue Oct 13 13:30:13 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 13 Oct 2015 16:30:13 +0300 Subject: RFR(XS) : 8139376 : [TESTBUG] ExecuteInstalledCodeTest should be run only on amd64 and sparcv9 Message-ID: <561D0765.2060301@oracle.com> http://cr.openjdk.java.net/~iignatyev/8139376/webrev.00/ > 1 line changed: 1 ins; 0 del; 0 mod; Hi all, please review the small fix which adds '@requires' to exclude compiler/jvmci/compilerToVM/ExecuteInstalledCodeTest from running on platforms which don't support JMVCI. webrev: http://cr.openjdk.java.net/~iignatyev/8139376/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8139376 -- Thanks, Igor From martin.doerr at sap.com Tue Oct 13 13:47:03 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 13 Oct 2015 13:47:03 +0000 Subject: RFR(S): 8138890: C1: Ambiguous operator delete In-Reply-To: References: <7C9B87B351A4BA4AA9EC95BB41811656722607B5@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672260AE1@DEWDFEMB19C.global.corp.sap> <56153267.7060401@oracle.com> <7C9B87B351A4BA4AA9EC95BB4181165672260BFB@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672261012@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB41811656722611F8@DEWDFEMB19C.global.corp.sap> <3D04808B-DB7A-4ECF-A3BF-42D5A20E2419@oracle.com> <7C9B87B351A4BA4AA9EC95BB418116567226135E@DEWDFEMB19C.global.corp.sap> Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165672261632@DEWDFEMB19C.global.corp.sap> Hi, I think this is reviewed, now. Can somebody sponsor, please? In addition, you could also push this reviewed change, too: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-October/019269.html http://cr.openjdk.java.net/~mdoerr/8138892_c1_counter_overflow/webrev.02 Thanks and best regards, Martin From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Dienstag, 13. Oktober 2015 01:10 To: Doerr, Martin Cc: hotspot compiler Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete On Oct 11, 2015, at 11:14 PM, Doerr, Martin > wrote: Hi Christian, seems like VALUE_OBJ_CLASS_SPEC inherits from _ValueObj on platforms on which the compiler uses empty base class optimization. On these platforms, the inheritance comes for free (no extra size for the object). A problem is that the macro VALUE_OBJ_CLASS_SPEC does not work for multi-inheritance because it translates to either nothing or a term which would need comma separation. That answers my question, thanks. The other class we inherit from defines new/delete operators which are not supposed to get used for this derived class, so I think making these operators private there is just the right thing to do. Best regards, Martin From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Samstag, 10. Oktober 2015 00:32 To: Doerr, Martin Cc: Volker Simonis; Lindenmaier, Goetz; Mikael Gerdin; hotspot compiler Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete On Oct 9, 2015, at 9:08 AM, Doerr, Martin > wrote: Hi Christian, I have just added comments. We can also get rid of the multi-inheritance in RanceCheckEliminator::Verification. Hmm. Why did we have it this way (not using the macro and such)? - class Verification : public _ValueObj /*VALUE_OBJ_CLASS_SPEC*/, public BlockClosure { + class Verification : public BlockClosure { The new webrev is: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.03 Best regards, Martin From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Freitag, 9. Oktober 2015 20:35 To: Doerr, Martin Cc: Volker Simonis; Lindenmaier, Goetz; Mikael Gerdin; hotspot compiler Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete On Oct 9, 2015, at 12:03 AM, Doerr, Martin > wrote: Hi, thanks for reviewing. As requested by G?tz, I just removed the second ?private?. The new webrev is here: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.02 Looks good. Can we add a comment saying that objects of this class should never be allocated on the heap or something? Best regards, Martin From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Mittwoch, 7. Oktober 2015 21:28 To: Doerr, Martin Cc: Mikael Gerdin; Christian Thalinger; hotspot compiler Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete Hi Martin, as the new/delete operators in StackObj are private (I missed that before) they shouldn't be visible in LIRGenerator. So this is probably yet another xlC bug :( On the other hand the new/delete operators in CompilationResourceObject are public and are inherited by LIRGenerator. So if we only want to generate LIRGenerator instances on the stack, your change is good, because it ensures this. And in that case we surely don't need an implementation. So thumbs up from me! Volker On Wednesday, October 7, 2015, Doerr, Martin > wrote: Hi Volker, the C1 classes we are talking about should never get instantiated by operator new. A typical way to establish this is to make the new operators private. I don?t really care if the delete operators are public or private because if the new operator is never used, how can the delete operator get used? It may be more beautiful to declare them as private as well. Only in the case G?tz has showed, some Compilers reject the private delete operators. Best regards, Martin From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Mittwoch, 7. Oktober 2015 17:57 To: Mikael Gerdin Cc: Doerr, Martin; Christian Thalinger; hotspot compiler Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete Hi Martin, we have: class LIRGenerator: public InstructionVisitor, public BlockClosure and: class BlockClosure: public CompilationResourceObj class CompilationResourceObj ALLOCATION_SUPER_CLASS_SPEC { public: void* operator new(size_t size) throw() { return Compilation::current()->arena()->Amalloc(size); } void* operator new(size_t size, Arena* arena) throw() { return arena->Amalloc(size); } void operator delete(void* p) {} // nothing to do }; class InstructionVisitor: public StackObj class StackObj ALLOCATION_SUPER_CLASS_SPEC { private: void* operator new(size_t size) throw(); void* operator new [](size_t size) throw(); #ifdef __IBMCPP__ public: #endif void operator delete(void* p); void operator delete [](void* p); Now you declare new "new()" and "delete()" operators in the LIRGenerator which will actually hide the corresponding operators from the base classes. You also provide no implementation for the new operators in LIRGenerator. So which new/delete operators will be actually used for allocating new LIRGenerator instances? OK, wait. As far as I can see, LIRGenerator is never dynamically allocated, right? In that case it should be a StackObj and you could probably solve the problem with "using" directives (e.g. using StackObj::operator new, ...). Have you tried that? Regards, Volker On Wed, Oct 7, 2015 at 4:55 PM, Mikael Gerdin > wrote: On 2015-10-07 16:17, Doerr, Martin wrote: Hi, that?s a good question J I can only remember that there were problems with some old compilers. Anyway, xlC 12.1 can deal with the private delete operators. If that's the case, can we also get rid of the workaround in allocation.hpp? Thanks /Mikael Here?s the new webrev: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.01 Best regards, Martin *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com] *Sent:* Mittwoch, 7. Oktober 2015 03:32 *To:* Doerr, Martin *Cc:* hotspot compiler *Subject:* Re: RFR(S): 8138890: C1: Ambiguous operator delete On Oct 6, 2015, at 3:56 AM, Doerr, Martin >> wrote: Hi, xlC on AIX rejects to compile LIRGenerator and RangeCheckEliminator::Verification due to ambiguous operator delete which gets inherited from multiple base classes. This change is a prerequisite for our C1 on PPC64 contribution. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.00 Let me ask my question here: why do you need the delete methods to be public on AIX? Please review this change. I need a sponsor, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue Oct 13 14:35:26 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 13 Oct 2015 22:35:26 +0800 Subject: RFR(XS) : 8139376 : [TESTBUG] ExecuteInstalledCodeTest should be run only on amd64 and sparcv9 In-Reply-To: <561D0765.2060301@oracle.com> References: <561D0765.2060301@oracle.com> Message-ID: <561D16AE.3080908@oracle.com> I don't think this is correct (we also have ppc): & os.arch != "aarch64" why you need it? Why first condition is not enough: (os.simpleArch == "x64" | os.simpleArch == "sparcv9") Thanks, Vladimir On 10/13/15 9:30 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8139376/webrev.00/ >> 1 line changed: 1 ins; 0 del; 0 mod; > > Hi all, > > please review the small fix which adds '@requires' to exclude > compiler/jvmci/compilerToVM/ExecuteInstalledCodeTest from running on > platforms which don't support JMVCI. > > webrev: http://cr.openjdk.java.net/~iignatyev/8139376/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8139376 > From zoltan.majo at oracle.com Tue Oct 13 14:41:45 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 13 Oct 2015 16:41:45 +0200 Subject: [9] RFR(S): 8080650: enable stubs to use frame pointers correctly In-Reply-To: <561CF811.3080604@oracle.com> References: <561BAAC7.9080206@oracle.com> <561BC2BC.8070005@oracle.com> <561CDD48.5000408@oracle.com> <561CF811.3080604@oracle.com> Message-ID: <561D1829.6080603@oracle.com> Hi Vladimir, On 10/13/2015 02:24 PM, Vladimir Kozlov wrote: > This seems right. > > Did you run with -XX:-UseStackBanging? Run at least jtreg tests. yes, I checked the output of PrintOptoAssembly also with -XX:-UseStackBanging and it is working as expected. I ran all JTREG hotspot tests; all tests pass that pass with and unmodified build. Thank you and best regards, Zoltan > > Thanks > Vladimir > > On 10/13/15 6:30 PM, Zolt?n Maj? wrote: >> Hi Vladimir, >> >> >> On 10/12/2015 04:25 PM, Vladimir Kozlov wrote: >>> The code which does not do stack banging seems incorrect - RSP is >>> modified before it is saved in RBP: >>> >>> subptr_imm32(rsp, framesize); >> >> you are right and thank you for catching the mistake! >> >> Here is the updated webrev: >> http://cr.openjdk.java.net/~zmajo/8080650/webrev.01/ >> >> I re-executed all JPRT tests (testset hotspot), all tests pass. >> >> Thank you and best regards, >> >> >> Zoltan >> >>> >>> Thanks, >>> Vladimir >>> >>> On 10/12/15 8:42 PM, Zolt?n Maj? wrote: >>>> Hi, >>>> >>>> >>>> please review the following patch for JDK-8080650. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080650 >>>> >>>> >>>> Problem: The following stack frame layout allows external tools (e.g., >>>> Linux perf or Solaris pstack) to determine the call chain currently on >>>> the stack: >>>> >>>> ... >>>> ======================== ^ >>>> 0x108 | return address | | caller's frame >>>> ======================== ==================== >>>> 0x100 | RBP of caller | | callee's frame >>>> ======================== v >>>> ... >>>> >>>> The example above assumes a 64-bit architecture, the addresses >>>> 0x108 and >>>> 0x100 are randomly chosen. >>>> >>>> For stack tracing to work, RBP must have the value 0x100 while >>>> execution >>>> is in the method "callee". However, when HotSpot generates code that >>>> does not need stack banging (e.g., stubs), RBP is assigned anincorrect >>>> value. For stubs, RBP is 8 bytes off the incorrect value (e.g., RBP >>>> contains the value 0x108 instead of 0x100 for the above example). >>>> >>>> >>>> Solution: Change MacroAssembler::verified_entry() to set up RBP >>>> correctly when generating stub code. Setting up RBP is now done the >>>> same >>>> way as it is done for compiled code (i.e., when stack banging is >>>> needed). >>>> >>>> Webrev: http://cr.openjdk.java.net/~zmajo/8080650/webrev.00/ >>>> >>>> Testing: >>>> - JPRT (testset hotspot), all tests pass; >>>> - locally executed all hotspot JTREG tests and all JTREG tests in >>>> jdk/test/java/lang/invoke, all tests pass that pass with an >>>> unmodified VM. >>>> >>>> >>>> Many thanks to Hongxi Sy for reporting this problem. >>>> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> >> From vladimir.kozlov at oracle.com Tue Oct 13 14:43:55 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 13 Oct 2015 22:43:55 +0800 Subject: [9] RFR(S): 8080650: enable stubs to use frame pointers correctly In-Reply-To: <561D1829.6080603@oracle.com> References: <561BAAC7.9080206@oracle.com> <561BC2BC.8070005@oracle.com> <561CDD48.5000408@oracle.com> <561CF811.3080604@oracle.com> <561D1829.6080603@oracle.com> Message-ID: <561D18AB.7080609@oracle.com> On 10/13/15 10:41 PM, Zolt?n Maj? wrote: > Hi Vladimir, > > > On 10/13/2015 02:24 PM, Vladimir Kozlov wrote: >> This seems right. >> >> Did you run with -XX:-UseStackBanging? Run at least jtreg tests. > > yes, I checked the output of PrintOptoAssembly also with > -XX:-UseStackBanging and it is working as expected. Perfect. Thank you for doing that. Vladimir > > I ran all JTREG hotspot tests; all tests pass that pass with and > unmodified build. > > Thank you and best regards, > > > Zoltan > >> >> Thanks >> Vladimir >> >> On 10/13/15 6:30 PM, Zolt?n Maj? wrote: >>> Hi Vladimir, >>> >>> >>> On 10/12/2015 04:25 PM, Vladimir Kozlov wrote: >>>> The code which does not do stack banging seems incorrect - RSP is >>>> modified before it is saved in RBP: >>>> >>>> subptr_imm32(rsp, framesize); >>> >>> you are right and thank you for catching the mistake! >>> >>> Here is the updated webrev: >>> http://cr.openjdk.java.net/~zmajo/8080650/webrev.01/ >>> >>> I re-executed all JPRT tests (testset hotspot), all tests pass. >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/12/15 8:42 PM, Zolt?n Maj? wrote: >>>>> Hi, >>>>> >>>>> >>>>> please review the following patch for JDK-8080650. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080650 >>>>> >>>>> >>>>> Problem: The following stack frame layout allows external tools (e.g., >>>>> Linux perf or Solaris pstack) to determine the call chain currently on >>>>> the stack: >>>>> >>>>> ... >>>>> ======================== ^ >>>>> 0x108 | return address | | caller's frame >>>>> ======================== ==================== >>>>> 0x100 | RBP of caller | | callee's frame >>>>> ======================== v >>>>> ... >>>>> >>>>> The example above assumes a 64-bit architecture, the addresses >>>>> 0x108 and >>>>> 0x100 are randomly chosen. >>>>> >>>>> For stack tracing to work, RBP must have the value 0x100 while >>>>> execution >>>>> is in the method "callee". However, when HotSpot generates code that >>>>> does not need stack banging (e.g., stubs), RBP is assigned anincorrect >>>>> value. For stubs, RBP is 8 bytes off the incorrect value (e.g., RBP >>>>> contains the value 0x108 instead of 0x100 for the above example). >>>>> >>>>> >>>>> Solution: Change MacroAssembler::verified_entry() to set up RBP >>>>> correctly when generating stub code. Setting up RBP is now done the >>>>> same >>>>> way as it is done for compiled code (i.e., when stack banging is >>>>> needed). >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~zmajo/8080650/webrev.00/ >>>>> >>>>> Testing: >>>>> - JPRT (testset hotspot), all tests pass; >>>>> - locally executed all hotspot JTREG tests and all JTREG tests in >>>>> jdk/test/java/lang/invoke, all tests pass that pass with an >>>>> unmodified VM. >>>>> >>>>> >>>>> Many thanks to Hongxi Sy for reporting this problem. >>>>> >>>>> Thank you and best regards, >>>>> >>>>> >>>>> Zoltan >>>>> >>> > From igor.ignatyev at oracle.com Tue Oct 13 15:26:53 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 13 Oct 2015 18:26:53 +0300 Subject: RFR(XS) : 8139376 : [TESTBUG] ExecuteInstalledCodeTest should be run only on amd64 and sparcv9 In-Reply-To: <561D16AE.3080908@oracle.com> References: <561D0765.2060301@oracle.com> <561D16AE.3080908@oracle.com> Message-ID: <561D22BD.7050009@oracle.com> Hi Vladimir, 'os.arch != "aarch64"' is a workaround for a bug in jtreg[*]. [*] https://bugs.openjdk.java.net/browse/CODETOOLS-7901514 Igor On 10/13/2015 05:35 PM, Vladimir Kozlov wrote: > I don't think this is correct (we also have ppc): > > & os.arch != "aarch64" > > why you need it? Why first condition is not enough: > (os.simpleArch == "x64" | os.simpleArch == "sparcv9") > > Thanks, > Vladimir > > On 10/13/15 9:30 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev/8139376/webrev.00/ >>> 1 line changed: 1 ins; 0 del; 0 mod; >> >> Hi all, >> >> please review the small fix which adds '@requires' to exclude >> compiler/jvmci/compilerToVM/ExecuteInstalledCodeTest from running on >> platforms which don't support JMVCI. >> >> webrev: http://cr.openjdk.java.net/~iignatyev/8139376/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8139376 >> From zoltan.majo at oracle.com Tue Oct 13 15:42:59 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 13 Oct 2015 17:42:59 +0200 Subject: [9] RFR(S): 8080650: enable stubs to use frame pointers correctly In-Reply-To: <561D18AB.7080609@oracle.com> References: <561BAAC7.9080206@oracle.com> <561BC2BC.8070005@oracle.com> <561CDD48.5000408@oracle.com> <561CF811.3080604@oracle.com> <561D1829.6080603@oracle.com> <561D18AB.7080609@oracle.com> Message-ID: <561D2683.9060608@oracle.com> Thank you reviewing this, Vladimir! Best regards, Zoltan On 10/13/2015 04:43 PM, Vladimir Kozlov wrote: > On 10/13/15 10:41 PM, Zolt?n Maj? wrote: >> Hi Vladimir, >> >> >> On 10/13/2015 02:24 PM, Vladimir Kozlov wrote: >>> This seems right. >>> >>> Did you run with -XX:-UseStackBanging? Run at least jtreg tests. >> >> yes, I checked the output of PrintOptoAssembly also with >> -XX:-UseStackBanging and it is working as expected. > > Perfect. Thank you for doing that. > > Vladimir > >> >> I ran all JTREG hotspot tests; all tests pass that pass with and >> unmodified build. >> >> Thank you and best regards, >> >> >> Zoltan >> >>> >>> Thanks >>> Vladimir >>> >>> On 10/13/15 6:30 PM, Zolt?n Maj? wrote: >>>> Hi Vladimir, >>>> >>>> >>>> On 10/12/2015 04:25 PM, Vladimir Kozlov wrote: >>>>> The code which does not do stack banging seems incorrect - RSP is >>>>> modified before it is saved in RBP: >>>>> >>>>> subptr_imm32(rsp, framesize); >>>> >>>> you are right and thank you for catching the mistake! >>>> >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~zmajo/8080650/webrev.01/ >>>> >>>> I re-executed all JPRT tests (testset hotspot), all tests pass. >>>> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/12/15 8:42 PM, Zolt?n Maj? wrote: >>>>>> Hi, >>>>>> >>>>>> >>>>>> please review the following patch for JDK-8080650. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080650 >>>>>> >>>>>> >>>>>> Problem: The following stack frame layout allows external tools >>>>>> (e.g., >>>>>> Linux perf or Solaris pstack) to determine the call chain >>>>>> currently on >>>>>> the stack: >>>>>> >>>>>> ... >>>>>> ======================== ^ >>>>>> 0x108 | return address | | caller's frame >>>>>> ======================== ==================== >>>>>> 0x100 | RBP of caller | | callee's frame >>>>>> ======================== v >>>>>> ... >>>>>> >>>>>> The example above assumes a 64-bit architecture, the addresses >>>>>> 0x108 and >>>>>> 0x100 are randomly chosen. >>>>>> >>>>>> For stack tracing to work, RBP must have the value 0x100 while >>>>>> execution >>>>>> is in the method "callee". However, when HotSpot generates code that >>>>>> does not need stack banging (e.g., stubs), RBP is assigned >>>>>> anincorrect >>>>>> value. For stubs, RBP is 8 bytes off the incorrect value (e.g., RBP >>>>>> contains the value 0x108 instead of 0x100 for the above example). >>>>>> >>>>>> >>>>>> Solution: Change MacroAssembler::verified_entry() to set up RBP >>>>>> correctly when generating stub code. Setting up RBP is now done the >>>>>> same >>>>>> way as it is done for compiled code (i.e., when stack banging is >>>>>> needed). >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~zmajo/8080650/webrev.00/ >>>>>> >>>>>> Testing: >>>>>> - JPRT (testset hotspot), all tests pass; >>>>>> - locally executed all hotspot JTREG tests and all JTREG tests in >>>>>> jdk/test/java/lang/invoke, all tests pass that pass with an >>>>>> unmodified VM. >>>>>> >>>>>> >>>>>> Many thanks to Hongxi Sy for reporting this problem. >>>>>> >>>>>> Thank you and best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>>> >>>> >> From roland.westrelin at oracle.com Tue Oct 13 16:00:46 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 13 Oct 2015 18:00:46 +0200 Subject: RFR: 8139259: aarch64: jtreg test TestLogSum segvs after 8132207 In-Reply-To: <6E7C7761-DD7B-4CCB-AE6D-0ADA27385F83@oracle.com> References: <1444389470.23861.23.camel@mint> <8AF4C615-5E7A-425E-8883-5E7ECE2669E7@oracle.com> <6E7C7761-DD7B-4CCB-AE6D-0ADA27385F83@oracle.com> Message-ID: <26E9A4E5-3C55-4CB3-96FA-7783A02DBCDA@oracle.com> > This seems one of parts of the P1 blocker (https://bugs.openjdk.java.net/browse/JDK-8139454). Roland, could you please push this (at least the library_call.cpp part)? Sure. It?s in. Roland. From aph at redhat.com Tue Oct 13 16:38:08 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 13 Oct 2015 17:38:08 +0100 Subject: AARCH64: 8139041: Redundant DMB instructions (CORRECTED ) In-Reply-To: <56186321.6010505@oracle.com> References: <561505E4.207@redhat.com> <5617DF32.4090508@redhat.com> <56186321.6010505@oracle.com> Message-ID: <561D3370.6050503@redhat.com> On 10/10/2015 02:00 AM, Vladimir Kozlov wrote: > On 10/10/15 2:47 AM, Christian Thalinger wrote: >> >>> On Oct 9, 2015, at 5:37 AM, Andrew Haley wrote: >>> >>> Hi, >>> >>> On 10/09/2015 03:59 PM, Roland Westrelin wrote: >>> >>>>> There is a much simpler way: remove adjacent barriers in >>>>> MacroAssembler. Thanks to the way that the AArch64 ISA is designed, >>>>> barriers can be merged simply by ORing them together. Of course, this >>>>> technique works for C1 and C2, and it adds essentially nothing to the >>>>> compilation time. >>>>> >>>>> http://cr.openjdk.java.net/~aph/8139041/ >>>>> >>>>> One thing which may be controversial is that I've added a field to >>>>> CodeBuffer to keep track of barriers and labels. I had to do this >>>>> because when we're compiling there is (AFAICS) essentially nowhere >>>>> else to keep the state. >> >> I don?t think it matters to have an additional field in CodeBuffer. It?s a temporary data structure and we use much more memory for graphs. >> >> I would even go that far and questioning putting it under #ifdef AARCH64. > > +1 that. OK. I'm guessing that PPC will want to use this anyway. http://cr.openjdk.java.net/~aph/8139041-2 Andrew. From pavel.punegov at oracle.com Tue Oct 13 16:44:42 2015 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Tue, 13 Oct 2015 19:44:42 +0300 Subject: RFR(L): 8066153: JEP-JDK-8046155: Test task: cover existing In-Reply-To: <5615C7C9.7030604@oracle.com> References: <5609334B.7050200@oracle.com> <5614886B.9050508@oracle.com> <56156920.2020405@oracle.com> <5615C7C9.7030604@oracle.com> Message-ID: <561D34FA.9020501@oracle.com> Hi all, please review a new version of tests: http://cr.openjdk.java.net/~ppunegov/8066153/webrev.01/ Most changes were made to Scenario and DirectiveBuilder classes to reflect recent changes made by Nils. VM fails with error message if user supplied incorrect directive, so Scenario was changed to handle both correct and incorrect directives. Multiple refactoring and cleaning were also made to the code: - Move directive file writing from the DirectiveBuilder into the new class DirectiveWriter. - Add random generators for CompileCommand and methods - All scenario related enums are moved to Scenario. - Cleaned code in directive building. On 08.10.2015 04:32, Vladimir Kozlov wrote: > Got it. Okay then. > > Thanks, > Vladimir > > On 10/8/15 2:49 AM, Pavel Punegov wrote: >> Thank you, Vladimir. >> >> LogCompilation output processing will signal failure only if we found >> that the method was printed when it should not be. >> It won't fail if there are no methods that should be printed at all, or >> there is a broken output that just wouldn't match regexps. >> >> On 07.10.2015 05:50, Vladimir Kozlov wrote: >>> We have test problems with parsing output of LogCompilation and other >>> outputs because it could be cut off. I would prefer adding new WB >>> events API to record interesting events. >>> Otherwise seems fine. Nils should look on this to make sure all >>> paths/flags are tested. >>> >>> Thanks, >>> Vladimir >>> >>> On 9/28/15 8:32 PM, Pavel Punegov wrote: >>>> Hi, >>>> >>>> please review the following tests fro JEP 165 Compiler Control. >>>> These tests cover both CompileCommand and new directives (through >>>> CompileDirectivesFile). >>>> >>>> The main idea of tests is to create a one or multiple commands or >>>> directives for methods in the pool and execute a test VM with a set of >>>> method states (should method be compiled, inlined, printed, etc.). On >>>> the end test checks that only correct methods are logged with >>>> LogCompilation, or printed via PrintAssembly. >>>> >>>> Bugs: >>>> https://bugs.openjdk.java.net/browse/JDK-8066153 >>>> https://bugs.openjdk.java.net/browse/JDK-8066165 >>>> >>>> webrev: http://cr.openjdk.java.net/~ppunegov/8066153/webrev.00/ >>>> >> -- Thanks, Pavel Punegov From pavel.punegov at oracle.com Tue Oct 13 17:12:35 2015 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Tue, 13 Oct 2015 20:12:35 +0300 Subject: RFR(M): 8066166: JEP-JDK-8046155: Test task: dcmd tests Message-ID: <561D3B83.8010307@oracle.com> Please review the following tests for diagnostic commands in CompilerControl. This change extend the previous tests for CC with ability to add, remove or clear directives with diagnostic command. Each test generates one or several commands and directive file, then executes another VM, which will be used as a target VM for JCMD. After the test performed all diagnostic commands, the test VM will check that all methods are compiled or not in the same way it was done before. webrev: http://cr.openjdk.java.net/~ppunegov/8066166/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8066166 -- Thanks, Pavel Punegov From nils.eliasson at oracle.com Tue Oct 13 17:16:07 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 13 Oct 2015 19:16:07 +0200 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: <5616709C.809@oracle.com> References: <56018E2B.2000108@oracle.com> <5614F60D.3040602@oracle.com> <56151DCE.90407@oracle.com> <56165D2A.7010407@oracle.com> <5616709C.809@oracle.com> Message-ID: <561D3C57.4010408@oracle.com> Hi Zoltan, Thanks for the feedback. The JDK webrev is here: http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.02/ I have fixed the comment too and will update the hotspot webrev shortly. Thanks, Nils On 2015-10-08 15:33, Zolt?n Maj? wrote: > Hi Nils, > > > On 10/08/2015 02:10 PM, Nils Eliasson wrote: >> Hi Zoltan, >> >> Thanks for the repro. Found a bug where the base directives got >> corrupted. Added test cases to the >> TestCompilerDirectivesCompatibility* which will cover that. > > Thank you for fixing the problem with the DisableIntrinsic flag (the > flag works now as expected). > > I've spotted two other small problems: > > 1) src/share/vm/compiler/abstractCompiler.hpp > > 72 // - the intrinsic is enabled (by using the appropriate > command-line flag > 73 // , the command-line compile ommand, or a compiler directive) > > The comma on line 73 should be at the end of line 72. > > 2) In your JDK changes (I've looked at webrev_jdk.01, as I think there > is no newer version): You have not declared the > sun.hotspot.WhiteBox::shouldPrintAssembly(Ljava/lang/reflect/Executable;)Z > method. As a result the VM is complaining if the WhiteBox API is enabled: > > Warning: 'NoSuchMethodError' on register of > sun.hotspot.WhiteBox::shouldPrintAssembly(Ljava/lang/reflect/Executable;)Z > > > Thank you and best regards, > > > Zoltan > >> >> New webrev: >> http://cr.openjdk.java.net/~neliasso/8046155/webrev.10/ >> >> Best regards, >> Nils >> >> >> On 2015-10-07 15:27, Zolt?n Maj? wrote: >>> Hi Nils, >>> >>> >>> On 10/07/2015 12:38 PM, Nils Eliasson wrote: >>>> Hi all, >>>> >>>> Latest webrev including fixes after comments from Chris and Zoltan: >>>> http://cr.openjdk.java.net/~neliasso/8046155/webrev.09/ >>> >>> thank you for the updated version. It seems, however, that the >>> DisableIntrinsic flag does not work correctly on the per-method level. >>> >>> If I execute the MathTest program I've sent out before with the >>> command-line option >>> >>> -XX:CompileCommand=option,MathTest::test1,ccstr,DisableIntrinsic,_dsin >>> >>> with jdk9-b83, I get the expected behavior (Math.sin is inlined into >>> test2 but not into test1): >>> >>> 128 1 b 3 MathTest::test1 (7 bytes) >>> @ 3 java.lang.Math::sin (5 bytes) >>> @ 1 java/lang/StrictMath::sin (not >>> loaded) not inlineable >>> 130 2 n 0 java.lang.StrictMath::sin (native) (static) >>> 132 3 b 3 MathTest::test2 (7 bytes) >>> @ 3 java.lang.Math::sin (5 bytes) >>> intrinsic >>> >>> >>> If I execute the test case with a locally-built jdk patched with >>> webrev.09, I get an erronous behavior (Math.sin is not inlined into >>> test2 although it should be): >>> >>> 133 1 b 3 MathTest::test1 (7 bytes) >>> @ 3 java.lang.Math::sin (5 bytes) >>> @ 1 java/lang/StrictMath::sin (not >>> loaded) not inlineable >>> 136 2 n 0 java.lang.StrictMath::sin (native) (static) >>> 138 3 b 3 MathTest::test2 (7 bytes) >>> @ 3 java.lang.Math::sin (5 bytes) >>> @ 1 java.lang.StrictMath::sin (0 >>> bytes) native method >>> >>> Could you please check why that happens? >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> >>> >>> >>>> >>>> Regards, >>>> //Nils >>>> >>>> >>>> >>>> On 2015-09-22 19:21, Nils Eliasson wrote: >>>> > Hi, > > This is the initial RFR for JEP165: Compiler Control. >>>> This feature > enables runtime manageable, method dependent >>>> compiler flags. > (Immutable for the duration of a compilation.) > >>>> > The change includes: - A parser for the directives format (json >>>> like) > including vmtests (json.cpp/hpp) - A component for >>>> construction of > compiler directives (directivesParser.cpp/hpp) - >>>> The directives > including the option definitions, default values >>>> and compilecommand > relations (compilerDirectives.cpp/hpp) - >>>> Diagnostic commands for > working with the directives - installing, >>>> removing, printing - Lots > of small changes wherever we access >>>> flags or legacy compilecommands > in the compiler > > Notes: The >>>> feature is documented in the JEP > >>>> (https://bugs.openjdk.java.net/browse/JDK-8046155). > > Currently >>>> only a small amount of compiler flags are included in the > change. >>>> The flags are a representative selection of different types > >>>> targeting both compilers. All of them existed as CompilerOracle > >>>> option commands. Two commands was not included in the directives >>>> due > to time constraints - CompilerThresholdScaling and >>>> UseRTMLocks. Both > are accessed from runtime (outside any >>>> compiler) and requires some > special handling. (Solved but not >>>> implemented.) > > Full backwards compatibility with CompileCommands >>>> is implemented but > can be turned off with flag >>>> -XX:CompileCommandCompatibilty. Also meta > handling the >>>> compatibility flag by supporting it in the directives > (test >>>> feature). > > The change contain some rough edges that will >>>> polished over the > coming days. > > JEP: >>>> https://bugs.openjdk.java.net/browse/JDK-8046155 Hotspot webrev: > >>>> http://cr.openjdk.java.net/~neliasso/8046155/webrev.01/ JDK webrev: >>>> > http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.01/ > > >>>> Please review! > > Best regards, Nils Eliasson >>>> >>>> >>> >> > From christian.thalinger at oracle.com Tue Oct 13 17:32:49 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 13 Oct 2015 07:32:49 -1000 Subject: RFR (XL): 8139170: JVMCI refresh In-Reply-To: <561C863D.7080800@oracle.com> References: <6ECC12F2-8693-43AD-8F08-B7E3F21AEB40@oracle.com> <561C863D.7080800@oracle.com> Message-ID: > On Oct 12, 2015, at 6:19 PM, Vladimir Kozlov wrote: > > Since we will get more changes from labs later we may enumerate them: JVMCI refresh 1. This will be the only universal refresh. If there is something later that needs to be fixed we will have separate bugs or enhancements. > > Can you explain new sed command in Gensrc-jdk.vm.ci.gmk. Are you sure it works on windows? > > Instead of is_trivial(method) may be we should have general function called from AdvancedThresholdPolicy::common() which return compilation level for particular method (for example, we can also limit it using compilecommand). Could be done as separate change after this. > > I looked on jdk.vm.ci changes and nothing looks terrible wrong. I am not familiar with it so I can't say that each line is correct. One thing I am wondering is why explicit imports are used instead of .* (compilation speed?): > > -import java.lang.annotation.*; > +import java.lang.annotation.ElementType; > +import java.lang.annotation.Retention; > +import java.lang.annotation.RetentionPolicy; > +import java.lang.annotation.Target; > > An other thing is using AMD64/amd64 in files and directory names. May be we should rename it to x64. No. The official name of this architecture is x86_64. Java?s os.arch returns amd64 and (unfortunately) x86_64 on Mac OS X. > > jvmciCodeInstaller_x86.cpp and jvmciCodeInstaller.cpp has next pattern: > + if (HotSpotMetaspaceConstantImpl::compressed(constant)) { > +#ifdef _LP64 > + ... > +#else > + fatal("unexpected compressed Klass* in 32-bit mode"); > +#endif > + } else { > > It would be nice to hide fatal() in some wrapper function. > > jvmciEnv.cpp use ASSERT instead of DEBUG. We renamed ifdef DEBUG long ago. Yes, I noticed that too. Will change to ASSERT. > > globals.hpp changes conflict with 8139377. > > Tests changes (mostly renaming) looks fine. > > Fix copyright years (2015, 2015) in new files. Will fix that. > > Thanks, > Vladimir > > On 10/13/15 10:19 AM, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8139170 >> http://cr.openjdk.java.net/~twisti/8139170/webrev/ >> >> During the review period for JEP 243 there were some changes and enhancements to the JVMCI code done by Oracle Labs. In order to not disturb the already long and complicated review of JEP 243 we decided to do a refresh after the initial integration. >> >> A lot of the Java changes is switching to using explicit imports. >> From jan.civlin at intel.com Tue Oct 13 17:57:30 2015 From: jan.civlin at intel.com (Civlin, Jan) Date: Tue, 13 Oct 2015 17:57:30 +0000 Subject: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. In-Reply-To: References: <39F83597C33E5F408096702907E6C45005879107@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C450058791D0@ORSMSX104.amr.corp.intel.com> Message-ID: <39F83597C33E5F408096702907E6C45005879240@ORSMSX104.amr.corp.intel.com> Vladimir, the updated webrev is at http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.01/ Thank you, Igor. Best, Jan. -----Original Message----- From: Igor Veresov [mailto:igor.veresov at oracle.com] Sent: Tuesday, October 13, 2015 10:51 AM To: Civlin, Jan Cc: Vladimir Kozlov Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. Done. > On Oct 13, 2015, at 9:51 AM, Civlin, Jan wrote: > > Igor, > > I got a response from the moderator that the previous message (attached below) has been rejected due to the size limits. > Please upload the attached webrev (I guess it will be > http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.01/) > > And I'll send the link to the group. > > Thank you, > > Jan. > > -----Original Message----- > From: Civlin, Jan > Sent: Monday, October 12, 2015 10:19 PM > To: Vladimir Kozlov > Cc: Igor Veresov; hotspot compiler; Civlin, Jan > Subject: RE: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. > > Vladimir, > > Here is a webrev built from a single changeset. > Please use it for further reviewing. > > Thank you, > > Jan. > > -----Original Message----- > From: Civlin, Jan > Sent: Saturday, October 10, 2015 12:14 PM > To: Vladimir Kozlov > Cc: hotspot compiler > Subject: RE: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. > > Vladimir, > > Thank you for the quick review. > > > I thought you are patching your repo using hotspot.patch which is clean of empty files or .hgtag and you use webrev only for facilitation of visual code review. > If you use hotspot.patch it does not propagate to your repo empty or already integrated in 8136725 files or my repo tags, since none of them are in the patch. > I thought you are simply skipping unchanged files if you see them in webrev html pages. > > My repo is a consistent and long living clone of your repo. It is a single place that includes the history of all my changes, which let me go ahead in development way far of what is ready for going out to you. I can create an additional repo and filter out my tags on way out, but it will create more possibilities for accidental errors. > > > x86.ad: it is indeed not (yet) AVX3, since AVX3 will have different ISA. Once we have AVX3 in the house and can debug it, AVX3 case will be added. > > c2_globals.hpp: > I will rename the flag to UseCMoveUnconditionally, but I see no point of having another flag for the vector: once SuperWord detects CMovD, it merely vectorize it. > In the opposite direction: one cannot ask for vectorization of CMovD and not to get them in the scalar case. > > compile.cpp: > 1114: will add "do_vector_loop() &&" and change to NOT_PRODUCT(if > (do_vector_loop() && Verbose&& && has_method()) > {tty->print("Compile::Init: use CMove without profitability tests for > method %s\n", method()->name()->as_quoted_ascii());}) > > loopopts.cpp: > 601: will add "&& cmp_op == Op_CmpD" and change to if (C->use_cmove() > && cmp_op == Op_CmpD) ;//keep going > > > Thank you, > > Jan > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Saturday, October 10, 2015 5:52 AM > To: Civlin, Jan > Cc: hotspot compiler > Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. > > Changes contains also 8136725 (loop reserve copy) changes. Please, clean up. > > x86.ad WAIT! According to next conditions (BTW, support condition should match predicate) this is only supported with AVX1 and AVX2 and not AVX3. Really? > > I think it should be reversed condition (< 3): > + case Op_CMoveVD: > + if (UseAVX > 2) > + ret_value = false; > > + instruct vcmov4D_reg(vecY dst, vecY src1, vecY src2, immI8 cop, > cmpOp_vcmppd copnd) %{ > + predicate(UseAVX > 0 && UseAVX < 3 && n->as_Vector()->length() == > + 4); > > > x86_64.ad changes are empty (could be only spacing change) so remove it from change. > > c2_globals.hpp DoReserveCopyInSuperWord is defined in 8136725 changes. > UseCMov should be UseCMoveUnconditionally I think (note 'move' instead > of 'mov'). Also I am not sure that you should mix 2 things into this > changes: one is vectorizing cmoveD (for doubles) and always generate cmoves. I think it is different issues and this change should concentrate on vectorizing only double cmoves. Then flag could be VectorizeCMoveD. > > compile.cpp print not under UseCmov flag: > + NOT_PRODUCT(if (Verbose && has_method()) {tty->print("Compile::Init: > use CMove without profitability tests for method %s\n", > method()->name()->as_quoted_ascii());}) > > loopopts.cpp changes inconsistent. In one place you check use_cmove only for doubles and in other for all. > > I will look on superword changes after you cleanup changes: remove > 8136725 and also create history from fresh repo - I don't want to see 50 revisions descriptions in webrev. > > Thanks, > Vladimir > > On 10/10/15 7:04 AM, Civlin, Jan wrote: >> Please review this patch. >> >> Hi All, >> >> >> We would like to contribute the SuperWord enhancement to support >> vector conditional move (CMovVD ) on Intel AVX cpu. >> >> >> The contribution Bug ID: 8139340. >> >> Please review this patch: >> >> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8139340 >> >> webrev: http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ >> >> Description: >> >> SuperWord enhancement to support vector conditional move (CMovVD) on >> Intel AVX cpu. >> >> The SuperWord optimization bails out on counted loops that contain >> any conditional statement other than the loop exit, and this prevents >> vectorization of many compute bound loops. >> >> The proposed enhancement enables generation of CMovD on demand >> (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD ) in >> SuperWord optimization. >> >> The performance gain observed on a simplified Monte Carlo Option >> Calculation was up to 2x speed-up. >> >> Thank you, >> >> Jan. >> >> *From:*Igor Veresov [mailto:igor.veresov at oracle.com] >> *Sent:* Friday, October 9, 2015 3:22 PM >> *To:* Civlin, Jan >> *Cc:* hotspot compiler; Vladimir Kozlov >> *Subject:* Re: SuperWord enhancement to support vector conditional >> move (CMovVD ) on Intel AVX cpu. >> >> Here it is: https://bugs.openjdk.java.net/browse/JDK-8139340 >> >> igor >> >> On Oct 9, 2015, at 2:57 PM, Civlin, Jan > > wrote: >> >> Thank you, Igor. >> >> What is the RFR for this? >> >> *From:*Igor Veresov [mailto:igor.veresov at oracle.com] >> *Sent:*Friday, October 9, 2015 2:53 PM >> *To:*Civlin, Jan >> *Cc:*hotspot compiler; Vladimir Kozlov >> *Subject:*Re: SuperWord enhancement to support vector conditional >> move (CMovVD ) on Intel AVX cpu. >> >> Here the webrev: >> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ >> >> igor >> >> On Oct 9, 2015, at 1:15 PM, Civlin, Jan > > wrote: >> >> Igor, >> >> Please create RFR and upload this patch. You may need to rename >> ancnav.js.remove_this_extention back to ancnav.js (I have to >> rename it for passing the mail server filters). >> >> Description: >> >> SuperWord enhancement to support vector conditional move >> (CMovVD) on Intel AVX cpu. >> >> The SuperWord optimization bails out on counted loops that >> contain any conditional statement other than the loop exit, and >> this prevents vectorization of many compute bound loops. >> >> The proposed enhancement enables generation of CMovD on demand >> (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD >> ) in SuperWord optimization. >> >> The performance gain observed on a simplified Monte Carlo Option >> Calculation was up to 2x speed-up. >> >> Thank you, >> >> Jan. >> >> >> > From christian.thalinger at oracle.com Tue Oct 13 18:01:31 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 13 Oct 2015 08:01:31 -1000 Subject: RFR (XL): 8139170: JVMCI refresh In-Reply-To: References: <6ECC12F2-8693-43AD-8F08-B7E3F21AEB40@oracle.com> <561C863D.7080800@oracle.com> Message-ID: <48004E32-6D60-4E40-9FF0-F0E4148D0344@oracle.com> > On Oct 12, 2015, at 10:59 PM, Doug Simon wrote: > >> >> On 13 Oct 2015, at 06:19, Vladimir Kozlov > wrote: >> >> Since we will get more changes from labs later we may enumerate them: JVMCI refresh 1. > > Or, pessimistically, JVMCI refresh 01 ;-) > >> Can you explain new sed command in Gensrc-jdk.vm.ci.gmk. > > http://hg.openjdk.java.net/graal/graal-jvmci-8/rev/1852abfbaca3 > >> Are you sure it works on windows? > > I can?t say for sure but given that I see similar patterns in other *.gmk files, I think it should be fine. It would be good if we would run at least one JVMCI test in JPRT. > >> Instead of is_trivial(method) may be we should have general function called from AdvancedThresholdPolicy::common() which return compilation level for particular method (for example, we can also limit it using compilecommand). Could be done as separate change after this. >> >> I looked on jdk.vm.ci changes and nothing looks terrible wrong. I am not familiar with it so I can't say that each line is correct. One thing I am wondering is why explicit imports are used instead of .* (compilation speed?): > > http://mail.openjdk.java.net/pipermail/graal-dev/2015-September/003546.html > >> -import java.lang.annotation.*; >> +import java.lang.annotation.ElementType; >> +import java.lang.annotation.Retention; >> +import java.lang.annotation.RetentionPolicy; >> +import java.lang.annotation.Target; >> >> An other thing is using AMD64/amd64 in files and directory names. May be we should rename it to x64. >> >> jvmciCodeInstaller_x86.cpp and jvmciCodeInstaller.cpp has next pattern: >> + if (HotSpotMetaspaceConstantImpl::compressed(constant)) { >> +#ifdef _LP64 >> + ... >> +#else >> + fatal("unexpected compressed Klass* in 32-bit mode"); >> +#endif >> + } else { >> >> It would be nice to hide fatal() in some wrapper function. >> >> jvmciEnv.cpp use ASSERT instead of DEBUG. We renamed ifdef DEBUG long ago. >> >> globals.hpp changes conflict with 8139377. > > Then we should adopt 8139377 instead. When I created the review 8139377 was not integrated yet. Let me pull again. > >> Tests changes (mostly renaming) looks fine. >> >> Fix copyright years (2015, 2015) in new files. >> >> Thanks, >> Vladimir >> >> On 10/13/15 10:19 AM, Christian Thalinger wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8139170 >>> http://cr.openjdk.java.net/~twisti/8139170/webrev/ >>> >>> During the review period for JEP 243 there were some changes and enhancements to the JVMCI code done by Oracle Labs. In order to not disturb the already long and complicated review of JEP 243 we decided to do a refresh after the initial integration. >>> >>> A lot of the Java changes is switching to using explicit imports. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Tue Oct 13 18:31:28 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 13 Oct 2015 08:31:28 -1000 Subject: RFR (XL): 8139170: JVMCI refresh In-Reply-To: <48004E32-6D60-4E40-9FF0-F0E4148D0344@oracle.com> References: <6ECC12F2-8693-43AD-8F08-B7E3F21AEB40@oracle.com> <561C863D.7080800@oracle.com> <48004E32-6D60-4E40-9FF0-F0E4148D0344@oracle.com> Message-ID: webrev updated. > On Oct 13, 2015, at 8:01 AM, Christian Thalinger wrote: > >> >> On Oct 12, 2015, at 10:59 PM, Doug Simon > wrote: >> >>> >>> On 13 Oct 2015, at 06:19, Vladimir Kozlov > wrote: >>> >>> Since we will get more changes from labs later we may enumerate them: JVMCI refresh 1. >> >> Or, pessimistically, JVMCI refresh 01 ;-) >> >>> Can you explain new sed command in Gensrc-jdk.vm.ci.gmk. >> >> http://hg.openjdk.java.net/graal/graal-jvmci-8/rev/1852abfbaca3 >> >>> Are you sure it works on windows? >> >> I can?t say for sure but given that I see similar patterns in other *.gmk files, I think it should be fine. > > It would be good if we would run at least one JVMCI test in JPRT. > >> >>> Instead of is_trivial(method) may be we should have general function called from AdvancedThresholdPolicy::common() which return compilation level for particular method (for example, we can also limit it using compilecommand). Could be done as separate change after this. >>> >>> I looked on jdk.vm.ci changes and nothing looks terrible wrong. I am not familiar with it so I can't say that each line is correct. One thing I am wondering is why explicit imports are used instead of .* (compilation speed?): >> >> http://mail.openjdk.java.net/pipermail/graal-dev/2015-September/003546.html >> >>> -import java.lang.annotation.*; >>> +import java.lang.annotation.ElementType; >>> +import java.lang.annotation.Retention; >>> +import java.lang.annotation.RetentionPolicy; >>> +import java.lang.annotation.Target; >>> >>> An other thing is using AMD64/amd64 in files and directory names. May be we should rename it to x64. >>> >>> jvmciCodeInstaller_x86.cpp and jvmciCodeInstaller.cpp has next pattern: >>> + if (HotSpotMetaspaceConstantImpl::compressed(constant)) { >>> +#ifdef _LP64 >>> + ... >>> +#else >>> + fatal("unexpected compressed Klass* in 32-bit mode"); >>> +#endif >>> + } else { >>> >>> It would be nice to hide fatal() in some wrapper function. >>> >>> jvmciEnv.cpp use ASSERT instead of DEBUG. We renamed ifdef DEBUG long ago. >>> >>> globals.hpp changes conflict with 8139377. >> >> Then we should adopt 8139377 instead. > > When I created the review 8139377 was not integrated yet. Let me pull again. > >> >>> Tests changes (mostly renaming) looks fine. >>> >>> Fix copyright years (2015, 2015) in new files. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/13/15 10:19 AM, Christian Thalinger wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8139170 >>>> http://cr.openjdk.java.net/~twisti/8139170/webrev/ >>>> >>>> During the review period for JEP 243 there were some changes and enhancements to the JVMCI code done by Oracle Labs. In order to not disturb the already long and complicated review of JEP 243 we decided to do a refresh after the initial integration. >>>> >>>> A lot of the Java changes is switching to using explicit imports. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Tue Oct 13 18:49:39 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 13 Oct 2015 08:49:39 -1000 Subject: RFR (XS): 8139524: JVMCI cannot be initialized with CMS or Serial GCs Message-ID: https://bugs.openjdk.java.net/browse/JDK-8139524 The fix is to handle the BarrierSet kind correctly. diff -r 0ca52fb7d980 src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java --- a/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java Tue Sep 29 17:01:37 2015 +0000 +++ b/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java Tue Oct 13 08:47:05 2015 -1000 @@ -86,13 +86,11 @@ public class HotSpotVMConfig { final long barrierSetAddress = UNSAFE.getAddress(universeCollectedHeap + collectedHeapBarrierSetOffset); final int kind = UNSAFE.getInt(barrierSetAddress + barrierSetFakeRttiOffset + fakeRttiConcreteTagOffset); - if ((kind == barrierSetCardTableModRef) || (kind == barrierSetCardTableExtension) || (kind == barrierSetG1SATBCT) || (kind == barrierSetG1SATBCTLogging)) { + if ((kind == barrierSetCardTableModRef) || (kind == barrierSetCardTableForRS) || (kind == barrierSetCardTableExtension) || (kind == barrierSetG1SATBCT) || (kind == barrierSetG1SATBCTLogging)) { final long base = UNSAFE.getAddress(barrierSetAddress + cardTableModRefBSByteMapBaseOffset); assert base != 0 : "unexpected byte_map_base: " + base; cardtableStartAddress = base; cardtableShift = cardTableModRefBSCardShift; - } else if (kind == barrierSetCardTableForRS) { - throw JVMCIError.unimplemented(); } else if (kind == barrierSetModRef) { // No post barriers cardtableStartAddress = 0; -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Tue Oct 13 19:02:38 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 13 Oct 2015 09:02:38 -1000 Subject: RFR (XS): 8139558 [JVMCI] SPARC hits: guarantee(heap_end < allocation_end) failed: heap end too close to end of address space (might lead to erroneous TLAB allocations) Message-ID: https://bugs.openjdk.java.net/browse/JDK-8139558 This assert can trigger trivially on SPARC so we have to disable it. diff -r 0ca52fb7d980 src/share/vm/jvmci/jvmciRuntime.cpp --- a/src/share/vm/jvmci/jvmciRuntime.cpp Tue Sep 29 17:01:37 2015 +0000 +++ b/src/share/vm/jvmci/jvmciRuntime.cpp Tue Oct 13 09:02:29 2015 -1000 @@ -778,9 +778,11 @@ JVM_ENTRY(void, JVM_RegisterJVMCINatives } #ifdef _LP64 +#ifndef TARGET_ARCH_sparc uintptr_t heap_end = (uintptr_t) Universe::heap()->reserved_region().end(); uintptr_t allocation_end = heap_end + ((uintptr_t)16) * 1024 * 1024 * 1024; guarantee(heap_end < allocation_end, "heap end too close to end of address space (might lead to erroneous TLAB allocations)"); +#endif // TARGET_ARCH_sparc #else fatal("check TLAB allocation code for address space conflicts"); #endif -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Tue Oct 13 19:07:15 2015 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 13 Oct 2015 12:07:15 -0700 Subject: RFR (XS): 8139558 [JVMCI] SPARC hits: guarantee(heap_end < allocation_end) failed: heap end too close to end of address space (might lead to erroneous TLAB allocations) In-Reply-To: References: Message-ID: <963BB2E7-DA2D-4CA7-8901-F2EEE46B6F9C@oracle.com> Looks good. igor > On Oct 13, 2015, at 12:02 PM, Christian Thalinger wrote: > > https://bugs.openjdk.java.net/browse/JDK-8139558 > > This assert can trigger trivially on SPARC so we have to disable it. > > diff -r 0ca52fb7d980 src/share/vm/jvmci/jvmciRuntime.cpp > --- a/src/share/vm/jvmci/jvmciRuntime.cpp Tue Sep 29 17:01:37 2015 +0000 > +++ b/src/share/vm/jvmci/jvmciRuntime.cpp Tue Oct 13 09:02:29 2015 -1000 > @@ -778,9 +778,11 @@ JVM_ENTRY(void, JVM_RegisterJVMCINatives > } > > #ifdef _LP64 > +#ifndef TARGET_ARCH_sparc > uintptr_t heap_end = (uintptr_t) Universe::heap()->reserved_region().end(); > uintptr_t allocation_end = heap_end + ((uintptr_t)16) * 1024 * 1024 * 1024; > guarantee(heap_end < allocation_end, "heap end too close to end of address space (might lead to erroneous TLAB allocations)"); > +#endif // TARGET_ARCH_sparc > #else > fatal("check TLAB allocation code for address space conflicts"); > #endif > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Tue Oct 13 19:07:39 2015 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 13 Oct 2015 12:07:39 -0700 Subject: RFR (XS): 8139524: JVMCI cannot be initialized with CMS or Serial GCs In-Reply-To: References: Message-ID: <3CAA7BFE-6814-4CC9-A1F5-0DA0022B99A8@oracle.com> Seems alright. igor > On Oct 13, 2015, at 11:49 AM, Christian Thalinger wrote: > > https://bugs.openjdk.java.net/browse/JDK-8139524 > > The fix is to handle the BarrierSet kind correctly. > > diff -r 0ca52fb7d980 src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java > --- a/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java Tue Sep 29 17:01:37 2015 +0000 > +++ b/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java Tue Oct 13 08:47:05 2015 -1000 > @@ -86,13 +86,11 @@ public class HotSpotVMConfig { > > final long barrierSetAddress = UNSAFE.getAddress(universeCollectedHeap + collectedHeapBarrierSetOffset); > final int kind = UNSAFE.getInt(barrierSetAddress + barrierSetFakeRttiOffset + fakeRttiConcreteTagOffset); > - if ((kind == barrierSetCardTableModRef) || (kind == barrierSetCardTableExtension) || (kind == barrierSetG1SATBCT) || (kind == barrierSetG1SATBCTLogging)) { > + if ((kind == barrierSetCardTableModRef) || (kind == barrierSetCardTableForRS) || (kind == barrierSetCardTableExtension) || (kind == barrierSetG1SATBCT) || (kind == barrierSetG1SATBCTLogging)) { > final long base = UNSAFE.getAddress(barrierSetAddress + cardTableModRefBSByteMapBaseOffset); > assert base != 0 : "unexpected byte_map_base: " + base; > cardtableStartAddress = base; > cardtableShift = cardTableModRefBSCardShift; > - } else if (kind == barrierSetCardTableForRS) { > - throw JVMCIError.unimplemented(); > } else if (kind == barrierSetModRef) { > // No post barriers > cardtableStartAddress = 0; > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Tue Oct 13 19:08:13 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 13 Oct 2015 09:08:13 -1000 Subject: RFR (XS): 8139558 [JVMCI] SPARC hits: guarantee(heap_end < allocation_end) failed: heap end too close to end of address space (might lead to erroneous TLAB allocations) In-Reply-To: <963BB2E7-DA2D-4CA7-8901-F2EEE46B6F9C@oracle.com> References: <963BB2E7-DA2D-4CA7-8901-F2EEE46B6F9C@oracle.com> Message-ID: <5594093C-3CE6-401A-91DE-A7D2F06970E5@oracle.com> Thanks. I missed there was already a bug filed so I will push under: 8139545: JVMCI : guarantee(heap_end < allocation_end) failed on some sparcv9 hosts > On Oct 13, 2015, at 9:07 AM, Igor Veresov wrote: > > Looks good. > > igor > >> On Oct 13, 2015, at 12:02 PM, Christian Thalinger > wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8139558 >> >> This assert can trigger trivially on SPARC so we have to disable it. >> >> diff -r 0ca52fb7d980 src/share/vm/jvmci/jvmciRuntime.cpp >> --- a/src/share/vm/jvmci/jvmciRuntime.cpp Tue Sep 29 17:01:37 2015 +0000 >> +++ b/src/share/vm/jvmci/jvmciRuntime.cpp Tue Oct 13 09:02:29 2015 -1000 >> @@ -778,9 +778,11 @@ JVM_ENTRY(void, JVM_RegisterJVMCINatives >> } >> >> #ifdef _LP64 >> +#ifndef TARGET_ARCH_sparc >> uintptr_t heap_end = (uintptr_t) Universe::heap()->reserved_region().end(); >> uintptr_t allocation_end = heap_end + ((uintptr_t)16) * 1024 * 1024 * 1024; >> guarantee(heap_end < allocation_end, "heap end too close to end of address space (might lead to erroneous TLAB allocations)"); >> +#endif // TARGET_ARCH_sparc >> #else >> fatal("check TLAB allocation code for address space conflicts"); >> #endif >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Tue Oct 13 19:08:32 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 13 Oct 2015 09:08:32 -1000 Subject: RFR (XS): 8139524: JVMCI cannot be initialized with CMS or Serial GCs In-Reply-To: <3CAA7BFE-6814-4CC9-A1F5-0DA0022B99A8@oracle.com> References: <3CAA7BFE-6814-4CC9-A1F5-0DA0022B99A8@oracle.com> Message-ID: Thanks. > On Oct 13, 2015, at 9:07 AM, Igor Veresov wrote: > > Seems alright. > > igor > >> On Oct 13, 2015, at 11:49 AM, Christian Thalinger > wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8139524 >> >> The fix is to handle the BarrierSet kind correctly. >> >> diff -r 0ca52fb7d980 src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java >> --- a/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java Tue Sep 29 17:01:37 2015 +0000 >> +++ b/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java Tue Oct 13 08:47:05 2015 -1000 >> @@ -86,13 +86,11 @@ public class HotSpotVMConfig { >> >> final long barrierSetAddress = UNSAFE.getAddress(universeCollectedHeap + collectedHeapBarrierSetOffset); >> final int kind = UNSAFE.getInt(barrierSetAddress + barrierSetFakeRttiOffset + fakeRttiConcreteTagOffset); >> - if ((kind == barrierSetCardTableModRef) || (kind == barrierSetCardTableExtension) || (kind == barrierSetG1SATBCT) || (kind == barrierSetG1SATBCTLogging)) { >> + if ((kind == barrierSetCardTableModRef) || (kind == barrierSetCardTableForRS) || (kind == barrierSetCardTableExtension) || (kind == barrierSetG1SATBCT) || (kind == barrierSetG1SATBCTLogging)) { >> final long base = UNSAFE.getAddress(barrierSetAddress + cardTableModRefBSByteMapBaseOffset); >> assert base != 0 : "unexpected byte_map_base: " + base; >> cardtableStartAddress = base; >> cardtableShift = cardTableModRefBSCardShift; >> - } else if (kind == barrierSetCardTableForRS) { >> - throw JVMCIError.unimplemented(); >> } else if (kind == barrierSetModRef) { >> // No post barriers >> cardtableStartAddress = 0; >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Tue Oct 13 19:22:26 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 13 Oct 2015 09:22:26 -1000 Subject: RFR(XS) : 8139376 : [TESTBUG] ExecuteInstalledCodeTest should be run only on amd64 and sparcv9 In-Reply-To: <561D0765.2060301@oracle.com> References: <561D0765.2060301@oracle.com> Message-ID: <6DE9D9D8-BCC0-4182-823E-32CC510D4C96@oracle.com> Looks good. > On Oct 13, 2015, at 3:30 AM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev/8139376/webrev.00/ >> 1 line changed: 1 ins; 0 del; 0 mod; > > Hi all, > > please review the small fix which adds '@requires' to exclude compiler/jvmci/compilerToVM/ExecuteInstalledCodeTest from running on platforms which don't support JMVCI. > > webrev: http://cr.openjdk.java.net/~iignatyev/8139376/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8139376 > > -- > Thanks, > Igor From christian.thalinger at oracle.com Tue Oct 13 19:23:32 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 13 Oct 2015 09:23:32 -1000 Subject: RFR(XS) : 8139376 : [TESTBUG] ExecuteInstalledCodeTest should be run only on amd64 and sparcv9 In-Reply-To: <561D22BD.7050009@oracle.com> References: <561D0765.2060301@oracle.com> <561D16AE.3080908@oracle.com> <561D22BD.7050009@oracle.com> Message-ID: <7630D219-418B-4E06-94AF-46DB93EA9455@oracle.com> > On Oct 13, 2015, at 5:26 AM, Igor Ignatyev wrote: > > Hi Vladimir, > > 'os.arch != "aarch64"' is a workaround for a bug in jtreg[*]. > > [*] https://bugs.openjdk.java.net/browse/CODETOOLS-7901514 Wow, this is really stupid: - if (arch.contains("64") && !arch.equals("ia64") && !arch.equals("ppc64")) + if (arch.equals("amd64") || arch.equals("x86_64")) > > Igor > > On 10/13/2015 05:35 PM, Vladimir Kozlov wrote: >> I don't think this is correct (we also have ppc): >> >> & os.arch != "aarch64" >> >> why you need it? Why first condition is not enough: >> (os.simpleArch == "x64" | os.simpleArch == "sparcv9") >> >> Thanks, >> Vladimir >> >> On 10/13/15 9:30 PM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev/8139376/webrev.00/ >>>> 1 line changed: 1 ins; 0 del; 0 mod; >>> >>> Hi all, >>> >>> please review the small fix which adds '@requires' to exclude >>> compiler/jvmci/compilerToVM/ExecuteInstalledCodeTest from running on >>> platforms which don't support JMVCI. >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev/8139376/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8139376 >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrij.pochepko at oracle.com Tue Oct 13 20:15:01 2015 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Tue, 13 Oct 2015 23:15:01 +0300 Subject: RFR(S): JDK-8139438: [TESTBUG] JVMCI test fails with RuntimeException: Has no virtual object before materialization Message-ID: <561D6645.7040300@oracle.com> Hi, please review a small fix for test: compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java Description: A test is changed to run testcases in separate VM launch instead of consecutive execution, which had wrong assumption about method compilation state in case of -XX:-TieredCompilation. So, a boolean system property is added into test to control test execution logic externally. I've also added minor code cleanup. webrev: http://cr.openjdk.java.net/~dpochepk/8139438/webrev.01/ Thanks, Dmitrij -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Tue Oct 13 22:10:57 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 14 Oct 2015 01:10:57 +0300 Subject: RFR(S): JDK-8139438: [TESTBUG] JVMCI test fails with RuntimeException: Has no virtual object before materialization In-Reply-To: <561D6645.7040300@oracle.com> References: <561D6645.7040300@oracle.com> Message-ID: Hi Dmitrij, the fix looks good to me. -- Thanks, Igor > On Oct 13, 2015, at 11:15 PM, Dmitrij Pochepko wrote: > > Hi, > > please review a small fix for test: compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java > > Description: > > A test is changed to run testcases in separate VM launch instead of consecutive execution, which had wrong assumption about method compilation state in case of -XX:-TieredCompilation. > So, a boolean system property is added into test to control test execution logic externally. > I've also added minor code cleanup. > > webrev: http://cr.openjdk.java.net/~dpochepk/8139438/webrev.01/ > > Thanks, > Dmitrij -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Tue Oct 13 22:54:20 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 13 Oct 2015 12:54:20 -1000 Subject: RFR (XXS): 8139386: JVMCI test failed with assert(_jvmci._alternate_call_target == 0L) failed: must be Message-ID: <9E9C7833-4F3A-4A57-8584-23966D1B2418@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8139386 The wrong store instruction was used to clear the value. diff -r e53bc007035a src/cpu/sparc/vm/sharedRuntime_sparc.cpp --- a/src/cpu/sparc/vm/sharedRuntime_sparc.cpp Tue Oct 13 09:21:10 2015 -1000 +++ b/src/cpu/sparc/vm/sharedRuntime_sparc.cpp Tue Oct 13 12:51:38 2015 -1000 @@ -1001,7 +1001,7 @@ void AdapterGenerator::gen_i2c_adapter(i __ delayed()->nop(); __ ld_ptr(G2_thread, in_bytes(JavaThread::jvmci_alternate_call_target_offset()), G3); - __ st(G0, Address(G2_thread, in_bytes(JavaThread::jvmci_alternate_call_target_offset()))); + __ st_ptr(G0, Address(G2_thread, in_bytes(JavaThread::jvmci_alternate_call_target_offset()))); __ bind(no_alternative_target); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed Oct 14 01:44:15 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 14 Oct 2015 09:44:15 +0800 Subject: RFR (XXS): 8139386: JVMCI test failed with assert(_jvmci._alternate_call_target == 0L) failed: must be In-Reply-To: <9E9C7833-4F3A-4A57-8584-23966D1B2418@oracle.com> References: <9E9C7833-4F3A-4A57-8584-23966D1B2418@oracle.com> Message-ID: <561DB36F.4070002@oracle.com> Good. Vladimir On 10/14/15 6:54 AM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8139386 > > The wrong store instruction was used to clear the value. > > diff -r e53bc007035a src/cpu/sparc/vm/sharedRuntime_sparc.cpp > --- a/src/cpu/sparc/vm/sharedRuntime_sparc.cppTue Oct 13 09:21:10 2015 -1000 > +++ b/src/cpu/sparc/vm/sharedRuntime_sparc.cppTue Oct 13 12:51:38 2015 -1000 > @@ -1001,7 +1001,7 @@ void AdapterGenerator::gen_i2c_adapter(i > __ delayed()->nop(); > > > __ ld_ptr(G2_thread, > in_bytes(JavaThread::jvmci_alternate_call_target_offset()), G3); > - __ st(G0, Address(G2_thread, > in_bytes(JavaThread::jvmci_alternate_call_target_offset()))); > + __ st_ptr(G0, Address(G2_thread, > in_bytes(JavaThread::jvmci_alternate_call_target_offset()))); > > > __ bind(no_alternative_target); > } > From vladimir.kozlov at oracle.com Wed Oct 14 01:53:15 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 14 Oct 2015 09:53:15 +0800 Subject: RFR(XS) : 8139376 : [TESTBUG] ExecuteInstalledCodeTest should be run only on amd64 and sparcv9 In-Reply-To: <561D22BD.7050009@oracle.com> References: <561D0765.2060301@oracle.com> <561D16AE.3080908@oracle.com> <561D22BD.7050009@oracle.com> Message-ID: <561DB58B.9040807@oracle.com> Okay. I hope that will be fixed soon. Thanks, Vladimir On 10/13/15 11:26 PM, Igor Ignatyev wrote: > Hi Vladimir, > > 'os.arch != "aarch64"' is a workaround for a bug in jtreg[*]. > > [*] https://bugs.openjdk.java.net/browse/CODETOOLS-7901514 > > Igor > > On 10/13/2015 05:35 PM, Vladimir Kozlov wrote: >> I don't think this is correct (we also have ppc): >> >> & os.arch != "aarch64" >> >> why you need it? Why first condition is not enough: >> (os.simpleArch == "x64" | os.simpleArch == "sparcv9") >> >> Thanks, >> Vladimir >> >> On 10/13/15 9:30 PM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev/8139376/webrev.00/ >>>> 1 line changed: 1 ins; 0 del; 0 mod; >>> >>> Hi all, >>> >>> please review the small fix which adds '@requires' to exclude >>> compiler/jvmci/compilerToVM/ExecuteInstalledCodeTest from running on >>> platforms which don't support JMVCI. >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev/8139376/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8139376 >>> From vladimir.kozlov at oracle.com Wed Oct 14 01:59:11 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 14 Oct 2015 09:59:11 +0800 Subject: AARCH64: 8139041: Redundant DMB instructions (CORRECTED ) In-Reply-To: <561D3370.6050503@redhat.com> References: <561505E4.207@redhat.com> <5617DF32.4090508@redhat.com> <56186321.6010505@oracle.com> <561D3370.6050503@redhat.com> Message-ID: <561DB6EF.2060603@oracle.com> Looks good. I leave to Roland to push through JPRT since it has shared part. Thanks, Vladimir On 10/14/15 12:38 AM, Andrew Haley wrote: > On 10/10/2015 02:00 AM, Vladimir Kozlov wrote: >> On 10/10/15 2:47 AM, Christian Thalinger wrote: >>> >>>> On Oct 9, 2015, at 5:37 AM, Andrew Haley wrote: >>>> >>>> Hi, >>>> >>>> On 10/09/2015 03:59 PM, Roland Westrelin wrote: >>>> >>>>>> There is a much simpler way: remove adjacent barriers in >>>>>> MacroAssembler. Thanks to the way that the AArch64 ISA is designed, >>>>>> barriers can be merged simply by ORing them together. Of course, this >>>>>> technique works for C1 and C2, and it adds essentially nothing to the >>>>>> compilation time. >>>>>> >>>>>> http://cr.openjdk.java.net/~aph/8139041/ >>>>>> >>>>>> One thing which may be controversial is that I've added a field to >>>>>> CodeBuffer to keep track of barriers and labels. I had to do this >>>>>> because when we're compiling there is (AFAICS) essentially nowhere >>>>>> else to keep the state. >>> >>> I don?t think it matters to have an additional field in CodeBuffer. It?s a temporary data structure and we use much more memory for graphs. >>> >>> I would even go that far and questioning putting it under #ifdef AARCH64. >> >> +1 that. > > OK. I'm guessing that PPC will want to use this anyway. > > http://cr.openjdk.java.net/~aph/8139041-2 > > Andrew. > From vladimir.kozlov at oracle.com Wed Oct 14 02:04:21 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 14 Oct 2015 10:04:21 +0800 Subject: RFR(L): 8066153: JEP-JDK-8046155: Test task: cover existing In-Reply-To: <561D34FA.9020501@oracle.com> References: <5609334B.7050200@oracle.com> <5614886B.9050508@oracle.com> <56156920.2020405@oracle.com> <5615C7C9.7030604@oracle.com> <561D34FA.9020501@oracle.com> Message-ID: <561DB825.9080200@oracle.com> Seems fine. Let Nils to look on it too. Thanks, Vladimir On 10/14/15 12:44 AM, Pavel Punegov wrote: > Hi all, > > please review a new version of tests: > http://cr.openjdk.java.net/~ppunegov/8066153/webrev.01/ > > Most changes were made to Scenario and DirectiveBuilder classes to > reflect recent changes made by Nils. > VM fails with error message if user supplied incorrect directive, so > Scenario was changed to handle both correct and incorrect directives. > > Multiple refactoring and cleaning were also made to the code: > - Move directive file writing from the DirectiveBuilder into the new > class DirectiveWriter. > - Add random generators for CompileCommand and methods > - All scenario related enums are moved to Scenario. > - Cleaned code in directive building. > > On 08.10.2015 04:32, Vladimir Kozlov wrote: >> Got it. Okay then. >> >> Thanks, >> Vladimir >> >> On 10/8/15 2:49 AM, Pavel Punegov wrote: >>> Thank you, Vladimir. >>> >>> LogCompilation output processing will signal failure only if we found >>> that the method was printed when it should not be. >>> It won't fail if there are no methods that should be printed at all, or >>> there is a broken output that just wouldn't match regexps. >>> >>> On 07.10.2015 05:50, Vladimir Kozlov wrote: >>>> We have test problems with parsing output of LogCompilation and other >>>> outputs because it could be cut off. I would prefer adding new WB >>>> events API to record interesting events. >>>> Otherwise seems fine. Nils should look on this to make sure all >>>> paths/flags are tested. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 9/28/15 8:32 PM, Pavel Punegov wrote: >>>>> Hi, >>>>> >>>>> please review the following tests fro JEP 165 Compiler Control. >>>>> These tests cover both CompileCommand and new directives (through >>>>> CompileDirectivesFile). >>>>> >>>>> The main idea of tests is to create a one or multiple commands or >>>>> directives for methods in the pool and execute a test VM with a set of >>>>> method states (should method be compiled, inlined, printed, etc.). On >>>>> the end test checks that only correct methods are logged with >>>>> LogCompilation, or printed via PrintAssembly. >>>>> >>>>> Bugs: >>>>> https://bugs.openjdk.java.net/browse/JDK-8066153 >>>>> https://bugs.openjdk.java.net/browse/JDK-8066165 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ppunegov/8066153/webrev.00/ >>>>> >>> > From vladimir.kozlov at oracle.com Wed Oct 14 02:06:36 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 14 Oct 2015 10:06:36 +0800 Subject: RFR(M): 8066166: JEP-JDK-8046155: Test task: dcmd tests In-Reply-To: <561D3B83.8010307@oracle.com> References: <561D3B83.8010307@oracle.com> Message-ID: <561DB8AC.1050001@oracle.com> Good. Thanks, Vladimir On 10/14/15 1:12 AM, Pavel Punegov wrote: > Please review the following tests for diagnostic commands in > CompilerControl. > > This change extend the previous tests for CC with ability to add, remove > or clear directives with diagnostic command. > Each test generates one or several commands and directive file, then > executes another VM, which will be used as a target VM for JCMD. > After the test performed all diagnostic commands, the test VM will check > that all methods are compiled or not in the same way it was done before. > > webrev: http://cr.openjdk.java.net/~ppunegov/8066166/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8066166 > From vladimir.kozlov at oracle.com Wed Oct 14 02:11:48 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 14 Oct 2015 10:11:48 +0800 Subject: RFR (XS): 8139524: JVMCI cannot be initialized with CMS or Serial GCs In-Reply-To: References: Message-ID: <561DB9E4.2080909@oracle.com> Good. Vladimir On 10/14/15 2:49 AM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8139524 > > The fix is to handle the BarrierSet kind correctly. > > diff -r 0ca52fb7d980 > src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java > --- > a/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.javaTue > Sep 29 17:01:37 2015 +0000 > +++ > b/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.javaTue > Oct 13 08:47:05 2015 -1000 > @@ -86,13 +86,11 @@ public class HotSpotVMConfig { > > > final long barrierSetAddress = > UNSAFE.getAddress(universeCollectedHeap + collectedHeapBarrierSetOffset); > final int kind = UNSAFE.getInt(barrierSetAddress + > barrierSetFakeRttiOffset + fakeRttiConcreteTagOffset); > - if ((kind == barrierSetCardTableModRef) || (kind == > barrierSetCardTableExtension) || (kind == barrierSetG1SATBCT) || (kind > == barrierSetG1SATBCTLogging)) { > + if ((kind == barrierSetCardTableModRef) || (kind == > barrierSetCardTableForRS) || (kind == barrierSetCardTableExtension) || > (kind == barrierSetG1SATBCT) || (kind == barrierSetG1SATBCTLogging)) { > final long base = UNSAFE.getAddress(barrierSetAddress + > cardTableModRefBSByteMapBaseOffset); > assert base != 0 : "unexpected byte_map_base: " + base; > cardtableStartAddress = base; > cardtableShift = cardTableModRefBSCardShift; > - } else if (kind == barrierSetCardTableForRS) { > - throw JVMCIError.unimplemented(); > } else if (kind == barrierSetModRef) { > // No post barriers > cardtableStartAddress = 0; > From vladimir.kozlov at oracle.com Wed Oct 14 02:15:07 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 14 Oct 2015 10:15:07 +0800 Subject: RFR (XS): 8139558 [JVMCI] SPARC hits: guarantee(heap_end < allocation_end) failed: heap end too close to end of address space (might lead to erroneous TLAB allocations) In-Reply-To: References: Message-ID: <561DBAAB.7080809@oracle.com> Okay. I saw this fix in JVMCI refresh changes. Thanks, Vladimir On 10/14/15 3:02 AM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8139558 > > This assert can trigger trivially on SPARC so we have to disable it. > > diff -r 0ca52fb7d980 src/share/vm/jvmci/jvmciRuntime.cpp > --- a/src/share/vm/jvmci/jvmciRuntime.cppTue Sep 29 17:01:37 2015 +0000 > +++ b/src/share/vm/jvmci/jvmciRuntime.cppTue Oct 13 09:02:29 2015 -1000 > @@ -778,9 +778,11 @@ JVM_ENTRY(void, JVM_RegisterJVMCINatives > } > > > #ifdef _LP64 > +#ifndef TARGET_ARCH_sparc > uintptr_t heap_end = (uintptr_t) > Universe::heap()->reserved_region().end(); > uintptr_t allocation_end = heap_end + ((uintptr_t)16) * 1024 * 1024 > * 1024; > guarantee(heap_end < allocation_end, "heap end too close to end of > address space (might lead to erroneous TLAB allocations)"); > +#endif // TARGET_ARCH_sparc > #else > fatal("check TLAB allocation code for address space conflicts"); > #endif > From uschindler at apache.org Wed Oct 14 07:50:20 2015 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 14 Oct 2015 09:50:20 +0200 Subject: RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server compiler In-Reply-To: <088901d10013$2e92db50$8bb891f0$@apache.org> References: <53037D5B-7CA1-493C-837B-AF502ADFDF83@oracle.com> <55E721C6.2000206@oracle.com> <066d01d0fecf$f4f42230$dedc6690$@apache.org> <06e001d0ff48$427d23d0$c7776b70$@apache.org> <82C6CE6C-1B2D-490C-9A0F-DE4132EDFE46@oracle.com> <06f801d0ff52$767fc2f0$637f48d0$@apache.org> <846C489A-B3DE-4E55-A5EC-C70146ADBF4E@oracle.com> <07e801d0ffb3$64a44360$2decca20$@thetaphi.de> <088901d10013$2e92db50$8bb891f0$@apache.org> Message-ID: <028a01d10654$fbc2c440$f3484cc0$@apache.org> Hi, > > > I got another failure with exactly same code: > > > > > > http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14421/ > > > > > > So it is definitely reproducible. I was not yet able to reproduce it > > > or test > > your patch (I have not much experience in doing this). Maybe Dawid > > Weiss has some time to try it out. > > > I just wanted to let you know that it is reproducible. The above > > > Jenkins link > > allows to download hserr.pid and replay logs, too. > > > > Thanks. > > The replay files are truncated AFAICT, so unusable. > > Is this our fault or a general problem with the JDK replay files? The files were > archived by Jenkins, so I have no idea what could truncate them. > > > Unless this bug is blocking your work, I would recommend waiting until > > the fix for JDK-8134974 is available. I just wanted to give feedback: Yesterday, I installed build 85 on Lucene's Jenkins, the SIGSEGVs are no longer happening. We have to wait a few more days, but looks good up to now. I did not find JDK-8134974 mentioned in the changes list of build 85, but I think it is part of the missing changelog for build 84 (that does not exist on jdk9.java.net). Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ From roland.westrelin at oracle.com Wed Oct 14 07:53:02 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 14 Oct 2015 09:53:02 +0200 Subject: RFR(S): 8134468: Lucene test failures with 32 bit JDK 9b78, Server compiler In-Reply-To: <028a01d10654$fbc2c440$f3484cc0$@apache.org> References: <53037D5B-7CA1-493C-837B-AF502ADFDF83@oracle.com> <55E721C6.2000206@oracle.com> <066d01d0fecf$f4f42230$dedc6690$@apache.org> <06e001d0ff48$427d23d0$c7776b70$@apache.org> <82C6CE6C-1B2D-490C-9A0F-DE4132EDFE46@oracle.com> <06f801d0ff52$767fc2f0$637f48d0$@apache.org> <846C489A-B3DE-4E55-A5EC-C70146ADBF4E@oracle.com> <07e801d0ffb3$64a44360$2decca20$@thetaphi.de> <088901d10013$2e92db50$8bb891f0$@apache.org> <028a01d10654$fbc2c440$f3484cc0$@apache.org> Message-ID: Hi Uwe, > I just wanted to give feedback: Yesterday, I installed build 85 on Lucene's Jenkins, the SIGSEGVs are no longer happening. We have to wait a few more days, but looks good up to now. I did not find JDK-8134974 mentioned in the changes list of build 85, but I think it is part of the missing changelog for build 84 (that does not exist on jdk9.java.net). Good. Thanks for letting us know. Roland. From roland.westrelin at oracle.com Wed Oct 14 08:14:34 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 14 Oct 2015 10:14:34 +0200 Subject: RFR(M): 8137168: Replace IfNode with a new RangeCheckNode for range checks In-Reply-To: <560606C4.3050902@oracle.com> References: <9E9DF2F9-9F85-47BA-9AAA-3BD14985357A@oracle.com> <560606C4.3050902@oracle.com> Message-ID: Thanks for the review, Vladimir. Can I get another review for this? Roland. > On Sep 26, 2015, at 4:45 AM, Vladimir Kozlov wrote: > > Looks fine to me. > > Thanks, > Vladimir > > On 9/25/15 11:04 PM, Roland Westrelin wrote: >> This code adds a new ideal node, RangeCheckNode that is inserted during parsing when a range check is emitted. The entire change is code refactoring to accommodate the new node. This is preparation work for 8042997 and 8135248. >> >> 8135248 will add a new method to java.util.Arrays: >> >> int checkIndex(int index, int length, >> OutOfBoundsToException oobe) throws T, IndexOutOfBoundsException { >> if (index < 0 || index >= length) >> throw outOfBounds(index, length, length, oobe); >> return index; >> } >> >> 8042997 will intrinsify that method and translate it into a CmpU + RangeCheckNode. >> >> The benefit of the RangeCheckNode is that it will help the compiler locate range checks to optimize even if they don?t strictly follow the pattern of a range check: CmpU + IfNode + LoadRange. The idea of using a node specifically for range checks is from John. >> >> http://cr.openjdk.java.net/~roland/8137168/webrev.00/ >> >> Roland. >> From forax at univ-mlv.fr Wed Oct 14 08:37:17 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 14 Oct 2015 10:37:17 +0200 (CEST) Subject: RFR(M): 8137168: Replace IfNode with a new RangeCheckNode for range checks In-Reply-To: References: <9E9DF2F9-9F85-47BA-9AAA-3BD14985357A@oracle.com> <069DE39F-D3CA-46D7-8C0B-03C089977387@oracle.com> Message-ID: <123219133.1396775.1444811837065.JavaMail.zimbra@u-pem.fr> Re-reading your mail, you don't even need 25 bytecodes if you put everything in local variables and use then as registers, I think you only need 7 :) https://github.com/forax/vmboiler/blob/master/src/com/github/forax/vmboiler/CodeGen.java#L43 R?mi ----- Mail original ----- > De: "John Rose" > ?: "Chris Thalinger" > Cc: "hotspot compiler" > Envoy?: Mercredi 30 Septembre 2015 02:42:56 > Objet: Re: RFR(M): 8137168: Replace IfNode with a new RangeCheckNode for > range checks > On Sep 29, 2015, at 4:01 PM, Christian Thalinger < > christian.thalinger at oracle.com > wrote: > > > On Sep 25, 2015, at 5:04 AM, Roland Westrelin < > > > roland.westrelin at oracle.com > > > > > > > wrote: > > > > > > The idea of using a node specifically for range checks is from John. > > > > > There should be a range-check bytecode :-) > > Or, there should be ~25 bytecodes and bunch of intrinsic methods. ;-) > http://cr.openjdk.java.net/~jrose/pres/201508-JVMComplexity.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed Oct 14 08:48:42 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 14 Oct 2015 16:48:42 +0800 Subject: RFR(S): 8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI In-Reply-To: References: <7B89ADB9-1DF9-4DE2-85C8-0ADFF34A3190@oracle.com> <55F99D08.3010204@oracle.com> <4DAAADBF-9A3C-46BD-9E86-29E9B5044FAA@oracle.com> <55F9AB59.6030604@oracle.com> <07AAF0D5-134D-4D85-BD4C-EA5049EF8857@oracle.com> <55FF5E26.1060008@oracle.com> <041EEDC9-D32F-420D-9D55-111499B13321@oracle.com> <9D17B19D-9A35-4EFE-B5F7-954629DA2FC2@oracle.com> <10866B0A-712E-4665-9CC3-838AE6536D4A@oracle.com> <56014EA4.50907@oracle.com> <56122D8D.1050909@oracle.com> <56125D5A.7060708@oracle.com> Message-ID: <561E16EA.9070705@oracle.com> Good. Thanks, Vladimir On 10/12/15 4:46 PM, Roland Westrelin wrote: > Here is a new webrev that covers mismatched field accesses as well: > > http://cr.openjdk.java.net/~roland/8136473/webrev.03/ > > Roland. > >> On Oct 5, 2015, at 1:22 PM, Vladimir Kozlov wrote: >> >> So you are covering oops too. Okay then. >> >> Thanks, >> Vladimir >> >> On 10/5/15 5:12 PM, Roland Westrelin wrote: >>> Thanks for looking at this, Vladimir. >>> >>>> Mismatching access can be only for basic type as I understand. The code for mismatched = true could be rearranged by checking type != T_OBJECT first. >>> >>> People do such crazy things with Unsafe, I thought it was best to be prepared for anything. >>> >>>> Why you set mismatched only for array element? What about fields? >>> >>> You?re right, fields need to be handled the same way. >>> >>>> And next should be && I think (if you keep your code) >>>> if (type != T_OBJECT || !element->isa_narrowoop()) >>> >>> Either we reach that test with a basic type that is not an object (type != T_OBJECT) and there?s a mismatch but >>> if we have element->array_element_basic_type() = T_NARROWOOP and type = T_OBJECT, then there?s no mismatch. >>> >>> Roland. >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 9/28/15 11:44 PM, Roland Westrelin wrote: >>>>> That fix wasn?t sufficient so here is a new webrev: >>>>> >>>>> http://cr.openjdk.java.net/~roland/8136473/webrev.02/ >>>>> >>>>> On platforms that don?t support unaligned accesses we still have mismatched accesses because the java code of Unsafe.putIntUnaligned() is implemented in terms of putShort() and putByte() so my test case fails on sparc. I added a new boolean to MemNode to record whether the node is ?mismatched? in addition to the ?unaligned? boolean. >>>>> >>>>> Roland. >>>>> >>>>>> On Sep 22, 2015, at 2:50 PM, Vladimir Kozlov wrote: >>>>>> >>>>>> Okay. >>>>>> >>>>>> Vladimir >>>>>> >>>>>> On 9/22/15 8:47 PM, Roland Westrelin wrote: >>>>>>> For the record, it seems _unaligned is a reserved keyword for MSVC so I will change the field and function names to unaligned_access: >>>>>>> >>>>>>> diff --git a/src/share/vm/opto/memnode.hpp b/src/share/vm/opto/memnode.hpp >>>>>>> --- a/src/share/vm/opto/memnode.hpp >>>>>>> +++ b/src/share/vm/opto/memnode.hpp >>>>>>> @@ -40,7 +40,7 @@ >>>>>>> // Load or Store, possibly throwing a NULL pointer exception >>>>>>> class MemNode : public Node { >>>>>>> private: >>>>>>> - bool _unaligned; >>>>>>> + bool _unaligned_access; >>>>>>> protected: >>>>>>> #ifdef ASSERT >>>>>>> const TypePtr* _adr_type; // What kind of memory is being addressed? >>>>>>> >>>>>>> @@ -129,8 +129,8 @@ >>>>>>> // the given memory state? (The state may or may not be in(Memory).) >>>>>>> Node* can_see_stored_value(Node* st, PhaseTransform* phase) const; >>>>>>> >>>>>>> - void set_unaligned() { _unaligned = true; } >>>>>>> - bool is_unaligned() const { return _unaligned; } >>>>>>> + void set_unaligned_access() { _unaligned_access = true; } >>>>>>> + bool is_unaligned_access() const { return _unaligned_access; } >>>>>>> >>>>>>> #ifndef PRODUCT >>>>>>> static void dump_adr_type(const Node* mem, const TypePtr* adr_type, outputStream *st); >>>>>>> >>>>>>> Roland. >>>>>>> >>>>>>>> On Sep 22, 2015, at 9:43 AM, Roland Westrelin wrote: >>>>>>>> >>>>>>>>> Roland I had a look too, the code looks good. >>>>>>>> >>>>>>>> Thanks, Michael. >>>>>>>> >>>>>>>> Roland. >>>>>>>> >>>>>>>>> >>>>>>>>> -Michael >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Roland Westrelin >>>>>>>>> Sent: Monday, September 21, 2015 2:03 AM >>>>>>>>> To: hotspot compiler >>>>>>>>> Subject: Re: RFR(S): 8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI >>>>>>>>> >>>>>>>>> Thanks for the review, Vladimir. >>>>>>>>> >>>>>>>>> Roland. >>>>>>>>> >>>>>>>>>> On Sep 21, 2015, at 3:32 AM, Vladimir Kozlov wrote: >>>>>>>>>> >>>>>>>>>> This is good. Thank you for extending the test. >>>>>>>>>> >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 9/18/15 11:03 PM, Roland Westrelin wrote: >>>>>>>>>>>>>> Hmm, so you just relaxed the assert. You may need to fix EA too because it also checks for matching types(memory sizes). >>>>>>>>>>>>>> I remember we had problem with RAW accesses back when jsr292 was implemented. So EA gave up on RAW access and marks allocations as escaping. Also may be superword/vectorization will be affected. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In general it is very bad for C2 to have different memory on the same non-RAW memory. >>>>>>>>>>>>> >>>>>>>>>>>>> It already happens with vectorization. Do you see another solution (rather than relaxing the assert)? Putting a MemBarCPUOrder before and after the unaligned store? >>>>>>>>>>>> >>>>>>>>>>>> MemBarCPUOrder are definitely will help and it is simplest solution but, I think, it is too drastic. >>>>>>>>>>>> It affect control flow and other memory slices. >>>>>>>>>>>> We can try to mark such memory accesses or/and mark objects which have such accesses (if it is possible) and prevent vectorization and scalarization for them only. We should be able execute optimization on other memory slices then. >>>>>>>>>>> >>>>>>>>>>> Here is a new change: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~roland/8136473/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> Unaligned accesses are explicitly marked as such. >>>>>>>>>>> >>>>>>>>>>> I added a test case with a non escaping allocation and it works fine. I also added test case with vectorization and if the accesses are effectively unaligned vectorization doesn't happen. One of the test cases causes an assertion to fire when the allocation is expanded: the logic in InitializeNode::complete_stores() is confused by the unaligned store so I made sure unaligned stores are not captured by the initialization. >>>>>>>>>>> >>>>>>>>>>> Roland. >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> > From vladimir.kozlov at oracle.com Wed Oct 14 09:03:40 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 14 Oct 2015 17:03:40 +0800 Subject: RFR (XL): 8139170: JVMCI refresh In-Reply-To: References: <6ECC12F2-8693-43AD-8F08-B7E3F21AEB40@oracle.com> <561C863D.7080800@oracle.com> <48004E32-6D60-4E40-9FF0-F0E4148D0344@oracle.com> Message-ID: <561E1A6C.7060306@oracle.com> >> It would be good if we would run at least one JVMCI test in JPRT. If they are stable you can add them (compiler/jvmci for all) to hotspot_compiler_3 in test/TEST.groups Changes looks good. Thanks, Vladimir On 10/14/15 2:31 AM, Christian Thalinger wrote: > webrev updated. > >> On Oct 13, 2015, at 8:01 AM, Christian Thalinger >> > > wrote: >> >>> >>> On Oct 12, 2015, at 10:59 PM, Doug Simon >> > wrote: >>> >>>> >>>> On 13 Oct 2015, at 06:19, Vladimir Kozlov >>>> > wrote: >>>> >>>> Since we will get more changes from labs later we may enumerate >>>> them: JVMCI refresh 1. >>> >>> Or, pessimistically, JVMCI refresh 01 ;-) >>> >>>> Can you explain new sed command in Gensrc-jdk.vm.ci.gmk. >>> >>> http://hg.openjdk.java.net/graal/graal-jvmci-8/rev/1852abfbaca3 >>> >>>> Are you sure it works on windows? >>> >>> I can?t say for sure but given that I see similar patterns in other >>> *.gmk files, I think it should be fine. >> >> It would be good if we would run at least one JVMCI test in JPRT. >> >>> >>>> Instead of is_trivial(method) may be we should have general function >>>> called from AdvancedThresholdPolicy::common() which return >>>> compilation level for particular method (for example, we can also >>>> limit it using compilecommand). Could be done as separate change >>>> after this. >>>> >>>> I looked on jdk.vm.ci changes and nothing looks terrible wrong. I am >>>> not familiar with it so I can't say that each line is correct. One >>>> thing I am wondering is why explicit imports are used instead of .* >>>> (compilation speed?): >>> >>> http://mail.openjdk.java.net/pipermail/graal-dev/2015-September/003546.html >>> >>>> -import java.lang.annotation.*; >>>> +import java.lang.annotation.ElementType; >>>> +import java.lang.annotation.Retention; >>>> +import java.lang.annotation.RetentionPolicy; >>>> +import java.lang.annotation.Target; >>>> >>>> An other thing is using AMD64/amd64 in files and directory names. >>>> May be we should rename it to x64. >>>> >>>> jvmciCodeInstaller_x86.cpp and jvmciCodeInstaller.cpp has next pattern: >>>> + if (HotSpotMetaspaceConstantImpl::compressed(constant)) { >>>> +#ifdef _LP64 >>>> + ... >>>> +#else >>>> + fatal("unexpected compressed Klass* in 32-bit mode"); >>>> +#endif >>>> + } else { >>>> >>>> It would be nice to hide fatal() in some wrapper function. >>>> >>>> jvmciEnv.cpp use ASSERT instead of DEBUG. We renamed ifdef DEBUG >>>> long ago. >>>> >>>> globals.hpp changes conflict with 8139377. >>> >>> Then we should adopt 8139377 instead. >> >> When I created the review 8139377 was not integrated yet. Let me pull >> again. >> >>> >>>> Tests changes (mostly renaming) looks fine. >>>> >>>> Fix copyright years (2015, 2015) in new files. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/13/15 10:19 AM, Christian Thalinger wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8139170 >>>>> http://cr.openjdk.java.net/~twisti/8139170/webrev/ >>>>> >>>>> During the review period for JEP 243 there were some changes and >>>>> enhancements to the JVMCI code done by Oracle Labs. In order to not >>>>> disturb the already long and complicated review of JEP 243 we >>>>> decided to do a refresh after the initial integration. >>>>> >>>>> A lot of the Java changes is switching to using explicit imports. > From aph at redhat.com Wed Oct 14 09:07:53 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 14 Oct 2015 10:07:53 +0100 Subject: JVMCI Status Message-ID: <561E1B69.8000006@redhat.com> I've been trying to keep up with all the JVMCI discussion, but not entirely successfully. Is it now stable enough for an AArch64 port, or is it still in flux? If it is ready, which repository should I use? Thanks, Andrew. From vladimir.kozlov at oracle.com Wed Oct 14 09:29:59 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 14 Oct 2015 17:29:59 +0800 Subject: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. In-Reply-To: <39F83597C33E5F408096702907E6C45005879240@ORSMSX104.amr.corp.intel.com> References: <39F83597C33E5F408096702907E6C45005879107@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C450058791D0@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C45005879240@ORSMSX104.amr.corp.intel.com> Message-ID: <561E2097.8060907@oracle.com> I said before that condition in .ad file in Matcher::match_rule_supported(): case Op_CMoveVD: if (UseAVX > 2) <<<<< (UseAVX < 1 || UseAVX > 2) ret_value = false; should match predicates: predicate(UseAVX > 0 && UseAVX < 3 && n->as_Vector()->length() == 4); Also why only length 4? There is no length 2? I don't see any code in superword.cpp which limits size of CMoveVD vector. Otherwise it seems fine. Thanks, Vladimir On 10/14/15 1:57 AM, Civlin, Jan wrote: > Vladimir, > > the updated webrev is at > > http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.01/ > > Thank you, Igor. > > Best, > > Jan. > > -----Original Message----- > From: Igor Veresov [mailto:igor.veresov at oracle.com] > Sent: Tuesday, October 13, 2015 10:51 AM > To: Civlin, Jan > Cc: Vladimir Kozlov > Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. > > Done. > >> On Oct 13, 2015, at 9:51 AM, Civlin, Jan wrote: >> >> Igor, >> >> I got a response from the moderator that the previous message (attached below) has been rejected due to the size limits. >> Please upload the attached webrev (I guess it will be >> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.01/) >> >> And I'll send the link to the group. >> >> Thank you, >> >> Jan. >> >> -----Original Message----- >> From: Civlin, Jan >> Sent: Monday, October 12, 2015 10:19 PM >> To: Vladimir Kozlov >> Cc: Igor Veresov; hotspot compiler; Civlin, Jan >> Subject: RE: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >> >> Vladimir, >> >> Here is a webrev built from a single changeset. >> Please use it for further reviewing. >> >> Thank you, >> >> Jan. >> >> -----Original Message----- >> From: Civlin, Jan >> Sent: Saturday, October 10, 2015 12:14 PM >> To: Vladimir Kozlov >> Cc: hotspot compiler >> Subject: RE: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >> >> Vladimir, >> >> Thank you for the quick review. >> >> >> I thought you are patching your repo using hotspot.patch which is clean of empty files or .hgtag and you use webrev only for facilitation of visual code review. >> If you use hotspot.patch it does not propagate to your repo empty or already integrated in 8136725 files or my repo tags, since none of them are in the patch. >> I thought you are simply skipping unchanged files if you see them in webrev html pages. >> >> My repo is a consistent and long living clone of your repo. It is a single place that includes the history of all my changes, which let me go ahead in development way far of what is ready for going out to you. I can create an additional repo and filter out my tags on way out, but it will create more possibilities for accidental errors. >> >> >> x86.ad: it is indeed not (yet) AVX3, since AVX3 will have different ISA. Once we have AVX3 in the house and can debug it, AVX3 case will be added. >> >> c2_globals.hpp: >> I will rename the flag to UseCMoveUnconditionally, but I see no point of having another flag for the vector: once SuperWord detects CMovD, it merely vectorize it. >> In the opposite direction: one cannot ask for vectorization of CMovD and not to get them in the scalar case. >> >> compile.cpp: >> 1114: will add "do_vector_loop() &&" and change to NOT_PRODUCT(if >> (do_vector_loop() && Verbose&& && has_method()) >> {tty->print("Compile::Init: use CMove without profitability tests for >> method %s\n", method()->name()->as_quoted_ascii());}) >> >> loopopts.cpp: >> 601: will add "&& cmp_op == Op_CmpD" and change to if (C->use_cmove() >> && cmp_op == Op_CmpD) ;//keep going >> >> >> Thank you, >> >> Jan >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Saturday, October 10, 2015 5:52 AM >> To: Civlin, Jan >> Cc: hotspot compiler >> Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >> >> Changes contains also 8136725 (loop reserve copy) changes. Please, clean up. >> >> x86.ad WAIT! According to next conditions (BTW, support condition should match predicate) this is only supported with AVX1 and AVX2 and not AVX3. Really? >> >> I think it should be reversed condition (< 3): >> + case Op_CMoveVD: >> + if (UseAVX > 2) >> + ret_value = false; >> >> + instruct vcmov4D_reg(vecY dst, vecY src1, vecY src2, immI8 cop, >> cmpOp_vcmppd copnd) %{ >> + predicate(UseAVX > 0 && UseAVX < 3 && n->as_Vector()->length() == >> + 4); >> >> >> x86_64.ad changes are empty (could be only spacing change) so remove it from change. >> >> c2_globals.hpp DoReserveCopyInSuperWord is defined in 8136725 changes. >> UseCMov should be UseCMoveUnconditionally I think (note 'move' instead >> of 'mov'). Also I am not sure that you should mix 2 things into this >> changes: one is vectorizing cmoveD (for doubles) and always generate cmoves. I think it is different issues and this change should concentrate on vectorizing only double cmoves. Then flag could be VectorizeCMoveD. >> >> compile.cpp print not under UseCmov flag: >> + NOT_PRODUCT(if (Verbose && has_method()) {tty->print("Compile::Init: >> use CMove without profitability tests for method %s\n", >> method()->name()->as_quoted_ascii());}) >> >> loopopts.cpp changes inconsistent. In one place you check use_cmove only for doubles and in other for all. >> >> I will look on superword changes after you cleanup changes: remove >> 8136725 and also create history from fresh repo - I don't want to see 50 revisions descriptions in webrev. >> >> Thanks, >> Vladimir >> >> On 10/10/15 7:04 AM, Civlin, Jan wrote: >>> Please review this patch. >>> >>> Hi All, >>> >>> >>> We would like to contribute the SuperWord enhancement to support >>> vector conditional move (CMovVD ) on Intel AVX cpu. >>> >>> >>> The contribution Bug ID: 8139340. >>> >>> Please review this patch: >>> >>> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8139340 >>> >>> webrev: http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ >>> >>> Description: >>> >>> SuperWord enhancement to support vector conditional move (CMovVD) on >>> Intel AVX cpu. >>> >>> The SuperWord optimization bails out on counted loops that contain >>> any conditional statement other than the loop exit, and this prevents >>> vectorization of many compute bound loops. >>> >>> The proposed enhancement enables generation of CMovD on demand >>> (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD ) in >>> SuperWord optimization. >>> >>> The performance gain observed on a simplified Monte Carlo Option >>> Calculation was up to 2x speed-up. >>> >>> Thank you, >>> >>> Jan. >>> >>> *From:*Igor Veresov [mailto:igor.veresov at oracle.com] >>> *Sent:* Friday, October 9, 2015 3:22 PM >>> *To:* Civlin, Jan >>> *Cc:* hotspot compiler; Vladimir Kozlov >>> *Subject:* Re: SuperWord enhancement to support vector conditional >>> move (CMovVD ) on Intel AVX cpu. >>> >>> Here it is: https://bugs.openjdk.java.net/browse/JDK-8139340 >>> >>> igor >>> >>> On Oct 9, 2015, at 2:57 PM, Civlin, Jan >> > wrote: >>> >>> Thank you, Igor. >>> >>> What is the RFR for this? >>> >>> *From:*Igor Veresov [mailto:igor.veresov at oracle.com] >>> *Sent:*Friday, October 9, 2015 2:53 PM >>> *To:*Civlin, Jan >>> *Cc:*hotspot compiler; Vladimir Kozlov >>> *Subject:*Re: SuperWord enhancement to support vector conditional >>> move (CMovVD ) on Intel AVX cpu. >>> >>> Here the webrev: >>> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ >>> >>> igor >>> >>> On Oct 9, 2015, at 1:15 PM, Civlin, Jan >> > wrote: >>> >>> Igor, >>> >>> Please create RFR and upload this patch. You may need to rename >>> ancnav.js.remove_this_extention back to ancnav.js (I have to >>> rename it for passing the mail server filters). >>> >>> Description: >>> >>> SuperWord enhancement to support vector conditional move >>> (CMovVD) on Intel AVX cpu. >>> >>> The SuperWord optimization bails out on counted loops that >>> contain any conditional statement other than the loop exit, and >>> this prevents vectorization of many compute bound loops. >>> >>> The proposed enhancement enables generation of CMovD on demand >>> (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD >>> ) in SuperWord optimization. >>> >>> The performance gain observed on a simplified Monte Carlo Option >>> Calculation was up to 2x speed-up. >>> >>> Thank you, >>> >>> Jan. >>> >>> >>> >> > From goetz.lindenmaier at sap.com Wed Oct 14 10:34:01 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 14 Oct 2015 10:34:01 +0000 Subject: RFR(M): 8139040: Fix initializations before ShouldNotReachHere() In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC41E81D98@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41E81FF4@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC41E824E8@DEWDFEMB12A.global.corp.sap> Hi Roland, thanks for reviewing this change! I changed the assert to fatal, I'm fine with that, too: http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.04/ Coleen, Roland, would one of you mind sponsoring this? Best regards, Goetz. -----Original Message----- From: Roland Westrelin [mailto:roland.westrelin at oracle.com] Sent: Dienstag, 13. Oktober 2015 10:10 To: Lindenmaier, Goetz Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(M): 8139040: Fix initializations before ShouldNotReachHere() Hi Goetz, > C1_LIRGenerator.hpp: > I added handling of the default case (assert(0)). Shouldn?t you use fatal instead of assert(0)? I went over the compiler related files and they look ok to me. Roland. > > compactHashtable.cpp: > Hmm, I?m not clear why get_num says corrupted() in one case, > and in the other returns false. The code is dead, anyways, so I > rather leave it as is. > > heapRegionRemSet.cpp > I added guarantee(max_prev != NULL). I think this is better understandable. > Else it looks as if there is a legal case where *max_prev must not be set. > > Updated webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.03/ > > Best regards, > Goetz. > > > > > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > Sent: Montag, 12. Oktober 2015 16:45 > To: Lindenmaier, Goetz > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(M): 8139040: Fix initializations before ShouldNotReachHere() > > Hi Goetz, > > More small nitpicks: > > http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.02/src/share/vm/c1/c1_LIRGenerator.hpp.sdiff.html > > handle default case? I dont see callers handling lir_cond_unknown. > > ------------ > > http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.02/src/share/vm/classfile/compactHashtable.cpp.html > > maybe the right thing to do would be to handle errors returned by HashTableHexDump::get_num() ? > (but your change is still better than the original) > > -------------- > > http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.02/src/share/vm/gc/g1/heapRegionRemSet.cpp.sdiff.html > > In PerRegionTable* OtherRegionsTable::delete_region_table(): > > 617 // Unsplice. > 618 *max_prev = max->collision_list_next(); > > Should the access to max_prev be guarded against != NULL? > > ------------ > > Otherwise the change looks good. > > Kind Regards, Thomas > > > On Mon, Oct 12, 2015 at 11:18 AM, Lindenmaier, Goetz > wrote: > Hi, > > I now fixed the warnings showing with -Wuninitialized anyways. > The change now enables this flag per default with gcc 4.8. > Older gcc versions detect more issues, as far as I checked all false > positives. Therefore I don't enable the flag for gcc < 4.8. > > The warnings reported by this flag depend on the optimization level, it's > most effective in the opt build. > > This unveiled some missing initializations in constructors, as in compile.hpp, > and oopMap.hpp that can actually cause wrong behavior. > > Complete webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.02/ > incremental webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.02-incremental/ > > Best regards, > Goetz. > > > From: Lindenmaier, Goetz > Sent: Mittwoch, 7. Oktober 2015 15:22 > To: hotspot-runtime-dev at openjdk.java.net > Subject: RFR(M): 8139040: Fix initializations before ShouldNotReachHere() > > Hi, > > SAP requires us to fix a row of issues in the hotspot coding. I would like > to share these with openJDK. > > This webrev fixes a row of missing intializations, mostly combined with ShouldNotReachHere() > in default cases of switches or the like. > http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.00/ > > In the debug build, ShouldNotReachHere() can be suppressed, so the uninitialized value actually can cause problems. > In opt builds, not all tools recognize the ShouldNotReachHere properly. > > In addition to this I would like to add -Wuninitialized to the warning flags. > This finds most of these issues in the opt build and > would require an additional 70 fixes plus fixes in jvmtiEnter.xsl. > Would it be appreciated to set this flag? > > Best regards, > Goetz. From hui.shi at linaro.org Wed Oct 14 12:48:25 2015 From: hui.shi at linaro.org (Hui Shi) Date: Wed, 14 Oct 2015 20:48:25 +0800 Subject: RFR: Elide more final field's write memory barrier with escape analysis result In-Reply-To: <7C9B87B351A4BA4AA9EC95BB4181165672261384@DEWDFEMB19C.global.corp.sap> References: <5612A2C6.5080108@redhat.com> <7C9B87B351A4BA4AA9EC95BB4181165672261165@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672261384@DEWDFEMB19C.global.corp.sap> Message-ID: Thanks Martin! Roland, would you please run JPRT test and sponsor this change? Regards Shi Hui On 12 October 2015 at 17:39, Doerr, Martin wrote: > Hi Hui Shi, > > > > thanks for the update. Looks good for PPC64 as well, now. > > As you already explained, the MemBarRelease is only relevant for fields of > the allocated object. Hence, the final and volatile cases can be handled > the same way. > > > > Best regards, > > Martin > > > > > > *From:* Hui Shi [mailto:hui.shi at linaro.org] > *Sent:* Samstag, 10. Oktober 2015 15:25 > *To:* Doerr, Martin > *Cc:* Roland Westrelin; hotspot compiler; > aarch64-port-dev at openjdk.java.net > > *Subject:* Re: RFR: Elide more final field's write memory barrier with > escape analysis result > > > > Thanks Roland and Martin! > > > > Agree, it's better remove extra code for PPC64. new webrev > http://cr.openjdk.java.net/~hshi/8138956/webrev_v2/ > > comments below > > > > Regards > > Shi Hui > > > > On 10 October 2015 at 00:17, Doerr, Martin wrote: > > Hi, > > I basically like this change. Thanks for pointing me to it. > > But I don't like the extra code for PPC64. If the allocation does not > escape globally it should be safe to elide the membar regardless of whether > we wrote final or volatile fields. > > > > Difference is final field is always belonging to initializing object while > volatile field isn't. It's reasonable to insert MemoryBarrier, when > volatile field is written in its owning class' initializer method, like you > example of AtomicInteger. > > > > In following example, class A initiailzer writes both final field and > volatile field, suppose A instance doesn't escape. MemBarRelase is inserted > because final and volatile field wirte. Writing b.vol in A's initializer is > same with writing b.vol in none-initalizer method and doesn't need > MemBarRelease in my understanding. > > > > 1. If final and volatile field from same allocation, > elide MemBarRelase when allocation doesn't escape is safe. > > 2. If volatile field doesn't belong to final field's allocation object, > MemBarRelase for volatile is not necessary. > > So it's safe to remove MemBarRelease when final field's allocation object > doesn't escape. > > > > Class A { > > final int a; > > A(int val, B b) { a=val; b.vol = val; } > > } > > > > Class B { volatile int vol;} > > > > > > Please also note that PPC64_ONLY(...) NOT_PPC(...) is incorrect on PPC32. > > Actually, it's ugly that PPC64_ONLY was used here. Should better be > (support_IRIW_for_not_multiple_copy_atomic_cpu && wrote_volatile()), but > that's not the topic of this change. > > Best regards, > Martin > > > > -----Original Message----- > From: hotspot-compiler-dev [mailto: > hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Roland > Westrelin > Sent: Donnerstag, 8. Oktober 2015 13:51 > To: Hui Shi > Cc: hotspot compiler; aarch64-port-dev at openjdk.java.net > Subject: Re: RFR: Elide more final field's write memory barrier with > escape analysis result > > > http://cr.openjdk.java.net/~hshi/8138956/webrev/ > > The code change looks good to me. The comments have a few typos and are a > bit confusing. I'll tweak them before I push it. > > PPC folks, in case you missed it, parse1.cpp has a ppc related fix. > > Roland. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From konstantin.shefov at oracle.com Wed Oct 14 14:39:44 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Wed, 14 Oct 2015 17:39:44 +0300 Subject: [9] RFR 8072369: [TESTBUG] Remove potentially insecure class cast in some hotspot tests In-Reply-To: <56153A30.7040705@oracle.com> References: <55EF0649.8050109@oracle.com> <55F0312E.7020908@oracle.com> <56153A30.7040705@oracle.com> Message-ID: <561E6930.3030301@oracle.com> Hello Kindly reminder. Thanks -Konstantin On 10/07/2015 06:28 PM, Konstantin Shefov wrote: > Hi Christian > > The assumption that the Application Class Loader is an instance of > URLClassLoader can be false, because, AFAIK, it is not documented > anywhere. > This may become false in the future releases of JDK. > That is why it is better not to relay on this assumption. > > Thanks > -Konstantin > > 06.10.2015 22:35, Christian Thalinger ?????: >> >>> On Sep 9, 2015, at 3:16 AM, Konstantin Shefov >>> > >>> wrote: >>> >>> Description of the fix. >>> Some tests in hotspot repo use class cast from Application class >>> loader to URLClassLoader, but Application class loader is not >>> guaranteed to be always an instance of a URLClassLoader. >> >> Please excuse my lack of knowledge here but in what configuration >> does this happen? >> >>> The tests should be changed so that they do not cast appclassloader >>> to URLClassLoader. >>> >>> -Konstantin >>> >>> On 09/08/2015 07:01 PM, Konstantin Shefov wrote: >>>> Hello >>>> >>>> Please review a test bug fix. >>>> >>>> JBS entry: https://bugs.openjdk.java.net/browse/JDK-8072369 >>>> Webrev: http://cr.openjdk.java.net/~kshefov/8072369/webrev.00 >>>> >>>> Thanks >>>> -Konstantin >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From konstantin.shefov at oracle.com Wed Oct 14 15:20:21 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Wed, 14 Oct 2015 18:20:21 +0300 Subject: [9] RFR 8072369: [TESTBUG] Remove potentially insecure class cast in some hotspot tests In-Reply-To: <561E6930.3030301@oracle.com> References: <55EF0649.8050109@oracle.com> <55F0312E.7020908@oracle.com> <56153A30.7040705@oracle.com> <561E6930.3030301@oracle.com> Message-ID: <561E72B5.3090403@oracle.com> Vladimir, Thanks for reviewing. I have modified the code according to your comments. http://cr.openjdk.java.net/~kshefov/8072369/webrev.01/ Regards, -Konstantin On 10/14/2015 05:39 PM, Konstantin Shefov wrote: > Hello > > Kindly reminder. > > Thanks > -Konstantin > > On 10/07/2015 06:28 PM, Konstantin Shefov wrote: >> Hi Christian >> >> The assumption that the Application Class Loader is an instance of >> URLClassLoader can be false, because, AFAIK, it is not documented >> anywhere. >> This may become false in the future releases of JDK. >> That is why it is better not to relay on this assumption. >> >> Thanks >> -Konstantin >> >> 06.10.2015 22:35, Christian Thalinger ?????: >>> >>>> On Sep 9, 2015, at 3:16 AM, Konstantin Shefov >>>> >>> > wrote: >>>> >>>> Description of the fix. >>>> Some tests in hotspot repo use class cast from Application class >>>> loader to URLClassLoader, but Application class loader is not >>>> guaranteed to be always an instance of a URLClassLoader. >>> >>> Please excuse my lack of knowledge here but in what configuration >>> does this happen? >>> >>>> The tests should be changed so that they do not cast appclassloader >>>> to URLClassLoader. >>>> >>>> -Konstantin >>>> >>>> On 09/08/2015 07:01 PM, Konstantin Shefov wrote: >>>>> Hello >>>>> >>>>> Please review a test bug fix. >>>>> >>>>> JBS entry: https://bugs.openjdk.java.net/browse/JDK-8072369 >>>>> Webrev: http://cr.openjdk.java.net/~kshefov/8072369/webrev.00 >>>>> >>>>> Thanks >>>>> -Konstantin >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrij.pochepko at oracle.com Wed Oct 14 18:29:23 2015 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Wed, 14 Oct 2015 21:29:23 +0300 Subject: RFR(S): JDK-8139438: [TESTBUG] JVMCI test fails with RuntimeException: Has no virtual object before materialization In-Reply-To: <561D6645.7040300@oracle.com> References: <561D6645.7040300@oracle.com> Message-ID: <561E9F03.9070502@oracle.com> Hi, an issue with 1st version was found: a getDeclaredMethod parameter(line 67) wasn't changed according to testFrame method signature change. Now changed from Integer.class boolean.class Please take a look at 2nd version: http://cr.openjdk.java.net/~dpochepk/8139438/webrev.02 Thanks, Dmitrij On 13.10.2015 23:15, Dmitrij Pochepko wrote: > Hi, > > please review a small fix for test: > compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java > > Description: > > A test is changed to run testcases in separate VM launch instead of > consecutive execution, which had wrong assumption about method > compilation state in case of -XX:-TieredCompilation. > So, a boolean system property is added into test to control test > execution logic externally. > I've also added minor code cleanup. > > webrev: http://cr.openjdk.java.net/~dpochepk/8139438/webrev.01/ > > Thanks, > Dmitrij -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Wed Oct 14 18:55:02 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 14 Oct 2015 08:55:02 -1000 Subject: RFR (XL): 8139170: JVMCI refresh In-Reply-To: <561E1A6C.7060306@oracle.com> References: <6ECC12F2-8693-43AD-8F08-B7E3F21AEB40@oracle.com> <561C863D.7080800@oracle.com> <48004E32-6D60-4E40-9FF0-F0E4148D0344@oracle.com> <561E1A6C.7060306@oracle.com> Message-ID: <3539A5FA-A879-424B-B3C1-4BF11A98ACE1@oracle.com> > On Oct 13, 2015, at 11:03 PM, Vladimir Kozlov wrote: > > >> It would be good if we would run at least one JVMCI test in JPRT. > > If they are stable you can add them (compiler/jvmci for all) to hotspot_compiler_3 in test/TEST.groups I?ll let Igor I. do that. > > Changes looks good. Thanks. > > Thanks, > Vladimir > > On 10/14/15 2:31 AM, Christian Thalinger wrote: >> webrev updated. >> >>> On Oct 13, 2015, at 8:01 AM, Christian Thalinger >>> >> > wrote: >>> >>>> >>>> On Oct 12, 2015, at 10:59 PM, Doug Simon >>> > wrote: >>>> >>>>> >>>>> On 13 Oct 2015, at 06:19, Vladimir Kozlov >>>>> > wrote: >>>>> >>>>> Since we will get more changes from labs later we may enumerate >>>>> them: JVMCI refresh 1. >>>> >>>> Or, pessimistically, JVMCI refresh 01 ;-) >>>> >>>>> Can you explain new sed command in Gensrc-jdk.vm.ci.gmk. >>>> >>>> http://hg.openjdk.java.net/graal/graal-jvmci-8/rev/1852abfbaca3 >>>> >>>>> Are you sure it works on windows? >>>> >>>> I can?t say for sure but given that I see similar patterns in other >>>> *.gmk files, I think it should be fine. >>> >>> It would be good if we would run at least one JVMCI test in JPRT. >>> >>>> >>>>> Instead of is_trivial(method) may be we should have general function >>>>> called from AdvancedThresholdPolicy::common() which return >>>>> compilation level for particular method (for example, we can also >>>>> limit it using compilecommand). Could be done as separate change >>>>> after this. >>>>> >>>>> I looked on jdk.vm.ci changes and nothing looks terrible wrong. I am >>>>> not familiar with it so I can't say that each line is correct. One >>>>> thing I am wondering is why explicit imports are used instead of .* >>>>> (compilation speed?): >>>> >>>> http://mail.openjdk.java.net/pipermail/graal-dev/2015-September/003546.html >>>> >>>>> -import java.lang.annotation.*; >>>>> +import java.lang.annotation.ElementType; >>>>> +import java.lang.annotation.Retention; >>>>> +import java.lang.annotation.RetentionPolicy; >>>>> +import java.lang.annotation.Target; >>>>> >>>>> An other thing is using AMD64/amd64 in files and directory names. >>>>> May be we should rename it to x64. >>>>> >>>>> jvmciCodeInstaller_x86.cpp and jvmciCodeInstaller.cpp has next pattern: >>>>> + if (HotSpotMetaspaceConstantImpl::compressed(constant)) { >>>>> +#ifdef _LP64 >>>>> + ... >>>>> +#else >>>>> + fatal("unexpected compressed Klass* in 32-bit mode"); >>>>> +#endif >>>>> + } else { >>>>> >>>>> It would be nice to hide fatal() in some wrapper function. >>>>> >>>>> jvmciEnv.cpp use ASSERT instead of DEBUG. We renamed ifdef DEBUG >>>>> long ago. >>>>> >>>>> globals.hpp changes conflict with 8139377. >>>> >>>> Then we should adopt 8139377 instead. >>> >>> When I created the review 8139377 was not integrated yet. Let me pull >>> again. >>> >>>> >>>>> Tests changes (mostly renaming) looks fine. >>>>> >>>>> Fix copyright years (2015, 2015) in new files. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/13/15 10:19 AM, Christian Thalinger wrote: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8139170 >>>>>> http://cr.openjdk.java.net/~twisti/8139170/webrev/ >>>>>> >>>>>> During the review period for JEP 243 there were some changes and >>>>>> enhancements to the JVMCI code done by Oracle Labs. In order to not >>>>>> disturb the already long and complicated review of JEP 243 we >>>>>> decided to do a refresh after the initial integration. >>>>>> >>>>>> A lot of the Java changes is switching to using explicit imports. >> From christian.thalinger at oracle.com Wed Oct 14 19:19:20 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 14 Oct 2015 09:19:20 -1000 Subject: JVMCI Status In-Reply-To: <561E1B69.8000006@redhat.com> References: <561E1B69.8000006@redhat.com> Message-ID: <62D75AE6-6B33-4B33-975B-83340C21E66B@oracle.com> > On Oct 13, 2015, at 11:07 PM, Andrew Haley wrote: > > I've been trying to keep up with all the JVMCI discussion, but not > entirely successfully. > > Is it now stable enough for an AArch64 port, or is it still in flux? It will be stable after we integrate 8139170. > If it is ready, which repository should I use? You can either wait for it to propagate to jdk9 or work with hs-comp. Btw. there is an AArch64 port of Graal: https://bitbucket.org/voo/aarch64-graal/overview It?s very outdated but I have been in contact with Daniel trying to convince him to pick up his work again and contribute the port to the Graal OpenJDK project. > > Thanks, > > Andrew. > From christian.thalinger at oracle.com Wed Oct 14 19:23:07 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 14 Oct 2015 09:23:07 -1000 Subject: RFR (XS): 8139558 [JVMCI] SPARC hits: guarantee(heap_end < allocation_end) failed: heap end too close to end of address space (might lead to erroneous TLAB allocations) In-Reply-To: <561DBAAB.7080809@oracle.com> References: <561DBAAB.7080809@oracle.com> Message-ID: <08FAC2C4-7137-4ED2-B9E2-4617CD54C21B@oracle.com> > On Oct 13, 2015, at 4:15 PM, Vladimir Kozlov wrote: > > Okay. I saw this fix in JVMCI refresh changes. Right, but we need to push it separately in order to avoid the noise in nightly testing. Thanks for the review. > > Thanks, > Vladimir > > On 10/14/15 3:02 AM, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8139558 >> >> This assert can trigger trivially on SPARC so we have to disable it. >> >> diff -r 0ca52fb7d980 src/share/vm/jvmci/jvmciRuntime.cpp >> --- a/src/share/vm/jvmci/jvmciRuntime.cppTue Sep 29 17:01:37 2015 +0000 >> +++ b/src/share/vm/jvmci/jvmciRuntime.cppTue Oct 13 09:02:29 2015 -1000 >> @@ -778,9 +778,11 @@ JVM_ENTRY(void, JVM_RegisterJVMCINatives >> } >> >> >> #ifdef _LP64 >> +#ifndef TARGET_ARCH_sparc >> uintptr_t heap_end = (uintptr_t) >> Universe::heap()->reserved_region().end(); >> uintptr_t allocation_end = heap_end + ((uintptr_t)16) * 1024 * 1024 >> * 1024; >> guarantee(heap_end < allocation_end, "heap end too close to end of >> address space (might lead to erroneous TLAB allocations)"); >> +#endif // TARGET_ARCH_sparc >> #else >> fatal("check TLAB allocation code for address space conflicts"); >> #endif >> From christian.thalinger at oracle.com Wed Oct 14 19:44:27 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 14 Oct 2015 09:44:27 -1000 Subject: [9] RFR 8072369: [TESTBUG] Remove potentially insecure class cast in some hotspot tests In-Reply-To: <561E6930.3030301@oracle.com> References: <55EF0649.8050109@oracle.com> <55F0312E.7020908@oracle.com> <56153A30.7040705@oracle.com> <561E6930.3030301@oracle.com> Message-ID: <46DD5D9E-108E-4206-AF44-E7F7C4D00219@oracle.com> Oops. Forgot to reply. Looks good. > On Oct 14, 2015, at 4:39 AM, Konstantin Shefov wrote: > > Hello > > Kindly reminder. > > Thanks > -Konstantin > > On 10/07/2015 06:28 PM, Konstantin Shefov wrote: >> Hi Christian >> >> The assumption that the Application Class Loader is an instance of URLClassLoader can be false, because, AFAIK, it is not documented anywhere. >> This may become false in the future releases of JDK. >> That is why it is better not to relay on this assumption. >> >> Thanks >> -Konstantin >> >> 06.10.2015 22:35, Christian Thalinger ?????: >>> >>>> On Sep 9, 2015, at 3:16 AM, Konstantin Shefov > wrote: >>>> >>>> Description of the fix. >>>> Some tests in hotspot repo use class cast from Application class loader to URLClassLoader, but Application class loader is not guaranteed to be always an instance of a URLClassLoader. >>> >>> Please excuse my lack of knowledge here but in what configuration does this happen? >>> >>>> The tests should be changed so that they do not cast appclassloader to URLClassLoader. >>>> >>>> -Konstantin >>>> >>>> On 09/08/2015 07:01 PM, Konstantin Shefov wrote: >>>>> Hello >>>>> >>>>> Please review a test bug fix. >>>>> >>>>> JBS entry: https://bugs.openjdk.java.net/browse/JDK-8072369 >>>>> Webrev: http://cr.openjdk.java.net/~kshefov/8072369/webrev.00 >>>>> >>>>> Thanks >>>>> -Konstantin >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Wed Oct 14 19:45:13 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 14 Oct 2015 09:45:13 -1000 Subject: AARCH64: 8139041: Redundant DMB instructions (CORRECTED ) In-Reply-To: <561D3370.6050503@redhat.com> References: <561505E4.207@redhat.com> <5617DF32.4090508@redhat.com> <56186321.6010505@oracle.com> <561D3370.6050503@redhat.com> Message-ID: > On Oct 13, 2015, at 6:38 AM, Andrew Haley wrote: > > On 10/10/2015 02:00 AM, Vladimir Kozlov wrote: >> On 10/10/15 2:47 AM, Christian Thalinger wrote: >>> >>>> On Oct 9, 2015, at 5:37 AM, Andrew Haley wrote: >>>> >>>> Hi, >>>> >>>> On 10/09/2015 03:59 PM, Roland Westrelin wrote: >>>> >>>>>> There is a much simpler way: remove adjacent barriers in >>>>>> MacroAssembler. Thanks to the way that the AArch64 ISA is designed, >>>>>> barriers can be merged simply by ORing them together. Of course, this >>>>>> technique works for C1 and C2, and it adds essentially nothing to the >>>>>> compilation time. >>>>>> >>>>>> http://cr.openjdk.java.net/~aph/8139041/ >>>>>> >>>>>> One thing which may be controversial is that I've added a field to >>>>>> CodeBuffer to keep track of barriers and labels. I had to do this >>>>>> because when we're compiling there is (AFAICS) essentially nowhere >>>>>> else to keep the state. >>> >>> I don?t think it matters to have an additional field in CodeBuffer. It?s a temporary data structure and we use much more memory for graphs. >>> >>> I would even go that far and questioning putting it under #ifdef AARCH64. >> >> +1 that. > > OK. I'm guessing that PPC will want to use this anyway. > > http://cr.openjdk.java.net/~aph/8139041-2 Looks good. > > Andrew. -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.simon at oracle.com Wed Oct 14 19:57:30 2015 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 14 Oct 2015 21:57:30 +0200 Subject: JVMCI Status In-Reply-To: <561E1B69.8000006@redhat.com> References: <561E1B69.8000006@redhat.com> Message-ID: Hi Andrew, If you?re game, you can use the instructions at https://bugs.openjdk.java.net/browse/GRAAL-56 as a starting point for an AArch64 port. -Doug > On 14 Oct 2015, at 11:07, Andrew Haley wrote: > > I've been trying to keep up with all the JVMCI discussion, but not > entirely successfully. > > Is it now stable enough for an AArch64 port, or is it still in flux? > If it is ready, which repository should I use? > > Thanks, > > Andrew. > From john.r.rose at oracle.com Wed Oct 14 20:50:22 2015 From: john.r.rose at oracle.com (John Rose) Date: Wed, 14 Oct 2015 13:50:22 -0700 Subject: RFR(M): 8137168: Replace IfNode with a new RangeCheckNode for range checks In-Reply-To: <123219133.1396775.1444811837065.JavaMail.zimbra@u-pem.fr> References: <9E9DF2F9-9F85-47BA-9AAA-3BD14985357A@oracle.com> <069DE39F-D3CA-46D7-8C0B-03C089977387@oracle.com> <123219133.1396775.1444811837065.JavaMail.zimbra@u-pem.fr> Message-ID: <2395B89F-E233-4C04-8427-5743E46903EB@oracle.com> On Oct 14, 2015, at 1:37 AM, Remi Forax wrote: > > Re-reading your mail, > you don't even need 25 bytecodes if you put everything in local variables and use then as registers, I think you only need 7 :) > https://github.com/forax/vmboiler/blob/master/src/com/github/forax/vmboiler/CodeGen.java#L43 We could squeeze it down to 3: S/K or A/B plus a load-constant. https://en.wikipedia.org/wiki/Combinatory_logic And, yours is a nice trade-off. ? John From vivek.r.deshpande at intel.com Wed Oct 14 21:18:56 2015 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Wed, 14 Oct 2015 21:18:56 +0000 Subject: RFR (M): 8139575: Update for x86 log in the math lib Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A568B3FB5@ORSMSX106.amr.corp.intel.com> Hi all I would like to contribute a patch which optimizes Math.log() for 64 and 32 bit X86 architecture using Intel LIBM implementation. The improvement gives 1.9x gain over base. Could you please review and sponsor this patch. Bug-id: https://bugs.openjdk.java.net/browse/JDK-8139575 webrev: http://cr.openjdk.java.net/~mcberg/8139575/webrev_01/ Thanks and regards, Vivek -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Wed Oct 14 22:33:54 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 15 Oct 2015 01:33:54 +0300 Subject: RFR(XS) : 8138794 : [TESTBUG] ctw tests fail to compile after 8137056 Message-ID: http://cr.openjdk.java.net/~iignatyev/8138794/webrev.00/index.html > 1 line changed: 0 ins; 0 del; 1 mod; Hi all, could you please review this 1-line patch? it simply updates tests according to 8137056 which moved sun.misc.SharedSecrets to jdk.internal.misc package. bug: https://bugs.openjdk.java.net/browse/JDK-8138794 ? Thanks, Igor From christian.thalinger at oracle.com Wed Oct 14 23:13:34 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 14 Oct 2015 13:13:34 -1000 Subject: RFR(S): JDK-8139438: [TESTBUG] JVMCI test fails with RuntimeException: Has no virtual object before materialization In-Reply-To: <561E9F03.9070502@oracle.com> References: <561D6645.7040300@oracle.com> <561E9F03.9070502@oracle.com> Message-ID: <88226C8C-A693-4E05-BF79-689013BAEED9@oracle.com> > On Oct 14, 2015, at 8:29 AM, Dmitrij Pochepko wrote: > > Hi, > > an issue with 1st version was found: a getDeclaredMethod parameter(line 67) wasn't changed according to testFrame method signature change. > Now changed from Integer.class boolean.class > > Please take a look at 2nd version: http://cr.openjdk.java.net/~dpochepk/8139438/webrev.02 + int levels[] = CompilerUtils.getAvailableCompilationLevels(); + // we need compilation level 4 to use EscapeAnalysis + if (levels.length < 1 || levels[levels.length - 1] != 4) { To be more robust against future changes of this WB method you should search the array for level 4 instead of assuming it?s in the last element. Otherwise this looks good. > > Thanks, > Dmitrij > > On 13.10.2015 23:15, Dmitrij Pochepko wrote: >> Hi, >> >> please review a small fix for test: compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java >> >> Description: >> >> A test is changed to run testcases in separate VM launch instead of consecutive execution, which had wrong assumption about method compilation state in case of -XX:-TieredCompilation. >> So, a boolean system property is added into test to control test execution logic externally. >> I've also added minor code cleanup. >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8139438/webrev.01/ >> >> Thanks, >> Dmitrij > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Wed Oct 14 23:34:08 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 15 Oct 2015 02:34:08 +0300 Subject: RFR(S): JDK-8139438: [TESTBUG] JVMCI test fails with RuntimeException: Has no virtual object before materialization In-Reply-To: <88226C8C-A693-4E05-BF79-689013BAEED9@oracle.com> References: <561D6645.7040300@oracle.com> <561E9F03.9070502@oracle.com> <88226C8C-A693-4E05-BF79-689013BAEED9@oracle.com> Message-ID: <7F1CB257-18F4-48FC-9CC3-DFE641191A37@oracle.com> Hi Chris, Thanks for review. we will address your comment later as a fix for RFE(JDK-8139619) if you don?t mind. Thanks, - Igor > On Oct 15, 2015, at 2:13 AM, Christian Thalinger wrote: > > >> On Oct 14, 2015, at 8:29 AM, Dmitrij Pochepko > wrote: >> >> Hi, >> >> an issue with 1st version was found: a getDeclaredMethod parameter(line 67) wasn't changed according to testFrame method signature change. >> Now changed from Integer.class boolean.class >> >> Please take a look at 2nd version: http://cr.openjdk.java.net/~dpochepk/8139438/webrev.02 > > + int levels[] = CompilerUtils.getAvailableCompilationLevels(); > + // we need compilation level 4 to use EscapeAnalysis > + if (levels.length < 1 || levels[levels.length - 1] != 4) { > > To be more robust against future changes of this WB method you should search the array for level 4 instead of assuming it?s in the last element. > > Otherwise this looks good. > >> >> Thanks, >> Dmitrij >> >> On 13.10.2015 23:15, Dmitrij Pochepko wrote: >>> Hi, >>> >>> please review a small fix for test: compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java >>> >>> Description: >>> >>> A test is changed to run testcases in separate VM launch instead of consecutive execution, which had wrong assumption about method compilation state in case of -XX:-TieredCompilation. >>> So, a boolean system property is added into test to control test execution logic externally. >>> I've also added minor code cleanup. >>> >>> webrev: http://cr.openjdk.java.net/~dpochepk/8139438/webrev.01/ >>> >>> Thanks, >>> Dmitrij >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Thu Oct 15 00:01:54 2015 From: dean.long at oracle.com (Dean Long) Date: Wed, 14 Oct 2015 17:01:54 -0700 Subject: RFR(XS) : 8138794 : [TESTBUG] ctw tests fail to compile after 8137056 In-Reply-To: References: Message-ID: <561EECF2.8030204@oracle.com> Looks good to me. dl On 10/14/2015 3:33 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8138794/webrev.00/index.html >> 1 line changed: 0 ins; 0 del; 1 mod; > Hi all, > > could you please review this 1-line patch? it simply updates tests according to 8137056 which moved sun.misc.SharedSecrets to jdk.internal.misc package. > > bug: https://bugs.openjdk.java.net/browse/JDK-8138794 > > ? > Thanks, > Igor From christian.thalinger at oracle.com Thu Oct 15 00:05:11 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 14 Oct 2015 14:05:11 -1000 Subject: RFR(S): JDK-8139438: [TESTBUG] JVMCI test fails with RuntimeException: Has no virtual object before materialization In-Reply-To: <7F1CB257-18F4-48FC-9CC3-DFE641191A37@oracle.com> References: <561D6645.7040300@oracle.com> <561E9F03.9070502@oracle.com> <88226C8C-A693-4E05-BF79-689013BAEED9@oracle.com> <7F1CB257-18F4-48FC-9CC3-DFE641191A37@oracle.com> Message-ID: <30332160-41CF-473D-ADF2-B9F7A9894F34@oracle.com> > On Oct 14, 2015, at 1:34 PM, Igor Ignatyev wrote: > > Hi Chris, > > Thanks for review. we will address your comment later as a fix for RFE(JDK-8139619) if you don?t mind. Sure. > > Thanks, > - Igor > >> On Oct 15, 2015, at 2:13 AM, Christian Thalinger > wrote: >> >> >>> On Oct 14, 2015, at 8:29 AM, Dmitrij Pochepko > wrote: >>> >>> Hi, >>> >>> an issue with 1st version was found: a getDeclaredMethod parameter(line 67) wasn't changed according to testFrame method signature change. >>> Now changed from Integer.class boolean.class >>> >>> Please take a look at 2nd version: http://cr.openjdk.java.net/~dpochepk/8139438/webrev.02 >> >> + int levels[] = CompilerUtils.getAvailableCompilationLevels(); >> + // we need compilation level 4 to use EscapeAnalysis >> + if (levels.length < 1 || levels[levels.length - 1] != 4) { >> >> To be more robust against future changes of this WB method you should search the array for level 4 instead of assuming it?s in the last element. >> >> Otherwise this looks good. >> >>> >>> Thanks, >>> Dmitrij >>> >>> On 13.10.2015 23:15, Dmitrij Pochepko wrote: >>>> Hi, >>>> >>>> please review a small fix for test: compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java >>>> >>>> Description: >>>> >>>> A test is changed to run testcases in separate VM launch instead of consecutive execution, which had wrong assumption about method compilation state in case of -XX:-TieredCompilation. >>>> So, a boolean system property is added into test to control test execution logic externally. >>>> I've also added minor code cleanup. >>>> >>>> webrev: http://cr.openjdk.java.net/~dpochepk/8139438/webrev.01/ >>>> >>>> Thanks, >>>> Dmitrij >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Thu Oct 15 00:37:38 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 14 Oct 2015 14:37:38 -1000 Subject: RFR (XL): 8139170: JVMCI refresh In-Reply-To: <3539A5FA-A879-424B-B3C1-4BF11A98ACE1@oracle.com> References: <6ECC12F2-8693-43AD-8F08-B7E3F21AEB40@oracle.com> <561C863D.7080800@oracle.com> <48004E32-6D60-4E40-9FF0-F0E4148D0344@oracle.com> <561E1A6C.7060306@oracle.com> <3539A5FA-A879-424B-B3C1-4BF11A98ACE1@oracle.com> Message-ID: <634083B2-FA94-4A10-85A8-DC8F2DED7F3A@oracle.com> I have pulled two SPARC changes: http://lafo.ssw.uni-linz.ac.at/hg/graal-jvmci-9/rev/c158981b3c59 http://lafo.ssw.uni-linz.ac.at/hg/graal-jvmci-9/rev/110a130aa88b and updated the webrev to include (actually exclude) the individual bug fixes pushed to hs-comp. > On Oct 14, 2015, at 8:55 AM, Christian Thalinger wrote: > > >> On Oct 13, 2015, at 11:03 PM, Vladimir Kozlov wrote: >> >>>> It would be good if we would run at least one JVMCI test in JPRT. >> >> If they are stable you can add them (compiler/jvmci for all) to hotspot_compiler_3 in test/TEST.groups > > I?ll let Igor I. do that. > >> >> Changes looks good. > > Thanks. > >> >> Thanks, >> Vladimir >> >> On 10/14/15 2:31 AM, Christian Thalinger wrote: >>> webrev updated. >>> >>>> On Oct 13, 2015, at 8:01 AM, Christian Thalinger >>>> >>> > wrote: >>>> >>>>> >>>>> On Oct 12, 2015, at 10:59 PM, Doug Simon >>>> > wrote: >>>>> >>>>>> >>>>>> On 13 Oct 2015, at 06:19, Vladimir Kozlov >>>>>> > wrote: >>>>>> >>>>>> Since we will get more changes from labs later we may enumerate >>>>>> them: JVMCI refresh 1. >>>>> >>>>> Or, pessimistically, JVMCI refresh 01 ;-) >>>>> >>>>>> Can you explain new sed command in Gensrc-jdk.vm.ci.gmk. >>>>> >>>>> http://hg.openjdk.java.net/graal/graal-jvmci-8/rev/1852abfbaca3 >>>>> >>>>>> Are you sure it works on windows? >>>>> >>>>> I can?t say for sure but given that I see similar patterns in other >>>>> *.gmk files, I think it should be fine. >>>> >>>> It would be good if we would run at least one JVMCI test in JPRT. >>>> >>>>> >>>>>> Instead of is_trivial(method) may be we should have general function >>>>>> called from AdvancedThresholdPolicy::common() which return >>>>>> compilation level for particular method (for example, we can also >>>>>> limit it using compilecommand). Could be done as separate change >>>>>> after this. >>>>>> >>>>>> I looked on jdk.vm.ci changes and nothing looks terrible wrong. I am >>>>>> not familiar with it so I can't say that each line is correct. One >>>>>> thing I am wondering is why explicit imports are used instead of .* >>>>>> (compilation speed?): >>>>> >>>>> http://mail.openjdk.java.net/pipermail/graal-dev/2015-September/003546.html >>>>> >>>>>> -import java.lang.annotation.*; >>>>>> +import java.lang.annotation.ElementType; >>>>>> +import java.lang.annotation.Retention; >>>>>> +import java.lang.annotation.RetentionPolicy; >>>>>> +import java.lang.annotation.Target; >>>>>> >>>>>> An other thing is using AMD64/amd64 in files and directory names. >>>>>> May be we should rename it to x64. >>>>>> >>>>>> jvmciCodeInstaller_x86.cpp and jvmciCodeInstaller.cpp has next pattern: >>>>>> + if (HotSpotMetaspaceConstantImpl::compressed(constant)) { >>>>>> +#ifdef _LP64 >>>>>> + ... >>>>>> +#else >>>>>> + fatal("unexpected compressed Klass* in 32-bit mode"); >>>>>> +#endif >>>>>> + } else { >>>>>> >>>>>> It would be nice to hide fatal() in some wrapper function. >>>>>> >>>>>> jvmciEnv.cpp use ASSERT instead of DEBUG. We renamed ifdef DEBUG >>>>>> long ago. >>>>>> >>>>>> globals.hpp changes conflict with 8139377. >>>>> >>>>> Then we should adopt 8139377 instead. >>>> >>>> When I created the review 8139377 was not integrated yet. Let me pull >>>> again. >>>> >>>>> >>>>>> Tests changes (mostly renaming) looks fine. >>>>>> >>>>>> Fix copyright years (2015, 2015) in new files. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 10/13/15 10:19 AM, Christian Thalinger wrote: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8139170 >>>>>>> http://cr.openjdk.java.net/~twisti/8139170/webrev/ >>>>>>> >>>>>>> During the review period for JEP 243 there were some changes and >>>>>>> enhancements to the JVMCI code done by Oracle Labs. In order to not >>>>>>> disturb the already long and complicated review of JEP 243 we >>>>>>> decided to do a refresh after the initial integration. >>>>>>> >>>>>>> A lot of the Java changes is switching to using explicit imports. >>> > From vladimir.kozlov at oracle.com Thu Oct 15 03:50:42 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 15 Oct 2015 11:50:42 +0800 Subject: RFR (XL): 8139170: JVMCI refresh In-Reply-To: <634083B2-FA94-4A10-85A8-DC8F2DED7F3A@oracle.com> References: <6ECC12F2-8693-43AD-8F08-B7E3F21AEB40@oracle.com> <561C863D.7080800@oracle.com> <48004E32-6D60-4E40-9FF0-F0E4148D0344@oracle.com> <561E1A6C.7060306@oracle.com> <3539A5FA-A879-424B-B3C1-4BF11A98ACE1@oracle.com> <634083B2-FA94-4A10-85A8-DC8F2DED7F3A@oracle.com> Message-ID: <561F2292.4050602@oracle.com> Okay. Thanks, Vladimir On 10/15/15 8:37 AM, Christian Thalinger wrote: > I have pulled two SPARC changes: > > http://lafo.ssw.uni-linz.ac.at/hg/graal-jvmci-9/rev/c158981b3c59 > http://lafo.ssw.uni-linz.ac.at/hg/graal-jvmci-9/rev/110a130aa88b > > and updated the webrev to include (actually exclude) the individual bug fixes pushed to hs-comp. > >> On Oct 14, 2015, at 8:55 AM, Christian Thalinger wrote: >> >> >>> On Oct 13, 2015, at 11:03 PM, Vladimir Kozlov wrote: >>> >>>>> It would be good if we would run at least one JVMCI test in JPRT. >>> >>> If they are stable you can add them (compiler/jvmci for all) to hotspot_compiler_3 in test/TEST.groups >> >> I?ll let Igor I. do that. >> >>> >>> Changes looks good. >> >> Thanks. >> >>> >>> Thanks, >>> Vladimir >>> >>> On 10/14/15 2:31 AM, Christian Thalinger wrote: >>>> webrev updated. >>>> >>>>> On Oct 13, 2015, at 8:01 AM, Christian Thalinger >>>>> >>>> > wrote: >>>>> >>>>>> >>>>>> On Oct 12, 2015, at 10:59 PM, Doug Simon >>>>> > wrote: >>>>>> >>>>>>> >>>>>>> On 13 Oct 2015, at 06:19, Vladimir Kozlov >>>>>>> > wrote: >>>>>>> >>>>>>> Since we will get more changes from labs later we may enumerate >>>>>>> them: JVMCI refresh 1. >>>>>> >>>>>> Or, pessimistically, JVMCI refresh 01 ;-) >>>>>> >>>>>>> Can you explain new sed command in Gensrc-jdk.vm.ci.gmk. >>>>>> >>>>>> http://hg.openjdk.java.net/graal/graal-jvmci-8/rev/1852abfbaca3 >>>>>> >>>>>>> Are you sure it works on windows? >>>>>> >>>>>> I can?t say for sure but given that I see similar patterns in other >>>>>> *.gmk files, I think it should be fine. >>>>> >>>>> It would be good if we would run at least one JVMCI test in JPRT. >>>>> >>>>>> >>>>>>> Instead of is_trivial(method) may be we should have general function >>>>>>> called from AdvancedThresholdPolicy::common() which return >>>>>>> compilation level for particular method (for example, we can also >>>>>>> limit it using compilecommand). Could be done as separate change >>>>>>> after this. >>>>>>> >>>>>>> I looked on jdk.vm.ci changes and nothing looks terrible wrong. I am >>>>>>> not familiar with it so I can't say that each line is correct. One >>>>>>> thing I am wondering is why explicit imports are used instead of .* >>>>>>> (compilation speed?): >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/graal-dev/2015-September/003546.html >>>>>> >>>>>>> -import java.lang.annotation.*; >>>>>>> +import java.lang.annotation.ElementType; >>>>>>> +import java.lang.annotation.Retention; >>>>>>> +import java.lang.annotation.RetentionPolicy; >>>>>>> +import java.lang.annotation.Target; >>>>>>> >>>>>>> An other thing is using AMD64/amd64 in files and directory names. >>>>>>> May be we should rename it to x64. >>>>>>> >>>>>>> jvmciCodeInstaller_x86.cpp and jvmciCodeInstaller.cpp has next pattern: >>>>>>> + if (HotSpotMetaspaceConstantImpl::compressed(constant)) { >>>>>>> +#ifdef _LP64 >>>>>>> + ... >>>>>>> +#else >>>>>>> + fatal("unexpected compressed Klass* in 32-bit mode"); >>>>>>> +#endif >>>>>>> + } else { >>>>>>> >>>>>>> It would be nice to hide fatal() in some wrapper function. >>>>>>> >>>>>>> jvmciEnv.cpp use ASSERT instead of DEBUG. We renamed ifdef DEBUG >>>>>>> long ago. >>>>>>> >>>>>>> globals.hpp changes conflict with 8139377. >>>>>> >>>>>> Then we should adopt 8139377 instead. >>>>> >>>>> When I created the review 8139377 was not integrated yet. Let me pull >>>>> again. >>>>> >>>>>> >>>>>>> Tests changes (mostly renaming) looks fine. >>>>>>> >>>>>>> Fix copyright years (2015, 2015) in new files. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 10/13/15 10:19 AM, Christian Thalinger wrote: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8139170 >>>>>>>> http://cr.openjdk.java.net/~twisti/8139170/webrev/ >>>>>>>> >>>>>>>> During the review period for JEP 243 there were some changes and >>>>>>>> enhancements to the JVMCI code done by Oracle Labs. In order to not >>>>>>>> disturb the already long and complicated review of JEP 243 we >>>>>>>> decided to do a refresh after the initial integration. >>>>>>>> >>>>>>>> A lot of the Java changes is switching to using explicit imports. >>>> >> > From vladimir.kozlov at oracle.com Thu Oct 15 04:09:49 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 15 Oct 2015 12:09:49 +0800 Subject: RFR(XS) : 8138794 : [TESTBUG] ctw tests fail to compile after 8137056 In-Reply-To: References: Message-ID: <561F270D.2030106@oracle.com> Good. Vladimir On 10/15/15 6:33 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8138794/webrev.00/index.html >> 1 line changed: 0 ins; 0 del; 1 mod; > > Hi all, > > could you please review this 1-line patch? it simply updates tests according to 8137056 which moved sun.misc.SharedSecrets to jdk.internal.misc package. > > bug: https://bugs.openjdk.java.net/browse/JDK-8138794 > > ? > Thanks, > Igor > From vladimir.kozlov at oracle.com Thu Oct 15 05:34:33 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 15 Oct 2015 13:34:33 +0800 Subject: [9] RFR 8072369: [TESTBUG] Remove potentially insecure class cast in some hotspot tests In-Reply-To: <561E72B5.3090403@oracle.com> References: <55EF0649.8050109@oracle.com> <55F0312E.7020908@oracle.com> <56153A30.7040705@oracle.com> <561E6930.3030301@oracle.com> <561E72B5.3090403@oracle.com> Message-ID: <561F3AE9.6040908@oracle.com> Looks good. Thanks, Vladimir On 10/14/15 11:20 PM, Konstantin Shefov wrote: > Vladimir, > > Thanks for reviewing. > I have modified the code according to your comments. > > http://cr.openjdk.java.net/~kshefov/8072369/webrev.01/ > > Regards, > -Konstantin > > On 10/14/2015 05:39 PM, Konstantin Shefov wrote: >> Hello >> >> Kindly reminder. >> >> Thanks >> -Konstantin >> >> On 10/07/2015 06:28 PM, Konstantin Shefov wrote: >>> Hi Christian >>> >>> The assumption that the Application Class Loader is an instance of >>> URLClassLoader can be false, because, AFAIK, it is not documented >>> anywhere. >>> This may become false in the future releases of JDK. >>> That is why it is better not to relay on this assumption. >>> >>> Thanks >>> -Konstantin >>> >>> 06.10.2015 22:35, Christian Thalinger ?????: >>>> >>>>> On Sep 9, 2015, at 3:16 AM, Konstantin Shefov >>>>> >>>> > wrote: >>>>> >>>>> Description of the fix. >>>>> Some tests in hotspot repo use class cast from Application class >>>>> loader to URLClassLoader, but Application class loader is not >>>>> guaranteed to be always an instance of a URLClassLoader. >>>> >>>> Please excuse my lack of knowledge here but in what configuration >>>> does this happen? >>>> >>>>> The tests should be changed so that they do not cast appclassloader >>>>> to URLClassLoader. >>>>> >>>>> -Konstantin >>>>> >>>>> On 09/08/2015 07:01 PM, Konstantin Shefov wrote: >>>>>> Hello >>>>>> >>>>>> Please review a test bug fix. >>>>>> >>>>>> JBS entry: https://bugs.openjdk.java.net/browse/JDK-8072369 >>>>>> Webrev: http://cr.openjdk.java.net/~kshefov/8072369/webrev.00 >>>>>> >>>>>> Thanks >>>>>> -Konstantin >>>>> >>>> >>> >> > From zoltan.majo at oracle.com Thu Oct 15 06:17:03 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 15 Oct 2015 08:17:03 +0200 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: <561D3C57.4010408@oracle.com> References: <56018E2B.2000108@oracle.com> <5614F60D.3040602@oracle.com> <56151DCE.90407@oracle.com> <56165D2A.7010407@oracle.com> <5616709C.809@oracle.com> <561D3C57.4010408@oracle.com> Message-ID: <561F44DF.10006@oracle.com> Hi Nils, On 10/13/2015 07:16 PM, Nils Eliasson wrote: > Hi Zoltan, > > Thanks for the feedback. > > The JDK webrev is here: > http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.02/ this looks good to me. Thank you and best regards, Zoltan > > I have fixed the comment too and will update the hotspot webrev shortly. > > Thanks, > Nils > > On 2015-10-08 15:33, Zolt?n Maj? wrote: >> Hi Nils, >> >> >> On 10/08/2015 02:10 PM, Nils Eliasson wrote: >>> Hi Zoltan, >>> >>> Thanks for the repro. Found a bug where the base directives got >>> corrupted. Added test cases to the >>> TestCompilerDirectivesCompatibility* which will cover that. >> >> Thank you for fixing the problem with the DisableIntrinsic flag (the >> flag works now as expected). >> >> I've spotted two other small problems: >> >> 1) src/share/vm/compiler/abstractCompiler.hpp >> >> 72 // - the intrinsic is enabled (by using the appropriate >> command-line flag >> 73 // , the command-line compile ommand, or a compiler directive) >> >> The comma on line 73 should be at the end of line 72. >> >> 2) In your JDK changes (I've looked at webrev_jdk.01, as I think >> there is no newer version): You have not declared the >> sun.hotspot.WhiteBox::shouldPrintAssembly(Ljava/lang/reflect/Executable;)Z >> method. As a result the VM is complaining if the WhiteBox API is >> enabled: >> >> Warning: 'NoSuchMethodError' on register of >> sun.hotspot.WhiteBox::shouldPrintAssembly(Ljava/lang/reflect/Executable;)Z >> >> >> Thank you and best regards, >> >> >> Zoltan >> >>> >>> New webrev: >>> http://cr.openjdk.java.net/~neliasso/8046155/webrev.10/ >>> >>> Best regards, >>> Nils >>> >>> >>> On 2015-10-07 15:27, Zolt?n Maj? wrote: >>>> Hi Nils, >>>> >>>> >>>> On 10/07/2015 12:38 PM, Nils Eliasson wrote: >>>>> Hi all, >>>>> >>>>> Latest webrev including fixes after comments from Chris and Zoltan: >>>>> http://cr.openjdk.java.net/~neliasso/8046155/webrev.09/ >>>> >>>> thank you for the updated version. It seems, however, that the >>>> DisableIntrinsic flag does not work correctly on the per-method level. >>>> >>>> If I execute the MathTest program I've sent out before with the >>>> command-line option >>>> >>>> -XX:CompileCommand=option,MathTest::test1,ccstr,DisableIntrinsic,_dsin >>>> >>>> with jdk9-b83, I get the expected behavior (Math.sin is inlined >>>> into test2 but not into test1): >>>> >>>> 128 1 b 3 MathTest::test1 (7 bytes) >>>> @ 3 java.lang.Math::sin (5 bytes) >>>> @ 1 java/lang/StrictMath::sin (not >>>> loaded) not inlineable >>>> 130 2 n 0 java.lang.StrictMath::sin (native) (static) >>>> 132 3 b 3 MathTest::test2 (7 bytes) >>>> @ 3 java.lang.Math::sin (5 bytes) >>>> intrinsic >>>> >>>> >>>> If I execute the test case with a locally-built jdk patched with >>>> webrev.09, I get an erronous behavior (Math.sin is not inlined into >>>> test2 although it should be): >>>> >>>> 133 1 b 3 MathTest::test1 (7 bytes) >>>> @ 3 java.lang.Math::sin (5 bytes) >>>> @ 1 java/lang/StrictMath::sin (not >>>> loaded) not inlineable >>>> 136 2 n 0 java.lang.StrictMath::sin (native) (static) >>>> 138 3 b 3 MathTest::test2 (7 bytes) >>>> @ 3 java.lang.Math::sin (5 bytes) >>>> @ 1 java.lang.StrictMath::sin (0 >>>> bytes) native method >>>> >>>> Could you please check why that happens? >>>> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> >>>> >>>> >>>>> >>>>> Regards, >>>>> //Nils >>>>> >>>>> >>>>> >>>>> On 2015-09-22 19:21, Nils Eliasson wrote: >>>>> > Hi, > > This is the initial RFR for JEP165: Compiler Control. >>>>> This feature > enables runtime manageable, method dependent >>>>> compiler flags. > (Immutable for the duration of a compilation.) > >>>>> > The change includes: - A parser for the directives format (json >>>>> like) > including vmtests (json.cpp/hpp) - A component for >>>>> construction of > compiler directives (directivesParser.cpp/hpp) - >>>>> The directives > including the option definitions, default values >>>>> and compilecommand > relations (compilerDirectives.cpp/hpp) - >>>>> Diagnostic commands for > working with the directives - >>>>> installing, removing, printing - Lots > of small changes wherever >>>>> we access flags or legacy compilecommands > in the compiler > > >>>>> Notes: The feature is documented in the JEP > >>>>> (https://bugs.openjdk.java.net/browse/JDK-8046155). > > Currently >>>>> only a small amount of compiler flags are included in the > >>>>> change. The flags are a representative selection of different >>>>> types > targeting both compilers. All of them existed as >>>>> CompilerOracle > option commands. Two commands was not included in >>>>> the directives due > to time constraints - >>>>> CompilerThresholdScaling and UseRTMLocks. Both > are accessed from >>>>> runtime (outside any compiler) and requires some > special >>>>> handling. (Solved but not implemented.) > > Full backwards >>>>> compatibility with CompileCommands is implemented but > can be >>>>> turned off with flag -XX:CompileCommandCompatibilty. Also meta > >>>>> handling the compatibility flag by supporting it in the directives >>>>> > (test feature). > > The change contain some rough edges that >>>>> will polished over the > coming days. > > JEP: >>>>> https://bugs.openjdk.java.net/browse/JDK-8046155 Hotspot webrev: > >>>>> http://cr.openjdk.java.net/~neliasso/8046155/webrev.01/ JDK >>>>> webrev: > >>>>> http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.01/ > > >>>>> Please review! > > Best regards, Nils Eliasson >>>>> >>>>> >>>> >>> >> > From pavel.punegov at oracle.com Thu Oct 15 11:22:57 2015 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Thu, 15 Oct 2015 14:22:57 +0300 Subject: RFR(M): 8066166: JEP-JDK-8046155: Test task: dcmd tests In-Reply-To: <561DB8AC.1050001@oracle.com> References: <561D3B83.8010307@oracle.com> <561DB8AC.1050001@oracle.com> Message-ID: <561F8C91.3090507@oracle.com> Thanks for review, Vladimir On 14.10.2015 05:06, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 10/14/15 1:12 AM, Pavel Punegov wrote: >> Please review the following tests for diagnostic commands in >> CompilerControl. >> >> This change extend the previous tests for CC with ability to add, remove >> or clear directives with diagnostic command. >> Each test generates one or several commands and directive file, then >> executes another VM, which will be used as a target VM for JCMD. >> After the test performed all diagnostic commands, the test VM will check >> that all methods are compiled or not in the same way it was done before. >> >> webrev: http://cr.openjdk.java.net/~ppunegov/8066166/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8066166 >> -- Thanks, Pavel Punegov From roland.westrelin at oracle.com Thu Oct 15 11:30:43 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 15 Oct 2015 13:30:43 +0200 Subject: RFR: Elide more final field's write memory barrier with escape analysis result In-Reply-To: References: <5612A2C6.5080108@redhat.com> <7C9B87B351A4BA4AA9EC95BB4181165672261165@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672261384@DEWDFEMB19C.global.corp.sap> Message-ID: <2CCD93AB-716E-4D81-A5B1-C008BC61E0F9@oracle.com> > Roland, would you please run JPRT test and sponsor this change? It?s in. Roland. From nils.eliasson at oracle.com Thu Oct 15 13:53:44 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 15 Oct 2015 15:53:44 +0200 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: <56018E2B.2000108@oracle.com> References: <56018E2B.2000108@oracle.com> Message-ID: <561FAFE8.5000901@oracle.com> Hi all, Here is the latest (final?) webrev. Changes since last time: - Fixed comments - update jdk webrev - Added test for verifying CompileCommand compatility - Fixed error messages when adding directives with diagnostic commands - Fixed bug on solaris sparc - synced with recent additions to hs-comp - Added flag DoReserveCopyInSuperWordDebug that was added as a CompileCommand option recently https://bugs.openjdk.java.net/browse/JDK-8046155 http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.03/ http://cr.openjdk.java.net/~neliasso/8046155/webrev.11/ Regards, Nils On 2015-09-22 19:21, Nils Eliasson wrote: > Hi, > > This is the initial RFR for JEP165: Compiler Control. This feature > enables runtime manageable, method dependent compiler flags. > (Immutable for the duration of a compilation.) > > The change includes: > - A parser for the directives format (json like) including vmtests > (json.cpp/hpp) > - A component for construction of compiler directives > (directivesParser.cpp/hpp) > - The directives including the option definitions, default values and > compilecommand relations (compilerDirectives.cpp/hpp) > - Diagnostic commands for working with the directives - installing, > removing, printing > - Lots of small changes wherever we access flags or legacy > compilecommands in the compiler > > Notes: > The feature is documented in the JEP > (https://bugs.openjdk.java.net/browse/JDK-8046155). > > Currently only a small amount of compiler flags are included in the > change. The flags are a representative selection of different types > targeting both compilers. All of them existed as CompilerOracle option > commands. Two commands was not included in the directives due to time > constraints - CompilerThresholdScaling and UseRTMLocks. Both are > accessed from runtime (outside any compiler) and requires some special > handling. (Solved but not implemented.) > > Full backwards compatibility with CompileCommands is implemented but > can be turned off with flag -XX:CompileCommandCompatibilty. Also meta > handling the compatibility flag by supporting it in the directives > (test feature). > > The change contain some rough edges that will polished over the coming > days. > > JEP: https://bugs.openjdk.java.net/browse/JDK-8046155 > Hotspot webrev: http://cr.openjdk.java.net/~neliasso/8046155/webrev.01/ > JDK webrev: http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.01/ > > Please review! > > Best regards, > Nils Eliasson From zoltan.majo at oracle.com Thu Oct 15 14:11:11 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 15 Oct 2015 16:11:11 +0200 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: <561FAFE8.5000901@oracle.com> References: <56018E2B.2000108@oracle.com> <561FAFE8.5000901@oracle.com> Message-ID: <561FB3FF.3030009@oracle.com> Hi, the parts I've looked at seem to be fine to me (I'm not a *R*eviewer). Thank you and best regards, Zoltan On 10/15/2015 03:53 PM, Nils Eliasson wrote: > Hi all, > > Here is the latest (final?) webrev. > > Changes since last time: > - Fixed comments > - update jdk webrev > - Added test for verifying CompileCommand compatility > - Fixed error messages when adding directives with diagnostic commands > - Fixed bug on solaris sparc > - synced with recent additions to hs-comp > - Added flag DoReserveCopyInSuperWordDebug that was added as a > CompileCommand option recently > > https://bugs.openjdk.java.net/browse/JDK-8046155 > http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.03/ > http://cr.openjdk.java.net/~neliasso/8046155/webrev.11/ > > Regards, > Nils > > On 2015-09-22 19:21, Nils Eliasson wrote: >> Hi, >> >> This is the initial RFR for JEP165: Compiler Control. This feature >> enables runtime manageable, method dependent compiler flags. >> (Immutable for the duration of a compilation.) >> >> The change includes: >> - A parser for the directives format (json like) including vmtests >> (json.cpp/hpp) >> - A component for construction of compiler directives >> (directivesParser.cpp/hpp) >> - The directives including the option definitions, default values and >> compilecommand relations (compilerDirectives.cpp/hpp) >> - Diagnostic commands for working with the directives - installing, >> removing, printing >> - Lots of small changes wherever we access flags or legacy >> compilecommands in the compiler >> >> Notes: >> The feature is documented in the JEP >> (https://bugs.openjdk.java.net/browse/JDK-8046155). >> >> Currently only a small amount of compiler flags are included in the >> change. The flags are a representative selection of different types >> targeting both compilers. All of them existed as CompilerOracle >> option commands. Two commands was not included in the directives due >> to time constraints - CompilerThresholdScaling and UseRTMLocks. Both >> are accessed from runtime (outside any compiler) and requires some >> special handling. (Solved but not implemented.) >> >> Full backwards compatibility with CompileCommands is implemented but >> can be turned off with flag -XX:CompileCommandCompatibilty. Also meta >> handling the compatibility flag by supporting it in the directives >> (test feature). >> >> The change contain some rough edges that will polished over the >> coming days. >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8046155 >> Hotspot webrev: http://cr.openjdk.java.net/~neliasso/8046155/webrev.01/ >> JDK webrev: http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.01/ >> >> Please review! >> >> Best regards, >> Nils Eliasson > From edward.nevill at gmail.com Thu Oct 15 15:51:05 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 15 Oct 2015 16:51:05 +0100 Subject: RFR: 8139674: aarch64: guarantee failure in TestOptionsWithRanges.java Message-ID: <1444924265.30110.11.camel@mylittlepony.linaroharston> Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8139674/webrev/ JIRA issue: https://bugs.openjdk.java.net/browse/JDK-8139674 The hotspot jtreg test runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails with a guarantee failure. # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (assembler_aarch64.hpp:256), pid=22842, tid=22845 # guarantee(chk == -1 || chk == 0) failed: Field too big for insn What is happening is that the code in InterpreterMacroAssembler::profile_arguments_type adjusts mdp to point past the arguments and uses negative offsets to index fields at the start of the method data structure. However, negative ldr offsets are very limited on aarch64 (-256 bytes) so this easily overflows when TypeProfileArgsLimit is large (>=16). The solution is to defer incrementing mdp until we are finished with all the args and use positive offsets instead. Tested with hotspot jtreg Before: Test results: passed: 896; failed: 6; error: 10 After: Test results: passed: 896; failed: 5; error: 10 Thanks for your help, Ed. From aph at redhat.com Thu Oct 15 15:55:23 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 15 Oct 2015 16:55:23 +0100 Subject: RFR: 8139674: aarch64: guarantee failure in TestOptionsWithRanges.java In-Reply-To: <1444924265.30110.11.camel@mylittlepony.linaroharston> References: <1444924265.30110.11.camel@mylittlepony.linaroharston> Message-ID: <561FCC6B.7000008@redhat.com> On 10/15/2015 04:51 PM, Edward Nevill wrote: > Please review the following webrev > > http://cr.openjdk.java.net/~enevill/8139674/webrev/ > > JIRA issue: https://bugs.openjdk.java.net/browse/JDK-8139674 > > > The hotspot jtreg test runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails with a guarantee failure. > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (assembler_aarch64.hpp:256), pid=22842, tid=22845 > # guarantee(chk == -1 || chk == 0) failed: Field too big for insn > > What is happening is that the code in InterpreterMacroAssembler::profile_arguments_type adjusts mdp to point past the arguments and uses negative offsets to index fields at the start of the method data structure. > > However, negative ldr offsets are very limited on aarch64 (-256 bytes) so this easily overflows when TypeProfileArgsLimit is large (>=16). > > The solution is to defer incrementing mdp until we are finished with all the args and use positive offsets instead. > > Tested with hotspot jtreg > > Before: Test results: passed: 896; failed: 6; error: 10 > After: Test results: passed: 896; failed: 5; error: 10 Thanks. Do we know that it cannot overflow even the +ve offset range? Andrew. From edward.nevill at gmail.com Thu Oct 15 16:40:58 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 15 Oct 2015 17:40:58 +0100 Subject: RFR: 8139674: aarch64: guarantee failure in TestOptionsWithRanges.java In-Reply-To: <561FCC6B.7000008@redhat.com> References: <1444924265.30110.11.camel@mylittlepony.linaroharston> <561FCC6B.7000008@redhat.com> Message-ID: <1444927258.30930.3.camel@mint> On Thu, 2015-10-15 at 16:55 +0100, Andrew Haley wrote: > On 10/15/2015 04:51 PM, Edward Nevill wrote: > Thanks. Do we know that it cannot overflow even the +ve offset range? > > Andrew. > > Yes. Because mdp points at the method data struct, so all the fields are small positive offsets. The problem happens when you increment mdp after all the args at the end of the mdp struct. Then the offset can become <= -256. All the best, Ed. From aph at redhat.com Thu Oct 15 16:54:39 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 15 Oct 2015 17:54:39 +0100 Subject: RFR: 8139674: aarch64: guarantee failure in TestOptionsWithRanges.java In-Reply-To: <1444927258.30930.3.camel@mint> References: <1444924265.30110.11.camel@mylittlepony.linaroharston> <561FCC6B.7000008@redhat.com> <1444927258.30930.3.camel@mint> Message-ID: <561FDA4F.6070600@redhat.com> On 10/15/2015 05:40 PM, Edward Nevill wrote: > On Thu, 2015-10-15 at 16:55 +0100, Andrew Haley wrote: >> On 10/15/2015 04:51 PM, Edward Nevill wrote: > >> Thanks. Do we know that it cannot overflow even the +ve offset range? > > Yes. Because mdp points at the method data struct, so all the fields are small positive offsets. The problem happens when you increment mdp after all the args at the end of the mdp struct. Then the offset can become <= -256. OK, looks good. Thanks, Andrew. From pavel.punegov at oracle.com Thu Oct 15 18:34:58 2015 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Thu, 15 Oct 2015 21:34:58 +0300 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: <561FAFE8.5000901@oracle.com> References: <56018E2B.2000108@oracle.com> <561FAFE8.5000901@oracle.com> Message-ID: <561FF1D2.5080908@oracle.com> Hi, In TestCompilerDirectivesCompatibilityCommand* tests -XX:+UnlockDiagnosticVMOptions should be specified before the PrintAssembly 36 * @run testng/othervm -Xbootclasspath/a:. -XX:-PrintAssembly -XX:CompileCommand=option,*.helper,bool,PrintAssembly,false -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI TestCompilerDirectivesCompatibilityCommandOff Otherwise it looks good (not a Reviewer) On 15.10.2015 16:53, Nils Eliasson wrote: > Hi all, > > Here is the latest (final?) webrev. > > Changes since last time: > - Fixed comments > - update jdk webrev > - Added test for verifying CompileCommand compatility > - Fixed error messages when adding directives with diagnostic commands > - Fixed bug on solaris sparc > - synced with recent additions to hs-comp > - Added flag DoReserveCopyInSuperWordDebug that was added as a > CompileCommand option recently > > https://bugs.openjdk.java.net/browse/JDK-8046155 > http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.03/ > http://cr.openjdk.java.net/~neliasso/8046155/webrev.11/ > > Regards, > Nils > > On 2015-09-22 19:21, Nils Eliasson wrote: >> Hi, >> >> This is the initial RFR for JEP165: Compiler Control. This feature >> enables runtime manageable, method dependent compiler flags. >> (Immutable for the duration of a compilation.) >> >> The change includes: >> - A parser for the directives format (json like) including vmtests >> (json.cpp/hpp) >> - A component for construction of compiler directives >> (directivesParser.cpp/hpp) >> - The directives including the option definitions, default values and >> compilecommand relations (compilerDirectives.cpp/hpp) >> - Diagnostic commands for working with the directives - installing, >> removing, printing >> - Lots of small changes wherever we access flags or legacy >> compilecommands in the compiler >> >> Notes: >> The feature is documented in the JEP >> (https://bugs.openjdk.java.net/browse/JDK-8046155). >> >> Currently only a small amount of compiler flags are included in the >> change. The flags are a representative selection of different types >> targeting both compilers. All of them existed as CompilerOracle >> option commands. Two commands was not included in the directives due >> to time constraints - CompilerThresholdScaling and UseRTMLocks. Both >> are accessed from runtime (outside any compiler) and requires some >> special handling. (Solved but not implemented.) >> >> Full backwards compatibility with CompileCommands is implemented but >> can be turned off with flag -XX:CompileCommandCompatibilty. Also meta >> handling the compatibility flag by supporting it in the directives >> (test feature). >> >> The change contain some rough edges that will polished over the >> coming days. >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8046155 >> Hotspot webrev: http://cr.openjdk.java.net/~neliasso/8046155/webrev.01/ >> JDK webrev: http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.01/ >> >> Please review! >> >> Best regards, >> Nils Eliasson > -- Thanks, Pavel Punegov -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Thu Oct 15 21:12:49 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 15 Oct 2015 14:12:49 -0700 Subject: [9] RFR(XS): 8137173: @HotSpotIntrinsicCandidate is not Oracle-specific In-Reply-To: <560E1CDF.7070307@oracle.com> References: <560D51BD.6030108@oracle.com>, <560D540E.4090609@oracle.com>, <20151001085441.434440@eggemoggin.niobe.net>, <560E1CDF.7070307@oracle.com> Message-ID: <20151015141249.801300@eggemoggin.niobe.net> 2015/10/1 10:57 -0700, zoltan.majo at oracle.com: > On 10/01/2015 05:54 PM, mark.reinhold at oracle.com wrote: >> I suggest putting this into jdk.internal.vm.annotation, which is >> also a good place for the ReservedStackAccess annotation envisioned >> in JEP 270 (http://openjdk.java.net/jeps/270). > > I filed an RFE, JDK-8138732: "move @HotSpotIntrinsicCandidate to the > jdk.internal.vm.annotation package" [1], to track the issue of moving > the annotation to a different package. I hope I can take care of it soon. > > Thank you and best regards, Thanks. While you're at it, could you please rename the annotation to @IntrinsicCandidate? There's no need for the "HotSpot" prefix any more since this annotation will now be in a package that is reserved for VM-specific annotations. (Sorry for this late suggestion; this just came up in a discussion of the @ReservedStackAccess annotation for JEP 270, which is also destined for the jdk.internal.vm.annotation package.) (I've pasted this addendum into JDK-8138732.) - Mark From christian.thalinger at oracle.com Thu Oct 15 21:21:18 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 15 Oct 2015 11:21:18 -1000 Subject: JVMCI Status In-Reply-To: <62D75AE6-6B33-4B33-975B-83340C21E66B@oracle.com> References: <561E1B69.8000006@redhat.com> <62D75AE6-6B33-4B33-975B-83340C21E66B@oracle.com> Message-ID: Btw. here is a patch that adds dummy implementations for the files required to run most new JVMCI tests. -------------- next part -------------- A non-text attachment was scrubbed... Name: jvmci-aarch64.patch Type: application/octet-stream Size: 7514 bytes Desc: not available URL: -------------- next part -------------- > On Oct 14, 2015, at 9:19 AM, Christian Thalinger wrote: > > >> On Oct 13, 2015, at 11:07 PM, Andrew Haley wrote: >> >> I've been trying to keep up with all the JVMCI discussion, but not >> entirely successfully. >> >> Is it now stable enough for an AArch64 port, or is it still in flux? > > It will be stable after we integrate 8139170. > >> If it is ready, which repository should I use? > > You can either wait for it to propagate to jdk9 or work with hs-comp. > > Btw. there is an AArch64 port of Graal: > > https://bitbucket.org/voo/aarch64-graal/overview > > It?s very outdated but I have been in contact with Daniel trying to convince him to pick up his work again and contribute the port to the Graal OpenJDK project. > >> >> Thanks, >> >> Andrew. >> > From igor.ignatyev at oracle.com Thu Oct 15 21:40:15 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 16 Oct 2015 00:40:15 +0300 Subject: RFR(XS) : 8138794 : [TESTBUG] ctw tests fail to compile after 8137056 In-Reply-To: <561F270D.2030106@oracle.com> References: <561F270D.2030106@oracle.com> Message-ID: <07AE5F81-0187-4AC0-B904-0A6387D8A28B@oracle.com> Dean, Vladimir Thanks for review. - Igor From igor.ignatyev at oracle.com Thu Oct 15 23:00:10 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 16 Oct 2015 02:00:10 +0300 Subject: RFR (XS) : 8139707 : [TESTBUG] Quarantine unstable compiler/jvmci tests Message-ID: <629162F0-39E9-4C40-B2AD-AE51694F4974@oracle.com> http://cr.openjdk.java.net/~iignatyev/8139707/webrev.00/ > 3 lines changed: 3 ins; 0 del; 0 mod; Hi all, please review the patch which adds @ignore to three compiler/jvmci tests: - compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java fails w/ Xcomp due to JDK-8139703 - compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java and InvalidateInstalledCodeTest.java intermittently fail in some configuration due to JDK-8139700 bug : https://bugs.openjdk.java.net/browse/JDK-8139707 Thanks, - Igor From christian.thalinger at oracle.com Thu Oct 15 23:04:37 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 15 Oct 2015 13:04:37 -1000 Subject: RFR (XS) : 8139707 : [TESTBUG] Quarantine unstable compiler/jvmci tests In-Reply-To: <629162F0-39E9-4C40-B2AD-AE51694F4974@oracle.com> References: <629162F0-39E9-4C40-B2AD-AE51694F4974@oracle.com> Message-ID: Looks good. > On Oct 15, 2015, at 1:00 PM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev/8139707/webrev.00/ >> 3 lines changed: 3 ins; 0 del; 0 mod; > > Hi all, > > please review the patch which adds @ignore to three compiler/jvmci tests: > - compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java fails w/ Xcomp due to JDK-8139703 > - compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java and InvalidateInstalledCodeTest.java intermittently fail in some configuration due to JDK-8139700 > > bug : https://bugs.openjdk.java.net/browse/JDK-8139707 > > Thanks, > - Igor From igor.ignatyev at oracle.com Thu Oct 15 23:21:46 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 16 Oct 2015 02:21:46 +0300 Subject: RFR (XS) : 8139707 : [TESTBUG] Quarantine unstable compiler/jvmci tests In-Reply-To: References: <629162F0-39E9-4C40-B2AD-AE51694F4974@oracle.com> Message-ID: <3976895E-5EE3-4681-BEEC-0E5C4CF59718@oracle.com> Thank you for review, Chris. > On Oct 16, 2015, at 2:04 AM, Christian Thalinger wrote: > > Looks good. > >> On Oct 15, 2015, at 1:00 PM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev/8139707/webrev.00/ >>> 3 lines changed: 3 ins; 0 del; 0 mod; >> >> Hi all, >> >> please review the patch which adds @ignore to three compiler/jvmci tests: >> - compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java fails w/ Xcomp due to JDK-8139703 >> - compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java and InvalidateInstalledCodeTest.java intermittently fail in some configuration due to JDK-8139700 >> >> bug : https://bugs.openjdk.java.net/browse/JDK-8139707 >> >> Thanks, >> - Igor > From vladimir.kozlov at oracle.com Fri Oct 16 00:53:27 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 16 Oct 2015 08:53:27 +0800 Subject: RFR: 8139674: aarch64: guarantee failure in TestOptionsWithRanges.java In-Reply-To: <1444924265.30110.11.camel@mylittlepony.linaroharston> References: <1444924265.30110.11.camel@mylittlepony.linaroharston> Message-ID: <56204A87.7050105@oracle.com> I don't think removing next line is right: - add(mdp, mdp, to_add); it shifts to next metadata cell. Also both exit paths execute the same instruction: + add(rscratch1, mdp, off_to_args); may be you can simplify exit without them: bind(done); + add(mdp, mdp, off_to_args); Thanks, Vladimir On 10/15/15 11:51 PM, Edward Nevill wrote: > Hi, > > Please review the following webrev > > http://cr.openjdk.java.net/~enevill/8139674/webrev/ > > JIRA issue: https://bugs.openjdk.java.net/browse/JDK-8139674 > > > The hotspot jtreg test runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails with a guarantee failure. > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (assembler_aarch64.hpp:256), pid=22842, tid=22845 > # guarantee(chk == -1 || chk == 0) failed: Field too big for insn > > What is happening is that the code in InterpreterMacroAssembler::profile_arguments_type adjusts mdp to point past the arguments and uses negative offsets to index fields at the start of the method data structure. > > However, negative ldr offsets are very limited on aarch64 (-256 bytes) so this easily overflows when TypeProfileArgsLimit is large (>=16). > > The solution is to defer incrementing mdp until we are finished with all the args and use positive offsets instead. > > Tested with hotspot jtreg > > Before: Test results: passed: 896; failed: 6; error: 10 > After: Test results: passed: 896; failed: 5; error: 10 > > Thanks for your help, > Ed. > > From jan.civlin at intel.com Fri Oct 16 01:12:26 2015 From: jan.civlin at intel.com (Civlin, Jan) Date: Fri, 16 Oct 2015 01:12:26 +0000 Subject: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. In-Reply-To: <39F83597C33E5F408096702907E6C450058797EF@ORSMSX104.amr.corp.intel.com> References: <39F83597C33E5F408096702907E6C45005879107@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C450058791D0@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C45005879240@ORSMSX104.amr.corp.intel.com> <561E2097.8060907@oracle.com> <39F83597C33E5F408096702907E6C450058797EF@ORSMSX104.amr.corp.intel.com> Message-ID: <39F83597C33E5F408096702907E6C45005879A67@ORSMSX104.amr.corp.intel.com> Vladimir, Michael Berg is about to add this new function for filtering based on vlen, so I use it now for my case and Michael will add more cases soon. const bool Matcher::match_rule_supported_vlen(int opcode, int vlen) The updated webrev is here: http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.02/ Thank you, Jan. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Wednesday, October 14, 2015 2:30 AM To: Civlin, Jan Cc: hotspot compiler Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. I said before that condition in .ad file in Matcher::match_rule_supported(): case Op_CMoveVD: if (UseAVX > 2) <<<<< (UseAVX < 1 || UseAVX > 2) ret_value = false; should match predicates: predicate(UseAVX > 0 && UseAVX < 3 && n->as_Vector()->length() == 4); Also why only length 4? There is no length 2? I don't see any code in superword.cpp which limits size of CMoveVD vector. Otherwise it seems fine. Thanks, Vladimir On 10/14/15 1:57 AM, Civlin, Jan wrote: > Vladimir, > > the updated webrev is at > > http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.01/ > > Thank you, Igor. > > Best, > > Jan. > > -----Original Message----- > From: Igor Veresov [mailto:igor.veresov at oracle.com] > Sent: Tuesday, October 13, 2015 10:51 AM > To: Civlin, Jan > Cc: Vladimir Kozlov > Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. > > Done. > >> On Oct 13, 2015, at 9:51 AM, Civlin, Jan wrote: >> >> Igor, >> >> I got a response from the moderator that the previous message (attached below) has been rejected due to the size limits. >> Please upload the attached webrev (I guess it will be >> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.01/) >> >> And I'll send the link to the group. >> >> Thank you, >> >> Jan. >> >> -----Original Message----- >> From: Civlin, Jan >> Sent: Monday, October 12, 2015 10:19 PM >> To: Vladimir Kozlov >> Cc: Igor Veresov; hotspot compiler; Civlin, Jan >> Subject: RE: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >> >> Vladimir, >> >> Here is a webrev built from a single changeset. >> Please use it for further reviewing. >> >> Thank you, >> >> Jan. >> >> -----Original Message----- >> From: Civlin, Jan >> Sent: Saturday, October 10, 2015 12:14 PM >> To: Vladimir Kozlov >> Cc: hotspot compiler >> Subject: RE: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >> >> Vladimir, >> >> Thank you for the quick review. >> >> >> I thought you are patching your repo using hotspot.patch which is clean of empty files or .hgtag and you use webrev only for facilitation of visual code review. >> If you use hotspot.patch it does not propagate to your repo empty or already integrated in 8136725 files or my repo tags, since none of them are in the patch. >> I thought you are simply skipping unchanged files if you see them in webrev html pages. >> >> My repo is a consistent and long living clone of your repo. It is a single place that includes the history of all my changes, which let me go ahead in development way far of what is ready for going out to you. I can create an additional repo and filter out my tags on way out, but it will create more possibilities for accidental errors. >> >> >> x86.ad: it is indeed not (yet) AVX3, since AVX3 will have different ISA. Once we have AVX3 in the house and can debug it, AVX3 case will be added. >> >> c2_globals.hpp: >> I will rename the flag to UseCMoveUnconditionally, but I see no point of having another flag for the vector: once SuperWord detects CMovD, it merely vectorize it. >> In the opposite direction: one cannot ask for vectorization of CMovD and not to get them in the scalar case. >> >> compile.cpp: >> 1114: will add "do_vector_loop() &&" and change to NOT_PRODUCT(if >> (do_vector_loop() && Verbose&& && has_method()) >> {tty->print("Compile::Init: use CMove without profitability tests for >> method %s\n", method()->name()->as_quoted_ascii());}) >> >> loopopts.cpp: >> 601: will add "&& cmp_op == Op_CmpD" and change to if >> (C->use_cmove() && cmp_op == Op_CmpD) ;//keep going >> >> >> Thank you, >> >> Jan >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Saturday, October 10, 2015 5:52 AM >> To: Civlin, Jan >> Cc: hotspot compiler >> Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >> >> Changes contains also 8136725 (loop reserve copy) changes. Please, clean up. >> >> x86.ad WAIT! According to next conditions (BTW, support condition should match predicate) this is only supported with AVX1 and AVX2 and not AVX3. Really? >> >> I think it should be reversed condition (< 3): >> + case Op_CMoveVD: >> + if (UseAVX > 2) >> + ret_value = false; >> >> + instruct vcmov4D_reg(vecY dst, vecY src1, vecY src2, immI8 cop, >> cmpOp_vcmppd copnd) %{ >> + predicate(UseAVX > 0 && UseAVX < 3 && n->as_Vector()->length() == >> + 4); >> >> >> x86_64.ad changes are empty (could be only spacing change) so remove it from change. >> >> c2_globals.hpp DoReserveCopyInSuperWord is defined in 8136725 changes. >> UseCMov should be UseCMoveUnconditionally I think (note 'move' >> instead of 'mov'). Also I am not sure that you should mix 2 things >> into this >> changes: one is vectorizing cmoveD (for doubles) and always generate cmoves. I think it is different issues and this change should concentrate on vectorizing only double cmoves. Then flag could be VectorizeCMoveD. >> >> compile.cpp print not under UseCmov flag: >> + NOT_PRODUCT(if (Verbose && has_method()) {tty->print("Compile::Init: >> use CMove without profitability tests for method %s\n", >> method()->name()->as_quoted_ascii());}) >> >> loopopts.cpp changes inconsistent. In one place you check use_cmove only for doubles and in other for all. >> >> I will look on superword changes after you cleanup changes: remove >> 8136725 and also create history from fresh repo - I don't want to see 50 revisions descriptions in webrev. >> >> Thanks, >> Vladimir >> >> On 10/10/15 7:04 AM, Civlin, Jan wrote: >>> Please review this patch. >>> >>> Hi All, >>> >>> >>> We would like to contribute the SuperWord enhancement to support >>> vector conditional move (CMovVD ) on Intel AVX cpu. >>> >>> >>> The contribution Bug ID: 8139340. >>> >>> Please review this patch: >>> >>> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8139340 >>> >>> webrev: http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ >>> >>> Description: >>> >>> SuperWord enhancement to support vector conditional move (CMovVD) >>> on Intel AVX cpu. >>> >>> The SuperWord optimization bails out on counted loops that contain >>> any conditional statement other than the loop exit, and this >>> prevents vectorization of many compute bound loops. >>> >>> The proposed enhancement enables generation of CMovD on demand >>> (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD ) >>> in SuperWord optimization. >>> >>> The performance gain observed on a simplified Monte Carlo Option >>> Calculation was up to 2x speed-up. >>> >>> Thank you, >>> >>> Jan. >>> >>> *From:*Igor Veresov [mailto:igor.veresov at oracle.com] >>> *Sent:* Friday, October 9, 2015 3:22 PM >>> *To:* Civlin, Jan >>> *Cc:* hotspot compiler; Vladimir Kozlov >>> *Subject:* Re: SuperWord enhancement to support vector conditional >>> move (CMovVD ) on Intel AVX cpu. >>> >>> Here it is: https://bugs.openjdk.java.net/browse/JDK-8139340 >>> >>> igor >>> >>> On Oct 9, 2015, at 2:57 PM, Civlin, Jan >> > wrote: >>> >>> Thank you, Igor. >>> >>> What is the RFR for this? >>> >>> *From:*Igor Veresov [mailto:igor.veresov at oracle.com] >>> *Sent:*Friday, October 9, 2015 2:53 PM >>> *To:*Civlin, Jan >>> *Cc:*hotspot compiler; Vladimir Kozlov >>> *Subject:*Re: SuperWord enhancement to support vector conditional >>> move (CMovVD ) on Intel AVX cpu. >>> >>> Here the webrev: >>> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ >>> >>> igor >>> >>> On Oct 9, 2015, at 1:15 PM, Civlin, Jan >> > wrote: >>> >>> Igor, >>> >>> Please create RFR and upload this patch. You may need to rename >>> ancnav.js.remove_this_extention back to ancnav.js (I have to >>> rename it for passing the mail server filters). >>> >>> Description: >>> >>> SuperWord enhancement to support vector conditional move >>> (CMovVD) on Intel AVX cpu. >>> >>> The SuperWord optimization bails out on counted loops that >>> contain any conditional statement other than the loop exit, and >>> this prevents vectorization of many compute bound loops. >>> >>> The proposed enhancement enables generation of CMovD on demand >>> (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD >>> ) in SuperWord optimization. >>> >>> The performance gain observed on a simplified Monte Carlo Option >>> Calculation was up to 2x speed-up. >>> >>> Thank you, >>> >>> Jan. >>> >>> >>> >> > From vladimir.kozlov at oracle.com Fri Oct 16 04:48:41 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 16 Oct 2015 12:48:41 +0800 Subject: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. In-Reply-To: <39F83597C33E5F408096702907E6C45005879A67@ORSMSX104.amr.corp.intel.com> References: <39F83597C33E5F408096702907E6C45005879107@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C450058791D0@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C45005879240@ORSMSX104.amr.corp.intel.com> <561E2097.8060907@oracle.com> <39F83597C33E5F408096702907E6C450058797EF@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C45005879A67@ORSMSX104.amr.corp.intel.com> Message-ID: <562081A9.9070008@oracle.com> On 10/16/15 9:12 AM, Civlin, Jan wrote: > Vladimir, > > Michael Berg is about to add this new function for filtering based on vlen, so I use it now for my case and Michael will add more cases soon. > > const bool Matcher::match_rule_supported_vlen(int opcode, int vlen) For your changes I would simple add next to the check in VectorNode::implemented(): && (vopc != Op_CMoveD || vlen == 4); For changes which Michael is working on, you have to add it to all platforms .ad (same as match_rule_supported()). I would suggest to have match_rule_supported_vector(int opcode, int vlen) which you will call from VectorNode::implemented() instead of match_rule_supported(). And move all current vector opcodes check in match_rule_supported() to new one. Thanks, Vladimir > > > The updated webrev is here: > > http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.02/ > > > Thank you, > > Jan. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, October 14, 2015 2:30 AM > To: Civlin, Jan > Cc: hotspot compiler > Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. > > I said before that condition in .ad file in Matcher::match_rule_supported(): > > case Op_CMoveVD: > if (UseAVX > 2) <<<<< (UseAVX < 1 || UseAVX > 2) > ret_value = false; > > should match predicates: > > predicate(UseAVX > 0 && UseAVX < 3 && n->as_Vector()->length() == 4); > > Also why only length 4? There is no length 2? I don't see any code in superword.cpp which limits size of CMoveVD vector. > > Otherwise it seems fine. > > Thanks, > Vladimir > > On 10/14/15 1:57 AM, Civlin, Jan wrote: >> Vladimir, >> >> the updated webrev is at >> >> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.01/ >> >> Thank you, Igor. >> >> Best, >> >> Jan. >> >> -----Original Message----- >> From: Igor Veresov [mailto:igor.veresov at oracle.com] >> Sent: Tuesday, October 13, 2015 10:51 AM >> To: Civlin, Jan >> Cc: Vladimir Kozlov >> Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >> >> Done. >> >>> On Oct 13, 2015, at 9:51 AM, Civlin, Jan wrote: >>> >>> Igor, >>> >>> I got a response from the moderator that the previous message (attached below) has been rejected due to the size limits. >>> Please upload the attached webrev (I guess it will be >>> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.01/) >>> >>> And I'll send the link to the group. >>> >>> Thank you, >>> >>> Jan. >>> >>> -----Original Message----- >>> From: Civlin, Jan >>> Sent: Monday, October 12, 2015 10:19 PM >>> To: Vladimir Kozlov >>> Cc: Igor Veresov; hotspot compiler; Civlin, Jan >>> Subject: RE: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >>> >>> Vladimir, >>> >>> Here is a webrev built from a single changeset. >>> Please use it for further reviewing. >>> >>> Thank you, >>> >>> Jan. >>> >>> -----Original Message----- >>> From: Civlin, Jan >>> Sent: Saturday, October 10, 2015 12:14 PM >>> To: Vladimir Kozlov >>> Cc: hotspot compiler >>> Subject: RE: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >>> >>> Vladimir, >>> >>> Thank you for the quick review. >>> >>> >>> I thought you are patching your repo using hotspot.patch which is clean of empty files or .hgtag and you use webrev only for facilitation of visual code review. >>> If you use hotspot.patch it does not propagate to your repo empty or already integrated in 8136725 files or my repo tags, since none of them are in the patch. >>> I thought you are simply skipping unchanged files if you see them in webrev html pages. >>> >>> My repo is a consistent and long living clone of your repo. It is a single place that includes the history of all my changes, which let me go ahead in development way far of what is ready for going out to you. I can create an additional repo and filter out my tags on way out, but it will create more possibilities for accidental errors. >>> >>> >>> x86.ad: it is indeed not (yet) AVX3, since AVX3 will have different ISA. Once we have AVX3 in the house and can debug it, AVX3 case will be added. >>> >>> c2_globals.hpp: >>> I will rename the flag to UseCMoveUnconditionally, but I see no point of having another flag for the vector: once SuperWord detects CMovD, it merely vectorize it. >>> In the opposite direction: one cannot ask for vectorization of CMovD and not to get them in the scalar case. >>> >>> compile.cpp: >>> 1114: will add "do_vector_loop() &&" and change to NOT_PRODUCT(if >>> (do_vector_loop() && Verbose&& && has_method()) >>> {tty->print("Compile::Init: use CMove without profitability tests for >>> method %s\n", method()->name()->as_quoted_ascii());}) >>> >>> loopopts.cpp: >>> 601: will add "&& cmp_op == Op_CmpD" and change to if >>> (C->use_cmove() && cmp_op == Op_CmpD) ;//keep going >>> >>> >>> Thank you, >>> >>> Jan >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Saturday, October 10, 2015 5:52 AM >>> To: Civlin, Jan >>> Cc: hotspot compiler >>> Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >>> >>> Changes contains also 8136725 (loop reserve copy) changes. Please, clean up. >>> >>> x86.ad WAIT! According to next conditions (BTW, support condition should match predicate) this is only supported with AVX1 and AVX2 and not AVX3. Really? >>> >>> I think it should be reversed condition (< 3): >>> + case Op_CMoveVD: >>> + if (UseAVX > 2) >>> + ret_value = false; >>> >>> + instruct vcmov4D_reg(vecY dst, vecY src1, vecY src2, immI8 cop, >>> cmpOp_vcmppd copnd) %{ >>> + predicate(UseAVX > 0 && UseAVX < 3 && n->as_Vector()->length() == >>> + 4); >>> >>> >>> x86_64.ad changes are empty (could be only spacing change) so remove it from change. >>> >>> c2_globals.hpp DoReserveCopyInSuperWord is defined in 8136725 changes. >>> UseCMov should be UseCMoveUnconditionally I think (note 'move' >>> instead of 'mov'). Also I am not sure that you should mix 2 things >>> into this >>> changes: one is vectorizing cmoveD (for doubles) and always generate cmoves. I think it is different issues and this change should concentrate on vectorizing only double cmoves. Then flag could be VectorizeCMoveD. >>> >>> compile.cpp print not under UseCmov flag: >>> + NOT_PRODUCT(if (Verbose && has_method()) {tty->print("Compile::Init: >>> use CMove without profitability tests for method %s\n", >>> method()->name()->as_quoted_ascii());}) >>> >>> loopopts.cpp changes inconsistent. In one place you check use_cmove only for doubles and in other for all. >>> >>> I will look on superword changes after you cleanup changes: remove >>> 8136725 and also create history from fresh repo - I don't want to see 50 revisions descriptions in webrev. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/10/15 7:04 AM, Civlin, Jan wrote: >>>> Please review this patch. >>>> >>>> Hi All, >>>> >>>> >>>> We would like to contribute the SuperWord enhancement to support >>>> vector conditional move (CMovVD ) on Intel AVX cpu. >>>> >>>> >>>> The contribution Bug ID: 8139340. >>>> >>>> Please review this patch: >>>> >>>> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8139340 >>>> >>>> webrev: http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ >>>> >>>> Description: >>>> >>>> SuperWord enhancement to support vector conditional move (CMovVD) >>>> on Intel AVX cpu. >>>> >>>> The SuperWord optimization bails out on counted loops that contain >>>> any conditional statement other than the loop exit, and this >>>> prevents vectorization of many compute bound loops. >>>> >>>> The proposed enhancement enables generation of CMovD on demand >>>> (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD ) >>>> in SuperWord optimization. >>>> >>>> The performance gain observed on a simplified Monte Carlo Option >>>> Calculation was up to 2x speed-up. >>>> >>>> Thank you, >>>> >>>> Jan. >>>> >>>> *From:*Igor Veresov [mailto:igor.veresov at oracle.com] >>>> *Sent:* Friday, October 9, 2015 3:22 PM >>>> *To:* Civlin, Jan >>>> *Cc:* hotspot compiler; Vladimir Kozlov >>>> *Subject:* Re: SuperWord enhancement to support vector conditional >>>> move (CMovVD ) on Intel AVX cpu. >>>> >>>> Here it is: https://bugs.openjdk.java.net/browse/JDK-8139340 >>>> >>>> igor >>>> >>>> On Oct 9, 2015, at 2:57 PM, Civlin, Jan >>> > wrote: >>>> >>>> Thank you, Igor. >>>> >>>> What is the RFR for this? >>>> >>>> *From:*Igor Veresov [mailto:igor.veresov at oracle.com] >>>> *Sent:*Friday, October 9, 2015 2:53 PM >>>> *To:*Civlin, Jan >>>> *Cc:*hotspot compiler; Vladimir Kozlov >>>> *Subject:*Re: SuperWord enhancement to support vector conditional >>>> move (CMovVD ) on Intel AVX cpu. >>>> >>>> Here the webrev: >>>> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ >>>> >>>> igor >>>> >>>> On Oct 9, 2015, at 1:15 PM, Civlin, Jan >>> > wrote: >>>> >>>> Igor, >>>> >>>> Please create RFR and upload this patch. You may need to rename >>>> ancnav.js.remove_this_extention back to ancnav.js (I have to >>>> rename it for passing the mail server filters). >>>> >>>> Description: >>>> >>>> SuperWord enhancement to support vector conditional move >>>> (CMovVD) on Intel AVX cpu. >>>> >>>> The SuperWord optimization bails out on counted loops that >>>> contain any conditional statement other than the loop exit, and >>>> this prevents vectorization of many compute bound loops. >>>> >>>> The proposed enhancement enables generation of CMovD on demand >>>> (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD >>>> ) in SuperWord optimization. >>>> >>>> The performance gain observed on a simplified Monte Carlo Option >>>> Calculation was up to 2x speed-up. >>>> >>>> Thank you, >>>> >>>> Jan. >>>> >>>> >>>> >>> >> From zoltan.majo at oracle.com Fri Oct 16 08:21:50 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 16 Oct 2015 10:21:50 +0200 Subject: [9] RFR(XS): 8137173: @HotSpotIntrinsicCandidate is not Oracle-specific In-Reply-To: <20151015141249.801300@eggemoggin.niobe.net> References: <560D51BD.6030108@oracle.com> <560D540E.4090609@oracle.com> <20151001085441.434440@eggemoggin.niobe.net> <560E1CDF.7070307@oracle.com> <20151015141249.801300@eggemoggin.niobe.net> Message-ID: <5620B39E.8070501@oracle.com> Hi Mark, On 10/15/2015 11:12 PM, mark.reinhold at oracle.com wrote: > 2015/10/1 10:57 -0700, zoltan.majo at oracle.com: >> On 10/01/2015 05:54 PM, mark.reinhold at oracle.com wrote: >>> I suggest putting this into jdk.internal.vm.annotation, which is >>> also a good place for the ReservedStackAccess annotation envisioned >>> in JEP 270 (http://openjdk.java.net/jeps/270). >> I filed an RFE, JDK-8138732: "move @HotSpotIntrinsicCandidate to the >> jdk.internal.vm.annotation package" [1], to track the issue of moving >> the annotation to a different package. I hope I can take care of it soon. >> >> Thank you and best regards, > Thanks. While you're at it, could you please rename the annotation to > @IntrinsicCandidate? There's no need for the "HotSpot" prefix any more > since this annotation will now be in a package that is reserved for > VM-specific annotations. > > (Sorry for this late suggestion; this just came up in a discussion of > the @ReservedStackAccess annotation for JEP 270, which is also destined > for the jdk.internal.vm.annotation package.) > > (I've pasted this addendum into JDK-8138732.) thank you for updating the bug description! Best regards, Zoltan > > - Mark From roland.westrelin at oracle.com Fri Oct 16 08:40:33 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 16 Oct 2015 10:40:33 +0200 Subject: RFR(L): JEP165: Compiler Control In-Reply-To: <561FAFE8.5000901@oracle.com> References: <56018E2B.2000108@oracle.com> <561FAFE8.5000901@oracle.com> Message-ID: <043DBD82-22EF-4F3C-AB6C-B83AC8A74068@oracle.com> > http://cr.openjdk.java.net/~neliasso/8046155/webrev_jdk.03/ > http://cr.openjdk.java.net/~neliasso/8046155/webrev.11/ That looks good to me. Roland. From roland.westrelin at oracle.com Fri Oct 16 09:02:01 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 16 Oct 2015 11:02:01 +0200 Subject: RFR: 8139674: aarch64: guarantee failure in TestOptionsWithRanges.java In-Reply-To: <56204A87.7050105@oracle.com> References: <1444924265.30110.11.camel@mylittlepony.linaroharston> <56204A87.7050105@oracle.com> Message-ID: > I don't think removing next line is right: > > - add(mdp, mdp, to_add); > > it shifts to next metadata cell. Yes, we shift to the next argument slot. We also do: off_to_args += to_add; and then data in the slot is addressed with: in_bytes(TypeEntriesAtCall::stack_slot_offset(i))-off_to_args that is relative to the current argument slot. before the change. After the change, it?s adjusted to: in_bytes(TypeEntriesAtCall::stack_slot_offset(i)) that is relative to the beginning of the space allocated for all arguments. So I think it?s good. This said, this: >> What is happening is that the code in InterpreterMacroAssembler::profile_arguments_type adjusts mdp to point past the arguments and uses negative offsets to index fields at the start of the method data structure. is not correct I think. We don?t move past the arguments. We move to the beginning of the slot dedicated to the next argument, not past it. The only source of negative offsets I can see is: 1555 ldr(tmp, Address(mdp, in_bytes(TypeEntriesAtCall::cell_count_offset())-off_to_args)); Roland. From edward.nevill at gmail.com Fri Oct 16 09:12:41 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Fri, 16 Oct 2015 10:12:41 +0100 Subject: RFR: 8139674: aarch64: guarantee failure in TestOptionsWithRanges.java In-Reply-To: <56204A87.7050105@oracle.com> References: <1444924265.30110.11.camel@mylittlepony.linaroharston> <56204A87.7050105@oracle.com> Message-ID: <1444986761.22434.29.camel@mint> Hi Vladimir, Thanks for the review. On Fri, 2015-10-16 at 08:53 +0800, Vladimir Kozlov wrote: > I don't think removing next line is right: > > - add(mdp, mdp, to_add); > > it shifts to next metadata cell. I believe removal of this line is correct. The old code kept mdp pointing at the current metadata cell that it was processing. This is what lead to the large negative offsets when it was trying to index the two fields at the start of the metadata structure. So in the old code, to process each metatdata cell it did. Address mdo_arg_addr(mdp, in_bytes(TypeEntriesAtCall::argument_type_offset(i))-off_to_args); profile_obj_type(tmp, mdo_arg_addr); In the revised code it does Address mdo_arg_addr(mdp, in_bytes(TypeEntriesAtCall::argument_type_offset(i))); profile_obj_type(tmp, mdo_arg_addr); 'off_to_args' is updated by 'to_add' each time round the loop. off_to_args += to_add; So in the old code the address of the metadata cell was calculated as mdp + in_bytes(TypeEntriesAtCall::argument_type_offset(i))-off_to_args Note: 'in_bytes(TypeEntriesAtCall::argument_type_offset(i))-off_to_args' always evaluates to 0! In the revised code the address is calculated as 'in_bytes(TypeEntriesAtCall::argument_type_offset(i))' which evaluates to the same address since mdp is no longer offset by 'off_to_args'. > > Also both exit paths execute the same instruction: > > + add(rscratch1, mdp, off_to_args); > > may be you can simplify exit without them: > > bind(done); > + add(mdp, mdp, off_to_args); I don't believe the exit can be simplified. The reason is that 'off_to_args' is different for each iteration around the loop. So in assembler what we will have is add x8, x0, #8 // x0 == mdp, offset to arg 0 == 8 blt done ... add x8, x0, #0x18 // arg 1 offset = 0x18 blt done .... add x8, x0, #0x108 // fallthru case done: mov x0, x8 So, mdp is updated by a different immediate value in each case, so we cannot merge them into a single case done: add x0, x0, #N // N == ??? Thanks for your help, Ed. From adinn at redhat.com Fri Oct 16 09:43:44 2015 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 16 Oct 2015 10:43:44 +0100 Subject: [aarch64-port-dev ] RFR: 8139674: aarch64: guarantee failure in TestOptionsWithRanges.java In-Reply-To: References: <1444924265.30110.11.camel@mylittlepony.linaroharston> <56204A87.7050105@oracle.com> Message-ID: <5620C6D0.3050704@redhat.com> On 16/10/15 10:02, Roland Westrelin wrote: >> I don't think removing next line is right: >> >> - add(mdp, mdp, to_add); >> >> it shifts to next metadata cell. > > Yes, we shift to the next argument slot. We also do: > > off_to_args += to_add; > > and then data in the slot is addressed with: > > in_bytes(TypeEntriesAtCall::stack_slot_offset(i))-off_to_args > > that is relative to the current argument slot. > > before the change. After the change, it?s adjusted to: > > in_bytes(TypeEntriesAtCall::stack_slot_offset(i)) > > that is relative to the beginning of the space allocated for all arguments. So I think it?s good. I agree with Roland that this change set is good. As he points out, in the new code off_to_args is being updated every time round the loop 1575 off_to_args += to_add; So, the add instructions generated at 1557 add(rscratch1, mdp, off_to_args); and 1583 add(rscratch1, mdp, off_to_args); will be inserting different positive constants into the generated instruction stream depending on the current value of off_to_args. > This said, this: > >>> What is happening is that the code in InterpreterMacroAssembler::profile_arguments_type adjusts mdp to point past the arguments and uses negative offsets to index fields at the start of the method data structure. > > is not correct I think. We don?t move past the arguments. We move to the beginning of the slot dedicated to the next argument, not past it. The only source of negative offsets I can see is: > > 1555 ldr(tmp, Address(mdp, in_bytes(TypeEntriesAtCall::cell_count_offset())-off_to_args)); What Ed said made sense to me. The old code executed 1550 add(mdp, mdp, off_to_args); before the loop i.e. it left mdp pointing just past the args. Subsequent ldr instructions then used a negative offset from this updated mdp register to address the arg slots which precede the slot addressed by mdp. Anyway, whatever the status regarding validity/clarity of the explanation Ed provided in the accompanying mail note the actual code changes look correct to me. 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 vladimir.kozlov at oracle.com Fri Oct 16 10:13:41 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 16 Oct 2015 18:13:41 +0800 Subject: RFR: 8139674: aarch64: guarantee failure in TestOptionsWithRanges.java In-Reply-To: <1444986761.22434.29.camel@mint> References: <1444924265.30110.11.camel@mylittlepony.linaroharston> <56204A87.7050105@oracle.com> <1444986761.22434.29.camel@mint> Message-ID: <5620CDD5.6090301@oracle.com> On 10/16/15 5:12 PM, Edward Nevill wrote: > Hi Vladimir, > > Thanks for the review. > > On Fri, 2015-10-16 at 08:53 +0800, Vladimir Kozlov wrote: >> I don't think removing next line is right: >> >> - add(mdp, mdp, to_add); >> >> it shifts to next metadata cell. > > I believe removal of this line is correct. The old code kept mdp pointing at the current metadata cell that it was processing. This is what lead to the large negative offsets when it was trying to index the two fields at the start of the metadata structure. > > So in the old code, to process each metatdata cell it did. > > Address mdo_arg_addr(mdp, in_bytes(TypeEntriesAtCall::argument_type_offset(i))-off_to_args); > profile_obj_type(tmp, mdo_arg_addr); > > In the revised code it does > > Address mdo_arg_addr(mdp, in_bytes(TypeEntriesAtCall::argument_type_offset(i))); > profile_obj_type(tmp, mdo_arg_addr); > > 'off_to_args' is updated by 'to_add' each time round the loop. > > off_to_args += to_add; > > So in the old code the address of the metadata cell was calculated as > > mdp + in_bytes(TypeEntriesAtCall::argument_type_offset(i))-off_to_args > > Note: 'in_bytes(TypeEntriesAtCall::argument_type_offset(i))-off_to_args' always evaluates to 0! > > In the revised code the address is calculated as 'in_bytes(TypeEntriesAtCall::argument_type_offset(i))' which evaluates to the same address since mdp is no longer offset by 'off_to_args'. Make sense. Thank you for explanation. > >> >> Also both exit paths execute the same instruction: >> >> + add(rscratch1, mdp, off_to_args); >> >> may be you can simplify exit without them: >> >> bind(done); >> + add(mdp, mdp, off_to_args); > > I don't believe the exit can be simplified. > > The reason is that 'off_to_args' is different for each iteration around the loop. So in assembler what we will have is > > add x8, x0, #8 // x0 == mdp, offset to arg 0 == 8 > blt done > ... > add x8, x0, #0x18 // arg 1 offset = 0x18 > blt done > .... > > add x8, x0, #0x108 // fallthru case > done: > mov x0, x8 > > So, mdp is updated by a different immediate value in each case, so we cannot merge them into a single case Okay, I missed that off_to_args is changing. Looks good. Thanks, Vladimir > > done: > add x0, x0, #N // N == ??? > > Thanks for your help, > Ed. > > From zoltan.majo at oracle.com Fri Oct 16 11:10:33 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 16 Oct 2015 13:10:33 +0200 Subject: [9] RFR(S): 8139380: VMError::report_and_die() does not produce replay file Message-ID: <5620DB29.3000603@oracle.com> Hi, please review the patch for 8139380. Bug: https://bugs.openjdk.java.net/browse/JDK-8139380 Problem: The test compiler/ciReplay/TestVM.sh intentionally crashes the VM and expects compiler replay data to be saved into a file ('test_replay.txt'). Since the JVMCI changes were pushed, the test fails on some platforms we support because the file is not created by the VM. The file should be created by VMError::report_and_die(). However, a SIGSEGV is thrown in VMError::report() (report() is called by report_and_die()) that causes the VM to exit without saving replay data. Solution: Update VMError::report() to use an appropriate format string to print the VM version in both JVMCI-enabled builds and builds without JVMCI. Webrev: http://cr.openjdk.java.net/~zmajo/8139380/webrev.00/ Testing: - JPRT (testset hotspot); - executed failing test on all supported platforms, the failure is not triggered. Thank you and best regards, Zoltan From roland.westrelin at oracle.com Fri Oct 16 11:48:23 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 16 Oct 2015 13:48:23 +0200 Subject: [9] RFR(S): 8139380: VMError::report_and_die() does not produce replay file In-Reply-To: <5620DB29.3000603@oracle.com> References: <5620DB29.3000603@oracle.com> Message-ID: > http://cr.openjdk.java.net/~zmajo/8139380/webrev.00/ That looks good to me. Roland. From kirk.pepperdine at gmail.com Fri Oct 16 12:14:03 2015 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Fri, 16 Oct 2015 14:14:03 +0200 Subject: [9] RFR(XS): 8137173: @HotSpotIntrinsicCandidate is not Oracle-specific In-Reply-To: <20151015141249.801300@eggemoggin.niobe.net> References: <560D51BD.6030108@oracle.com> <560D540E.4090609@oracle.com> <20151001085441.434440@eggemoggin.niobe.net> <560E1CDF.7070307@oracle.com> <20151015141249.801300@eggemoggin.niobe.net> Message-ID: Hi Oliwia, I?ve updated the abstract. I hope you find this one better suited to the event. Kind regards, Kirk Pepperdine Java Performance Tuning Workshop > In this workshop you will be introduced to jPDM (Java Performance Diagnostic Model), a methodology that brings structure to the often adhoc activity of performance tuning. Following jPDM will help you quickly and definitivily identify root causes of performance bottlenecks. In addition, we will deep dive into different aspects of the Java stack and look at some of the tools you can use to reveal the inner workings. The talk will be augmented with a number of exercises so do bring a laptop. If you don?t have one to bring don?t fret, we encourage people to problem solve in groups. If you have one, we would encourage you share. > > Topics covered: > 1. Performance Benchmarking > > ? benchmarking basics > ? types and purpose of benchmarks > ? load, stress, spike, endurance > ? finding and resolving blocking conditions > > 2. Improving observability > ? taking measures > ? logging > ? Java Management eXtensions > > 3. jPDM, a performance diagnostic model > ? using key metrics to categorize a performance bottleneck > ? OS, JVM, Application, liveliness > > 4. Garbage Collection > ? Java memory management (in a nutshell) > ? GC logging > ? GC tuning tactics > > 5. Profiling > ? Execution profiling > ? Memory profiling > ? Memory leaks > On Oct 15, 2015, at 11:12 PM, mark.reinhold at oracle.com wrote: > > 2015/10/1 10:57 -0700, zoltan.majo at oracle.com: >> On 10/01/2015 05:54 PM, mark.reinhold at oracle.com wrote: >>> I suggest putting this into jdk.internal.vm.annotation, which is >>> also a good place for the ReservedStackAccess annotation envisioned >>> in JEP 270 (http://openjdk.java.net/jeps/270). >> >> I filed an RFE, JDK-8138732: "move @HotSpotIntrinsicCandidate to the >> jdk.internal.vm.annotation package" [1], to track the issue of moving >> the annotation to a different package. I hope I can take care of it soon. >> >> Thank you and best regards, > > Thanks. While you're at it, could you please rename the annotation to > @IntrinsicCandidate? There's no need for the "HotSpot" prefix any more > since this annotation will now be in a package that is reserved for > VM-specific annotations. > > (Sorry for this late suggestion; this just came up in a discussion of > the @ReservedStackAccess annotation for JEP 270, which is also destined > for the jdk.internal.vm.annotation package.) > > (I've pasted this addendum into JDK-8138732.) > > - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From zoltan.majo at oracle.com Fri Oct 16 13:01:48 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 16 Oct 2015 15:01:48 +0200 Subject: [9] RFR(S): 8139380: VMError::report_and_die() does not produce replay file In-Reply-To: References: <5620DB29.3000603@oracle.com> Message-ID: <5620F53C.50500@oracle.com> Thank you, Roland, for the review! Best regards, Zoltan On 10/16/2015 01:48 PM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~zmajo/8139380/webrev.00/ > That looks good to me. > > Roland. From vladimir.kozlov at oracle.com Fri Oct 16 13:10:39 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 16 Oct 2015 21:10:39 +0800 Subject: [9] RFR(S): 8139380: VMError::report_and_die() does not produce replay file In-Reply-To: <5620DB29.3000603@oracle.com> References: <5620DB29.3000603@oracle.com> Message-ID: <5620F74F.4020408@oracle.com> Or: #if INCLUDE_JVMCI EnableJVMCI ? ", jvmci" : "", UseJVMCICompiler ? ", jvmci compiler" : "", #else "", "", #endif Vladimir On 10/16/15 7:10 PM, Zolt?n Maj? wrote: > Hi, > > > please review the patch for 8139380. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139380 > > Problem: The test compiler/ciReplay/TestVM.sh intentionally crashes the > VM and expects compiler replay data to be saved into a file > ('test_replay.txt'). Since the JVMCI changes were pushed, the test fails > on some platforms we support because the file is not created by the VM. > > The file should be created by VMError::report_and_die(). However, a > SIGSEGV is thrown in VMError::report() (report() is called by > report_and_die()) that causes the VM to exit without saving replay data. > > > Solution: Update VMError::report() to use an appropriate format string > to print the VM version in both JVMCI-enabled builds and builds without > JVMCI. > > Webrev: > http://cr.openjdk.java.net/~zmajo/8139380/webrev.00/ > > Testing: > - JPRT (testset hotspot); > - executed failing test on all supported platforms, the failure is not > triggered. > > Thank you and best regards, > > > Zoltan > From kirk.pepperdine at gmail.com Fri Oct 16 13:10:55 2015 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Fri, 16 Oct 2015 15:10:55 +0200 Subject: [9] RFR(XS): 8137173: @HotSpotIntrinsicCandidate is not Oracle-specific In-Reply-To: References: <560D51BD.6030108@oracle.com> <560D540E.4090609@oracle.com> <20151001085441.434440@eggemoggin.niobe.net> <560E1CDF.7070307@oracle.com> <20151015141249.801300@eggemoggin.niobe.net> Message-ID: <72449570-16E5-4B18-900B-7CBD4C42F08D@gmail.com> My apologies for the *spam* and for the **spam** about the *spam* Kind regards, Kirk From zoltan.majo at oracle.com Fri Oct 16 13:25:19 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 16 Oct 2015 15:25:19 +0200 Subject: [9] RFR(S): 8139380: VMError::report_and_die() does not produce replay file In-Reply-To: <5620F74F.4020408@oracle.com> References: <5620DB29.3000603@oracle.com> <5620F74F.4020408@oracle.com> Message-ID: <5620FABF.8010504@oracle.com> Hi Vladimir, On 10/16/2015 03:10 PM, Vladimir Kozlov wrote: > #if INCLUDE_JVMCI > EnableJVMCI ? ", jvmci" : "", > UseJVMCICompiler ? ", jvmci compiler" : "", > #else > "", "", > #endif thank you for the review. I've updated the code according to your suggestion. For the record, here is what I intend to push: http://cr.openjdk.java.net/~zmajo/8139380/webrev.01/ Thank you and best regards, Zoltan On 10/16/2015 03:10 PM, Vladimir Kozlov wrote: > #if INCLUDE_JVMCI > EnableJVMCI ? ", jvmci" : "", > UseJVMCICompiler ? ", jvmci compiler" : "", > #else > "", "", > #endif From vladimir.kozlov at oracle.com Fri Oct 16 13:27:15 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 16 Oct 2015 21:27:15 +0800 Subject: [9] RFR(S): 8139380: VMError::report_and_die() does not produce replay file In-Reply-To: <5620FABF.8010504@oracle.com> References: <5620DB29.3000603@oracle.com> <5620F74F.4020408@oracle.com> <5620FABF.8010504@oracle.com> Message-ID: <5620FB33.2050403@oracle.com> Okay. Thanks, Vladimir On 10/16/15 9:25 PM, Zolt?n Maj? wrote: > Hi Vladimir, > > > On 10/16/2015 03:10 PM, Vladimir Kozlov wrote: >> #if INCLUDE_JVMCI >> EnableJVMCI ? ", jvmci" : "", >> UseJVMCICompiler ? ", jvmci compiler" : "", >> #else >> "", "", >> #endif > > thank you for the review. > > I've updated the code according to your suggestion. For the record, here > is what I intend to push: > > http://cr.openjdk.java.net/~zmajo/8139380/webrev.01/ > > Thank you and best regards, > > > Zoltan > > > On 10/16/2015 03:10 PM, Vladimir Kozlov wrote: >> #if INCLUDE_JVMCI >> EnableJVMCI ? ", jvmci" : "", >> UseJVMCICompiler ? ", jvmci compiler" : "", >> #else >> "", "", >> #endif > From roland.westrelin at oracle.com Fri Oct 16 13:33:22 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 16 Oct 2015 15:33:22 +0200 Subject: [9] RFR(S): 8139380: VMError::report_and_die() does not produce replay file In-Reply-To: <5620FABF.8010504@oracle.com> References: <5620DB29.3000603@oracle.com> <5620F74F.4020408@oracle.com> <5620FABF.8010504@oracle.com> Message-ID: <0F987576-B072-40CA-87D0-C3803B8DAE99@oracle.com> > http://cr.openjdk.java.net/~zmajo/8139380/webrev.01/ Still good. Roland. From zoltan.majo at oracle.com Fri Oct 16 13:35:09 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 16 Oct 2015 15:35:09 +0200 Subject: [9] RFR(S): 8139380: VMError::report_and_die() does not produce replay file In-Reply-To: <0F987576-B072-40CA-87D0-C3803B8DAE99@oracle.com> References: <5620DB29.3000603@oracle.com> <5620F74F.4020408@oracle.com> <5620FABF.8010504@oracle.com> <0F987576-B072-40CA-87D0-C3803B8DAE99@oracle.com> Message-ID: <5620FD0D.9090202@oracle.com> Thank you, Roland! Best regards, Zoltan On 10/16/2015 03:33 PM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~zmajo/8139380/webrev.01/ > Still good. > > Roland. From roland.westrelin at oracle.com Fri Oct 16 13:56:55 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 16 Oct 2015 15:56:55 +0200 Subject: RFR(XS): 8139750: [BACKOUT] Elide more final field's write memory barrier with escape analysis result Message-ID: 8138956 caused a lot of failures during nightly testing. This is a RFR for a back out of that change: http://cr.openjdk.java.net/~roland/8139750/webrev.00/ Roland. From roland.westrelin at oracle.com Fri Oct 16 14:00:25 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 16 Oct 2015 16:00:25 +0200 Subject: RFR: Elide more final field's write memory barrier with escape analysis result In-Reply-To: <2CCD93AB-716E-4D81-A5B1-C008BC61E0F9@oracle.com> References: <5612A2C6.5080108@redhat.com> <7C9B87B351A4BA4AA9EC95BB4181165672261165@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672261384@DEWDFEMB19C.global.corp.sap> <2CCD93AB-716E-4D81-A5B1-C008BC61E0F9@oracle.com> Message-ID: Unfortunately that change caused a lot of failures during our nightly testing and we are backing it out. https://bugs.openjdk.java.net/browse/JDK-8139750 is the bug that cover those failures. I could reproduce one of those failures by running java/util/Map/Defaults.java with options: -server -Xcomp -XX:MaxRAMFraction=8 -XX:+CreateCoredumpOnCrash -ea -esa -XX:+TieredCompilation -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -XX:+IgnoreUnrecognizedVMOptions -XX:+AggressiveOpts -XX:-UseBiasedLocking I created a redo issue in case this is resubmitted: https://bugs.openjdk.java.net/browse/JDK-8139758 Roland. From vladimir.kozlov at oracle.com Fri Oct 16 14:09:34 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 16 Oct 2015 22:09:34 +0800 Subject: RFR(XS): 8139750: [BACKOUT] Elide more final field's write memory barrier with escape analysis result In-Reply-To: References: Message-ID: <5621051E.90403@oracle.com> Okay. Vladimir On 10/16/15 9:56 PM, Roland Westrelin wrote: > 8138956 caused a lot of failures during nightly testing. This is a RFR for a back out of that change: > > http://cr.openjdk.java.net/~roland/8139750/webrev.00/ > > Roland. > From roland.westrelin at oracle.com Fri Oct 16 14:10:27 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 16 Oct 2015 16:10:27 +0200 Subject: RFR(XS): 8139750: [BACKOUT] Elide more final field's write memory barrier with escape analysis result In-Reply-To: <5621051E.90403@oracle.com> References: <5621051E.90403@oracle.com> Message-ID: Thanks for the review, Vladimir. Roland. > On Oct 16, 2015, at 4:09 PM, Vladimir Kozlov wrote: > > Okay. > > Vladimir > > On 10/16/15 9:56 PM, Roland Westrelin wrote: >> 8138956 caused a lot of failures during nightly testing. This is a RFR for a back out of that change: >> >> http://cr.openjdk.java.net/~roland/8139750/webrev.00/ >> >> Roland. >> From hui.shi at linaro.org Fri Oct 16 14:51:04 2015 From: hui.shi at linaro.org (Hui Shi) Date: Fri, 16 Oct 2015 22:51:04 +0800 Subject: RFR: Elide more final field's write memory barrier with escape analysis result In-Reply-To: References: <5612A2C6.5080108@redhat.com> <7C9B87B351A4BA4AA9EC95BB4181165672261165@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672261384@DEWDFEMB19C.global.corp.sap> <2CCD93AB-716E-4D81-A5B1-C008BC61E0F9@oracle.com> Message-ID: Thanks for help back out! This looks assertion in PhaseIdealLoop::compute_lca_of_uses when verify dominance, will look at this. Regards Shi Hui On 16 October 2015 at 22:00, Roland Westrelin wrote: > Unfortunately that change caused a lot of failures during our nightly > testing and we are backing it out. > > https://bugs.openjdk.java.net/browse/JDK-8139750 is the bug that cover > those failures. I could reproduce one of those failures by running > java/util/Map/Defaults.java with options: > -server -Xcomp -XX:MaxRAMFraction=8 -XX:+CreateCoredumpOnCrash -ea -esa > -XX:+TieredCompilation -XX:CompileThreshold=100 > -XX:+UnlockExperimentalVMOptions -XX:+IgnoreUnrecognizedVMOptions > -XX:+AggressiveOpts -XX:-UseBiasedLocking > > I created a redo issue in case this is resubmitted: > > https://bugs.openjdk.java.net/browse/JDK-8139758 > > Roland. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalyd at gmail.com Fri Oct 16 14:56:55 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 16 Oct 2015 10:56:55 -0400 Subject: Jitted array-length checks before entering a loop In-Reply-To: References: <780C7C66-6E88-4B38-8156-EA53525F863A@oracle.com> Message-ID: Chris (or anyone else), Any thoughts on this? Looks like an opportunity to slim down the emitted code. Thanks On Fri, Oct 9, 2015 at 4:14 PM, Vitaly Davidovich wrote: > So basically, the deopt blobs are unreachable -- not sure if that's > intentional or not. Perhaps it's intentional in that deopt'ing in this > case is a waste of time (the simple exit is just fine), but the code for it > is left behind. > > On Fri, Oct 9, 2015 at 2:51 PM, Vitaly Davidovich > wrote: > >> Chris, >> >> Below is a sample dump (array is in %rsi). You can see the 2 tests in >> question that jump to deopt blobs (I presume). If I change the code to >> always pass a zero length array (the below assembly is for non-empty array >> 100% of the time), the code generation changes to favor that case, and >> these tests are not present. >> >> 0x00007f63476c7da0: mov %eax,-0x14000(%rsp) >> 0x00007f63476c7da7: push %rbp >> 0x00007f63476c7da8: sub $0x10,%rsp ;*synchronization entry >> >> 0x00007f63476c7dac: mov 0xc(%rsi),%r10d ;*arraylength >> >> ; implicit exception: >> dispatches to 0x00007f63476c7e11 >> 0x00007f63476c7db0: test %r10d,%r10d >> 0x00007f63476c7db3: jle 0x00007f63476c7de2 ;*if_icmplt >> >> 0x00007f63476c7db5: test %r10d,%r10d >> 0x00007f63476c7db8: jbe 0x00007f63476c7dfd >> 0x00007f63476c7dba: mov %r10d,%r8d >> 0x00007f63476c7dbd: dec %r8d >> 0x00007f63476c7dc0: cmp %r10d,%r8d >> 0x00007f63476c7dc3: jae 0x00007f63476c7dfd >> 0x00007f63476c7dc5: xor %r11d,%r11d >> 0x00007f63476c7dc8: nopl 0x0(%rax,%rax,1) ;*aload_0 >> >> 0x00007f63476c7dd0: mov 0x10(%rsi,%r11,4),%r8d ;*aaload >> >> 0x00007f63476c7dd5: test %r8d,%r8d >> 0x00007f63476c7dd8: je 0x00007f63476c7dee ;*invokevirtual amethod >> >> 0x00007f63476c7dda: inc %r11d ;*iinc >> >> 0x00007f63476c7ddd: cmp %r10d,%r11d >> 0x00007f63476c7de0: jl 0x00007f63476c7dd0 ;*return >> >> 0x00007f63476c7de2: add $0x10,%rsp >> 0x00007f63476c7de6: pop %rbp >> 0x00007f63476c7de7: test %eax,0x5cd3213(%rip) # >> 0x00007f634d39b000 >> ; {poll_return} >> 0x00007f63476c7ded: retq >> 0x00007f63476c7dee: mov $0xfffffff6,%esi >> 0x00007f63476c7df3: callq 0x00007f6347684320 ; OopMap{off=88} >> ;*invokevirtual amethod >> ; {runtime_call} >> 0x00007f63476c7df8: callq 0x00007f634c17f570 ;*invokevirtual amethod >> ; {runtime_call} >> 0x00007f63476c7dfd: mov %rsi,%rbp >> 0x00007f63476c7e00: mov $0xffffff86,%esi >> 0x00007f63476c7e05: xchg %ax,%ax >> 0x00007f63476c7e07: callq 0x00007f6347684320 ; OopMap{rbp=Oop off=108} >> ;*aload_0 >> ; {runtime_call} >> 0x00007f63476c7e0c: callq 0x00007f634c17f570 ;*aload_0 >> ; {runtime_call} >> 0x00007f63476c7e11: mov $0xfffffff6,%esi >> 0x00007f63476c7e16: nop >> 0x00007f63476c7e17: callq 0x00007f6347684320 ; OopMap{off=124} >> ;*arraylength >> ; {runtime_call} >> 0x00007f63476c7e1c: callq 0x00007f634c17f570 ;*arraylength >> ; {runtime_call} >> >> >> On Fri, Oct 9, 2015 at 2:31 PM, Christian Thalinger < >> christian.thalinger at oracle.com> wrote: >> >>> >>> On Sep 28, 2015, at 3:37 AM, Nassim Halli >>> wrote: >>> >>> Hi guys, >>> >>> I have a question relative to some code generated by the C2 compiler. >>> >>> When I look at the assembly codes for this method: >>> >>> static void compiledMethod (Atype[] data) { >>> int n = data.length >>> for (int i = 0; i < n; ++i) >>> data[i].amethod(); >>> } >>> >>> I get the this assembly on Linux X86_64 before entering the loop (not >>> OSR): >>> >>> # data is in rbx >>> mov 0xc(%rbx),%r9d >>> >>> # data.length is in r9d >>> test %r9d,%r9d >>> jle END_OF_LOOP >>> >>> test %r9d,%r9d >>> jbe BB0 >>> >>> mov %r9d,%r11d >>> dec %r11d >>> cmp %r9d,%r11d >>> jae BB0 >>> >>> >>> Did you leave out any assembly? Where is BB0? >>> >>> >>> It seems to me the second and third check are useless and the >>> corresponding branches are never taken. >>> Could you please tell me more about these checks, If and why are they >>> required ? >>> >>> Thanks a lot. >>> >>> Nassim H. >>> >>> >>> *Test conditions:* >>> >>> java version "1.8.0_51" >>> Java(TM) SE Runtime Environment (build 1.8.0_51-b16) >>> Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode) >>> Default options. >>> Linux, Intel Sandy Bridge core i5-2000 >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bharadwaj.yadavalli at oracle.com Fri Oct 16 17:14:52 2015 From: bharadwaj.yadavalli at oracle.com (S. Bharadwaj Yadavalli) Date: Fri, 16 Oct 2015 13:14:52 -0400 Subject: RFR (XS): 8139675: Record C2 compilation of unexpectedly large methods as a failure instead of crashing Message-ID: <5621308C.7070608@oracle.com> I'd like to request for a review of the change at [2] to address [1]. This changes a method size assertion during compilation to record compilation failure and return gracefully. Thanks, Bharadwaj [1] https://bugs.openjdk.java.net/browse/JDK-8139675 [2] http://cr.openjdk.java.net/~bharadwaj/8139675/webrev/ From michael.c.berg at intel.com Fri Oct 16 18:36:29 2015 From: michael.c.berg at intel.com (Berg, Michael C) Date: Fri, 16 Oct 2015 18:36:29 +0000 Subject: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. In-Reply-To: <562081A9.9070008@oracle.com> References: <39F83597C33E5F408096702907E6C45005879107@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C450058791D0@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C45005879240@ORSMSX104.amr.corp.intel.com> <561E2097.8060907@oracle.com> <39F83597C33E5F408096702907E6C450058797EF@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C45005879A67@ORSMSX104.amr.corp.intel.com> <562081A9.9070008@oracle.com> Message-ID: Initially I thought about doing that very thing. I would take this in different direction though, thus avoiding two duplicate lists. That is to have match_rule_supported_vector call match_rule_supported, keeping the lists disjunct. The vector length constraints are fewer in number and divergent and we don't' want people mixing the context rules as they have different meanings. It also removes the necessity of maintaining two identical lists. Otherwise granularity of control could become harder to manage. Thanks, Michael -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Thursday, October 15, 2015 9:49 PM To: Civlin, Jan Cc: hotspot compiler; Berg, Michael C Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. On 10/16/15 9:12 AM, Civlin, Jan wrote: > Vladimir, > > Michael Berg is about to add this new function for filtering based on vlen, so I use it now for my case and Michael will add more cases soon. > > const bool Matcher::match_rule_supported_vlen(int opcode, int vlen) For your changes I would simple add next to the check in VectorNode::implemented(): && (vopc != Op_CMoveD || vlen == 4); For changes which Michael is working on, you have to add it to all platforms .ad (same as match_rule_supported()). I would suggest to have match_rule_supported_vector(int opcode, int vlen) which you will call from VectorNode::implemented() instead of match_rule_supported(). And move all current vector opcodes check in match_rule_supported() to new one. Thanks, Vladimir > > > The updated webrev is here: > > http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.02/ > > > Thank you, > > Jan. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, October 14, 2015 2:30 AM > To: Civlin, Jan > Cc: hotspot compiler > Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. > > I said before that condition in .ad file in Matcher::match_rule_supported(): > > case Op_CMoveVD: > if (UseAVX > 2) <<<<< (UseAVX < 1 || UseAVX > 2) > ret_value = false; > > should match predicates: > > predicate(UseAVX > 0 && UseAVX < 3 && n->as_Vector()->length() == 4); > > Also why only length 4? There is no length 2? I don't see any code in superword.cpp which limits size of CMoveVD vector. > > Otherwise it seems fine. > > Thanks, > Vladimir > > On 10/14/15 1:57 AM, Civlin, Jan wrote: >> Vladimir, >> >> the updated webrev is at >> >> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.01/ >> >> Thank you, Igor. >> >> Best, >> >> Jan. >> >> -----Original Message----- >> From: Igor Veresov [mailto:igor.veresov at oracle.com] >> Sent: Tuesday, October 13, 2015 10:51 AM >> To: Civlin, Jan >> Cc: Vladimir Kozlov >> Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >> >> Done. >> >>> On Oct 13, 2015, at 9:51 AM, Civlin, Jan wrote: >>> >>> Igor, >>> >>> I got a response from the moderator that the previous message (attached below) has been rejected due to the size limits. >>> Please upload the attached webrev (I guess it will be >>> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.01/) >>> >>> And I'll send the link to the group. >>> >>> Thank you, >>> >>> Jan. >>> >>> -----Original Message----- >>> From: Civlin, Jan >>> Sent: Monday, October 12, 2015 10:19 PM >>> To: Vladimir Kozlov >>> Cc: Igor Veresov; hotspot compiler; Civlin, Jan >>> Subject: RE: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >>> >>> Vladimir, >>> >>> Here is a webrev built from a single changeset. >>> Please use it for further reviewing. >>> >>> Thank you, >>> >>> Jan. >>> >>> -----Original Message----- >>> From: Civlin, Jan >>> Sent: Saturday, October 10, 2015 12:14 PM >>> To: Vladimir Kozlov >>> Cc: hotspot compiler >>> Subject: RE: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >>> >>> Vladimir, >>> >>> Thank you for the quick review. >>> >>> >>> I thought you are patching your repo using hotspot.patch which is clean of empty files or .hgtag and you use webrev only for facilitation of visual code review. >>> If you use hotspot.patch it does not propagate to your repo empty or already integrated in 8136725 files or my repo tags, since none of them are in the patch. >>> I thought you are simply skipping unchanged files if you see them in webrev html pages. >>> >>> My repo is a consistent and long living clone of your repo. It is a single place that includes the history of all my changes, which let me go ahead in development way far of what is ready for going out to you. I can create an additional repo and filter out my tags on way out, but it will create more possibilities for accidental errors. >>> >>> >>> x86.ad: it is indeed not (yet) AVX3, since AVX3 will have different ISA. Once we have AVX3 in the house and can debug it, AVX3 case will be added. >>> >>> c2_globals.hpp: >>> I will rename the flag to UseCMoveUnconditionally, but I see no point of having another flag for the vector: once SuperWord detects CMovD, it merely vectorize it. >>> In the opposite direction: one cannot ask for vectorization of CMovD and not to get them in the scalar case. >>> >>> compile.cpp: >>> 1114: will add "do_vector_loop() &&" and change to NOT_PRODUCT(if >>> (do_vector_loop() && Verbose&& && has_method()) >>> {tty->print("Compile::Init: use CMove without profitability tests >>> for method %s\n", method()->name()->as_quoted_ascii());}) >>> >>> loopopts.cpp: >>> 601: will add "&& cmp_op == Op_CmpD" and change to if >>> (C->use_cmove() && cmp_op == Op_CmpD) ;//keep going >>> >>> >>> Thank you, >>> >>> Jan >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Saturday, October 10, 2015 5:52 AM >>> To: Civlin, Jan >>> Cc: hotspot compiler >>> Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >>> >>> Changes contains also 8136725 (loop reserve copy) changes. Please, clean up. >>> >>> x86.ad WAIT! According to next conditions (BTW, support condition should match predicate) this is only supported with AVX1 and AVX2 and not AVX3. Really? >>> >>> I think it should be reversed condition (< 3): >>> + case Op_CMoveVD: >>> + if (UseAVX > 2) >>> + ret_value = false; >>> >>> + instruct vcmov4D_reg(vecY dst, vecY src1, vecY src2, immI8 cop, >>> cmpOp_vcmppd copnd) %{ >>> + predicate(UseAVX > 0 && UseAVX < 3 && n->as_Vector()->length() >>> + == 4); >>> >>> >>> x86_64.ad changes are empty (could be only spacing change) so remove it from change. >>> >>> c2_globals.hpp DoReserveCopyInSuperWord is defined in 8136725 changes. >>> UseCMov should be UseCMoveUnconditionally I think (note 'move' >>> instead of 'mov'). Also I am not sure that you should mix 2 things >>> into this >>> changes: one is vectorizing cmoveD (for doubles) and always generate cmoves. I think it is different issues and this change should concentrate on vectorizing only double cmoves. Then flag could be VectorizeCMoveD. >>> >>> compile.cpp print not under UseCmov flag: >>> + NOT_PRODUCT(if (Verbose && has_method()) {tty->print("Compile::Init: >>> use CMove without profitability tests for method %s\n", >>> method()->name()->as_quoted_ascii());}) >>> >>> loopopts.cpp changes inconsistent. In one place you check use_cmove only for doubles and in other for all. >>> >>> I will look on superword changes after you cleanup changes: remove >>> 8136725 and also create history from fresh repo - I don't want to see 50 revisions descriptions in webrev. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/10/15 7:04 AM, Civlin, Jan wrote: >>>> Please review this patch. >>>> >>>> Hi All, >>>> >>>> >>>> We would like to contribute the SuperWord enhancement to >>>> support vector conditional move (CMovVD ) on Intel AVX cpu. >>>> >>>> >>>> The contribution Bug ID: 8139340. >>>> >>>> Please review this patch: >>>> >>>> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8139340 >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ >>>> >>>> Description: >>>> >>>> SuperWord enhancement to support vector conditional move (CMovVD) >>>> on Intel AVX cpu. >>>> >>>> The SuperWord optimization bails out on counted loops that contain >>>> any conditional statement other than the loop exit, and this >>>> prevents vectorization of many compute bound loops. >>>> >>>> The proposed enhancement enables generation of CMovD on demand >>>> (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD ) >>>> in SuperWord optimization. >>>> >>>> The performance gain observed on a simplified Monte Carlo Option >>>> Calculation was up to 2x speed-up. >>>> >>>> Thank you, >>>> >>>> Jan. >>>> >>>> *From:*Igor Veresov [mailto:igor.veresov at oracle.com] >>>> *Sent:* Friday, October 9, 2015 3:22 PM >>>> *To:* Civlin, Jan >>>> *Cc:* hotspot compiler; Vladimir Kozlov >>>> *Subject:* Re: SuperWord enhancement to support vector conditional >>>> move (CMovVD ) on Intel AVX cpu. >>>> >>>> Here it is: https://bugs.openjdk.java.net/browse/JDK-8139340 >>>> >>>> igor >>>> >>>> On Oct 9, 2015, at 2:57 PM, Civlin, Jan >>> > wrote: >>>> >>>> Thank you, Igor. >>>> >>>> What is the RFR for this? >>>> >>>> *From:*Igor Veresov [mailto:igor.veresov at oracle.com] >>>> *Sent:*Friday, October 9, 2015 2:53 PM >>>> *To:*Civlin, Jan >>>> *Cc:*hotspot compiler; Vladimir Kozlov >>>> *Subject:*Re: SuperWord enhancement to support vector conditional >>>> move (CMovVD ) on Intel AVX cpu. >>>> >>>> Here the webrev: >>>> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ >>>> >>>> igor >>>> >>>> On Oct 9, 2015, at 1:15 PM, Civlin, Jan >>> > wrote: >>>> >>>> Igor, >>>> >>>> Please create RFR and upload this patch. You may need to rename >>>> ancnav.js.remove_this_extention back to ancnav.js (I have to >>>> rename it for passing the mail server filters). >>>> >>>> Description: >>>> >>>> SuperWord enhancement to support vector conditional move >>>> (CMovVD) on Intel AVX cpu. >>>> >>>> The SuperWord optimization bails out on counted loops that >>>> contain any conditional statement other than the loop exit, and >>>> this prevents vectorization of many compute bound loops. >>>> >>>> The proposed enhancement enables generation of CMovD on demand >>>> (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD >>>> ) in SuperWord optimization. >>>> >>>> The performance gain observed on a simplified Monte Carlo Option >>>> Calculation was up to 2x speed-up. >>>> >>>> Thank you, >>>> >>>> Jan. >>>> >>>> >>>> >>> >> From christian.thalinger at oracle.com Fri Oct 16 22:18:38 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 16 Oct 2015 12:18:38 -1000 Subject: [9] RFR(S): 8139380: VMError::report_and_die() does not produce replay file In-Reply-To: <5620DB29.3000603@oracle.com> References: <5620DB29.3000603@oracle.com> Message-ID: Oops. Sorry, this is my code. Thanks for fixing it. > On Oct 16, 2015, at 1:10 AM, Zolt?n Maj? wrote: > > Hi, > > > please review the patch for 8139380. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139380 > > Problem: The test compiler/ciReplay/TestVM.sh intentionally crashes the VM and expects compiler replay data to be saved into a file ('test_replay.txt'). Since the JVMCI changes were pushed, the test fails on some platforms we support because the file is not created by the VM. > > The file should be created by VMError::report_and_die(). However, a SIGSEGV is thrown in VMError::report() (report() is called by report_and_die()) that causes the VM to exit without saving replay data. > > > Solution: Update VMError::report() to use an appropriate format string to print the VM version in both JVMCI-enabled builds and builds without JVMCI. > > Webrev: > http://cr.openjdk.java.net/~zmajo/8139380/webrev.00/ > > Testing: > - JPRT (testset hotspot); > - executed failing test on all supported platforms, the failure is not triggered. > > Thank you and best regards, > > > Zoltan > From christian.thalinger at oracle.com Fri Oct 16 22:23:50 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 16 Oct 2015 12:23:50 -1000 Subject: RFR (XS): 8139675: Record C2 compilation of unexpectedly large methods as a failure instead of crashing In-Reply-To: <5621308C.7070608@oracle.com> References: <5621308C.7070608@oracle.com> Message-ID: <5505C9BF-C5E4-4724-BA62-4CC78EF5F1A7@oracle.com> > On Oct 16, 2015, at 7:14 AM, S. Bharadwaj Yadavalli wrote: > > I'd like to request for a review of the change at [2] to address [1]. > > This changes a method size assertion during compilation to record compilation failure and return gracefully. I don?t know the history here or anything about that assert, really. One thing we have to think about is this enhancement changes product behavior. Before the compilation was successful (was it?) and now it fails. > > Thanks, > > Bharadwaj > > [1] https://bugs.openjdk.java.net/browse/JDK-8139675 > [2] http://cr.openjdk.java.net/~bharadwaj/8139675/webrev/ From vladimir.kozlov at oracle.com Sat Oct 17 00:51:55 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 17 Oct 2015 08:51:55 +0800 Subject: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. In-Reply-To: References: <39F83597C33E5F408096702907E6C45005879107@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C450058791D0@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C45005879240@ORSMSX104.amr.corp.intel.com> <561E2097.8060907@oracle.com> <39F83597C33E5F408096702907E6C450058797EF@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C45005879A67@ORSMSX104.amr.corp.intel.com> <562081A9.9070008@oracle.com> Message-ID: <56219BAB.1090804@oracle.com> Yes, you can do that way too (match_rule_supported_vector call match_rule_supported). Thanks, Vladimir On 10/17/15 2:36 AM, Berg, Michael C wrote: > Initially I thought about doing that very thing. I would take this in different direction though, thus avoiding two duplicate lists. That is to have match_rule_supported_vector call match_rule_supported, keeping the lists disjunct. The vector length constraints are fewer in number and divergent and we don't' want people mixing the context rules as they have different meanings. It also removes the necessity of maintaining two identical lists. Otherwise granularity of control could become harder to manage. > > Thanks, > Michael > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, October 15, 2015 9:49 PM > To: Civlin, Jan > Cc: hotspot compiler; Berg, Michael C > Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. > > On 10/16/15 9:12 AM, Civlin, Jan wrote: >> Vladimir, >> >> Michael Berg is about to add this new function for filtering based on vlen, so I use it now for my case and Michael will add more cases soon. >> >> const bool Matcher::match_rule_supported_vlen(int opcode, int vlen) > > For your changes I would simple add next to the check in > VectorNode::implemented(): > > && (vopc != Op_CMoveD || vlen == 4); > > For changes which Michael is working on, you have to add it to all platforms .ad (same as match_rule_supported()). > > I would suggest to have match_rule_supported_vector(int opcode, int > vlen) which you will call from VectorNode::implemented() instead of match_rule_supported(). And move all current vector opcodes check in > match_rule_supported() to new one. > > Thanks, > Vladimir > >> >> >> The updated webrev is here: >> >> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.02/ >> >> >> Thank you, >> >> Jan. >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Wednesday, October 14, 2015 2:30 AM >> To: Civlin, Jan >> Cc: hotspot compiler >> Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >> >> I said before that condition in .ad file in Matcher::match_rule_supported(): >> >> case Op_CMoveVD: >> if (UseAVX > 2) <<<<< (UseAVX < 1 || UseAVX > 2) >> ret_value = false; >> >> should match predicates: >> >> predicate(UseAVX > 0 && UseAVX < 3 && n->as_Vector()->length() == 4); >> >> Also why only length 4? There is no length 2? I don't see any code in superword.cpp which limits size of CMoveVD vector. >> >> Otherwise it seems fine. >> >> Thanks, >> Vladimir >> >> On 10/14/15 1:57 AM, Civlin, Jan wrote: >>> Vladimir, >>> >>> the updated webrev is at >>> >>> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.01/ >>> >>> Thank you, Igor. >>> >>> Best, >>> >>> Jan. >>> >>> -----Original Message----- >>> From: Igor Veresov [mailto:igor.veresov at oracle.com] >>> Sent: Tuesday, October 13, 2015 10:51 AM >>> To: Civlin, Jan >>> Cc: Vladimir Kozlov >>> Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >>> >>> Done. >>> >>>> On Oct 13, 2015, at 9:51 AM, Civlin, Jan wrote: >>>> >>>> Igor, >>>> >>>> I got a response from the moderator that the previous message (attached below) has been rejected due to the size limits. >>>> Please upload the attached webrev (I guess it will be >>>> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.01/) >>>> >>>> And I'll send the link to the group. >>>> >>>> Thank you, >>>> >>>> Jan. >>>> >>>> -----Original Message----- >>>> From: Civlin, Jan >>>> Sent: Monday, October 12, 2015 10:19 PM >>>> To: Vladimir Kozlov >>>> Cc: Igor Veresov; hotspot compiler; Civlin, Jan >>>> Subject: RE: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >>>> >>>> Vladimir, >>>> >>>> Here is a webrev built from a single changeset. >>>> Please use it for further reviewing. >>>> >>>> Thank you, >>>> >>>> Jan. >>>> >>>> -----Original Message----- >>>> From: Civlin, Jan >>>> Sent: Saturday, October 10, 2015 12:14 PM >>>> To: Vladimir Kozlov >>>> Cc: hotspot compiler >>>> Subject: RE: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >>>> >>>> Vladimir, >>>> >>>> Thank you for the quick review. >>>> >>>> >>>> I thought you are patching your repo using hotspot.patch which is clean of empty files or .hgtag and you use webrev only for facilitation of visual code review. >>>> If you use hotspot.patch it does not propagate to your repo empty or already integrated in 8136725 files or my repo tags, since none of them are in the patch. >>>> I thought you are simply skipping unchanged files if you see them in webrev html pages. >>>> >>>> My repo is a consistent and long living clone of your repo. It is a single place that includes the history of all my changes, which let me go ahead in development way far of what is ready for going out to you. I can create an additional repo and filter out my tags on way out, but it will create more possibilities for accidental errors. >>>> >>>> >>>> x86.ad: it is indeed not (yet) AVX3, since AVX3 will have different ISA. Once we have AVX3 in the house and can debug it, AVX3 case will be added. >>>> >>>> c2_globals.hpp: >>>> I will rename the flag to UseCMoveUnconditionally, but I see no point of having another flag for the vector: once SuperWord detects CMovD, it merely vectorize it. >>>> In the opposite direction: one cannot ask for vectorization of CMovD and not to get them in the scalar case. >>>> >>>> compile.cpp: >>>> 1114: will add "do_vector_loop() &&" and change to NOT_PRODUCT(if >>>> (do_vector_loop() && Verbose&& && has_method()) >>>> {tty->print("Compile::Init: use CMove without profitability tests >>>> for method %s\n", method()->name()->as_quoted_ascii());}) >>>> >>>> loopopts.cpp: >>>> 601: will add "&& cmp_op == Op_CmpD" and change to if >>>> (C->use_cmove() && cmp_op == Op_CmpD) ;//keep going >>>> >>>> >>>> Thank you, >>>> >>>> Jan >>>> >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Saturday, October 10, 2015 5:52 AM >>>> To: Civlin, Jan >>>> Cc: hotspot compiler >>>> Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >>>> >>>> Changes contains also 8136725 (loop reserve copy) changes. Please, clean up. >>>> >>>> x86.ad WAIT! According to next conditions (BTW, support condition should match predicate) this is only supported with AVX1 and AVX2 and not AVX3. Really? >>>> >>>> I think it should be reversed condition (< 3): >>>> + case Op_CMoveVD: >>>> + if (UseAVX > 2) >>>> + ret_value = false; >>>> >>>> + instruct vcmov4D_reg(vecY dst, vecY src1, vecY src2, immI8 cop, >>>> cmpOp_vcmppd copnd) %{ >>>> + predicate(UseAVX > 0 && UseAVX < 3 && n->as_Vector()->length() >>>> + == 4); >>>> >>>> >>>> x86_64.ad changes are empty (could be only spacing change) so remove it from change. >>>> >>>> c2_globals.hpp DoReserveCopyInSuperWord is defined in 8136725 changes. >>>> UseCMov should be UseCMoveUnconditionally I think (note 'move' >>>> instead of 'mov'). Also I am not sure that you should mix 2 things >>>> into this >>>> changes: one is vectorizing cmoveD (for doubles) and always generate cmoves. I think it is different issues and this change should concentrate on vectorizing only double cmoves. Then flag could be VectorizeCMoveD. >>>> >>>> compile.cpp print not under UseCmov flag: >>>> + NOT_PRODUCT(if (Verbose && has_method()) {tty->print("Compile::Init: >>>> use CMove without profitability tests for method %s\n", >>>> method()->name()->as_quoted_ascii());}) >>>> >>>> loopopts.cpp changes inconsistent. In one place you check use_cmove only for doubles and in other for all. >>>> >>>> I will look on superword changes after you cleanup changes: remove >>>> 8136725 and also create history from fresh repo - I don't want to see 50 revisions descriptions in webrev. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/10/15 7:04 AM, Civlin, Jan wrote: >>>>> Please review this patch. >>>>> >>>>> Hi All, >>>>> >>>>> >>>>> We would like to contribute the SuperWord enhancement to >>>>> support vector conditional move (CMovVD ) on Intel AVX cpu. >>>>> >>>>> >>>>> The contribution Bug ID: 8139340. >>>>> >>>>> Please review this patch: >>>>> >>>>> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8139340 >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ >>>>> >>>>> Description: >>>>> >>>>> SuperWord enhancement to support vector conditional move (CMovVD) >>>>> on Intel AVX cpu. >>>>> >>>>> The SuperWord optimization bails out on counted loops that contain >>>>> any conditional statement other than the loop exit, and this >>>>> prevents vectorization of many compute bound loops. >>>>> >>>>> The proposed enhancement enables generation of CMovD on demand >>>>> (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD ) >>>>> in SuperWord optimization. >>>>> >>>>> The performance gain observed on a simplified Monte Carlo Option >>>>> Calculation was up to 2x speed-up. >>>>> >>>>> Thank you, >>>>> >>>>> Jan. >>>>> >>>>> *From:*Igor Veresov [mailto:igor.veresov at oracle.com] >>>>> *Sent:* Friday, October 9, 2015 3:22 PM >>>>> *To:* Civlin, Jan >>>>> *Cc:* hotspot compiler; Vladimir Kozlov >>>>> *Subject:* Re: SuperWord enhancement to support vector conditional >>>>> move (CMovVD ) on Intel AVX cpu. >>>>> >>>>> Here it is: https://bugs.openjdk.java.net/browse/JDK-8139340 >>>>> >>>>> igor >>>>> >>>>> On Oct 9, 2015, at 2:57 PM, Civlin, Jan >>>> > wrote: >>>>> >>>>> Thank you, Igor. >>>>> >>>>> What is the RFR for this? >>>>> >>>>> *From:*Igor Veresov [mailto:igor.veresov at oracle.com] >>>>> *Sent:*Friday, October 9, 2015 2:53 PM >>>>> *To:*Civlin, Jan >>>>> *Cc:*hotspot compiler; Vladimir Kozlov >>>>> *Subject:*Re: SuperWord enhancement to support vector conditional >>>>> move (CMovVD ) on Intel AVX cpu. >>>>> >>>>> Here the webrev: >>>>> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ >>>>> >>>>> igor >>>>> >>>>> On Oct 9, 2015, at 1:15 PM, Civlin, Jan >>>> > wrote: >>>>> >>>>> Igor, >>>>> >>>>> Please create RFR and upload this patch. You may need to rename >>>>> ancnav.js.remove_this_extention back to ancnav.js (I have to >>>>> rename it for passing the mail server filters). >>>>> >>>>> Description: >>>>> >>>>> SuperWord enhancement to support vector conditional move >>>>> (CMovVD) on Intel AVX cpu. >>>>> >>>>> The SuperWord optimization bails out on counted loops that >>>>> contain any conditional statement other than the loop exit, and >>>>> this prevents vectorization of many compute bound loops. >>>>> >>>>> The proposed enhancement enables generation of CMovD on demand >>>>> (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD >>>>> ) in SuperWord optimization. >>>>> >>>>> The performance gain observed on a simplified Monte Carlo Option >>>>> Calculation was up to 2x speed-up. >>>>> >>>>> Thank you, >>>>> >>>>> Jan. >>>>> >>>>> >>>>> >>>> >>> From vladimir.kozlov at oracle.com Mon Oct 19 00:44:04 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 19 Oct 2015 08:44:04 +0800 Subject: RFR (M): 8139575: Update for x86 log in the math lib In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A568B3FB5@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A568B3FB5@ORSMSX106.amr.corp.intel.com> Message-ID: <56243CD4.7040902@oracle.com> macroAssembler_x86.hpp instead of couple #if you can do: + void fast_log(XMMRegister xmm0, XMMRegister xmm1, XMMRegister xmm2, XMMRegister xmm3, + XMMRegister xmm4, XMMRegister xmm5, XMMRegister xmm6, XMMRegister xmm7, + Register rax, Register rcx, Register rdx, Register tmp1 LP64_ONLY(, Register tmp2)); Otherwise looks good. Thanks, Vladimir On 10/15/15 5:18 AM, Deshpande, Vivek R wrote: > Hi all > > I would like to contribute a patch which optimizes Math.log() for 64 and > 32 bit X86 architecture using Intel LIBM implementation. > > The improvement gives 1.9x gain over base. > > Could you please review and sponsor this patch. > > Bug-id: > > https://bugs.openjdk.java.net/browse/JDK-8139575 > webrev: > > http://cr.openjdk.java.net/~mcberg/8139575/webrev_01/ > > Thanks and regards, > > Vivek > From zoltan.majo at oracle.com Mon Oct 19 06:53:11 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 19 Oct 2015 08:53:11 +0200 Subject: [9] RFR(S): 8139380: VMError::report_and_die() does not produce replay file In-Reply-To: References: <5620DB29.3000603@oracle.com> Message-ID: <56249357.409@oracle.com> Hi Chris, On 10/17/2015 12:18 AM, Christian Thalinger wrote: > Oops. Sorry, this is my code. Thanks for fixing it. you're welcome. Once I've discovered the cause of the problem the fix was straightforward to come up with. Best regards, Zoltan > >> On Oct 16, 2015, at 1:10 AM, Zolt?n Maj? wrote: >> >> Hi, >> >> >> please review the patch for 8139380. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8139380 >> >> Problem: The test compiler/ciReplay/TestVM.sh intentionally crashes the VM and expects compiler replay data to be saved into a file ('test_replay.txt'). Since the JVMCI changes were pushed, the test fails on some platforms we support because the file is not created by the VM. >> >> The file should be created by VMError::report_and_die(). However, a SIGSEGV is thrown in VMError::report() (report() is called by report_and_die()) that causes the VM to exit without saving replay data. >> >> >> Solution: Update VMError::report() to use an appropriate format string to print the VM version in both JVMCI-enabled builds and builds without JVMCI. >> >> Webrev: >> http://cr.openjdk.java.net/~zmajo/8139380/webrev.00/ >> >> Testing: >> - JPRT (testset hotspot); >> - executed failing test on all supported platforms, the failure is not triggered. >> >> Thank you and best regards, >> >> >> Zoltan >> From vladimir.x.ivanov at oracle.com Mon Oct 19 13:08:04 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 19 Oct 2015 16:08:04 +0300 Subject: [9] RFR (XXXS): 8139881: Exclude java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java from execution Message-ID: <5624EB34.6060001@oracle.com> Exclude java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java from execution [1] until 8129523 [2] is fixed. Thanks! Best regards, Vladimir Ivanov [1] diff --git a/test/java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java b/test/java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java --- a/test/java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java +++ b/test/java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java @@ -23,6 +23,7 @@ /* * @test LFSingleThreadCachingTest + * @ignore 8129523 * @bug 8046703 * @key randomness * @summary Test verifies that lambda forms are cached when run with single thread [2] https://bugs.openjdk.java.net/browse/JDK-8129523 From vladimir.kozlov at oracle.com Mon Oct 19 13:53:19 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 19 Oct 2015 21:53:19 +0800 Subject: [9] RFR (XXXS): 8139881: Exclude java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java from execution In-Reply-To: <5624EB34.6060001@oracle.com> References: <5624EB34.6060001@oracle.com> Message-ID: <5624F5CF.6090708@oracle.com> Good. Thanks, Vladimir On 10/19/15 9:08 PM, Vladimir Ivanov wrote: > Exclude java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java from > execution [1] until 8129523 [2] is fixed. > > Thanks! > > Best regards, > Vladimir Ivanov > > [1] diff --git > a/test/java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java > b/test/java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java > --- a/test/java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java > +++ b/test/java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java > @@ -23,6 +23,7 @@ > > /* > * @test LFSingleThreadCachingTest > + * @ignore 8129523 > * @bug 8046703 > * @key randomness > * @summary Test verifies that lambda forms are cached when run with > single thread > > [2] https://bugs.openjdk.java.net/browse/JDK-8129523 From vladimir.x.ivanov at oracle.com Mon Oct 19 14:52:01 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 19 Oct 2015 17:52:01 +0300 Subject: [9] RFR (XXXS): 8139881: Exclude java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java from execution In-Reply-To: <5624F5CF.6090708@oracle.com> References: <5624EB34.6060001@oracle.com> <5624F5CF.6090708@oracle.com> Message-ID: <56250391.5000207@oracle.com> Thanks, Vladimir. Best regards, Vladimir Ivanov On 10/19/15 4:53 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 10/19/15 9:08 PM, Vladimir Ivanov wrote: >> Exclude java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java from >> execution [1] until 8129523 [2] is fixed. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov >> >> [1] diff --git >> a/test/java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java >> b/test/java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java >> --- a/test/java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java >> +++ b/test/java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java >> @@ -23,6 +23,7 @@ >> >> /* >> * @test LFSingleThreadCachingTest >> + * @ignore 8129523 >> * @bug 8046703 >> * @key randomness >> * @summary Test verifies that lambda forms are cached when run with >> single thread >> >> [2] https://bugs.openjdk.java.net/browse/JDK-8129523 From roland.westrelin at oracle.com Mon Oct 19 15:07:17 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 19 Oct 2015 17:07:17 +0200 Subject: RFR(S): 8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI In-Reply-To: <561E16EA.9070705@oracle.com> References: <7B89ADB9-1DF9-4DE2-85C8-0ADFF34A3190@oracle.com> <55F99D08.3010204@oracle.com> <4DAAADBF-9A3C-46BD-9E86-29E9B5044FAA@oracle.com> <55F9AB59.6030604@oracle.com> <07AAF0D5-134D-4D85-BD4C-EA5049EF8857@oracle.com> <55FF5E26.1060008@oracle.com> <041EEDC9-D32F-420D-9D55-111499B13321@oracle.com> <9D17B19D-9A35-4EFE-B5F7-954629DA2FC2@oracle.com> <10866B0A-712E-4665-9CC3-838AE6536D4A@oracle.com> <56014EA4.50907@oracle.com> <56122D8D.1050909@oracle.com> <56125D5A.7060708@oracle.com> <561E16EA.9070705@oracle.com> Message-ID: <3CE4059A-822D-4420-A0C7-3B7407C0E64A@oracle.com> Thanks for the review, Vladimir but Tobias noticed I missed one store in LibraryCallKit::inline_unsafe_access(). Here is a new webrev: http://cr.openjdk.java.net/~roland/8136473/webrev.04/ With the extra change below. Roland. diff --git a/src/share/vm/opto/idealKit.cpp b/src/share/vm/opto/idealKit.cpp --- a/src/share/vm/opto/idealKit.cpp +++ b/src/share/vm/opto/idealKit.cpp @@ -368,7 +368,8 @@ Node* IdealKit::store(Node* ctl, Node* adr, Node *val, BasicType bt, int adr_idx, - MemNode::MemOrd mo, bool require_atomic_access) { + MemNode::MemOrd mo, bool require_atomic_access, + bool mismatched) { assert(adr_idx != Compile::AliasIdxTop, "use other store_to_memory factory"); const TypePtr* adr_type = NULL; debug_only(adr_type = C->get_adr_type(adr_idx)); @@ -379,6 +380,9 @@ } else { st = StoreNode::make(_gvn, ctl, mem, adr, adr_type, val, bt, mo); } + if (mismatched) { + st->as_Store()->set_mismatched_access(); + } st = transform(st); set_memory(st, adr_idx); diff --git a/src/share/vm/opto/idealKit.hpp b/src/share/vm/opto/idealKit.hpp --- a/src/share/vm/opto/idealKit.hpp +++ b/src/share/vm/opto/idealKit.hpp @@ -228,7 +228,9 @@ BasicType bt, int adr_idx, MemNode::MemOrd mo, - bool require_atomic_access = false); + bool require_atomic_access = false, + bool mismatched = false + ); // Store a card mark ordered after store_oop Node* storeCM(Node* ctl, diff --git a/src/share/vm/opto/library_call.cpp b/src/share/vm/opto/library_call.cpp --- a/src/share/vm/opto/library_call.cpp +++ b/src/share/vm/opto/library_call.cpp @@ -2515,7 +2515,7 @@ // Update IdealKit memory. __ sync_kit(this); } __ else_(); { - __ store(__ ctrl(), adr, val, type, alias_type->index(), mo, is_volatile); + __ store(__ ctrl(), adr, val, type, alias_type->index(), mo, is_volatile, mismatched); } __ end_if(); // Final sync IdealKit and GraphKit. final_sync(ideal); > On Oct 14, 2015, at 10:48 AM, Vladimir Kozlov wrote: > > Good. > > Thanks, > Vladimir > > On 10/12/15 4:46 PM, Roland Westrelin wrote: >> Here is a new webrev that covers mismatched field accesses as well: >> >> http://cr.openjdk.java.net/~roland/8136473/webrev.03/ >> >> Roland. >> >>> On Oct 5, 2015, at 1:22 PM, Vladimir Kozlov wrote: >>> >>> So you are covering oops too. Okay then. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/5/15 5:12 PM, Roland Westrelin wrote: >>>> Thanks for looking at this, Vladimir. >>>> >>>>> Mismatching access can be only for basic type as I understand. The code for mismatched = true could be rearranged by checking type != T_OBJECT first. >>>> >>>> People do such crazy things with Unsafe, I thought it was best to be prepared for anything. >>>> >>>>> Why you set mismatched only for array element? What about fields? >>>> >>>> You?re right, fields need to be handled the same way. >>>> >>>>> And next should be && I think (if you keep your code) >>>>> if (type != T_OBJECT || !element->isa_narrowoop()) >>>> >>>> Either we reach that test with a basic type that is not an object (type != T_OBJECT) and there?s a mismatch but >>>> if we have element->array_element_basic_type() = T_NARROWOOP and type = T_OBJECT, then there?s no mismatch. >>>> >>>> Roland. >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 9/28/15 11:44 PM, Roland Westrelin wrote: >>>>>> That fix wasn?t sufficient so here is a new webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~roland/8136473/webrev.02/ >>>>>> >>>>>> On platforms that don?t support unaligned accesses we still have mismatched accesses because the java code of Unsafe.putIntUnaligned() is implemented in terms of putShort() and putByte() so my test case fails on sparc. I added a new boolean to MemNode to record whether the node is ?mismatched? in addition to the ?unaligned? boolean. >>>>>> >>>>>> Roland. >>>>>> >>>>>>> On Sep 22, 2015, at 2:50 PM, Vladimir Kozlov wrote: >>>>>>> >>>>>>> Okay. >>>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>> On 9/22/15 8:47 PM, Roland Westrelin wrote: >>>>>>>> For the record, it seems _unaligned is a reserved keyword for MSVC so I will change the field and function names to unaligned_access: >>>>>>>> >>>>>>>> diff --git a/src/share/vm/opto/memnode.hpp b/src/share/vm/opto/memnode.hpp >>>>>>>> --- a/src/share/vm/opto/memnode.hpp >>>>>>>> +++ b/src/share/vm/opto/memnode.hpp >>>>>>>> @@ -40,7 +40,7 @@ >>>>>>>> // Load or Store, possibly throwing a NULL pointer exception >>>>>>>> class MemNode : public Node { >>>>>>>> private: >>>>>>>> - bool _unaligned; >>>>>>>> + bool _unaligned_access; >>>>>>>> protected: >>>>>>>> #ifdef ASSERT >>>>>>>> const TypePtr* _adr_type; // What kind of memory is being addressed? >>>>>>>> >>>>>>>> @@ -129,8 +129,8 @@ >>>>>>>> // the given memory state? (The state may or may not be in(Memory).) >>>>>>>> Node* can_see_stored_value(Node* st, PhaseTransform* phase) const; >>>>>>>> >>>>>>>> - void set_unaligned() { _unaligned = true; } >>>>>>>> - bool is_unaligned() const { return _unaligned; } >>>>>>>> + void set_unaligned_access() { _unaligned_access = true; } >>>>>>>> + bool is_unaligned_access() const { return _unaligned_access; } >>>>>>>> >>>>>>>> #ifndef PRODUCT >>>>>>>> static void dump_adr_type(const Node* mem, const TypePtr* adr_type, outputStream *st); >>>>>>>> >>>>>>>> Roland. >>>>>>>> >>>>>>>>> On Sep 22, 2015, at 9:43 AM, Roland Westrelin wrote: >>>>>>>>> >>>>>>>>>> Roland I had a look too, the code looks good. >>>>>>>>> >>>>>>>>> Thanks, Michael. >>>>>>>>> >>>>>>>>> Roland. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Michael >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Roland Westrelin >>>>>>>>>> Sent: Monday, September 21, 2015 2:03 AM >>>>>>>>>> To: hotspot compiler >>>>>>>>>> Subject: Re: RFR(S): 8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI >>>>>>>>>> >>>>>>>>>> Thanks for the review, Vladimir. >>>>>>>>>> >>>>>>>>>> Roland. >>>>>>>>>> >>>>>>>>>>> On Sep 21, 2015, at 3:32 AM, Vladimir Kozlov wrote: >>>>>>>>>>> >>>>>>>>>>> This is good. Thank you for extending the test. >>>>>>>>>>> >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> On 9/18/15 11:03 PM, Roland Westrelin wrote: >>>>>>>>>>>>>>> Hmm, so you just relaxed the assert. You may need to fix EA too because it also checks for matching types(memory sizes). >>>>>>>>>>>>>>> I remember we had problem with RAW accesses back when jsr292 was implemented. So EA gave up on RAW access and marks allocations as escaping. Also may be superword/vectorization will be affected. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In general it is very bad for C2 to have different memory on the same non-RAW memory. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It already happens with vectorization. Do you see another solution (rather than relaxing the assert)? Putting a MemBarCPUOrder before and after the unaligned store? >>>>>>>>>>>>> >>>>>>>>>>>>> MemBarCPUOrder are definitely will help and it is simplest solution but, I think, it is too drastic. >>>>>>>>>>>>> It affect control flow and other memory slices. >>>>>>>>>>>>> We can try to mark such memory accesses or/and mark objects which have such accesses (if it is possible) and prevent vectorization and scalarization for them only. We should be able execute optimization on other memory slices then. >>>>>>>>>>>> >>>>>>>>>>>> Here is a new change: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~roland/8136473/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> Unaligned accesses are explicitly marked as such. >>>>>>>>>>>> >>>>>>>>>>>> I added a test case with a non escaping allocation and it works fine. I also added test case with vectorization and if the accesses are effectively unaligned vectorization doesn't happen. One of the test cases causes an assertion to fire when the allocation is expanded: the logic in InitializeNode::complete_stores() is confused by the unaligned store so I made sure unaligned stores are not captured by the initialization. >>>>>>>>>>>> >>>>>>>>>>>> Roland. >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> >> From ahmed.khawaja at oracle.com Mon Oct 19 15:25:54 2015 From: ahmed.khawaja at oracle.com (Ahmed Khawaja) Date: Mon, 19 Oct 2015 10:25:54 -0500 Subject: Help integrating intrinsics with Interp/C1 on SPARC Message-ID: <56250B82.8040009@oracle.com> Greetings, I am in the process of adding C2 intrinsics for CRC32 on SPARC and noticed that the x86 intrinsics have hooks for being called directly from the interp/C1 and not only C2. I am working on enabling this for SPARC as well, but one issue I am having is there documentation seems to be somewhat lacking for the calling conventions from the interp/C1 into an intrinsic method. For example, the intrinsics on SPARC have everything passed in the O registers and return in O0. For the interp/C1 I am having some trouble figuring out exactly how arguments are passed in and where the result is expected. If anyone has any pointers on this or further sources of documentation, please let me know. Thank you, Ahmed Khawaja From tobias.hartmann at oracle.com Mon Oct 19 15:27:12 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 19 Oct 2015 17:27:12 +0200 Subject: RFR(S): 8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI In-Reply-To: <3CE4059A-822D-4420-A0C7-3B7407C0E64A@oracle.com> References: <7B89ADB9-1DF9-4DE2-85C8-0ADFF34A3190@oracle.com> <55F99D08.3010204@oracle.com> <4DAAADBF-9A3C-46BD-9E86-29E9B5044FAA@oracle.com> <55F9AB59.6030604@oracle.com> <07AAF0D5-134D-4D85-BD4C-EA5049EF8857@oracle.com> <55FF5E26.1060008@oracle.com> <041EEDC9-D32F-420D-9D55-111499B13321@oracle.com> <9D17B19D-9A35-4EFE-B5F7-954629DA2FC2@oracle.com> <10866B0A-712E-4665-9CC3-838AE6536D4A@oracle.com> <56014EA4.50907@oracle.com> <56122D8D.1050909@oracle.com> <56125D5A.7060708@oracle.com> <561E16EA.9070705@oracle.com> <3CE4059A-822D-4420-A0C7-3B7407C0E64A@oracle.com> Message-ID: <56250BD0.2060209@oracle.com> Hi Roland, thanks for updating the patch. Looks good to me! Best, Tobias On 19.10.2015 17:07, Roland Westrelin wrote: > Thanks for the review, Vladimir but Tobias noticed I missed one store in LibraryCallKit::inline_unsafe_access(). Here is a new webrev: > > http://cr.openjdk.java.net/~roland/8136473/webrev.04/ > > With the extra change below. > > Roland. > > diff --git a/src/share/vm/opto/idealKit.cpp b/src/share/vm/opto/idealKit.cpp > --- a/src/share/vm/opto/idealKit.cpp > +++ b/src/share/vm/opto/idealKit.cpp > @@ -368,7 +368,8 @@ > > Node* IdealKit::store(Node* ctl, Node* adr, Node *val, BasicType bt, > int adr_idx, > - MemNode::MemOrd mo, bool require_atomic_access) { > + MemNode::MemOrd mo, bool require_atomic_access, > + bool mismatched) { > assert(adr_idx != Compile::AliasIdxTop, "use other store_to_memory factory"); > const TypePtr* adr_type = NULL; > debug_only(adr_type = C->get_adr_type(adr_idx)); > @@ -379,6 +380,9 @@ > } else { > st = StoreNode::make(_gvn, ctl, mem, adr, adr_type, val, bt, mo); > } > + if (mismatched) { > + st->as_Store()->set_mismatched_access(); > + } > st = transform(st); > set_memory(st, adr_idx); > > diff --git a/src/share/vm/opto/idealKit.hpp b/src/share/vm/opto/idealKit.hpp > --- a/src/share/vm/opto/idealKit.hpp > +++ b/src/share/vm/opto/idealKit.hpp > @@ -228,7 +228,9 @@ > BasicType bt, > int adr_idx, > MemNode::MemOrd mo, > - bool require_atomic_access = false); > + bool require_atomic_access = false, > + bool mismatched = false > + ); > > // Store a card mark ordered after store_oop > Node* storeCM(Node* ctl, > diff --git a/src/share/vm/opto/library_call.cpp b/src/share/vm/opto/library_call.cpp > --- a/src/share/vm/opto/library_call.cpp > +++ b/src/share/vm/opto/library_call.cpp > @@ -2515,7 +2515,7 @@ > // Update IdealKit memory. > __ sync_kit(this); > } __ else_(); { > - __ store(__ ctrl(), adr, val, type, alias_type->index(), mo, is_volatile); > + __ store(__ ctrl(), adr, val, type, alias_type->index(), mo, is_volatile, mismatched); > } __ end_if(); > // Final sync IdealKit and GraphKit. > final_sync(ideal); > > > > >> On Oct 14, 2015, at 10:48 AM, Vladimir Kozlov wrote: >> >> Good. >> >> Thanks, >> Vladimir >> >> On 10/12/15 4:46 PM, Roland Westrelin wrote: >>> Here is a new webrev that covers mismatched field accesses as well: >>> >>> http://cr.openjdk.java.net/~roland/8136473/webrev.03/ >>> >>> Roland. >>> >>>> On Oct 5, 2015, at 1:22 PM, Vladimir Kozlov wrote: >>>> >>>> So you are covering oops too. Okay then. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/5/15 5:12 PM, Roland Westrelin wrote: >>>>> Thanks for looking at this, Vladimir. >>>>> >>>>>> Mismatching access can be only for basic type as I understand. The code for mismatched = true could be rearranged by checking type != T_OBJECT first. >>>>> >>>>> People do such crazy things with Unsafe, I thought it was best to be prepared for anything. >>>>> >>>>>> Why you set mismatched only for array element? What about fields? >>>>> >>>>> You?re right, fields need to be handled the same way. >>>>> >>>>>> And next should be && I think (if you keep your code) >>>>>> if (type != T_OBJECT || !element->isa_narrowoop()) >>>>> >>>>> Either we reach that test with a basic type that is not an object (type != T_OBJECT) and there?s a mismatch but >>>>> if we have element->array_element_basic_type() = T_NARROWOOP and type = T_OBJECT, then there?s no mismatch. >>>>> >>>>> Roland. >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 9/28/15 11:44 PM, Roland Westrelin wrote: >>>>>>> That fix wasn?t sufficient so here is a new webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~roland/8136473/webrev.02/ >>>>>>> >>>>>>> On platforms that don?t support unaligned accesses we still have mismatched accesses because the java code of Unsafe.putIntUnaligned() is implemented in terms of putShort() and putByte() so my test case fails on sparc. I added a new boolean to MemNode to record whether the node is ?mismatched? in addition to the ?unaligned? boolean. >>>>>>> >>>>>>> Roland. >>>>>>> >>>>>>>> On Sep 22, 2015, at 2:50 PM, Vladimir Kozlov wrote: >>>>>>>> >>>>>>>> Okay. >>>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 9/22/15 8:47 PM, Roland Westrelin wrote: >>>>>>>>> For the record, it seems _unaligned is a reserved keyword for MSVC so I will change the field and function names to unaligned_access: >>>>>>>>> >>>>>>>>> diff --git a/src/share/vm/opto/memnode.hpp b/src/share/vm/opto/memnode.hpp >>>>>>>>> --- a/src/share/vm/opto/memnode.hpp >>>>>>>>> +++ b/src/share/vm/opto/memnode.hpp >>>>>>>>> @@ -40,7 +40,7 @@ >>>>>>>>> // Load or Store, possibly throwing a NULL pointer exception >>>>>>>>> class MemNode : public Node { >>>>>>>>> private: >>>>>>>>> - bool _unaligned; >>>>>>>>> + bool _unaligned_access; >>>>>>>>> protected: >>>>>>>>> #ifdef ASSERT >>>>>>>>> const TypePtr* _adr_type; // What kind of memory is being addressed? >>>>>>>>> >>>>>>>>> @@ -129,8 +129,8 @@ >>>>>>>>> // the given memory state? (The state may or may not be in(Memory).) >>>>>>>>> Node* can_see_stored_value(Node* st, PhaseTransform* phase) const; >>>>>>>>> >>>>>>>>> - void set_unaligned() { _unaligned = true; } >>>>>>>>> - bool is_unaligned() const { return _unaligned; } >>>>>>>>> + void set_unaligned_access() { _unaligned_access = true; } >>>>>>>>> + bool is_unaligned_access() const { return _unaligned_access; } >>>>>>>>> >>>>>>>>> #ifndef PRODUCT >>>>>>>>> static void dump_adr_type(const Node* mem, const TypePtr* adr_type, outputStream *st); >>>>>>>>> >>>>>>>>> Roland. >>>>>>>>> >>>>>>>>>> On Sep 22, 2015, at 9:43 AM, Roland Westrelin wrote: >>>>>>>>>> >>>>>>>>>>> Roland I had a look too, the code looks good. >>>>>>>>>> >>>>>>>>>> Thanks, Michael. >>>>>>>>>> >>>>>>>>>> Roland. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -Michael >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Roland Westrelin >>>>>>>>>>> Sent: Monday, September 21, 2015 2:03 AM >>>>>>>>>>> To: hotspot compiler >>>>>>>>>>> Subject: Re: RFR(S): 8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI >>>>>>>>>>> >>>>>>>>>>> Thanks for the review, Vladimir. >>>>>>>>>>> >>>>>>>>>>> Roland. >>>>>>>>>>> >>>>>>>>>>>> On Sep 21, 2015, at 3:32 AM, Vladimir Kozlov wrote: >>>>>>>>>>>> >>>>>>>>>>>> This is good. Thank you for extending the test. >>>>>>>>>>>> >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>> On 9/18/15 11:03 PM, Roland Westrelin wrote: >>>>>>>>>>>>>>>> Hmm, so you just relaxed the assert. You may need to fix EA too because it also checks for matching types(memory sizes). >>>>>>>>>>>>>>>> I remember we had problem with RAW accesses back when jsr292 was implemented. So EA gave up on RAW access and marks allocations as escaping. Also may be superword/vectorization will be affected. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In general it is very bad for C2 to have different memory on the same non-RAW memory. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It already happens with vectorization. Do you see another solution (rather than relaxing the assert)? Putting a MemBarCPUOrder before and after the unaligned store? >>>>>>>>>>>>>> >>>>>>>>>>>>>> MemBarCPUOrder are definitely will help and it is simplest solution but, I think, it is too drastic. >>>>>>>>>>>>>> It affect control flow and other memory slices. >>>>>>>>>>>>>> We can try to mark such memory accesses or/and mark objects which have such accesses (if it is possible) and prevent vectorization and scalarization for them only. We should be able execute optimization on other memory slices then. >>>>>>>>>>>>> >>>>>>>>>>>>> Here is a new change: >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~roland/8136473/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> Unaligned accesses are explicitly marked as such. >>>>>>>>>>>>> >>>>>>>>>>>>> I added a test case with a non escaping allocation and it works fine. I also added test case with vectorization and if the accesses are effectively unaligned vectorization doesn't happen. One of the test cases causes an assertion to fire when the allocation is expanded: the logic in InitializeNode::complete_stores() is confused by the unaligned store so I made sure unaligned stores are not captured by the initialization. >>>>>>>>>>>>> >>>>>>>>>>>>> Roland. >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> > From vladimir.kozlov at oracle.com Tue Oct 20 00:40:04 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 20 Oct 2015 08:40:04 +0800 Subject: RFR(S): 8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI In-Reply-To: <3CE4059A-822D-4420-A0C7-3B7407C0E64A@oracle.com> References: <7B89ADB9-1DF9-4DE2-85C8-0ADFF34A3190@oracle.com> <55F99D08.3010204@oracle.com> <4DAAADBF-9A3C-46BD-9E86-29E9B5044FAA@oracle.com> <55F9AB59.6030604@oracle.com> <07AAF0D5-134D-4D85-BD4C-EA5049EF8857@oracle.com> <55FF5E26.1060008@oracle.com> <041EEDC9-D32F-420D-9D55-111499B13321@oracle.com> <9D17B19D-9A35-4EFE-B5F7-954629DA2FC2@oracle.com> <10866B0A-712E-4665-9CC3-838AE6536D4A@oracle.com> <56014EA4.50907@oracle.com> <56122D8D.1050909@oracle.com> <56125D5A.7060708@oracle.com> <561E16EA.9070705@oracle.com> <3CE4059A-822D-4420-A0C7-3B7407C0E64A@oracle.com> Message-ID: <56258D64.2000008@oracle.com> Okay. Thanks, Vladimir On 10/19/15 11:07 PM, Roland Westrelin wrote: > Thanks for the review, Vladimir but Tobias noticed I missed one store in LibraryCallKit::inline_unsafe_access(). Here is a new webrev: > > http://cr.openjdk.java.net/~roland/8136473/webrev.04/ > > With the extra change below. > > Roland. > > diff --git a/src/share/vm/opto/idealKit.cpp b/src/share/vm/opto/idealKit.cpp > --- a/src/share/vm/opto/idealKit.cpp > +++ b/src/share/vm/opto/idealKit.cpp > @@ -368,7 +368,8 @@ > > Node* IdealKit::store(Node* ctl, Node* adr, Node *val, BasicType bt, > int adr_idx, > - MemNode::MemOrd mo, bool require_atomic_access) { > + MemNode::MemOrd mo, bool require_atomic_access, > + bool mismatched) { > assert(adr_idx != Compile::AliasIdxTop, "use other store_to_memory factory"); > const TypePtr* adr_type = NULL; > debug_only(adr_type = C->get_adr_type(adr_idx)); > @@ -379,6 +380,9 @@ > } else { > st = StoreNode::make(_gvn, ctl, mem, adr, adr_type, val, bt, mo); > } > + if (mismatched) { > + st->as_Store()->set_mismatched_access(); > + } > st = transform(st); > set_memory(st, adr_idx); > > diff --git a/src/share/vm/opto/idealKit.hpp b/src/share/vm/opto/idealKit.hpp > --- a/src/share/vm/opto/idealKit.hpp > +++ b/src/share/vm/opto/idealKit.hpp > @@ -228,7 +228,9 @@ > BasicType bt, > int adr_idx, > MemNode::MemOrd mo, > - bool require_atomic_access = false); > + bool require_atomic_access = false, > + bool mismatched = false > + ); > > // Store a card mark ordered after store_oop > Node* storeCM(Node* ctl, > diff --git a/src/share/vm/opto/library_call.cpp b/src/share/vm/opto/library_call.cpp > --- a/src/share/vm/opto/library_call.cpp > +++ b/src/share/vm/opto/library_call.cpp > @@ -2515,7 +2515,7 @@ > // Update IdealKit memory. > __ sync_kit(this); > } __ else_(); { > - __ store(__ ctrl(), adr, val, type, alias_type->index(), mo, is_volatile); > + __ store(__ ctrl(), adr, val, type, alias_type->index(), mo, is_volatile, mismatched); > } __ end_if(); > // Final sync IdealKit and GraphKit. > final_sync(ideal); > > > > >> On Oct 14, 2015, at 10:48 AM, Vladimir Kozlov wrote: >> >> Good. >> >> Thanks, >> Vladimir >> >> On 10/12/15 4:46 PM, Roland Westrelin wrote: >>> Here is a new webrev that covers mismatched field accesses as well: >>> >>> http://cr.openjdk.java.net/~roland/8136473/webrev.03/ >>> >>> Roland. >>> >>>> On Oct 5, 2015, at 1:22 PM, Vladimir Kozlov wrote: >>>> >>>> So you are covering oops too. Okay then. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/5/15 5:12 PM, Roland Westrelin wrote: >>>>> Thanks for looking at this, Vladimir. >>>>> >>>>>> Mismatching access can be only for basic type as I understand. The code for mismatched = true could be rearranged by checking type != T_OBJECT first. >>>>> >>>>> People do such crazy things with Unsafe, I thought it was best to be prepared for anything. >>>>> >>>>>> Why you set mismatched only for array element? What about fields? >>>>> >>>>> You?re right, fields need to be handled the same way. >>>>> >>>>>> And next should be && I think (if you keep your code) >>>>>> if (type != T_OBJECT || !element->isa_narrowoop()) >>>>> >>>>> Either we reach that test with a basic type that is not an object (type != T_OBJECT) and there?s a mismatch but >>>>> if we have element->array_element_basic_type() = T_NARROWOOP and type = T_OBJECT, then there?s no mismatch. >>>>> >>>>> Roland. >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 9/28/15 11:44 PM, Roland Westrelin wrote: >>>>>>> That fix wasn?t sufficient so here is a new webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~roland/8136473/webrev.02/ >>>>>>> >>>>>>> On platforms that don?t support unaligned accesses we still have mismatched accesses because the java code of Unsafe.putIntUnaligned() is implemented in terms of putShort() and putByte() so my test case fails on sparc. I added a new boolean to MemNode to record whether the node is ?mismatched? in addition to the ?unaligned? boolean. >>>>>>> >>>>>>> Roland. >>>>>>> >>>>>>>> On Sep 22, 2015, at 2:50 PM, Vladimir Kozlov wrote: >>>>>>>> >>>>>>>> Okay. >>>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 9/22/15 8:47 PM, Roland Westrelin wrote: >>>>>>>>> For the record, it seems _unaligned is a reserved keyword for MSVC so I will change the field and function names to unaligned_access: >>>>>>>>> >>>>>>>>> diff --git a/src/share/vm/opto/memnode.hpp b/src/share/vm/opto/memnode.hpp >>>>>>>>> --- a/src/share/vm/opto/memnode.hpp >>>>>>>>> +++ b/src/share/vm/opto/memnode.hpp >>>>>>>>> @@ -40,7 +40,7 @@ >>>>>>>>> // Load or Store, possibly throwing a NULL pointer exception >>>>>>>>> class MemNode : public Node { >>>>>>>>> private: >>>>>>>>> - bool _unaligned; >>>>>>>>> + bool _unaligned_access; >>>>>>>>> protected: >>>>>>>>> #ifdef ASSERT >>>>>>>>> const TypePtr* _adr_type; // What kind of memory is being addressed? >>>>>>>>> >>>>>>>>> @@ -129,8 +129,8 @@ >>>>>>>>> // the given memory state? (The state may or may not be in(Memory).) >>>>>>>>> Node* can_see_stored_value(Node* st, PhaseTransform* phase) const; >>>>>>>>> >>>>>>>>> - void set_unaligned() { _unaligned = true; } >>>>>>>>> - bool is_unaligned() const { return _unaligned; } >>>>>>>>> + void set_unaligned_access() { _unaligned_access = true; } >>>>>>>>> + bool is_unaligned_access() const { return _unaligned_access; } >>>>>>>>> >>>>>>>>> #ifndef PRODUCT >>>>>>>>> static void dump_adr_type(const Node* mem, const TypePtr* adr_type, outputStream *st); >>>>>>>>> >>>>>>>>> Roland. >>>>>>>>> >>>>>>>>>> On Sep 22, 2015, at 9:43 AM, Roland Westrelin wrote: >>>>>>>>>> >>>>>>>>>>> Roland I had a look too, the code looks good. >>>>>>>>>> >>>>>>>>>> Thanks, Michael. >>>>>>>>>> >>>>>>>>>> Roland. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -Michael >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Roland Westrelin >>>>>>>>>>> Sent: Monday, September 21, 2015 2:03 AM >>>>>>>>>>> To: hotspot compiler >>>>>>>>>>> Subject: Re: RFR(S): 8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI >>>>>>>>>>> >>>>>>>>>>> Thanks for the review, Vladimir. >>>>>>>>>>> >>>>>>>>>>> Roland. >>>>>>>>>>> >>>>>>>>>>>> On Sep 21, 2015, at 3:32 AM, Vladimir Kozlov wrote: >>>>>>>>>>>> >>>>>>>>>>>> This is good. Thank you for extending the test. >>>>>>>>>>>> >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>> On 9/18/15 11:03 PM, Roland Westrelin wrote: >>>>>>>>>>>>>>>> Hmm, so you just relaxed the assert. You may need to fix EA too because it also checks for matching types(memory sizes). >>>>>>>>>>>>>>>> I remember we had problem with RAW accesses back when jsr292 was implemented. So EA gave up on RAW access and marks allocations as escaping. Also may be superword/vectorization will be affected. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In general it is very bad for C2 to have different memory on the same non-RAW memory. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It already happens with vectorization. Do you see another solution (rather than relaxing the assert)? Putting a MemBarCPUOrder before and after the unaligned store? >>>>>>>>>>>>>> >>>>>>>>>>>>>> MemBarCPUOrder are definitely will help and it is simplest solution but, I think, it is too drastic. >>>>>>>>>>>>>> It affect control flow and other memory slices. >>>>>>>>>>>>>> We can try to mark such memory accesses or/and mark objects which have such accesses (if it is possible) and prevent vectorization and scalarization for them only. We should be able execute optimization on other memory slices then. >>>>>>>>>>>>> >>>>>>>>>>>>> Here is a new change: >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~roland/8136473/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> Unaligned accesses are explicitly marked as such. >>>>>>>>>>>>> >>>>>>>>>>>>> I added a test case with a non escaping allocation and it works fine. I also added test case with vectorization and if the accesses are effectively unaligned vectorization doesn't happen. One of the test cases causes an assertion to fire when the allocation is expanded: the logic in InitializeNode::complete_stores() is confused by the unaligned store so I made sure unaligned stores are not captured by the initialization. >>>>>>>>>>>>> >>>>>>>>>>>>> Roland. >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> > From roland.westrelin at oracle.com Tue Oct 20 07:37:53 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 20 Oct 2015 09:37:53 +0200 Subject: RFR(S): 8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI In-Reply-To: <56258D64.2000008@oracle.com> References: <7B89ADB9-1DF9-4DE2-85C8-0ADFF34A3190@oracle.com> <55F99D08.3010204@oracle.com> <4DAAADBF-9A3C-46BD-9E86-29E9B5044FAA@oracle.com> <55F9AB59.6030604@oracle.com> <07AAF0D5-134D-4D85-BD4C-EA5049EF8857@oracle.com> <55FF5E26.1060008@oracle.com> <041EEDC9-D32F-420D-9D55-111499B13321@oracle.com> <9D17B19D-9A35-4EFE-B5F7-954629DA2FC2@oracle.com> <10866B0A-712E-4665-9CC3-838AE6536D4A@oracle.com> <56014EA4.50907@oracle.com> <56122D8D.1050909@oracle.com> <56125D5A.7060708@oracle.com> <561E16EA.9070705@oracle.com> <3CE4059A-822D-4420-A0C7-3B7407C0E64A@oracle.com> <56258D64.2000008@oracle.com> Message-ID: Thanks Vladimir and Tobias for the reviews. Roland. > On Oct 20, 2015, at 2:40 AM, Vladimir Kozlov wrote: > > Okay. > > Thanks, > Vladimir > > On 10/19/15 11:07 PM, Roland Westrelin wrote: >> Thanks for the review, Vladimir but Tobias noticed I missed one store in LibraryCallKit::inline_unsafe_access(). Here is a new webrev: >> >> http://cr.openjdk.java.net/~roland/8136473/webrev.04/ >> >> With the extra change below. >> >> Roland. >> >> diff --git a/src/share/vm/opto/idealKit.cpp b/src/share/vm/opto/idealKit.cpp >> --- a/src/share/vm/opto/idealKit.cpp >> +++ b/src/share/vm/opto/idealKit.cpp >> @@ -368,7 +368,8 @@ >> >> Node* IdealKit::store(Node* ctl, Node* adr, Node *val, BasicType bt, >> int adr_idx, >> - MemNode::MemOrd mo, bool require_atomic_access) { >> + MemNode::MemOrd mo, bool require_atomic_access, >> + bool mismatched) { >> assert(adr_idx != Compile::AliasIdxTop, "use other store_to_memory factory"); >> const TypePtr* adr_type = NULL; >> debug_only(adr_type = C->get_adr_type(adr_idx)); >> @@ -379,6 +380,9 @@ >> } else { >> st = StoreNode::make(_gvn, ctl, mem, adr, adr_type, val, bt, mo); >> } >> + if (mismatched) { >> + st->as_Store()->set_mismatched_access(); >> + } >> st = transform(st); >> set_memory(st, adr_idx); >> >> diff --git a/src/share/vm/opto/idealKit.hpp b/src/share/vm/opto/idealKit.hpp >> --- a/src/share/vm/opto/idealKit.hpp >> +++ b/src/share/vm/opto/idealKit.hpp >> @@ -228,7 +228,9 @@ >> BasicType bt, >> int adr_idx, >> MemNode::MemOrd mo, >> - bool require_atomic_access = false); >> + bool require_atomic_access = false, >> + bool mismatched = false >> + ); >> >> // Store a card mark ordered after store_oop >> Node* storeCM(Node* ctl, >> diff --git a/src/share/vm/opto/library_call.cpp b/src/share/vm/opto/library_call.cpp >> --- a/src/share/vm/opto/library_call.cpp >> +++ b/src/share/vm/opto/library_call.cpp >> @@ -2515,7 +2515,7 @@ >> // Update IdealKit memory. >> __ sync_kit(this); >> } __ else_(); { >> - __ store(__ ctrl(), adr, val, type, alias_type->index(), mo, is_volatile); >> + __ store(__ ctrl(), adr, val, type, alias_type->index(), mo, is_volatile, mismatched); >> } __ end_if(); >> // Final sync IdealKit and GraphKit. >> final_sync(ideal); >> >> >> >> >>> On Oct 14, 2015, at 10:48 AM, Vladimir Kozlov wrote: >>> >>> Good. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/12/15 4:46 PM, Roland Westrelin wrote: >>>> Here is a new webrev that covers mismatched field accesses as well: >>>> >>>> http://cr.openjdk.java.net/~roland/8136473/webrev.03/ >>>> >>>> Roland. >>>> >>>>> On Oct 5, 2015, at 1:22 PM, Vladimir Kozlov wrote: >>>>> >>>>> So you are covering oops too. Okay then. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/5/15 5:12 PM, Roland Westrelin wrote: >>>>>> Thanks for looking at this, Vladimir. >>>>>> >>>>>>> Mismatching access can be only for basic type as I understand. The code for mismatched = true could be rearranged by checking type != T_OBJECT first. >>>>>> >>>>>> People do such crazy things with Unsafe, I thought it was best to be prepared for anything. >>>>>> >>>>>>> Why you set mismatched only for array element? What about fields? >>>>>> >>>>>> You?re right, fields need to be handled the same way. >>>>>> >>>>>>> And next should be && I think (if you keep your code) >>>>>>> if (type != T_OBJECT || !element->isa_narrowoop()) >>>>>> >>>>>> Either we reach that test with a basic type that is not an object (type != T_OBJECT) and there?s a mismatch but >>>>>> if we have element->array_element_basic_type() = T_NARROWOOP and type = T_OBJECT, then there?s no mismatch. >>>>>> >>>>>> Roland. >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 9/28/15 11:44 PM, Roland Westrelin wrote: >>>>>>>> That fix wasn?t sufficient so here is a new webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~roland/8136473/webrev.02/ >>>>>>>> >>>>>>>> On platforms that don?t support unaligned accesses we still have mismatched accesses because the java code of Unsafe.putIntUnaligned() is implemented in terms of putShort() and putByte() so my test case fails on sparc. I added a new boolean to MemNode to record whether the node is ?mismatched? in addition to the ?unaligned? boolean. >>>>>>>> >>>>>>>> Roland. >>>>>>>> >>>>>>>>> On Sep 22, 2015, at 2:50 PM, Vladimir Kozlov wrote: >>>>>>>>> >>>>>>>>> Okay. >>>>>>>>> >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 9/22/15 8:47 PM, Roland Westrelin wrote: >>>>>>>>>> For the record, it seems _unaligned is a reserved keyword for MSVC so I will change the field and function names to unaligned_access: >>>>>>>>>> >>>>>>>>>> diff --git a/src/share/vm/opto/memnode.hpp b/src/share/vm/opto/memnode.hpp >>>>>>>>>> --- a/src/share/vm/opto/memnode.hpp >>>>>>>>>> +++ b/src/share/vm/opto/memnode.hpp >>>>>>>>>> @@ -40,7 +40,7 @@ >>>>>>>>>> // Load or Store, possibly throwing a NULL pointer exception >>>>>>>>>> class MemNode : public Node { >>>>>>>>>> private: >>>>>>>>>> - bool _unaligned; >>>>>>>>>> + bool _unaligned_access; >>>>>>>>>> protected: >>>>>>>>>> #ifdef ASSERT >>>>>>>>>> const TypePtr* _adr_type; // What kind of memory is being addressed? >>>>>>>>>> >>>>>>>>>> @@ -129,8 +129,8 @@ >>>>>>>>>> // the given memory state? (The state may or may not be in(Memory).) >>>>>>>>>> Node* can_see_stored_value(Node* st, PhaseTransform* phase) const; >>>>>>>>>> >>>>>>>>>> - void set_unaligned() { _unaligned = true; } >>>>>>>>>> - bool is_unaligned() const { return _unaligned; } >>>>>>>>>> + void set_unaligned_access() { _unaligned_access = true; } >>>>>>>>>> + bool is_unaligned_access() const { return _unaligned_access; } >>>>>>>>>> >>>>>>>>>> #ifndef PRODUCT >>>>>>>>>> static void dump_adr_type(const Node* mem, const TypePtr* adr_type, outputStream *st); >>>>>>>>>> >>>>>>>>>> Roland. >>>>>>>>>> >>>>>>>>>>> On Sep 22, 2015, at 9:43 AM, Roland Westrelin wrote: >>>>>>>>>>> >>>>>>>>>>>> Roland I had a look too, the code looks good. >>>>>>>>>>> >>>>>>>>>>> Thanks, Michael. >>>>>>>>>>> >>>>>>>>>>> Roland. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -Michael >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Roland Westrelin >>>>>>>>>>>> Sent: Monday, September 21, 2015 2:03 AM >>>>>>>>>>>> To: hotspot compiler >>>>>>>>>>>> Subject: Re: RFR(S): 8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI >>>>>>>>>>>> >>>>>>>>>>>> Thanks for the review, Vladimir. >>>>>>>>>>>> >>>>>>>>>>>> Roland. >>>>>>>>>>>> >>>>>>>>>>>>> On Sep 21, 2015, at 3:32 AM, Vladimir Kozlov wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> This is good. Thank you for extending the test. >>>>>>>>>>>>> >>>>>>>>>>>>> Vladimir >>>>>>>>>>>>> >>>>>>>>>>>>> On 9/18/15 11:03 PM, Roland Westrelin wrote: >>>>>>>>>>>>>>>>> Hmm, so you just relaxed the assert. You may need to fix EA too because it also checks for matching types(memory sizes). >>>>>>>>>>>>>>>>> I remember we had problem with RAW accesses back when jsr292 was implemented. So EA gave up on RAW access and marks allocations as escaping. Also may be superword/vectorization will be affected. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In general it is very bad for C2 to have different memory on the same non-RAW memory. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It already happens with vectorization. Do you see another solution (rather than relaxing the assert)? Putting a MemBarCPUOrder before and after the unaligned store? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> MemBarCPUOrder are definitely will help and it is simplest solution but, I think, it is too drastic. >>>>>>>>>>>>>>> It affect control flow and other memory slices. >>>>>>>>>>>>>>> We can try to mark such memory accesses or/and mark objects which have such accesses (if it is possible) and prevent vectorization and scalarization for them only. We should be able execute optimization on other memory slices then. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Here is a new change: >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~roland/8136473/webrev.01/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Unaligned accesses are explicitly marked as such. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I added a test case with a non escaping allocation and it works fine. I also added test case with vectorization and if the accesses are effectively unaligned vectorization doesn't happen. One of the test cases causes an assertion to fire when the allocation is expanded: the logic in InitializeNode::complete_stores() is confused by the unaligned store so I made sure unaligned stores are not captured by the initialization. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Roland. >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> From martin.doerr at sap.com Tue Oct 20 09:02:10 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 20 Oct 2015 09:02:10 +0000 Subject: RFR(M) 8138894: C1: Support IRIW on weak memory platforms Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165672261F64@DEWDFEMB19C.global.corp.sap> Hi Christian, can I consider this change reviewed? You had a look at it in your reply to my email announcing the C1 PPC64 port. Your reply: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-October/019220.html Thanks, Martin From: Doerr, Martin Sent: Donnerstag, 8. Oktober 2015 23:47 To: 'hotspot compiler' Subject: RFR(M) 8138894: C1: Support IRIW on weak memory platforms Hi, Some time ago, we implemented support for ordering of "Independent Reads of Independent Writes" in the template interpreter and C2 Compiler for PPC64. However, it needs to be consistent with C1. Without "IRIW" support, we generate load-acquire for volatile loads and release-store-fence for volatile stores. With "IRIW" support, we generate fence-load-acquire for volatile loads and release-store for volatile stores. CPU_NOT_MULTIPLE_COPY_ATOMIC is currently only defined on PPC64 (though it may be interesting for aarch64 as well). This change is a prerequisite for our C1 on PPC64 contribution. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8138894_c1_IRIW/webrev.00 Please review this change. I need a sponsor, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Tue Oct 20 09:05:52 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 20 Oct 2015 09:05:52 +0000 Subject: RFR(M) 8138895: C1: PPC64 Port needs special register for Locks in synchronization code Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165672261F7D@DEWDFEMB19C.global.corp.sap> Hi Christian, can I consider this change reviewed? You had a look at it in your reply to my email announcing the C1 PPC64 port. Your reply: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-October/019220.html I'm writing separate mails to get a confirmation in each mail thread. Thanks, Martin From: Doerr, Martin Sent: Donnerstag, 8. Oktober 2015 23:49 To: 'hotspot compiler' Subject: RFR(M) 8138895: C1: PPC64 Port needs special register for Locks in synchronization code Hi, This change introduces syncLockOpr like the existing syncTempOpr. Other platforms than PPC64 just return a new register so it's no functional change there. This change is a prerequisite for our C1 on PPC64 contribution. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8138895_c1_syncLockOpr/webrev.00 Implementation for aarch64 is included but not tested. Please review this change. I need a sponsor, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Tue Oct 20 16:36:53 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 20 Oct 2015 06:36:53 -1000 Subject: RFR(M) 8138894: C1: Support IRIW on weak memory platforms In-Reply-To: <7C9B87B351A4BA4AA9EC95BB4181165672261F64@DEWDFEMB19C.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB4181165672261F64@DEWDFEMB19C.global.corp.sap> Message-ID: > On Oct 19, 2015, at 11:02 PM, Doerr, Martin wrote: > > Hi Christian, > > can I consider this change reviewed? Yes. > You had a look at it in your reply to my email announcing the C1 PPC64 port. Your reply: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-October/019220.html > > Thanks, > Martin > > > From: Doerr, Martin > Sent: Donnerstag, 8. Oktober 2015 23:47 > To: 'hotspot compiler' > Subject: RFR(M) 8138894: C1: Support IRIW on weak memory platforms > > Hi, > > Some time ago, we implemented support for ordering of "Independent Reads of Independent Writes" in the template interpreter and C2 Compiler for PPC64. However, it needs to be consistent with C1. > > Without "IRIW" support, we generate load-acquire for volatile loads and release-store-fence for volatile stores. > With "IRIW" support, we generate fence-load-acquire for volatile loads and release-store for volatile stores. > CPU_NOT_MULTIPLE_COPY_ATOMIC is currently only defined on PPC64 (though it may be interesting for aarch64 as well). > This change is a prerequisite for our C1 on PPC64 contribution. > > Webrev is here: > http://cr.openjdk.java.net/~mdoerr/8138894_c1_IRIW/webrev.00 > > Please review this change. I need a sponsor, please. > > Best regards, > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.civlin at intel.com Tue Oct 20 16:46:31 2015 From: jan.civlin at intel.com (Civlin, Jan) Date: Tue, 20 Oct 2015 16:46:31 +0000 Subject: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. In-Reply-To: <562081A9.9070008@oracle.com> References: <39F83597C33E5F408096702907E6C45005879107@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C450058791D0@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C45005879240@ORSMSX104.amr.corp.intel.com> <561E2097.8060907@oracle.com> <39F83597C33E5F408096702907E6C450058797EF@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C45005879A67@ORSMSX104.amr.corp.intel.com> <562081A9.9070008@oracle.com> Message-ID: <39F83597C33E5F408096702907E6C4500587A13F@ORSMSX104.amr.corp.intel.com> Vladimir, Here is the updated patch with the straight "&& (vopc != Op_CMoveD || vlen == 4);" in VectorNode::implemented. Please take a look and review. http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.03/ Thank you, Jan. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Thursday, October 15, 2015 9:49 PM To: Civlin, Jan Cc: hotspot compiler; Berg, Michael C Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. On 10/16/15 9:12 AM, Civlin, Jan wrote: > Vladimir, > > Michael Berg is about to add this new function for filtering based on vlen, so I use it now for my case and Michael will add more cases soon. > > const bool Matcher::match_rule_supported_vlen(int opcode, int vlen) For your changes I would simple add next to the check in VectorNode::implemented(): && (vopc != Op_CMoveD || vlen == 4); For changes which Michael is working on, you have to add it to all platforms .ad (same as match_rule_supported()). I would suggest to have match_rule_supported_vector(int opcode, int vlen) which you will call from VectorNode::implemented() instead of match_rule_supported(). And move all current vector opcodes check in match_rule_supported() to new one. Thanks, Vladimir > > > The updated webrev is here: > > http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.02/ > > > Thank you, > > Jan. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, October 14, 2015 2:30 AM > To: Civlin, Jan > Cc: hotspot compiler > Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. > > I said before that condition in .ad file in Matcher::match_rule_supported(): > > case Op_CMoveVD: > if (UseAVX > 2) <<<<< (UseAVX < 1 || UseAVX > 2) > ret_value = false; > > should match predicates: > > predicate(UseAVX > 0 && UseAVX < 3 && n->as_Vector()->length() == 4); > > Also why only length 4? There is no length 2? I don't see any code in superword.cpp which limits size of CMoveVD vector. > > Otherwise it seems fine. > > Thanks, > Vladimir > > On 10/14/15 1:57 AM, Civlin, Jan wrote: >> Vladimir, >> >> the updated webrev is at >> >> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.01/ >> >> Thank you, Igor. >> >> Best, >> >> Jan. >> >> -----Original Message----- >> From: Igor Veresov [mailto:igor.veresov at oracle.com] >> Sent: Tuesday, October 13, 2015 10:51 AM >> To: Civlin, Jan >> Cc: Vladimir Kozlov >> Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >> >> Done. >> >>> On Oct 13, 2015, at 9:51 AM, Civlin, Jan wrote: >>> >>> Igor, >>> >>> I got a response from the moderator that the previous message (attached below) has been rejected due to the size limits. >>> Please upload the attached webrev (I guess it will be >>> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.01/) >>> >>> And I'll send the link to the group. >>> >>> Thank you, >>> >>> Jan. >>> >>> -----Original Message----- >>> From: Civlin, Jan >>> Sent: Monday, October 12, 2015 10:19 PM >>> To: Vladimir Kozlov >>> Cc: Igor Veresov; hotspot compiler; Civlin, Jan >>> Subject: RE: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >>> >>> Vladimir, >>> >>> Here is a webrev built from a single changeset. >>> Please use it for further reviewing. >>> >>> Thank you, >>> >>> Jan. >>> >>> -----Original Message----- >>> From: Civlin, Jan >>> Sent: Saturday, October 10, 2015 12:14 PM >>> To: Vladimir Kozlov >>> Cc: hotspot compiler >>> Subject: RE: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >>> >>> Vladimir, >>> >>> Thank you for the quick review. >>> >>> >>> I thought you are patching your repo using hotspot.patch which is clean of empty files or .hgtag and you use webrev only for facilitation of visual code review. >>> If you use hotspot.patch it does not propagate to your repo empty or already integrated in 8136725 files or my repo tags, since none of them are in the patch. >>> I thought you are simply skipping unchanged files if you see them in webrev html pages. >>> >>> My repo is a consistent and long living clone of your repo. It is a single place that includes the history of all my changes, which let me go ahead in development way far of what is ready for going out to you. I can create an additional repo and filter out my tags on way out, but it will create more possibilities for accidental errors. >>> >>> >>> x86.ad: it is indeed not (yet) AVX3, since AVX3 will have different ISA. Once we have AVX3 in the house and can debug it, AVX3 case will be added. >>> >>> c2_globals.hpp: >>> I will rename the flag to UseCMoveUnconditionally, but I see no point of having another flag for the vector: once SuperWord detects CMovD, it merely vectorize it. >>> In the opposite direction: one cannot ask for vectorization of CMovD and not to get them in the scalar case. >>> >>> compile.cpp: >>> 1114: will add "do_vector_loop() &&" and change to NOT_PRODUCT(if >>> (do_vector_loop() && Verbose&& && has_method()) >>> {tty->print("Compile::Init: use CMove without profitability tests >>> for method %s\n", method()->name()->as_quoted_ascii());}) >>> >>> loopopts.cpp: >>> 601: will add "&& cmp_op == Op_CmpD" and change to if >>> (C->use_cmove() && cmp_op == Op_CmpD) ;//keep going >>> >>> >>> Thank you, >>> >>> Jan >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Saturday, October 10, 2015 5:52 AM >>> To: Civlin, Jan >>> Cc: hotspot compiler >>> Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >>> >>> Changes contains also 8136725 (loop reserve copy) changes. Please, clean up. >>> >>> x86.ad WAIT! According to next conditions (BTW, support condition should match predicate) this is only supported with AVX1 and AVX2 and not AVX3. Really? >>> >>> I think it should be reversed condition (< 3): >>> + case Op_CMoveVD: >>> + if (UseAVX > 2) >>> + ret_value = false; >>> >>> + instruct vcmov4D_reg(vecY dst, vecY src1, vecY src2, immI8 cop, >>> cmpOp_vcmppd copnd) %{ >>> + predicate(UseAVX > 0 && UseAVX < 3 && n->as_Vector()->length() >>> + == 4); >>> >>> >>> x86_64.ad changes are empty (could be only spacing change) so remove it from change. >>> >>> c2_globals.hpp DoReserveCopyInSuperWord is defined in 8136725 changes. >>> UseCMov should be UseCMoveUnconditionally I think (note 'move' >>> instead of 'mov'). Also I am not sure that you should mix 2 things >>> into this >>> changes: one is vectorizing cmoveD (for doubles) and always generate cmoves. I think it is different issues and this change should concentrate on vectorizing only double cmoves. Then flag could be VectorizeCMoveD. >>> >>> compile.cpp print not under UseCmov flag: >>> + NOT_PRODUCT(if (Verbose && has_method()) {tty->print("Compile::Init: >>> use CMove without profitability tests for method %s\n", >>> method()->name()->as_quoted_ascii());}) >>> >>> loopopts.cpp changes inconsistent. In one place you check use_cmove only for doubles and in other for all. >>> >>> I will look on superword changes after you cleanup changes: remove >>> 8136725 and also create history from fresh repo - I don't want to see 50 revisions descriptions in webrev. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/10/15 7:04 AM, Civlin, Jan wrote: >>>> Please review this patch. >>>> >>>> Hi All, >>>> >>>> >>>> We would like to contribute the SuperWord enhancement to >>>> support vector conditional move (CMovVD ) on Intel AVX cpu. >>>> >>>> >>>> The contribution Bug ID: 8139340. >>>> >>>> Please review this patch: >>>> >>>> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8139340 >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ >>>> >>>> Description: >>>> >>>> SuperWord enhancement to support vector conditional move (CMovVD) >>>> on Intel AVX cpu. >>>> >>>> The SuperWord optimization bails out on counted loops that contain >>>> any conditional statement other than the loop exit, and this >>>> prevents vectorization of many compute bound loops. >>>> >>>> The proposed enhancement enables generation of CMovD on demand >>>> (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD ) >>>> in SuperWord optimization. >>>> >>>> The performance gain observed on a simplified Monte Carlo Option >>>> Calculation was up to 2x speed-up. >>>> >>>> Thank you, >>>> >>>> Jan. >>>> >>>> *From:*Igor Veresov [mailto:igor.veresov at oracle.com] >>>> *Sent:* Friday, October 9, 2015 3:22 PM >>>> *To:* Civlin, Jan >>>> *Cc:* hotspot compiler; Vladimir Kozlov >>>> *Subject:* Re: SuperWord enhancement to support vector conditional >>>> move (CMovVD ) on Intel AVX cpu. >>>> >>>> Here it is: https://bugs.openjdk.java.net/browse/JDK-8139340 >>>> >>>> igor >>>> >>>> On Oct 9, 2015, at 2:57 PM, Civlin, Jan >>> > wrote: >>>> >>>> Thank you, Igor. >>>> >>>> What is the RFR for this? >>>> >>>> *From:*Igor Veresov [mailto:igor.veresov at oracle.com] >>>> *Sent:*Friday, October 9, 2015 2:53 PM >>>> *To:*Civlin, Jan >>>> *Cc:*hotspot compiler; Vladimir Kozlov >>>> *Subject:*Re: SuperWord enhancement to support vector conditional >>>> move (CMovVD ) on Intel AVX cpu. >>>> >>>> Here the webrev: >>>> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ >>>> >>>> igor >>>> >>>> On Oct 9, 2015, at 1:15 PM, Civlin, Jan >>> > wrote: >>>> >>>> Igor, >>>> >>>> Please create RFR and upload this patch. You may need to rename >>>> ancnav.js.remove_this_extention back to ancnav.js (I have to >>>> rename it for passing the mail server filters). >>>> >>>> Description: >>>> >>>> SuperWord enhancement to support vector conditional move >>>> (CMovVD) on Intel AVX cpu. >>>> >>>> The SuperWord optimization bails out on counted loops that >>>> contain any conditional statement other than the loop exit, and >>>> this prevents vectorization of many compute bound loops. >>>> >>>> The proposed enhancement enables generation of CMovD on demand >>>> (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD >>>> ) in SuperWord optimization. >>>> >>>> The performance gain observed on a simplified Monte Carlo Option >>>> Calculation was up to 2x speed-up. >>>> >>>> Thank you, >>>> >>>> Jan. >>>> >>>> >>>> >>> >> From christian.thalinger at oracle.com Tue Oct 20 20:19:41 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 20 Oct 2015 10:19:41 -1000 Subject: RFR (XXS): 8139935: Bootcycle builds are broken on jdk9/hs due to JVMCI changes Message-ID: https://bugs.openjdk.java.net/browse/JDK-8139935 The reason this ?works? for a non-bootcycle build is because a JDK 9 javac won't enforce the ?hidden packages? rules when running on a non-JDK 9 platform. diff -r a8a8604f890f make/gensrc/Gensrc-jdk.vm.ci.gmk --- a/make/gensrc/Gensrc-jdk.vm.ci.gmk Sat Oct 17 19:40:30 2015 -0400 +++ b/make/gensrc/Gensrc-jdk.vm.ci.gmk Tue Oct 20 09:57:02 2015 -1000 @@ -77,6 +77,7 @@ PROCESSOR_PATH := $(call PathList, \ $(MKDIR) -p $(@D) $(eval $(call ListPathsSafely,PROC_SRCS,$(@D)/_gensrc_proc_files)) $(JAVA_SMALL) $(NEW_JAVAC) \ + -XDignore.symbol.file \ -sourcepath $(SOURCEPATH) \ -implicit:none \ -proc:only \ -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Tue Oct 20 23:58:25 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 20 Oct 2015 13:58:25 -1000 Subject: RFR(M) 8138892: C1: Improve counter overflow checking In-Reply-To: <4295855A5C1DE049A61835A1887419CC41E81D63@DEWDFEMB12A.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB4181165672260C97@DEWDFEMB19C.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41E81D63@DEWDFEMB12A.global.corp.sap> Message-ID: <74584B20-982F-4FA5-A863-85663DDD8F2F@oracle.com> Sorry, I?m pretty busy but I will try to sponsor this. > On Oct 11, 2015, at 10:58 PM, Lindenmaier, Goetz wrote: > > Hi Martin, > > this change looks good, thank you. > > Could someone please sponsor this? > > Best regards, > Goetz. > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net]On Behalf Of Doerr, Martin > Sent: Mittwoch, 7. Oktober 2015 23:02 > To: hotspot compiler; Andrew Haley (aph at redhat.com) > Subject: RFR(M) 8138892: C1: Improve counter overflow checking > > Hi, > > C1 currently loads the Method pointer in the fast path even though it is only required in the overflow case. In addition, stupid code gets generated when the frequency is set to 0 which occurs with -Xcomp. > > The following webrev optimizes that: > http://cr.openjdk.java.net/~mdoerr/8138892_c1_counter_overflow/webrev.02 > > It?s not tested on aarch64. > > Please review this change. I need a sponsor, please. > > Best regards, > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Wed Oct 21 00:01:14 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 20 Oct 2015 14:01:14 -1000 Subject: RFR(M) 8138892: C1: Improve counter overflow checking In-Reply-To: <74584B20-982F-4FA5-A863-85663DDD8F2F@oracle.com> References: <7C9B87B351A4BA4AA9EC95BB4181165672260C97@DEWDFEMB19C.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41E81D63@DEWDFEMB12A.global.corp.sap> <74584B20-982F-4FA5-A863-85663DDD8F2F@oracle.com> Message-ID: <890C84B6-8FAF-4D2A-9277-777E372361CB@oracle.com> Btw. it would help if you could export a changeset with the correct commit message and send it as attachment to the list. > On Oct 20, 2015, at 1:58 PM, Christian Thalinger wrote: > > Sorry, I?m pretty busy but I will try to sponsor this. > >> On Oct 11, 2015, at 10:58 PM, Lindenmaier, Goetz > wrote: >> >> Hi Martin, >> >> this change looks good, thank you. >> >> Could someone please sponsor this? >> >> Best regards, >> Goetz. >> >> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net ]On Behalf Of Doerr, Martin >> Sent: Mittwoch, 7. Oktober 2015 23:02 >> To: hotspot compiler; Andrew Haley (aph at redhat.com ) >> Subject: RFR(M) 8138892: C1: Improve counter overflow checking >> >> Hi, >> >> C1 currently loads the Method pointer in the fast path even though it is only required in the overflow case. In addition, stupid code gets generated when the frequency is set to 0 which occurs with -Xcomp. >> >> The following webrev optimizes that: >> http://cr.openjdk.java.net/~mdoerr/8138892_c1_counter_overflow/webrev.02 >> >> It?s not tested on aarch64. >> >> Please review this change. I need a sponsor, please. >> >> Best regards, >> Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Wed Oct 21 00:03:31 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 20 Oct 2015 14:03:31 -1000 Subject: RFR(M) 8138892: C1: Improve counter overflow checking In-Reply-To: <890C84B6-8FAF-4D2A-9277-777E372361CB@oracle.com> References: <7C9B87B351A4BA4AA9EC95BB4181165672260C97@DEWDFEMB19C.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41E81D63@DEWDFEMB12A.global.corp.sap> <74584B20-982F-4FA5-A863-85663DDD8F2F@oracle.com> <890C84B6-8FAF-4D2A-9277-777E372361CB@oracle.com> Message-ID: <80643179-9E06-4E68-82AF-3A2FFAE5A6E8@oracle.com> > On Oct 20, 2015, at 2:01 PM, Christian Thalinger wrote: > > Btw. it would help if you could export a changeset with the correct commit message and send it as attachment to the list. Even better, attach it to the JIRA issue. > >> On Oct 20, 2015, at 1:58 PM, Christian Thalinger > wrote: >> >> Sorry, I?m pretty busy but I will try to sponsor this. >> >>> On Oct 11, 2015, at 10:58 PM, Lindenmaier, Goetz > wrote: >>> >>> Hi Martin, >>> >>> this change looks good, thank you. >>> >>> Could someone please sponsor this? >>> >>> Best regards, >>> Goetz. >>> >>> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net ]On Behalf Of Doerr, Martin >>> Sent: Mittwoch, 7. Oktober 2015 23:02 >>> To: hotspot compiler; Andrew Haley (aph at redhat.com ) >>> Subject: RFR(M) 8138892: C1: Improve counter overflow checking >>> >>> Hi, >>> >>> C1 currently loads the Method pointer in the fast path even though it is only required in the overflow case. In addition, stupid code gets generated when the frequency is set to 0 which occurs with -Xcomp. >>> >>> The following webrev optimizes that: >>> http://cr.openjdk.java.net/~mdoerr/8138892_c1_counter_overflow/webrev.02 >>> >>> It?s not tested on aarch64. >>> >>> Please review this change. I need a sponsor, please. >>> >>> Best regards, >>> Martin >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed Oct 21 00:37:40 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 21 Oct 2015 08:37:40 +0800 Subject: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. In-Reply-To: <39F83597C33E5F408096702907E6C4500587A13F@ORSMSX104.amr.corp.intel.com> References: <39F83597C33E5F408096702907E6C45005879107@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C450058791D0@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C45005879240@ORSMSX104.amr.corp.intel.com> <561E2097.8060907@oracle.com> <39F83597C33E5F408096702907E6C450058797EF@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C45005879A67@ORSMSX104.amr.corp.intel.com> <562081A9.9070008@oracle.com> <39F83597C33E5F408096702907E6C4500587A13F@ORSMSX104.amr.corp.intel.com> Message-ID: <5626DE54.7050301@oracle.com> Okay, it looks good. Thanks, Vladimir On 10/21/15 12:46 AM, Civlin, Jan wrote: > Vladimir, > > Here is the updated patch with the straight "&& (vopc != Op_CMoveD || vlen == 4);" in VectorNode::implemented. > > Please take a look and review. > > http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.03/ > > > Thank you, > > Jan. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, October 15, 2015 9:49 PM > To: Civlin, Jan > Cc: hotspot compiler; Berg, Michael C > Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. > > On 10/16/15 9:12 AM, Civlin, Jan wrote: >> Vladimir, >> >> Michael Berg is about to add this new function for filtering based on vlen, so I use it now for my case and Michael will add more cases soon. >> >> const bool Matcher::match_rule_supported_vlen(int opcode, int vlen) > > For your changes I would simple add next to the check in > VectorNode::implemented(): > > && (vopc != Op_CMoveD || vlen == 4); > > For changes which Michael is working on, you have to add it to all platforms .ad (same as match_rule_supported()). > > I would suggest to have match_rule_supported_vector(int opcode, int > vlen) which you will call from VectorNode::implemented() instead of match_rule_supported(). And move all current vector opcodes check in > match_rule_supported() to new one. > > Thanks, > Vladimir > >> >> >> The updated webrev is here: >> >> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.02/ >> >> >> Thank you, >> >> Jan. >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Wednesday, October 14, 2015 2:30 AM >> To: Civlin, Jan >> Cc: hotspot compiler >> Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >> >> I said before that condition in .ad file in Matcher::match_rule_supported(): >> >> case Op_CMoveVD: >> if (UseAVX > 2) <<<<< (UseAVX < 1 || UseAVX > 2) >> ret_value = false; >> >> should match predicates: >> >> predicate(UseAVX > 0 && UseAVX < 3 && n->as_Vector()->length() == 4); >> >> Also why only length 4? There is no length 2? I don't see any code in superword.cpp which limits size of CMoveVD vector. >> >> Otherwise it seems fine. >> >> Thanks, >> Vladimir >> >> On 10/14/15 1:57 AM, Civlin, Jan wrote: >>> Vladimir, >>> >>> the updated webrev is at >>> >>> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.01/ >>> >>> Thank you, Igor. >>> >>> Best, >>> >>> Jan. >>> >>> -----Original Message----- >>> From: Igor Veresov [mailto:igor.veresov at oracle.com] >>> Sent: Tuesday, October 13, 2015 10:51 AM >>> To: Civlin, Jan >>> Cc: Vladimir Kozlov >>> Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >>> >>> Done. >>> >>>> On Oct 13, 2015, at 9:51 AM, Civlin, Jan wrote: >>>> >>>> Igor, >>>> >>>> I got a response from the moderator that the previous message (attached below) has been rejected due to the size limits. >>>> Please upload the attached webrev (I guess it will be >>>> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.01/) >>>> >>>> And I'll send the link to the group. >>>> >>>> Thank you, >>>> >>>> Jan. >>>> >>>> -----Original Message----- >>>> From: Civlin, Jan >>>> Sent: Monday, October 12, 2015 10:19 PM >>>> To: Vladimir Kozlov >>>> Cc: Igor Veresov; hotspot compiler; Civlin, Jan >>>> Subject: RE: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >>>> >>>> Vladimir, >>>> >>>> Here is a webrev built from a single changeset. >>>> Please use it for further reviewing. >>>> >>>> Thank you, >>>> >>>> Jan. >>>> >>>> -----Original Message----- >>>> From: Civlin, Jan >>>> Sent: Saturday, October 10, 2015 12:14 PM >>>> To: Vladimir Kozlov >>>> Cc: hotspot compiler >>>> Subject: RE: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >>>> >>>> Vladimir, >>>> >>>> Thank you for the quick review. >>>> >>>> >>>> I thought you are patching your repo using hotspot.patch which is clean of empty files or .hgtag and you use webrev only for facilitation of visual code review. >>>> If you use hotspot.patch it does not propagate to your repo empty or already integrated in 8136725 files or my repo tags, since none of them are in the patch. >>>> I thought you are simply skipping unchanged files if you see them in webrev html pages. >>>> >>>> My repo is a consistent and long living clone of your repo. It is a single place that includes the history of all my changes, which let me go ahead in development way far of what is ready for going out to you. I can create an additional repo and filter out my tags on way out, but it will create more possibilities for accidental errors. >>>> >>>> >>>> x86.ad: it is indeed not (yet) AVX3, since AVX3 will have different ISA. Once we have AVX3 in the house and can debug it, AVX3 case will be added. >>>> >>>> c2_globals.hpp: >>>> I will rename the flag to UseCMoveUnconditionally, but I see no point of having another flag for the vector: once SuperWord detects CMovD, it merely vectorize it. >>>> In the opposite direction: one cannot ask for vectorization of CMovD and not to get them in the scalar case. >>>> >>>> compile.cpp: >>>> 1114: will add "do_vector_loop() &&" and change to NOT_PRODUCT(if >>>> (do_vector_loop() && Verbose&& && has_method()) >>>> {tty->print("Compile::Init: use CMove without profitability tests >>>> for method %s\n", method()->name()->as_quoted_ascii());}) >>>> >>>> loopopts.cpp: >>>> 601: will add "&& cmp_op == Op_CmpD" and change to if >>>> (C->use_cmove() && cmp_op == Op_CmpD) ;//keep going >>>> >>>> >>>> Thank you, >>>> >>>> Jan >>>> >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Saturday, October 10, 2015 5:52 AM >>>> To: Civlin, Jan >>>> Cc: hotspot compiler >>>> Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >>>> >>>> Changes contains also 8136725 (loop reserve copy) changes. Please, clean up. >>>> >>>> x86.ad WAIT! According to next conditions (BTW, support condition should match predicate) this is only supported with AVX1 and AVX2 and not AVX3. Really? >>>> >>>> I think it should be reversed condition (< 3): >>>> + case Op_CMoveVD: >>>> + if (UseAVX > 2) >>>> + ret_value = false; >>>> >>>> + instruct vcmov4D_reg(vecY dst, vecY src1, vecY src2, immI8 cop, >>>> cmpOp_vcmppd copnd) %{ >>>> + predicate(UseAVX > 0 && UseAVX < 3 && n->as_Vector()->length() >>>> + == 4); >>>> >>>> >>>> x86_64.ad changes are empty (could be only spacing change) so remove it from change. >>>> >>>> c2_globals.hpp DoReserveCopyInSuperWord is defined in 8136725 changes. >>>> UseCMov should be UseCMoveUnconditionally I think (note 'move' >>>> instead of 'mov'). Also I am not sure that you should mix 2 things >>>> into this >>>> changes: one is vectorizing cmoveD (for doubles) and always generate cmoves. I think it is different issues and this change should concentrate on vectorizing only double cmoves. Then flag could be VectorizeCMoveD. >>>> >>>> compile.cpp print not under UseCmov flag: >>>> + NOT_PRODUCT(if (Verbose && has_method()) {tty->print("Compile::Init: >>>> use CMove without profitability tests for method %s\n", >>>> method()->name()->as_quoted_ascii());}) >>>> >>>> loopopts.cpp changes inconsistent. In one place you check use_cmove only for doubles and in other for all. >>>> >>>> I will look on superword changes after you cleanup changes: remove >>>> 8136725 and also create history from fresh repo - I don't want to see 50 revisions descriptions in webrev. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/10/15 7:04 AM, Civlin, Jan wrote: >>>>> Please review this patch. >>>>> >>>>> Hi All, >>>>> >>>>> >>>>> We would like to contribute the SuperWord enhancement to >>>>> support vector conditional move (CMovVD ) on Intel AVX cpu. >>>>> >>>>> >>>>> The contribution Bug ID: 8139340. >>>>> >>>>> Please review this patch: >>>>> >>>>> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8139340 >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ >>>>> >>>>> Description: >>>>> >>>>> SuperWord enhancement to support vector conditional move (CMovVD) >>>>> on Intel AVX cpu. >>>>> >>>>> The SuperWord optimization bails out on counted loops that contain >>>>> any conditional statement other than the loop exit, and this >>>>> prevents vectorization of many compute bound loops. >>>>> >>>>> The proposed enhancement enables generation of CMovD on demand >>>>> (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD ) >>>>> in SuperWord optimization. >>>>> >>>>> The performance gain observed on a simplified Monte Carlo Option >>>>> Calculation was up to 2x speed-up. >>>>> >>>>> Thank you, >>>>> >>>>> Jan. >>>>> >>>>> *From:*Igor Veresov [mailto:igor.veresov at oracle.com] >>>>> *Sent:* Friday, October 9, 2015 3:22 PM >>>>> *To:* Civlin, Jan >>>>> *Cc:* hotspot compiler; Vladimir Kozlov >>>>> *Subject:* Re: SuperWord enhancement to support vector conditional >>>>> move (CMovVD ) on Intel AVX cpu. >>>>> >>>>> Here it is: https://bugs.openjdk.java.net/browse/JDK-8139340 >>>>> >>>>> igor >>>>> >>>>> On Oct 9, 2015, at 2:57 PM, Civlin, Jan >>>> > wrote: >>>>> >>>>> Thank you, Igor. >>>>> >>>>> What is the RFR for this? >>>>> >>>>> *From:*Igor Veresov [mailto:igor.veresov at oracle.com] >>>>> *Sent:*Friday, October 9, 2015 2:53 PM >>>>> *To:*Civlin, Jan >>>>> *Cc:*hotspot compiler; Vladimir Kozlov >>>>> *Subject:*Re: SuperWord enhancement to support vector conditional >>>>> move (CMovVD ) on Intel AVX cpu. >>>>> >>>>> Here the webrev: >>>>> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ >>>>> >>>>> igor >>>>> >>>>> On Oct 9, 2015, at 1:15 PM, Civlin, Jan >>>> > wrote: >>>>> >>>>> Igor, >>>>> >>>>> Please create RFR and upload this patch. You may need to rename >>>>> ancnav.js.remove_this_extention back to ancnav.js (I have to >>>>> rename it for passing the mail server filters). >>>>> >>>>> Description: >>>>> >>>>> SuperWord enhancement to support vector conditional move >>>>> (CMovVD) on Intel AVX cpu. >>>>> >>>>> The SuperWord optimization bails out on counted loops that >>>>> contain any conditional statement other than the loop exit, and >>>>> this prevents vectorization of many compute bound loops. >>>>> >>>>> The proposed enhancement enables generation of CMovD on demand >>>>> (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD >>>>> ) in SuperWord optimization. >>>>> >>>>> The performance gain observed on a simplified Monte Carlo Option >>>>> Calculation was up to 2x speed-up. >>>>> >>>>> Thank you, >>>>> >>>>> Jan. >>>>> >>>>> >>>>> >>>> >>> From jan.civlin at intel.com Wed Oct 21 00:43:29 2015 From: jan.civlin at intel.com (Civlin, Jan) Date: Wed, 21 Oct 2015 00:43:29 +0000 Subject: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. In-Reply-To: <5626DE54.7050301@oracle.com> References: <39F83597C33E5F408096702907E6C45005879107@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C450058791D0@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C45005879240@ORSMSX104.amr.corp.intel.com> <561E2097.8060907@oracle.com> <39F83597C33E5F408096702907E6C450058797EF@ORSMSX104.amr.corp.intel.com> <39F83597C33E5F408096702907E6C45005879A67@ORSMSX104.amr.corp.intel.com> <562081A9.9070008@oracle.com> <39F83597C33E5F408096702907E6C4500587A13F@ORSMSX104.amr.corp.intel.com> <5626DE54.7050301@oracle.com> Message-ID: <39F83597C33E5F408096702907E6C4500587A344@ORSMSX104.amr.corp.intel.com> Thank you, Vladimir. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Tuesday, October 20, 2015 5:38 PM To: Civlin, Jan Cc: hotspot compiler Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. Okay, it looks good. Thanks, Vladimir On 10/21/15 12:46 AM, Civlin, Jan wrote: > Vladimir, > > Here is the updated patch with the straight "&& (vopc != Op_CMoveD || vlen == 4);" in VectorNode::implemented. > > Please take a look and review. > > http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.03/ > > > Thank you, > > Jan. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, October 15, 2015 9:49 PM > To: Civlin, Jan > Cc: hotspot compiler; Berg, Michael C > Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. > > On 10/16/15 9:12 AM, Civlin, Jan wrote: >> Vladimir, >> >> Michael Berg is about to add this new function for filtering based on vlen, so I use it now for my case and Michael will add more cases soon. >> >> const bool Matcher::match_rule_supported_vlen(int opcode, int vlen) > > For your changes I would simple add next to the check in > VectorNode::implemented(): > > && (vopc != Op_CMoveD || vlen == 4); > > For changes which Michael is working on, you have to add it to all platforms .ad (same as match_rule_supported()). > > I would suggest to have match_rule_supported_vector(int opcode, int > vlen) which you will call from VectorNode::implemented() instead of > match_rule_supported(). And move all current vector opcodes check in > match_rule_supported() to new one. > > Thanks, > Vladimir > >> >> >> The updated webrev is here: >> >> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.02/ >> >> >> Thank you, >> >> Jan. >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Wednesday, October 14, 2015 2:30 AM >> To: Civlin, Jan >> Cc: hotspot compiler >> Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >> >> I said before that condition in .ad file in Matcher::match_rule_supported(): >> >> case Op_CMoveVD: >> if (UseAVX > 2) <<<<< (UseAVX < 1 || UseAVX > 2) >> ret_value = false; >> >> should match predicates: >> >> predicate(UseAVX > 0 && UseAVX < 3 && n->as_Vector()->length() == 4); >> >> Also why only length 4? There is no length 2? I don't see any code in superword.cpp which limits size of CMoveVD vector. >> >> Otherwise it seems fine. >> >> Thanks, >> Vladimir >> >> On 10/14/15 1:57 AM, Civlin, Jan wrote: >>> Vladimir, >>> >>> the updated webrev is at >>> >>> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.01/ >>> >>> Thank you, Igor. >>> >>> Best, >>> >>> Jan. >>> >>> -----Original Message----- >>> From: Igor Veresov [mailto:igor.veresov at oracle.com] >>> Sent: Tuesday, October 13, 2015 10:51 AM >>> To: Civlin, Jan >>> Cc: Vladimir Kozlov >>> Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >>> >>> Done. >>> >>>> On Oct 13, 2015, at 9:51 AM, Civlin, Jan wrote: >>>> >>>> Igor, >>>> >>>> I got a response from the moderator that the previous message (attached below) has been rejected due to the size limits. >>>> Please upload the attached webrev (I guess it will be >>>> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.01/) >>>> >>>> And I'll send the link to the group. >>>> >>>> Thank you, >>>> >>>> Jan. >>>> >>>> -----Original Message----- >>>> From: Civlin, Jan >>>> Sent: Monday, October 12, 2015 10:19 PM >>>> To: Vladimir Kozlov >>>> Cc: Igor Veresov; hotspot compiler; Civlin, Jan >>>> Subject: RE: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >>>> >>>> Vladimir, >>>> >>>> Here is a webrev built from a single changeset. >>>> Please use it for further reviewing. >>>> >>>> Thank you, >>>> >>>> Jan. >>>> >>>> -----Original Message----- >>>> From: Civlin, Jan >>>> Sent: Saturday, October 10, 2015 12:14 PM >>>> To: Vladimir Kozlov >>>> Cc: hotspot compiler >>>> Subject: RE: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >>>> >>>> Vladimir, >>>> >>>> Thank you for the quick review. >>>> >>>> >>>> I thought you are patching your repo using hotspot.patch which is clean of empty files or .hgtag and you use webrev only for facilitation of visual code review. >>>> If you use hotspot.patch it does not propagate to your repo empty or already integrated in 8136725 files or my repo tags, since none of them are in the patch. >>>> I thought you are simply skipping unchanged files if you see them in webrev html pages. >>>> >>>> My repo is a consistent and long living clone of your repo. It is a single place that includes the history of all my changes, which let me go ahead in development way far of what is ready for going out to you. I can create an additional repo and filter out my tags on way out, but it will create more possibilities for accidental errors. >>>> >>>> >>>> x86.ad: it is indeed not (yet) AVX3, since AVX3 will have different ISA. Once we have AVX3 in the house and can debug it, AVX3 case will be added. >>>> >>>> c2_globals.hpp: >>>> I will rename the flag to UseCMoveUnconditionally, but I see no point of having another flag for the vector: once SuperWord detects CMovD, it merely vectorize it. >>>> In the opposite direction: one cannot ask for vectorization of CMovD and not to get them in the scalar case. >>>> >>>> compile.cpp: >>>> 1114: will add "do_vector_loop() &&" and change to NOT_PRODUCT(if >>>> (do_vector_loop() && Verbose&& && has_method()) >>>> {tty->print("Compile::Init: use CMove without profitability tests >>>> for method %s\n", method()->name()->as_quoted_ascii());}) >>>> >>>> loopopts.cpp: >>>> 601: will add "&& cmp_op == Op_CmpD" and change to if >>>> (C->use_cmove() && cmp_op == Op_CmpD) ;//keep going >>>> >>>> >>>> Thank you, >>>> >>>> Jan >>>> >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Saturday, October 10, 2015 5:52 AM >>>> To: Civlin, Jan >>>> Cc: hotspot compiler >>>> Subject: Re: RFR: 8139340: SuperWord enhancement to support vector conditional move (CMovVD ) on Intel AVX cpu. >>>> >>>> Changes contains also 8136725 (loop reserve copy) changes. Please, clean up. >>>> >>>> x86.ad WAIT! According to next conditions (BTW, support condition should match predicate) this is only supported with AVX1 and AVX2 and not AVX3. Really? >>>> >>>> I think it should be reversed condition (< 3): >>>> + case Op_CMoveVD: >>>> + if (UseAVX > 2) >>>> + ret_value = false; >>>> >>>> + instruct vcmov4D_reg(vecY dst, vecY src1, vecY src2, immI8 cop, >>>> cmpOp_vcmppd copnd) %{ >>>> + predicate(UseAVX > 0 && UseAVX < 3 && n->as_Vector()->length() >>>> + == 4); >>>> >>>> >>>> x86_64.ad changes are empty (could be only spacing change) so remove it from change. >>>> >>>> c2_globals.hpp DoReserveCopyInSuperWord is defined in 8136725 changes. >>>> UseCMov should be UseCMoveUnconditionally I think (note 'move' >>>> instead of 'mov'). Also I am not sure that you should mix 2 things >>>> into this >>>> changes: one is vectorizing cmoveD (for doubles) and always generate cmoves. I think it is different issues and this change should concentrate on vectorizing only double cmoves. Then flag could be VectorizeCMoveD. >>>> >>>> compile.cpp print not under UseCmov flag: >>>> + NOT_PRODUCT(if (Verbose && has_method()) {tty->print("Compile::Init: >>>> use CMove without profitability tests for method %s\n", >>>> method()->name()->as_quoted_ascii());}) >>>> >>>> loopopts.cpp changes inconsistent. In one place you check use_cmove only for doubles and in other for all. >>>> >>>> I will look on superword changes after you cleanup changes: remove >>>> 8136725 and also create history from fresh repo - I don't want to see 50 revisions descriptions in webrev. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/10/15 7:04 AM, Civlin, Jan wrote: >>>>> Please review this patch. >>>>> >>>>> Hi All, >>>>> >>>>> >>>>> We would like to contribute the SuperWord enhancement to >>>>> support vector conditional move (CMovVD ) on Intel AVX cpu. >>>>> >>>>> >>>>> The contribution Bug ID: 8139340. >>>>> >>>>> Please review this patch: >>>>> >>>>> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8139340 >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ >>>>> >>>>> Description: >>>>> >>>>> SuperWord enhancement to support vector conditional move (CMovVD) >>>>> on Intel AVX cpu. >>>>> >>>>> The SuperWord optimization bails out on counted loops that contain >>>>> any conditional statement other than the loop exit, and this >>>>> prevents vectorization of many compute bound loops. >>>>> >>>>> The proposed enhancement enables generation of CMovD on demand >>>>> (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD ) >>>>> in SuperWord optimization. >>>>> >>>>> The performance gain observed on a simplified Monte Carlo Option >>>>> Calculation was up to 2x speed-up. >>>>> >>>>> Thank you, >>>>> >>>>> Jan. >>>>> >>>>> *From:*Igor Veresov [mailto:igor.veresov at oracle.com] >>>>> *Sent:* Friday, October 9, 2015 3:22 PM >>>>> *To:* Civlin, Jan >>>>> *Cc:* hotspot compiler; Vladimir Kozlov >>>>> *Subject:* Re: SuperWord enhancement to support vector conditional >>>>> move (CMovVD ) on Intel AVX cpu. >>>>> >>>>> Here it is: https://bugs.openjdk.java.net/browse/JDK-8139340 >>>>> >>>>> igor >>>>> >>>>> On Oct 9, 2015, at 2:57 PM, Civlin, Jan >>>> > wrote: >>>>> >>>>> Thank you, Igor. >>>>> >>>>> What is the RFR for this? >>>>> >>>>> *From:*Igor Veresov [mailto:igor.veresov at oracle.com] >>>>> *Sent:*Friday, October 9, 2015 2:53 PM >>>>> *To:*Civlin, Jan >>>>> *Cc:*hotspot compiler; Vladimir Kozlov >>>>> *Subject:*Re: SuperWord enhancement to support vector conditional >>>>> move (CMovVD ) on Intel AVX cpu. >>>>> >>>>> Here the webrev: >>>>> http://cr.openjdk.java.net/~iveresov/vector-cmove/webrev.00/ >>>>> >>>>> igor >>>>> >>>>> On Oct 9, 2015, at 1:15 PM, Civlin, Jan >>>> > wrote: >>>>> >>>>> Igor, >>>>> >>>>> Please create RFR and upload this patch. You may need to rename >>>>> ancnav.js.remove_this_extention back to ancnav.js (I have to >>>>> rename it for passing the mail server filters). >>>>> >>>>> Description: >>>>> >>>>> SuperWord enhancement to support vector conditional move >>>>> (CMovVD) on Intel AVX cpu. >>>>> >>>>> The SuperWord optimization bails out on counted loops that >>>>> contain any conditional statement other than the loop exit, and >>>>> this prevents vectorization of many compute bound loops. >>>>> >>>>> The proposed enhancement enables generation of CMovD on demand >>>>> (-XX:+UseCMov), and further vectorization of CMovD (into CMovVD >>>>> ) in SuperWord optimization. >>>>> >>>>> The performance gain observed on a simplified Monte Carlo Option >>>>> Calculation was up to 2x speed-up. >>>>> >>>>> Thank you, >>>>> >>>>> Jan. >>>>> >>>>> >>>>> >>>> >>> From vladimir.kozlov at oracle.com Wed Oct 21 00:57:02 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 21 Oct 2015 08:57:02 +0800 Subject: hg: jdk9/hs-comp/hotspot: 8132168: Support IdealGraphVisualizer in optimized build In-Reply-To: <201510202247.t9KMlJF1011897@aojmv0008.oracle.com> References: <201510202247.t9KMlJF1011897@aojmv0008.oracle.com> Message-ID: <5626E2DE.9030405@oracle.com> Hi Vladimir I did not see updated webrev for these changes. The old one was only to add range: http://cr.openjdk.java.net/~vlivanov/8132168/webrev.00/ Changes are fine but we have to follow review process. Thanks, Vladimir K On 10/21/15 6:47 AM, vladimir.x.ivanov at oracle.com wrote: > Changeset: 1cd251540653 > Author: vlivanov > Date: 2015-10-20 19:22 +0300 > URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1cd251540653 > > 8132168: Support IdealGraphVisualizer in optimized build > Reviewed-by: kvn > > ! src/share/vm/opto/c2_globals.hpp > > Changeset: 03fa0a35a468 > Author: vlivanov > Date: 2015-10-20 22:03 +0000 > URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/03fa0a35a468 > > Merge > > ! src/share/vm/opto/c2_globals.hpp > From goetz.lindenmaier at sap.com Wed Oct 21 08:35:22 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 21 Oct 2015 08:35:22 +0000 Subject: 8138894: C1: Support IRIW on weak memory platforms In-Reply-To: <7C9B87B351A4BA4AA9EC95BB4181165672260EB1@DEWDFEMB19C.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB4181165672260EB1@DEWDFEMB19C.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC41E83A32@DEWDFEMB12A.global.corp.sap> Hi Martin, in c1_IR.hpp you have a cut&paste error: void set_wrote_volatile() { _wrote_final = true; } probably should set the new field _wrote_volatile. Besides that the change looks good. Reviewed. Best regards, Goetz. From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Doerr, Martin Sent: Donnerstag, 8. Oktober 2015 23:44 To: hotspot compiler Subject: 8138894: C1: Support IRIW on weak memory platforms Hi, Some time ago, we implemented support for ordering of "Independent Reads of Independent Writes" in the template interpreter and C2 Compiler for PPC64. However, it needs to be consistent with C1. Without "IRIW" support, we generate load-acquire for volatile loads and release-store-fence for volatile stores. With "IRIW" support, we generate fence-load-acquire for volatile loads and release-store for volatile stores. CPU_NOT_MULTIPLE_COPY_ATOMIC is currently only defined on PPC64 (though it may be interesting for aarch64 as well). This change is a prerequisite for our C1 on PPC64 contribution. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8138894_c1_IRIW/webrev.00 Please review this change. I need a sponsor, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Wed Oct 21 09:30:18 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 21 Oct 2015 09:30:18 +0000 Subject: 8138894: C1: Support IRIW on weak memory platforms In-Reply-To: <4295855A5C1DE049A61835A1887419CC41E83A32@DEWDFEMB12A.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB4181165672260EB1@DEWDFEMB19C.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41E83A32@DEWDFEMB12A.global.corp.sap> Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165672262174@DEWDFEMB19C.global.corp.sap> Hi, thanks for finding this and for the review. The new webrev is here: http://cr.openjdk.java.net/~mdoerr/8138894_c1_IRIW/webrev.01/ I have also attached this changeset to the bug in JIRA: http://cr.openjdk.java.net/~mdoerr/8138894_c1_IRIW/webrev.01/main-hotspot-xxx.changeset Best regards, Martin From: Lindenmaier, Goetz Sent: Mittwoch, 21. Oktober 2015 10:35 To: Doerr, Martin; hotspot compiler Subject: RE: 8138894: C1: Support IRIW on weak memory platforms Hi Martin, in c1_IR.hpp you have a cut&paste error: void set_wrote_volatile() { _wrote_final = true; } probably should set the new field _wrote_volatile. Besides that the change looks good. Reviewed. Best regards, Goetz. From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Doerr, Martin Sent: Donnerstag, 8. Oktober 2015 23:44 To: hotspot compiler Subject: 8138894: C1: Support IRIW on weak memory platforms Hi, Some time ago, we implemented support for ordering of "Independent Reads of Independent Writes" in the template interpreter and C2 Compiler for PPC64. However, it needs to be consistent with C1. Without "IRIW" support, we generate load-acquire for volatile loads and release-store-fence for volatile stores. With "IRIW" support, we generate fence-load-acquire for volatile loads and release-store for volatile stores. CPU_NOT_MULTIPLE_COPY_ATOMIC is currently only defined on PPC64 (though it may be interesting for aarch64 as well). This change is a prerequisite for our C1 on PPC64 contribution. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8138894_c1_IRIW/webrev.00 Please review this change. I need a sponsor, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Wed Oct 21 09:53:45 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 21 Oct 2015 09:53:45 +0000 Subject: RFR(M) 8138892: C1: Improve counter overflow checking In-Reply-To: <80643179-9E06-4E68-82AF-3A2FFAE5A6E8@oracle.com> References: <7C9B87B351A4BA4AA9EC95BB4181165672260C97@DEWDFEMB19C.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41E81D63@DEWDFEMB12A.global.corp.sap> <74584B20-982F-4FA5-A863-85663DDD8F2F@oracle.com> <890C84B6-8FAF-4D2A-9277-777E372361CB@oracle.com> <80643179-9E06-4E68-82AF-3A2FFAE5A6E8@oracle.com> Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165672262198@DEWDFEMB19C.global.corp.sap> Hi Christian, I have uploaded the final webrev and attached this changeset to the bug in JIRA: http://cr.openjdk.java.net/~mdoerr/8138892_c1_counter_overflow/webrev.03/main-hotspot-xxx.changeset It contains the reviewers. I have also attached a changeset with reviewers to the operator delete change: https://bugs.openjdk.java.net/browse/JDK-8138890 Best regards, Martin From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Christian Thalinger Sent: Mittwoch, 21. Oktober 2015 02:04 To: Lindenmaier, Goetz Cc: hotspot compiler Subject: Re: RFR(M) 8138892: C1: Improve counter overflow checking On Oct 20, 2015, at 2:01 PM, Christian Thalinger > wrote: Btw. it would help if you could export a changeset with the correct commit message and send it as attachment to the list. Even better, attach it to the JIRA issue. On Oct 20, 2015, at 1:58 PM, Christian Thalinger > wrote: Sorry, I?m pretty busy but I will try to sponsor this. On Oct 11, 2015, at 10:58 PM, Lindenmaier, Goetz > wrote: Hi Martin, this change looks good, thank you. Could someone please sponsor this? Best regards, Goetz. From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net]On Behalf Of Doerr, Martin Sent: Mittwoch, 7. Oktober 2015 23:02 To: hotspot compiler; Andrew Haley (aph at redhat.com) Subject: RFR(M) 8138892: C1: Improve counter overflow checking Hi, C1 currently loads the Method pointer in the fast path even though it is only required in the overflow case. In addition, stupid code gets generated when the frequency is set to 0 which occurs with -Xcomp. The following webrev optimizes that: http://cr.openjdk.java.net/~mdoerr/8138892_c1_counter_overflow/webrev.02 It?s not tested on aarch64. Please review this change. I need a sponsor, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Wed Oct 21 10:30:02 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 21 Oct 2015 10:30:02 +0000 Subject: RFR(M) 8138892: C1: Improve counter overflow checking In-Reply-To: <7C9B87B351A4BA4AA9EC95BB4181165672262198@DEWDFEMB19C.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB4181165672260C97@DEWDFEMB19C.global.corp.sap> <4295855A5C1DE049A61835A1887419CC41E81D63@DEWDFEMB12A.global.corp.sap> <74584B20-982F-4FA5-A863-85663DDD8F2F@oracle.com> <890C84B6-8FAF-4D2A-9277-777E372361CB@oracle.com> <80643179-9E06-4E68-82AF-3A2FFAE5A6E8@oracle.com> <7C9B87B351A4BA4AA9EC95BB4181165672262198@DEWDFEMB19C.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC41E83AA0@DEWDFEMB12A.global.corp.sap> Hi, Anyways, I double-checked that these three reviewed changes import, jcheck and build fine: 8138890: C1: Ambiguous operator delete http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.03/main-hotspot-xxx.changeset 8138894: C1: Support IRIW on weak memory platforms http://cr.openjdk.java.net/~mdoerr/8138894_c1_IRIW/webrev.01/main-hotspot-xxx.changeset 8138892: C1: Improve counter overflow checking http://cr.openjdk.java.net/~mdoerr/8138892_c1_counter_overflow/webrev.03/main-hotspot-xxx.changeset Christian, thanks a lot for helping us. I appreciate this a lot! Best regards, Goetz. From: Doerr, Martin Sent: Mittwoch, 21. Oktober 2015 11:54 To: Christian Thalinger; Lindenmaier, Goetz Cc: hotspot compiler Subject: RE: RFR(M) 8138892: C1: Improve counter overflow checking Hi Christian, I have uploaded the final webrev and attached this changeset to the bug in JIRA: http://cr.openjdk.java.net/~mdoerr/8138892_c1_counter_overflow/webrev.03/main-hotspot-xxx.changeset It contains the reviewers. I have also attached a changeset with reviewers to the operator delete change: https://bugs.openjdk.java.net/browse/JDK-8138890 Best regards, Martin From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Christian Thalinger Sent: Mittwoch, 21. Oktober 2015 02:04 To: Lindenmaier, Goetz Cc: hotspot compiler Subject: Re: RFR(M) 8138892: C1: Improve counter overflow checking On Oct 20, 2015, at 2:01 PM, Christian Thalinger > wrote: Btw. it would help if you could export a changeset with the correct commit message and send it as attachment to the list. Even better, attach it to the JIRA issue. On Oct 20, 2015, at 1:58 PM, Christian Thalinger > wrote: Sorry, I?m pretty busy but I will try to sponsor this. On Oct 11, 2015, at 10:58 PM, Lindenmaier, Goetz > wrote: Hi Martin, this change looks good, thank you. Could someone please sponsor this? Best regards, Goetz. From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net]On Behalf Of Doerr, Martin Sent: Mittwoch, 7. Oktober 2015 23:02 To: hotspot compiler; Andrew Haley (aph at redhat.com) Subject: RFR(M) 8138892: C1: Improve counter overflow checking Hi, C1 currently loads the Method pointer in the fast path even though it is only required in the overflow case. In addition, stupid code gets generated when the frequency is set to 0 which occurs with -Xcomp. The following webrev optimizes that: http://cr.openjdk.java.net/~mdoerr/8138892_c1_counter_overflow/webrev.02 It?s not tested on aarch64. Please review this change. I need a sponsor, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Wed Oct 21 11:08:36 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 21 Oct 2015 14:08:36 +0300 Subject: hg: jdk9/hs-comp/hotspot: 8132168: Support IdealGraphVisualizer in optimized build In-Reply-To: <5626E2DE.9030405@oracle.com> References: <201510202247.t9KMlJF1011897@aojmv0008.oracle.com> <5626E2DE.9030405@oracle.com> Message-ID: <56277234.1000103@oracle.com> Some background: there are 2 bugs in play here - 8132168 [1] and 8065151 [2]. PrintIdealGraphLevel range fix was tracked by 8132168 initially [3], but I erroneously used 8065151 in the changeset. In order to fix that I swapped the contents of the bugs. So, changesets and jbs agree on the changes now. At the same time I noticed that I haven't pushed ex-8065151 yet though it was reviewed long ago [4]. So, I finally pushed it. Sorry for the confusion. Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8132168 [2] https://bugs.openjdk.java.net/browse/JDK-8065151 [3] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-July/018514.html [4] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-November/016307.html On 10/21/15 3:57 AM, Vladimir Kozlov wrote: > Hi Vladimir > > I did not see updated webrev for these changes. The old one was only to > add range: > > http://cr.openjdk.java.net/~vlivanov/8132168/webrev.00/ > > Changes are fine but we have to follow review process. > > Thanks, > Vladimir K > > On 10/21/15 6:47 AM, vladimir.x.ivanov at oracle.com wrote: >> Changeset: 1cd251540653 >> Author: vlivanov >> Date: 2015-10-20 19:22 +0300 >> URL: >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1cd251540653 >> >> 8132168: Support IdealGraphVisualizer in optimized build >> Reviewed-by: kvn >> >> ! src/share/vm/opto/c2_globals.hpp >> >> Changeset: 03fa0a35a468 >> Author: vlivanov >> Date: 2015-10-20 22:03 +0000 >> URL: >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/03fa0a35a468 >> >> Merge >> >> ! src/share/vm/opto/c2_globals.hpp >> From edward.nevill at gmail.com Wed Oct 21 12:28:53 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 21 Oct 2015 13:28:53 +0100 Subject: RFR: 8140238: Zero fails to build from source Message-ID: <1445430533.563.8.camel@mylittlepony.linaroharston> Hi, Could someone please sponsor the following webrev and push it through JPRT http://cr.openjdk.java.net/~enevill/8140238/ JIRA issue: https://bugs.openjdk.java.net/browse/JDK-8140238 Zero fails to build after 8136421: JEP 243: Java-Level JVM Compiler Interface https://bugs.openjdk.java.net/browse/JDK-8136421 The commit for 8136421 updated headers etc for _sparc, _x86, _ppr and _aarch64 but failed to update _zero. and 8078554: Compiler: implement ranges (optionally constraints) for those flags that have them missing https://bugs.openjdk.java.net/browse/JDK-8078554 The commit for 8078554 causes zero to generate an error about AllocatePrefetchDistance having the value -1 so I have set this to 0 in vm_version_zero.cpp. I have posted this to hotspot-compiler rather than build-dev because it is only in the hs-comp tree at the moment and because the build was broken by the commits for the above issues. Thanks for your help, Ed. From goetz.lindenmaier at sap.com Wed Oct 21 12:50:06 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 21 Oct 2015 12:50:06 +0000 Subject: RFR(XS): 8140239: Fix product build after "8132168: Support IdealGraphVisualizer in optimized build" Message-ID: <4295855A5C1DE049A61835A1887419CC41E83B4C@DEWDFEMB12A.global.corp.sap> Hi, After "8132168: Support IdealGraphVisualizer in optimized build" the product build is broken: compilerDirectives.cpp:181: error: 'PrintIdealGraphLevel' was not declared in this scope 8132168 changes the flag from 'develop' to 'notproduct'. 'Notproduct' does not define "const intx PrintIdealGraphLevel = 0;" in the product build, as 'develop' did. I fixed this by wrapping the flag with NOT_PRODUCT: http://cr.openjdk.java.net/~goetz/webrevs/8140239-prodBld/webrev.00/ Please review this change. I please need a sponsor. Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed Oct 21 13:33:29 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 21 Oct 2015 21:33:29 +0800 Subject: hg: jdk9/hs-comp/hotspot: 8132168: Support IdealGraphVisualizer in optimized build In-Reply-To: <56277234.1000103@oracle.com> References: <201510202247.t9KMlJF1011897@aojmv0008.oracle.com> <5626E2DE.9030405@oracle.com> <56277234.1000103@oracle.com> Message-ID: <56279429.3070801@oracle.com> Now it makes sense. Thanks, Vladimir On 10/21/15 7:08 PM, Vladimir Ivanov wrote: > Some background: there are 2 bugs in play here - 8132168 [1] and 8065151 > [2]. > > PrintIdealGraphLevel range fix was tracked by 8132168 initially [3], but > I erroneously used 8065151 in the changeset. > > In order to fix that I swapped the contents of the bugs. So, changesets > and jbs agree on the changes now. > > At the same time I noticed that I haven't pushed ex-8065151 yet though > it was reviewed long ago [4]. So, I finally pushed it. > > Sorry for the confusion. > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8132168 > [2] https://bugs.openjdk.java.net/browse/JDK-8065151 > [3] > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-July/018514.html > > [4] > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-November/016307.html > > > On 10/21/15 3:57 AM, Vladimir Kozlov wrote: >> Hi Vladimir >> >> I did not see updated webrev for these changes. The old one was only to >> add range: >> >> http://cr.openjdk.java.net/~vlivanov/8132168/webrev.00/ >> >> Changes are fine but we have to follow review process. >> >> Thanks, >> Vladimir K >> >> On 10/21/15 6:47 AM, vladimir.x.ivanov at oracle.com wrote: >>> Changeset: 1cd251540653 >>> Author: vlivanov >>> Date: 2015-10-20 19:22 +0300 >>> URL: >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1cd251540653 >>> >>> 8132168: Support IdealGraphVisualizer in optimized build >>> Reviewed-by: kvn >>> >>> ! src/share/vm/opto/c2_globals.hpp >>> >>> Changeset: 03fa0a35a468 >>> Author: vlivanov >>> Date: 2015-10-20 22:03 +0000 >>> URL: >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/03fa0a35a468 >>> >>> Merge >>> >>> ! src/share/vm/opto/c2_globals.hpp >>> From vladimir.kozlov at oracle.com Wed Oct 21 13:36:47 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 21 Oct 2015 21:36:47 +0800 Subject: RFR: 8140238: Zero fails to build from source In-Reply-To: <1445430533.563.8.camel@mylittlepony.linaroharston> References: <1445430533.563.8.camel@mylittlepony.linaroharston> Message-ID: <562794EF.4010509@oracle.com> Looks good. Since it is only zero platform specific changes someone from outside Oracle can push it. Thanks, Vladimir On 10/21/15 8:28 PM, Edward Nevill wrote: > Hi, > > Could someone please sponsor the following webrev and push it through JPRT > > http://cr.openjdk.java.net/~enevill/8140238/ > > JIRA issue: https://bugs.openjdk.java.net/browse/JDK-8140238 > > Zero fails to build after > > 8136421: JEP 243: Java-Level JVM Compiler Interface > > https://bugs.openjdk.java.net/browse/JDK-8136421 > > The commit for 8136421 updated headers etc for _sparc, _x86, _ppr and _aarch64 but failed to update _zero. > > and > > 8078554: Compiler: implement ranges (optionally constraints) for those flags that have them missing > > https://bugs.openjdk.java.net/browse/JDK-8078554 > > The commit for 8078554 causes zero to generate an error about AllocatePrefetchDistance having the value -1 so I have set this to 0 in vm_version_zero.cpp. > > I have posted this to hotspot-compiler rather than build-dev because it is only in the hs-comp tree at the moment and because the build was broken by the commits for the above issues. > > Thanks for your help, > Ed. > > From erik.joelsson at oracle.com Wed Oct 21 07:51:09 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 21 Oct 2015 09:51:09 +0200 Subject: RFR (XXS): 8139935: Bootcycle builds are broken on jdk9/hs due to JVMCI changes In-Reply-To: References: Message-ID: <562743ED.1090807@oracle.com> Looks good to me. /Erik On 2015-10-20 22:19, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8139935 > > The reason this ?works? for a non-bootcycle build is because a JDK 9 javac won't enforce the ?hidden packages? rules when running on a non-JDK 9 platform. > > diff -r a8a8604f890f make/gensrc/Gensrc-jdk.vm.ci.gmk > --- a/make/gensrc/Gensrc-jdk.vm.ci.gmk Sat Oct 17 19:40:30 2015 -0400 > +++ b/make/gensrc/Gensrc-jdk.vm.ci.gmk Tue Oct 20 09:57:02 2015 -1000 > @@ -77,6 +77,7 @@ PROCESSOR_PATH := $(call PathList, \ > $(MKDIR) -p $(@D) > $(eval $(call ListPathsSafely,PROC_SRCS,$(@D)/_gensrc_proc_files)) > $(JAVA_SMALL) $(NEW_JAVAC) \ > + -XDignore.symbol.file \ > -sourcepath $(SOURCEPATH) \ > -implicit:none \ > -proc:only \ > From vladimir.x.ivanov at oracle.com Wed Oct 21 13:44:49 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 21 Oct 2015 16:44:49 +0300 Subject: RFR(XS): 8140239: Fix product build after "8132168: Support IdealGraphVisualizer in optimized build" In-Reply-To: <4295855A5C1DE049A61835A1887419CC41E83B4C@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC41E83B4C@DEWDFEMB12A.global.corp.sap> Message-ID: <562796D1.8000807@oracle.com> Goetz, thanks for spotting that! Why not simply exclude IGVPrintLevel in product binaries instead? - cflags(IGVPrintLevel, intx, PrintIdealGraphLevel, IGVPrintLevel) \ + NOT_PRODUCT(cflags(IGVPrintLevel, intx, PrintIdealGraphLevel, IGVPrintLevel)) \ IGVPrintLevel is used only in non-product code and PrintIdealGraphLevel functionality is not available in product builds. Best regards, Vladimir Ivanov PS: I'm surprised the problem wasn't caught by JPRT. Shouldn't the merged version be tested? It looks like the merge [1] happened after the job finished. (FTR I had to restart the job due to a timeout.) [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/03fa0a35a468 On 10/21/15 3:50 PM, Lindenmaier, Goetz wrote: > Hi, > > After "8132168: Support IdealGraphVisualizer in optimized build" the > product build is broken: > compilerDirectives.cpp:181: error: 'PrintIdealGraphLevel' was not > declared in this scope > > 8132168 changes the flag from 'develop' to 'notproduct'. 'Notproduct' > does not define > "const intx PrintIdealGraphLevel = 0;" in the product build, as > 'develop' did. > > I fixed this by wrapping the flag with NOT_PRODUCT: > > http://cr.openjdk.java.net/~goetz/webrevs/8140239-prodBld/webrev.00/ > > Please review this change. I please need a sponsor. > > Best regards, > > Goetz. > From goetz.lindenmaier at sap.com Wed Oct 21 14:34:22 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 21 Oct 2015 14:34:22 +0000 Subject: RFR(XS): 8140239: Fix product build after "8132168: Support IdealGraphVisualizer in optimized build" In-Reply-To: <562796D1.8000807@oracle.com> References: <4295855A5C1DE049A61835A1887419CC41E83B4C@DEWDFEMB12A.global.corp.sap> <562796D1.8000807@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41E83C11@DEWDFEMB12A.global.corp.sap> Hi Vladimir, I just tried to implement the same behavior as with 'develop'. But excluding the flag altogether is fine with me, too: http://cr.openjdk.java.net/~goetz/webrevs/8140239-prodBld/webrev.01/ I put in you as reviewer, if that's ok. Best regards, Goetz. > -----Original Message----- > From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] > Sent: Mittwoch, 21. Oktober 2015 15:45 > To: Lindenmaier, Goetz; hotspot compiler > Subject: Re: RFR(XS): 8140239: Fix product build after "8132168: Support > IdealGraphVisualizer in optimized build" > > Goetz, thanks for spotting that! > > Why not simply exclude IGVPrintLevel in product binaries instead? > > - cflags(IGVPrintLevel, intx, PrintIdealGraphLevel, > IGVPrintLevel) \ > + NOT_PRODUCT(cflags(IGVPrintLevel, intx, PrintIdealGraphLevel, > IGVPrintLevel)) \ > > IGVPrintLevel is used only in non-product code and PrintIdealGraphLevel > functionality is not available in product builds. > > Best regards, > Vladimir Ivanov > > PS: I'm surprised the problem wasn't caught by JPRT. Shouldn't the > merged version be tested? It looks like the merge [1] happened after the > job finished. (FTR I had to restart the job due to a timeout.) > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/03fa0a35a468 > > On 10/21/15 3:50 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > After "8132168: Support IdealGraphVisualizer in optimized build" the > > product build is broken: > > compilerDirectives.cpp:181: error: 'PrintIdealGraphLevel' was not > > declared in this scope > > > > 8132168 changes the flag from 'develop' to 'notproduct'. 'Notproduct' > > does not define > > "const intx PrintIdealGraphLevel = 0;" in the product build, as > > 'develop' did. > > > > I fixed this by wrapping the flag with NOT_PRODUCT: > > > > http://cr.openjdk.java.net/~goetz/webrevs/8140239-prodBld/webrev.00/ > > > > Please review this change. I please need a sponsor. > > > > Best regards, > > > > Goetz. > > From vladimir.x.ivanov at oracle.com Wed Oct 21 15:09:31 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 21 Oct 2015 18:09:31 +0300 Subject: RFR(XS): 8140239: Fix product build after "8132168: Support IdealGraphVisualizer in optimized build" In-Reply-To: <4295855A5C1DE049A61835A1887419CC41E83C11@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC41E83B4C@DEWDFEMB12A.global.corp.sap> <562796D1.8000807@oracle.com> <4295855A5C1DE049A61835A1887419CC41E83C11@DEWDFEMB12A.global.corp.sap> Message-ID: <5627AAAB.10805@oracle.com> Sure, looks good. Best regards, Vladimir Ivanov On 10/21/15 5:34 PM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > I just tried to implement the same behavior as with 'develop'. > But excluding the flag altogether is fine with me, too: > http://cr.openjdk.java.net/~goetz/webrevs/8140239-prodBld/webrev.01/ > I put in you as reviewer, if that's ok. > > Best regards, > Goetz. > > > > >> -----Original Message----- >> From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] >> Sent: Mittwoch, 21. Oktober 2015 15:45 >> To: Lindenmaier, Goetz; hotspot compiler >> Subject: Re: RFR(XS): 8140239: Fix product build after "8132168: Support >> IdealGraphVisualizer in optimized build" >> >> Goetz, thanks for spotting that! >> >> Why not simply exclude IGVPrintLevel in product binaries instead? >> >> - cflags(IGVPrintLevel, intx, PrintIdealGraphLevel, >> IGVPrintLevel) \ >> + NOT_PRODUCT(cflags(IGVPrintLevel, intx, PrintIdealGraphLevel, >> IGVPrintLevel)) \ >> >> IGVPrintLevel is used only in non-product code and PrintIdealGraphLevel >> functionality is not available in product builds. >> >> Best regards, >> Vladimir Ivanov >> >> PS: I'm surprised the problem wasn't caught by JPRT. Shouldn't the >> merged version be tested? It looks like the merge [1] happened after the >> job finished. (FTR I had to restart the job due to a timeout.) >> >> [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/03fa0a35a468 >> >> On 10/21/15 3:50 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> After "8132168: Support IdealGraphVisualizer in optimized build" the >>> product build is broken: >>> compilerDirectives.cpp:181: error: 'PrintIdealGraphLevel' was not >>> declared in this scope >>> >>> 8132168 changes the flag from 'develop' to 'notproduct'. 'Notproduct' >>> does not define >>> "const intx PrintIdealGraphLevel = 0;" in the product build, as >>> 'develop' did. >>> >>> I fixed this by wrapping the flag with NOT_PRODUCT: >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8140239-prodBld/webrev.00/ >>> >>> Please review this change. I please need a sponsor. >>> >>> Best regards, >>> >>> Goetz. >>> From pavel.punegov at oracle.com Wed Oct 21 15:27:05 2015 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Wed, 21 Oct 2015 18:27:05 +0300 Subject: RFR(XS): 8140240: Missing test files in CompilerControl tests Message-ID: <5627AEC9.8090206@oracle.com> Hi all, Please review the following change. It adds missing classes and fixes into existing files that haven't got into the repository with the change for JDK-8066153 [*] (JEP-JDK-8046155: Test task: cover existing). Bug id: https://bugs.openjdk.java.net/browse/JDK-8140240 webrev: http://cr.openjdk.java.net/~ppunegov/8140240/webrev.00/ [*] https://bugs.openjdk.java.net/browse/JDK-8066153 -- Thanks, Pavel Punegov From vladimir.kozlov at oracle.com Wed Oct 21 15:30:30 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 21 Oct 2015 23:30:30 +0800 Subject: RFR(XS): 8140240: Missing test files in CompilerControl tests In-Reply-To: <5627AEC9.8090206@oracle.com> References: <5627AEC9.8090206@oracle.com> Message-ID: <5627AF96.608@oracle.com> Looks good. Thanks, Vladimir On 10/21/15 11:27 PM, Pavel Punegov wrote: > Hi all, > > Please review the following change. > It adds missing classes and fixes into existing files that haven't got > into the repository with the change for JDK-8066153 [*] > (JEP-JDK-8046155: Test task: cover existing). > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8140240 > webrev: http://cr.openjdk.java.net/~ppunegov/8140240/webrev.00/ > > [*] https://bugs.openjdk.java.net/browse/JDK-8066153 > From pavel.punegov at oracle.com Wed Oct 21 15:38:31 2015 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Wed, 21 Oct 2015 18:38:31 +0300 Subject: RFR(XS): 8140240: Missing test files in CompilerControl tests In-Reply-To: <5627AF96.608@oracle.com> References: <5627AEC9.8090206@oracle.com> <5627AF96.608@oracle.com> Message-ID: <5627B177.9020704@oracle.com> Thanks for review, Vladimir On 21.10.2015 18:30, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 10/21/15 11:27 PM, Pavel Punegov wrote: >> Hi all, >> >> Please review the following change. >> It adds missing classes and fixes into existing files that haven't got >> into the repository with the change for JDK-8066153 [*] >> (JEP-JDK-8046155: Test task: cover existing). >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8140240 >> webrev: http://cr.openjdk.java.net/~ppunegov/8140240/webrev.00/ >> >> [*] https://bugs.openjdk.java.net/browse/JDK-8066153 >> -- Thanks, Pavel Punegov From christian.thalinger at oracle.com Wed Oct 21 18:22:34 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 21 Oct 2015 08:22:34 -1000 Subject: RFR (XXS): 8139935: Bootcycle builds are broken on jdk9/hs due to JVMCI changes In-Reply-To: <562743ED.1090807@oracle.com> References: <562743ED.1090807@oracle.com> Message-ID: Thanks, Erik. > On Oct 20, 2015, at 9:51 PM, Erik Joelsson wrote: > > Looks good to me. > > /Erik > > On 2015-10-20 22:19, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8139935 >> >> The reason this ?works? for a non-bootcycle build is because a JDK 9 javac won't enforce the ?hidden packages? rules when running on a non-JDK 9 platform. >> >> diff -r a8a8604f890f make/gensrc/Gensrc-jdk.vm.ci.gmk >> --- a/make/gensrc/Gensrc-jdk.vm.ci.gmk Sat Oct 17 19:40:30 2015 -0400 >> +++ b/make/gensrc/Gensrc-jdk.vm.ci.gmk Tue Oct 20 09:57:02 2015 -1000 >> @@ -77,6 +77,7 @@ PROCESSOR_PATH := $(call PathList, \ >> $(MKDIR) -p $(@D) >> $(eval $(call ListPathsSafely,PROC_SRCS,$(@D)/_gensrc_proc_files)) >> $(JAVA_SMALL) $(NEW_JAVAC) \ >> + -XDignore.symbol.file \ >> -sourcepath $(SOURCEPATH) \ >> -implicit:none \ >> -proc:only \ >> > From dean.long at oracle.com Wed Oct 21 21:29:18 2015 From: dean.long at oracle.com (Dean Long) Date: Wed, 21 Oct 2015 14:29:18 -0700 Subject: RFR 8140267: assert(is_native_ptr || alias_type->adr_type() == TypeOopPtr::BOTTOM || alias_type->field() != __null || alias_type->element() != __null) failed: field, array element or unknown Message-ID: <562803AE.5020200@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8140267 http://cr.openjdk.java.net/~dlong/8140267/webrev/ 8136473 caused lots of failures in nightly testing, so we need to back it out. dl From christian.thalinger at oracle.com Wed Oct 21 22:01:51 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 21 Oct 2015 12:01:51 -1000 Subject: RFR 8140267: assert(is_native_ptr || alias_type->adr_type() == TypeOopPtr::BOTTOM || alias_type->field() != __null || alias_type->element() != __null) failed: field, array element or unknown In-Reply-To: <562803AE.5020200@oracle.com> References: <562803AE.5020200@oracle.com> Message-ID: <46B8D7A5-D06A-4F6D-B8EA-D93D79609D8E@oracle.com> Looks good. > On Oct 21, 2015, at 11:29 AM, Dean Long wrote: > > https://bugs.openjdk.java.net/browse/JDK-8140267 > http://cr.openjdk.java.net/~dlong/8140267/webrev/ > > 8136473 caused lots of failures in nightly testing, so we need to back it out. > > dl From dean.long at oracle.com Wed Oct 21 22:04:42 2015 From: dean.long at oracle.com (Dean Long) Date: Wed, 21 Oct 2015 15:04:42 -0700 Subject: RFR 8140267: assert(is_native_ptr || alias_type->adr_type() == TypeOopPtr::BOTTOM || alias_type->field() != __null || alias_type->element() != __null) failed: field, array element or unknown In-Reply-To: <46B8D7A5-D06A-4F6D-B8EA-D93D79609D8E@oracle.com> References: <562803AE.5020200@oracle.com> <46B8D7A5-D06A-4F6D-B8EA-D93D79609D8E@oracle.com> Message-ID: <56280BFA.90809@oracle.com> Thanks Christian. dl On 10/21/2015 3:01 PM, Christian Thalinger wrote: > Looks good. > >> On Oct 21, 2015, at 11:29 AM, Dean Long wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8140267 >> http://cr.openjdk.java.net/~dlong/8140267/webrev/ >> >> 8136473 caused lots of failures in nightly testing, so we need to back it out. >> >> dl From goetz.lindenmaier at sap.com Thu Oct 22 06:13:33 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 22 Oct 2015 06:13:33 +0000 Subject: RFR(XS): 8140239: Fix product build after "8132168: Support IdealGraphVisualizer in optimized build" In-Reply-To: <5627AAAB.10805@oracle.com> References: <4295855A5C1DE049A61835A1887419CC41E83B4C@DEWDFEMB12A.global.corp.sap> <562796D1.8000807@oracle.com> <4295855A5C1DE049A61835A1887419CC41E83C11@DEWDFEMB12A.global.corp.sap> <5627AAAB.10805@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41E83F4B@DEWDFEMB12A.global.corp.sap> Hi Vladimir, thanks for pushing the change! Best regards, Goetz. > -----Original Message----- > From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] > Sent: Mittwoch, 21. Oktober 2015 17:10 > To: Lindenmaier, Goetz; hotspot compiler > Subject: Re: RFR(XS): 8140239: Fix product build after "8132168: Support > IdealGraphVisualizer in optimized build" > > Sure, looks good. > > Best regards, > Vladimir Ivanov > > On 10/21/15 5:34 PM, Lindenmaier, Goetz wrote: > > Hi Vladimir, > > > > I just tried to implement the same behavior as with 'develop'. > > But excluding the flag altogether is fine with me, too: > > http://cr.openjdk.java.net/~goetz/webrevs/8140239-prodBld/webrev.01/ > > I put in you as reviewer, if that's ok. > > > > Best regards, > > Goetz. > > > > > > > > > >> -----Original Message----- > >> From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] > >> Sent: Mittwoch, 21. Oktober 2015 15:45 > >> To: Lindenmaier, Goetz; hotspot compiler > >> Subject: Re: RFR(XS): 8140239: Fix product build after "8132168: Support > >> IdealGraphVisualizer in optimized build" > >> > >> Goetz, thanks for spotting that! > >> > >> Why not simply exclude IGVPrintLevel in product binaries instead? > >> > >> - cflags(IGVPrintLevel, intx, PrintIdealGraphLevel, > >> IGVPrintLevel) \ > >> + NOT_PRODUCT(cflags(IGVPrintLevel, intx, PrintIdealGraphLevel, > >> IGVPrintLevel)) \ > >> > >> IGVPrintLevel is used only in non-product code and PrintIdealGraphLevel > >> functionality is not available in product builds. > >> > >> Best regards, > >> Vladimir Ivanov > >> > >> PS: I'm surprised the problem wasn't caught by JPRT. Shouldn't the > >> merged version be tested? It looks like the merge [1] happened after the > >> job finished. (FTR I had to restart the job due to a timeout.) > >> > >> [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/03fa0a35a468 > >> > >> On 10/21/15 3:50 PM, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> After "8132168: Support IdealGraphVisualizer in optimized build" the > >>> product build is broken: > >>> compilerDirectives.cpp:181: error: 'PrintIdealGraphLevel' was not > >>> declared in this scope > >>> > >>> 8132168 changes the flag from 'develop' to 'notproduct'. 'Notproduct' > >>> does not define > >>> "const intx PrintIdealGraphLevel = 0;" in the product build, as > >>> 'develop' did. > >>> > >>> I fixed this by wrapping the flag with NOT_PRODUCT: > >>> > >>> http://cr.openjdk.java.net/~goetz/webrevs/8140239- > prodBld/webrev.00/ > >>> > >>> Please review this change. I please need a sponsor. > >>> > >>> Best regards, > >>> > >>> Goetz. > >>> From christian.thalinger at oracle.com Thu Oct 22 23:47:31 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 22 Oct 2015 13:47:31 -1000 Subject: RFR(XS): 8140239: Fix product build after "8132168: Support IdealGraphVisualizer in optimized build" In-Reply-To: <4295855A5C1DE049A61835A1887419CC41E83F4B@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC41E83B4C@DEWDFEMB12A.global.corp.sap> <562796D1.8000807@oracle.com> <4295855A5C1DE049A61835A1887419CC41E83C11@DEWDFEMB12A.global.corp.sap> <5627AAAB.10805@oracle.com> <4295855A5C1DE049A61835A1887419CC41E83F4B@DEWDFEMB12A.global.corp.sap> Message-ID: Why are we prefixing flags with CONST_ in product builds? #ifdef PRODUCT #define MATERIALIZE_DEVELOPER_FLAG(type, name, value, doc) type CONST_##name = value; #define MATERIALIZE_PD_DEVELOPER_FLAG(type, name, doc) type CONST_##name = pd_##name; #define MATERIALIZE_NOTPRODUCT_FLAG(type, name, value, doc) type CONST_##name = value; #else Is it to find uses of developer/notproduct flags in product code? Does it even matter? > On Oct 21, 2015, at 8:13 PM, Lindenmaier, Goetz wrote: > > Hi Vladimir, > > thanks for pushing the change! > > Best regards, > Goetz. > >> -----Original Message----- >> From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] >> Sent: Mittwoch, 21. Oktober 2015 17:10 >> To: Lindenmaier, Goetz; hotspot compiler >> Subject: Re: RFR(XS): 8140239: Fix product build after "8132168: Support >> IdealGraphVisualizer in optimized build" >> >> Sure, looks good. >> >> Best regards, >> Vladimir Ivanov >> >> On 10/21/15 5:34 PM, Lindenmaier, Goetz wrote: >>> Hi Vladimir, >>> >>> I just tried to implement the same behavior as with 'develop'. >>> But excluding the flag altogether is fine with me, too: >>> http://cr.openjdk.java.net/~goetz/webrevs/8140239-prodBld/webrev.01/ >>> I put in you as reviewer, if that's ok. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] >>>> Sent: Mittwoch, 21. Oktober 2015 15:45 >>>> To: Lindenmaier, Goetz; hotspot compiler >>>> Subject: Re: RFR(XS): 8140239: Fix product build after "8132168: Support >>>> IdealGraphVisualizer in optimized build" >>>> >>>> Goetz, thanks for spotting that! >>>> >>>> Why not simply exclude IGVPrintLevel in product binaries instead? >>>> >>>> - cflags(IGVPrintLevel, intx, PrintIdealGraphLevel, >>>> IGVPrintLevel) \ >>>> + NOT_PRODUCT(cflags(IGVPrintLevel, intx, PrintIdealGraphLevel, >>>> IGVPrintLevel)) \ >>>> >>>> IGVPrintLevel is used only in non-product code and PrintIdealGraphLevel >>>> functionality is not available in product builds. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> PS: I'm surprised the problem wasn't caught by JPRT. Shouldn't the >>>> merged version be tested? It looks like the merge [1] happened after the >>>> job finished. (FTR I had to restart the job due to a timeout.) >>>> >>>> [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/03fa0a35a468 >>>> >>>> On 10/21/15 3:50 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> After "8132168: Support IdealGraphVisualizer in optimized build" the >>>>> product build is broken: >>>>> compilerDirectives.cpp:181: error: 'PrintIdealGraphLevel' was not >>>>> declared in this scope >>>>> >>>>> 8132168 changes the flag from 'develop' to 'notproduct'. 'Notproduct' >>>>> does not define >>>>> "const intx PrintIdealGraphLevel = 0;" in the product build, as >>>>> 'develop' did. >>>>> >>>>> I fixed this by wrapping the flag with NOT_PRODUCT: >>>>> >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8140239- >> prodBld/webrev.00/ >>>>> >>>>> Please review this change. I please need a sponsor. >>>>> >>>>> Best regards, >>>>> >>>>> Goetz. >>>>> From vladimir.kozlov at oracle.com Fri Oct 23 03:24:53 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 23 Oct 2015 11:24:53 +0800 Subject: RFR(XS): 8140239: Fix product build after "8132168: Support IdealGraphVisualizer in optimized build" In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC41E83B4C@DEWDFEMB12A.global.corp.sap> <562796D1.8000807@oracle.com> <4295855A5C1DE049A61835A1887419CC41E83C11@DEWDFEMB12A.global.corp.sap> <5627AAAB.10805@oracle.com> <4295855A5C1DE049A61835A1887419CC41E83F4B@DEWDFEMB12A.global.corp.sap> Message-ID: <5629A885.3030600@oracle.com> On 10/23/15 7:47 AM, Christian Thalinger wrote: > Why are we prefixing flags with CONST_ in product builds? It was your change: 8024545: make develop and notproduct flag values available in product builds http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.hpp.udiff.html Vladimir > > #ifdef PRODUCT > #define MATERIALIZE_DEVELOPER_FLAG(type, name, value, doc) type CONST_##name = value; > #define MATERIALIZE_PD_DEVELOPER_FLAG(type, name, doc) type CONST_##name = pd_##name; > #define MATERIALIZE_NOTPRODUCT_FLAG(type, name, value, doc) type CONST_##name = value; > #else > > Is it to find uses of developer/notproduct flags in product code? Does it even matter? > >> On Oct 21, 2015, at 8:13 PM, Lindenmaier, Goetz wrote: >> >> Hi Vladimir, >> >> thanks for pushing the change! >> >> Best regards, >> Goetz. >> >>> -----Original Message----- >>> From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] >>> Sent: Mittwoch, 21. Oktober 2015 17:10 >>> To: Lindenmaier, Goetz; hotspot compiler >>> Subject: Re: RFR(XS): 8140239: Fix product build after "8132168: Support >>> IdealGraphVisualizer in optimized build" >>> >>> Sure, looks good. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 10/21/15 5:34 PM, Lindenmaier, Goetz wrote: >>>> Hi Vladimir, >>>> >>>> I just tried to implement the same behavior as with 'develop'. >>>> But excluding the flag altogether is fine with me, too: >>>> http://cr.openjdk.java.net/~goetz/webrevs/8140239-prodBld/webrev.01/ >>>> I put in you as reviewer, if that's ok. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] >>>>> Sent: Mittwoch, 21. Oktober 2015 15:45 >>>>> To: Lindenmaier, Goetz; hotspot compiler >>>>> Subject: Re: RFR(XS): 8140239: Fix product build after "8132168: Support >>>>> IdealGraphVisualizer in optimized build" >>>>> >>>>> Goetz, thanks for spotting that! >>>>> >>>>> Why not simply exclude IGVPrintLevel in product binaries instead? >>>>> >>>>> - cflags(IGVPrintLevel, intx, PrintIdealGraphLevel, >>>>> IGVPrintLevel) \ >>>>> + NOT_PRODUCT(cflags(IGVPrintLevel, intx, PrintIdealGraphLevel, >>>>> IGVPrintLevel)) \ >>>>> >>>>> IGVPrintLevel is used only in non-product code and PrintIdealGraphLevel >>>>> functionality is not available in product builds. >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> PS: I'm surprised the problem wasn't caught by JPRT. Shouldn't the >>>>> merged version be tested? It looks like the merge [1] happened after the >>>>> job finished. (FTR I had to restart the job due to a timeout.) >>>>> >>>>> [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/03fa0a35a468 >>>>> >>>>> On 10/21/15 3:50 PM, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> After "8132168: Support IdealGraphVisualizer in optimized build" the >>>>>> product build is broken: >>>>>> compilerDirectives.cpp:181: error: 'PrintIdealGraphLevel' was not >>>>>> declared in this scope >>>>>> >>>>>> 8132168 changes the flag from 'develop' to 'notproduct'. 'Notproduct' >>>>>> does not define >>>>>> "const intx PrintIdealGraphLevel = 0;" in the product build, as >>>>>> 'develop' did. >>>>>> >>>>>> I fixed this by wrapping the flag with NOT_PRODUCT: >>>>>> >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8140239- >>> prodBld/webrev.00/ >>>>>> >>>>>> Please review this change. I please need a sponsor. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Goetz. >>>>>> > From zoltan.majo at oracle.com Fri Oct 23 07:51:19 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 23 Oct 2015 09:51:19 +0200 Subject: [9] RFR(S): 8138651: -XX:DisableIntrinsic matches intrinsics overly eagerly In-Reply-To: <5613C735.60006@oracle.com> References: <5613B7D5.5090702@oracle.com> <5613C735.60006@oracle.com> Message-ID: <5629E6F7.8040502@oracle.com> Hi Aleksey, On 10/06/2015 03:05 PM, Aleksey Shipilev wrote: > On 10/06/2015 03:00 PM, Zolt?n Maj? wrote: >> https://bugs.openjdk.java.net/browse/JDK-8138651 >> >> Problem: The DisableIntrinsic flag does not disable intrinsics >> accurately. For example, -XX:DisableIntrinsic=_copyOfRange disables both >> the intrinsic with the ID _copyOfRange and the intrinsic with the _copyOf. >> >> Solution: Change the processing of the DisableIntrinsic flag (both >> globally and on a per-method level). >> >> Webrev: http://cr.openjdk.java.net/~zmajo/8138651/webrev.00/ > Thanks for fixing this annoyance, Zoltan! thank for the feedback. > > The patch looks good to me. A few comments: > > * Why do you need a copy of the list? Can't strtok operate on ccstr itself? No, it can't, because it modifies the list. > > * I think this collides with Nil's CompilerControl JEP a bit, that > apparently moved/redone this part of compiler. Thank you for pointing that out. I've adapted the code to the changes done by compiler control. Please see the updated webrev in my reply to Vladimir. Thank you and best regards, Zoltan > > Thanks, > -Aleksey > > From zoltan.majo at oracle.com Fri Oct 23 07:51:37 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 23 Oct 2015 09:51:37 +0200 Subject: [9] RFR(S): 8138651: -XX:DisableIntrinsic matches intrinsics overly eagerly In-Reply-To: <56148585.1020507@oracle.com> References: <5613B7D5.5090702@oracle.com> <56148585.1020507@oracle.com> Message-ID: <5629E709.2000004@oracle.com> Hi Vladimir, thank you for the feedback! On 10/07/2015 04:37 AM, Vladimir Kozlov wrote: > To be precise DisableIntrinsic is ccstrlist option, not ccstr. Yes, > the actual type is the same. > > An other concern is separators since format could be different if > option specified in file. Look how we do search in DeoptimizeOnlyAt > string. I've checked and DisableIntrinsic supports accumulation of argument values: If -XX:DisableIntrinsic is specified multiple times on the command line, all argument values are concatenated into one argument. In that case, '\n' is used as separator. I updated the webrev to support "\n" as a separator. If DisableIntrinsic is used on the per-method level (i.e., with -XX:CompileCommand=option,...), HotSpot expects the type of DisableIntrinsic to be 'ccstr' and not 'ccstrlist'. That does not allow specifying a list of intrinsics to be disabled (e.g., _getInt,_getInVolatile,_hashCode) and is inconsistent with the declaration of DisableIntrinsic in globals.hpp. To address this problem, the webrev changes the type of the per-method level DisableIntrinsic flag to 'ccstrlist'. For per-method ccstrlists, the separator is a whitespace (internally). I've updated the webrev to support whitespace as a separator as well. I noticed an other problem while working on this fix: If DisableIntrinsic is specified multiple times for the same method, argument values do not accumulate. For example, with -XX:CompileCommand=option,sun.misc.Unsafe::putChar,ccstrlist,DisableIntrinsic,_getInt,_getIntVolatile -XX:CompileCommand=option,sun.misc.Unsafe::putChar,ccstrlist,DisableIntrinsic,_hashCode only '_hashCode' will be disabled for 'putChar'. That is also inconsistent with the way DisableIntrinsic works when used globally (with -XX:DisableIntrinsic). This inconsistency should be addressed, but as the fix requires significant changes to CompilerOracle, I would like to take care of that separately. I've filed an RFE for that: https://bugs.openjdk.java.net/browse/JDK-8140322 I hope that is fine. Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8138651/webrev.01/ Testing: - JPRT (testset hotspot, including the newly added IntrinsicDisabledTest.java test). Thank you and best regards, Zoltan > > Thanks, > Vladimir > > On 10/6/15 8:00 PM, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the patch for JDK-8138651. >> >> https://bugs.openjdk.java.net/browse/JDK-8138651 >> >> Problem: The DisableIntrinsic flag does not disable intrinsics >> accurately. For example, -XX:DisableIntrinsic=_copyOfRange disables both >> the intrinsic with the ID _copyOfRange and the intrinsic with the >> _copyOf. >> >> Solution: Change the processing of the DisableIntrinsic flag (both >> globally and on a per-method level). >> >> Webrev: http://cr.openjdk.java.net/~zmajo/8138651/webrev.00/ >> >> Testing: >> - JPRT (testset hotspot); >> - executed the the newly added test >> compiler/intrinsics/IntrinsicDisabledTest.java with/without the fix on >> all platforms, the test behaves as expected. >> >> Thank you and best regards, >> >> >> Zoltan >> From nils.eliasson at oracle.com Fri Oct 23 09:03:56 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 23 Oct 2015 11:03:56 +0200 Subject: RFR (S): 8140343: SEGV in DirectivesStack::getMatchingDirective Message-ID: <5629F7FC.7090008@oracle.com> Hi all, This fixes a bug when using a compiler that doesn't have compiler directives. This is a temporary fix using the default directive for c1. In the future permanent fix all compilers will have directives by default. bug: https://bugs.openjdk.java.net/browse/JDK-8140343 webrev: http://cr.openjdk.java.net/~neliasso/8140343/webrev.01/ Please review, Nils From vladimir.kozlov at oracle.com Fri Oct 23 09:42:23 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 23 Oct 2015 17:42:23 +0800 Subject: [9] RFR(S): 8138651: -XX:DisableIntrinsic matches intrinsics overly eagerly In-Reply-To: <5629E709.2000004@oracle.com> References: <5613B7D5.5090702@oracle.com> <56148585.1020507@oracle.com> <5629E709.2000004@oracle.com> Message-ID: <562A00FF.9080608@oracle.com> On 10/23/15 3:51 PM, Zolt?n Maj? wrote: > Hi Vladimir, > > > thank you for the feedback! > > On 10/07/2015 04:37 AM, Vladimir Kozlov wrote: >> To be precise DisableIntrinsic is ccstrlist option, not ccstr. Yes, >> the actual type is the same. >> >> An other concern is separators since format could be different if >> option specified in file. Look how we do search in DeoptimizeOnlyAt >> string. > > I've checked and DisableIntrinsic supports accumulation of argument > values: If -XX:DisableIntrinsic is specified multiple times on the > command line, all argument values are concatenated into one argument. In > that case, '\n' is used as separator. I updated the webrev to support > "\n" as a separator. Good. > > If DisableIntrinsic is used on the per-method level (i.e., with > -XX:CompileCommand=option,...), HotSpot expects the type of > DisableIntrinsic to be 'ccstr' and not 'ccstrlist'. That does not allow > specifying a list of intrinsics to be disabled (e.g., > _getInt,_getInVolatile,_hashCode) and is inconsistent with the > declaration of DisableIntrinsic in globals.hpp. > > To address this problem, the webrev changes the type of the per-method > level DisableIntrinsic flag to 'ccstrlist'. For per-method ccstrlists, > the separator is a whitespace (internally). I've updated the webrev to > support whitespace as a separator as well. Yes. > > I noticed an other problem while working on this fix: If > DisableIntrinsic is specified multiple times for the same method, > argument values do not accumulate. For example, with > > -XX:CompileCommand=option,sun.misc.Unsafe::putChar,ccstrlist,DisableIntrinsic,_getInt,_getIntVolatile > > -XX:CompileCommand=option,sun.misc.Unsafe::putChar,ccstrlist,DisableIntrinsic,_hashCode > > > only '_hashCode' will be disabled for 'putChar'. That is also > inconsistent with the way DisableIntrinsic works when used globally > (with -XX:DisableIntrinsic). > > This inconsistency should be addressed, but as the fix requires > significant changes to CompilerOracle, I would like to take care of that > separately. I've filed an RFE for that: > > https://bugs.openjdk.java.net/browse/JDK-8140322 > > I hope that is fine. Yes, it is fine to fix separately. > > Here is the updated webrev: > http://cr.openjdk.java.net/~zmajo/8138651/webrev.01/ Will you update later (in next rfe) next method to print all items on list 'v'? Should it be 'ccstrlist v'?: + void print_ccstrlist(outputStream* st, ccstr n, ccstr v, bool mod) { print_ccstr(st, n, v, mod); } Otherwise changes looks good. Thanks, Vladimir > > Testing: > - JPRT (testset hotspot, including the newly added > IntrinsicDisabledTest.java test). > > Thank you and best regards, > > > Zoltan > >> >> Thanks, >> Vladimir >> >> On 10/6/15 8:00 PM, Zolt?n Maj? wrote: >>> Hi, >>> >>> >>> please review the patch for JDK-8138651. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8138651 >>> >>> Problem: The DisableIntrinsic flag does not disable intrinsics >>> accurately. For example, -XX:DisableIntrinsic=_copyOfRange disables both >>> the intrinsic with the ID _copyOfRange and the intrinsic with the >>> _copyOf. >>> >>> Solution: Change the processing of the DisableIntrinsic flag (both >>> globally and on a per-method level). >>> >>> Webrev: http://cr.openjdk.java.net/~zmajo/8138651/webrev.00/ >>> >>> Testing: >>> - JPRT (testset hotspot); >>> - executed the the newly added test >>> compiler/intrinsics/IntrinsicDisabledTest.java with/without the fix on >>> all platforms, the test behaves as expected. >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> > From zoltan.majo at oracle.com Fri Oct 23 10:11:19 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 23 Oct 2015 12:11:19 +0200 Subject: [9] RFR(S): 8138651: -XX:DisableIntrinsic matches intrinsics overly eagerly In-Reply-To: <562A00FF.9080608@oracle.com> References: <5613B7D5.5090702@oracle.com> <56148585.1020507@oracle.com> <5629E709.2000004@oracle.com> <562A00FF.9080608@oracle.com> Message-ID: <562A07C7.8060902@oracle.com> Hi Vladimir, thank you for the review! On 10/23/2015 11:42 AM, Vladimir Kozlov wrote: > [...] >> This inconsistency should be addressed, but as the fix requires >> significant changes to CompilerOracle, I would like to take care of that >> separately. I've filed an RFE for that: >> >> https://bugs.openjdk.java.net/browse/JDK-8140322 >> >> I hope that is fine. > > Yes, it is fine to fix separately. > >> >> Here is the updated webrev: >> http://cr.openjdk.java.net/~zmajo/8138651/webrev.01/ > > Will you update later (in next rfe) next method to print all items on > list 'v'? Should it be 'ccstrlist v'?: > > + void print_ccstrlist(outputStream* st, ccstr n, ccstr v, bool mod) > { print_ccstr(st, n, v, mod); } Yes, you are right, changing the argument type to 'ccstrlist v' would make the code clearer and printing list items would also make sense. I noted this problem in the description of JDK-8140322. Thank you and best regards, Zoltan > > Otherwise changes looks good. > > Thanks, > Vladimir > >> >> Testing: >> - JPRT (testset hotspot, including the newly added >> IntrinsicDisabledTest.java test). >> >> Thank you and best regards, >> >> >> Zoltan >> >>> >>> Thanks, >>> Vladimir >>> >>> On 10/6/15 8:00 PM, Zolt?n Maj? wrote: >>>> Hi, >>>> >>>> >>>> please review the patch for JDK-8138651. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8138651 >>>> >>>> Problem: The DisableIntrinsic flag does not disable intrinsics >>>> accurately. For example, -XX:DisableIntrinsic=_copyOfRange disables >>>> both >>>> the intrinsic with the ID _copyOfRange and the intrinsic with the >>>> _copyOf. >>>> >>>> Solution: Change the processing of the DisableIntrinsic flag (both >>>> globally and on a per-method level). >>>> >>>> Webrev: http://cr.openjdk.java.net/~zmajo/8138651/webrev.00/ >>>> >>>> Testing: >>>> - JPRT (testset hotspot); >>>> - executed the the newly added test >>>> compiler/intrinsics/IntrinsicDisabledTest.java with/without the fix on >>>> all platforms, the test behaves as expected. >>>> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> >> From nils.eliasson at oracle.com Fri Oct 23 11:49:29 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 23 Oct 2015 13:49:29 +0200 Subject: [9] RFR(S): 8138651: -XX:DisableIntrinsic matches intrinsics overly eagerly In-Reply-To: <5629E709.2000004@oracle.com> References: <5613B7D5.5090702@oracle.com> <56148585.1020507@oracle.com> <5629E709.2000004@oracle.com> Message-ID: <562A1EC9.6020006@oracle.com> Hi Zoltan, Some comments: IntrinsicDisabledTest.java: >> return >> System.getProperty("java.vm.name").toLowerCase().contains("server"); >> think the best practice is to use Platform.isServer() ("import jdk.test.lib.Platform;"). compilerDirectives.cpp: I think the canonilization of the list belongs at the construction site, and not do at the (hot) use site. Preferably we would agree on using the ',' separator in all use case (it only has internal uses). The compilecommand parser should be straightforward to fix. The VM flag may be parsed by a common parser that we can't change - then the vmflag value should be canonicalized during CompilerBroker_init or similar. If there is some reason to why that doesn't work then I would suggest moving the canonicalization to DirectiveSet constructor and DirectiveSet::clone so it only happens once per DirectiveSet. Best regards, Nils On 2015-10-23 09:51, Zolt?n Maj? wrote: > Hi Vladimir, > > > thank you for the feedback! > > On 10/07/2015 04:37 AM, Vladimir Kozlov wrote: >> To be precise DisableIntrinsic is ccstrlist option, not ccstr. Yes, >> the actual type is the same. >> >> An other concern is separators since format could be different if >> option specified in file. Look how we do search in DeoptimizeOnlyAt >> string. > > I've checked and DisableIntrinsic supports accumulation of argument > values: If -XX:DisableIntrinsic is specified multiple times on the > command line, all argument values are concatenated into one argument. > In that case, '\n' is used as separator. I updated the webrev to > support "\n" as a separator. > > If DisableIntrinsic is used on the per-method level (i.e., with > -XX:CompileCommand=option,...), HotSpot expects the type of > DisableIntrinsic to be 'ccstr' and not 'ccstrlist'. That does not > allow specifying a list of intrinsics to be disabled (e.g., > _getInt,_getInVolatile,_hashCode) and is inconsistent with the > declaration of DisableIntrinsic in globals.hpp. > > To address this problem, the webrev changes the type of the > per-method level DisableIntrinsic flag to 'ccstrlist'. For per-method > ccstrlists, the separator is a whitespace (internally). I've updated > the webrev to support whitespace as a separator as well. > > I noticed an other problem while working on this fix: If > DisableIntrinsic is specified multiple times for the same method, > argument values do not accumulate. For example, with > > -XX:CompileCommand=option,sun.misc.Unsafe::putChar,ccstrlist,DisableIntrinsic,_getInt,_getIntVolatile > > -XX:CompileCommand=option,sun.misc.Unsafe::putChar,ccstrlist,DisableIntrinsic,_hashCode > > only '_hashCode' will be disabled for 'putChar'. That is also > inconsistent with the way DisableIntrinsic works when used globally > (with -XX:DisableIntrinsic). > > This inconsistency should be addressed, but as the fix requires > significant changes to CompilerOracle, I would like to take care of > that separately. I've filed an RFE for that: > > https://bugs.openjdk.java.net/browse/JDK-8140322 > > I hope that is fine. > > Here is the updated webrev: > http://cr.openjdk.java.net/~zmajo/8138651/webrev.01/ > > Testing: - JPRT (testset hotspot, including the newly added > IntrinsicDisabledTest.java test). > > Thank you and best regards, > > > Zoltan > >> >> Thanks, Vladimir >> >> On 10/6/15 8:00 PM, Zolt?n Maj? wrote: >>> Hi, >>> >>> >>> please review the patch for JDK-8138651. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8138651 >>> >>> Problem: The DisableIntrinsic flag does not disable intrinsics >>> accurately. For example, -XX:DisableIntrinsic=_copyOfRange >>> disables both the intrinsic with the ID _copyOfRange and the >>> intrinsic with the _copyOf. >>> >>> Solution: Change the processing of the DisableIntrinsic flag >>> (both globally and on a per-method level). >>> >>> Webrev: http://cr.openjdk.java.net/~zmajo/8138651/webrev.00/ >>> >>> Testing: - JPRT (testset hotspot); - executed the the newly added >>> test compiler/intrinsics/IntrinsicDisabledTest.java with/without >>> the fix on all platforms, the test behaves as expected. >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Fri Oct 23 18:39:39 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 23 Oct 2015 08:39:39 -1000 Subject: RFR(XS): 8140239: Fix product build after "8132168: Support IdealGraphVisualizer in optimized build" In-Reply-To: <5629A885.3030600@oracle.com> References: <4295855A5C1DE049A61835A1887419CC41E83B4C@DEWDFEMB12A.global.corp.sap> <562796D1.8000807@oracle.com> <4295855A5C1DE049A61835A1887419CC41E83C11@DEWDFEMB12A.global.corp.sap> <5627AAAB.10805@oracle.com> <4295855A5C1DE049A61835A1887419CC41E83F4B@DEWDFEMB12A.global.corp.sap> <5629A885.3030600@oracle.com> Message-ID: > On Oct 22, 2015, at 5:24 PM, Vladimir Kozlov wrote: > > On 10/23/15 7:47 AM, Christian Thalinger wrote: >> Why are we prefixing flags with CONST_ in product builds? > > It was your change: > 8024545: make develop and notproduct flag values available in product builds > http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.hpp.udiff.html Damn. I knew it :-) I vaguely remember that I did that because of getting the flag address for the flag table. But this works as well: diff -r bc48b669bc66 src/share/vm/runtime/globals.cpp --- a/src/share/vm/runtime/globals.cpp Mon Oct 19 00:24:58 2015 -0700 +++ b/src/share/vm/runtime/globals.cpp Fri Oct 23 08:35:34 2015 -1000 @@ -536,7 +536,7 @@ const char* Flag::flag_error_str(Flag::E // 4991491 do not "optimize out" the was_set false values: omitting them // tickles a Microsoft compiler bug causing flagTable to be malformed -#define NAME(name) NOT_PRODUCT(&name) PRODUCT_ONLY(&CONST_##name) +#define NAME(name) (void*)&name #define RUNTIME_PRODUCT_FLAG_STRUCT( type, name, value, doc) { #type, XSTR(name), &name, NOT_PRODUCT_ARG(doc) Flag::Flags(Flag::DEFAULT | Flag::KIND_PRODUCT) }, #define RUNTIME_PD_PRODUCT_FLAG_STRUCT( type, name, doc) { #type, XSTR(name), &name, NOT_PRODUCT_ARG(doc) Flag::Flags(Flag::DEFAULT | Flag::KIND_PRODUCT | Flag::KIND_PLATFORM_DEPENDENT) }, diff -r bc48b669bc66 src/share/vm/runtime/globals.hpp --- a/src/share/vm/runtime/globals.hpp Mon Oct 19 00:24:58 2015 -0700 +++ b/src/share/vm/runtime/globals.hpp Fri Oct 23 08:35:34 2015 -1000 @@ -4129,9 +4129,9 @@ public: #define DECLARE_MANAGEABLE_FLAG(type, name, value, doc) extern "C" type name; #define DECLARE_PRODUCT_RW_FLAG(type, name, value, doc) extern "C" type name; #ifdef PRODUCT -#define DECLARE_DEVELOPER_FLAG(type, name, value, doc) extern "C" type CONST_##name; const type name = value; -#define DECLARE_PD_DEVELOPER_FLAG(type, name, doc) extern "C" type CONST_##name; const type name = pd_##name; -#define DECLARE_NOTPRODUCT_FLAG(type, name, value, doc) extern "C" type CONST_##name; +#define DECLARE_DEVELOPER_FLAG(type, name, value, doc) const type name = value; +#define DECLARE_PD_DEVELOPER_FLAG(type, name, doc) const type name = pd_##name; +#define DECLARE_NOTPRODUCT_FLAG(type, name, value, doc) const type name = value; #else #define DECLARE_DEVELOPER_FLAG(type, name, value, doc) extern "C" type name; #define DECLARE_PD_DEVELOPER_FLAG(type, name, doc) extern "C" type name; @@ -4152,9 +4152,9 @@ public: #define MATERIALIZE_MANAGEABLE_FLAG(type, name, value, doc) type name = value; #define MATERIALIZE_PRODUCT_RW_FLAG(type, name, value, doc) type name = value; #ifdef PRODUCT -#define MATERIALIZE_DEVELOPER_FLAG(type, name, value, doc) type CONST_##name = value; -#define MATERIALIZE_PD_DEVELOPER_FLAG(type, name, doc) type CONST_##name = pd_##name; -#define MATERIALIZE_NOTPRODUCT_FLAG(type, name, value, doc) type CONST_##name = value; +#define MATERIALIZE_DEVELOPER_FLAG(type, name, value, doc) +#define MATERIALIZE_PD_DEVELOPER_FLAG(type, name, doc) +#define MATERIALIZE_NOTPRODUCT_FLAG(type, name, value, doc) #else #define MATERIALIZE_DEVELOPER_FLAG(type, name, value, doc) type name = value; #define MATERIALIZE_PD_DEVELOPER_FLAG(type, name, doc) type name = pd_##name; I think we should do that and not make flags conditional like the fix for this bug. > > Vladimir > >> >> #ifdef PRODUCT >> #define MATERIALIZE_DEVELOPER_FLAG(type, name, value, doc) type CONST_##name = value; >> #define MATERIALIZE_PD_DEVELOPER_FLAG(type, name, doc) type CONST_##name = pd_##name; >> #define MATERIALIZE_NOTPRODUCT_FLAG(type, name, value, doc) type CONST_##name = value; >> #else >> >> Is it to find uses of developer/notproduct flags in product code? Does it even matter? >> >>> On Oct 21, 2015, at 8:13 PM, Lindenmaier, Goetz wrote: >>> >>> Hi Vladimir, >>> >>> thanks for pushing the change! >>> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] >>>> Sent: Mittwoch, 21. Oktober 2015 17:10 >>>> To: Lindenmaier, Goetz; hotspot compiler >>>> Subject: Re: RFR(XS): 8140239: Fix product build after "8132168: Support >>>> IdealGraphVisualizer in optimized build" >>>> >>>> Sure, looks good. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 10/21/15 5:34 PM, Lindenmaier, Goetz wrote: >>>>> Hi Vladimir, >>>>> >>>>> I just tried to implement the same behavior as with 'develop'. >>>>> But excluding the flag altogether is fine with me, too: >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8140239-prodBld/webrev.01/ >>>>> I put in you as reviewer, if that's ok. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] >>>>>> Sent: Mittwoch, 21. Oktober 2015 15:45 >>>>>> To: Lindenmaier, Goetz; hotspot compiler >>>>>> Subject: Re: RFR(XS): 8140239: Fix product build after "8132168: Support >>>>>> IdealGraphVisualizer in optimized build" >>>>>> >>>>>> Goetz, thanks for spotting that! >>>>>> >>>>>> Why not simply exclude IGVPrintLevel in product binaries instead? >>>>>> >>>>>> - cflags(IGVPrintLevel, intx, PrintIdealGraphLevel, >>>>>> IGVPrintLevel) \ >>>>>> + NOT_PRODUCT(cflags(IGVPrintLevel, intx, PrintIdealGraphLevel, >>>>>> IGVPrintLevel)) \ >>>>>> >>>>>> IGVPrintLevel is used only in non-product code and PrintIdealGraphLevel >>>>>> functionality is not available in product builds. >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> PS: I'm surprised the problem wasn't caught by JPRT. Shouldn't the >>>>>> merged version be tested? It looks like the merge [1] happened after the >>>>>> job finished. (FTR I had to restart the job due to a timeout.) >>>>>> >>>>>> [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/03fa0a35a468 >>>>>> >>>>>> On 10/21/15 3:50 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> After "8132168: Support IdealGraphVisualizer in optimized build" the >>>>>>> product build is broken: >>>>>>> compilerDirectives.cpp:181: error: 'PrintIdealGraphLevel' was not >>>>>>> declared in this scope >>>>>>> >>>>>>> 8132168 changes the flag from 'develop' to 'notproduct'. 'Notproduct' >>>>>>> does not define >>>>>>> "const intx PrintIdealGraphLevel = 0;" in the product build, as >>>>>>> 'develop' did. >>>>>>> >>>>>>> I fixed this by wrapping the flag with NOT_PRODUCT: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8140239- >>>> prodBld/webrev.00/ >>>>>>> >>>>>>> Please review this change. I please need a sponsor. >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Goetz. >>>>>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Fri Oct 23 19:20:15 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 23 Oct 2015 19:20:15 +0000 Subject: RFR(XS): 8140239: Fix product build after "8132168: Support IdealGraphVisualizer in optimized build" In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC41E83B4C@DEWDFEMB12A.global.corp.sap> <562796D1.8000807@oracle.com> <4295855A5C1DE049A61835A1887419CC41E83C11@DEWDFEMB12A.global.corp.sap> <5627AAAB.10805@oracle.com> <4295855A5C1DE049A61835A1887419CC41E83F4B@DEWDFEMB12A.global.corp.sap> <5629A885.3030600@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41E8C985@DEWDFEMB12A.global.corp.sap> Hi, Yes, I think that is better, too. I just wanted to make the quick fix for the build, first. Thanks for further looking into this! Best regards, Goetz. From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Friday, October 23, 2015 8:40 PM To: Vladimir Kozlov Cc: Lindenmaier, Goetz ; hotspot compiler Subject: Re: RFR(XS): 8140239: Fix product build after "8132168: Support IdealGraphVisualizer in optimized build" On Oct 22, 2015, at 5:24 PM, Vladimir Kozlov > wrote: On 10/23/15 7:47 AM, Christian Thalinger wrote: Why are we prefixing flags with CONST_ in product builds? It was your change: 8024545: make develop and notproduct flag values available in product builds http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.hpp.udiff.html Damn. I knew it :-) I vaguely remember that I did that because of getting the flag address for the flag table. But this works as well: diff -r bc48b669bc66 src/share/vm/runtime/globals.cpp --- a/src/share/vm/runtime/globals.cpp Mon Oct 19 00:24:58 2015 -0700 +++ b/src/share/vm/runtime/globals.cpp Fri Oct 23 08:35:34 2015 -1000 @@ -536,7 +536,7 @@ const char* Flag::flag_error_str(Flag::E // 4991491 do not "optimize out" the was_set false values: omitting them // tickles a Microsoft compiler bug causing flagTable to be malformed -#define NAME(name) NOT_PRODUCT(&name) PRODUCT_ONLY(&CONST_##name) +#define NAME(name) (void*)&name #define RUNTIME_PRODUCT_FLAG_STRUCT( type, name, value, doc) { #type, XSTR(name), &name, NOT_PRODUCT_ARG(doc) Flag::Flags(Flag::DEFAULT | Flag::KIND_PRODUCT) }, #define RUNTIME_PD_PRODUCT_FLAG_STRUCT( type, name, doc) { #type, XSTR(name), &name, NOT_PRODUCT_ARG(doc) Flag::Flags(Flag::DEFAULT | Flag::KIND_PRODUCT | Flag::KIND_PLATFORM_DEPENDENT) }, diff -r bc48b669bc66 src/share/vm/runtime/globals.hpp --- a/src/share/vm/runtime/globals.hpp Mon Oct 19 00:24:58 2015 -0700 +++ b/src/share/vm/runtime/globals.hpp Fri Oct 23 08:35:34 2015 -1000 @@ -4129,9 +4129,9 @@ public: #define DECLARE_MANAGEABLE_FLAG(type, name, value, doc) extern "C" type name; #define DECLARE_PRODUCT_RW_FLAG(type, name, value, doc) extern "C" type name; #ifdef PRODUCT -#define DECLARE_DEVELOPER_FLAG(type, name, value, doc) extern "C" type CONST_##name; const type name = value; -#define DECLARE_PD_DEVELOPER_FLAG(type, name, doc) extern "C" type CONST_##name; const type name = pd_##name; -#define DECLARE_NOTPRODUCT_FLAG(type, name, value, doc) extern "C" type CONST_##name; +#define DECLARE_DEVELOPER_FLAG(type, name, value, doc) const type name = value; +#define DECLARE_PD_DEVELOPER_FLAG(type, name, doc) const type name = pd_##name; +#define DECLARE_NOTPRODUCT_FLAG(type, name, value, doc) const type name = value; #else #define DECLARE_DEVELOPER_FLAG(type, name, value, doc) extern "C" type name; #define DECLARE_PD_DEVELOPER_FLAG(type, name, doc) extern "C" type name; @@ -4152,9 +4152,9 @@ public: #define MATERIALIZE_MANAGEABLE_FLAG(type, name, value, doc) type name = value; #define MATERIALIZE_PRODUCT_RW_FLAG(type, name, value, doc) type name = value; #ifdef PRODUCT -#define MATERIALIZE_DEVELOPER_FLAG(type, name, value, doc) type CONST_##name = value; -#define MATERIALIZE_PD_DEVELOPER_FLAG(type, name, doc) type CONST_##name = pd_##name; -#define MATERIALIZE_NOTPRODUCT_FLAG(type, name, value, doc) type CONST_##name = value; +#define MATERIALIZE_DEVELOPER_FLAG(type, name, value, doc) +#define MATERIALIZE_PD_DEVELOPER_FLAG(type, name, doc) +#define MATERIALIZE_NOTPRODUCT_FLAG(type, name, value, doc) #else #define MATERIALIZE_DEVELOPER_FLAG(type, name, value, doc) type name = value; #define MATERIALIZE_PD_DEVELOPER_FLAG(type, name, doc) type name = pd_##name; I think we should do that and not make flags conditional like the fix for this bug. Vladimir #ifdef PRODUCT #define MATERIALIZE_DEVELOPER_FLAG(type, name, value, doc) type CONST_##name = value; #define MATERIALIZE_PD_DEVELOPER_FLAG(type, name, doc) type CONST_##name = pd_##name; #define MATERIALIZE_NOTPRODUCT_FLAG(type, name, value, doc) type CONST_##name = value; #else Is it to find uses of developer/notproduct flags in product code? Does it even matter? On Oct 21, 2015, at 8:13 PM, Lindenmaier, Goetz > wrote: Hi Vladimir, thanks for pushing the change! Best regards, Goetz. -----Original Message----- From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] Sent: Mittwoch, 21. Oktober 2015 17:10 To: Lindenmaier, Goetz; hotspot compiler Subject: Re: RFR(XS): 8140239: Fix product build after "8132168: Support IdealGraphVisualizer in optimized build" Sure, looks good. Best regards, Vladimir Ivanov On 10/21/15 5:34 PM, Lindenmaier, Goetz wrote: Hi Vladimir, I just tried to implement the same behavior as with 'develop'. But excluding the flag altogether is fine with me, too: http://cr.openjdk.java.net/~goetz/webrevs/8140239-prodBld/webrev.01/ I put in you as reviewer, if that's ok. Best regards, Goetz. -----Original Message----- From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] Sent: Mittwoch, 21. Oktober 2015 15:45 To: Lindenmaier, Goetz; hotspot compiler Subject: Re: RFR(XS): 8140239: Fix product build after "8132168: Support IdealGraphVisualizer in optimized build" Goetz, thanks for spotting that! Why not simply exclude IGVPrintLevel in product binaries instead? - cflags(IGVPrintLevel, intx, PrintIdealGraphLevel, IGVPrintLevel) \ + NOT_PRODUCT(cflags(IGVPrintLevel, intx, PrintIdealGraphLevel, IGVPrintLevel)) \ IGVPrintLevel is used only in non-product code and PrintIdealGraphLevel functionality is not available in product builds. Best regards, Vladimir Ivanov PS: I'm surprised the problem wasn't caught by JPRT. Shouldn't the merged version be tested? It looks like the merge [1] happened after the job finished. (FTR I had to restart the job due to a timeout.) [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/03fa0a35a468 On 10/21/15 3:50 PM, Lindenmaier, Goetz wrote: Hi, After "8132168: Support IdealGraphVisualizer in optimized build" the product build is broken: compilerDirectives.cpp:181: error: 'PrintIdealGraphLevel' was not declared in this scope 8132168 changes the flag from 'develop' to 'notproduct'. 'Notproduct' does not define "const intx PrintIdealGraphLevel = 0;" in the product build, as 'develop' did. I fixed this by wrapping the flag with NOT_PRODUCT: http://cr.openjdk.java.net/~goetz/webrevs/8140239- prodBld/webrev.00/ Please review this change. I please need a sponsor. Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Fri Oct 23 20:36:00 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 23 Oct 2015 10:36:00 -1000 Subject: RFR(XS): 8140239: Fix product build after "8132168: Support IdealGraphVisualizer in optimized build" In-Reply-To: <4295855A5C1DE049A61835A1887419CC41E8C985@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC41E83B4C@DEWDFEMB12A.global.corp.sap> <562796D1.8000807@oracle.com> <4295855A5C1DE049A61835A1887419CC41E83C11@DEWDFEMB12A.global.corp.sap> <5627AAAB.10805@oracle.com> <4295855A5C1DE049A61835A1887419CC41E83F4B@DEWDFEMB12A.global.corp.sap> <5629A885.3030600@oracle.com> <4295855A5C1DE049A61835A1887419CC41E8C985@DEWDFEMB12A.global.corp.sap> Message-ID: <239649EC-3D07-40D6-A5DD-80ABBEA903D9@oracle.com> > On Oct 23, 2015, at 9:20 AM, Lindenmaier, Goetz wrote: > > Hi, > > Yes, I think that is better, too. > I just wanted to make the quick fix for the build, first. Sure. Let me file an enhancement for what I proposed? https://bugs.openjdk.java.net/browse/JDK-8140424 > > Thanks for further looking into this! > > Best regards, > Goetz. > > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Friday, October 23, 2015 8:40 PM > To: Vladimir Kozlov > Cc: Lindenmaier, Goetz ; hotspot compiler > Subject: Re: RFR(XS): 8140239: Fix product build after "8132168: Support IdealGraphVisualizer in optimized build" > > > On Oct 22, 2015, at 5:24 PM, Vladimir Kozlov > wrote: > > On 10/23/15 7:47 AM, Christian Thalinger wrote: > > Why are we prefixing flags with CONST_ in product builds? > > It was your change: > 8024545: make develop and notproduct flag values available in product builds > http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.hpp.udiff.html > > Damn. I knew it :-) > > I vaguely remember that I did that because of getting the flag address for the flag table. But this works as well: > > diff -r bc48b669bc66 src/share/vm/runtime/globals.cpp > --- a/src/share/vm/runtime/globals.cpp Mon Oct 19 00:24:58 2015 -0700 > +++ b/src/share/vm/runtime/globals.cpp Fri Oct 23 08:35:34 2015 -1000 > @@ -536,7 +536,7 @@ const char* Flag::flag_error_str(Flag::E > // 4991491 do not "optimize out" the was_set false values: omitting them > // tickles a Microsoft compiler bug causing flagTable to be malformed > > -#define NAME(name) NOT_PRODUCT(&name) PRODUCT_ONLY(&CONST_##name) > +#define NAME(name) (void*)&name > > #define RUNTIME_PRODUCT_FLAG_STRUCT( type, name, value, doc) { #type, XSTR(name), &name, NOT_PRODUCT_ARG(doc) Flag::Flags(Flag::DEFAULT | Flag::KIND_PRODUCT) }, > #define RUNTIME_PD_PRODUCT_FLAG_STRUCT( type, name, doc) { #type, XSTR(name), &name, NOT_PRODUCT_ARG(doc) Flag::Flags(Flag::DEFAULT | Flag::KIND_PRODUCT | Flag::KIND_PLATFORM_DEPENDENT) }, > diff -r bc48b669bc66 src/share/vm/runtime/globals.hpp > --- a/src/share/vm/runtime/globals.hpp Mon Oct 19 00:24:58 2015 -0700 > +++ b/src/share/vm/runtime/globals.hpp Fri Oct 23 08:35:34 2015 -1000 > @@ -4129,9 +4129,9 @@ public: > #define DECLARE_MANAGEABLE_FLAG(type, name, value, doc) extern "C" type name; > #define DECLARE_PRODUCT_RW_FLAG(type, name, value, doc) extern "C" type name; > #ifdef PRODUCT > -#define DECLARE_DEVELOPER_FLAG(type, name, value, doc) extern "C" type CONST_##name; const type name = value; > -#define DECLARE_PD_DEVELOPER_FLAG(type, name, doc) extern "C" type CONST_##name; const type name = pd_##name; > -#define DECLARE_NOTPRODUCT_FLAG(type, name, value, doc) extern "C" type CONST_##name; > +#define DECLARE_DEVELOPER_FLAG(type, name, value, doc) const type name = value; > +#define DECLARE_PD_DEVELOPER_FLAG(type, name, doc) const type name = pd_##name; > +#define DECLARE_NOTPRODUCT_FLAG(type, name, value, doc) const type name = value; > #else > #define DECLARE_DEVELOPER_FLAG(type, name, value, doc) extern "C" type name; > #define DECLARE_PD_DEVELOPER_FLAG(type, name, doc) extern "C" type name; > @@ -4152,9 +4152,9 @@ public: > #define MATERIALIZE_MANAGEABLE_FLAG(type, name, value, doc) type name = value; > #define MATERIALIZE_PRODUCT_RW_FLAG(type, name, value, doc) type name = value; > #ifdef PRODUCT > -#define MATERIALIZE_DEVELOPER_FLAG(type, name, value, doc) type CONST_##name = value; > -#define MATERIALIZE_PD_DEVELOPER_FLAG(type, name, doc) type CONST_##name = pd_##name; > -#define MATERIALIZE_NOTPRODUCT_FLAG(type, name, value, doc) type CONST_##name = value; > +#define MATERIALIZE_DEVELOPER_FLAG(type, name, value, doc) > +#define MATERIALIZE_PD_DEVELOPER_FLAG(type, name, doc) > +#define MATERIALIZE_NOTPRODUCT_FLAG(type, name, value, doc) > #else > #define MATERIALIZE_DEVELOPER_FLAG(type, name, value, doc) type name = value; > #define MATERIALIZE_PD_DEVELOPER_FLAG(type, name, doc) type name = pd_##name; > > I think we should do that and not make flags conditional like the fix for this bug. > > > > Vladimir > > > > #ifdef PRODUCT > #define MATERIALIZE_DEVELOPER_FLAG(type, name, value, doc) type CONST_##name = value; > #define MATERIALIZE_PD_DEVELOPER_FLAG(type, name, doc) type CONST_##name = pd_##name; > #define MATERIALIZE_NOTPRODUCT_FLAG(type, name, value, doc) type CONST_##name = value; > #else > > Is it to find uses of developer/notproduct flags in product code? Does it even matter? > > > On Oct 21, 2015, at 8:13 PM, Lindenmaier, Goetz > wrote: > > Hi Vladimir, > > thanks for pushing the change! > > Best regards, > Goetz. > > > -----Original Message----- > From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com ] > Sent: Mittwoch, 21. Oktober 2015 17:10 > To: Lindenmaier, Goetz; hotspot compiler > Subject: Re: RFR(XS): 8140239: Fix product build after "8132168: Support > IdealGraphVisualizer in optimized build" > > Sure, looks good. > > Best regards, > Vladimir Ivanov > > On 10/21/15 5:34 PM, Lindenmaier, Goetz wrote: > > Hi Vladimir, > > I just tried to implement the same behavior as with 'develop'. > But excluding the flag altogether is fine with me, too: > http://cr.openjdk.java.net/~goetz/webrevs/8140239-prodBld/webrev.01/ > I put in you as reviewer, if that's ok. > > Best regards, > Goetz. > > > > > > -----Original Message----- > From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com ] > Sent: Mittwoch, 21. Oktober 2015 15:45 > To: Lindenmaier, Goetz; hotspot compiler > Subject: Re: RFR(XS): 8140239: Fix product build after "8132168: Support > IdealGraphVisualizer in optimized build" > > Goetz, thanks for spotting that! > > Why not simply exclude IGVPrintLevel in product binaries instead? > > - cflags(IGVPrintLevel, intx, PrintIdealGraphLevel, > IGVPrintLevel) \ > + NOT_PRODUCT(cflags(IGVPrintLevel, intx, PrintIdealGraphLevel, > IGVPrintLevel)) \ > > IGVPrintLevel is used only in non-product code and PrintIdealGraphLevel > functionality is not available in product builds. > > Best regards, > Vladimir Ivanov > > PS: I'm surprised the problem wasn't caught by JPRT. Shouldn't the > merged version be tested? It looks like the merge [1] happened after the > job finished. (FTR I had to restart the job due to a timeout.) > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/03fa0a35a468 > > On 10/21/15 3:50 PM, Lindenmaier, Goetz wrote: > > Hi, > > After "8132168: Support IdealGraphVisualizer in optimized build" the > product build is broken: > compilerDirectives.cpp:181: error: 'PrintIdealGraphLevel' was not > declared in this scope > > 8132168 changes the flag from 'develop' to 'notproduct'. 'Notproduct' > does not define > "const intx PrintIdealGraphLevel = 0;" in the product build, as > 'develop' did. > > I fixed this by wrapping the flag with NOT_PRODUCT: > > http://cr.openjdk.java.net/~goetz/webrevs/8140239- > prodBld/webrev.00/ > > > Please review this change. I please need a sponsor. > > Best regards, > > Goetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Fri Oct 23 20:39:47 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 23 Oct 2015 10:39:47 -1000 Subject: RFR (S): 8140343: SEGV in DirectivesStack::getMatchingDirective In-Reply-To: <5629F7FC.7090008@oracle.com> References: <5629F7FC.7090008@oracle.com> Message-ID: <4CEF759F-3981-438A-B62C-9A7C30B32259@oracle.com> > On Oct 22, 2015, at 11:03 PM, Nils Eliasson wrote: > > Hi all, > > This fixes a bug when using a compiler that doesn't have compiler directives. This is a temporary fix using the default directive for c1. What are the default directives for C1 and C2? This fix is for JVMCI compilers and JVMCI compilers can only replace C2 in a tiered configuration. Depending on what they are, wouldn?t it make more sense to use C2?s default directives? > In the future permanent fix all compilers will have directives by default. How would that look like? > > bug: https://bugs.openjdk.java.net/browse/JDK-8140343 > webrev: http://cr.openjdk.java.net/~neliasso/8140343/webrev.01/ > > Please review, > Nils From christian.thalinger at oracle.com Fri Oct 23 23:12:11 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 23 Oct 2015 13:12:11 -1000 Subject: RFR (XL): 8139170: JVMCI refresh In-Reply-To: <561F2292.4050602@oracle.com> References: <6ECC12F2-8693-43AD-8F08-B7E3F21AEB40@oracle.com> <561C863D.7080800@oracle.com> <48004E32-6D60-4E40-9FF0-F0E4148D0344@oracle.com> <561E1A6C.7060306@oracle.com> <3539A5FA-A879-424B-B3C1-4BF11A98ACE1@oracle.com> <634083B2-FA94-4A10-85A8-DC8F2DED7F3A@oracle.com> <561F2292.4050602@oracle.com> Message-ID: I?ve updated the webrev with fixes from SQE for the tests which were failing due to changes the visibility of some internal classes and methods: http://cr.openjdk.java.net/~twisti/8139170/webrev/ > On Oct 14, 2015, at 5:50 PM, Vladimir Kozlov wrote: > > Okay. > > Thanks, > Vladimir > > On 10/15/15 8:37 AM, Christian Thalinger wrote: >> I have pulled two SPARC changes: >> >> http://lafo.ssw.uni-linz.ac.at/hg/graal-jvmci-9/rev/c158981b3c59 >> http://lafo.ssw.uni-linz.ac.at/hg/graal-jvmci-9/rev/110a130aa88b >> >> and updated the webrev to include (actually exclude) the individual bug fixes pushed to hs-comp. >> >>> On Oct 14, 2015, at 8:55 AM, Christian Thalinger wrote: >>> >>> >>>> On Oct 13, 2015, at 11:03 PM, Vladimir Kozlov wrote: >>>> >>>>>> It would be good if we would run at least one JVMCI test in JPRT. >>>> >>>> If they are stable you can add them (compiler/jvmci for all) to hotspot_compiler_3 in test/TEST.groups >>> >>> I?ll let Igor I. do that. >>> >>>> >>>> Changes looks good. >>> >>> Thanks. >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/14/15 2:31 AM, Christian Thalinger wrote: >>>>> webrev updated. >>>>> >>>>>> On Oct 13, 2015, at 8:01 AM, Christian Thalinger >>>>>> >>>>> > wrote: >>>>>> >>>>>>> >>>>>>> On Oct 12, 2015, at 10:59 PM, Doug Simon >>>>>> > wrote: >>>>>>> >>>>>>>> >>>>>>>> On 13 Oct 2015, at 06:19, Vladimir Kozlov >>>>>>>> > wrote: >>>>>>>> >>>>>>>> Since we will get more changes from labs later we may enumerate >>>>>>>> them: JVMCI refresh 1. >>>>>>> >>>>>>> Or, pessimistically, JVMCI refresh 01 ;-) >>>>>>> >>>>>>>> Can you explain new sed command in Gensrc-jdk.vm.ci.gmk. >>>>>>> >>>>>>> http://hg.openjdk.java.net/graal/graal-jvmci-8/rev/1852abfbaca3 >>>>>>> >>>>>>>> Are you sure it works on windows? >>>>>>> >>>>>>> I can?t say for sure but given that I see similar patterns in other >>>>>>> *.gmk files, I think it should be fine. >>>>>> >>>>>> It would be good if we would run at least one JVMCI test in JPRT. >>>>>> >>>>>>> >>>>>>>> Instead of is_trivial(method) may be we should have general function >>>>>>>> called from AdvancedThresholdPolicy::common() which return >>>>>>>> compilation level for particular method (for example, we can also >>>>>>>> limit it using compilecommand). Could be done as separate change >>>>>>>> after this. >>>>>>>> >>>>>>>> I looked on jdk.vm.ci changes and nothing looks terrible wrong. I am >>>>>>>> not familiar with it so I can't say that each line is correct. One >>>>>>>> thing I am wondering is why explicit imports are used instead of .* >>>>>>>> (compilation speed?): >>>>>>> >>>>>>> http://mail.openjdk.java.net/pipermail/graal-dev/2015-September/003546.html >>>>>>> >>>>>>>> -import java.lang.annotation.*; >>>>>>>> +import java.lang.annotation.ElementType; >>>>>>>> +import java.lang.annotation.Retention; >>>>>>>> +import java.lang.annotation.RetentionPolicy; >>>>>>>> +import java.lang.annotation.Target; >>>>>>>> >>>>>>>> An other thing is using AMD64/amd64 in files and directory names. >>>>>>>> May be we should rename it to x64. >>>>>>>> >>>>>>>> jvmciCodeInstaller_x86.cpp and jvmciCodeInstaller.cpp has next pattern: >>>>>>>> + if (HotSpotMetaspaceConstantImpl::compressed(constant)) { >>>>>>>> +#ifdef _LP64 >>>>>>>> + ... >>>>>>>> +#else >>>>>>>> + fatal("unexpected compressed Klass* in 32-bit mode"); >>>>>>>> +#endif >>>>>>>> + } else { >>>>>>>> >>>>>>>> It would be nice to hide fatal() in some wrapper function. >>>>>>>> >>>>>>>> jvmciEnv.cpp use ASSERT instead of DEBUG. We renamed ifdef DEBUG >>>>>>>> long ago. >>>>>>>> >>>>>>>> globals.hpp changes conflict with 8139377. >>>>>>> >>>>>>> Then we should adopt 8139377 instead. >>>>>> >>>>>> When I created the review 8139377 was not integrated yet. Let me pull >>>>>> again. >>>>>> >>>>>>> >>>>>>>> Tests changes (mostly renaming) looks fine. >>>>>>>> >>>>>>>> Fix copyright years (2015, 2015) in new files. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 10/13/15 10:19 AM, Christian Thalinger wrote: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8139170 >>>>>>>>> http://cr.openjdk.java.net/~twisti/8139170/webrev/ >>>>>>>>> >>>>>>>>> During the review period for JEP 243 there were some changes and >>>>>>>>> enhancements to the JVMCI code done by Oracle Labs. In order to not >>>>>>>>> disturb the already long and complicated review of JEP 243 we >>>>>>>>> decided to do a refresh after the initial integration. >>>>>>>>> >>>>>>>>> A lot of the Java changes is switching to using explicit imports. >>>>> >>> >> From vladimir.kozlov at oracle.com Sat Oct 24 02:53:19 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 24 Oct 2015 10:53:19 +0800 Subject: RFR(XS): 8140239: Fix product build after "8132168: Support IdealGraphVisualizer in optimized build" In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC41E83B4C@DEWDFEMB12A.global.corp.sap> <562796D1.8000807@oracle.com> <4295855A5C1DE049A61835A1887419CC41E83C11@DEWDFEMB12A.global.corp.sap> <5627AAAB.10805@oracle.com> <4295855A5C1DE049A61835A1887419CC41E83F4B@DEWDFEMB12A.global.corp.sap> <5629A885.3030600@oracle.com> Message-ID: <562AF29F.9080004@oracle.com> > +#define NAME(name) (void*)&name If it works with all C++ compilers I am fine with it. Thanks, Vladimir On 10/24/15 2:39 AM, Christian Thalinger wrote: > >> On Oct 22, 2015, at 5:24 PM, Vladimir Kozlov >> > wrote: >> >> On 10/23/15 7:47 AM, Christian Thalinger wrote: >>> Why are we prefixing flags with CONST_ in product builds? >> >> It was your change: >> 8024545: make develop and notproduct flag values available in product >> builds >> http://cr.openjdk.java.net/~twisti/8024545/webrev/src/share/vm/runtime/globals.hpp.udiff.html > > Damn. I knew it :-) > > I vaguely remember that I did that because of getting the flag address > for the flag table. But this works as well: > > diff -r bc48b669bc66 src/share/vm/runtime/globals.cpp > --- a/src/share/vm/runtime/globals.cppMon Oct 19 00:24:58 2015 -0700 > +++ b/src/share/vm/runtime/globals.cppFri Oct 23 08:35:34 2015 -1000 > @@ -536,7 +536,7 @@ const char* Flag::flag_error_str(Flag::E > // 4991491 do not "optimize out" the was_set false values: omitting them > // tickles a Microsoft compiler bug causing flagTable to be malformed > > > -#define NAME(name) NOT_PRODUCT(&name) PRODUCT_ONLY(&CONST_##name) > +#define NAME(name) (void*)&name > > > #define RUNTIME_PRODUCT_FLAG_STRUCT( type, name, value, doc) { > #type, XSTR(name), &name, NOT_PRODUCT_ARG(doc) > Flag::Flags(Flag::DEFAULT | Flag::KIND_PRODUCT) }, > #define RUNTIME_PD_PRODUCT_FLAG_STRUCT( type, name, doc) { > #type, XSTR(name), &name, NOT_PRODUCT_ARG(doc) > Flag::Flags(Flag::DEFAULT | Flag::KIND_PRODUCT | > Flag::KIND_PLATFORM_DEPENDENT) }, > diff -r bc48b669bc66 src/share/vm/runtime/globals.hpp > --- a/src/share/vm/runtime/globals.hppMon Oct 19 00:24:58 2015 -0700 > +++ b/src/share/vm/runtime/globals.hppFri Oct 23 08:35:34 2015 -1000 > @@ -4129,9 +4129,9 @@ public: > #define DECLARE_MANAGEABLE_FLAG(type, name, value, doc) extern "C" > type name; > #define DECLARE_PRODUCT_RW_FLAG(type, name, value, doc) extern "C" > type name; > #ifdef PRODUCT > -#define DECLARE_DEVELOPER_FLAG(type, name, value, doc) extern "C" > type CONST_##name; const type name = value; > -#define DECLARE_PD_DEVELOPER_FLAG(type, name, doc) extern "C" > type CONST_##name; const type name = pd_##name; > -#define DECLARE_NOTPRODUCT_FLAG(type, name, value, doc) extern "C" > type CONST_##name; > +#define DECLARE_DEVELOPER_FLAG(type, name, value, doc) const type > name = value; > +#define DECLARE_PD_DEVELOPER_FLAG(type, name, doc) const type > name = pd_##name; > +#define DECLARE_NOTPRODUCT_FLAG(type, name, value, doc) const type > name = value; > #else > #define DECLARE_DEVELOPER_FLAG(type, name, value, doc) extern "C" > type name; > #define DECLARE_PD_DEVELOPER_FLAG(type, name, doc) extern "C" > type name; > @@ -4152,9 +4152,9 @@ public: > #define MATERIALIZE_MANAGEABLE_FLAG(type, name, value, doc) type > name = value; > #define MATERIALIZE_PRODUCT_RW_FLAG(type, name, value, doc) type > name = value; > #ifdef PRODUCT > -#define MATERIALIZE_DEVELOPER_FLAG(type, name, value, doc) type > CONST_##name = value; > -#define MATERIALIZE_PD_DEVELOPER_FLAG(type, name, doc) type > CONST_##name = pd_##name; > -#define MATERIALIZE_NOTPRODUCT_FLAG(type, name, value, doc) type > CONST_##name = value; > +#define MATERIALIZE_DEVELOPER_FLAG(type, name, value, doc) > +#define MATERIALIZE_PD_DEVELOPER_FLAG(type, name, doc) > +#define MATERIALIZE_NOTPRODUCT_FLAG(type, name, value, doc) > #else > #define MATERIALIZE_DEVELOPER_FLAG(type, name, value, doc) type > name = value; > #define MATERIALIZE_PD_DEVELOPER_FLAG(type, name, doc) type > name = pd_##name; > > I think we should do that and not make flags conditional like the fix > for this bug. > >> >> Vladimir >> >>> >>> #ifdef PRODUCT >>> #define MATERIALIZE_DEVELOPER_FLAG(type, name, value, doc) type >>> CONST_##name = value; >>> #define MATERIALIZE_PD_DEVELOPER_FLAG(type, name, doc) type >>> CONST_##name = pd_##name; >>> #define MATERIALIZE_NOTPRODUCT_FLAG(type, name, value, doc) type >>> CONST_##name = value; >>> #else >>> >>> Is it to find uses of developer/notproduct flags in product code? >>> Does it even matter? >>> >>>> On Oct 21, 2015, at 8:13 PM, Lindenmaier, Goetz >>>> > wrote: >>>> >>>> Hi Vladimir, >>>> >>>> thanks for pushing the change! >>>> >>>> Best regards, >>>> Goetz. >>>> >>>>> -----Original Message----- >>>>> From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] >>>>> Sent: Mittwoch, 21. Oktober 2015 17:10 >>>>> To: Lindenmaier, Goetz; hotspot compiler >>>>> Subject: Re: RFR(XS): 8140239: Fix product build after "8132168: >>>>> Support >>>>> IdealGraphVisualizer in optimized build" >>>>> >>>>> Sure, looks good. >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 10/21/15 5:34 PM, Lindenmaier, Goetz wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> I just tried to implement the same behavior as with 'develop'. >>>>>> But excluding the flag altogether is fine with me, too: >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8140239-prodBld/webrev.01/ >>>>>> I put in you as reviewer, if that's ok. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] >>>>>>> Sent: Mittwoch, 21. Oktober 2015 15:45 >>>>>>> To: Lindenmaier, Goetz; hotspot compiler >>>>>>> Subject: Re: RFR(XS): 8140239: Fix product build after "8132168: >>>>>>> Support >>>>>>> IdealGraphVisualizer in optimized build" >>>>>>> >>>>>>> Goetz, thanks for spotting that! >>>>>>> >>>>>>> Why not simply exclude IGVPrintLevel in product binaries instead? >>>>>>> >>>>>>> - cflags(IGVPrintLevel, intx, PrintIdealGraphLevel, >>>>>>> IGVPrintLevel) \ >>>>>>> + NOT_PRODUCT(cflags(IGVPrintLevel, intx, PrintIdealGraphLevel, >>>>>>> IGVPrintLevel)) \ >>>>>>> >>>>>>> IGVPrintLevel is used only in non-product code and >>>>>>> PrintIdealGraphLevel >>>>>>> functionality is not available in product builds. >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>> PS: I'm surprised the problem wasn't caught by JPRT. Shouldn't the >>>>>>> merged version be tested? It looks like the merge [1] happened >>>>>>> after the >>>>>>> job finished. (FTR I had to restart the job due to a timeout.) >>>>>>> >>>>>>> [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/03fa0a35a468 >>>>>>> >>>>>>> On 10/21/15 3:50 PM, Lindenmaier, Goetz wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> After "8132168: Support IdealGraphVisualizer in optimized build" the >>>>>>>> product build is broken: >>>>>>>> compilerDirectives.cpp:181: error: 'PrintIdealGraphLevel' was not >>>>>>>> declared in this scope >>>>>>>> >>>>>>>> 8132168 changes the flag from 'develop' to 'notproduct'. >>>>>>>> 'Notproduct' >>>>>>>> does not define >>>>>>>> "const intx PrintIdealGraphLevel = 0;" in the product build, as >>>>>>>> 'develop' did. >>>>>>>> >>>>>>>> I fixed this by wrapping the flag with NOT_PRODUCT: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8140239- >>>>> prodBld/webrev.00/ >>>>>>>> >>>>>>>> Please review this change. I please need a sponsor. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Goetz. >>>>>>>> >>> > From vladimir.kozlov at oracle.com Sat Oct 24 03:09:33 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 24 Oct 2015 11:09:33 +0800 Subject: RFR (XL): 8139170: JVMCI refresh In-Reply-To: References: <6ECC12F2-8693-43AD-8F08-B7E3F21AEB40@oracle.com> <561C863D.7080800@oracle.com> <48004E32-6D60-4E40-9FF0-F0E4148D0344@oracle.com> <561E1A6C.7060306@oracle.com> <3539A5FA-A879-424B-B3C1-4BF11A98ACE1@oracle.com> <634083B2-FA94-4A10-85A8-DC8F2DED7F3A@oracle.com> <561F2292.4050602@oracle.com> Message-ID: <562AF66D.6050908@oracle.com> Good. Thanks, Vladimir On 10/24/15 7:12 AM, Christian Thalinger wrote: > I?ve updated the webrev with fixes from SQE for the tests which were failing due to changes the visibility of some internal classes and methods: > > http://cr.openjdk.java.net/~twisti/8139170/webrev/ > >> On Oct 14, 2015, at 5:50 PM, Vladimir Kozlov wrote: >> >> Okay. >> >> Thanks, >> Vladimir >> >> On 10/15/15 8:37 AM, Christian Thalinger wrote: >>> I have pulled two SPARC changes: >>> >>> http://lafo.ssw.uni-linz.ac.at/hg/graal-jvmci-9/rev/c158981b3c59 >>> http://lafo.ssw.uni-linz.ac.at/hg/graal-jvmci-9/rev/110a130aa88b >>> >>> and updated the webrev to include (actually exclude) the individual bug fixes pushed to hs-comp. >>> >>>> On Oct 14, 2015, at 8:55 AM, Christian Thalinger wrote: >>>> >>>> >>>>> On Oct 13, 2015, at 11:03 PM, Vladimir Kozlov wrote: >>>>> >>>>>>> It would be good if we would run at least one JVMCI test in JPRT. >>>>> >>>>> If they are stable you can add them (compiler/jvmci for all) to hotspot_compiler_3 in test/TEST.groups >>>> >>>> I?ll let Igor I. do that. >>>> >>>>> >>>>> Changes looks good. >>>> >>>> Thanks. >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/14/15 2:31 AM, Christian Thalinger wrote: >>>>>> webrev updated. >>>>>> >>>>>>> On Oct 13, 2015, at 8:01 AM, Christian Thalinger >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>>> >>>>>>>> On Oct 12, 2015, at 10:59 PM, Doug Simon >>>>>>> > wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On 13 Oct 2015, at 06:19, Vladimir Kozlov >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> Since we will get more changes from labs later we may enumerate >>>>>>>>> them: JVMCI refresh 1. >>>>>>>> >>>>>>>> Or, pessimistically, JVMCI refresh 01 ;-) >>>>>>>> >>>>>>>>> Can you explain new sed command in Gensrc-jdk.vm.ci.gmk. >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/graal/graal-jvmci-8/rev/1852abfbaca3 >>>>>>>> >>>>>>>>> Are you sure it works on windows? >>>>>>>> >>>>>>>> I can?t say for sure but given that I see similar patterns in other >>>>>>>> *.gmk files, I think it should be fine. >>>>>>> >>>>>>> It would be good if we would run at least one JVMCI test in JPRT. >>>>>>> >>>>>>>> >>>>>>>>> Instead of is_trivial(method) may be we should have general function >>>>>>>>> called from AdvancedThresholdPolicy::common() which return >>>>>>>>> compilation level for particular method (for example, we can also >>>>>>>>> limit it using compilecommand). Could be done as separate change >>>>>>>>> after this. >>>>>>>>> >>>>>>>>> I looked on jdk.vm.ci changes and nothing looks terrible wrong. I am >>>>>>>>> not familiar with it so I can't say that each line is correct. One >>>>>>>>> thing I am wondering is why explicit imports are used instead of .* >>>>>>>>> (compilation speed?): >>>>>>>> >>>>>>>> http://mail.openjdk.java.net/pipermail/graal-dev/2015-September/003546.html >>>>>>>> >>>>>>>>> -import java.lang.annotation.*; >>>>>>>>> +import java.lang.annotation.ElementType; >>>>>>>>> +import java.lang.annotation.Retention; >>>>>>>>> +import java.lang.annotation.RetentionPolicy; >>>>>>>>> +import java.lang.annotation.Target; >>>>>>>>> >>>>>>>>> An other thing is using AMD64/amd64 in files and directory names. >>>>>>>>> May be we should rename it to x64. >>>>>>>>> >>>>>>>>> jvmciCodeInstaller_x86.cpp and jvmciCodeInstaller.cpp has next pattern: >>>>>>>>> + if (HotSpotMetaspaceConstantImpl::compressed(constant)) { >>>>>>>>> +#ifdef _LP64 >>>>>>>>> + ... >>>>>>>>> +#else >>>>>>>>> + fatal("unexpected compressed Klass* in 32-bit mode"); >>>>>>>>> +#endif >>>>>>>>> + } else { >>>>>>>>> >>>>>>>>> It would be nice to hide fatal() in some wrapper function. >>>>>>>>> >>>>>>>>> jvmciEnv.cpp use ASSERT instead of DEBUG. We renamed ifdef DEBUG >>>>>>>>> long ago. >>>>>>>>> >>>>>>>>> globals.hpp changes conflict with 8139377. >>>>>>>> >>>>>>>> Then we should adopt 8139377 instead. >>>>>>> >>>>>>> When I created the review 8139377 was not integrated yet. Let me pull >>>>>>> again. >>>>>>> >>>>>>>> >>>>>>>>> Tests changes (mostly renaming) looks fine. >>>>>>>>> >>>>>>>>> Fix copyright years (2015, 2015) in new files. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 10/13/15 10:19 AM, Christian Thalinger wrote: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8139170 >>>>>>>>>> http://cr.openjdk.java.net/~twisti/8139170/webrev/ >>>>>>>>>> >>>>>>>>>> During the review period for JEP 243 there were some changes and >>>>>>>>>> enhancements to the JVMCI code done by Oracle Labs. In order to not >>>>>>>>>> disturb the already long and complicated review of JEP 243 we >>>>>>>>>> decided to do a refresh after the initial integration. >>>>>>>>>> >>>>>>>>>> A lot of the Java changes is switching to using explicit imports. >>>>>> >>>> >>> > From nils.eliasson at oracle.com Sat Oct 24 08:49:31 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Sat, 24 Oct 2015 10:49:31 +0200 Subject: RFR (S): 8140343: SEGV in DirectivesStack::getMatchingDirective In-Reply-To: <4CEF759F-3981-438A-B62C-9A7C30B32259@oracle.com> References: <5629F7FC.7090008@oracle.com> <4CEF759F-3981-438A-B62C-9A7C30B32259@oracle.com> Message-ID: <562B461B.3000402@oracle.com> On 2015-10-23 22:39, Christian Thalinger wrote: >> On Oct 22, 2015, at 11:03 PM, Nils Eliasson wrote: >> >> Hi all, >> >> This fixes a bug when using a compiler that doesn't have compiler directives. This is a temporary fix using the default directive for c1. > What are the default directives for C1 and C2? This fix is for JVMCI compilers and JVMCI compilers can only replace C2 in a tiered configuration. Depending on what they are, wouldn?t it make more sense to use C2?s default directives? The default directive is a directive that is always installed, always enabled and contains all the default values from vmflags and compile commands. This is the directive all compilations are using if no additional directives are installed. > >> In the future permanent fix all compilers will have directives by default. > How would that look like? Long story. It is an internal implementation detail to the structure of compiler directives. Right now there is a bit of an overhead adding a new compiler, even if only a single flag is used. The idea is to have all directives contain all flags for all compilers - it might sound expensive but will actually be more efficient. The most common use case is only having the default directive, and in this case the common flags wouldn't have to be duplicated for each compiler. The profit in the JVMCI case is that all the common flags are valid and usable without any workaround. The improvement is straightforward and wont affect any use site but is big enough not to be the fix of this bug. //Nils >> bug: https://bugs.openjdk.java.net/browse/JDK-8140343 >> webrev: http://cr.openjdk.java.net/~neliasso/8140343/webrev.01/ >> >> Please review, >> Nils From christos at zoulas.com Sat Oct 24 13:13:05 2015 From: christos at zoulas.com (Christos Zoulas) Date: Sat, 24 Oct 2015 09:13:05 -0400 Subject: RFR(XS): 8140239: Fix product build after "8132168: Support IdealGraphVisualizer in optimized build" In-Reply-To: <562AF29F.9080004@oracle.com> from Vladimir Kozlov (Oct 24, 10:53am) Message-ID: <20151024131305.D83F717FDAB@rebar.astron.com> On Oct 24, 10:53am, vladimir.kozlov at oracle.com (Vladimir Kozlov) wrote: -- Subject: Re: RFR(XS): 8140239: Fix product build after "8132168: Support I | > +#define NAME(name) (void*)&name | | If it works with all C++ compilers I am fine with it. We should start using c++ casts... christos From nils.eliasson at oracle.com Mon Oct 26 09:54:22 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 26 Oct 2015 10:54:22 +0100 Subject: RFR(S): 8139996: CompileCommand prints quoted ascii strings Message-ID: <562DF84E.4080507@oracle.com> Hi all, This change makes method matchers (used by compile commands and compiler control) print symbols as utf8 instead of ascii. The print out of used commands will now look the same as the patterns the user has supplied. bug: https://bugs.openjdk.java.net/browse/JDK-8139996 webrev: http://cr.openjdk.java.net/~neliasso/8139996/webrev.01/ Please review, Nils Eliasson From vladimir.kozlov at oracle.com Mon Oct 26 12:54:14 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 26 Oct 2015 20:54:14 +0800 Subject: RFR(S): 8139996: CompileCommand prints quoted ascii strings In-Reply-To: <562DF84E.4080507@oracle.com> References: <562DF84E.4080507@oracle.com> Message-ID: <562E2276.8030501@oracle.com> Looks fine. Thanks, Vladimir On 10/26/15 5:54 PM, Nils Eliasson wrote: > Hi all, > > This change makes method matchers (used by compile commands and compiler > control) print symbols as utf8 instead of ascii. The print out of used > commands will now look the same as the patterns the user has supplied. > > bug: https://bugs.openjdk.java.net/browse/JDK-8139996 > webrev: http://cr.openjdk.java.net/~neliasso/8139996/webrev.01/ > > Please review, > Nils Eliasson From nils.eliasson at oracle.com Mon Oct 26 13:22:26 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 26 Oct 2015 14:22:26 +0100 Subject: RFR(S): 8139996: CompileCommand prints quoted ascii strings In-Reply-To: <562E2276.8030501@oracle.com> References: <562DF84E.4080507@oracle.com> <562E2276.8030501@oracle.com> Message-ID: <562E2912.7050501@oracle.com> Thanks Vladimir, //Nils On 2015-10-26 13:54, Vladimir Kozlov wrote: > Looks fine. > > Thanks, > Vladimir > > On 10/26/15 5:54 PM, Nils Eliasson wrote: >> Hi all, >> >> This change makes method matchers (used by compile commands and compiler >> control) print symbols as utf8 instead of ascii. The print out of used >> commands will now look the same as the patterns the user has supplied. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8139996 >> webrev: http://cr.openjdk.java.net/~neliasso/8139996/webrev.01/ >> >> Please review, >> Nils Eliasson From aleksey.shipilev at oracle.com Mon Oct 26 14:14:30 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 26 Oct 2015 17:14:30 +0300 Subject: RFC (S) 8140483: Atomic*FieldUpdaters final fields should be trusted Message-ID: <562E3546.5060007@oracle.com> Hi, I would like to gauge interest in doing a simple VM change that significantly improves the performance of Atomic*FieldUpdaters: https://bugs.openjdk.java.net/browse/JDK-8140483 In short, we are looking into folding away the checks in A*FU: private final Class tclass; private final Class cclass; public final int get(T obj) { if (obj == null || obj.getClass() != tclass || cclass != null) fullCheck(obj); return unsafe.getIntVolatile(obj, offset); } Since most use cases for A*FU involve putting them into static final fields, the Updater instances are known constants. Now, the internal instance final fields are not trusted by default. This can be "fixed" with -XX:+TrustNonStaticFinalFields -- the bad thing about this option is that it's global, and it may break user code. Vladimir I. has a potential improvement that handles this by tracking the final field writes, but there is no clear ETA for that feature. With this little VM improvement, we can close the gap for A*FU, and eliminate another reason for using Unsafe today: http://cr.openjdk.java.net/~shade/8140483/webrev.00/ It improves the generated code and performance significantly: http://cr.openjdk.java.net/~shade/8140483/notes.txt Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From zoltan.majo at oracle.com Mon Oct 26 14:16:49 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 26 Oct 2015 15:16:49 +0100 Subject: [9] RFR(S): 8138651: -XX:DisableIntrinsic matches intrinsics overly eagerly In-Reply-To: <562A1EC9.6020006@oracle.com> References: <5613B7D5.5090702@oracle.com> <56148585.1020507@oracle.com> <5629E709.2000004@oracle.com> <562A1EC9.6020006@oracle.com> Message-ID: <562E35D1.9000105@oracle.com> Hi Nils, thank you for the feedback! On 10/23/2015 01:49 PM, Nils Eliasson wrote: > Hi Zoltan, > > Some comments: > > IntrinsicDisabledTest.java: > > >> return >> System.getProperty("java.vm.name").toLowerCase().contains("server"); > >> > > think the best practice is to use Platform.isServer() ("import > jdk.test.lib.Platform;"). I did not know about that method. Thanks, I've updated the code. > > compilerDirectives.cpp: > > I think the canonilization of the list belongs at the construction > site, and not do at the (hot) use site. The call sites of DirectiveSet::is_intrinsic_disabled() are not that hot, as they are called either when a method is compiled or through the WhiteBox API. In the first case, the time spent on going through a small character array containing disabled intrinsics is not be high (relative to the time spent on compilation). The WhiteBox API is -- I think -- not available in product builds. But from a design perspective it might be a better design to canonicalize the string on construction. > Preferably we would agree on using the ',' separator in all use case > (it only has internal uses). The compilecommand parser should be > straightforward to fix. The VM flag may be parsed by a common parser > that we can't change - then the vmflag value should be canonicalized > during CompilerBroker_init or similar. There are other flags of type ccstrlist. Changing the way a ccstrlist flags are parsed might affect these as well, so I would not want to change the way the VM parses flags. > > If there is some reason to why that doesn't work then I would suggest > moving the canonicalization to DirectiveSet constructor and > DirectiveSet::clone so it only happens once per DirectiveSet. That is a good idea. The new webrev performs canonicalization - in the DirectiveSet constructor, when the value of the global DisableIntrinsic flag is read; - in the DirectiveSet::compilecommand_compatibility_init() method, when the value of the per-method DisableIntrinsic flag is read. Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8138651/webrev.02/ I've tested the updated webrev with: - JPRT (testset hotspot), all tests pass; - locally executing all hotspot tests, all tests pass that pass with the unmodified version of the VM. Thank you and best regards, Zoltan > > Best regards, > Nils > > > > > > On 2015-10-23 09:51, Zolt?n Maj? wrote: > > Hi Vladimir, > > > thank you for the feedback! > > On 10/07/2015 04:37 AM, > Vladimir Kozlov wrote: >> To be precise DisableIntrinsic is ccstrlist > option, not ccstr. Yes, >> the actual type is the same. >> >> An other > concern is separators since format could be different if >> option > specified in file. Look how we do search in DeoptimizeOnlyAt >> > string. > > I've checked and DisableIntrinsic supports accumulation of > argument > values: If -XX:DisableIntrinsic is specified multiple times > on the > command line, all argument values are concatenated into one > argument. > In that case, '\n' is used as separator. I updated the > webrev to > support "\n" as a separator. > > If DisableIntrinsic is > used on the per-method level (i.e., with > > -XX:CompileCommand=option,...), HotSpot expects the type of > > DisableIntrinsic to be 'ccstr' and not 'ccstrlist'. That does not > > allow specifying a list of intrinsics to be disabled (e.g., > > _getInt,_getInVolatile,_hashCode) and is inconsistent with the > > declaration of DisableIntrinsic in globals.hpp. > > To address this > problem, the webrev changes the type of the > per-method level > DisableIntrinsic flag to 'ccstrlist'. For per-method > ccstrlists, the > separator is a whitespace (internally). I've updated > the webrev to > support whitespace as a separator as well. > > I noticed an other > problem while working on this fix: If > DisableIntrinsic is specified > multiple times for the same method, > argument values do not > accumulate. For example, with > > > -XX:CompileCommand=option,sun.misc.Unsafe::putChar,ccstrlist,DisableIntrinsic,_getInt,_getIntVolatile > > > > -XX:CompileCommand=option,sun.misc.Unsafe::putChar,ccstrlist,DisableIntrinsic,_hashCode > >> only '_hashCode' will be disabled for 'putChar'. That is also > > inconsistent with the way DisableIntrinsic works when used globally > > (with -XX:DisableIntrinsic). > > This inconsistency should be > addressed, but as the fix requires > significant changes to > CompilerOracle, I would like to take care of > that separately. I've > filed an RFE for that: > > > https://bugs.openjdk.java.net/browse/JDK-8140322 > > I hope that is > fine. > > Here is the updated webrev: > > http://cr.openjdk.java.net/~zmajo/8138651/webrev.01/ > > Testing: - > JPRT (testset hotspot, including the newly added > > IntrinsicDisabledTest.java test). > > Thank you and best regards, > > > > Zoltan > >> >> Thanks, Vladimir >> >> On 10/6/15 8:00 PM, Zolt?n > Maj? wrote: >>> Hi, >>> >>> >>> please review the patch for > JDK-8138651. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8138651 > >>> >>> Problem: The DisableIntrinsic flag does not disable intrinsics > >>> accurately. For example, -XX:DisableIntrinsic=_copyOfRange >>> > disables both the intrinsic with the ID _copyOfRange and the >>> > intrinsic with the _copyOf. >>> >>> Solution: Change the processing of > the DisableIntrinsic flag >>> (both globally and on a per-method > level). >>> >>> Webrev: > http://cr.openjdk.java.net/~zmajo/8138651/webrev.00/ >>> >>> Testing: > - JPRT (testset hotspot); - executed the the newly added >>> test > compiler/intrinsics/IntrinsicDisabledTest.java with/without >>> the > fix on all platforms, the test behaves as expected. >>> >>> Thank you > and best regards, >>> >>> >>> Zoltan >>> > > > From martin.doerr at sap.com Mon Oct 26 14:18:25 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 26 Oct 2015 14:18:25 +0000 Subject: RFR(S): 8138890: C1: Ambiguous operator delete In-Reply-To: <7C9B87B351A4BA4AA9EC95BB4181165672261632@DEWDFEMB19C.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB41811656722607B5@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672260AE1@DEWDFEMB19C.global.corp.sap> <56153267.7060401@oracle.com> <7C9B87B351A4BA4AA9EC95BB4181165672260BFB@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672261012@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB41811656722611F8@DEWDFEMB19C.global.corp.sap> <3D04808B-DB7A-4ECF-A3BF-42D5A20E2419@oracle.com> <7C9B87B351A4BA4AA9EC95BB418116567226135E@DEWDFEMB19C.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165672261632@DEWDFEMB19C.global.corp.sap> Message-ID: <7C9B87B351A4BA4AA9EC95BB418116567226291E@DEWDFEMB19C.global.corp.sap> Hi Christian, thanks for sponsoring. Best regards, Martin From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Doerr, Martin Sent: Dienstag, 13. Oktober 2015 15:47 To: Christian Thalinger Cc: hotspot compiler Subject: RE: RFR(S): 8138890: C1: Ambiguous operator delete Hi, I think this is reviewed, now. Can somebody sponsor, please? In addition, you could also push this reviewed change, too: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-October/019269.html http://cr.openjdk.java.net/~mdoerr/8138892_c1_counter_overflow/webrev.02 Thanks and best regards, Martin From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Dienstag, 13. Oktober 2015 01:10 To: Doerr, Martin Cc: hotspot compiler Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete On Oct 11, 2015, at 11:14 PM, Doerr, Martin > wrote: Hi Christian, seems like VALUE_OBJ_CLASS_SPEC inherits from _ValueObj on platforms on which the compiler uses empty base class optimization. On these platforms, the inheritance comes for free (no extra size for the object). A problem is that the macro VALUE_OBJ_CLASS_SPEC does not work for multi-inheritance because it translates to either nothing or a term which would need comma separation. That answers my question, thanks. The other class we inherit from defines new/delete operators which are not supposed to get used for this derived class, so I think making these operators private there is just the right thing to do. Best regards, Martin From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Samstag, 10. Oktober 2015 00:32 To: Doerr, Martin Cc: Volker Simonis; Lindenmaier, Goetz; Mikael Gerdin; hotspot compiler Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete On Oct 9, 2015, at 9:08 AM, Doerr, Martin > wrote: Hi Christian, I have just added comments. We can also get rid of the multi-inheritance in RanceCheckEliminator::Verification. Hmm. Why did we have it this way (not using the macro and such)? - class Verification : public _ValueObj /*VALUE_OBJ_CLASS_SPEC*/, public BlockClosure { + class Verification : public BlockClosure { The new webrev is: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.03 Best regards, Martin From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Freitag, 9. Oktober 2015 20:35 To: Doerr, Martin Cc: Volker Simonis; Lindenmaier, Goetz; Mikael Gerdin; hotspot compiler Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete On Oct 9, 2015, at 12:03 AM, Doerr, Martin > wrote: Hi, thanks for reviewing. As requested by G?tz, I just removed the second ?private?. The new webrev is here: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.02 Looks good. Can we add a comment saying that objects of this class should never be allocated on the heap or something? Best regards, Martin From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Mittwoch, 7. Oktober 2015 21:28 To: Doerr, Martin Cc: Mikael Gerdin; Christian Thalinger; hotspot compiler Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete Hi Martin, as the new/delete operators in StackObj are private (I missed that before) they shouldn't be visible in LIRGenerator. So this is probably yet another xlC bug :( On the other hand the new/delete operators in CompilationResourceObject are public and are inherited by LIRGenerator. So if we only want to generate LIRGenerator instances on the stack, your change is good, because it ensures this. And in that case we surely don't need an implementation. So thumbs up from me! Volker On Wednesday, October 7, 2015, Doerr, Martin > wrote: Hi Volker, the C1 classes we are talking about should never get instantiated by operator new. A typical way to establish this is to make the new operators private. I don?t really care if the delete operators are public or private because if the new operator is never used, how can the delete operator get used? It may be more beautiful to declare them as private as well. Only in the case G?tz has showed, some Compilers reject the private delete operators. Best regards, Martin From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Mittwoch, 7. Oktober 2015 17:57 To: Mikael Gerdin Cc: Doerr, Martin; Christian Thalinger; hotspot compiler Subject: Re: RFR(S): 8138890: C1: Ambiguous operator delete Hi Martin, we have: class LIRGenerator: public InstructionVisitor, public BlockClosure and: class BlockClosure: public CompilationResourceObj class CompilationResourceObj ALLOCATION_SUPER_CLASS_SPEC { public: void* operator new(size_t size) throw() { return Compilation::current()->arena()->Amalloc(size); } void* operator new(size_t size, Arena* arena) throw() { return arena->Amalloc(size); } void operator delete(void* p) {} // nothing to do }; class InstructionVisitor: public StackObj class StackObj ALLOCATION_SUPER_CLASS_SPEC { private: void* operator new(size_t size) throw(); void* operator new [](size_t size) throw(); #ifdef __IBMCPP__ public: #endif void operator delete(void* p); void operator delete [](void* p); Now you declare new "new()" and "delete()" operators in the LIRGenerator which will actually hide the corresponding operators from the base classes. You also provide no implementation for the new operators in LIRGenerator. So which new/delete operators will be actually used for allocating new LIRGenerator instances? OK, wait. As far as I can see, LIRGenerator is never dynamically allocated, right? In that case it should be a StackObj and you could probably solve the problem with "using" directives (e.g. using StackObj::operator new, ...). Have you tried that? Regards, Volker On Wed, Oct 7, 2015 at 4:55 PM, Mikael Gerdin > wrote: On 2015-10-07 16:17, Doerr, Martin wrote: Hi, that?s a good question J I can only remember that there were problems with some old compilers. Anyway, xlC 12.1 can deal with the private delete operators. If that's the case, can we also get rid of the workaround in allocation.hpp? Thanks /Mikael Here?s the new webrev: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.01 Best regards, Martin *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com] *Sent:* Mittwoch, 7. Oktober 2015 03:32 *To:* Doerr, Martin *Cc:* hotspot compiler *Subject:* Re: RFR(S): 8138890: C1: Ambiguous operator delete On Oct 6, 2015, at 3:56 AM, Doerr, Martin >> wrote: Hi, xlC on AIX rejects to compile LIRGenerator and RangeCheckEliminator::Verification due to ambiguous operator delete which gets inherited from multiple base classes. This change is a prerequisite for our C1 on PPC64 contribution. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.00 Let me ask my question here: why do you need the delete methods to be public on AIX? Please review this change. I need a sponsor, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Mon Oct 26 18:01:31 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 26 Oct 2015 19:01:31 +0100 Subject: RFC (S) 8140483: Atomic*FieldUpdaters final fields should be trusted In-Reply-To: <562E3546.5060007@oracle.com> References: <562E3546.5060007@oracle.com> Message-ID: Hi Aleksey, this is a nice little change with good performance improvements. However, I already see the list of exceptions in trust_final_non_static_fields() growing longer and longer :) Maybe a new annotation "@TrustNonStaticFinalFields" would be the better solution? It should be public (but not necessarily in the standard java name space) to allow users to annotate their code and profit from such optimizations as well. We could also avoid adding an annotation and instead just introduce a new option like -XX:TrustNonStaticFinalFieldsIn=. This would have the charm of not polluting the code with non-standard annotations. And it could be of type 'ccstrlist' (i.e. 'accumulating string argument') and pre-initialized with packages like "java/util/concurrent/atomic". Extending -XX:CompileCommand with something like a 'trustnonstaticfinalsin ' option would be just another flavour of this approach. Both these proposals would give people the chance to experiment with this optimization without having to recompile HotSpot. What do you think? Volker On Mon, Oct 26, 2015 at 3:14 PM, Aleksey Shipilev wrote: > Hi, > > I would like to gauge interest in doing a simple VM change that > significantly improves the performance of Atomic*FieldUpdaters: > https://bugs.openjdk.java.net/browse/JDK-8140483 > > In short, we are looking into folding away the checks in A*FU: > > private final Class tclass; > private final Class cclass; > > public final int get(T obj) { > if (obj == null || obj.getClass() != tclass || cclass != null) > fullCheck(obj); > return unsafe.getIntVolatile(obj, offset); > } > > Since most use cases for A*FU involve putting them into static final > fields, the Updater instances are known constants. Now, the internal > instance final fields are not trusted by default. This can be "fixed" > with -XX:+TrustNonStaticFinalFields -- the bad thing about this option > is that it's global, and it may break user code. Vladimir I. has a > potential improvement that handles this by tracking the final field > writes, but there is no clear ETA for that feature. > > With this little VM improvement, we can close the gap for A*FU, and > eliminate another reason for using Unsafe today: > http://cr.openjdk.java.net/~shade/8140483/webrev.00/ > > It improves the generated code and performance significantly: > http://cr.openjdk.java.net/~shade/8140483/notes.txt > > Thanks, > -Aleksey > From pavel.punegov at oracle.com Mon Oct 26 18:12:43 2015 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Mon, 26 Oct 2015 21:12:43 +0300 Subject: RFR (XXS): 8140350: compiler control tests fail with compiled: true, but should: false on required level: 1 Message-ID: <562E6D1B.1040404@oracle.com> Hi, Please review the following fix for compiler control tests. Issue: Tests could fail (mostly with Xcomp) if they check compilation with WB.isMethodCompiled(), because method could be already compiled on higher level. When test method is excluded on the 1st level, it will be compiled on the 4th level. Test would incorrectly assume then that test method is compilable on the level it should not. Fix: make test check that the method could be compiled on particular level with WhiteBox.isMethodCompilable. bug: https://bugs.openjdk.java.net/browse/JDK-8140350 webrev: http://cr.openjdk.java.net/~ppunegov/8140350/webrev.00/ -- Thanks, Pavel Punegov From aleksey.shipilev at oracle.com Mon Oct 26 18:18:44 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 26 Oct 2015 21:18:44 +0300 Subject: RFC (S) 8140483: Atomic*FieldUpdaters final fields should be trusted In-Reply-To: References: <562E3546.5060007@oracle.com> Message-ID: <562E6E84.5020005@oracle.com> Hi Volker, On 10/26/2015 09:01 PM, Volker Simonis wrote: > However, I already see the list of exceptions in > trust_final_non_static_fields() growing longer and longer :) Yes, it grows. This particular thing appears to have a very low cost/benefit ratio. In fact, it is surprising how many people have contacted me offline saying this what helps to get rid of Unsafe usages for them. Yes, this is a band-aid, but this is a highly profitable band-aid, considering the use case :) > Maybe a new annotation "@TrustNonStaticFinalFields" would be the > better solution? It should be public (but not necessarily in the > standard java name space) to allow users to annotate their code and > profit from such optimizations as well. I am against adding yet another annotation, especially since it will leak into publicly-accessible namespace. As we learned, people would frown once we decide to pull it back, so it seems better to never tempt! As noted in the JIRA issue, the "actual" way to fix this is to deal with final fields wholesale, e.g. by speculatively optimizing them, and detecting the stores. This will also solve A*FU thing we are discussing. This is what Vladimir I. had shown at this list already: https://bugs.openjdk.java.net/browse/JDK-8058164 With a limited time budget, I think a sane tactics would be to add another explicit exception to the stability rules, and invest the saved time into solving the problem wholesale, and later ditch the exceptions. > We could also avoid adding an annotation and instead just introduce a > new option like > -XX:TrustNonStaticFinalFieldsIn=. This would > have the charm of not polluting the code with non-standard > annotations. And it could be of type 'ccstrlist' (i.e. 'accumulating > string argument') and pre-initialized with packages like > "java/util/concurrent/atomic". While this is an interesting suggestion, I think parsing these lists adds up to either classload, or compilation time, depending where you implement the predicate tests, and how many hours you spend fine-tuning it. Compiler Control JEP, I think, is providing the facilities to access these properties in the uniform and more-or-less performant manner. > Extending -XX:CompileCommand with > something like a 'trustnonstaticfinalsin ' option would be just > another flavour of this approach. See above. Yes, compiler command would be nice. Compiler Control JEP had not landed yet though. I would suggest to rebuild the exception list to Compiler Control the next time a new exception is required. > Both these proposals would give people the chance to experiment with > this optimization without having to recompile HotSpot. You can already experiment with the optimization (I assume in benchmarks) by using global -XX:+TrustNonStaticFinalFields option. Cheers, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From pavel.punegov at oracle.com Mon Oct 26 18:32:32 2015 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Mon, 26 Oct 2015 21:32:32 +0300 Subject: RFR (XXS): 8140453: compiler control test failed with RuntimeException: CompileCommand: nonexistent missing Message-ID: <562E71C0.30606@oracle.com> Please review the following small fix for tests. Output processor incorrectly checks for validity only method pattern instead of full command. Also small refactoring done: inlined local variables. bug: https://bugs.openjdk.java.net/browse/JDK-8140453 webrev: http://cr.openjdk.java.net/~ppunegov/8140453/webrev.00/ -- Thanks, Pavel Punegov From pavel.punegov at oracle.com Mon Oct 26 19:37:36 2015 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Mon, 26 Oct 2015 22:37:36 +0300 Subject: RFR(S): 8066158: JEP-JDK-8046155: Test task: directive parser Message-ID: <562E8100.7030806@oracle.com> Please review the following new test for CompilerControl. The test is aimed to check directive file parser with correct and incorrect files. It contains simple test cases with empty objects, arrays, files, etc. webrev: http://cr.openjdk.java.net/~ppunegov/8066158/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8066158 -- Thanks, Pavel Punegov From forax at univ-mlv.fr Mon Oct 26 22:37:58 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 26 Oct 2015 23:37:58 +0100 (CET) Subject: RFC (S) 8140483: Atomic*FieldUpdaters final fields should be trusted In-Reply-To: <562E3546.5060007@oracle.com> References: <562E3546.5060007@oracle.com> Message-ID: <1651311281.461213.1445899078476.JavaMail.zimbra@u-pem.fr> Hi Aleksey, there is another solution, Put the implementation of ARFU inside java.lang.invoke, it will be a mess in term of maintenance for Doug and Martin, but fields of classes in java.lang.invoke are always trusted and as a bonus you have access to nice annotations like @ForceInline. Taking a look to the generated assembly, I wonder why the obj.getClass() == tclass is not removed. Given that in for your test there is no subclass of AFUBench, it should work. So my guess is that the type of 'this' inside the test is not propagated to the method 'get', am i right ? regards, R?mi ----- Mail original ----- > De: "Aleksey Shipilev" > ?: "hotspot compiler" > Envoy?: Lundi 26 Octobre 2015 15:14:30 > Objet: RFC (S) 8140483: Atomic*FieldUpdaters final fields should be trusted > > Hi, > > I would like to gauge interest in doing a simple VM change that > significantly improves the performance of Atomic*FieldUpdaters: > https://bugs.openjdk.java.net/browse/JDK-8140483 > > In short, we are looking into folding away the checks in A*FU: > > private final Class tclass; > private final Class cclass; > > public final int get(T obj) { > if (obj == null || obj.getClass() != tclass || cclass != null) > fullCheck(obj); > return unsafe.getIntVolatile(obj, offset); > } > > Since most use cases for A*FU involve putting them into static final > fields, the Updater instances are known constants. Now, the internal > instance final fields are not trusted by default. This can be "fixed" > with -XX:+TrustNonStaticFinalFields -- the bad thing about this option > is that it's global, and it may break user code. Vladimir I. has a > potential improvement that handles this by tracking the final field > writes, but there is no clear ETA for that feature. > > With this little VM improvement, we can close the gap for A*FU, and > eliminate another reason for using Unsafe today: > http://cr.openjdk.java.net/~shade/8140483/webrev.00/ > > It improves the generated code and performance significantly: > http://cr.openjdk.java.net/~shade/8140483/notes.txt > > Thanks, > -Aleksey > > From aleksey.shipilev at oracle.com Mon Oct 26 22:59:20 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 27 Oct 2015 01:59:20 +0300 Subject: RFC (S) 8140483: Atomic*FieldUpdaters final fields should be trusted In-Reply-To: <1651311281.461213.1445899078476.JavaMail.zimbra@u-pem.fr> References: <562E3546.5060007@oracle.com> <1651311281.461213.1445899078476.JavaMail.zimbra@u-pem.fr> Message-ID: <562EB048.1050106@oracle.com> Hi Remi, On 10/27/2015 01:37 AM, Remi Forax wrote: > Put the implementation of ARFU inside java.lang.invoke, it will be a > mess in term of maintenance for Doug and Martin, but fields of > classes in java.lang.invoke are always trusted and as a bonus you > have access to nice annotations like @ForceInline. Oh noes. Maintenance mess is something I don't want to contribute to. Compared with three lines in compiler code, the A*FU impl move is very messy. E.g. Doug continuously reminds me that JSR166 is also used outside OpenJDK, and therefore I think this suggestion pretty much means forking java.util.concurrent. > Taking a look to the generated assembly, I wonder why the > obj.getClass() == tclass is not removed. Given that in for your test > there is no subclass of AFUBench, it should work. So my guess is that > the type of 'this' inside the test is not propagated to the method > 'get', am i right ? There are, in fact, subclasses of AFUBench generated by JMH itself, so you cannot elide the typecheck. If you would do the A*FU ops against some pristine "holder" class, then a typecheck will be elided, and only a nullcheck will be present. Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From vitalyd at gmail.com Mon Oct 26 23:18:15 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 26 Oct 2015 19:18:15 -0400 Subject: RFC (S) 8140483: Atomic*FieldUpdaters final fields should be trusted In-Reply-To: <562EB048.1050106@oracle.com> References: <562E3546.5060007@oracle.com> <1651311281.461213.1445899078476.JavaMail.zimbra@u-pem.fr> <562EB048.1050106@oracle.com> Message-ID: > > There are, in fact, subclasses of AFUBench generated by JMH itself, so > you cannot elide the typecheck. If you would do the A*FU ops against > some pristine "holder" class, then a typecheck will be elided, and only > a nullcheck will be present. If the A*FU op is inlined into caller, I'd hope the null check is removed as well. Likewise, if it's inlined into caller, `this` class is known at JIT time of the caller, so should be able to fold obj.getClass() == tclass to true or false? On Mon, Oct 26, 2015 at 6:59 PM, Aleksey Shipilev < aleksey.shipilev at oracle.com> wrote: > Hi Remi, > > On 10/27/2015 01:37 AM, Remi Forax wrote: > > Put the implementation of ARFU inside java.lang.invoke, it will be a > > mess in term of maintenance for Doug and Martin, but fields of > > classes in java.lang.invoke are always trusted and as a bonus you > > have access to nice annotations like @ForceInline. > > Oh noes. Maintenance mess is something I don't want to contribute to. > Compared with three lines in compiler code, the A*FU impl move is very > messy. E.g. Doug continuously reminds me that JSR166 is also used > outside OpenJDK, and therefore I think this suggestion pretty much means > forking java.util.concurrent. > > > Taking a look to the generated assembly, I wonder why the > > obj.getClass() == tclass is not removed. Given that in for your test > > there is no subclass of AFUBench, it should work. So my guess is that > > the type of 'this' inside the test is not propagated to the method > > 'get', am i right ? > > There are, in fact, subclasses of AFUBench generated by JMH itself, so > you cannot elide the typecheck. If you would do the A*FU ops against > some pristine "holder" class, then a typecheck will be elided, and only > a nullcheck will be present. > > Thanks, > -Aleksey > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksey.shipilev at oracle.com Mon Oct 26 23:41:50 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 27 Oct 2015 02:41:50 +0300 Subject: RFC (S) 8140483: Atomic*FieldUpdaters final fields should be trusted In-Reply-To: References: <562E3546.5060007@oracle.com> <1651311281.461213.1445899078476.JavaMail.zimbra@u-pem.fr> <562EB048.1050106@oracle.com> Message-ID: <562EBA3E.3040208@oracle.com> On 10/27/2015 02:18 AM, Vitaly Davidovich wrote: > There are, in fact, subclasses of AFUBench generated by JMH itself, so > you cannot elide the typecheck. If you would do the A*FU ops against > some pristine "holder" class, then a typecheck will be elided, and only > a nullcheck will be present. > > > If the A*FU op is inlined into caller, I'd hope the null check is > removed as well. Likewise, if it's inlined into caller, `this` class is > known at JIT time of the caller, so should be able to fold > obj.getClass() == tclass to true or false? In non-"this" case, you may not be able to prove the A*FU receiver is non-null. In "this" case, you may not be able to prove the type is unique, as that simple benchmark demonstrated. Although, I think in most practical cases you are able to do either. But, I think this has little to do with the current topic: trusting final fields in A*FU enables optimizations. Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From vitalyd at gmail.com Mon Oct 26 23:52:50 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 26 Oct 2015 19:52:50 -0400 Subject: RFC (S) 8140483: Atomic*FieldUpdaters final fields should be trusted In-Reply-To: <562EBA3E.3040208@oracle.com> References: <562E3546.5060007@oracle.com> <1651311281.461213.1445899078476.JavaMail.zimbra@u-pem.fr> <562EB048.1050106@oracle.com> <562EBA3E.3040208@oracle.com> Message-ID: > > In non-"this" case, you may not be able to prove the A*FU receiver is > non-null. Yes (particularly annoying since final instance fields aren't treated as constants :)). In "this" case, you may not be able to prove the type is > unique, as that simple benchmark demonstrated. Although, I think in most > practical cases you are able to do either. In this particular case, A*FU is doing obj.getClass() == tclass as a cheaper check than what fullCheck() does, which is tclass.isInstance(obj). However, theoretically speaking, if A*FU op is inlined into an instance method where `this` is passed, it should be able to determine at JIT time whether `this` is tclass or subtype of it. Then that whole type check could be removed. But, I think this has little to do with the current topic: trusting > final fields in A*FU enables optimizations. Yes, sorry -- I blame Remi for digressing :). On Mon, Oct 26, 2015 at 7:41 PM, Aleksey Shipilev < aleksey.shipilev at oracle.com> wrote: > On 10/27/2015 02:18 AM, Vitaly Davidovich wrote: > > There are, in fact, subclasses of AFUBench generated by JMH itself, > so > > you cannot elide the typecheck. If you would do the A*FU ops against > > some pristine "holder" class, then a typecheck will be elided, and > only > > a nullcheck will be present. > > > > > > If the A*FU op is inlined into caller, I'd hope the null check is > > removed as well. Likewise, if it's inlined into caller, `this` class is > > known at JIT time of the caller, so should be able to fold > > obj.getClass() == tclass to true or false? > > In non-"this" case, you may not be able to prove the A*FU receiver is > non-null. In "this" case, you may not be able to prove the type is > unique, as that simple benchmark demonstrated. Although, I think in most > practical cases you are able to do either. > > But, I think this has little to do with the current topic: trusting > final fields in A*FU enables optimizations. > > Thanks, > -Aleksey > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksey.shipilev at oracle.com Tue Oct 27 00:04:08 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 27 Oct 2015 03:04:08 +0300 Subject: RFC (S) 8140483: Atomic*FieldUpdaters final fields should be trusted In-Reply-To: References: <562E3546.5060007@oracle.com> <1651311281.461213.1445899078476.JavaMail.zimbra@u-pem.fr> <562EB048.1050106@oracle.com> <562EBA3E.3040208@oracle.com> Message-ID: <562EBF78.4020700@oracle.com> On 10/27/2015 02:52 AM, Vitaly Davidovich wrote: > In this particular case, A*FU is doing obj.getClass() == tclass as a > cheaper check than what fullCheck() does, which is > tclass.isInstance(obj). However, theoretically speaking, if A*FU op is > inlined into an instance method where `this` is passed, it should be > able to determine at JIT time whether `this` is tclass or subtype of > it. Then that whole type check could be removed. Yes, I get that. It may be profitable to check Class.isInstance, instead of the exact match, so that subclasses are also acceptable. And it indeed does help to eliminate the type check. Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From vitalyd at gmail.com Tue Oct 27 00:13:00 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 26 Oct 2015 20:13:00 -0400 Subject: RFC (S) 8140483: Atomic*FieldUpdaters final fields should be trusted In-Reply-To: <562EBF78.4020700@oracle.com> References: <562E3546.5060007@oracle.com> <1651311281.461213.1445899078476.JavaMail.zimbra@u-pem.fr> <562EB048.1050106@oracle.com> <562EBA3E.3040208@oracle.com> <562EBF78.4020700@oracle.com> Message-ID: Yes, I think so because passing `this` is the common pattern for these classes. As for your actual changes, you sure just checking package and holder not being serializable isn't too broad a brush? It makes for shorter code, but may inadvertently include something in the future that it shouldn't and cause hard to catch issues. sent from my phone On Oct 26, 2015 8:04 PM, "Aleksey Shipilev" wrote: > On 10/27/2015 02:52 AM, Vitaly Davidovich wrote: > > In this particular case, A*FU is doing obj.getClass() == tclass as a > > cheaper check than what fullCheck() does, which is > > tclass.isInstance(obj). However, theoretically speaking, if A*FU op is > > inlined into an instance method where `this` is passed, it should be > > able to determine at JIT time whether `this` is tclass or subtype of > > it. Then that whole type check could be removed. > > Yes, I get that. It may be profitable to check Class.isInstance, instead > of the exact match, so that subclasses are also acceptable. And it > indeed does help to eliminate the type check. > > Thanks, > -Aleksey > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalyd at gmail.com Tue Oct 27 00:58:58 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 26 Oct 2015 20:58:58 -0400 Subject: Jitted array-length checks before entering a loop In-Reply-To: References: <780C7C66-6E88-4B38-8156-EA53525F863A@oracle.com> Message-ID: Anyone have thoughts? sent from my phone On Oct 16, 2015 10:56 AM, "Vitaly Davidovich" wrote: > Chris (or anyone else), > > Any thoughts on this? Looks like an opportunity to slim down the emitted > code. > > Thanks > > On Fri, Oct 9, 2015 at 4:14 PM, Vitaly Davidovich > wrote: > >> So basically, the deopt blobs are unreachable -- not sure if that's >> intentional or not. Perhaps it's intentional in that deopt'ing in this >> case is a waste of time (the simple exit is just fine), but the code for it >> is left behind. >> >> On Fri, Oct 9, 2015 at 2:51 PM, Vitaly Davidovich >> wrote: >> >>> Chris, >>> >>> Below is a sample dump (array is in %rsi). You can see the 2 tests in >>> question that jump to deopt blobs (I presume). If I change the code to >>> always pass a zero length array (the below assembly is for non-empty array >>> 100% of the time), the code generation changes to favor that case, and >>> these tests are not present. >>> >>> 0x00007f63476c7da0: mov %eax,-0x14000(%rsp) >>> 0x00007f63476c7da7: push %rbp >>> 0x00007f63476c7da8: sub $0x10,%rsp ;*synchronization entry >>> >>> 0x00007f63476c7dac: mov 0xc(%rsi),%r10d ;*arraylength >>> >>> ; implicit exception: >>> dispatches to 0x00007f63476c7e11 >>> 0x00007f63476c7db0: test %r10d,%r10d >>> 0x00007f63476c7db3: jle 0x00007f63476c7de2 ;*if_icmplt >>> >>> 0x00007f63476c7db5: test %r10d,%r10d >>> 0x00007f63476c7db8: jbe 0x00007f63476c7dfd >>> 0x00007f63476c7dba: mov %r10d,%r8d >>> 0x00007f63476c7dbd: dec %r8d >>> 0x00007f63476c7dc0: cmp %r10d,%r8d >>> 0x00007f63476c7dc3: jae 0x00007f63476c7dfd >>> 0x00007f63476c7dc5: xor %r11d,%r11d >>> 0x00007f63476c7dc8: nopl 0x0(%rax,%rax,1) ;*aload_0 >>> >>> 0x00007f63476c7dd0: mov 0x10(%rsi,%r11,4),%r8d ;*aaload >>> >>> 0x00007f63476c7dd5: test %r8d,%r8d >>> 0x00007f63476c7dd8: je 0x00007f63476c7dee ;*invokevirtual amethod >>> >>> 0x00007f63476c7dda: inc %r11d ;*iinc >>> >>> 0x00007f63476c7ddd: cmp %r10d,%r11d >>> 0x00007f63476c7de0: jl 0x00007f63476c7dd0 ;*return >>> >>> 0x00007f63476c7de2: add $0x10,%rsp >>> 0x00007f63476c7de6: pop %rbp >>> 0x00007f63476c7de7: test %eax,0x5cd3213(%rip) # >>> 0x00007f634d39b000 >>> ; {poll_return} >>> 0x00007f63476c7ded: retq >>> 0x00007f63476c7dee: mov $0xfffffff6,%esi >>> 0x00007f63476c7df3: callq 0x00007f6347684320 ; OopMap{off=88} >>> ;*invokevirtual amethod >>> ; {runtime_call} >>> 0x00007f63476c7df8: callq 0x00007f634c17f570 ;*invokevirtual amethod >>> ; {runtime_call} >>> 0x00007f63476c7dfd: mov %rsi,%rbp >>> 0x00007f63476c7e00: mov $0xffffff86,%esi >>> 0x00007f63476c7e05: xchg %ax,%ax >>> 0x00007f63476c7e07: callq 0x00007f6347684320 ; OopMap{rbp=Oop >>> off=108} >>> ;*aload_0 >>> ; {runtime_call} >>> 0x00007f63476c7e0c: callq 0x00007f634c17f570 ;*aload_0 >>> ; {runtime_call} >>> 0x00007f63476c7e11: mov $0xfffffff6,%esi >>> 0x00007f63476c7e16: nop >>> 0x00007f63476c7e17: callq 0x00007f6347684320 ; OopMap{off=124} >>> ;*arraylength >>> ; {runtime_call} >>> 0x00007f63476c7e1c: callq 0x00007f634c17f570 ;*arraylength >>> ; {runtime_call} >>> >>> >>> On Fri, Oct 9, 2015 at 2:31 PM, Christian Thalinger < >>> christian.thalinger at oracle.com> wrote: >>> >>>> >>>> On Sep 28, 2015, at 3:37 AM, Nassim Halli >>>> wrote: >>>> >>>> Hi guys, >>>> >>>> I have a question relative to some code generated by the C2 compiler. >>>> >>>> When I look at the assembly codes for this method: >>>> >>>> static void compiledMethod (Atype[] data) { >>>> int n = data.length >>>> for (int i = 0; i < n; ++i) >>>> data[i].amethod(); >>>> } >>>> >>>> I get the this assembly on Linux X86_64 before entering the loop (not >>>> OSR): >>>> >>>> # data is in rbx >>>> mov 0xc(%rbx),%r9d >>>> >>>> # data.length is in r9d >>>> test %r9d,%r9d >>>> jle END_OF_LOOP >>>> >>>> test %r9d,%r9d >>>> jbe BB0 >>>> >>>> mov %r9d,%r11d >>>> dec %r11d >>>> cmp %r9d,%r11d >>>> jae BB0 >>>> >>>> >>>> Did you leave out any assembly? Where is BB0? >>>> >>>> >>>> It seems to me the second and third check are useless and the >>>> corresponding branches are never taken. >>>> Could you please tell me more about these checks, If and why are they >>>> required ? >>>> >>>> Thanks a lot. >>>> >>>> Nassim H. >>>> >>>> >>>> *Test conditions:* >>>> >>>> java version "1.8.0_51" >>>> Java(TM) SE Runtime Environment (build 1.8.0_51-b16) >>>> Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode) >>>> Default options. >>>> Linux, Intel Sandy Bridge core i5-2000 >>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue Oct 27 02:03:35 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 27 Oct 2015 10:03:35 +0800 Subject: RFR(S): 8066158: JEP-JDK-8046155: Test task: directive parser In-Reply-To: <562E8100.7030806@oracle.com> References: <562E8100.7030806@oracle.com> Message-ID: <562EDB77.4000304@oracle.com> Good. Thanks, Vladimir On 10/27/15 3:37 AM, Pavel Punegov wrote: > Please review the following new test for CompilerControl. > > The test is aimed to check directive file parser with correct and > incorrect files. > It contains simple test cases with empty objects, arrays, files, etc. > > webrev: http://cr.openjdk.java.net/~ppunegov/8066158/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8066158 > From vladimir.kozlov at oracle.com Tue Oct 27 02:05:31 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 27 Oct 2015 10:05:31 +0800 Subject: RFR (XXS): 8140453: compiler control test failed with RuntimeException: CompileCommand: nonexistent missing In-Reply-To: <562E71C0.30606@oracle.com> References: <562E71C0.30606@oracle.com> Message-ID: <562EDBEB.9080303@oracle.com> Looks fine. Thanks, Vladimir On 10/27/15 2:32 AM, Pavel Punegov wrote: > Please review the following small fix for tests. > > Output processor incorrectly checks for validity only method pattern > instead of full command. > Also small refactoring done: inlined local variables. > > bug: https://bugs.openjdk.java.net/browse/JDK-8140453 > webrev: http://cr.openjdk.java.net/~ppunegov/8140453/webrev.00/ > From vladimir.kozlov at oracle.com Tue Oct 27 02:08:04 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 27 Oct 2015 10:08:04 +0800 Subject: RFR (XXS): 8140350: compiler control tests fail with compiled: true, but should: false on required level: 1 In-Reply-To: <562E6D1B.1040404@oracle.com> References: <562E6D1B.1040404@oracle.com> Message-ID: <562EDC84.7010602@oracle.com> Good. Thanks, Vladimir On 10/27/15 2:12 AM, Pavel Punegov wrote: > Hi, > > Please review the following fix for compiler control tests. > Issue: Tests could fail (mostly with Xcomp) if they check compilation > with WB.isMethodCompiled(), because method could be already compiled on > higher level. > When test method is excluded on the 1st level, it will be compiled on > the 4th level. Test would incorrectly assume then that test method is > compilable on the level it should not. > > Fix: make test check that the method could be compiled on particular > level with WhiteBox.isMethodCompilable. > > bug: https://bugs.openjdk.java.net/browse/JDK-8140350 > webrev: http://cr.openjdk.java.net/~ppunegov/8140350/webrev.00/ > From edward.nevill at gmail.com Tue Oct 27 10:21:10 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 27 Oct 2015 10:21:10 +0000 Subject: RFR: 8140582: aarch64: jvm fails to initialise after 8078556 Message-ID: <1445941270.31480.9.camel@mint> Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8140582/webrev/ JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8140582 The vm fails to initialises with the following error on aarch64 systems with 64K pagesize ed at arm64:~/jdk9-dev/hs-comp/hotspot$ /home/ed/images/jdk/bin/java intx StackYellowPages=1 is outside the allowed range [ 2 ... 7 ] intx StackShadowPages=1 is outside the allowed range [ 4 ... 34 ] Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. The problem is the following code in src/os/linux/vm/os_linux.cpp // If the pagesize of the VM is greater than 8K determine the appropriate // number of initial guard pages. The user can change this with the // command line arguments, if needed. if (vm_page_size() > (int)Linux::vm_default_page_size()) { StackYellowPages = 1; StackRedPages = 1; StackShadowPages = round_to((StackShadowPages*Linux::vm_default_page_size()), vm_page_size()) / vm_page_size(); } My proposed fix is to set MIN_STACK_YELLOW_PAGES, MIN_STACK_RED_PAGES, and MIN_STACK_SHADOW_PAGES to 1 in globals_aarch64.hpp Thanks for the review, Ed. From tobias.hartmann at oracle.com Tue Oct 27 11:17:18 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 27 Oct 2015 12:17:18 +0100 Subject: [9] RFR(S): 8140574: C2 must re-execute checks after deoptimizing from merged uncommon traps Message-ID: <562F5D3E.6070907@oracle.com> Hi, please review the following patch. https://bugs.openjdk.java.net/browse/JDK-8140574 http://cr.openjdk.java.net/~thartmann/8140574/webrev.00/ Problem: C2 merges the branches for an If and the dominating If into a single region that branches to the uncommon trap for the dominating If to optimize explicit range checks. The problem is that if the dominating If branches to an uncommon trap with 'Reason_unloaded', the merged uncommon trap will not re-execute the checks but directly execute the branch of the first If. This leads to wrong code being executed. Since we don't know which of the two checks failed, we have to re-execute both. Solution: As Roland pointed out, IfNode::has_only_uncommon_traps() should check if the dominating uncommon trap has 'Reason_unstable_if' to ensure that we re-execute the bytecode after deoptimization. The type of the dominated uncommon trap does not matter in this case. Testing: Regression test and JPRT. I also compared the PrintOptoAssembly output of TestExcplicitRangChecks to the baseline version to make sure that all range checks are still folded. Thanks, Tobias From aleksey.shipilev at oracle.com Tue Oct 27 11:19:22 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 27 Oct 2015 14:19:22 +0300 Subject: RFR (S) 8140483: Atomic*FieldUpdaters final fields should be trusted In-Reply-To: <562E3546.5060007@oracle.com> References: <562E3546.5060007@oracle.com> Message-ID: <562F5DBA.7000807@oracle.com> Hi, I'd like to start a formal review for the change: https://bugs.openjdk.java.net/browse/JDK-8140483 The feedback was overwhelmingly positive so far. Some suggested we use compiler control and/or maintain the list of trusted classes. I still think it is an overkill for the fix at hand, and we should instead wait for the wholesale final field optimizations. Therefore, I suggest we go with the explicit exceptions. Now, it may take two forms: a) Accept all non-serializable java/util/concurrent/atomic classes: http://cr.openjdk.java.net/~shade/8140483/webrev.01/ b) Spell out A*FU symbol names explicitly: http://cr.openjdk.java.net/~shade/8140483/webrev.02/ I am leaning towards (b), because it does not involve hacking ciKlass::is_subtype_of, and it appears much safer from the correctness standpoint. Both changes pass JPRT, and both changes improve A*FU performance and the generated code quality. Thanks, -Aleksey On 10/26/2015 05:14 PM, Aleksey Shipilev wrote: > Hi, > > I would like to gauge interest in doing a simple VM change that > significantly improves the performance of Atomic*FieldUpdaters: > https://bugs.openjdk.java.net/browse/JDK-8140483 > > In short, we are looking into folding away the checks in A*FU: > > private final Class tclass; > private final Class cclass; > > public final int get(T obj) { > if (obj == null || obj.getClass() != tclass || cclass != null) > fullCheck(obj); > return unsafe.getIntVolatile(obj, offset); > } > > Since most use cases for A*FU involve putting them into static final > fields, the Updater instances are known constants. Now, the internal > instance final fields are not trusted by default. This can be "fixed" > with -XX:+TrustNonStaticFinalFields -- the bad thing about this option > is that it's global, and it may break user code. Vladimir I. has a > potential improvement that handles this by tracking the final field > writes, but there is no clear ETA for that feature. > > With this little VM improvement, we can close the gap for A*FU, and > eliminate another reason for using Unsafe today: > http://cr.openjdk.java.net/~shade/8140483/webrev.00/ > > It improves the generated code and performance significantly: > http://cr.openjdk.java.net/~shade/8140483/notes.txt > > Thanks, > -Aleksey > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From roland.westrelin at oracle.com Tue Oct 27 11:22:03 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 27 Oct 2015 12:22:03 +0100 Subject: [9] RFR(S): 8140574: C2 must re-execute checks after deoptimizing from merged uncommon traps In-Reply-To: <562F5D3E.6070907@oracle.com> References: <562F5D3E.6070907@oracle.com> Message-ID: > http://cr.openjdk.java.net/~thartmann/8140574/webrev.00/ That looks good to me. Roland. From aleksey.shipilev at oracle.com Tue Oct 27 11:26:58 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 27 Oct 2015 14:26:58 +0300 Subject: RFC (S) 8140483: Atomic*FieldUpdaters final fields should be trusted In-Reply-To: References: <562E3546.5060007@oracle.com> <1651311281.461213.1445899078476.JavaMail.zimbra@u-pem.fr> <562EB048.1050106@oracle.com> <562EBA3E.3040208@oracle.com> <562EBF78.4020700@oracle.com> Message-ID: <562F5F82.3080302@oracle.com> On 10/27/2015 03:13 AM, Vitaly Davidovich wrote: > Yes, I think so because passing `this` is the common pattern for these > classes. Yes, we need to consider that polish after trusted finals lands: https://bugs.openjdk.java.net/browse/JDK-8140587 Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From tobias.hartmann at oracle.com Tue Oct 27 11:28:51 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 27 Oct 2015 12:28:51 +0100 Subject: [9] RFR(S): 8140574: C2 must re-execute checks after deoptimizing from merged uncommon traps In-Reply-To: References: <562F5D3E.6070907@oracle.com> Message-ID: <562F5FF3.4090305@oracle.com> Thanks, Roland! Best, Tobias On 27.10.2015 12:22, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~thartmann/8140574/webrev.00/ > > That looks good to me. > > Roland. > From vitalyd at gmail.com Tue Oct 27 12:28:25 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 27 Oct 2015 08:28:25 -0400 Subject: RFR (S) 8140483: Atomic*FieldUpdaters final fields should be trusted In-Reply-To: <562F5DBA.7000807@oracle.com> References: <562E3546.5060007@oracle.com> <562F5DBA.7000807@oracle.com> Message-ID: FWIW I like (b) as well. You made a GUARDED_ENTRY change in (a) - is that a good change to make even if you go with (b)? sent from my phone On Oct 27, 2015 7:20 AM, "Aleksey Shipilev" wrote: > Hi, > > I'd like to start a formal review for the change: > https://bugs.openjdk.java.net/browse/JDK-8140483 > > The feedback was overwhelmingly positive so far. Some suggested we use > compiler control and/or maintain the list of trusted classes. I still > think it is an overkill for the fix at hand, and we should instead wait > for the wholesale final field optimizations. Therefore, I suggest we go > with the explicit exceptions. > > Now, it may take two forms: > > a) Accept all non-serializable java/util/concurrent/atomic classes: > http://cr.openjdk.java.net/~shade/8140483/webrev.01/ > > b) Spell out A*FU symbol names explicitly: > http://cr.openjdk.java.net/~shade/8140483/webrev.02/ > > I am leaning towards (b), because it does not involve hacking > ciKlass::is_subtype_of, and it appears much safer from the correctness > standpoint. Both changes pass JPRT, and both changes improve A*FU > performance and the generated code quality. > > Thanks, > -Aleksey > > On 10/26/2015 05:14 PM, Aleksey Shipilev wrote: > > Hi, > > > > I would like to gauge interest in doing a simple VM change that > > significantly improves the performance of Atomic*FieldUpdaters: > > https://bugs.openjdk.java.net/browse/JDK-8140483 > > > > In short, we are looking into folding away the checks in A*FU: > > > > private final Class tclass; > > private final Class cclass; > > > > public final int get(T obj) { > > if (obj == null || obj.getClass() != tclass || cclass != null) > > fullCheck(obj); > > return unsafe.getIntVolatile(obj, offset); > > } > > > > Since most use cases for A*FU involve putting them into static final > > fields, the Updater instances are known constants. Now, the internal > > instance final fields are not trusted by default. This can be "fixed" > > with -XX:+TrustNonStaticFinalFields -- the bad thing about this option > > is that it's global, and it may break user code. Vladimir I. has a > > potential improvement that handles this by tracking the final field > > writes, but there is no clear ETA for that feature. > > > > With this little VM improvement, we can close the gap for A*FU, and > > eliminate another reason for using Unsafe today: > > http://cr.openjdk.java.net/~shade/8140483/webrev.00/ > > > > It improves the generated code and performance significantly: > > http://cr.openjdk.java.net/~shade/8140483/notes.txt > > > > Thanks, > > -Aleksey > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalyd at gmail.com Tue Oct 27 12:29:44 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 27 Oct 2015 08:29:44 -0400 Subject: RFC (S) 8140483: Atomic*FieldUpdaters final fields should be trusted In-Reply-To: <562F5F82.3080302@oracle.com> References: <562E3546.5060007@oracle.com> <1651311281.461213.1445899078476.JavaMail.zimbra@u-pem.fr> <562EB048.1050106@oracle.com> <562EBA3E.3040208@oracle.com> <562EBF78.4020700@oracle.com> <562F5F82.3080302@oracle.com> Message-ID: Sounds good. sent from my phone On Oct 27, 2015 7:27 AM, "Aleksey Shipilev" wrote: > On 10/27/2015 03:13 AM, Vitaly Davidovich wrote: > > Yes, I think so because passing `this` is the common pattern for these > > classes. > > Yes, we need to consider that polish after trusted finals lands: > https://bugs.openjdk.java.net/browse/JDK-8140587 > > Thanks, > -Aleksey > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hui.shi at linaro.org Tue Oct 27 14:49:27 2015 From: hui.shi at linaro.org (Hui Shi) Date: Tue, 27 Oct 2015 22:49:27 +0800 Subject: [REDO] Elide more final field's write memory barrier with escape analysis result Message-ID: Fixing regression https://bugs.openjdk.java.net/browse/JDK-8139750, root cause is stable field's allocation doesn't always dominate MemBarRelease node created for stable field write. Could someone help review and sponsor this changeset? bug: https://bugs.openjdk.java.net/browse/JDK-8139758 webrev: http://cr.openjdk.java.net/~hshi/8139758/webrev_v2/ Analyzing java/util/Map/Defaults.java Error message is "assert(!had_error) failed: bad dominance". Assertion fails because MemBarRelease's Precedent input (checkCastPP node) doesn't dominate MemBarRelease node. Checking fail compilation method java/lang/invoke/MethodType.makeImpl 1. early return when mt is not null. 2. stable field write is applied on newly created MethodType object. 3. MemBarRelease is created with Precedent input (allocation "new MethodType(rtype, ptypes, trusted)") 4. MemBarRelease is created at the exit of this method. As early return exits in this method, MemBarRealse is not dominated by its Precedent input. This problem doesn't show up before my early change, because Precedent input is only set for boxed type instance and no stable field in boxed type. MethodType makeImpl(Class rtype, Class[] ptypes, boolean trusted) { MethodType mt = internTable.get(new MethodType(ptypes, rtype)); if (mt != null) return mt; if (ptypes.length == 0) { ptypes = NO_PTYPES; trusted = true; } mt = new MethodType(rtype, ptypes, trusted); // promote the object to the Real Thing, and reprobe mt.form = MethodTypeForm.findForm(mt); // stable field write return internTable.add(mt); } For this reason, adding Precedent input for stable field store's MemBarRealse is skipped in new patch. For final field store, allocation always dominate MemBarRelease. Because allocation is immediately before initializer method and method has only one entry. New patch includes: 1. In do_put_xxx, set_alloc_with_final when filed is final and can find its allocation. Remove constrains for boxed type check. 2. Skip setting MemBarRelease's Precedent input for stable field write. There is no performance degradation here, before this change MemBarRelease precedent input isn't set as alloc_with_final is only update for boxed class and no stable field in boxed class. Early discussion about why these constrains need removed and can be removed is in http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-October/019196.html Regards Shi Hui -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue Oct 27 15:04:29 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 27 Oct 2015 23:04:29 +0800 Subject: [9] RFR(S): 8140574: C2 must re-execute checks after deoptimizing from merged uncommon traps In-Reply-To: <562F5D3E.6070907@oracle.com> References: <562F5D3E.6070907@oracle.com> Message-ID: <562F927D.2030802@oracle.com> Note is_uncommon_trap_proj(Deoptimization::Reason_none) returns value for ANY reasons. Your change is limiting it to only one. We may fold less because of that. Should we just additionally check re-execute flag? dom_unc->jvms()->should_reexecute() Unfortunately wee can't change reexecute flag since JVM state is already recorded according to it. Roland, what do you think? Thanks, Vladimir On 10/27/15 7:17 PM, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > https://bugs.openjdk.java.net/browse/JDK-8140574 > http://cr.openjdk.java.net/~thartmann/8140574/webrev.00/ > > Problem: > C2 merges the branches for an If and the dominating If into a single region that branches to the uncommon trap for the dominating If to optimize explicit range checks. The problem is that if the dominating If branches to an uncommon trap with 'Reason_unloaded', the merged uncommon trap will not re-execute the checks but directly execute the branch of the first If. This leads to wrong code being executed. Since we don't know which of the two checks failed, we have to re-execute both. > > Solution: > As Roland pointed out, IfNode::has_only_uncommon_traps() should check if the dominating uncommon trap has 'Reason_unstable_if' to ensure that we re-execute the bytecode after deoptimization. The type of the dominated uncommon trap does not matter in this case. > > Testing: > Regression test and JPRT. I also compared the PrintOptoAssembly output of TestExcplicitRangChecks to the baseline version to make sure that all range checks are still folded. > > Thanks, > Tobias > From roland.westrelin at oracle.com Tue Oct 27 15:09:07 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 27 Oct 2015 16:09:07 +0100 Subject: [9] RFR(S): 8140574: C2 must re-execute checks after deoptimizing from merged uncommon traps In-Reply-To: <562F927D.2030802@oracle.com> References: <562F5D3E.6070907@oracle.com> <562F927D.2030802@oracle.com> Message-ID: <896013D7-03B4-40B3-900B-9B258ED60AE8@oracle.com> > Should we just additionally check re-execute flag? > > dom_unc->jvms()->should_reexecute() > > Unfortunately wee can't change reexecute flag since JVM state is already recorded according to it. > > Roland, what do you think? Is checking for should_reexecute() sufficient? Couldn?t we reexecute some bytecode in one branch that caused the branch to become dead but not the if itself? This change was put in so we optimize the pattern: if (i < 0 || i >= length) { throw? } of explicit array bound checks. Restricting it to unstable_if uncommon traps, doesn?t break that scenario so I would say that fix is good enough and feels safe. Roland. From vladimir.kozlov at oracle.com Tue Oct 27 15:30:11 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 27 Oct 2015 23:30:11 +0800 Subject: [9] RFR(S): 8140574: C2 must re-execute checks after deoptimizing from merged uncommon traps In-Reply-To: <896013D7-03B4-40B3-900B-9B258ED60AE8@oracle.com> References: <562F5D3E.6070907@oracle.com> <562F927D.2030802@oracle.com> <896013D7-03B4-40B3-900B-9B258ED60AE8@oracle.com> Message-ID: <562F9883.1050904@oracle.com> I see. So the only pattern we are looking for is where 'throw' is replaced with unstable_if uncommon trap. Okay then. Thanks, Vladimir On 10/27/15 11:09 PM, Roland Westrelin wrote: >> Should we just additionally check re-execute flag? >> >> dom_unc->jvms()->should_reexecute() >> >> Unfortunately wee can't change reexecute flag since JVM state is already recorded according to it. >> >> Roland, what do you think? > > Is checking for should_reexecute() sufficient? Couldn?t we reexecute some bytecode in one branch that caused the branch to become dead but not the if itself? > > This change was put in so we optimize the pattern: > > if (i < 0 || i >= length) { throw? } > > of explicit array bound checks. Restricting it to unstable_if uncommon traps, doesn?t break that scenario so I would say that fix is good enough and feels safe. > > Roland. > From vladimir.kozlov at oracle.com Tue Oct 27 15:34:51 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 27 Oct 2015 23:34:51 +0800 Subject: RFR: 8140582: aarch64: jvm fails to initialise after 8078556 In-Reply-To: <1445941270.31480.9.camel@mint> References: <1445941270.31480.9.camel@mint> Message-ID: <562F999B.6080107@oracle.com> Seems good. Thanks, Vladimir On 10/27/15 6:21 PM, Edward Nevill wrote: > Hi, > > Please review the following webrev > > http://cr.openjdk.java.net/~enevill/8140582/webrev/ > > JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8140582 > > The vm fails to initialises with the following error on aarch64 systems with 64K pagesize > > ed at arm64:~/jdk9-dev/hs-comp/hotspot$ /home/ed/images/jdk/bin/java > intx StackYellowPages=1 is outside the allowed range [ 2 ... 7 ] > intx StackShadowPages=1 is outside the allowed range [ 4 ... 34 ] > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > The problem is the following code in src/os/linux/vm/os_linux.cpp > > // If the pagesize of the VM is greater than 8K determine the appropriate > // number of initial guard pages. The user can change this with the > // command line arguments, if needed. > if (vm_page_size() > (int)Linux::vm_default_page_size()) { > StackYellowPages = 1; > StackRedPages = 1; > StackShadowPages = round_to((StackShadowPages*Linux::vm_default_page_size()), vm_page_size()) / vm_page_size(); > } > > My proposed fix is to set MIN_STACK_YELLOW_PAGES, MIN_STACK_RED_PAGES, and MIN_STACK_SHADOW_PAGES to 1 in globals_aarch64.hpp > > Thanks for the review, > Ed. > > From roland.westrelin at oracle.com Tue Oct 27 16:17:14 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 27 Oct 2015 17:17:14 +0100 Subject: [9] RFR(S): 8140574: C2 must re-execute checks after deoptimizing from merged uncommon traps In-Reply-To: <562F9883.1050904@oracle.com> References: <562F5D3E.6070907@oracle.com> <562F927D.2030802@oracle.com> <896013D7-03B4-40B3-900B-9B258ED60AE8@oracle.com> <562F9883.1050904@oracle.com> Message-ID: > I see. So the only pattern we are looking for is where 'throw' is replaced with unstable_if uncommon trap. Actually, thinking about this more, I don?t think testing for unstable_if is sufficient. We could have something like this: if (i < 0) { if (some_condition) { // never taken so unc unstable_if } } if (i >= length) { // never taken so unc unstable_if } Then if the compiler proves some_condition is always true, we have: if (i < 0) { // never taken so unc unstable_if } if (i >= length) { // never taken so unc unstable_if } and we go ahead with the folding but the deoptimizatin in the first branch would have us resume execution after the i < 0 test. So I think we have to restrict when we apply that transformation even more, maybe matching the expected bytecode pattern more closely? Roland. > > Okay then. > > Thanks, > Vladimir > > On 10/27/15 11:09 PM, Roland Westrelin wrote: >>> Should we just additionally check re-execute flag? >>> >>> dom_unc->jvms()->should_reexecute() >>> >>> Unfortunately wee can't change reexecute flag since JVM state is already recorded according to it. >>> >>> Roland, what do you think? >> >> Is checking for should_reexecute() sufficient? Couldn?t we reexecute some bytecode in one branch that caused the branch to become dead but not the if itself? >> >> This change was put in so we optimize the pattern: >> >> if (i < 0 || i >= length) { throw? } >> >> of explicit array bound checks. Restricting it to unstable_if uncommon traps, doesn?t break that scenario so I would say that fix is good enough and feels safe. >> >> Roland. >> From adinn at redhat.com Tue Oct 27 16:17:45 2015 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 27 Oct 2015 16:17:45 +0000 Subject: [aarch64-port-dev ] RFR: 8140582: aarch64: jvm fails to initialise after 8078556 In-Reply-To: <1445941270.31480.9.camel@mint> References: <1445941270.31480.9.camel@mint> Message-ID: <562FA3A9.9030205@redhat.com> On 27/10/15 10:21, Edward Nevill wrote: > Please review the following webrev > > http://cr.openjdk.java.net/~enevill/8140582/webrev/ Looks good to me. regards, Andrew Dinn ----------- From konstantin.shefov at oracle.com Tue Oct 27 17:09:10 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Tue, 27 Oct 2015 20:09:10 +0300 Subject: [9] RFR 8131778: java disables UseAES flag when using VIS=2 on sparc Message-ID: <562FAFB6.7080305@oracle.com> Hello Please review a bug fix. JBS entry: https://bugs.openjdk.java.net/browse/JDK-8131778 Webrev: http://cr.openjdk.java.net/~kshefov/8131778/webrev.00 Thanks -Konstantin From vitalyd at gmail.com Tue Oct 27 17:23:48 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 27 Oct 2015 13:23:48 -0400 Subject: Using Array.newInstance still generates checkcast instructions Message-ID: Hi, I (intuitively) thought that using Array.newInstance() and specifying a final class (e.g. String) would remove checkcasts in the caller. However, it appears that the check is still generated (at least on 8u51). Why would this be? It seems the JIT should know the true runtime type of the array, and if accesses to it are inlined, the checkcast could be removed. Am I missing something? e.g. public final class ArrayList { private final T[] _items; public ArrayList(Class klass, int size) { _items = (T[])Array.newInstance(klass, size); } // rest omitted for brevity public T get(int index) { return _items[index]; } } ArrayList strings = new ArrayList<>(String.class, 10); String s = strings.get(0); // why is this checkcast not eliminated? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Tue Oct 27 17:40:49 2015 From: john.r.rose at oracle.com (John Rose) Date: Tue, 27 Oct 2015 10:40:49 -0700 Subject: Using Array.newInstance still generates checkcast instructions In-Reply-To: References: Message-ID: <7872D2FE-ECF8-4EDB-9674-49B949679F31@oracle.com> It's an old problem we have talked about before: There is only limited type inference through field loads. The JIT notes that the type of the heap variable is the erased Object[]. It does not attempt to attach special knowledge (T=String) to the type of 'strings' (ArrayList), because type parameter bindings are not completely reliable at runtime, due to the possibility of heap pollution (e.g., via reflective access). In some cases if the whole use case is inlined (as perhaps may happen here) then 'strings' can be scalarized and type propagation will be more accurate, since 'strings._items' would be lifted into a register. (Type prop. through locals is not disturbed by the possibility of reflective access, heap pollution, etc.) If you are seeing a cast then either (a) scalarization is incomplete (it can fail for even tiny reasons which is why we need un-aliasable value types), or (b) there is a bug somewhere. The likely bet is (a). ? John On Oct 27, 2015, at 10:23 AM, Vitaly Davidovich wrote: > > Hi, > > I (intuitively) thought that using Array.newInstance() and specifying a final class (e.g. String) would remove checkcasts in the caller. However, it appears that the check is still generated (at least on 8u51). Why would this be? It seems the JIT should know the true runtime type of the array, and if accesses to it are inlined, the checkcast could be removed. Am I missing something? > > e.g. > > public final class ArrayList { > private final T[] _items; > > public ArrayList(Class klass, int size) { > _items = (T[])Array.newInstance(klass, size); > } > > // rest omitted for brevity > > public T get(int index) { return _items[index]; } > > } > > ArrayList strings = new ArrayList<>(String.class, 10); > String s = strings.get(0); // why is this checkcast not eliminated? > > > Thanks From vitalyd at gmail.com Tue Oct 27 17:46:26 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 27 Oct 2015 13:46:26 -0400 Subject: Using Array.newInstance still generates checkcast instructions In-Reply-To: <7872D2FE-ECF8-4EDB-9674-49B949679F31@oracle.com> References: <7872D2FE-ECF8-4EDB-9674-49B949679F31@oracle.com> Message-ID: The whole use case is inlined here, which is the case that bothers me. If the underlying array access is inlined, couldn't its runtime type be checked? I don't understand the heap pollution issue in this case. The field is not Object[] at JIT time. sent from my phone On Oct 27, 2015 1:40 PM, "John Rose" wrote: > It's an old problem we have talked about before: There is only limited > type inference through field loads. The JIT notes that the type of the > heap variable is the erased Object[]. It does not attempt to attach > special knowledge (T=String) to the type of 'strings' (ArrayList), because > type parameter bindings are not completely reliable at runtime, due to the > possibility of heap pollution (e.g., via reflective access). > > In some cases if the whole use case is inlined (as perhaps may happen > here) then 'strings' can be scalarized and type propagation will be more > accurate, since 'strings._items' would be lifted into a register. (Type > prop. through locals is not disturbed by the possibility of reflective > access, heap pollution, etc.) If you are seeing a cast then either (a) > scalarization is incomplete (it can fail for even tiny reasons which is why > we need un-aliasable value types), or (b) there is a bug somewhere. The > likely bet is (a). > > ? John > > On Oct 27, 2015, at 10:23 AM, Vitaly Davidovich wrote: > > > > Hi, > > > > I (intuitively) thought that using Array.newInstance() and specifying a > final class (e.g. String) would remove checkcasts in the caller. However, > it appears that the check is still generated (at least on 8u51). Why would > this be? It seems the JIT should know the true runtime type of the array, > and if accesses to it are inlined, the checkcast could be removed. Am I > missing something? > > > > e.g. > > > > public final class ArrayList { > > private final T[] _items; > > > > public ArrayList(Class klass, int size) { > > _items = (T[])Array.newInstance(klass, size); > > } > > > > // rest omitted for brevity > > > > public T get(int index) { return _items[index]; } > > > > } > > > > ArrayList strings = new ArrayList<>(String.class, 10); > > String s = strings.get(0); // why is this checkcast not eliminated? > > > > > > Thanks > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalyd at gmail.com Tue Oct 27 17:55:22 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 27 Oct 2015 13:55:22 -0400 Subject: Using Array.newInstance still generates checkcast instructions In-Reply-To: References: <7872D2FE-ECF8-4EDB-9674-49B949679F31@oracle.com> Message-ID: By the way, the "old problem we talked about before" was different, I believe. It was about profiling field values, whereas here its just inspecting the runtime type of field at a callsite. sent from my phone On Oct 27, 2015 1:46 PM, "Vitaly Davidovich" wrote: > The whole use case is inlined here, which is the case that bothers me. If > the underlying array access is inlined, couldn't its runtime type be > checked? I don't understand the heap pollution issue in this case. The > field is not Object[] at JIT time. > > sent from my phone > On Oct 27, 2015 1:40 PM, "John Rose" wrote: > >> It's an old problem we have talked about before: There is only limited >> type inference through field loads. The JIT notes that the type of the >> heap variable is the erased Object[]. It does not attempt to attach >> special knowledge (T=String) to the type of 'strings' (ArrayList), because >> type parameter bindings are not completely reliable at runtime, due to the >> possibility of heap pollution (e.g., via reflective access). >> >> In some cases if the whole use case is inlined (as perhaps may happen >> here) then 'strings' can be scalarized and type propagation will be more >> accurate, since 'strings._items' would be lifted into a register. (Type >> prop. through locals is not disturbed by the possibility of reflective >> access, heap pollution, etc.) If you are seeing a cast then either (a) >> scalarization is incomplete (it can fail for even tiny reasons which is why >> we need un-aliasable value types), or (b) there is a bug somewhere. The >> likely bet is (a). >> >> ? John >> >> On Oct 27, 2015, at 10:23 AM, Vitaly Davidovich >> wrote: >> > >> > Hi, >> > >> > I (intuitively) thought that using Array.newInstance() and specifying a >> final class (e.g. String) would remove checkcasts in the caller. However, >> it appears that the check is still generated (at least on 8u51). Why would >> this be? It seems the JIT should know the true runtime type of the array, >> and if accesses to it are inlined, the checkcast could be removed. Am I >> missing something? >> > >> > e.g. >> > >> > public final class ArrayList { >> > private final T[] _items; >> > >> > public ArrayList(Class klass, int size) { >> > _items = (T[])Array.newInstance(klass, size); >> > } >> > >> > // rest omitted for brevity >> > >> > public T get(int index) { return _items[index]; } >> > >> > } >> > >> > ArrayList strings = new ArrayList<>(String.class, 10); >> > String s = strings.get(0); // why is this checkcast not eliminated? >> > >> > >> > Thanks >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Tue Oct 27 17:56:43 2015 From: john.r.rose at oracle.com (John Rose) Date: Tue, 27 Oct 2015 10:56:43 -0700 Subject: Using Array.newInstance still generates checkcast instructions In-Reply-To: References: <7872D2FE-ECF8-4EDB-9674-49B949679F31@oracle.com> Message-ID: <61A0A2EA-2623-48BD-9533-2D28FBC6E1E9@oracle.com> On Oct 27, 2015, at 10:46 AM, Vitaly Davidovich wrote: > > The whole use case is inlined here, which is the case that bothers me. If the underlying array access is inlined, couldn't its runtime type be checked? I don't understand the heap pollution issue in this case. The field is not Object[] at JIT time. > As a more more limited use case for Array.newInstance, see Arrays.copyOfRange (four argument version). That is supposed to copyOfRange(new String[2], ?) is supposed to feed through the right type to the return value, and it's a bug if it doesn't. There's some relevant difference in your use case (even after inlining) and copyOfRange; I think it's the field. Maybe our scalarization optimization is losing the type of the value; the rules for feeding types through fields (even after scalarization) are tricky. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksey.shipilev at oracle.com Tue Oct 27 18:00:38 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 27 Oct 2015 21:00:38 +0300 Subject: Using Array.newInstance still generates checkcast instructions In-Reply-To: References: <7872D2FE-ECF8-4EDB-9674-49B949679F31@oracle.com> Message-ID: <562FBBC6.2030206@oracle.com> The field is Object[] both in bytecode and "at JIT time". And you cannot do otherwise since pessimistically somebody can store, say, Integer instead of String there, thus polluting the heap. As John says, you can only propagate the type information if, among other things, the instance is guaranteed to avoid heap pollution. Compiler cannot change field types, it can only carry a limited set of constraints about the types... AFAIR, once instance escapes, all bets are off. But even if (hypothetically) dataflow analysis could have said the array has no suspicious writes before your access right after the construction, I am not very sure Array.newInstance is transparent for compiler at all. Mostly because it delegates to a native method and apparently has no vmSymbols entries that might indicate any special compiler treatment. Thanks, -Aleksey On 10/27/2015 08:46 PM, Vitaly Davidovich wrote: > The whole use case is inlined here, which is the case that bothers me. > If the underlying array access is inlined, couldn't its runtime type be > checked? I don't understand the heap pollution issue in this case. The > field is not Object[] at JIT time. > > sent from my phone > > On Oct 27, 2015 1:40 PM, "John Rose" > wrote: > > It's an old problem we have talked about before: There is only > limited type inference through field loads. The JIT notes that the > type of the heap variable is the erased Object[]. It does not > attempt to attach special knowledge (T=String) to the type of > 'strings' (ArrayList), because type parameter bindings are not > completely reliable at runtime, due to the possibility of heap > pollution (e.g., via reflective access). > > In some cases if the whole use case is inlined (as perhaps may > happen here) then 'strings' can be scalarized and type propagation > will be more accurate, since 'strings._items' would be lifted into a > register. (Type prop. through locals is not disturbed by the > possibility of reflective access, heap pollution, etc.) If you are > seeing a cast then either (a) scalarization is incomplete (it can > fail for even tiny reasons which is why we need un-aliasable value > types), or (b) there is a bug somewhere. The likely bet is (a). > > ? John > > On Oct 27, 2015, at 10:23 AM, Vitaly Davidovich > wrote: > > > > Hi, > > > > I (intuitively) thought that using Array.newInstance() and > specifying a final class (e.g. String) would remove checkcasts in > the caller. However, it appears that the check is still generated > (at least on 8u51). Why would this be? It seems the JIT should know > the true runtime type of the array, and if accesses to it are > inlined, the checkcast could be removed. Am I missing something? > > > > e.g. > > > > public final class ArrayList { > > private final T[] _items; > > > > public ArrayList(Class klass, int size) { > > _items = (T[])Array.newInstance(klass, size); > > } > > > > // rest omitted for brevity > > > > public T get(int index) { return _items[index]; } > > > > } > > > > ArrayList strings = new ArrayList<>(String.class, 10); > > String s = strings.get(0); // why is this checkcast not eliminated? > > > > > > Thanks > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From aleksey.shipilev at oracle.com Tue Oct 27 18:12:57 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 27 Oct 2015 21:12:57 +0300 Subject: Using Array.newInstance still generates checkcast instructions In-Reply-To: <562FBBC6.2030206@oracle.com> References: <7872D2FE-ECF8-4EDB-9674-49B949679F31@oracle.com> <562FBBC6.2030206@oracle.com> Message-ID: <562FBEA9.5040505@oracle.com> Ah no, my bad. C2 actually intrinsifies j.l.r.Array::newArray. I would think storing that array instance into Object[] field trips any subsequent analysis. If I were you, I'd do more differential tests: pulling the "string" from the near-allocated newArray, the same with load/store through String[], the same with load/store through Object[], etc. -Aleksey On 10/27/2015 09:00 PM, Aleksey Shipilev wrote: > The field is Object[] both in bytecode and "at JIT time". > > And you cannot do otherwise since pessimistically somebody can store, > say, Integer instead of String there, thus polluting the heap. As John > says, you can only propagate the type information if, among other > things, the instance is guaranteed to avoid heap pollution. Compiler > cannot change field types, it can only carry a limited set of > constraints about the types... > > AFAIR, once instance escapes, all bets are off. But even if > (hypothetically) dataflow analysis could have said the array has no > suspicious writes before your access right after the construction, I am > not very sure Array.newInstance is transparent for compiler at all. > Mostly because it delegates to a native method and apparently has no > vmSymbols entries that might indicate any special compiler treatment. > Thanks, > -Aleksey > > On 10/27/2015 08:46 PM, Vitaly Davidovich wrote: >> The whole use case is inlined here, which is the case that bothers me. >> If the underlying array access is inlined, couldn't its runtime type be >> checked? I don't understand the heap pollution issue in this case. The >> field is not Object[] at JIT time. >> >> sent from my phone >> >> On Oct 27, 2015 1:40 PM, "John Rose" > > wrote: >> >> It's an old problem we have talked about before: There is only >> limited type inference through field loads. The JIT notes that the >> type of the heap variable is the erased Object[]. It does not >> attempt to attach special knowledge (T=String) to the type of >> 'strings' (ArrayList), because type parameter bindings are not >> completely reliable at runtime, due to the possibility of heap >> pollution (e.g., via reflective access). >> >> In some cases if the whole use case is inlined (as perhaps may >> happen here) then 'strings' can be scalarized and type propagation >> will be more accurate, since 'strings._items' would be lifted into a >> register. (Type prop. through locals is not disturbed by the >> possibility of reflective access, heap pollution, etc.) If you are >> seeing a cast then either (a) scalarization is incomplete (it can >> fail for even tiny reasons which is why we need un-aliasable value >> types), or (b) there is a bug somewhere. The likely bet is (a). >> >> ? John >> >> On Oct 27, 2015, at 10:23 AM, Vitaly Davidovich > > wrote: >> > >> > Hi, >> > >> > I (intuitively) thought that using Array.newInstance() and >> specifying a final class (e.g. String) would remove checkcasts in >> the caller. However, it appears that the check is still generated >> (at least on 8u51). Why would this be? It seems the JIT should know >> the true runtime type of the array, and if accesses to it are >> inlined, the checkcast could be removed. Am I missing something? >> > >> > e.g. >> > >> > public final class ArrayList { >> > private final T[] _items; >> > >> > public ArrayList(Class klass, int size) { >> > _items = (T[])Array.newInstance(klass, size); >> > } >> > >> > // rest omitted for brevity >> > >> > public T get(int index) { return _items[index]; } >> > >> > } >> > >> > ArrayList strings = new ArrayList<>(String.class, 10); >> > String s = strings.get(0); // why is this checkcast not eliminated? >> > >> > >> > Thanks >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From vitalyd at gmail.com Tue Oct 27 18:14:55 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 27 Oct 2015 14:14:55 -0400 Subject: Using Array.newInstance still generates checkcast instructions In-Reply-To: <61A0A2EA-2623-48BD-9533-2D28FBC6E1E9@oracle.com> References: <7872D2FE-ECF8-4EDB-9674-49B949679F31@oracle.com> <61A0A2EA-2623-48BD-9533-2D28FBC6E1E9@oracle.com> Message-ID: Here's the basic example I used earlier, a bit more spelled out + assembly: static final class ArrayList { private final T[] _items; ArrayList(final Class klass, final int size) { _items = (T[]) Array.newInstance(klass, size); for (int i = 0; i < _items.length; ++i) { try { _items[i] = klass.newInstance(); } catch (InstantiationException | IllegalAccessException e) { throw new RuntimeException(e); } } } public T get(final int index) { return _items[index]; } } private static final ArrayList POOL = new ArrayList<>(String.class, 10); private static int get() { return POOL.get(0).length(); } Disassembly for get(): [Verified Entry Point] [Constants] # {method} {0x00007fcd5029f960} 'get' '()I' # [sp+0x20] (sp of caller) 0x00007fcd7a488820: mov %eax,-0x14000(%rsp) 0x00007fcd7a488827: push %rbp 0x00007fcd7a488828: sub $0x10,%rsp ;*synchronization entry 0x00007fcd7a48882c: mov $0x64890def0,%r10 ; {oop(`POOL`)} 0x00007fcd7a488836: mov 0xc(%r10),%r11d ;*getfield _items 0x00007fcd7a48883a: mov 0xc(%r12,%r11,8),%r10d ; implicit exception: dispatches to 0x00007fcd7a488895 0x00007fcd7a48883f: test %r10d,%r10d 0x00007fcd7a488842: jbe 0x00007fcd7a488870 0x00007fcd7a488844: mov 0x10(%r12,%r11,8),%ebp ;*aaload 0x00007fcd7a488849: mov 0x8(%r12,%rbp,8),%r11d ; implicit exception: dispatches to 0x00007fcd7a4888a5 * 0x00007fcd7a48884e: cmp $0xf80002da,%r11d ; {metadata('java/lang/String')}* 0x00007fcd7a488855: jne 0x00007fcd7a488885 0x00007fcd7a488857: lea (%r12,%rbp,8),%r10 ;*checkcast 0x00007fcd7a48885b: mov 0xc(%r10),%r10d ;*getfield value ; - java.lang.String::length at 1 (line 611) 0x00007fcd7a48885f: mov 0xc(%r12,%r10,8),%eax ;*arraylength ; - java.lang.String::length at 4 (line 611) ; implicit exception: dispatches to 0x00007fcd7a4888b5 0x00007fcd7a488864: add $0x10,%rsp 0x00007fcd7a488868: pop %rbp 0x00007fcd7a488869: test %eax,0x5e1d791(%rip) # 0x00007fcd802a6000 ; {poll_return} 0x00007fcd7a48886f: retq I even gave it a static final field (as the holder of the array) to work with :(. On Tue, Oct 27, 2015 at 1:56 PM, John Rose wrote: > On Oct 27, 2015, at 10:46 AM, Vitaly Davidovich wrote: > > > The whole use case is inlined here, which is the case that bothers me. If > the underlying array access is inlined, couldn't its runtime type be > checked? I don't understand the heap pollution issue in this case. The > field is not Object[] at JIT time. > > > As a more more limited use case for Array.newInstance, see > Arrays.copyOfRange (four argument version). > > That is supposed to copyOfRange(new String[2], ?) is supposed to feed > through the right type to the return value, and it's a bug if it doesn't. > > There's some relevant difference in your use case (even after inlining) > and copyOfRange; I think it's the field. Maybe our scalarization > optimization is losing the type of the value; the rules for feeding types > through fields (even after scalarization) are tricky. > > ? John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalyd at gmail.com Tue Oct 27 18:19:39 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 27 Oct 2015 14:19:39 -0400 Subject: Using Array.newInstance still generates checkcast instructions In-Reply-To: <562FBEA9.5040505@oracle.com> References: <7872D2FE-ECF8-4EDB-9674-49B949679F31@oracle.com> <562FBBC6.2030206@oracle.com> <562FBEA9.5040505@oracle.com> Message-ID: > > Ah no, my bad. C2 actually intrinsifies j.l.r.Array::newArray. That's right, it's intrinsified. But irrespective of that, the issue isn't speed of newArray but rather the dynamic type of the returned (and stored in a field in my example) array -- it's exactly the "reified" T[] (String[] in my example). I would think storing that array instance into Object[] field trips any > subsequent analysis. If I were you, I'd do more differential tests: > pulling the "string" from the near-allocated newArray, the same with > load/store through String[], the same with load/store through Object[], > etc. Again, the field is Object[] only statically. I know C2 does receiver type sharpening and other optimizations by looking at exact receiver type, so it's surprising that this isn't triggering here, in a few straightforward example (see the example I posted with assembly). This whole thing is an attempt at manually reifying generics, and hoping the JIT could see through it (at least in fully inlined callsites). On Tue, Oct 27, 2015 at 2:12 PM, Aleksey Shipilev < aleksey.shipilev at oracle.com> wrote: > Ah no, my bad. C2 actually intrinsifies j.l.r.Array::newArray. > > I would think storing that array instance into Object[] field trips any > subsequent analysis. If I were you, I'd do more differential tests: > pulling the "string" from the near-allocated newArray, the same with > load/store through String[], the same with load/store through Object[], > etc. > > -Aleksey > > On 10/27/2015 09:00 PM, Aleksey Shipilev wrote: > > The field is Object[] both in bytecode and "at JIT time". > > > > And you cannot do otherwise since pessimistically somebody can store, > > say, Integer instead of String there, thus polluting the heap. As John > > says, you can only propagate the type information if, among other > > things, the instance is guaranteed to avoid heap pollution. Compiler > > cannot change field types, it can only carry a limited set of > > constraints about the types... > > > > AFAIR, once instance escapes, all bets are off. But even if > > (hypothetically) dataflow analysis could have said the array has no > > suspicious writes before your access right after the construction, I am > > not very sure Array.newInstance is transparent for compiler at all. > > Mostly because it delegates to a native method and apparently has no > > vmSymbols entries that might indicate any special compiler treatment. > > Thanks, > > -Aleksey > > > > On 10/27/2015 08:46 PM, Vitaly Davidovich wrote: > >> The whole use case is inlined here, which is the case that bothers me. > >> If the underlying array access is inlined, couldn't its runtime type be > >> checked? I don't understand the heap pollution issue in this case. The > >> field is not Object[] at JIT time. > >> > >> sent from my phone > >> > >> On Oct 27, 2015 1:40 PM, "John Rose" >> > wrote: > >> > >> It's an old problem we have talked about before: There is only > >> limited type inference through field loads. The JIT notes that the > >> type of the heap variable is the erased Object[]. It does not > >> attempt to attach special knowledge (T=String) to the type of > >> 'strings' (ArrayList), because type parameter bindings are not > >> completely reliable at runtime, due to the possibility of heap > >> pollution (e.g., via reflective access). > >> > >> In some cases if the whole use case is inlined (as perhaps may > >> happen here) then 'strings' can be scalarized and type propagation > >> will be more accurate, since 'strings._items' would be lifted into a > >> register. (Type prop. through locals is not disturbed by the > >> possibility of reflective access, heap pollution, etc.) If you are > >> seeing a cast then either (a) scalarization is incomplete (it can > >> fail for even tiny reasons which is why we need un-aliasable value > >> types), or (b) there is a bug somewhere. The likely bet is (a). > >> > >> ? John > >> > >> On Oct 27, 2015, at 10:23 AM, Vitaly Davidovich >> > wrote: > >> > > >> > Hi, > >> > > >> > I (intuitively) thought that using Array.newInstance() and > >> specifying a final class (e.g. String) would remove checkcasts in > >> the caller. However, it appears that the check is still generated > >> (at least on 8u51). Why would this be? It seems the JIT should know > >> the true runtime type of the array, and if accesses to it are > >> inlined, the checkcast could be removed. Am I missing something? > >> > > >> > e.g. > >> > > >> > public final class ArrayList { > >> > private final T[] _items; > >> > > >> > public ArrayList(Class klass, int size) { > >> > _items = (T[])Array.newInstance(klass, size); > >> > } > >> > > >> > // rest omitted for brevity > >> > > >> > public T get(int index) { return _items[index]; } > >> > > >> > } > >> > > >> > ArrayList strings = new ArrayList<>(String.class, 10); > >> > String s = strings.get(0); // why is this checkcast not > eliminated? > >> > > >> > > >> > Thanks > >> > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.nevill at gmail.com Tue Oct 27 18:20:26 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 27 Oct 2015 18:20:26 +0000 Subject: RFR: 8140611: aarch64: jtreg test jdk/tools/pack200/UnpackerMemoryTest.java SEGVs Message-ID: <1445970026.31480.18.camel@mint> Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8140611/webrev/ JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8140611 Summary: The UnpackerMemoryTest SEGVs in jni_GetStringUTFChars. The problem is that c_rarg3 is a really bad choice for a tmp register since at this point the native arguments have been loaded into registers. (I confess guilt for this). 'lr' is a much better choice for the tmp register. We know this is free because we are just about to do a 'rt_call' which clobbers lr in any case. Thanks for the review, Ed. From vladimir.kozlov at oracle.com Wed Oct 28 02:59:36 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 28 Oct 2015 10:59:36 +0800 Subject: RFR: 8140611: aarch64: jtreg test jdk/tools/pack200/UnpackerMemoryTest.java SEGVs In-Reply-To: <1445970026.31480.18.camel@mint> References: <1445970026.31480.18.camel@mint> Message-ID: <56303A18.2070306@oracle.com> Good. Thanks, Vladimir On 10/28/15 2:20 AM, Edward Nevill wrote: > Hi, > > Please review the following webrev > > http://cr.openjdk.java.net/~enevill/8140611/webrev/ > > JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8140611 > > Summary: The UnpackerMemoryTest SEGVs in jni_GetStringUTFChars. > > The problem is that c_rarg3 is a really bad choice for a tmp register since at this point the native arguments have been loaded into registers. (I confess guilt for this). > > 'lr' is a much better choice for the tmp register. We know this is free because we are just about to do a 'rt_call' which clobbers lr in any case. > > Thanks for the review, > Ed. > > From adinn at redhat.com Wed Oct 28 08:27:10 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 28 Oct 2015 08:27:10 +0000 Subject: RFR: 8140611: aarch64: jtreg test jdk/tools/pack200/UnpackerMemoryTest.java SEGVs In-Reply-To: <1445970026.31480.18.camel@mint> References: <1445970026.31480.18.camel@mint> Message-ID: <563086DE.3070200@redhat.com> On 27/10/15 18:20, Edward Nevill wrote: > Please review the following webrev > > http://cr.openjdk.java.net/~enevill/8140611/webrev/ > > JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8140611 > > Summary: The UnpackerMemoryTest SEGVs in jni_GetStringUTFChars. > > The problem is that c_rarg3 is a really bad choice for a tmp register > since at this point the native arguments have been loaded into > registers. (I confess guilt for this). > > 'lr' is a much better choice for the tmp register. We know this is > free because we are just about to do a 'rt_call' which clobbers lr in > any case. Looks ok to me. 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 nils.eliasson at oracle.com Wed Oct 28 09:15:37 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 28 Oct 2015 10:15:37 +0100 Subject: RFR (S): 8140343: SEGV in DirectivesStack::getMatchingDirective In-Reply-To: <562B461B.3000402@oracle.com> References: <5629F7FC.7090008@oracle.com> <4CEF759F-3981-438A-B62C-9A7C30B32259@oracle.com> <562B461B.3000402@oracle.com> Message-ID: <56309239.3080601@oracle.com> Still open for review. Regards, Nils On 2015-10-24 10:49, Nils Eliasson wrote: > > On 2015-10-23 22:39, Christian Thalinger wrote: >>> On Oct 22, 2015, at 11:03 PM, Nils Eliasson >>> wrote: >>> >>> Hi all, >>> >>> This fixes a bug when using a compiler that doesn't have compiler >>> directives. This is a temporary fix using the default directive for c1. >> What are the default directives for C1 and C2? This fix is for JVMCI >> compilers and JVMCI compilers can only replace C2 in a tiered >> configuration. Depending on what they are, wouldn?t it make more >> sense to use C2?s default directives? > > The default directive is a directive that is always installed, always > enabled and contains all the default values from vmflags and compile > commands. This is the directive all compilations are using if no > additional directives are installed. >> >>> In the future permanent fix all compilers will have directives by >>> default. >> How would that look like? > > Long story. It is an internal implementation detail to the structure > of compiler directives. Right now there is a bit of an overhead adding > a new compiler, even if only a single flag is used. The idea is to > have all directives contain all flags for all compilers - it might > sound expensive but will actually be more efficient. The most common > use case is only having the default directive, and in this case the > common flags wouldn't have to be duplicated for each compiler. The > profit in the JVMCI case is that all the common flags are valid and > usable without any workaround. The improvement is straightforward and > wont affect any use site but is big enough not to be the fix of this bug. > > //Nils > > >>> bug: https://bugs.openjdk.java.net/browse/JDK-8140343 >>> webrev: http://cr.openjdk.java.net/~neliasso/8140343/webrev.01/ >>> >>> Please review, >>> Nils > From zoltan.majo at oracle.com Wed Oct 28 11:07:50 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 28 Oct 2015 12:07:50 +0100 Subject: [9] RFR(S): 8139907: compiler/intrinsics/montgomerymultiply/MontgomeryMultiplyTest.java fails with timeout Message-ID: <5630AC86.10104@oracle.com> Hi, please review the patch for JDK-8139907. https://bugs.openjdk.java.net/browse/JDK-8139907 Problem: The MontgomeryMultiplyTest times out on certain slow platforms. The MontgomeryMultiplyTest was added by JDK-8130150 to test the Montgomery multiply and square intrinsics. Although the intrinsics are available only on x86_64 and aarch64, the test is executed on all platforms, including slow platforms. Solution: Change test to execute only on platforms where intrinsics are available. Webrev: http://cr.openjdk.java.net/~zmajo/8139907/webrev.00/ Testing: - JPRT: the MontgomeryMultiplyTest tests is executed only on relevant platforms. Thank you and best regards, Zoltan From nils.eliasson at oracle.com Wed Oct 28 11:54:15 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 28 Oct 2015 12:54:15 +0100 Subject: [9] RFR(S): 8139907: compiler/intrinsics/montgomerymultiply/MontgomeryMultiplyTest.java fails with timeout In-Reply-To: <5630AC86.10104@oracle.com> References: <5630AC86.10104@oracle.com> Message-ID: <5630B767.1020808@oracle.com> Hi Zoltan, Looks good, Regards, Nils (Not a reviewer) On 2015-10-28 12:07, Zolt?n Maj? wrote: > Hi, > > > please review the patch for JDK-8139907. > > https://bugs.openjdk.java.net/browse/JDK-8139907 > > Problem: The MontgomeryMultiplyTest times out on certain slow > platforms. The MontgomeryMultiplyTest was added by JDK-8130150 to test > the Montgomery multiply and square intrinsics. Although the intrinsics > are available only on x86_64 and aarch64, the test is executed on all > platforms, including slow platforms. > > Solution: Change test to execute only on platforms where intrinsics > are available. > > Webrev: > http://cr.openjdk.java.net/~zmajo/8139907/webrev.00/ > > Testing: > - JPRT: the MontgomeryMultiplyTest tests is executed only on relevant > platforms. > > Thank you and best regards, > > > Zoltan > From nils.eliasson at oracle.com Wed Oct 28 12:08:08 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 28 Oct 2015 13:08:08 +0100 Subject: RFR(S): 8140581: Excluding compile messages should only be printed with PrintCompilation Message-ID: <5630BAA8.7070509@oracle.com> Hi, Please review this patch for JDK-8140581. "Excluding compile" has historically been on by default but suppressible with -XX:CompileCommand=quiet. This change makes it controllable by the PrintCompilation flag so that it shows up when the user actually wants to log information about compiles bug: https://bugs.openjdk.java.net/browse/JDK-8140581 webrev: http://cr.openjdk.java.net/~neliasso/8140581/webrev.01/ Regards, Nils Eliasson -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed Oct 28 12:39:39 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 28 Oct 2015 20:39:39 +0800 Subject: [9] RFR(S): 8139907: compiler/intrinsics/montgomerymultiply/MontgomeryMultiplyTest.java fails with timeout In-Reply-To: <5630AC86.10104@oracle.com> References: <5630AC86.10104@oracle.com> Message-ID: <5630C20B.2060303@oracle.com> Good. Thanks, Vladimir On 10/28/15 7:07 PM, Zolt?n Maj? wrote: > Hi, > > > please review the patch for JDK-8139907. > > https://bugs.openjdk.java.net/browse/JDK-8139907 > > Problem: The MontgomeryMultiplyTest times out on certain slow platforms. > The MontgomeryMultiplyTest was added by JDK-8130150 to test the > Montgomery multiply and square intrinsics. Although the intrinsics are > available only on x86_64 and aarch64, the test is executed on all > platforms, including slow platforms. > > Solution: Change test to execute only on platforms where intrinsics are > available. > > Webrev: > http://cr.openjdk.java.net/~zmajo/8139907/webrev.00/ > > Testing: > - JPRT: the MontgomeryMultiplyTest tests is executed only on relevant > platforms. > > Thank you and best regards, > > > Zoltan > From zoltan.majo at oracle.com Wed Oct 28 13:03:17 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 28 Oct 2015 14:03:17 +0100 Subject: [9] RFR(S): 8139907: compiler/intrinsics/montgomerymultiply/MontgomeryMultiplyTest.java fails with timeout In-Reply-To: <5630C20B.2060303@oracle.com> References: <5630AC86.10104@oracle.com> <5630C20B.2060303@oracle.com> Message-ID: <5630C795.9000107@oracle.com> Thank you, Vladimir and Nils, for the review! Best regards, Zoltan On 10/28/2015 01:39 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 10/28/15 7:07 PM, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the patch for JDK-8139907. >> >> https://bugs.openjdk.java.net/browse/JDK-8139907 >> >> Problem: The MontgomeryMultiplyTest times out on certain slow platforms. >> The MontgomeryMultiplyTest was added by JDK-8130150 to test the >> Montgomery multiply and square intrinsics. Although the intrinsics are >> available only on x86_64 and aarch64, the test is executed on all >> platforms, including slow platforms. >> >> Solution: Change test to execute only on platforms where intrinsics are >> available. >> >> Webrev: >> http://cr.openjdk.java.net/~zmajo/8139907/webrev.00/ >> >> Testing: >> - JPRT: the MontgomeryMultiplyTest tests is executed only on relevant >> platforms. >> >> Thank you and best regards, >> >> >> Zoltan >> From tobias.hartmann at oracle.com Wed Oct 28 13:07:25 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 28 Oct 2015 14:07:25 +0100 Subject: [9] RFR(S): 8140574: C2 must re-execute checks after deoptimizing from merged uncommon traps In-Reply-To: References: <562F5D3E.6070907@oracle.com> <562F927D.2030802@oracle.com> <896013D7-03B4-40B3-900B-9B258ED60AE8@oracle.com> <562F9883.1050904@oracle.com> Message-ID: <5630C88D.5000205@oracle.com> Thanks for the review, Vladimir and Roland! On 27.10.2015 17:17, Roland Westrelin wrote: >> I see. So the only pattern we are looking for is where 'throw' is replaced with unstable_if uncommon trap. > > Actually, thinking about this more, I don?t think testing for unstable_if is sufficient. We could have something like this: > > if (i < 0) { > if (some_condition) { > // never taken so unc unstable_if > } > } I agree that this would be a problem but why would be add an uncommon trap here? Either the i<0 branch is never executed, then we would add the uncommon trap like this if (i < 0) { // unc unstable_if } or it was executed and then also "some_condition" was true and we would not add an uncommon trap at all. > if (i >= length) { > // never taken so unc unstable_if > } > > Then if the compiler proves some_condition is always true, we have: > > if (i < 0) { > // never taken so unc unstable_if > } > if (i >= length) { > // never taken so unc unstable_if > } > > and we go ahead with the folding but the deoptimizatin in the first branch would have us resume execution after the i < 0 test. > > So I think we have to restrict when we apply that transformation even more, maybe matching the expected bytecode pattern more closely? I'm not sure how to do this. We would somehow have to make sure that the dominating uncommon trap "belongs" to the dominating if and not to some other if that was removed, right? Thanks, Tobias > > Roland. > >> >> Okay then. >> >> Thanks, >> Vladimir >> >> On 10/27/15 11:09 PM, Roland Westrelin wrote: >>>> Should we just additionally check re-execute flag? >>>> >>>> dom_unc->jvms()->should_reexecute() >>>> >>>> Unfortunately wee can't change reexecute flag since JVM state is already recorded according to it. >>>> >>>> Roland, what do you think? >>> >>> Is checking for should_reexecute() sufficient? Couldn?t we reexecute some bytecode in one branch that caused the branch to become dead but not the if itself? >>> >>> This change was put in so we optimize the pattern: >>> >>> if (i < 0 || i >= length) { throw? } >>> >>> of explicit array bound checks. Restricting it to unstable_if uncommon traps, doesn?t break that scenario so I would say that fix is good enough and feels safe. >>> >>> Roland. >>> > From vladimir.kozlov at oracle.com Wed Oct 28 13:08:06 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 28 Oct 2015 21:08:06 +0800 Subject: RFR(S): 8140581: Excluding compile messages should only be printed with PrintCompilation In-Reply-To: <5630BAA8.7070509@oracle.com> References: <5630BAA8.7070509@oracle.com> Message-ID: <5630C8B6.7070302@oracle.com> Why not (PrintCompilation && !quietly)? And leave set_not_compilable() call the same since print_made_not_compilable() has next condition: if (PrintCompilation && report) { Thanks, Vladimir On 10/28/15 8:08 PM, Nils Eliasson wrote: > Hi, > > Please review this patch for JDK-8140581. > > "Excluding compile" has historically been on by default but suppressible > with -XX:CompileCommand=quiet. This change makes it controllable by the > PrintCompilation flag so that it shows up when the user actually wants > to log information about compiles > > bug: https://bugs.openjdk.java.net/browse/JDK-8140581 > webrev: http://cr.openjdk.java.net/~neliasso/8140581/webrev.01/ > > Regards, > Nils Eliasson From roland.westrelin at oracle.com Wed Oct 28 13:33:59 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 28 Oct 2015 14:33:59 +0100 Subject: [9] RFR(S): 8140574: C2 must re-execute checks after deoptimizing from merged uncommon traps In-Reply-To: <5630C88D.5000205@oracle.com> References: <562F5D3E.6070907@oracle.com> <562F927D.2030802@oracle.com> <896013D7-03B4-40B3-900B-9B258ED60AE8@oracle.com> <562F9883.1050904@oracle.com> <5630C88D.5000205@oracle.com> Message-ID: <08638FB2-B0C8-4140-8913-77F80A9449C5@oracle.com> >> if (i < 0) { >> if (some_condition) { >> // never taken so unc unstable_if >> } >> } > > I agree that this would be a problem but why would be add an uncommon trap here? Either the i<0 branch is never executed, then we would add the uncommon trap like this > > if (i < 0) { > // unc unstable_if > } > > or it was executed and then also "some_condition" was true and we would not add an uncommon trap at all. Profiling is what tells us that we can cut one branch. It?s not 100% accurate. We could have: void m1(boolean flag) { if (i < 0) { if (flag) { } } } that is called a lot with flag false and i sometimes negative, sometimes positive so m1 is compiled, no more profiling is recorded and the profiling tells us the branch is never taken. Then we run: void m2(int i) { .. m1(i, flag); } with i always positive. During parsing the compiler is unable to prove flag always true, so we add the unc and after some optimization, flag is proven always true so the test is removed. For instance, this: for (int i = 0; i < 10; i++); flag = (i == 10); I think it would be worthwhile to check we can write a test case like this. >> So I think we have to restrict when we apply that transformation even more, maybe matching the expected bytecode pattern more closely? > > I'm not sure how to do this. We would somehow have to make sure that the dominating uncommon trap "belongs" to the dominating if and not to some other if that was removed, right? I suppose if we can prove that the bci of the unc for the dominating if dominates the bci of the unc of the dominated if then we?re good. Maybe by iterating over the ciTypeFlow blocks of the method. Roland. From nils.eliasson at oracle.com Wed Oct 28 13:39:05 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 28 Oct 2015 14:39:05 +0100 Subject: RFR(S): 8140581: Excluding compile messages should only be printed with PrintCompilation In-Reply-To: <5630C8B6.7070302@oracle.com> References: <5630BAA8.7070509@oracle.com> <5630C8B6.7070302@oracle.com> Message-ID: <5630CFF9.4070508@oracle.com> Having both works for me. http://cr.openjdk.java.net/~neliasso/8140581/webrev.02/ Thanks, Nils On 2015-10-28 14:08, Vladimir Kozlov wrote: > Why not (PrintCompilation && !quietly)? > > And leave set_not_compilable() call the same since > print_made_not_compilable() has next condition: > > if (PrintCompilation && report) { > > Thanks, > Vladimir > > On 10/28/15 8:08 PM, Nils Eliasson wrote: >> Hi, >> >> Please review this patch for JDK-8140581. >> >> "Excluding compile" has historically been on by default but suppressible >> with -XX:CompileCommand=quiet. This change makes it controllable by the >> PrintCompilation flag so that it shows up when the user actually wants >> to log information about compiles >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8140581 >> webrev: http://cr.openjdk.java.net/~neliasso/8140581/webrev.01/ >> >> Regards, >> Nils Eliasson From vladimir.kozlov at oracle.com Wed Oct 28 13:45:14 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 28 Oct 2015 21:45:14 +0800 Subject: RFR(S): 8140581: Excluding compile messages should only be printed with PrintCompilation In-Reply-To: <5630CFF9.4070508@oracle.com> References: <5630BAA8.7070509@oracle.com> <5630C8B6.7070302@oracle.com> <5630CFF9.4070508@oracle.com> Message-ID: <5630D16A.4080408@oracle.com> Okay. Thanks, Vladimir On 10/28/15 9:39 PM, Nils Eliasson wrote: > Having both works for me. > > http://cr.openjdk.java.net/~neliasso/8140581/webrev.02/ > > Thanks, > Nils > > On 2015-10-28 14:08, Vladimir Kozlov wrote: >> Why not (PrintCompilation && !quietly)? >> >> And leave set_not_compilable() call the same since >> print_made_not_compilable() has next condition: >> >> if (PrintCompilation && report) { >> >> Thanks, >> Vladimir >> >> On 10/28/15 8:08 PM, Nils Eliasson wrote: >>> Hi, >>> >>> Please review this patch for JDK-8140581. >>> >>> "Excluding compile" has historically been on by default but suppressible >>> with -XX:CompileCommand=quiet. This change makes it controllable by the >>> PrintCompilation flag so that it shows up when the user actually wants >>> to log information about compiles >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8140581 >>> webrev: http://cr.openjdk.java.net/~neliasso/8140581/webrev.01/ >>> >>> Regards, >>> Nils Eliasson > From nils.eliasson at oracle.com Wed Oct 28 14:10:08 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 28 Oct 2015 15:10:08 +0100 Subject: [9] RFR(S): 8138651: -XX:DisableIntrinsic matches intrinsics overly eagerly In-Reply-To: <562E35D1.9000105@oracle.com> References: <5613B7D5.5090702@oracle.com> <56148585.1020507@oracle.com> <5629E709.2000004@oracle.com> <562A1EC9.6020006@oracle.com> <562E35D1.9000105@oracle.com> Message-ID: <5630D740.6020904@oracle.com> Hi Zoltan, Thank you, it looks much better. I dislike the extra copy forced by using strtok in is_intrinsics_disabled. I tried rewriting it using strstr + checking trailing token but it didn't get any cleaner so I am ok with it. Make sure to run all the regression tests for compiler control in test/compiler/compilercontrol Best regards, Nils On 2015-10-26 15:16, Zolt?n Maj? wrote: > Hi Nils, > > > thank you for the feedback! > > On 10/23/2015 01:49 PM, Nils Eliasson wrote: >> Hi Zoltan, >> >> Some comments: >> >> IntrinsicDisabledTest.java: >> >> >> return >> >> System.getProperty("java.vm.name").toLowerCase().contains("server"); >> >> >> >> think the best practice is to use Platform.isServer() ("import >> jdk.test.lib.Platform;"). > > I did not know about that method. Thanks, I've updated the code. > >> >> compilerDirectives.cpp: >> >> I think the canonilization of the list belongs at the construction >> site, and not do at the (hot) use site. > > The call sites of DirectiveSet::is_intrinsic_disabled() are not that > hot, as they are called either when a method is compiled or through > the WhiteBox API. In the first case, the time spent on going through a > small character array containing disabled intrinsics is not be high > (relative to the time spent on compilation). The WhiteBox API is -- I > think -- not available in product builds. > > But from a design perspective it might be a better design to > canonicalize the string on construction. > >> Preferably we would agree on using the ',' separator in all use case >> (it only has internal uses). The compilecommand parser should be >> straightforward to fix. The VM flag may be parsed by a common parser >> that we can't change - then the vmflag value should be canonicalized >> during CompilerBroker_init or similar. > > There are other flags of type ccstrlist. Changing the way a ccstrlist > flags are parsed might affect these as well, so I would not want to > change the way the VM parses flags. > >> >> If there is some reason to why that doesn't work then I would suggest >> moving the canonicalization to DirectiveSet constructor and >> DirectiveSet::clone so it only happens once per DirectiveSet. > > That is a good idea. The new webrev performs canonicalization > - in the DirectiveSet constructor, when the value of the global > DisableIntrinsic flag is read; > - in the DirectiveSet::compilecommand_compatibility_init() method, > when the value of the per-method DisableIntrinsic flag is read. > > Here is the updated webrev: > http://cr.openjdk.java.net/~zmajo/8138651/webrev.02/ > > I've tested the updated webrev with: > - JPRT (testset hotspot), all tests pass; > - locally executing all hotspot tests, all tests pass that pass with > the unmodified version of the VM. > > Thank you and best regards, > > > Zoltan > >> >> Best regards, >> Nils >> >> >> >> >> >> On 2015-10-23 09:51, Zolt?n Maj? wrote: >> > Hi Vladimir, > > > thank you for the feedback! > > On 10/07/2015 >> 04:37 AM, Vladimir Kozlov wrote: >> To be precise DisableIntrinsic is >> ccstrlist option, not ccstr. Yes, >> the actual type is the same. >> >> >> An other concern is separators since format could be different if >> >> option specified in file. Look how we do search in >> DeoptimizeOnlyAt >> string. > > I've checked and DisableIntrinsic >> supports accumulation of argument > values: If -XX:DisableIntrinsic >> is specified multiple times on the > command line, all argument >> values are concatenated into one argument. > In that case, '\n' is >> used as separator. I updated the webrev to > support "\n" as a >> separator. > > If DisableIntrinsic is used on the per-method level >> (i.e., with > -XX:CompileCommand=option,...), HotSpot expects the >> type of > DisableIntrinsic to be 'ccstr' and not 'ccstrlist'. That >> does not > allow specifying a list of intrinsics to be disabled >> (e.g., > _getInt,_getInVolatile,_hashCode) and is inconsistent with >> the > declaration of DisableIntrinsic in globals.hpp. > > To address >> this problem, the webrev changes the type of the > per-method level >> DisableIntrinsic flag to 'ccstrlist'. For per-method > ccstrlists, >> the separator is a whitespace (internally). I've updated > the webrev >> to support whitespace as a separator as well. > > I noticed an other >> problem while working on this fix: If > DisableIntrinsic is specified >> multiple times for the same method, > argument values do not >> accumulate. For example, with > > >> -XX:CompileCommand=option,sun.misc.Unsafe::putChar,ccstrlist,DisableIntrinsic,_getInt,_getIntVolatile >> > > >> -XX:CompileCommand=option,sun.misc.Unsafe::putChar,ccstrlist,DisableIntrinsic,_hashCode >> >> >> only '_hashCode' will be disabled for 'putChar'. That is also > >> inconsistent with the way DisableIntrinsic works when used globally > >> (with -XX:DisableIntrinsic). > > This inconsistency should be >> addressed, but as the fix requires > significant changes to >> CompilerOracle, I would like to take care of > that separately. I've >> filed an RFE for that: > > >> https://bugs.openjdk.java.net/browse/JDK-8140322 > > I hope that is >> fine. > > Here is the updated webrev: > >> http://cr.openjdk.java.net/~zmajo/8138651/webrev.01/ > > Testing: - >> JPRT (testset hotspot, including the newly added > >> IntrinsicDisabledTest.java test). > > Thank you and best regards, > > >> > Zoltan > >> >> Thanks, Vladimir >> >> On 10/6/15 8:00 PM, Zolt?n >> Maj? wrote: >>> Hi, >>> >>> >>> please review the patch for >> JDK-8138651. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8138651 >> >>> >>> Problem: The DisableIntrinsic flag does not disable >> intrinsics >>> accurately. For example, >> -XX:DisableIntrinsic=_copyOfRange >>> disables both the intrinsic >> with the ID _copyOfRange and the >>> intrinsic with the _copyOf. >>> >> >>> Solution: Change the processing of the DisableIntrinsic flag >>> >> (both globally and on a per-method level). >>> >>> Webrev: >> http://cr.openjdk.java.net/~zmajo/8138651/webrev.00/ >>> >>> Testing: >> - JPRT (testset hotspot); - executed the the newly added >>> test >> compiler/intrinsics/IntrinsicDisabledTest.java with/without >>> the >> fix on all platforms, the test behaves as expected. >>> >>> Thank you >> and best regards, >>> >>> >>> Zoltan >>> > >> >> > From zoltan.majo at oracle.com Wed Oct 28 14:46:58 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 28 Oct 2015 15:46:58 +0100 Subject: [9] RFR(S): 8138651: -XX:DisableIntrinsic matches intrinsics overly eagerly In-Reply-To: <5630D740.6020904@oracle.com> References: <5613B7D5.5090702@oracle.com> <56148585.1020507@oracle.com> <5629E709.2000004@oracle.com> <562A1EC9.6020006@oracle.com> <562E35D1.9000105@oracle.com> <5630D740.6020904@oracle.com> Message-ID: <5630DFE2.1090401@oracle.com> Hi Nils, On 10/28/2015 03:10 PM, Nils Eliasson wrote: > Hi Zoltan, > > Thank you, it looks much better. thank you for the review! > > I dislike the extra copy forced by using strtok in > is_intrinsics_disabled. I tried rewriting it using strstr + checking > trailing token but it didn't get any cleaner so I am ok with it. Thanks. > > Make sure to run all the regression tests for compiler control in > test/compiler/compilercontrol I ran them, all tests pass that pass with an unmodified VM. > > Best regards, Thank you and best regards, Zoltan > Nils > > > > On 2015-10-26 15:16, Zolt?n Maj? wrote: >> Hi Nils, >> >> >> thank you for the feedback! >> >> On 10/23/2015 01:49 PM, Nils Eliasson wrote: >>> Hi Zoltan, >>> >>> Some comments: >>> >>> IntrinsicDisabledTest.java: >>> >>> >> return >> >>> System.getProperty("java.vm.name").toLowerCase().contains("server"); >>> >> >>> >>> think the best practice is to use Platform.isServer() ("import >>> jdk.test.lib.Platform;"). >> >> I did not know about that method. Thanks, I've updated the code. >> >>> >>> compilerDirectives.cpp: >>> >>> I think the canonilization of the list belongs at the construction >>> site, and not do at the (hot) use site. >> >> The call sites of DirectiveSet::is_intrinsic_disabled() are not that >> hot, as they are called either when a method is compiled or through >> the WhiteBox API. In the first case, the time spent on going through >> a small character array containing disabled intrinsics is not be high >> (relative to the time spent on compilation). The WhiteBox API is -- I >> think -- not available in product builds. >> >> But from a design perspective it might be a better design to >> canonicalize the string on construction. >> >>> Preferably we would agree on using the ',' separator in all use case >>> (it only has internal uses). The compilecommand parser should be >>> straightforward to fix. The VM flag may be parsed by a common parser >>> that we can't change - then the vmflag value should be canonicalized >>> during CompilerBroker_init or similar. >> >> There are other flags of type ccstrlist. Changing the way a ccstrlist >> flags are parsed might affect these as well, so I would not want to >> change the way the VM parses flags. >> >>> >>> If there is some reason to why that doesn't work then I would >>> suggest moving the canonicalization to DirectiveSet constructor and >>> DirectiveSet::clone so it only happens once per DirectiveSet. >> >> That is a good idea. The new webrev performs canonicalization >> - in the DirectiveSet constructor, when the value of the global >> DisableIntrinsic flag is read; >> - in the DirectiveSet::compilecommand_compatibility_init() method, >> when the value of the per-method DisableIntrinsic flag is read. >> >> Here is the updated webrev: >> http://cr.openjdk.java.net/~zmajo/8138651/webrev.02/ >> >> I've tested the updated webrev with: >> - JPRT (testset hotspot), all tests pass; >> - locally executing all hotspot tests, all tests pass that pass with >> the unmodified version of the VM. >> >> Thank you and best regards, >> >> >> Zoltan >> >>> >>> Best regards, >>> Nils >>> >>> >>> >>> >>> >>> On 2015-10-23 09:51, Zolt?n Maj? wrote: >>> > Hi Vladimir, > > > thank you for the feedback! > > On 10/07/2015 >>> 04:37 AM, Vladimir Kozlov wrote: >> To be precise DisableIntrinsic >>> is ccstrlist option, not ccstr. Yes, >> the actual type is the same. >>> >> >> An other concern is separators since format could be different >>> if >> option specified in file. Look how we do search in >>> DeoptimizeOnlyAt >> string. > > I've checked and DisableIntrinsic >>> supports accumulation of argument > values: If -XX:DisableIntrinsic >>> is specified multiple times on the > command line, all argument >>> values are concatenated into one argument. > In that case, '\n' is >>> used as separator. I updated the webrev to > support "\n" as a >>> separator. > > If DisableIntrinsic is used on the per-method level >>> (i.e., with > -XX:CompileCommand=option,...), HotSpot expects the >>> type of > DisableIntrinsic to be 'ccstr' and not 'ccstrlist'. That >>> does not > allow specifying a list of intrinsics to be disabled >>> (e.g., > _getInt,_getInVolatile,_hashCode) and is inconsistent with >>> the > declaration of DisableIntrinsic in globals.hpp. > > To address >>> this problem, the webrev changes the type of the > per-method level >>> DisableIntrinsic flag to 'ccstrlist'. For per-method > ccstrlists, >>> the separator is a whitespace (internally). I've updated > the >>> webrev to support whitespace as a separator as well. > > I noticed >>> an other problem while working on this fix: If > DisableIntrinsic is >>> specified multiple times for the same method, > argument values do >>> not accumulate. For example, with > > >>> -XX:CompileCommand=option,sun.misc.Unsafe::putChar,ccstrlist,DisableIntrinsic,_getInt,_getIntVolatile >>> > > >>> -XX:CompileCommand=option,sun.misc.Unsafe::putChar,ccstrlist,DisableIntrinsic,_hashCode >>> >>> >> only '_hashCode' will be disabled for 'putChar'. That is also > >>> inconsistent with the way DisableIntrinsic works when used globally >>> > (with -XX:DisableIntrinsic). > > This inconsistency should be >>> addressed, but as the fix requires > significant changes to >>> CompilerOracle, I would like to take care of > that separately. I've >>> filed an RFE for that: > > >>> https://bugs.openjdk.java.net/browse/JDK-8140322 > > I hope that is >>> fine. > > Here is the updated webrev: > >>> http://cr.openjdk.java.net/~zmajo/8138651/webrev.01/ > > Testing: - >>> JPRT (testset hotspot, including the newly added > >>> IntrinsicDisabledTest.java test). > > Thank you and best regards, > >>> > > Zoltan > >> >> Thanks, Vladimir >> >> On 10/6/15 8:00 PM, Zolt?n >>> Maj? wrote: >>> Hi, >>> >>> >>> please review the patch for >>> JDK-8138651. >>> >>> >>> https://bugs.openjdk.java.net/browse/JDK-8138651 >>> >>> Problem: >>> The DisableIntrinsic flag does not disable intrinsics >>> >>> accurately. For example, -XX:DisableIntrinsic=_copyOfRange >>> >>> disables both the intrinsic with the ID _copyOfRange and the >>> >>> intrinsic with the _copyOf. >>> >>> Solution: Change the processing >>> of the DisableIntrinsic flag >>> (both globally and on a per-method >>> level). >>> >>> Webrev: >>> http://cr.openjdk.java.net/~zmajo/8138651/webrev.00/ >>> >>> >>> Testing: - JPRT (testset hotspot); - executed the the newly added >>> >>> test compiler/intrinsics/IntrinsicDisabledTest.java with/without >>> >>> the fix on all platforms, the test behaves as expected. >>> >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> > >>> >>> >> > From zoltan.majo at oracle.com Wed Oct 28 14:58:51 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 28 Oct 2015 15:58:51 +0100 Subject: [9] RFR(S): 8138651: -XX:DisableIntrinsic matches intrinsics overly eagerly In-Reply-To: <5630DFE2.1090401@oracle.com> References: <5613B7D5.5090702@oracle.com> <56148585.1020507@oracle.com> <5629E709.2000004@oracle.com> <562A1EC9.6020006@oracle.com> <562E35D1.9000105@oracle.com> <5630D740.6020904@oracle.com> <5630DFE2.1090401@oracle.com> Message-ID: <5630E2AB.9050004@oracle.com> Hi, For the record: I plan to push the latest webrev (webrev.02) tomorrow (Oct 29), unless, of course, there are other suggestions on how to improve this patch. Thank you and best regards, Zoltan On 10/28/2015 03:46 PM, Zolt?n Maj? wrote: > Hi Nils, > > > On 10/28/2015 03:10 PM, Nils Eliasson wrote: >> Hi Zoltan, >> >> Thank you, it looks much better. > > thank you for the review! > >> >> I dislike the extra copy forced by using strtok in >> is_intrinsics_disabled. I tried rewriting it using strstr + checking >> trailing token but it didn't get any cleaner so I am ok with it. > > Thanks. > >> >> Make sure to run all the regression tests for compiler control in >> test/compiler/compilercontrol > > I ran them, all tests pass that pass with an unmodified VM. > >> >> Best regards, > > Thank you and best regards, > > > Zoltan > >> Nils >> >> >> >> On 2015-10-26 15:16, Zolt?n Maj? wrote: >>> Hi Nils, >>> >>> >>> thank you for the feedback! >>> >>> On 10/23/2015 01:49 PM, Nils Eliasson wrote: >>>> Hi Zoltan, >>>> >>>> Some comments: >>>> >>>> IntrinsicDisabledTest.java: >>>> >>>> >> return >> >>>> System.getProperty("java.vm.name").toLowerCase().contains("server"); >>>> >> >>>> >>>> think the best practice is to use Platform.isServer() ("import >>>> jdk.test.lib.Platform;"). >>> >>> I did not know about that method. Thanks, I've updated the code. >>> >>>> >>>> compilerDirectives.cpp: >>>> >>>> I think the canonilization of the list belongs at the construction >>>> site, and not do at the (hot) use site. >>> >>> The call sites of DirectiveSet::is_intrinsic_disabled() are not that >>> hot, as they are called either when a method is compiled or through >>> the WhiteBox API. In the first case, the time spent on going through >>> a small character array containing disabled intrinsics is not be >>> high (relative to the time spent on compilation). The WhiteBox API >>> is -- I think -- not available in product builds. >>> >>> But from a design perspective it might be a better design to >>> canonicalize the string on construction. >>> >>>> Preferably we would agree on using the ',' separator in all use >>>> case (it only has internal uses). The compilecommand parser should >>>> be straightforward to fix. The VM flag may be parsed by a common >>>> parser that we can't change - then the vmflag value should be >>>> canonicalized during CompilerBroker_init or similar. >>> >>> There are other flags of type ccstrlist. Changing the way a >>> ccstrlist flags are parsed might affect these as well, so I would >>> not want to change the way the VM parses flags. >>> >>>> >>>> If there is some reason to why that doesn't work then I would >>>> suggest moving the canonicalization to DirectiveSet constructor and >>>> DirectiveSet::clone so it only happens once per DirectiveSet. >>> >>> That is a good idea. The new webrev performs canonicalization >>> - in the DirectiveSet constructor, when the value of the global >>> DisableIntrinsic flag is read; >>> - in the DirectiveSet::compilecommand_compatibility_init() method, >>> when the value of the per-method DisableIntrinsic flag is read. >>> >>> Here is the updated webrev: >>> http://cr.openjdk.java.net/~zmajo/8138651/webrev.02/ >>> >>> I've tested the updated webrev with: >>> - JPRT (testset hotspot), all tests pass; >>> - locally executing all hotspot tests, all tests pass that pass with >>> the unmodified version of the VM. >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> >>>> >>>> Best regards, >>>> Nils >>>> >>>> >>>> >>>> >>>> >>>> On 2015-10-23 09:51, Zolt?n Maj? wrote: >>>> > Hi Vladimir, > > > thank you for the feedback! > > On 10/07/2015 >>>> 04:37 AM, Vladimir Kozlov wrote: >> To be precise DisableIntrinsic >>>> is ccstrlist option, not ccstr. Yes, >> the actual type is the >>>> same. >> >> An other concern is separators since format could be >>>> different if >> option specified in file. Look how we do search in >>>> DeoptimizeOnlyAt >> string. > > I've checked and DisableIntrinsic >>>> supports accumulation of argument > values: If -XX:DisableIntrinsic >>>> is specified multiple times on the > command line, all argument >>>> values are concatenated into one argument. > In that case, '\n' is >>>> used as separator. I updated the webrev to > support "\n" as a >>>> separator. > > If DisableIntrinsic is used on the per-method level >>>> (i.e., with > -XX:CompileCommand=option,...), HotSpot expects the >>>> type of > DisableIntrinsic to be 'ccstr' and not 'ccstrlist'. That >>>> does not > allow specifying a list of intrinsics to be disabled >>>> (e.g., > _getInt,_getInVolatile,_hashCode) and is inconsistent with >>>> the > declaration of DisableIntrinsic in globals.hpp. > > To >>>> address this problem, the webrev changes the type of the > >>>> per-method level DisableIntrinsic flag to 'ccstrlist'. For >>>> per-method > ccstrlists, the separator is a whitespace >>>> (internally). I've updated > the webrev to support whitespace as a >>>> separator as well. > > I noticed an other problem while working on >>>> this fix: If > DisableIntrinsic is specified multiple times for the >>>> same method, > argument values do not accumulate. For example, with >>>> > > >>>> -XX:CompileCommand=option,sun.misc.Unsafe::putChar,ccstrlist,DisableIntrinsic,_getInt,_getIntVolatile >>>> > > >>>> -XX:CompileCommand=option,sun.misc.Unsafe::putChar,ccstrlist,DisableIntrinsic,_hashCode >>>> >>>> >> only '_hashCode' will be disabled for 'putChar'. That is also > >>>> inconsistent with the way DisableIntrinsic works when used globally >>>> > (with -XX:DisableIntrinsic). > > This inconsistency should be >>>> addressed, but as the fix requires > significant changes to >>>> CompilerOracle, I would like to take care of > that separately. >>>> I've filed an RFE for that: > > >>>> https://bugs.openjdk.java.net/browse/JDK-8140322 > > I hope that is >>>> fine. > > Here is the updated webrev: > >>>> http://cr.openjdk.java.net/~zmajo/8138651/webrev.01/ > > Testing: - >>>> JPRT (testset hotspot, including the newly added > >>>> IntrinsicDisabledTest.java test). > > Thank you and best regards, > >>>> > > Zoltan > >> >> Thanks, Vladimir >> >> On 10/6/15 8:00 PM, >>>> Zolt?n Maj? wrote: >>> Hi, >>> >>> >>> please review the patch for >>>> JDK-8138651. >>> >>> >>>> https://bugs.openjdk.java.net/browse/JDK-8138651 >>> >>> Problem: >>>> The DisableIntrinsic flag does not disable intrinsics >>> >>>> accurately. For example, -XX:DisableIntrinsic=_copyOfRange >>> >>>> disables both the intrinsic with the ID _copyOfRange and the >>> >>>> intrinsic with the _copyOf. >>> >>> Solution: Change the processing >>>> of the DisableIntrinsic flag >>> (both globally and on a per-method >>>> level). >>> >>> Webrev: >>>> http://cr.openjdk.java.net/~zmajo/8138651/webrev.00/ >>> >>> >>>> Testing: - JPRT (testset hotspot); - executed the the newly added >>>> >>> test compiler/intrinsics/IntrinsicDisabledTest.java >>>> with/without >>> the fix on all platforms, the test behaves as >>>> expected. >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> > >>>> >>>> >>> >> > From vladimir.kozlov at oracle.com Wed Oct 28 15:09:00 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 28 Oct 2015 23:09:00 +0800 Subject: [9] RFR(S): 8138651: -XX:DisableIntrinsic matches intrinsics overly eagerly In-Reply-To: <5630E2AB.9050004@oracle.com> References: <5613B7D5.5090702@oracle.com> <56148585.1020507@oracle.com> <5629E709.2000004@oracle.com> <562A1EC9.6020006@oracle.com> <562E35D1.9000105@oracle.com> <5630D740.6020904@oracle.com> <5630DFE2.1090401@oracle.com> <5630E2AB.9050004@oracle.com> Message-ID: <5630E50C.1060502@oracle.com> Sounds good. Thanks, Vladimir On 10/28/15 10:58 PM, Zolt?n Maj? wrote: > Hi, > > > For the record: I plan to push the latest webrev (webrev.02) tomorrow > (Oct 29), unless, of course, there are other suggestions on how to > improve this patch. > > Thank you and best regards, > > > Zoltan > > > On 10/28/2015 03:46 PM, Zolt?n Maj? wrote: >> Hi Nils, >> >> >> On 10/28/2015 03:10 PM, Nils Eliasson wrote: >>> Hi Zoltan, >>> >>> Thank you, it looks much better. >> >> thank you for the review! >> >>> >>> I dislike the extra copy forced by using strtok in >>> is_intrinsics_disabled. I tried rewriting it using strstr + checking >>> trailing token but it didn't get any cleaner so I am ok with it. >> >> Thanks. >> >>> >>> Make sure to run all the regression tests for compiler control in >>> test/compiler/compilercontrol >> >> I ran them, all tests pass that pass with an unmodified VM. >> >>> >>> Best regards, >> >> Thank you and best regards, >> >> >> Zoltan >> >>> Nils >>> >>> >>> >>> On 2015-10-26 15:16, Zolt?n Maj? wrote: >>>> Hi Nils, >>>> >>>> >>>> thank you for the feedback! >>>> >>>> On 10/23/2015 01:49 PM, Nils Eliasson wrote: >>>>> Hi Zoltan, >>>>> >>>>> Some comments: >>>>> >>>>> IntrinsicDisabledTest.java: >>>>> >>>>> >> return >> >>>>> System.getProperty("java.vm.name").toLowerCase().contains("server"); >>>>> >> >>>>> >>>>> think the best practice is to use Platform.isServer() ("import >>>>> jdk.test.lib.Platform;"). >>>> >>>> I did not know about that method. Thanks, I've updated the code. >>>> >>>>> >>>>> compilerDirectives.cpp: >>>>> >>>>> I think the canonilization of the list belongs at the construction >>>>> site, and not do at the (hot) use site. >>>> >>>> The call sites of DirectiveSet::is_intrinsic_disabled() are not that >>>> hot, as they are called either when a method is compiled or through >>>> the WhiteBox API. In the first case, the time spent on going through >>>> a small character array containing disabled intrinsics is not be >>>> high (relative to the time spent on compilation). The WhiteBox API >>>> is -- I think -- not available in product builds. >>>> >>>> But from a design perspective it might be a better design to >>>> canonicalize the string on construction. >>>> >>>>> Preferably we would agree on using the ',' separator in all use >>>>> case (it only has internal uses). The compilecommand parser should >>>>> be straightforward to fix. The VM flag may be parsed by a common >>>>> parser that we can't change - then the vmflag value should be >>>>> canonicalized during CompilerBroker_init or similar. >>>> >>>> There are other flags of type ccstrlist. Changing the way a >>>> ccstrlist flags are parsed might affect these as well, so I would >>>> not want to change the way the VM parses flags. >>>> >>>>> >>>>> If there is some reason to why that doesn't work then I would >>>>> suggest moving the canonicalization to DirectiveSet constructor and >>>>> DirectiveSet::clone so it only happens once per DirectiveSet. >>>> >>>> That is a good idea. The new webrev performs canonicalization >>>> - in the DirectiveSet constructor, when the value of the global >>>> DisableIntrinsic flag is read; >>>> - in the DirectiveSet::compilecommand_compatibility_init() method, >>>> when the value of the per-method DisableIntrinsic flag is read. >>>> >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~zmajo/8138651/webrev.02/ >>>> >>>> I've tested the updated webrev with: >>>> - JPRT (testset hotspot), all tests pass; >>>> - locally executing all hotspot tests, all tests pass that pass with >>>> the unmodified version of the VM. >>>> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> >>>>> >>>>> Best regards, >>>>> Nils >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 2015-10-23 09:51, Zolt?n Maj? wrote: >>>>> > Hi Vladimir, > > > thank you for the feedback! > > On 10/07/2015 >>>>> 04:37 AM, Vladimir Kozlov wrote: >> To be precise DisableIntrinsic >>>>> is ccstrlist option, not ccstr. Yes, >> the actual type is the >>>>> same. >> >> An other concern is separators since format could be >>>>> different if >> option specified in file. Look how we do search in >>>>> DeoptimizeOnlyAt >> string. > > I've checked and DisableIntrinsic >>>>> supports accumulation of argument > values: If -XX:DisableIntrinsic >>>>> is specified multiple times on the > command line, all argument >>>>> values are concatenated into one argument. > In that case, '\n' is >>>>> used as separator. I updated the webrev to > support "\n" as a >>>>> separator. > > If DisableIntrinsic is used on the per-method level >>>>> (i.e., with > -XX:CompileCommand=option,...), HotSpot expects the >>>>> type of > DisableIntrinsic to be 'ccstr' and not 'ccstrlist'. That >>>>> does not > allow specifying a list of intrinsics to be disabled >>>>> (e.g., > _getInt,_getInVolatile,_hashCode) and is inconsistent with >>>>> the > declaration of DisableIntrinsic in globals.hpp. > > To >>>>> address this problem, the webrev changes the type of the > >>>>> per-method level DisableIntrinsic flag to 'ccstrlist'. For >>>>> per-method > ccstrlists, the separator is a whitespace >>>>> (internally). I've updated > the webrev to support whitespace as a >>>>> separator as well. > > I noticed an other problem while working on >>>>> this fix: If > DisableIntrinsic is specified multiple times for the >>>>> same method, > argument values do not accumulate. For example, with >>>>> > > >>>>> -XX:CompileCommand=option,sun.misc.Unsafe::putChar,ccstrlist,DisableIntrinsic,_getInt,_getIntVolatile >>>>> > > >>>>> -XX:CompileCommand=option,sun.misc.Unsafe::putChar,ccstrlist,DisableIntrinsic,_hashCode >>>>> >>>>> >> only '_hashCode' will be disabled for 'putChar'. That is also > >>>>> inconsistent with the way DisableIntrinsic works when used globally >>>>> > (with -XX:DisableIntrinsic). > > This inconsistency should be >>>>> addressed, but as the fix requires > significant changes to >>>>> CompilerOracle, I would like to take care of > that separately. >>>>> I've filed an RFE for that: > > >>>>> https://bugs.openjdk.java.net/browse/JDK-8140322 > > I hope that is >>>>> fine. > > Here is the updated webrev: > >>>>> http://cr.openjdk.java.net/~zmajo/8138651/webrev.01/ > > Testing: - >>>>> JPRT (testset hotspot, including the newly added > >>>>> IntrinsicDisabledTest.java test). > > Thank you and best regards, > >>>>> > > Zoltan > >> >> Thanks, Vladimir >> >> On 10/6/15 8:00 PM, >>>>> Zolt?n Maj? wrote: >>> Hi, >>> >>> >>> please review the patch for >>>>> JDK-8138651. >>> >>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8138651 >>> >>> Problem: >>>>> The DisableIntrinsic flag does not disable intrinsics >>> >>>>> accurately. For example, -XX:DisableIntrinsic=_copyOfRange >>> >>>>> disables both the intrinsic with the ID _copyOfRange and the >>> >>>>> intrinsic with the _copyOf. >>> >>> Solution: Change the processing >>>>> of the DisableIntrinsic flag >>> (both globally and on a per-method >>>>> level). >>> >>> Webrev: >>>>> http://cr.openjdk.java.net/~zmajo/8138651/webrev.00/ >>> >>> >>>>> Testing: - JPRT (testset hotspot); - executed the the newly added >>>>> >>> test compiler/intrinsics/IntrinsicDisabledTest.java >>>>> with/without >>> the fix on all platforms, the test behaves as >>>>> expected. >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> > >>>>> >>>>> >>>> >>> >> > From vladimir.kozlov at oracle.com Wed Oct 28 15:19:30 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 28 Oct 2015 23:19:30 +0800 Subject: RFR (S): 8140343: SEGV in DirectivesStack::getMatchingDirective In-Reply-To: <56309239.3080601@oracle.com> References: <5629F7FC.7090008@oracle.com> <4CEF759F-3981-438A-B62C-9A7C30B32259@oracle.com> <562B461B.3000402@oracle.com> <56309239.3080601@oracle.com> Message-ID: <5630E782.3070707@oracle.com> I share Chris's concern - is _c1_store is always good choice and always defined. We still can have Server VM without C1 (PPC64). Or Zero. It should be taking into account. If _c1_store is always present in all VM variants - it should be explained in comment. Thanks, Vladimir On 10/28/15 5:15 PM, Nils Eliasson wrote: > Still open for review. > > Regards, > Nils > > On 2015-10-24 10:49, Nils Eliasson wrote: >> >> On 2015-10-23 22:39, Christian Thalinger wrote: >>>> On Oct 22, 2015, at 11:03 PM, Nils Eliasson >>>> wrote: >>>> >>>> Hi all, >>>> >>>> This fixes a bug when using a compiler that doesn't have compiler >>>> directives. This is a temporary fix using the default directive for c1. >>> What are the default directives for C1 and C2? This fix is for JVMCI >>> compilers and JVMCI compilers can only replace C2 in a tiered >>> configuration. Depending on what they are, wouldn?t it make more >>> sense to use C2?s default directives? >> >> The default directive is a directive that is always installed, always >> enabled and contains all the default values from vmflags and compile >> commands. This is the directive all compilations are using if no >> additional directives are installed. >>> >>>> In the future permanent fix all compilers will have directives by >>>> default. >>> How would that look like? >> >> Long story. It is an internal implementation detail to the structure >> of compiler directives. Right now there is a bit of an overhead adding >> a new compiler, even if only a single flag is used. The idea is to >> have all directives contain all flags for all compilers - it might >> sound expensive but will actually be more efficient. The most common >> use case is only having the default directive, and in this case the >> common flags wouldn't have to be duplicated for each compiler. The >> profit in the JVMCI case is that all the common flags are valid and >> usable without any workaround. The improvement is straightforward and >> wont affect any use site but is big enough not to be the fix of this bug. >> >> //Nils >> >> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8140343 >>>> webrev: http://cr.openjdk.java.net/~neliasso/8140343/webrev.01/ >>>> >>>> Please review, >>>> Nils >> > From nils.eliasson at oracle.com Wed Oct 28 16:12:46 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 28 Oct 2015 17:12:46 +0100 Subject: RFR (S): 8140343: SEGV in DirectivesStack::getMatchingDirective In-Reply-To: <5630E782.3070707@oracle.com> References: <5629F7FC.7090008@oracle.com> <4CEF759F-3981-438A-B62C-9A7C30B32259@oracle.com> <562B461B.3000402@oracle.com> <56309239.3080601@oracle.com> <5630E782.3070707@oracle.com> Message-ID: <5630F3FE.7060007@oracle.com> Hi Vladimir, The C1 store will always be an ok choice. Even if C1 is unavailable the c1 store will be populated with the common flags (Enable, Exclude, Print, Break, Log etc.). I will update the comment to reflect that. Thanks, Nils On 2015-10-28 16:19, Vladimir Kozlov wrote: > I share Chris's concern - is _c1_store is always good choice and > always defined. We still can have Server VM without C1 (PPC64). Or > Zero. It should be taking into account. > > If _c1_store is always present in all VM variants - it should be > explained in comment. > > Thanks, > Vladimir > > On 10/28/15 5:15 PM, Nils Eliasson wrote: >> Still open for review. >> >> Regards, >> Nils >> >> On 2015-10-24 10:49, Nils Eliasson wrote: >>> >>> On 2015-10-23 22:39, Christian Thalinger wrote: >>>>> On Oct 22, 2015, at 11:03 PM, Nils Eliasson >>>>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> This fixes a bug when using a compiler that doesn't have compiler >>>>> directives. This is a temporary fix using the default directive >>>>> for c1. >>>> What are the default directives for C1 and C2? This fix is for JVMCI >>>> compilers and JVMCI compilers can only replace C2 in a tiered >>>> configuration. Depending on what they are, wouldn?t it make more >>>> sense to use C2?s default directives? >>> >>> The default directive is a directive that is always installed, always >>> enabled and contains all the default values from vmflags and compile >>> commands. This is the directive all compilations are using if no >>> additional directives are installed. >>>> >>>>> In the future permanent fix all compilers will have directives by >>>>> default. >>>> How would that look like? >>> >>> Long story. It is an internal implementation detail to the structure >>> of compiler directives. Right now there is a bit of an overhead adding >>> a new compiler, even if only a single flag is used. The idea is to >>> have all directives contain all flags for all compilers - it might >>> sound expensive but will actually be more efficient. The most common >>> use case is only having the default directive, and in this case the >>> common flags wouldn't have to be duplicated for each compiler. The >>> profit in the JVMCI case is that all the common flags are valid and >>> usable without any workaround. The improvement is straightforward and >>> wont affect any use site but is big enough not to be the fix of this >>> bug. >>> >>> //Nils >>> >>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8140343 >>>>> webrev: http://cr.openjdk.java.net/~neliasso/8140343/webrev.01/ >>>>> >>>>> Please review, >>>>> Nils >>> >> From pavel.punegov at oracle.com Wed Oct 28 16:27:20 2015 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Wed, 28 Oct 2015 19:27:20 +0300 Subject: RFR (XXS): 8140669 and 8140667 Quarantine CompilerControl tests Message-ID: <5630F768.3090008@oracle.com> Hi, please review the change to quarantine two tests to reduce failures in the nightly. webrev: http://cr.openjdk.java.net/~ppunegov/8140405/webrev.00/ bug 1: https://bugs.openjdk.java.net/browse/JDK-8140667 bug 2: https://bugs.openjdk.java.net/browse/JDK-8140669 -- Thanks, Pavel Punegov From nils.eliasson at oracle.com Wed Oct 28 16:28:22 2015 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 28 Oct 2015 17:28:22 +0100 Subject: RFR (S): 8140343: SEGV in DirectivesStack::getMatchingDirective In-Reply-To: <5630F3FE.7060007@oracle.com> References: <5629F7FC.7090008@oracle.com> <4CEF759F-3981-438A-B62C-9A7C30B32259@oracle.com> <562B461B.3000402@oracle.com> <56309239.3080601@oracle.com> <5630E782.3070707@oracle.com> <5630F3FE.7060007@oracle.com> Message-ID: <5630F7A6.9010009@oracle.com> And the webrev: http://cr.openjdk.java.net/~neliasso/8140343/webrev.04/ Regards, Nils On 2015-10-28 17:12, Nils Eliasson wrote: > Hi Vladimir, > > The C1 store will always be an ok choice. Even if C1 is unavailable > the c1 store will be populated with the common flags (Enable, Exclude, > Print, Break, Log etc.). > > I will update the comment to reflect that. > > Thanks, > Nils > > > On 2015-10-28 16:19, Vladimir Kozlov wrote: >> I share Chris's concern - is _c1_store is always good choice and >> always defined. We still can have Server VM without C1 (PPC64). Or >> Zero. It should be taking into account. >> >> If _c1_store is always present in all VM variants - it should be >> explained in comment. >> >> Thanks, >> Vladimir >> >> On 10/28/15 5:15 PM, Nils Eliasson wrote: >>> Still open for review. >>> >>> Regards, >>> Nils >>> >>> On 2015-10-24 10:49, Nils Eliasson wrote: >>>> >>>> On 2015-10-23 22:39, Christian Thalinger wrote: >>>>>> On Oct 22, 2015, at 11:03 PM, Nils Eliasson >>>>>> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> This fixes a bug when using a compiler that doesn't have compiler >>>>>> directives. This is a temporary fix using the default directive >>>>>> for c1. >>>>> What are the default directives for C1 and C2? This fix is for JVMCI >>>>> compilers and JVMCI compilers can only replace C2 in a tiered >>>>> configuration. Depending on what they are, wouldn?t it make more >>>>> sense to use C2?s default directives? >>>> >>>> The default directive is a directive that is always installed, always >>>> enabled and contains all the default values from vmflags and compile >>>> commands. This is the directive all compilations are using if no >>>> additional directives are installed. >>>>> >>>>>> In the future permanent fix all compilers will have directives by >>>>>> default. >>>>> How would that look like? >>>> >>>> Long story. It is an internal implementation detail to the structure >>>> of compiler directives. Right now there is a bit of an overhead adding >>>> a new compiler, even if only a single flag is used. The idea is to >>>> have all directives contain all flags for all compilers - it might >>>> sound expensive but will actually be more efficient. The most common >>>> use case is only having the default directive, and in this case the >>>> common flags wouldn't have to be duplicated for each compiler. The >>>> profit in the JVMCI case is that all the common flags are valid and >>>> usable without any workaround. The improvement is straightforward and >>>> wont affect any use site but is big enough not to be the fix of >>>> this bug. >>>> >>>> //Nils >>>> >>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8140343 >>>>>> webrev: http://cr.openjdk.java.net/~neliasso/8140343/webrev.01/ >>>>>> >>>>>> Please review, >>>>>> Nils >>>> >>> > From tobias.hartmann at oracle.com Wed Oct 28 16:51:56 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 28 Oct 2015 17:51:56 +0100 Subject: [9] RFR(S): 8140574: C2 must re-execute checks after deoptimizing from merged uncommon traps In-Reply-To: <08638FB2-B0C8-4140-8913-77F80A9449C5@oracle.com> References: <562F5D3E.6070907@oracle.com> <562F927D.2030802@oracle.com> <896013D7-03B4-40B3-900B-9B258ED60AE8@oracle.com> <562F9883.1050904@oracle.com> <5630C88D.5000205@oracle.com> <08638FB2-B0C8-4140-8913-77F80A9449C5@oracle.com> Message-ID: <5630FD2C.5060804@oracle.com> Hi Roland, thanks for the suggestions - I was able to create a regression test that triggers the problem you described: http://cr.openjdk.java.net/~thartmann/8140574/webrev.01/ I'll look into how we can fix this. Best, Tobias On 28.10.2015 14:33, Roland Westrelin wrote: >>> if (i < 0) { >>> if (some_condition) { >>> // never taken so unc unstable_if >>> } >>> } >> >> I agree that this would be a problem but why would be add an uncommon trap here? Either the i<0 branch is never executed, then we would add the uncommon trap like this >> >> if (i < 0) { >> // unc unstable_if >> } >> >> or it was executed and then also "some_condition" was true and we would not add an uncommon trap at all. > > Profiling is what tells us that we can cut one branch. It?s not 100% accurate. > > We could have: > > void m1(boolean flag) { > if (i < 0) { > if (flag) { > } > } > } > > that is called a lot with flag false and i sometimes negative, sometimes positive so m1 is compiled, no more profiling is recorded and the profiling tells us the branch is never taken. Then we run: > > void m2(int i) { > .. > m1(i, flag); > } > > with i always positive. During parsing the compiler is unable to prove flag always true, so we add the unc and after some optimization, flag is proven always true so the test is removed. > > For instance, this: > > for (int i = 0; i < 10; i++); > flag = (i == 10); > > I think it would be worthwhile to check we can write a test case like this. > >>> So I think we have to restrict when we apply that transformation even more, maybe matching the expected bytecode pattern more closely? >> >> I'm not sure how to do this. We would somehow have to make sure that the dominating uncommon trap "belongs" to the dominating if and not to some other if that was removed, right? > > I suppose if we can prove that the bci of the unc for the dominating if dominates the bci of the unc of the dominated if then we?re good. Maybe by iterating over the ciTypeFlow blocks of the method. > > Roland. > From igor.veresov at oracle.com Wed Oct 28 19:10:26 2015 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 28 Oct 2015 12:10:26 -0700 Subject: RFR(XS) 8140604: Internal Error runtime/stubRoutines.hpp:392 assert(_intrinsic_log != 0L) failed: must be defined Message-ID: This is a little assert problem that was exposed by 8139575. The following change fixes the assert plus a little bit of cleanup. Webrev: http://cr.openjdk.java.net/~iveresov/8140604/webrev.00/ Thanks, igor From john.r.rose at oracle.com Wed Oct 28 19:40:27 2015 From: john.r.rose at oracle.com (John Rose) Date: Wed, 28 Oct 2015 12:40:27 -0700 Subject: Using Array.newInstance still generates checkcast instructions In-Reply-To: References: <7872D2FE-ECF8-4EDB-9674-49B949679F31@oracle.com> <61A0A2EA-2623-48BD-9533-2D28FBC6E1E9@oracle.com> Message-ID: <3385BCAE-1197-47C8-B813-9221CA1EB49C@oracle.com> On Oct 27, 2015, at 11:14 AM, Vitaly Davidovich wrote: > > Here's the basic example I used earlier, a bit more spelled out + assembly: (This is going back several years.) Look at the code in Arrays.copyOfRange. Note how the call to Array.newInstance is passed newType.getComponentType. That part is important. The C2 intrinsic only optimizes the case where the ARRAY Class is available, not the ELEMENT Class. Try re-doing your experiment by reifying the T[] type, not the T (element) type. Make sure your use of Array.newInstance takes its metadata from a call to getComponentType. Perhaps this could be upgraded; maybe it is time to. The old code shape is designed for the case where constant folding is infrequent, and the dynamic (non-constant) version works best when you start with the T[] type. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalyd at gmail.com Wed Oct 28 19:54:15 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 28 Oct 2015 15:54:15 -0400 Subject: Using Array.newInstance still generates checkcast instructions In-Reply-To: <3385BCAE-1197-47C8-B813-9221CA1EB49C@oracle.com> References: <7872D2FE-ECF8-4EDB-9674-49B949679F31@oracle.com> <61A0A2EA-2623-48BD-9533-2D28FBC6E1E9@oracle.com> <3385BCAE-1197-47C8-B813-9221CA1EB49C@oracle.com> Message-ID: > > Try re-doing your experiment by > reifying the T[] type, not the T (element) type. Make sure your use of > Array.newInstance takes its metadata from a call to getComponentType. I'm not sure I understand you correctly John. Why is the issue related to Array.newInstance? It does produce the expected reified array, String[] in this case, and to me it looks like the T[] is reified. My question is more about uses of that field not looking at the runtime type of the array to see if checkcast can be trivially removed. Did I misunderstand? If I did misunderstand, what should my example ArrayList look like? On Wed, Oct 28, 2015 at 3:40 PM, John Rose wrote: > On Oct 27, 2015, at 11:14 AM, Vitaly Davidovich wrote: > > > Here's the basic example I used earlier, a bit more spelled out + assembly: > > > (This is going back several years.) Look at the code in > Arrays.copyOfRange. > Note how the call to Array.newInstance is passed newType.getComponentType. > That part is important. The C2 intrinsic only optimizes the case where > the ARRAY > Class is available, not the ELEMENT Class. Try re-doing your experiment by > reifying the T[] type, not the T (element) type. Make sure your use of > Array.newInstance takes its metadata from a call to getComponentType. > > Perhaps this could be upgraded; maybe it is time to. The old code shape > is designed for the case where constant folding is infrequent, and the > dynamic (non-constant) version works best when you start with the T[] type. > > ? John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Wed Oct 28 20:31:43 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 28 Oct 2015 23:31:43 +0300 Subject: RFR (XXS): 8140669 and 8140667 Quarantine CompilerControl tests In-Reply-To: <5630F768.3090008@oracle.com> References: <5630F768.3090008@oracle.com> Message-ID: <697FA269-9D80-4C20-8DFE-C76667585153@oracle.com> Hi Pavel, looks good to me, Thanks, ? Igor > On Oct 28, 2015, at 7:27 PM, Pavel Punegov wrote: > > Hi, > > please review the change to quarantine two tests to reduce failures in the nightly. > > webrev: http://cr.openjdk.java.net/~ppunegov/8140405/webrev.00/ > bug 1: https://bugs.openjdk.java.net/browse/JDK-8140667 > bug 2: https://bugs.openjdk.java.net/browse/JDK-8140669 > > -- > Thanks, > Pavel Punegov > From john.r.rose at oracle.com Wed Oct 28 20:51:25 2015 From: john.r.rose at oracle.com (John Rose) Date: Wed, 28 Oct 2015 13:51:25 -0700 Subject: Using Array.newInstance still generates checkcast instructions In-Reply-To: References: <7872D2FE-ECF8-4EDB-9674-49B949679F31@oracle.com> <61A0A2EA-2623-48BD-9533-2D28FBC6E1E9@oracle.com> <3385BCAE-1197-47C8-B813-9221CA1EB49C@oracle.com> Message-ID: <8EA37203-ED2C-4BBD-804A-5E2AFAA37333@oracle.com> On Oct 28, 2015, at 12:54 PM, Vitaly Davidovich wrote: > > what should my example ArrayList look like Try changing your ArrayList class constructor: - ArrayList(final Class klass, final int size) { - _items = (T[]) Array.newInstance(klass, size); + ArrayList(final Class arrayKlass, final int size) { + _items = (T[]) Array.newInstance(arrayKlass.getComponentType(), size); That will make the source code shape more like Arrays.copyOfRange, and what the optimizer expects. YMMV ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalyd at gmail.com Wed Oct 28 21:04:38 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 28 Oct 2015 17:04:38 -0400 Subject: Using Array.newInstance still generates checkcast instructions In-Reply-To: <8EA37203-ED2C-4BBD-804A-5E2AFAA37333@oracle.com> References: <7872D2FE-ECF8-4EDB-9674-49B949679F31@oracle.com> <61A0A2EA-2623-48BD-9533-2D28FBC6E1E9@oracle.com> <3385BCAE-1197-47C8-B813-9221CA1EB49C@oracle.com> <8EA37203-ED2C-4BBD-804A-5E2AFAA37333@oracle.com> Message-ID: No difference in codegen. I also wouldn't expect any here since the Array.newInstance call and the read of the array in get() are "disconnected" as far as JIT is concerned - once the constructor returns, any type info inferred in the constructor of ArrayList is gone. This is different from Arrays.copyOfRange() where the array instantiation and read from it are performed in one CFG. On Wed, Oct 28, 2015 at 4:51 PM, John Rose wrote: > On Oct 28, 2015, at 12:54 PM, Vitaly Davidovich wrote: > > > what should my example ArrayList look like > > > Try changing your ArrayList class constructor: > > - ArrayList(final Class klass, final int size) { > - _items = (T[]) Array.newInstance(klass, size); > + ArrayList(final Class arrayKlass, final int size) { > + _items = (T[]) Array.newInstance(arrayKlass.getComponentType(), > size); > > That will make the source code shape more like Arrays.copyOfRange, and > what the optimizer expects. > > YMMV > > ? John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Wed Oct 28 21:19:20 2015 From: john.r.rose at oracle.com (John Rose) Date: Wed, 28 Oct 2015 14:19:20 -0700 Subject: RFR (S) 8140483: Atomic*FieldUpdaters final fields should be trusted In-Reply-To: <562F5DBA.7000807@oracle.com> References: <562E3546.5060007@oracle.com> <562F5DBA.7000807@oracle.com> Message-ID: <2532F7C7-C914-4307-8929-96028D971EE1@oracle.com> On Oct 27, 2015, at 4:19 AM, Aleksey Shipilev wrote: > > Hi, > > I'd like to start a formal review for the change: > https://bugs.openjdk.java.net/browse/JDK-8140483 > > The feedback was overwhelmingly positive so far. Some suggested we use > compiler control and/or maintain the list of trusted classes. I still > think it is an overkill for the fix at hand, and we should instead wait > for the wholesale final field optimizations. This is a good point-fix for a specific problem with a specific set of performance-sensitive classes. I prefer class-based exceptions (b), as more accurate and less likely to be subverted by "surprising" package additions. (The check for Serializable, does, however, cut out the main "surprise" effect.) ? John P.S. Fixing finals is one of those slippery-slope problems, like fixing the class file format (or, for that matter, fixing our broken kitchen stove, which ended up with a much more expensive kitchen remodel, because we couldn't fix just the stove). From christian.thalinger at oracle.com Wed Oct 28 21:32:33 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 28 Oct 2015 14:32:33 -0700 Subject: RFR (S): 8140343: SEGV in DirectivesStack::getMatchingDirective In-Reply-To: <562B461B.3000402@oracle.com> References: <5629F7FC.7090008@oracle.com> <4CEF759F-3981-438A-B62C-9A7C30B32259@oracle.com> <562B461B.3000402@oracle.com> Message-ID: > On Oct 24, 2015, at 1:49 AM, Nils Eliasson wrote: > > > On 2015-10-23 22:39, Christian Thalinger wrote: >>> On Oct 22, 2015, at 11:03 PM, Nils Eliasson wrote: >>> >>> Hi all, >>> >>> This fixes a bug when using a compiler that doesn't have compiler directives. This is a temporary fix using the default directive for c1. >> What are the default directives for C1 and C2? This fix is for JVMCI compilers and JVMCI compilers can only replace C2 in a tiered configuration. Depending on what they are, wouldn?t it make more sense to use C2?s default directives? > > The default directive is a directive that is always installed, always enabled and contains all the default values from vmflags and compile commands. This is the directive all compilations are using if no additional directives are installed. Alright, but then I am confused that you said ?default directive for c1?. Anyway, it?s good. >> >>> In the future permanent fix all compilers will have directives by default. >> How would that look like? > > Long story. It is an internal implementation detail to the structure of compiler directives. Right now there is a bit of an overhead adding a new compiler, even if only a single flag is used. The idea is to have all directives contain all flags for all compilers - it might sound expensive but will actually be more efficient. The most common use case is only having the default directive, and in this case the common flags wouldn't have to be duplicated for each compiler. The profit in the JVMCI case is that all the common flags are valid and usable without any workaround. The improvement is straightforward and wont affect any use site but is big enough not to be the fix of this bug. Ok. > > //Nils > > >>> bug: https://bugs.openjdk.java.net/browse/JDK-8140343 >>> webrev: http://cr.openjdk.java.net/~neliasso/8140343/webrev.01/ >>> >>> Please review, >>> Nils > From pavel.punegov at oracle.com Wed Oct 28 21:37:21 2015 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Thu, 29 Oct 2015 00:37:21 +0300 Subject: RFR (XXS): 8140669 and 8140667 Quarantine CompilerControl tests In-Reply-To: <697FA269-9D80-4C20-8DFE-C76667585153@oracle.com> References: <5630F768.3090008@oracle.com> <697FA269-9D80-4C20-8DFE-C76667585153@oracle.com> Message-ID: <56314011.6040406@oracle.com> Thank you, Igor. 28.10.2015 23:31, Igor Ignatyev wrote: > Hi Pavel, > > looks good to me, > > Thanks, > ? Igor > >> On Oct 28, 2015, at 7:27 PM, Pavel Punegov wrote: >> >> Hi, >> >> please review the change to quarantine two tests to reduce failures in the nightly. >> >> webrev: http://cr.openjdk.java.net/~ppunegov/8140405/webrev.00/ >> bug 1: https://bugs.openjdk.java.net/browse/JDK-8140667 >> bug 2: https://bugs.openjdk.java.net/browse/JDK-8140669 >> >> -- >> Thanks, >> Pavel Punegov >> -- Thanks, Pavel Punegov From vladimir.kozlov at oracle.com Thu Oct 29 06:03:18 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 29 Oct 2015 14:03:18 +0800 Subject: RFR (S): 8140343: SEGV in DirectivesStack::getMatchingDirective In-Reply-To: <5630F7A6.9010009@oracle.com> References: <5629F7FC.7090008@oracle.com> <4CEF759F-3981-438A-B62C-9A7C30B32259@oracle.com> <562B461B.3000402@oracle.com> <56309239.3080601@oracle.com> <5630E782.3070707@oracle.com> <5630F3FE.7060007@oracle.com> <5630F7A6.9010009@oracle.com> Message-ID: <5631B6A6.8040001@oracle.com> Looks good, for records. I see you pushed it already. Thanks, Vladimir On 10/29/15 12:28 AM, Nils Eliasson wrote: > > And the webrev: http://cr.openjdk.java.net/~neliasso/8140343/webrev.04/ > > Regards, > Nils > > On 2015-10-28 17:12, Nils Eliasson wrote: >> Hi Vladimir, >> >> The C1 store will always be an ok choice. Even if C1 is unavailable >> the c1 store will be populated with the common flags (Enable, Exclude, >> Print, Break, Log etc.). >> >> I will update the comment to reflect that. >> >> Thanks, >> Nils >> >> >> On 2015-10-28 16:19, Vladimir Kozlov wrote: >>> I share Chris's concern - is _c1_store is always good choice and >>> always defined. We still can have Server VM without C1 (PPC64). Or >>> Zero. It should be taking into account. >>> >>> If _c1_store is always present in all VM variants - it should be >>> explained in comment. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/28/15 5:15 PM, Nils Eliasson wrote: >>>> Still open for review. >>>> >>>> Regards, >>>> Nils >>>> >>>> On 2015-10-24 10:49, Nils Eliasson wrote: >>>>> >>>>> On 2015-10-23 22:39, Christian Thalinger wrote: >>>>>>> On Oct 22, 2015, at 11:03 PM, Nils Eliasson >>>>>>> wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> This fixes a bug when using a compiler that doesn't have compiler >>>>>>> directives. This is a temporary fix using the default directive >>>>>>> for c1. >>>>>> What are the default directives for C1 and C2? This fix is for JVMCI >>>>>> compilers and JVMCI compilers can only replace C2 in a tiered >>>>>> configuration. Depending on what they are, wouldn?t it make more >>>>>> sense to use C2?s default directives? >>>>> >>>>> The default directive is a directive that is always installed, always >>>>> enabled and contains all the default values from vmflags and compile >>>>> commands. This is the directive all compilations are using if no >>>>> additional directives are installed. >>>>>> >>>>>>> In the future permanent fix all compilers will have directives by >>>>>>> default. >>>>>> How would that look like? >>>>> >>>>> Long story. It is an internal implementation detail to the structure >>>>> of compiler directives. Right now there is a bit of an overhead adding >>>>> a new compiler, even if only a single flag is used. The idea is to >>>>> have all directives contain all flags for all compilers - it might >>>>> sound expensive but will actually be more efficient. The most common >>>>> use case is only having the default directive, and in this case the >>>>> common flags wouldn't have to be duplicated for each compiler. The >>>>> profit in the JVMCI case is that all the common flags are valid and >>>>> usable without any workaround. The improvement is straightforward and >>>>> wont affect any use site but is big enough not to be the fix of >>>>> this bug. >>>>> >>>>> //Nils >>>>> >>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8140343 >>>>>>> webrev: http://cr.openjdk.java.net/~neliasso/8140343/webrev.01/ >>>>>>> >>>>>>> Please review, >>>>>>> Nils >>>>> >>>> >> > From vladimir.kozlov at oracle.com Thu Oct 29 06:16:39 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 29 Oct 2015 14:16:39 +0800 Subject: RFR (XXS): 8140669 and 8140667 Quarantine CompilerControl tests In-Reply-To: <5630F768.3090008@oracle.com> References: <5630F768.3090008@oracle.com> Message-ID: <5631B9C7.5030703@oracle.com> Good. Thanks, Vladimir On 10/29/15 12:27 AM, Pavel Punegov wrote: > Hi, > > please review the change to quarantine two tests to reduce failures in > the nightly. > > webrev: http://cr.openjdk.java.net/~ppunegov/8140405/webrev.00/ > bug 1: https://bugs.openjdk.java.net/browse/JDK-8140667 > bug 2: https://bugs.openjdk.java.net/browse/JDK-8140669 > From cnewland at chrisnewland.com Thu Oct 29 09:36:40 2015 From: cnewland at chrisnewland.com (Chris Newland) Date: Thu, 29 Oct 2015 09:36:40 -0000 Subject: LogCompilation suggestion: output locale Message-ID: <6e38534d1500151ccb05e83b5ef7f66d.squirrel@excalibur.xssl.net> Hi, It would be useful for JITWatch to know the system locale when the LogCompilation output was written in order to parse some of the numeric values (stamp attribute etc.). Would you consider this patch (against tip of jigsaw/jake) to output a tag inside the log header tag? Kind regards, Chris diff -r b96d0485a1a9 src/share/vm/utilities/ostream.cpp --- a/src/share/vm/utilities/ostream.cpp Wed Oct 21 13:21:33 2015 -0400 +++ b/src/share/vm/utilities/ostream.cpp Thu Oct 29 09:23:17 2015 +0000 @@ -34,6 +34,8 @@ #include "utilities/ostream.hpp" #include "utilities/top.hpp" #include "utilities/xmlstream.hpp" +#include +#include extern "C" void jio_print(const char* s); // Declarationtion of jvm method @@ -957,6 +959,9 @@ xs->tail("release"); xs->head("info"); xs->text("%s", VM_Version::internal_vm_info_string()); xs->cr(); xs->tail("info"); + std::locale l(""); + xs->head("locale"); xs->text("%s", l.name().c_str()); xs->cr(); + xs->tail("locale"); xs->tail("vm_version"); // Record information about the command-line invocation. xs->head("vm_arguments"); // Cf. Arguments::print_on() From roland.westrelin at oracle.com Thu Oct 29 10:27:20 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 29 Oct 2015 11:27:20 +0100 Subject: RFR(XS) 8140604: Internal Error runtime/stubRoutines.hpp:392 assert(_intrinsic_log != 0L) failed: must be defined In-Reply-To: References: Message-ID: > Webrev: http://cr.openjdk.java.net/~iveresov/8140604/webrev.00/ That looks good to me. Roland. From aleksey.shipilev at oracle.com Thu Oct 29 11:09:50 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 29 Oct 2015 14:09:50 +0300 Subject: RFR (S) 8140483: Atomic*FieldUpdaters final fields should be trusted In-Reply-To: <2532F7C7-C914-4307-8929-96028D971EE1@oracle.com> References: <562E3546.5060007@oracle.com> <562F5DBA.7000807@oracle.com> <2532F7C7-C914-4307-8929-96028D971EE1@oracle.com> Message-ID: <5631FE7E.4040809@oracle.com> On 10/29/2015 12:19 AM, John Rose wrote: > On Oct 27, 2015, at 4:19 AM, Aleksey Shipilev wrote: >> I'd like to start a formal review for the change: >> https://bugs.openjdk.java.net/browse/JDK-8140483 >> >> The feedback was overwhelmingly positive so far. Some suggested we use >> compiler control and/or maintain the list of trusted classes. I still >> think it is an overkill for the fix at hand, and we should instead wait >> for the wholesale final field optimizations. > > This is a good point-fix for a specific problem with a specific set of performance-sensitive classes. > > I prefer class-based exceptions (b), as more accurate and less likely > to be subverted by "surprising" package additions. (The check for > Serializable, does, however, cut out the main "surprise" effect.) Excellent, thanks John! Vladimir I. had also reviewed internally. This is the changeset we will be pushing then: http://cr.openjdk.java.net/~shade/8140483/8140483.changeset Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From tobias.hartmann at oracle.com Thu Oct 29 14:14:49 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 29 Oct 2015 15:14:49 +0100 Subject: [9] RFR(S): 8140574: C2 must re-execute checks after deoptimizing from merged uncommon traps In-Reply-To: <5630FD2C.5060804@oracle.com> References: <562F5D3E.6070907@oracle.com> <562F927D.2030802@oracle.com> <896013D7-03B4-40B3-900B-9B258ED60AE8@oracle.com> <562F9883.1050904@oracle.com> <5630C88D.5000205@oracle.com> <08638FB2-B0C8-4140-8913-77F80A9449C5@oracle.com> <5630FD2C.5060804@oracle.com> Message-ID: <563229D9.2050004@oracle.com> Hi Roland, > I suppose if we can prove that the bci of the unc for the dominating if dominates the bci of the unc of the dominated if then we?re good. Maybe by iterating over the ciTypeFlow blocks of the method. I implemented such a check using ciTypeFlow: http://cr.openjdk.java.net/~thartmann/8140574/webrev.02/ It works fine for my test and I also verified that the range checks in TestExplicitRangeChecks are folded. The only problem is that the checks in 'test19' [1] are not folded anymore because they were inlined from 'test19_helper1' and 'test19_helper2'. The current approach only looks at the current method and does not check inlined methods. I think this could be done as well but would be much more complicated. Maybe we can do this in a follow up RFE. What do you think? Thanks, Tobias [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/e18469511c58/test/compiler/rangechecks/TestExplicitRangeChecks.java#l362 On 28.10.2015 17:51, Tobias Hartmann wrote: > Hi Roland, > > thanks for the suggestions - I was able to create a regression test that triggers the problem you described: > http://cr.openjdk.java.net/~thartmann/8140574/webrev.01/ > > I'll look into how we can fix this. > > Best, > Tobias > > On 28.10.2015 14:33, Roland Westrelin wrote: >>>> if (i < 0) { >>>> if (some_condition) { >>>> // never taken so unc unstable_if >>>> } >>>> } >>> >>> I agree that this would be a problem but why would be add an uncommon trap here? Either the i<0 branch is never executed, then we would add the uncommon trap like this >>> >>> if (i < 0) { >>> // unc unstable_if >>> } >>> >>> or it was executed and then also "some_condition" was true and we would not add an uncommon trap at all. >> >> Profiling is what tells us that we can cut one branch. It?s not 100% accurate. >> >> We could have: >> >> void m1(boolean flag) { >> if (i < 0) { >> if (flag) { >> } >> } >> } >> >> that is called a lot with flag false and i sometimes negative, sometimes positive so m1 is compiled, no more profiling is recorded and the profiling tells us the branch is never taken. Then we run: >> >> void m2(int i) { >> .. >> m1(i, flag); >> } >> >> with i always positive. During parsing the compiler is unable to prove flag always true, so we add the unc and after some optimization, flag is proven always true so the test is removed. >> >> For instance, this: >> >> for (int i = 0; i < 10; i++); >> flag = (i == 10); >> >> I think it would be worthwhile to check we can write a test case like this. >> >>>> So I think we have to restrict when we apply that transformation even more, maybe matching the expected bytecode pattern more closely? >>> >>> I'm not sure how to do this. We would somehow have to make sure that the dominating uncommon trap "belongs" to the dominating if and not to some other if that was removed, right? >> >> I suppose if we can prove that the bci of the unc for the dominating if dominates the bci of the unc of the dominated if then we?re good. Maybe by iterating over the ciTypeFlow blocks of the method. >> >> Roland. >> From konstantin.shefov at oracle.com Thu Oct 29 15:43:06 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Thu, 29 Oct 2015 18:43:06 +0300 Subject: [9] RFR 8131778: java disables UseAES flag when using VIS=2 on sparc In-Reply-To: <562FAFB6.7080305@oracle.com> References: <562FAFB6.7080305@oracle.com> Message-ID: <56323E8A.3060208@oracle.com> This is the fix of the issue when both flags "useAES" and "useAESIntrinsics" are disabled, although only "useAESIntrinsics" should be disabled if some instruction sets are not supported by a CPU. This fix has been tested by the slightly modified tests from https://bugs.openjdk.java.net/browse/JDK-8079667 (which will be resolved in the nearest future). -Konstantin On 10/27/2015 08:09 PM, Konstantin Shefov wrote: > Hello > > Please review a bug fix. > > JBS entry: https://bugs.openjdk.java.net/browse/JDK-8131778 > Webrev: http://cr.openjdk.java.net/~kshefov/8131778/webrev.00 > > Thanks > -Konstantin From konstantin.shefov at oracle.com Thu Oct 29 16:13:02 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Thu, 29 Oct 2015 19:13:02 +0300 Subject: [9] RFR 8139385: [TESTBUG]: JVMCI test crashes in constantPoolHandle::constantPoolHandle Message-ID: <5632458E.40106@oracle.com> Hello Please review a test bug fix in whitebox.cpp. The problem with the test (crash) happened because of C++ type "long" on Windows 64-bit platforms has length of 32-bit, and when we casted a 64-bit pointer to "long" we had wrong pointer as a result. The solution is to cast the pointer to "jlong", which is "signed long long" and is always 64-bit. Tested by test "compiler/jvmci/compilerToVM/GetConstantPoolTest.java " Bug: https://bugs.openjdk.java.net/browse/JDK-8139385 Webrev: http://cr.openjdk.java.net/~kshefov/8139385/webrev/ Thanks -Konstantin -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavel.punegov at oracle.com Thu Oct 29 16:22:52 2015 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Thu, 29 Oct 2015 19:22:52 +0300 Subject: RFR (XXS): 8140776: CompilerControl: Remove UTF-16 from the tests Message-ID: <563247DC.4040801@oracle.com> Hi, Please review the fix that excludes Unicode method generation in Compiler Control. There are a lots of failures in the Nightly caused by these strings. I was unable to reproduce them, so the real reason is unknown. The fix is to remove this generation until the reason isn't found. webrev: http://cr.openjdk.java.net/~ppunegov/8140776/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8140776 -- Thanks, Pavel Punegov From tobias.hartmann at oracle.com Thu Oct 29 16:30:24 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 29 Oct 2015 17:30:24 +0100 Subject: [9] RFR(S): 8140574: C2 must re-execute checks after deoptimizing from merged uncommon traps In-Reply-To: <5630FD2C.5060804@oracle.com> References: <562F5D3E.6070907@oracle.com> <562F927D.2030802@oracle.com> <896013D7-03B4-40B3-900B-9B258ED60AE8@oracle.com> <562F9883.1050904@oracle.com> <5630C88D.5000205@oracle.com> <08638FB2-B0C8-4140-8913-77F80A9449C5@oracle.com> <5630FD2C.5060804@oracle.com> Message-ID: <563249A0.7050701@oracle.com> Hi Roland, > I suppose if we can prove that the bci of the unc for the dominating if dominates the bci of the unc of the dominated if then we?re good. Maybe by iterating over the ciTypeFlow blocks of the method. I implemented such a check using ciTypeFlow: http://cr.openjdk.java.net/~thartmann/8140574/webrev.02/ It works fine for my test and I also verified that the range checks in TestExplicitRangeChecks are folded. The only problem is that the checks in 'test19' [1] are not folded anymore because they were inlined from 'test19_helper1' and 'test19_helper2'. The current approach only looks at the current method and does not check inlined methods. I think this could be done as well but would be much more complicated. Maybe we can do this in a follow up RFE. What do you think? Thanks, Tobias [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/e18469511c58/test/compiler/rangechecks/TestExplicitRangeChecks.java#l362 On 28.10.2015 17:51, Tobias Hartmann wrote: > Hi Roland, > > thanks for the suggestions - I was able to create a regression test that triggers the problem you described: > http://cr.openjdk.java.net/~thartmann/8140574/webrev.01/ > > I'll look into how we can fix this. > > Best, > Tobias > > On 28.10.2015 14:33, Roland Westrelin wrote: >>>> if (i < 0) { >>>> if (some_condition) { >>>> // never taken so unc unstable_if >>>> } >>>> } >>> >>> I agree that this would be a problem but why would be add an uncommon trap here? Either the i<0 branch is never executed, then we would add the uncommon trap like this >>> >>> if (i < 0) { >>> // unc unstable_if >>> } >>> >>> or it was executed and then also "some_condition" was true and we would not add an uncommon trap at all. >> >> Profiling is what tells us that we can cut one branch. It?s not 100% accurate. >> >> We could have: >> >> void m1(boolean flag) { >> if (i < 0) { >> if (flag) { >> } >> } >> } >> >> that is called a lot with flag false and i sometimes negative, sometimes positive so m1 is compiled, no more profiling is recorded and the profiling tells us the branch is never taken. Then we run: >> >> void m2(int i) { >> .. >> m1(i, flag); >> } >> >> with i always positive. During parsing the compiler is unable to prove flag always true, so we add the unc and after some optimization, flag is proven always true so the test is removed. >> >> For instance, this: >> >> for (int i = 0; i < 10; i++); >> flag = (i == 10); >> >> I think it would be worthwhile to check we can write a test case like this. >> >>>> So I think we have to restrict when we apply that transformation even more, maybe matching the expected bytecode pattern more closely? >>> >>> I'm not sure how to do this. We would somehow have to make sure that the dominating uncommon trap "belongs" to the dominating if and not to some other if that was removed, right? >> >> I suppose if we can prove that the bci of the unc for the dominating if dominates the bci of the unc of the dominated if then we?re good. Maybe by iterating over the ciTypeFlow blocks of the method. >> >> Roland. >> From igor.veresov at oracle.com Thu Oct 29 16:56:17 2015 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 29 Oct 2015 09:56:17 -0700 Subject: RFR(XS) 8140604: Internal Error runtime/stubRoutines.hpp:392 assert(_intrinsic_log != 0L) failed: must be defined In-Reply-To: References: Message-ID: <990AC3AD-4722-45E7-9BDA-6D530DB54EEF@oracle.com> Thanks! igor > On Oct 29, 2015, at 3:27 AM, Roland Westrelin wrote: > >> Webrev: http://cr.openjdk.java.net/~iveresov/8140604/webrev.00/ > > That looks good to me. > > Roland. From pavel.punegov at oracle.com Thu Oct 29 18:16:59 2015 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Thu, 29 Oct 2015 21:16:59 +0300 Subject: RFR (XXS): 8140776: CompilerControl: Remove UTF-16 from the tests In-Reply-To: <563247DC.4040801@oracle.com> References: <563247DC.4040801@oracle.com> Message-ID: <5632629B.5090600@oracle.com> After the offline discussion with Igor I, I decided to not to remove these lines, but just comment them with TODO comment Here is an updated version: http://cr.openjdk.java.net/~ppunegov/8140776/webrev.01/ On 29.10.2015 19:22, Pavel Punegov wrote: > Hi, > > Please review the fix that excludes Unicode method generation in > Compiler Control. > > There are a lots of failures in the Nightly caused by these strings. I > was unable to reproduce them, so the real reason is unknown. > The fix is to remove this generation until the reason isn't found. > > webrev: http://cr.openjdk.java.net/~ppunegov/8140776/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8140776 > -- Thanks, Pavel Punegov From igor.ignatyev at oracle.com Thu Oct 29 18:25:49 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 29 Oct 2015 21:25:49 +0300 Subject: RFR (XXS): 8140776: CompilerControl: Remove UTF-16 from the tests In-Reply-To: <5632629B.5090600@oracle.com> References: <563247DC.4040801@oracle.com> <5632629B.5090600@oracle.com> Message-ID: <45ECEF93-E5D6-4A8A-A936-E6E84E076252@oracle.com> Hi Pavel, thank for changing that, looks good to me. Thanks, ? Igor > On Oct 29, 2015, at 9:16 PM, Pavel Punegov wrote: > > After the offline discussion with Igor I, I decided to not to remove these lines, but just comment them with TODO comment > > Here is an updated version: > http://cr.openjdk.java.net/~ppunegov/8140776/webrev.01/ > > On 29.10.2015 19:22, Pavel Punegov wrote: >> Hi, >> >> Please review the fix that excludes Unicode method generation in Compiler Control. >> >> There are a lots of failures in the Nightly caused by these strings. I was unable to reproduce them, so the real reason is unknown. >> The fix is to remove this generation until the reason isn't found. >> >> webrev: http://cr.openjdk.java.net/~ppunegov/8140776/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8140776 >> > > -- > Thanks, > Pavel Punegov > From igor.ignatyev at oracle.com Thu Oct 29 18:28:58 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 29 Oct 2015 21:28:58 +0300 Subject: [9] RFR 8139385: [TESTBUG]: JVMCI test crashes in constantPoolHandle::constantPoolHandle In-Reply-To: <5632458E.40106@oracle.com> References: <5632458E.40106@oracle.com> Message-ID: Hi Konstantin, the fix looks good to me. Thanks, ? Igor > On Oct 29, 2015, at 7:13 PM, Konstantin Shefov wrote: > > Hello > > Please review a test bug fix in whitebox.cpp. > > The problem with the test (crash) happened because of C++ type "long" on Windows 64-bit platforms has length of 32-bit, and when we casted a 64-bit pointer to "long" we had wrong pointer as a result. > > The solution is to cast the pointer to "jlong", which is "signed long long" and is always 64-bit. > > Tested by test "compiler/jvmci/compilerToVM/GetConstantPoolTest.java " > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139385 > Webrev: http://cr.openjdk.java.net/~kshefov/8139385/webrev/ > > Thanks > -Konstantin From pavel.punegov at oracle.com Thu Oct 29 18:33:09 2015 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Thu, 29 Oct 2015 21:33:09 +0300 Subject: RFR (XXS): 8140776: CompilerControl: Remove UTF-16 from the tests In-Reply-To: <45ECEF93-E5D6-4A8A-A936-E6E84E076252@oracle.com> References: <563247DC.4040801@oracle.com> <5632629B.5090600@oracle.com> <45ECEF93-E5D6-4A8A-A936-E6E84E076252@oracle.com> Message-ID: <56326665.50703@oracle.com> Thanks, Igor On 29.10.2015 21:25, Igor Ignatyev wrote: > Hi Pavel, > > thank for changing that, looks good to me. > > Thanks, > ? Igor >> On Oct 29, 2015, at 9:16 PM, Pavel Punegov wrote: >> >> After the offline discussion with Igor I, I decided to not to remove these lines, but just comment them with TODO comment >> >> Here is an updated version: >> http://cr.openjdk.java.net/~ppunegov/8140776/webrev.01/ >> >> On 29.10.2015 19:22, Pavel Punegov wrote: >>> Hi, >>> >>> Please review the fix that excludes Unicode method generation in Compiler Control. >>> >>> There are a lots of failures in the Nightly caused by these strings. I was unable to reproduce them, so the real reason is unknown. >>> The fix is to remove this generation until the reason isn't found. >>> >>> webrev: http://cr.openjdk.java.net/~ppunegov/8140776/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8140776 >>> >> -- >> Thanks, >> Pavel Punegov >> -- Thanks, Pavel Punegov From michael.c.berg at intel.com Thu Oct 29 19:06:58 2015 From: michael.c.berg at intel.com (Berg, Michael C) Date: Thu, 29 Oct 2015 19:06:58 +0000 Subject: CR for RFR 8140779 Message-ID: Hi Folks, I would like to contribute AVX 512 changes for bug fixes and performance issues. I need two reviewers to examine this patch and comment as needed: Bug-id: https://bugs.openjdk.java.net/browse/JDK-8140779 webrev: http://cr.openjdk.java.net/~mcberg/8140779/webrev.01/ Debugging on Evex machines, a number of issues were uncovered which could not be addressed via emulation. These changes include a unified approach with call frames for Evex and pre Evex targets, performance changes for 32 bit Evex performance, general improvements to all x86 targets for reduction patterns, encoding changes for correctness, changes that reduce register pressure for generated code, CPUID additions for additional state control, vector length guards on instructions which only partially support Evex on some targets. Also included are the addition of a state object which is atomic to each instruction emit and which is programmed with specific target information. There is a reduction of x86 assembler interfaces from 20 to 4. Code which manages the legacy code path for instructions which do not have Evex support is also included which must manage upper bank resources of registers while avoiding complication in the register allocator which would bloat code. Please consider this a high priority review for target system usage. Thanks, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Thu Oct 29 21:36:12 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 30 Oct 2015 00:36:12 +0300 Subject: [9] RFR (L): 8072008: Emit direct call instead of linkTo* for recursive indy/MH.invoke* calls Message-ID: <5632914C.5050106@oracle.com> http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8072008 NB! It touches aarch64 & ppc code, so I'd like to hear from the maintainers whether the changes are fine. To simplify review process, the changes can be split in 2 parts. http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/hotspot.reloc/ Platform-dependent changes in macro assembler to switch from relocation types to relocation instances, and attach pre-resolved method to call sites in generated code. http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/hotspot.attach/ High-level adjustments in C2 and test cases. Overview There's a performance problem with inlining through MH.linkTo*/invokeBasic linkers. When MemberName/receiver is constant and VM sees the target method during compilation, but decides not to inline (e.g. recursive inlining), a call to linker is generated, but more optimal code shape is to call target method directly. The problem with substituting a linker call by a direct/virtual call is that call site resolution logic relies on bytecode info (see SharedRuntime::resolve_{static,opt_virtual,virtual}_call_C and SharedRuntime::find_callee_info_helper). But on bytecode level symbolic reference points to the linker method, which doesn't tell anything about target method. The fix is to attach additional metadata (Method*) to the call site, so VM can use it instead of inspecting bytecode when linking the call site. The Method* is placed in relocation table (for static_call, opt_virtual_call, and virtual_call relocation types) and contains a Method* the call site is resolved to by JIT compiler (_method from a call IR node). It is used only in C2 generated code. Example: MemberName mn = ... <> ... ; // compile-time constant MethodHandle.linkToStatic(..., mn) compiles to: callq 0x0000000109cb1900 ; OopMap{off=28} ; *invokestatic linkToStatic ; - Test::invokeStatic at 3 (line 108) ; {static_call T.f1} It's a call to MethodHandle.linkToStatic on bytecode level, but in generated code it's a direct call to T.f1. For testing purposes, 2 new WhiteBox methods are introduced: - clearInlineCaches - deoptimize They are used in unit tests (test/compiler/jsr292/NonInlinedCall/*) which stresses new code shapes. WhiteBox changes require some adjustments in build scripts, since @HotSpotIntrinsicCandidate isn't part of JDK8. But it will be fixed separately (the idea is to start building wb.jar with JDK9). Testing: JPRT, java/lang/invoke, nashorn, octane Thanks! Best regards, Vladimir Ivanov From vladimir.x.ivanov at oracle.com Fri Oct 30 00:01:52 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 30 Oct 2015 03:01:52 +0300 Subject: [9] RFR (L): 8072008: Emit direct call instead of linkTo* for recursive indy/MH.invoke* calls In-Reply-To: <5632914C.5050106@oracle.com> References: <5632914C.5050106@oracle.com> Message-ID: <5632B370.7050600@oracle.com> In addition, here are some excerpts from InvokeTest compilation log on x86 [1]: (I) Optimized virtual call 0x000000010af78b03: callq 0x000000010aeb9580 ;*invokestatic linkToVirtual {reexecute=0 rethrow=0 return_oop=1} ; {optimized virtual_call java.lang.invoke.InvokeTest$T::f1} relocations: @0x000000010af78954: f0053413 relocInfo at 0x000000010af78956 [type=3(opt_virtual_call) addr=0x000000010af78b03 offset=19 format=1 data=5] | [destination=0x000000010aeb9580 metadata=0x000000011b994a20] Recorded metadata: # 5: 0x000000011b994a20 {method} {0x000000011b994a20} 'f1' '()Ljava/lang/Class;' in 'java/lang/invoke/InvokeTest$T' (II) Virtual call 0x000000010af741e3: callq 0x000000010aeb9800 ;*invokestatic linkToVirtual {reexecute=0 rethrow=0 return_oop=1} ; {virtual_call java.lang.invoke.InvokeTest$T::f1} relocations: @0x000000010af74152: f802000a0004241d relocInfo at 0x000000010af74158 [type=2(virtual_call) addr=0x000000010af741e3 offset=29 format=1 data={000a0004}] | [destination=0x000000010aeb9800 cached_value=0x000000010af741d9 metadata=0x000000011b994a20] Recorded metadata: # 4: 0x000000011b994a20 {method} {0x000000011b994a20} 'f1' '()Ljava/lang/Class;' in 'java/lang/invoke/InvokeTest$T' (III) Static call 0x000000010af91e0f: callq 0x000000010aeb9a80 ;*invokestatic linkToStatic {reexecute=0 rethrow=0 return_oop=1} ; {static_call java.lang.invoke.InvokeTest$T::f2} relocations: @0x000000010af91dd0: f004440f relocInfo at 0x000000010af91dd2 [type=4(static_call) addr=0x000000010af91e0f offset=15 format=1 data=4] | [destination=0x000000010aeb9a80 metadata=0x000000011b994ae8] Recorded metadata: # 4: 0x000000011b994ae8 {method} {0x000000011b994ae8} 'f2' '()Ljava/lang/Class;' in 'java/lang/invoke/InvokeTest$T' Best regards, Vladimir Ivanov [1] http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/InvokeTest.log On 10/30/15 12:36 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8072008 > > NB! It touches aarch64 & ppc code, so I'd like to hear from the > maintainers whether the changes are fine. > > To simplify review process, the changes can be split in 2 parts. > > http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/hotspot.reloc/ > > Platform-dependent changes in macro assembler to switch from relocation > types to relocation instances, and attach pre-resolved method to call > sites in generated code. > > http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/hotspot.attach/ > High-level adjustments in C2 and test cases. > > Overview > > There's a performance problem with inlining through > MH.linkTo*/invokeBasic linkers. When MemberName/receiver is constant and > VM sees the target method during compilation, but decides not to inline > (e.g. recursive inlining), a call to linker is generated, but more > optimal code shape is to call target method directly. > > The problem with substituting a linker call by a direct/virtual call is > that call site resolution logic relies on bytecode info (see > SharedRuntime::resolve_{static,opt_virtual,virtual}_call_C and > SharedRuntime::find_callee_info_helper). But on bytecode level symbolic > reference points to the linker method, which doesn't tell anything about > target method. > > The fix is to attach additional metadata (Method*) to the call site, so > VM can use it instead of inspecting bytecode when linking the call site. > The Method* is placed in relocation table (for static_call, > opt_virtual_call, and virtual_call relocation types) and contains a > Method* the call site is resolved to by JIT compiler (_method from a > call IR node). > > It is used only in C2 generated code. > > Example: > > MemberName mn = ... <> ... ; // compile-time constant > MethodHandle.linkToStatic(..., mn) > > compiles to: > > callq 0x0000000109cb1900 ; OopMap{off=28} > ; *invokestatic linkToStatic > ; - Test::invokeStatic at 3 (line 108) > ; {static_call T.f1} > > It's a call to MethodHandle.linkToStatic on bytecode level, but in > generated code it's a direct call to T.f1. > > For testing purposes, 2 new WhiteBox methods are introduced: > - clearInlineCaches > - deoptimize > > They are used in unit tests (test/compiler/jsr292/NonInlinedCall/*) > which stresses new code shapes. > > WhiteBox changes require some adjustments in build scripts, since > @HotSpotIntrinsicCandidate isn't part of JDK8. But it will be fixed > separately (the idea is to start building wb.jar with JDK9). > > Testing: JPRT, java/lang/invoke, nashorn, octane > > Thanks! > > Best regards, > Vladimir Ivanov From vladimir.kozlov at oracle.com Fri Oct 30 06:59:11 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 30 Oct 2015 14:59:11 +0800 Subject: [9] RFR 8139385: [TESTBUG]: JVMCI test crashes in constantPoolHandle::constantPoolHandle In-Reply-To: <5632458E.40106@oracle.com> References: <5632458E.40106@oracle.com> Message-ID: <5633153F.70206@oracle.com> Good. Thanks, Vladimir On 10/30/15 12:13 AM, Konstantin Shefov wrote: > Hello > > Please review a test bug fix in whitebox.cpp. > > The problem with the test (crash) happened because of C++ type "long" on > Windows 64-bit platforms has length of 32-bit, and when we casted a > 64-bit pointer to "long" we had wrong pointer as a result. > > The solution is to cast the pointer to "jlong", which is "signed long > long" and is always 64-bit. > > Tested by test "compiler/jvmci/compilerToVM/GetConstantPoolTest.java " > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139385 > Webrev: http://cr.openjdk.java.net/~kshefov/8139385/webrev/ > > Thanks > -Konstantin From vladimir.kozlov at oracle.com Fri Oct 30 07:27:53 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 30 Oct 2015 15:27:53 +0800 Subject: [9] RFR(S): 8140574: C2 must re-execute checks after deoptimizing from merged uncommon traps In-Reply-To: <563229D9.2050004@oracle.com> References: <562F5D3E.6070907@oracle.com> <562F927D.2030802@oracle.com> <896013D7-03B4-40B3-900B-9B258ED60AE8@oracle.com> <562F9883.1050904@oracle.com> <5630C88D.5000205@oracle.com> <08638FB2-B0C8-4140-8913-77F80A9449C5@oracle.com> <5630FD2C.5060804@oracle.com> <563229D9.2050004@oracle.com> Message-ID: <56331BF9.4050701@oracle.com> First, I would move new check code to ciTypeFlow so that you call it as: if (!flow->is_dominated_by(bci, dom_bci)) { return false; } Second, you check only successors blocks which could be optimized out. ciTypeFlow has rpo list and _methodBlocks->block_containing(bci). May be we can do more general domination search if it is not expensive. Thanks, Vladimir On 10/29/15 10:14 PM, Tobias Hartmann wrote: > Hi Roland, > >> I suppose if we can prove that the bci of the unc for the dominating if dominates the bci of the unc of the dominated if then we?re good. Maybe by iterating over the ciTypeFlow blocks of the method. > > I implemented such a check using ciTypeFlow: > > http://cr.openjdk.java.net/~thartmann/8140574/webrev.02/ > > It works fine for my test and I also verified that the range checks in TestExplicitRangeChecks are folded. The only problem is that the checks in 'test19' [1] are not folded anymore because they were inlined from 'test19_helper1' and 'test19_helper2'. The current approach only looks at the current method and does not check inlined methods. I think this could be done as well but would be much more complicated. Maybe we can do this in a follow up RFE. > > What do you think? > > Thanks, > Tobias > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/e18469511c58/test/compiler/rangechecks/TestExplicitRangeChecks.java#l362 > > > On 28.10.2015 17:51, Tobias Hartmann wrote: >> Hi Roland, >> >> thanks for the suggestions - I was able to create a regression test that triggers the problem you described: >> http://cr.openjdk.java.net/~thartmann/8140574/webrev.01/ >> >> I'll look into how we can fix this. >> >> Best, >> Tobias >> >> On 28.10.2015 14:33, Roland Westrelin wrote: >>>>> if (i < 0) { >>>>> if (some_condition) { >>>>> // never taken so unc unstable_if >>>>> } >>>>> } >>>> >>>> I agree that this would be a problem but why would be add an uncommon trap here? Either the i<0 branch is never executed, then we would add the uncommon trap like this >>>> >>>> if (i < 0) { >>>> // unc unstable_if >>>> } >>>> >>>> or it was executed and then also "some_condition" was true and we would not add an uncommon trap at all. >>> >>> Profiling is what tells us that we can cut one branch. It?s not 100% accurate. >>> >>> We could have: >>> >>> void m1(boolean flag) { >>> if (i < 0) { >>> if (flag) { >>> } >>> } >>> } >>> >>> that is called a lot with flag false and i sometimes negative, sometimes positive so m1 is compiled, no more profiling is recorded and the profiling tells us the branch is never taken. Then we run: >>> >>> void m2(int i) { >>> .. >>> m1(i, flag); >>> } >>> >>> with i always positive. During parsing the compiler is unable to prove flag always true, so we add the unc and after some optimization, flag is proven always true so the test is removed. >>> >>> For instance, this: >>> >>> for (int i = 0; i < 10; i++); >>> flag = (i == 10); >>> >>> I think it would be worthwhile to check we can write a test case like this. >>> >>>>> So I think we have to restrict when we apply that transformation even more, maybe matching the expected bytecode pattern more closely? >>>> >>>> I'm not sure how to do this. We would somehow have to make sure that the dominating uncommon trap "belongs" to the dominating if and not to some other if that was removed, right? >>> >>> I suppose if we can prove that the bci of the unc for the dominating if dominates the bci of the unc of the dominated if then we?re good. Maybe by iterating over the ciTypeFlow blocks of the method. >>> >>> Roland. >>> From roland.westrelin at oracle.com Fri Oct 30 07:38:45 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 30 Oct 2015 08:38:45 +0100 Subject: [9] RFR(S): 8140574: C2 must re-execute checks after deoptimizing from merged uncommon traps In-Reply-To: <56331BF9.4050701@oracle.com> References: <562F5D3E.6070907@oracle.com> <562F927D.2030802@oracle.com> <896013D7-03B4-40B3-900B-9B258ED60AE8@oracle.com> <562F9883.1050904@oracle.com> <5630C88D.5000205@oracle.com> <08638FB2-B0C8-4140-8913-77F80A9449C5@oracle.com> <5630FD2C.5060804@oracle.com> <563229D9.2050004@oracle.com> <56331BF9.4050701@oracle.com> Message-ID: > Second, you check only successors blocks which could be optimized out. ciTypeFlow has rpo list and _methodBlocks->block_containing(bci). May be we can do more general domination search if it is not expensive. Is the check that Tobias proposes even sufficient for correctness? if (i < 0) { if (some_other_test) { } } if (i >= length) { } The some_other_test test is a predecessor of the i >= length test. I also think we need a true domination test. Roland. > > Thanks, > Vladimir > > On 10/29/15 10:14 PM, Tobias Hartmann wrote: >> Hi Roland, >> >>> I suppose if we can prove that the bci of the unc for the dominating if dominates the bci of the unc of the dominated if then we?re good. Maybe by iterating over the ciTypeFlow blocks of the method. >> >> I implemented such a check using ciTypeFlow: >> >> http://cr.openjdk.java.net/~thartmann/8140574/webrev.02/ >> >> It works fine for my test and I also verified that the range checks in TestExplicitRangeChecks are folded. The only problem is that the checks in 'test19' [1] are not folded anymore because they were inlined from 'test19_helper1' and 'test19_helper2'. The current approach only looks at the current method and does not check inlined methods. I think this could be done as well but would be much more complicated. Maybe we can do this in a follow up RFE. >> >> What do you think? >> >> Thanks, >> Tobias >> >> [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/e18469511c58/test/compiler/rangechecks/TestExplicitRangeChecks.java#l362 >> >> >> On 28.10.2015 17:51, Tobias Hartmann wrote: >>> Hi Roland, >>> >>> thanks for the suggestions - I was able to create a regression test that triggers the problem you described: >>> http://cr.openjdk.java.net/~thartmann/8140574/webrev.01/ >>> >>> I'll look into how we can fix this. >>> >>> Best, >>> Tobias >>> >>> On 28.10.2015 14:33, Roland Westrelin wrote: >>>>>> if (i < 0) { >>>>>> if (some_condition) { >>>>>> // never taken so unc unstable_if >>>>>> } >>>>>> } >>>>> >>>>> I agree that this would be a problem but why would be add an uncommon trap here? Either the i<0 branch is never executed, then we would add the uncommon trap like this >>>>> >>>>> if (i < 0) { >>>>> // unc unstable_if >>>>> } >>>>> >>>>> or it was executed and then also "some_condition" was true and we would not add an uncommon trap at all. >>>> >>>> Profiling is what tells us that we can cut one branch. It?s not 100% accurate. >>>> >>>> We could have: >>>> >>>> void m1(boolean flag) { >>>> if (i < 0) { >>>> if (flag) { >>>> } >>>> } >>>> } >>>> >>>> that is called a lot with flag false and i sometimes negative, sometimes positive so m1 is compiled, no more profiling is recorded and the profiling tells us the branch is never taken. Then we run: >>>> >>>> void m2(int i) { >>>> .. >>>> m1(i, flag); >>>> } >>>> >>>> with i always positive. During parsing the compiler is unable to prove flag always true, so we add the unc and after some optimization, flag is proven always true so the test is removed. >>>> >>>> For instance, this: >>>> >>>> for (int i = 0; i < 10; i++); >>>> flag = (i == 10); >>>> >>>> I think it would be worthwhile to check we can write a test case like this. >>>> >>>>>> So I think we have to restrict when we apply that transformation even more, maybe matching the expected bytecode pattern more closely? >>>>> >>>>> I'm not sure how to do this. We would somehow have to make sure that the dominating uncommon trap "belongs" to the dominating if and not to some other if that was removed, right? >>>> >>>> I suppose if we can prove that the bci of the unc for the dominating if dominates the bci of the unc of the dominated if then we?re good. Maybe by iterating over the ciTypeFlow blocks of the method. >>>> >>>> Roland. >>>> From vladimir.kozlov at oracle.com Fri Oct 30 08:16:17 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 30 Oct 2015 16:16:17 +0800 Subject: CR for RFR 8140779 In-Reply-To: References: Message-ID: <56332751.5010800@oracle.com> match_rule_supported() already calls has_match_rule(opcode) so don't call it in match_rule_supported_vector(). Otherwise very nice cleanup. Thank you. Igor, please, use RBT on x86 to execute a lot of tests. Thanks, Vladimir On 10/30/15 3:06 AM, Berg, Michael C wrote: > Hi Folks, > > I would like to contribute AVX 512 changes for bug fixes and performance > issues. I need two reviewers to examine this patch and comment as needed: > > Bug-id: https://bugs.openjdk.java.net/browse/JDK-8140779 > > webrev: > > http://cr.openjdk.java.net/~mcberg/8140779/webrev.01/ > > Debugging on Evex machines, a number of issues were uncovered which > could not be addressed via emulation. These changes include a unified > approach with call frames for Evex and pre Evex targets, performance > changes for 32 bit Evex performance, general improvements to all x86 > targets for reduction patterns, encoding changes for correctness, > changes that reduce register pressure for generated code, CPUID > additions for additional state control, vector length guards on > instructions which only partially support Evex on some targets. Also > included are the addition of a state object which is atomic to each > instruction emit and which is programmed with specific target > information. There is a reduction of x86 assembler interfaces from 20 to > 4. Code which manages the legacy code path for instructions which do not > have Evex support is also included which must manage upper bank > resources of registers while avoiding complication in the register > allocator which would bloat code. > > Please consider this a high priority review for target system usage. > > Thanks, > > Michael > From forax at univ-mlv.fr Fri Oct 30 08:36:31 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 30 Oct 2015 09:36:31 +0100 (CET) Subject: [9] RFR (L): 8072008: Emit direct call instead of linkTo* for recursive indy/MH.invoke* calls In-Reply-To: <5632914C.5050106@oracle.com> References: <5632914C.5050106@oracle.com> Message-ID: <460938999.2219256.1446194191676.JavaMail.zimbra@u-pem.fr> Thanks Vladimir, this fix an important regression between jdk7 (before update 40) and jdk8. I know that this can be complicated but does this patch can be backported to an update of 8 ? regards, R?mi ----- Mail original ----- > De: "Vladimir Ivanov" > ?: "hotspot compiler" > Envoy?: Jeudi 29 Octobre 2015 22:36:12 > Objet: [9] RFR (L): 8072008: Emit direct call instead of linkTo* for recursive indy/MH.invoke* calls > > http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8072008 > > NB! It touches aarch64 & ppc code, so I'd like to hear from the > maintainers whether the changes are fine. > > To simplify review process, the changes can be split in 2 parts. > > http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/hotspot.reloc/ > > Platform-dependent changes in macro assembler to switch from relocation > types to relocation instances, and attach pre-resolved method to call > sites in generated code. > > http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/hotspot.attach/ > High-level adjustments in C2 and test cases. > > Overview > > There's a performance problem with inlining through > MH.linkTo*/invokeBasic linkers. When MemberName/receiver is constant and > VM sees the target method during compilation, but decides not to inline > (e.g. recursive inlining), a call to linker is generated, but more > optimal code shape is to call target method directly. > > The problem with substituting a linker call by a direct/virtual call is > that call site resolution logic relies on bytecode info (see > SharedRuntime::resolve_{static,opt_virtual,virtual}_call_C and > SharedRuntime::find_callee_info_helper). But on bytecode level symbolic > reference points to the linker method, which doesn't tell anything about > target method. > > The fix is to attach additional metadata (Method*) to the call site, so > VM can use it instead of inspecting bytecode when linking the call site. > The Method* is placed in relocation table (for static_call, > opt_virtual_call, and virtual_call relocation types) and contains a > Method* the call site is resolved to by JIT compiler (_method from a > call IR node). > > It is used only in C2 generated code. > > Example: > > MemberName mn = ... <> ... ; // compile-time constant > MethodHandle.linkToStatic(..., mn) > > compiles to: > > callq 0x0000000109cb1900 ; OopMap{off=28} > ; *invokestatic linkToStatic > ; - Test::invokeStatic at 3 (line 108) > ; {static_call T.f1} > > It's a call to MethodHandle.linkToStatic on bytecode level, but in > generated code it's a direct call to T.f1. > > For testing purposes, 2 new WhiteBox methods are introduced: > - clearInlineCaches > - deoptimize > > They are used in unit tests (test/compiler/jsr292/NonInlinedCall/*) > which stresses new code shapes. > > WhiteBox changes require some adjustments in build scripts, since > @HotSpotIntrinsicCandidate isn't part of JDK8. But it will be fixed > separately (the idea is to start building wb.jar with JDK9). > > Testing: JPRT, java/lang/invoke, nashorn, octane > > Thanks! > > Best regards, > Vladimir Ivanov > From vladimir.x.ivanov at oracle.com Fri Oct 30 08:57:48 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 30 Oct 2015 11:57:48 +0300 Subject: [9] RFR (L): 8072008: Emit direct call instead of linkTo* for recursive indy/MH.invoke* calls In-Reply-To: <460938999.2219256.1446194191676.JavaMail.zimbra@u-pem.fr> References: <5632914C.5050106@oracle.com> <460938999.2219256.1446194191676.JavaMail.zimbra@u-pem.fr> Message-ID: <5633310C.9080403@oracle.com> Remi, very unlikely. I'm afraid it's too late to get it into for any forthcoming 8u release. It is not considered as a critical bug, so it would be really hard to get it into. Best regards, Vladimir Ivanov On 10/30/15 11:36 AM, Remi Forax wrote: > Thanks Vladimir, > this fix an important regression between jdk7 (before update 40) and jdk8. > > I know that this can be complicated but does this patch can be backported to an update of 8 ? > > regards, > R?mi > > ----- Mail original ----- >> De: "Vladimir Ivanov" >> ?: "hotspot compiler" >> Envoy?: Jeudi 29 Octobre 2015 22:36:12 >> Objet: [9] RFR (L): 8072008: Emit direct call instead of linkTo* for recursive indy/MH.invoke* calls >> >> http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8072008 >> >> NB! It touches aarch64 & ppc code, so I'd like to hear from the >> maintainers whether the changes are fine. >> >> To simplify review process, the changes can be split in 2 parts. >> >> http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/hotspot.reloc/ >> >> Platform-dependent changes in macro assembler to switch from relocation >> types to relocation instances, and attach pre-resolved method to call >> sites in generated code. >> >> http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/hotspot.attach/ >> High-level adjustments in C2 and test cases. >> >> Overview >> >> There's a performance problem with inlining through >> MH.linkTo*/invokeBasic linkers. When MemberName/receiver is constant and >> VM sees the target method during compilation, but decides not to inline >> (e.g. recursive inlining), a call to linker is generated, but more >> optimal code shape is to call target method directly. >> >> The problem with substituting a linker call by a direct/virtual call is >> that call site resolution logic relies on bytecode info (see >> SharedRuntime::resolve_{static,opt_virtual,virtual}_call_C and >> SharedRuntime::find_callee_info_helper). But on bytecode level symbolic >> reference points to the linker method, which doesn't tell anything about >> target method. >> >> The fix is to attach additional metadata (Method*) to the call site, so >> VM can use it instead of inspecting bytecode when linking the call site. >> The Method* is placed in relocation table (for static_call, >> opt_virtual_call, and virtual_call relocation types) and contains a >> Method* the call site is resolved to by JIT compiler (_method from a >> call IR node). >> >> It is used only in C2 generated code. >> >> Example: >> >> MemberName mn = ... <> ... ; // compile-time constant >> MethodHandle.linkToStatic(..., mn) >> >> compiles to: >> >> callq 0x0000000109cb1900 ; OopMap{off=28} >> ; *invokestatic linkToStatic >> ; - Test::invokeStatic at 3 (line 108) >> ; {static_call T.f1} >> >> It's a call to MethodHandle.linkToStatic on bytecode level, but in >> generated code it's a direct call to T.f1. >> >> For testing purposes, 2 new WhiteBox methods are introduced: >> - clearInlineCaches >> - deoptimize >> >> They are used in unit tests (test/compiler/jsr292/NonInlinedCall/*) >> which stresses new code shapes. >> >> WhiteBox changes require some adjustments in build scripts, since >> @HotSpotIntrinsicCandidate isn't part of JDK8. But it will be fixed >> separately (the idea is to start building wb.jar with JDK9). >> >> Testing: JPRT, java/lang/invoke, nashorn, octane >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov >> From vladimir.kozlov at oracle.com Fri Oct 30 09:00:04 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 30 Oct 2015 17:00:04 +0800 Subject: [9] RFR 8131778: java disables UseAES flag when using VIS=2 on sparc In-Reply-To: <56323E8A.3060208@oracle.com> References: <562FAFB6.7080305@oracle.com> <56323E8A.3060208@oracle.com> Message-ID: <56333194.5060401@oracle.com> sparc: Indent is wrong for !UseAES } else { block. sparc and x86: you need to set flags to false in addition to warnings: } else if (UseAES || UseAESIntrinsics) { + if (UseAES && !FLAG_IS_DEFAULT(UseAES)) { warning("AES instructions are not available on this CPU"); } ! if (UseAESIntrinsics && !FLAG_IS_DEFAULT(UseAESIntrinsics)) { ! warning("AES intrinsics are not available on this CPU"); } Thanks, Vladimir On 10/29/15 11:43 PM, Konstantin Shefov wrote: > This is the fix of the issue when both flags "useAES" and > "useAESIntrinsics" are disabled, although only "useAESIntrinsics" should > be disabled if some instruction sets are not supported by a CPU. > > This fix has been tested by the slightly modified tests from > https://bugs.openjdk.java.net/browse/JDK-8079667 (which will be resolved > in the nearest future). > > -Konstantin > > On 10/27/2015 08:09 PM, Konstantin Shefov wrote: >> Hello >> >> Please review a bug fix. >> >> JBS entry: https://bugs.openjdk.java.net/browse/JDK-8131778 >> Webrev: http://cr.openjdk.java.net/~kshefov/8131778/webrev.00 >> >> Thanks >> -Konstantin > From aph at redhat.com Fri Oct 30 11:01:40 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 30 Oct 2015 11:01:40 +0000 Subject: RFR: 8140611: aarch64: jtreg test jdk/tools/pack200/UnpackerMemoryTest.java SEGVs In-Reply-To: <1445970026.31480.18.camel@mint> References: <1445970026.31480.18.camel@mint> Message-ID: <56334E14.8000809@redhat.com> On 10/27/2015 06:20 PM, Edward Nevill wrote: > 'lr' is a much better choice for the tmp register. We know this is free because we are just about to do a 'rt_call' which clobbers lr in any case. I guess it's OK, but LR is rather unidiomatic for the AArech64 port. You can't use one of the scratch registers? Andrew. From vladimir.x.ivanov at oracle.com Fri Oct 30 11:02:13 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 30 Oct 2015 14:02:13 +0300 Subject: CR for RFR 8140779 In-Reply-To: <56332751.5010800@oracle.com> References: <56332751.5010800@oracle.com> Message-ID: <56334E35.7020009@oracle.com> I also briefly looked through the change. It looks really good and the code is much cleaner now. Best regards, Vladimir Ivanov On 10/30/15 11:16 AM, Vladimir Kozlov wrote: > match_rule_supported() already calls has_match_rule(opcode) so don't > call it in match_rule_supported_vector(). > > Otherwise very nice cleanup. Thank you. > > Igor, please, use RBT on x86 to execute a lot of tests. > > Thanks, > Vladimir > > On 10/30/15 3:06 AM, Berg, Michael C wrote: >> Hi Folks, >> >> I would like to contribute AVX 512 changes for bug fixes and performance >> issues. I need two reviewers to examine this patch and comment as needed: >> >> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8140779 >> >> webrev: >> >> http://cr.openjdk.java.net/~mcberg/8140779/webrev.01/ >> >> Debugging on Evex machines, a number of issues were uncovered which >> could not be addressed via emulation. These changes include a unified >> approach with call frames for Evex and pre Evex targets, performance >> changes for 32 bit Evex performance, general improvements to all x86 >> targets for reduction patterns, encoding changes for correctness, >> changes that reduce register pressure for generated code, CPUID >> additions for additional state control, vector length guards on >> instructions which only partially support Evex on some targets. Also >> included are the addition of a state object which is atomic to each >> instruction emit and which is programmed with specific target >> information. There is a reduction of x86 assembler interfaces from 20 to >> 4. Code which manages the legacy code path for instructions which do not >> have Evex support is also included which must manage upper bank >> resources of registers while avoiding complication in the register >> allocator which would bloat code. >> >> Please consider this a high priority review for target system usage. >> >> Thanks, >> >> Michael >> From aph at redhat.com Fri Oct 30 11:02:59 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 30 Oct 2015 11:02:59 +0000 Subject: [9] RFR (L): 8072008: Emit direct call instead of linkTo* for recursive indy/MH.invoke* calls In-Reply-To: <5632914C.5050106@oracle.com> References: <5632914C.5050106@oracle.com> Message-ID: <56334E63.7050704@redhat.com> On 10/29/2015 09:36 PM, Vladimir Ivanov wrote: > NB! It touches aarch64 & ppc code, so I'd like to hear from the > maintainers whether the changes are fine. It seems to work quite sweetly. Andrew. From vladimir.x.ivanov at oracle.com Fri Oct 30 11:07:05 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 30 Oct 2015 14:07:05 +0300 Subject: [9] RFR (L): 8072008: Emit direct call instead of linkTo* for recursive indy/MH.invoke* calls In-Reply-To: <56334E63.7050704@redhat.com> References: <5632914C.5050106@oracle.com> <56334E63.7050704@redhat.com> Message-ID: <56334F59.4010904@oracle.com> Thanks, Andrew! Best regards, Vladimir Ivanov On 10/30/15 2:02 PM, Andrew Haley wrote: > On 10/29/2015 09:36 PM, Vladimir Ivanov wrote: >> NB! It touches aarch64 & ppc code, so I'd like to hear from the >> maintainers whether the changes are fine. > > It seems to work quite sweetly. > > Andrew. > From tobias.hartmann at oracle.com Fri Oct 30 13:57:42 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 30 Oct 2015 14:57:42 +0100 Subject: [9] RFR(S): 8140574: C2 must re-execute checks after deoptimizing from merged uncommon traps In-Reply-To: References: <562F5D3E.6070907@oracle.com> <562F927D.2030802@oracle.com> <896013D7-03B4-40B3-900B-9B258ED60AE8@oracle.com> <562F9883.1050904@oracle.com> <5630C88D.5000205@oracle.com> <08638FB2-B0C8-4140-8913-77F80A9449C5@oracle.com> <5630FD2C.5060804@oracle.com> <563229D9.2050004@oracle.com> <56331BF9.4050701@oracle.com> Message-ID: <56337756.2070003@oracle.com> Thanks, Vladimir and Roland! You are right, this is still not correct. As you suggested, I implemented a dominator check similar to [1]: http://cr.openjdk.java.net/~thartmann/8140574/webrev.03/ Instead of computing the dominator information for all blocks, we only compute the information if a block is dominated by 'dom_block'. I had to change the implementation of ciTypeFlow to also store predecessor information. I verified correctness with TestExplicitRangeChecks and the regression tests. Thanks, Tobias [1] https://en.wikipedia.org/wiki/Dominator_(graph_theory)#Algorithms On 30.10.2015 08:38, Roland Westrelin wrote: >> Second, you check only successors blocks which could be optimized out. ciTypeFlow has rpo list and _methodBlocks->block_containing(bci). May be we can do more general domination search if it is not expensive. > > Is the check that Tobias proposes even sufficient for correctness? > > if (i < 0) { > if (some_other_test) { > } > } > if (i >= length) { > } > > The some_other_test test is a predecessor of the i >= length test. > > I also think we need a true domination test. > > Roland. > >> >> Thanks, >> Vladimir >> >> On 10/29/15 10:14 PM, Tobias Hartmann wrote: >>> Hi Roland, >>> >>>> I suppose if we can prove that the bci of the unc for the dominating if dominates the bci of the unc of the dominated if then we?re good. Maybe by iterating over the ciTypeFlow blocks of the method. >>> >>> I implemented such a check using ciTypeFlow: >>> >>> http://cr.openjdk.java.net/~thartmann/8140574/webrev.02/ >>> >>> It works fine for my test and I also verified that the range checks in TestExplicitRangeChecks are folded. The only problem is that the checks in 'test19' [1] are not folded anymore because they were inlined from 'test19_helper1' and 'test19_helper2'. The current approach only looks at the current method and does not check inlined methods. I think this could be done as well but would be much more complicated. Maybe we can do this in a follow up RFE. >>> >>> What do you think? >>> >>> Thanks, >>> Tobias >>> >>> [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/e18469511c58/test/compiler/rangechecks/TestExplicitRangeChecks.java#l362 >>> >>> >>> On 28.10.2015 17:51, Tobias Hartmann wrote: >>>> Hi Roland, >>>> >>>> thanks for the suggestions - I was able to create a regression test that triggers the problem you described: >>>> http://cr.openjdk.java.net/~thartmann/8140574/webrev.01/ >>>> >>>> I'll look into how we can fix this. >>>> >>>> Best, >>>> Tobias >>>> >>>> On 28.10.2015 14:33, Roland Westrelin wrote: >>>>>>> if (i < 0) { >>>>>>> if (some_condition) { >>>>>>> // never taken so unc unstable_if >>>>>>> } >>>>>>> } >>>>>> >>>>>> I agree that this would be a problem but why would be add an uncommon trap here? Either the i<0 branch is never executed, then we would add the uncommon trap like this >>>>>> >>>>>> if (i < 0) { >>>>>> // unc unstable_if >>>>>> } >>>>>> >>>>>> or it was executed and then also "some_condition" was true and we would not add an uncommon trap at all. >>>>> >>>>> Profiling is what tells us that we can cut one branch. It?s not 100% accurate. >>>>> >>>>> We could have: >>>>> >>>>> void m1(boolean flag) { >>>>> if (i < 0) { >>>>> if (flag) { >>>>> } >>>>> } >>>>> } >>>>> >>>>> that is called a lot with flag false and i sometimes negative, sometimes positive so m1 is compiled, no more profiling is recorded and the profiling tells us the branch is never taken. Then we run: >>>>> >>>>> void m2(int i) { >>>>> .. >>>>> m1(i, flag); >>>>> } >>>>> >>>>> with i always positive. During parsing the compiler is unable to prove flag always true, so we add the unc and after some optimization, flag is proven always true so the test is removed. >>>>> >>>>> For instance, this: >>>>> >>>>> for (int i = 0; i < 10; i++); >>>>> flag = (i == 10); >>>>> >>>>> I think it would be worthwhile to check we can write a test case like this. >>>>> >>>>>>> So I think we have to restrict when we apply that transformation even more, maybe matching the expected bytecode pattern more closely? >>>>>> >>>>>> I'm not sure how to do this. We would somehow have to make sure that the dominating uncommon trap "belongs" to the dominating if and not to some other if that was removed, right? >>>>> >>>>> I suppose if we can prove that the bci of the unc for the dominating if dominates the bci of the unc of the dominated if then we?re good. Maybe by iterating over the ciTypeFlow blocks of the method. >>>>> >>>>> Roland. >>>>> > From dmitry.dmitriev at oracle.com Fri Oct 30 14:47:25 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Fri, 30 Oct 2015 17:47:25 +0300 Subject: RFR (S): JDK-8141042: Typos and refactoring in Compiler constraints functions Message-ID: <563382FD.2090207@oracle.com> Hello, Please review this small fix for compiler constraint functions. Several typos were fixed(missed space, missed argument to print function) and also some refactoring was made(move range check to the generic 'range()' macro etc.). Also, modified constraint for AliasLevel level to disallow ran with low AliasLevel in mixed mode to avoid crashes. Full description of the problems and solutions are in the JBS: https://bugs.openjdk.java.net/browse/JDK-8141042 I plan to push it to the hs-rt/hotspot repo, because related test fix was also pushed to the hs-rt/hotspot repo. JBS: https://bugs.openjdk.java.net/browse/JDK-8141042 webrev.00: http://cr.openjdk.java.net/~ddmitriev/8141042/webrev.00/ Testing: JPRT(hotspot test set), hotspot all, vm.quick Thanks, Dmitry From roland.westrelin at oracle.com Fri Oct 30 15:07:36 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 30 Oct 2015 16:07:36 +0100 Subject: [9] RFR(S): 8140574: C2 must re-execute checks after deoptimizing from merged uncommon traps In-Reply-To: <56337756.2070003@oracle.com> References: <562F5D3E.6070907@oracle.com> <562F927D.2030802@oracle.com> <896013D7-03B4-40B3-900B-9B258ED60AE8@oracle.com> <562F9883.1050904@oracle.com> <5630C88D.5000205@oracle.com> <08638FB2-B0C8-4140-8913-77F80A9449C5@oracle.com> <5630FD2C.5060804@oracle.com> <563229D9.2050004@oracle.com> <56331BF9.4050701@oracle.com> <56337756.2070003@oracle.com> Message-ID: <9ABF50BA-31E5-46A3-872E-9CB8872A8084@oracle.com> > http://cr.openjdk.java.net/~thartmann/8140574/webrev.03/ I think you need to check that should_reexecute() is true for the JVMState of the dominating test. I don?t know if that part is good or not: 2911 JsrSet* jsr_null = new ciTypeFlow::JsrSet(NULL); 2914 Block* block = get_block_for(index, jsr_null, ciTypeFlow::no_create); 2915 Block* dom_block = get_block_for(dom_index, jsr_null, ciTypeFlow::no_create); (The use of JsrSet null that I don?t understand) Also, the same bci can be in multiple blocks because ciTypeFlow clones some block (ciTypeFlow::clone_loop_head()) and I wonder if that can be a problem or not. Otherwise it looks good to me. Roland. From roland.westrelin at oracle.com Fri Oct 30 15:36:52 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 30 Oct 2015 16:36:52 +0100 Subject: CR for RFR 8140779 In-Reply-To: References: Message-ID: <549586D4-7309-45DB-875F-5904F032997D@oracle.com> > http://cr.openjdk.java.net/~mcberg/8140779/webrev.01/ That looks ok to me. Roland. From roland.westrelin at oracle.com Fri Oct 30 16:04:28 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 30 Oct 2015 17:04:28 +0100 Subject: [REDO] Elide more final field's write memory barrier with escape analysis result In-Reply-To: References: Message-ID: > webrev: http://cr.openjdk.java.net/~hshi/8139758/webrev_v2/ Thanks for re-submitting this. So you?re fixing an existing bug in the process. Nice. We usually need a test case for every bug fix. Can you write such a test case that triggers that bug. test/compiler/stable has example regression test cases for @Stable. Roland. From vladimir.x.ivanov at oracle.com Fri Oct 30 16:36:45 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 30 Oct 2015 19:36:45 +0300 Subject: RFR (S): JDK-8141042: Typos and refactoring in Compiler constraints functions In-Reply-To: <563382FD.2090207@oracle.com> References: <563382FD.2090207@oracle.com> Message-ID: <56339C9D.70907@oracle.com> Looks good. Best regards, Vladimir Ivanov On 10/30/15 5:47 PM, Dmitry Dmitriev wrote: > Hello, > > Please review this small fix for compiler constraint functions. Several > typos were fixed(missed space, missed argument to print function) and > also some refactoring was made(move range check to the generic 'range()' > macro etc.). Also, modified constraint for AliasLevel level to disallow > ran with low AliasLevel in mixed mode to avoid crashes. > > Full description of the problems and solutions are in the JBS: > https://bugs.openjdk.java.net/browse/JDK-8141042 > > I plan to push it to the hs-rt/hotspot repo, because related test fix > was also pushed to the hs-rt/hotspot repo. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8141042 > webrev.00: http://cr.openjdk.java.net/~ddmitriev/8141042/webrev.00/ > Testing: JPRT(hotspot test set), hotspot all, vm.quick > > Thanks, > Dmitry From konstantin.shefov at oracle.com Fri Oct 30 16:39:00 2015 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Fri, 30 Oct 2015 19:39:00 +0300 Subject: [9] RFR 8131778: java disables UseAES flag when using VIS=2 on sparc In-Reply-To: <56333194.5060401@oracle.com> References: <562FAFB6.7080305@oracle.com> <56323E8A.3060208@oracle.com> <56333194.5060401@oracle.com> Message-ID: <56339D24.2000107@oracle.com> Hi Vladimir, Thanks for reviewing. I have changed the webrev according to your comments: http://cr.openjdk.java.net/~kshefov/8131778/webrev.01 -Konstantin On 10/30/2015 12:00 PM, Vladimir Kozlov wrote: > sparc: > > Indent is wrong for !UseAES } else { block. > > sparc and x86: you need to set flags to false in addition to warnings: > > } else if (UseAES || UseAESIntrinsics) { > + if (UseAES && !FLAG_IS_DEFAULT(UseAES)) { > warning("AES instructions are not available on this CPU"); > } > ! if (UseAESIntrinsics && !FLAG_IS_DEFAULT(UseAESIntrinsics)) { > ! warning("AES intrinsics are not available on this CPU"); > } > > Thanks, > Vladimir > > On 10/29/15 11:43 PM, Konstantin Shefov wrote: >> This is the fix of the issue when both flags "useAES" and >> "useAESIntrinsics" are disabled, although only "useAESIntrinsics" should >> be disabled if some instruction sets are not supported by a CPU. >> >> This fix has been tested by the slightly modified tests from >> https://bugs.openjdk.java.net/browse/JDK-8079667 (which will be resolved >> in the nearest future). >> >> -Konstantin >> >> On 10/27/2015 08:09 PM, Konstantin Shefov wrote: >>> Hello >>> >>> Please review a bug fix. >>> >>> JBS entry: https://bugs.openjdk.java.net/browse/JDK-8131778 >>> Webrev: http://cr.openjdk.java.net/~kshefov/8131778/webrev.00 >>> >>> Thanks >>> -Konstantin >> From zoltan.majo at oracle.com Fri Oct 30 16:50:47 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 30 Oct 2015 17:50:47 +0100 Subject: RFR (S): JDK-8141042: Typos and refactoring in Compiler constraints functions In-Reply-To: <563382FD.2090207@oracle.com> References: <563382FD.2090207@oracle.com> Message-ID: <56339FE7.8050705@oracle.com> Hi Dmitry, maybe you want to add a whitespace before opening a parenthesis in the following lines in commandLineFlagConstraintsCompiler.cpp: 243 "between %d and %d inclusively or -1(means no change) " 244 "or %d(special value for critical thread class/priority)\n", Otherwise it looks good (I'm not a Reviewer). Please let me know if you need a sponsor. Thank you and best regards, Zoltan On 10/30/2015 03:47 PM, Dmitry Dmitriev wrote: > Hello, > > Please review this small fix for compiler constraint functions. > Several typos were fixed(missed space, missed argument to print > function) and also some refactoring was made(move range check to the > generic 'range()' macro etc.). Also, modified constraint for > AliasLevel level to disallow ran with low AliasLevel in mixed mode to > avoid crashes. > > Full description of the problems and solutions are in the JBS: > https://bugs.openjdk.java.net/browse/JDK-8141042 > > I plan to push it to the hs-rt/hotspot repo, because related test fix > was also pushed to the hs-rt/hotspot repo. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8141042 > webrev.00: http://cr.openjdk.java.net/~ddmitriev/8141042/webrev.00/ > Testing: JPRT(hotspot test set), hotspot all, vm.quick > > Thanks, > Dmitry From zoltan.majo at oracle.com Fri Oct 30 16:53:03 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 30 Oct 2015 17:53:03 +0100 Subject: RFR (S): JDK-8141042: Typos and refactoring in Compiler constraints functions In-Reply-To: <56339FE7.8050705@oracle.com> References: <563382FD.2090207@oracle.com> <56339FE7.8050705@oracle.com> Message-ID: <5633A06F.5030200@oracle.com> P.S.: Sorry for the format of my previous mail -- my email client seems to play tricks. On 10/30/2015 05:50 PM, Zolt?n Maj? wrote: > Hi Dmitry, > > > maybe you want to add a whitespace before opening a parenthesis in the > following lines in commandLineFlagConstraintsCompiler.cpp: > > 243 "between %d and %d inclusively or -1(means no change) " > 244 "or %d(special value for critical thread class/priority)\n", > Otherwise it looks good (I'm not a Reviewer). Please let me know if > you need a sponsor. Thank you and best regards, Zoltan > > > On 10/30/2015 03:47 PM, Dmitry Dmitriev wrote: >> Hello, >> >> Please review this small fix for compiler constraint functions. >> Several typos were fixed(missed space, missed argument to print >> function) and also some refactoring was made(move range check to the >> generic 'range()' macro etc.). Also, modified constraint for >> AliasLevel level to disallow ran with low AliasLevel in mixed mode to >> avoid crashes. >> >> Full description of the problems and solutions are in the JBS: >> https://bugs.openjdk.java.net/browse/JDK-8141042 >> >> I plan to push it to the hs-rt/hotspot repo, because related test fix >> was also pushed to the hs-rt/hotspot repo. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8141042 >> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8141042/webrev.00/ >> Testing: JPRT(hotspot test set), hotspot all, vm.quick >> >> Thanks, >> Dmitry > From dmitry.dmitriev at oracle.com Fri Oct 30 17:06:43 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Fri, 30 Oct 2015 20:06:43 +0300 Subject: RFR (S): JDK-8141042: Typos and refactoring in Compiler constraints functions In-Reply-To: <56339FE7.8050705@oracle.com> References: <563382FD.2090207@oracle.com> <56339FE7.8050705@oracle.com> Message-ID: <5633A3A3.9000606@oracle.com> Hi Zoltan, Thank you for the review! I add spaces to the 243 and 244 lines in commandLineFlagConstraintsCompiler.cpp. Also, by the way, I move '&&' from start of the line 240 to the end of the line 239. webrev.01: http://cr.openjdk.java.net/~ddmitriev/8141042/webrev.01/ Dmitry On 30.10.2015 19:50, Zolt?n Maj? wrote: > Hi Dmitry, > > > maybe you want to add a whitespace before opening a parenthesis in the > following lines in commandLineFlagConstraintsCompiler.cpp: > > 243 "between %d and %d inclusively or -1(means no change) " > 244 "or %d(special value for critical thread class/priority)\n", > Otherwise it looks good (I'm not a Reviewer). Please let me know if > you need a sponsor. Thank you and best regards, Zoltan > > > On 10/30/2015 03:47 PM, Dmitry Dmitriev wrote: >> Hello, >> >> Please review this small fix for compiler constraint functions. >> Several typos were fixed(missed space, missed argument to print >> function) and also some refactoring was made(move range check to the >> generic 'range()' macro etc.). Also, modified constraint for >> AliasLevel level to disallow ran with low AliasLevel in mixed mode to >> avoid crashes. >> >> Full description of the problems and solutions are in the JBS: >> https://bugs.openjdk.java.net/browse/JDK-8141042 >> >> I plan to push it to the hs-rt/hotspot repo, because related test fix >> was also pushed to the hs-rt/hotspot repo. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8141042 >> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8141042/webrev.00/ >> Testing: JPRT(hotspot test set), hotspot all, vm.quick >> >> Thanks, >> Dmitry > From tatiana.pivovarova at oracle.com Fri Oct 30 17:11:48 2015 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Fri, 30 Oct 2015 20:11:48 +0300 Subject: [9] RFR (XS): 8138809: improve tests for CompilerToVM::hasCompiledCodeForOSR Message-ID: <5633A4D4.4090607@oracle.com> Hy guys! Please review this small patch. I added some negative cases to existed test (nonexistent compilation levels and wrong byte-code indexes). Bugid: https://bugs.openjdk.java.net/browse/JDK-8138809 webrev: http://cr.openjdk.java.net/~tpivovarova/8138809/webrev.00/ Thanks, Tatiana -------------- next part -------------- An HTML attachment was scrubbed... URL: From zoltan.majo at oracle.com Fri Oct 30 17:15:26 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 30 Oct 2015 18:15:26 +0100 Subject: RFR (S): JDK-8141042: Typos and refactoring in Compiler constraints functions In-Reply-To: <5633A3A3.9000606@oracle.com> References: <563382FD.2090207@oracle.com> <56339FE7.8050705@oracle.com> <5633A3A3.9000606@oracle.com> Message-ID: <5633A5AE.4070304@oracle.com> The new webrev looks good to me! Thank you and best regards, Zoltan On 10/30/2015 06:06 PM, Dmitry Dmitriev wrote: > Hi Zoltan, > > Thank you for the review! > I add spaces to the 243 and 244 lines in > commandLineFlagConstraintsCompiler.cpp. Also, by the way, I move '&&' > from start of the line 240 to the end of the line 239. > > webrev.01: http://cr.openjdk.java.net/~ddmitriev/8141042/webrev.01/ > > > Dmitry > > On 30.10.2015 19:50, Zolt?n Maj? wrote: >> Hi Dmitry, >> >> >> maybe you want to add a whitespace before opening a parenthesis in >> the following lines in commandLineFlagConstraintsCompiler.cpp: >> >> 243 "between %d and %d inclusively or -1(means no change) " >> 244 "or %d(special value for critical thread class/priority)\n", >> Otherwise it looks good (I'm not a Reviewer). Please let me know if >> you need a sponsor. Thank you and best regards, Zoltan >> >> >> On 10/30/2015 03:47 PM, Dmitry Dmitriev wrote: >>> Hello, >>> >>> Please review this small fix for compiler constraint functions. >>> Several typos were fixed(missed space, missed argument to print >>> function) and also some refactoring was made(move range check to the >>> generic 'range()' macro etc.). Also, modified constraint for >>> AliasLevel level to disallow ran with low AliasLevel in mixed mode >>> to avoid crashes. >>> >>> Full description of the problems and solutions are in the JBS: >>> https://bugs.openjdk.java.net/browse/JDK-8141042 >>> >>> I plan to push it to the hs-rt/hotspot repo, because related test >>> fix was also pushed to the hs-rt/hotspot repo. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141042 >>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8141042/webrev.00/ >>> Testing: JPRT(hotspot test set), hotspot all, vm.quick >>> >>> Thanks, >>> Dmitry >> > From dean.long at oracle.com Fri Oct 30 19:46:11 2015 From: dean.long at oracle.com (Dean Long) Date: Fri, 30 Oct 2015 12:46:11 -0700 Subject: [9] RFR (L): 8072008: Emit direct call instead of linkTo* for recursive indy/MH.invoke* calls In-Reply-To: <5632914C.5050106@oracle.com> References: <5632914C.5050106@oracle.com> Message-ID: <5633C903.8010107@oracle.com> Do you need *_call_Relocation::method_value() to be scanned in any new places, like nmethod::metadata_do? dl On 10/29/2015 2:36 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8072008 > > NB! It touches aarch64 & ppc code, so I'd like to hear from the > maintainers whether the changes are fine. > > To simplify review process, the changes can be split in 2 parts. > > http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/hotspot.reloc/ > > Platform-dependent changes in macro assembler to switch from > relocation types to relocation instances, and attach pre-resolved > method to call sites in generated code. > > http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/hotspot.attach/ > High-level adjustments in C2 and test cases. > > Overview > > There's a performance problem with inlining through > MH.linkTo*/invokeBasic linkers. When MemberName/receiver is constant > and VM sees the target method during compilation, but decides not to > inline (e.g. recursive inlining), a call to linker is generated, but > more optimal code shape is to call target method directly. > > The problem with substituting a linker call by a direct/virtual call > is that call site resolution logic relies on bytecode info (see > SharedRuntime::resolve_{static,opt_virtual,virtual}_call_C and > SharedRuntime::find_callee_info_helper). But on bytecode level > symbolic reference points to the linker method, which doesn't tell > anything about target method. > > The fix is to attach additional metadata (Method*) to the call site, > so VM can use it instead of inspecting bytecode when linking the call > site. The Method* is placed in relocation table (for static_call, > opt_virtual_call, and virtual_call relocation types) and contains a > Method* the call site is resolved to by JIT compiler (_method from a > call IR node). > > It is used only in C2 generated code. > > Example: > > MemberName mn = ... <> ... ; // compile-time constant > MethodHandle.linkToStatic(..., mn) > > compiles to: > > callq 0x0000000109cb1900 ; OopMap{off=28} > ; *invokestatic linkToStatic > ; - Test::invokeStatic at 3 (line 108) > ; {static_call T.f1} > > It's a call to MethodHandle.linkToStatic on bytecode level, but in > generated code it's a direct call to T.f1. > > For testing purposes, 2 new WhiteBox methods are introduced: > - clearInlineCaches > - deoptimize > > They are used in unit tests (test/compiler/jsr292/NonInlinedCall/*) > which stresses new code shapes. > > WhiteBox changes require some adjustments in build scripts, since > @HotSpotIntrinsicCandidate isn't part of JDK8. But it will be fixed > separately (the idea is to start building wb.jar with JDK9). > > Testing: JPRT, java/lang/invoke, nashorn, octane > > Thanks! > > Best regards, > Vladimir Ivanov From christian.thalinger at oracle.com Fri Oct 30 22:43:50 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 30 Oct 2015 15:43:50 -0700 Subject: RFR (XL): 8139170: JVMCI refresh In-Reply-To: <562AF66D.6050908@oracle.com> References: <6ECC12F2-8693-43AD-8F08-B7E3F21AEB40@oracle.com> <561C863D.7080800@oracle.com> <48004E32-6D60-4E40-9FF0-F0E4148D0344@oracle.com> <561E1A6C.7060306@oracle.com> <3539A5FA-A879-424B-B3C1-4BF11A98ACE1@oracle.com> <634083B2-FA94-4A10-85A8-DC8F2DED7F3A@oracle.com> <561F2292.4050602@oracle.com> <562AF66D.6050908@oracle.com> Message-ID: Last update of the webrev with jdk9b88 and a few more test fixes. Note there are changes in the top-level directory now: http://cr.openjdk.java.net/~twisti/8139170/webrev/ http://cr.openjdk.java.net/~twisti/8139170/hotspot/webrev/ > On Oct 23, 2015, at 8:09 PM, Vladimir Kozlov wrote: > > Good. > > Thanks, > Vladimir > > On 10/24/15 7:12 AM, Christian Thalinger wrote: >> I?ve updated the webrev with fixes from SQE for the tests which were failing due to changes the visibility of some internal classes and methods: >> >> http://cr.openjdk.java.net/~twisti/8139170/webrev/ >> >>> On Oct 14, 2015, at 5:50 PM, Vladimir Kozlov wrote: >>> >>> Okay. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/15/15 8:37 AM, Christian Thalinger wrote: >>>> I have pulled two SPARC changes: >>>> >>>> http://lafo.ssw.uni-linz.ac.at/hg/graal-jvmci-9/rev/c158981b3c59 >>>> http://lafo.ssw.uni-linz.ac.at/hg/graal-jvmci-9/rev/110a130aa88b >>>> >>>> and updated the webrev to include (actually exclude) the individual bug fixes pushed to hs-comp. >>>> >>>>> On Oct 14, 2015, at 8:55 AM, Christian Thalinger wrote: >>>>> >>>>> >>>>>> On Oct 13, 2015, at 11:03 PM, Vladimir Kozlov wrote: >>>>>> >>>>>>>> It would be good if we would run at least one JVMCI test in JPRT. >>>>>> >>>>>> If they are stable you can add them (compiler/jvmci for all) to hotspot_compiler_3 in test/TEST.groups >>>>> >>>>> I?ll let Igor I. do that. >>>>> >>>>>> >>>>>> Changes looks good. >>>>> >>>>> Thanks. >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 10/14/15 2:31 AM, Christian Thalinger wrote: >>>>>>> webrev updated. >>>>>>> >>>>>>>> On Oct 13, 2015, at 8:01 AM, Christian Thalinger >>>>>>>> >>>>>>> > wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On Oct 12, 2015, at 10:59 PM, Doug Simon >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 13 Oct 2015, at 06:19, Vladimir Kozlov >>>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>> Since we will get more changes from labs later we may enumerate >>>>>>>>>> them: JVMCI refresh 1. >>>>>>>>> >>>>>>>>> Or, pessimistically, JVMCI refresh 01 ;-) >>>>>>>>> >>>>>>>>>> Can you explain new sed command in Gensrc-jdk.vm.ci.gmk. >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/graal/graal-jvmci-8/rev/1852abfbaca3 >>>>>>>>> >>>>>>>>>> Are you sure it works on windows? >>>>>>>>> >>>>>>>>> I can?t say for sure but given that I see similar patterns in other >>>>>>>>> *.gmk files, I think it should be fine. >>>>>>>> >>>>>>>> It would be good if we would run at least one JVMCI test in JPRT. >>>>>>>> >>>>>>>>> >>>>>>>>>> Instead of is_trivial(method) may be we should have general function >>>>>>>>>> called from AdvancedThresholdPolicy::common() which return >>>>>>>>>> compilation level for particular method (for example, we can also >>>>>>>>>> limit it using compilecommand). Could be done as separate change >>>>>>>>>> after this. >>>>>>>>>> >>>>>>>>>> I looked on jdk.vm.ci changes and nothing looks terrible wrong. I am >>>>>>>>>> not familiar with it so I can't say that each line is correct. One >>>>>>>>>> thing I am wondering is why explicit imports are used instead of .* >>>>>>>>>> (compilation speed?): >>>>>>>>> >>>>>>>>> http://mail.openjdk.java.net/pipermail/graal-dev/2015-September/003546.html >>>>>>>>> >>>>>>>>>> -import java.lang.annotation.*; >>>>>>>>>> +import java.lang.annotation.ElementType; >>>>>>>>>> +import java.lang.annotation.Retention; >>>>>>>>>> +import java.lang.annotation.RetentionPolicy; >>>>>>>>>> +import java.lang.annotation.Target; >>>>>>>>>> >>>>>>>>>> An other thing is using AMD64/amd64 in files and directory names. >>>>>>>>>> May be we should rename it to x64. >>>>>>>>>> >>>>>>>>>> jvmciCodeInstaller_x86.cpp and jvmciCodeInstaller.cpp has next pattern: >>>>>>>>>> + if (HotSpotMetaspaceConstantImpl::compressed(constant)) { >>>>>>>>>> +#ifdef _LP64 >>>>>>>>>> + ... >>>>>>>>>> +#else >>>>>>>>>> + fatal("unexpected compressed Klass* in 32-bit mode"); >>>>>>>>>> +#endif >>>>>>>>>> + } else { >>>>>>>>>> >>>>>>>>>> It would be nice to hide fatal() in some wrapper function. >>>>>>>>>> >>>>>>>>>> jvmciEnv.cpp use ASSERT instead of DEBUG. We renamed ifdef DEBUG >>>>>>>>>> long ago. >>>>>>>>>> >>>>>>>>>> globals.hpp changes conflict with 8139377. >>>>>>>>> >>>>>>>>> Then we should adopt 8139377 instead. >>>>>>>> >>>>>>>> When I created the review 8139377 was not integrated yet. Let me pull >>>>>>>> again. >>>>>>>> >>>>>>>>> >>>>>>>>>> Tests changes (mostly renaming) looks fine. >>>>>>>>>> >>>>>>>>>> Fix copyright years (2015, 2015) in new files. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 10/13/15 10:19 AM, Christian Thalinger wrote: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8139170 >>>>>>>>>>> http://cr.openjdk.java.net/~twisti/8139170/webrev/ >>>>>>>>>>> >>>>>>>>>>> During the review period for JEP 243 there were some changes and >>>>>>>>>>> enhancements to the JVMCI code done by Oracle Labs. In order to not >>>>>>>>>>> disturb the already long and complicated review of JEP 243 we >>>>>>>>>>> decided to do a refresh after the initial integration. >>>>>>>>>>> >>>>>>>>>>> A lot of the Java changes is switching to using explicit imports. >>>>>>> >>>>> >>>> >> From vladimir.x.ivanov at oracle.com Fri Oct 30 23:27:36 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Sat, 31 Oct 2015 02:27:36 +0300 Subject: [9] RFR (L): 8072008: Emit direct call instead of linkTo* for recursive indy/MH.invoke* calls In-Reply-To: <5633C903.8010107@oracle.com> References: <5632914C.5050106@oracle.com> <5633C903.8010107@oracle.com> Message-ID: <5633FCE8.2010901@oracle.com> No, it's not needed. All relocations refer to recorded metadata section in the nmethod: + Method* virtual_call_Relocation::method_value() { + Metadata* m = code()->metadata_at(_method_index); + assert(m != NULL || _method_index == 0, "should be non-null for non-zero index"); + assert(m == NULL || m->is_method(), "not a method"); + return (Method*)m; + } The following code in nmethod::metadata_do should enumerate them: // Visit the metadata section for (Metadata** p = metadata_begin(); p < metadata_end(); p++) { if (*p == Universe::non_oop_word() || *p == NULL) continue; // skip non-oops Metadata* md = *p; f(md); } Special cases are needed for embedded metadata. And recording happens in resolved_method_index (see *.ad changes): src/share/vm/opto/machnode.hpp: + int resolved_method_index(CodeBuffer &cbuf) const { + if (_override_symbolic_info) { + // Attach corresponding Method* to the call site, so VM can use it during resolution + // instead of querying symbolic info from bytecode. + assert(_method != NULL, "method should be set"); + assert(_method->constant_encoding()->is_method(), "should point to a Method"); + return cbuf.oop_recorder()->find_index(_method->constant_encoding()); + } + return 0; // Use symbolic info from bytecode (resolved_method == NULL). + } Best regards, Vladimir Ivanov On 10/30/15 10:46 PM, Dean Long wrote: > Do you need *_call_Relocation::method_value() to be scanned in any new > places, > like nmethod::metadata_do? > > dl > > On 10/29/2015 2:36 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8072008 >> >> NB! It touches aarch64 & ppc code, so I'd like to hear from the >> maintainers whether the changes are fine. >> >> To simplify review process, the changes can be split in 2 parts. >> >> http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/hotspot.reloc/ >> >> Platform-dependent changes in macro assembler to switch from >> relocation types to relocation instances, and attach pre-resolved >> method to call sites in generated code. >> >> http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/hotspot.attach/ >> High-level adjustments in C2 and test cases. >> >> Overview >> >> There's a performance problem with inlining through >> MH.linkTo*/invokeBasic linkers. When MemberName/receiver is constant >> and VM sees the target method during compilation, but decides not to >> inline (e.g. recursive inlining), a call to linker is generated, but >> more optimal code shape is to call target method directly. >> >> The problem with substituting a linker call by a direct/virtual call >> is that call site resolution logic relies on bytecode info (see >> SharedRuntime::resolve_{static,opt_virtual,virtual}_call_C and >> SharedRuntime::find_callee_info_helper). But on bytecode level >> symbolic reference points to the linker method, which doesn't tell >> anything about target method. >> >> The fix is to attach additional metadata (Method*) to the call site, >> so VM can use it instead of inspecting bytecode when linking the call >> site. The Method* is placed in relocation table (for static_call, >> opt_virtual_call, and virtual_call relocation types) and contains a >> Method* the call site is resolved to by JIT compiler (_method from a >> call IR node). >> >> It is used only in C2 generated code. >> >> Example: >> >> MemberName mn = ... <> ... ; // compile-time constant >> MethodHandle.linkToStatic(..., mn) >> >> compiles to: >> >> callq 0x0000000109cb1900 ; OopMap{off=28} >> ; *invokestatic linkToStatic >> ; - Test::invokeStatic at 3 (line 108) >> ; {static_call T.f1} >> >> It's a call to MethodHandle.linkToStatic on bytecode level, but in >> generated code it's a direct call to T.f1. >> >> For testing purposes, 2 new WhiteBox methods are introduced: >> - clearInlineCaches >> - deoptimize >> >> They are used in unit tests (test/compiler/jsr292/NonInlinedCall/*) >> which stresses new code shapes. >> >> WhiteBox changes require some adjustments in build scripts, since >> @HotSpotIntrinsicCandidate isn't part of JDK8. But it will be fixed >> separately (the idea is to start building wb.jar with JDK9). >> >> Testing: JPRT, java/lang/invoke, nashorn, octane >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov > From dean.long at oracle.com Sat Oct 31 01:17:03 2015 From: dean.long at oracle.com (Dean Long) Date: Fri, 30 Oct 2015 18:17:03 -0700 Subject: [9] RFR (L): 8072008: Emit direct call instead of linkTo* for recursive indy/MH.invoke* calls In-Reply-To: <5633FCE8.2010901@oracle.com> References: <5632914C.5050106@oracle.com> <5633C903.8010107@oracle.com> <5633FCE8.2010901@oracle.com> Message-ID: <5634168F.5060105@oracle.com> Great, just checking! dl On 10/30/2015 4:27 PM, Vladimir Ivanov wrote: > No, it's not needed. All relocations refer to recorded metadata > section in the nmethod: > > + Method* virtual_call_Relocation::method_value() { > + Metadata* m = code()->metadata_at(_method_index); > + assert(m != NULL || _method_index == 0, "should be non-null for > non-zero index"); > + assert(m == NULL || m->is_method(), "not a method"); > + return (Method*)m; > + } > > The following code in nmethod::metadata_do should enumerate them: > > // Visit the metadata section > for (Metadata** p = metadata_begin(); p < metadata_end(); p++) { > if (*p == Universe::non_oop_word() || *p == NULL) continue; // > skip non-oops > Metadata* md = *p; > f(md); > } > > Special cases are needed for embedded metadata. > > And recording happens in resolved_method_index (see *.ad changes): > > src/share/vm/opto/machnode.hpp: > + int resolved_method_index(CodeBuffer &cbuf) const { > + if (_override_symbolic_info) { > + // Attach corresponding Method* to the call site, so VM can > use it during resolution > + // instead of querying symbolic info from bytecode. > + assert(_method != NULL, "method should be set"); > + assert(_method->constant_encoding()->is_method(), "should > point to a Method"); > + return > cbuf.oop_recorder()->find_index(_method->constant_encoding()); > + } > + return 0; // Use symbolic info from bytecode (resolved_method == > NULL). > + } > Best regards, > Vladimir Ivanov > > On 10/30/15 10:46 PM, Dean Long wrote: >> Do you need *_call_Relocation::method_value() to be scanned in any new >> places, >> like nmethod::metadata_do? >> >> dl >> >> On 10/29/2015 2:36 PM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8072008 >>> >>> NB! It touches aarch64 & ppc code, so I'd like to hear from the >>> maintainers whether the changes are fine. >>> >>> To simplify review process, the changes can be split in 2 parts. >>> >>> http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/hotspot.reloc/ >>> >>> Platform-dependent changes in macro assembler to switch from >>> relocation types to relocation instances, and attach pre-resolved >>> method to call sites in generated code. >>> >>> http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/hotspot.attach/ >>> High-level adjustments in C2 and test cases. >>> >>> Overview >>> >>> There's a performance problem with inlining through >>> MH.linkTo*/invokeBasic linkers. When MemberName/receiver is constant >>> and VM sees the target method during compilation, but decides not to >>> inline (e.g. recursive inlining), a call to linker is generated, but >>> more optimal code shape is to call target method directly. >>> >>> The problem with substituting a linker call by a direct/virtual call >>> is that call site resolution logic relies on bytecode info (see >>> SharedRuntime::resolve_{static,opt_virtual,virtual}_call_C and >>> SharedRuntime::find_callee_info_helper). But on bytecode level >>> symbolic reference points to the linker method, which doesn't tell >>> anything about target method. >>> >>> The fix is to attach additional metadata (Method*) to the call site, >>> so VM can use it instead of inspecting bytecode when linking the call >>> site. The Method* is placed in relocation table (for static_call, >>> opt_virtual_call, and virtual_call relocation types) and contains a >>> Method* the call site is resolved to by JIT compiler (_method from a >>> call IR node). >>> >>> It is used only in C2 generated code. >>> >>> Example: >>> >>> MemberName mn = ... <> ... ; // compile-time constant >>> MethodHandle.linkToStatic(..., mn) >>> >>> compiles to: >>> >>> callq 0x0000000109cb1900 ; OopMap{off=28} >>> ; *invokestatic linkToStatic >>> ; - Test::invokeStatic at 3 (line 108) >>> ; {static_call T.f1} >>> >>> It's a call to MethodHandle.linkToStatic on bytecode level, but in >>> generated code it's a direct call to T.f1. >>> >>> For testing purposes, 2 new WhiteBox methods are introduced: >>> - clearInlineCaches >>> - deoptimize >>> >>> They are used in unit tests (test/compiler/jsr292/NonInlinedCall/*) >>> which stresses new code shapes. >>> >>> WhiteBox changes require some adjustments in build scripts, since >>> @HotSpotIntrinsicCandidate isn't part of JDK8. But it will be fixed >>> separately (the idea is to start building wb.jar with JDK9). >>> >>> Testing: JPRT, java/lang/invoke, nashorn, octane >>> >>> Thanks! >>> >>> Best regards, >>> Vladimir Ivanov >> From michael.c.berg at intel.com Sat Oct 31 04:06:32 2015 From: michael.c.berg at intel.com (Berg, Michael C) Date: Sat, 31 Oct 2015 04:06:32 +0000 Subject: CR for RFR 8140779 In-Reply-To: <56332751.5010800@oracle.com> References: <56332751.5010800@oracle.com> Message-ID: Vladimir, Igor: I have uploaded the latest source at http://cr.openjdk.java.net/~mcberg/8140779/webrev.02/ Thanks, Michael -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Friday, October 30, 2015 1:16 AM To: hotspot-compiler-dev at openjdk.java.net; Berg, Michael C Subject: Re: CR for RFR 8140779 match_rule_supported() already calls has_match_rule(opcode) so don't call it in match_rule_supported_vector(). Otherwise very nice cleanup. Thank you. Igor, please, use RBT on x86 to execute a lot of tests. Thanks, Vladimir On 10/30/15 3:06 AM, Berg, Michael C wrote: > Hi Folks, > > I would like to contribute AVX 512 changes for bug fixes and > performance issues. I need two reviewers to examine this patch and comment as needed: > > Bug-id: https://bugs.openjdk.java.net/browse/JDK-8140779 > > webrev: > > http://cr.openjdk.java.net/~mcberg/8140779/webrev.01/ > > Debugging on Evex machines, a number of issues were uncovered which > could not be addressed via emulation. These changes include a unified > approach with call frames for Evex and pre Evex targets, performance > changes for 32 bit Evex performance, general improvements to all x86 > targets for reduction patterns, encoding changes for correctness, > changes that reduce register pressure for generated code, CPUID > additions for additional state control, vector length guards on > instructions which only partially support Evex on some targets. Also > included are the addition of a state object which is atomic to each > instruction emit and which is programmed with specific target > information. There is a reduction of x86 assembler interfaces from 20 > to 4. Code which manages the legacy code path for instructions which > do not have Evex support is also included which must manage upper bank > resources of registers while avoiding complication in the register > allocator which would bloat code. > > Please consider this a high priority review for target system usage. > > Thanks, > > Michael > From vladimir.kozlov at oracle.com Sat Oct 31 05:47:09 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 31 Oct 2015 13:47:09 +0800 Subject: CR for RFR 8140779 In-Reply-To: References: <56332751.5010800@oracle.com> Message-ID: <563455DD.2010306@oracle.com> > match_rule_supported() already calls has_match_rule(opcode) so don't call it in match_rule_supported_vector(). This change was done only in x64 .ad files. It should be done in other platforms too. Igor or who will sponsor this, please, make corresponding changes in our closed sources too (in .ad file and c2_globals_*.hpp). Thanks, Vladimir On 10/31/15 12:06 PM, Berg, Michael C wrote: > Vladimir, Igor: I have uploaded the latest source at > > http://cr.openjdk.java.net/~mcberg/8140779/webrev.02/ > > Thanks, > Michael > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Friday, October 30, 2015 1:16 AM > To: hotspot-compiler-dev at openjdk.java.net; Berg, Michael C > Subject: Re: CR for RFR 8140779 > > match_rule_supported() already calls has_match_rule(opcode) so don't call it in match_rule_supported_vector(). > > Otherwise very nice cleanup. Thank you. > > Igor, please, use RBT on x86 to execute a lot of tests. > > Thanks, > Vladimir > > On 10/30/15 3:06 AM, Berg, Michael C wrote: >> Hi Folks, >> >> I would like to contribute AVX 512 changes for bug fixes and >> performance issues. I need two reviewers to examine this patch and comment as needed: >> >> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8140779 >> >> webrev: >> >> http://cr.openjdk.java.net/~mcberg/8140779/webrev.01/ >> >> Debugging on Evex machines, a number of issues were uncovered which >> could not be addressed via emulation. These changes include a unified >> approach with call frames for Evex and pre Evex targets, performance >> changes for 32 bit Evex performance, general improvements to all x86 >> targets for reduction patterns, encoding changes for correctness, >> changes that reduce register pressure for generated code, CPUID >> additions for additional state control, vector length guards on >> instructions which only partially support Evex on some targets. Also >> included are the addition of a state object which is atomic to each >> instruction emit and which is programmed with specific target >> information. There is a reduction of x86 assembler interfaces from 20 >> to 4. Code which manages the legacy code path for instructions which >> do not have Evex support is also included which must manage upper bank >> resources of registers while avoiding complication in the register >> allocator which would bloat code. >> >> Please consider this a high priority review for target system usage. >> >> Thanks, >> >> Michael >> From vladimir.kozlov at oracle.com Sat Oct 31 05:51:00 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 31 Oct 2015 13:51:00 +0800 Subject: RFR (XL): 8139170: JVMCI refresh In-Reply-To: References: <6ECC12F2-8693-43AD-8F08-B7E3F21AEB40@oracle.com> <561C863D.7080800@oracle.com> <48004E32-6D60-4E40-9FF0-F0E4148D0344@oracle.com> <561E1A6C.7060306@oracle.com> <3539A5FA-A879-424B-B3C1-4BF11A98ACE1@oracle.com> <634083B2-FA94-4A10-85A8-DC8F2DED7F3A@oracle.com> <561F2292.4050602@oracle.com> <562AF66D.6050908@oracle.com> Message-ID: <563456C4.6040205@oracle.com> On 10/31/15 6:43 AM, Christian Thalinger wrote: > Last update of the webrev with jdk9b88 and a few more test fixes. Note there are changes in the top-level directory now: > > http://cr.openjdk.java.net/~twisti/8139170/webrev/ Good. > http://cr.openjdk.java.net/~twisti/8139170/hotspot/webrev/ Just push it already! It is hard to continue reviewing the same big changes over and over again. If something brakes we can fix it easy as small additional changes which easy to review. Thanks, Vladimir > > >> On Oct 23, 2015, at 8:09 PM, Vladimir Kozlov wrote: >> >> Good. >> >> Thanks, >> Vladimir >> >> On 10/24/15 7:12 AM, Christian Thalinger wrote: >>> I?ve updated the webrev with fixes from SQE for the tests which were failing due to changes the visibility of some internal classes and methods: >>> >>> http://cr.openjdk.java.net/~twisti/8139170/webrev/ >>> >>>> On Oct 14, 2015, at 5:50 PM, Vladimir Kozlov wrote: >>>> >>>> Okay. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/15/15 8:37 AM, Christian Thalinger wrote: >>>>> I have pulled two SPARC changes: >>>>> >>>>> http://lafo.ssw.uni-linz.ac.at/hg/graal-jvmci-9/rev/c158981b3c59 >>>>> http://lafo.ssw.uni-linz.ac.at/hg/graal-jvmci-9/rev/110a130aa88b >>>>> >>>>> and updated the webrev to include (actually exclude) the individual bug fixes pushed to hs-comp. >>>>> >>>>>> On Oct 14, 2015, at 8:55 AM, Christian Thalinger wrote: >>>>>> >>>>>> >>>>>>> On Oct 13, 2015, at 11:03 PM, Vladimir Kozlov wrote: >>>>>>> >>>>>>>>> It would be good if we would run at least one JVMCI test in JPRT. >>>>>>> >>>>>>> If they are stable you can add them (compiler/jvmci for all) to hotspot_compiler_3 in test/TEST.groups >>>>>> >>>>>> I?ll let Igor I. do that. >>>>>> >>>>>>> >>>>>>> Changes looks good. >>>>>> >>>>>> Thanks. >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 10/14/15 2:31 AM, Christian Thalinger wrote: >>>>>>>> webrev updated. >>>>>>>> >>>>>>>>> On Oct 13, 2015, at 8:01 AM, Christian Thalinger >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Oct 12, 2015, at 10:59 PM, Doug Simon >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 13 Oct 2015, at 06:19, Vladimir Kozlov >>>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>> Since we will get more changes from labs later we may enumerate >>>>>>>>>>> them: JVMCI refresh 1. >>>>>>>>>> >>>>>>>>>> Or, pessimistically, JVMCI refresh 01 ;-) >>>>>>>>>> >>>>>>>>>>> Can you explain new sed command in Gensrc-jdk.vm.ci.gmk. >>>>>>>>>> >>>>>>>>>> http://hg.openjdk.java.net/graal/graal-jvmci-8/rev/1852abfbaca3 >>>>>>>>>> >>>>>>>>>>> Are you sure it works on windows? >>>>>>>>>> >>>>>>>>>> I can?t say for sure but given that I see similar patterns in other >>>>>>>>>> *.gmk files, I think it should be fine. >>>>>>>>> >>>>>>>>> It would be good if we would run at least one JVMCI test in JPRT. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Instead of is_trivial(method) may be we should have general function >>>>>>>>>>> called from AdvancedThresholdPolicy::common() which return >>>>>>>>>>> compilation level for particular method (for example, we can also >>>>>>>>>>> limit it using compilecommand). Could be done as separate change >>>>>>>>>>> after this. >>>>>>>>>>> >>>>>>>>>>> I looked on jdk.vm.ci changes and nothing looks terrible wrong. I am >>>>>>>>>>> not familiar with it so I can't say that each line is correct. One >>>>>>>>>>> thing I am wondering is why explicit imports are used instead of .* >>>>>>>>>>> (compilation speed?): >>>>>>>>>> >>>>>>>>>> http://mail.openjdk.java.net/pipermail/graal-dev/2015-September/003546.html >>>>>>>>>> >>>>>>>>>>> -import java.lang.annotation.*; >>>>>>>>>>> +import java.lang.annotation.ElementType; >>>>>>>>>>> +import java.lang.annotation.Retention; >>>>>>>>>>> +import java.lang.annotation.RetentionPolicy; >>>>>>>>>>> +import java.lang.annotation.Target; >>>>>>>>>>> >>>>>>>>>>> An other thing is using AMD64/amd64 in files and directory names. >>>>>>>>>>> May be we should rename it to x64. >>>>>>>>>>> >>>>>>>>>>> jvmciCodeInstaller_x86.cpp and jvmciCodeInstaller.cpp has next pattern: >>>>>>>>>>> + if (HotSpotMetaspaceConstantImpl::compressed(constant)) { >>>>>>>>>>> +#ifdef _LP64 >>>>>>>>>>> + ... >>>>>>>>>>> +#else >>>>>>>>>>> + fatal("unexpected compressed Klass* in 32-bit mode"); >>>>>>>>>>> +#endif >>>>>>>>>>> + } else { >>>>>>>>>>> >>>>>>>>>>> It would be nice to hide fatal() in some wrapper function. >>>>>>>>>>> >>>>>>>>>>> jvmciEnv.cpp use ASSERT instead of DEBUG. We renamed ifdef DEBUG >>>>>>>>>>> long ago. >>>>>>>>>>> >>>>>>>>>>> globals.hpp changes conflict with 8139377. >>>>>>>>>> >>>>>>>>>> Then we should adopt 8139377 instead. >>>>>>>>> >>>>>>>>> When I created the review 8139377 was not integrated yet. Let me pull >>>>>>>>> again. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Tests changes (mostly renaming) looks fine. >>>>>>>>>>> >>>>>>>>>>> Fix copyright years (2015, 2015) in new files. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> On 10/13/15 10:19 AM, Christian Thalinger wrote: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8139170 >>>>>>>>>>>> http://cr.openjdk.java.net/~twisti/8139170/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> During the review period for JEP 243 there were some changes and >>>>>>>>>>>> enhancements to the JVMCI code done by Oracle Labs. In order to not >>>>>>>>>>>> disturb the already long and complicated review of JEP 243 we >>>>>>>>>>>> decided to do a refresh after the initial integration. >>>>>>>>>>>> >>>>>>>>>>>> A lot of the Java changes is switching to using explicit imports. >>>>>>>> >>>>>> >>>>> >>> > From vladimir.kozlov at oracle.com Sat Oct 31 05:58:11 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 31 Oct 2015 13:58:11 +0800 Subject: [9] RFR 8131778: java disables UseAES flag when using VIS=2 on sparc In-Reply-To: <56339D24.2000107@oracle.com> References: <562FAFB6.7080305@oracle.com> <56323E8A.3060208@oracle.com> <56333194.5060401@oracle.com> <56339D24.2000107@oracle.com> Message-ID: <56345873.4050909@oracle.com> Looks good. Thanks, Vladimir On 10/31/15 12:39 AM, Konstantin Shefov wrote: > Hi Vladimir, > > Thanks for reviewing. > > I have changed the webrev according to your comments: > http://cr.openjdk.java.net/~kshefov/8131778/webrev.01 > > -Konstantin > > On 10/30/2015 12:00 PM, Vladimir Kozlov wrote: >> sparc: >> >> Indent is wrong for !UseAES } else { block. >> >> sparc and x86: you need to set flags to false in addition to warnings: >> >> } else if (UseAES || UseAESIntrinsics) { >> + if (UseAES && !FLAG_IS_DEFAULT(UseAES)) { >> warning("AES instructions are not available on this CPU"); >> } >> ! if (UseAESIntrinsics && !FLAG_IS_DEFAULT(UseAESIntrinsics)) { >> ! warning("AES intrinsics are not available on this CPU"); >> } >> >> Thanks, >> Vladimir >> >> On 10/29/15 11:43 PM, Konstantin Shefov wrote: >>> This is the fix of the issue when both flags "useAES" and >>> "useAESIntrinsics" are disabled, although only "useAESIntrinsics" should >>> be disabled if some instruction sets are not supported by a CPU. >>> >>> This fix has been tested by the slightly modified tests from >>> https://bugs.openjdk.java.net/browse/JDK-8079667 (which will be resolved >>> in the nearest future). >>> >>> -Konstantin >>> >>> On 10/27/2015 08:09 PM, Konstantin Shefov wrote: >>>> Hello >>>> >>>> Please review a bug fix. >>>> >>>> JBS entry: https://bugs.openjdk.java.net/browse/JDK-8131778 >>>> Webrev: http://cr.openjdk.java.net/~kshefov/8131778/webrev.00 >>>> >>>> Thanks >>>> -Konstantin >>> >