CFV: New JDK9 Committer: Amy Lu
Brian Goetz
brian.goetz at oracle.com
Fri Jul 17 17:32:04 UTC 2015
Vote: Yes
On Jul 17, 2015, at 1:16 PM, Mike Duigou <openjdk at duigou.org> wrote:
> Vote: YES
>
> On 2015-07-17 06:40, jdk9-dev-request at openjdk.java.net wrote:
>> Send jdk9-dev mailing list submissions to
>> jdk9-dev at openjdk.java.net
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://mail.openjdk.java.net/mailman/listinfo/jdk9-dev
>> or, via email, send a message with subject or body 'help' to
>> jdk9-dev-request at openjdk.java.net
>> You can reach the person managing the list at
>> jdk9-dev-owner at openjdk.java.net
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of jdk9-dev digest..."
>> Today's Topics:
>> 1. Re: JEPs proposed to target JDK 9 (2015/7/16) (Paul Sandoz)
>> 2. Re: JEPs proposed to target JDK 9 (2015/7/16) (Paul Sandoz)
>> 3. CFV: New JDK9 Committer: Amy Lu (Paul Sandoz)
>> 4. Re: CFV: New JDK9 Committer: Amy Lu (Jaroslav Bachorik)
>> 5. Re: CFV: New JDK9 Committer: Amy Lu (Weijun Wang)
>> ----------------------------------------------------------------------
>> Message: 1
>> Date: Fri, 17 Jul 2015 11:43:19 +0200
>> From: Paul Sandoz <paul.sandoz at oracle.com>
>> Cc: jdk9-dev <jdk9-dev at openjdk.java.net>
>> Subject: Re: JEPs proposed to target JDK 9 (2015/7/16)
>> Message-ID: <E7A53553-2CCC-4DB9-B487-E136FDD6BB6E at oracle.com>
>> Content-Type: text/plain; charset=windows-1252
>> Hi Vitaly,
>> Unsafe is not being removed it is being made inaccessible by default.
>> As such it is currently not going anywhere.
>> It?s not possible to replace all the use-cases where one can peek and
>> poke at any memory address.
>> We have to pick off common use-cases and chip away at improving how
>> the JIT optimizes.
>> One such common use-case, separate but perhaps related to VarHandles,
>> i have been looking at is array equality and array comparison (hold
>> your nose at all those new methods on Arrays, it?s what it is!):
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/
>> This patch separates out two implementation approaches for performance
>> measurement purposes.
>> Under the covers one approach leverages an array mismatch method that
>> views byte[]/short[]/char[] etc. as a pseudo unaligned long[] via
>> Unsage.getLongUnaligned:
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/src/java.base/share/classes/java/util/ArraysSupport.java.html
>> So far it seems to perform well and does not require one to dive into
>> HotSpot and create new intrinsics. (Note: there is already a C2
>> intrinsic for char[] equality that performs very well so this
>> technique is not needed in that case, but is still needed for C1.)
>> I have experimental support for a VarHandle that views byte[] as a
>> pseudo unaligned long[]. While you can also do this with ByteBuffer
>> one is in the lap of the escape analysis gods. I would like to revisit
>> this array mismatch method to see if i can replace Unsafe with
>> VarHandle and achieve the same performance and similar generated code
>> (ideally the same in the unrolled loop).
>> In terms of JIT optimisations it would be handy if HotSpot could turn
>> two contigious unaligned unsafe long accesses into one SIMD-based
>> access. I don?t understand enough about the super word/vectorization
>> support in HotSpot to know if that is feasible.
>> More generally if HotSpot could ?naturally" optimize the ordinary
>> array equality/comparison code even better! But i dunno if that is
>> possible for both C1 and C2 in the near term. So i believe the array
>> mismatch implementation technique is a good solution for the moment.
>> Paul.
>> On 17 Jul 2015, at 04:34, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>>> Right, there will be places where programmer knows more than the JIT. This
>>> is expressable with Unsafe today, and will not be quite so with
>>> varhandles. The overall context here is removal of Unsafe, so we're going
>>> from something possible today to something that heavily relies on JIT. It
>>> seems like a bit of Sufficiently Smart Compiler territory ...
>>> Having JIT gather all array lengths and look at most restrictive is good,
>>> but still incurs the arguably biggest cost of this whole thing: memory
>>> accesses that may not otherwise be needed. This also would work best in a
>>> loop context where this check could be amortized over the iterations, but
>>> sometimes you just have islands of code that do this type of thing and not
>>> all bunched in one tight loop that the JIT can easily work with.
>>> Most languages with safety checks typically have unsafe constructs/regions
>>> - Unsafe serves a bit of that role on the JVM, and I'm uncertain that
>>> removing that escape hatch is a good thing when there's no replacement that
>>> works at least as well.
>> ------------------------------
>> Message: 2
>> Date: Fri, 17 Jul 2015 12:24:11 +0200
>> From: Paul Sandoz <paul.sandoz at oracle.com>
>> Cc: jdk9-dev at openjdk.java.net
>> Subject: Re: JEPs proposed to target JDK 9 (2015/7/16)
>> Message-ID: <56CD9DA7-221D-4DA2-9E03-C6E3E7289EF2 at oracle.com>
>> Content-Type: text/plain; charset=windows-1252
>> Hi David,
>> You raise a fair point, although i don?t think lookup is it particular
>> worse than what has to be done today with Unsafe or
>> Atomic*FieldUpdater classes.
>> It is important we leverage the same access control checks as required
>> for method handles, hence the identical lookup process. It might be
>> possible to provide some helper methods for the case where the
>> receiver is identical to the requested lookup class e.g.:
>> VarHandle.findField(Foo.class, "blah", int.class);
>> (MethodHandles.lookup() is caller sensitive, so the calling class of
>> that method above would be required.)
>> We did explore the possibility of a field literal mechanism (a syntax
>> and potentially the notion of dynamic constants) but considered that
>> too much to bite off at the moment. So i hope we can improve this over
>> time. And more generally once we have value types and generics over
>> primitives and values i hope we can further improve the user
>> experience.
>> Paul.
>> On 17 Jul 2015, at 00:21, David M. Lloyd <david.lloyd at redhat.com> wrote:
>>> On 07/16/2015 04:56 PM, mark.reinhold at oracle.com wrote:
>>>> The following JEPs have been placed into the "Proposed to Target"
>>>> state by their owners after discussion and review:
>>>> 193: Variable Handles
>>>> http://openjdk.java.net/jeps/193
>>> Given how frequently I expect the VarHandle API will be used (in my code, at least), I think it would be nice to require that there be a simpler/friendlier API for constructing the things. In particular, the example proposed API usage is particularly unfriendly:
>>> class Bar {
>>> static final VarHandle VH_FOO_FIELD_I;
>>> static {
>>> try {
>>> VH_FOO_FIELD_I = MethodHandles.lookup().
>>> in(Foo.class).
>>> findFieldVarHandle(Foo.class, "i", int.class);
>>> } catch (Exception e) {
>>> throw new Error(e);
>>> }
>>> }
>>> }
>>> Ideally, VarHandle construction should be possible on one line, and thus should already throw Error directly. To me, the *worst case* API looks something like this:
>>> private static final VarHandle BLAH = MethodHandles.lookup().in(Foo.class).findFieldVarHandle(Foo.class, "blah", int.class);
>>> But even that is arguably fairly ridiculous complexity considering that we're talking about the ability to update a variable in a way that conceptually is not dissimilar to the simple assignments that we have at the language level today. It is my belief that having a "syntax" which is highly complex relative to the more traditional operations that these are very strongly related to acts to perpetuate a mode of thinking that these kinds of operations belong to a different "strata" of engineering, which I think is unwarranted.
>>> I do not think that requiring a simpler syntax for realizing VarHandles in the initial implementation is an unreasonable additional requirement.
>>> --
>>> - DML
>> ------------------------------
>> Message: 3
>> Date: Fri, 17 Jul 2015 15:23:43 +0200
>> From: Paul Sandoz <paul.sandoz at oracle.com>
>> To: jdk9-dev <jdk9-dev at openjdk.java.net>
>> Subject: CFV: New JDK9 Committer: Amy Lu
>> Message-ID: <5D76F3B7-DBC0-420E-BA97-A7D95B268D7C at oracle.com>
>> Content-Type: text/plain; charset=windows-1252
>> I hereby nominate Amy Lu to jdk9 Committer.
>> Amy helps keep the JDK testing lights on, running ?em, analysis of
>> failures, and fixing ?em.
>> In total Amy has contributed 27 changes to jdk9/jdk since August 2014 [1].
>> Votes are due by 31st July.
>> Only current JDK9 Committers [2] 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 [3].
>> Thanks,
>> Paul.
>> [1]
>> hg log -f -k amy.lu -k amlu --template
>> "{date|isodate}\n{desc|firstline}\nhttp://hg.openjdk.java.net/jdk9/dev/jdk/rev/{rev}\n\n
>> 2015-07-16 10:21 +0200
>> 8131140: Mark some tests from WhileOpStatefulTest.java and
>> WhileOpTest.java as serialization hostile
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12406
>> 2015-07-16 10:17 +0200
>> 8130402: Mark intermittently failing test: tools/pack200/PackTestZip64.java
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12405
>> 2015-06-30 10:00 +0200
>> 8129759: Mark two tests from DistinctOpTest.java and SliceOpTest.java
>> as serialization hostile
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12256
>> 2015-06-12 14:28 +0800
>> 8085879: Mark intermittently failing: java/util/Arrays/ParallelPrefix.java
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12170
>> 2015-06-03 15:33 +0100
>> 8081773: sun/net/www/protocol/https/ChunkedOutputStream.java
>> references library that doesn't exist
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12079
>> 2015-06-03 12:37 +0200
>> 8081775: two lib/testlibrary tests are failing with "Error. failed to
>> clean up files after test" with jtreg 4.1 b12
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12077
>> 2015-05-20 17:16 +0300
>> 8080680: sun/nio/cs/TestCompoundTest.java should be removed from TEST.groups
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12007
>> 2015-05-19 11:05 -0400
>> 8080658: Update sun/nio/cs/FindDecoderBugs.java to use random number
>> generator library
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/11982
>> 2015-05-08 10:22 +0100
>> 8079651: (dc) Promiscuous.java fails with NumberFormatException due to
>> network interference
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/11891
>> 2015-04-03 00:00 -0700
>> 8076632: Remove duplicate tests: FDTest, MethodReferenceTest and more
>> -- follow-on (completion)
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/11712
>> 2015-04-02 17:32 -0700
>> 8075304: Remove duplicate test: FDTest
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/11711
>> 2015-03-16 10:24 +0100
>> 8075111: Mark testFlatMappingClose (from CollectorsTest) as
>> serialization hostile
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/11610
>> 2015-03-10 13:30 +0100
>> 8074674: Doclint regression in java/util/regex/Matcher.java
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/11583
>> 2015-02-10 12:28 -0500
>> 8069255: Suppress deprecation warnings in jdk.rmic module (jdk repo)
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/11380
>> 2015-01-23 16:16 +0000
>> 8069262: Doclint regression in java.nio.channels.Channels
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/11302
>> 2014-12-13 20:22 +0000
>> 8067112: Update java/util/Collections/EmptyIterator.java to eliminate
>> dependency on sun.tools.java
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/11099
>> 2014-12-03 14:34 +0000
>> 8066131: Update
>> java/nio/charset/Charset/NIOCharsetAvailabilityTest.java to eliminate
>> dependency on sun.misc.Launcher
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/11050
>> 2014-11-26 11:12 -0800
>> 8060026: Update jdk/test/tools/launcher tests to eliminate dependency
>> on sun.tools.jar.Main
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/11025
>> 2014-10-16 19:27 -0700
>> 8060432: tools/pack200/TestNormal.java fails on Windows with
>> java.io.FileNotFoundException after JDK-8058854
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/10847
>> 2014-10-13 18:16 +0100
>> 8058856: tools/jar/LeadingGarbage.java, introduced in JDK-8058520,
>> fails on Windows
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/10789
>> 2014-10-13 17:43 +0100
>> 8058854: Remove dependency on dt.jar from
>> test/tools/jar/normalize/TestNormal.java
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/10788
>> 2014-10-11 13:24 +0100
>> 8058855: Update java.util.zip tests to work with modular image
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/10784
>> 2014-09-17 23:27 -0400
>> 8058569: Update java/lang/invoke/lambda tests to eliminate dependency
>> on sun.tools.jar.Main
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/10686
>> 2014-08-22 18:54 -0700
>> 8055852: Add test/java/lang/Math/DoubleConsts.java and FloatConsts.java
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/10530
>> 2014-08-22 14:56 -0700
>> 8042003: Update java/lang/Math tests to eliminate dependency on
>> sun.misc.DoubleConsts and sun.misc.FloatConsts
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/10529
>> 2014-08-19 12:26 -0700
>> 8055262: Update jdk/test/java/util/Base64 tests to remove use of
>> sun.misc.BASE64Encoder/Decoder
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/10518
>> 2014-08-03 20:09 +0800
>> 8054095: No space allowed in platforms string in ProblemList.txt
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/10432
>> [2] http://openjdk.java.net/census#jdk9
>> [3] http://openjdk.java.net/projects#committer-vote
>> ------------------------------
>> Message: 4
>> Date: Fri, 17 Jul 2015 15:30:52 +0200
>> From: Jaroslav Bachorik <jaroslav.bachorik at oracle.com>
>> To: jdk9-dev at openjdk.java.net
>> Subject: Re: CFV: New JDK9 Committer: Amy Lu
>> Message-ID: <55A9038C.7050603 at oracle.com>
>> Content-Type: text/plain; charset=windows-1252; format=flowed
>> Vote: yes
>> -JB-
>> On 17.7.2015 15:23, Paul Sandoz wrote:
>>> I hereby nominate Amy Lu to jdk9 Committer.
>>> Amy helps keep the JDK testing lights on, running ?em, analysis of failures, and fixing ?em.
>>> In total Amy has contributed 27 changes to jdk9/jdk since August 2014 [1].
>>> Votes are due by 31st July.
>>> Only current JDK9 Committers [2] 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 [3].
>>> Thanks,
>>> Paul.
>>> [1]
>>> hg log -f -k amy.lu -k amlu --template "{date|isodate}\n{desc|firstline}\nhttp://hg.openjdk.java.net/jdk9/dev/jdk/rev/{rev}\n\n
>>> 2015-07-16 10:21 +0200
>>> 8131140: Mark some tests from WhileOpStatefulTest.java and WhileOpTest.java as serialization hostile
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12406
>>> 2015-07-16 10:17 +0200
>>> 8130402: Mark intermittently failing test: tools/pack200/PackTestZip64.java
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12405
>>> 2015-06-30 10:00 +0200
>>> 8129759: Mark two tests from DistinctOpTest.java and SliceOpTest.java as serialization hostile
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12256
>>> 2015-06-12 14:28 +0800
>>> 8085879: Mark intermittently failing: java/util/Arrays/ParallelPrefix.java
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12170
>>> 2015-06-03 15:33 +0100
>>> 8081773: sun/net/www/protocol/https/ChunkedOutputStream.java references library that doesn't exist
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12079
>>> 2015-06-03 12:37 +0200
>>> 8081775: two lib/testlibrary tests are failing with "Error. failed to clean up files after test" with jtreg 4.1 b12
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12077
>>> 2015-05-20 17:16 +0300
>>> 8080680: sun/nio/cs/TestCompoundTest.java should be removed from TEST.groups
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/12007
>>> 2015-05-19 11:05 -0400
>>> 8080658: Update sun/nio/cs/FindDecoderBugs.java to use random number generator library
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/11982
>>> 2015-05-08 10:22 +0100
>>> 8079651: (dc) Promiscuous.java fails with NumberFormatException due to network interference
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/11891
>>> 2015-04-03 00:00 -0700
>>> 8076632: Remove duplicate tests: FDTest, MethodReferenceTest and more -- follow-on (completion)
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/11712
>>> 2015-04-02 17:32 -0700
>>> 8075304: Remove duplicate test: FDTest
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/11711
>>> 2015-03-16 10:24 +0100
>>> 8075111: Mark testFlatMappingClose (from CollectorsTest) as serialization hostile
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/11610
>>> 2015-03-10 13:30 +0100
>>> 8074674: Doclint regression in java/util/regex/Matcher.java
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/11583
>>> 2015-02-10 12:28 -0500
>>> 8069255: Suppress deprecation warnings in jdk.rmic module (jdk repo)
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/11380
>>> 2015-01-23 16:16 +0000
>>> 8069262: Doclint regression in java.nio.channels.Channels
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/11302
>>> 2014-12-13 20:22 +0000
>>> 8067112: Update java/util/Collections/EmptyIterator.java to eliminate dependency on sun.tools.java
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/11099
>>> 2014-12-03 14:34 +0000
>>> 8066131: Update java/nio/charset/Charset/NIOCharsetAvailabilityTest.java to eliminate dependency on sun.misc.Launcher
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/11050
>>> 2014-11-26 11:12 -0800
>>> 8060026: Update jdk/test/tools/launcher tests to eliminate dependency on sun.tools.jar.Main
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/11025
>>> 2014-10-16 19:27 -0700
>>> 8060432: tools/pack200/TestNormal.java fails on Windows with java.io.FileNotFoundException after JDK-8058854
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/10847
>>> 2014-10-13 18:16 +0100
>>> 8058856: tools/jar/LeadingGarbage.java, introduced in JDK-8058520, fails on Windows
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/10789
>>> 2014-10-13 17:43 +0100
>>> 8058854: Remove dependency on dt.jar from test/tools/jar/normalize/TestNormal.java
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/10788
>>> 2014-10-11 13:24 +0100
>>> 8058855: Update java.util.zip tests to work with modular image
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/10784
>>> 2014-09-17 23:27 -0400
>>> 8058569: Update java/lang/invoke/lambda tests to eliminate dependency on sun.tools.jar.Main
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/10686
>>> 2014-08-22 18:54 -0700
>>> 8055852: Add test/java/lang/Math/DoubleConsts.java and FloatConsts.java
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/10530
>>> 2014-08-22 14:56 -0700
>>> 8042003: Update java/lang/Math tests to eliminate dependency on sun.misc.DoubleConsts and sun.misc.FloatConsts
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/10529
>>> 2014-08-19 12:26 -0700
>>> 8055262: Update jdk/test/java/util/Base64 tests to remove use of sun.misc.BASE64Encoder/Decoder
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/10518
>>> 2014-08-03 20:09 +0800
>>> 8054095: No space allowed in platforms string in ProblemList.txt
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/10432
>>> [2] http://openjdk.java.net/census#jdk9
>>> [3] http://openjdk.java.net/projects#committer-vote
>> ------------------------------
>> Message: 5
>> Date: Fri, 17 Jul 2015 06:40:56 -0700 (PDT)
>> From: Weijun Wang <weijun.wang at oracle.com>
>> To: <paul.sandoz at oracle.com>
>> Cc: jdk9-dev at openjdk.java.net
>> Subject: Re: CFV: New JDK9 Committer: Amy Lu
>> Message-ID: <e18c0871-22e3-4903-87bc-146ab33755d2 at default>
>> Content-Type: text/plain; charset=UTF-8
>> Vote: yes
>> --Weijun
>> ----- paul.sandoz at oracle.com wrote:
>>> I hereby nominate Amy Lu to jdk9 Committer.
>> End of jdk9-dev Digest, Vol 21, Issue 7
>> ***************************************
More information about the jdk9-dev
mailing list