Re: JDK 9 RFR of JDK-8142370: Move java/util/concurrent/Phaser/Basic.java to tier 2

Hi Amy, On 11/9/2015 7:20 PM, Amy Lu wrote: java/util/concurrent/Phaser/Basic.java fails intermittently (JDK-8141031). This patch is to mark the test with keyword 'intermittent' and moved it to tier 2 until the problem is addressed. bug: https://bugs.openjdk.java.net/browse/JDK-8142370 webr

Re: JDK 9 RFR of JDK-8142370: Move java/util/concurrent/Phaser/Basic.java to tier 2

I approve this change. @key intermittent also added in CVS. We also observe this test to fail, but only very rarely. On Mon, Nov 9, 2015 at 7:44 PM, joe darcy wrote: > Hi Amy, > > On 11/9/2015 7:20 PM, Amy Lu wrote: > >> java/util/concurrent/Phaser/Basic.java fails intermittently (JDK-8141031)

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

Hi Stuart, I don't know if I have any new information to add. When I try to solve this equation, I: - Look at the difference between fixed-arg and non-optimized varargs from my benchmarks (allocating an array doesn't get faster with JIT optimizations, does it?), which is on the order of tens of

JDK 9 RFR of JDK-8142370: Move java/util/concurrent/Phaser/Basic.java to tier 2

java/util/concurrent/Phaser/Basic.java fails intermittently (JDK-8141031). This patch is to mark the test with keyword 'intermittent' and moved it to tier 2 until the problem is addressed. bug: https://bugs.openjdk.java.net/browse/JDK-8142370 webrev: http://cr.openjdk.java.net/~amlu/8142370/we

Code Review for JEP 259: Stack-Walking API

javadoc: http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html webrev: http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.00/ Overview of the implementation: When stack walking begins, the StackWalker calls into the VM to anchor a native frame (callStackWalk) that

Re: Proposed API for JEP 259: Stack-Walking API

I have updated the APIs to incorporate all the feedback. Thank you all. Let me know if I miss any. Summary: 1. Change to use wildcard walk(Function, ? extends T> function) 2. Removed the walk method taking IntUnaryOperator batchSizeMapper argument 3. Add the new static factory method to cre

Re: JDK 9 RFR of JDK-8142369: Move TestLocalTime.java to tier 2

looks good! On 11/9/15 4:27 PM, joe darcy wrote: Hello, The test java/util/zip/TestLocalTime.java fails intermittently (JDK-8135108). The test should be marked accordingly and moved to tier 2 until the problem is addressed. Patch below. Thanks, -Joe diff -r 5ee9639ba99f test/TEST.gr

Re: JDK 9 RFR of JDK-8142363: Remove LFMultiThreadCachingTest.java from windows problem list

+1 On Nov 9, 2015, at 7:05 PM, joe darcy wrote: > Hello, > > With a fix for JDK-8131129 now pushed, the test > > test/java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java > > should be removed from the problem list to see if the fix is effective at > resolving the intermittent failure. >

JDK 9 RFR of JDK-8142369: Move TestLocalTime.java to tier 2

Hello, The test java/util/zip/TestLocalTime.java fails intermittently (JDK-8135108). The test should be marked accordingly and moved to tier 2 until the problem is addressed. Patch below. Thanks, -Joe diff -r 5ee9639ba99f test/TEST.groups --- a/test/TEST.groupsTue Nov 10 01:38:35

Re: JDK 9 RFR of JDK-8142369: Move TestLocalTime.java to tier 2

looks OK On Nov 9, 2015, at 7:27 PM, joe darcy wrote: > Hello, > > The test > >java/util/zip/TestLocalTime.java > > fails intermittently (JDK-8135108). The test should be marked accordingly and > moved to tier 2 until the problem is addressed. > > Patch below. > > Thanks, > > -Joe > >

Re: RFR: 8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches

Hi, so we should add some test cases that guards against Wrapper.zero references leaking through the public API and add stronger wording to Wrapper.zero documentation? I turned your test case below into a jtreg test, included added variants for the other integral primitive types: http://cr

JDK 9 RFR of JDK-8142363: Remove LFMultiThreadCachingTest.java from windows problem list

Hello, With a fix for JDK-8131129 now pushed, the test test/java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java should be removed from the problem list to see if the fix is effective at resolving the intermittent failure. (If JDK-8131129 is not effective, the test should be put back on

Re: RFR: 8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches

1. If the Wrapper.zero "leaks" as a reference into any of the public 292 API, that would be a bug, since the API specifies that the conversion from a zero to a box-reference is the same as mandated by the JLS for boxing conversion. (This is like Integer.valueOf(x), not new Integer(x).) 2. Sinc

Re: RFR (XS): 8141677: Improve java.lang.invoke.MemberName hashCode implementation

Nicely done. +1 > On Nov 9, 2015, at 6:26 AM, Claes Redestad wrote: > > Vladimir, > > I instrumented and counted 7 invocations of MethodName.hashCode during > initialization, so I agree the only real concern from a startup point of view > is avoiding Byte$ByteCache: > > http://cr.openjdk.jav

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

On 11/7/15 9:42 AM, Michael Hixson wrote: (Realizing that we're discussing details of a feature that doesn't exist (frozen arrays)...) It seems to me that as long as the callee invoked the method with comma-separated arguments instead of an array, then the callee can automatically be opted into

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

>>> As to whether this is implementation vs. JAR URL spec then I assume it >>> needs to be spec so that libraries can create URLs that will use runtime >>> versioning when access the JAR. >>> >> >> Yeah, i don’t think we can avoid it. > > Ok. I guess I should put the information in JarURLConn

Re: RFR:JDK-8138664- ZonedDateTime parse error for any date using 'GMT0' ZoneID

Hi Nadeesh, Thanks for fixing this issue. It looks fine, I can sponsor the change for you. Roger On 11/9/2015 4:12 AM, nadeesh tv wrote: Hi all, Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8138664 Issue- ZonedDateTime parse error for any date using 'GMT0' ZoneID So

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

Hi, My first thought would be that if we're running interpreted then we are already deep in the hole performance wise. If in addition we are class loading and initializing then our performance should be dominated by IO, a much deeper hole.  This isn't to say that class initializing cost isn't im

Re: RFR:JDK-8066571:UnsupportedTemporalTypeException is thrown not only in the case of unsupported temporal

Hi Naddesh, Thanks for fixing this issue. I can sponsor getting the fix pushed. Roger On 11/9/2015 4:16 AM, nadeesh tv wrote: Hi all, Please review a fix for Bug Id - https://bugs.openjdk.java.net/browse/JDK-8066571 Issue - IsoFields.Un

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

Hi Peter, nice catch: http://cr.openjdk.java.net/~redestad/8142334/webrev.02 /Claes On 2015-11-09 20:26, Peter Levart wrote: Hi Claes, I see you apply this pattern consistently: private static NamedFunction getConstantFunction(int idx) { NamedFunction function = FUNCTIONS[idx];

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

It’s nice to see these issues get resolved while I was sleeping ;-) >> On 08/11/2015 20:38, Paul Sandoz wrote: >>> : >>> The name is derived from the requirement that if the fragment is present a >>> call to getRuntimeVersionedEntry is required (or the equivalent of), thus >>> the URL is a refer

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

Hi Claes, I see you apply this pattern consistently: private static NamedFunction getConstantFunction(int idx) { NamedFunction function = FUNCTIONS[idx]; if (function != null) { return function; } return makeConstantFunction(idx); } priva

Re: RFR 9: 8132394 : (process) ProcessBuilder support for a pipeline of processes

Hi Paul, Alan, What are the chances that varargs will be updated at some point in the future to use Lists instead of arrays? It would be a bit of thrash to try to avoid varargs if varargs is likely to be updated. It is a bit awkward at the moment though. I'd hope that at some point varargs

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

Hi Michael, Peter, I admit to not having followed all the benchmarking discussion (travel, Devoxx) but I did want to respond to this: Peter wrote: So it looks like that there's no need to burden the public API with explicit argument overloads. These are JMH benchmarks, which take care to w

Re: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class

Using @Stable breaks down some of the complexity. And the CHM (with the winning computeIfAbsent) breaks down lots more. Nice job! I'm a little sad that it needs two CHMs (CACHE and CLASS_CACHE). This must be because there are three or four states per key, instead of the usual two. These states sh

Re: 8141652 : Rename methods Objects.nonNullElse* to requireNonNullElse*

Hi Stephen, On 11/6/2015 10:42 PM, Stephen Colebourne wrote: Seems fine to me. I would have inlined the ZoneId change to one line: String id = Objects.requireNonNullElse(aliasMap.get(zoneId), zoneId); to avoid the local variable change, but no big deal. Stephen Thanks, I'll fix that. Roger

Re: RFR 9: 8132394 : (process) ProcessBuilder support for a pipeline of processes

Hi Paul, Thanks for the review, On 11/9/2015 4:32 AM, Paul Sandoz wrote: Hi Roger, ProcessBuilder — 711 * The FileDescriptor is used as the standard input of the next Process 712 * begin started. s/begin/to be started ? ok 714 static class RedirectPipeImpl extends Red

RFR: 8142334: Improve lazy initialization of java.lang.invoke

Hi, across java.lang.invoke there are a number of inner Lazy classes whose purpose is to defer initialization of various internally used NamedFunctions and MethodHandles until first usage. The issue is that once *any* function or handle in these classes are referenced they're all initialized,

Re: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class

... thanks a lot, Peter and Vladimir! Best, Michael > Am 09.11.2015 um 13:42 schrieb Vladimir Ivanov : > > Looks good! > > Best regards, > Vladimir Ivanov > > On 11/9/15 3:16 PM, Peter Levart wrote: >> Hi all, >> >> Thanks for analysis, reviews and discussion that hopefully beheaded this >>

Re: RFR: updated draft API for JEP 269 Convenience Collection Factories

There's another issue with relying on EA, which is EA will not analyze methods above a certain (bytecode) size; IIRC it's around 150. So if this method gets inlined into a bulky method, the varargs will not be eliminated, I believe. I don't think it's a problem for this API for the reasons I ment

Re: RFR: 8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches

Looks much better now. Reviewed. Best regards, Vladimir Ivanov On 11/9/15 4:36 PM, Claes Redestad wrote: Vladimir, thanks for asserting this. The j.l.invoke code is still rather foreign to me, so I took extreme precautions to not change any semantics. Simplified thusly: http://cr.openjdk.jav

Re: RFR 9: 8132394 : (process) ProcessBuilder support for a pipeline of processes

Hi Alan, Thanks for comments, On 11/9/2015 6:20 AM, Alan Bateman wrote: On 05/11/2015 21:56, Roger Riggs wrote: Please review the new ProcessBuilder.startPipeline API, implementation, and tests. : javadoc of ProcessBuilder: only startPipeline is new: http://cr.openjdk.java.net/~rriggs

Re: RFR: 8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches

Vladimir, thanks for asserting this. The j.l.invoke code is still rather foreign to me, so I took extreme precautions to not change any semantics. Simplified thusly: http://cr.openjdk.java.net/~redestad/8141678/webrev.03/ Effects remain largely the same. Thanks! /Claes On 2015-11-09 13:13

Re: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class

Hi all, Thanks for analysis, reviews and discussion that hopefully beheaded this hydra. I added an assert to method setSpeciesDataToConcreteBMHClass() that verifies the presence of @Stable annotation on the SPECIES_DATA field of the generated class. It caught a bug I made when I specified a

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

+1000 sent from my phone On Nov 9, 2015 7:49 AM, "Doug Lea" wrote: > On 11/09/2015 05:43 AM, Chris Hegarty wrote: > >> On 02/11/15 10:45, Aleksey Shipilev wrote: >> >>> On 11/02/2015 02:56 AM, Chris Hegarty wrote: >>> In line with the intended location for other VM annotations, see 813

Re: RFR: 8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches

On 11/09/2015 02:13 PM, Claes Redestad wrote: >> Can we avoid shared secrets by doing the following? >> >> @HotSpotIntrinsicCandidate >> public static Byte valueOf(byte b) { >> if (b == 0) return ZERO; >> final int offset = 128; >> return ByteCache.cache[(int)b + offset]; >> } > > I

Re: RFR (XS): 8141677: Improve java.lang.invoke.MemberName hashCode implementation

Reviewed. Best regards, Vladimir Ivanov On 11/9/15 5:26 PM, Claes Redestad wrote: Vladimir, I instrumented and counted 7 invocations of MethodName.hashCode during initialization, so I agree the only real concern from a startup point of view is avoiding Byte$ByteCache: http://cr.openjdk.java.n

Re: RFR (XS): 8141677: Improve java.lang.invoke.MemberName hashCode implementation

Vladimir, I instrumented and counted 7 invocations of MethodName.hashCode during initialization, so I agree the only real concern from a startup point of view is avoiding Byte$ByteCache: http://cr.openjdk.java.net/~redestad/8141677/webrev.02/ Thanks! /Claes On 2015-11-09 12:33, Vladimir Iv

Re: RFR: 8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches

> On 9 Nov 2015, at 14:36, Claes Redestad wrote: > > Vladimir, > > thanks for asserting this. Indeed! > The j.l.invoke code is still rather foreign to me, so I took extreme > precautions to not change any semantics. > > Simplified thusly: > > http://cr.openjdk.java.net/~redestad/8141678/w

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

On 09/11/15 12:34, Peter Levart wrote: On 11/09/2015 01:32 PM, Peter Levart wrote: On 11/09/2015 11:43 AM, Chris Hegarty wrote: On 02/11/15 10:45, Aleksey Shipilev wrote: On 11/02/2015 02:56 AM, Chris Hegarty wrote: In line with the intended location for other VM annotations, see 8138732

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

On 11/09/2015 05:43 AM, Chris Hegarty wrote: On 02/11/15 10:45, Aleksey Shipilev wrote: On 11/02/2015 02:56 AM, Chris Hegarty wrote: In line with the intended location for other VM annotations, see 8138732 [1], @sun.misc.Contended should be moved to the jdk.internal.vm.annotation package. http

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

On 11/09/2015 11:43 AM, Chris Hegarty wrote: On 02/11/15 10:45, Aleksey Shipilev wrote: On 11/02/2015 02:56 AM, Chris Hegarty wrote: In line with the intended location for other VM annotations, see 8138732 [1], @sun.misc.Contended should be moved to the jdk.internal.vm.annotation package. ht

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

On 11/09/2015 01:32 PM, Peter Levart wrote: On 11/09/2015 11:43 AM, Chris Hegarty wrote: On 02/11/15 10:45, Aleksey Shipilev wrote: On 11/02/2015 02:56 AM, Chris Hegarty wrote: In line with the intended location for other VM annotations, see 8138732 [1], @sun.misc.Contended should be moved

Re: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class

Looks good! Best regards, Vladimir Ivanov On 11/9/15 3:16 PM, Peter Levart wrote: Hi all, Thanks for analysis, reviews and discussion that hopefully beheaded this hydra. I added an assert to method setSpeciesDataToConcreteBMHClass() that verifies the presence of @Stable annotation on the SPEC

Re: RFR 9: 8132394 : (process) ProcessBuilder support for a pipeline of processes

> On 9 Nov 2015, at 12:20, Alan Bateman wrote: > > > > On 05/11/2015 21:56, Roger Riggs wrote: >> Please review the new ProcessBuilder.startPipeline API, implementation, and >> tests. >> >> : >> >> javadoc of ProcessBuilder: only startPipeline is new: >> http://cr.openjdk.java.net/~rrigg

Re: RFR: 8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches

Claes, I don't think Wrapper.zero identity matters (e.g. see MethodHandles.constant [1] or InvokerBytecodeGenerator.emitConst). So, you can considerably simplify your code by allocating fresh wrapper instances. Best regards, Vladimir Ivanov [1] public static MethodHandle constant(Class

Re: RFR (XS): 8141677: Improve java.lang.invoke.MemberName hashCode implementation

Claes, If you want to avoid Byte$ByteCache initialization, don't you achieve the same just by wrapping reference kind manually [1]? Regarding getting rid of varags method call (Objects.hashCode), do you see any measurable improvements? I'm reluctant to see such changes (manual method body in

Re: RFR 9: 8132394 : (process) ProcessBuilder support for a pipeline of processes

On 05/11/2015 21:56, Roger Riggs wrote: Please review the new ProcessBuilder.startPipeline API, implementation, and tests. : javadoc of ProcessBuilder: only startPipeline is new: http://cr.openjdk.java.net/~rriggs/pipedoc/ I skimmed over the javadoc and it looks quite good. The method

Re: RFR: 8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches

Hi Paul, On 2015-11-09 09:42, Paul Sandoz wrote: Hi Claes, How much difference are you observing? On jake startup this removes about 22Kb, 8 classes and some 1000+ objects from Hello World, and much of that will never be loaded with this approach (Short.valueOf, Character.valueOf and Byte.v

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

On 11/09/2015 01:43 PM, Chris Hegarty wrote: > On 02/11/15 10:45, Aleksey Shipilev wrote: >> On 11/02/2015 02:56 AM, Chris Hegarty wrote: >>> In line with the intended location for other VM annotations, >>> see 8138732 [1], @sun.misc.Contended should be moved >>> to the jdk.internal.vm.annotation p

Re: RFR 9: 8132394 : (process) ProcessBuilder support for a pipeline of processes

Hi Roger, ProcessBuilder — 711 * The FileDescriptor is used as the standard input of the next Process 712 * begin started. s/begin/to be started ? 714 static class RedirectPipeImpl extends Redirect { 715 final FileDescriptor fd; 716 717 RedirectPipeImpl() {

Re: jmx-dev RFR 6425769: jmx remote bind address

On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: > Hi, > > Updated webrev with jtreg test in Java: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ > bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > I believe this updated webrev addresses all concerns and incorpora

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

On 02/11/15 10:45, Aleksey Shipilev wrote: On 11/02/2015 02:56 AM, Chris Hegarty wrote: In line with the intended location for other VM annotations, see 8138732 [1], @sun.misc.Contended should be moved to the jdk.internal.vm.annotation package. http://cr.openjdk.java.net/~chegar/8140687/00/ C

Re: RFR: 8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches

Hi Claes, How much difference are you observing? If it is small perhaps it’s worth waiting to see if there are much larger improvements we can make, as the non-obvious tight coupling also has it’s own cost in terms of maintenance. Can we avoid shared secrets by doing the following? @HotSpotIn

Re: RFR (XS): 8141677: Improve java.lang.invoke.MemberName hashCode implementation

> On 8 Nov 2015, at 21:55, Aleksey Shipilev wrote: > > On 11/08/2015 03:30 PM, Claes Redestad wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8141677 >> webrev: http://cr.openjdk.java.net/~redestad/8141677/webrev.01/ > > The approach looks sensible. The implementation deserves a comment

Re: Questions about Stream/Iterable/Files / FOLDING Collector

Hi Tagir, "Let a thousand flowers bloom” :-) It’s great you can do this. For the moment i am ok with waiting until we have better mechanisms in the language platform to do even better [*], then we can gather use-cases based on developer experience such as yours. Paul. [*] FWIW we experimented

Re: Questions about Stream/Iterable/Files - and possibly the compiler

> On 7 Nov 2015, at 00:16, Peter Levart wrote: > > > > On 11/07/2015 12:02 AM, Peter Levart wrote: >> How would you otherwise write a parallel stream into a file if it was not by >> using a Collector? Would you make it serial 1st? > > Ah, yes. forEachOrdered() ! > Exactly! triggering a for

RFR:JDK-8066571:UnsupportedTemporalTypeException is thrown not only in the case of unsupported temporal

Hi all, Please review a fix for Bug Id - https://bugs.openjdk.java.net/browse/JDK-8066571 Issue - IsoFields.Unit.issupportedBy was not checking isIso() Solution - Moved isIso() from Filed to IsoFields sothat both Field and Unit can use Apa

RFR:JDK-8138664- ZonedDateTime parse error for any date using 'GMT0' ZoneID

Hi all, Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8138664 Issue- ZonedDateTime parse error for any date using 'GMT0' ZoneID Solution - Handled the GMT0 separately in the parsing method BugId - https://bugs.openjdk.java.net/browse/JDK-8138664 webrev - http://cr.openjd

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> On 9 Nov 2015, at 09:19, Alan Bateman wrote: > > > > On 08/11/2015 20:38, Paul Sandoz wrote: >> : >> The name is derived from the requirement that if the fragment is present a >> call to getRuntimeVersionedEntry is required (or the equivalent of), thus >> the URL is a reference to a runtim

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 08/11/2015 20:38, Paul Sandoz wrote: : The name is derived from the requirement that if the fragment is present a call to getRuntimeVersionedEntry is required (or the equivalent of), thus the URL is a reference to a runtime versioned entry. I was just wondering about something shorter, li