CFV: New JDK9 Committer: Amy Lu
Mike Duigou
openjdk at duigou.org
Fri Jul 17 17:16:36 UTC 2015
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