From martijnverburg at gmail.com Wed Feb 1 09:46:47 2017 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 1 Feb 2017 09:46:47 +0000 Subject: Notice for new signups to Project Valhalla - How to Contribute Message-ID: Hi all, There will be renewed interest before FOSDEM so I'm sending out the quarterly reminder for newcomers. Valhalla is one of OpenJDK's more complex areas to get involved in. A guide to getting started with Valhalla and levels of suggested contribution can be found on the home page: http://openjdk.java.net/projects/valhalla/ Cheers, Martijn From tobias.hartmann at oracle.com Mon Feb 6 12:39:29 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 6 Feb 2017 13:39:29 +0100 Subject: Problems with vdefault/vwithfield Message-ID: <369a227f-f6b5-fad7-f60f-b78c967671cd@oracle.com> Hi, please review the following fix: http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.06/ We hit a ShouldNotReachHere in GenerateOopMap::interp1() with "unexpected opcode: 215" because the _vwithfield bytecode is not known. I fixed the same problem in MethodLiveness::BasicBlock::compute_gen_kill_single() and BCEscapeAnalyzer::iterate_one_block() and modified the tests to trigger this. Thanks, Tobias From tobias.hartmann at oracle.com Mon Feb 6 13:00:45 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 6 Feb 2017 14:00:45 +0100 Subject: Problems with vdefault/vwithfield In-Reply-To: <369a227f-f6b5-fad7-f60f-b78c967671cd@oracle.com> References: <369a227f-f6b5-fad7-f60f-b78c967671cd@oracle.com> Message-ID: Hi, Mr. Simms pointed out that in GenerateOopMap::interp1() me may have to pop arguments for vwithdefault. But then we would need to do the same with vnew. I'm not too familiar with that code, Fred, could you have a look? Thanks, Tobias On 06.02.2017 13:39, Tobias Hartmann wrote: > Hi, > > please review the following fix: > http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.06/ > > We hit a ShouldNotReachHere in GenerateOopMap::interp1() with "unexpected opcode: 215" because the _vwithfield bytecode is not known. I fixed the same problem in MethodLiveness::BasicBlock::compute_gen_kill_single() and BCEscapeAnalyzer::iterate_one_block() and modified the tests to trigger this. > > Thanks, > Tobias > From frederic.parain at oracle.com Mon Feb 6 14:35:25 2017 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 6 Feb 2017 09:35:25 -0500 Subject: Problems with vdefault/vwithfield In-Reply-To: References: <369a227f-f6b5-fad7-f60f-b78c967671cd@oracle.com> Message-ID: <59f0178b-e07b-5b17-4aa5-1ad205b26338@oracle.com> I'll look at the issue today. Fred On 02/06/2017 08:00 AM, Tobias Hartmann wrote: > Hi, > > Mr. Simms pointed out that in GenerateOopMap::interp1() me may have to pop arguments for vwithdefault. But then we would need to do the same with vnew. I'm not too familiar with that code, Fred, could you have a look? > > Thanks, > Tobias > > On 06.02.2017 13:39, Tobias Hartmann wrote: >> Hi, >> >> please review the following fix: >> http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.06/ >> >> We hit a ShouldNotReachHere in GenerateOopMap::interp1() with "unexpected opcode: 215" because the _vwithfield bytecode is not known. I fixed the same problem in MethodLiveness::BasicBlock::compute_gen_kill_single() and BCEscapeAnalyzer::iterate_one_block() and modified the tests to trigger this. >> >> Thanks, >> Tobias >> From frederic.parain at oracle.com Mon Feb 6 15:09:35 2017 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 6 Feb 2017 10:09:35 -0500 Subject: Problems with vdefault/vwithfield In-Reply-To: <59f0178b-e07b-5b17-4aa5-1ad205b26338@oracle.com> References: <369a227f-f6b5-fad7-f60f-b78c967671cd@oracle.com> <59f0178b-e07b-5b17-4aa5-1ad205b26338@oracle.com> Message-ID: <7aa1668f-5eca-abc4-0777-65bd3add4880@oracle.com> Handling of vnew and vwithfield are indeed incorrect. Handling of vdefault of vdefault is correct. You can push your code if you want, I'll fix vnew and vwithfield later this week. Thanks, Fred On 02/06/2017 09:35 AM, Frederic Parain wrote: > I'll look at the issue today. > > Fred > > On 02/06/2017 08:00 AM, Tobias Hartmann wrote: >> Hi, >> >> Mr. Simms pointed out that in GenerateOopMap::interp1() me may have to >> pop arguments for vwithdefault. But then we would need to do the same >> with vnew. I'm not too familiar with that code, Fred, could you have a >> look? >> >> Thanks, >> Tobias >> >> On 06.02.2017 13:39, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following fix: >>> http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.06/ >>> >>> We hit a ShouldNotReachHere in GenerateOopMap::interp1() with >>> "unexpected opcode: 215" because the _vwithfield bytecode is not >>> known. I fixed the same problem in >>> MethodLiveness::BasicBlock::compute_gen_kill_single() and >>> BCEscapeAnalyzer::iterate_one_block() and modified the tests to >>> trigger this. >>> >>> Thanks, >>> Tobias >>> From tobias.hartmann at oracle.com Mon Feb 6 15:07:37 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 6 Feb 2017 16:07:37 +0100 Subject: Problems with vdefault/vwithfield In-Reply-To: <7aa1668f-5eca-abc4-0777-65bd3add4880@oracle.com> References: <369a227f-f6b5-fad7-f60f-b78c967671cd@oracle.com> <59f0178b-e07b-5b17-4aa5-1ad205b26338@oracle.com> <7aa1668f-5eca-abc4-0777-65bd3add4880@oracle.com> Message-ID: <827deb6c-8107-321a-8e62-2018897a3bfe@oracle.com> Hi Fred, On 06.02.2017 16:09, Frederic Parain wrote: > Handling of vnew and vwithfield are indeed incorrect. > Handling of vdefault of vdefault is correct. > > You can push your code if you want, I'll fix vnew and vwithfield > later this week. Thanks, I'll do so. Best regards, Tobias > Thanks, > > Fred > > On 02/06/2017 09:35 AM, Frederic Parain wrote: >> I'll look at the issue today. >> >> Fred >> >> On 02/06/2017 08:00 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> Mr. Simms pointed out that in GenerateOopMap::interp1() me may have to >>> pop arguments for vwithdefault. But then we would need to do the same >>> with vnew. I'm not too familiar with that code, Fred, could you have a >>> look? >>> >>> Thanks, >>> Tobias >>> >>> On 06.02.2017 13:39, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following fix: >>>> http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.06/ >>>> >>>> We hit a ShouldNotReachHere in GenerateOopMap::interp1() with >>>> "unexpected opcode: 215" because the _vwithfield bytecode is not >>>> known. I fixed the same problem in >>>> MethodLiveness::BasicBlock::compute_gen_kill_single() and >>>> BCEscapeAnalyzer::iterate_one_block() and modified the tests to >>>> trigger this. >>>> >>>> Thanks, >>>> Tobias >>>> From tobias.hartmann at oracle.com Mon Feb 6 15:09:49 2017 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Mon, 06 Feb 2017 15:09:49 +0000 Subject: hg: valhalla/valhalla/hotspot: Fixed vdefault/vwithfield Message-ID: <201702061509.v16F9nwG014616@aojmv0008.oracle.com> Changeset: 4e77262011e9 Author: thartmann Date: 2017-02-06 16:09 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/4e77262011e9 Fixed vdefault/vwithfield ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/compiler/methodLiveness.cpp ! src/share/vm/oops/generateOopMap.cpp ! test/compiler/valhalla/valuetypes/ValueTypeTestBench.java From frederic.parain at oracle.com Tue Feb 7 18:22:38 2017 From: frederic.parain at oracle.com (frederic parain) Date: Tue, 7 Feb 2017 13:22:38 -0500 Subject: RFR: Fixing interpreter oopmap generation for vnew and vwithfield Message-ID: Greetings, Please review this change which fixes the generation of the interpreter oopmaps for vnew, vdefault and vwithfield. http://cr.openjdk.java.net/~fparain/generateOopMapFix/index.html The fix has been tested by Tobias (I haven't been able to reproduce the crashes on my machine). Thank you, Fred From david.simms at oracle.com Wed Feb 8 09:11:20 2017 From: david.simms at oracle.com (David Simms) Date: Wed, 8 Feb 2017 10:11:20 +0100 Subject: RFR: Fixing interpreter oopmap generation for vnew and vwithfield In-Reply-To: References: Message-ID: <684d5199-ea7b-9032-36fe-9abfbc0cfe95@oracle.com> Looks good. I've also been having a hard time producing crashes or obvious leaks...I might look to add some more assertions/tracing when I add some code in there... Thanks Frederic ! On 07/02/17 19:22, frederic parain wrote: > Greetings, > > Please review this change which fixes the generation of the > interpreter oopmaps for vnew, vdefault and vwithfield. > > http://cr.openjdk.java.net/~fparain/generateOopMapFix/index.html > > The fix has been tested by Tobias (I haven't been able to reproduce > the crashes on my machine). > > Thank you, > > Fred From frederic.parain at oracle.com Wed Feb 8 14:01:19 2017 From: frederic.parain at oracle.com (frederic parain) Date: Wed, 8 Feb 2017 09:01:19 -0500 Subject: RFR: Fixing interpreter oopmap generation for vnew and vwithfield In-Reply-To: <684d5199-ea7b-9032-36fe-9abfbc0cfe95@oracle.com> References: <684d5199-ea7b-9032-36fe-9abfbc0cfe95@oracle.com> Message-ID: <411adff7-38d9-f086-9529-99a10eb206d1@oracle.com> Thank you for your review. Fred On 08/02/2017 04:11, David Simms wrote: > > Looks good. > > I've also been having a hard time producing crashes or obvious leaks...I > might look to add some more assertions/tracing when I add some code in > there... > > Thanks Frederic ! > > On 07/02/17 19:22, frederic parain wrote: >> Greetings, >> >> Please review this change which fixes the generation of the >> interpreter oopmaps for vnew, vdefault and vwithfield. >> >> http://cr.openjdk.java.net/~fparain/generateOopMapFix/index.html >> >> The fix has been tested by Tobias (I haven't been able to reproduce >> the crashes on my machine). >> >> Thank you, >> >> Fred > > From frederic.parain at oracle.com Wed Feb 8 14:05:02 2017 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Wed, 08 Feb 2017 14:05:02 +0000 Subject: hg: valhalla/valhalla/hotspot: Fix interpreter oopmap generation for vnew, vdefault and vwithfield Message-ID: <201702081405.v18E52jK026713@aojmv0008.oracle.com> Changeset: 6b0043ccc9ac Author: fparain Date: 2017-02-08 09:07 -0500 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/6b0043ccc9ac Fix interpreter oopmap generation for vnew, vdefault and vwithfield ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/generateOopMap.hpp From tobias.hartmann at oracle.com Mon Feb 13 16:39:46 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 13 Feb 2017 17:39:46 +0100 Subject: Value type array optimizations/fixes with C2 Message-ID: <28f80a1a-947c-15f0-c6e4-a9a776d1f48f@oracle.com> Hi, http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.07/ please review this change which includes: - Fixed wrong return value in AddPNode::Value() - Basic version of ValueArrayKlass::oop_print_on() for debugging - Fixed escape analysis to keep track of the field being accessed in VT arrays - Re-enabled asserts in graphKit.cpp and memnode.cpp - Implemented scalar replacement for flattened value type arrays - Implemented re-allocation of scalar replaced value type arrays on deoptimization - Refactored valuetypenode.cpp and related code - Refactored test bench to use flags from jtreg command line instead of hard-coding command line options - Enabled/added corresponding regression tests and match rules There are still some problems with incremental inlining. I disabled the flag for testing and will work on fixing this next. Thanks, Tobias From john.r.rose at oracle.com Tue Feb 14 01:58:31 2017 From: john.r.rose at oracle.com (John Rose) Date: Mon, 13 Feb 2017 17:58:31 -0800 Subject: Proposal: Add a type token class for representing generic types In-Reply-To: References: Message-ID: <3B5EDE35-5464-4514-B2F8-3D66C00F7B28@oracle.com> On Jan 4, 2017, at 2:17 PM, Brian Goetz wrote: > > Now, this isn't a slam-dunk indictment, but its a concern. This is a special case of source-reflection, and as such shares the basic design degrees of freedom: Given a fragment of source code, the compiler probably has a nice internal AST for it, but how much of that AST do we want to feed through to runtime? Source locations? Source text? Internal compiler data derived and decorated onto the AST (probably not)? Types? Which types? Annotations? Which? Etc., etc. VM type descriptors come in (at least) two forms, and both are significantly different from source types. So there's a lot to design here. I think the prototyping work should proceed by supporting specific use cases as javac extensions which generate code via indy (or condy, when we get that). We need a fairly representative set of worked examples of use cases, with prototypes, before we can generalize to answer the question, "what's in a type token". Gunnar's use cases appear to rely on existing obscure behavior of reflecting over inner classes. That's barely specified, often surprising, and not a suitable foundation for answering the above questions. A better foundation would be a mechanism (forthcoming) for uttering today's JVM constant pool constants in Java code, such as MH and MT constants. That mechanism should be extensible, enough to support the needed prototypes of (various formulations of) type tokens. Meanwhile, the Valhalla stuff is likely to be driven by a balanced set of tradeoffs regarding translation strategy of reified generics supporting the "any" keyword on type variables. And also of the details of value types. Those requirements almost certainly will force us to shape yet another type system for the VM, and/or a moderate extension of the existing type system(s). HTH ? John From david.simms at oracle.com Tue Feb 14 09:10:58 2017 From: david.simms at oracle.com (David Simms) Date: Tue, 14 Feb 2017 10:10:58 +0100 Subject: Value type array optimizations/fixes with C2 In-Reply-To: <28f80a1a-947c-15f0-c6e4-a9a776d1f48f@oracle.com> References: <28f80a1a-947c-15f0-c6e4-a9a776d1f48f@oracle.com> Message-ID: <2cd63641-9c42-7101-8525-cfacc7b159a9@oracle.com> I can't answer for the JIT parts, but the rest of it looks good ! On 13/02/17 17:39, Tobias Hartmann wrote: > Hi, > > http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.07/ > > please review this change which includes: > - Fixed wrong return value in AddPNode::Value() > - Basic version of ValueArrayKlass::oop_print_on() for debugging > - Fixed escape analysis to keep track of the field being accessed in VT arrays > - Re-enabled asserts in graphKit.cpp and memnode.cpp > - Implemented scalar replacement for flattened value type arrays > - Implemented re-allocation of scalar replaced value type arrays on deoptimization > - Refactored valuetypenode.cpp and related code > - Refactored test bench to use flags from jtreg command line instead of hard-coding command line options > - Enabled/added corresponding regression tests and match rules > > There are still some problems with incremental inlining. I disabled the flag for testing and will work on fixing this next. > > Thanks, > Tobias From tobias.hartmann at oracle.com Tue Feb 14 09:12:46 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 14 Feb 2017 10:12:46 +0100 Subject: Value type array optimizations/fixes with C2 In-Reply-To: <2cd63641-9c42-7101-8525-cfacc7b159a9@oracle.com> References: <28f80a1a-947c-15f0-c6e4-a9a776d1f48f@oracle.com> <2cd63641-9c42-7101-8525-cfacc7b159a9@oracle.com> Message-ID: <36800aad-4784-7ac4-4a4a-df0b07044ec3@oracle.com> Hi, On 14.02.2017 10:10, David Simms wrote: > I can't answer for the JIT parts, but the rest of it looks good ! Thanks for looking at this! Best regards, Tobias > On 13/02/17 17:39, Tobias Hartmann wrote: >> Hi, >> >> http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.07/ >> >> please review this change which includes: >> - Fixed wrong return value in AddPNode::Value() >> - Basic version of ValueArrayKlass::oop_print_on() for debugging >> - Fixed escape analysis to keep track of the field being accessed in VT arrays >> - Re-enabled asserts in graphKit.cpp and memnode.cpp >> - Implemented scalar replacement for flattened value type arrays >> - Implemented re-allocation of scalar replaced value type arrays on deoptimization >> - Refactored valuetypenode.cpp and related code >> - Refactored test bench to use flags from jtreg command line instead of hard-coding command line options >> - Enabled/added corresponding regression tests and match rules >> >> There are still some problems with incremental inlining. I disabled the flag for testing and will work on fixing this next. >> >> Thanks, >> Tobias > > From rwestrel at redhat.com Wed Feb 15 08:30:06 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 15 Feb 2017 09:30:06 +0100 Subject: Value type array optimizations/fixes with C2 In-Reply-To: <28f80a1a-947c-15f0-c6e4-a9a776d1f48f@oracle.com> References: <28f80a1a-947c-15f0-c6e4-a9a776d1f48f@oracle.com> Message-ID: > http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.07/ That looks good to me. Roland. From tobias.hartmann at oracle.com Wed Feb 15 08:35:36 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 15 Feb 2017 09:35:36 +0100 Subject: Value type array optimizations/fixes with C2 In-Reply-To: References: <28f80a1a-947c-15f0-c6e4-a9a776d1f48f@oracle.com> Message-ID: Hi Roland, On 15.02.2017 09:30, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.07/ > > That looks good to me. Thanks for looking at this! Best regards, Tobias > > Roland. > From tobias.hartmann at oracle.com Wed Feb 15 08:41:44 2017 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Wed, 15 Feb 2017 08:41:44 +0000 Subject: hg: valhalla/valhalla/hotspot: Implemented scalar replacement and re-allocation for VT arrays Message-ID: <201702150841.v1F8ficx024885@aojmv0008.oracle.com> Changeset: ff2439741c86 Author: thartmann Date: 2017-02-15 09:41 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/ff2439741c86 Implemented scalar replacement and re-allocation for VT arrays Summary: - Fixed wrong return value in AddPNode::Value() - Basic version of ValueArrayKlass::oop_print_on() for debugging - Fixed escape analysis to keep track of the field being accessed in VT arrays - Re-enabled asserts in graphKit.cpp and memnode.cpp - Implemented scalar replacement for flattened value type arrays - Implemented re-allocation of scalar replaced value type arrays on deoptimization - Refactored valuetypenode.cpp and related code - Refactored test bench to use flags from jtreg command line instead of hard-coding command line options - Enabled/added corresponding regression tests and match rules Reviewed-by: dsimms, roland ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/valueArrayKlass.cpp ! src/share/vm/oops/valueArrayKlass.hpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/valuetypenode.cpp ! src/share/vm/opto/valuetypenode.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/fieldDescriptor.cpp ! test/compiler/valhalla/valuetypes/ValueTypeTestBench.java From rwestrel at redhat.com Wed Feb 15 13:37:56 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 15 Feb 2017 14:37:56 +0100 Subject: Fixes for 32 bit build on linux Message-ID: <0d737989-394a-b900-25e7-7c7dfaff736c@redhat.com> My changes to the calling convention API broke the build on 32 bit linux: http://cr.openjdk.java.net/~roland/valhalla/32bit-build/webrev.00/ Roland. From tobias.hartmann at oracle.com Thu Feb 16 13:33:55 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 16 Feb 2017 14:33:55 +0100 Subject: Value type array optimizations/fixes with C2 In-Reply-To: <28f80a1a-947c-15f0-c6e4-a9a776d1f48f@oracle.com> References: <28f80a1a-947c-15f0-c6e4-a9a776d1f48f@oracle.com> Message-ID: <2301aee1-375a-f4b8-a713-7de854d3e0a8@oracle.com> Hi, here's a small follow-up fix: - Parse::ensure_phi() should check for dead value type locals before generating Phis for merging - ValueTypeNode::store_values() uses wrong holder object when storing recursively flattened VT fields http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.08/ Thanks, Tobias On 13.02.2017 17:39, Tobias Hartmann wrote: > Hi, > > http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.07/ > > please review this change which includes: > - Fixed wrong return value in AddPNode::Value() > - Basic version of ValueArrayKlass::oop_print_on() for debugging > - Fixed escape analysis to keep track of the field being accessed in VT arrays > - Re-enabled asserts in graphKit.cpp and memnode.cpp > - Implemented scalar replacement for flattened value type arrays > - Implemented re-allocation of scalar replaced value type arrays on deoptimization > - Refactored valuetypenode.cpp and related code > - Refactored test bench to use flags from jtreg command line instead of hard-coding command line options > - Enabled/added corresponding regression tests and match rules > > There are still some problems with incremental inlining. I disabled the flag for testing and will work on fixing this next. > > Thanks, > Tobias > From tobias.hartmann at oracle.com Thu Feb 16 16:15:00 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 16 Feb 2017 17:15:00 +0100 Subject: Fixes for 32 bit build on linux In-Reply-To: <0d737989-394a-b900-25e7-7c7dfaff736c@redhat.com> References: <0d737989-394a-b900-25e7-7c7dfaff736c@redhat.com> Message-ID: <10d46a78-2f62-b6df-8c81-2555f095c66d@oracle.com> Hi Roland, On 15.02.2017 14:37, Roland Westrelin wrote: > My changes to the calling convention API broke the build on 32 bit linux: > > http://cr.openjdk.java.net/~roland/valhalla/32bit-build/webrev.00/ Looks good to me, thanks for fixing the problem I introduced in fieldDescriptor.cpp! Best regards, Tobias From rwestrel at redhat.com Thu Feb 16 16:17:59 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 16 Feb 2017 17:17:59 +0100 Subject: Fixes for 32 bit build on linux In-Reply-To: <10d46a78-2f62-b6df-8c81-2555f095c66d@oracle.com> References: <0d737989-394a-b900-25e7-7c7dfaff736c@redhat.com> <10d46a78-2f62-b6df-8c81-2555f095c66d@oracle.com> Message-ID: <9f67d54f-6c6e-42ae-9a83-16e32e317184@redhat.com> >> http://cr.openjdk.java.net/~roland/valhalla/32bit-build/webrev.00/ > > Looks good to me, thanks for fixing the problem I introduced in fieldDescriptor.cpp! Thanks for taking a look at this. Roland. From rwestrel at redhat.com Thu Feb 16 17:01:29 2017 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Thu, 16 Feb 2017 17:01:29 +0000 Subject: hg: valhalla/valhalla/hotspot: fix x86 32 bit build (broken by change to calling convention) Message-ID: <201702161701.v1GH1ToZ014381@aojmv0008.oracle.com> Changeset: 08ad2f74ff83 Author: roland Date: 2017-02-15 14:31 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/08ad2f74ff83 fix x86 32 bit build (broken by change to calling convention) ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/share/vm/oops/valueArrayKlass.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/runtime/fieldDescriptor.cpp From rwestrel at redhat.com Thu Feb 16 17:03:39 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 16 Feb 2017 18:03:39 +0100 Subject: Value type array optimizations/fixes with C2 In-Reply-To: <2301aee1-375a-f4b8-a713-7de854d3e0a8@oracle.com> References: <28f80a1a-947c-15f0-c6e4-a9a776d1f48f@oracle.com> <2301aee1-375a-f4b8-a713-7de854d3e0a8@oracle.com> Message-ID: > http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.08/ That looks good to me. Roland. From tobias.hartmann at oracle.com Thu Feb 16 17:04:37 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 16 Feb 2017 18:04:37 +0100 Subject: Value type array optimizations/fixes with C2 In-Reply-To: References: <28f80a1a-947c-15f0-c6e4-a9a776d1f48f@oracle.com> <2301aee1-375a-f4b8-a713-7de854d3e0a8@oracle.com> Message-ID: On 16.02.2017 18:03, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.08/ > That looks good to me. Thanks, Roland! From tobias.hartmann at oracle.com Thu Feb 16 17:07:02 2017 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Thu, 16 Feb 2017 17:07:02 +0000 Subject: hg: valhalla/valhalla/hotspot: Parse::ensure_phi() should check for dead value type locals before generating Phis for merging Message-ID: <201702161707.v1GH72Gm015936@aojmv0008.oracle.com> Changeset: 8054e179a773 Author: thartmann Date: 2017-02-16 18:06 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/8054e179a773 Parse::ensure_phi() should check for dead value type locals before generating Phis for merging ValueTypeNode::store_values() uses wrong holder object when storing recursively flattened VT fields Reviewed-by: roland ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/valuetypenode.cpp ! test/compiler/valhalla/valuetypes/ValueTypeTestBench.java From tobias.hartmann at oracle.com Fri Feb 17 08:42:11 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 17 Feb 2017 09:42:11 +0100 Subject: Build broken on Windows x64 In-Reply-To: <588095CA.6050006@oracle.com> References: <588095CA.6050006@oracle.com> Message-ID: <3448f6ae-cc52-0c79-6053-c94b1d20cf25@oracle.com> Hi, any updates on this? I'm also seeing these failures on multiple platforms: # Internal Error (/scratch/opt/jprt/T/P1/173212.tohartma/s/hotspot/src/share/vm/classfile/javaClasses.cpp:891), pid=1767, tid=1770 # assert(_protection_domain_offset != 0) failed: must be set Stack: [0x00007fd82cafd000,0x00007fd82cbfe000], sp=0x00007fd82cbfbdb0, free space=1019k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x138b61f] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x15f V [libjvm.so+0x138c2ff] VMError::report_and_die(Thread*, char const*, int, char const*, char const*, __va_list_tag*)+0x2f V [libjvm.so+0x94402d] report_vm_error(char const*, int, char const*, char const*, ...)+0xdd V [libjvm.so+0xc436a9] java_lang_Class::protection_domain(oop)+0x39 V [libjvm.so+0xbef365] InstanceKlass::protection_domain() const+0x35 V [libjvm.so+0x11db684] AdapterHandlerLibrary::get_adapter(methodHandle const&)+0x194 V [libjvm.so+0xfb2708] Method::make_adapters(methodHandle, Thread*)+0x18 V [libjvm.so+0xfb2fdb] Method::link_method(methodHandle const&, Thread*) [clone .part.110]+0x14b V [libjvm.so+0xfb311a] Method::restore_unshareable_info(Thread*)+0xaa V [libjvm.so+0xc011d8] InstanceKlass::restore_unshareable_info(ClassLoaderData*, Handle, Thread*)+0x78 V [libjvm.so+0x12a736b] SystemDictionary::load_shared_class(instanceKlassHandle, Handle, Handle, Thread*)+0x29b V [libjvm.so+0x12a7542] SystemDictionary::load_shared_class(Symbol*, Handle, Thread*)+0xd2 V [libjvm.so+0x12a3e1a] SystemDictionary::load_instance_class(Symbol*, Handle, Thread*)+0x19a V [libjvm.so+0x12a4feb] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*)+0xa7b V [libjvm.so+0x12a56c1] SystemDictionary::resolve_or_null(Symbol*, Handle, Handle, Thread*)+0xf1 V [libjvm.so+0x12a590e] SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, Thread*)+0x1e V [libjvm.so+0x12a60a1] SystemDictionary::initialize_wk_klass(SystemDictionary::WKID, int, Thread*)+0x151 V [libjvm.so+0x12a612e] SystemDictionary::initialize_wk_klasses_until(SystemDictionary::WKID, SystemDictionary::WKID&, Thread*)+0x5e V [libjvm.so+0x12a6239] SystemDictionary::initialize_preloaded_classes(Thread*)+0x69 V [libjvm.so+0x12a678c] SystemDictionary::initialize(Thread*)+0x24c V [libjvm.so+0x13159e0] Universe::genesis(Thread*)+0x790 V [libjvm.so+0x13163ac] universe2_init()+0x2c V [libjvm.so+0xbef0b8] init_globals()+0xa8 V [libjvm.so+0x12e2adb] Threads::create_vm(JavaVMInitArgs*, bool*)+0x24b V [libjvm.so+0xc62b7e] JNI_CreateJavaVM+0x8e C [libjli.so+0x7173] JavaMain+0x83 C [libpthread.so.0+0x7dc5] start_thread+0xc5 Best regards, Tobias On 19.01.2017 11:32, Tobias Hartmann wrote: > Hi Fred, > > the Windows x64 build is currently broken due to: > C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(283) : error C2065: '_num_int_args' : undeclared identifier > C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(283) : error C2050: switch expression not integral > C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(287) : error C2065: '_num_int_args' : undeclared identifier > C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(294) : error C2065: '_num_int_args' : undeclared identifier > C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(301) : error C2065: '_num_int_args' : undeclared identifier > C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(305) : error C2065: 'c_rarg4' : undeclared identifier > C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(307) : error C2065: 'c_rarg4' : undeclared identifier > C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(308) : error C2065: '_num_int_args' : undeclared identifier > C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(312) : error C2065: 'c_rarg5' : undeclared identifier > C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(314) : error C2065: 'c_rarg5' : undeclared identifier > C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(315) : error C2065: '_num_int_args' : undeclared identifier > C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(554) : error C2259: 'SlowSignatureHandler' : cannot instantiate abstract class > due to following members: > 'void NativeSignatureIterator::pass_valuetype(void)' : is abstract > C:\jprt\T\P1\093341.tohartma\s\hotspot\src\share\vm\runtime/signature.hpp(326) : see declaration of 'NativeSignatureIterator::pass_valuetype' > C:\jprt\T\P1\093341.tohartma\s\hotspot\src\cpu\x86\vm\interpreterRT_x86_64.cpp(554) : error C2228: left of '.iterate' must have class/struct/union > > The problem is that there are some #ifdef _WIN64 in the code and the WIN64 specific code is not implemented. Is this intended? > > Thanks, > Tobias > From tobias.hartmann at oracle.com Fri Feb 17 09:45:05 2017 From: tobias.hartmann at oracle.com (tobias.hartmann at oracle.com) Date: Fri, 17 Feb 2017 09:45:05 +0000 Subject: hg: valhalla/valhalla/hotspot: Fixed JPRT build assert in escape analysis Message-ID: <201702170945.v1H9j5pl015951@aojmv0008.oracle.com> Changeset: 9a55fbdc1883 Author: thartmann Date: 2017-02-17 10:44 +0100 URL: http://hg.openjdk.java.net/valhalla/valhalla/hotspot/rev/9a55fbdc1883 Fixed JPRT build assert in escape analysis ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciValueKlass.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/valuetypenode.cpp From tobias.hartmann at oracle.com Fri Feb 17 11:19:41 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 17 Feb 2017 12:19:41 +0100 Subject: Fixes for 32 bit build on linux In-Reply-To: <9f67d54f-6c6e-42ae-9a83-16e32e317184@redhat.com> References: <0d737989-394a-b900-25e7-7c7dfaff736c@redhat.com> <10d46a78-2f62-b6df-8c81-2555f095c66d@oracle.com> <9f67d54f-6c6e-42ae-9a83-16e32e317184@redhat.com> Message-ID: <5bdd0fc1-0a4a-2161-f123-801b8d0c7d5d@oracle.com> Hi Roland, the value type tests still fail on 32-bit due to the calling convention changes: # Internal Error (/scratch/opt/jprt/T/P1/100517.tohartma/s/hotspot/src/cpu/x86/vm/sharedRuntime_x86_32.cpp:802), pid=30518, tid=30548 # assert(i > 0 && (sig_extended.at(i-1)._bt == T_LONG || sig_extended.at(i-1)._bt == T_DOUBLE)) failed: missing half and # Internal Error (/oracle/valhalla/hotspot/src/cpu/x86/vm/sharedRuntime_x86_32.cpp:809), pid=3036, tid=3073 # assert(!regs[i].second()->is_valid() || regs[i].first()->next() == regs[i].second()) failed: scrambled load targets? Due you plan to fix this as well or should we disable testing on 32-bit for now? Best regards, Tobias On 16.02.2017 17:17, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~roland/valhalla/32bit-build/webrev.00/ >> >> Looks good to me, thanks for fixing the problem I introduced in fieldDescriptor.cpp! > > Thanks for taking a look at this. > > Roland. > From rwestrel at redhat.com Fri Feb 17 12:52:04 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 17 Feb 2017 13:52:04 +0100 Subject: Fixes for 32 bit build on linux In-Reply-To: <5bdd0fc1-0a4a-2161-f123-801b8d0c7d5d@oracle.com> References: <0d737989-394a-b900-25e7-7c7dfaff736c@redhat.com> <10d46a78-2f62-b6df-8c81-2555f095c66d@oracle.com> <9f67d54f-6c6e-42ae-9a83-16e32e317184@redhat.com> <5bdd0fc1-0a4a-2161-f123-801b8d0c7d5d@oracle.com> Message-ID: Hi Tobias, > Due you plan to fix this as well or should we disable testing on 32-bit for now? Nope. I don't have such a plan. We could force ValueTypePassFieldsAsArgs to false on 32 bits to be able to run those tests? Roland. From tobias.hartmann at oracle.com Fri Feb 17 12:59:36 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 17 Feb 2017 13:59:36 +0100 Subject: Fixes for 32 bit build on linux In-Reply-To: References: <0d737989-394a-b900-25e7-7c7dfaff736c@redhat.com> <10d46a78-2f62-b6df-8c81-2555f095c66d@oracle.com> <9f67d54f-6c6e-42ae-9a83-16e32e317184@redhat.com> <5bdd0fc1-0a4a-2161-f123-801b8d0c7d5d@oracle.com> Message-ID: <31b596fb-c65e-2527-708a-0b6c6c86f28f@oracle.com> Hi Roland, On 17.02.2017 13:52, Roland Westrelin wrote: > Nope. I don't have such a plan. We could force ValueTypePassFieldsAsArgs > to false on 32 bits to be able to run those tests? Okay, yes, I'll do that with my next change (found some other problems as well). Best regards, Tobias From karen.kinnear at oracle.com Thu Feb 23 16:07:43 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 23 Feb 2017 11:07:43 -0500 Subject: CFV: New Valhalla Committer: Stanislav Smirnov Message-ID: I hereby nominate Stanislav Smirnov (email: stanislav.smirnov at oracle.com ) to Committer role in Project Valhalla. Stas (openjdk name: stsmirno) works in the Hotspot JVM Runtime team and has already contributed 8 hotspot [1] and 1 idk [2] changesets to Valhalla. Votes are due by March 9th, 2017. Only current Valhalla Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4] [1] http://hg.openjdk.java.net/valhalla/valhalla/hotspot/log?revcount=2000&rev=(author(%22stsmirno%22)+or+desc(%22Contributed-by:+stanislav.smirnov at oracle.com%22))+and+not+merge() [2] http://hg.openjdk.java.net/jdk9/dev/log?revcount=2000&rev=(author(%22stsmirno%22)+or+desc(%22Contributed-by:+stanislav.smirnov at oracle.com%22))+and+not+merge() [3] http://openjdk.java.net/census#valhalla [4] http://openjdk.java.net/projects#committer-vote From zoltan.majo at oracle.com Thu Feb 23 16:09:22 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 23 Feb 2017 17:09:22 +0100 Subject: CFV: New Valhalla Committer: Stanislav Smirnov In-Reply-To: References: Message-ID: Vote: yes. Best regards, Zoltan On 02/23/2017 05:07 PM, Karen Kinnear wrote: > I hereby nominate Stanislav Smirnov (email: stanislav.smirnov at oracle.com ) to Committer role in Project Valhalla. > > Stas (openjdk name: stsmirno) works in the Hotspot JVM Runtime team and has already contributed 8 hotspot [1] and 1 idk [2] changesets to Valhalla. > > Votes are due by March 9th, 2017. > > Only current Valhalla Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [4] > > [1] http://hg.openjdk.java.net/valhalla/valhalla/hotspot/log?revcount=2000&rev=(author(%22stsmirno%22)+or+desc(%22Contributed-by:+stanislav.smirnov at oracle.com%22))+and+not+merge() > [2] http://hg.openjdk.java.net/jdk9/dev/log?revcount=2000&rev=(author(%22stsmirno%22)+or+desc(%22Contributed-by:+stanislav.smirnov at oracle.com%22))+and+not+merge() > [3] http://openjdk.java.net/census#valhalla > [4] http://openjdk.java.net/projects#committer-vote From tobias.hartmann at oracle.com Thu Feb 23 16:10:10 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 23 Feb 2017 17:10:10 +0100 Subject: CFV: New Valhalla Committer: Stanislav Smirnov In-Reply-To: References: Message-ID: <6f5cb41b-8501-5c11-664f-00ef495824a1@oracle.com> Vote: yes On 23.02.2017 17:07, Karen Kinnear wrote: > I hereby nominate Stanislav Smirnov (email: stanislav.smirnov at oracle.com ) to Committer role in Project Valhalla. > > Stas (openjdk name: stsmirno) works in the Hotspot JVM Runtime team and has already contributed 8 hotspot [1] and 1 idk [2] changesets to Valhalla. > > Votes are due by March 9th, 2017. > > Only current Valhalla Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [4] > > [1] http://hg.openjdk.java.net/valhalla/valhalla/hotspot/log?revcount=2000&rev=(author(%22stsmirno%22)+or+desc(%22Contributed-by:+stanislav.smirnov at oracle.com%22))+and+not+merge() > [2] http://hg.openjdk.java.net/jdk9/dev/log?revcount=2000&rev=(author(%22stsmirno%22)+or+desc(%22Contributed-by:+stanislav.smirnov at oracle.com%22))+and+not+merge() > [3] http://openjdk.java.net/census#valhalla > [4] http://openjdk.java.net/projects#committer-vote > From frederic.parain at oracle.com Thu Feb 23 16:18:00 2017 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 23 Feb 2017 11:18:00 -0500 Subject: CFV: New Valhalla Committer: Stanislav Smirnov In-Reply-To: References: Message-ID: Vote: yes Fred On 02/23/2017 11:07 AM, Karen Kinnear wrote: > I hereby nominate Stanislav Smirnov (email: stanislav.smirnov at oracle.com ) to Committer role in Project Valhalla. > > Stas (openjdk name: stsmirno) works in the Hotspot JVM Runtime team and has already contributed 8 hotspot [1] and 1 idk [2] changesets to Valhalla. > > Votes are due by March 9th, 2017. > > Only current Valhalla Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [4] > > [1] http://hg.openjdk.java.net/valhalla/valhalla/hotspot/log?revcount=2000&rev=(author(%22stsmirno%22)+or+desc(%22Contributed-by:+stanislav.smirnov at oracle.com%22))+and+not+merge() > [2] http://hg.openjdk.java.net/jdk9/dev/log?revcount=2000&rev=(author(%22stsmirno%22)+or+desc(%22Contributed-by:+stanislav.smirnov at oracle.com%22))+and+not+merge() > [3] http://openjdk.java.net/census#valhalla > [4] http://openjdk.java.net/projects#committer-vote > From karen.kinnear at oracle.com Thu Feb 23 16:16:41 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 23 Feb 2017 11:16:41 -0500 Subject: CFV: New Valhalla Committer: Stanislav Smirnov In-Reply-To: References: Message-ID: Vote: yes thanks, Karen > On Feb 23, 2017, at 11:18 AM, Frederic Parain wrote: > > Vote: yes > > Fred > > On 02/23/2017 11:07 AM, Karen Kinnear wrote: >> I hereby nominate Stanislav Smirnov (email: stanislav.smirnov at oracle.com ) to Committer role in Project Valhalla. >> >> Stas (openjdk name: stsmirno) works in the Hotspot JVM Runtime team and has already contributed 8 hotspot [1] and 1 idk [2] changesets to Valhalla. >> >> Votes are due by March 9th, 2017. >> >> Only current Valhalla Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by >> replying to this mailing list. >> >> For Lazy Consensus voting instructions, see [4] >> >> [1] http://hg.openjdk.java.net/valhalla/valhalla/hotspot/log?revcount=2000&rev=(author(%22stsmirno%22)+or+desc(%22Contributed-by:+stanislav.smirnov at oracle.com%22))+and+not+merge() >> [2] http://hg.openjdk.java.net/jdk9/dev/log?revcount=2000&rev=(author(%22stsmirno%22)+or+desc(%22Contributed-by:+stanislav.smirnov at oracle.com%22))+and+not+merge() >> [3] http://openjdk.java.net/census#valhalla >> [4] http://openjdk.java.net/projects#committer-vote > From maurizio.cimadamore at oracle.com Thu Feb 23 22:01:53 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 23 Feb 2017 22:01:53 +0000 Subject: CFV: New Valhalla Committer: Stanislav Smirnov In-Reply-To: References: Message-ID: <66df927e-bccf-d315-2846-5d6743518751@oracle.com> Vote: yes Maurizio On 23/02/17 16:07, Karen Kinnear wrote: > I hereby nominate Stanislav Smirnov (email: stanislav.smirnov at oracle.com ) to Committer role in Project Valhalla. > > Stas (openjdk name: stsmirno) works in the Hotspot JVM Runtime team and has already contributed 8 hotspot [1] and 1 idk [2] changesets to Valhalla. > > Votes are due by March 9th, 2017. > > Only current Valhalla Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [4] > > [1] http://hg.openjdk.java.net/valhalla/valhalla/hotspot/log?revcount=2000&rev=(author(%22stsmirno%22)+or+desc(%22Contributed-by:+stanislav.smirnov at oracle.com%22))+and+not+merge() > [2] http://hg.openjdk.java.net/jdk9/dev/log?revcount=2000&rev=(author(%22stsmirno%22)+or+desc(%22Contributed-by:+stanislav.smirnov at oracle.com%22))+and+not+merge() > [3] http://openjdk.java.net/census#valhalla > [4] http://openjdk.java.net/projects#committer-vote From david.simms at oracle.com Fri Feb 24 08:09:54 2017 From: david.simms at oracle.com (David Simms) Date: Fri, 24 Feb 2017 09:09:54 +0100 Subject: CFV: New Valhalla Committer: Stanislav Smirnov In-Reply-To: References: Message-ID: <9eb24b0b-133b-9db0-db1d-04b543a409b0@oracle.com> Vote: yes /David Simms On 23/02/17 17:07, Karen Kinnear wrote: > I hereby nominate Stanislav Smirnov (email: stanislav.smirnov at oracle.com ) to Committer role in Project Valhalla. > > Stas (openjdk name: stsmirno) works in the Hotspot JVM Runtime team and has already contributed 8 hotspot [1] and 1 idk [2] changesets to Valhalla. > > Votes are due by March 9th, 2017. > > Only current Valhalla Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [4] > > [1] http://hg.openjdk.java.net/valhalla/valhalla/hotspot/log?revcount=2000&rev=(author(%22stsmirno%22)+or+desc(%22Contributed-by:+stanislav.smirnov at oracle.com%22))+and+not+merge() > [2] http://hg.openjdk.java.net/jdk9/dev/log?revcount=2000&rev=(author(%22stsmirno%22)+or+desc(%22Contributed-by:+stanislav.smirnov at oracle.com%22))+and+not+merge() > [3] http://openjdk.java.net/census#valhalla > [4] http://openjdk.java.net/projects#committer-vote From brian.goetz at oracle.com Fri Feb 24 15:00:45 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 24 Feb 2017 10:00:45 -0500 Subject: CFV: New Valhalla Committer: Stanislav Smirnov In-Reply-To: References: Message-ID: <6304a50a-63d9-dc8f-cc12-d752df218570@oracle.com> vote: yes! On 2/23/2017 11:07 AM, Karen Kinnear wrote: > I hereby nominate Stanislav Smirnov (email: stanislav.smirnov at oracle.com ) to Committer role in Project Valhalla. > > Stas (openjdk name: stsmirno) works in the Hotspot JVM Runtime team and has already contributed 8 hotspot [1] and 1 idk [2] changesets to Valhalla. > > Votes are due by March 9th, 2017. > > Only current Valhalla Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [4] > > [1] http://hg.openjdk.java.net/valhalla/valhalla/hotspot/log?revcount=2000&rev=(author(%22stsmirno%22)+or+desc(%22Contributed-by:+stanislav.smirnov at oracle.com%22))+and+not+merge() > [2] http://hg.openjdk.java.net/jdk9/dev/log?revcount=2000&rev=(author(%22stsmirno%22)+or+desc(%22Contributed-by:+stanislav.smirnov at oracle.com%22))+and+not+merge() > [3] http://openjdk.java.net/census#valhalla > [4] http://openjdk.java.net/projects#committer-vote