Re: Review request: JDK-8157246 MHs.arrayLength, arrayElementGetter/Setter, arrayConstructor need to specify invocation-time behavior

> On 7 Nov 2017, at 12:06, mandy chung wrote: > > http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8157246/webrev.00/index.html > > This fixes the spec of MethodHandles::arrayLength, arrayConstructor, > arrayElementGetter/Setter to specify the behavior if the returned method > handle is invok

Re: RFR 8187742 Minimal set of bootstrap methods for dynamic constants

On Nov 7, 2017, at 1:35 PM, fo...@univ-mlv.fr wrote: > > perhaps getFinalStatic, because it's restricted to final field. The restriction to final field is because we are expecting the method to be used from condy, where it seems to be a syntax error to sample a constant from a non-constant variab

Re: RFR 8187742 Minimal set of bootstrap methods for dynamic constants

> On 8 Nov 2017, at 08:59, John Rose wrote: > > On Nov 7, 2017, at 1:35 PM, fo...@univ-mlv.fr > wrote: >> >> perhaps getFinalStatic, because it's restricted to final field. > > The restriction to final field is because we are expecting the > method to be used from c

Re: [Patch][JDK10] Use Class.getPackageName() where possible

Hi Mandy, yes, the revision in the webrev is correct; the trailing '.' in the pkg was just to ensure it was a package prefix. +1, Roger On 11/7/2017 6:00 PM, mandy chung wrote: On 11/7/17 6:48 AM, Christoph Dreis wrote: === PATCH === diff -r 67aa34b019e1 src/java.base/share/cla

Re: Review request: JDK-8157246 MHs.arrayLength, arrayElementGetter/Setter, arrayConstructor need to specify invocation-time behavior

On 11/8/17 8:49 AM, Paul Sandoz wrote: On 7 Nov 2017, at 12:06, mandy chung wrote: http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8157246/webrev.00/index.html This fixes the spec of MethodHandles::arrayLength, arrayConstructor, arrayElementGetter/Setter to specify the behavior if the retu

Re: Review request: JDK-8157246 MHs.arrayLength, arrayElementGetter/Setter, arrayConstructor need to specify invocation-time behavior

> On 8 Nov 2017, at 10:13, mandy chung wrote: > > > > On 11/8/17 8:49 AM, Paul Sandoz wrote: >>> On 7 Nov 2017, at 12:06, mandy chung >>> wrote: >>> >>> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8157246/webrev.00/index.html >>> >>>

Re: Review request: JDK-8157246 MHs.arrayLength, arrayElementGetter/Setter, arrayConstructor need to specify invocation-time behavior

Hi Mandy, A few editorial suggestions: MethodHandle.java: 891: "accepts**a** zero-length trailing array argument 895: "if **the* *{@code array} does" MethodHandleImpl.java: 667:  hard to follow indentation; perhaps adding the "else" will help. MethodHandles.java: 2517: "Produces a method handl

RFR 8190974 Parallel stream execution within a custom ForkJoinPool should obey the parallelism

Hi, Please review this patch to ensure that a parallel stream obeys the parallelism of a custom fork join pool when it is executed within that pool: http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/

Re: [Patch][JDK10] Use Class.getPackageName() where possible

Thanks Roger. Christoph - your patch has been pushed to jdk/jdk repo. Mandy On 11/8/17 10:11 AM, Roger Riggs wrote: Hi Mandy, yes, the revision in the webrev is correct; the trailing '.' in the pkg was just to ensure it was a package prefix. +1, Roger On 11/7/2017 6:00 PM, mandy chung

RE: [Patch][JDK10] Use Class.getPackageName() where possible

Hi Mandy, > Christoph - your patch has been pushed to jdk/jdk repo. I appreciate the sponsoring. Thanks! Cheers, Christoph

Re: RFR: jsr166 jdk10 integration wave 5

> On 6 Nov 2017, at 12:00, Martin Buchholz wrote: > > The notable thing this time around is the embarrassing number of rare races > being fixed, all of which are second tries. This time for sure! > > There's a large number of boring changes to appease errorprone, notably > http://errorprone.i

Re: RFR: jsr166 jdk10 integration wave 5

On Wed, Nov 8, 2017 at 2:09 PM, Paul Sandoz wrote: > > > 685 final Node succ(Node p) { > 686 // TODO: should we skip deleted nodes here? > > Is the comment still relevant? > It's still an open question, like what's the best GC strategy, or should ArrayList automatically shrink (as

Re: RFR: jsr166 jdk10 integration wave 5

> On 8 Nov 2017, at 14:20, Martin Buchholz wrote: > > > > On Wed, Nov 8, 2017 at 2:09 PM, Paul Sandoz wrote: > > > 685 final Node succ(Node p) { > 686 // TODO: should we skip deleted nodes here? > > Is the comment still relevant? > > It's still an open question, like what's

Re: RFR 8190974 Parallel stream execution within a custom ForkJoinPool should obey the parallelism

You probably want a different summary. + * @summary Tests counting of streams containing Integer.MAX_VALUE + 1 elements Will this fail if common pool parallelism is odd? +int splitsForPHalfC = countSplits(new ForkJoinPool(ForkJoinPool.getCommonPoolParallelism() / 2)); I would drop

Re: Review request: JDK-8157246 MHs.arrayLength, arrayElementGetter/Setter, arrayConstructor need to specify invocation-time behavior

Hi Roger, Updated version: http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8157246/webrev.02/index.html On 11/8/17 11:37 AM, Roger Riggs wrote: Hi Mandy, A few editorial suggestions: MethodHandle.java: 891: "accepts**a** zero-length trailing array argument Fixed 895: "if **the* *{@code ar

Re: RFR 8187742 Minimal set of bootstrap methods for dynamic constants

On Nov 7, 2017, at 12:59 PM, John Rose wrote: > > For condy, having the BSM validate types is a code smell > for the reason you mention. Also, when primitives (and value > types) are in the mix, people usually code the validation > incorrectly, since Class.isInstance is the wrong tool, and > the

Re: RFR 8190974 Parallel stream execution within a custom ForkJoinPool should obey the parallelism

> On 8 Nov 2017, at 15:48, Martin Buchholz wrote: > > You probably want a different summary. > + * @summary Tests counting of streams containing Integer.MAX_VALUE + 1 > elements > Doh, indeed. > Will this fail if common pool parallelism is odd? > +int splitsForPHalfC = countSplit

Re: RFR 8190974 Parallel stream execution within a custom ForkJoinPool should obey the parallelism

Looks good, but have comments as always. Fix type: exection Unrelated typo: the this slice spliterator I would test core libraries under taskset with an odd number of cpus On Wed, Nov 8, 2017 at 4:43 PM, Paul Sandoz wrote: > > On 8 Nov 2017, at 15:48, Martin Buchholz wrote: > > You probabl